Re: If MS pulls plug-in support, who do I sue

Again, the gist of this erroneous patent is two parts:

First,  REMOTE client/server operations.  The key is REMOTE.

OLE was LOCAL machine operations.  The next generation of OLE aka
ACTIVEX/COM and DCOM made it network based,  thin (or FAT as I like to call
it with you use a PC) client, etc, system.

Although the patent talks about existing prior-art, it uses the "prior art"
to illustrate the "problem" thus defining the need for this patent or what
this patent solves.

Second, since within a LOCAL system, all the components will be available,
in a REMOTE arrangement, the client may or may not have the components to
handle the data.   So the other part of the claim is the ability to
associate the data with a "handler" and this handler is automatically sent
to the client and automatically installed.  The data can handled by the
client.   How the data is displayed is immaterial.  Pop it up in another
window or within the same window, it doesn't matter.

So lets imagine the patent locks itself into a "Frame" window concept,  then
you win - you bypass the patent by displaying another way.   In fact,  is
this was the case,  this Microsoft can use the following method to get
around the patent:

- Burn in Microsoft Only ActiveX components in the OS and only support
Microsoft script maps, extensions.

For example,  *.DOC,   this should, in theory, bypass the patent because it
uses standard script mapping and using file association and standard html,
you can display and edit word docs in a standalone window or view port.
However, you need WORD installed on the machine.  A delayed process.  Could
this be the reason Microsoft now offers a downloadable "Word Viewer?"

On the other hand, PDF is not a Microsoft component. Although it is part of
the standard script map tables for most web servers, the client side
component is not available.   This PDF component (Acrobat Reader) has to be
downloaded in a "delayed fashion."   This would be, in my technical expert
opinion, Acrobat defense.  The irony here with the fact that using Acrobat
requires an extensive complete download of their reader system, probably
saved their butt.  However, if they provided an embedded tag and distributed
activex components to Web sites for free distribution and automatic tag
association, then they are in the same boat FLASH is in.

Lets imagine the patent claims are isolated to just HTML based browsers,
then the obvious circumvention are proprietary frontend systems.  That is
means Prodigy had it right. AOL had it right,  We have it right with our
Wildcat! Navigator system.  This would coincide with the current direction
of the internet with more and more "private or semi-private" systems
offering their own "look and feel."    Our strategic direction is based on
this vision.  People what to add more "interaction" with their exclusive
users.

However, the problem with this direction of add-valued" custom look and feel
systems is that it is being done with the standard HTML server/browser
technology augmented flexible browser plug-in capabilities.

So like I said, the argument has to be presented that the TECHNOLOGY has
existed, maybe not for the World Wide Web,  but nonetheless exist before the
patent was filed.

This is why I said the patent claims are flawed.  It targets the WWW yet
makes broad references to other usages that are not web based.

If Eolas limits their patent to web-browsers, then I see the progress and
direction to custom web sites halted.  In a way,  this will benefit my
Wildcat! BBS technology so I shouldn't be complaining.

However,  If Eolas attempts to cover all "non-web" frontend systems, then
Mr. Doyle will no doubt be over burdened with lot of companies challenging
the patent.

With that said,  I don't think Mr. Doyle is willing to risk losing its claim
on the WWW by targeting that offer non-www systems as well where he will
surely lose.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office







----

----- Original Message ----- 
From: "Jake Robb" <jakerobb@mac.com>
To: "W3C Public Web Plugins List" <public-web-plugins@w3.org>
Sent: Tuesday, September 09, 2003 11:41 AM
Subject: Re: If MS pulls plug-in support, who do I sue


