DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0049] FIG. 1 shows a high-level block diagram illustrating an exemplary system 100 for accessing and adapting feature rich information content for presentation on an electronic device 104 . The accessed and adapted information content is transmitted between an information source 102 and the electronic device 104 .

[0050] The information source 102 includes any type of device such as a web server, application server, database or other backend system, or any interface such as a web service to an information provider. Preferably, the information source 102 provides information content expressed in a markup language, such as those markup languages known in the art including Hypertext Markup Language (HTML), Extensible Markup Language (XML) with or without Extensible Style Sheets (XSL), VoiceXML, Extensible Hypertext Markup Language (XHTML), or Wireless Markup Language (WML). Furthermore, the information content can store images, video, audio information. Preferably, the information source 102 can be accessed through an information access network 106 such as a local area network (LAN) or wide area network (WAN).

[0051] The electronic device 104 includes any type of device such as a personal computer (PC), wireless telephone, personal digital assistant (PDA), hand-held computer, network appliance, and a wide variety of other types of electronic devices that might have navigational capability (e.g., keyboard, touch screen, mouse, etc.) and an optional display for viewing downloaded information content. Furthermore, the electronic device 104 can also include a device such as a set-top box, Internet access appliance, infra-red remote control used with a set-top box, and so forth. Moreover, the electronic device 104 can include any type of device that has the capability to utilize speech synthesis markups such as W3C (www.w3.org) Voice Extensible Markup Language (VoiceXML).

[0052] Information content from the information source 102 is preferably retrieved and tailored for use on the electronic device 104 by a distributed browser 108 . The distributed browser 108 is generally made up of a server browser 110 and a client browser 112 . By utilizing the distributed browser 108 , smaller electronic devices with limited hardware capability can access feature rich information or data. Moreover, the distributed browser 108 allows for efficient use of the communications network 114 bandwidth. Of course, electronic devices with high processing power, fast network connection, and large memory can also use the present embodiments.

[0053] In the exemplary embodiment, the server browser 110 and the client browser 112 are hosted on separate platforms. For example, the server browser 110 might be hosted on a back-end server, and the client browser 112 might be hosted on the electronic device 104 . However, it should be understood that the server browser 110 and client browser 112 can be hosted on the same platform such as on an electronic device, especially if the platform or electronic device has the appropriate hardware and network capabilities.

[0054] The server browser 110 can access information content at the information source 102 via the information access network 106 . In the exemplary embodiment, the server browser 110 operates as a client of the information source 102 . For example, using a known suite of communications protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP), the server browser 110 can issue a Hypertext Transfer Protocol (HTTP) request to the information source 102 over the information access network 106 . By utilizing HTTP requests, such as is known in the art, the server browser 110 can access information content, including applications, static and dynamic content, at the information source 102 . Dynamic content can include script codes such as JavaScript, developed by Netscape (www.netscape.com), and Jscript, developed by Microsoft (www.microsoft.com).

[0055] Preferably, communications between the client and server browsers 112 and 110 , respectively, are via a defined application protocol implemented on top of a wired or wireless transport layer depending on the nature of the electronic device 104 and communications network 114 .

[0056] Therefore, the communications network 114 might include a wired network such as those that utilize Ethernet or similarly IEEE 802.3 protocols. The communications network 114 might also include a wireless network such as a local area wireless network (LAWN) or wireless local area network (WLAN). Moreover, the communications network 114 might include wireless networks that utilize other known protocols and technologies such as Bluetooth, wireless application protocol (WAP), time division multiple access (TDMA), or code division multiple access (CDMA). Furthermore, the communications network 114 is not limited to terrestrial networks, but can utilize other forms of transmission, as is known in the art, such as a satellite connection.

[0057] To provide an exemplary illustration, assume that a PDA hosts a client browser, a PC hosts a server browser, and the PDA and PC are both connected to an Ethernet network. Then, the client browser and the server browser could perform information transactions over the Ethernet network. Such transactions would utilize Ethernet or similarly IEEE 802.3 protocols. Nevertheless, in this example, the client and server browsers communicate over a wired network.

[0058] In another example, assume that an internet-enabled refrigerator hosts a client browser, a set-top box hosts a server browser, and both could perform information transactions over a Bluetooth or IEEE 802.11 wireless LAN. Then, according to this example, the client and server browsers are communicating over a wireless network.

[0059] The distributed browser supports network optimization between the client browser 112 and server browser 110 through the use of a transport layer protocol that effectively increases the speed of transmission of content between these two end-points. This results in reduced latency for the client browser 112 to retrieve content from the information source 102 and hence an overall improvement in the user's experience. This type of optimization is most beneficial when the communication path between the client browser 112 and server browser 110 is over a wireless network.

[0060] One implementation of this type of transport layer optimization is based on the Stream Control Transmission Protocol (SCTP) [Network Working Group RFC 2960] with parameters and message sequencing optimized for wireless transmission media. The key feature of the SCTP-based network optimization protocol is support for multiple independent streams of application messages over a single connection. This reduces or can eliminate the “head-of-line-blocking” problem associated with the use of TCP due to the necessity to maintain strict sequence messaging. The ability to support multiple independent streams is key to the application of this protocol to the distributed browser 108 since two or more of the various objects which constitute the content obtained from the information source 102 can be simultaneously transferred via separate streams over the same connection. Flow control and congestion control are mechanisms utilized by the protocol to maintain the efficiency of the streams.

[0061] Another feature of the SCTP-based network optimization protocol is the capability to monitor the reachability of the remote end-point thereby providing transport-level fault tolerance. The SCTP-based network optimization protocol also supports preservation of application message boundaries for logical chunks of data sent over a single stream. This is a particularly efficient method for the client browser 112 to receive independent parts of the same document useful for the support of in-line expansion of folderized content. Lastly, the protocol supports unordered reliable message delivery which provides for the out-of-band messaging capability used to support the server to device push of content, configuration updates and application updates described elsewhere in this document.

