Techniques for programming event-driven transactions in mobile applications

Abstract

Techniques for interacting with a client process on a mobile device connected to a network over a wireless link include receiving, at a mobile interactions server, a first message from the client process. The first message indicates a first action by a user of the mobile device. The first action is related to a first graphical element displayed on the device for requesting a service from an application. Based on the first message, it is determined whether the action is associated with an event type of a plurality of predetermined event types. If it is determined the action is not associated with the event type, then, without invoking any method of the application, first data is generated. The first data describes any change in the first graphical element. The first data is sent to the client process for changing the display of the first graphical element.

Claims

What is claimed is:

1. A method of interacting with a client process on a mobile device connected to a network over a wireless link, the method comprising the steps of:

receiving at a mobile interactions server a first message from the client process indicating a first action by a user of the mobile device, the first action related to a first graphical element displayed on the device for requesting a service form an application;

based on the first message, determining whether the action is associated with an event type of a plurality of predetermined event types; wherein each of the predetermined event types corresponds to one or more application-specific event objects used for invoking a specific method of the application;

if it is determined the action is not associated with the event type, then, without invoking any method of the application,

generating first data describing any change in the first graphical element; and

sending the first data to the client process for changing the display of the first graphical element.

2. The method of claim 1, further comprising, if it is determined the action is associated with the event type, then performing the steps of:

generating second data describing a particular event of the event type;

invoking a particular event handling method of the application to provide the service, the particular event handling method associated with the event type; and

passing the second data to the event handling method.

3. The method of claim 1, further comprising, before said step of receiving the first message, the steps of:

receiving second data from the application describing the first graphical element and indicating one or more event handling methods associated with the first graphical element; and

passing the second data to the client process for displaying the first graphical element.

4. The method of claim 3, wherein each of the one or more event handling methods is associated with one event type of the plurality of predetermined event types.

5. The method of claim 2, wherein the particular event handling method is associated with one event type of the plurality of predetermined event types.

6. The method of claim 5, wherein a name of the particular event handling method indicates the one event type with which it is associated.

7. The method of claim 2, wherein the particular event handling method is associated with the first graphical element.

8. The method of claim 1, wherein the plurality of predetermined events types does not include an event type associated with the user of the mobile device pressing a character key.

9. The method of claim 1, wherein the plurality of predetermined event types includes an exit-graphical-element event type and an enter-graphical-element event type.

10. The method of claim 9, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to one of moving a cursor from the first graphical element and pressing an enter key; and

if the first action does correspond to one of moving the cursor from the first graphical element and pressing the enter key, then the first action is associated with the exit-graphical-element event type.

11. The method of claim 9, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to moving a cursor onto the first graphical element; and

if the first action does correspond to moving the cursor onto the first graphical element, then the first action is associated with the enter-graphical-element event type.

12. The method of claim 1, wherein

the first graphical element is included in a page of one or more graphical elements associated with requesting the service from the application; and

the plurality of predetermined event types includes an exit-page event type and an enter-page event type.

13. The method of claim 12, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to pressing an enter key on a graphical element associated with a reference to a different page; and

if the first action does correspond to pressing the enter key on the graphical element associated with the reference to the different page, then the first action is associated with the exit-page event type and the enter-page event type.

14. The method of claim 12, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to pressing an enter key on a last graphical element on the page; and

if the first action does correspond to pressing the enter key on the last graphical element on the page, then the first action is associated with the exit-page event type.

15. The method of claim 1, wherein

the first graphical element is included in a page of one or more graphical elements associated with requesting the service from the application; and

the plurality of predetermined event types includes an special-key-pressed event type.

16. The method of claim 15, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to one of pressing a page-back key, pressing a page-forward key and pressing a menu key; and

if the first action does correspond to one of pressing a page-back key, pressing a page-forward key and pressing a menu key, then the first action is associated with the special-key-pressed event type.

17. The method of claim 1, wherein the plurality of predetermined event types includes an exit-application event type and an enter-application event type.

18. The method of claim 17, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to pressing an enter key on a graphical element associated with a main menu item; and

if the first action does correspond to pressing the enter key on the graphical element associated with the main menu item, then the first action is associated with the enter-application event type.

19. The method of claim 17, wherein:

the first graphical element is included in a page of one or more graphical elements associated with requesting the service from the application;

the application includes one or more pages; and

said step of determining whether the action is associated with an event type further comprising

determining whether the first message indicates the first action corresponds to pressing an enter key on a last graphical element on a page without a reference to a different page; and

if the first action does correspond to pressing the enter key on the last graphical element on the page without the reference to the different page, then the first action is associated with the exit-application event type.

20. The method of claim 2, further comprising, if the particular event handling method determines no more pages of one or more graphical elements are to be provided by the application, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for exiting the application.

21. The method of claim 2, further comprising, if the particular event handling method determines a request is to be made to a network resource having a particular URL address, then receiving third data indicating a particular exception and the URL address in a particular event exception handling method of the mobile interactions server for sending the request to the network resource.

22. The method of claim 2, further comprising, if the particular event handling method determines not to complete processing of the particular event, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for skipping all remaining event handling methods for the particular event.

23. The method of claim 2, further comprising, if the particular event handling method determines not to complete processing of the particular event, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for invoking all remaining event handling methods of the application for the particular event.

24. The method of claim 2, further comprising, if the particular event handling method determines not to complete processing of the particular event, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for invoking only the event handling methods of the mobile interactions server for the particular event.

25. The method of claim 2, wherein the particular event handling method inherits from a first event handling interface provided by the mobile interactions server, the first event handling interface defining the plurality of event types.

26. The method of claim 25, wherein the first event handling interface inherits from a JAVA event handling interface.

27. A method of interacting with a client process on a mobile device connected to a network over a wireless link, the method comprising the steps of:

sending from an application to a mobile interactions server first data describing a first graphical element for displaying on the mobile device and one or more event handling methods of the application associated with the first graphical element;

receiving at a particular event handling method of the plurality of event handling methods second data describing an event having a particular event type of a plurality of predetermined event types in response to an action by a user of the mobile device; wherein each of the predetermined event types corresponds to one or more application-specific event objects used for invoking a specific method of the application; and

providing a service for the client process in response to receiving the second data, wherein

the particular event handling method is associated with the particular event type, and

the action is determined by the mobile interactions server to be associated with the particular event type.

28. The method of claim 27, the method further comprising the steps of:

determining whether to invoke an exception handling method of the mobile interactions server; and

if it is determined to invoke the exception handling method, then sending third data describing a particular exception to the exception handling method.

29. The method of claim 28, wherein the particular exception is associated with no more pages of one or more graphical elements for the client process.

30. The method of claim 28, wherein the particular exception is associated with redirecting the mobile interactions server to a network resource having a particular URL address.

31. The method of claim 28, wherein the particular exception is associated with aborting all event handlers for the event.

32. The method of claim 28, wherein the particular exception is associated with interrupting the particular event handler for the event.

33. The method of claim 28, wherein the particular exception is associated with invoking only an event handler of the mobile interactions server for the event.

34. A computer-readable storage medium carrying instructions for interacting with a client process on a mobile device connected to a network over a wireless link, the computer readable medium comprising instructions for causing one or more processors to perform the steps of:

receiving over the network a first message from the client process indicating a first action by a user of the mobile device, the first action related to a first graphical element displayed on the device for requesting a service form an application;

based on the first message, determining whether the action is associated with an event type of a plurality of predetermined event type; wherein each of the predetermined event types corresponds to one or more application-specific event objects used for invoking a specific method of the application;

if it is determined the action is not associated with the event type, then, without invoking any method of the application,

generating first data describing any change in the first graphical element; and

passing the first data to the client process for changing the display of the first graphical element.

35. The computer-readable medium of claim 34, the instructions further causing the one or more processors to perform the step of, if it is determined the action is associated with the event type, then:

generating second data describing a particular event of the event type;

invoking a particular event handling method of the application to provide the service, the particular event handling method defined for the event type; and

passing the second data to the event handling method.

36. The computer-readable medium of claim 34, the instructions further causing the one or more processors to perform the step of, before said step of receiving the first message:

receiving second data from the application describing the first graphical element and indicating one or more event handling methods associated with the first graphical element; and

passing the second data to the client process for displaying the first graphical element.

37. The computer-readable medium of claim 36, wherein each of the one or more event handling methods is associated with one event type of the plurality of predetermined event types.

38. The computer-readable medium of claim 35, wherein the particular event handling method is associated with one event type of the plurality of predetermined event types.

39. The computer-readable medium of claim 38, wherein a name of the particular event handling method indicates the one event type with which it is associated.

40. The computer-readable medium of claim 35, wherein the particular event handling method is associated with the first graphical element.

41. The computer-readable medium of claim 34, wherein the plurality of predetermined events types does not include an event type associated with the user of the mobile device pressing a character key.

42. The computer-readable medium of claim 34, wherein the plurality of predetermined event types includes an exit-graphical-element event type and an enter-graphical-element event type.

43. The computer-readable medium of claim 42, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to one of moving a cursor from the first graphical element and pressing an enter key; and

if the first action does correspond to one of moving the cursor from the first graphical element and pressing the enter key, then the first action is associated with the exit-graphical-element event type.

44. The computer-readable medium of claim 42, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to moving a cursor onto the first graphical element; and

if the first action does correspond to moving the cursor onto the first graphical element, then the first action is associated with the enter-graphical-element event type.

45. The computer-readable medium of claim 34, wherein

the first graphical element is included in a page of one or more graphical elements associated with requesting the service from the application; and

the plurality of predetermined event types includes an exit-page event type and an enter-page event type.

46. The computer-readable medium of claim 45, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to pressing an enter key on a graphical element associated with a reference to a different page; and

if the first action does correspond to pressing the enter key on the graphical element associated with the reference to the different page, then the first action is associated with the exit-page event type and the enter-page event type.

47. The computer-readable medium of claim 45, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to pressing an enter key on a last graphical element on the page; and

if the first action does correspond to pressing the enter key on the last graphical element on the page, then the first action is associated with the exit-page event type.

48. The computer-readable medium of claim 34, wherein

the first graphical element is included in a page of one or more graphical elements associated with requesting the service from the application; and

the plurality of predetermined event types includes an special-key-pressed event type.

49. The computer-readable medium of claim 48, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to one of pressing a page-back key, pressing a page-forward key and pressing a menu key; and

if the first action does correspond to one of pressing a page-back key, pressing a page- forward key and pressing a menu key, then the first action is associated with the special-key-pressed event type.

50. The computer-readable medium of claim 34, wherein the plurality of predetermined event types includes an exit-application event type and an enter-application event type.

51. The computer-readable medium of claim 50, said step of determining whether the action is associated with an event type further comprising:

determining whether the first message indicates the first action corresponds to pressing an enter key on a graphical element associated with a main menu item; and

if the first action does correspond to pressing the enter key on the graphical element associated with the main menu item, then the first action is associated with the enter-application event type.

52. The computer-readable medium of claim 50, wherein:

the first graphical element is included in a page of one or more graphical elements associated with requesting the service from the application;

the application includes one or more pages; and

said step of determining whether the action is associated with an event type further comprises

determining whether the first message indicates the first action corresponds to pressing an enter key on a last graphical element on a page without a reference to a different page; and

if the first action does correspond to pressing the enter key on the last graphical element on the page without the reference to the different page, then the first action is associated with the exit-application event type.

