Title of Invention

"MESSAGE SEND QUEUE REORDERING BASED ON PRIORITY"

Abstract A method of ordering a message send queue (410) in a server (108) sending respective response data to a wireless communication device (102) in response to a plurality of requests from the wireless communication device, the method comprising the steps of placing data comprising a response to a first request in the send queue (410) and serially transmitting the data in said send queue to the wireless device (102); receiving data comprising a response to a second request, said second request being determined to have a respective relative priority that is higher than a priority of the first request; and placing some of the data comprising the response to the second request in the send queue (410) ahead of at least some of the data comprising the response to the first request still in the queue and serially transmitting the data in said send queue to the wireless device (102).
Full Text MESSAGE SEND QUEUE REORDERING BASED ON PRIORITY
FIELD OF THE INVENTION
The present invention relates to a method and system for reordering a message send queue based on a priority of the message to be sent.
BACKGROUND OF THE INVENTION
Mobile devices such as wireless communication devices providing voice communications, data communications or both in a wireless communication network are increasingly prevalent in modern society. Such devices may also provide additional personal digital assistant (PDA) functions such as a calendar, alarm, contact lists, calculators, etc. One common feature of such devices is a World Wide Web browser facility whereby a user may navigate web pages such as those made available through an intranet or the public Internet.
During a browsing experience, a web browser acquires web page data to render the web page on a display of the device. The web browser formulates requests for data using a protocol such as the Hyper Text Transfer Protocol (HTTP) for requesting data from a web page server. In a wireless device, the requests and responses are typically communicated between the wireless device and the web page server through an intermediate server providing gateway services, bridging communications between the wireless network and the network of the web page server.
The gateway receives the requests from the wireless device and forwards them to the web server for service. Responses from the web server are received by the gateway and queued for communication to the wireless device.
To obtain the data for a single web page, a browser is often required to formulate more than one request. Occasionally, a response for a second request is required to be received and processed before the response for an earlier request is fully processed by the wireless device. When such a secondary HTTP request is made to the server while the communication of a response to an earlier request may be pending or in progress, the gateway sends any data that it has in its send queue until the entire response of the first request is completed. As a result, the web browser is delayed in receiving the response to
the secondary request until it receives the entire response to the earlier request.
By way of an example, a browser of the wireless device may encounter a JavaScript™ source or cascading style sheet (ess) reference in a response while loading a web page. Such references require immediate action. The browser is required to fetch the data for the reference, via a second request. It is also required to pause any further rendering of the page for any response data it may have until the new reference is completed. However, the send queue of the gateway may contain the remainder of the response to the first request while it receives the response to the second request. Send queues operate in accordance with first in first out (FIFO) rules. As such, the gateway puts the response to the second request at the end of its queue for sending after it completes the sending of the first response. Though such a manner of FIFO operation in a queue serializing response data is often desirable, it is apparent there are situations were a different ordering of communications may be required. When a secondary response requiring immediate action itself comprises a reference requiring immediate action, the delay experienced may be further compounded. As a result, a satisfying user experience may be affected. Web page loading times appear to lengthen when incomplete screens are displayed while waiting for additional data.
WO03085934A1 discloses a method of transferring additional Hyper Text Mark up Language (HTML) code objects from a server to a client device in response to further client device requests initiated by the presence of the additional objects in an HTML code object provided to the client device by the server in response to a first request. The server determines the priorities for the additional HTML code objects among the further requests from the client. The server then delays or forwards each additional object in dependence on its respective priority. The method disclosed in WO0308934A1 operates at the Transport Control Protocol (TCP) level and, as such, does not order, i.e. reorder, data already placed in the server's message send queue.
A solution to one or more of these shortcomings is therefore desired.
SUMMARY
Therefore, there is a need for a method and system whereby a first device (e.g. a wireless handheld device or mobile station) may send a request to a second device (e.g. a wireless
gateway server or other server) for response data having a higher priority than response data for an earlier request which is still transferring to the first device from the second device. Further there is a need for a second device (e.g. the server) to process the prioritized requests accordingly, inserting the higher priority response data into a content stream that the second device is transmitting to the first device, pre-empting any earlier lower priority response data that may already be queued.
Accordingly, the present invention provides in one main aspect a method of ordering a message send queue in a server sending respective response data to a wireless communication device in response to a plurality of requests from the wireless communication device, the method comprising the steps of: placing data comprising a response to a first request in the send queue and serially transmitting the data in said send queue to the wireless device; receiving data comprising a response to a second request, said second request being determined to have a respective relative priority that is higher than a priority of the first request; and placing some of the data comprising the response to the second request in the send queue ahead of at least some of the data comprising the response to the first request still in the queue and serially transmitting the data in said send queue to the wireless device.
Preferably, to accommodate a need for multiple levels of priority, a multi-level priority mechanism is desired whereby higher-priority responses pre-empt any lower-priority responses in a response queue.
In accordance with an embodiment of the invention, an HTTP header for a send request is adapted to include a priority indication of the request's relative priority (e.g.: x-rim-priority-request "priority number"). The priority indication instructs a gateway to order the response data for the request so that the response data for the request arrives at the requesting device ahead of lower priority response data that may be in the gateway's send queue.
These and other aspects including one or more method aspects and computer program product aspects will be apparent to those of ordinary skill in the art.
BRIEF DESCRIPTION OF THE DRAWINGS
In order that the invention may be readily understood, embodiments of the invention are illustrated by way of examples in the accompanying drawings, in which:
Fig. 1 is a schematic diagram of a system architecture in accordance with an embodiment of the invention;
Fig. 2 is a detailed diagram of a preferred wireless communication device of FIG. 1 in accordance with an embodiment of the invention;
Figs. 3A and 3B are flowcharts of operations of a mobile device in accordance with an embodiment of the invention illustrating a method for including a priority with a request for data; and
Fig. 4 is an illustration of a wireless gateway server in accordance with an embodiment of the invention.
DETAILED DESCRIPTION
FIG. 1 is a schematic illustration of an architecture for a system 100 in accordance with an embodiment of the invention. System 100 comprises a wireless communication device 102 coupled for communicating wirelessly with a wireless network 104 symbolized by a base station. Wireless network 104 may conform to any of the wireless network technologies and protocols capable of supporting data communications including cellular, wide-area network, GSM, GPRS, CDMA, iDEN™, Mobitex™, etc.
Wireless communication device 102 is adapted for web browsing and is capable of sending HTTP requests for web page data and receiving responses thereto comprising response data through wireless network 104 in accordance with one or more protocols implemented by the network 104. Wireless network 104 is further coupled for communication to a wireless gateway server 108 providing data communications services to the wireless device 102. In the present embodiment, wireless gateway server 108 is configured behind a firewall 106 well-known to those skilled in the art. Though not shown, intermediate wireless gateway server 108 and wireless network 104 may be a public relay and a public network such as the Internet. Wireless gateway server 108 may include but is not limited to a BlackBerry™ Enterprise Server or a wireless access protocol (WAP) gateway.
Through wireless gateway server 108, wireless device 102 may be coupled for communication over a network such as the public Internet 110 or an intranet 112 to a content server such as web servers 114 and 116.
In the illustrated embodiment of this invention, the wireless device 102 sends an HTTP request (i.e. a GET) for service by web server 114 or 116 through the firewall 106, to wireless gateway server 108. The wireless transport gateway is configured to provide access (i.e. HTTP connectivity), which is preferably secure, to intranet 116 and the public Internet 114. The wireless gateway server 108 performs the necessary address and protocol translation to route data between the wireless and IP networks. Optionally and preferably for handheld wireless devices such as device 102, the wireless gateway may convert and process data that passes between a content server, such as web server 114, 116, and an application resident on wireless device 102. Gateways may perform custom filtering and other data functions to deliver content to handhelds in an efficient and appropriate format.
Wireless gateway server 108 routes communications from the wireless device 102 (e.g. a GET) to the appropriate web server on the appropriate network. Once a response including response data (e.g. a portion of a web page such as part of an Hyper Text Markup Language (HTML) file) is returned to the gateway 108, the gateway prepares the response data for the appropriate wireless protocol of wireless network 104. The gateway 108 puts the response data, typically in a packet form according to a protocol of the wireless network, in a send queue for communicating to the wireless device 102 via the firewall
and network 104.
In accordance with the present embodiment, the wireless device 102 is adapted to include in an HTTP request a priority indication for instructing a priority handling by the gateway, at least for some requests. As well, the gateway is adapted to prioritize the return of response data in accordance with the priorities of the requests the gateway receives.
FIG. 2 is a block diagram illustrating an embodiment of wireless communication device 104 comprising a mobile electronic device 200 including preferred embodiments of the apparatus and method of the current application. Mobile electronic device 200 is preferably a two-way wireless electronic communication device having at least voice and data communication capabilities. Mobile electronic device 200 preferably has the capability to communicate with other computer systems on the Internet. Depending on the specific functionality provided, the wireless device may be referred to as a data messaging device, a two-way pager, a wireless e-mail device, a cellular telephone with data messaging capabilities, a wireless Internet appliance, or a data communication device, as examples.
Where mobile electronic device 200 is enabled for two-way communication, it incorporates a communication antenna subsystem 211, including both a receiver 212 and a transmitter 214, as well as associated components such as one or more, preferably embedded or internal, antenna elements 216 and 218, local oscillators (LOs) 213, and a processing module such as a digital signal processor (DSP) 220. As will be apparent to those skilled in the field of communications, the particular design of the communication subsystem 211 is dependent upon the protocols of the wireless communications network in which the device 200 is intended to operate.
Mobile electronic device 200 preferably includes a microprocessor 238 that controls the overall operation of the device. Communication functions, including at least data and preferably voice communications, are performed through communication subsystem 211. Microprocessor 238 also interacts with further device subsystems such as the display 222, flash memory 224, random access memory (RAM) 226, auxiliary input/output (I/O) subsystems 228, serial port 230, keyboard 232, speaker 234, microphone 236, a short-range communications subsystem 240 and any other device subsystems generally designated as 242.
Flash memory 224 may provide a local store of instructions and data of one or more applications for adapting and configuring the microprocessor to provide various features such as PDA features, a web browser, games, etc. A preferred application that may be loaded onto mobile station 202 may be a personal information manager (PIM) application having the ability to organize and manage data items relating to the user such as, but not limited to, instant messaging (IM), e-mail, calendar events, voice mails, appointments, and task items. Thus flash memory 224 of the present embodiment stores programs 250 (e.g. a web browser, PIM) device state information 252, address book 254, other PIM data 256, and other data and/or instructions 258.
Figs. 3A and 3B illustrate flowcharts of operations of a mobile wireless device (e.g. device 102) in accordance with an embodiment of the invention illustrating a method for including a priority with a request for data. Operations 300 and 310 represent exemplary steps for an embodiment of a browser application for loading web pages. Persons of ordinary skill in the art will appreciate that other applications requesting data may be adapted in a similar manner.
Operations 300 are initiated on the start of a loading of a page. At step 302 an initial priority level is set. The level may be sent with a request for data, for example as part of an HTTP header, as would be understood to a person of ordinary skill in the art. In accordance with the present embodiment of the invention, the priority level is included in requests the responses for which require priority treatment by the gateway but is otherwise omitted from other requests. When a priority level is omitted, the respective responses are given a normal treatment by the gateway (i.e. a respective low priority treatment) and placed at a tail end rather than a head end of the FIFO send queue.
At step 304, a first request for web page data is issued to the gateway to request a response and thereafter at step 306 a process for handling the response to the request is started together with the current priority level. Operations 300 may then end 308.
Operations 310 represent a method for handling a response to a request which may be implemented in accordance with various well-known techniques such as objected-oriented programming and re-entrant coding techniques for programming a processor for handling the response data. At step 312, processing begins to act upon the response data, for example, to render the response on a display of the device. Persons of ordinary skill will
appreciate that the response data is typically received as a stream of data in one or more packets and the response is typically processed serially in portions. Hence, as the stream is received, it is processed and a determination is made {step 312) whether the processing of the complete response is complete. If it is not complete, via No branch to step 314, the response is evaluated for a reference requiring a further request for data from a content source such as a web server. If a reference is not found, the portion of the response may be acted on, for example, to render the portion of data on a display of the device (step 315) before looping to step 312.
In the present embodiment relating to processing HTML, a variety of types of references may be encountered that require or otherwise may benefit from an immediate request for the matter identified by the reference. As previously discussed, ess and JavaScript™ are examples of such references. However, those of ordinary skill in the art will appreciate that references defining other embedded media within a page may be included. The embodiment disclosed herein is useful when making a determination as to whether or not to render matter identified by an HTML reference; and when that determination changes the path to be taken for processing the rest of the HTML page. For example if an object tag inside an HTML page is encountered, a determination as to whether the device can render that item is to be made. Before the determination is made, it may be necessary to fetch the data.
Object tags may reference a variety of media such as Shockwave-flash, scalable vector graphics (svg), images, and other forms of media. Now typically rendering agents pre-allocate display space for the object and render additional portions of the pate, going back to adjust the content that was rendered if the object that is fetched can't be processed. However, a rendering agent could also fetch the object and wait for it and then continue processing once a response is received.
If a reference is found at step 314, a further determination is made whether action on the reference is to be immediately taken (step 316). If action is to be immediate, processing of responses on outstanding requests is suspended (step 322). At step 324 a Get request is sent with the priority level increased by one. A process for handling the response is started and the current level plus one is passed to initiate the process. The current process (i.e. current instance of operations 310) then waits on the processing of the response data for the higher priority reference (step 326). Once that other process response instance (i.e.
new instance of operations 310) started by step 326 completes, the current process resumes operations, starting the processing of earlier response (step 328), if any, and looping to step 312 for a further determination whether more response data of the current response requires processing.
If at step 316 it is determined that the further reference in the current response does not require immediate action, via No branch to step 318, a request for data identified by the new reference is sent without a priority level and a process initiated to handle a response for the new reference. Processing of the current response then continues at step 312.
If at step 312 no further response data requires processing, operations 310 end at step 330.
Consider operations 300 and 310 with reference to the pseudo-code block below for a sample web page defined by MainDocument.htm:
MainDocumenthtm

