Dynamically generating a mobile application

Methods and apparatuses, including computer program products, are described for dynamically generating a mobile application. A server receives a request from a mobile device to launch an application on the mobile device. The server generates a configuration file based on the launched application. The server transmits the configuration file to the mobile device for generation of a user interface of the launched application using the configuration file. The user interface includes a first display area using browser functionality of the mobile device to display one or more web page elements formatted by the server to appear as native to the mobile device. The user interface further includes a second display area having one or more interface elements that are native to an operating system of the mobile device.

FIELD OF THE INVENTION

The subject matter of this application relates generally to methods and apparatuses, including computer program products, for dynamically generating a mobile application.

BACKGROUND OF THE INVENTION

Mobile computing devices, such as smartphones, tablets, and personal data assistants (PDAs) have become increasingly common tools for both entertainment and business productivity. These devices have seen an increase in their hardware processing power, which has contributed to their ability to execute robust applications while taking advantage of user interface feature set provided by the native operating system of the device. Such applications are generally developed, compiled and packaged in advance, and made available to consumers via an online marketplace such as an app store. Users can select applications for purchase and download to the device.

However, updates to such applications, particularly when dealing with a static user interface, generally require extensive development time due to changing of the application code. This leads to an increase in product costs and delayed time for the updates to become available because the applications are changed, recompiled and repackaged, and the user has to re-download the application. Also, due to the increasing number of devices in the marketplace that run different types of operating systems, the development effort must be duplicated to create separate application code for each device/operating system.

SUMMARY OF THE INVENTION

In general overview, the techniques described herein are related to the dynamic generation of mobile applications on mobile devices. The techniques provide for a lightweight container application installed on the mobile device, where the container application builds itself dynamically based on context data associated with the user of the application. The container synthesizes both browser functionality and native operating system functionality to provide a user interface that is easily customizable and server-based, while appearing to the user as if the application is native to the operating system.

The invention, in one aspect, features a computer-implemented method for dynamically generating a mobile application. A server receives a request from a mobile device to launch an application on the mobile device. The server generates a configuration file based on the launched application. The server transmits the configuration file to the mobile device for generation of a user interface of the launched application using the configuration file. The user interface includes a first display area using browser functionality of the mobile device to display one or more web page elements formatted by the server to appear as native to the mobile device. The user interface further includes a second display area having one or more interface elements that are native to an operating system of the mobile device.

The invention, in another aspect, features a computer-implemented method for dynamically generating a mobile application. A mobile device sends a request to a server to launch an application on the mobile device. Thee mobile device receives a configuration file from the server based on the launched application. The mobile device generates a user interface of the launched application using the configuration file. The user interface includes a first display area using browser functionality of the mobile device to display one or more web page elements formatted to appear as native to the mobile device. The user interface further includes a second display area having one or more interface elements that are native to an operating system of the mobile device.

The invention, in another aspect, features a computer-implemented system for dynamically generating a mobile application. The system includes a server configured to receive, from a mobile device, a request to launch an application on the mobile device. The server is further configured to generate a configuration file based on the launched application and transmit, to the mobile device, the configuration file for generation of a user interface of the launched application using the configuration file. The user interface includes a first display area using browser functionality of the mobile device to display one or more web page elements formatted by the server to appear as native to the mobile device. The user interface further includes a second display area having one or more interface elements native to an operating system of the mobile device.

The invention, in another aspect, features a computer-implemented system for dynamically generating a mobile application. The system includes a mobile device configured to send, to a server, a request to launch an application on the mobile device. The mobile device is further configured to receive, from the server, a configuration file based on the launched application and generate a user interface of the launched application using the configuration file. The user interface includes a first display area using browser functionality of the mobile device to display one or more web page elements formatted by the server to appear as native to the mobile device. The user interface further includes a second display area having one or more interface elements that are native to an operating system of the mobile computing device.

The invention, in another aspect, features a computer program product, tangibly embodied in a computer readable storage medium, for dynamically generating a mobile application. The computer program product including instructions operable to cause a data processing apparatus to receive, from a mobile device, a request to launch an application on the mobile device, retrieve a configuration file based on the launched application, and transmit, to the mobile device, the configuration file for generation of, a user interface of the launched application using the configuration file and the web page. The user interface includes a first display area using browser functionality of the mobile device to display one or more web page elements formatted by the server to appear as native to the mobile device. The user interface further includes a second display area having one or more interface elements native to an operating system of the mobile device.