53. The computer-readable medium of claim 35, the instructions further causing the one or more processors to perform the step of, if the particular event handling method determines no more pages of one or more graphical elements are to be provided by the application, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for exiting the application.

54. The computer-readable medium of claim 35, the instructions further causing the one or more processors to perform the step of, if the particular event handling method determines a request is to be made to a network resource having a particular URL address, then receiving third data indicating a particular exception and the URL address in a particular event exception handling method of the mobile interactions server for sending the request to the network resource.

55. The computer-readable medium of claim 35, the instructions further causing the one or more processors to perform the step of, if the particular event handling method determines not to complete processing of the particular event, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for skipping all remaining event handling methods for the particular event.

56. The computer-readable medium of claim 35, the instructions further causing the one or more processors to perform the step of, if the particular event handling method determines not to complete processing of the particular event, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for invoking all remaining event handling methods of the application for the particular event.

57. The computer-readable medium of claim 35, the instructions further causing the one or more processors to perform the step of, if the particular event handling method determines not to complete processing of the particular event, then receiving third data indicating a particular exception in a particular event exception handling method of the mobile interactions server for invoking only the event handling methods of the mobile interactions server for the particular event.

58. The computer-readable medium of claim 35, wherein the particular event handling method inherits from a first event handling interface provided by the mobile interactions server, the first event handling interface defining the plurality of event types.

59. The computer-readable medium of claim 58, wherein the first event handling interface inherits from a JAVA event handling interface.

60. A computer-readable storage medium carrying instructions for interacting with a client process on a mobile device connected to a network over a wireless link, the computer-readable medium comprising instructions for causing one or more processors to perform the steps of:

sending to a mobile interactions server first data describing a first graphical element for display on the mobile device an one or more event handling methods of the application associated with the first graphical element;

receiving at a particular event handling method of the plurality of event handling methods second data describing an event having a particular event type of a plurality of predetermined event types in response to an action by a user of the mobile device; wherein each of the predetermined event types corresponds to one or more application-specific event objects used for invoking a specific method of the application; and

providing a service for the client process in response to receiving the second data, wherein

the particular event handling method is associated with the particular event type, and

the action is determined by the mobile interactions server to be associated with the particular event type.

61. The computer-readable medium of claim 60, the instructions further causing the one or more processors to perform the steps of:

determining whether to invoke an exception handling method of the mobile interactions server; and

if it is determined to invoke the exception handling method, then sending third data describing a particular exception to the exception handling method.

62. The computer-readable medium of claim 61, wherein the particular exception is associated with no more pages of one or more graphical elements for the client process.

63. The computer-readable medium of claim 61, wherein the particular exception is associated with redirecting the mobile interactions server to a network resource having a particular URL address.

64. The computer-readable medium of claim 61, wherein the particular exception is associated with aborting all event handlers for the event.

65. The computer-readable medium of claim 61, wherein the particular exception is associated with interrupting the particular event handler for the event.

66. The computer-readable medium of claim 61, wherein the particular exception is associated with invoking only an event handler of the mobile interactions server for the event.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. patent application Ser. No. 09/872,066, filed May 31, 2001 entitled "Maintaining State Information in Mobile Applications," by Jyotirmoy Paul, Jeff Barton, Anit Chakraborty and Siva Dirisala.

This application is related to U.S. patent application Ser. No. 09/872,986, filed May 31, 2001 entitled "Techniques for Navigating in Mobile Applications," by Jyotirmoy Paul, Jeff Barton, Anit Chakraborty and Siva Dirisala.

This application is related to U.S. patent application Ser. No. 09/872,566, filed May 31, 2001 entitled "Techniques for Supporting Multiple Devices in Mobile Applications," by Jyotirmoy Paul, Jeff Barton, Anit Chakraborty and Siva Dirisala.

FIELD OF INVENTION

The present invention generally relates to network-based services for mobile, wireless devices. The invention relates more specifically to performing complex transactions for a network-based service using an event-driven interface.

BACKGROUND OF THE INVENTION

Society is becoming increasingly reliant on network-based services. Network-based services are any services provided to devices over a network. Common network-based services include, for example, services provided over the World Wide Web, database services, etc.

Services provided over the World Wide Web are typically presented in the form of one or more web pages. A web page is data expressed in a HyperText Markup Language (HTML) and transferred over a network using the hypertext transfer protocol (HTTP) of the Internet protocol (IP). The network can be a local network, a wide area network, or the Internet itself, a public network of computer networks.

Database services may be provided by a database application, which in turn may access a database through services provided by a database server. A database application is a software application that communicates with a database server process on the network to store data into and retrieve data from a database.

According to the Internet protocol (IP), a program on one device connected to the network interacts with another program located on another device with asynchronous stateless messages. The two programs run independently and interact only through these messages. The messages are asynchronous in that each can take an arbitrary amount of time to travel from source device to destination device. Consequently, two successive messages may arrive out of order. The messages are stateless in that each message is sent, transmitted and received independently, without inheriting or relying on characteristics from any previous messages sent.

The program that initiates the communication is a client process, and the program that waits for and responds to a request from the client process is the server process. The term "client" is often used to refer to either the client process, or the machine on which the client process runs, or both. The term "server" is similarly used to refer to either the server process, or the machine on which the server process is executing, or both.

A widely used client process supported by many servers on the Internet is a browser. A browser communicates with servers to retrieve and decode data expressed in HTML. HTML marks portions of the data with tags related to the manner in which the portions are to be displayed.

Adding programs, referred to as plug-ins, to a browser can extend a browser's functionality. A browser that has added functionality due to one or more plug-ins is referred to herein as an extended browser. Extended browsers may, for example, use input forms into which the user can enter data that is validated in some regard before being sent back to the server. Standard HTML does not provide for this client side validation process.