>
> Here's a quick link to the patent:
>
> http://tinyurl.com/juea
>
> Please have a look at claims 1 and 6.  It specifically refers to
> "displaying" the embedded interactive object *within* the hypertext
> document, even going so far as to say that the embedded object shall have
a
> particular visual location within the document.
>
> While looking through the patent again, I noticed a part in the
description
> section which mentioned OLE and Apple's OpenDoc, claiming that neither had
> the ability to be embedded in a remote hypermedia document.  I thought
that
> OpenDoc did have that ability; does anyone know?  And what about OLE?
Since
> it's mentioned in the patent, it was obviously pre-existing.  Was it
> possible to embed OLE documents in pages then, or was that not until the
> advent of ActiveX?
>
> -Jake
>
>
> Hector Santos wrote:
>
> >
> > Jake,
> >
> > No, I think the patent is more broad than this.
> >
> > The automatic "transformation" (a keyword for patentability) of the data
via
> > an server-side embedded application provided to the end-user client
software
> > is the key technology here they wish to control.
> >
> > It doesn't matter how's it done.  If you send data + program to a client
> > machine to manage the data on the client side,  you are covered by the
> > erroneous patent.
> >
> > If it was anything else, this would be an easy patent claim to refute
and
> > circumvent.  For example, a NON-WEB BROWSER that offers its own
proprietary
> > component system  such as our Wildcat! Navigator.
> >
> > But there is a light in the end of the tunnel.  The fact the patent
attempts
> > to be broad, in my opinion, begins to slip when it specifically uses an
> > example of a distributed spreadsheet:
> >
> >   "Other applications of the invention are possible. For example, the
user
> >   can operate a spreadsheet program that is being executed by one or
more
> >   other computer systems connected via the network to the user's client
> >   computer. Once the spreadsheet program has calculated results, the
> >   results may be sent over the network to the user's client computer for
> >   display to the user. In this way, computer systems located remotely on
> >   the network can be used to provide the computing power that may be
> >   required for certain tasks and to reduce the data bandwidth by only
> >   transmitting results of the computations."
> >
> > This is remote client/server fundamental methodology for distribution of
> > computer data processing.  It is why client/servers systems exist.  Any
IP
> > lawyer that doesn't use this against the patent is worthless.
> >
> > Listen people,  we need to realize two things about this case:
> >
> > 1) There is substantial argument for prior art and obviousness.
However,
> > due to current USPTO guidelines, to win this case the courts would have
to
> > revert to old software patent requirements.  There is certainly
substantial
> > proof that the USPTO software patent guidelines are inadequate and not
good
> > for society.
> >
> > 2) The economic incentive for large corporations to  patent every
concept
> > written down by employee's "Technical Work Book",  regardless of the
merits
> > of the patent.  Remember, patents do not protect ideas - lawyers do!
> >
> > With that said, Microsoft is in an interesting "quagmire" because on the
one
> > hand, they need this fundamental feature which is important for many of
> > today's application but also strategic for future Windows systems.  To
> > submit to the patent, Gates will finally be in a position of losing
control
> > of his empire. On the other hand, they can win this case but it will
require
> > prove to the courts the inadequacies of the software patent guidelines.
To
> > do so, they will automatically void many of their software patents filed
and
> > issued over the last few years.
> >
> > But in my mind, this really has nothing to do with Microsoft.  The
patent
> > address fundamental concepts in client/server computing that has nothing
to
> > do with Microsoft.  MS did not invent remote client/server computing.
> >
> > In short,  the winning strategy is to write to the USPTO and the Appeals
> > Court to get your input on the matter.  The patent claim must be struck
down
> > and voided otherwise WE all lose.  In my case, I can show substantial
prior
> > art and business operations with our Wildcat! Navigator so Eolas will
have a
> > tough time with us. I don't need Mr. Pei!  But anyone else new
developing
> > software with this technology?  well, you will have some issues to do
with
> > here.
> >
> > Who knows?  The courts and USPTO may decide that this technology is
obvious
> > and fundamental in the telecomputing market place thus declaring it in
the
> > public domain, just like it was done with the HAYES Modem AT command
set -
> > declared it PUBLIC DOMAIN!
> >
> > Sincerely,
> >
> > Hector Santos, CTO
> > Santronics Software, Inc.
> > http://www.santronics.com
> > 305-431-2846 Cell
> > 305-248-3204 Office
> >
> >
> > ----- Original Message -----
> > From: "Jake Robb" <jakerobb@mac.com>
> > To: "W3C Public Web Plugins List" <public-web-plugins@w3.org>
> > Sent: Tuesday, September 09, 2003 10:36 AM
> > Subject: Re: If MS pulls plug-in support, who do I sue
> >
> >
> >>
> >> From my understanding of the patent, the plugin must draw content
within
> > the
> >> "hypermedia document" (web page).  If your ActiveX does not have any
> > visual
> >> components that actually appear on the page, I think you're safe.
> >>
> >> -Jake
> >>
> >>
> >> Russell Cowdrey wrote:
> >>
> >>>
> >>>
> >>> Richard,
> >>>
> >>> I'm most interested in your last comment that the ActiveX control
would
> > have
> >>> to have a display area in a browser window.  My control is 95% in the
> >>> background, but there are times that we display html as modal dialogs
in
> > IE.
> >>> Would that be in violation?
> >>>
> >>> All of that would not get around the issue of being able to easily
> > launch
> >>> the ActiveX control in the first place which will I fear become much
> > more
> >>> cumbersome if allowed at all.
> >>>
> >>> Russell
> >>>
> >>
> >>
> >
> >
>
>

Received on Tuesday, 9 September 2003 13:35:55 UTC