Application cards based on contextual data

A server includes a network communication device, a storage device, and a processing device. The processing device executes computer-readable instructions that, when executed by the processing device, cause the processing device to: receive contextual data from a client computing device via the network communication device, the contextual data indicates a first application view displayed on the client computing device; identify a first application function ID that identifies a first application function corresponding with the first application view; determine a first user intent ID that corresponds with the first application function ID; determine a second user intent ID that transitions from the first user intent ID; identify a second application function ID that corresponds with the second user intent ID; retrieve a card object corresponding with the second application function ID from the storage device; and transmit the card object to the client computing device via the network communication device.

TECHNICAL FIELD

This disclosure relates to determining application cards for display on a mobile computing device based on contextual data of the mobile computing device.

BACKGROUND

Many mobile computing devices can install and execute applications. Applications include application functions that a user of the mobile computing device may use to perform a particular task. For example, a crowd-sourced review application may include a restaurant review function that enables a user to view restaurant reviews. A ride-requesting application may include a ride-requesting function that enables a user to request a ride from one place to another. Many mobile computing devices allow users to switch between applications. For example, a user can switch from viewing a restaurant review in the crowd-sourced review application to requesting a ride to the restaurant in the ride-requesting application.

SUMMARY

A server may include a network communication device, a storage device and a processing device. The storage device may store an application function data store, a user intent data store and a card data store. The application function data store stores application function identifiers (IDs) that identify application functions, and user intent IDs that identify user intents corresponding with the application function IDs. The user intent data store stores the user intent IDs and transitions between the user intent IDs. The card data store stores card objects corresponding with the application function IDs. Each card object may include computer-readable instructions that are executable at client computing devices to perform the application function identified by the application function ID. The processing device can execute computer-readable instructions that, when executed by the processing device, cause the processing device to receive contextual data from a client computing device via the network communication device. The contextual data may indicate a first application view currently being displayed on the client computing device.

The processing device may identify a first application function ID that identifies a first application function corresponding with the first application view by comparing the contextual data with the application function IDs stored in the application function data store. The processing device may determine a first user intent ID that corresponds with the first application function ID. The first user intent ID may indicate a current user intent of a user of the client computing device. The processing device may determine a second user intent ID that transitions from the first user intent ID. The second user intent ID may indicate a prediction of a subsequent user intent of the user based on the current user intent. The processing device may identify a second application function ID that corresponds with the second user intent ID. The second application function ID may identify a second application function. The processing device may retrieve a card object corresponding with the second application ID from the card data store. The processing device may transmit the card object to the client computing device via the network communication device.

A mobile computing device may include a touchscreen display, a plurality of sensors, a transceiver, a memory, and a computing processor. The computing processor may execute computer-readable instructions that, when executed by the computing processor, cause the computing processor to display a first application view representing a first application function on the touchscreen display. The computing processor may store contextual data in the memory. The contextual data may include a first application function identifier (ID) that identifies the first application function. The contextual data may include sensor measurements measured by the plurality of sensors. The contextual data may include application function usage data including a history of application views displayed on the touchscreen display. The computing processor may transmit the contextual data to a server via the transceiver. The computing processor may receive a card object from the server in response to transmitting the contextual data to the server. The card object may indicate a second application function ID that identifies a second application function. The computing processor may determine a rendering of an application card representing the second application function based on the card object. The computing processor may display the application card concurrently with the first application view.

A computer-implemented method may include storing, in a storage device of a server, an application function graph that stores application function identifiers (IDs) as graph nodes and user intent IDs that identify user intents corresponding with the application function IDs. The application function IDs identify application functions. The method may include storing, in the storage device, a user intent graph that stores the user intent IDs as graph nodes and transitions between the user intent IDs as edges. The method may include storing, in the storage device, a card data store that stores card objects corresponding with the application function IDs. Each card object may include computer-readable instructions that are executable at client computing devices to perform the application function identified by the application function ID. The method may include receiving, via a network communication device of the server, contextual data from a client computing device. The contextual data may indicate a first application view currently being displayed on the client computing device.

The method may include identifying, by a processing device of the server, a first application function ID that identifies a first application function corresponding with the first application view by comparing the contextual data with the application function IDs stored in the application function data store. The method may include determining, by the processing device, a first user intent ID that corresponds with the first application function ID. The first user intent ID may indicate a current user intent of a user of the client computing device. The method may include determining, by the processing device, a second user intent ID that transitions from the first user intent ID. The second user intent ID may indicate a prediction of a subsequent user intent of the user based on the current user intent. The method may include identifying, by the processing device, a second application function ID that corresponds with the second user intent ID. The second application function ID identifies a second application function. The method may include retrieving, by the processing device, a card object corresponding with the second application ID from the card data store. The method may include transmitting, via the network communication device, the card object to the client computing device.

DETAILED DESCRIPTION

Mobile computing devices enable users to switch between applications in order to perform different application functions. Switching between applications is time-consuming because it takes considerable time to launch an application and manually navigate to an application view within the application. Furthermore, a user may have to press several buttons to switch from viewing a first application view in a first application to viewing a second application view in a second application. For example, the user may have to press a home button to switch to a home screen, select an icon to launch the second application, and then navigate to the second application view within the second application. Excessive presses of the home button may accelerate wear and tear. Time wasted in manually navigating between application views may increase power consumption and accelerate battery drainage. Lastly, due to the exponential growth of applications, discovering application functions and their corresponding application views has become increasingly challenging.

The mobile computing device can display a first application view of a first application function and concurrently display an application card for a second application function. The application card may include application controls that allow a user of the mobile computing device to use the second application function without manually navigating to a second application view of the second application function. The application card may include executable instructions that the mobile computing device can execute to perform the second application function. The mobile computing device can display the application card based on contextual data of the mobile computing device.

The contextual data may indicate an application view currently being displayed on the mobile computing device. For example, upon displaying an application view for a restaurant-review function in a crowd-sourced review application, the mobile computing device can display an application card for a request-a-ride function in a ride-requesting application. The contextual data can include sensor measurements (e.g., accelerometer readings). For example, upon detecting that the user of the mobile computing device is walking and using the restaurant-review function, the mobile computing device can display an application card for a reserve-table function from a table-reserving application. The contextual data may include a history of previously displayed application views and the mobile computing device may display the application card based on the history.

