Adaptive connected standby for a computing device

Various computing devices and methods of managing the power consumption thereby are disclosed. In one aspect, a method of managing power consumption of a computing device that has a battery is provided. The method includes cycling the computing device between a connected standby active state and a connected standby idle state. The duration of the connected standby idle state is set based at least in part on a charge level of the battery.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computing devices and software, and more particularly to managing a connected standby state for a computing device.

2. Description of the Related Art

Battery operated devices, such as portable computers and smart phones, rely on battery power when not connected to source of external power, such as an AC source. Modern portable computing devices may be capable of simultaneously running many power hungry applications and components, such as disk drives, communications radios (WiFi, WAN etc.) displays and others. Power conservation, even in the face of these power consuming programs and components, remains a technical goal since the need for more frequent battery recharges can reduce user satisfaction.

The inventors have recognized one known technique used for battery power is to place the computing device into a connected standby state. The connected-standby state can be described as periodic waking up of the computing device, restoring the basic state required to establish network connectivity and allow various applications to access their remote servers and update data on the local device as well as the remote state. Conventional connected-standby control algorithms use a few fixed battery threshold levels to guide their behavior, which means that until the battery charge goes down to some critical level, the control behavior is exactly the same. When the battery hits the critical level, the behavior changes rapidly to only minimal periodical network connectivity before shutting down completely when battery discharges to an “alarm” level. The main problem is that the control algorithm remains the same throughout the wide range of battery charge levels and other environmental circumstances.

The present invention is directed to overcoming or reducing the effects of one or more of the foregoing disadvantages.

SUMMARY OF EMBODIMENTS OF THE INVENTION

In accordance with one aspect of an embodiment of the present invention, a method of managing power consumption of a computing device that has a battery is provided. The method includes cycling the computing device between a connected standby active state and a connected standby idle state. The duration of the connected standby idle state is set based at least in part on a charge level of the battery.

In accordance with another aspect of an embodiment of the present invention, a computing device is provided that includes a battery and a connected standby controller. The connected standby controller is programmed to cycle the computing device between a connected standby active state and a connected standby idle state, and set the duration of the connected standby idle state based at least in part on a charge level of the battery.

In accordance with another aspect of an embodiment of the present invention, a computer readable medium having computer readable instructions for performing a method is provided. The method includes managing power consumption of a computing device that has a battery by cycling the computing device between a connected standby active state and a connected standby idle state, and setting the duration of the connected standby idle state based at least in part on a charge level of the battery.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Various embodiments of a computing device and software operable to manage a connected standby state for the computing device are disclosed. In one variant, the computing device has a battery. The computing device is programmed or arranged to cycle between a connected standby active state and a connected standby idle state, and set the duration of the connected standby idle state based at least in part on a charge level of the battery. In an embodiment, the computing device includes a connected standby controller and algorithm code operable to implement the connected standby state control. Additional details will now be described.

In the drawings described below, reference numerals are generally repeated where identical elements appear in more than one figure. Turning now to the drawings, and in particular toFIG. 1is a system block diagram of an exemplary embodiment of a computing device10that includes a processor15, a storage device20, a memory25, a battery30and a network interface35that is operable to provide bi-directional communications with a network device or devices40. In addition, the computing device10includes a connected standby controller (CSB)45which, as described in more detail below, may be a stand alone integrated circuit, part of the processor15or other integrated circuit of the computing device10or be implemented as software in the form of a driver or other type of assemblage of code stored on or off the computing device10. In addition, some optional components include a battery charge sensor50, a case temperature sensor55and an AC power source57. Again the battery charge sensor50may be a discrete integrated circuit or a component of another portion of the computing device such as for example the processor15.

The processor15may be a microprocessor, a graphics processor, a combined microprocessor/graphics processor, an application specification integrated circuit or other type of integrated circuit. The storage device20is a computer readable medium and may be any kind of hard disk, optical storage disk, solid state storage device, ROM, RAM or virtually any other system for storing computer readable media. The storage device20may be populated with plural applications, which are abbreviated APP1, APP2 . . . APPn, as well as an operating system OS and ALGORITHM CODE, which may be designed to implement the selected behavior of the connected standby controller45to be described below. The various pieces of code may be loaded into the memory25as needed. Windows®, Linux, or more application specific types of operating system software may be used or the like.

