Patent Description:
With present day smart phones and other portable (i.e., hand held) electronic devices, minimizing battery drainage is a key design consideration, as battery life is of paramount importance to consumers. To reduce battery drainage, most portable devices enter a power save mode following a predetermined time duration in which a user input is not detected at the device. During the power save mode, the display is turned off and processing activities of the central processing unit are minimized. Some devices have various stages of power save modes in which battery consumption is progressively reduced.

A typical smart phone in use today has tens or even hundreds of software applications, commonly called "apps", stored in the device's memory. Some of these apps are provided by the original equipment manufacturer (OEM). Others are downloaded by the user from external sources. An icon for each app is typically displayed on one of the device's home screens, allowing the user to rapidly launch it, whereby it runs on the device's processor and consumes battery power. Once a first app is launched and runs in the foreground by producing dominant images on the device's display, if the user switches operation to a second app, the first app may continue to perform low level background processing, such as periodically communicating with a server to receive updates. Further, some applications launch programs in the background or periodically run process or command in the background even when the terminal is in an idle or sleep mode, thus contributing to battery drainage. A user is typically unaware of the power being consumed by the running of such applications.

<CIT> discloses device-assisted services for protecting network capacity, which include monitoring a network service usage activity of a communications device in network communications.

<CIT> discloses an IT system behavior measurement and analysis system, where an analysis unit generates an analysis result by referring to trace data to accumulate a number of times of execution of a wake-up process.

The above and other aspects, features and advantages of the present technology will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings in which like reference numerals indicate like elements or features, wherein:.

The following description, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain exemplary embodiments of the invention provided herein for illustrative purposes. The description includes various specific details to assist a person of ordinary skill the art with understanding the claimed invention, but these details are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the illustrative examples described herein can be made without departing from the scope of the appended claims. For the purposes of simplicity and clarity, descriptions of well-known functions and constructions may be omitted when their inclusion may obscure appreciation of the subject matter of the claimed invention by a person or ordinary skill in the art.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the present invention are provided for illustration purpose only and not for the purpose of limiting the invention as defined by the appended claims.

Thus, for example, a reference to "a component surface" includes reference to one or more of such surfaces.

By the term "substantially" it is typically meant that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including but in no way limited to, for example, tolerances, measurement error, measurement accuracy limitations and other factors known to persons of ordinary skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide.

In exemplary embodiments of the invention described hereinafter, an electronic device and a method operative therein monitors automatic wakeup events that occur in the background during a sleep (or idle) mode. Wakeup events are monitored for respective applications executable within the electronic device, e.g., apps that run on an application processor (AP) of the device. Applications are then ranked for processing activity during the sleep mode, on the basis of at least the monitored wakeup events. For instance, an application determined to have the most frequent wakeups or use the most cumulative processor time during a predetermined time period of device operation in the background can be ranked at the top of a processing activity list. A list of apps with processing activity, or a ranking list, can be then be displayed, allowing a user to discern which applications are consuming more processing activity, and hence causing more battery drainage than is desired. A menu can then be generated which allows a user to take appropriate action, such as blocking wakeup automatic wakeups for a selected application, deleting the application altogether from the device memory, or removing the application from the ranking list.

In one implementation, ratios of automatic wakeups (including both periodic and non-periodic wakeups, if any) to user-initiated wakeups are established for each application. The processing activity rankings are then based on these ratios. A high ratio for an application is an indication that a relatively high percentage of the processing activity for that application has been occurring automatically, i.e., as part of background processing in the sleep mode without user interaction with the application. Applications exhibiting high ratios of this sort may be considered good candidates for having automatic wakeups blocked.

A portable electronic device in accordance with the invention can be a mobile terminal such a smart phone, a tablet computer, an electronic-book (e-book) reader, or any other electronic device that operates in a power save mode(s) to conserve battery power. A mobile terminal is a terminal or user equipment that can wirelessly access networks and can freely install and uninstall applications. Here, the networks include the Internet, mobile communication networks and other similar data and communication networks. A mobile terminal may wirelessly access the Internet via a mobile communication network using Wireless Application Protocol (WAP) or Wireless Internet Platform for Interoperability (WIPI), via a wireless Local Area Network (LAN) using access points, or via a portable Internet service such as Wireless Broadband (WiBro) or Worldwide Interoperability for Microwave Access (WiMax) enabling high-speed Internet access while in motion. A mobile communication network is composed of base stations and controllers controlling the same, may be a synchronous or asynchronous system, and may be any mobile network based on Code Division Multiple Access (CDMA), Global System for Mobile communications (GSM), third generation, enhanced third (<NUM>) generation, <NUM>th or <NUM>th generation wireless technology, or other suitable protocol.