The application card may display graphical user interface (GUI) elements that receive function parameters for the application function represented by the application card. The function parameters may be populated based on the contextual data. For example, a destination address in the application card for the request-a-ride function may be populated with a restaurant address displayed in the application view for the restaurant-review function. The GUI elements in the application card may be similar to GUI elements in an application view of the application function. Furthermore, similar to the GUI elements in the application view of the application function, the GUI elements in the application card can invoke the same application programming interfaces (APIs), libraries and endpoints to operate in the same manner.

FIG. 1illustrates an example system10that displays an application view46and an application card50in conjunction with an application function146. In the illustrated example, the system10includes a server100, a client computing device140, and a network190. The server100and the client computing device140may store applications that have application functions146(e.g.,146-1,146-2. . .146-N). The applications may have application views46(e.g.,46-1,46-2. . .46-N) that represent the application functions146. The server100may store application cards50(e.g.,50-1,50-2. . .50-N) that represent the application functions146. The application views46and the application cards50may include computer-readable instructions that can be executed by the client computing device140to perform representative application functions146. The application views46and the application cards50may invoke application programming interfaces (APIs), libraries and/or endpoints associated with their representative applications functions146to perform the application functions146.

The client computing device140may display an application view46-1of an application function146-1. The application view46-1may be referred to as a current application view, for example, because a user of the client computing device140may be viewing the application view46-1. In the example ofFIG. 1, the application view46-1displays a representation of a restaurant review function of a crowd-sourced review application. An example of the crowd-sourced review application is the YELP® application (hereinafter, Yelp). As illustrated, the application view46-1is displaying a restaurant review for a restaurant named Thai Palace.

The client computing device140may display an application card50-2of another application function146-2. The application function146-2may be referred to as a subsequent application function, for example, because the user of the client computing device140may use the application function146-2after (e.g., immediately after) using the application function146-1. In the example ofFIG. 1, the application function146-2is a request-a-ride function of a ride-requesting application. An example of the request-a-ride function is the Request an UberX® driver function (hereinafter, Request UberX) in the UBER® application (hereinafter, Uber). The application card50-2may include computer-readable instructions that upon execution perform the application function146-2.

The application card50-2may be referred to as a Deep View Card (DVC), for example, because the application card50-2displays GUI elements that correspond with function parameters of the application function146-2. Put another way, an application card50-2allows a user to leverage a function of the corresponding application, and in some scenarios, to parameterize the card with one or more values. For example, a user may enter a pickup location and/or a drop-off location into an application card that leverages the reserve UberX function of Uber. The client computing device140may display the application card50-2such that the application card50-2hovers over the application view46-1. The client computing device140may control a transparency of the application card50-2such that the application card50-2may not conceal portions of the application view46-1. The GUI elements of the application card50-2enable a user to use the application function146-2without switching applications and manually navigating to an application view46-2representing the application function146-2.

In the illustrated example, the GUI elements of the application card50-2include first and second text fields150,152, first and second text labels154,156, and a button158. The text fields150,152may receive parameters for the application function146-2. For example, the first text field150may receive a current address and the second text field152may receive a destination address. The first and second text fields150,152may be populated based on information displayed in the application view46-1. For example, a restaurant address displayed by the restaurant review function may be used to populate the destination address. The first and second text labels154,156may display information that is determined by invoking an API, a library and/or an endpoint associated with the application function146-2. For example, the application card50-2may use a fare estimate endpoint associated with the application function146-2to determine a fare estimate displayed by the text label154. Similarly, the application card50-2may use a time estimate endpoint associated with the application function146-2to determine a time estimate displayed by the text label156.

The client computing device140may receive a selection of the button158, for example, when the user presses the button158. The application card50-2may use the parameters received through the text fields150and152to perform a task (e.g., request an UberX ride) upon receiving a selection of the button158. By determining (e.g., predicting) that the user of the client computing device140may use the application function146-2and automatically displaying the application card50-2, the user may not have to switch applications and manually navigate to the application view46-2. For example, the user may not have to press a home button to go to a home screen, find an Uber icon in an application tray, select the Uber icon to launch Uber, and then navigate to the request UberX function within the Uber application.

The client computing device140may receive the application card50-2from the server100. Receiving the application card50-2indicates that the server100has determined (e.g., predicted) the application function146-2as the subsequent application function the user of the client computing device140may use after using the application function146-1. The client computing device140may send contextual data160to the server100. The server100may use the contextual data160to select the application card50-2from the application cards50. The server100may transmit the application card50-2to the client computing device140as a card object180(e.g., using JavaScript Object Notation (JSON)).

The contextual data160may include on-screen application information162. The on-screen application information162may include an application identifier (application ID)164that indicates a current application being displayed at the client computing device140. For example, the application ID164may include an application ID for the YELP® application. The on-screen application information162may include an application function ID166that indicates a current application function being displayed at the client computing device140. For example, the application function ID166may include an application function ID for the application function146-1. The on-screen application information162may include information that indicates the application view46-1. The on-screen application information162may include information displayed at the client computing device140. For example, the on-screen application information162may indicate that the client computing device140is displaying a restaurant review for a restaurant named Thai Palace.

The contextual data160may include sensor measurements168. The client computing device140may include sensors (e.g., location sensor, accelerometer, gyroscope, or the like). The sensors may record (e.g., capture) the sensor measurements168. Example sensor measurements168may include a location of the client computing device140, an accelerometer reading, a gyroscope reading or the like. The contextual data160may include an application function usage history170. The application function usage history170may indicate a sequence in which the application functions146were used. For example, the application function usage history170may indicate that the application function146-2of the second application is used immediately after the application function146-1of the first application 85% of the time. The application function146-2being used immediately after the application function146-1may refer to the application function146-2being used within a threshold amount of time from the usage of the application function146-1(e.g., within 5 seconds).

The server100receives the contextual data160and determines a relevant application card50based on the contextual data160. In the example ofFIG. 1, the server100determines the application card50-2as the most relevant application card50. Determining the relevant application card50may include determining the subsequent application function that the user of the client computing device140may use after using the current application function. In the example ofFIG. 1, the server100determines the application function146-2as the subsequent application function based on the application function146-1being the current application function. The server100indicates its determination of the subsequent application function via the card object180.

