(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(19) World Intellectual Property Organization
`International Bureau
`
`11111111111111111111111111111111111111111111111111111111111111111111111111111111
`
`(43) International Publication Date
`29 November 2001 (29.11.2001)
`
`peT
`
`(10) International Publication Number
`WO 01/91482 Al
`
`(51) International Patent Classification7:
`G06F 15/16, 17/30
`
`H04Q 7/20,
`
`(21) International Application Number: PCT/USO 111 7274
`
`(22) International Filing Date:
`
`23 May 2001 (23.05.2001)
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`English
`
`English
`
`(30) Priority Data:
`60/206,543
`60/277,001
`
`23 May 2000 (23.05.2000) US
`18 March 2001 (18.03.2001) US
`
`(71) Applicant (for all deSignated States except US): MEDIA
`FARM, INC. [US/uS]; 1616 Hollenbeck Avenue #l1,
`Sunnyvale, CA (US).
`
`(72) Inventor; and
`(75) Inventor/Applicant (for us only): BHAREDWAJ, Srini(cid:173)
`vas lIN/US]; 1616 Hollenbeck Avenue#l1, Sunnyvale, CA
`(US).
`
`(74) Agent: LEE, Otto, 0.; Intellectual Property Law Group,
`LLP, 12 South First Street, 12th Floor, San Jose, CA 95113
`(US).
`
`(81) Designated States (national): AE, AG, AL, AM, AT, AU,
`AZ, BA, BB, BG, BR, BY, BZ, CA, ClI, CN, CO, CR, CU,
`CZ, DE, DK, DM, DZ, EE, ES, Fl, GB, GD, GE, GlI, GM,
`HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK,
`LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX,
`MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL,
`TJ, TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, zw.
`
`(84) Designated States (regional): ARIPO patent (GlI, GM,
`KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian
`patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European
`patent (AT, BE, ClI, CY, DE, DK, ES, Fl, FR., GB, GR, IE,
`TT, LU, MC, NL, PT, SE, TR), OAPT patent (BF, BJ, CF,
`CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG).
`
`Published:
`with international search report
`
`[Continued on next page J
`--------------------------------------------------------------------------------------
`
`iiiiiiiiiiii
`iiiiiiiiiiii
`
`--iiiiiiiiiiii
`== ---
`
`!!!!!!!! (54) Title: REMOTE DISPLAYS IN MOBILE COMMUNICATION NETWORKS
`
`--iiiiiiiiiiii
`iiiiiiiiiiii ----
`
`10
`
`270
`
`220
`
`230
`
`210
`
`N
`(57) Abstract: A method and system that uses a thin client solution in a mobile network is disclosed. The thin client (10) is not
`QIO required to be equipped with an execution environment; rather, the client (10) is used as a display device for applications that run on
`~ remote servers (200). Applications such as E-mail client, browser and others execute on a remotely located server, but use the client
`~ (10) as a display and input device. The client (10) is equipped with a speech input device, which receives speech input and transmits
`S that are transmitted and received hetween the client (10) and one or more server (200) is contemplated, which method results in a
`-... it to the server for interpretation or recognition at the server (200). Because handwidth is limited, a method of combining requests
`o by a user via the client (10), maintains application state on the server (200). Thus, when a user turns "off" the client device (10), the
`> server (200) may still maintain the state of the applications the user executed at the server (200). When the client (10) reestablishes
`~ connection with the server (200), the user's prior state may be restored.
`
`reduction of traffic between the client (10) and the server(s). The server (200), which runs applications that are used and accessed
`
`-i-
`
`Amazon Exhibit 1007
`IPR Petition - USP 9,456,040
`
`

`

`WO 01/91482 Al
`
`11111111111111111111111111111111111111111111111111111111111111111111111111111111
`
`before the expiration of the time limit for amending the
`claims and to be republished in the event of receipt of
`amendments
`
`For two-letter codes and other abbreviations, refer to the "Guid(cid:173)
`ance Notes on Codes and A bbreviations " appearing at the begin(cid:173)
`ning of each regular issue of the PCT Gazette.
`
`-ii-
`
`

`

