System and method for processing extensible markup language (XML) documents

ES 2 326 073 T3

DESCRIPTION

System and method for handling or processing documents in Extensible Labeling Language (XML).

The invention relates generally to wireless communications and mobile wireless communication devices. In particular, the invention relates to the general support of Extensible Markup Language (XML) for wireless communication devices.

XML is fast becoming one of the most common schemes for exchanging data between different computer systems. For transfer over wireless communication systems or other narrowband communication systems, an efficient encoding scheme is required to reduce the size of XML documents for transmission. Perhaps the most popular encoding scheme for preparing XML documents for wireless transmission is Wireless Application Protocol (WAP) Binary XML, or WBXML. WBXML relies on token tables or codebooks to encode and decode the XML. The WBXML specification uses the term "code page" to mean a set of token-to-tag equivalences. A code page can have no more than 256 entries, so there can be multiple code pages. The term "codebook" is used here to indicate a set of one or more code pages. A codebook is therefore a set of lookup tables that map XML tags or attributes and their corresponding token equivalents.

Known XML solutions for wireless communication systems use two copies of token tables. One copy is typically embedded in an information gateway, server, or other information source for transcoding or signaling from XML to WBXML, while another copy is embedded in the mobile communication device side of software application code, which parses syntactically and / or decodes the flagged WBXML. In fact, the most popular WBXML client software applications have the encoding scheme embedded in the parser. This works well if the encoding system is well known. However, for new dialects of XML, there is no known encoding scheme. A software application developer or designer who wants to use a new XML dialect must invent an encoding scheme and / or create both a transcoder to do the encoding and a parser for the client software application.

In such systems, a mobile communication device or possibly software applications installed on such a device must know how an XML document has been encoded, that is, which token table was used, by a WBXML encoder in order to process a received WBXML document. . This means that an XML application on mobile communication devices is typically configured for a specific type of XML corresponding to an encoding scheme used on a server or gateway. When an XML processor is implanted in the computer software code for example, the coding scheme is typically embedded in the software code, such that each time a new type of XML document is received, both the software code server and mobile communication device software code must be modified accordingly, which is costly, time-consuming, and error-prone, particularly if different entities are responsible for server operations and mobile communication devices and applications. Also, if a WBXML parser receives a WBXML document generated from an XML document type that has never been previously processed and the codebook for that particular XML document type is not embedded in the parser or decoder or a mobile communication device in which the decoder or parser is implanted, then the device and any software applications on the device are unable to handle the WBXML document.

A publication by M.Girardot et al. Entitled "Millau: An Coding Format for Efficient Representation and Interchange of XML on the Web", ISDN Computer Networks and Systems, North Holland Publishing, Amsterdam, NL, vol. 33, n ° 1-6, June 2000, pages 747 to 765 describes a system for transcoding and exchanging WBXML documents between a wireless mobile device and a data server, which allows the encoding scheme and the encoded content to be transmitted separately and to generate the code spaces. However, this publication does not consider the possibility of generating the encoding / decoding scheme on demand, at encoding / decoding time, when the scheme is not locally available.

Other publications that describe an issue relevant to the present invention include Sperberg-McQueen CM et al., "Max HTML: A Manifesto for Adding SGML Intelligence to the World-Wide-Web," ISDN Computer Networks and Systems, North Holland Publishing , Amsterdam, NL, vol. 28, n ° 1, December 1, 1995 pages 3 to 11, "Creation of App Cache copies in Plugin Java" August 2000 identified by the reference XP002256443 and EP0768807. However, none of these references considers the possibility of generating in a system comprising a wireless mobile device and a data server that exchanges WBXML documents, an encoding / decoding scheme for XML documents on demand, at the moment of encoding / decoding. , when the schema is not locally available.

WO98 / 41377 describes a method for transcoding data transmitted between computers. The method comprises a network client requesting a URL object. To get the requested URL object, it is checked against a client-side cache, followed by a server-side cache, and if the object is not

ES 2 326 073 T3 in the server-side cache, the object is requested from the Internet. If the object is not located on the Internet, an error page is returned.

Thus, there remains a need for a system and method for universal XML support in mobile communication devices that is not restricted to any particular encoding scheme so that enabled XML applications are independent of a particular XML type and your encoding scheme.

There remains a related need for a system and method for handling or processing XML documents of any kind.

There remains another need for a system and method to support XML on mobile communication devices that support new XML document types without the need to change the software code on the devices.

Generalities

According to a first main aspect of the invention, a data server for processing Extensible Markup Language "XML" documents has been provided, comprising: a codebook cache for storing a plurality of codebooks for transcoding XML documents, each codebook comprising a set of lookup tables that match XML tags or attributes and their corresponding token equivalents; a codebook system that includes the codebook cache and is configured to receive a request for a requested codebook from a data server or wireless mobile communication device and to determine whether the requested codebook is stored in the codebook cache; and a codebook generator configured to generate the requested codebook using an embedded or external source of XML definitions of said XML documents when the requested codebook is not stored in the codebook cache; wherein the codebook system is further configured to transmit the requested codebook in response to the request.

According to a second main aspect of the invention, there has been provided a method for processing Extensible Markup Language "XML" documents in a data server, comprising the operations of: receiving a document in the data server from a source of information; determine if a codebook for transcoding the document is stored in a codebook system coupled to the data server, each codebook comprising a set of lookup tables that establish correspondence between XML tags or attributes and their corresponding token equivalents ; generating the codebook using an embedded or external source of XML definitions when the codebook for transcoding the document is not stored in the codebook system, and transcoding the document using the codebook to generate a transcoded document.

According to a third main aspect of the invention, a wireless mobile communication device has been provided for processing Extensible Markup Language "XML" documents for transmission over a wireless network, the device comprising: means for generating a document on the wireless mobile communication device; means for determining whether the document is associated with a referenced document definition; and means, operable if the document is associated with a referenced definition, to: determine whether a codebook for transcoding XML documents for the referenced definition is stored in a codebook cache; retrieving the codebook from the codebook cache if the codebook is stored in the codebook cache; and requesting the codebook from the data server of the first main aspect and receiving the codebook from the data server if the codebook is not stored in the codebook cache, wherein the codebook comprises a set of lookup tables that map XML tags or attributes to their corresponding token equivalents.

According to a fourth main aspect of the invention, a method of processing Extensible Markup Language "XML" documents in a wireless mobile communication device for transmission over a wireless network has been provided, the method comprising the operations of: generating a document on the mobile wireless communication device; determining if the document is associated with a referenced document definition; and, if the document is associated with a referenced definition, determining whether a codebook for transcoding XML documents for the referenced definition is stored in a codebook cache; retrieving the codebook from the codebook cache if the codebook is stored in the codebook cache; requesting the codebook from the data server of the first main aspect and receiving the codebook from the data server if the codebook is not stored in the codebook cache, wherein the codebook comprises a set of lookup tables that map XML tags or attributes to their corresponding token equivalents.

According to a fifth main aspect of the invention, there has been provided an Extensible Markup Language "XML" document processing system comprising a mobile wireless communication device and a data server, the mobile wireless communication device comprising: a parser; Y

ES 2 326 073 T3 a codebook system accessible by the parser, the codebook system comprising a cache memory intended to store codebooks used by the parser to transcode a document, the parser being intended for codes to search the cache for a requested codebook, and further requesting the codebook from the data server when the codebook is not present in the cache of the device; and the data server comprising: a transcoder; and a codebook generator for building codebooks using an embedded or external source of XML definitions of said XML documents to allow the data server to transcode documents, the codebook generator being accessible by a system of books of data server codes; wherein the codebook system of the data server is accessible by both the transcoder and the codebook system of the mobile wireless communication device, said codebook system of the data server comprising a cache memory for store the codebooks used by the transcoding system to transcode documents on the data server, the data server codebook system being intended to search the cache for a requested codebook, and further request a codebook from the codebook generator when the requested codebook is not present in the cache and wherein the codebook comprises a set of lookup tables that map XML tags or attributes and their corresponding token equivalents.

According to a sixth main aspect of the invention, a method has been created for processing XML Extensible Markup Language documents in a system comprising a mobile wireless communication device and a data server, the method comprising the operations of: on the mobile wireless communication device: receiving a processed document from the data server, in which the processed document is generated by the data server by transcoding a document using a codebook, the codebook comprising a lookup table that matches labels or attributes of XML and its corresponding token equivalents; determining if the codebook used to transcode the processed document is stored in the mobile wireless communication device; requesting the codebook from the data server when the codebook is not stored on the mobile wireless communication device; receiving the codebook from the data server; and transcoding the processed document using the codebook to retrieve the document; and at the data server: receiving a request for the codebook from the mobile wireless communication device; determining if the codebook is stored in a codebook system coupled to the data server; generating the codebook using an embedded or external source of XML definitions of said XML documents when the codebook for transcoding the document is not stored in the codebook system; and transcoding the document using the codebook to generate a processed document for transmission to the mobile wireless communication device.

Other features of the invention will be described or will become apparent in the course of the following detailed description.

Brief description of the drawings

Fig. 1 is a block diagram of a communication system that provides access to an information source from a mobile wireless communication device.

Fig. 2 is a block diagram illustrating internal elements of mobile device 12 and data server 18 of FIG. 1.

Fig. 3 is a signal flow diagram illustrating the operation of a data server 18 in response to a connection request from a mobile device 12.

Fig. 4 is a signal flow diagram showing the processing of a document by a mobile device 12.

Fig. 5 is a signal flow diagram illustrating data server operations related to processing of the mobile device shown in FIG. Four.

Fig. 6 is a flow chart illustrating the data server handling of a received XML document.

