WO2001086462A1 - Method of converting html/xml to hdml/wml in real-time for display on mobile devices - Google Patents

Abstract

A method for converting HTML/XML to HDML/WML in real time for display on wireless communication devices. The request for Web content comes from the mobile unit and is received by a proxy server (220). The proxy server retrieves the content from the Web or from local cache (222). The proxy server paryses the mobile unit request to determine the mobile device type and the mobile user preferences. The specifications for the device type (226) and user preferences (224) are retrieved by the proxy server from its database. Based on the device and user information, the proxy server retrieves a conversion specification tailored to the device and the user (228). The retrieved Web content is then processed by the proxy server based on the conversion specification. The result of this processing is then optimized for transmission and sent to the waiting wireless communications devices (234).

Description

METHOD OF CONVERTING HTML/XML

TO HDML/WML IN REAL-TIME

FOR DISPLAY ON MOBILE DEVICES

Background of the Invention

1. Field of the Invention

The present invention relates generally to wireless communications and more particularly relates to a method for converting HTML/XML to I--DIV1L/WML in real time for display on mobile devices.

2. Related Art

The advent of wireless personal communications devices has revolutionized the telecommunications industry. Cellular, personal communications services ("PCS") and other services provide wireless personal cornmunications to businesses and individuals at home, in the office, on the road, and any other location the wireless network may reach. Wireless telephone subscribers must no longer use pubhc telephones along the road, wait until returning to the home or office to check messages, or wait to return important business calls. Instead, wireless subscribers can carry out day-to-day business from the privacy of an automobile, from a remote job site, while walking along the airport concourse, and anywhere else that a personal communications signal is accessible.

Thus, it is no surprise that since the introduction of the cellular telephone service, the number of wireless telephone subscribers has increased steadily. Today, there are a staggering number of wireless telephone subscribers whose ranks are growing rapidly. In fact, many households have multiple wireless telephones in addition to their conventional land line services. With a market of this size, there is fierce competition among hardware manufacturers and service providers. In an attempt to lure customers, most providers offer handsets with desirable features or attributes such as small size, light weight, longer battery life, speed dial, and the like. Many recent additions to the marketplace include multi-functional handsets that even provide pocket organizer functions integrated into the wireless handset. Most manufacturers, however, are still scrambling to add new features to their communications devices to snare a portion of this booming market.

