`
`WO 02/052785 A2
`
`I IIIII IIIIIIII II IIIIII IIIII IIII I II Ill lllll lllll lllll lllll lllll llll 1111111111111111111
`
`CN, CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, ES, FI,
`GB, GD, GE, GTJ, GM, HR, fl[!, TD, ll, TN. 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, UZ, VN, Y[!, ZA,
`ZW. ARIPO patent (GH, Glvf, KE, LS. MW. MZ, SD. SL, SZ,
`TZ. UG, ZM, Zif;, Eurasian patent (AM, AZ, BY, KG, KZ,
`MD, RU. TJ, TM), European patent (AT, BE, CH, CJ: DE,
`DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE, TR),
`Q4Pl patent (BF, BJ, CF, CG, Cl, CM, GA, GN, GQ. GW.
`ML, MR, NE, SN, TD, TG)
`as to the applicant's entitlement to claim the priority of the
`earlier application (Rule 4. l 7(iii)) for the following desig(cid:173)
`nations AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY,
`BZ, CA, CH, CN, CO, CR, CU. CZ, DE, DK, DM, DZ, EC,
`EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN,
`TS, JP. KE. KG, KP. KR, KZ. LC. LK. LR. LS. LT, LU, LV.
`
`lvlA, lvlD, lvlG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT,
`RO, RU. SD. SE, SG. ST. SK. SL, TJ, TM. TR .. TT, TZ, UA,
`UG, UZ, VN, YU, Z.4, ZW, ARIPO patent (GI!, GA.f, KE, LS,
`lvlW, lvlZ. SD. SL, SZ, TZ. UG. ZJo..1, Zif;, Eurasian patent
`(AJo..1, AZ, BY, KG, KZ, MD, R[!, TJ, Tlvl), European patent
`(AT, BE, CH. CY, DE, DK, ES, Fl, FR, GB, GR, IE, TT. U!,
`lvlC, NL, PI; SE, TR), OAPI patent (BF; BJ. CF; CG, CI,
`CM, GA, GN, GQ, mv, ML, lvlR, NE, SN, TD, TG)
`ofinventorship (Rule 4.17(iv))for US only
`
`Published:
`without international search report and to be republished
`upon receipt of that report
`
`For two-letter codes and other abbreviations, refer to the "Guid(cid:173)
`ance Notes on Codes and Abbreviations" appearing at the begin(cid:173)
`ning of each regular issue of the PCT Gazette.
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`Information Browser System and Method for a Wireless Communication
`
`Device
`
`FIELD OF THE INVENTION
`
`The present invention relates to browsing information content in World Wide
`
`Web (WWW) pages accessed using a wireless device.
`
`BACKGROUND OF THE INVENTION
`
`5
`
`10
`
`Accessing browsable information such as Web content on the Internet is a
`
`part of everyday life for many people today. Most users currently access such
`
`information content by using computer systems that are physically connected to the
`
`Internet via a modem and physical wires of some sort, typically a telephone line or
`
`15
`
`coaxial cable. At the same time, wireless devices and the wireless .networks they
`
`work on are becoming more widely available. Many modern wireless networks are
`
`connected or at least connectable to the Internet. As such, the demand for browsers
`
`on wireless devices that can access the World Wide Web is increasing rapidly.
`
`20
`
`Wireless devices and the associated wireless networks within which they
`
`operate present several design challenges not normally encountered in standard
`
`wired networks. First, unlike personal computers (PCs) and servers that are wired to
`
`the network, mobile and other wireless devices are connected to the network using
`
`radio links. As such, they are only connected when the device is "in range", or within
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`coverage of one of the wireless network's radio transmitters. Because the wireless
`
`networks do not completely cover all areas where users will be using the devices,
`
`connectivity to the networks can be frequently gained and lost. No connectivity
`
`guarantees can be made at any given point in time.
`
`5
`
`Furthermore, even when a device is connected to a wireless network, the
`
`bandwidth of such networks can be quite low. Current networks, such as Mobitex™
`
`and Datatac™, operate in the 9.6 kilo-bit per second (kbps) to 14.4kbps range.
`
`Newer networks, such as General Packet Radio Service (GPRS) and the Global
`
`1 o System for Mobile Communications (GSM), will operate in the 20kbps to 110kbps
`
`range. As will be apparent to those skilled in the art, this range relates to raw speed.
`
`Real. speed is lower when retransmissions of corrupted packets and network.
`
`congestion are accounted for. So-called third generation networks, such as
`
`Universal Mobile Telecommunications System (UMTS), are expected to operate in
`
`15
`
`the 384kbps range or higher, but are not expected to be deployed for at least several
`
`years.
`
`Most mobile devices also currently have much lower screen resolution and
`
`processing power than typical PCs or laptops. For example, known mobile devices
`
`20
`
`tend to have screen resolution on the order of 160 x 160 x 1 bit (monochrome) or
`
`smaller, as compared to low-end desktop PC or laptop monitor resolution of 1024 x
`
`768 X 24bits.
`
`For a user, these factors make the browsing experience on mobile devices
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`considerably different from that on computers with wired network connections. From
`
`the perspective of service providers and device manufacturers, such characteristics
`
`of wireless devices and wireless networks hinders the provision of browsing
`
`capabilities in wireless systems.
`
`In particular, much of the information content on
`
`s wired networks assumes that a computer or device will be connected to the network
`
`for the duration of the browsing session.
`
`In addition, content is increasingly being
`
`geared towards bandwidths of 128kbps or higher and to high-resolution screens and
`
`computers with extensive processing power to support animations, large graphics,
`
`and the like.
`
`10
`
`The Wireless Application Protocol (WAP) Forum was cr~ated to address
`
`incompatibilities between the capabilities of current mobile devices and wireless
`
`networks and the various processing, memory and display requirements for viewing
`
`different types of Web content. The result was the WAP specification, a de-facto
`
`"15 worldwide standard, which includes both a protocol to deliver Web content to
`
`wireless devices, and a new form of markup, called Wireless Markup Language
`
`(WML). WML is geared towards providing the essence of high-value web pages for
`
`extremely small devices such as cellular telephones.
`
`20
`
`The WAP protocol addresses the issue of delivering content to wireless
`
`devices on slow, unreliable networks. However, although WML allows content to be
`
`developed for cell phones, it is not clear that it is as appropriate for personal digital
`
`assistant (PDA) style mobile devices, which have larger screens and tend to have
`
`more processing power than most cell phones.
`
`- 3 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`The continuing movement towards web-based user interfaces for wireless
`
`communication devices, coupled with a general sentiment that Hypertext Markup
`
`Language (HTML) and WML provide inadequate user interface controls, is expected
`
`5
`
`to result in an increasing demand for mechanisms to extend basic browsing
`
`capabilities. Browser extensibility will therefore likely become an important part of
`
`mobile device application platforms.
`
`Therefore, there is a need for a Web content browser for wireless devices,
`
`10 which provides browsing functionality similar to that of conventional Web browsers
`
`designed for hard-wired network connected devices. Such a browser should
`
`overcome the above problems associated with browsing information on a wireless
`
`device and should be compatible with multiple information content types. There is a
`
`further need for such a browser to be integrated with other functions of wireless
`
`15
`
`communication devices.
`
`SUMMARY OF THE INVENTION
`
`According to an embodiment of the invention, a web browser comprises a
`
`page cache containing a plurality of pages in a plurality of formats, and a converter
`
`20
`
`and renderer operatively connected to the page cache for rendering the plurality of
`
`pages for display by the browser.
`
`In accordance with a further aspect of the invention, a wireless web browser
`
`comprises a radio configured for communications with both a Wireless Application
`
`- 4 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`Protocol (WAP) gateway and an Internet Protocol (IP) proxy server.
`
`A web browser according to another aspect of the
`
`invention has a
`
`background processing object, the background processing object permitting the
`
`s
`
`browser to access information after the browser has been closed.
`
`According to a further aspect of the invention, a web browser comprises a
`
`message store, the message store connected to at least one application selected
`
`from the set of: email application, voicemail application and SMS application, and
`
`1 o
`
`the message store containing objects retrieved by the browser and the least one
`
`application.
`
`In another embodiment of the invention, a computer readable medium
`
`comprises instructions for implementing a page cache, a renderer controller
`
`15
`
`operatively connected to the page cache and a serialization manager operatively
`
`connected to the renderer controller.
`
`A method for installing a converter on a wireless device according to a still
`
`further aspect of the invention comprises the steps of determining if the converter is
`
`20
`
`registered on the wireless device, if the converter is registered, then requesting the
`
`converter via a wireless network, and when the converter is received in response to
`
`the request, installing the converter on the wireless device.
`
`A method for rendering a page on a wireless communication device, in
`
`- 5 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`another aspect of the invention, comprises the steps of
`
`receiving the page over
`
`a wireless network, selecting a converter for the page, rendering the page to created
`
`a rendered page for display by a browser, and storing the rendered page in a page
`
`cache.
`
`5
`
`In another embodiment of the invention, a browser for a wireless device
`
`comprises a browser object operatively connected to a browser daemon, a stack
`
`manager operatively connected to the browser object and the browser daemon, the
`
`stack manager further connected to a wireless radio ·via a plurality of interface
`
`1 o adapters, and the radio connected to a plurality of communication links, the
`
`communication links providing information to and sending information from the
`
`browser object and the browser daemon.
`
`A computer readable medium comprising instructions for implementing a
`
`1 s
`
`browser for a wireless device according to a further embodiment of the invention
`
`comprises instructions for implementing a browser object and a browser daemon,
`
`the browser object and the browser daemon communicating with each other,
`
`instructions for implementing a stack manager, the stack manager in communication
`
`with the browser object and the browser daemon, instructions for implementing a
`
`20
`
`plurality of interface adapters, the interface adapters in communication with the
`
`stack manager and a wireless radio, and instructions for connecting the radio to a
`
`plurality of communication links, the communication links providing information to
`
`and sending information from the browser object and the browser daemon.
`
`- 6 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`For a better understanding of the present invention, and to show more clearly
`
`5
`
`how it can be carried into effect, reference will now be made, by way of example
`
`only, to the accompanying drawings in which:
`
`Figure 1 is a block diagram of objects and components in an embodiment of
`
`the present invention;
`
`1 o
`
`Figure 2 is a block diagram of objects and components associated with a
`
`browser daemon;
`
`Figure 3 is a block d,iagram of objects and components associated with a
`
`renderer system;
`
`Figure 4 a block diagram of converter, renderer and page objects;
`
`15
`
`Figure 5 is a block diagram of an information browsing system utilizing the
`
`present invention;
`
`Figure 6 is a block diagram illustrating communication connections;
`
`Figure 7 is a logical flow chart of the process performed by the present
`
`invention;
`
`20
`
`Figure 8 is a logical flow chart of the process performed by a network' request;
`
`Figure 9 is a logical flow chart of the process performed by a renderer
`
`system;
`
`Figure 1 O is a logical flow chart of the process for closing a browser session;
`
`Figure 11 is a block diagram of the objects and components of the present
`
`~5
`
`invention integrated with a messaging system;
`
`- 7 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`Figure 12 is a block diagram of an information browsing system utilizing the
`
`present invention integrated with a messaging system;
`
`Figure 13 is a screen capture of a message list;
`
`Figure 14 is a screen capture of a message list browser menu; and
`
`5
`
`Figure15 is a screen capture of a generic browser menu.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`A browser according to an aspect of the present invention is generic in the
`
`1 o
`
`sense that it preferably displays content from WML, HTML and new formats as they
`
`become available. Subsequent references in this description to WML and HTML
`
`type content are intended to include not only WML and HTML, but also other content
`
`types or formats which are or may become available. Many browser functions are
`
`common across all content types, whereas other functions are specific to the content
`
`15
`
`type, as will become clear from the following description. The browser will preferably
`
`be able to switch between different content types as determined by the type of
`
`content returned to the browser in response to an information or content request.
`
`Referring now to Figure 1, a block diagram of objects and components in an
`
`20
`
`embodiment of the present invention, is shown generally as 100. Figure 1 illustrates
`
`a software implementation of browser 100, with the arrows representing references
`
`between the objects and components. The invention is preferably implemented
`
`primarily in software, but may also be implemented at least partially in hardware.
`
`- 8 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`As described above, generic and content-specific functionality and related
`
`software objects are separate. Dispatch thread 102 is the main event thread of
`
`system 100 and notifies browser application object 104 of all user inputs and
`
`communication events.
`
`In order to ensure a responsive user interface (UI),
`
`s
`
`processing times for such events should be limited. Browser application object 104
`
`is the parent application object, which basically functions as a container for the
`
`object shown as browser object 106. Browser object 106 is a transient process while
`
`browser daemon 108 is a persistent process. Browser daemon 108 always runs in
`
`the background and supports all the fetching operations. It also automatically loads
`
`10
`
`previously fetched Uniform Resource Locators (URLs) into the message list, as will
`
`become apparent from the description below.
`
`Browser object 106 and browser daemon 108 perform "generic" browser
`
`functions that apply to WML, HTML, WMLScript and any other content types that
`
`15 may be received or otherwise encountered. This includ~s such functions as history
`
`management, control of page retrieval and display, control of image retrieval and
`
`display, creation and handling of menus, detection and execution of scripts and the
`
`like.
`
`20
`
`History object 110 is the navigation history, essentially a memory stack of
`
`pages or more particularly the URLs associated with the pages that have been most
`
`recently accessed. History object 110 can be queried to determine whether or not it
`
`is empty. Based on this determination, browser 100 enables or disables "Forward"
`
`and "Back" functions for example.
`
`- 9 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`Bookmarks object 112 is a store of all the bookmarks currently known to
`
`browser 100. The contents of the bookmarks object are controlled by a user, through
`
`add, delete, arrange and such bookmark operations.
`
`5
`
`Browser object 106, as discussed briefly above, is a transient object which is
`
`opened and closed by a user. When the user asks to see a new URL, the browser
`
`object 106 first asks the page cache 114 if the page object corresponding to the
`
`URL is available. If it is, the browser object 106 displays it, via a display or screen
`
`1 o
`
`user interface object (not shown). Otherwise, browser object 106 creates a fetch
`
`request object and sends that fetch request object to the browser daemon 108.
`
`Browser daemon 108, in turn, processes the fetch request object (as discussed
`
`further below) and sends a result back to browser object 106. When browser
`
`daemon 108 receives a response to a fetch request object, it places data from the
`
`1 s
`
`response into the fetch request and changes a state of the fetch request object to
`
`"received". Browser object 106 has an associated receiver thread 118 for each
`
`request that waits for a request to change to "received" state. When a response is
`
`received, receiver thread 118 creates a render thread 120 to process that result.
`
`This scheme eliminates the need for a received results queue or the like and thereby
`
`20
`
`conserves memory resources on a device in which a browser such as shown in Fig.
`
`1 is implemented. However, it should be appreciated that other aspects of the
`
`invention are also applicable to systems which utilize a results queue.
`
`Render thread 120 provides the result to page cache 114 and asks for a
`
`- 10 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`corresponding page object 124 in return. Page cache 114, in turn, delegates to
`
`renderer system 122 to produce page object 124 from the result. When renderer
`
`system 122 returns page object 124, page cache 114 will store it.
`
`5
`
`If an information request is outstanding or in process when browser object
`
`106 is closed, when browser daemon 108 is ready to forward that result to browser
`
`object 106, browser daemon 108 will detect that browser object 106 no longer exists.
`
`In such a case, browser daemon 108 will optionally store the result as a browser
`
`message in a message store (not shown). Such functionality is described in more
`
`1 o detail below.
`
`Page cache 114, as its name implies, is a cache of page objects 124. If the
`
`page object corresponding to a requested Uniform Resource Locator (URL) is in
`
`page cache 114, it can be displayed by the browser object 106 very quickly. As is
`
`15
`
`common
`
`in
`
`the art, page cache 114 employs a least recently used (LRU)
`
`replacement policy.
`
`Raw data cache 126 is a cache that stores the raw bytes for all requested
`
`content, including HTML pages, WMLC decks, images, compiled WMLScript scripts
`
`20
`
`and any other requested content formats. Like the page cache 114, it also employs
`
`a LRU replacement policy.
`
`Secondary fetch threads 128 are used to process secondary fetch operations,
`
`such as loading images and are initiated by browser object 106. Primary fetch
`
`- 11 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`operations, such as fetching pages, are preferably performed as background
`
`operations by browser daemon 108 (Figure 2).
`
`Referring now to Figure 2 a block diagram of objects and components
`
`5
`
`associated with a browser daemon is shown generally as 150. Stack manager 160
`
`manages all requests for content, directing them to the appropriate stack. Stack
`
`manager 160, in conjunction with renderer system 122 (Figure 3), provides for the
`
`multiple content format functionality of browser 100 and the device in which it is
`
`installed. Stack manager 160 is associated with both a WAP stack 162 and an
`
`1 o HTTP stack 164 through WAP stack adapter object 166 and HTTP stack adapter
`
`object 168 respectively. In a preferred embodiment, HTTP stack 164 is a proprietary
`
`HTTP-over-lPPP (IP Proxy Protocol) stack, discussed in further detail below. Thus,
`
`a wireless device equipped with a browser 100 can access information using not
`
`only WAP, as in prior art wireless devices, but also HTTP.
`
`15
`
`For each URL that is not in page cache 114 or raw data cache 126 an
`
`instance of a primary fetch thread 172 is created to fetch the requested data. Cookie
`
`cache 170 stores cookies associated with previously accessed or downloaded
`
`information content. Some information sources may for example require a user to
`
`20
`
`login using a user name and password, either or both of which may be stored as a
`
`cookie in cookie cache 170. Process converter thread 174 is a worker thread that
`
`retrieves fetch requests from the request queue 176 and creates instances of
`
`primary fetch thread 172 to process the request. Request queue 176 is a queue that
`
`contains requests for information from browser daemon 108. As resources permit,
`
`- 12-
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`an item on request queue 176 will be initiated as a primary fetch thread 172. Data
`
`received in response to requests from the browser daemon 108 will preferably be
`
`added to fetch requests in the request queue 176 and the status of such requests
`
`changed to "received", as described above.
`
`5
`
`Referring now to Figure 3 a block diagram of objects and components
`
`associated with a renderer system is shown generally as 200. In response to a page
`
`object request, renderer control object 202 will examine the resultant content type to
`
`determine which converter and renderer objects are required to generate a page
`
`1 o
`
`object. Serialization manager 204 determines if the required converter object is
`
`resident on the device and if so, calls the appropriate converter object (206a, 206b,
`
`206c, 206d). Converter object 206 converts the raw input data into an object that
`
`can be rendered. Converter object 206 creates an appropriate renderer object
`
`(208a, 208b, 208c, 208d) to render the data and produce a page object (124a, 124b,
`
`15
`
`124c, 124d) and return the new page object to the page cache 114. The new page
`
`object, which contains screen user interface (UI) components, will also be displayed
`
`to a user by the browser object 106. All pages generated by the converters and
`
`renderers are compatible with the particular display UI implemented in the wireless
`
`device.
`
`20
`
`Serialization manager 204 maintains a registry of format converters for
`
`different information formats.
`
`In a preferred embodiment of the invention, a third
`
`party communicates with serialization manager 204
`
`to register new
`
`format
`
`converter/renderer combinations such as the Format X ·converter object 206d.
`
`- 13 ·-
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`Information formats other than those corresponding to converter objects provided on
`
`the device by a manufacturer can thereby be rendered and displayed by the device
`
`by simply installing the appropriate converter objects, which creates associated
`
`renderer objects as required.
`
`5
`
`When content is returned to the wireless device in response to an information
`
`request, the renderer controller 202, in conjunction with the serialization manager
`
`204, determines the type of content, the converter and renderer objects required to
`
`convert the content into a page object, and whether or not the required converter
`
`1 o
`
`and renderer objects are available on the device.
`
`If the required converter is
`
`regi.stered with the serialization manager 204, then the converter is called to convert
`
`the byte array into a page. Serialization manager 204 returns a null value to
`
`renderer controller 202 when a required converter object is not registered.
`
`15
`
`Where received information is in a format other than those for which a
`
`converter object is registered with the serialization manager 204, the device may not
`
`be capable of displaying the information. According to a further aspect of the
`
`invention, a remote system or server in the network within which the wireless device
`
`is operating may register non-resident converter and renderer objects as being
`
`20
`
`available to the device, In such systems, when information received in response to
`
`an information request is in a format requiring converter and renderer objects not
`
`resident on the device but registered with the serialization manager 204 as non(cid:173)
`
`resident converter objects, serialization manager 204 requests and downloads the
`
`required converter object. Serialization manager 204 thereby significantly expands
`
`- 14 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`the browsing capabilities of the wireless device in comparison with prior art devices.
`
`Referring now to Figure 4 a block diagram of converter, renderer and page
`
`objects is shown generally as 240.
`
`Converter object 206 is a superclass object
`
`s
`
`representing all conve~er objects 206a to 206d. Similarly, renderer object 208 is a
`
`superclass object representing all rendering functions 208a, 208b, 208c, and 208d.
`
`WML converter object 206a and WML renderer object 208a convert a byte array that
`
`contains WMLC (Compiled WML) into a WML page object 124a. HTML converter
`
`object 206b and HTML renderer object 208b convert a byte array that contains
`
`1 o
`
`filtered HTML content into an HTML page object 124b. Similarly, the WMLScript
`
`converter object 206c and WMLScript renderer object 208c comprise a rendering
`
`engine for WMLScript scripts, which creates WMLScript page objects 124c. Format
`
`X converter object 206d and Format X renderer object 208d
`
`illustrate the
`
`extensibility aspect of the present invention which is described in further below.
`
`15
`
`Referring now to Figure 5 a block diagram of an information browsing system
`
`utilizing the present invention is shown as wireless device 300. User input is
`
`provided to the main browser control component 304 through input interface 306. It
`
`should be noted that the functionality of both browser object 106 and browser
`
`20
`
`daemon 108 is included in component 304. Background .operations performed by
`
`component 304 involve daemon 108 functionality, whereas foreground operations
`
`would be associated with the browser 106.
`
`Depending upon the nature of the user input, component 304 may interact
`
`- 15 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`with one or more of the memory lists or caches 110, 112, 114, 126 and 170, in
`
`memory 308. Memory 308 may for example be a random access memory (RAM) in
`
`which the various caches occupy predetermined storage space or alternatively,
`
`dynamically allocated storage space. Memory 308 may also possibly com~rise
`
`5 multiple distinct memory elements, each incorporating one or more of the caches.
`
`Wireless device 300 further includes a stack manager 310. Stack manager
`
`310 manages all requests for content, directing them to the appropriate interface
`
`adapter 312 or 316. Stack manager 310 further communicates with renderer
`
`1 o
`
`controller 320 and converter/renderers 330a, 330b, 330c and 330d to ensure
`
`incoming data is properly converted and rendered for display to a user. WAP
`
`interface 314 and HTTP interface 318 interact with radio 334 to request and obtain
`
`data over a wireless network. Renderer controller 320 and serialization manager
`
`322 perform the functions described previously with regard to Figure 3. User
`
`15
`
`interface 332 may be visual display or any other device that is capable of
`
`communicating the results of a browser request to a user. Although shown as single
`
`functional blocks 330a, 330b, 330c and 330d, it is to be understood that the
`
`converter/renderers perform both the converter and renderer object functions
`
`described above to generate pages for display on the device from information
`
`20
`
`received in response to requests. As described above, the renderers are preferably
`
`transient objects created by the converters as required and thus are not shown
`
`separately in the block diagram.
`
`Radio 334 is a wireless communication module, which operates in a wireless
`
`- 16 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`communication network.
`
`In a preferred embodiment of the invention radio 334 is a
`
`device adapted for communication on the Mobitex network, although communication
`
`modules for the DataT AC network, GSM/GPRS networks and other wireless
`
`communication systems are also possible. The multiple content type information
`
`s
`
`browsers and associated methods in accordance with the instant invention are
`
`independent of the particular wireless network on which the device operates.
`
`Referring now to Figure 6, a block diagram illustrating communication
`
`connections is shown generally as 380. Radio 334 of wireless device 300
`
`1 o
`
`communicates over wireless links to a plurality of devices. Communication link 336
`
`connects radio 334 with a WAP gateway 338 or with an IP proxy server 340 via links
`
`360, 362 or 364. Thus, radio 334 is able to utilize either a WAP or HTTP protocol. In
`
`I
`
`a preferred embodiment of the invention, HTTP interface 318 is a proprietary HTTP(cid:173)
`
`over-lPPP stack, such that when HTTP is used for information browsing, radio 334
`
`15
`
`communicates with an IP proxy server 340 using IPPP. In the embodiment shown in
`
`Figure 6, IP proxy server 340 incl'udes a WML filter 342, an HTML filter 344 and an
`
`HTTP connector 346. Filters 342 and 344 respectively convert raw WML and raw
`
`HTML content into proprietary filtered formats and return the filtered content to radio
`
`334 via communication links 360 and 362 respectively. A third alternative is
`
`20
`
`unfiltered data and this is performed via communications link 364.
`
`Both WAP gateway 338 and IP proxy server 340 request information or
`
`content from information sources such as servers 352a and 352b through a network
`
`350. Network 350 is typically the Internet, but may also be an intranet or other
`
`- 17 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`relatively smaller-scale network. WAP gateway 338 and IP proxy server 340 may
`
`possibly be connected to different networks. Servers 352a and 352b may be
`
`connected to network 350 through one or more further networks. Other information
`
`source arrangements will be apparent to those skilled in the art and are intended by
`
`5
`
`the inventors to be within the scope of the invention.
`
`Referring now to Figure 7, a logical flow chart of the process performed in an
`
`illustrative embodiment of the present invention is shown generally as 400. The
`
`browser implementing process 400 is preferably pre-programmed with a "home
`
`10
`
`page" URL that it will attempt to load when started at step 402. The browser will first
`
`create a request to load the pre-programmed "home page" URL at step 404. It will
`
`then enter the normal page-request cycle, · which begins with
`
`the browser
`
`determining if a valid previously rendered copy of the home page is stored in the
`
`page cache at step 406.
`
`If the home page is stored in the page cache, then the
`
`15
`
`browser can quickly load it from cache at step 408 and display the page at step 410.
`
`If no valid' copy of the page is stored in the cache, when the cache copy has
`
`expired or has been replaced by a new page entry under a page cache LRU
`
`replacement policy for example, the browser attempts to download the home page
`
`20
`
`from the information source through a network request, indicated at step 412.
`
`In
`
`response to the network request, the network returns information to the browser at
`
`step 414, which may be the requested information but may instead be an error
`
`message if the requested
`
`information cannot be accessed or is otherwise
`
`unavailable. A test is made at step 416 to determine if the network request was
`
`- 18 -
`
`
`
`WO 02/052785
`
`PCT/CAOl/01857
`
`successful. If it was, i.e. the requested information is returned, the returned content
`
`is converted and rendered at step 418. Provided that the home page is either stored
`
`in the page cache when the browser is started or downloaded from the network, the
`
`home page is displayed by the browser on the device at step 410. If the home page
`
`s
`
`cannot be loaded, control moves from step 416 to step 420 where the browser may
`
`generate an error page or selected a predetermined stored page. The error page or
`
`predetermined stored page is then displayed at step 410. The error page or
`
`predetermined stored page is preferably stored in a memory location not subject to
`
`the normal LRU cache replacement scheme. Although browser startup would be
`
`1 o
`
`simplified by initially displaying a predetermined stored page and thereby avoiding
`
`some processing and possibly network access operations, this would preclude a
`
`user selecting a personal home page.
`
`As discussed briefly above, converted and rendered pages processed by the
`
`15
`
`browser include not only WML and HTML pages for display, but also WMLScript and
`
`other script pages with run elements which are exec