This is text

Documents:

905-DEL-2005-Abstract-(03-11-2011).pdf

905-del-2005-Abstract-(28-03-2014).pdf

905-del-2005-abstract.pdf

905-del-2005-Assignment-(28-03-2014).pdf

905-DEL-2005-Claims-(03-11-2011).pdf

905-del-2005-claims.pdf

905-DEL-2005-Correspondence Others-(02-05-2011).pdf

905-DEL-2005-Correspondence Others-(03-11-2011).pdf

905-del-2005-Correspondence Others-(13-04-2011).pdf

905-del-2005-Correspondence Others-(18-06-2012).pdf

905-del-2005-Correspondence-Others-(20-12-2011).pdf

905-del-2005-Correspondence-Others-(28-03-2014).pdf

905-del-2005-correspondence-others.pdf

905-del-2005-description (complete).pdf

905-del-2005-drawings.pdf

905-del-2005-form-1.pdf

905-DEL-2005-Form-13-(03-11-2011).pdf

905-del-2005-form-18.pdf

905-del-2005-Form-2-(28-03-2014).pdf

905-del-2005-form-2.pdf

905-DEL-2005-Form-3-(02-05-2011).pdf

905-DEL-2005-Form-3-(03-11-2011).pdf

905-del-2005-Form-3-(13-04-2011).pdf

905-del-2005-Form-3-(18-06-2012).pdf

905-del-2005-Form-3-(20-12-2011).pdf

905-del-2005-form-3.pdf

905-del-2005-form-5.pdf

905-del-2005-GPA-(28-03-2014).pdf

905-del-2005-gpa.pdf

Petition 137 for Form 3.pdf

Petition 137 for Proof of Right.pdf


Patent Number 260248
Indian Patent Application Number 905/DEL/2005
PG Journal Number 16/2014
Publication Date 18-Apr-2014
Grant Date 15-Apr-2014
Date of Filing 08-Apr-2005
Name of Patentee RESEARCH IN MOTION LIMITED
Applicant Address 295 PHILLIP STREET, WATERLOO, ONTARIO N2L 3W8, CANADA.
Inventors:
# Inventor's Name Inventor's Address
1 TAPUSKA DAVID 712 WILLOW WOOD PLACE, WATERLOO, ONTARIO N2T 2T7, CANADA.
2 KNOWLES MICHAEL 847 BRANDENBURG BLVD., WATERLOO, ONTARIO N2T 2X5, CANADA.
PCT International Classification Number H04B 7/185
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 04252119.5 2004-04-08 EPO