Extending business processes to mobile devices

A system, method, and computer program product are provided for intercepting an e-mail from a backend system and converting the e-mail into a message which can be used by a mobile device to graphically represent a business process. The mobile device can interact with the graphic representation, or invoke a business method from a local graphic representation, in order to send a response message to the backend system for further communications.

BACKGROUND OF INVENTION

1. Field of the Invention

The present invention relates generally to business processes and, more specifically, to integrating business processes into a mobile platform.

2. Description of the Background Art

Backend systems have been developed to automate many business processes within the workplace. A simple business process involving the creation of a work order by an employee and the approval or denial thereof by an employer is frequently automated by systems which allow the employee to create an electronic work order for the employer's review.

In many cases, these systems provide helpful e-mails to indicate a status change within the system. For example, when an employee creates a work order, the system may dispatch an e-mail to the employer indicating that a new work order is available in the system. The e-mail may even include some details of the work order, but does not provide any uniform manner in which the employer can readily approve or decline the work order within the e-mail itself. Instead, the employer must log on to the system and use the appropriate interface to approve or decline the work order.

Requiring direct access to the business process system creates several drawbacks. Notable among these drawbacks is the difficulty of accessing the business process system directly from a mobile device. Costly solutions require the development of dedicated client software on the mobile device to interface the business process system directly. Otherwise, a mobile device-equipped employee may have no recourse other than to return to the office in order to directly access the business process system.

The inability to use mobile devices effectively to automate interaction with business process systems is inefficient. Accordingly, what is desired is a means to interface with a backend system from a mobile device in an efficient and economical manner.

SUMMARY OF INVENTION

Embodiments of the invention include a method comprising intercepting an e-mail from a backend system, determining that the e-mail is a widget e-mail, transforming the widget e-mail into a widget message, and synchronizing the widget message to a client device.

Embodiments of the invention additionally include a computer-readable medium having computer-executable instructions stored thereon that, if executed by a computing device, cause the computing device to perform a method comprising intercepting an e-mail from a backend system, determining that the e-mail is a widget e-mail, transforming the widget e-mail into a widget message, and synchronizing the widget message to a client device.

Embodiments of the invention additionally include a system, comprising an interceptor configured to intercept an e-mail from a backend system and determine that the e-mail is a widget e-mail, a transformer configured to transform the widget e-mail into a widget message, and a sync engine configured to send the widget message to a mobile device.

Embodiments of the invention additionally include a method comprising receiving a client widget request from a client device, creating a function call to a backend system responsive to the client widget request, and transmitting the function call to the backend system.

Embodiments of the invention additionally include a computer-readable medium having computer-executable instructions stored thereon that, if executed by a computing device, cause the computing device to perform a method comprising receiving a client widget request from a client device, creating a function call to a backend system responsive to the client widget request, and transmitting the function call to the backend system.

Embodiments of the invention additionally include a method comprising receiving a widget message, running a user interface, populating the user interface with contents of the widget message, receiving an input from the user interface, and sending a widget request based on the input.

Embodiments of the invention additionally include a system comprising a mobile office client in communication with a mobile office server, and a client widget configured to receive a widget message, run a user interface, and populate the user interface with contents of the widget message.

DETAILED DESCRIPTION

The following detailed description of the present invention refers to the accompanying drawings that illustrate exemplary embodiments consistent with this invention. Other embodiments are possible, and modifications can be made to the embodiments within the spirit and scope of the invention. Therefore, the detailed description is not meant to limit the invention. Rather, the scope of the invention is defined by the appended claims.

It would be apparent to one of skill in the art that the present invention, as described below, can be implemented in many different embodiments of software, hardware, firmware, and/or the entities illustrated in the figures. Any actual software code with the specialized control of hardware to implement the present invention is not limiting of the present invention. Thus, the operational behavior of the present invention will be described with the understanding that modifications and variations of the embodiments are possible, given the level of detail presented herein.