<FIG> is a functional block diagram of an exemplary embodiment of an electronic device, <NUM>, that monitors and manages processing activity in accordance with the invention. Electronic device <NUM> includes a control unit <NUM> having at least one processor for controlling the overall operations of device <NUM>, and for executing applications (hereafter, also called "apps") <NUM> that interact with a user. As used herein, an app is any process that can output information or images on a display, output sound, cause movement such as vibration, perform a measurement, communicate with other processes or with external equipment, etc. As will be explained below, in some implementations, the user is provided with menu options to modify the behavior of selected apps. Therefore, the apps under particular consideration herein are apps that are nonessential to the basic operation of device <NUM>. (It is preferable that essential processes, such as original operating system (OS) processes, are not blocked from performing their intended operations via user management described hereafter as it would be undesirable to disturb such processes. ) Any app can be an OEM app originally provided as pre-installed software, or an app that was voluntarily downloaded by a user.

Electronic device <NUM> further includes a memory <NUM> that stores program instructions for applications retrieved by and executed within control unit <NUM>, and stores a variety of data for various programs. An RF communications unit <NUM> performs necessary operations on transmit (coding, amplification, modulation, up-converting, etc.) and on receive (filtering, downconverting, demodulation, decoding, amplification, etc.) to perform data communication via antenna <NUM> with external base stations, access nodes, or other computing devices. An input/output (I/O) section 150is provided for interaction with the user, and may include a display such as a touch screen, a keyboard (virtual and/or real), function keys or buttons, a speaker, microphone, and any other suitable I/O means. A rechargeable battery <NUM> provides electrical power to the various components of device <NUM>. Battery life of battery <NUM> (i.e., the length of time that the device being powered can operate on a single charge of the battery) may be improved by embodiments described herein, as processing activity causing battery drainage is selectively reduced.

Control unit <NUM> includes one or more processors within which a plurality of apps <NUM> run. Any one of apps APP-<NUM>, APP-<NUM>,. APP-N can run in the foreground, typically resulting in images generated by the app dominating the display of device <NUM>. The foreground running app is typically the result of a current user selection of that app for execution. While one app runs in the foreground, another app may run in the background, performing operations such as communicating with an external server to retrieve user data or to retrieve software updates for the application itself. For instance, an email app typically runs in the background while another app runs in the foreground, by periodically communicating with a mail server to check for the latest email. While the apps <NUM> are shown as part of control unit <NUM>, it is understood by one skilled in the art that when any app APP-j is not being actively executed such as running in the foreground, it may be in a state of suspension in between background operations. In the suspended state, the app may be considered to reside in memory <NUM> where the latest data corresponding to the suspended state is stored in correspondence with the program code thereof.

Control unit <NUM> also controls device <NUM> to enter a power save mode (interchangeably referred to herein as a sleep mode). In the sleep mode, the device's display can be turned off to conserve power, and the control unit's application processor (AP) can be suspended. When the AP is suspended, any applications currently running, whether in the foreground or background, are suspended until they are awakened, as discussed below.

The sleep mode can be automatically initiated following a predetermined time duration in which no user interaction is detected by device <NUM>. During the sleep mode, device <NUM> continues to perform periodic background communication operations necessary for device <NUM> to be communication ready. Furthermore, with predetermined arrangement therefor, any app can be automatically and periodically awakened in the sleep mode (unless blocked as discussed later) to retrieve or transmit user data or software updates. Control unit <NUM> further includes an activity manager <NUM>, an alarm manager <NUM>, kernel <NUM> and hardware (HW) timer <NUM>, which together function to monitor and manage processing activity in the sleep mode as described further hereafter. An operating system database (DB) <NUM> can be utilized as an alternative processing entity to the activity manager <NUM> in some implementations discussed later.