The network interface35may be a wired or wireless connection and as such may be for example an ethernet connection either wired or wireless or near field communication or some other type of network interface. The network device or devices40may be a computer, a local or cloud server, a smart television, or virtually any other type of electronic device that may benefit from networked communications.

The computing device10may take on a virtually limitless number of form factors. Examples include tablet computers, smart phones, hand held computers, remote controls or others. In one exemplary embodiment depicted pictorially inFIG. 2, the computing device10may be a tablet computer that includes a case60and a screen65. The screen65may be touch enabled or not as desired. The computing device10as a tablet computer may include multiple ports. A few exemplary ports are depicted, such as the USB 3.0 ports70and75, a wired ethernet port80and a video port85. The computing device10may be operable to establish bi-directional wireless communication90with the network device or devices40. The computing device10may include a wireless transmitter that is not visible. Again it should be understood thatFIG. 2simply illustrates one of the many possibilities of a physical implementation of the computing device10.

The behavior of the computing device10depicted inFIG. 1may be modified according to the charge level of the battery30. Still referring toFIG. 1and referring also to the bar chart depicted inFIG. 3, the battery charge level may be subdivided into different operating zones, with different operating rules for each. In this exemplary embodiment, there are four main zones between 100% battery charge and 0% battery charge, namely: (1) an Unconstrained Power Consumption Zone between 100% charge and charge level Q1; (2) a Constrained Power Consumption Zone between charge levels Q1and Q5, with additional optionally-tracked charge levels Q2, Q3and Q4between charge levels Q1and Q5; a Critical Zone between charge levels Q5and Q6; and a Forced Shutdown zone at charge level Q6. When the batter charge level is between 100% and Q1, there is sufficient power in the battery30such that the computing device10may operate in a virtually unconstrained manner. If, however, the charge level falls into the Constrained Power Consumption Zone, then the algorithm code can operate to modify the behavior of the computing device10to conserve power. Part of this modification of the operating characteristics of the computing device10may involve the manipulation of various aspects of the computing device10operation in relation to the entry and exit from a connected standby state as described in more detail below. The tracked charge levels Q2, Q3and Q4provide additional granularity to the power conservation device behavior modifications. There may be fewer or more than the two additional tracked levels Q2, Q3and Q4. When the battery charge level falls to the level Q5and thus Critical Zone, drastic actions may be taken by the computing device10to conserve power. Some of these actions will be explained in detail below. Finally, when the battery charge level reaches Q6, a forced shutdown may result.

The connected standby state will now be described in conjunction withFIG. 1and the timing diagram depicted inFIG. 4. As a connected standby (CSB) platform, the computing device10is operable to be very low power consumption, always-on and always network connected platform that enables communication applications to be always up-to-date, and available with minimum energy. The desired user experience is for the computing device10to be responsive and always available to the user, with users pertinent information, and operate for days without having to recharge the battery30. The computing device10may accomplish the desired user experience with tight power management of all platform compute, graphics, display and other device resources, minimizing power use when resources and devices are not needed, and only making resources available when the user activities need them. From the point of view of the OS, the computing device10in the CSB state appears to be in a sleep or S0 state. In actuality, the computing device10may be in an interruptible loop consisting of an CSB active state S0a and a CSB idle state S0i. Referring toFIG. 4, at some time t1after initial time t0, entry into CSB active state S0a is commenced. After some brief latency t2-T1, the computing device10is operating in CSB active state S0a. During the CSB active state S0a, which may last for a couple of seconds or some other period suitable for the particular computing device involved, any active applications, say APP1, APP2 . . . APPn, can synchronize their structures and thus maintain network associativity. Network associativity is necessary for the user to avoid extra latencies in synching up their network running applications. After synch-up is completed at time t3, the computing device10transitions into (or back into as the case may be) the CSB idle state S0i, with period t4-t3representing the S0i state entry latency. While in the CSB idle state S0i, the display33may be turned off, and some or all of the processor15and the network interface35may power down. Other components may be shut off or otherwise powered down. In the absence of any wake up events, the computing device10remains in the CSB idle state S0i for the period t5-t4. The length of the period t5-t4may be modified in response to battery charge level and other considerations to be described below. One exemplary default value for the CSB idle state S0i duration t5-t4is about 10 seconds. Some exemplary wake up events that will provoke the computing device10to exit the CSB idle state S0i include movement of a system power button, a signal from a wake up timer, connection of a peripheral or connection of a storage medium, such as an SD card. There may be many others. The OS is unaware of the transitions between S0a and S0i, which can reduce OS induced wake up latency. Still referring toFIG. 4, assuming no wake up events, the computing device10begins the transition back to the CSB active state S0a at time t5, and reaches it at time t6with a latency of t6-t5. The cycle repeats through times t7and t8and so on. This cycling between the CSB active state S0a and the CSB idle state S0i will continue so long as there are no wake up events or other activity which require wake up states.

