Comments on Patent
so for obvious reason, this is largely focussed on details of WebWisdomDB
(i.e. server side)
It does describe essence of client side but much more crudely
I think we ought to claim that our current HTML version has
ALL the essential ideas of much better XML version (that is because
HTML is essentially a special case of XML and I do use JavaScript to interpret HTML
in non trivial and client dependent fashion. Further HTML in a very crude way
encodes Lukasz's general idea that Web page defines collaboration policy. Card
games have JavaScript that implements a very different policy (upto 6 players
and any number of observers) than supported by Tango)

In general one has Web Pages whose content are interpreted on "master"
and dispatched to client where both HTML page and implementation of
message can differ. A key idea in current JSSB is 2 types of messages
a) Direct Interpretation of event on master recreated on client as the same
   event -- only option on client is essentially to accept or ignore event
   This is used for resize, form contents, scrolling and some button clicks, layer clicks
   and layer mouse over/out
b) Indirect Interpretation of event where master sends to other or selected
   clients not the event but the "logical meaning of event". This can be
   interpreted in any way the client likes. 
   This is used for some buttons, pointers, cards and some layer events
   ( your choice in fact). This indirect method is most powerful and
   sometimes forced on you as Netscape does NOT allow you to recreate
   general events.
   
events of type (a) are handled entirely in JSSB; those of type (b) are
application dependent and handled by JavaScript loaded in web page invoked
by JSSB. I think these two strategies will be present in all future versions.
(b) is more powerful but more work.

A critical implementation idea is to NOT process events when they are received
but rather to form effectively 3 queues -- events delivered by tango are put in queues
and processed by daemons
1) General Web page Level Events
2) Events of type a) above (joined with 1) in current JSSB)
3) Events of type b) above.
These queues are necessary to cope with unpredictable timing so that events must
wait till everything is ready.

Another interesting idea is automatic registration of "special pages" e.g. a
pointered page where page works up through frames and windows to find a registration
server which notifies JSSB of this page type. This allows spawned pages to be
controlled.

Serialization of events in current JSB illustrates use of XML to exchange data
The ability to define "history pages" whoise serialized content (placed in
hidden form elements) illustrates a general archiving capability

JavaScript Control Bar allowing window invocation/positioning including
automatic next/prev buttons is worth a claim

I think that the NCSA shared Biology Workbench illustrates a key idea implicit
in WebWisdomDB support. Namely one can share a general distributed educational object
"just" by sharing its graphical interface. This seems quite general and much easier
than say SV2 approach where server controls collaboration. The shared graphical
interface "only" requires the caching support on server (as claimed already)
which is clearly easier than fancy server collaboration support

The blurb on start up pages defines other important things which are more like
features than implementation inventions. These include
A) Performance Package -- application level and in principle can have "agent" that
notifies a teacher if student machine is out of wack
B) Generation of preview/review windows
C) Support for mirror sites
D) JavaSript API for shared (card) games