The card object180may include an application ID182. The application ID182may identify an application (e.g., Uber) that includes the application function146-2. The card object180may include an application function ID184. The application function ID184may identify the application function146-2. The card object180may indicate a layout186for the application card50-2. The layout186may include computer-readable instructions that the client computing device140can execute to render the application card50-2. The layout186may indicate the GUI elements for the application card50-2. The layout186may indicate function parameters for the application function146-2. The server100may transmit the layout186as a layout file. The client computing device140receives the card object180and renders the application card50-2based on the information included in the card object180.

FIG. 2Aillustrates another example application card50-3for an application function146-3. In the example ofFIG. 2A, the application function146-3refers to a “reserve table” function, where a user can request a reservation at a particular establishment at a particular date and time. The application view46-1may display a restaurant review of a restaurant and the application card50-3enables the user to reserve a table at the restaurant. For example, the application view46-1may display a review of Thai Palace and the application card50-3enables the user to reserve a table at Thai Palace. By displaying the application card50-3in conjunction with the application view46-1, the user does not have to manually navigate to the application view46-3representing the application function146-3. For example, a user viewing a review of Thai Palace on the YELP® application does not have to press the home button to go to the home screen, launch another application (e.g., the OPENTABLE® application), and then navigate to the reserve table function within the OPENTABLE® application.

The application card50-3may include GUI elements that enable the user of the client computing device140to use (e.g., operate) the application function146-3. The GUI elements may include drop-downs248,250,252, and a button254. The drop-down248may allow a user to enter a number of guests that may go to the restaurant. The drop-down250may allow a user to enter a date for the table reservation. The drop-down252may allow a user to enter a reservation time. The button254may be a submit button. Upon receiving a selection of the button254, the application function146-3may generate a request for a reservation at the restaurant indicated by the application card50-3for the entered number of guests (e.g., two) at the given time and date (Saturday, May 31 at 7:00 PM).

A server (e.g., server100inFIG. 1) may determine (e.g., predict) the application function146-3as a subsequent application function that a user of the client computer device140may use after using the application function146-1. For example, the server may determine that a user may reserve a table at a restaurant that the user is reading a review about through the application view46-1. The server may select default values for the drop-downs248,250and252. The server may select values for the drop-downs248,250and252based on the contextual data received from the client computing device140. For example, the contextual data may indicate historical values that the user selected for the drop-downs248,250and252. The user may change the values of the drop-downs248,250and252. For example, the user may increase the number of people from2to4.

FIG. 2Billustrates another example application card50-4that represents an application function146-4. In the example ofFIG. 2B, the application function146-4refers to a messaging function. The application view46-1may display a restaurant review of a restaurant and the application card50-4enables the user to send a message to a contact about the restaurant. For example, the application view46-1may display a review of Thai Palace and the application card50-4enables the user to send a message about Thai Palace. By displaying the application card50-4in conjunction with the application view46-1, the user does not have to manually navigate to an application view corresponding with the application function146-4. For example, a user viewing a review of Thai Palace on YELP® does not have to press the home button to go to the home screen, launch another application (e.g., Messenger®), and navigate to the messaging function within the Messenger® application.

The application card50-4includes GUI elements that enable the user of the client computing device140to use (e.g., perform) the application function146-4. The GUI elements may include a drop-down260, a text field262, and a button264. The drop-down260may indicate a contact. The text field262may receive and display a message that can be sent to the contact. The button264may be a submit button. Upon receiving a selection of the button264, the application function146-4may send the message to the contact.

A server (e.g., server100inFIG. 1) may determine (e.g., predict) the application function146-4as a subsequent application function that a user of the client computer device140may use after using the application function146-1. For example, the server may determine that a user may message a contact about a restaurant when the user is reading a review of the restaurant in the application view46-1. The server may select a value for the drop-down260to be a contact with whom the user of the client computing device140communicates most frequently. The server may select a value for the drop-down260to be the last contact with whom the user of the client computing device140communicated. The server may select a default message as a value for the text field262. The server may select a value for the text field262based on the contextual data received from the client computing device140. For example, the contextual data may indicate historical messages that the user may have sent to the contact indicated by the drop-down260. The user may change the value of the drop-down260and the text field262. For example, the user can send the message to Veronica instead of Betty.

FIG. 3Aillustrates an example application view46-4that represents an application function146-4of the active application. In the example ofFIG. 3A, the active application is a messaging application, and the application function146-4is a messaging function of the messaging application. The application function146-4may enable a user of the client computing device140to send and receive messages. The client computing device140may display the application card50-1in conjunction with the application view46-4. The client computing device140may display the application card50-1based on detecting an entity310in a message312. The entity310may be associated with the application function146-1. For example, the entity310may be a restaurant and the application function146-1may be a restaurant review function that can display a review of the restaurant.

A server (e.g., server100inFIG. 1) may receive the message312as contextual data. The server may identify the entity310in the message312. The server may identify an application function that is associated with the entity310. The server may identify the application function by identifying an application function that can display information about the entity310. For example, the server may identify Thai palace as the entity310and the restaurant review function of YELP® as the application function146-1.

The application card50-1may be an advertisement (e.g., sponsored application card). The application card50-1may include indicium320, for example, to indicate that the application card50-1is an advertisement. A developer of the active application may receive a financial incentive when an application card50is displayed. The developer may receive the financial incentive in response to the client computing device140performing a defined action. For example, the developer of the application function146-4may receive the financial incentive when the user clicks on the application card50-1(e.g., pay-per-click) or when the application card50-1is overlaid upon the GUI of the application (e.g., pay-per-impression).

The server may determine that two application functions correspond with the entity310. The server may determine a financial incentive associated with selecting each application function and select the application function with the higher financial incentive. For example, the server may determine that the restaurant review function of the YELP® application and a restaurant review function of the TRIPADVISOR® application (another crowd-sourced review application) correspond with the restaurant entity310“Thai Palace”. The server may select the restaurant review function of the YELP® application instead of the restaurant review function of the TRIP ADVISOR® application, for example, because YELP® provides a financial incentive of $0.37 whereas TRIP ADVISOR® only provides $0.25.

In the example ofFIG. 3A, the application function146-4may be referred to as a current application function. The application function146-1may be referred to as a predicted subsequent application function, for example, because the application function146-1may be a prediction of an application function that the user may use subsequent to using the application function146-4. Advantageously, the user of the client computing device140may view a restaurant review of Thai Palace without having to manually launch the YELP® application and searching for Thai Palace within the YELP® application. Furthermore, the user may launch the YELP® application to a state that displays the restaurant review of Thai palace by pressing on the application card50-1.