FIG. 1is an example of a business process100in which the actors are a field employee102and a manager106, in accordance with an embodiment of the present invention. In this particular business process, the field employee102has just learned of the need for a repair. However, the business process100dictates that the field employee102must seek the approval of the manager106before performing the repair. Accordingly, field employee102submits a work order104. This work order104is received by the manager106, who reviews the contents thereof. If everything is satisfactory, the manager106sends an approval108of the work order104to field employee102, authorizing the field employee102to proceed with the repair work.

One skilled in the relevant arts will appreciate that this particular business process100is provided by way of example, and not limitation, and other business processes involving other levels of interaction between one or more actors would work within the framework discussed herein.

Traditionally, the work order104and approval108are paper forms, which require the field employee102to fill out the form and submit it to the manager106for a signature, which in turn acts as the approval108. Such a set up is disadvantageous, as a field employee102performing work at, by way of example, and not limitation, a client site, would have to return to the office to submit a paper work order104.

More recently, electronic systems have been put in place which eliminate the paper component of the above example, but otherwise function in a similar manner. Field employee102can pull up an interface for a backend system developed to support business process100. Using this interface, field employee102can submit the required information to complete work order104, which is then sent to manager106.

In these electronic systems, manager106is usually required to log on to the same backend system in order to retrieve and review the work order104. Manager106may be notified that the work order106is ready for review by, for example, an e-mail indicating a submission to the backend system has been made. Upon logging in to the system in a managerial capacity, manager106reviews the work order104and electronically signs the work order, thereby creating an approval108notification.

Similarly, when the approval108is completed, field employee102is able to log on to the same backend system in order to retrieve and review the approval108. Field employee102may also be notified that approval108has been received by, for example, an e-mail indicating the approval.

Despite the increased usefulness of these electronic systems over traditional paper filings, it has been difficult to implement access to the backend system within mobile devices. Without a mobile device interface, field employee102must still return to the office to access the backend system and create the work order104. However, creating an interface to the backend system has traditionally involved writing dedicated software for a mobile device platform, or even building a custom mobile device platform for the task. Tying the business process to deployed mobile platforms increases the ease with which the business process can be implemented and itself deployed, as well as reducing expenses, among other benefits.

II. Business Process Widgets

FIG. 2is a network200for managing a business process, in accordance with an embodiment of the present invention. A backend system202natively handles the business process, in accordance with an embodiment of the present invention. In accordance with a further embodiment of the present invention, backend system202is a self-contained business process system able to handle every phase of the business process, such as business process100, entirely within the backend system202. One skilled in the relevant arts will appreciate that although backend system202is shown as a single component, it may comprise multiple servers or devices, arranged locally or globally, and communicating over a local access network or a wide access network, such as the Internet. One skilled in the relevant arts will recognize that additional embodiments of the backend system202will conform to the network200ofFIG. 2.

By way of example, and not limitation, backend system202manages a business process comprising employee vacation time verification, although one skilled in the relevant arts will recognize that other example business processes could be handled by backend system202. An employee wishing to request vacation time would normally be able to log in to backend system202and enter the vacation time request, in accordance with an embodiment of the present invention. Vacation approvers (e.g., a manager) can log in to the backend system202and approve or decline a vacation request.

Whenever a business process is initiated within backend system202, the backend system202sends an e-mail, as shown inFIG. 2, to e-mail server204, in accordance with an embodiment of the present invention. The intended destination of this e-mail varies with the particular business process, but is usually the e-mail account associated with a user who needs to take the next action in the business process. Continuing the above example, and not by way of limitation, when an employee requests vacation time within backend system202, an e-mail is dispatched to the employee's manager via e-mail server204in order to notify the manager of the pending request.

In accordance with a further embodiment of the present invention, the e-mail at e-mail server204is forwarded to mobile office server205for distribution to a mobile device212. In an example embodiment, mobile office server205is the iAnywhere Mobile Office server platform by Sybase, Inc., although one skilled in the relevant arts will appreciate that the concepts described herein can be applied to other enterprise services.