The invention, in another aspect, features a computer program product, tangibly embodied in a computer readable storage medium, for dynamically generating a mobile application. The computer program product including instructions operable to cause a mobile device to send, to a server, a request to launch an application on the mobile device, receive, from the server, a configuration file based on the launched application, and generate a user interface of the launched application using the configuration file. The user interface includes a first display area using browser functionality of the mobile device to display one or more web page elements formatted by the server to appear as native to the mobile device. The user interface further includes a second display area having one or more interface elements that are native to an operating system of the mobile device.

In some embodiments, any of the above aspects can include one or more of the following features. In some embodiments, the user interface includes a third display area. In some embodiments, the first display area includes one or more interface elements that are native to the operating system of the mobile device. In some embodiments, the second display area includes browser functionality of the mobile device to display one or more of the web page elements formatted to appear as native to the mobile device.

In some embodiments, the server receives a login request associated with the launched application from the mobile device. The login request includes user credentials. The server determines a user context based on the user credentials. The server generates a second configuration file based on the user context and transmits, to the mobile device, the second configuration file for generation of the user interface for the launched application.

In some embodiments, generation of the user interface includes removing at least one of an element of the first section and an element of the second section from display based on the user context or the second configuration file. In some embodiments, generation of the user interface includes adding at least one of an element of the first section and an element of the second section to display based on the user context or the second configuration file.

In some embodiments, the server retrieves one or more additional web page elements in response to a navigation command received from the mobile device, and transmits the one or more additional web page elements to the mobile device for display in the first display area. In some embodiments, the server determines which of the one or more additional web page elements to display based on the user context or the second configuration file. In some embodiments, the navigation command includes a server location for the one or more additional web page elements. In some embodiments, the server location is a URL address.

In some embodiments, the user context is associated with a company, a role, an application, a user persona, or any combination thereof. In some embodiments, the configuration file includes URL addresses for retrieving one or more image files from the server, the image files being displayed in at least one of the first display area and the second display area.

In some embodiments, the generating a configuration file includes retrieving, by the server, a stored configuration file based on the identity of the launched application. In some embodiments, the generating a configuration file includes retrieving, by the server, configuration data based on the identity of the launched application, and building, by the server, the configuration file using the retrieved configuration data. In some embodiments, the configuration file is a JSON object.

In some embodiments, the generating a second configuration file includes retrieving, by the server, a stored configuration file based on the user context. In some embodiments, the generating a second configuration file includes retrieving, by the server, configuration data based on the user context, building, by the server, the configuration file using the retrieved configuration data. In some embodiments, the second configuration file is a JSON object.

In some embodiments, the launched application includes function calls associated with functions of the operating system of the mobile device and the one or more web page elements include URL addresses that identify the function calls to request execution of the associated functions by the operating system. In some embodiments, execution of the function calls causes the appearance of the launched application to change.

In some embodiments, the server retrieves one or more additional web page elements based on the launched application, and transmits the one or more additional web page elements to the mobile device for storage at the mobile device and later display in the first display area. In some embodiments, the one or more interface elements are input elements, notification elements, navigation elements, or any combination thereof.

In some embodiments, the mobile device analyzes the configuration file to determine whether an updated version of the launched application is available, and downloads the updated version if available. In some embodiments, the first display area is located inside of a native control of the mobile device.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a system100for dynamically generating a mobile application. The system100includes a mobile computing device102, a communications network104, a server computing device106, and a data source108. The server106and the data source108can reside at the same physical location or may be dispersed to different physical locations. The server106and the data source108can be located on the same physical device, or the data source108can be distributed on different physical devices. The server106and the data source108can communicate via a communications network, for example the communications network104. AlthoughFIG. 1depicts only a single mobile computing device102, communications network104, server computing device106, and data source108, the techniques described herein are not limited to this structure. Instead, this system100can include any of a number of configurations or components (e.g., multiple mobile computing devices, multiple servers) that do not depart from the scope and spirit of the invention.

The mobile computing device102communicates with the server computing device via the communications network104. Example mobile computing devices102can include, but are not limited to a smart phone (e.g., Apple iPhone®) or other mobile communications device, a portable video game system, a tablet computer, an internet appliance, a personal computer, or the like. In some examples, the mobile device102can be installed in a vehicle. The mobile device102can be configured to include an embedded digital camera apparatus, and a storage module (e.g., Flash memory) to hold photographs, video or other information captured with the camera. The mobile device102includes network-interface components to enable the user to connect to a communications network104, such as the Internet, wireless network (e.g., GPRS, CDMA, RF), or the like.