FIG. 3Billustrates an example implementation in which the client computing device140replaces the application card50-1with another application card50-3as the information displayed by the application view46-4changes. In the example ofFIG. 3B, the client computing device140displays the application view46-4for the application function146-4. The client computing device140may receive a message330through the application function146-4. The message330may indicate a date332and a time334. The client computing device140may transmit the date332and the time334as contextual data to a server (e.g., server100inFIG. 1).

The server receives the contextual data including the messages312and330. The server may use the messages312and330to predict an application function that the user of the client computing device140may use subsequent to using the application function146-4. The server may identify the entity310as a restaurant. The server may identify a date entity332and a time entity334in a subsequent message330. The server may predict that the user intends to reserve a table at the restaurant at the date and time indicated in the message330. The server may identify an application function (e.g., application function146-3) that enables that user to reserve a table at the restaurant. In the example ofFIG. 3B, the application function146-3is a “reserve table” function of the OPENTABLE® application. The server transmits the application card50-3representing the application function146-3.

The application card50-3may receive function parameters. The function parameters may include a number of guests (e.g., drop-down248), a date (e.g., drop-down250), and a time (e.g., drop-down252). The server may determine values for the function parameters based on the contextual data. For example, the server may determine the date and time function parameters by identifying the date entity332and the time entity334in the message330. A developer of the application function146-3may provide a financial incentive to a developer of the application function146-4for displaying the application function146-3. For example, the developer of the OPENTABLE® application may provide a financial incentive to the developer of the MESSENGER™ application (e.g., Facebook, Inc.) for displaying the reserve table function of the OPENTABLE® application based on the messages communicated via MESSENGER™. By displaying the application card50-3, the user of the client computing device140does not have to manually launch the OPENTABLE® application, navigate to an application view for the reserve table function, and manually enter the function parameters.

FIG. 4illustrates a server400. The server400illustrates an example implementation of the server100. The server400receives contextual data (e.g., contextual data160) from a client computing device (e.g., client computing device140). The contextual data indicates a current application view that the client computing device may be currently displaying. The server400uses the contextual data to determine an application card (e.g. application card50) that can be displayed on the client computing device in conjunction with the current application view. The server400transmits the application card to the client computing device. The server400may transmit the application card to the client computing device by transmitting a card object (e.g., card object180).

The server400may include a processing device402, a storage device404, and a network communication device406. The processing device402may include a collection of one or more computing processors that execute computer readable instructions. The computing processors of the processing device402may operate independently or in a distributed manner. The computing processors may be connected via a bus and/or a network. The computing processors may be located in the same physical device (e.g., same housing). The computing processors may be located in different physical devices (e.g., different housings, for example, in a distributed computing system). A computing processor may include physical central processing units (pCPUs). A pCPU may execute computer-readable instructions to implement virtual central processing units (vCPUs). The processing device402may execute a current user intent ID determiner416(intent estimator416, hereinafter), a subsequent user intent ID determiner420(intent predictor420, hereinafter), an application function ID determiner424(function determiner424, hereinafter), and a result generator428. The processing device402may execute instructions, stored in the storage device404that cause the processing device402to implement the intent estimator416, the intent predictor420, the function determiner424, and the results generator428.

The storage device404stores data. The storage device404may include one or more computer readable storage mediums. For example, the storage device404may include solid state memory devices, hard disk memory devices, optical disk drives, a read-only memory, nanotube-based storage devices, or the like. The storage device404may be connected to the processing device402via a bus and/or a network. Different storage mediums within the storage device404may be located at the same physical location (e.g., in the same data center, same rack, or same housing). Different storage mediums of the storage device404may be distributed (e.g., in different data centers, different racks, or different housings). The storage device404may implement (e.g., store) a user intent data store410(e.g., intent graph), an application function data store408(e.g., function graph), and an application card data store412.

The network communication device406may communicate with a network (e.g., network190shown inFIG. 1). The network communication device406may include one or more communication interfaces that perform wired communication (e.g., via Ethernet, Universal Serial Bus (USB), or fiber-optic cables). The network communication device406may perform wireless communication (e.g., via Wi-Fi, cellular network, or satellites). The network communication device406may include a transceiver that communicates with the network in accordance with an Institute of Electrical and Electronics Engineers (IEEE) specification (e.g., Ethernet, Wireless Local Area Network (LAN), or the like). The network communication device406may include a transceiver that communicates with the network in accordance with a 3rd Generation Partnership Project (3GPP) specification (e.g., Code Division Multiple Access (CDMA), Long Term Evolution (LTE), LTE-Advanced, or the like). The network communication device406may include a transceiver that communicates with the network in accordance with a Universal Serial Bus (USB) specification (e.g., via a USB port).

The server400may be implemented by a cloud computing platform. The cloud computing platform may include a collection of remote computing services. The cloud computing platform may include computing resources (e.g., processing device402). The computing resources may include servers (e.g., physical servers or virtual machines). The cloud computing resources may include storage resources (e.g., storage device404). The storage resources may include database servers that may support NoSQL, MySQL, Oracle, SQL Server, or the like. The cloud computing platform may include networking resources (e.g., network communication device406). For example, the networking resources may distribute incoming requests for event notifications across multiple virtual private servers. Example cloud computing platforms include Amazon Web Services®, and Google Cloud Platform™.

The application function data store408may store application function identifiers (IDs). An application function ID may identify a corresponding application function. An application function ID may be associated with a user intent ID. The user intent ID associated with an application function ID may indicate an intent of a user that is currently using the corresponding application function. For example, a user intent ID for a restaurant review function may refer to the following user intent: ‘learn about a restaurant’. Similarly, a user intent ID of a reserve table function may refer to ‘reserve a table at the restaurant’. Furthermore, a user intent ID of a request-ride function may refer to ‘travel to a destination address’. Moreover, a user intent ID of a deliver food function may refer to ‘order food from a restaurant’.FIG. 5illustrates an example implementation of the application function data store408. The server400may determine the application function IDs and the user intent IDs associated with the application function IDs, for example, based on input from an operator (e.g., a human operator).

The user intent data store410may store user intent IDs that refer to user intents. The user intent data store410may store relationships (e.g., temporal relationships) between the user intent IDs. For example, the user intent data store410may store transitions between the user intent IDs. The user intent data store410may indicate a prediction of a subsequent user intent ID given a current user intent ID. An example subsequent user intent may refer to ‘go to a restaurant’, for example, if a current user intent ID refers to ‘learn about a restaurant’. Another example subsequent user intent ID may refer to ‘reserve a table at a restaurant’, for example, if a current user intent ID refers to ‘learn about the restaurant’.FIG. 6illustrates an example implementations of the user intent data store410. The server400may determine the transitions between the user intent IDs, for example, based on input from an operator (e.g., a human operator).