An exemplary process flow for the entry into and exit from the interruptible loop consisting of the CSB active state S0a and idle state S0i just described may be understood by referring now toFIG. 1and to the flow chart depicted inFIG. 5. At step100inFIG. 5, the CSB controller45inFIG. 1looks for a CSB entry opportunity. Software, for example the OS or a plug in or other type of code, makes an identification of device idleness. For example, the OS may make a determination that the network interface35is idle, the applications APP1, APP2 . . . APPn are idle, and there are no incoming data packets from the network device(s)40. If a CSB entry opportunity is not seen at step110then step100is repeated where the CSB controller45continues to look for a CSB entry opportunity. If, however, at step110a CSB entry opportunity is observed by the CSB controller45, then the CSB controller45propagates a CSB hint at step115. The CSB hint at step115is an instruction or set of instructions propagated to various portions of the computing device10to prepare for entry into the CSB active state S0a. After the CSB hint is propagated at step115, the CSB active state S0a is entered at step120. As noted above in conjunction withFIG. 4, the duration of the S0a active state may be about two seconds in an exemplary embodiment, however, this duration may be tailored according to device requirements. At step125, the CSB idle state S0i state is entered. As noted above, in conjunction withFIG. 4, this period corresponds to the period t5-t4inFIG. 4.

While in the CSB idle state S0i at step125, the computing device10may be subject to a variety of wake up events. The management of those wake up events will now be described in conjunction withFIG. 5. At step130the CSB controller45checks for the presence of awake up event. If no wake up event is received then at step135, the CSB controller45determines if the CSB idle state S0i period (e.g., t5-t4inFIG. 4) has elapsed. For example, the CSB idle state S0i period t5-t4may be about 10 seconds in an exemplary embodiment, though other values may be used as well. Indeed, the CSB idle state S0i period may be modified in response to battery charge level, case temperature or other inputs. Lower battery charge levels may prompt the CSB controller45to increase length of the CSB idle state S0i period.

Still referring toFIG. 5, if the CSB idle state S0i period has not elapsed at step135then a return is made to step130to determine if another wake up event has occurred. This loop will continue so long as no wake up events are encountered and so long as the CSB idle state S0i period has not elapsed at step135. However, if at step135the CSB idle state S0i period has elapsed then step120is repeated and the CSB active state S0a is again entered for the period t3-t2shown inFIG. 4and the loop is repeated to step125and130, etc. If, however, at step130a wake up event is encountered then at step140the CSB controller45determines if the wake up event has been masked by the OS or other code associated with the computing device10. If at step140a determination is made that the wake up event is masked then at step145the wake up event is ignored. If, however, it is determined at step140that the wake up event is not masked, then at step150another conditional is encountered. At step150, the number of assertions of the wake up event is counted and if that count exceeds a prior maximum set earlier by the CSB controller45for that particular type of wake up event then at step155, the CSB idle state S0i is exited and the process returns to step100where the CSB controller45continues to look for a CSB entry opportunity. If, however, at step150the CSB controller45determines that the number of assertions of the wake up event has not exceeded the maximum allowed for that event, then the CSB controller45returns to step130polling for the next wake up event. This cycle proceeds continuously while the computing device10is in operation.