Portable devices capable of wireless communications are finding ever more uses and popularity. Some of these mobile devices are able to connect to a network. It is desirable to make network-based services available for access by such network capable mobile devices.

When making network-based services available for mobile devices, one cannot count on the ability to use software designed for a general-purpose computer. The smallest laptops are too cumbersome for some uses, such as for wireless telephony and for warehouse inventory control. Handheld devices used by agents of an enterprise in the field for these uses have limited hardware and software due to constraints imposed by limited size and low power availability.

For example, screen size, memory and plug-in functionality on the handheld device may be significantly less than what is available through a browser on a laptop, so that a Web page easily viewed on a low-end laptop is essentially unintelligible on the mobile device. A network-based service cannot rely on a particular mobile device having a screen of a needed size or having the power to execute a full browser or to accept plug-ins, such as those that allow the browser to use forms.

Some of these small footprint handheld devices may not run a World Wide Web browser at all. For example, mobile telephones use a wireless application protocol (WAP), which does not respond to the full set of HTML tags. These devices use data presented in a wireless markup language (WML), a specific implementation of the extensible markup language (XML) using a WML-specific document type definition (DTD). Other handheld devices used in industry, such as bar code readers, communicate with a network using a teletype protocol (Telnet), which accepts or sends one character at a time, with little or no display options such as font size, font type, italics, and color, and without the capability for displaying images.

Even the keys vary from one mobile device to another. Some devices may have a full keyboard like that on a PC, others may have just a few keys. For example, a mobile telephone typically has a twelve-key keypad and one or more function keys for performing certain functions such as answering the telephone or dialing a call. It is extremely burdensome for an application to monitor and respond to user actions involving each key of each keypad arrangement.

Complex interactions, such as those involving shopping online or employing an expert system to diagnose symptoms of a problem, require many messages to be sent back and forth between a client process and one or more server processes. In some cases, a first process must pass along "state information" with a first message to a second process, so that the second process will pass the state information back in a subsequent message to the first process. The state information received by the first process in the subsequent message lets the first process know that the subsequent message is related to the same transaction as the first message.

Because there is a wide variety of mobile devices, with a wide range of screen sizes, colors, memory sizes, page buffers, processor types and client protocols, among other properties, it is generally cost prohibitive to try to duplicate all the functionality of a network-based service for each possible mobile device.

Based on the foregoing, there is a clear need for techniques that allow network-based services to be made readily available to a wide range of mobile devices or to support complex transactions, or both, without having to explicitly program each network-based service to support all forms of mobile devices. There is also a need for a way to insulate an application providing the network service from the details of handling every keystroke by the user or a mobile device.

SUMMARY OF THE INVENTION

Techniques are provided for interacting with a client process on a mobile device connected to a network over a wireless link. According to one aspect of the invention, the techniques include receiving at a mobile interactions server a first message from the client process. The first message indicates a first action by a user of the mobile device. The first action is related to a first graphical element displayed on the device for requesting a service from an application. Based on the first message, it is determined whether the action is associated with an event type of a plurality of predetermined event types. If it is determined the action is not associated with the event type, then, without invoking any method of the application, first data is generated. The first data describes any change in the first graphical element. The first data is sent to the client process for changing the display of the first graphical element.

According to one embodiment of this aspect, if it is determined that the action is associated with the event type, then second data is generated. The second data describes a particular event of the event type. A particular event handling method of the application is invoked to provide the service. The particular event handling method is associated with the event type. The second data is passed to the event handling method.

According to another embodiment, the plurality of predetermined events types does not include an event type associated with the user of the mobile device pressing a character key.

According to another aspect of the invention, the techniques include sending from an application to a mobile interactions server first data. The first data describes a first graphical element for display on the mobile device. The first data also describes one or more event handling methods of the application associated with the first graphical element. Second data is received at a particular event handling method of the plurality of event handling methods. The second data describes an event having a particular event type of a plurality of predetermined event types. The second data is received in response to an action by a user of the mobile device. A service is provided for the client process in response to receiving the second data. The particular event handling method is associated with the particular event type. The mobile interactions server determines whether the action is associated with the particular event type.

An advantage of these event handling techniques is that the application developer can employ the observer-observable paradigm for software development. In the observer-observable paradigm a program element deals only with observable objects and ignores other objects. The observer registers the objects that are to be observable and the system notifies the observer when an observable object is generated, changes, or terminates. As applied to mobile applications developers, the mobile application is built to observe events of certain predefined event types. Other events, such as those associated with the user pressing each character key while entering data into a text field, or the user moving a cursor up and down on a list, are not registered observables for the application; and the developer does not develop instructions to handle events associated with those actions. As implemented in several embodiments, the built-in methods of the mobile interactions server handle the intra-field actions, and most of the intra-page actions, by the user.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1A is a block diagram that illustrates one embodiment of a mobile applications server connected to a network with which a mobile device communicates over a wireless link.

FIG. 1B is a block diagram that illustrates a graphical object used by an embodiment of the mobile applications server 110 to interact with a mobile device.

FIG. 1C is a block diagram that illustrates an embodiment of an application comprised of a hierarchy of graphical objects and methods.

FIG. 1D is a block diagram that illustrates one embodiment of a mobile interactions server used in the mobile applications server of FIG. 1A.

FIG. 2A is a flowchart that illustrates one embodiment of a method for a mobile interactions server to respond to a client making an initial request for services.

FIG. 2B is a block diagram of a main menu on a screen of a mobile device produced in response to requesting applications from a mobile applications server.

FIG. 2C is a flowchart that illustrates one embodiment of a method for a mobile interactions server to respond to a subsequent action by a user of the client process.

FIG. 2D is a block diagram of an event object used by the mobile interactions server.

FIG. 3 is a block diagram that illustrates an embodiment of a data structure for storing session state information by the mobile applications server 110.

FIG. 4A is a flowchart that illustrates a method for handling a special key event.

