\n\nI hate software patents. I don't even like them when they're being used to screw Microsoft. But I particularly hate it when someone buys a patent (this patent was originally awarded to the University of California), sits on it for years, and then starts suing people over it -- having done nothing useful with it or anything else in the meantime. But let's take a look at this patent on its merits:\n
A system allowing a user of a browser program on a computer connected to an open distributed hypermedia system to access and execute an embedded program object. The program object is embedded into a hypermedia document much like data objects (1). The user may select the program object from the screen (2). Once selected the program object executes on the user's (client) computer or may execute on a remote server or additional remote computers in a distributed processing arrangement (3). After launching the program object, the user is able to interact with the object as the invention provides for ongoing interprocess communication between the application object (4) (program) and the browser program. One application of the embedded program object allows a user to view large and complex multi-dimensional objects from within the browser's window. The user can manipulate a control panel to change the viewpoint used to view the image. The invention allows a program to execute on a remote server or other computers to calculate the viewing transformations and send frame data to the client computer thus providing the user of the client computer with interactive features and allowing the user to have access to greater computing power than may be available at the user's client computer (5).\nI've labeled what seem to me to be the main claims in the abstract. (I will get to the specific claims -- er claim -- later, and IANAL let alone a patent lawyer). Note that a lot of text -- none of it bold -- is devoted to implementing something like VRML but rendered on the server -- I don't think they'll be suing anyone over that nugget.\n
... a browser application, that parses a first distributed hypermedia document to identify text formats included in said distributed hypermedia document and for responding to predetermined text formats to initiate processing specified by said text formats; utilizing said browser to display, on said client workstation, at least a portion of a first hypermedia document received over said network from said server, wherein the portion of said first hypermedia document is displayed within a first browser-controlled window on said client workstation, wherein said first distributed hypermedia document includes an embed text format, located at a first location in said first distributed hypermedia document, that specifies the location of at least a portion of an object external to the first distributed hypermedia document, wherein said object has type information associated with it utilized by said browser to identify and locate an executable application external to the first distributed hypermedia document, and wherein said embed text format is parsed by said browser to automatically invoke said executable application to execute on said client workstation in order to display said object and enable interactive processing of said object within a display area created at said first location within the portion of said first distributed hypermedia document being displayed in said first browser-controlled window.\nIn other words, the \"embedded\" data object has \"type information\" used to pick the external plugin that displays and allows interaction with its data in a display area in the browser window.\n\nThis appears to be the single thing on which they are basing their lawsuit. It's no small thing, but it does seem to me to be obvious. After all, how do browsers handle links to non-textual embedded data that doesn't require a plugin. The only major example in 1995 was images, e.g. gifs and jpegs. These were, and are, embedded using <img> tags which contain a URL (here's where the actual image data is) and dimensioning information (here's the width and height). <img> tags don't contain any real metadata beyond themselves (I'm an <img> tag, which connotes I refer to an image) and -- arguably -- the \"filename extension\" at the end of their src URL (which is often garbage).\n\nNow, browsers don't render images themselves, as a rule, they call on external libraries or the operating system to do it. So an <img> tag is basically saying \"here's a link to some image data, and this is how big I'd like you to render it\" and the browser gets this information and calls external software to render it. Images aren't interactive, so that's not covered -- but OpenDoc and PageMaker and so forth have interprocess event handling covered in spades.\n\nSo let's suppose you're a programmer and you know about <img> tags and it occurs to you that there's no way to embed QuickTime movies (say) in your web page. And no way to handle Illustrator files. And no way to display 3D models. What to do? Any decent programmer is going to immediately consider coming up with a new kind of tag for each kind of document, and then replace the code that handles <img> tags with a huge switch statement somewhere and decide this sounds like hard work and bad architecture.\n\nAbandoning the totally obvious -- but obviously bad -- solution, the next most obvious solution is to invent a generic embed tag and move the information connoted by the tag's name (\"img\") into the attributes of the tag itself (e.g. type=\"image\"). And, again obviously, expecting the browser to be modified and recompiled every time we pull a new media type out of our asses is stupid, so let's generalize the \"get the OS to render it\" side of things by mapping types to specific pieces of software (\"plugins\"). Oh, and the data might be interactive (e.g. movies need a play button and they need to be refreshed more often than images) so we'll need to pass events to and fro. OMG call up the patent attorney.\n\nThe only thing missing from OpenDoc was the ability to embed a url for downloading the \"part editor\" you need if you don't already have it. OK, that may be genuinely novel. But how is it also not obvious given this is web browsers we're talking about. I didn't use OpenDoc for much serious work, so I don't remember what OpenDoc did when you opened a document containing parts for which you lacked editors -- I know it coped, but I can't remember exactly how much information it provided you with. If it told you something about the component needed to deal with the part and from whom it might be obtained, then Apple even has prior art for this.\n\nIt's easy to claim something is obvious in hindsight. I think I've demonstrated that -- at the very least -- OpenDoc represents prior art for almost everything in the patent (even the minutiae). If OpenDoc documents were web pages, and OpenDoc data embedding automatically included a way to obtain (download) the software required to handle it (and -- arguably -- it did, just not URLs since OpenDoc wasn't a web browser) then this patent would be completely meaningless. (And, frankly, if web pages were OpenDoc documents it would be pretty awesome -- if OpenDoc were still around and didn't suck.)\n