[0062] Referring again to FIG. 1, a commercially available or standard client browser 140 can also be supported. Preferably, an event translator 136 is used to convert a request/response protocol, such as an HTTP request, from the standard client browser 140 (e.g., WML, XHTML, cHTML, etc.) to an event that the server browser 110 recognizes. Preferably, the translation process includes event information, content information, and the context of the event such that transactions between the standard client browser 140 and the information source 102 (e.g. HTML form submission) are preserved. Therefore, by using the event translator 136 , the server browser 110 can provide an interface to any end user application with a known protocol. Thus, for example, an electronic device 104 can utilize the client browser 112 or standard client browser 140 , or both at the same time, if so desired.

[0063] The server browser 110 can be hosted on any platform with sufficient hardware capability for performing tasks by the server browser 110 described herein. Such platforms can include but are certainly not limited to desktop or laptop PCs, servers, computer clusters, or embedded devices. It should also be understood that the server browser 110 can also be hosted on the electronic device 104 , especially if the electronic device has the hardware and network connection capability.

[0064] According to the exemplary embodiment, the server browser 110 can authenticate itself with the information source 102 , facilitate the request of the information using a protocol acceptable to the information source 102 (e.g., an HTTP request for a web server), provide secure transactions with the information source 102 , provide secure transactions with the client browser 112 , execute embedded scripts or code segments, and resolve necessary external references (e.g., request HTML frames or script sources) to complete the information model. Preferably, the server browser 110 also includes information content caching and data pre-fetch for performance gain.

[0065] Furthermore, the server browser 110 can perform information content transformations or apply device specific style sheets to aid in presentation (e.g., display or voice) and navigation (e.g., keyboard, touch screen, or scrolling), and perform content grouping for electronic devices that accepts data in limited quantities.

[0066] To deliver these capabilities, the server browser 110 preferably contains the modules including user agent 110 , cookie handler 112 , QDOM 116 , script executor 120 , normalizer 124 , serializer 128 , and connectivity 132 , each described below. A session manager 108 is also included to manage the session between the client browser 112 and the server browser 110 . Similarly, the session manager 108 can also manage the session between the standard client browser 24 and the server browser 110 .

[0067] FIG. 2 is a diagram further illustrating the server browser of FIG. 1 . The server browser utilizes a user agent 110 for accessing information at the information source 102 . Preferably, the user agent 110 has the functionality of a traditional PC browser (e.g., Netscape Navigator, Internet Explorer, and so forth) as well as extended functionality, described below, due to the distributed nature of the electronic device 104 . To access the appropriate information content at the information source 102 , the user agent 110 communicates the requested resource identifier to the information source 102 .

[0068] For example, the user agent 110 might transmit an HTTP request to a remote web server that hosts yahoo.com. According to this example, the user agent 110 would transmit a resource identifier to request a specific web page or ask the remote web server to perform a database query. The request including the resource identifier is broken into HTTP packets and the packets are sent across the Internet's TCP/IP communications infrastructure to the remote web server. The resource identifier then enables the host computer to locate the requested page at yahoo.com and return the information content to the user agent 110 .

[0069] In addition to transmitting the resource identifier, the user agent 110 might inform the information source 102 of the client browser 112 type, electronic device 104 capabilities, and user preferences in the request headers and receives information identifying the properties of the data received (such as the content type, length and encoding) in the response headers. The headers that are sent back and forth between the information source 102 and the server browser 110 may also contain one or more cookies stored at the server browser 110 on behalf of the client browser 112 .

[0070] Preferably, the user agent 110 conforms to the broader industry definition of the term as a component of the server browser 110 that acts on behalf of the electronic device 104 to request information from an information source 102 . The requested information content can be from any information source including a web server as described above, but is not restricted to a web server. Other sources of information content might include an email server, Instant Messaging server, database or other storage of information. Additionally, the means through which the user agent 110 communicates with the information source 102 includes the HTTP protocol as described above, but of course, is not limited to that protocol.

[0071] Beyond industry conformance, the server browser adds the concept of dynamic user agent 110 functionality by enabling the identity information sent in the request to the information source 102 to vary depending on the type of application being accessed. According to standard industry practice, a content server or information source 102 recognizes the properties of a connected client, and understands how the client browser works. Then, the server sends suitable content to the client so that, for example, the Netscape browser may receive different content from Internet Explorer because they report different user agent capabilities in their requests. The different capabilities may be explicitly stated or implied by client name and version information. These and other existing client browsers in the industry always report the same user agent attributes to every content server with every content request. In the exemplary embodiment, however, the user agent 110 attributes that are contained in the request can vary dynamically between requests. In doing so the identity which extracts the most content from the information source 102 will be represented by the user agent 110 . The identity to be represented will be determined via pre-configured rules and/or via algorithms taking into account the response information obtained from prior requests to the information source 102 .

[0072] Information content might also use XML information content and XSL style sheets instead of HTML as the preferred internet/intranet information content format. By using XML information content and an XSL style sheet, it can provide a clear separation of data and presentation. The XSL style sheet is applied to the XML information content by an XSLT engine to present the information content to an electronic device 104 .

[0073] The XSL style sheet is applied to the XML information content at the information source 102 , but preferably the client browser 112 can also apply the XSL style sheet to the XML information content. In this case, the server browser 110 preferably employs an XSLT engine to apply the XSL style sheet to the XML data before normalizing to produce content. One such example would be a WML client browser used to request an XML+XSL combination that produces XHTML. Alternatively, the information content author may choose to use the original XML and apply templates and/or wireless markup instead of or in combination with XSL style sheets.