FIG. 4B is a flow chart that illustrates exception handling methods of the mobile interactions server.

FIG. 5A is a diagram that illustrates an embodiment of a page on a display of a mobile device.

FIG. 5B is a diagram that illustrates an embodiment of a next page on a display of a mobile device.

FIG. 6A is a flowchart that illustrates one embodiment of a method for a device-sensitive presentation manager to prepare page output for a particular mobile device.

FIG. 6B is a flowchart that illustrates one embodiment of a method for an XML to protocol converter to manage page output for a particular mobile device.

FIG. 7 is a flowchart that illustrates one embodiment of a method for an application developer to utilize a mobile interactions server.

FIG. 8 is a block diagram that illustrates a computer system upon which an embodiment may be implemented.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Operational Context

To illustrate network applications interacting with mobile devices employing a wireless link, consider FIG. 1A. FIG. 1A is a block diagram that illustrates one embodiment of a mobile applications server 110 connected to a network 108 with which a mobile device 101 communicates over a wireless link 106.

The mobile device 101 includes a screen display 102, one or more keys 104 and a client process 103 running on a microprocessor (not shown) in the mobile device 101. Some mobile devices may include a sensor 105, such as a microphone or barcode reader. The mobile device 101 communicates with a base station 107 using a wireless link 106 that may be proprietary. Examples of wireless links include a local radio frequency link such as IEEE 802.11, a wide area radio frequency link, a satellite link, and a personal communication services (PCS) data link through a WAP Gateway.

The base station 107 is connected to the network 108. The base station 107 passes network message traffic between the client 103 and the servers on the network 108. The network 108 may be any network using an asynchronous stateless protocol like TCP/IP, including a local network, a private wide area network, or the Internet.

The mobile applications server 110 includes one or more processes executing on a machine connected to the network 108. According to one embodiment, the mobile applications server 110 provides functionality for the mobile device 101 beyond the functionality built into the processor and client 103 on board the mobile device itself.

In one embodiment, the mobile applications server 110 provides one or more applications 116 that may be used by a mobile device over the network 108. For example, assume that mobile device 101 is a device having a barcode reader as the sensor 105. Such a device may be used in conjunction with an inventory application to update an inventory database. The update may be performed by scanning the barcode on an item and pressing a key to indicate whether the item is being added to the inventory, or is being removed from the inventory due to damage, due to sale, or due to transport to another warehouse.

For another example, a database application for mobile device 101 having a microphone, such as a mobile phone, could identify the user of the mobile device based on a comparison of the user's voice with a voice print for the user. The voice print may be maintained in a database by a database server on the same platform as the mobile applications server 110 or some other server platform on the network 108.

The mobile applications server 110 may also provide non-database applications. For example, if the sensor 105 is a global positioning system (GPS), then the mobile application could compute the area walked off by a user carrying the mobile device 101 based on positions output from the sensor 105 and transmitted to the mobile applications server 110.

According to several embodiments, applications 116 on mobile applications server 110 interact with mobile device 101 through a mobile interactions server 150 in the applications layer. The network device on which mobile applications server 110 executes also includes processes that execute in a network layer, a transport layer, and a security layer that are not significantly modified by the invention and are not described further.

Overview of Functional Components

Referring to FIG. 1A, mobile applications server 110 is one or more processes executing on a computing device connected to the network 108 that provides services for a mobile device 101 in response to one or more requests for services from the client process 103 executing on the mobile device 101.

Mobile applications server 110 includes one or more applications 116. In general, an application is a set of instructions that can be called to cause one or more processors to perform a series of related tasks for providing a requested service. An application often requires input data and produces output data. An application often comprises one or more methods that can be invoked separately each with their own input and output.

Many ways of producing applications are known in the art. For example, in one embodiment, the application is a package of JAVA classes containing public methods that can be invoked separately by the name of the method and the name of the class. Input for each public method is provided as one or more data structures called parameters and output is provided as a returned data structure. The names of the public methods, and the names and definitions of the input and returned data structures are published as an application programming interface (API). In another embodiment, the application is a library of methods created in another language that also has a published API. In still other embodiments, the application is a compiled program executed by a command line in the operating system language for the platform on which the applications reside. The compiled program operates on input in data files or on an input stream and produces output in data files or on an output stream, all defined in the operating system language. In yet other embodiments, the application is a script in the operating system language that executes several compiled programs in sequence.

Each application of the mobile applications 116 on the mobile applications server 110 provides functionality for mobile devices. As described in the background section, different mobile devices may have different characteristics. For example, different devices may communicate on the network through their base stations with different protocols (e.g., WAP, HTTP, Telnet), may have different keys and sensors, and may have different screen sizes, different memory capacities and different processing power. Such differences in characteristics complicate obtaining input for the application and presenting output from the application. These applications 116 are special in that they communicate with the mobile device 101 through a mobile interactions server 150, described next, in a manner that does not require developers of the application 116 to address specific characteristics of the individual mobile device 101.

The mobile applications server 110 includes the mobile interactions server 150 that provides data or methods or both for obtaining input data from the mobile device, for presenting output data at the mobile device, and for managing the data communicated with the mobile device. The mobile interactions server 150 receives requests from the client process 103 through the mobile device base station 107 and returns responses to the client process 103 through the base station 107. The mobile interactions server also passes data to the applications 116 involved, causes methods of the applications 116 involved to be executed, and receives any output from the applications 116 for the mobile device 101. The mobile interactions server thus operates to intercede between the application 116 and the mobile device 101 to insulate the application 116 from dealing with specific characteristics of individual mobile devices.