The mobile device102also includes application software that is downloaded from the server computing device106to enable a user to view information and perform transactions based on configuration files and other information received from the server computing device106. In some embodiments, the application software is a proprietary dynamic container application103to be installed on the mobile device102and written with programmatic code designed to interact with an operating system that is native to the mobile device102. For example, due to the inherent differences of mobile operating systems, a developer writes a container application103for the iOS platform and a separate container application103for the Android platform. Although the container application103is device- and/or operating system-specific, the application103is a binary file that contains baseline features, e.g., for interacting with the native operating system. Instead of containing a large number of hard-coded user interface features which would increase the size of the application, the application103leverages a browser-type interface (but appearing native to the user) that receives configuration files from the server106for customization of the structure and content. Therefore, the application is small in size and does not increase in size substantially, even as the user interface displayed in the application grows and changes, because the user interface features are driven by the configuration files that are stored at the server106and contain web links to the majority of the user interface content. In addition, the application103does not need to be repackaged frequently due to the server-based generation and retrieval of user interface elements.

In some embodiments, the container application103uses browser-type software or specific functionality (e.g., WebView in the Android operating system) to enable the application to present formatted information that is received from the server computing device106and to contain links and other commands for navigation and/or execution of functionality. The container application103may utilize existing browser software or functionality that is already available on the mobile device102.

In some embodiments, the container application103includes a series of screens that contain different information and/or functionality. To enable navigation between the screens, the container application103includes input elements such as tabs, buttons, or menu options. These input elements can be part of the native functionality of the mobile device's102operating system, the container application's103code, the formatted information received from the server computing device106, or a combination. The container application103can use a configuration file received from the server computing device106to adjust the appearance and/or functionality of the input elements.

The mobile application configuration module110generates the configuration file for use with the container application103by retrieving pre-stored configuration data from one or more data sources (e.g., data source108). The configuration data can be categorized according to a number of different classifications. For example, the configuration data can be customized for a particular user (e.g., John Smith), a particular role (e.g., investment advisor), a particular employer or company (e.g., Fidelity), a particular application (e.g., Wealth Central), or a particular workflow/function. In some embodiments, the mobile application configuration module110retrieves a pre-stored configuration file that contains default structure and content based on a particular classification. In some embodiments, the mobile application configuration module110dynamically generates the configuration file by determining information about the user's persona, the container application, and other characteristics, then retrieving specific data associated with those characteristics and building the configuration file for transmission to the mobile device102. Using this technique, the server106stores the configuration data and configuration files, which allows the structure and content of the container application103user interface to be modified in one location and distributed to many users across different mobile devices and operating systems—instead of requiring discrete development of an application for each platform and forcing users to download an updated version of the container application103frequently when changes are made.

The configuration file can be stored in data source108, or generated by the mobile application configuration module110, in any number of structures. In one embodiment, the configuration file is a JSON (JavaScript Object Notation) object. JSON is a text-based, position-independent data interchange format consisting of name-value pairs that can be used to map onto the data structures of many different applications. JSON objects are typically lean and lightweight, easy for machines to parse and humans to read, which promotes efficiencies in both generation and transmission of JSON objects. Due to its versatility, openness and simplicity, JSON is well-suited for use in generating both pre-stored configuration files and enabling the he mobile application configuration module110to generate configuration files dynamically based on real-time data retrieval. However, other data formats can be used, including but not limited to XML, without altering the spirit or scope of the invention.

The configuration data comprises the structure and content to be presented on the mobile device102in the container application103. For example, the configuration file can indicate that a particular tab in the container application is not displayed. Based on the configuration file, the container application103removes the tab from display in the user interface. The configuration file can include function calls (described below) to achieve the adjustment in appearance or functionality of the input elements.

In some embodiments, the container application103includes function calls (also called ‘callbacks’) designed to access native functionality of the mobile device102. For example, the container application103can access a digital camera apparatus coupled with the mobile device102and/or digital camera software installed on the mobile device102. In another example, the container application103can utilize a pop-up loading screen message or alert badge functionality that is part of the palette of functions provided by the operating system of the mobile device102.