[0074] In addition to providing normalizer functionality, the system can also use templates and meta-tag markup to alter the original information content to better suit an end user application for which it was not originally designed. This can be achieved through the addition, removal or substitution of sections of content, tags and attributes (separately or together) in the markup, described more below.

[0075] Information content might also use VoiceXML (www.voicexml.org) which is an XML based language for specifying voice dialogs, including audio prompts and text-to-speech (TTS) for output and touch-tone keys (DTMF) as well as automatic speech recognition (ASR) for input. VoiceXML technology enables consolidation of voice and web applications. For example, it can be used with voice-only devices to access a voice portal, or used to facilitate multi-modal (graphical and voice) dialogs to VoiceXML enabled client browsers).

[0076] Preferably, the system ( 100 in FIG. 1 ) via the user manager 110 has the ability to read and process VoiceXML markup as well as convert from one markup (from WML for instance) to VoiceXML format. In addition, templates and/or wireless markup can be used to specify which parts of a web page are to be audible (i.e. converted to VoiceXML) and which are to be rendered visually by the browser. The server can interact with a VoiceXML gateway (much in the same way as it does with the WML gateway) to facilitate the VoiceXML based services.

[0077] Location based services might also prove to be very popular in this industry as they are well suited to mobile applications. Preferably, the server browser 110 via the user agent 110 has the ability to interact with the network entity supplying the location information via a defined protocol. The current coordinates of the electronic device accessing the network are preferably sent in the request headers to the content (web) server and/or be accessible via session cookies so that the device can easily utilize this location information. This functionality enables useful applications such as a restaurant locator that lists restaurants within a few miles of the user's current location.

[0078] Referring back to FIG. 1 , the server browser 110 contains a cookie handler 112 . Cookies provide a means of personalizing the information content that is retrieved by the user agent 110 on behalf of the user of the electronic device 104 . Preferably, the cookie handler 112 supports session and persistent cookies. Session cookies are valid for the current user's session and persistent cookies can expire after a pre-determined time specified in the cookie or be permanent. An added benefit to server side cookie processing is that the user is provided access to his or her cookies from multiple electronic devices and the user's cookies are not lost when the user changes electronic devices.

[0079] Referring back to FIG. 2 , the user agent 110 translates the requested data content, if necessary, into a recognizable markup language for further processing. The markup language may be in the format of XML, WML, HTML, or any other markup language or technology (e.g., video, audio, image) that incorporates the features used by the present embodiments.

[0080] The translated information is then organized into a logically structured format for further processing by the QDOM 116 . The QDOM 116 efficiently constructs a nodal structure. The use of the QDOM 116 enables a standard structured interface to the retrieved content that can be utilized by all modules of the server browser 110 . The QDOM 116 can effectively and efficiently store the information content in a standardized structure for use by the normalizer, more described below.

