Re: a what if...

Hi Michael,

No, I don't think you are off base.  I was actually just ready to post I
started this morning,  sarcastic suggestion of a "patent pending" process
where the technology completes a full circle in its evolution.  Here you go:

Although I think there is enough prior art and obviousness on this nuisance
patent, what I am about to propose will probably be a mute point.  But it
may be a way around the patent:

- Avoid the automation of sending plugins!

In other words, the "frontend" which there are thousands of many different
color, shape and size, is provided as a whole package or the process of the
sending the plugin is delayed witih a URL that request the user to download
it - keeping the entire process at the hosting side.

Here is an example of the "patent-pending" process called:

                   "Cooperative Component Distribution and Linkage System"

Legend:

CooComp <tm>   "Cooperative Component"  a program you wish to sent to the
client.
CCReservior <tm>  a holding source of CooComps <tm>
CCSlot  <tm>   A CooComp <tm> slot or position in the CCReservior <tm>
CCAlias <tm>  A literal identifier for the CooComp <tm>
CCCost <tm>  The user cost of using the CooComp <tm>
CCVendor <tm>  The vendor or owner of the CooComp <tm>
CCS <tm>  CooComp in source form
CCX <tm>    CooComp in binary (object or p-code) form

Given a general server side COOCOMP tag for general remote server
presentation of data:

        <COOCOMP calias=nuts.ccx cccost=00.50> blah-blah-blah </>

The server-side activation of this logic redirects the user to another
SERVER-SIDE interactive request to download:

        <H2>Required Cooperative Component: Nuts.ccx</H2>
        <H2>If you download this, it will cost you 50 cents </H2>
        <a href=/server-side-coocomp/download.ccx?nuts.ccx>Start
Download</h>

Certainly the idea of a "DOWNLOAD" is not patentable.  You can download
anything you like. So the goal here is delay the process and keep it
entirely on the server side.  There are additional benefits here as you can
apply additional attributes such as the "cost of the business".  Also note
how CooComps <tm> can work on the server side as well!

Now, once the browser downloads the CCX.  It has two choices:

1) It burns the CCX as a resource and clones the browser executable thus
making a new permanent frontend, or

2) The frontend is designed with a CooComp reservoir.

The CCReservior holds slots called CCSlots where CCX applications can be
stored.   We are no longer are dealing with the idea of a PLUGIN but rather
a upfront design consideration that there will be X amount of possible
extension to the frontend.  The future is fixed.  Once the CCReservior is
filled.  The vendor can decide to charge the user to purchage a new upgrade
that hold a larger CCReservior.   Again, "delay" is the key here.  No patent
can deny a vendor the natural right to extend the capability of his Frontend
as long as you "reserve" the slots for extendability and delay the process
of filling the CooComp Reservior.

Now thats version 1.0.

In version 2.0 when a new patent pending process concept called CCPOW
augmented the CooComp system,

           CooCompPOW - "Cooperative Component Predeterministic Operator
aWareness System"

Again, the key technologies in version 1.0 is "delay" and emphasis on
server-side user interaction.

In version 2.0,  the server-side hosting system has predetermined its
business requirements for a complete user experience on this hosting system.
Thus, this will naturally define the capabilities of the frontend system.
For this, we need additional definitions:

CCGROUP <tm>    A group of CCX files.
CCZ <tm>  A file extension representing compressed group of CCX files with
installation logic.

So when the user first visits the hosting system, the host will present the
following:

         Hi there

        Thanks for calling our BBS powered by Santronics's Wildcat!
Interactive Net Server.

         Click here to Login, but before you do this, in order to fully
enjoy  your experience on
         this Online BBS , you will need the following Cooperative
Components <tm> to give you
        a  great  Wildcat! "Purring" Navigation of the BBS!

         nuts.ccx
         mail client.ccx
         file client.ccx
         Who's Online client.ccx
         terminal mode client.ccx
         personal properties client.ccx
         chat and instant message client.ccx
         spreadsheet.ccx
         Order entry.ccx

         3rd party Cooperative Components:

         Chess.wcx
         Viva Los Vegas!.ccx

         Click here to download the complete group of CCX files. Once you
downloaded the
         file, exit to a dos screen or use explorer if you like and open the
CCX file.  It will
         automatically find the Wildcat! Navigator frontend and add the ccx
to its reservior. Then
         restart  Wildcat Navigator and enjoy the system. You won't be asked
again to download
         anything (PS: This idea is patent pending!)

         Your Wildcat! Navigator is designed to hold 1,000,000,000
Cooperative Components by
         design because we expected that you might want to add more
capabilities to your
         Online Navigational experience.  For example, rather than seeing
your stock charts in text based
         columnar format,    you might want to see the same numbers in a
Chart!  Or maybe not.
         But for sure, you will    want to read your mail offline in a more
friendly fashion! or if your
         grandma calls the BBS,  you will want to be notified with a popup
message or bet yet,
         download our SDK and program a CCX to automatically disconnect when
she logs on
        so that she doesn't see you in the porn section!!

         Please note, there may or may not be a cost associated with each
Cooperative Component.

So in summary,  if you know what the compabilities will be for your web
site, well PUT it all together upfront and tell the user to download your
extensions, and then create your own "browser" that will not communicate or
interface with anything else but itself and the remote server!

Sincerely,

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


----- Original Message ----- 
From: "Michael Condouris" <priority_one@amberdigital.com>
To: "W3C Public Web Plugins List" <public-web-plugins@w3.org>
Sent: Thursday, September 04, 2003 3:31 PM
Subject: a what if...


>
> What if Microsoft's change to IE is to actually patch commonly used
> plugins directly into the browser's binary?  Would this circumvent the
> patent by eliminating the call to an external executable?
>
> If so, other browsers would have to follow suit if they were persued.
> It would certainly put the kibosh on new plugin creation, but give them
> a better negotiating position.
>
> Just a thought, please let me know if I'm way off base.
> -- 
> Michael Condouris
> http://www.amberdigital.com
> Telephone: 973-857-7707
>
>

Received on Thursday, 4 September 2003 16:23:58 UTC