Fig. 7 is a flow chart showing the processing of a transcoded document received by a mobile device.

Fig. 8 is a signal flow diagram illustrating data server operations associated with a codebook request in accordance with another aspect of the invention.

Fig. 9 is a flow chart showing data server processing of a codebook request in accordance with the embodiment of the invention shown in FIG. 8.

Fig. 10 is a flow chart illustrating exemplary data server processing of a received XML document to support the codebook request scheme in FIGS. 8 and 9.

ES 2 326 073 T3

Fig. 11 is a signal flow diagram showing the creation of a WBXML document on a mobile device.

Fig. 12 is a signal flow diagram showing the processing of a WBXML document received from a mobile device by a data server.

Fig. 13 is a flow chart depicting mobile device handling of a generated XML document.

Fig. 14 is a flow chart illustrating the handling of a WBXML document received by a data server.

Fig. 15 is a block diagram illustrating a mobile device in which systems and methods according to the invention could be practiced.

Description of preferred embodiments

Fig. 1 is a block diagram of a communication system that provides access to an information source from a mobile wireless communication device. In fig. 1, the system 10 includes a mobile wireless communication device 12, a wireless communication network 14, a wireless network gateway 15, a wide area network (WAN) 16, a data server 18, and an information source 20 .

Mobile device 12 is a mobile wireless communication device adapted to operate within a wireless communication network 14, such as a two-way communication device having at least data and possibly voice communication capabilities, for example. Depending on the functionality provided by the mobile 12, the mobile device may be a data messaging device, two-way pager, a cell phone with data messaging capabilities, a wireless Internet device, or a data communication device ( with or without telephone capabilities), but is referred to in the following primarily as a “mobile device”. The particular design of a communication subsystem (not shown) within mobile device 12 will depend on the communication network 14 in which mobile device 12 is intended to operate. For example, a mobile device 12 intended for a North American market may include a communication subsystem designed to operate within the Mobitex ™ mobile communication system or the DataTAC ™ mobile communication system, while a mobile device 12 intended for use in Europe it may incorporate a General Packet Radio Communication Service (GPRS) communication subsystem. Other types of mobile devices and networks are also considered. The systems and methods described herein can be implemented in conjunction with virtually any wireless network 14 and mobile device 12.

The wireless network gateway 15 shown in FIG. 1 provides an interface between the wireless network 14 and a WAN 16, which may, for example, be the Internet. Such functions as access by the mobile device, data conversion between WAN protocols and wireless network protocols, storing and sending data to and from the mobile device 12, and other interface functions can be performed by the network gateway 15. wireless.

It is possible that a data server 18 could be hosted by a carrier or network operator associated with the wireless network 14. In this case, the connection between the data server 18 and the wireless network gateway 15 could use a private network of the bearer instead of WAN 16. WAN 16 can then be used to communicate between data server 18 and information source 20. This hosted or public implementation of a data server 18 is a reasonable alternative approach to the system 10 shown in FIG. 1.

Data server 18 is a system that effectively provides mobile device 12 with access to information source 20. Through data server 18, mobile device 12 can access any information source 20, such as the Internet. or web server, which can communicate with data server 18. The information source 20 therefore does not require special applications or protocol support for wireless network communications, since it communicates with the data server 18, not directly with the mobile device 12. Although it has been shown in fig. 1 As a direct connection, the data server 18 and the information source 20 can possibly communicate over a network such as a local area network (LAN) or WAN, including the Internet. In alternative embodiments, the functions of the data server 18 may be incorporated into the wireless network gateway 15 or information source 20. Other embodiments of a wireless network gateway 15, data server 18, and information source 20 may also be apparent to those skilled in the art and as such are considered to be within the scope of the present invention.

Wireless networks and the Internet use similar access schemes, in which communication equipment such as mobile device 12 in a wireless network or computers connected to the Internet such as data server 18 and possibly information source 20 are identified by numerical addresses. For example, mobile device 12 would be identified on the Mobitex network using a Mobitex Access Number (MAN), and public Internet nodes are identified using an Internet Protocol (IP) address scheme. However, the difference between wireless network and Internet transport mechanisms typically precludes direct communication between information sources 20, the vast majority of which are Internet-based, and mobile devices such as the mobile device 12. Internet and other WAN communication protocols can also be

ES 2 326 073 T3 "talkers", involving several exchanges to establish communications between a sender and a receiver and relatively large amounts of overhead, which is undesirable in wireless network communications. Furthermore, content provided by information sources such as 20 is widely targeted for transmissions over wired communication networks. As described above, XML documents are relatively large and should be compressed for transmission over wireless communication channels. Data server 18 bridges the gap between Internet-based information sources 20 and possibly other information sources 20 and wireless network 14 with associated mobile device 12. The functions of the data server 18 may include address mapping, content transformation and verification, and protocol mapping and optimization, for example.

Although mobile device 12, wireless network 14, and gateway 15 are shown in FIG. 1, the invention is also applicable to other types of mobile devices that can request or otherwise obtain XML documents. Processing resources and communication link bandwidth tend not to be as limited for desktop computer systems and wired communication links as well as for mobile devices and wireless communication networks. However, transcoding XML documents as described here not only reduces the size of the data, but also makes it a more efficient parser and easier to write. The reduced data size provides means for faster transfer of XML documents over wired connections, while simpler and more efficient parsers make similar desktop computer system software applications and any other data server client applications. easier to develop. Thus, it should be appreciated that the systems and methods described herein can be implemented in conjunction with wired or wireless communication systems and devices.

Turning now to fig. 2, an embodiment of the invention will be described below. Fig. 2 is a block diagram illustrating internal elements of mobile device 12 and data server 18 of FIG. 1. As shown in FIG. 2, the data server 18 included a protocol translator 24, a connection handler 26,1 transcoding system 28, a codebook system 30, a codebook servlet 32, and a codebook generator 34 . Mobile device 12 includes a communication subsystem 36, a software application 38, a WBXML parser 40, an application handler 42, and a codebook system 44.

Although not shown in FIG. 2, the wireless network 14, the wireless network gateway 15, and the WAN 16 shown in FIG. 1, as well as any other intervening communication links and networks through which mobile device 12 and data server 18 communicate, have generally been designed as wireless transport 22. Those skilled in the art will appreciate that wireless transport 22 is intended to represent any system that provides communication between mobile device 12, operating within a wireless communication network, and data server 18, over one or more links. or wired or wireless communication networks. It should therefore be apparent that the present invention is in no way limited to a communication system such as system 10 in FIG. 1. The systems and methods described here do not depend on any of the particular communication networks or protocols.

At data server 18, protocol translator 24 performs any necessary translation between protocols used for communications with mobile device 12 through wireless transport 22 over a link 35 and protocols used for communications with information source 20 through communication link 21. In a considered embodiment of the invention, data server 18 communicates with wireless transport 22 over link 35 using the so-called IP Proxy Protocol (IPPP), a proprietary protocol developed by the owner of the present application, while communicating with information sources you can use Hypertext Transfer Protocol (HTTP) or Transmission Control Protocol (TCP), for example. If the same protocols are used between data server 18 and wireless transport 22 and between data server 18 and information source 20, or the functions of data server 18 are implemented in information source 20, then the protocol translator 24 may not be required.

Fig. 2 shows only a connection handler 26, communication link 21 and information source 20. In an integrated system where data server 18 is associated with information source 20, when information source 20 provides data access and remote transcoding services, for example, connection 21 is internal to the embedded system. However, in other embodiments, the connection handler 26 and possibly other connection handlers (not shown) for different types of connections allow the data server 18 to simultaneously handle and process the content of different sources of information, including sources based on Internet.

Connection handlers such as 26 are intermediate objects that have the ability to handle content from incoming and outgoing connections to a data server 18. The particular connection handler or handlers on a data server 18 can be replaced and preferably customized, or additional handlers can preferably be added to a data server 18 when necessary. A connection handler can optimize not only the information content, but also a communication protocol. For example some requests that would normally be sent to mobile device 12 (such as a request for a password) can be resolved by connection handler 26. This case of a protocol optimization can tailor so-called "talkers" protocols to be more wireless friendly by reducing the amounts of traffic sent over a wireless transport 22 to a mobile device 12, thereby reducing the effects of wireless latency and restrictions. bandwidth of the wireless network.

ES 2 326 073 T3

In the case of a desktop computer system (not shown) instead of mobile device 12, a gateway such as an Internet Service Provider (ISP) system or an Application Service Provider (ASP) system could providing an interface to the data server 18. When a data server supports both wired and wireless clients, different transports and protocol translators could be implemented for different types of clients.

Outgoing connections are made from a mobile device 12 in order to send data and receive data from Internet nodes, for example. Data server 18 can receive connection requests from mobile device 12 using a particular protocol, such as the proprietary IPPP protocol mentioned above, although other protocols could also be used. Data server 18 then establishes a connection to the Internet, in accordance with the protocol and routing information provided by mobile device 12 in the connection request, and translates and maps that connection to start sending data on both. addresses. A filtering or transcoding process in transcoding system 28 is invoked by connection handler 26 whenever necessary, based, for example, on the type of content that is passed over the connection. Such outbound connections and the operation of data server 18 and mobile device 12 will be described in greater detail below, in the context of web browser operations.

Incoming connections are used, for example, to implement a data push model. In this model, the mobile device 12 has sent information without having issued requests to fetch the information, as in the case with outgoing connections. As briefly described above, a mobile device 12 may exist in a different network domain than the nodes on the Internet. The data server 18 is responsible for saving the Internet and wireless domains. Thus, the data server 18 requires certain routing information to route the traffic to the particular mobile device 12. In a push operation, at least some of this routing information must be provided by the Internet node, such as the information source 20, which issues a request to establish an incoming connection. Data server 18 can convert commonly known access schemes such as email or IP numbers into the appropriate wireless network address of an intended recipient mobile device.