[0081] Referring back to FIG. 1 , the server browser 110 has script executor 120 for assisting the QDOM 116 in interpreting embedded script code in the information content received from the information source 102 . The script executor 120 is preferably capable of supporting the European Computer Manufactures Association standard (ECMAScript revision 3), which is most prevalent in the industry, but may also be capable of handling other scripting languages, known in the art, such as JavaScript, Jscript (Microsoft's extending implementation of ECMAScript), Visual Basic Script (VBScript), or WMLScript. The script executor 120 enables programmatic access to the QDOM 116 representation of the document.

[0082] This extension to the QDOM 116 can allow executed script code to modify the resultant document that is sent to the client browser 112 , thus enabling dynamic content generation via scripting. Script executor 120 can also allow programmatic access to the cookies for a particular user, giving the content author the ability to create, modify or retrieve cookies associated with a given resource via script code. To interact with the user, communications between the script executor 120 and the client browser 112 is done via script events that are part of the application protocol between the server browser 110 and the client browser 112 .

[0083] Referring back to FIG. 1 , the server browser 110 has a Cascading Style Sheet (CSS) processor for supporting cascading style sheets. Cascading Style Sheets is now an industry standard developed and promoted by W3C (www.w3.org/Style) and supported by many of todays desktop browsers such as Internet Explorer. It defines a simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents that describes how the document should be presented on the screen. By attaching style sheets to structured documents on the Web (e.g. HTML), authors and readers can influence the presentation of documents without sacrificing device-independence or adding new HTML tags. The CCS processor can apply elements of style specified in the content received from the information source 102 . For example, the information source 102 may specify style elements including, but not limited to, color, background, size, font type, font size and alignment.

[0084] Preferably, the CSS processor is capable of supporting the W3C specifications for CSS levels 1 & 2. In addition, the CSS processor interacts with the script executor 120 in a manner that enables the information source to specify dynamically changeable elements of style via a scripting language. The QDOM resulting from CSS processing represents stylized content that can be interpreted and visually represented by the client browser 112 .

[0085] Referring again to FIG. 2 , data content that has been transformed into a DOM tree is then forwarded from the QDOM 116 to the normalizer 124 . Preferably, the normalizer 124 sends the DOM tree first to a template normalizer. If the template normalizer is unsuccessful at normalization, the DOM tree is then forwarded to an automatic normalizer where the data is normalized and then forwarded to the serializer 128 to be sent to the electronic device 104 via the connectivity manager 132 , further described below.

[0086] The serializer 128 utilizes the normalized tree as input and produces a media stream targeted for a specific electronic device 104 . Applying a style sheet or formatting rules to the DOM tree outputs a document (e.g., an XML document) that will be streamed to the electronic device 104 . Preferably, the formatting rules are electronic device 104 specific and take into account display size, font types, color etc. as well as the particular markup language(s) supported by the target electronic device 104 .

[0087] The server browser 110 has connectivity manager 132 for interacting with the client browser 112 . Connectivity manager 132 sends and receives information to the client browser 112 using an event format and protocol such as a proprietary format (e.g., OBML, described below) and XML event messages. According to the requirements of the electronic device 104 , the events may be translated via the event translator 136 ( FIG. 1 ) to use an externally defined format and protocol such as WML and WAP.

[0088] Referring back to FIG. 1 , the event translator 136 preferably provides the server browser 110 with compatibility with any standard client browser 140 or end user application that employs a known protocol such as HTTP. Current examples of such standard client browsers 140 include both WAP and non-WAP based WML browsers, HTML browsers, XHTML browsers, as well as both iMode and non-iMode compact-HTML (CHTML) browsers.

[0089] FIG. 3 is a diagram further illustrating exemplary uses for the event translator of FIG. 1 . The event translator 136 can be utilized on the server browser 110 side or the client browser 112 side, depending on which client browser 112 or standard client browser 140 is utilized. According to the server browser 110 side, the event translator 136 operates as the interface between a standard client browser 140 and the information content data stored in a DOM format at the server browser 110 . Preferably, the DOM is a QDOM 116 that identifies each node in the document using a unique value. According to the client browser 112 side, the event translator 136 can exist on the client browser 112 and provide an interface between the third party viewer and the micro-gateway 144 144 . One skilled in the art would appreciate that the event translator 136 is not limited to the server browser 110 side or the client browser 112 side, but can also operate between and externally to the server browser 110 and client browser 112 , if so desired.

[0090] Preferably, the event translator 136 translates requests for information content to known events that can be used to generate or modify a DOM tree, dynamically assigns unique device identifiers to identify the information source 102 of standard client browser 140 events, sends events and receives responses to and from the server browser 110 , and manages sessions and transactions (including timeouts, authentication, error handling etc.)

[0091] Referring back to FIG. 1 , the client browser 112 can be hosted on an electronic device 104 such as a PDA, handheld PC, mobile phone or any device with sufficient navigation and presentation capability. The client browser 112 provides the user interface for presentation or rendering of the retrieved information as well navigational capability.

[0092] Furthermore, portions of the client browser 112 may be used by a standard or commercially available client browser. In such examples, the client browser 112 can provide distributed browser functionality that is compatible with the standard or commercially available client browser.

[0093] Moreover, the electronic device 104 is preferably validated by user/appliance ID, which can be stored within a database on a server. This ID authenticates the electronic device 104 and validates that it is allowed to access specific data content found in a particular data source.

[0094] In an exemplary embodiment, the client browser 112 can access information content via the server browser 110 . Additionally, the client browser 112 preferably allows the user to submit information content or form data back to the information source 102 . The form data is a response to a query posed by the data content of a particular document from the information source 102 . Events containing the data for each component in the form are forwarded to the server browser 110 by the electronic device 104 where they are formatted in accordance with the content of that document by the server browser 110 . The result may be an error notification (e.g. network timeout, bad data, etc.) or display of a new document received from the server browser 112 as a result of server side 112 processing of the submitted form data.

[0095] Referring now to FIG. 4 , the client browser 112 preferably includes a microbrowser 148 , event controller 152 , and DOM store 116 according to the industry standard Model View Controller (MVC) representation. The microbrowser 148 is one example of an end user “View” application and represents information such as graphical or textual display, or audio to the user. The event controller 152 processes events to and from the server browser 110 . The DOM store 124 is utilized for caching the information content received over the communications network 114 .

[0096] The event controller 152 and the DOM store 124 operate as a micro-gateway 144 between the server browser 110 and an application 168 for interaction with the end user. In the exemplary embodiment the application 168 presents a typical browser interface allowing display and navigation of content, form interaction and submission and so forth. It should be understood, however, that the micro-gateway 144 can also support multiple different end user applications 172 on the electronic device depending on their availability and the nature and type of content data delivered to it.

[0097] Examples of such end user applications include, but are not limited to, email, instant messaging, media players and other such plug-ins. Further, multiple different kinds of browsers designed for particular markup types (HTML, cHTML, WML, etc.) and so forth can also be supported by the micro-gateway 144 . The micro-gateway 144 can also be used as a front end to enable access to web services by end user applications. In this regard, the application 168 utilizes a common API to the micro-gateway as a transport mechanism to relay requests and responses to the web service application information source 102 .

[0098] In one aspect of the exemplary embodiment, the micro-gateway 144 presents an external interface to other applications 168 and 172 that consists of a well defined interface to the DOM Store 124 component and an interface to the event controller 152 using the same event model that is described below for communications internal to the distributed browser. In another embodiment, the micro-gateway 144 can be combined with the end user application 168 and 172 and use a more tightly coupled internal interface.

[0099] Additionally, the micro-gateway 144 can use an event translator (not shown in FIG. 4 ) to provide an interface to third party or commercially available applications such as HTML or WML or cHTML browsers. For example, according to an aspect of the present embodiment, a micro-gateway 144 and an event translator to cHTML can be used to provide an interface between the server browser component and the third party cHTML browser known as Pocket Internet Explorer on a Pocket PC device running the Microsoft Windows CE operating system.

[0100] The microbrowser 148 , renders the information content transmitted to the client browser 112 by the server browser 110 . In the exemplary embodiment, the rendering includes visual representations (both textual and graphical) of the markup elements, but can be extended to provide other representations (e.g., audio) according to the capabilities of the electronic device 104 . The format of the representations can be fixed by particular microbrowser 148 implementations such as a WML or proprietary (e.g., OBML) browser, or can be modified according to an XSLT style defined in conjunction with the content markup.

[0101] Typically the microbrowser 148 is used to directly display markup based content received through the micro-gateway 172 . In addition, the markup based content can be used to adaptively tailor the microbrowser 148 according to directives contained in the information content. Adaptations can include embedding application logic in the content presentation, modifications to the interface (menus, titles, etc.) and other configuration of the browser application or device.

[0102] It should be understood, however, that an additional property of the browser is the ability to download and install other applications or plug-ins as needed to support non-markup based content, including images, audio, video, and multipurpose internet mail extensions (MIME) or secure MIME (S/MIME) document formats such as plain text, Acrobat (e.g., “*.pdf” format), Microsoft Word and so forth. Content of these types is can be viewed through the use of these other applications or plug-ins by the micro-gateway 144 or microbrowser 148 , or both 144 and 148 .

[0103] Preferably, the event controller 152 is an event handler. Events to and from the server browser 110 are formatted according to the particular electronic device 104 in use. In the exemplary embodiment, XML event messages and a proprietary protocol are interpreted by the event controller 152 to manage data and events to and from the server browser 110 .

[0104] The DOM store 124 provides a secondary cache of the information content stored on the server browser 110 . The secondary cache preferably resides on the electronic device 104 to reduce the need to pass data between the server and client browsers 110 and 112 , respectfully. The information content that the user desires is transmitted to the client browser 112 from the server browser 110 . In the exemplary embodiment, however, once the information has been transmitted, it is stored for reuse. The information content is retained on the electronic device 104 while it is valid and while there is sufficient space to store it. The information content is stored in a DOM structure according to the W3C definition of an XML document and can be accessed by the microbrowser 148 or other applications on the client browser 112 .

[0105] When the DOM is examined or modified, the event controller 152 preferably delegates the event to the DOM facade 118 . These events include click, blurchange, submit, expand, etc.

[0106] In the case of a click event, the DOM facade 118 preferably examines and executes the content and/or script associated with clicking on a given node. In the case of an bulrchange event, the DOM facade 118 preferably modifies the DOM so it reflects that the user has provided data. In the case of a submit event, the DOM facade 118 preferably examines the existing user input to formulate an appropriate form submission request. In the case of an expand event, the DOM facade 118 preferably delegates to a serializer to server the contents of a given folder to the client browser.

[0107] In cases where a standard browser (cHTML, WML, XHTML, etc.) is used, there is preferably no event controller. The requests from the standard browser are interpreted and translated by the event translator into events that the DOM facade 118 understands.

[0108] An “active” page is a page from the information source that is of higher than normal interest to the user of the client browser 112 . It is given an active status in the cache and retained on the electronic device 14 when it otherwise might have been deleted for space or timing reasons. Where a document has been made part of the “active” cache (either through a push from the server or explicitly requested by the user through a client application such as the micro-browser), the content and any related data for that document can be accessed when the electronic device 104 is out of coverage.

[0109] Preferably, the client browser 112 handles “active” page content submissions separately and can store form data for those submissions to allow repeated attempts to submit that data until either the submission is successful or the user explicitly instructs the client browser application to delete the form data. Delivery of form submission data for the “active” content pages is guaranteed by the storage of the data in the client application browser.

[0110] Further, the client browser 112 retains the context of “active” page submissions and allows the user to access a history of chained interactions with the information source as a series of submissions of data and responses to the submissions. Note that each response can itself require a further submission and in turn generate another response, thus forming the chain. The status of an active submission in progress can also be viewed in the client browser.

[0111] The server browser 110 contains a Push Server which has functionality and interfaces enabling an application or system administrator to push information to the client browser 112 . The pushed information can take the form of simple text alerts, web (multimedia) content from the information source 102 or configuration updates to the client browser 112 including but not limited to enabling or disabling feature options, adding bookmarks, modifying network preferences and changing the client browser's 110 look and feel. In addition to content, the server browser 110 can facilitate a push of updates/upgrades to components of the client browser or an update of the entire client browser application 112 .

[0112] Preferably, the interface (API) to the Push Server will conform to the WAP Push Protocol specified by the WAP Forum. Accordingly, the push initiation may also be via a Multimedia Messaging Service (MMS) Server/Proxy-Relay. As described in that WAP Forum specification [WAP-205-MMSArchOverview-20010425-a] MMS Server is used to provide storage services for the messages while the MMS Proxy-Relay component interacts with the client browser 112 and with other available messaging systems. The MMS Server and MMS Proxy-Relay components may or may not be combined. Preferably, the push interface will be extended to support the ability to push a part of the content from the information source 102 which replaces in-line only that part of the content page as rendered in the client browser 112 which acts as the MMS Client.

[0113] The distributed browser 108 preferably utilizes send and receive events to convey information between the server and client browser 110 and 112 , respectively. Events between these components can be classed as an events message, acknowledgment/negative acknowledgment (ACK/NAK) message, security handshake request/response, and decrypt ACK/NAK message.

[0114] An events message preferably carries information between the server and client browsers 110 and 112 , respectively. An ACK/NAK message is used to confirm or deny receipt of an events message. A security handshake message is used to transport information used by encryption and decryption routines. A decrypt ACK/NAK is used to report success or failure in the security routines.

[0115] The first byte of the messages preferably contains an identifier that uniquely defines which type of message is contained in the data being sent. The 2-byte integral values are always “little endian” or bytes at lower addresses have lower significance.

[0116] FIG. 5 shows the structure of an exemplary events message that is transmitted between the server browser 110 and the microbrowser 148 (i.e., via the network interface 156 and event controller 152 ). The event message may be modified or intercepted by the event controller 152 . The event message includes header identifier, header version number, and the unique message identifier. Additionally, the event message also includes the event type such as response, original, push, or stop. Moreover, event data is included at the end of the events message.

[0117] The event data area of the events message may be compressed and/or encrypted as specified in the header component. When converted to plain text, the data area is defined as having the following exemplary structure:

[0118] <XML Events Message>=<Event Protocol Version><Event Separator><Session ID><Event Separator><XML Events><EOM>

[0119] <Event Protocol Version>=Integer

[0120] <Session ID>=<Server Session ID>|<Server Session ID><integer separator><Client Session ID>

[0121] <Server Session ID>=<Device Type><integer separator><Page ID>

[0122] <Device Type>=Integer (uniquely identifying different devices)

[0123] <Page ID>=Integer

[0124] <Client Session ID>=Integer

[0125] <XML Events>=<Event>|<Event><Event Separator><XMLEvents>

[0126] <Event>=<Event ID><field separator><XML Node><field separator><Attributes>

[0127] <Event ID>=integer (see table below)

[0128] <XML Node>=Integer

[0129] <Attributes>=<value>|<value><value separator><Attributes>

[0130] <value>=ASCII text

[0131] <EOM>=\r\n (0x0D 0x0A)

[0132] <Event Separator>=|

[0133] <Field separator>=*

[0134] <Value separator>={circumflex over ( )}

[0135] <Integer separator>=,

[0136] All events contained within an events message belong to the same session or page of content.

[0137] When there is only a single client browser 112 on the electronic device 104 , the session id information needs only to specify an identifier for the server browser 110 session or content page. When there are multiple client browsers on the electronic device 104 (e.g. multiple browser windows, browser+instant message client, or other combinations), the events message should identify which client browser 112 it is associated with.

[0138] Preferably, the page id is generated on the server browser 110 . When the client browser 112 has no valid server session id to send, a zero will be sent. Zero is not used as a valid session id.

[0139] For any Uniform Resource Locator (URL) data that is contained in an events message, standard URL encoding as is known in the art, is used to ensure that the information content does not include any of the characters special to a proprietary packet format (i.e., “|”, “{circumflex over ( )}”, and “*”). For any XML content contained in an events message, standard HTML encoding, as is known in the art, is used (e.g., where characters can be represented by “&#n;” where n is the ASCII code for that character).

[0140] The node value maps directly to a node in the DOM tree (e.g., output of the QDOM 116 in FIG. 2 ) and signifies the node affected by the event. For some events (e.g. load, error) the node is set to 0, indicating that there is no direct connection to a particular node. Other events (e.g. expand, onblurchange, submit, onclick) have a direct correlation to an element in the QDOM and are targeted to that element by the value set in the events message.

[0141] The following table lists the different events that can be contained within an events message: 1

[0142] 2

[0143] To conserve bandwidth over the communications network 114 between the connectivity manager 36 and the radio interface 156 , an events message may contain more than one event. In one exemplary embodiment, all onblurchange events are stored by the microbrowser 148 until a submit event is generated. At that point they are bundled together into a single events message for transmission to the server browser 110 .

[0144] FIG. 6 shows the structure of an exemplary transmission ACK/NAK message that is transmitted between the radio interface ( 156 of FIG. 4 ) and connectivity ( 132 of FIG. 2 ). An ACK message is preferably used when the underlying communications network 114 does not provide message delivery confirmation to the network interface 156 and connectivity manager 132 . A NAK message signifies that although an events message was received, it could not be processed (e.g. because of low memory conditions).

[0145] FIG. 7 shows the structure of an exemplary message used by the security subsystems of the connectivity manager 132 and the network interface 156 . The security handshake request and security handshake response messages are used to exchange public keys between the connectivity manager 132 and network interface 156 . The security ACK and NAK messages are used to signify successful decryption of events messages that have been encrypted using the shared public keys. Receipt of a security NAK message at any time or a need to encrypt the data in an events message when public keys have not been shared preferably initiate a security handshake request.

[0146] The server browser 110 includes a QDOM 116 . The QDOM 116 utilizes a in-memory representation of an document tree as a single mutable object or creation of a DOM does not require creation of a language object for every node of the tree, whether that language happens to be Java or C++ or another object oriented language.

[0147] The mutability of a QDOM 116 is preferred, because transformations of the DOM tree will be applied, resulting in a new tree structure within the same QDOM Object. The architecture of a QDOM 116 allows these transformations to be performed in an efficient manner with regard to both speed and resources used.

[0148] A QDOM 116 consists of an aggregation of N re-usable buffers that contain arrays of raw bytes. As the QDOM grows, additional re-usable buffers are added, only as needed. Some of the re-usable buffers contain binary information describing the DOM tree structure, tree dependencies, and references to information content data. Other buffers contain the actual content data.

[0149] FIG. 8 shows one exemplary embodiment in which separate QDOM 116 arrays 180 are used for the values representing the following properties of each element node 184 : element name tag 188 , parent node 192 , previous element sibling 196 , next element sibling 200 , first child element 204 , and first attribute 208 . Similarly, each attribute node can be described with the following properties including attribute name tag, attribute value tag, previous attribute sibling, and next attribute sibling. Separate arrays can be stored in the QDOM 116 for attribute data, or it can be overlaid in the same arrays used for element data.

[0150] In another exemplary embodiment, the same information can be stored in structures for each node and attribute. The QDOM 116 contains one or more arrays of each of these structures. The choice of the means of storage depends on the functionality of the programming language employed for the QDOM.

[0151] The actual string names of the tags and attributes of tree elements are replaced by a corresponding value equivalent. A dictionary of the strings and their corresponding value is preferably built up as necessary to deal with a particular set of XML tags. For performance reasons, pre-compiled dictionaries can be used for the well-known markup languages, such as HTML or WML.

[0152] FIG. 9 shows a re-usable content buffer 212 that the QDOM array 180 references when information content that is not well known (such as plain text data) is used. The QDOM array 180 preferably stores the start and end positions of the text in the content buffer 212 . In another exemplary embodiment, the content buffer 212 stores zero terminated strings and the QDOM array 180 stores the start position.

[0153] Preferably, the interface to the QDOM 116 is value based because every node (for example, see 184 in FIG. 8 ) of the tree has a unique value associated with it. All operations on the nodes in the tree that the interface provides can be carried out using that value as a reference to the affected nodes. All comparisons between nodes are also value based, so expensive string comparisons can be avoided.

[0154] Since the underlying structure of the QDOM 116 groups of raw bytes, it can easily and efficiently be serialized to and from permanent storage, thus reducing the amount of random access memory (RAM) memory necessary to support multiple users and multiple documents per user.

[0155] In situations where resources are limited, such as on a PDA, the QDOM 116 structure in the form of DOM store, XMLDocument, and XMLelement ( 124 , 162 , and 164 in FIG. 4 respectfully) can also be used efficiently by the client browser 112 . The QDOM storage is divided into smaller groups that are held in a permanent storage area (e.g., FLASH). Only such groups as are needed for the current operations on the QDOM are retained in or moved to a fast memory area (e.g. RAM). This provides high performance through an efficient use of the data in RAM while still minimizing the actual resource load in use at any one time.

[0156] A QDOM 116 is implemented as a re-usable object, so rather than deleting it and having a “garbage collector” reclaim a space occupied by the document, the QDOM 116 can be easily and efficiently re-initialized and used to store some other XML Document.

[0157] A number of preliminary tests have been taken to determine the time saved using the QDOM 116 as compared to the node-based interface of the standard W3C DOM. The tests show more than 100× improvement over other W3C compliant models.

[0158] The normalizer organizes the DOM tree into tiers or folders under headings that contain related content. The result is a set of hierarchical DOM node collections. The characteristics of font, font size, font color, hue saturation comparison of background and foreground color and Cascading Style Sheet or XSLT properties are used to determine the weight of a text node. The weight is then used to determine whether it will be inserted into a normalized document tree as a parent or child. The parent nodes become folder titles and the child nodes become the folder contents. Thus, higher weight document objects are pushed to the top of the tree so the user can decide whether to “walk” down the branch or not.

[0159] The normalizer dynamically streamlines and folderized the content automatically or via predefined additional rules to achieve automatically an experience similar to reading a newspaper. The normalizer including the template normalizer and meta-tags allow the content source to be redefined once for all networks and device types. The alternative technologies in the industry are large cycle time, re-development of the content, often specific to one or more of the following: each device ergonomics, or a particular client-only browser, or a particular network type.

[0160] The goal to normalizing is to adapt desktop focus web content to handheld browsers. This requires filtering unsupported content, dropping unneeded content, reordering and partitioning content to improve navigation and application flow for display on a limited device. Some of the functions to normalization are folderize/partition content, drop content not required on a handheld device, reorder content, provide prompts/names to input elements

[0161] The normalization process can utilize a weighted heuristic and pattern recognition to create a the contextual relationship of with nodes in the source tree. The output from the normalization process is a hierarchical content tree. Preferably, the normalized tree is not specific to a particular presentation language. Therefore it can be transcoded for display by any type of client browser.

[0162] Content collapsing rules in the automatic normalizer utilize the previous page loaded to determine if similar constructs exist in a page which can be collapsed into folders or selectable input elements on subsequent loads. This is performed by comparing the previous page loaded with the current page. The trees of the documents are compared to determine if similar fragments (list of links, table, image) exist. The similar fragments of the tree are collapsed into folders or select input elements. The effect is to conserve display space on the device.

[0163] Electronic devices can have limited display characteristics such as display size, font types, color etc. Most web content is tailored for display on desktop browsers which not only suppose a large screen, but also support a rich set of fonts, colors, and formatting constructs such as tables and frames. The normalizer adapts existing information content for display on the electronic device 104 . The normalizer 124 includes an automatic normalizer 80 and template normalizer 84 .

[0164] Referring back to FIG. 2 , the automatic normalizer 80 in the normalizer 124 maintains the context of the information content before taking the electronic device 104 specifics into account. The automatic normalization process does this by organizing the information content into folders. The result of this approach is that sets of nested folders are created which the user can “walk” the information content on the electronic device 104 . The titles of the folders are sent to the electronic device 104 first and the user can determine if the contents of particular folders are of interest. This not only increases usability in terms of reduced content to scroll through for the user and time spent scrolling through the page, it also optimizes wireless bandwidth utilization because less data is sent to the electronic device 104 .

[0165] It should be noted that while the exemplary embodiments of the normalizer processes concentrate on the normalization of HTML content, including that generated by scripting technologies such as JavaScript, these same processes can be applied to other markup content. It is well suited to any XML content.

[0166] The automatic normalization process traverses a DOM tree from the QDOM 116 40 and creates a new, normalized tree. Preferably, the original DOM is transformed rather than copied, so that it becomes the normalized tree itself. This provides both efficient performance and efficient memory utilization.

[0167] The normalization process begins with the root node of the document and traverses the tree along a depth first path to maintain context at all times.

[0168] If a node is the beginning of a table, a table pattern recognition process is preferably executed. The entire table is weighted and pattern recognition criteria are compared to determine if the table matches a defined pattern. The table recognition criteria define a profile for different data table types. Each cell in the criteria is defined to be either greater than, less than or equal to a root table weight, a “don't care” or defined to contain certain nodes such as anchors or images. The root table weight can be derived from any cell in the table such as the cell at position row 0, column 0 or can be derived outside the context of the table. These criteria define the pattern that is attempting to be matched. If a pattern is recognized, the table cells are formatted corresponding to that pattern. If a pattern cannot be recognized, the weighted node processing continues.

[0169] The major part of the weighted node process is the maintenance of a weighted node stack. The first element of that stack is always the “DOCUMENT” itself, having by default the highest possible weight. The normalization process takes the next node from the DOM tree. The node is first filtered to determine if it has an effect on weighting or presentation. If the node is not significant it is preferably dropped. Nodes such as the HTML tag in HTML are not significant since the tag has no effect on presentation. Next it is determined whether the node is a weighting node or a content node. Weighting nodes are nodes that affect the display of rendered content such as a bold or heading format tag. Some weighted tags may have a negative weight that allows nesting of the tags and emulates a hierarchy of nodes weights such as nested list items. Content nodes are nodes such as text nodes, input nodes, and image nodes.

[0170] When a weighted node is encountered, the node weight is added to the accumulated weight. When a content node is encountered it is assigned the accumulated weight and becomes a weighted node. The weighted node finds its position on the weighted node stack by finding the lightest element on the stack with a weight greater than his (node's parent). Stack nodes from that point on are preferably deleted from the stack. The new weighted node becomes a child node for that parent. When the node goes out of scope (e.g. if a TABLE is ended), the normalization process checks the weighted node stack to remove all nodes that belonged to the expired scope of influence.

[0171] For example, if the node on the weighted node stack is part of a table and the table scope of influence has expired, then that node is removed from the weighted node stack. However, if that node belongs to more than one scope of influence (e.g. it is part of one table nested inside another table), all scopes of influences are checked against that node and it is removed preferably when they are all expired. When the inner table ends, node stays until it replaced by a heavier node or the outer table ends.

[0172] The template normalizer 84 is a tool for recognizing patterns within a document through a DOM tree and applying changes to those patterns as specified in the template syntax. Preferably the template normalizer 84 is part of a larger process of normalizing all documents. One step of the larger process is an attempt to match and apply templates where possible.

[0173] The template normalizer 84 preferably handles numerous variations of the same document as dictated by the application logic that produces it. For example, if a certain data table could have various numbers of columns and rows, or even not be present in the document at all, the template normalizer 84 is preferably still capable of dealing with those variations.

[0174] The template normalizer 84 is capable of recognizing an document from a set of potential documents that could be produced by the application. For example, if the application produces two completely different documents depending on whether a user is logged on or not, a single template could still recognize the outcome and apply its changes to either one.

[0175] The template normalizer 84 is also capable of recognizing a change in the overall structure of the document to determine when its rules are not applicable any longer. In that case, it will not attempt to apply the changes, but will convey the document to an automatic normalizer 80 .

[0176] The template normalizer 84 uses a regular expression pattern-matching machine as applicable to DOM trees. The syntax of a template is strict XML as described by the World Wide Web Consortium (www.w3c.org) and includes a number of proprietary regular expression tags and attributes that describe how the template normalizer 84 should match and modify original content.

[0177] Tags:

[0178] <xgrp> equivalent to a bracket in Regular Expressions

[0179] <xany> equivalent to a wild card in Regular expressions

[0180] <xalt> equivalent to ‘or’ in Regular expressions

[0181] <xadd> signifies the addition of contained markup

[0182] <xnone> equivalent to “empty” in Regular Expressions

[0183] Attributes:

[0184] “xtimes” the number of times to apply a recurring pattern

[0185] “xtitle” specifies a new title for a matched pattern

[0186] “xid” specifies a name of an XML node

[0187] “xparent” re-parent an XML node to a specified element

[0188] “xdrop” delete a node from the tree

[0189] “xformat” produce a formatting attribute for an input field

[0190] “xaction” apply a user-specified algorithm to the branch of a tree

[0191] The normalization process preferably scans a dictionary of templates and an initial comparison is made based on a URL specified for the template and the URL of a document to be processed. If the URLs match, then the template normalization process begins.

[0192] The template normalizer 84 deals with a document or XML document in two steps: first it uses the regular expression pattern-matching machine to impose itself over a document and attempts to match the template to the document content. The match is performed using the regular expression tags in the template to apply standard regular expression algorithms. If that process fails, the changes specified by the template are not applied, and the document is conveyed to the automatic normalizer 80 .

[0193] If the match process succeeds, the template normalizer 84 will apply changes as specified by the attributes of the matched regular expression elements. Changes include dropping nodes, creation of new folders or tiers, re-parenting nodes, assigning new titles to nodes, etc.

[0194] During the application of the changes, the template normalizer 84 can use a complex state variable syntax to refer to the parts of the document. These variables can be set as pointers to nodes in the DOM or counters. Resolution of a variable expression starts with the inner most expression and is processed outward. This is similar to list processing in the LISP programming language. The inner resolutions are used to resolve subsequent resolutions.

[0195] Where a counter is used in a variable expression, the variable will be resolved using the current value of the counter.

RESOLUTION EXAMPLE

[0196] If $z=a and $ya=“data” the expression $(y($z)) would be resolved to $(y$(z))=$ya=“data”.

[0197] $z gets resolved to a and this creates the expression $ya which is then resolved to “data”.

COUNTER EXAMPLE

[0198] If xcounter=“x” and the first iteration of an Xgrp is occurring, then the expression $a($x) will be resolved to

[0199] $al.

[0200] If a variable is used in the context of an Xtitle attribute, the value for the variable is derived from the text value of the DOM node that is referenced by the variable.

[0201] If the variable is used in the context of an xparent, then the variable is resolved to a DOM node to which to move the referring node as a child.

[0202] The xid attribute is used to set the value of a variable to the DOM node.

[0203] Template normalization involves matching a template DOM tree with an input DOM tree and applying changes to the input DOM tree. The automatic normalization algorithms may be called during the apply step of template normalization where specified by the xaction attribute.

[0204] With integration of the automatic normalization algorithms, a template can be utilized to drop and reorder content while calling the automatic normalization algorithms to partition the