Browse Prior Art Database

System and Method for Battery Power Management for the Successful Future Critical Task Execution of Mobile Devices Disclosure Number: IPCOM000249131D
Publication Date: 2017-Feb-08
Document File: 4 page(s) / 58K

Publishing Venue

The Prior Art Database


i. Is there a way to prioritize the activities consuming the battery power, and preserve some battery power for the future high priority activities to happen successfully?

ii. We propose a method for battery power management for the successful future critical task execution of mobile devices with the use of APIs to make calls to the mobile OS by different applications.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.


System and Method for Battery Power Management for the Successful Future Critical Task Execution of Mobile Devices

Examples of Critical task executions requiring OS level API support:

Consider a chatting application where user has kept an alert when his manager becomes available. In such cases, only application knows when a particular user is going to be available when he actually logs into the application which gets registered at server. It is a future event which user is interested in because he has to discuss urgent issue over the chat client.

Other example would be a whether application (e.g., DarkSky) where you keep an alert like "alert me when it is cloudy" because user has to start early to reach his home as rains may spoil the road.

Other example might be "destination alert" app for transportation service (e.g., IRCTC). Reaching destination station may not be always at the schedule time. Other parameters like location has to be used which are again application specific.

Working of the proposed method:

• Step 1: It’s possible to get the list of ongoing & future activities involving battery power usage.  Directly – from the events/activities scheduled by the user (alarm events,

calendar events, etc.)  Indirectly – from the remainder’s descriptions (text analytics), from

SMS/notification descriptions, from the call records (voice call analysis data), etc. data sources.

• Step 2: It’s possible to find the expected battery power consumption amount for the different activities.  Using historical information, user profiles, etc.  Ongoing data download leaves the battery 95% to 85% full (using the

metadata like file size getting downloaded, etc.) • Step 3: It’s possible to find priorities among the activities.

 Using the user’s preferences, historical information, etc.  Example: Alarm event for tomorrow morning has more priority than on

ongoing download. • Step 4: Find if the successful execution of any of these activities is obstructed

due to the battery power consumption by lower priority activities.  If YES: Alert the user about the possible conflict of high priority activity

going to be obstructed by the lower priority activity. And get user’s confirmation on this.

o If the user responds with a neglect on the conflict (because he would take care of recharging the battery soon), then nothing to do.


o If the user does not respond or responds to take an action, then the low priority activity will be put on hold (and resumed when the battery power violations are not going to happen)

 If NO: Nothing to do.

System Design:

User APIs to make calls to the mobile OS

 API to register task/activity details with the Mobile Operating System:

RegisterTask API:

Input Parameters:(Task Id, App Id, Priority, ExpectedStartTime, ExpectedBatteryUsageAmount)

Description: Register the task along with it’s App information at the mobile operating system. P...