In the embodiment of FIG. 1A, the mobile interactions server 150 generates additional components at runtime in response to an initial request from the client process 103. These additional components include a listener 152, a state machine 154 and a state information database 155. The listener 152 is a process launched by the mobile interactions server 150. The listener monitors a port associated with input having a particular protocol (e.g., HTTP, WAP, or Telnet) on the mobile applications server. The listener acts in response to requests received from a client process on the port and causes data to be sent back to the client process over the network.

In the embodiment depicted, the listener produces descriptions in the extensible Markup Language (XML) of graphical elements for display on the screen 102 of mobile device 101 which are sent to a conventional XML converter 112 described below. When monitoring some ports, however, the listener 152 does not send an XML document. Instead, the listener 152 produces a response for the mobile device in the protocol used by the base station 107. For example, when listening on a Telnet port, the listener produces a response using the Telnet protocol. In this case, the response is sent to the base station via the network 108 and bypasses the conventional XML converter 112. If the response produced by the listener 152 for the client process uses the methods of an application 116 or information from previous requests and responses, then the listener causes a method of a state machine 154 to be executed and the listener bases the response for the client process on the data returned from the state machine 154.

The state machined 154 is a process that is launched by the listener. In some embodiments, the state machine 154 is a library of methods invoked as controlled by the listener 152. In other embodiments, the state machine 154 is a background process that executes in parallel waiting for a particular message upon which to act. The state machine 154 receives data from the listener 152 based on requests from the client process and returns responses to the listener 152 for the client process. The state machine 154 also determines which methods of which applications 116 are involved and causes the involved methods to be executed.

The state machine 154 also manages information about multiple requests and responses involving the client process for each client process communicating over the port. The state information database 155 is persistent storage for the information managed by the methods of the state machine 154 for the client process during the client communication session with the mobile interactions server. Thus, the state machine 154 and state information database 155 enable applications to perform complex transactions in which a response passed to the client in response to a request contains or depends on information carried in a previous request or response. In some embodiments the state information database survives for a limited time after communication with the client terminates—in case the break in communications is an unintentional interruption. If the client reestablishes communication within the limited time, then the state machine method invoked by the listener to commence a session with the client identifies the existing state information database for the client and employs the existing database instead of creating a new one.

The mobile applications server also includes a conventional XML converter process 112, which translates descriptions in the eXtensible Markup Language (XML) of graphical elements for display on the screen 102 of mobile device 101 to descriptions used by the base station 107 for several protocols. Conventional XML converters use an eXtensible Stylesheet Language (XSL) to translate from XML to any of several markup languages used by a variety of base stations. However, there is not a standard markup language for Telnet devices, and conventional XML converters do not translate XML descriptions into a markup language for Telnet. In an alternative embodiment, shown in FIG. 1D, the listener 152 produces Telnet protocol responses that are sent to the network 108, bypassing the conventional XML converter 112.

FIG. 1D is a block diagram showing an embodiment 150b of mobile interactions server 150. This embodiment includes an embodiment 152b of listener 152 in which the listener 152 includes a device-sensitive presentation manager 140 and an XML to protocol converter 114. The device-sensitive presentation manager is a process that modifies the format of data received from the state machine for display on the screen 102 of the mobile device 101 based on information particular to the mobile device before sending the information to the client process.

For example, the data from the state machine indicates a menu of 10 items, but the screen 102 of the particular mobile device 101 has only five lines. The device-sensitive presentation manager 140 receives data indicating the menu with the ten items, determines that the mobile device has a display screen that only shows five lines, and reformats the data to send one of three subsets of the data, each subset indicating five lines of graphical display or less. For example, the first subset of data indicates four menu items for the first four lines and a button labeled "next items" for the fifth line. The second subset of data indicates three menu items for the middle three lines, a button labeled "prev items" for the first line and a button labeled "next items" for the fifth line. The third subset of data indicates a button labeled "prev items" on the first line followed by the last three menu items on the next three lines.

In the illustrated embodiment, the information particular to a mobile device comes from a device profile database 145 holding information about the characteristics of mobile devices. In other embodiments, the information comes from prompting the mobile device for its characteristics and obtaining an answer in a process called negotiating. In some embodiments the process is performed by invoking a method in a library of methods, in another embodiment the process executes in the background waiting for input from the listener.

In the illustrated embodiment, the output from the device sensitive presentation manager 140 is in XML, which is used as a common markup language relatively easily converted to device-specific protocols. In another embodiment, a different markup language is used as the common markup language.

Listener 152b also includes an internal XML to protocol converter 114. The internal converter 114 is a process that receives data in XML and converts it to a protocol used by the base station 107 of the mobile device 101. Some protocols use data in mark up languages produced by an external conventional XML converter 112. For these protocols, the internal XML to protocol converter 114 sends the XML data to the external conventional XML converter 112 with little or no change, as shown in FIG. 1A by arrow 113a. The external XML converter 112 uses XSL to produce different markup languages tailored to types of mobile device and sends data in these markup languages over the network as shown in FIG. 1A by arrow 113b. The external XML converter 112 produces various versions of HTML for HTTP clients like web browsers, a Handheld Device Markup Language (HDML) for some devices, a markup language for voice capable gateways (VoxML), and various versions of WML, such as for ERICSSON™ and NOKIA™ 7110 devices. An Example of a conventional XML converter suitable for the external converter 112 is PORTAL-TO-GO™ of the ORACLE™ Corporation.

For other protocols for which there is not a standard markup language, the internal XML to protocol converter 114 performs parsing of the XML data and converts the data to messages that follow the protocol. For example, for the Telnet protocol, the internal XML to protocol converter 114 determines which XML elements are displayed on the next line and sends the contents of those elements, character by character, to the base station 107, as dictated by the Telnet protocol. These Telnet responses are not sent to the external conventional XML converter 112 but are sent directly to the network as indicated by arrow 113c in FIG. 1D for the base station, bypassing the external conventional XML converter 112. This internal XML to protocol converter 114 is especially useful with industrial devices, for example, with industrial bar code readers used on the floor of a warehouse or factory, which communicate with an inventory database application over a local area network using the Telnet protocol.