`WO 01/91482
`
`PCT/US01/17274
`
`REMOTE DISPLAYS IN MOBILE COMMUNICATION NETWORKS
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`TECHNICAL FIELD
`The present invention claims priority from application 60/206,543 filed on May 23,2000 titled
`REMOTE DISPLAYS IN MOBILE NETWORKS and application (no. pending) filed on March 18,
`2001 titled VIRTUAL PALMTOP PLATFORM. This invention is related generally to client-server
`computing, and particularly, to handheld computing devices used in mobile communication
`networks.
`
`BACKGROUND
`3G is an evolving wireless standard. The types of applications used with this new standard
`include improved multimedia communications that combine voice, video, text and other methods.
`The next generation wireless communication services are expected to rely increasingly on
`data-including video and movin~ pictures--whereas the current wireless communication services
`are limited to voice-based applications such as telephone services. Other applications that are
`contemplated to use the new wireless networking standard include providing Internet
`browsing-web browsin~n a large number of formats; and applications that enhance personal
`
`productivity--e.g., financial, calendar, groupware, and others--and location-based services. The
`current systems use micro browsers and ex~cution environments that run on the customer terminal
`devices. The newly contemplated applications impose severe restrictions on the existing solutions.
`The amount of data that should be handled, the speed with which the data should be transmitted
`from and to the customer terminal device is expected to overwhelm the current architectures and
`strain the capabilities on both the customer devices such as the hand-held terminal devices as well
`as on the back-end devices such as the servers that support and deliver these applications.
`
`SUMMARY
`
`This disclosure is directed toward a system and method to enable a client device such as a
`handheld computer ora cellular telephone device. Examples of such client devices include the
`commercially available PalmTM Personal Digital Assis~ant (PDA), and similar devices marketed by
`companies such as Nokia Corporation of Finland, Handspring, Inc. of Mountain View, California,
`and others. The following discussion uses a novel device called a Virtual PalmTop. This device
`comprises hardware and/or software configured to enable a general-purpose client device such as
`the aforementioned exemplary devices to function in a manner as disclosed and described herein.
`
`A feature of these client devices is that they are small (i.e., they have a small screen or a
`form-factor). Because of their size, which is typically configured to fit in a person's shirt pocket, they
`cannot be equipped with an unlimited amount of memory. Further, their processing power is limited
`
`- 1 -
`
`

`

`WO 01/91482
`
`PCT/US01/17274
`
`10
`
`15
`
`20
`
`25
`
`because of limitations due to the amount of battery power available, and the amount of heat they
`can dissipate. A further feature of these client devices is that they are typically designed to work
`with a mobile communication network, and this requirement imposes additional restrictions such as
`the amount of bandwidth available, and how to handle in case of a service interruption or outage.
`5 Due to these and other limitations, applications that run well on conventional computers such as
`personal computers do not run as desired on these handheld and/or mobile devices.
`Traditional systems such as the 3G PP Mobile Execution Environment (MExE) have been
`developed to enable execution of client applications on a client device for wireless and mobile
`applications. In contrast to MExE, one can execute applications on a remotely situated server, and
`use the client device as a mere output device rather than an execution environment. By so
`configuring, the client device can be adapted to handle a number of applications that may be
`running on a variety of application servers. For example, a browser program may be running on a
`first server, and an electronic mail application may be running on a second server, but the Client
`device will be used as a common output device for both the applications. As a consequence, the
`client device can be treated as a thin client, with minimal need to handle complex applications
`locally. This configuration enables the client device to handle any type of application such as a
`Wireless Access Protocol (WAP) application, a Common Language Infrastructure (CLI) application,
`or a Java Virtual Machine (JVM) application. Accordingly, with a minimal need for additional
`software on the client device, any currently existing application may be accessed using this system.
`In some situations, however, there is a need to perform certain localized actions on the client
`device as a result of a user action or inaction. Examples of these situations include the need to
`highlight a specified portion of the display area to indicate a user's selection of that portion of the
`display area. In such cases, there could be deposited on the client device a small piece of code to
`handle these localized actions without the need to transmit an indication of the user's action to the
`server and wait for an instruction as to how the user's action should be handled. As a result, the
`amount of data transmitted from the client device to the server (and back) is somewhat reduce~.
`A second feature of the disclosed system is to further reduce the. amount of data transmitted
`from the client device to the server. This is accomplished by the use of a novel feature called a
`"compound request." In a normal client device, all user interactions generate "events." An event is
`typically a result of a user action or inaction. When events are generated at the client device, they
`are transmitted to the server, whereupon the server takes an appropriate previously defined action
`or may simply ignore the events. These events are sent to the server from the client device in a
`data packet. But if a large number of data packets are generated at the client device, and all these
`packets are sent to the server, the limited bandwidth offered by the wireless network may not be
`able to effectively handle them. Moreover, the transmission delay-also called "Iatency"-of these
`"event" data packets d~creases the responsiveness of the system and may lead to user frustration.
`Combining a number of events that occur in a predefined time interval and transmitting them in a
`single data packet alleviates this problem. It should be noted, however, that these principles do not
`require that only one data packet be transmitted; rather, a fewer number of data packets than are
`-2-
`
`30
`
`35
`
`

`

`WO 01/91482
`
`PCT/US01/17274
`
`typically sent will reduce the latency problem. Similarly, a number of responses from the server to
`the client device can also be combined and sent in a fewer number of data packets to save
`bandwidth.
`In order for the client device to provide a display interface to a number of applications that
`5 may run on a number of different application servers, it is necessary to maintain the state of each of
`these applications at some location, preferably on the respective servers. Advantageously, the state
`of the application programs may be stored so that in case of a disconnection between the client
`device and the server, a user may reestablish his state easily.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`Software Configuration on the Client device
`The presently disclosed system includes a client device configured to support the above(cid:173)
`mentioned features. It should be noted that a client device contemplated for use with this invention
`does not need an execution environment, as is the case with commercially available handheld
`computers such as PalmTM. The presently contemplated client device may use only a graphics
`protocol engine rather than a full-fledged execution environment. Of course, it should be easily
`understood that in alternative embodiments, the graphics protocol engine could be added to a
`commercially available handheld computer, which may include an execution environment to function
`according to the method disclosed herein. The description provided 'in this document presents the
`features of the client software, which features are collectively called VP client. VP client features
`include, a graphics protocol subsystem, an event protocol subsystem, a speech protocol subsystem,
`and an ALM protocol subsystem. Also present is a cache management subsystem, which is
`configured to combine user actions and manage drawables and server requests.
`
`Application Perspective
`From an application environment's viewpoint, a Virtual PalmTop Client device abstracts its
`display as a series of drawables on which certain drawing actions are possible. The protocol
`between the client device and the server enables actions on these drawables and sending of user
`events back to the applications running on the server.
`Four different protocols come together to define a system for rurining a broad range of
`graphical applications, multimedia applications, multimodal applications, etc. Fig 5 describes the.4
`different protocols used by the invention that operate between clients and servers. The Graphics
`and Speech Interface Protocol specifies the mechanism of how the user display is updated and how
`multiple drawables on the client are managed and the use of compound actions to.update and
`manage them.
`
`The invention contains several different components. The Graphics and Speech protocol
`outlines a basic graphical interaction. There are several different capabilities in this protoco\. They
`are, (1) Capability Negotiation - Query the deNice for its capabilities and negotiate a list of
`capabilities to use in subsequent requests; (2) Mandatory Drawing Requests - a range of requests
`that establish the mandatory parts of the drawing protocol; (3) Optional Widget Protocol - a list of
`-3-
`
`

`

`WO 01/91482
`
`PCT/US01/17274
`
`optional requests that allow a server to use the Widget capabilities of a device if they exist; (4)
`Drawable Management; (5) On Action primitives; (6) Visual Objects and Management; and (7)
`
`Speech support and Notification.
`The Event System protocol delivers user events and input back to the application running on
`the server. A variety of input methods are possible, including Key and Mouse style devices, touch
`panels, etc. In addition, speech too can be an input method. The Event System protocol delivers the
`various inputs to the server and these are used to send input actions up to the application.
`The ALM protocol along with DHCP is used to bootstrap handsets back to their prior eXisting
`state notably by helping them reestablish connections to the user's running applications. They also
`offer a way of launching new applications.
`
`5
`
`10
`
`An implementation would involve a 2.5 Generation or 3rd Generation Wireless WideArea or
`Wireless LAN network. Handsets would run the VP Client. Servers hosted at the Mobile Service
`Switching Center (in the case of the Wide Area Solution) would act as the VP Server. The thin client
`15 would use these servers to run applications downloaded from the Internet or those provided
`specifically by the service provider. An alternative emobodiment would involve a trusted Application
`Service Provider which purchases networking that allows it to run the same applets and applications
`on behalf of the client. A third embodiment would involve an enterprise or other service provider
`owning and operating the VP server. It is also possible for the server to be agented and a mobile
`RPC implementation allowing an agent to exist between the server and the client. The agent would
`mediate requests and act as a buffering agent that bridges two networks, namely the wireline
`internet and the wireless mobile network.
`An alternative embodiment exists in Wireless LAN environments. In these environments, the
`VP client and server interact over the Wireless LAN in a similar fashion. It is also possible for a
`handset to use both environments. In this case as the user leaves the WLAN environment and goes
`over the wide area environment, the user can connect back to his previously running applications
`now using the wide area connection or vice versa. Advantageously, the applications may also be
`migrated.
`
`25
`
`20
`
`30
`
`35
`
`Software Configuration on the Server Computer
`As is the case with the client device, the server computer is programmed to execute a number
`of subsystems, each designed to interact with a similar subsystem on the client device. Accordingly,
`counterparts to the each of the several subsystems present in the client device, namely, the
`graphics subsystem, the event protocol subsystem, the speech protocol subsystem" the ALM
`subsystem and the cache management subsystem, are present in the server computer. In addition
`to these subsystems, the server computer also executes application programs for use by a user of
`the client device and optionally, an execution environment such as a Java Virtual Machine.
`An aspect of the present disclosure includes a method of compounding drawing requests and
`other transmissions from the server. For example, certain display actions required to update a
`-4-
`
`

`

`WO 01/91482
`
`PCT/US01/17274
`
`drawable can be aggregated into fewer actions and sent to the client, thereby conserving bandwidth.
`This can be implemented in a number of ways. For example, if one considers a display system to
`be a series of drawables, one can aggregate a series of requests to draw an object on the client
`device and send the aggregated actions to the client in a fewer number of transmissions.
`Additionally, a feature of the presently disclosed system includes storing these compounded
`drawing requests in the server for later use. By thus storing the data transmitted to the client device
`at the server, the server can maintain state information for the client device. In case the client
`device is turned off or otherwise "lost" its state, the server can restore the client device's state by
`retransmitting ("replaying") the client's state information to the client device. A number of
`transmissions to be sent to the client can be aggregated and sent as fewer transmissions than
`ordinarily required.
`As will be explained in detail below, the server computer is configured to include an
`Application List Manager (ALM) module. The Client deals with the ALM server. ALM server keeps
`track of the number of applications currently run by the client, and a list of available applications.
`The respective servers where these applications were running when the client is turned off store and
`maintain a log file for that client for that application. When client is turned on, the ALM server
`notifies the client (or the client informs the ALM server) and the original client state is restored.
`
`VP Client Specification
`The VP Client specification requires a set of mandatory procedures and a set of optional
`procedures. The mandatory procedures are raw drawing primitives and primitives intended to
`establish the initial capability negotiation and connect the system. Additional primitives like Widget
`primitives, drawable manipulation, OnAction Primitives, Visual Objects and support procedures for
`compound requests are optional.
`The VP Client provides the necessary display abstraction needed by a server to first obtain
`information on the capabilities of the display notably its form factor, color capabilities, voice
`capabilities and input capabilities, support for compound requests, caching, widgets, etc.
`VPSYSTEMINFO, INITIALIZEGRAPHICSYSTEM, INITIALIZEEVENTSYSTEM, GETVISUALINFO
`provide support for such capability negotiation.
`An illustrative sequence of packets that can establish a clienUserver session can be described
`as follows:
`
`-------VpSYSTEMI N FO----o7
`Server
`~-----VPSYSTEMINFO (REPLY)
`
`Client
`
`--------1 N ITIALIZEGRAPHICSSYSTEM-07
`Server
`~----- INITIALIZEGRAPHICSSYSTEM (REPLY)
`Server
`-----lnitializeEventSystem 7 Client
`
`Client
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`

`

`WO 01/91482
`
`PCT/US01/17274
`
`~----lnitEventSystem (Evnt protocol) ----------
`Server
`----lnitEventSystem (REPLY)--------------------7
`
`Client
`
`Server ~----lnitializeEventSystem (REPLY) -------------
`
`Client
`
`This initial exchange sets up the Client and server to interact. The VP client then awaits
`requests from the server requiring drawing actions on drawables or other display or output actions.
`When there is input, the VP client picks up these events and delivers them to the server using the
`DeliverNextEvent or DeliverEvents' requests of the Event Protocol.
`An External Data Representation (XDR) library on the client first decodes every server
`request. Thereafter, VP Client executes a corresponding drawing action. The server request can be
`either a simple or a compound request. If it is a simple request, then after the drawing action is
`taken the client replies with VPOK or indicates the cause of the failure. If it is a compound request,
`the client executes the various subrequests contained in the compound request in a predetermined
`sequence and then returns the results in one large reply. If any of these subrequests fails, the client
`may both stop executing additional requests and return with a failure indication and the list of
`committed requests. Alternatively, the client may ignore the failed subrequest arid continue
`processing the remaining subrequests. The server can then replay the rest of the requests as it
`sees appropriate.
`A server will then use either a raw drawing protocol and/or a widget protocol. If the VP client
`and server negotiate that the client supports compound requests but not widgets, then the VP server
`will look to issue a sequence of drawing actions corresponding to each widget drawing request. The
`following code is an example of a graphical application in the Java programming language:
`
`Button b = new Button ("ABUTTON");
`f.add (b);
`Scroll bar B = new Scrollbar ( .... );
`f.add (B);
`f.setVisible 0;
`
`The above will cause the setVisible request to issue possibly one or two compound requests
`to the VP client. This may lead to a single Compound Request (CR):
`
`DrawRect
`DrawLine
`DrawString
`
`DrawRect
`DrawRect
`
`. I 7 These represent CR for Button
`
`-6-
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`

`

`WO 01/91482
`
`PCT/US01/17274
`
`DrawPolygon
`DrawPolygon
`DrawRect
`DrawLine
`DrawLine
`
`5
`
`I -7 These represent CR for Scrollbar
`
`The ability .to batch requests represents an enormous win for thin client solutions over wireless
`when compared to the use of single drawing requests both in minimizing overhead and reducing
`. over -the- air latency. Individually and serially sent the 10 requests would take 1 sec:;ond on a
`10 wireless network with 100 ms. latency as contention to regain control enormously slows down the
`network with additional costs relating to interrupt latency etc. adding marginal delay. Using the one
`compound request, the thin client solution reduces it to a single data exchange.
`A client can cache requests on drawables as it chooses but must do so on an all or none
`basis. This enables cache replay on a per drawable basis. The VP Server section provides an
`illustration for how efficiently drawable state can be reestablished by a VP server on a client.
`The VP Client tracks these drawables. A preferred embodiment might store the drawable
`cache in Non-Volatile Memory but this is NOT a reqirement. At a time only one application is
`considered ACTIVE in a VP client. The VP client could switch from application to applica~ion. As it
`does so, the drawables of suspended applications are deleted gradually to make space for new
`
`15
`
`20
`
`drawables for.the active application. This form of lazy caching-i.e., not discarding cache soon after
`
`it is no more needed or actively accessed-is also commonly used in microprocessor memory
`hierarchies, virtual memory systems and caches in file systems. The VP client which is close to the
`display where there is minimal memory present is viewed as a more expensive cache for requests
`on active drawables. A discarded cache can be updated as and when required by the corresponding
`server side environment (like Java Virtual Machine) supporting the application.
`The VP client implementation can vary based on the capabilities' of the device. On a device
`with a very good Windowing system and widget library a very advanced implementation is possible.
`
`25
`
`30
`
`-7-
`
`

`

`WO 01191482
`
`PCT/US01l17274
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`These and other features of the principles of the disclosed system are more readily
`understood from the following detailed description in conjunction with the accompanying drawings,
`in which,
`Fig. 1 shows a client device that can be adapted to practice the principles of the present
`invention.
`Fig. 2 depicts a server computer that can be adapted to implement the principles of the
`present invention.
`Fig. 3 describes the 3G Environment depicting servers and clients including several server
`farms hosted in the service environment at the mobile switching services center (MSC) by the
`Wireless Service Provider, or at an ASP or within an Enterprise.
`Fig. 4 describes the conceptual architecture for a client device configured according to the
`principles disclosed herein, which figure shows a plurality of applications running on remotely
`located servers using the client device for output (display), in addition to a depiction of activity from
`the client device transmitted to the serVer.
`Fig. 5 depicts drawable cache on an illustrative client device configured in according to the
`principles of the present invention, and three applications--one active and two suspended-each
`with a set of drawables, wherein the solid colored drawables indicate full caches while the white
`colored drawables indicate cleared caches.
`Fig. 6 depicts a server and a client configured according to the principles of the present
`invention showing a request from the server to the client, wherein the server holds all of its
`drawables, and the client has cleared its cache on some drawables.
`Fig. 7 pictorially describes aspects of certain protocols-VP Graphics protocol, ~peech
`
`Protocol, Event Protocol, ALM Protocol, remote procedure call (rpc) and DHCP-in addition to RTP,
`an optional protocol for speech and multimedia.
`Fig. 8 shows an illustrative embodiment of server software implementation using t~e Java®
`programming language Abstract Windowing Toolkit (AWT).
`Fig .. 9 outlines a sample configuration for a multimodal server farm that uses speech, and display as
`methods of communication.
`Fig. 10 shows an illustrative interaction of input events in a multi modal (speech and display)
`application.
`
`DETAILED DESCRIPTION
`Definitions:
`Pixmap: An off-screen buffer on which a graphics can be drawn. After drawing into a pixmap,
`the graphics can be copied to a window and cause the graphics to appear on a screen if the window
`is visible. It should be noted that there isno need to have a pixmap buffer; a graphics can be drawn
`
`-8-
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`

`

`WO 01191482
`
`PCT/US01l17274
`
`on a window directly. But using a pixmap helps a rapid update of the screen without repeating a
`series of primitive drawing operations. Pixmaps are typically used to store image data such as
`icons, logos that are loaded from adisk. These images can then be copied to a window. Like
`windows, pixmaps are server-side resol.lrces.
`
`5
`
`Bitmap: A bitmap is similar to a pixmap, except that in a bitmap a single bit represents each
`pixel. In X-windows terminology, a bitmap is considered a pixmap with a depth of 1.
`
`Drawable: A drawable is anything on which a graphics can be drawn. Drawables include
`windows, pixmaps, and bitmaps. According to X-windows terminology, everything that can be
`displayed is a drawable
`
`Window: In X, a window is an actual visible drawable element, and is normally rectangular in
`shape, though this shape can be modified. Pixmap, on the otherhand, is an off-screen chunk of
`memory to which one can draw a graphic, but a pixmap is not visible. Windows can have child
`windows that are bounded by the parent window. Windows can be resized, moved, their masks
`changed, reparented to other windows, mapped (Le., once a window is created, it must be mapped
`to ll1ake it visible), unmapped (Le., a window can be made invisible by unmapping it) and destroyed.
`Windows and pixmaps can be drawin using several primitive drawing functions provided in X.
`Among others, this includes drawing lines, rectangles, polygons, filled rectangles or polygons, arcs,
`filled arcs, copying one drawable to another drawable, etc.
`
`Events: An event is a happening on a window. This could be a user action such as a button
`press, button release, key press, mouse click, exposure of a window on a screen, resizing a
`window, moving a window or an object, or simply moving a cursor or a mouse pointer on a window.
`A window can be configured to select what events are captured or serviced by that window. The
`events a window can select are enumerated by turning on appropriate bits in an "event mask." A
`programmer can configure an unlimited number of events including some events based on a user
`inaction such as timeout after a window is exposed, the amount of time expired after a button is
`pressed and held before it is released, etc. When an event occurs, if it is masked, then it can be
`captured by the server (in the case of X-windows) and propagated to a predefined code segment
`called an "event handler." The event handler either ignores the event or perfo~ms an action
`responsive to the event.
`Server: The word "server" is used in two different ways in this document. "Server'" as applied
`to a client-server hardware system implies a server computer that services a client device's needs.
`On the other hand, the word "server" as applied to a user-interface ("windowing") environment
`denotes a program that runs on a computer with which a user interacts. In a client-server computing
`system using an X-window type user interface environment, the "X-server" is a program that runs on
`the client device and is configured to capture events that are generated at the client device and
`transmit them to an "application" running on the server computer. In this document, the word
`"server" should be understood based on the context in either of these two ways.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`-9-
`
`