The e-mail intended for mobile device212is intercepted at mobile office server205by interceptor206, in accordance with an embodiment of the present invention. In the event that the e-mail is a regular e-mail (i.e., an e-mail not originating from backend system202, or otherwise not involved with the processes described herein), then the e-mail is passed on to sync engine208, in accordance with a further embodiment of the present invention. Sync engine208is configured to transmit this e-mail to mobile device212. Any existing method can be used for such transmission, including by way of example, and not limitation, methods detailed in “Synchronizing Communications and Data Between Mobile Devices and Servers,” U.S. patent application Ser. No. 12/104,905 to Jeide et al., filed Apr. 17, 2008, which is incorporated herein by reference in its entirety.

However, if the e-mail is an e-mail sent by the backend system202, then it is caught by interceptor206and routed to transformer210, in accordance with an embodiment of the present invention. The method by which interceptor206determines which messages to intercept is discussed further with regard toFIG. 3, below.

Transformer210is able to take the e-mail from backend system202and prepare a document intended for mobile device212. In accordance with an embodiment of the present invention, this document is an XML document describing data to be plugged into a graphical user interface (“GUI”) on mobile device212. This GUI allows a user of mobile device212to interact with backend system202by responding to any requests needed to continue the business process and/or by presenting data which the user must see as part of the business process, in accordance with an embodiment of the present invention.

In accordance with an embodiment of the present invention, transformer210is a general transformer module to which plug-ins such as plug-in212may be added. Plug-in212is specific to the particular “widget e-mail” which has been intercepted, indicating that this e-mail will be transformed into a widget message format for display on mobile device212. Plug-in212gathers information from the widget e-mail and any other sources for creating the widget message. In accordance with an embodiment of the present invention, plug-in212is operable to optionally interface with backend system202to provide any additional information needed in the widget message. Plug-in212then returns the particular widget message to the base transformer210module for forwarding to sync engine208. At this point, sync engine208can forward the widget message to mobile device212.

Mobile device212receives the widget message at mobile office client214, in accordance with an embodiment of the present invention. In an example embodiment, mobile office client214is the iAnywhere Mobile Office client platform by Sybase, Inc., although one skilled in the relevant arts will appreciate that the concepts described herein can be applied to other client platform technologies.

Mobile office client214has a client widget216installed therein which enables the rendering of the GUI showing the widget message, in accordance with an embodiment of the present invention. Following the earlier non-limiting example of the vacation time verification business process, a manager might receive a vacation request at mobile office client214. This vacation request would contain data to populate a GUI provided by client widget216. By way of further example, and not limitation, the GUI can display the employee's name, the dates for which vacation approval is requested, and two buttons corresponding to the manager's available actions of “allow” or “decline,” to respectively allow or decline the vacation time request.

In accordance with an embodiment of the present invention, client widget216comprises an XML file describing the GUI. In accordance with an additional embodiment of the present invention, elements of this GUI are localized, such that the XML file comprises various substitution strings for various GUI elements. The particular localization used is based on a setting. By way of example, and not limitation, this setting could be set on the device212itself, the mobile office client214, or in another location accessible to the GUI.

This widget message is shown in the mobile office client214inbox along with other business process widget messages and regular e-mails, in accordance with an embodiment of the present invention. In accordance with a further embodiment of the present invention, the widget message is displayed with a custom icon associated with the corresponding business process, indicating the status of the message (e.g., read or unread, although one skilled in the relevant arts will recognize that other statuses may be used). This icon changes as the status of the message changes, in accordance with an additional embodiment of the present invention.

The mobile office client214displays a GUI associated with client widget216which enables a set of functionality, in accordance with an embodiment of the present invention. This set of functionality correlates to actions which can be taken by a user of the mobile device212within backend system202. Continuing the above example, a manager may choose to “allow” a vacation time request by clicking on the corresponding button.

By selecting some functionality within the GUI, a response document is sent to responder218in mobile office server205by the mobile device212, in accordance with an embodiment of the present invention. In accordance with a further embodiment of the present invention, this response document is formatted as an XML document.