One way in which new features are added to wireless communication devices is by integrating the device into the Web. This allows the countless services available through the Web to be extended to a wireless communications device. However, traditional web pages typically contain too much information to be advantageously presented on the smaller display of a wireless communication device such as a digital cellular telephone. Therefore, new Web based programming languages such as the Handheld Device Markup Language ('ΗDML") have been developed to serve the wireless market. In serving the wireless market, HDML has evolved and is now called the Wireless Markup Language ("WML"), and will be herein referred to as HDML WML.

HDML/WML is part of a larger body called the Wireless Application Protocol ("WAP"), which is a result of continuous work to define an industry wide standard for developing applications over wireless networks. The WAP forum was formed to create the global wireless protocol specification that works across differing wireless network technology types for adoption by appropriate industry standards bodies. HDML/WML is a markup language intended for use in specifying content and user interfaces for narrow bandwidth ("narrowband") devices, including cellular phones, pagers, and personal digital assistants ("PDA"). HDML/WML was designed with the limitations and consfraints of these narrowband, small screen devices specifically in rnind. Some of these constraints include (1) the small display and limited user input facilities; (2) the narrowband network connection; and (3) the limited memory and computational resources.

HDML/WML was designed with four major functional areas. First, the text presentation and layout area includes text and image support, including a variety of formatting and layout commands.

Second, a "card and deck" organizational metaphor whereby all information is organized into a collection of screen sized cards that comprise decks. Third, inter-card navigation and linking is supported for explicitly managing the navigation between cards and decks. Finally, the fourth major functional area in HDlVfL/WML is string parameterization and state management that allows the use of a state model to add parameters to the decks.

Today, HDML/WML offers an efficient means of providing content and services from the Web infrastructure to wireless handheld devices such as cellular phones, pagers, and PDAs. Unfortunately, the vast majority of content on the Web is created in hpyer text markup language or extensible markup language ("HTML/XML") and is thus not useful on the constrained wireless corrrmunication devices. HTML/XML requires significant context to be useful. The constrained display and restricted resources of wireless devices reduce the context to such a level that HTML/XML becomes unusable. The pull down menu for navigational history and the context sensitive forward and back buttons are simply not available through the small screens of wireless mobile devices such as cellular phones, pagers, and PDAs.

Although most Web content is unusable on wireless communications devices, certain types of information are desirable to wireless device users. For example, Web pages with time sensitive, discrete data such as stock quotes, weather reports, email, calendar and appointment data, inventory data, price lists, corporate directories, white and yellow pages, and invoice status. Thus, there is a need to provide existing HTML/XML Web content to wireless communication devices with constrained displays and limited computational resources such as RAM and processing power.

Summary of the Invention

Accordingly, an advantage of the present invention is that it allows for the conversion of HTML/XML content from the Web to HDML/WML content for a wireless communications device. An additional advantage of the present invention is that the HDML/WML content is optimized for display on wireless communication devices. The conversion takes place in a conversion server that acts as a proxy server for the wireless communications device. This proxy function allows the conversion server to receive and process all Web related requests from the mobile unit. Additionally, the proxy/communication server receives all of the corresponding responses and channels those responses to the mobile unit after conversion to HDML/WML. Furthermore, the proxy/communication server can be configured to restrict certain types of requests, responses, and connections.

The HTML/XML to HDML/WML conversion process begins with a request from the wireless device. This request is received by the conversion server, acting as a proxy for the mobile unit. In addition to the actual request for Web content, the wireless device sends certain user data and device data. This additional data is maintained by the mobile unit for identification purposes. The user and device data, therefore, allow the server to identify (with the required degree of certainty) the type of mobile device making the request and the preferences of the user making the request.

Upon receiving the request, the conversion server retrieves the desired content from the Web in the form of an HTML/XML document. Alternatively, if the requested document has been previously retrieved by the conversion server, the document may be located in the server's local cache. If so, the conversion server retrieves the document from its local cache. This decreases the overall response time to the mobile unit by eliminating the otherwise necessary Web access step.

After the conversion server has retrieved the requested document, the server examines the user data and device data received in the request. Based on the user information, device information, and the type of data contained in the requested HTML/XML document, the server selects the appropriate conversion specification. The conversion server then retrieves the appropriate conversion specification from its local database for use in the conversion process.

The conversion process follows the instructions in the conversion specification, making necessary allowances based on the user information, device information, and' the type of data contained in the requested HTML/XML document. The conversion server runs the retrieved Web document through a series of conversion routines to convert the content into a format that is appropriate for the specific device. When the conversion is complete, the conversion server optimizes the data for display on the requesting mobile unit and transmits the data to the waiting wireless communications device.

Brief Description of the Drawings

The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

Figure 1 is a diagram illustrating a wireless communication device; Figure 2 is a block diagram portraying a wireless communication system according to the present invention;

Figure 3 is a flowchart depicting a method for requesting information across a wireless network according to the present invention;

Figure 4 is. a block diagram illustrating a wireless communication system that links a wireless communications device to the World Wide Web according to the present invention;

Figure 5 is a flowchart of a process for receiving HTML/XML content from the Web and converting it to HDML/WML content for a wireless communications device; and

Figure 6 is a flowchart of a method for converting HTML/XML content to HDML/WML content according to the present invention.

Detailed Description of the Preferred Embodiments of the Invention

The present invention is directed toward a method for converting Web content in HTML/XML format to HDML/WML format for eventual display on a mobile wireless communications device. In one example embodiment, the mobile device can be a digital cellular telephone that connects to a Web server using wireless communications technology. After reading this description it will become apparent to one of ordinary skill in the art how to implement the invention in alternative embodiments and alternative, applications. As such, this detailed description of a preferred and alternative embodiments should not be construed to limit the scope or breadth of the present invention. 1. Introduction and Overview

• The present invention provides a method for converting HTlVfL/XML to HDML/WML such that native Web content can be efficiently displayed on a mobile wireless communications device. In one embodiment, the wireless communications device sends its requests for Intemet content to a Web server that acts as a proxy for Internet related requests from the mobile device. Examples of requests that may be sent from the mobile device include Web search requests, Yellow Page lookup requests, informational queries, and any other requests that may be useful or valuable to users of Web content. The wireless communication device sends, along with its request for content from the Web, certain local information to uniquely identify the mobile device and the preferences of the user of the mobile wireless device. After the request has been processed by the Web server, the result is translated into HDML/WML and optimized for transmission back to the mobile wireless communications device. 2. Example Environment

Before describing the invention in detail, it is useful to describe an example environment in which the invention can be implemented. One example environment is a handset or communication device operating within a wireless communication network such as, for example, a cellular, GSM, PCS or radio communication network. Wireless communication devices embodying the present invention can be implemented in various configurations and architectures. Typically, a wireless cornmunication device will include a keypad for control of the device and data entry, and a display for displaying relevant information.

An example wireless communication device 100 is illustrated in Figure 1. Communication device 100 is presented for illustrative purposes only; implementation of the invention is not dependent on any. particular device architecture or communication network.

Device 100 includes a processor 104, a speaker 106, a display 108, a keypad 110, a transceiver 122, a memory 114, a microphone 116, a power source 118 and an antenna 120. Device 100 is typically a mobile device such as a handheld handset or an integrated vehicle phone. It is configured to communicate with other communications devices such as base station 112. Base station 112 is typically within a geographic area known as a "cell" and handles communications for all wireless devices within the cell.

Processor 104 directs the overall operation of device 100. A computer program or set of instructions is typically coded or otherwise implemented on the processor to enable the processor to carry out the device operation. Memory 114 interfaces with processor 104 and may store program code and provide storage space for data useful in executing the program code and carrying out the device functions. Memory 114 may be implemented as read only memory ("ROM"), random access memory ("RAM") or any other convenient memory format. The features and functionality of -the invention described below may be implemented using hardware, software, or a combination thereof, and such software can run on a processor such as processor 104 and be stored in a memory such as

memory 114.

Transceiver 122 includes a transmitter that .transmits voice and data information via antenna 120 to a recipient commumcation device such as, for example, base station 112. Transceiver 122 also includes a receiver that receives voice and data information from another communication device (e.g., base station 112). The received voice and data information is provided to the user or used to facilitate device operation.

User interface features include speaker 106, display 108, keypad 110, and microphone 116. Microphone 116 accepts voice or other audio information from the user and converts this information into electrical signals that can be transmitted by transceiver 122. Likewise, speaker 106 converts electrical signals received by transceiver 122 into audio information that can be heard by a user of device 100. Display 108 displays information such as call information, keypad entry information, signal presence and strength information, battery life information, or any other information useful to the user. Display 108 preferably takes the form of a liquid crystal display ("LCD"), which has low power consumption characteristics, but could also be implemented as a light emitting diode ("LED") display or any other appropriate visual indicator. Keypad 110 typically includes an alphanumeric keypad and may also include special function keys, hi one embodiment, keypad 110 is backlit to permit viewing of the keys in low light or dark conditions. Device 100 may also include a flip panel (not shown) that can be closed to conceal part or all of the keypad 110.

Power source 118 provides power to device 100. It can be implemented with rechargeable batteries, such as NiCad or NiMH rechargeable batteries, or with any other suitable power source. 3. Wireless Services Through a Web Server Figure 2 is a block diagram illustrating a wireless communication system according to the present invention. The communication system provides information to a wireless device user based on the location of the user and his device. It includes a wireless handset 130 and a hands-free unit 132 incorporating a position determination system 134. Handset 130 can be implemented in a configuration such as device 100 of Figure 1, or in any other wireless cornmunication device capable of communicating with remote locations via a wireless communication medium. In the description below, "handset" refers to any communication device capable of communicating with other devices via a wireless medium.

Hands-free unit 132 is optionally provided to allow the user of wireless device 130 to communicate in a hands-free mode. Hands-free unit 132 may include a microphone and speaker to provide wireless device 130 with speakerphone-like capabilities. Such capabilities are particularly desirable, where wireless device 130 is utilized in an automobile or other mobile situation. In one implementation, hands-free unit 132 is configured according to conventional industry standards for a "hands-free kit."

As mentioned above, in addition to the conventional standards, hands-free unit 132 is equipped in a preferred embodiment with a position determination system 134 to determine the location of hands-free unit 132 and handset 130. Alternatively, position determination system 134 may be directly incorporated into handset 130. Position determination system 134 determines location in terms of parameters such as latitude, longitude, height, speed of travel, and any other useful location or position parameters. In one embodiment, position determination system 134 is implemented using a global positioning system ("GPS") or differential GPS. The design and configuration of a GPS is well known to those of ordinary skill in the art. Alternative position determination systems may also be employed. One example of an alternative^' position determination system is a triangulation system. In such a system, the position of handset 130 is determined by triangulating a signal from handset 130 with the fixed locations of two or more base stations. Triangulation systems, though useful and relatively inexpensive, have several drawbacks. Errors due to multipath signal transmission may occur and the systems may be inoperable in areas where only one base station is available.

Wireless device 130 preferably includes both a voice and data interface, particularly where position determination system 134 is incorporated in a hands-free unit 132. The voice interface provides hands-free operation and speakerphone-like capabihties. The data interface allows position information obtained by system 134 to be provided to handset 130 for transmission over wireless network 140. Moreover, where voice recognition or speech synthesis capabilities are provided (discussion below), the data interface provides the data to be synthesized into speech or the data received via voice recognition.

Handset 130 communicates with other entities via wireless network 140. Network 140 is typically comprised of a plurality of base stations that provide relay points for communication. Network 140 may be a cellular, PCS, GSM, or any other wireless communication network. In addition to conventional communication with other wired or wireless communication devices, as shown in Figure 2, network 140 permits communication between handset 130 and data server(s) 136. When a user requests information, handset 130 provides the location of the' handset to server 136 across wireless network 140. Server 136 retrieves relevant information from an associated database 138 and conveys the information to handset 130 over wireless network 140. The information may be displayed on the handset display or audibly rendered via speech synthesis or prerecorded scripts. Although the type of information stored in database 138 is virtually limitless, several example applications are provided for illustrative purposes. In one example application, driving directions to a destination address are provided to a handset user. The user requests driving directions to the destination via keypad entry and/or voice command, and the request is cornmunicated to server 136 over wireless network 140. At the time of the request, the handset location deteirnined by position determination system 134 is also provided to server 136 to provide a starting point for the directions. Using the handset location and the destination address, server 136 calculates a route and compiles driving directions. The driving directions are transmitted to handset 130 over network 140 and are displayed or audibly rendered to the user. In addition to textual driving directions, a map showing the route may be displayed on the handset display. Options such as the shortest possible route, interstate route, safest route, most scenic route, etc. may be provided. The user's choice of options will dictate the route calculation. The options may be stored locally and prompts or scripts generated in the memory of handset 130. Alternatively, the options, prompts and scripts may be stored at server 136 and provided to the user via network 140.

Another example application locates particular types of businesses or services in the user's location. Restaurants, gas stations, hotels and other businesses or services near the user's location can be identified and provided to the user. Again, the user requests the business or service type vocally or via keypad entry. The request is communicated to server 136 over wireless network 140, along with the user's current location as determined by the position determination system 134. Server 136, based on the handset location and user request, retrieves and returns relevant information to handset 130 over network 140.

Parameter limits or filters may be implemented to refine the request and selections returned.

The user may set a location filter, for example, that requires returned selections be within a certain maximum number of miles of the user's current location. If the user is seeking a restaurant, the user may request or be prompted to select parameters that refine the search results. These parameters may include cuisine type (e.g., Italian, French, American, etc.), restaurant type (e.g., fast food, casual dining, formal, etc.), price range and so on. Additionally, for restaurants, gas stations, motels and other businesses, the user may identify a preferred national or regional chain. Alternatively, the user may have a preferences profile stored in the Web server 136 that contains this information.

As noted above, the search may be refined (the query narrowed) on the user's own initiative or based on system prompts. If the user simply requests a nearby restaurant, for example, server 136 may prompt the user with questions about parameters such as those described above. Alternatively, to conserve bandwidth over network 140, prompts can be stored locally and made by handset 130 (or hands-free unit 132) before the request is sent to server 136. In this embodiment, updated scripts and/or prompts may be downloaded from server 136 to handset 130. Preferably, memory-intensive data such as establishment locations, driving directions, etc. are stored in database 138 to minimize the amount of memory required in handset 130. The precise distribution of data storage among these devices will be influenced by factors such as available bandwidth, memory costs and airtime costs.

The user may also specify avoidance of certain areas or parts of town, such as those that have high crime rates, gang or drug activity, or other undesirable attributes. Crime statistics from law enforcement authorities or other sources can be compiled and stored in database 138. Based on these statistics, certain areas or neighborhoods may be identified as high crime rate areas or otherwise undesirable areas. The user may opt to not receive choices for establishments in, or driving directions through, those areas. This feature can be implemented automatically, as a default selection or through a user prompt. Alternatively, the system may provide an automatic warning sound or indication to alert the user of entry into a high-crime-rate area. This feature is particularly useful if the user is unfamiliar with a particular area in which he or she is travelling. A method for requesting information across network 140 is illustrated in Figure 3. In step 202, a user initiates a request for information. As described above, this request can be made via a keypad entry or by voice command with an appropriate voice recognition system. In step 204, the system determines whether the request requires the handset location or position. If all information is based on positional information, this step can be eliminated on the assumption that answering any request requires positional information. Since many requests may be fulfilled based on previously transmitted position information or without any position information at all, however, inclusion of step 204 is preferable to avoid unnecessary transmission of position information over network 140.

If position information is required, the method proceeds from step 204 to step 212, where position determination device 134 acquires the position of handset 130. In one implementation, position determination occurs regularly while handset 130 (or hands-free unit 132) is powered on.

If position determination device 134 is situated in hands-free unit 132, unit 132 provides the position data to handset 130 for transmission to server 136 over wireless network 140 (step 214).

If position information is not required, the method proceeds from step 204 directly to step 206.

In step 206, handset 130 sends the request to server 136 via wireless network 140. The request includes any position data acquired in steps 212-214. In step 208, server 136 retrieves the data or information requested from database 138. The data may be retrievable and usable in raw form, or it may need to be processed. This determination is based on the type of request, the information requested, and the manner or format in which the information is stored in database 138. The raw or processed data is communicated to handset 130 over network 140 and, in step 210, is displayed or provided to the user.

As described above, scripts or prompts may be provided to the user to refine the information request. If the scripts or prompts are stored in database 138 (as opposed to local storage in handset 130), they are retrieved by server 136 in step 208 and provided to the user in step 210. The user's answers to the prompts are sent by handset 130 to server 136, which uses the refined information to retrieve additional data or information from database 138, or to further refine the user's query. This potentially repetitive process is illustrated in Figure 3 by flow line 222 and the repetition of steps 202, 206 and 208. During this repetitive prompting process, depending on time elapsed and distance traveled, updated position information may be provided to server 136. If the refining prompts are stored locally in device 130 or unit 132, refinement occurs before the query is sent and this repetitive process will not usually be necessary.

Once the request has been sufficiently refined, server 136 uses the refined request to retrieve data from database 138. Continuing with the examples described above, server 136 may retrieve locations of restaurants, gas stations, hotels, or other facilities or services near the user. In one implementation, the information is listed or ranked in order of best matches to the user's request and/or preferences. The listing of facilities or services matching the request is provided to handset 130 over network 140 as shown in step 208, and the information is audibly or visually provided to the user as illustrated in step 210. If the information is provided audibly, audio data can be prerecorded or synthesized by server 136 and transmitted over network 140, or data can be sent across network 140 and speech synthesized locally.

Once the user selects a facility or service from the list of options provided, server 136 can retrieve or compute driving directions to the facility or service based on the user's current position. If sufficient time has elapsed to significantly alter the user's current position, server 136 may request a position update. In one implementation, a speed of travel parameter is provided by handset 130 along with the current position. In this implementation, the determination of whether to update the position information can be based in part on this parameter. Where the user is traveling at a high, rate of speed, positional updates will be required often to ensure accurate directions. Additionally, where the user is approaching a freeway exit or other waypoint in the route being computed, server 136 may request a position update to ensure that this waypoint has not been passed. If it has been passed, an alternative route may be calculated or the user may be directed to backtrack to the passed waypoint.

4. Converting HTML/XML to HDML WML

Figure 4 portrays an extension of the previously described Figure 2 environment. In Figure 4, an example configuration is shown that depicts a mobile unit 100 connected to the Web 150 through server 136 and wireless network 140. Additionally shown in Figure 4 are four separate example illustrations of database 138. In one embodiment, database 138A contains information relating to the display properties and processing capabihties of mobile unit 100. Database 138B preferably contains information relating to the preferences of a user of mobile unit 100 while database 138C preferably contains conversion specifications for the translation of HTML XML data to HDML/WML. Finally, in this embodiment, database 138D contains HTML/XML documents from the Web that have been cached at the server 136 for future access.

The process that converts HTML/XML to HDML/WML begins with mobile unit 100 requesting information from the Web 150. This request is initiated by the user of mobile unit 100 and is transmitted to server 136 over wireless network 140 as described in the previously referenced Sending Local Information Patent. In an alternative embodiment, the request can be initiated automatically by the mobile unit. In addition to the URL that comprises the request for information from the Web 150, the request further includes certain information regarding the mobile unit 100 and the requesting user of the mobile unit 100. This device and user information corresponds to more detailed information located in database 138A and 138B, respectively. For example, the device information included in the request may uniquely identify the mobile unit 100 as the NeoPoint 1000 digital cellular telephone by using the moniker "NP1K." Corresponding information in database 138A, however, illuminates all of the features and characteristics specific to that device. Such information may include, but is not limited to, transmit and receive frequencies, interoperability standards, safety requirements, encryption specifications, weight, LCD dimensions, keypad features, button and knob features, flip features, microphone and earpiece characteristics, antenna specifications, internal clock information, battery type, memory capabilities, browser type, application support, and Short Messaging Service ("SMS") capabilities, internal processor specifications, and Over the Air Service Prograrnming capabilities, to name just a few.

Related information about the user of the mobile can advantageously be maintained in database 138B. The user of the mobile unit 100 is preferably identified by a shortened label, in a fashion similar to the identification of the mobile unit 100. Examples of information about the user that can be stored in database 138B include but are not limited to full name, age, sex, marital status, preferred airline and seating arrangements, preferred fueling stations and fuel requirements (e.g. diesel, gasoline, propane, electric), .credit card number(s), preferred restaurants and cuisine types, and the last recorded location of the user's mobile unit.

Turning to Figure 5, an example of a process for converting HTML/XML to HDML/WML is portrayed in flowchart form. As described above, the process is initiated by the mobile unit 100 sending a request to the server 136 in step 220. Once the server 136 has received a request from mobile unit 100, the server 136 retrieves the requested document from the Web 150 as illustrated in step 222. The document retrieved from the Web 150 by the server 136 corresponds to the URL sent by the mobile unit 100, as is well known in the art. The process used by the server 13*6 to retrieve the requested KTML/XML document is similarly well known to those having ordinary skill in the art.

In step 224, the server 136 fetches the user preferences and/or user profile information from database 138B. For example, an incoming request might preferably contain separate keys that uniquely identify the user of the mobile unit, the' mobile unit itself, and the requested URL. Therefore, in this example embodiment, the server 136 parses the mcoming request from mobile unit 100. After parsing the request, the server 136 performs a lookup in database 138B using the unique user key. In this fashion, the server 136 retrieves the user preferences and/or user profile information from database 138B.

In a similar fashion, the server 136 fetches the device characteristics and specifications from database 138 A as illustrated in step 226. Preferably, the characteristics and specifications are maintained and updated on an on-going basis to encompass the most recent upgrades and newer models of mobile units. In an alternative embodiment, the server 136 fetches the device characteristics and specifications from database 138A prior to fetching the user profile and preferences from database 138B. Additionally, in a multitasking multiprocessing embodiment, the server 136 may simultaneously fetch the user profile and preferences and the device characteristics and specifications from their respective databases. Moreover, to decrease response time, the database fetches can be carried out simultaneously with the retrieval of the requested HTML/XML document.

Based on the retrieved user preferences, device specifications, and content type of the HTML/XML document, the server 136, in step 228, fetches the appropriate conversion specification or specifications from database 138C. For example, different mobile devices may have different display characteristics and the ability to display more or less rows and columns of characters. Additionally, the content of the HTML/XML document may contain multiple images with differing image file formats. The color depth of the images may vary while the mobile unit 100 may only have the capability to display images in gray scale.

Continuing the^' example, the content of the .HTML/XML document may contain frames and tables. The text in the HTML/XML document may contain varied formatting such as boldface type, different font types, and different font sizes. The content of the HTML/XML document may utilize radio buttons, popup menus, or on-focus user interface options. Finally, the content of the HTML/XML document may include scripts or applets that are not supported by a mobile unit. Therefore, depending on the preferences of the individual user, the characteristics of the display device, and the content of the retrieved HTML/XML document, the server 136 fetches the appropriate conversion specification or specifications from database 138C.

The conversion specifications contain abstracts of the desired data contained in the

HTML/XML document. As discussed above, the content of an HTML/XML Web document may contain certain user interface elements that are not compatible with the mobile unit's 100 display.

Thus, the conversion specifications relate the germane information from the HTML/XML structures to the necessary context for display on the mobile unit's 100 display.

Once the conversion specifications have been selected, in step 230 the server 136 converts the native HTML/XML document into its corresponding HDML/WML counterpart. Once the HTML/XML document has been converted, the resulting I-DML/WML is optimized in step 232. For example, to take maximum advantage of the wireless communications network and the processing power of the mobile unit, the optimization step reduces the size of the transmission to the mobile device. Additionally, according to the specifications and characteristics of the mobile device, the optimization step formats the display size of the HDML/WML cards and decks to utilize the entire display of the mobile unit 100. Finally, as shown in step 234, the optimized HDlvrL/WML is tokenized and sent to the mobile unit 100 over wireless network 140.

The tokenizing of the HDML/WML is a process that is well known in the art. The function of tokenizing is to reduce the number of bytes required for transmission over the wireless network

140. This is accomplished by substituting well known and pre-defined character sets with numeric tokens. For example, a subset of HDML/WML code might look like the following:

<wml>

<card id="abc" ordered="true"> <p>

<do type="accept">

<go href=" ttp://xyz.org/s"/> </do>

X.: $(X)<br/> Y: $(&#x59;)<br/>

Enter name: <input type="text" name="N"/> </p> </card> </ ml>

The corresponding tokenized form of the above example (with numbers in hexadecimal form) might look like the following:

01 04 6A 04 'X* 00 'Y' 00 7F E7 21 03 'a¹ 'b' 'c¹ 00

33 01 20 E8 38 01 AB 4B 03 'X' ^• •y^{i •}z' 00 88 03

^•s' 00 01 03 1 . 1 'X' l . l 1 1 00 82 00 26 03 1 t ιγι

1 . t t I 00 82 02 .28 03 1 1 ^•E¹ 'n' ^■t' ^■e' ι_rι 1 1 ^■n'

^■a' ^• ' 'e' 1 . t 1 1 00 AF 48 18 03 ^•N" 00 01 01 01

The above condensed form of the HDML/WML code is annotated in the following table:

A flowchart of an example process for converting HTML/XML to HDML/WML is illustrated in Figure 6. This process is an expansion of the previously described step 230. initially, in step 240 the content of the HTML/XML document is parsed by the server 136. This parsing separates the content mto corresponding key - value pairs. These pairs represent the format and the context of the elements that comprise the HTML/XML document. For example, a sample set of

HTML/XML code might look like the following:

<html>

<head>

<title>EdgeMail : POP Manager</title> </head> <body>

<TABLE IDTH=520 cellpadding=l cellspacing=0 border=0> <TR>

<TD width=50%xFONT FACE=ARIAL>Flight #l</FONTx/TD>

<TD align=right width=50%xFONT FACE=ARIALxB>Departure Date: </Bx/FONTx/TD>

<TD align=left widt =50%><FONT FACE=ARIAL>Nov 19, 1999</FONTx/TD> </TR> </TABLE> </body> </html>

Continuing the example, the corresponding key - value pairs to the above sample code might look like the following:

ROOT.htmll .headl .titlel .textl EdgeMail: POP Manager

ROOT.htmll.headl.stylel.type text ess

ROOT.htmll. headl. stylel. textl Span.c2 {font-family: ARIAL} td.cl

ROOT.htmll. body l.tablel. border 0

ROOT.htmll .body 1.table 1.cellspacing 0

ROOT.htmll. body l.tablel. cellpadding 1

ROOT.htmll .body 1.tablel .width 520

ROOT.htmll .body 1.tablel .trl.tdl .class cl

ROOT.htmll .bodyl .tablel .trl .tdl .width 50%

ROOT.htmll. body l.tablel. trl.tdl. textl Flight #1 ROOT.htmll .body 1.tablel .trl .td2.width 50%

ROOT.htmll .body 1.tablel .trl .td2.align Right

ROOT.htmll .body 1.tablel .trl .td2.spanl .class c2

ROOT.htmll.bodyl.tablel.trl.td2.sρanl.bl.textl Departure Date:

ROOT.htmll .body 1.tablel .trl .td3.class cl

ROOT.htmir.bodyl.tablel.trl.td3.width 50%

ROOT.htmll.bodyl.tablel.trl.td3.align left

After the HTML/XML code has been parsed into its constituent key - value pairs, the server 136 filters out the non-essential content. This filtering process is based on the specifications and characteristics of the mobile unit. For example, if the mobile unit does not have the ability to display graphics, the filtering process of step 242 substitutes the text corresponding to the graphic and thus filters out the graphical elements of the content. In a preferred embodiment, the server 136 similarly filters out unnecessary textual items. For example, all comments can be removed. Additionally, textual data in tabular format can be reformatted into lists. Continuing the example, a very large table can be converted into multiple lists. Long textual entries can be converted into multiple cards in the HDML/WML deck. Alternatively, for a mobile unit that has the ability to display graphics, the image size can be reduced, the image file format can be converted to a format supported by the mobile unit, and the color depth can be optimized for display on the mobile device. In this fashion, the server 136 filters out the unnecessary content from the key - value pairs.

Next, in step 244, the server 136 converts the key - value pairs into HDML/WML. For example, the tables that were converted to lists above are formatted in HDML/WML structures such that the lists correspond to cards in an HDML/WML deck. In a preferred embodiment, the server 136 recognizes the context of each element of the filtered content by the nature of the key - value pair for that element. Thus, the server 136 restructures the filtered elements into HDML/WML by wrapping those elements in the corresponding code segments for the HDML/WML card and deck paradigm. For example, the above referenced key - value pairs are the following: ROOT.htmll .headl .titlel .textl EdgeMail: POP Manager

ROOT.htmll .headl .style 1.type text/ess

ROOT.htmll .headl .stylel .textl Span.c2 {font-family: ARIAL} td.cl

ROOT.htmll .body 1.tablel .border 0

ROOT.htmll.bodyl.tablel.cellspacing 0

ROOT.htmll.bodyl.tablel.cellpadding 1

ROOT.htmll .body l.tablel. width 520

ROOT.htmll .body 1.tablel .tr 1 rtdl .class cl

ROOT.htmll .body 1.tablel .trl .tdl .width 50%

ROOT.htmll .bodyl .tablel .trl .tdl .textl Flight #1

ROOT.htmll .body 1.tablel .trl .td2.width 50%

ROOT.htmll .bodyl .tablel .trl .td2.align Right

ROOT.htmll .body 1.tablel .trl .td2.sρanl .class c2

ROOT.htmll .bodyl .tablel .trl .td2.spanl .b 1.textl Departure Date:

ROOT.htmll .body l.tablel .trl .td3. class cl

ROOT.htmll .body 1.tablel .trl .td3.width 50%

ROOT.htmll .body 1.table 1.trl .td3.align left

After conversion into HDML/WML, these key - value pairs may look like:

<wml>

<card>

<p mode="nowrap" />Flight #l : </p>

<p raode="nowrap" />Departure Date : Nov 19 , 1999</p> </card> </wml>

After this conversion process, the resulting HDML/WML code is optimized as described above with reference to step 232. Finally, as described above with reference to step 234, the optimized HDML/WML code is tokenized for reduction in transmission size and sent to the waiting mobile unit 100 for display to the user of the wireless communications device.

While the particular method of converting HTML/XML to HDML/WML in real-time for display on wireless communication devices herein shown and described in detail is fully capable of attaining the above described objects of this invention, it is to be understood that the description and drawings represent the presently preferred embodiment of the invention and are, as such, a representative of the subject matter which is broadly contemplated by the present invention. Jt is further understood that the scope of the present invention fully encompasses other embodiments that may become obvious to those skilled in the art, and that the scope of the present invention is accordingly limited by nothing other than the appended claims.

Claims

What is claimed is:

1. A method for converting HTML/XML to HDML/WML comprising the steps of: at the mobile unit, sending a request to a proxy server; at the proxy server, retrieving the requested HTML/XML document from the Web, retrieving a conversion specification, retrieving mobile unit device information, extracting needed data from the HTML/XML document, format the extracted data in HDML/WML, optimizing the HDML/WML data for transmission, and transmitting the HDML/WML data to the mobile unit for display.

2. The method of claim 1 wherein said request contains information pertaining to the mobile device.

3. The method of claim 1 wherein the proxy server retrieves the requested HTML/XML document from local cache.

4. A method for a Web server to convert HTML/XML to HDML/WML comprising the steps of: retrieving a requested HTML/XML document from the Web; parsing the HTML/XML code to generate key/value pairs; filtering the key/value pairs into the relevant subset; translating the key/value pairs into HDML/WML card/deck pairs; and tokenizing the HDML/WML card/deck pairs.

5. The method of claim 4 wherein said request is sent by a wireless commuriications device and said request comprises: a Uniform Resource Locator; a key that uniquely identifies said wireless communications device; and a key that uniquely identifies the user profile of said wireless communications device.

6. The method of claim 5 wherein the Web server retrieves said requested HTML/XML document from local cache.