W3C home > Mailing lists > Public > public-web-plugins@w3.org > September 2003

More Prior Art - Smoking gun? RFC 965 "A Format for a Graphical Communication Protocol" Dec/1985

From: Hector Santos <winserver.support@winserver.com>
Date: Tue, 2 Sep 2003 08:54:30 -0400
Message-ID: <002e01c37151$5b71f330$92dc9e44@FAMILY>
To: "web-plugins" <public-web-plugins@w3.org>

This is the smoking gun?  More prior art description a remote client/server
concept of transforming server commands to graphic images on a client
machine.

http://www.ietf.org/rfc/rfc965.txt

I don't know about anyone else, but there is SO much prior art and
information showing the obviousness and the non-novelty of Mr. Doyle patent
it really isn't funny anymore - but shocking and even more shocking
Microsoft is having a hard time with this.  In my opinion,  this RFC is the
smoking gun.  Check out this particular section along with my HLS inline
comments:

From RFC 965

V.  AN ARCHITECTURE FOR PIGCF PROCESSING

   This section presents an example software architecture for the
   generation and interpretation of PIGCF in a multimedia conferencing
   system using GKS as the underlying programmer's graphics interface.

HLS: Cool. Today we got HTML!

   This section should not be interpreted as a definitive statement of
   such an architecture, but only as an exercise to illustrate how the
   format proposed in this paper fits within the overall framework of a
   conferencing system. Choosing GKS simplifies the example
   architecture; nevertheless, other graphics packages can be used by
   adding, to the architecture, the modules to interpret and generate
   the PIGCF level L items.

HLS: So what you are saying is that its the IDEA that counts?  Never mind
how its implemented?

   Figure 1 shows the major software modules charged with graphics
   interaction and display at a conferencing workstation. This is a
   familiar programmer's view of the graphics pipeline. A conferencing
   application program updates data structures and uses
   device-independent graphics services through a language binding.

HLS: Language Binding -- hmmm, sounds familiar!

   These services, in turn, use device-dependent graphics services that
   call on device drivers to accept input and to present graphic
   pictures. ......

HLS:  Device drivers == remote terminal applets!  Accept input? You
mean interact with the end-users?

   ..... The application performs numerous other functions for
   conference management and control of other media streams, but we need
   not consider them in this example.

HLS:  You mean like a image Panning /Zooming and other interactive actions?

   In Figure 2, the basic graphics pipeline has been augmented with the
   software modules involved in the generation, transmission, reception,
   and interpretation of PIGCF streams. ....

HLS:  Whoa! Let me get this straight.  You mean you have hosting software
(web sever),  transfer software (TCP/IP), reception software (Browser) and
interpretation software (client side applets?)  HA!  That pretty much covers
it!!  But that's impossible, its still only 1985!!!  Mr. Doyle is NOT HERE
yet!

   ... The application has a module for
   interpreting the lower and higher levels of PIGCF and one for
   generating the upper level U. The device-independent graphics
   services include modules for generating and interpreting the lower
   level, L.....

HLS:  Now you getting fancy on me!!

  .... This reflects the current practice of including the
   generation and interpretation functions in the graphics package.

HLS:  Current practice of SENDING components to end-user machines?  Wait a
second!  Again! You are way ahead of yourself! This is 1985 and Mr. Doyle
did not invent the practice yet!

   There is also a module that transmits the outgoing PIGCF streams to
   remote work stations. Similarly, there is a module that receives
   incoming streams from remote  stations..  In actual practice, the
   transmit and receive modules are decomposed  into several processes
   implementing a layered protocol architecture.

HLS: Yeah,  you already said this!

I have to be nuts but I suggest the following:

Mr. Doyle borrowed a page or two from existing, published RFC 965
information and other videotext concepts already in work and high in the
"Future technology Index".   He is probably a Unix wienie, but also had
access to IBM/Sears Prodigy with its mass marketing of "Videotext" systems.
He probably was also a CompuServe user and maybe used a some of the
frontends for it.   Or maybe he was lurking the Fidocon 89 trade show and
saw my Gold Xpress demonstration of plotting Pie Charts and Histograms on a
remote client system based on interpreted data received from the remote host
system.   Either way,  he then takes public domain software,  twisted it
little to implement RFC 965 and videotext  ideas and uses the currently
growing internet HTML protocol to demonstrate that it does WORK!

Who knows!?

One thing for sure he was definitely exposed to the prior art.  There was
just too much of it around.  And if not, then he isn't much of a PHD!
Sorry Michael.

If anything,  you have a copyright, not a patent!

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
Received on Tuesday, 2 September 2003 08:56:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:03 UTC