The application card data store412may store card objects180that can be used to display application cards50. The application card data store412may store the card objects180as card records. Each card object180may correspond with an application function. The card object180may include a template for the application card50. The template may include GUI elements for the application card50. Each GUI element may correspond with a function parameter of the application function. The card object180may include a uniform resource location (URL) that indicates the function parameters of the application function. An example card object180for the reserve-table function may indicate that the reserve-table function receives the following function parameters: a restaurant name, a number of guests, a reservation date, and a reservation time. Another example card object180for the restaurant-review function may indicate that the restaurant-review function has the following function parameters: a restaurant name and a location. Another example card object180for the request-ride function may indicate that the request-ride function receives the following function parameters: an origin address and a destination address.

The card object180may include computer-readable instructions for the client computing device140on rendering the application card50at the client computing device140. The card object180may include computer-readable instructions that can be executed by the client computing device140to perform the corresponding application function. The computer-readable instructions in the card object180may refer to APIs, libraries and/or endpoints of the corresponding application function. When the computer-readable instructions in the card object180are executed by the client computing device140, the client computing device140can make API calls to perform the corresponding application function.

The server400may receive the card objects180from an operator (e.g., a human operator). The server400may generate the card objects180by identifying function parameters of application functions. For example, the server400may analyze an application to determine the application functions within the application. The server400determine the function parameters of an application function by analyzing application views representing the application functions. For example, the server400may identify the function parameters by identifying text boxes and dropdowns in the application views. The server400identify the function parameters by crawling and/or scraping websites associated with applications. For example, the server400may identify function parameters on a website associated with an application and determine that the application includes the same function parameters.

The intent estimator416determines (e.g., estimates) a current user intent ID418based on the contextual data160. The contextual data160may indicate a current application view46that the client computing device140may be displaying. The intent estimator416may identify the current application function ID, for example, by identifying the function ID166(shown inFIG. 1). The intent estimator416may query the application function data store408to determine a user intent ID associated with the application function ID166. The intent estimator416may access the application function data store408and retrieve a user intent ID associated with the application function ID166. The user intent ID associated with the application function ID166may be referred to as the current user intent ID418. The current user intent ID may indicate a current intent of the user of the client computing device140.

The application function ID166, in some examples, is associated with multiple user intent IDs. Each user intent ID may include a confidence value that indicates a likelihood of the application function ID166matching the user intent ID. The intent estimator416may select the user intent ID with the highest confidence value. For example, the application function ID166may be associated with three different user intent IDs. One of the three user intent IDs may have a confidence value of 0.6 and the other two user intent IDs may have a confidence value of 0.2. The intent estimator416may select the user intent ID that has the confidence value of 0.6. The confidence values may be pre-determined (e.g., pre-calculated). For example, an operator (e.g., human operator) may input the confidence values in the application function data store408.

The intent predictor420determines (e.g., predicts) a subsequent user intent ID422based on the current user intent ID418. The intent predictor420may query the user intent data store410to determine a likely subsequent user intent ID422for the current user intent ID418. The user intent data store410may store user intent IDs. For some user intent IDs, the user intent data store410may store a likely subsequent user intent ID422. The intent predictor420may determine the subsequent user intent ID422by accessing the user intent data store410and retrieving the subsequent user intent ID associated with the current user intent418. The intent predictor420may determine that the subsequent user intent ID422refers to ‘going to the restaurant’, for example, if the current user intent ID418refers to ‘learning about the restaurant’ and an accelerometer measurement indicates that the user is walking towards the restaurant. The intent predictor420may determine that the subsequent user intent ID422refers to ‘reserve table at the restaurant’, for example, if the current user intent ID418refers to ‘planning to go to the restaurant’ (e.g., as illustrated inFIG. 3B).

The function determiner424determines (e.g., identifies) an application function426that corresponds with the predicted subsequent user intent ID422. The function determiner424may identify the application function426by searching the application function data store408based on the predicted subsequent user intent ID422. The function determiner424may access the application function data store408and retrieve an application function ID that corresponds with the predicted subsequent user intent ID422. The function determiner424may identify an application function that most closely matches (e.g., fulfills) the predicted subsequent user intent ID422. The function determiner424may receive a list of application function IDs from the application function data store408. Each application function ID may include a relevance value that indicates a relevance of the corresponding application function ID to the predicted subsequent user intent ID422. The function determiner424may select the application function ID with the highest relevance value. An operator (e.g., human operator) may input the relevance values into the application function data store408.

The result generator428determines (e.g., selects) the card object180for the predicted application function426. The result generator428may access the application card data store412and retrieve the card object180corresponding with the predicted application function426. The card object180may include function parameters for the predicted application function426. The result generator428may determine (e.g., populate) the function parameters based on the contextual data160. For example, the result generator428may determine a destination address parameter for a request ride application function based on an address displayed in the application view46.

The application card data store412may store multiple corresponding card objects180for the application function426. Some of the card objects180may be suitable for the client computing device140, if an application including the application function426is installed on the client computing device140. Other card objects180may be suitable for the client computing device140, if the client computing device140does not have an application that includes the application function426. The contextual data160may indicate the applications installed on the client computing device140. The results generator428may select the appropriate card object180upon determining whether the application function426is installed on the client computing device140.

Card objects180that are selected when the client computing device140does not include the application function426may include sufficient computer-readable instructions that can be executed by the client computing device140to perform the application function426. Card objects180that are selected when the client computing device140includes the application function426may include fewer computer-readable instructions that: invoke the application function426on the client computing device140, and cause the client computing device140to execute the application function426in the background when the application card50is displayed.

