(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2010/0077035 A1
`(43) Pub. Date:
`Mar. 25, 2010
`Li et al.
`
`US 20100077035A1
`
`(54) OPTIMIZED POLLING IN LOW RESOURCE
`DEVICES
`
`(75) Inventors:
`
`Du Li, Palo Alto, CA (US); Umesh
`Chandra, Sunnyvale, CA (US)
`
`Correspondence Address:
`BANNER & WITCOFF, LTD.
`1100 13th STREET, N.W., SUITE 1200
`WASHINGTON, DC 20005-4051 (US)
`
`(73) Assignee:
`
`NOKIA CORPORATION, Espoo
`(FI)
`
`(21) Appl. No.:
`
`12/235,744
`
`(22) Filed:
`
`Sep. 23, 2008
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 5/82
`(2006.01)
`G06F 5/16
`(52) U.S. Cl. ......................................... 709/206: 709/228
`(57)
`ABSTRACT
`Methods and systems for optimizing server polling by a
`mobile client are described, thereby allowing mobile termi
`nals to conserve battery life by more efficiently using
`resources such as the processor and transceiver in the mobile
`terminal. A broker system may be used to minimize wireless
`communication traffic used for polling. A broker stub inter
`cepts server polling messages at the client, multiplexes the
`sever requests together, and forwards the multiplexed mes
`sage to a broker skeleton that de-multiplexes and forwards the
`messages as appropriate. Polling may also be dynamically
`adapted based on user behavior, or a server guard may be used
`to monitor changes to data, and notify a client to poll its
`respective server when the server guard detects new or
`updated data on that server for that client.
`
`-
`
`301
`
`38
`
`COLLABORATION CLIENT
`
`--
`
`CHAT CLIENT
`
`WHITEBOARD -
`CLIENT
`
`305
`
`BROKERSTUB
`v A
`
`XML, HTTP REQUEST
`
`N
`
`s
`
`307
`
`309
`
`a
`
`311 -
`
`-
`313 -
`
`---
`/
`
`317
`
`WEBSERVER
`
`COLLABORATION SERVER
`
`BROKERSKELETON
`
`|-
`
`A
`
`y
`
`w
`
`CHAT SERVER
`
`WHITEBOARD
`SERVER
`
`| -
`w
`
`315
`
`---
`
`319
`
`Page 1 of 16
`
`GOOGLE EXHIBIT 1033
`
`

`

`Patent Application Publication
`
`Mar. 25, 2010 Sheet 1 of 5
`
`US 2010/0077035 A1
`
`
`
`125
`
`SERVICE
`PROVIDER
`
`130
`CONTENT
`PROVIDER/
`SERVER
`
`155
`
`PROCESSOR
`
`FIG. 1
`
`Page 2 of 16
`
`

`

`Patent Application Publication
`
`Mar. 25, 2010 Sheet 2 of 5
`
`US 2010/0077035 A1
`
`DISPLAY
`
`236
`
`RADIO
`TRANSCEIVER
`242
`
`BROADCAST
`TRANSCEIVER
`241
`
`WLAN
`TRANSCEIVER
`243
`
`TELECOM
`TRANSCEIVER
`244
`
`228
`
`SOFTWARE
`
`212 -
`
`
`
`
`
`USER INTERFACE
`CONTROL
`230
`
`BATTERY
`250
`
`FIG. 2
`
`Page 3 of 16
`
`

`

`Patent Application Publication
`
`Mar. 25, 2010 Sheet 3 of 5
`
`US 2010/0077035 A1
`
`COLLABORATION CLIENT
`
`-
`/
`
`301
`303
`
`CHAT CLIENT
`y A
`
`is
`
`305
`
`WHITEBOARD
`CLIENT
`y A
`
`BROKERSTUB
`y A
`
`XML, HTTP REQUEST
`
`-
`
`WEBSERVER
`
`COLLABORATION SERVER
`
`BROKERSKELETON
`
`-
`
`A
`
`CHAT SERVER
`
`WHITEBOARD
`SERVER
`
`311 -
`
`-
`313
`
`/
`
`317
`
`FIG. 3
`
`307
`
`309
`
`315
`
`319
`
`Page 4 of 16
`
`

`

`Patent Application Publication
`
`Mar. 25, 2010 Sheet 4 of 5
`
`US 2010/0077035 A1
`
`401 -
`
`-
`
`405 -
`
`USER BROWSESTO
`CLIENT-SERVER BASED
`SERVICE(S)
`y
`USER OR SERVICES
`ACTIVATES MULTIPLE
`CLIENT-SERVER PROCESSES
`403 7
`y
`CLIENT(S) REQUEST
`UPDATE FROM
`SERVER(S)
`y
`BROKERSTUB
`- INTERCEPTS SERVER
`407 -
`REGUESTS
`y
`BROKERSTUB MULTIPLEXES
`REOUESTS AND SENDS TO
`BROKERSKELETON
`y
`409 f
`BROKERSKELETON RECEIVES
`REOUEST AND DEMULTIPLEXES
`THE REO UEST
`y
`BROKER FORWARDS
`INDIVIDUAL REO UESTS TO
`RESPECTIVE SERVERS
`
`/ EACHSERVER GENERATES
`AND SENDS RESPONSE TO
`CLIENT COMPONENTS
`
`
`
`BROKERSKELETON
`INTERCEPTS
`RESPONSE(S)
`
`BROKERSKELETON
`- MULTIPLEXES RESPONSES
`AND SENDS TO STUB
`y
`BROKERSTUB RECEIVES
`- RESPONSE AND DEMULTIPLEXES
`THE RESPONSE
`y
`BROKERSTUB FORWARDS
`INDIVIDUAL RESPONSES TO
`RESPECTIVE CLIENTS
`
`Y
`
`K
`41.1 -
`
`FIG. 4
`
`Page 5 of 16
`
`

`

`Patent Application Publication
`
`Mar. 25, 2010 Sheet 5 of 5
`
`US 2010/0077035 A1
`
`CLIENT COMPONENTS REGISTER
`WITH SERVER GUARD
`
`501
`
`y
`SERVER GUARD (E.G., BROKER
`SKELETON)PERIODICALLY
`CHECKS FOR UPDATES
`
`503
`
`y
`BROKERSTUBSENDS
`"HEARTBEAT"MSGS TO
`SERVER GUARD
`
`505
`
`y
`SERVER GUARD RESPONDS
`BROKERSTUB IDENTIFYING
`SERVERS WITH NEW DATA
`y
`BROKERSTUB NOTIFIES CLIENT
`COMPONENTS THAT HAVE NEW
`DATA AVAILABLE
`y
`COMPONENT CLIENTS WITH
`NEW DATA SEND REQUESTAND
`RECEIVE NEW DATA
`
`507
`
`509
`
`511
`
`FIG. 5
`
`Page 6 of 16
`
`

`