The connection handles in a data server 18 can be stream-based objects. When an outgoing or incoming connection is requested, a virtual carried stream is established between the mobile device 12 and the appropriate connection handler 26. The connection handler 26 will be installed and initiated to process the content for the established connection. Loading the connection handler 26 is based on a connection request, which preferably contains a reference to a connection handler name that may imply the type of traffic that would go through the virtual carried stream and the position of the connection handler 26 which should be loaded by data server 18 if it is not already loaded. The functions of the connection handler such as 26 include mapping the Internet or other source-side information connections and mobile device connections, sending traffic between these connections, and loading and invoking the appropriate transcoders on information destined for the mobile device. 12.

Each connection is preferably associated with an instance of a connection handler 26. This is true even for a connection that does not require the content to be processed by the data server 18, for example, when the content received from an information source 20 it has already been formatted for transmission over wireless transport 22. This type of connection handler sends the content back and forth without making any kind of modification to the content, even though it can make modifications to the protocol. For clarity, those skilled in the art will appreciate the distinction between the data or content (that the mobile device requested or is being sent) and the protocol (the "wrappers" and conversions required to deliver the data).

Connection handlers are also responsible for loading and executing the appropriate content filters or transcoders, to convert an XML document to WBXML, for example. In this example, if information source 20 returns an XML document in response to a request from connection handler 26, then connection handler 26 invokes an XML to WBXML transcoder (not shown) in transcoding system 28. As described in more detail below, an XML to WBXML transcoder in transcoding system 28 converts XML content to WBXML content by replacing XML tags and attributes with WBXML tokens taken as specified in a codebook. The resulting WBXML content is then sent by connection handler 26, through protocol translator 24 if necessary, to mobile device 12. WBXML encoded content is smaller in size and therefore can be more efficiently transmitted over a wireless network.

For previously processed XML types, the codebooks are preferably stored in a data memory or cache 31 in the codebook system 30 and can subsequently be accessed by the XML to WBXML transcoder in the transcoding system 28. . The codebook cache 31 may reside in a memory component such as a Random Access Memory (RAM), a hard disk drive, or other memory into which codebook data can be written. In order to conserve memory space, a least recently used replacement (LRU) scheme or other memory management scheme may be used for the codebook cache 31 by the codebook system 30, thereby that the most frequently used codebooks are held in cache 31. Codebooks that are used particularly often can also be marked or designed for permanent storage, or stored in another data memory or memory element. Alternatively, such codebooks that are

ES 2 326 073 T3 expected to be frequently used can instead be generated using the codebook generator 34 and stored, in a permanent codebook cache (not shown), implanted, for example, in a Read Only Memory (ROM), to ensure that such codebooks are available to the data server 18 and are not erased or overwritten.

The codebook generator 34 can be used to build a codebook for any XML document that has an external definition referenced, such as a SyncML message for example, that has a MIME type registered with the World Wide Web Consortium (W3C). ) and has a corresponding publicly available codebook. The codebook generator 34, the external XML definitions 23 that define the XML grammar for an XML document, and the retrieval of such external definitions 23 via the connection 25 are described in more detail below. The codebook servlet 32 ​​handles codebook requests from mobile devices such as 12 and is also described below.

In mobile device 12, communication subsystem 36 includes components associated with communication functions of mobile device 12, such as one or more antennas, a receiver, a transmitter, and related circuits and modules (not shown). Communication subsystem 36 may be different on different types of mobile devices, and is dependent on the particular wireless transport 22 that mobile device 12 is configured to operate with.

One or more software applications 38 may be installed on mobile device 12, including, for example, a messaging application, a browser, a data synchronization application, a calendar application, a to-do list application, and a calculator. Some of these software applications, a messaging application, for example, may involve communication functions, while others may be "local" functions, using user interfaces resident on the mobile device (not shown) to receive inputs and provide outputs. . As the present invention is applicable to mobile devices such as 12, receiving information content from remote information sources such as 20, exemplary software application 38 is displayed with a link to communication subsystem 36, through the parser of WBXML 40. In this exemplary mobile device 12, a request for information, including for example a Uniform Resource Positioner (URL) is passed to parser 40 by software application 38 or its associated application handler 42 when the information is to be downloaded. to the mobile device 12 from a remote location. Software application 38 is thereby enabled to receive and possibly send information via communication subsystem 36. It should be noted that other software applications (not shown) may also interact with the communication subsystem 36, and the software application 38 may interact with other components of the mobile device, including, for example, a mobile device keyboard, a display screen. presentation, memory elements, other input or output components, and even other software applications.

The WBXML parser 40 parses the WBXML content such that any WBXML tokens are applied appropriately and the content can be handled by the connection handler 42 instead of the software application 36. Two types of parsers are available for parsing XML documents: Event-based parsers and tree-based parsers. An event-based parser is faster and consumes less memory than a tree-based parser and may thus be more suitable for mobile devices. An event-based parser reports event analysis directly to software application 38 through callback methods. Software applications using an event-based parser 40 implement parser event handlers, such as application handler 42, to receive parsing events. The application handler 42 is a set of application-specific callbacks that the parser invokes in response to data in a received WBXML document.

The codebook cache 45 in the mobile device codebook system 44, like the codebook cache 31 in the data server 18, can be implanted in a RAM or other data storage where new Codebooks can be written and from which previously stored codebooks can be retrieved. An LRU replacement scheme or other memory management scheme can be used to limit the size of the codebook cache. As described above, particular codebooks, especially those most frequently used or expected to be frequently used, may be designed for permanent storage in the codebook cache or stored in a codebook cache. different mobile device (not shown).

When the WBXML content is received by the mobile device 12, the WBXML parser 40 is invoked to parse the received WBXML content. The parser 40 requests the codebook from the codebook system 44. If the WBXML document is of a known or previously processed type and its corresponding codebook is stored in the codebook cache 45, then the codebook is returned to the parser 40 by the codebook system 44 and used to parse the received WBXML document. If the WBXML document is of a type for which no codebook is available from the codebook cache 45, then according to an aspect of the invention described in more detail below, the codebook is requested from the server. of data 18 by the codebook system 44, stored in the codebook cache 45, and then returned to the parser 40 and used to parse the WBXML document. In one embodiment of the invention, the mobile device codebook cache 45 initially contains only "permanent" codebooks. If there is, and the system 44 of books

ES 2 326 073 T3 codes requests any other code books from data server 18 when required. Depending on the type of software application 38 and its corresponding application handler 42, the application handler 42 may request a codebook from the mobile device's codebook system 44 and transcode elements of the received WBXML document to XML. Thus, parser 40 and application handler 42 effectively comprise a transcoding system in mobile device 12, configured to parse and encode received WBXML documents to retrieve original XML documents. The transcoding system may include only parser 40, when parser 40 performs both parser and transcoding, or both parser 40 and application handler 42, when application handler 42 performs transcoding. The mobile device's handling of the received WBXML content is described in detail below.

As shown in FIG. 2, codebook requests can be made by mobile device 12 and codebooks can be returned to mobile device 12 by data server 18 over a different link 37 and using a different protocol than those used for requests for information and document transfers. The exemplary codebook request and transfer link 37 shown in FIG. 2 and the communication protocol used therein provides means for communication directly with the codebook servlet 32 ​​on the data server 18 and thus does not require translation of the protocol by the protocol translator 24. In alternative embodiments however, the requests and codebook transfers can be performed through protocol translator 24.

The operation of the system shown in fig. 2 will be described in more detail below. Fig. 3 is a signal flow diagram illustrating the operation of a data server 18 in response to a connection request from a mobile device 12. As described above, mobile device 12 can communicate with data server 18 using a different protocol than the protocol used between data server 18 and information source 20, such as proprietary IPPP. In such arrangements, although the connection request conforms to a particular protocol, the request may specify a particular connection type or connection handler associated with a different protocol. Therefore, when information is requested from an information source 20 by the data server 18 via HTTP, for example, a request sent from a mobile device 12 could be an HTTP request, or a request that conforms to another protocol but specifies HTTP or an HTTP connection handler and is thus interpreted by the data server 18 as an HTTP request. Protocol translator 24 translates requests from mobile device 12 whenever necessary.

It will be apparent that fig. 3 shows only the elements of the data server 18 directly involved in an information request and response operation. The codebook servlet 32 ​​is involved in the codebook request management and thus is not shown in FIG. 3 to avoid congestion in the drawing.

In fig. 3, a request from the mobile device 12 is received by the data server 18 and translated if necessary into a protocol used for communication between the data server 18 and the information source 20. As shown, the request from the mobile device 12 specifies the content type accepted in response to the request, WBXML in the example of FIG. 3. If the request from mobile device 12 is an HTTP "get" request, for example, then the WBXML can be specified as a MIME type in an accept type field in a typical HTTP request header. The protocol translator 24 invokes the appropriate connection handler 26 and sends the possibly translated request to the connection handler 26. For an HTTP request or a request that specifies an HTTP connection or an HTTP connection handler, the invoked connection handler 26 is an HTTP connection handler. Connection handler 26 then sends a request to information source 20 via connection 21 (FIG. 2), which may possibly be a direct connection or one or more network connections. Information source 20 can, for example, be a network server or other system configured to be accessible via the Internet.