FIG. 5illustrates an example application function graph500. The application function graph500may be stored in the application function data store408. The application function graph500may include graph nodes510that store information about application functions146-1,146-2. . .146-8. For example, the graph nodes510may store application function IDs for the application functions146-1,146-2. . .146-8. The graph nodes510may be connected via edges520and530. The application functions146-1,146-2. . .146-8may be associated with user intents148-1,148-2. . .148-10. The graph nodes510may stores user intent IDs that refer to the user intents148-1,148-2. . .148-10. In the example ofFIG. 5, the application function146-1may refer to a restaurant review function in a crowd-sourced review application (e.g., YELP®) and the user intent148-1may refer to ‘learning about the restaurant’. The application function146-2may refer to a request ride function (e.g., request UberX® function) in a ride-sharing application (e.g., UBER®) and the user intent148-2may refer to ‘going to restaurant’. The application function146-3may refer to a reserve table function in a table reservation application (e.g., OPENTABLE®) and the user intent148-3may refer to ‘reserving a table at the restaurant’.

An application function ID may be associated with multiple user intent IDs. For example, the application function146-4(e.g., messaging contact function) may be associated with user intents148-4,148-9and148-10. The user intent148-4may refer to ‘chatting with a contact’. The user intent148-9may refer to ‘planning to eat from a restaurant’, for example, when a message includes the restaurant name (e.g., entity310inFIG. 3B). The user intent148-10may refer to ‘planning to go to the restaurant’, for example, when messages include the restaurant name, a data and a time (e.g., date332and time334inFIG. 3B). The application function146-5may refer to a deliver food function of a food delivery application (e.g., Eat24) and the user intent148-5may refer to ‘order food from the restaurant’.

The edges520and530may indicate transitions between the application function IDs. A transition from the application function146-1to the application function146-2may refer to the application function146-2being used immediately after (e.g., within a threshold time period) the application function146-1. The edges520may indicate transitions that a developer may have specified (e.g., programmed in program code for an application function). An edge520from the application function146-1to the application functions146-6,146-7and146-8indicates that the application function146-1includes developer-programmed user-selectable links to the application functions146-6,146-7and147-8. For example, a restaurant review function (e.g., application function146-1) may include a user-selectable link for getting directions to the restaurant (e.g., application function146-6). Furthermore, the restaurant review function may include a user-selectable link for exploring a menu of the restaurant (e.g., application function146-7). Moreover, the restaurant review function may include a user-selectable link for calling the restaurant (e.g., application function146-8).

The edges530may indicate transitions that a server (e.g., server400inFIG. 4) determines. The edges530may indicate transitions that are not explicitly specified (e.g., programmed) by a developer. For example, the application function146-1may not include a developer-programmed user-selectable link for the application function146-2. The server may determine that a user of a client computing device may use the application function146-2subsequent to using the application function146-1. For example, the server may determine that a user viewing a restaurant review on the YELP® application can go to the restaurant using the UBER® application. Hence, the server may identify a transition between the restaurant review function (e.g., application function146-1) and the request UberX® function (e.g., application function146-2) of the UBER® application.

As illustrated inFIG. 5, the server can connect application functions from different applications even though the developer of the application functions may not have explicitly connected the application functions via user-selectable links. For example, the server can connect the application function146-1to the application function146-2even though a developer of the application function146-1may not have programmed a user-selectable link for the application function146-2. In the example ofFIG. 5, the server may connect the ‘request UberX’ function to the ‘restaurant review function’ of the YELP® application even though the YELP® application does not include a user-selectable link for requesting an UberX®.

An application function may include different application states. Different application states of an application function may have different function parameters. For example, the application function146-2may have an origin address parameter (e.g., ‘From’ address) and a destination address parameter (e.g., ‘To’ address). Different values of the origin address parameter and the destination address parameter may yield different application states of the application function146-2. The application function graph500may be stored as an application state graph. In an application state graph, the graph nodes510may represent application states, and the edges520and530may represent transitions between the application states. The application function graph500may be stored using any suitable data structure (e.g., a look-up table (LUT), an array, a multi-dimensional array, or the like).

FIG. 6illustrates an example user intent graph600. The user intent graph600includes graph nodes610that store user intent IDs that refer to user intents148-1,148-2. . .148-5. The user intent graph600includes edges620that connect the graph nodes610. Each user intent ID may be associated with an application function ID. The application function ID associated with a user intent ID may help achieve the referenced user intent when the corresponding application function is executed at a client computing device. For example, the restaurant review function (e.g., application function146-1) helps a user learn about a restaurant (e.g., user intent148-1). Similarly, the request UberX® function (e.g., application function146-2) helps a user go to the restaurant (e.g., user intent148-2).

The edges620may be directed edges. A direction of an edge620may indicate a prediction of a subsequent user intent ID. For example, an edge620directed from the user intent148-4to the user intent148-1may indicate that when a current user intent ID matches (e.g., equals) a user intent ID of the user intent148-4then a subsequent user intent ID may be a user intent ID of the user intent148-1. Similarly, when a current user intent ID refers to ‘messaging about a restaurant’ (e.g., user intent148-4), then a subsequent user intent ID may refer to ‘learning about the restaurant’ (e.g., user intent148-1). In response to the server determining the user intent148-1as the subsequent user intent, the client computing device may display an application card for an application function associated with the user intent148-1. For example, the client computing device may display an application card50-1for the application function146-1in conjunction with an application view46-4for the application function146-4(e.g., as illustrated inFIG. 3A).

A current user intent ID may lead (e.g., refer) to several potential subsequent user intent IDs. For example, the user intent148-4may lead to one of the user intents148-1,148-2,148-3and148-5. The edges620may be weighted edges that indicate the probability of a current user intent leading to a subsequent user intent. Table 1 illustrates the probabilities of the user intent148-4transitioning into the user intents148-1,148-2,148-3and148-5.

TABLE 1Probabilities of Subsequent User IntentsCurrent User intentSubsequent user intentProbability148-4148-10.6148-20.1148-30.1148-50.2

The server may determine the probabilities based on application usage data from other client computing devices. For example, the server may monitor user-initiated transitions between different application functions in order to determine the probabilities. The probability of the user intent148-1may be 0.6, for example, because 60% of users may have manually navigated to an application view of the application function146-1immediately after (e.g., within a threshold time, for example, 5 seconds) viewing an application view of the application function148-4. Referring toFIG. 1, the server100may determine the probabilities based on the application usage history170of the client computing device140. For example, the probability of the user intent148-5may be 0.2 because the user of the client computing device140may have used the application function146-5immediately after (e.g., within a threshold time, for example, 5 seconds) using the application function146-4on 20% of occasions.