`

`WO 01191482
`
`PCT/US01l17274
`
`Agent: An "agent" as used in this document is an intermediate computer that may control,
`manage, mediate or coordinate the data transmission activities between the client device and the
`server computer. In the disclosed system herein, the agent computer is an optional component.
`
`10
`
`15
`
`20
`
`25
`
`5 Hardware architecture
`As illustrated in FIG. 1 a client device 10 configured according to the principles disclosed
`herein includes a central processing unit 20 ("CPU"), which could be a general-purpose processor
`such as an Intel® StrongARM® processor or a special-purpose processor. The CPU 20 is
`connected through a bus 30 to, among other things, volatile memory 40 (also called RAM or random
`access memory), non-volatile memory 50 (such as disk drives, CD-ROMs or data tapes), a network
`communications adapter 60 (such as an Ethernet card), an input means 70, such as a keyboard
`and/or a pointing or point-and-click device (such as a mouse, light pen, touch" screen, touch pad, joy
`stick, jog dial), an output device, such as a video display screen and/or an audio speaker, and a
`removable media drive 80, such as a floppy disk drive, CD-ROM drive, PCMIA port, C~-WORM
`drive or data tape drive.
`The client devicE:) 10 operates client software 90 for use with the present invention. The client
`software is shown graphically in FIG. 1 as being stored in non-volatile memory 50. However, it
`should be understood that it can also be stored in transportable media read by removable media
`drive 80. All, or portions of the client software 90 also can be loaded into volatile memory 40 (RAM),
`for example during operation. Exemplary transportable media implementing the client software
`(which may be in any form, such as source code, compiled or binary versions) include floppy disks,
`magnetic tape and opticaJ disks, and others. In one embodiment, a client device is a portable
`computer such as a hand-held device and the electronic communications network is a wireless
`network connected to the Internet or an online service. Further, "Client de