In fig. 3, the mobile device 12 specifies the WBXML as an accepted content type. However, data server 18 may transcode received XML content to WBXML content accepted by mobile device 12 and may thereby include XML instead of, or possibly in addition to, WBXML as an accepted content type in the submitted request. to the information source 20. In the example shown in FIG. 3, the request sent from the data server 18 includes both XML and WBXML, as accepted content types. This type of request can be useful, for example, if an information source 20 cannot transcode XML data to WBXML data. Information source 20 may then return XML data instead of WBXML data in response to the request from data server 18, even though the mobile device requests specific WBXML as the accepted content type. When data server 18 is not configured to include additional accepted content types in a request to information source 20, information source 20 may however return requested content in a content type other than those specified in the request, or instead return an error or failure message indicating that the content cannot be provided in an accepted content type.

Information source 20 returns the requested content to connection handler 26 as an XML document in the example shown in FIG. 3. The content handler 26 parses the received XML document to the transcoding system 28, and in particular to the XML-> WBXML transcoder 74. When implemented as software code, the transcoder 74 can be invoked by either the connection handler 26 or the transcoder system 74 upon receipt of the XML document from the information source 20.

ES 2 326 073 T3

As described above, the 74 XML ^ WBXML transcoder converts XML tags and attributes to tokens, based on mapping of tables in a particular codebook. The codebook cache 31 on the data server 18 stores codebooks for "known" XML types, such as XML types for which the corresponding codebooks are permanently stored in the cache 31 and types that have been previously processed by the data server 18. Each codebook in cache 31 is identified and can be retrieved using a corresponding identifier, which can, for example, be a unique public XML identifier that normally appears in a DOCTYPE declaration of a valid XML document, a URL that allows retrieving an externally referenced definition as described in more detail below, a MIME type, or possibly another identifier associated with an XML document or document type. In the example of fig. 3, the returned XML document includes one or more such identifiers. Using the identifier in the received XML document, the transcoder 74 requests the codebook from the codebook system 30. If the required codebook is stored in cache 31 (not shown in FIG. 3) in codebook system 30, then the codebook is returned to transcoder 74 and the XML document is transcoded to a document. WBXML. In the example of fig. 3 however, it has been assumed for illustrative purposes that there is no codebook available in the codebook system 30 for the identifier in the XML document returned by the information source 20.

When data server 18 receives a valid XML document of a type of which codebook is stored in cache 31 in system 30, for example when data server 18 has not processed XML documents of that type, the book code is generated by data server 18. The codebook system 30, after determining that the required codebook is not available in its cache 31, will then initiate a codebook constructed by the codebook generator 34. The codebook generator 34 retrieves a description or definition of the grammar used in that document either from an embedded (not shown) or external source (23) of XML definitions. The external source of XML definitions 23 may be implemented as a Document Type Definition (DTD) server, for example. A DTD is a formal description, it is XML Declaration Syntax, of a particular type of document. Define what names and structures can be used in a particular type of document. All documents that belong to a particular type and use the same DTD are constructed and named in a consistent and compliant way. In another possible embodiment, a combination of namespaces and encoding schemes can implement a source of external definitions 23. External definitions or descriptions of XML grammar can also be divided into multiple sources and many formats. In some XML documents, a grammar definition may be embedded in the document itself, such that the definition is extracted from the document. It should therefore be appreciated that the present invention is in no way dependent on a particular type of document definition. The techniques described herein could be adapted to use one or more definition types, such as DTD schemas, and other document definitions, including both commonly known and future definition types. In general, an outer definition defines a set of valid strings that can occur in a document.

In fig. 3, if the transcoder 74 requests a codebook that is not cached in the codebook system 30, then a definition is requested for the XML document from source 23. Although the definition request is shown in the fig. 3 as being handled by connection handler 26, a different connection handler (not shown) may instead be used to retrieve a definition from external source 23 if information source 20 and definition source 23 are configured for communications. using different protocols. The codebook generator 34 may possibly be configured for direct communication with one or more external definition sources 23, such as via link 25 shown in FIG. 2. A grammar definition can be requested from an external source such as 23 using, for example, the identifier associated with the received document. For an external definition source such as 23, a source address 23 may also be required. This address could be supplied by information source 20 with the XML document. Addresses for one or more external definition sources 23 may also be stored on the data server 18. The definition retrieval process can be simplified when a URL from which a definition can be retrieved is used as a type identifier of document to index the codebook cache. The same identifier is then used to request a codebook from the codebook system 30 and to request a definition from the external source 23.

When the requested definition is returned to data server 18 by definition source 23, it is used by codebook generator 34 to build a new codebook. The codebook generator 34 converts the grammatical definition of the document into mapping tables used to transcode the received document type to a WBXML document. The new codebook is then sent to codebook system 30, which returns the codebook to transcoder 74 and may also cache the codebook. The new codebook is then used by transcoder 74 to transcode the XML document to a WBXML document.

WBXML allows some identifiers such as the public ID in a valid XML document to be encoded as a text string as well as an integer, usually for well-known XML types such as Wireless Markup Language (WML). The document type identifier used to index the codebook cache in the codebook system 30 could be similarly encoded and included in a transcoded WBXML document. The WBXML document, which includes the encoded identifier, is passed to connection handler 26, which formats a response and sends the response to protocol translator 24. Protocol translator 24 performs any necessary protocol translation on the response and sends the response. answer

ES 2 326 073 T3 to the mobile device 12. The identifier in the response sent to the mobile device 12 is used by the mobile device 12 to retrieve the correct codebook to analyze the WBXML document, as will be described in more detail below. It may also be possible to configure data server 18 such that responses to mobile device 12 are formatted by protocol translator 24 instead of active connection handler 26. Connection handler 26 then handles request / response operations between data server 18 and external systems such that information source 20 and definition source 23, and protocol translator 24 handles communications with the mobile device 12.

In some cases, the XML document returned by information source 20 might not be a well-known XML document type. Those skilled in the art will appreciate that although XML documents may use externally referenced grammar definitions or descriptions such as a DTD to describe the markup available in any specific type of XML document, not all XML documents use such external descriptions. Since the rules of XML syntax are followed, an XML document named "well formed only" effectively defines its own markup by the use and placement of elements rather than a formal definition. Other "well-formed" XML documents may also include an embedded definition.

If a well-formed XML document only or a well-formed XML document with no external definition is returned to the data server 18 by the information source 20, then a codebook is constructed when the XML document is processed by the transcoder 74 and stored in the cache. 30 from codebook. As there is no formal grammar definition available for a well-formed XML document only, the codebook is generated "haphazardly". When a new tag or element attribute is found, a token is assigned by transcoder 74. Any subsequent occurrences of the same tag or attribute are separated into tokens using this token assignment. For a well-formed document with an embedded definition, the definition is extracted from the document and provided to the codebook generator 34 by the transcoder 74. A codebook can then be generated substantially as described above. Alternatively, the transcoder 74 itself may extract and analyze an embedded definition, assign signal to tags in the document, and add the resulting tag-to-token mapping to the codebook cache 31.

These types of XML documents do not include a DOCTYPE declaration and thus no public ID, so some other unique identifier is preferably generated and used in the codebook cache 31 and the WBXML document. This generated identifier can then be used by mobile device 12 to determine which codebook to use when parsing the WBXML document. It should be noted that each well-formed document only or embedded definition can define elements and other constructs in a different way than any other document, such that a generated codebook and unique identifier can be associated with a particular document rather than a document type. Therefore, each time a document is received, a new codebook and identifier can be created.

In order to ensure that these generated identifiers are different, it may be desirable to use an identifier generation scheme that is dependent on the content of a well-formed XML document only, a document with an embedded definition, or an embedded definition. For example, a hash function algorithm ("function to reduce a long text message into a short text message") could be used to hash the content of the document or definition to generate a unique identifier for each different document. A unique identifier could also be generated using information associated with the request / response operation through which the XML document was obtained, including, for example, some combination of a mobile device identifier, a request / response session identifier. , and a timestamp of the request and / or response. Other data-dependent identifier generation schemes will also be apparent to those skilled in the art and as such are considered within the scope of the present invention. The hash of a document is simply an illustrative example of a possible method for the generation of the identifier. The generation scheme of the particular identifier used is preferably chosen or configured such that the generated identifier is the same as any identifier associated with a known XML type. Otherwise, a generated identifier can potentially access an incorrect codebook for a known document type rather than a new generated codebook for an unknown type.

The WBXML specification also allows literal encoding of tags and attributes. Therefore, as an alternative to transcoding well-formed XML documents only, only global tags, such as starting elements and ending elements for example, are separated into tokens. Other tags and attributes are then kept as literals in the encoding, that is, not separated into tokens. This saves time of token assignment processing and codebook generation. In some circumstances, this may be a viable alternative encoding scheme for documents with an embedded or external definition.

If a well-formed XML document only has a W3C registered MIME type and has corresponding publicly available token tables, then a third option for encoding the well-formed XML document only is to use the codebook generator 34 to enter the token pairs and labels and generate an "offline" codebook. The generated codebook can then be temporarily or permanently stored in the codebook cache 31 and used each time an XML document of that MIME type is transcoded. In this case, the MIME type could be used as an index to cache 31 of the codebook. As before, use a URL or other address from which token tables are available for the type

ES 2 326 073 T3

MIME as the identifier can advantageously simplify the codebook and token table retrieval operations.

Systems and methods according to the invention can also support "malformed" XML documents. Sometimes it is possible to clean up an XML document that is close to well formed, for example if some closing tags are missing from the document. The XML ^ WBXML transcoder 74 can format such XML documents so that they are well formed before converting to WBXML.