The CSB controller45may mask off a particular wake up event based on the charge level of the battery30. For example, if the battery charge level reaches Q2inFIG. 3, the CSB controller45may elect to mask wake up events associated with email push to the computing device10. Similarly, the CSB controller45may elect to mask wake up events associated with a phone finder application when the battery charge level reaches Q3inFIG. 4, but leave battery alarm signals unmasked. The determination of whether or not a particular wake up event is masked and how the system responds to that determination is described in greater detail now in conjunction withFIG. 1and the flow chart depicted inFIG. 6. Step160inFIG. 6begins with the results of the conditional in step140ofFIG. 5. Thus, whether or not the wake up event is masked at step140inFIG. 5, the next determination made by the CSB controller45, at step165, is whether the battery charge level is less than some threshold. This may be a determination for example as to whether or not the battery charge is at level Q1, Q2or Q3shown inFIG. 3. If at step165, the battery charge level is not less than some threshold, then the computing device10at step170proceeds back to step140inFIG. 5. If, however, at step165, the battery level charge is less than some threshold, say less than Q3inFIG. 3, then the CSB controller45may take multiple courses of action. For example, an active application, like APP1, may inform a server to change a mode of interaction at step175. The APP1 may ping the network device(s)40a server or vice versa. In the latter case, the network device(s)40may have to wait longer for the computing device10device to wake if its wake up events are masked or unmasked but not yet numbering above the threshold discussed in conjunction with step150inFIG. 5. In this instance, the application APP1 may inform the network device(s)40of the power state of the computing device10so that network device(s) will know to limit pings, which might otherwise deplete the battery30even further. In addition, a determination is made at step175as to whether or not the OS or the CSB controller45has set a quality of service or QoS for the particular application APP1 that is responsible for the wake up event. Some applications may be entitled to a certain level of quality of service, which is not negotiable, in which case the CSB controller45controller has to obligate. If a QoS has not been set for the particular application APP1 at step175then at step185the wake up event is masked and at step190, a return to step150inFIG. 5is initiated. If, however, at step180that a QoS has been set for the application APP1 then at step195, the wake up event is not masked and at step200a return to step150inFIG. 5is initiated. This cycle of steps inFIG. 6will be repeated again and again. It should be noted that all masked wake up events may eventually be serviced.

Referring again toFIGS. 1, 3 and 4, a temperature of the computing device10may be monitored by, for example the case temperature sensor55, and used as a basis to modify the CSB state entry and exit parameters. Higher temperatures increase power consumption due to leakage. In such cases, it may be appropriate for the CSB controller45to take extra power savings steps, such as changing the charge level thresholds (e.g., Q2or Q3) that trigger changes in the CSB idle state S0i period. The charge level thresholds may be raised for higher temperatures and vice versa. Similarly, the length of the CSB idle state S0i period (t5-t4inFIG. 4) may be lengthened and/or the number of assertions of an unmasked wake up event increased for higher temperatures or vice versa. While case temperature could be used, the temperature measurement used for CSB controller behavior could be made by the processor15or other component of computing device10and of temperatures other than the case temperature.

A given user's usage habits can be taken into account by the CSB controller45so that CSB state entry and exit parameters reflect other than simply default settings. For example, User A might regularly recharge the battery30shown inFIG. 1every 24 hours. User B might take a more haphazard approach and recharge the battery30after three days one week and after six days the next. The ALGORITHM CODE can allow the CSB controller45to keep a rolling average of the time interval between battery recharges. Where the rolling average is, for example, about 24 hours for User A, the CSB controller45can be less aggressive with power savings tactics. The battery charge level thresholds (e.g., Q2or Q3) that trigger changes in the CSB idle state S0i period or other parameters can be lowered since the battery30will likely be recharged in less than a day. For User B, the rolling average of time periods between charges will be longer, and prompt the CSB controller45to be more aggressive in the types of power savings modifications described herein.

Still referring toFIG. 1, the CSB controller45and the ALGORITHM CODE can react differently when the computing device10is operating on DC versus AC power. In DC mode, the CSB controller45will be necessarily more aggressive in employing the savings tactics described herein. However, even on AC power, the CSB controller45can use the same sorts of tactics to reduce energy consumption and perhaps heat generation, albeit with less restrictions on CSB state entry/exit and other parameters.