The above process where mobile device212receives a widget message offering a set of options for a response details the scenario where mobile device212is an intermediary in the business process. However, mobile device212may also initiate the process by using a client-invocable widget, in accordance with an embodiment of the present invention. Continuing the above example, if mobile device212is associated with an employee requesting vacation time, the employee would need to initiate the vacation request business process. In this case, client widget216provides mobile office client214with a widget that can be selected to initiate the process. The widget requests information from the user (e.g., date range for the vacation request, manager to be sent to for approval, etc.), and then sends this message in the same manner as the manager sends a response to responder218in the previous scenario, in accordance with an embodiment of the present invention. This is discussed more fully below with regard toFIGS. 2 and 3.

Responder218receives the message from mobile device212. In accordance with an embodiment of the present invention, responder218is a generic responder module which routes the message to plug-in220which has been written specifically to interface with backend system202. Plug-in220then receives the message from responder218and calls any needed functions within backend system202.

III. Delivering Business Process Requests

FIG. 3is a flowchart300illustrating steps by which a business process request is delivered from a backend system to a mobile device, in accordance with an embodiment of the present invention. Continued reference will be made to network200ofFIG. 2.

Any e-mail intended for delivery to a mobile device can be transformed into a business process request on mobile office server205, in accordance with an embodiment of the present invention. By accomplishing this, mobile workers can interact directly with the backend system202without the need for a dedicated framework. Any backend system202can be integrated into network200by intercepting e-mails sent by backend system202and transforming them into widget messages.

The method begins at step302and proceeds to step304where an e-mail is received from a backend system, such as backend system202. At step306, regular expression matching is performed on the e-mail data in order to determine whether the e-mail is a widget e-mail which should be intercepted, in accordance with an embodiment of the present invention. One skilled in the relevant arts will recognize that methods other than regular expression matching may be employed, and regular expressions are provided by way of example, and not limitation.

In accordance with an embodiment of the present invention, a widget package includes a manifest document which relates various components to the business process associated with the widget package. This manifest document may include references to a particular transformer plug-in212, responder plug-in220, and other files and components needed by the business process. This manifest document and the widget package are further detailed in Section VI, below.

In order to determine whether a particular widget package applies to a received e-mail, match rules from the manifest document are used in step306to perform the regular expression matching on e-mail data, in accordance with an embodiment of the present invention. By way of example, and not limitation, the match rules may specify a regular expression which must be matched by the e-mail subject line in order for the e-mail to be considered a widget e-mail at step306. One skilled in the relevant arts will recognize that other fields and regular expression matches may be used.

By continuation of the previous non-limiting example, if an employee has submitted a vacation request to backend system202, the e-mail generated by backend system202to be sent to an approving manager may have a subject line reading “Vacation Approval Request.” A regular expression match for any e-mail with the subject line “Vacation Approval Request” could be written in the manifest for the widget package, thereby associating any such e-mail with the components of the widget package.

At step308, a determination is made as to whether the e-mail is a widget e-mail based on the regular expression matching of step306. If the e-mail is not a widget e-mail, it is treated as a regular e-mail and synchronized to the mobile device212at step312.

However, if the e-mail is a widget e-mail, then a widget message is created using the transformer plug-in specified within the matched manifest file at step310, in accordance with an embodiment of the present invention. The widget message is specified in an XML format expected by client widget216within mobile device212, in accordance with a further embodiment of the present invention. A developer seeking to integrate backend system202with mobile office server205to provide business processes to mobile devices212codes the transformer plug-in to create a compatible XML message which can be interpreted by the client widget216.

This widget message is synchronized to the mobile device212using the synchronization engine208at step312, as with regular e-mails, and the method ends at step314.

IV. Replying to Business Process Requests

After the mobile device212has received the widget message, a user may initiate a response to the business process from within client widget216. Moreover, a client widget216may declare a business process to be available on the mobile device212for client-initiated invocation, in accordance with an embodiment of the present invention. This interaction within mobile device212is described further in Section V, below.

Regardless of whether client widget216is a response to a business process or the invocation of a new business process, mobile office server205is configured to receive these response messages the same way, in accordance with an embodiment of the present invention.FIG. 4is a flowchart400illustrating steps by which the mobile office server205is configured to receive a response message and invoke the appropriate functionality within backend system202, in accordance with an embodiment of the present invention.