As the codebooks generated for well-formed XML documents only or documents with embedded definitions may be different for each document, it is possible that a mobile device would always have to request a codebook when a WBXML document corresponding to such an XML document is received. Thus, there may be very little advantage in caching such new codebooks on a data server 18. This type of codebook could instead be included in a response to mobile device 12 from data server 18, for example by adding or adding the codebook to the WBXML document. This would prevent using significant space in the codebook cache 31 to store such one-time entries, but would not necessarily imply any performance penalty, as these codebooks would probably always be requested otherwise by a mobile device. 12. Including such codebooks with a transcoded document also reduces the resource load associated with codebook requests.

Rather than custom-build both the software for the data server 18 and the software applications for the mobile device 12 to operate only with certain specific known coding schemes as well as in known systems, the codebook cache 31 It is accessible by both the data server 18 and the mobile device 12. Codebooks stored in codebook cache 31 on data server 18 need not be sent to mobile device 12 unless requested by mobile device 12 on the assumption that they may already be stored in memory at mobile device 12. Data server 18 effectively provides another service to mobile device 12 whereby mobile device 12 can request a codebook for any particular document from data server 18. These operations are described in detail below with reference to figs. 4 and 5. FIG. 4 is a signal flow diagram showing the processing of a document by a mobile device 12, and FIG. 5 is a signal flow diagram illustrating data server 18 operations related to processing by the mobile device shown in FIG. Four.

In fig. 4, the communication subsystem 36 in the mobile device 12 receives a response to a connection request (not shown) that includes a WBXML document. The request / response process may be substantially as shown in FIG. 3 and described above, for example. It should be noted that although an answer has been shown in FIG. 3, a received WBXML document could instead be a document that has been pushed to the mobile device 12 by an information source. In fig. 4, the received WBXML document is intended for use by a mobile device software application 38.

The transcoding of an XML document to WBXML by the data server 18 can be transparent to a user who wants to work with XML on the mobile device 12. To this end, the WBXML document is preferably passed to the WBXML parser 40. The WBXML parser 40 injects all parsing events to application handler 42 for software application 38 in the callback functions of application handler 42. The received documents are thereby parsed into elements by the parser 40, and the elements are passed to the application handler 42. The transcoding of these elements from a WBXML document back to XML can possibly be handled well by the parser. 40 or by the application manipulator 42. If parser 40 is a binary parser, for example, then application handler 42 would normally be configured to transcode binary elements passed to it from parser 40 using the appropriate codebook. If parser 40 is a string parser however, parser 40 may transcode parsed routine elements of a received WBXML document before passing the elements to application handler 42. Although not explicitly shown in FIG. . 4, it should be noted that a mobile device 12 may include more than one type of parser 40 and more than one software application 38 and associated application handler 42. Each software application 38 and application handler 42 can then be configured to operate with any of different types of parser. In the example shown in fig. 4, the application handler 42 uses the codebook to transcode document elements. It has also been considered that elements can be transcoded when they are parsed, or transcoding can be performed on parsed elements after all or part of a received document has been parsed.

The first parsing callback function from parser 40 to application handler 42 preferably includes the identifier associated with the WBXML document. This identifier is then used by the application handler 42 as a key to retrieve the appropriate codebook from the codebook cache 45 (not shown) in the codebook system 44. In some embodiments, or for operations involving applications for which transcoding is handled by parser 40 as described above, the codebook may instead be requested by parser 40.

ES 2 326 073 T3

If the codebook is stored in the codebook cache 45 (not shown in FIG. 4) and in the codebook system 44, it is returned to the application handler 42 and the elements of the received document are transcoded. you can proceed based on the token, tag, and mapping attribute specified in the codebook. As described above, certain "permanent" codebooks, the most often used codebooks, or several of the most recently used codebooks may be stored in the codebook cache in the book system 44. of codes. In the example of fig. 4 however, the codebook is not available in the codebook system 44 on the mobile device 12 and therefore must be requested from the data server 18. A codebook request, including at least the identifier associated with the received document, is prepared by the codebook system 44 on the mobile device 12 and sent to the data server 18 through the communication subsystem 36 and the communication link. communication 37 (fig. 2).

Referring now to FIG. 5, the request for the required codebook is received by the codebook servlet 32 ​​on the data server 18. The codebook servlet 32 ​​retrieves the requested codebook from the codebook cache 31 ( not shown) in the codebook system 30 based on the identifier included in the codebook request from the mobile device 12. The retrieved codebook is returned to the codebook servlet 32 ​​and sent back to the mobile device 12 for use in parsing the WBXML document. It should be appreciated that the codebook requests and transfers may instead be handled by the codebook servlet 32 ​​through the protocol translator 24 if necessary. Also, although a codebook servlet 32 ​​is shown in FIG. 5, other interfaces to the codebook system 30 are also possible in the data server 18. The example shown in FIG. 5 assumes that the codebook is available from the codebook system 30. If this were not the case, for example if the codebook had expired from the cache in the codebook system 30 or the data server to which the codebook request was submitted would not be the data server to from which the WBXML document was received, then additional operations would be performed to retrieve a grammar definition and convert it into a codebook, as described in greater detail below with reference to FIG. 8.

Turning now to fig. 4, when the requested codebook is received by the communication subsystem 36 in the mobile device 12, it is sent to the codebook system 44, which stores the codebook in the codebook cache of the mobile device and provides the codebook to application handler 42 and / or parser 40, depending on which components handles the transcoding of parsed WBXML elements on mobile device 12.

In the example shown in fig. 4, the parsing of the WBXML document and the transcoding of parsed WBXML elements continues when the codebook is available to the application handler 42. When the parsing and transcoding are complete, the XML data can be sent to the software application 38, or to the other software applications or subsystems (not shown) of the mobile device. For example, the parsed data may be stored in a data memory of the mobile device, further processed by a software application of the mobile device, or displayed on a screen of the mobile device.

Once cached in the codebook system 44, a codebook may be designated for permanent storage, or stored only temporarily. As memory resources in mobile wireless communication devices such as mobile device 12 tend to be limited and consume considerable power, most codebooks will likely be temporarily stored. For example, the codebooks generated by the data server 18 for well-formed documents only may be different for each well-formed document only, and as such are preferably temporarily stored. Any of the memory management techniques described above can be implemented for the codebook cache in the codebook system 44.

Thus, in accordance with one aspect of the invention, codebooks are decoupled from software applications such that any application can request and use a codebook at any time. This is in contrast to known systems, in which a particular coding scheme is embedded in each corresponding respective application handler or software application.

Figs. 6 and 7 are alternative representations of data server and mobile device operations in accordance with aspects of the invention. Fig. 6 is a flow chart illustrating data server processing of a received XML document. Fig. 7 is a flow chart showing the processing of a transcoded document received by a mobile device.

In fig. 6, the data server processing begins at step 50, when an XML document destined for a mobile device is received from an information source. The document may be received by the data server in response to a request from a mobile device and transmitted to the information source by the data server, or it may instead be a document that is pushed to a mobile device, ie that is, transmitted without first being requested by the mobile device.

The data server then determines in step 52 whether the received document is a known XML document type that has an externally referenced formal grammar definition, such as a valid XML document. This can be done by looking for a public ID in a DOCTYPE declaration, for example. If the document has

ES 2 326 073 T3 an external referenced definition such as a DTD, then the document type identifier of the document is determined in step 54, and used in step 56 to request the codebook corresponding to the document type from the codebooks on the data server.

It has been determined in step 58 that the codebook corresponding to the identifier is stored in the codebook cache of the codebook system, then the data server proceeds to transcode the document in step 66 and sends the document transcoded to the mobile device in step 68. The data server processing of the received document is completed and the process ends in step 70. However, if the codebook corresponding to the identifier is not in the codebook cache (step 58), then a definition for the document is retrieved by the codebook generator at step 60 and used to generate a new codebook for that document type in step 62, as described above. The new codebook is then stored in the codebook cache at step 64 and the XML document is transcoded using the codebook, at step 66. The transcoded document is sent to the mobile device at step 68 and the process ends at step 70.

XML documents such as new types of XML documents, well-formed documents only that do not use a formal definition, or documents with embedded grammar definitions result in a negative determination in operation 52. A unique identifier is generated in operation 72, hashing the document for example, and the codebook can be requested from the codebook system at step 74. If the codebook is cached in the server's codebook system, which corresponds to a positive determination in step 76, then the document is transcoded (66), sent to the mobile device (68), and the process terminate (80) as described above. When no codebook corresponding to the generated identifier has been found in the codebook cache, the processing continues in step 78, to generate a new codebook from the received document itself or an embedded definition if applicable. A definition embedded in a received XML document is preferably extracted from the document and used either by the transcoder or by the codebook generator to generate a new codebook. The new codebook is then stored in the codebook cache at step 80, and the document is transcoded and sent to the mobile device (steps 66 and 68) and processing ends at step 70. As described above, a codebook for a well-formed document is only generated when the document is transcoded. Thus, operations 78 and 66 can be performed simultaneously, after which the codebook can be stored in the codebook cache in operation 80.

As the codebook and identifier for each received document that has no external referenced definition may be different, such that the probability of finding a codebook for a well-formed document in a codebook cache is relatively low, steps 74 and 76 can be bypassed in some embodiments of the invention. However, it is also possible that several different documents of this type may have a common codebook. For example, documents from a particular source may all use the same embedded definition. If a unique identifier has been generated for each of these documents, then the common codebook is generated and stored in the codebook cache each time one of the documents is received. In accordance with another aspect of the invention, identifiers can be generated for such documents depending on codebook or definition rather than document. For example, a codebook can be generated and then chopped to generate the identifier. Although a common codebook would still be generated on the data server each time a document sharing the common codebook is received, only one copy of the codebook would be stored on the data server. A codebook dependent identifier generation scheme can also provide significant advantages for a mobile device, as will be described in more detail below.

