Butting Heads Over the '906 Rebuttal
by Dale Dougherty
The Eolas '906 patent describes a method for embedding a hypermedia application in a browser window such that a user can control or manage the output of this separate application within the window. I wrote about the reexam of Eolas, which was formally requested by the W3C citing additional prior art in the original HTML specification and a proposed HTML+ specification. In March of this year, the PTO issued a preliminary finding rejecting the claims in the patent. This rebuttal by Eolas is an attempt to refine their claims and, in effect, re-write the early history of the Web’s development to suit their own narrow interests. To do that, Doyle and Felten constrain the Web to what they thought it was and thus limit its capabilities. In short, Doyle claims to have invented a special kind of interactivity that was not obvious to anyone at the time.
Not a lot of coverage has been given to the arguments that Eolas uses to support their claims. Eolas and the University of California apparently issued statements to the press when they submitted their rebuttal to the PTO, but their papers were not generally available. (And so stories such as this one did not cover any of the details of their argument.) I have obtained a copy indirectly from the official PTO files, and in view of the technical arguments that they advance, I am not surprised that Eolas did not widely circulate their written materials. I have provided a zip file containing these documents so you can judge for yourself.
The basic premise of Eolas’ written response is that browser developers working in 1993 and 1994 did not consider embedding interactive applications in the browser window and that the browser simply rendered static information. Felten makes the statement that Berners-Lee’s HTML specification “teaches away from the provision of rich interactivity in the browser.” Felten says that “Berners-Lee teaches a language for authoring Web pages but it does not teach how to build a browser or how a browser works.” Those statements are completely inconsistent with Tim Berners-Lee’s vision of the Web. Berners-Lee talked about browsers that were equally capable of reading and writing, which goes back to Ted Nelson’s definition of hypertext as non-linear writing. In his book, “Weaving the Web,” Berners-Lee uses the phrase “browser/editor” to refer to the kind of client application he envisioned as a Web browser. He writes about his own prototyping of the first Web client, which he said was “basically like a word processor”: “By mid-November I had a point-and-click browser/editor which I called WorldWideWeb.” He goes on to say that “the browser would decode URIs, and let me read, write or edit Web pages in HTML.” This reflects the spirit of early Web development, as I recall hearing it first-hand. (Today’s wikis and weblogs seem to close to realizing this vision.)
Felten and Doyle ignore most of this early history and insist that the browser was designed only to display static information. They are setting up a false dichotomy between static and interactive. Is a document that you can edit in a word processor static or not? Felten argues, for instance, that the only kind of editing possible was through a helper application. The place to look for Berners-Lee’s vision in is not in the HTML specification but the methods section of the http protocol as defined in 1992, which not only described the GET request but the PUT and POST requests, among others. Mosaic chose not to provide editing capability, but this doesn’t mean that it was not part of the vision. In fact, Berners-Lee was frustrated that Mosaic did not provide integrated editing capabilities.
In developing the HTML+ specification, David Raggett introduced the EMBED tag to “provide a simple form of object level embedding,” Felten characterizes the purpose of the EMBED tag “to display new types of static information.” The proposed spec adds that “sophisticated browsers can link to external editors for creating or revising embedded data” and Felten says that “there is nothing to suggest that the “external editors” would provide any display within a web browser window.” This interpretation, however, is directly at odds with the purpose of the HTML+ proposal.
The discussion of the EMBED tag, recorded still in the WWW-Talk archives, assumed that the viewer sub-window in the browser window would be active and under the control of the user via the viewer program for interacting with content such as movies. (Again, Felten must argue that movies are understood to be static content.) Two messages in particular directly contradict the position Eolas now urges and mention calling Windows DLLs. No special line was drawn around interactive content, and certainly the Eolas patent contributed nothing in regard to allowing such cooperation between active programs.
Raggett posted a message (on June 14, 1993) to WWW-Talk (it is called Raggett II in the W3C filing):
Browsers can then be upgraded to display new formats without changing their code at all. All you would need is a way of binding the MIME content type to the function name for that format, e.g. via X resources or a config file. The functions could be implemented as separate programs driven via pipes and stdin/stdout or as dynamically linked library modules (Windows DLLs).
Bill Janssen’s message (#482) follows within an hour of the Raggett II email, and provides his interpretation, which Eolas uses to bootstrap all their special meaning technical talk about pipes and DLLs.
Yes, that sounds good. My favorite way to handle this is to have the browser create and manage an X sub-window over the area where the inset is to be displayed, and pass the window ID of the sub-window to the subprogram which understands the inset format, with the understanding that that program is to handle all events and refresh on the sub-window, but the browser gets to handle configuration and window movement.
In many ways, this describes the technical solution that Doyle et al disclosed in the ‘906 patent. Accordingly, if what Doyle et al disclosed is dynamic and interactive, then Raggett I and II are also dynamic and interactive.
Kevin Altis, at Intel, also responded (message 564) on this same thread following Raggett II:
This is the only sane way to deal with ‘foreign’ elements that a browser can’t understand or render itself. The number of foreign object types (pictures, equations, spreadsheets, movies etc., open and platform specific picture formats, different ways of specifying equations, etc. will quickly overwhelm anyone writing browsers. It also clutters the very simple HTML we now have. In some cases it may even be possible to translate certain images, such as FAX data into text, that a browser can handle.
Digression: Under Windows you could use Dynamic Link Libraries for the Browser to display data types it does not know about: movies, spreadsheets, etc. and on the Mac you could also use DLL or AppleEvents.
-- Message 564
Obviously, both Janssen and Altis read Raggett’s email as describing precisely what the PTO contended it described in rejecting the ‘906 patent claims. One could argue that if they saw the browser as a kind of word processor, then it was natural to embed objects like spreadsheets or movies inside documents and that those embedded objects would be functional as well.
Of course, one should also pay attention to the Viola browser and its demonstration of embedded applications, which I worked on with Pei Wei. See Pei Wei’s comments about the patent .
Felten writes: “I have been told that by patent counsel for Eolas and the Regents that a patent may not be obtained, even though the invention is not anticipated, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would not have been obvious at the time the invention was made to a person having ordinary skill in the art to which the subject matter pertains.” He goes on to define a person having “ordinary skill in the art” as someone who has recently graduated from a computer science program or has “acquired equivalent knowledge through experience in the industry.” So, if Felten and Doyle must argue that the invention covered by the 906’ could not be produced by someone of ordinary skill in the art of browser development, they should know that Pei and an associate, Scott Silvey, were undergraduates at Berkeley in 1993 when they demonstrated the kind of application running inside a browser that Doyle claims to have invented later on.
Since the PTO has taken the brave step of revisiting their original decision to grant the Eolas patent, we can only hope that they will see the broader context of early Web development in evaluating the narrow and revisionist explanation of the Web browser provided by Eolas.
Are you following the '906 patent?
A review of the Eolas rebuttals
I'm a little concerned that no one is paying attention to this case anymore. I'm a software developer and recently a client of the company I work for asked us to review this case. What I learned from the whole thing is that the patent process in the US with regards to software in particular is broken.