`US 2010/0077035 A1
`
`Mar. 25, 2010
`
`OPTIMIZED POLLING IN LOW RESOURCE
`DEVICES
`
`FIELD OF THE INVENTION
`0001. The invention relates generally to resource conser
`Vation in mobile and low resource devices, such as mobile
`phones, Smartphones, personal digital assistants, ultra-mo
`bile PCs, and the like. More specifically, the invention pro
`vides techniques for optimizing polling between a client and
`its server application to reduce the overhead required to main
`tain an active and accurate connection between the client and
`the server.
`
`BACKGROUND OF THE INVENTION
`0002 Intelligent mobile computing devices, such as
`smartphones and ultra mobile PCs, have become ubiquitous
`throughout Society and throughout the world. Some users
`primarily use mobile devices occasionally, e.g., in airports or
`restaurants, when those users do not have access to a more
`traditional computer that might have dedicated power and a
`hardwired network connection. Some other users rely on
`mobile computing devices as their primary data processing
`devices because those users do not have or even need a more
`traditional computer for their living or professional needs.
`Mobile devices use radio technologies for communication
`and batteries for power. They are becoming Sophisticated
`enough to act as a powerful information terminal, limited
`only by the duration of the mobile device's battery before the
`battery must be recharged.
`0003. In some environments involving mobile devices,
`e.g., the Web, a server cannot initiate communication to a
`client, nor can the server maintain a very long-term connec
`tion with a client, out of considerations of security and server
`scalability. Instead, each client must initiate or establish the
`connection with the server in order to send data to the server
`and receive data from the server. In addition, each client must
`periodically poll the server for new or updated data, prefer
`ably frequently, in order to ensure that the client has the most
`recent information and data. Thus, client-server communica
`tion can become a resource hog and a performance bottle
`neck, causing the mobile device's battery to drain quickly.
`
`BRIEF SUMMARY OF THE INVENTION
`0004. The following presents a simplified summary of the
`invention in order to provide a basic understanding of various
`aspects described here. This Summary is not an extensive
`overview of the invention, and is not intended to identify key
`or critical elements of the invention or to delineate the scope
`of the invention. The following Summary merely presents
`Some concepts of the invention in a simplified form as a
`prelude to the more detailed description provided below.
`0005 To overcome limitations in the prior art described
`above, and to overcome other limitations that will be apparent
`upon reading and understanding the present specification, the
`present invention is directed to more efficiently managing
`client-server communications between mobile clients and
`their respective servers from which they obtain data.
`0006. A first aspect of the invention provides broker-man
`aged client-server communications between a mobile client
`(e.g., a mobile terminal) and one or more servers providing
`data to one or more corresponding client components execut
`ing on the mobile client. A broker module (“stub”) executing
`at the mobile client intercepts server request messages sent by
`
`any client components executing on the mobile client. The
`broker stub multiplexes the server request messages into a
`broker request message, and transmits the broker request
`message for receipt by a broker module skeleton executing on
`a SWC.
`0007. When the broker stub receives a response from the
`broker skeleton, the broker stub demultiplexes the broker
`response message into discrete server response messages,
`each server response message corresponding to a different
`client component executing on the apparatus.
`0008 According to another aspect of the invention, when
`a broker skeleton (e.g., executing on a web server) receives a
`multiplexed broker request message from a mobile terminal,
`the broker skeleton demultiplexes the broker request message
`into discrete server request messages, and forwards each bro
`ker request message to a server identified in each broker
`request message. When the broker skeleton receives a server
`response message from each of the identified servers, the
`skeleton multiplexes the server response messages into a
`single broker response message, and sends the broker
`response message to the mobile terminal. The single mes
`sages transmitted between broker skeleton and broker stub
`may be sent in multiple packets or bursts, but logically cor
`respond to a single communication.
`0009. According to another aspect of the invention, one or
`more mobile clients executing on a mobile terminal may
`perform adaptive polling based on user behavior with each
`application on the mobile client. The mobile terminal may
`execute a client component to poll at a particular interval to a
`server providing data for the client, when a user interaction
`criterion is met. The mobile terminal may execute the client
`component that polls the server at another interval, different
`from said first interval, when the user interaction criterion is
`not met. In one example the user interaction criterion may
`include the client component being displayed on a display
`screen of the apparatus. In another example the user interac
`tion criterion may include the client component being dis
`played on the display screen with a higher level of promi
`nence than a second client component executing on the
`mobile terminal.
`0010. According to another aspect of the invention, a
`server guard module may be used to independently monitor
`one or more servers for updated data. The server guard mod
`ule may be executing on a web server or other data processing
`device having a direct power connection and hardwired net
`work connection. The server guard module may alternatively
`reside on a mobile terminal, however, if the resources saved
`and efficiencies gained are greater than when the server guard
`resides on a device having a constant or direct power source.
`The server guard module receives a registration message
`from a client component executing on a mobile terminal.
`Each registration message provides to the server guard infor
`mation Such as the address of the server corresponding to the
`client component and the query parameters the client com
`ponent will use to retrieve information from the server. The
`server guard registers the information in a database. To deter
`mine whether each server component has new data intended
`for its corresponding client component, the server guard
`either periodically polls each server component according to
`a predefined schedule or new updates committed to the serv
`ers are made aware to the server guard. When a server com
`ponent has new data intended for its corresponding client
`
`Page 7 of 16
`
`