<FIG> is a flow chart illustrating an exemplary method <NUM> that may be performed in the electronic device <NUM> of <FIG>. During active mode operation of device <NUM>, a plurality of apps <NUM> each register wakeup alarms with the alarm manager <NUM> (step <NUM>). When an app such as APP-<NUM> registers a wakeup alarm, the app requests to be "awakened" at a point of time in the future, or on a periodic basis, such that the app can be run in the future to perform a predetermined operation. When an alarm is registered for an app, it is retained by the system even if the device <NUM> enters and remains in sleep mode.

At (<NUM>), the device <NUM> enters sleep mode, which, as indicated above, can occur automatically after a predetermined time duration during which no user inputs are received. If device <NUM> is equipped with a soft or hard key to allow sleep mode to be entered manually, sleep mode is initiated upon detecting a user input via the key. During sleep mode, the application processor (AP) which runs all apps, becomes suspended, until it is awakened by a subsequent alarm trigger stemming from a registered alarm, or until a user input is received in the I/O section <NUM> (e.g., the user touches a touchscreen of I/O <NUM>).

At (<NUM>), all wakeup events that occur during the sleep mode are recorded by the activity manager <NUM> (or the operating system DB in alternative implementation), and the events are tabulated for a predetermined time duration. The predetermined time duration can be established in a number of ways, and can be set by default or via a selection in a user settings menu. For instance, it may be desirable for a user or monitoring program to know how many times each app was awakened over the last X days or hours, regardless of the type of operation, e.g., active mode, sleep mode, or other type of power saving mode. Alternatively or additionally, the number of awakening times for each app over the last X days or hours only during sleep modes may be determined.

Next, apps are ranked for sleep mode usage based on the wakeup alarm events, and a list of the rankings is displayed in a user access mode (<NUM>) such as a menu mode. In this manner, the user can identify which apps are being awakened the most frequently during sleep modes and thus which apps are draining the battery <NUM> the most during sleep modes. Examples of ranking methods are detailed further below. At (<NUM>), wakeup alarms are modified according to a user instruction. In exemplary menu options described later (see <FIG>), a user may be given an option to block wakeup requests for a selected app, to delete an app, or to simply remove an app from the ranking list.

<FIG> illustrates a method operative within device <NUM> by which wakeup alarms can be registered and wakeup events recorded in accordance with implementations of the invention. In an active mode of device <NUM> (i.e., a non-sleep mode), a given application APP-j which is currently operating in the foreground or background can send a request for an alarm setting (registration) to alarm manager <NUM>, as indicated at (<NUM>). This request can be in the form of a wakeup alarm time for a specific time in the future. In this case, an additional request instruction can be included for subsequent wakeups at a specified periodic time interval beginning from the specific time. Alternatively, the request can be for a specified periodic wakeup without a specific start time, such that the time of the first wakeup could be determined by the system. The alarm manager <NUM> then delivers the requested wakeup alarm time to the kernel <NUM> if the particular app that made the request is not currently blocked from registering requests. As indicated earlier, a user can block selected apps from registering requests in an options menu presented on the device <NUM> display, an example of which is shown in <FIG>. At (<NUM>), kernel <NUM> then sets the HW timer in accordance with any non-blocked request by an app.

When a wakeup time arrives for the app, HW timer <NUM> generates a wakeup trigger corresponding to the app, which is delivered to alarm manager <NUM> via the kernel <NUM> (<NUM>). Alarm manager <NUM> responds by calling a function of the application to wake it up (<NUM>). At the same time, alarm manager <NUM> records (<NUM>) the wakeup event to an alarm count block (part of activity manager <NUM> in this example) which counts every wakeup event for each app of the apps <NUM>. In addition, the activity manager <NUM> determines the running time of the app for each wakeup event; the running times are also stored by the alarm count block (<NUM>). In this manner, wakeup statistics are generated for each app and compared with those of other apps to establish rankings, which are displayable in a rankings list for app management by the user.

Ranking of apps for processing activity during the sleep mode is an indirect way to rank apps for excessive battery usage. Such rankings can be established in several ways.