The method begins at step402and proceeds to step404where a client widget request is received. As noted above, this request initiates within client widget216, either as a response or as a user-invoked business process. At step406, the responder module218forwards the request to an appropriate plug-in220, as specified in the corresponding manifest file noted in Section III, and further discussed in Section VI. As with the transformer plug-in212, responder plug-in220is developed for compatibility with backend system202, and understands how to translate client widget requests into functionality within backend system202.

By way of continuing the previous non-limiting example, the client widget request corresponds to the vacation approval by the manager. A plug-in220is developed which receives and interprets the manager's approval request, then formats it at step408in a manner which allows plug-in220to call the approval function within backend system202. This message is then sent at step410.

Further by way of example, the original vacation request by the initiating employee is also a client widget request, and an example of a client-invoked request from a client-invocable client widget216. Plug-in220receives and interprets the employee's vacation request, and likewise formats it at step408in a manner which allows plug-in220to call the new vacation request function within backend system202. This message is then sent at step410. The plug-in220to handle these two requests within the same overarching business process may be written as a single plug-in220, or separated into multiple plug-ins220, in accordance with an embodiment of the present invention. The method then ends at step412.

V. Client-Side Display and Invocation of Business Processes

Mobile device212comprises the mobile office client214which synchronizes with sync engine208to receive e-mails and widget messages, in accordance with an embodiment of the present invention. When receiving a widget message, mobile office client214relies on an associated client widget216to interpret and display, using a GUI, the information contained within the widget message, in accordance with a further embodiment of the present invention.

FIG. 5is a flowchart500illustrating steps by which the mobile device212is configured to receive a widget message for display, and to provide a response based on interaction with the widget message, in accordance with an embodiment of the present invention. One skilled in the relevant arts will recognize that not all of these steps apply to every business process, nor must they be performed in the particular order illustrated. However, the order shown corresponds to an embodiment in which mobile device212receives a message and provides a response thereto, such as the case with the approving manager in the vacation approval business process described earlier by way of example, and not limitation.

The method begins at step502and proceeds to step504where a widget message is received. At step506, the widget message is shown on a message list using icons corresponding to the related business process, in accordance with an embodiment of the present invention. These icons are described within the manifest file, and are discussed further in context in Section VI, below.

The widget message is parsed and used to populate a user interface at step508based on a user interface described within client widget216, in accordance with an embodiment of the present invention. In accordance with a further embodiment of the present invention, the user interface is described using XML. This occurs, by way of example, and not limitation, when a user selects the message from a message list for viewing.

The particular user interface to be used depends on the operating platform of mobile device212, in accordance with an embodiment of the present invention. As will be described further in Section VI, the manifest file describes several client widgets216which can display the information within the widget message received at step504, with each client widget216corresponding to a different operating platform for mobile device212. By way of example, and not limitation, a client widget216is described for the Windows Mobile Professional operating platform, developed by Microsoft Corp.; an additional client widget216is described for the Windows Mobile Standard operating platform, developed by Microsoft Corp.; a further client widget216is described for the Symbian operating platform, developed by the Symbian Foundation; yet a further client widget216is described for the iPhone operating platform, developed by Apple Inc. One skilled in the relevant arts will recognize that additional client widgets216can be developed to target any particular mobile operating platform on a mobile device212, and the aforementioned are provided by way of example, and not limitation.

When the status of the widget message changes, such as when the business process is performed, the icon for the message is changed at step510to another icon, in accordance with a further embodiment of the present invention. Upon interaction with the client widget216, a request may be triggered, resulting in a widget request being sent at step512. Continuing the previous example, this widget request is sent when an approving manager selects a button to approve a vacation request. The method ends at step514.

In addition to changing the icon for the message upon performance of a business process action, the widget message itself becomes read-only on mobile device212, in accordance with an embodiment of the present invention. This prevents triggering of the business process action a subsequent time.

VI. Widget Development and Packaging

A developer wishing to integrate a business process provided by backend system202with mobile office server205provides a widget package including the various components which are needed by mobile office server205and each connected mobile device212to interact as part of the business process, in accordance with an embodiment of the present invention. The components included in the widget package enable the functionality detailed in flowcharts300ofFIG. 3,400ofFIG. 4, and500ofFIG. 5, in accordance with a further embodiment of the present invention.