Alternatively, codebooks for documents that have no external referenced definition can be embedded or appended to or appended to transcoded WBXML documents to avoid taking up space in the codebook cache with essentially one-time codebook entries and to provide general codebook request operations that are not dependent on any particular data server. This alternative scheme is described in greater detail below with reference to FIG. 9.

Turning now to fig. 7, when a WBXML document from a data server is received on a mobile device in step 82, the identifier of the received document is determined (step 84). As described before, some XML documents received at a data server might not include an identifier. However, according to one embodiment of the invention, identifiers are preferably generated at the data server and included in all WBXML documents sent to a mobile device. Therefore, WBXML documents received on a mobile device preferably include an identifier. Using the identifier determined in step 84, the codebook can be requested from the codebook cache of the mobile device in step 86. If the required codebook is found in the cache, the received document is parsed and transcoded in step 90, the resulting XML data is sent to a mobile device software application or other mobile device resource such as a memory. data or display screen at step 92, and the mobile device processing ends at step 94. If the codebook is not found in the codebook cache on the mobile device, it is requested from the data server in step 96. After some delay time associated with the codebook request, indicated by the dashed line between operations 96 and 98, the code book is received by the mobile device

ES 2 326 073 T3 from the data server at step 98 and stored in the codebook cache of the mobile device at step 100. Processing then continues at step 90 as described above.

Now consider an example of two WBXML documents that have originated from only different well-formed XML documents but have a common corresponding codebook structure. On the data server, an identifier and codebook would have been generated for each of the XML documents. If the identifiers are generated by the data server for well-formed documents only depending on the generated codebooks rather than the content of the documents, then the resulting WBXML documents have the same document type identifier. When the first WBXML document is received on the mobile device, its codebook is requested from the data server and stored in the mobile device's codebook cache. When the second WBXML document is received however, the codebook corresponding to the identifier is found in the codebook of the mobile device, since of course the codebook entry has already been deleted or overwritten in the cache, avoiding hence the codebook request to the data server and its associated use of communication resources, mobile device power consumption, and time delay. The particular identifier generation scheme may be determined by a mobile device communication service provider, wireless communication network operator, data server owner or service provider, application service provider or the like, depending on the behaviors data server and mobile device and possible optimizations of document or codebook processing.

It should be apparent from the above description that the present invention advantageously allows a mobile device and a server to build respective codebook caches, which provide means for transferring and processing both known and previously unknown types of XML documents. The codebook caches on the mobile device and on the data server do not need to be the same, and can be updated to include new codebooks "on the fly", without requiring a disconnection from a server or mobile device or any changes. software or hardware. A software application on the mobile device side could further preferably seed the codebook cache of the mobile device upon installation if it was previously known what kind of XML documents would be received. This seeding could be accomplished by creating the codebook on the mobile device or by forcing the codebook cache 44 to retrieve a codebook from the data server before any data is sent.

In prior embodiments of the invention, a mobile device requests a data book from a data server when a codebook corresponding to a document has not been found in the codebook cache on the mobile device. However, it is important to note that the invention is in no way restricted to this type of codebook request. A codebook, such as a document, can also be pushed to a mobile device for storage in its codebook cache, when a new document type is set or a certain document type is found or is expected to be found frequently, for instance. Codebook requests or codebook push to mobile devices can also be used as alternatives to particular codebooks previously loaded into a codebook cache of the mobile device. Instead of pre-loading a set of frequently or permanently used codebooks onto a mobile device, a mobile device user or software application can request these codebooks from a data server when the mobile device is first configured. place to work with the data server. A data server may similarly be configured to push a predetermined codebook set to a mobile device when the mobile device is registered or authorized for communication with the data server.

The above embodiments also show operations when a codebook request is received by a data server 18 in which the requested codebook exists in the server's codebook cache. However, it is possible that a mobile device 12 can be enabled for communication with more than one data server 18. Thus, a codebook request could be sent to a data server that has not previously transcoded an XML document of the type for which a codebook has been requested, or a data server where the codebook requested is not already stored in the codebook cache. If the mobile device 12 is configured to request a codebook from the particular data server 18 from which a WBXML document or other transcoded XML document has been received, then the parsing operations at the mobile device 12 proceed substantially as follows. described before. Alternatively, data server 18 may be configured to distribute new codebooks, as they are generated, to other data servers or central codebook memory (not shown) accessible to multiple data servers. New codebooks are therefore either stored in the codebook cache of multiple data servers, or at least accessible to them, such that codebook requests can be sent to any one of them. plurality of data servers when a codebook is required by a mobile device 12.

Restricting mobile devices 12 to send codebook requests only to a particular data server 18 from which a transcoded XML document has been received may not be an optimal solution, because parsing and transcoding of received documents is then dependent on a single data server. If the data server is disconnected or otherwise inoperable or unavailable to the mobile device 12, then the received transcoded XML documents for which no codebook has been stored in the codebook cache 45 of the mobile device cannot be transcoded from

ES 2 326 073 T3 back to XML until the data server 18 that sent the document to the mobile device 12 is back in service. Distribution of codebooks among multiple data servers or to a central codebook memory may also require substantial amounts of data transfer and occupy data server resources. Furthermore, any delays in the distribution of a new codebook by a data server can cause errors in the handling of the codebook request, for example if a new codebook is requested from a data server before the new codebook has been stored in the codebook cache or central codebook memory of the data server.

An alternative scheme that addresses these questions while providing improved flexibility for retrieving codebooks from data servers will now be described with reference to FIG. 8 which is a signal flow diagram illustrating data server operations associated with a codebook request in accordance with another aspect of the invention.

In fig. 8, a codebook request and received by data server 18 from a mobile device 12. Codebook requests are received by codebook servlet 32, possibly through protocol translator 24 if necessary . The codebook servlet 32 ​​then requests the codebook from the codebook system 30, which determines whether the requested codebook is stored in the server's codebook cache (not shown) on the codebook system 30. code books. In the example of fig. 8, the requested codebook is not in the codebook cache. This can occur, for example, when the data server 18 receiving the codebook request from the mobile device 12 has not previously transcoded an XML document of the type with which the requested codebook is associated. However, the codebook may also be absent from the server's codebook cache if the codebook has only been temporarily stored and was overwritten or cleared from the cache before the book code was requested by the mobile device 12.

In accordance with this embodiment of the invention, a codebook that has not been found in the server's codebook cache in the codebook system 30 is generated by the data server 18. In the example of FIG. . 8, the codebook is associated with an XML document that conforms to a DTD available from an external definition source displayed as a DTD server 23a. When the codebook system 30 determines that the requested codebook is not available in its codebook cache, the codebook generator 34 is invoked and requests the DTD for the document from the DTD server 23a. The DTD is requested from the DTD server 23a, using the appropriate document type identifier. The DTD server then returns the DTD to the codebook generator, which generates the requested codebook using the DTD, substantially as described above. The codebook is then sent to the codebook system 30, which preferably stores the codebook in its cache. The codebook system 30 also returns the codebook to the codebook servlet 32, and the codebook is returned to the mobile device 12, through the protocol translator 24 if required. In mobile device 12, the requested codebook is stored in the mobile device's codebook cache 45 and, if the codebook request was made to allow transcoding of a received WBXML document, the codebook it is used to treat the document, as described above.

The server operations involved in the codebook request scheme of FIG. 8 are shown in fig. 9. fig. 9 is a flow chart showing data server processing of a codebook request in accordance with an embodiment of the invention shown in FIG. 8. In fig. 9, server processing begins when a codebook request is received from a mobile device at step 102. The server then determines the identifier associated with the requested codebook in step 104. As described above, the mobile device can insert a public document ID or other identifier in the codebook request, such that the identifier is preferably extracted from the request. Using the identifier, it is then determined whether the requested codebook is in the server's codebook cache, in step 106. If the codebook is in the cache, it is retrieved from the cache at step 108, returned to the mobile device at step 110, and codebook request processing ends at step 112.

When the codebook is not in the cache, the server determines an address of an external definition source from which the definition can be retrieved, in step 114. When this address has been determined, the server retrieves the definition, at step 116, for example by a request and response process as described above. The requested codebook is then generated in step 118, preferably stored in the server's codebook cache at step 120 and returned to the mobile device in step 110. The codebook request handling is then completed, and ends at step 112.

An advantage of using a URL from which an external definition can be retrieved will be apparent from figs. 8 and 9. When the identifier in the codebook request points to the location of an external definition, then the data server does not need to resolve the identifier to determine the address of an external definition source (step 114 of FIG. 9), such as DTD server 23a. As such, the request contains all the information required to retrieve an external definition, which simplifies the handling of the codebook request by a data server. Furthermore, this scheme provides means for codebook request load distribution across multiple data servers without requiring any kind of codebook communication between

ES 2 326 073 T3 data servers. For example, a first data server (DS1) can receive an XML document, retrieve the DTD, create the codebook, transcode the XML document to a WBXML document, and send the WBXML document to the mobile device. A second data server (DS2) could then receive the request for the codebook from the mobile device. If the codebook is not already cached on the DS2 server, since DS1 has generated and cached the codebook, DS2 will have to retrieve the DTD and generate the codebook. In this case, using the URL of the DTD as the identifier for the XML document type is much more useful than using a public ID or other identifier since the URL is all that is required to retrieve the DTD.

Using the public ID as the identifier would either require communication between DS1 and DS2 or restrict the mobile device from sending the codebook request only to DS1 as described above. Such communication and restrictions can make the entire system less robust and less scalable. However, when an identifier is associated with a URL of a definition, or the identifier can be resolved in such a URL, the benefits described above are achieved by using the identifier. For example, the identifier could be a hash function or other transformation of a definition URL, which a data server can resolve to the URL by querying a hash function table or other lookup table.