Some edges620may specify a sensor measurement trigger650. For example, the edge from the user intent148-3to the user intent148-2may specify an accelerometer measurement that corresponds with the user of the client computing device walking. In the example ofFIG. 6, a user of the client computing device may be reserving a table at the restaurant via a reserve table function (e.g., application function146-3). The user may also be walking towards the restaurant (e.g., as indicated by the accelerometer measurement and GPS location). The client computing device may display an application card for the request UberX function, so that the user can get a ride to the restaurant. The application card for the request UberX function may be similar to the application card50-2for the application function146-2illustrated inFIG. 1.

FIG. 7illustrates a method700for determining (e.g., selecting) an application card for an application function that can be displayed at a client computing device in conjunction with an application view for another application function. At702, a server receives contextual data from a client computing device. The contextual data may indicate a current application view displayed at the client computing device. The contextual data may indicate sensor measurements. The contextual data may include an application usage history.

At704, the server determines a current application function ID that identifies a current application function corresponding with the current application view based on the contextual data. The server may determine the current application function ID by comparing the contextual data with application function IDs stored in a data store (e.g., the application function data store408illustrated inFIGS. 4 and 5).

At706, the server determines (e.g., estimates) a current user intent ID associated with the current application function ID. The server may access an application function data store (e.g., the application function data store408illustrated inFIGS. 4 and 5) and retrieve the current user intent ID from the application function data store. The current user intent ID may refer to a current intent of a user of the client computing device.

At708, the server determines (e.g., predicts) a subsequent user intent ID that transitions from the current user intent ID. The server may access a user intent data store (e.g., the user intent data store illustrated inFIGS. 4 and 6) and retrieve the subsequent user intent ID from the user intent data store. If multiple user intent IDs transition from the current user intent ID, the server may select the user intent ID with the highest confidence value as the subsequent user intent ID. Referring toFIG. 6, if the current user intent ID refers to the user intent148-4, the server may select the user intent ID for the user intent148-1as the subsequent user intent ID. The server may determine the subsequent user intent ID based on sensor measurements. For example, referring toFIG. 6, if the current user intent ID refers to the user intent148-3and an accelerometer measurement indicates that the user of the client computing device is walking, the server may select the user intent ID of the user intent148-2as the subsequent user intent ID. The server may determine the subsequent user intent ID based on function parameter values in the current application view. For example, referring toFIG. 6, if the current user intent ID refers to the user intent148-2and a destination address parameter includes a restaurant address, the server may select the user intent ID of the user intent148-3as the subsequent user intent ID.

At710, the server identifies an application function ID that corresponds with the subsequent user intent ID. The server may use the application function data store408and/or the user intent data store410to identify the application function ID that corresponds with the subsequent user intent ID. For example, the server may perform an application function search in the application function data store408for an application function ID that is suitable for the subsequent user intent ID. Additionally or alternatively, the server may use the user intent graph600to identify the application function ID that corresponds with the subsequent user intent ID. For example, the server may select an application function ID associated with the subsequent user intent ID from the user intent graph600. The application function ID corresponding with the subsequent user intent ID may be referred to as a predicted application function ID.

At712, the server retrieves a card object corresponding with the predicted application function ID. For example, referring toFIG. 4, the server may retrieve the card object180from the application card data store412. At714, the server transmits the card object to the client computing device.

FIG. 8illustrates an example client computing device840. The client computing device840illustrates an example implementation of the client computing device140shown inFIG. 1. The client computing device840may include sensors842, a memory844(e.g., memory hardware), a touchscreen display854, and a computing processor860(e.g., data processing hardware).

The memory844may store application functions846. The application functions846may be similar to the application functions146shown inFIG. 1. The memory844may store a contextual data store850and a layout data store852. The contextual data store850may store contextual data (e.g., contextual data160shown inFIG. 1). The layout data store852may store layouts that can be used to display application cards (e.g., application cards50shown inFIG. 1). The layouts may be stored as layout files. The layouts may be referred to as application card templates that include GUI elements that correspond with function parameters for an application function846.

The computing processor860may include an on-die sensor842′, a sensor hub862, a transceiver864, display circuitry866, and a central processing unit (CPU)868. References to the sensors842may include the on-die sensor842′. The sensors842may include a location sensor, for example, Global Positioning System (GPS) and/or Global Navigation Satellite System (GLONASS). The sensors842may include an accelerometer, a magnetometer, gyroscope, or the like.

The sensor hub862may manage the sensors842. The sensor hub862may receive sensor measurements from the sensors842. The sensor hub862may determine when to turn on, or turn off the sensors842. The sensor hub862may turn on a sensor842and command the sensor842to record a sensor measurement. The sensor hub862may turn off the sensor842, for example, to conserve power. The sensor hub862may receive sensor data periodically (e.g., once every hour, once every minute, or the like). The sensor hub862may capture sensor data in response to receiving a request (e.g., from a server via the transceiver864).

The transceiver864enables electronic communication with a network (e.g., network190shown inFIG. 1). The transceiver864may include a cellular transceiver, for example, a LTE transceiver, a LTE-Advanced transceiver, or a 5G (5thgeneration mobile network) transceiver. The transceiver864may include a Wi-Fi transceiver. The transceiver864may include a ZigBee transceiver, a Bluetooth transceiver (e.g., Bluetooth Low Energy transceiver), a NFC transceiver, or the like. The transceiver864may communicate with the network via wired communications. For example, the transceiver864may communicate with the network via an Ethernet cable, a fiber-optic cable, a USB cable, or the like.

The CPU868may include an ARM processor based on a reduced instruction set computing (RISC) architecture. The CPU868may include multiple cores (e.g., dual-core, quad-core, or octa-core). The CPU868may execute computer-readable instructions stored in the memory844. When the CPU868executes computer-readable instructions, the CPU868may implement a contextual data logger870and an application card renderer872. The CPU868may execute the application functions846-1and846-2. The application functions may be similar to the application functions146-1and146-2shown inFIG. 1.

The contextual data logger870may include an application that operates on the application layer. Additionally or alternatively, the contextual data logger870may include an operating system process that operates on the presentation layer. The contextual data logger870may log contextual data (e.g., contextual data160shown inFIG. 1). The contextual data logger870may store the contextual data in the contextual data store850. The contextual data logger870may receive sensor measurements from the sensor hub862and store the sensor measurements in the contextual data store850. The contextual data logger870may log information being displayed on the touchscreen display854. For example, the contextual data logger870may log information that indicates a current application function ID (e.g., an on-screen application function ID, for example, the application function ID166shown inFIG. 1).