FIG. 6is an exemplary widget package600including the various components to be integrated into mobile office server205and each mobile device212, in accordance with an embodiment of the present invention. In accordance with a further embodiment of the present invention, widget package600is a zipped or otherwise archived set of files intended for distribution to mobile office server205and each mobile device212.

Widget package600comprises a manifest602, which serves as a packing list of files within the widget package600. As is shown inFIG. 6, manifest602points to or itself contains the various components which describe how the business process is handled within mobile office server205and each mobile device212, in accordance with an embodiment of the present invention.

In accordance with an embodiment of the present invention, manifest602is an XML document. In accordance with a further embodiment of the present invention, manifest602comprises XML elements which describe a widget module. By way of example, and not limitation, these elements include ModuleName, ModuleVersion, ModuleDescription, and ModuleDisplayName elements.

As previously stated, a widget message may be presented within mobile office client using a client icon which is associated with the business process. In accordance with an embodiment of the present invention, the manifest602comprises an element ClientIconIndex which points to an icon to be used within the inbox of mobile office client214.

In accordance with a further embodiment of the present invention, manifest602also indicates whether the widget module is invocable within mobile office client214by the client, without the need for an associated e-mail. Manifest602provides an InvokeOnClient element to specify this behavior, in accordance with an embodiment of the present invention.

Manifest602also points to a transformer plug-in604, such as the plug-in212ofFIG. 2, to be integrated into mobile office server205, in accordance with an embodiment of the present invention. A TransformPlugin element comprises nested File and Class elements which allow for the specification of a dynamic linked library (DLL) and a .NET type, respectively, that implement the mail processor interface of plug-in212and interceptor206ofFIG. 2, in accordance with an embodiment of the present invention. One skilled in the relevant arts will recognize that the transformer need not be specified using .NET components, and can be in any suitable language.

Similarly, manifest602points to a responder plug-in606, such as plug-in220ofFIG. 2, to be integrated into mobile office server205, in accordance with an embodiment of the present invention. A ResponsePlugin element comprises nested File and Class elements which allow for the specification of a dynamic linked library (DLL) and a .NET type, respectively, that implement the device responder interface of plug-in220ofFIG. 2, in accordance with an embodiment of the present invention. As before, one skilled in the relevant arts will recognize that the responder need not be specified using .NET components, and can be in any suitable language.

Manifest602further provides descriptions for the various client widgets216to be implemented within mobile office client214of mobile device212, in accordance with an embodiment of the present invention. A ClientWidgets element is provided to describe each of the supported mobile device212platforms for the business process widget, as well as the corresponding client module to use for each platform.

A CFWidget element comprises nested File and Class elements which allow for the specification of a dynamic linked library (DLL) and a .NET type, respectively, that implement the client widget216ofFIG. 2, in accordance with an embodiment of the present invention. As before, one skilled in the relevant arts will recognize that the client widget need not be specified using .NET components, and can be in any suitable language.

The client widget DLL can further implement controls not normally available in the target platform. In accordance with an embodiment of the present invention, the client widget DLL for the Apple iPhone platform includes select box and check box components which are not normally available in the Apple iPhone SDK.

An XMLWidget element describes the client module implemented as an XML user interface description, in accordance with an embodiment of the present invention. This module represents the user interface shown to the user for a business process widget.

Manifest602also provides, either in-line or by reference to an external file, a set of match rules to determine whether an e-mail received by mobile office server205should be parsed as a widget e-mail, in accordance with an embodiment of the present invention. As previously noted, this is written in the form of regular expressions, although one skilled in the relevant arts will appreciate that other techniques for determining whether an incoming e-mail is a widget e-mail may be used. A match rule is described using a MatchRule element, with inner tags corresponding to various elements of the e-mail. By way of example, and not limitation, a regular expression to match a particular e-mail subject line is embedded within a pair of SubectRegExp tags.

A number of context variables618are also provided within manifest602, in accordance with an embodiment of the present invention. These context variables are made available to the methods in the transformer plug-in212and responder plug-in220.