The scheme shown in fig. 8 can be applied not only for XML documents that have an associated DTD, but also for documents that have a registered MIME type and publicly available token tables, or any other XML documents that have a reference to an external publicly available document grammar definition. . For other XML documents such as well-formed documents only and documents with embedded definitions however, a codebook is generated by a data server using the XML document or an embedded definition. It is therefore preferable that such codebooks are embedded or added to or appended to transcoded documents sent to a mobile device 12. Then, any mobile device 12 requests only those codebooks associated with valid XML documents or XML documents that have publicly available witness tables, from which a codebook can be generated by any data server that has access to the codebooks. codes, token tables, or other external definitions from which codebooks can be generated. In order to provide means for the codebook request operations shown in FIGS. 8 and 9, while maintaining support for XML documents without external definition, data server operations can be modified as shown in fig. 10. FIG. 10 is a flow chart illustrating the exemplary data server handling of a received XML document to support the codebook request scheme in FIGS. 8 and 9.

In fig. 10, the treatment of an XML document having an external referenced definition is substantially the same as that shown in FIG. 6 and described above, and therefore has not been described in further detail. When a document received from an information source in step 50 has been determined to have no external referenced definition (step 52), then a codebook is generated from the document or embedded definition in step 78, as described above. described before. The received document is then transcoded in step 66. As also described above, the codebook can be generated when the document is transcoded, such that operations 66 and 78 can actually be simultaneous operations. The codebook is then embedded or appended to the transcoded document in step 67, and the transcoded document and codebook are sent to the mobile device in step 69. Since the codebook is sent to the mobile device with the transcoded document, an identifier does not need to be generated and the codebook does not necessarily need to be stored on the data server.

The above description refers to transcoding XML documents to WBXML documents on a data server, sending transcoded documents to a mobile wireless communication device, and handling documents on the mobile device. However, according to another aspect of the invention, XML documents can also be prepared on a mobile device and transcoded to WBXML for transmission to a data server. The data server can then transcode WBXML documents received from a mobile device to XML for transfer to an intended recipient.

Fig. 11 is a signal flow diagram showing the creation of a WBXML document on a mobile device. The mobile device 212 shown in FIG. 11 is similar to mobile device 12 shown in FIG. 4, but provides means for creating XML and WBXML documents. Communication subsystem 236 and codebook system 244 may be the same as similarly labeled components on mobile device 12. Software application 238 and its application handler 242 may also be the same as application 38 and handler 42 in FIG. 4, for example if the software application 38 is configured to both receive and generate the XML content. However, it should be appreciated that any mobile device software application can either receive XML data, or generate XML data, or both, and that a mobile device can include more than one type of software application.

The WBXML generator 241 performs the inverse operations of the WBXML parser 40, because instead of parsing document elements from a WBXML document, the WBXML generator 241 gathers document elements into a WBXML document. The transcoding of XML document elements to WBXML elements can be handled either by the WBXML generator 241 or by the application handler 242, depending on the configuration of the mobile device 212, the software application 238, and its handler 242. In mobile device 212 of the example, application handler 242 transcodes document elements

ES 2 326 073 T3

XML to WBXML document elements, although a mobile device can include software applications and associated manipulators of any of the above types.

As shown in FIG. 11, the software application 238 generates XML data that is passed to the application handler 242. This data may have previously been stored on mobile device 212, it may be entered by a user on a keyboard, or other input (not shown) on mobile device 212, or it may possibly be uploaded to mobile device 212 through a data transfer system such as a serial port connection to a computer or a short range wireless communication system such as an infrared receiver or Bluetooth ™ communication module. XML data generated by software application 238 can be transferred to application handler 242 in a single transfer as shown in FIG. 11, or element by element when each element is generated.

When some or all of the XML data from software application 238 is received by application handler 242, the codebook required to transcode the XML data to WBXML is requested from codebook system 244 using an identifier. associated with the XML type of the data generated by the software application 238. The codebook system 244 returns the requested codebook to the application handler 242, either retrieving the codebook from its cache (not shown) or requesting the codebook from a data server if the codebook is not. it is available in your cache. The codebook request process, possibly including codebook generation on a data server, can be performed by any of the schemes described above.

When the codebook is received by the application handler 242, the transcoding of the XML data to WBXML document elements continues. Once all of the XML data from the software application 238 has been transcoded into WBXML elements and transferred to the WBXML generator 241, the wBXML generator 241 gathers the WBXML elements into a WBXML document, including the identifier associated with the XML type, and transfers the WBXML document to communication subsystem 236. The WBXML document is then transmitted to a data server.

XML data generated by software application 238 may also be stored in memory (not shown) in mobile device 212 until the requested codebook is received. This provides means for generating data in a mobile device 212 even when the mobile device 212 is out of range of the communication network or is otherwise unable to request and / or receive a code book from a data server. Since the data is stored in the mobile device 212, other mobile device operations, functions, and software applications can be used even though a generated XML document has not yet been transcoded and sent to the data server. The stored data can then be transcoded and sent to the data server as long as the codebook is received.

It has been considered that an XML document generated on the mobile device 212 may be destined either for a data server, or for a recipient of the intended document with which a data server may be configured to communicate, such as a web server. data for example, or for both. If the XML document is to be transmitted to one or more receivers by a data server, then an address of each receiver is preferably added to or embedded in the WBXML document by the software application 238, the application handler 242, or possibly the generator. 241 of WBXML on mobile device 212.

The example device 212 above and the signal streams shown in FIG. 11 refer to the generation of an XML document for which a codebook is either available on the mobile device 212 or comes from a data server. As described above, a codebook for an XML document that has a publicly available grammar definition can be generated by any data server that has access to the grammar definition. As such, if mobile devices and mobile device software applications are configured to generate only known types of XML, then a mobile device need not include a codebook generation system since any codebooks required to generate documents WBXML on a mobile device can then be requested from a data server. However, when the processing facilities on a mobile device allow it, the mobile device can generate well-formed XML documents only or other new types of XML documents, generate corresponding codebooks for such documents, and embed, add, or add the books. from codes to transcoded WBXML documents before sending the documents to a data server. Alternatively, and as described above for data server 18, a unique identifier could be generated and codebooks could be stored in a codebook cache (not shown) on mobile device 212 if there is sufficient storage space. available memory. If a codebook is required by a data server for a WBXML document generated from such an XML document, then it could be requested from the mobile device. Of these two alternatives, sending such codebooks to a data server may be preferable in order to avoid handling the codebook request on a mobile device, possible time delays in retrieving codebooks from a mobile device when a mobile device is disconnected or out of range of the communication network, and increased codebook request / response traffic on the mobile device to data server communication links.

Fig. 12 is a signal flow diagram showing the processing of a WBXML document received from a mobile device by a data server. The data server 218 and its components are substantially

ES 2 326 073 T3 similar to data server 18 and similarly labeled components shown in FIG. 3 and described above, except that transcoder system 228 includes a WBXML to XML transcoder 274.

A mobile device 212 preferably transfers documents to a data server 218 using the same protocol used for document transfers from a data server to a mobile device, such as proprietary IPPP, although different protocols may be used depending on the transfer direction. of the document.

A WBXML document from mobile device 212 is received by data server 218 and any necessary protocol translations are performed by protocol translator 224. The received WBXML document is sent to transcoder 274 in transcoding system 228. It should go without saying that the transcoder system 228 in the data server 218 also performs parsing of received documents. This is also true for the transcoding system 28 in the data server 18 described above. Those skilled in the art will appreciate that a separate parsing system could also be provided on a data server without departing from the scope of the present invention.

If the codebook is embedded or is added or appended to the WBXML document, the transcoder 274 extracts and uses the codebook to transcode the elements of the WBXML document to XML, and can also store the codebook in a book cache. codes (not shown) in the codebook system 230. In the example shown in fig. 12, the received WBXML document has an external referenced definition. The identifier is used by the transcoder 274 to request the codebook for the document from the codebook system 230. The codebook system either returns the requested codebook, if the codebook is found in its codebook cache, or invokes the codebook generator 224 to generate the requested codebook.

As described above, the codebook generator 234 requests the definition using the identifier, which is preferably an address such as a URL from which the definition can be retrieved, from an external definition source 223. When the definition is returned to the codebook generator 234, it is used to generate the requested codebook, which is then returned to the codebook system 230. The codebook system 230 preferably stores the new codebook in its cache and provides the codebook to the transcoder 274. The analyzed WBXML elements are then transcoded and assembled into an XML document.

If the document from the mobile device 212 is intended to be processed further by the data server 218 or other components therein, then the XML document is sent to such other components of the data server or possibly stored in a memory (not shown) on the data server 218 for subsequent processing. If the received WBXML document is destined for a receiving system 228 identified by an address embedded or provided with the document by mobile device 212, then the transcoded document is sent to receiving system 220 through an appropriate connection handler 226. Communications from data server 218 to receiving system 220 can be accomplished by connection handler 226 used for communications between data server 218 and external definition source 223, as shown in FIG. 12, or different connection handles can be used. As a document request from the mobile device 12 as described above, the mobile device 218 can send a connection request and with the WBXML document to specify any document receiving systems such as 220 and a communication and / or protocol handler. which is to be used to transfer the document to any receiving systems.

The XML documents generated in the mobile device 212 are therefore transcoded to WBXML for transfer to a data server 218 and transcoded back to XML by the data server 218. It has also been considered that the mobile device 212 can transfer a WBXML document to a similarly enabled mobile device, either directly or through a data server. In the latter case, a WBXML document is preferably sent to an intended recipient mobile device rather than being transcoded to XML by the data server. The receiving mobile device may request a required codebook either from a data server or possibly from a sending mobile device.