The container application103can execute function calls by embedding the function calls in links or input elements that are displayed on the mobile device102. When the user interacts with an input element that contains a reference to a function call, the container application103parses the function call and executes the appropriate functionality for that function call. In some embodiments, the function call references a feature within the operating system of the mobile device102. In some embodiments, the function call references a feature within the container application103. The container application103can append arguments to the function call that operate to configure the particular execution of the function call.

An illustrative list of function calls is provided below:showLogin—displays the login screen for the container application.hideLogin—hides the login screen and displays, e.g., a default landing screen.showLoading—displays a loading message indicator to inform the user that information is being loaded into the application.hideLoading—hides the loading message indicator.switchTab—switches to a particular tab within the application. This function call takes an argument with the tab name that is being activated (e.g., switchTab:TradingTab).deleteTabs—deletes one or more tabs from the list of tabs available in the application. This function call takes an argument with a list of tab names (e.g., deleteTabs: TradingTab,NewsTab).setBadge—sets the badge of a tab within the application. A badge is a graphical indicator, usually numerical, that indicates the arrival or pendency of an item for review by the user. This function takes arguments for the tab name and the value to which the badge is set (e.g., setBadge:AlertsTab:15).showURL—opens a URL location in a fullscreen, free-float view within the application. This function takes an argument with the URL to be opened (e.g., showURL:http://www.abc.com).doBack—returns to the previously displayed screen.batch—executes one or more function calls in a list. This function call takes an argument with a list of function call names and associated arguments, if any (e.g., batch: switchTab: TradingTab, setB adge: TradingTab:15).evalJS—executes JavaScript logic on a tab. This function call takes arguments with the tab name and the JavaScript logic to be executed.

The communications network104channels communications from the mobile device102to the server106. The network104may be a local network, such as a LAN, or a wide area network, such as the Internet or the World Wide Web. The network104may utilize satellite or other wireless communications technology. For example, the mobile device102may send and receive information via a communications link to a satellite, which in turn communicates with the server106. The mobile device102and the server106can transmit data using standard formatting and/or transmission protocols, such as XML, HTTP, HTTPS, SMS, JSON, or other similar data communication techniques.

The server computing device106communicates with the mobile device102via a communications network, e.g., communications network104. The server106includes a mobile application configuration module110. The mobile application configuration module110provides a data interface between the mobile device102and the server106.

FIG. 2is a flow diagram200of a method for dynamically generating a mobile application using the system100ofFIG. 1. The server computing device106receives (202) a request to launch an application (e.g., container application103) on the mobile device102. In some embodiments, the request includes context data used by the server computing device106to understand the identity of the application being launched at the mobile device102. For example, when a user clicks or activates the container application103on the mobile device102, the device102generates a request containing an identifier (e.g., name) of the container application103. The context data can be further augmented with other data derived from the container application103, the device102itself, and/or the user of the device102. The context data may include any number of parameters or attributes that provide context for the request, including but not limited to: mobile device hardware type, mobile device operating system version, container application version, network connection type, request header information (e.g., date, time, source address, destination address), encryption information, transmission protocol information, user demographics, and the like.

Upon receiving the request to launch the container application103, the mobile application configuration module110at the server computing device106generates (204) a configuration file based on the launched application. The configuration file contains attributes related to appearance and functionality of the container application103. As described in more detail below, the configuration file changes the look, feel and function of the container application103based on the data contained therein. The use of a configuration file that is generated at the server106and transmitted to the mobile device102enables the container application103to be easily and quickly customized for each of a large number of different users. The use of a configuration file also reduces the need for extensive device- or application-specific code to be resident inside the container application103. Instead, the container application103can contain a smaller set of device-specific features that are leveraged by the configuration file to greatly increase the customization options. Also, based on other requests (e.g., navigation, login, transactional) received from the mobile device102, the mobile application configuration module110can generate one or more additional configuration files at different points during use of the container application103.

The user interface of the container application103is also configurable to appear to the user as though it is native to the operating system of the mobile device102. The user interface of the container application can include elements that are native to the operating system of the mobile device102(e.g., buttons, input mechanisms, alerts, badges, pop-up windows). The user interface of the container application103can also include elements associated with browser functionality resident on the mobile device102. In some embodiments, the browser functionality can be invoked using classes and/or objects native to the operating system of the mobile device102(e.g., WebView of the Android operating system). As explained in more detail throughout the specification, the user interface of the container application103can include any number of these types of elements in many different configurations without departing from the scope of the invention.

In some embodiments, the mobile application configuration module110parses the context data received as part of the request to determine how the configuration file is generated. For example, upon receiving a request identifying a particular container application103(e.g., WealthCentral application), the module110can generate a configuration file that contains a set of properties required for that particular application103. In some embodiments, the module110may retrieve the set of properties from data source108by accessing a configuration database for the application103.

The configuration file generated by the mobile application configuration module110can also contain properties based on other elements of the context data. For example, the request may include the identity of a company or other business entity associated with the launched application103. The business entity can be the provider of the launched application103or the provider of a service or feature offering that is accessed via the launched application103. The mobile application configuration module110can generate the configuration file to contain properties that enable configuration of the launched application103according to specifications established by the business entity.

The techniques described above will now be explained in more detail through an example use case.FIG. 3is a workflow diagram of a process300for launching and configuring the container application (e.g., container application103) on the mobile device102by using the system100ofFIG. 1.FIGS. 4-8are screenshots of a user interface of the container application103on the mobile device102during the process300ofFIG. 3, as configured by the mobile application configuration module110of the server106.

Prior to use, the container application103is installed on the mobile device102. After installation, for example, an icon402for the container application103(e.g., Wealth Central) appears in the home screen400of the mobile device102, as shown inFIG. 4. To launch (302) the container application103, the user interacts with the mobile device102in some way (e.g., for touchscreen devices, the user taps the appropriate icon402).

Once the container application103is launched (302) on the mobile device102, the mobile device102transmits a request to the mobile application configuration module110on the server computing device106. The request includes context data associated with the launched application. In this example, the request includes data to identify the launched application as the Wealth Central application from Fidelity. Because the mobile application configuration module110knows that the Wealth Central application has been launched, the module110generates a configuration file that contains appropriate structure and information for the Wealth Central application.

During transmission of the request by the mobile device102and generation of the configuration file by the module110, the container application103can display a Loading screen (e.g., a spinning wheel or the like) to indicate to the user that the application is starting up and loading necessary data for first-time use. The container application103can cause the Loading screen to be displayed by executing the appropriate function call (e.g., showLoading) to the operating system of the mobile device102.

The mobile application configuration module110generates (304) the configuration file based on the context data in the request, including the data that identifies Wealth Central as the launched application. At this point, the module110can also determine whether a session already exists between the container application103on the mobile device102and the module110on the server106. The session can be established based on any number of different considerations, including but not limited to the requirements of the communications protocol used between the devices102,106, management of application state information between the container application103and the module110, or the need for authentication of the user of the mobile device102. A session may already exist if, for example, the container application103has been used prior to the current launch within a predetermined amount of time (e.g., 5 minutes) and the mobile device102has not been powered off in the interim. In this example, the container application103is being launched for the first time after the device102is powered on, so communications between the container application103on the mobile device102and the module110on the server106has not been initiated yet, therefore no session exists.

The configuration file contains a series of parameters that control the user interface and functionality of the configuration application103. In this example, the module110determines that the Wealth Central application is launched and no session currently exists between the mobile device102and the server106. As a result, the module110generates a configuration file for display of a login screen in the container application103. In some embodiments, the module110generates the configuration file by retrieving parameters or other information (e.g., images, links) from a database (e.g., data source108) that are pre-established for use with the Wealth Central application.

An example configuration file generated by the module110is a Tab Configuration JSON object that contains the following properties:msgTxt—Message to be displayed before the login screen (optional);msgTitle—Title for above message (optional);stopApp—Indicates if the user can continue using the container application or not (optional);updateUrl—URL for downloading the latest version of the container application (optional);updateLabel—Label for the updateURL (optional);headerBkgr—RBG color values for the container application header;cacheLifetimeDays—Lifetime of the container application image cache;loginUrl—Login URL for the container application;tabs—Configuration object for all available tabs. Contains:label—Label (i.e., name) of the tab;image—PNG image to be displayed for the tab;url—Initial URL to be loaded for the tab;isPreload—Indicator for preloading the tab immediately after login;supportRotation—Indicator for supporting rotation of the tab.

Once the module110generates the configuration file, the module110transmits the configuration file to the container application103on the mobile device. Based on the configuration file, the container application103configures the user interface of the application and executes any logic or commands indicated in the configuration file. For example, if the version of the container application103that was launched on the mobile device102is out of date, the module110sets parameters in the configuration file so that the container application103performs a series of functions to inform the user to update the application103:msgTxt=“The current version of this app is out of date. Please update your application.”;stopApp=true;updateUrl=http://appstore.apple.comupdateLabel=Download

Based on the above settings, the container application103determines that the msgTxt parameter is not blank and the stopApp parameter is true, and the container application103displays a pop-up message with the message in the msgTxt field. The pop-up message does not contain a continue button because stopApp is true, meaning that the user should not be allowed to progress further with the application103. The container application103also determines that updateUrl and updateLabel are not blank, so the pop-up message also contains an update button labeled with updateLabel that when selected, launches a browser window pointing to updateUrl that allows the user to obtain the most current version of the application103. However, if the container application103is already the most current version, the module110generates a configuration file that does not have the parameters set in this way.

Continuing withFIG. 3, the container application103displays (306) a login screen, as shown inFIG. 5. Because the configuration file received from the module110included a loginUrl parameter, the container application103includes in the user interface an area with browser functionality500. The container application103issues a request to the URL indicated in the loginUrl parameter, and displays the web content returned from the URL request in the browser area500. In this manner, as with other user interface screens described herein, the user interface comprises web content that is dynamically retrieved from a server, instead of the user interface being stored or pre-coded into the container application103itself. As a result, the user interface can be quickly and easily changed for a large number of users by simply altering the web content—rather than being required to alter the configuration application and forcing users to download an updated version each time the user interface is updated.

The login screen includes fields for entering the user ID502and PIN504, and a toggle switch input506that enables the container application103to save the user ID so that the user can avoid re-entering the user ID upon subsequent uses of the application103. The container application also displays a Log In button508. In this example, the user ID502and PIN504are fields contained in the web content that the container application103displays based on the updateUrl field in the configuration file. The application103changes the appearance of the fields502and504to appear like other similar fields in native applications on the mobile device102. Because the fields502and504share an appearance similar to that of fields in native applications, the user assumes that the container application103is native to the mobile device102instead of a browser-based user interface that is downloaded using a URL.

In certain areas of the screen (e.g.,510,512), the user interface displays images associated with the Wealth Central application. In some embodiments, the images are downloaded as part of the web content request. In some embodiments, the images are stored as part of the container application103and the configuration file controls the display of the images in the user interface.

Once the user enters his or her ID and PIN in the appropriate fields and presses the Log in button506, the container application103transmits context data to the mobile application configuration module110with the entered credential information (in this case, the user ID and PIN). The module110authenticates (308) the user based on the credential information and determines his or her level of access to the Wealth Central application. For example, a first user may only be entitled to access his accounts and receive financial news, but a second user may be entitled to access her accounts, receive quotes for potential transactions/trades, and execute transactions using the application. As indicated above, the Tab Configuration JSON object previously transmitted to the container application103contains parameters to configure the appearance of all available tabs, including fields such as label, image, url. The module110now generates (308) an additional configuration file that includes parameters to configure the tabs available to the user after login has completed. Also, during the login process, the container application103can display a Loading screen by using the showLoading function call.

Once the module110has verified the credentials and authenticated the user, the module110transmits the additional configuration file to the container application103. The container application103then loads the tabs based on the Tab Configuration JSON object previously received from the mobile application configuration module110. As part of the tab loading process, the container application103issues requests and receives content from locations based on the url field for each tab. The container application103may locally cache images contained in the web content that it receives to enable faster access during future use of the application103. The container application103also reloads images it has previously cached if those images are older than a pre-defined expiration date. Further, a session is created between the container application103on the mobile device102and the mobile application configuration module110on the server106. The session acts to preserve the context of the conversation between the two devices102,106and two applications103,110such that navigation of the application103and interaction with the module110is enhanced. For example, the container application103is now aware of the identity of the user, based on the authenticated credential information. The container application103does not need to continually re-authenticate the user every time the application103issues an information request or transaction command to the module110. Also, the container application103can use the preserved context information to improve the navigation capabilities of the user interface. In one example and as explained in more detail below, when a user navigates between tabs in the application103, the application can request customized web content based on, e.g., the identity of the user in the session context data, and present the customized web content in the user interface without requiring additional inputs.

It should be noted that the identity of the user is not limited to personal information (name, address). A user can also be associated with a company or a group that has certain predefined attributes that are reflected in user interface of the container application103. In one example, the container application103can dynamically change the user interface appearance based on the company associated with the user. The container application103may download and/or display images (e.g., logos) that are specific to the company based on the context of the session, thereby providing a branded experience to the user. The context enables the application103to make appearance changes without requiring extensive reconfiguration of the application103(e.g., in the case of a pre-stored and pre-compiled user interface). Because the container application103preserves the context as the user navigates, the application103is uniquely customized to the user.

Next, the container application103deletes any tabs that the authenticated user is not entitled to access. For example, a user may only be entitled to access the Accounts and Clients tabs, but be unable to access the News tab. The configuration file received by the container application103identifies which tabs the user can view (e.g., Accounts, Clients). The container application103determines the remaining tabs that should not be displayed in the user interface and calls the deleteTabs function call (explained above) with arguments for each tab to be removed.

Once the application103has completed configuration of the tabs, the application displays (310) the landing screen, as shown inFIG. 6. The user interface of the landing screen is divided into two sections: the top section602is a display area using browser functionality of the mobile device102to display the list of available tabs604, and the bottom section606is a display area containing a menu bar608with a series of buttons that are native to the operating system of the mobile device102. As with the Login screen, the application103changes the appearance of the list of available tabs604to appear as though it was generated by the native operating system. Also, the container application103configures the menu bar608to contain only those buttons that correspond with tabs or functionality to which the user is entitled access. In combination, the top area602and the bottom area606appear to the user as though the user interface is seamlessly generated by the native operating system, when the top area is generated through use of web content retrieved from a URL and the bottom area is native content. Upon being presented with the landing screen, the user can select one of the available tabs604or one of the buttons in the menu bar608. In this example, the user selects (310) the Accounts tab. As described previously, the container application103uses the configuration file to determine the URL provided in the url field for the Accounts tab. The URL can, but does not have to, point to the server106. The URL can point to another server (not shown) that provides web content to the container application103.

The container application103issues a request to the server identified in the Accounts tab URL, the identified server retrieves (312) UI content for the Accounts tab, and the application103receives the UI content in response to the request. The container application103displays (314) the Accounts tab, as shown inFIG. 7. The Accounts screen contains a top area702containing a list of accounts704available for viewing based on the context data (e.g., user's credentials), and a bottom area706containing a menu bar708with buttons native to the operating system. Similar to the landing screen, the top area702is generated through use of web content retrieved from the Accounts tab URL and the bottom area706is native content. In this example, the user then selects (314) the Quotes button in the menu bar706at the bottom of the screen. Similar to the tabs, the Quotes button (and the other buttons in the menu bar706) can have an associated URL. In some embodiments, each of the buttons in the menu bar706corresponds to a tab of the container application103.

The container application103issues a request to the server identified in the Quotes tab URL, the identified server retrieves (316) UI content for the Quotes tab, and the application103receives the UI content in response to the request. The container application103displays (318) the Quotes tab, as shown inFIG. 8. The Quotes screen contains a top area802containing the current pricing information for a tradable security804(e.g., Ford stock) available for viewing based on the context data (e.g., user's credentials), and a bottom area806containing a menu bar808with buttons native to the operating system. Similar to the landing screen and Accounts tab, the top area802is generated through use of UI content retrieved from the Quotes tab URL and the bottom area806is native content.

To provide for interaction with a user, the above described techniques can be implemented on a computer in communication with a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, and/or tactile input.

Information transfer over transmission medium can be based on one or more communication protocols. Communication protocols can include, for example, Ethernet protocol, Internet Protocol (IP), Voice over IP (VOIP), a Peer-to-Peer (P2P) protocol, Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP), Signaling System #7 (SS7), a Global System for Mobile Communications (GSM) protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, and/or other communication protocols.

Devices of the computing system can include, for example, a computer, a computer with a browser device, a telephone, an IP phone, a mobile device (e.g., cellular phone, personal digital assistant (PDA) device, laptop computer, electronic mail device), and/or other communication devices. The browser device includes, for example, a computer (e.g., desktop computer, laptop computer) with a World Wide Web browser (e.g., Microsoft® Internet Explorer® available from Microsoft Corporation, Mozilla® Firefox available from Mozilla Corporation). Mobile computing device include, for example, a Blackberry®. IP phones include, for example, a Cisco® Unified IP Phone 7985G available from Cisco Systems, Inc, and/or a Cisco® Unified Wireless Phone 7920 available from Cisco Systems, Inc.

One skilled in the art will realize the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting of the invention described herein.