In one implementation of a ranking method, just the raw number of automatic wakeup events for each app (i.e., a wakeup event due to a registered alarm) occurring in sleep modes is counted over a predetermined period of time, such as X days or hours. The app with the most wakeup events is then considered to use the most processing power and is placed at the top of the ranking list for processing activity. Note that an "active mode wakeup" for a particular app can occur during the active mode when that app is not running in the foreground, but this type of wakeup event is not counted in the exemplary embodiment. In other words, while a first app is running in the foreground and a second app is essentially suspended without any processor usage, a wakeup alarm that was set previously can go off, whereby the second app performs its intended operations for that wakeup event as background processing while the first app continues to operate in the foreground. In other embodiments (not further described herein), such active mode wakeups may be considered.

In another ranking method, the cumulative run time due to automatic wakeup events for each app over the predetermined time duration is determined and used as the primary metric for ranking.

In another ranking method, a hybrid of the number of wakeup events and cumulative run time is considered. For example, it may be considered that a wakeup event expends a minimum amount of energy due to processing activity, even if the run time for that wakeup event is negligible. Therefore, a total processing activity measure may be determined with a hybrid approach by (k x N) + RT, where N is the number of wakeup events, k is predetermined constant considering a minimum amount of energy expended for each wakeup event, and RT is the cumulative run time for all wakeup events.

A ranking method according to still another embodiment is based on a ratio "C" of:.

At least four cases are possible for A / B, i.e.:.

Here, ALARM_TIME is cumulative wakeup lasting time in sleep state. For example, if a first wakeup lasts 3sec, a second wakeup lasts for 2sec during the predetermined time, the ALARM_TIME is 5sec and the ALARM_CNT is <NUM>. RUN CNT denotes the number of times the user initiated the application during the predetermined duration. RUN TIME refers to the cumulative running time due to user initiated activations of the app over the relevant time period.

Thus, the ratio C for a given application provides a measure of the percentage of the cumulative processing time for that application that is attributed to the automatic wakeup operations as compared to that attributed to the active operations initiated by the user. Consequently, a high ratio C for an app is an indication that a relatively high percentage of the processing activity for that app has been occurring automatically, i.e., as part of background processing without user interaction with the app. Apps exhibiting high ratios of this sort may be considered good candidates for having automatic wakeups blocked.

A simple example of determining a ranking based on the ratio C is illustrated in Table <NUM>. In the example, automatic wakeups and user-initiated executions are counted for each of a scheduling app, a clock alarm app, an email app and a weather app. (A user can set a certain time for an alarm in the schedule application or e.g., for morning call time in the clock alarm application. Even though the system is in a sleep state, the alarm works by the registered wakeup when the set time is reached. Email and weather applications usually synchronize with a server periodically whereas alarm of the scheduling and clock alarm application usually operate only one time that the user set. ) The ratio C is lowest for the scheduling app and highest for the email app. Hence the user might consider that the processing activity for the email app during the sleep mode is excessive. The user may then decide to make an adjustment such as blocking wakeups for the email app or lengthening the cycle for which the email app accesses a mail server in another settings menu.

<FIG> is a flow chart illustrating an example method, <NUM>, that may be performed in the electronic device of <FIG>. In this example, wakeup events for apps are monitored in a sleep mode and user executions are also monitored, whereby rankings may be based on the ratio C indicating percentage of processing activity "A" due to automatic wakeup events to processing activity "B" due to user interactions for each app under consideration.