The content processing schemes shown in Figs. 11 and 12 are shown in flow diagram form in FIGS. 13 and 14. FIG. 13 is a flow chart depicting mobile device processing of a generated XML document, and FIG. 14 is a flow chart illustrating the handling of a WBXML document received by a data server.

In fig. 13, an XML document is generated on the mobile device 212 in step 250. It is then determined in step 252 whether the XML document is a known XML document type that has an external referenced and available grammar definition, such as a document Valid XML. The type of XML document generated may be dependent, for example, on the particular mobile device software application that generates the XML document. If the XML document has an externally referenced definition such as a DTD, as can be determined by searching for a DOCTYPE declaration in the XML document, then the document type identifier of the document is determined in operation 254, and used in operation 256 to request the corresponding codebook from the codebook system on the mobile device.

ES 2 326 073 T3

If the codebook is stored in the codebook cache of the mobile device codebook system, as determined in step 258, then the XML document is transcoded in step 260 and the resulting WBXML document is sent to a data server and / or receiver or receivers in operation 262, completing the processing by the mobile device of the generated XML document. The process ends at step 264. However, if the codebook corresponding to the identifier is not in the codebook cache (step 258), then it is requested from a data server in step 266. The codebook is received from the data server at step 268, after some time delay indicated by the dashed line between steps 266 and 268. The codebook is then preferably stored in the codebook cache on the mobile device at step 270, and processing is concluded with steps 260, 262, and 264 as described above.

Mobile devices with relatively limited processing power will likely be enabled to generate only XML documents for which codebooks can be generated and requested from a data server in order to avoid codebook generation on mobile devices. In such mobile devices, the handling of a locally generated XML document includes operations 250 and 254 to 270. When a mobile device can generate codebooks for XML documents such as new types of XML documents, only well-formed documents that do not use a formal definition, or documents with embedded grammar definitions, then a negative determination can be made at step 252. The codebook is generated from the document or embedded definition in step 272, as described above for example, the XML document is transcoded using the codebook in step 274, the codebook is preferably embedded or it is added or appended to the transcoded WBXML document in step 276, and the WBXML document and codebook are sent to the data server and / or receiver (s) in step 278.

Alternatively, the codebook generated in step 272 can be stored in the codebook cache on the mobile device using a unique computed identifier. However, for the reasons described in detail above, codebooks generated from XML documents or embedded definitions are preferably sent to the data server or any other receivers with or without the WBXML document.

Turning now to fig. 14, the treatment of a WBXML document generated on a mobile device will be described. Fig. 14 is a flow chart illustrating the handling of a WBXML document received by a data server. As shown, the processing method begins when a WBXML document from a mobile device is received at the data server in step 280. It is then determined whether the codebook has been provided with the document, for example when a codebook used for a well-formed XML document was only embedded or is appended to the WBXML document. If the codebook has been provided with it, then it is extracted at step 284, and the document is parsed and transcoded back to WBXML using the codebook at step 286. As described above, the document sent from the mobile device may be intended for use by the data server and possibly also or instead of by one or more receivers. The transcoded document is then distributed to components within the data server and / or to any intended receivers, at step 288. The method then ends at step 290. If the document is intended for more than one receiving mobile device, then the received WBXML document could be sent to the mobile devices in operation 288 without being transcoded while the transcoded version of XML could be sent to other receivers such as computer systems. with which the data server can communicate, through a WAN such as the Internet, for example. As WBXML can also provide more efficient use of communication resources even for wired communication systems, it is possible that a data server could be configured to distribute a received WBXML document to all receivers, and that the transcoding operations of operation 286 would be performed by each receiver.

If the codebook was not provided by the mobile device with the received WBXML document, as determined in step 282, then the data server determines the identifier of the received document in step 292. The codebook is below requested from the codebook system at the data server, using the identifier, in step 294. The codebook system then determines whether the codebook is in its cache at step 296. If the codebook is found in the cache, then processing continues at step 286, as described above. If the codebook is not in the cache, then at step 298, either the definition associated with the identifier or the codebook itself is retrieved. In most of the implementations, it has been considered that the definition will be retrieved and the codebook will be generated by the data server. However, it should be understood that the invention is in no way limited thereto. When the resources of the mobile device allow it, the codebooks could be requested from a mobile device from which the WBXML document was received.

When a definition is retrieved by the data server at step 298, a codebook is generated at step 300. The required codebook, either generated at step 300 or retrieved at step 298 by the server server. Data is preferably stored in the data server codebook at step 302, and processing is concluded with steps 286, 288, and 290 as described above.

According to another aspect of the invention, WBXML documents can be directly exchanged between mobile devices. Processing by a mobile device of a received WBXML document can be substantial

ES 2 326 073 T3 as described above. A required codebook that is not provided with the WBXML document or found in the codebook cache of the mobile device may preferably be requested either from a data server or possibly from the sending mobile device.

Fig. 15 is a block diagram illustrating a mobile wireless communication device in which systems and methods in accordance with the invention could be practiced. In fig. 15, the mobile device 322 includes a communication subsystem 336, a WBXML string parser 340, a WBXML string generator 341, a WBXML binary parser 342, a WBXML binary generator 343, three 346 software applications , 352 and 358, each of which includes the software code that implements the actual software application 350, 356, 362 and a corresponding application handler 348, 354, 360, and a codebook system 344 including a codebook cache 345. Mobile device 322 in FIG. 15 is substantially similar to mobile device 12 in FIG. 2, but shows multiple software applications and two types of WBXML parsers and generators.

Communication subsystem 336 includes such components when required for mobile device 322 to communicate with a data server over links 335 and 337, which can be used for document transfers and codebook requests and responses, for example, and possibly with other mobile devices over link 339. The exact implementation of the communication subsystem 336 will depend on the communication systems and protocols with which the mobile device 322 is intended to operate, as described above.

The WBXML string parser 340 receives WBXML documents and parses and transcodes the documents back to XML. The string parser 340 is therefore connected to the codebook system 344 to provide means for retrieval of the codebook when a WBXML document is received. If the codebook is embedded or is added or appended to the received document however, and the codebook is extracted, passed to the codebook system 344 for storage in the codebook cache 345, and used to transcode the WBXML document. The parsed and transcoded XML data is then passed to application handler 348 for use by application 350. It should be appreciated that application 246 is configured to work with XML on mobile device 322 and thus XML data is passed through string parser 340. Similarly, application 346 is also configured to generate XML on mobile device 322. XML data generated by software application 350 is passed to WBXML string generator 341 by application handler 348. The WBXML series generator 341 retrieves the relevant codebook from the codebook system 344 or generates the codebook from the XML data or an embedded definition as described above. The codebook is used to transcode the XML data to WBXML data that is assembled into a WBXML document and passed to communication subsystem 336 for transmission to a data server or possibly another mobile device. A codebook generated on mobile device 322 may be sent along with the transcoded WBXML document, stored in cache 345 on codebook system 344, or both.

Software application 352 configured to work with binary parser 342 includes an application handler 354 that handles transcoding operations. A received WBXML document to be used by application 352 is parsed by parser 342 and the parsed WBXML document elements are passed to application handler 354. The application handler 354 then either requests the codebook from the codebook system 344 or extracts an embedded codebook from the document, and uses the codebook to transcode the parsed elements to WBXML. When an XML document is generated using the software application 356, the application handler 354 either generates the appropriate codebook from the document itself or an embedded definition or requests the codebook from the codebook system 344. , and uses the codebook to transcode XML elements generated by the 356 application into binary WBXML elements. The WBXML binary generator 343 performs inverse operations of the WBXML binary parser 342, and gathers the WBXML elements passed to it by the WBXML document application handler 354.

Applications 346 and 352 are configured to work in conjunction with codebook system 344 in accordance with aspects of the invention. It should also be appreciated that a mobile device 322 incorporating such applications may also have other software applications installed and running on it. For example application 358 includes an application handler 360 in which an encoding scheme is embedded, as would be common in accordance with a known technique described above. Application 358 may use parser 242 and generator 343, as shown in FIG. 15, but does not interact with the codebook system 344. Implementation of the invention on a mobile device can thereby provide compatibility with mobile device software applications that use embedded transcoding schemes.

Mobile device 322 as shown in FIG. 15 is intended for illustrative purposes only, and the invention is in no way restricted to a mobile device that includes the components shown therein. For example, other software applications that only send or receive XML, as well as still other applications that allow communication functions or non-communication functions, may also or instead be implemented in a mobile device.

ES 2 326 073 T3

It will be appreciated that the above description refers to preferred embodiments by way of example only. Many variations on the invention will be obvious to those skilled in the art, and such obvious variations are within the scope of the invention as described herein, whether or not they are expressly described.

For example, although a single mobile device, data server, and information source are shown in the drawings, a data server will typically provide services for a plurality of mobile devices, possibly over different wireless communication networks, and access to a plurality of source of information through different direct or network-based connections. Similarly, any wireless communication network and any information source can communicate with multiple data servers.

In addition, the systems and methods described above and can be implemented to transcode and parse content types other than XML. Similarly, these systems and methods could be adapted to other coding systems than WBXML. The benefits and advantages described above could also be derived for such encoding schemes as type length encoding, for example.

Although data servers and information sources are fundamentally described above as separate systems, an integrated system that incorporates both the data server and the information source functionality has also been considered. Such integrated systems are particularly advantageous when confidential or otherwise sensitive information is provided by an information source. In this case, an intermediate data server is not required to transcode information for transmission to a mobile device. For example, confidential information that is transcoded and encrypted at the information source remains encrypted until it is decrypted on the mobile device, providing end-to-end security.