Optimizing preemptive operating system with motion sensing

Abstract

A method and apparatus to provide a scheduler comprising determining a current use characteristic for the device based on motion information and active applications, and scheduling a future task.

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 determining a current use characteristic for a device based on motion information and active applications, and scheduling a future task.

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.

FIG. 6 is a block diagram of a computer system that may be utilized with the present invention.

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'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'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'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'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.

FIG. 6 is a block diagram of a particular machine that may be used with the present invention. It will be apparent to those of ordinary skill in the art, however that other alternative systems of various system architectures may also be used.

The data processing system illustrated in FIG. 6 includes a bus or other internal communication means 640 for communicating information, and a processing unit 610 coupled to the bus 640 for processing information. The processing unit 610 may be a central processing unit (CPU), a digital signal processor (DSP), or another type of processing unit 610.

The system further includes, in one embodiment, a random access memory (RAM) or other volatile storage device 620 (referred to as memory), coupled to bus 640 for storing information and instructions to be executed by processor 610. Main memory 620 may also be used for storing temporary variables or other intermediate information during execution of instructions by processing unit 610.

The system also comprises in one embodiment a read only memory (ROM) 650 and/or static storage device 650 coupled to bus 640 for storing static information and instructions for processor 610. In one embodiment, the system also includes a data storage device 630 such as a magnetic disk or optical disk and its corresponding disk drive, or Flash memory or other storage which is capable of storing data when no power is supplied to the system. Data storage device 630 in one embodiment is coupled to bus 640 for storing information and instructions.

The system may further be coupled to an output device 670, such as a cathode ray tube (CRT) or a liquid crystal display (LCD) coupled to bus 640 through bus 660 for outputting information. The output device 670 may be a visual output device, an audio output device, and/or tactile output device (e.g. vibrations, etc.)

An input device 675 may be coupled to the bus 660. The input device 675 may be an alphanumeric input device, such as a keyboard including alphanumeric and other keys, for enabling a user to communicate information and command selections to processing unit 610. An additional user input device 680 may further be included. One such user input device 680 is cursor control device 680, such as a mouse, a trackball, stylus, cursor direction keys, or touch screen, may be coupled to bus 640 through bus 660 for communicating direction information and command selections to processing unit 610, and for controlling movement on display device 670.

Another device, which may optionally be coupled to computer system 600, is a network device 685 for accessing other nodes of a distributed system via a network. The communication device 685 may include any of a number of commercially available networking peripheral devices such as those used for coupling to an Ethernet, token ring, Internet, or wide area network, personal area network, wireless network or other method of accessing other devices. The communication device 685 may further be a null-modem connection, or any other mechanism that provides connectivity between the computer system 600 and the outside world.

Note that any or all of the components of this system illustrated in FIG. 6 and associated hardware may be used in various embodiments of the present invention.

It will be appreciated by those of ordinary skill in the art that the particular machine that embodies the present invention may be configured in various ways according to the particular implementation. The control logic or software implementing the present invention can be stored in main memory 620, mass storage device 630, or other storage medium locally or remotely accessible to processor 610.

It will be apparent to those of ordinary skill in the art that the system, method, and process described herein can be implemented as software stored in main memory 620 or read only memory 650 and executed by processor 610. This control logic or software may also be resident on an article of manufacture comprising a computer readable medium having computer readable program code embodied therein and being readable by the mass storage device 630 and for causing the processor 610 to operate in accordance with the methods and teachings herein.

The present invention may also be embodied in a handheld or portable device containing a subset of the computer hardware components described above. For example, the handheld device may be configured to contain only the bus 640, the processor 610, and memory 650 and/or 620.

The handheld device may be configured to include a set of buttons or input signaling components with which a user may select from a set of available options. These could be considered input device #1675 or input device #2680. The handheld device may also be configured to include an output device 670 such as a liquid crystal display (LCD) or display element matrix for displaying information to a user of the handheld device. Conventional methods may be used to implement such a handheld device. The implementation of the present invention for such a device would be apparent to one of ordinary skill in the art given the disclosure of the present invention as provided herein.