The contextual data logger870may log function parameters from the current application function. For example, the contextual data logger870may log a restaurant name from a restaurant name parameter of a restaurant review function. Similarly, the contextual data logger870may log a destination address from a destination address field of a request ride function. The contextual data logger870may log an application usage history by logging application functions (e.g., all application functions) used at the client computing device840.

The contextual data logger870may transmit (e.g., send) the contextual data to a server via the transceiver864. The contextual data logger870may transmit the contextual data periodically, for example, once every minute, once every day, or once every month. The contextual data logger870may transmit the contextual data upon receiving a request from an application, a user of the client computing device840and/or a server.

The application card renderer872receives a card object (e.g., the card object180shown inFIG. 1) via the transceiver864. The card object indicates a subsequent application function that a user of the client computing device840may want to use based on the contextual data. The application card renderer872renders (e.g., displays) an application card (e.g., application card50shown inFIG. 1) on the touchscreen display854based on information included in the card object. The card object may indicate a layout for the application card. For example, the card object may indicate the GUI elements to display on the application card. The application card renderer872uses the layout indicated by the card object to display the application card.

The card object may include function parameter values. The application card renderer872may populate the GUI elements of the application card, so that the GUI elements display the function parameter values included in the card object. Additionally or alternatively, the application card renderer872may determine the function parameters values for the GUI elements in the application card based on the contextual data logged by the contextual data logger870. For example, the application card renderer872may use a restaurant name specified in a message of a messaging application to populate a restaurant name parameter of a restaurant review function. Similarly, the application card renderer872may use a restaurant address specified in a restaurant review function to populate a destination address of a ride requesting function. The application card renderer872may retrieve the contextual data from the contextual data store850and/or the application card872may receive the contextual data from the contextual data logger870.

The card object may include a layout identifier that identifies an application card layout stored in the layout data store852. The application card renderer872may retrieve the application card layout from layout data store852. The application card renderer872may use the retrieved application card layout to display the application card.

The application card renderer872may display the application card so that the application card hovers over a current application view. The application card renderer872may control a transparency level of the application card so that the application card does not conceal the current application view. The application card renderer872may reduce a size of the current application view to a threshold percentage of the display area on the touchscreen display854. For example, the application card renderer872may reduce the size of the current application view to 75% of the display area. The application card rendered872may use the remainder of the display area to display the application card. For example, the application card renderer872may use the remaining 25% of the display area to display the application card.

The application card renderer872may execute computer-readable instructions included in the card object to display the application card. The application card renderer872may execute computer-readable instructions included in the card object to perform an application function corresponding with the application card. The application card renderer872may execute the application function corresponding with the application card as a background operation. For example, referring toFIG. 1, the client computing device140may execute the application function146-2in the background while the application card50-2is displayed.

FIG. 9illustrates a method900for displaying an application card representative of a subsequent application function ID. At902, a client computing device displays a current application view of a current application function on a display of the client computing device. For example, referring toFIG. 1, the client computing device140may display the application view46-1representing the application function146-1.

At904, the client computing device logs contextual data (e.g., contextual data160shown inFIG. 1). The client computing device may store the contextual data in a data store (e.g., contextual data store850). The contextual data may include information indicating the current application function ID, sensor measurements, and/or application usage history.

At906, the client computing device transmits the contextual data to a server. The client computing device may retrieve the contextual data from the contextual data store and transmit the retrieved data to the server. The client computing device may be storing the contextual data at a higher frequency than transmitting the contextual data to the server, for example, to conserve battery power. For example, referring toFIG. 1, the client computing device140may transmit the contextual data160to the server100.

At908, the client computing device receives a card object that corresponds with an application function ID for a subsequent application function. For example, referring toFIG. 1, the client computing device140may receive the card object180from the server100. The card object may include executable instructions that the client computing device can execute to display the application card and perform the corresponding application function.

At910, the client computing device determines a rendering for the application card. For example, the client computing device may execute computer-readable instructions included in the application card to display the application card. Alternatively, the client computing device may retrieve an application card layout indicated by the card object and use the application card layout to display the application card in conjunction with the current application view.

At912, the client computing device displays the application card of the predicted application function concurrently with the application view of the current application function. The application card may include GUI elements, so that the predicted application function can be used without switching applications and manually navigating to the application view of the predicted application function. Referring toFIG. 1, the application card50-2is an example of the application card and the application function146-2is an example of the predicted application function.

FIG. 10is a block diagram of an example computing devices1000that may be used to implement the systems and methods described in this document. For example the computing device1000may be used to implement the server100and/or the client computing device140shown inFIG. 1. The computing device1000is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document.

The computing device1000includes a processor1002, memory1004, a storage device1006, a high-speed interface1008connecting to memory1004and high-speed expansion ports1010, and a low speed interface1012connecting to low speed bus1014and storage device1006. Each of the components1002,1004,1006,1008,1010, and1012, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor1002can process instructions for execution within the computing device1000, including instructions stored in the memory1004or on the storage device1006to display graphical information for a graphical user interface (GUI) on an external input/output device, such as display1016coupled to high speed interface1008. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices1000may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

The memory1004stores information within the computing device1000. In one implementation, the memory1004is a computer-readable medium. In one implementation, the memory1004is a volatile memory unit or units. In another implementation, the memory1004is a non-volatile memory unit or units.

The storage device1006is capable of providing mass storage for the computing device1000. In some implementations, the storage device1006is a computer-readable medium. In various different implementations, the storage device1006may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory1004, the storage device1006, or memory on processor1002.

The high speed controller1008manages bandwidth-intensive operations for the computing device1000, while the low speed controller1012manages lower bandwidth-intensive operations. Such allocation of duties is exemplary only. In some implementations, the high-speed controller1008is coupled to memory1004, display1016(e.g., through a graphics processor or accelerator), and to high-speed expansion ports1010, which may accept various expansion cards (not shown). In the implementation, low-speed controller1012is coupled to storage device1006and low-speed expansion port1014. The low-speed expansion port, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device, such as a switch or router, e.g., through a network adapter.

The computing device1000may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server1020, or multiple times in a group of such servers. It may also be implemented as part of a rack server system1024. In addition, it may be implemented in a personal computer, such as a laptop computer1022. Alternatively, components from computing device1000may be combined with other components in a mobile device (not shown). Each of such devices may contain one or more of computing device1000, and an entire system may be made up of multiple computing devices1000communicating with each other.