Abstract:
A method and apparatus to provide a scheduler comprising receiving motion information from a mobile device, determining a current use characteristic for the mobile device based on the motion information, and scheduling a task based on the current use characteristic.

Description:
FIELD OF THE INVENTION 
     The present invention relates to preemptive operating systems, and more particularly to scheduling in preemptive operating systems. 
     BACKGROUND 
     Mobile devices are gaining increasing functionality and importance in our daily lives. Accelerometers may be incorporated in these devices for measuring the motion that the device experiences. More and more of these mobile devices have multi-tasking preemptive operating systems that allow the device to run several programs or applications at once. These preemptive operating systems have schedulers to prioritize tasks. In prior implementations, these schedulers based their decision on the priority of each application or function, and occasionally on the time of day. 
     SUMMARY OF THE INVENTION 
     A method and apparatus to provide a scheduler comprising receiving motion information from a mobile device, determining a current use characteristic for the mobile device based on the motion information, and scheduling a task based on the current use characteristic. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: 
         FIG. 1  is a network diagram illustrating a network in which the present system may work. 
         FIG. 2  is a block diagram of one embodiment of the scheduler. 
         FIG. 3  is a flowchart of one embodiment of scheduling. 
         FIGS. 4A and 4B  is a flowchart of one embodiment of setting scheduling preferences. 
         FIG. 5  is a list of exemplary tasks and the associated resources used. 
     
    
    
     DETAILED DESCRIPTION 
     The method and apparatus described is for providing a preemptive operating system which schedules tasks in a mobile device. Prior art schedulers have had no awareness as to the motion that the device is experiencing and in particular what the user&#39;s motion implies about the state of the device and the likelihood of the user to perform certain actions with the device. In prior art, these schedulers know only of the current state of various programs and whether the device has the screen turned on or off but have no awareness of the motion that a device is experiencing. 
     The scheduler of the present invention in one embodiment optimizes these preemptive operating environments using motion information. The scheduler optimizes tasks, programs, and data communications based upon the device&#39;s use characteristic, determined based on the motion information. Data communications may include pulling data from and pushing data to the network. 
     While the scheduler improves the performance of all programs on a mobile device, some programs require especially low latency in their execution in order to operate accurately. In particular, programs that receive and process the input from integrated or wirelessly tethered sensors degrade rapidly in performance and accuracy as latency increases. Many of these sensor programs analyze data in real time, sampling a sensor from 1 to 300+Hz. In a preemptive operating system where the host processor interfaces directly with a given sensor, a higher priority task such as a phone call or data transfer will preempt the lower priority task of real time data analysis. If system bandwidth is limited, the lower priority task may be halted entirely, significantly degrading the program&#39;s performance. 
       FIG. 1  is a network diagram illustrating a network in which the present system may work. The system includes a mobile device  110 . The mobile device  110 , in one embodiment, receives data from one or more sensors  120 ,  170 . The sensors  120 ,  170  may be coupled to the mobile device  110  via a wireless connection  120  such as 802.11 WiFi, Bluetooth, etc or may be integrated in the mobile device  170 . The integrated sensors  170 , in one embodiment include an inertial sensor. The mobile device  110  can also retrieve data from a server  130  via network  140 , or send data to a server  130  via network  140 . The network may be the Internet, a cellular telephone network, or any other network. The mobile device  110  may be getting data from the network via various protocols including Wireless Access Protocol (WAP), HTTP, or other protocols. 
     The mobile device  110  may also obtain data from other another mobile device  150  either through a direct connection or through network. The scheduler  160  in mobile device  110  determines when the various tasks and communications occur. This may include obtaining data from, and sending data to, servers  130 , sensors  120 , and other mobile devices  150 , as well as internal processes such as programs and tasks. 
       FIG. 2  is a block diagram of one embodiment of the scheduler. The scheduler  160  in one embodiment is a software application which runs on a mobile device. In another embodiment, the scheduler  160  may have a client and a server component. The functionality may be split between the client and the server. In one embodiment, the preference settings, and calculations may be on the server which has more processing power and storage available, while the implementation/use aspects reside on the client. For simplicity, the below description refers to any schedulable task, program, or data communication as a “task.” 
     Scheduler  160  includes a resource identification list  210 , which includes a listing of one or more potential tasks and the resource(s) that the task uses. For example, a download task utilizes network bandwidth, storage bandwidth (memory bus), and storage. By contrast, a telephone call task only uses network bandwidth.  FIG. 5  lists a number of exemplary tasks and their associated resources. 
     Prioritizer  220  includes a list of tasks and their relative priorities. For example, a task which is observed by the user is a higher priority than a task which is generally not observed by the user. A task which provides semi-real-time feedback or other data processing is higher priority than a task which provides background download, synchronization, or similar features. In one embodiment, user may use a user interface  225  to prioritize tasks. In one embodiment, the system comes with a default set of priorities, which may be edited or adjusted by the user. 
     Motion information logic  230  receives motion data. In one embodiment, motion data is received from an accelerometer or other inertial sensor. In one embodiment, motion data is received from a 3-dimensional accelerometer that is part of the device. Motion logic  230  determines a current motion, and based on an identified activity of the user, determines expected future motion as well. For example, if the user is walking at a rapid cadence, it is likely that he or she will continue to walk. If the user is playing a game, he or she is likely to continue moving the device and playing the game. 
     In one embodiment, the system further includes an active application detector  240 . In one embodiment, active application detector detects when an application is active (i.e. being used), even if there is no associated motion. For example, the user may open an application such as a web download application while keeping the mobile device stationary. 
     Current task scheduler  250  prioritizes current tasks based on prioritizer  220  data and resource ID  210  data. The current tasks are determined by current task scheduler  250  based on active app. detector  240  and motion logic  230 . 
     If the current task scheduler  250  determines that two applications conflict, it can in one embodiment, send a stop message to application stop logic  270 . In one embodiment, current task scheduler  250  also then sends the stopped task to future task scheduler  260 . In one embodiment, current task scheduler  250  may also utilize resource restrictor  280  to reduce available resources for lower priority tasks. In one embodiment, current task scheduler  250  uses prioritizer data to determine which application(s) to throttle. 
     Resource restrictor  280  may be used to reduce the available resources to one or more of the currently active applications. This may include reducing available bandwidth. 
     Future task scheduler  260  receives future tasks for scheduling. In one embodiment, these future tasks may be received from current task scheduler  250 . In one embodiment, future tasks may be received from the user. The user may, in one embodiment, add tasks to a list of “future tasks” which should be performed when there are resources available. For example, for a larger download or upload project, the user may indicate that the project is a “future task” instead of directly initializing the task. 
     Future task scheduler  260  passes a task to current task scheduler  250  when the motion info logic  230  and active application detector  240  indicate that the time is good for performing that task. For example, when the device is not in motion, and there are no applications using network bandwidth, a upload or download future task may be scheduled. In one embodiment, future task scheduler  260  passes tasks for data calls to the server for uploads, downloads, and synchronization to the current task scheduler  250  when the device is idle. In one embodiment, the device is idle when no motion is detected. In one embodiment, the device is idle when no motion is detected and the user is not interacting with any application. 
     In one embodiment, the system may have tasks that are interruptible (such as downloads) and tasks that are not interruptible (such as installation of applications). In one embodiment, future task scheduler  260  may also have as an input a clock. In one embodiment, the future task scheduler may take into account the likelihood of a user initiating a conflicting task, prior to passing a non-interruptible task to the current task scheduler  250 . 
       FIG. 3  is a flowchart of one embodiment of scheduling. The process starts at block  305 . 
     At block  310 , motion data is logged. Motion data is logged, in one embodiment in a buffer or similar temporary memory. At block  315 , current motion is identified, and future expected motions are identified. At block  320 , the active applications are identified. 
     At block  320 , the process determines whether there is a conflict between the motions/sensors and any current tasks. If there is no conflict, the process continues to block  330 . At block  330 , the process determines whether there are any future tasks. Future tasks are tasks either scheduled by the user to be executed in the future, or halted previously. If there are no future tasks, the process returns to block  310  to continue logging motion data. 
     If there are future tasks, the process, at block  335 , determines whether there are resources available currently to execute the future task. In one embodiment, this is determined based on the motion data. In one embodiment, this is determined based on the motion data and the active application data. In one embodiment, this is determined based on the motion data and time-of-day data. 
     If the resources are available, at block  340  the future task is initiated. The process then returns to block  330 , to query whether there are any more future tasks to be scheduled. In one embodiment, the future tasks are scheduled in order of priority. That is the first query is for the highest priority future task, then for the next highest priority, and so on. In one embodiment, each future task is evaluated by this process. If there are no remaining future tasks, the process returns to block  310  to continue logging motion data. 
     If, at block  325 , the process found that there was a conflict between the current applications, the process continues to block  350 . 
     At block  350 , the conflicting resource is identified. This may include network bandwidth, memory bandwidth, display, etc. 
     At block  355 , the lowest priority application which uses that resource is identified. In one embodiment, the lowest priority resource may be one that is restartable, not viewed or actively utilized by the user. For example, a backup application may be the lowest priority application. 
     At block  360 , the process determines whether throttling should be used. In one embodiment, throttling is always used when available. In one embodiment, throttling is only used if the application is a non-interruptible application. In one embodiment, the user may set a preference for throttling. 
     If throttling should be used, the process, at block  365  throttles the conflicting application&#39;s use of the conflicting resource. The process then returns to block  325 , to determine whether there is still a conflict. 
     If throttling should not be used, at block  370  the lowest priority application is stopped. It is then, at block  375 , added to the future tasks list. In this way, the system ensures that the task will be performed at some future time. The process then returns to block  325 , to determine whether there is still a conflict. 
     In this way, the system provides a method to ensure that low priority applications are throttled based on motion data, and potentially other data. Note that while this and other processes are shown in flowchart form, the actual implementation need not be sequential as described. Thus, for example, future tasks may also be monitoring the resource availability for tasks on the list. In one embodiment, conflicts may be tested for every time there is a change in state in the device, i.e. a new application is started, a new motion type is detected, etc. 
       FIGS. 4A and 4B  are a flowchart of one embodiment of setting scheduling preferences. The process starts at block  405 . In one embodiment, this process is performed on the mobile device. I another embodiment, this process may be performed on a remote server, and the results may be uploaded to the mobile device. In one embodiment, the process may be split between the mobile device and a server. 
     At block  410 , the applications on the mobile device are identified. In one embodiment, this process is triggered each time a new application is added to the mobile device. In one embodiment, only new applications are evaluated and prioritized in that instance. 
     At block  415 , the process identifies any applications needing real-time feedback. Such applications may include sensors which require real-time control commands, applications such as telephone applications where even short delays can impact the user experience. 
     At block  420 , the process determines whether there are any such applications. If so, at block  422 , these applications receive the highest priority. The process then continues to block  425 . If there are no such applications, the process continues directly to block  425 . 
     At block  425 , the process identifies any applications having direct user interactions. Such applications may include games, productivity applications, and other applications where delays can impact the user experience. 
     At block  423 , the process determines whether there are any such applications. If so, at block  432 , these applications receive the next highest priority. The process then continues to block  435 . If there are no such applications, the process continues directly to block  435 . 
     At block  435 , the process identifies any non-interruptible applications. Such applications may include software installation, games requiring periodic memory access, and other applications that cannot be terminated without causing problems. 
     At block  440 , the process determines whether there are any such applications. If so, at block  442 , these applications receive the next highest priority. The process then continues to block  445 . If there are no such applications, the process continues directly to block  445 . 
     At block  445 , the process identifies any applications including periodic reporting. This includes sensors that have periodic updates, applications which report out to the user, applications such as email which use periodic data pulls, etc. 
     At block  450 , the process determines whether there are any such applications. If so, at block  452 , these applications receive the next highest priority. The process then continues to block  455 . If there are no such applications, the process continues directly to block  455 . 
     At block  455 , the remaining applications receive the lowest priority. 
     At block  460 , the process determines whether there is likely conflicts between equally prioritized applications. For example, it is unlikely that a user will be playing two games simultaneously, but the user may walk and make a telephone call at the same time. If there are equally prioritized applications which may conflict, the process continues to block  462 . 
     At block  462 , the conflicting applications are reprioritized based on usage statistics or other measurements. In one embodiment, the prioritization occurs within the same category. That is, the lowest priority application within a category is still a higher priority than the highest prioritization in the next lower category. In one embodiment, more frequently used applications receive higher priority. In one embodiment, delay-sensitivity is used for prioritizing within the category. In one embodiment, this step is skipped entirely, and the user is prompted to make prioritization decisions. In one embodiment, if two such applications are found in conflict during use, the one which was activated later is considered the higher priority application. 
     At block  465 , in one embodiment the priorities are provided to the user, and the user is permitted to make changes. In one embodiment, this only occurs if the user specifically requests it. Otherwise, the entire scheduling process is completely transparent to the user, and the user need not be aware of it at all. In one embodiment, if the user lowers the priority of an application which requires real-time feedback or has user interaction, the user is warned of the risk of such a reprioritization. 
     At block  470 , the priorities are saved. The process then ends at block  475 . In one embodiment, this process may be invoked by the user at any time, may be automatically triggered periodically, may be triggered whenever a new application is added to the mobile device, or may be started by another trigger. 
     In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.