Additional files and resources can be provided within manifest602or linked to by manifest602. The aforementioned files, resources, and other descriptive elements of widget packet600are provided by way of example, and not limitation.

VII. Communications And Example Application

FIG. 7is a communication flow diagram700illustrating communications between backend system202, e-mail server204, mobile office server205, and mobile device212, in accordance with an embodiment of the present invention.

Continuing with the non-limiting example vacation authorization business process, the backend system sends a business process e-mail at step702. In the example, this could be an approval request e-mail generated by the backend system upon submission of an employee's vacation request. This e-mail is intended for receipt by the approving manager in the example. As with a normal e-mail, it is received by e-mail server204. Mobile office server205then requests the e-mail at step703. The e-mail is sent to the mobile office server at step704for distribution to the appropriate mobile device212associated with the recipient, in accordance with an embodiment of the present invention. One skilled in the relevant arts will appreciate that other means by which mobile office server205can retrieve e-mail messages for distribution to mobile devices exist, and the above method is presented by way of example, and not limitation.

Mobile office server205receives the e-mail and performs the steps of flowchart300ofFIG. 3to generate a widget message, in accordance with an embodiment of the present invention. This widget message is then sent to mobile device212at step706.

The mobile device212may then optionally perform the steps of flowchart500ofFIG. 5in response to receiving the widget message of step706, in accordance with an embodiment of the present invention. Based on interaction with the widget message at mobile device212, the mobile device212sends a client widget request at step708back to mobile office server205. Alternatively, a client-invocable client widget216may generate client widget request708directly upon invocation without the need to receive widget message706.

Mobile office server205receives the client widget request and performs the steps of flowchart400ofFIG. 4to interact with backend system202, in accordance with an embodiment of the present invention. The resulting backend system message is sent to the backend system202at step710.

VIII. Example Computer System Implementation

Various aspects of the present invention can be implemented by software, firmware, hardware, or a combination thereof.FIG. 8illustrates an example computer system800in which the present invention, or portions thereof, can be implemented as computer-readable code. For example, the methods illustrated by flowcharts300ofFIG. 3,400ofFIG. 4, and500ofFIG. 5, can be implemented in system800. Various embodiments of the invention are described in terms of this example computer system800. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.

Computer system800includes one or more processors, such as processor804. Processor804can be a special purpose or a general purpose processor. Processor804is connected to a communication infrastructure806(for example, a bus or network).

Computer system800also includes a main memory808, preferably random access memory (RAM), and may also include a secondary memory810. Secondary memory810may include, for example, a hard disk drive812, a removable storage drive814, and/or a memory stick. Removable storage drive814may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive814reads from and/or writes to a removable storage unit818in a well known manner. Removable storage unit818may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive814. As will be appreciated by persons skilled in the relevant art(s), removable storage unit818includes a computer usable storage medium having stored therein computer software and/or data.

In alternative implementations, secondary memory810may include other similar means for allowing computer programs or other instructions to be loaded into computer system800. Such means may include, for example, a removable storage unit822and an interface820. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units822and interfaces820which allow software and data to be transferred from the removable storage unit822to computer system800.

Computer system800may also include a communications interface824. Communications interface824allows software and data to be transferred between computer system800and external devices. Communications interface824may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface824are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface824. These signals are provided to communications interface824via a communications path826. Communications path826carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels.

In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage unit818, removable storage unit822, and a hard disk installed in hard disk drive812. Signals carried over communications path826can also embody the logic described herein. Computer program medium and computer usable medium can also refer to memories, such as main memory808and secondary memory810, which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system800.

Computer programs (also called computer control logic) are stored in main memory808and/or secondary memory810. Computer programs may also be received via communications interface824. Such computer programs, when executed, enable computer system800to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor804to implement the processes of the present invention, such as the steps in the methods illustrated by flowcharts300ofFIG. 3,400ofFIG. 4, and500ofFIG. 5, discussed above. Accordingly, such computer programs represent controllers of the computer system800. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system800using removable storage drive814, interface820, hard drive812or communications interface824.