Graphical Elements

According to the present invention, the applications 116 communicate indirectly with the mobile devices through the mobile interactions server 150 using data that describes one or more graphical elements that may be displayed on the screens of the mobile devices and may be associated with actions by a user of the mobile device, such as moving a cursor and pressing a key. Several types of known graphical elements are associated with known actions by a user who manipulates a cursor on the screen of the mobile device and coordinates the use of one or more keys on the mobile device. Among the known graphical elements are a text field, a button, a check list, a set of radio buttons, and a pull down menu (also called a popup menu). According to the disclosed techniques, the application employs these graphical elements and others to prompt for and obtain a series of inputs from a user of the mobile device in order to conduct a complex transaction. The techniques allow an application designer to include graphical elements without the application designer providing the details of how the graphical elements are communicated to the mobile device or how much information is stored on the mobile device.

For example, an application can be built to allow a mobile telephone user to search for a name in a telephone directory maintained in a telephone directory database by a third party and to download the name and number to the mobile telephone's speed dial list maintained in persistent memory on the mobile telephone. The application constructs a first set of graphical elements for the mobile telephone to prompt the user of the telephone to input each character of the name being searched for. This set of graphical elements used together is called a page. The application uses the name input by the user to construct a query to send to the third party database to obtain a list of names and numbers that match the name being searched for. The application then constructs another page of one or more graphical elements to present the one or more resulting names and prompt for the user to select one or more. In response to further user action, the application then constructs another page of graphical elements to prompt the user to indicate whether the selected names should be added to the speed dial directory or dialed or ignored. Based on the response the application issues a command that causes the telephone to add the numbers to the telephone's speed dial directory or to dial a selected one number or to simply end the application. According to the techniques described below, this application can employ all the graphical elements needed without dealing with the details of the protocol to communicate with the device, or how the graphical element is rendered on the screen of the mobile device, or maintaining all the user inputs in persistent storage.

The Structures for Graphical Elements

The fundamental building block for a graphical user interface for interacting with a user of the mobile device is the graphical element. A page is constructed of one or more graphical elements that are intended to be used together by a user of the mobile device. An application is built of one or more pages. When a user first requests services from the mobile applications server, the user is presented with a main menu including a menu item for each selectable application on the mobile applications server. When the user selects one of the menu items, the user is presented with the first page of the corresponding application.

The graphical element and the page and the menu item are implemented as objects in an object-oriented language like JAVA™. In object-oriented implementations, an object is a data structure that is a particular instance of a data structure type defined in a class. The objects are said to be instantiated from the class. The class defines the attributes and methods for all the objects in the class. While all objects instantiated from the same class have the same attributes, the values that those objects store for those attributes may vary from object to object. Furthermore, an attribute may be defined to refer to an object of a second class, so that the value this attribute takes is an object of the second class. Classes can inherit some or all of their attributes and methods from other classes which themselves may inherit attributes and methods from other classes. In JAVA, the classes form a hierarchy and a class can only inherit from classes above them in the hierarchy to avoid cyclic inheritance. In JAVA several classes are stored together in a package. Each class in the package has a unique name and the names together constitute a namespace.

According to the object oriented implementation, a menu item object corresponding to the application includes one or more page objects as attribute values, and each page object includes one or more field objects as attribute values. A field object corresponds to a graphical element.

Mobile Applications Bean Objects

A bean is a class of objects with at least a minimum set of attributes and methods, including a bean name and a method for listing the attributes (i.e., properties) and attribute values of each object. This method gives the bean class the behavior of introspection. In one embodiment the bean class methods includes a method for setting a value for an attribute of the object, and a method for getting the value of the attribute. These methods give the bean class the behavior of persistence, and, by providing a standard format for storing and retrieving information, give the bean class the behavior of serialization. In this embodiment, the methods provide the functionality to store and retrieve the attributes and attribute values of instances of the bean class or of instances of classes that inherit from the bean class.

In another embodiment, the bean class includes a vector of event handling methods. An event is an object generated by a listener in response to a message from a client process. Different listeners produce different event types. The event received from the listener is the input parameter for the event handler corresponding to the event type. The vector of event handlers in the bean class handle events in response to a user of the mobile device activating a control of the mobile device 101, such as by pressing a key 104 of the mobile device, using a pointing device on the mobile device, or turning on the sensor 105. In some embodiments, event handling methods are implementations of interfaces for handling event objects. An interface is data that defines the name for a method and the names of the parameters used as input to the method, and the class of the objects used as values for the parameters, and the class of the object returned, if any. The class is often identified by the name of the class; the name of the class of which an object is an instance is also called the type of the object. An implementation of an interface provides the instructions to use the parameters to produce the returned value.

A JavaBeans class is a commercially available, published bean class including methods for providing introspection, persistence and event handling.

According to the present disclosed techniques, mobile applications beans are provided to an application developer and used in the application. A mobile applications bean is a class that inherits the attributes, attribute values and methods of a bean class and extends them for describing a graphical element, a page or an application menu item. The mobile applications bean extends the bean class by providing an additional one or more attributes or by replacing one or more methods or by adding one or more methods or interfaces, or by some combination of these changes. A menu item bean is a mobile applications bean extended to provide the attributes and methods used when an application is invoked or launched and when the application terminates. A page bean is a mobile applications bean extended to provide the attributes and methods used when a page is entered and exited. A field type bean class is a mobile applications bean class extended for each graphical element. A different field type bean class is defined for each of the known graphical elements used to interact with a user of a mobile device. For example, a field type bean class is defined for a text field, a button, a radio button, a checklist, a list, and a list of selectable values, as described in more detail below.

