Patent Grant
10108251
Personal mobile devices have become increasingly popular. Users typically carry multiple personal mobile devices at any given time to satisfy their mobile computing and communication needs. These devices may include, for example, phones and smart phones, laptops, tablets, gaming devices, digital cameras, personal digital assistants, and so on. Personal mobile devices run multiple applications at any given time and run on batteries while their users are mobile. There are various types of batteries available (e.g., lithium polymer batteries, lithium ion batteries, nickel cadmium batteries, etc.) but they all suffer from limited lifetimes. Even though battery technology has improved significantly in the last few years, it is still quite common for users to run down their devices' batteries unexpectedly because of the unpredictable mix of applications they run at any given time.
The battery usage or consumption of a personal mobile device may be monitored with a power management tool. Most power management tools simply monitor a device's battery usage, set off alarms when the battery usage drops below a certain threshold, and display the battery usage for the users to act upon, e.g., by charging the device when needed. Recent tools have been developed to monitor the percentage of battery used by a given component or application running in a device. These tools, however, suffer from significant monitoring overhead and are limited to working in only a small category of devices.
The personal mobile devices of today therefore have a very coarse level of granularity at which battery usage is monitored. Power management tools may monitor battery usage per application but they do not allow users to allocate the battery usage per application. For example, if a user is expecting an important business call at a smart phone that has low battery, the user cannot automatically allocate the battery to the phone call and suspend other applications from draining the battery. Users have to resort to ad-hoc methods based on experience and rudimentary monitoring to turn off applications that are perceived to consume more battery. Further, there is no way for a user to manage or coordinate total available battery power across multiple personal mobile devices.
In addition, a single mobile device is used in multiple contexts (e.g., work, personal, guest, etc.) by a user. These contexts can be considered as multiple user personas that may impose different requirements on the device usage policies, including those related to the battery. A particular persona, say the work persona, may put a higher priority to the e-mail and phone usage, while the guest persona may put a higher priority on some game applications.
The present application may be more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:
A system, method, and non-transitory computer readable medium for virtualizing battery in a personal mobile device or across personal mobile devices are disclosed. As generally described herein, a personal mobile device is a portable computing and communication device that is used to process, receive, and send information in various environments. Personal mobile devices may include, but not be limited to, for example, phones and smart phones, laptops, tablets, gaming devices, digital cameras, and personal digital assistants, among others.
In various embodiments, a battery virtualization module virtualizes the battery in a personal mobile device. In other embodiments, a coordinated battery virtualization module virtualizes the total available battery across a group of diverse personal mobile devices controlled by a user. Battery virtualization, as generally used herein, refers to the ability to allocate an available battery charge among specific applications and multiple user personas and to ensure that designated applications have higher priority and access to the battery. In the first set of embodiments, the applications run on the personal mobile device itself. In the second set of embodiments, the applications may run across the group of diverse personal mobile devices controlled by the user. The goal in both cases is to maximize the total battery life, making sure that battery can be reserved for specific high priority applications, and thus enhance the user's Quality of Experience (“QoE”).
It is appreciated that embodiments described herein below may include various components and features. Some of the components and features may be removed and/or modified without departing from a scope of the system, method, and non-transitory computer readable medium for virtualizing battery across personal mobile devices. It is also appreciated that, in the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. However, it is appreciated that the embodiments may be practiced without limitation to these specific details. In other instances, well known methods and structures may not be described in detail to avoid unnecessarily obscuring the description of the embodiments. Also, the embodiments may be used in combination with each other.
Reference in the specification to “an embodiment,” “an example” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment or example is included in at least that one example, but not necessarily in other examples. The various instances of the phrase “in one embodiment” or similar phrases in various places in the specification are not necessarily all referring to the same embodiment. As used herein, a component is a combination of hardware and software executing on that hardware to provide a given functionality.
Referring now to
Attention is now directed to
For example, the user could specify policies for prioritizing phone functionality at the highest level, while putting all business applications at the next priority level, and so on. In another example, the user may allocate percentages of battery usage across applications, such as, for example, allocate 20% of battery usage to games, allocate 50% of battery usage to phone calls, and so on. As appreciated by one skilled in the art, users today run applications with multiple personas (e.g., work, personal, parent, etc.) as well as varying contexts (e.g., locations, cost, etc.). The policies that the user may specify with the User Policy and Rules engine 205 may be based on the user's multiple personas and context information.
The Application Power Monitoring module 210 monitors battery usage per application. CPU and memory usage on a per application basis are also monitored, which help in estimating the battery usage. The Application Power Monitoring module 210 may adopt various models to monitor battery usage, including models that are device-specific. Lastly, the Power-Aware Application Resource Scheduler module 215 uses the monitoring information acquired by the Application Power Monitoring module 210 to make resource scheduling decisions for applications running in the device. For example, applications that have used up their battery allocation may be forced to close and thus starved for resources such as CPU cycles, I/O devices, memory accesses, and so on.
An example of a battery virtualization module of
In various embodiments, when the personal mobile device 315 is being charged, the battery virtualization module 315 allocates the battery for each application, class of applications, or user personas, based on battery charging policies. For example, the user might want proportional charging or priority-based charging for each application, class of applications or user personas.
A flowchart for virtualizing a battery in a personal mobile device is shown in
It is appreciated that each application running in the device has the perception that it has its own dedicated battery, even though there is a single battery that is shared by all applications.
In various embodiments, the battery virtualization module described above with reference to
The Application Power Monitoring module 710 monitors battery usage per application. CPU and memory usage are also monitored and used to estimate the battery usage. The Application Power Monitoring module 710 may adopt various models to monitor battery usage, including models that are device-specific. Lastly, the Power-Aware Application Migration and Resource Scheduler module 715 uses the monitoring information acquired by the Application Power Monitoring module 710 to make resource scheduling decisions for applications running in the user's personal mobile devices.
In this case, the Power-Aware Application Migration and Resource Scheduler 715 consolidates application power profiles and current power availability from all the devices controlled by the user, and then makes informed decisions to manage and control the resource scheduling of applications at each of the individual devices, including admission control (i.e., stopping or delaying the launch of specific applications). In addition, the control actions include application migration from one device to another and can also include the use of communication and computing in a disaggregated manner across the devices.
For example, consider a user running applications in four personal mobile devices: a smart phone, a tablet, a laptop, and a gaming device. The user establishes policies that specify that the phone applications are to be allocated 40% of the total battery power. When those phone applications are running, depending on the battery being consumed at each device by the other applications, the Power-Aware Application Migration and Resource Scheduler module 715 may trigger the migration of some of these other applications to other devices with more battery available. The goal is to have battery allocation across the applications and devices controlled by the user so that each application perceives to have its own dedicated battery. As appreciated by one skilled in the art, the application migration and resource scheduling are transparent to the user. The user may set the power management policies with the User Policies and Rules engine 705 and the Application Power Monitoring module 710 and Power-Aware Application Migration and Resource Scheduler module 715 monitor and allocate the battery across the applications and devices accordingly.
Attention is now directed to
As appreciated by one skilled in the art, the coordinated battery virtualization module 800 is shown implemented on top of the hypervisors in the personal mobile devices for illustration purposes only. Other implementations may be considered, including having the coordinated battery virtualization module 800 be integrated with the hypervisor in each personal mobile device. In case the mobile device is not equipped with a hypervisor, but includes a host OS, the coordinated battery virtualization module 800 can be implemented in the host OS.
Referring now to
A flowchart for virtualizing a battery across personal mobile devices controlled by a user is shown in
The power management policies may be specified by the user with a user interface such as the one illustrated in
Advantageously, the battery virtualization module 200 of
The battery virtualization module 200 of
A machine (e.g., a computing device) can include and/or receive a tangible non-transitory computer-readable medium 1220 storing a set of computer-readable instructions (e.g., software) via an input device 1225. As used herein, the processor 1205 can include one or a plurality of processors such as in a parallel processing system. The memory can include memory addressable by the processor 1205 for execution of computer readable instructions. The computer readable medium 1220 can include volatile and/or non-volatile memory such as a random access memory (“RAM”), magnetic memory such as a hard disk, floppy disk, and/or tape memory, a solid state drive (“SSD”), flash memory, phase change memory, and so on. In some embodiments, the non-volatile memory 1215 can be a local or remote database including a plurality of physical non-volatile memory devices.
The processor 1205 can control the overall operation of the component 1200. The processor 1205 can be connected to a memory controller 1230, which can read and/or write data from and/or to volatile memory 1210 (e.g., RAM). The processor 1205 can be connected to a bus 1235 to provide communication between the processor 1205, the network connection 1240, and other portions of the component 1200. The non-volatile memory 1215 can provide persistent data storage for the component 1200. Further, the graphics controller 1245 can connect to an optional display 1250.
Each component 1200 can include a computing device including control circuitry such as a processor, a state machine, ASIC, controller, and/or similar machine. As used herein, the indefinite articles “a” and/or “an” can indicate one or more than one of the named object. Thus, for example, “a processor” can include one or more than one processor, such as in a multi-core processor, cluster, or parallel processing arrangement.
It is appreciated that the previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. For example, it is appreciated that the present disclosure is not limited to a particular configuration, such as component 1200.
Those skilled in the art would further appreciate that the various illustrative modules and steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. For example, the example steps of
To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality (e.g., the Coordinated Battery Virtualization module 1260). Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.
This is a continuation of U.S. application Ser. No. 14/383,180, filed Sep. 5, 2014, which is a national stage application under 35 U.S.C. § 371 of PCT/US2012/028381, filed Mar. 8, 2012, which are both hereby incorporated by reference in their entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6697953 | Collins | Feb 2004 | B1 |
| 7583951 | Gibbs | Sep 2009 | B2 |
| 7584376 | Finkelstein et al. | Sep 2009 | B2 |
| 7598702 | Walrath | Oct 2009 | B2 |
| 7864720 | Jeyaseelan | Jan 2011 | B2 |
| 7873852 | Bell | Jan 2011 | B2 |
| 8958854 | Morley et al. | Feb 2015 | B1 |
| 20050060590 | Bradley et al. | Mar 2005 | A1 |
| 20050085277 | Chen | Apr 2005 | A1 |
| 20060140140 | Fuccello | Jun 2006 | A1 |
| 20070079154 | Diefenbaugh et al. | Apr 2007 | A1 |
| 20070243852 | Gibbs | Oct 2007 | A1 |
| 20080186086 | Bell | Aug 2008 | A1 |
| 20080200220 | Jackson | Aug 2008 | A1 |
| 20080313483 | Pasupuleti Sureshbabu | Dec 2008 | A1 |
| 20090187782 | Greene et al. | Jul 2009 | A1 |
| 20090225230 | Arroyo et al. | Sep 2009 | A1 |
| 20100023940 | Iwamatsu et al. | Jan 2010 | A1 |
| 20100145643 | Katpelly et al. | Jun 2010 | A1 |
| 20100146312 | Liao | Jun 2010 | A1 |
| 20100194632 | Raento | Aug 2010 | A1 |
| 20110159931 | Boss et al. | Jun 2011 | A1 |
| 20110213997 | Kansal et al. | Sep 2011 | A1 |
| 20110268000 | Kashikar et al. | Nov 2011 | A1 |
| 20120047379 | Chen et al. | Feb 2012 | A1 |
| 20120167118 | Pingili | Jun 2012 | A1 |
| 20120324578 | Seinfeld | Dec 2012 | A1 |
| 20130117595 | Murawski | May 2013 | A1 |
| 20130132009 | Rolia | May 2013 | A1 |
| 20140024416 | Xie et al. | Jan 2014 | A1 |
| 20140195843 | Lai et al. | Jul 2014 | A1 |
| 20140365795 | Nielsen et al. | Dec 2014 | A1 |
| 20150047380 | Liao | Feb 2015 | A1 |
| 20150058617 | Oishi | Feb 2015 | A1 |
| 20150177811 | Bose et al. | Jun 2015 | A1 |
| 20150324181 | Segal | Nov 2015 | A1 |
| 20150347179 | Barraclough et al. | Dec 2015 | A1 |
| Number | Date | Country |
|---|---|---|
| 101727166 | Jun 2010 | CN |
| 2015162 | Jan 2009 | EP |
| 10-2009-0064403 | Jun 1999 | KR |
| 10-2010-0126025 | Dec 2010 | KR |
| 2010147610 | Dec 2010 | WO |
| Entry |
|---|
| Anastasi et al., “Power Management in Mobile and Pervasive Computer Systems,” University of Pisa, Department of Information Engineering. |
| Number | Date | Country | |
|---|---|---|---|
| 20170068300 A1 | Mar 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14383180 | US | |
| Child | 15341127 | US |