The device <NUM> is operated in the active mode at <NUM>. Wakeup alarms are then registered for respective apps at <NUM> in the manner described above. If a sleep mode is entered at <NUM>, the application processor (AP) of control unit <NUM> is suspended such that no apps are run; and the alarm manager <NUM> then ascertains at <NUM> whether a wakeup trigger for any app has been received from the HW timer <NUM>. If not, the device remains in the sleep mode. If yes, then at <NUM>, the wakeup count "A" for the relevant app is updated, and processing activity rankings are established or updated in accordance with the additional "A" count data. That is, the "C" count for the app is updated or in the process of being developed. (An initial predetermined time duration for generating sufficient counts is necessary to establish an initial ranking for the various apps.

If the sleep mode is not entered at <NUM>, then if a user execution for an app is detected at <NUM>, then the corresponding count "B" for user executions of that app is updated at <NUM>, such that the ratio "C" can be updated.

With the ratio C updated at <NUM> or <NUM>, the process determines whether a user menu for managing processing activity is accessed at <NUM>. If no, the process returns to <NUM>. If yes, it is determined at <NUM> whether a user instruction is received for blocking wakeup alarms of removing apps. If no, the flow returns to <NUM>. If yes, the registered alarms are modified accordingly at <NUM>, and the flow then returns to <NUM>.

<FIG> is a functional block diagram of processing modules within an embodiment 110a of the control unit <NUM> of electronic device <NUM>. Control unit 110a includes alarm manager <NUM>, activity manager <NUM>, kernel <NUM>, HW timer <NUM>, and a representative application APP-j of the foreground / background running apps <NUM>, all of which have been described above in connection with <FIG>. Control unit 110a further includes an alarm count block <NUM>, a data block <NUM> and a User Interface (UI) block <NUM>.

As described above, any given app APP-j of apps <NUM> registers a wakeup alarm with alarm manager <NUM> (to perform a predefined processing operation) to request wakeup at a future time. That is, a future wakeup event is expected to be performed for APP-j at a time in which the device <NUM> is either in a sleep mode or in the active mode running a different app in the foreground. The wakeup alarm time is delivered to HW timer <NUM>, and when the wakeup occurs, the app APP-j is called to wake it up and begin its predefined processing operation. In conjunction with the wakeup call, alarm manager <NUM> delivers the APP name to the alarm count block <NUM>. Alarm count block <NUM> counts every application's wakeup events and stores the running time of the application using a received start and end time of the processing activity for each wakeup event from the activity manager <NUM>. To this end, alarm count block <NUM> includes an APP_ALARM_CNT processing module <NUM> to update wakeup counts (alarm counts) for respective apps. An updated count for APP-j is delivered to a memory region <NUM> within data block <NUM> (data block <NUM> can also be considered part of memory <NUM>) which stores the alarm counts for the respective apps. Alarm count block <NUM> further includes an App_Run_CNT processing module to monitor run times corresponding to the wakeup events, to eventually arrive at a cumulative run time over a predetermined time duration as described earlier. Thereby, a processing activity ranking can be derived for the various apps that have registered wakeup alarms.

Data block <NUM> stores wakeup statistics calculated in one of the methods described above in connection with <FIG> or <FIG>. That is, processing activity for apps during the sleep mode can be characterized either by the number of wakeup events or cumulative running times associated with the wakeup events over a predetermined time duration; or, by the ratio C described above.

Referring temporarily to <FIG>, an example display screen <NUM> of a menu which enables processing activity management for apps with registered alarms in accordance with an embodiment is shown. Display screen <NUM> includes a main area <NUM> displaying identifiable icons for a predetermined number of apps (APP-<NUM> to APP-<NUM> in the example). The apps displayed are those in a most frequent wakeup list established for all the apps <NUM>. A metric of processing activity during power save mode is displayed alongside each app APP-<NUM> to APP-<NUM>. In the example, the ratio C is used to characterize the amount of power save mode processing activity for each app as the percentage defined by A/B (number of automatic wakeup events to the number of user initiated executions). In other embodiments, the metric can be based just on the number of automatic wakeups, the running times for those wakeups, or a combination thereof as described earlier. The displayed metric can be augmented by a length of a bar <NUM> for rapid visual perception of the relative processing activities.

Any displayed app icon such as that for APP-<NUM> can be selected by the user for processing activity management, as indicated by touch event <NUM> occurring on a touch screen display of device <NUM>. When an app is so selected, a pop-up menu or the like is generated, prompting a user to input a command for one of several menu options. Selecting a "block wakeup" option <NUM> results in all future automatic wakeup alarms being blocked for the selected app APP-<NUM>, thereby blocking processing operations for that app in the power save mode. A "delete app" menu option <NUM> allows the user to delete the selected app APP-<NUM> entirely from the device memory <NUM>. A "remove from list" menu option allows the user to remove the icon from the frequent wakeup display list on main screen <NUM>, whereby another app is typically displayed in its place. Main screen <NUM> includes a power saving mode icon <NUM> allowing display of the apps in the frequent wakeup list, a removed list icon <NUM> allowing the user to view and manage those apps already removed from the frequent wakeup list; and a blocked list icon <NUM> allowing the user to display a list of the blocked apps. A blocked app may also be allowed to become unblocked with suitable user command (not shown). Thus, <FIG> illustrates a graphical user interface (GUI) that is provided, for interaction by a user, by certain devices embodying the invention, that GUI providing the user with an indication of relative power consumption by a plurality of apps, and enabling the user to provide inputs (commands) to influence future power consumption.

Returning to <FIG>, the UI processing block <NUM> is configured to generate the user interface display for processing activity management such as that shown and described for <FIG>. UI block <NUM> also provides a reset function to initialize the wakeup statistics. To this end, UI processing block <NUM> includes a LIST display module <NUM>, a delete App processing module <NUM>, a Remove App from list processing module <NUM>; a Block WakeupAlarm processing module <NUM>; a Removed App list processing module <NUM>; a blocked App list processing module <NUM>; and a Reset Data processing module <NUM>. Data block <NUM> further includes a List manage data structure <NUM> to store the various lists which are accessed as needed by the associated processing modules <NUM> to <NUM>.

<FIG> is a functional block diagram of processing modules within an embodiment 110b of the control unit <NUM> of electronic device <NUM>. Control unit 110b includes an alarm count block <NUM>, a data block <NUM> and a UI block <NUM> which can be the same or substantially similar to count block <NUM>, data block <NUM> and UI block <NUM>, respectfully, of <FIG>. Moreover, alarm manager <NUM>, kernel <NUM>, HW timer <NUM> and representative application APP-j are the same as described above. Control unit 110b differs from control unit 110a by substituting an Operating System database (DB) <NUM>, such as the Android (trademark of Google corporation) DB, for the activity manager <NUM>. The Operating System DB <NUM> manages the data block <NUM> including the number of application executions (i.e., the above-described parameter "B"), the application running times and the number of automatic wakeup alarms (i.e., the parameter "A" described above). The alarm count block <NUM> receives the information from the Operating System DB <NUM> and operates in the same manner as in the embodiment of <FIG>.

The above-described methods according to the present invention can be implemented in hardware, firmware or as software or computer code that can be stored in a recording medium such as a CD ROM, an RAM, a floppy disk, a hard disk, or a magneto-optical disk or computer code downloaded over a network originally stored on a remote recording medium or a non-transitory machine readable medium and to be stored on a local recording medium, so that the methods described herein can be rendered in such software that is stored on the recording medium using a general purpose computer, or a special processor or in programmable or dedicated hardware, such as an ASIC or FPGA. As would be understood in the art, the computer, the processor, microprocessor controller or the programmable hardware include memory components, e.g., RAM, ROM, Flash, etc. that may store or receive software or computer code that when accessed and executed by the computer, processor or hardware implement the processing methods described herein. In addition, it would be recognized that when a general purpose computer accesses code for implementing the processing shown herein, the execution of the code transforms the general purpose computer into a special purpose computer for executing the processing shown herein.

It will be also be appreciated that, throughout the description and claims of this specification, language in the general form of "X for Y" (where Y is some action, activity or step and X is some means for carrying out that action, activity or step) encompasses means X adapted or arranged specifically, but not exclusively, to do Y.

Claim 1:
A portable electronic device (<NUM>) comprising:
a display (<NUM>);
a memory (<NUM>) within which applications are stored;
a control unit (<NUM>), operatively coupled to the memory (<NUM>), and configured to:
monitor automatic wakeup events for respective applications that occur when the applications are in a background within the electronic device (<NUM>) during a power save mode or idle mode;
present via the display (<NUM>) a list of the applications including a processing activity, based on the monitored automatic wakeup events, for each of the applications, wherein the applications included in the list are ranked based on the processing activity for each of the applications;
present via the display (<NUM>) a user selectable icon permitting a user to block automatic wakeup events for a selected application that occur when the selected application is in the background during the power save mode or idle mode; and block, in response to the selection of the user selectable icon,
the automatic wakeup events of the selected application that occur in the background during the power save mode or idle mode.