FIG. 1B shows some of the main attributes and methods included in a mobile applications bean 180. A mobile applications bean 180 includes a bean name 181 and a bean value 182 as required by all beans. The mobile applications bean also includes zero or more attributes and attribute values 184 particular to the type of mobile applications bean. In this context the type of a mobile applications bean is used to indicate one of the menu item bean, the page bean, and the field type beans, such as the text bean, the button bean and other beans mentioned above or described in more detail below.

The mobile applications bean 180 includes a method 187 for generating an XML document that describes the graphical element to be displayed on a screen of the mobile device to represent an object of the mobile applications bean. An XML document that describes a graphical element for display on a variety of mobile devices is described in more detail in the related application incorporated by reference in its entirety above.

The mobile applications bean 180 includes a method 188 for handling an event generated by a listener when a graphical element corresponding to the bean is involved in an action by the user of the mobile device. For some mobile applications beans this method 188 is just an abstract method naming the method and the parameters and the parameter types and including a return statement to end the method, but not performing any significant functions. The event handling method is to be written by the application programmer when the application is built in order to have the event handling method perform the desired tasks of the application as described with an example below. The mobile applications beans include default event handlers for all events generated by the mobile interactions server. In addition, a set of event handlers, corresponding to a limited set of predefined events, is defined in a mobile applications interface so that the application developer can provide the instructions to execute upon occurrence of one of the predefined events. The predefined events are high-level, generic events that insulate the application from the device-specific details of user actions on the mobile device, such as keys stroked and pointing device characteristics manipulated.

For example, a predefined field-entered event is generated when a cursor on the screen 102 of the mobile device 101 enters a graphical element associated with a field type bean. A pre-defined special-key-pressed event is generated when a special key of the keys 104 is pressed to move to a different page without completing and submitting the current page. A pre-defined page-exited event is generated when a user indicates the user is finished with the page, such as when an enter key is pressed with the cursor placed on a button labeled "submit." If the application does not include instructions for the event handling methods for these events, the mobile interactions server employs one of the built-in event handlers for these events. More details on the event handling methods and interfaces are described in a later section.

The Field Bean

The field beans describe the attributes and behavior of the graphical elements displayed on the screen 102 of the mobile device 101 and used to display information to the user or collect data from the user or both.

According to one embodiment, a set of nine field types are defined by corresponding field type bean subclasses of a field bean subclass of the mobile applications bean. The set of nine field bean types are provided to the application developer to instantiate and add event handlers to provide the behavior for the application being developed. The nine field type beans include a text field bean, a list of values (LOV) field bean, a list field bean, a multi-list field bean, a checkbox field bean, a radio field bean, a button field bean, a heading field bean, and a separator field bean. The values assigned to properties of the field beans are used to customize the instantiated field type for particular applications. For example, the "hidden" property of a text bean may be set to "true" to suppress display of the value. Similarly, the "editable" property of a text bean may be set to "true" to allow the user to type characters that replace the characters currently in the value of the bean. Default values provided for some attributes are assigned if the application does not explicitly assign other values. In the preferred embodiment, a method 187 for generating an XML document for each field type bean is built-in and need not be written or replaced by the application developer.

FIG. 5A shows how text field beans are rendered on a Telnet device having a fourteen line display. This display is based on the XML document produced by method 187 for this subclass and subsequently processed by the XML to protocol converter 114. A device using the Telnet protocol adds one character at a time to the current line of a display device, except that a special "line-feed" character displays a new line with no characters. Some Telnet devices display only the current line, others display several lines. On Telnet display 501, text field bean 514 is displayed as a string of characters including a text field prompt 515 and a text field value 516. A prompt is an attribute (i.e., property) of this text field subclass, which has a value of "ACCT" for the object displayed. The "ACCT" prompt value indicates the text field 514 contains a value for an account number.

The editable attribute of this text field element is indicated by the XML document produced by method 187 for this bean. The editable field is rendered as a reversed background highlight 517 according to the XML to protocol converter 114 based on information in the device profile database 145 about the display used by this device. For example, it is determined from the device profile database that the display on the particular mobile device in which the client process is executing supports reverse background text. Then the editable text is highlighted on this Telnet display by reversing black and white for the characters and background. The user of the mobile device may replace the characters in the value of this field bean with other characters indicating a different account number. As the user strokes each character key, the built-in event handling method 188 for the text field bean automatically uses the XML generating method 187 to produce an XML document that describes the new character in the field and the cursor moved to the next position. The application developer does not have to replace either method 187 or 188 and therefore does not need to know the details of communicating with the mobile device.

Sample attributes of the nine field bean classes are provided in Tables 1 through 9. Values are assigned to these attributes by the application to specify the layout of the graphical elements with which a user of the mobile device receives and enters data. The information in each of the following tables is also used in the method 187 to generate XML documents for the objects instantiated from the bean. The method 187 to generate XML uses an XML document type definition (DTD) for the bean. The DTD defines XML element tags that correspond to the field bean types and attributes that correspond to the entries in the "Attribute" column. The DTD also specifies data types for the attributes that correspond to the entries in the "Allowed Values" column and default values that correspond to the entries in the "Default Value" column in the Tables 1 through 9. A corresponding style sheet is used by the XML converters 112 and 114 to translate the XML document into other markup languages or protocols.

If an attribute is inherited from the field bean of the mobile applications bean, a "yes" appears in the "Inherited" column in Tables 1 through 9. A short description of the graphical effect of the attribute on a corresponding graphical element ultimately produced on the screen of a mobile device is included in the column titled "Graphical Effect." The "get", "set" and "is" columns refers to the bean class methods used to access the attribute; the "is" method is used to get an attribute value that holds a logical value "true" or "false".

A text field bean object is used to display text or receive text input from a user. Constraints on user input, if any, are described by some of the attributes for this bean. Table 1 shows attributes of the text field bean.