The present invention may also be embodied in a special purpose appliance including a subset of the computer hardware components described above, such as a kiosk or a vehicle. For example, the appliance may include a processing unit 610, a data storage device 630, a bus 640, and memory 620, and no input/output mechanisms, or only rudimentary communications mechanisms, such as a small touch-screen that permits the user to communicate in a basic manner with the device. In general, the more special-purpose the device is, the fewer of the elements need be present for the device to function. In some devices, communications with the user may be through a touch-based screen, or similar mechanism. In one embodiment, the device may not provide any direct input/output signals, but may be configured and accessed through a website or other network-based connection through network device 685.

It will be appreciated by those of ordinary skill in the art that any configuration of the particular machine implemented as the computer system may be used according to the particular implementation. The control logic or software implementing the present invention can be stored on any machine-readable medium locally or remotely accessible to processor 610. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g. a computer). For example, a machine readable medium includes read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, or other storage media which may be used for temporary or permanent data storage. In one embodiment, the control logic may be implemented as transmittable data, such as electrical, optical, acoustical or other forms of propagated signals (e.g. carrier waves, infrared signals, digital signals, etc.).

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.

Claims

1. A method comprising: identifying one or more resources currently in use by a device;identifying current motion information for the device;determining predicted future motion for the device; andscheduling a future task based on the resources used by other active tasks, the current motion information, and the predicted future motion of the device.

2. The method of claim 1, further comprising: scheduling the future task to be immediately executed when the task utilizes resources not currently used by the device.

3. The method of claim 1, further comprising: determining that the future task would utilize a particular resource currently used by an other task on the device; andwhen the future task is a higher priority than the other task, reducing resource availability to the other task.

4. The method of claim 3, wherein reducing resource availability comprises terminating the other task by the device.

5. The method of claim 4, wherein when the other task is terminated, the other task is placed on a future task list to be executed when the resource becomes available again.

6. The method of claim 1, further comprising: prioritizing tasks based on resource use and application profile.

7. The method of claim 1, wherein the task is transmitting data to a server, and wherein the data transmission task is scheduled when the motion information and the currently active applications indicate that the device is idle.

8. The method of claim 7, wherein the data is for one or more of: uploading, downloading, and synchronizing data with a server.

9. The method of claim 7, wherein the device is idle when the device is motionless, and no user interaction with the device is occurring.

10. The method of claim 7, wherein the device is idle when the device is motionless and no voice call is being made.

11. A device comprising: a motion sensor to obtain motion information;resource detector to detect one or more currently used resources; anda processor to predict a future use characteristic for the device, based on the one or more currently used resources, current motion information of the device, and predicted future motion information; anda scheduler to schedule one or more tasks to be executed at a future time based on the future use characteristics of the device.

12. The device of claim 11, further comprising: the scheduler to schedule the task to be immediately executed, when the task utilizes resources not currently used.

13. The device of claim 11, further comprising: a prioritizer to determine a conflict between the currently used resources and the resources needed by the task; andwhen the task is a higher priority, a resource restrictor to reduce resource availability to current users of the resource.

14. The device of claim 13, wherein reducing resource availability comprises terminating the current users of the resource.

15. The mobile device of claim 14, wherein when the existing operation is terminated, the existing operation is placed on a future task list to be executed when the resource becomes available again.

16. The device of claim 11, further comprising: the scheduler to prioritize tasks based on resource use and application profile.

17. The device of claim 11, wherein the task is transmitting data to a server, and wherein the data transmission task is scheduled when the motion information and the currently active applications indicate that the device is idle.

18. The device of claim 17, wherein the data call is for one or more of: uploading, downloading, and synchronizing data with a server.

19. The device of claim 17, wherein the device is idle when one of the following is occurring: the device is motionless and no user interaction with the device is occurring, or when the device is motionless and no voice call is being made.

20. A device including a network connection comprising: a motion information logic to receive motion information of a device, and to predict future motion information;a resource detector to detect current resource usage of the device;a processor to determine future use characteristics based on the one or more of the current resource usage, the current motion information, and the predicted future motion information;a scheduler to receive a task to be scheduled to be executed at a future time;the scheduler to schedule the task for future execution based on the predicted future use characteristics.