Patent Application
20160224397
This disclosure relates generally to data processing systems, and more specifically to software control and execution for data processing systems.
Computer systems include generally a central processing unit (CPU), a memory that stores software and data, and a set of input/output peripheral devices. The software includes both application programs and an operating system. The operating system establishes a human interface for the selection and execution of programs, and allows application programs to interface with computer hardware. The operating systems of mobile communication devices, commonly referred to as “smartphones”, “tablets”, and desktop computers are different in that the mobile operating system is especially adapted for the mobile environment. For example, mobile operating systems place special emphasis on saving power to preserve battery life while providing fast launch times for mobile applications. Thus there is an ongoing need to balance fast launching of mobile applications with the need conserve power in a way that improves the user's experience.
In the following description, the use of the same reference numerals in different drawings indicates similar or identical items. Unless otherwise noted, the word “coupled” and its associated verb forms include both direct connection and indirect connection by means known in the art, and unless otherwise noted any description of direct connection implies alternate embodiments using suitable forms of indirect connection as well.
In one form, a data processing system includes a memory, a central processing unit, at least one peripheral device, and a context-based execution controller. The memory stores an operating system and a plurality of software applications. The central processing unit is coupled to the memory and executes a selected software application of the plurality of software applications as directed by the operating system. The at least one peripheral device includes a real-time clock for defining execution contexts for the plurality of software applications. The context-based execution controller is coupled to the memory and to the at least one peripheral device and takes at least one speculative action with respect to launching the selected software application in response to an execution context indicated by the at least one peripheral device.
In another form, a context-based execution controller for managing an application program execution environment for a mobile communication device or the like includes a usage pattern analyzer and a usage history table. The usage pattern analyzer is coupled to the usage history table and is responsive to a plurality of inputs including a real time signal and an application launch signal to form an execution context for each of a plurality of software applications based on the real time signal and the application launch signal. The usage pattern analyzer also stores the execution context in the usage history table, and the usage pattern analyzer further uses the real time signal to output an action request with respect to one of the plurality of software applications that is inactive.
In yet another form, a method includes receiving at least one execution context signal. An application launch signal is also received. History information is formed based on a plurality of inputs including the at least one execution context signal and the application launch signal. The history information is stored in a usage history table. The usage history table is accessed in response to the at least one execution context signal. An action request associated with a software application is provided based on the usage history table.
Mobile communication device 110 is a hand-held device commonly referred to as a “smartphone” that not only provides voice communication over the cellular telephone network but also stores and executes a variety of application programs or “mobile apps” that offer a variety of useful functions such as EMAIL, calendar, internet browser, electronic book reader, games, and the like. To implement these mobile apps, mobile communication device 110 itself includes a data processing system complete with a central processing unit, memory for storing a mobile operating system and mobile apps, and input/output peripheral devices.
The execution environment of mobile communication device 110 creates the need to launch and execute mobile apps quickly while preserving battery life. The inventors have discovered that these environmental factors correlate with a user's propensity to launch certain mobile apps or to use certain data within the mobile apps. In order to enhance the user's experience, mobile communication device 110 operates to speculatively launch mobile apps and load data related to such mobile apps based on the execution context. As used herein, “execution context” includes a set of one or more environmental factors. For example, environmental factors can include such things as time of day or week, location, proximity to other mobile users, recent selection of other mobile apps, and the like.
When the mobile operating system has completed initialization, it creates a graphical user interface (GUI) to allow the user to interact with it. In most smartphones, the GUI provides icons corresponding to mobile apps underneath a touch screen such that the user can select an app by pressing a finger on an overlying position on the touch screen. The mobile operating system loops on a decision box 230 in which it waits for a user input to launch a mobile application.
When the user selects a mobile app to launch, the mobile operating system launches the application in a series of actions 240. In an action box 242, the mobile operating system creates an entry in a process table and allocates a virtual memory space. In an action box 244, the mobile operating system reads the executable instructions from a non-volatile (“FLASH”) memory and loads the instructions into a volatile memory that can be accessed significantly faster than the FLASH memory. In an action box 246, the mobile operating system creates an entry in a scheduler and loads a central processing unit's program counter with an entry point of a process associated with the mobile app. It should be apparent that actions 240 are merely exemplary and represent only the more significant steps in launching an application.
Flow continues to a series of actions 250 associated with running the mobile app. In an action box 252, the central processing unit starts running the application code by fetching the first instruction using the process table. Flow continues to action box 254, in which the mobile app executes application-specific startup tasks, including for example setting up tables in volatile memory, loading information about user preferences from non-volatile memory, setting up application-specific GUIs, and the like. Finally at action box 256, the application becomes available to the user.
Execution of the mobile app continues until the operating system detects an end to or switch of the application in decision box 260. For example, the user (or operating system) may close the application, or in the context of a multiple-application execution environment, switch the current application into the background and another application into the foreground.
It should be apparent from flow diagram 200 that there are many actions taken by the mobile operating system and the mobile app itself before the app is available to the user for its intended function. A reduction in the amount of time required before the application is available to the user when the user wants it would greatly enhance the user's subjective experience.
In particular, the inventors have discovered that by storing information over time about the context that existed for previous launches of a mobile app, the mobile operating system can partially hide the overhead from the user and make the application available to the user in anticipation of the user's desire to launch it. The inventors have observed that the context of the application establishes a likelihood of the user launching the application, especially in mobile communication devices. For example, the user may check EMAIL regularly at a certain time of day. The user may also launch a radio player application on entering a sports arena or stadium. Moreover the user may make certain predictable choices to the application. Thus both real time and geographical location may indicate the mobile app a user is likely to want or need, and enhance the user's experience by pre-launching the app predicted by the context.
CPU 310 is a central processing unit that is adapted to execute stored program instructions while consuming only a small amount of power. The architecture of CPU 310 may vary from embodiment to embodiment. For example, CPU 310 can be a low power CPU designed and licensed by Advanced RISC Machines, Ltd.
RAM 330 includes memory that can be accessed by CPU 310 at high speed. A mobile operating system typically uses portions of RAM 330 to set up various data structures, such as a portion 332 for storing a process table, and a portion 334 for storing a scheduler. In addition, the operating system loads particular mobile apps, or portions thereof, into an application code portion 336 of RAM 330 so they can be executed at relatively high speed.
FLASH memory 340 is formed of inexpensive floating-gate memory, and includes several portions of interest including a portion 342 for storing the mobile operating system itself and another portion 344 for storing mobile apps including a portion 345 for storing a representative first app labeled “APP #1” and a portion 346 for storing a representative Nth app labeled “APP #N”, and a portion 348 for storing other user data.
Peripheral devices 350 include a real-time clock (RTC) 352, a modem and transceiver 354, a global positioning system (GPS) receiver 356, and an I/O peripheral interface 358. Real time clock 352 has an output for providing a signal indicative of real time that CPU 310 can correlate to time of the day, day of the week and year, etc. Modem and transceiver 354 provides various communication links, such as a cellular telephone system, a high-speed limited distance network known as “WiFi”, a short distance communication link known as near-field communication, and the like. GPS receiver 356 receives triangulation data from GPS satellites that allows the CPU to determine terrestrial location coordinates. I/O peripheral interface 358 provides a bridge to relatively low-speed peripherals, such as a virtual keyboard 362 from which CPU 310 receives user input and a display 364 which CPU 310 uses to output the GUI. As should be apparent, peripheral devices 350 are merely illustrative of the type of peripherals present in a typical mobile communication device.
In addition, FLASH memory 340 includes a portion 343 for storing a context based application controller. The context based application controller is connected to peripheral devices 350 over system bus 320 and is adapted to create and store history information associated with an execution context for each of the plurality of software applications. For example the context could be a combination of the time of day and a geographical location in which the mobile app is frequently launched. The context based application controller uses the history information to direct the mobile operating system to take at least one speculative action, such as pre-launching the mobile app or pre-loading certain data.
Usage history table 420 is a table of entries created and maintained by usage pattern analyzer 410 in RAM 330 or FLASH memory 340. Each entry has an application indicator and context data corresponding to and associated with the software application. The application indicator indicates, directly or indirectly, a particular mobile application. In the example shown in
Peripherals 430 include a real time clock 432, a GPS receiver 434, and a user interface 436 corresponding to like elements in
Process table 440 is located in a portion of RAM corresponding to portion 332 in
In operation, usage pattern analyzer 410 periodically receives or reads the context information and predicts applications that have a high probability of being launched by the user in the current context. Usage pattern analyzer 410 does this, for example, by performing an associative search of the context field of usage history table 420 to look for one or more apps that are correlated to the current context.
In some embodiments, usage pattern analyzer 410 can determine the context from various sets of variables. For example, usage pattern analyzer 410 can evaluate the context based on global application execution characteristics. These global application characteristics include, for example, the most commonly used application (EMAIL or a social media application or a web browser) and its probability of selection, based on a sorted list of applications the time spent or number of initializations, and the times of execution of different applications.
Alternatively, the context can be based on single application level characteristics, such as the most commonly pressed button in an application, and the probabilities of the various options of buttons that can be pressed or actions that can be made or selected within the application.
The context can also be established based on a multi-application execution characteristic. In other words, the execution of one application may establish a likelihood of launching another application. These factors include the probabilities of execution of a different application once another specified application has been executed, i.e. conditional probabilities of execution, and the length of time the user waits or takes before the next application is expired.
Usage pattern analyzer 410 continues to track such context-based metrics and maintains and refines this information in usage history table 420 over time. It can also transmit this information to a central entity such as remote server 130 for collection and analysis over much larger set of users.
Usage pattern analyzer 410 leverages execution context information in a variety of ways by directing the operating system to take a variety of speculative actions. For example, the execution context can be used to choose particular applications to pro-actively load and place the application code in RAM. Certain applications can be loaded into RAM based on historic execution information before the user actually provides an input to launch the application. For example, a social media application can be loaded into memory at noon every day because the user frequently loads the social media application at her lunch hour. Thus the pre-loading can reduce the latency perceived by the user. Usage pattern analyzer 410 can also direct the mobile operating system to allocate shared resources such as memory to various applications based on their usage histories.
Another action includes speculative instruction stream warm-ups, e.g. loading relevant handler code into memory and executing the handler code up to until a certain point. This action may require the developer to specify a programming model to support the partial execution. Speculative instruction stream warm-ups reduce latency. Usage pattern analyzer 410 could base the decision to warm up based on a context established by other user inputs such as scroll downs, scroll ups, side swipes etc. For example, the first action taken by the user in a social media application is typically a scroll down.
Since the number of instruction streams that can possibly be executed are limited (e.g. when inside a mobile app), probabilistic execution/loading/warm-up can be performed over multiple choices. Essentially the run-time system performs run-ahead execution expecting a user input in the future (decided based on past history) and this can be performed over multiple instruction streams. For example, the two or three most likely instruction streams can be speculatively executed. Conditional probabilities of execution can be used to manage memory e.g. load a different application to memory after a certain application is executed because the user did so as shown by historic data. It is also possible to use usage histories to load balance the system when multiple applications are executing. One example of this factor is to give more priority to the application the user executes more often based on historic data.
Another action is the pre-loading of data based on execution context. For example, the execution context may indicate that a user will launch a web browser and check a favorite news site at a certain time of the day. In this example the speculative action would include loading data indicating the URL of the website and directing the web browser to go to the website in addition to loading the program.
Yet another action is the allocation of memory space based on context. For example when available free space drops below a limit, the context-based execution controller can provide the user usage information to help make decisions on which applications to remove.
Note that while the context-based execution controller is particularly useful in mobile systems because the execution choices are relatively limited, it can also be used in desktop systems. For example on a regular work day, the diversity of the applications and their usage patterns may still be predictable, and most of the applications such as email clients, tele-conference applications, and the like are routinely used. In these desktop systems, the history of program usage is particularly useful context information to allow the context-based execution controller to make predictions about the time to execute a program proactively.
In these systems in addition to history data, other relevant context information can be used to take proactive actions. For example certain EMAIL programs include an integrated calendar application, and the calendar application includes context-based hints about programs that are likely to be used. For example, a scheduled appointment in the electronic calendar requires the use of a virtual meeting program, and this program can be speculatively launched as the meeting time approaches.
Another action in the desktop system environment is speculative boot-up of the workstation based on the location of the user. For example the system can determine the user's location from a GPS receiver, a cellular network, a radio frequency identification (RFID) signal, or a near-field communication signal from a mobile communication device carried by the user. This action allows the user's workstation to be ready when he or she arrives at his or her desk, but requires the communication peripheral to remain active.
Note that in case of a misprediction, the context-based execution controller terminates the speculatively executed application and adjusts the history table to improve the rate of successful predictions. This self-learning mechanism ensures that the changes in user behavior are taken into account to continuously improve the success of the prediction mechanism.
In another embodiment, in addition to automatic learning of application execution context, the user can pre-specify future application execution behavior. In yet another embodiment, software vendors can characterize user behavior and pre-bias the usage pattern analyzer based on the characterization. The characterization may consists of data that indicates which applications are suitable for prediction and which are not. For example an EMAIL application is a good candidate whereas a screen-saver or game is not. This information can be provided by the application vendor and used by the usage pattern analyzer to make predictions. The operating system may support this feature by defining a protocol for applications to request this behavior and the operating system to grant it. The protocol may specify software application program interfaces (APIs), libraries, and other interface protocols to allow the application to request this behavior, specify what portions will be pre-executed, specify pre-execution end points, specify how authentication is handled, etc.
In one particular example of the operation of the context-based execution controller, a user is travelling. The user has taken this trip before and takes a mobile device with her. However the user's route takes her through areas that have no wireless service. In this example, the user's mobile device detects that the travel is beginning, predicts the destination, and can therefore predict the gap in wireless service.
The usage pattern analyzer can detect this condition based on the purchase of a train ticket, GPS location information, WiFi or cellular properties such as changing signal strength, historical travel data such as a history of weekly visits, or other similar means. Moreover multiple methods can be used and cross-correlated to form a stronger inference. Based on this detected travel pattern, the user's mobile device can deduce the destination and prefetch relevant information for the user while still within the wireless service area. Relevant pre-fetch data can include, for example, web pages of interest to the user, news and information about the route of travel, origin, destination, maps, chapters of books that the user is reading or friends have recommended, topical news of interest, tourist information, and so on. The mobile device may also collect personal information of the user's recent history such as photos from a prior social engagement or a movie that the user has marked for watching. The mobile device can remind the user of gifts associated with the people at the location based on previous purchase histories and suggest for a store located near the route of travel.
This information can be cached on the user's mobile device and presented through conventional means (e.g., as cached web pages or notifications) while outside any wireless service area or prior to entering a roaming area with increased access charges. Access to this information could be altered for security or commercial purposes based on location.
Some of the functions of context-based execution controller 400 may be implemented with various combinations of hardware and software. For example, usage pattern analyzer 410 may be implemented as a component of the mobile operating system, as an application program, or in hardware. If implemented in software, some or all of the software components may be stored in a non-transitory computer readable storage medium for execution by at least one processor. In various embodiments, the non-transitory computer readable storage medium includes a magnetic or optical disk storage device, solid-state storage devices such as FLASH memory, or other non-volatile memory device or devices. The computer readable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted and/or executable by one or more processors.
The circuits of
While particular embodiments have been described, various modifications to these embodiments will be apparent to those skilled in the art. For example, the context-based execution controller can use various inputs to define the execution context, including but not limited to real time, geographic location, the launching of related mobile apps, etc. In addition, the prediction can use fixed logic criteria or fuzzy logic. Moreover while the embodiments have described taking certain actions such as speculative loading of a program, speculative loading of data, allocation of memory space, many other speculative actions may be taken as well.
Accordingly, it is intended by the appended claims to cover all modifications of the disclosed embodiments that fall within the scope of the disclosed embodiments.