`

`US 2010/0077035 A1
`
`Mar. 25, 2010
`
`component, the server guard notifies the corresponding client
`component indicating that the server has new data intended
`for the client component.
`0011. According to yet another aspect of the invention, a
`mobile terminal may be adapted to interact with a server
`guard. Each client component on the mobile terminal sends a
`registration message to the server guard. Each registration
`message provides server component information correspond
`ing to a server providing data to the client component sending
`the message. The mobile terminal Subsequently sends a plu
`rality of heartbeat messages to the server guard module
`according to a predefined schedule, each message requesting
`status regarding the availability of new data. The mobile
`terminal receives a response from the sever guard module,
`where the response is responsive to one of the heartbeat
`messages, and indicates the server has new data that the
`mobile terminal has not yet received.
`0012. In one example, the client component on the mobile
`terminal may subsequently send a polling message to its
`corresponding server to get the new data, providing any nec
`essary query data (e.g., a current location of the mobile ter
`minal, on which the query might be dependent). Alterna
`tively, when the server does not require query parameters
`specific to or based on the client component (e.g., the server
`merely provides Greenwich mean time, regardless of who
`queries the server), then the response received from the server
`guard may directly include the new data provided by the
`SeVe.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0013. A more complete understanding of the present
`invention and the advantages thereof may be acquired by
`referring to the following description in consideration of the
`accompanying drawings, in which like reference numbers
`indicate like features, and wherein:
`0014 FIG. 1 illustrates a network architecture that may be
`used according to one or more illustrative aspects of the
`invention.
`0015 FIG. 2 illustrates a mobile terminal that may be used
`according to one or more illustrative aspects of the invention.
`0016 FIG. 3 illustrates a data flow between a collabora
`tion clientanda collaboration server according to one or more
`illustrative aspects of the invention.
`0017 FIG.4 illustrates a flowchart for a method of broker
`managed server polling according to one or more illustrative
`aspects of the invention.
`0018 FIG. 5 illustrates a flowchart for a method of server
`guard-managed serverpolling according to one or more illus
`trative aspects of the invention.
`
`DETAILED DESCRIPTION OF THE INVENTION
`0019. In the following description of the various embodi
`ments, reference is made to the accompanying drawings,
`which form a part hereof, and in which is shown by way of
`illustration various embodiments in which the invention may
`be practiced. It is to be understood that other embodiments
`may be utilized and structural and functional modifications
`may be made without departing from the scope of the present
`invention.
`0020 FIG. 1 illustrates an exemplary communication net
`work through which various inventive principles may be
`practiced. A number of computers and devices including
`mobile communication devices 105 and 110, personal digital
`
`assistant (PDA) 120, personal computer (PC) 115, service
`provider 125 and content provider 130 may communicate
`with one another and with other devices through network 100.
`Network 100 may include wired and wireless connections
`and network elements, and connections over the network may
`include permanent or temporary connections. Communica
`tion through network 100 is not limited to the illustrated
`devices and may include additional devices such as a home
`Video storage system, a portable audio/video player, a digital
`camera/camcorder, a positioning device Such as a GPS (Glo
`bal Positioning System) device or satellite, a mobile televi
`sion, a set-top box (STB), a digital video recorder, remote
`control devices and any combination thereof.
`0021 Although shown as a single network in FIG. 1 for
`simplicity, network 100 may include multiple networks that
`are interlinked so as to provide intemetworked communica
`tions. Such networks may include one or more private or
`public packet-switched networks (e.g., the Internet), one or
`more private or public circuit-switched networks (e.g., a pub
`lic Switched telephone network), a cellular network config
`ured to facilitate communications to and from mobile com
`munication devices 105 and 110 (e.g., through use of base
`stations, mobile Switching centers, etc.), a short or medium
`range wireless communication connection (e.g., Bluetooth R.
`ultra wideband (UWB), infrared, WiBree, wireless local area
`network (WLAN) according to one or more versions Institute
`of Electrical and Electronics Engineers standard no. 802.11),
`or a high-speed wireless data network Such as Evolution-Data
`Optimized (EV-DO) networks, Universal Mobile Telecom
`munications System (UMTS) networks, Long Term Evolu
`tion (LTE) networks or Enhanced Data rates for GSM Evo
`lution (EDGE) networks. Devices 105-120 may use various
`communication protocols such as Internet Protocol (IP),
`Transmission Control Protocol (TCP), Simple Mail Transfer
`Protocol (SMTP) among others known in the art. Various
`messaging services such as Short Messaging Service (SMS)
`may also be included.
`(0022 Devices 105-120 may be configured to interact with
`each other or other devices, such as content server 130 or
`service provider 125. In one example, mobile device 110 may
`include client software 165 that is configured to coordinate
`the transmission and reception of information to and from
`content provider/server 130. In one arrangement, client soft
`ware 165 may include application or server specific protocols
`for requesting and receiving content from content server 130.
`For example, client software 165 may comprise a Web
`browser or mobile variants thereof and content provider/
`server 130 may comprise a web server. Billing services (not
`shown) may also be included to charge access or data fees for
`services rendered. In one arrangement where service provider
`125 provides cellular network access (e.g., a wireless service
`provider), client software 165 may include instructions for
`access and communication through the cellular network. Cli
`ent software 165 may be stored in computer-readable
`memory 160 such as read only or random access memory in
`device 110 and may include instructions that cause one or
`more components (e.g., processor 155, a transceiver, and a
`display) of device 110 to perform various functions and meth
`ods including those described herein.
`0023 FIG. 2 illustrates a computing device such as mobile
`device 212 that may be used in network 100 of FIG.1. Mobile
`device 212 may include a controller 225 connected to a user
`interface control 230, display 236 and other elements as illus
`trated. Controller 225 may include one or more processors
`
`Page 8 of 16
`
`

`

`US 2010/0077035 A1
`
`Mar. 25, 2010
`
`228 and memory 234 storing software 240. Mobile device
`212 may also include a battery 250, speaker 252 and antenna
`254. User interface control 230 may include controllers or
`adapters configured to receive input from or provide output to
`a keypad, touch screen, Voice interface (e.g. via microphone
`256), function keys, joystick, data glove, mouse and the like.
`0024 Computer executable instructions and data used by
`processor 228 and other components of mobile device 212
`may be stored in a storage facility Such as memory 234.
`Memory 234 may comprise any type or combination of read
`only memory (ROM) modules or random access memory
`(RAM) modules, including both volatile and nonvolatile
`memory such as disks. Software 240 may be stored within
`memory 234 to provide instructions to processor 228 such
`that when the instructions are executed, processor 228,
`mobile device 212 and/or other components of mobile device
`212 are caused to perform various functions or methods such
`as those described herein. Software may include both appli
`cations and operating system software, and may include code
`segments, instructions, applets, pre-compiled code, compiled
`code, computer programs, program modules, engines, pro
`gram logic, and combinations thereof. Computer executable
`instructions and data may further be stored on computer read
`able media including EEPROM, flash memory or other
`memory technology, CD-ROM, DVD or other optical disk
`storage, magnetic cassettes, magnetic tape, magnetic storage
`and the like.
`0025. It should be understood that any of the method steps,
`procedures or functions described herein may be imple
`mented using one or more processors in combination with
`executable instructions that cause the processors and other
`components to perform the method steps, procedures or func
`tions. As used herein, the terms “processor and “computer
`whether used alone or in combination with executable
`instructions stored in a memory or other computer-readable
`storage medium should be understood to encompass any of
`various types of well-known computing structures including
`but not limited to one or more microprocessors, special-pur
`pose computer chips, field-programmable gate arrays (FP
`GAS), controllers, application-specific integrated circuits
`(ASICS), combinations of hardware/firmware, or other spe
`cial or general-purpose processing circuitry.
`0026. Mobile device 212 or its various components may
`be configured to receive, decode and process various types of
`transmissions including digital broadband broadcast trans
`missions that are based, for example, on the Digital Video
`Broadcast (DVB) standard, such as DVB-H, DVB-H+, or
`DVB-MHP, through a specific broadcast transceiver 241.
`Other digital transmission formats may alternatively be used
`to deliver content and information of availability of supple
`mental services. Additionally or alternatively, mobile device
`212 may be configured to receive, decode and process trans
`missions through FM/AM Radio transceiver 242, wireless
`local area network (WLAN) transceiver 243, and telecommu
`nications transceiver 244. Transceivers 241,242,243 and 244
`may, alternatively, include individual transmitter and receiver
`components.
`0027. Although the above description of FIG. 2 generally
`relates to a mobile device, other devices or systems may
`include the same or similar components and perform the same
`or similar functions and methods. For example, a stationary
`computer such as PC 115 (FIG. 1) may include the compo
`
`nents described above and may be configured to perform the
`same or similar functions as mobile device 212 and its com
`ponents.
`0028. In Web-based systems, e.g., data communications
`over the Internet, client-server communications usually fol
`low a request-response pattern where, in response to the client
`sending an HTTP request to the server, the server sends a
`response back to the client. The response typically includes
`data requested by the client. During each request-response
`cycle, a mobile client needs to establish a TCP connection
`within its wireless communications network, and then com
`municate the request/response messages using the TCP con
`nection. Each cycle can take several exchanges of messages,
`or “round trips.” between the client and the server, and the
`HTTP request header often takes several hundred (e.g., 600)
`bytes, even if the application payload only has a few bytes of
`data. Hence communication latency can be high and link
`utilization may below.
`0029. The mobility of a device aggravates the problems of
`HTTP and Web communication because radio technologies
`such as Wi-Fi and 3G have high communication latencies and
`low bit rates. Newer wireless data communication technolo
`gies present similar problems. The uplink and downlink
`speeds are typically asymmetric, with the uplink being slower
`and more energy-consuming. After every transmission, the
`wireless interface may be left in a high power consumption
`state, and transits into a low power State only after a pre
`defined period of inactivity. Each communication costs CPU
`cycles, memory, and battery power. If a mobile client has
`multiple components that need to communicate with a server,
`the wireless interface is kept busy, the battery drains fast, and
`the mobile device may become less responsive.
`0030. In view of the above, aspects of the invention are
`directed to improved techniques for client-server interaction
`using mobile devices when power is a limited resource, i.e.,
`the phone is not plugged in to a power source, but is instead
`using battery power. The inventive techniques may also be
`used to conserve power consumption even when the device or
`apparatus is plugged in, to help with better utilization of
`network bandwidth by conserving the number of bytes sent,
`and to better utilize a mobile device's CPU by reducing pro
`cessing cycles used in communications.
`0031. To illustrate various aspects of the invention, the
`following illustrative scenario is used. With reference back to
`FIG. 1, devices 110, 120 may be executing client software
`165 that provides collaboration services, e.g., a shared white
`board that all users can draw on, as well as a chat service. With
`further reference to FIG. 3, client software 165 may be
`referred to as collaboration client 301. FIG. 3 illustrates a
`logical data flow diagram between each collaboration client
`and its applicable servers. With the collaboration client 301,
`each collaboration service 303, 305 may act as a unique
`client, incommunication with a unique server for that service.
`For example, the chat feature may be provided in each col
`laboration client 301 by a chat client software module 303
`executing on collaboration client 301 in communication with
`a chat server software module 317 executing on a collabora
`tion server 313, e.g., a logical server executing on server 130
`(FIG. 1). Similarly, the whiteboard feature may be provided
`in each collaboration client 301 by a whiteboard client soft
`ware module 305 executing on collaboration client 301 in
`communication with a whiteboard server software module
`319 executing on collaboration server 313, e.g., a logical
`server executing on server 130 (FIG. 1) distinct from the
`
`Page 9 of 16
`
`

`

`US 2010/0077035 A1
`
`Mar. 25, 2010
`
`logical server providing chat features. Additional collabora
`tion services may also be provided, but only two are refer
`enced herein for illustrative purposes.
`0032 Each of the chat and whiteboard components has its
`own user interface on the client side, Sometimes provided
`within a single web page in a browser window. Other user
`interfaces may alternatively be used. In addition to having
`unique servers, each component may also have its own data
`base storing data corresponding to the service/feature pro
`vided by that component. The application servers 317, 319
`may be invoked by a Web server 311, e.g., using Apache,
`when requests are received from the clients 303, 305. The
`clients 303, 305 typically poll their respective servers 317,
`319 according to a schedule, e.g., every 5 seconds, to retrieve
`updates available on the server.
`0033 According to an aspect of the invention, broker stub
`307 and broker skeleton 315 may be used to multiplex and
`combine server requests into a single message, thereby con
`serving resources in the mobile client. The broker stub 307
`may be coded in Ajax (Asynchronous JavaScript and XML)
`to provide services that communicate with a server in the
`background. The broker stub 307 may provide APIs (appli
`cation programming interfaces) through which the client
`components may send XMLHttpRequests (XHR) requests to
`server 313 Such that multiple requests can be aggregated and
`sent as one, and the polling intervals may be dynamically
`adapted depending on the availability of updates, network
`conditions, and server workload.
`0034. Thus, in the example illustrated in FIG. 3, and with
`further reference to FIG.4, a user in step 401 may browse on
`his or her mobile phone to access a Web-based collaboration
`service, through which mobile clients 110, 120 communicate
`with each other via server 313 across a wireless network (e.g.,
`a high-latency network). Throughout the process, broker
`modules 307, 315 mediate the client-server communication
`to make the communications more efficient. The broker may
`include the client side module (stub 307) and the server side
`module (skeleton 315). Stub 3.07 may reside in the same Web
`page as the collaboration client components such as chat 303
`and whiteboard 305 and provides APIs for them to commu
`nicate with the server 313. Stub 3.07 may alternatively be
`independent from client components.
`0035. In step 403, a user using a collaboration client 301
`activates chat and whiteboard services within the collabora
`tion service. In step 405, each client requests an update from
`its respective server. Each request may be referred to as a
`server request message or a component request message. In
`step 407, broker stub 307 intercepts the multiple server
`request messages, and in step 409, stub 307 may multiplex
`requests from those components into one broker request mes
`sage and send the multiplexed broker request message to
`broker skeleton 315. In step 411, skeleton 315 intercepts the
`multiplexed broker request message sent from the stub 307
`and demultiplexes the request. In step 413 the skeleton sends
`or dispatches the demultiplexed requests (the individual com
`ponent request messages) to their respective original compo
`nent servers 317,319.
`0036. In step 415 one or more component servers 317,319
`generate a response back to their respective component cli
`ents 303,305. In step 417 broker skeleton 315 intercepts the
`responses, referred to individually as a server response mes
`sage or component response message. In step 419 broker
`skeleton 315 multiplexes the response messages and sends a
`multiplexed broker response message back to broker stub
`
`307. In step 421 broker stub 307 receives the multiplexed
`broker response message and demultiplexes the message
`back into individual component response messages. In step
`423 broker stub 307 dispatches or forwards the individual
`response messagess to their corresponding client components
`303,305.
`0037 According to another aspect of the invention, the
`broker system (e.g., broker skeleton 315 and broker stub 307)
`may perform adaptive polling. In one embodiment, the stub
`might not send a periodic polling request until a last connec
`tion for that request has completed (or the request has timed
`out, based on a predefined value), resulting in slowing down
`a polling task if its interval is too frequent for current network
`conditions or server workload. The broker stub may also
`adapt (slow down or speed up) the polling interval of a peri
`odic request according to the availability of updates. The
`availability of updates may be application-specific insofar as
`a client component needs to provide feedback to the stub by
`indicating availability of data via stub APIs.
`0038. In one illustrative embodiment, Yahoo! connection
`manager (YCM) may be used for cross platform APIs for
`programming XHR. The main interface may be asyncke
`quest(method, url, callback, data), which sends an asynchro
`nous request to a server. Among the four arguments, method
`is an HTTP method such as GET and POST: url is the address
`of the target Web server; callback is the object for handling the
`server response; data holds the data to be sent in a POST
`request. The callback object may provide the following three
`members: Success is the function called to process the server
`response that is returned successfully; failure is the function
`to handle a problematic response, e.g., communication failure
`or server error, argument is any object containing data for the
`Success and failure handlers to process the server response.
`0039. The APIs may leverage YCM for underlying XHR
`communications by distinguishing the following four types
`of XHR tasks: one-time polling to query the server, e.g., to
`load shared data when a component is initialized, periodic
`polling to periodically query the server for new updates to
`Some shared data, one-time updating to notify the server of
`local state changes to Some shared data, and periodic updating
`to periodically send updates of some shared data to the server.
`0040. Every task may define a unique id, a method to get
`its url, and a callback object. An updating task additionally
`defines a method to get the data to be sent. A periodic task also
`may define an interval to specify the frequency at which the
`request is sent. In some embodiments, periodic updating may
`be used, e.g., when Web service APIs support input sources
`Such as mic, camera, and GPS, which may generate periodic
`updates.
`0041 One-time polling and updating tasks may be sent in
`specific components by calling Ajax broker methods, send
`polling(task) and send updating (task), respectively, where
`object task is defined as above. A periodic polling task is sent
`by the broker stub after the component registers it by calling
`Ajax broker method register polling(task).
`0042. According to an aspect of the invention, the broker
`stub 307 may administer periodic polling requests by multi
`plexing requests and adapting the request intervals. In an