Energy conservation of battery powered devices

Abstract

Reducing power consumption in an electronic device may include analyzing device usage data associated with the device to predict an extended period during which a user is inactive, the usage data including at least one of historical usage data and a current usage signal; and entering an enhanced low power state by implementing one or more power saving optimization measures that slow, delay, or interrupt one or more normal activities normally performed by the device over at least a portion of the extended period during which the extended user is inactive. The method may also include exiting the enhanced low power state by suspending the one or more power saving optimization measures. Exiting the enhanced low power state may be performed in response to at least one of: user active; specifying a user routine; or the time predicted by the analysis device using the data.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 374,665, filed on September 6, 2022, entitled “Multi-Device Context Synchronization and Applications Thereof,” the disclosure of which is incorporated by reference in its entirety for all purposes. Background Art

[0003] A user may have multiple electronic devices, including, for example, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart watch, etc. In some cases, a user may have multiple instances of such electronic devices. In certain applications, these devices may need to be used in coordination. To this end, information may need to be exchanged between these devices. Although existing technologies can achieve such synchronization, these technologies may face disadvantages related to query frequency, network bandwidth, and other issues as the number of items to be synchronized increases. Summary of the invention

[0004] Disclosed herein is an improved technique for synchronizing data (particularly contextual data) between multiple electronic devices associated with a user, and also disclosed are various exemplary applications that can be implemented through such contextual synchronization.

[0005] A method of reducing power consumption in an electronic device performed by one or more processors of the electronic device may include: analyzing device usage data associated with the device to predict an extended period of user inactivity, the usage data including at least one of historical usage data and current usage signals; and entering an enhanced low-power state by implementing one or more power-saving optimization measures during at least a portion of the extended period of user inactivity, the one or more power-saving optimization measures slowing down, delaying, or interrupting one or more normal activities normally performed by the device. The method may also include: exiting the enhanced low-power state by suspending the one or more power-saving optimization measures. Exiting the enhanced low-power state may be performed in response to at least one of the following: user activity; a specified user routine; or a time predicted by analyzing the device usage data.

[0006] The device usage data may include both historical usage data and current usage signals. The usage data may include synchronization context information from one or more remote devices associated with a user of the device. The synchronization context information may include information corresponding to the user's location, which may be compared with the location of the device to trigger entry into an enhanced low-power state. The one or more power saving optimization measures include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low-power mode, slowing down or postponing background tasks, changing at least one of an audio notification, a visual notification, or a tactile notification provided to the user, and delaying or suppressing a wake-up event of the device.

[0007] A method for reducing power consumption in an electronic device performed by one or more processors of the electronic device may include: analyzing device usage data associated with the device to predict an extended period of user inactivity, the usage data including historical usage data, current usage signals, and contextual information from one or more remote devices associated with a user of the device; and entering an enhanced low-power state by implementing one or more power-saving optimization measures during at least a portion of the extended period of extended user inactivity, the one or more power-saving optimization measures slowing down, delaying, or interrupting one or more normal activities normally performed by the device. The method may also include: exiting the enhanced low-power state by suspending the one or more power-saving optimization measures. Exiting the enhanced low-power state may be performed in response to at least one of the following: user activity; a specified user routine; or a time predicted by analyzing the device usage data.

[0008] The synchronization context information may include information corresponding to the location of the user, which may be compared to the location of the device to trigger entry into an enhanced low power state. The one or more power saving optimization measures include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low power mode, slowing down or deferring background tasks, changing at least one of an audio notification, a visual notification, or a tactile notification provided to the user, and delaying or suppressing a wake-up event of the device.

[0009] The electronic device may include one or more processors, memory, storage, one or more input / output devices, and a power system. The electronic device may also include a usage predictor that analyzes device usage data to predict an extended period of user inactivity, the usage data including at least one of historical usage data and current usage signals; and a power management entity that causes the device to enter an enhanced low-power state by implementing one or more power saving optimization measures during at least a portion of the extended period of user inactivity, the one or more power saving optimization measures slowing down, delaying, or interrupting one or more normal activities normally performed by the device. The usage predictor may include one or more processes running on the one or more processors, and the power management entity may include one or more processes running on the one or more processors. The power management entity may also cause the device to exit the enhanced low-power state by suspending one or more power saving optimization measures. Exiting the enhanced low-power state may be performed by the power management entity in response to at least one of the following: user activity; a specified user routine; or a time predicted by analyzing device usage data.

[0010] The usage data may include synchronization context information from one or more remote devices associated with a user of the device. The synchronization context information may include information corresponding to the location of the user, which may be compared to the location of the device to trigger entry into an enhanced low power state. The one or more power saving optimization measures may include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low power mode, slowing down or postponing background tasks, changing at least one of an audio notification, a visual notification, or a tactile notification provided to the user, and delaying or suppressing a wake-up event of the device.

[0011] The electronic device may include one or more processors, memory, storage, one or more input / output devices, and a power system. The electronic device may also include a usage predictor that analyzes device usage data to predict an extended period of user inactivity, the usage data including historical usage data, current usage signals, and synchronization context information from one or more remote devices associated with a user of the device; and a power management entity that causes the device to enter an enhanced low-power state by implementing one or more power-saving optimization measures during at least a portion of the extended period of user inactivity, the one or more power-saving optimization measures including slowing down, delaying, or interrupting one or more normal activities typically performed by the device. The usage predictor may include one or more processes running on the one or more processors, and the power management entity includes one or more processes running on the one or more processors. The power management entity may also cause the device to exit the enhanced low-power state by suspending one or more power-saving optimization measures. Exiting the enhanced low-power state may be performed by the power management entity in response to at least one of the following: user activity; a specified user routine; or a time predicted by analyzing device usage data.

[0012] The synchronization context information may include information corresponding to the location of the user, which may be compared to the location of the device to trigger entry into an enhanced low power state. The one or more power saving optimization measures may include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low power mode, slowing down or deferring background tasks, changing at least one of an audio notification, a visual notification, or a tactile notification provided to the user, and delaying or suppressing a wake-up event of the device.

[0013] A method for synchronizing context information between multiple electronic devices associated with a user, each device including one or more processors, a communication interface, and a memory or storage device, the method can be performed by at least one of the devices and can include: subscribing to one or more contexts, each context corresponding to one or more attributes, states, or other information corresponding to another of the multiple electronic devices; and receiving periodic updates of one or more subscribed contexts from a data repository shared or distributed among the multiple devices, wherein receiving periodic updates includes pulling periodic updates from the data repository or receiving pushed updates from the data repository. The one or more contexts can each be a key / value pair. The one or more subscribed contexts can include a subset of the contexts available in the data repository. The subscribed contexts can be filtered based on at least one of relevance or importance, wherein the relevance or importance of each context controls the frequency, scheduling, and priority of updates to the context.

[0014] The method may also include: evaluating the subscribed context and one or more conditions on the local device, and performing an action based on the result of the evaluation. The at least one context may correspond to the state of an application on another one or more devices of the multiple electronic devices. In response to an update to the at least one context indicating that the user is using the application on another device, performing an action based on the result of the evaluation may include initiating synchronization of application data associated with the application, which synchronization would have been performed at a later time. The at least one context may include one or more contexts corresponding to the load, thermal state, or power state of other devices in the multiple electronic devices, and performing an action based on the result of the evaluation may include: providing distributed processing tasks to one or more of the other electronic devices in response to one or more contexts corresponding to the load, thermal state, or power state of other devices in the multiple electronic devices.

[0015] A method of synchronizing context information between multiple electronic devices, each device including one or more processors, a communication interface and a memory or storage device, the method can be performed by at least one of the devices and can include: providing periodic updates of one or more contexts associated with the device to a data repository shared or distributed among the multiple devices in response to a pull request for periodic updates from the data repository or a push update to the data repository. The one or more contexts can each include a key / value pair. The contexts can be filtered based on at least one of relevance or importance, wherein the relevance or importance of each context controls the frequency, scheduling and priority of updates to the context.

[0016] A method for synchronizing data between multiple electronic devices associated with a user may include: subscribing to one or more contexts on one of the multiple electronic devices, at least one context corresponding to the state of an application on another of the multiple electronic devices; receiving periodic updates of one or more subscribed contexts from a data repository shared or distributed among the multiple devices; and in response to an update to the at least one context indicating that the user is using the application on another device, initiating synchronization of application data associated with the application, which synchronization would have been performed at a later time. The one or more subscribed contexts may include at least one context corresponding to the location of one or more of the multiple electronic devices. A communication interface for synchronizing application data may be selected based at least in part on the location of the at least one context corresponding to the one or more of the multiple electronic devices. The method may also include: if the at least one context corresponding to the location of one or more of the multiple electronic devices indicates that the user is not using the application on one of the devices, delaying synchronization of application data to the device in the multiple electronic devices.

[0017] A method for performing distributed processing among multiple electronic devices associated with a user may include: on one device of the multiple electronic devices, subscribing to one or more contexts corresponding to the load, thermal state, or power state of other devices in the multiple electronic devices; receiving periodic updates of one or more subscribed contexts from a data repository shared or distributed among the multiple devices; and providing distributed processing tasks to one or more of the other electronic devices in response to one or more contexts corresponding to the load, thermal state, or power state corresponding to the other devices in the multiple electronic devices.

[0018] The one or more subscribed contexts may include at least one context corresponding to the load of one of the other electronic devices, and providing distributed processing tasks to one or more of the other electronic devices in response to the one or more contexts may also include: if the load is below a threshold, assigning the distributed processing task to the other electronic device; and if the load is above a threshold, not assigning the distributed processing task to the other electronic device.

[0019] The one or more subscribed contexts may include at least one context corresponding to a thermal state of one of the other electronic devices, and providing distributed processing tasks to one or more of the other electronic devices in response to the one or more contexts may also include: if the thermal state is below a threshold, assigning the distributed processing task to the other electronic device; and if the thermal state is above a threshold, not assigning the distributed processing task to the other electronic device.

[0020] The one or more subscribed contexts may include at least one context corresponding to the AC power connection status of one of the other electronic devices, and providing distributed processing tasks to one or more of the other electronic devices in response to the one or more contexts may also include: if the other electronic device is connected to an AC power source, assigning the distributed processing task to the other electronic device; and if the other electronic device is not connected to an AC power source, not assigning the distributed processing task to the other electronic device.

[0021] The one or more subscribed contexts may include at least one context corresponding to a battery charging status of one of the other electronic devices, and providing distributed processing tasks to one or more of the other electronic devices in response to the one or more contexts may also include: if the charging status is higher than a threshold, assigning the distributed processing task to the other electronic device; and if the charging status is lower than the threshold, not assigning the distributed processing task to the other electronic device.

[0022] An electronic device may include a power system including a battery and a processor programmed to: detect connection of an external power source to the electronic device; determine an estimated disconnection time at which the external power source is expected to be disconnected from the electronic device based at least in part on synchronization context data from one or more other devices associated with a user of the device; identify one or more expected battery charging intervals prior to the estimated disconnection time; and operate the power system to charge the battery from the external power source during the identified one or more expected battery charging intervals. The processor may be programmed to determine the estimated disconnection time using a machine learning model.

[0023] The synchronization context data may provide an indication of the user's location. If the synchronization context data indicates that the user is in a different location from the device, the estimated disconnection time may be determined based at least in part on an expected time for the user to return to the location of the device. One or more desired battery charging intervals may be selected to reduce the time required to fully charge the battery. The processor may also be programmed to operate the power supply system to charge the battery from the external power source during the identified one or more desired battery charging intervals by adjusting the battery charging rate to reduce the time required to fully charge the battery.

[0024] The electronic device may further include a display, and the processor may further be programmed to communicate information about the one or more desired battery charging intervals to a user via the display. The electronic device may further include an input device, and the processor may further be programmed to receive user input about charging via the input device.

[0025] A method of operating an electronic device performed by a processor of the electronic device may include: detecting a connection of an external power source to the electronic device; determining an estimated disconnection time at which the external power source is expected to be disconnected from the electronic device based at least in part on synchronization context data from one or more other devices associated with a user of the device; identifying one or more expected battery charging intervals prior to the estimated disconnection time; and operating the power system to charge the battery from the external power source during the identified one or more expected battery charging intervals. Determining the estimated disconnection time may also include using a machine learning model.

[0026] The synchronization context data may provide an indication of the user's location. If the synchronization context data indicates that the user is in a different location from the device, the estimated disconnection time may be determined based at least in part on the expected time for the user to return to the location of the device. One or more desired battery charging intervals may be selected to reduce the time required to fully charge the battery. The method may also include adjusting the battery charging rate to reduce the time required to fully charge the battery. The method may also include communicating information about the one or more desired battery charging intervals to the user via a display of the electronic device. The method may also include receiving user input regarding charging via an input of the electronic device.

[0027] An electronic device may include a power system including a battery and a processor programmed to: receive synchronization context data from one or more other devices associated with a user of the device; determine one or more battery charging intervals based at least in part on the synchronization context data; and operate the power system to charge the battery from an external power source during the identified one or more battery charging intervals. The processor may be programmed to determine the one or more battery charging intervals using a machine learning model.

[0028] The synchronization context data may provide an indication of the user's location. If the synchronization context data indicates that the user is in a different location from the device, the one or more battery charging intervals are determined based at least in part on an expected time for the user to return to the location of the device. The one or more expected battery charging intervals may be selected to reduce the time required to fully charge the battery. The processor may also be programmed to operate the power supply system to charge the battery during the one or more battery charging intervals by adjusting the battery charging rate to reduce the time required to fully charge the battery. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 A block diagram of an electronic device is illustrated.

[0030] Figure 2 Multiple devices synchronizing context information are illustrated.

[0031] Figure 3A more detailed view of multiple device synchronization context information is illustrated.

[0032] Figure 4 Multiple devices are illustrated synchronizing context information over various communication links.

[0033] Figure 5 The device is illustrated to receive and transmit context information.

[0034] Figure 6 An optimized battery charging routine for an electronic device is illustrated.

[0035] Figure 7 A flow chart illustrating an optimized battery charging routine for an electronic device for regulating battery charging is illustrated.

[0036] Figure 8 An electronic device that communicates parameters of an optimized battery charging routine to a user is illustrated.

[0037] Fig. 9 A flow chart / block diagram illustrating an enhanced power save mode for an electronic device.

[0038] Fig.10 A flow chart / block diagram for entering an enhanced power saving mode is illustrated.

[0039] Fig.11 A flow chart / block diagram for exiting an enhanced power save mode is illustrated. DETAILED DESCRIPTION

[0040] In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding of the disclosed concepts. As part of this description, some of the drawings in the drawings of the present disclosure represent structures and devices in block diagram form for simplicity. For the sake of clarity, not all features of actual implementations are described in the present disclosure. In addition, the language used in the present disclosure is selected for readability and instructional purposes and has not been selected to describe or limit the disclosed subject matter. Instead, the attached claims are intended for this purpose.

[0041] Various embodiments of the disclosed concepts are illustrated by way of example, and are not limited to individual drawings, in which similar reference numerals indicate similar elements. For simplicity and clear illustration, reference numerals are repeated in different drawings to indicate corresponding or similar elements, where appropriate. In addition, many specific details are shown in order to provide a full understanding of the specific implementation described herein. In other cases, methods, procedures, and components are not described in detail to avoid blurring the related functions described. Mentioning "one", "a kind of" or "another" embodiment in this disclosure is not necessarily the same or different embodiments, and this means at least one. A given drawing may be used to illustrate more than one embodiment or more than one type of features of the present disclosure, and all elements in the drawings may not be required for a given embodiment or type. When provided in the drawings, the reference numerals refer to the same element throughout several drawings, but they may not be repeated in each drawing. Unless otherwise specified, the drawings are not drawn to scale, and the proportions of certain components may be enlarged to better illustrate the details and features of the present disclosure.

[0042] Introduction

[0043] Figure 1 1 is a block diagram of an electronic device 100 according to an embodiment of the present disclosure. The electronic device 100 may include one or more processors 101 (for convenience, collectively referred to herein as a single processor, which may be implemented as any suitable form of processing circuit), a memory 102, a non-volatile storage device 103, a display 104, an input device 105, an input / output (I / O) interface 106, a network interface 107, a power supply system 108, and the like. Figure 1 The various functional blocks shown may include hardware elements (including circuits), software elements (including machine executable instructions), or a combination of hardware and software elements (which may be referred to as logic). Processor 101, memory 102, non-volatile storage device 103, display 104, input device 105, input / output (I / O) interface 106, network interface 107 and / or power system 108 may each be directly or indirectly communicatively coupled to each other (e.g., through or via another component, a communication bus, a network, etc.) to send and / or receive data between each other. It should be noted that Figure 1 This is merely one example of a particular implementation and is intended to illustrate the types of components that may be present in electronic device 100 .

[0044] For example, electronic device 100 may include any suitable computing device, including a desktop computer or a laptop / notebook computer (such as the Apple Computer available from Apple Inc. of Cupertino, California). MacBook mini or Mac ), a portable electronic device or a handheld electronic device such as a wireless electronic device or a smart phone (such as available from Apple Inc. in Cupertino, California ), tablet computers (such as those available from Apple Inc. in Cupertino, California ), wearable electronic devices (such as the Apple ) and other similar devices.

[0045] Figure 1 The processor 101 and other related items in the embodiment may be completely embodied by hardware or by hardware programmed to execute appropriate software instructions. Figure 1 Other related items in the electronic device 100 may be single independent processing modules, or may be fully or partially combined in any of the other elements in the electronic device 100. The processor 101 may be implemented with a combination of a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, a gated logic, a discrete hardware component, a dedicated hardware finite state machine, or any other suitable entity that can perform calculations or other manipulations of information. The processor 101 may include one or more application processors, one or more baseband processors, or both, and perform various functions described herein.

[0046] exist Figure 1 In the electronic device 100, the processor 101 may be operably coupled to the memory 102 and the non-volatile storage device 103 to execute various algorithms. Such programs or instructions executed by the processor 101 may be stored in any suitable article including one or more tangible computer-readable media. The tangible computer-readable medium may include the memory 102 and / or the non-volatile storage device 103, individually or collectively, to store instructions or routines. The memory 102 and the non-volatile storage device 103 may include any suitable article for storing data and executable instructions, such as random access memory, read-only memory, rewritable flash memory, hard drive, and optical disk. In addition, the program (e.g., operating system) encoded on such a computer program product may also include instructions that can be executed by the processor 101 to enable the electronic device 100 to provide various functions.

[0047] In certain embodiments, the display 104 can facilitate a user viewing images generated on the electronic device 100. In some embodiments, the display 104 can include a touch screen, which can facilitate user interaction with a user interface of the electronic device 100. In addition, it should be understood that in some embodiments, the display 104 can include one or more liquid crystal displays (LCDs), light emitting diode (LED) displays, organic light emitting diode (OLED) displays, active matrix organic light emitting diode (AMOLED) displays, or some combination of these and / or other display technologies.

[0048] The input device 105 of the electronic device 100 can enable a user to interact with the electronic device 100 (e.g., pressing a button to increase or decrease the volume level). As with the network interface 107, the I / O interface 106 can enable the electronic device 100 to interact with various other electronic devices. In some embodiments, the I / O interface 106 may include an I / O port for a hardwired connection for charging and / or content manipulation using a standard connector and protocol such as the Lightning connector provided by Apple Inc. of Cupertino, California, a universal serial bus (USB), or other similar connectors and protocols. The network interface 107 may include, for example, one or more interfaces for a personal area network (PAN) such as an ultra-wideband (UWB) or Network; Local Area Network (LAN) or Wireless Local Area Network (WLAN), such as one of the IEEE 802.11x family of protocols (e.g. ) networks; and / or wide area networks (WANs), such as any standards associated with the 3rd Generation Partnership Project (3GPP), including, for example, 3rd Generation (3G) cellular networks, Universal Mobile Telecommunications System (UMTS), 4th Generation (4G) cellular networks, Long Term Evolution (LET), and / or 4G cellular networks. Cellular network, Long Term Evolution Licensed Assisted Access (LTE-LAA) cellular network, 5th generation (5G) cellular network and / or new radio (NR) cellular network, 6th generation (6G) or super 6G cellular network, satellite network, non-terrestrial network, etc. Specifically, the network interface 107 may include, for example, one or more interfaces of cellular communication standards of 5G specifications for using and / or implementing frequency ranges for wireless communication including millimeter wave (mmWave) frequency ranges (e.g., 24.25 gigahertz (GHz)-300GHz). The network interface 107 of the electronic device 100 may allow communication through the aforementioned networks (e.g., 5G, Wi-Fi, LTE-LAA, etc.).

[0049] The network interface 107 may also include, for example, one or more interfaces for: a broadband fixed wireless access network (eg, ), mobile broadband wireless network (mobile ), asynchronous digital subscriber line (e.g., ADSL, VDSL), digital video terrestrial broadcasting Network and its extension DVB handheld equipment Networks, ultra-wideband (UWB) networks, alternating current (AC) power lines, etc.

[0050] The power system 108 of the electronic device 100 may include any suitable power source, such as a rechargeable battery (e.g., a lithium-ion or lithium-polymer (Li-poly) battery) and / or a power converter, including a DC / DC power converter, an AC / DC power converter, a power adapter (which may be external), etc.

[0051] Context Synchronization

[0052] Figure 2 Multiple devices are illustrated synchronizing context information. These devices may all be associated with a particular user, such as a desktop computer 100a, a laptop or notebook computer 100b, a tablet computer 100c, a smart phone 100d, and / or a smart watch 100e. In addition, other electronic devices may also be included, such as wireless headphones, stylus, keyboard, mouse, trackpad or other input peripherals, smart home devices including hubs, sensors, actuators, etc. These various devices may exchange or synchronize data between them, which may be used in a variety of ways to enhance the user's experience with these devices. As described in more detail below, the data may include one or more "contexts," which may be key / value pairs that describe specific attributes, states, or other information available on one device that may be related to one or more other devices. These contexts may be synchronized between devices in a variety of ways as described in more detail below. Figure 2In the example of , these contexts are shown as being exchanged through the cloud 207. Various specific implementations of such systems are described in more detail below, but may include any appropriate combination of shared or distributed data repositories and communication paths for exchanging context data. In the case where the devices are in the same location (e.g., smart phone 100d and smart watch 100e), the exchange may be performed through a local communication channel, such as Bluetooth, WiFi, or wired LAN (if available). For devices that are not in the same location, such as a laptop computer 100b or tablet computer 100c that a user brings to a coffee shop compared to a desktop computer 100a left at home or at work, when the devices are not in the same location, communication may be performed through the Internet or other WAN connections. Once the user returns and the device becomes in the same location, the remote device that previously communicated through the Internet or other WAN connection may switch to a more local connection as needed. In other cases, two devices associated with a user may never be in the same location, such as a home desktop computer and a work desktop computer, so they may always rely on the Internet or WAN communication.

[0053] Figure 3 A more detailed view of multiple device synchronization context information is illustrated. More specifically, Figure 3 Three devices 300a, 300b and 300c are illustrated, which exchange information via data repository 320, but more or less devices can be used if applicable. In some embodiments, data repository 320 can be a shared centralized database accessible to each device. This shared centralized database can be hosted on a server accessible to each device, or can be stored in a shared device that can be considered as a primary device. Even in the case of a shared centralized database, each device using this shared centralized database for context synchronization as described herein can still locally cache all or part of this shared centralized database, for example, to improve performance or reliability, adapt to various connections with different bandwidths, power consumption or other properties, etc. However, if the cached data is different from the data in the shared centralized data repository, it is considered that this centralized database is "authoritative". In other cases, shared data repository 320 can be implemented as a distributed database, in which each device maintains a copy of the entire database or the part related to this device of the database. In this case, a mechanism for which copy of a particular entry for arbitration has "authoritativeness" can be provided. For example, each entry can be designated as having one and only one owner, so that the owner's copy can be considered authoritative among any distributed copies. As between two non-owners, other mechanisms can be used to determine which copy is authoritative, such as the most recently updated copy, etc. If applicable, any of a variety of such techniques can be used unless inconsistent with the teachings described herein.

[0054] Go to Figure 3 A device including multiple clients, multiple contexts, and multiple subscriptions, each of which is described in more detail below. For illustrative purposes, each device has a slightly different configuration of these items. These configurations are provided as examples, and multiple combinations, permutations, and variations of these configurations are also possible. First, a device (e.g., device 300a) may include multiple "clients" 311a, 312a, 313a. More or fewer clients may be provided. A client may be a source or sink of one or more contexts. A client may include a process or application running on the device that uses information associated with the context.

[0055] Each client may be associated with one or more contexts. For example, device 300a includes three contexts 314a, 315a, and 316a associated with clients 311a, 312a, and 313a, respectively. As described in more detail below, a context is data generated or used by a client. A context may be used by multiple clients on the same device, and / or by one or more clients on one or more different devices, as more clearly illustrated by the examples discussed below. A context may, but need not, include a key / value pair representing a state or condition.

[0056] Subscription can be a mechanism for receiving context from or delivering context to clients on a shared data repository and / or other devices. For example, device 300a includes three subscriptions 317a, 318a, and 319a associated with contexts 314a, 315a, and 316a, respectively. Subscription can manage delivery to and from clients, or optionally in some embodiments, only manage delivery to clients, where context is delivered to a shared data repository 320 by the client directly or through another device. In either case, subscription can be based on a push action or a pull action, in which a client as a source of context transmits or "pushes" the context to one or more clients, and in a pull action, a client as a consumer of context retrieves or "pulls" the context from a data repository or optionally another client and / or device.

[0057] Returning to the example of device 300a, clients 311a, 312a, and 313a may correspond to various applications or processes running on device 300a. Client 311a may be the source of context 314a associated with subscription 317a. Changes in the state or condition associated with context 314a may cause client 311a to provide updated context to shared data repository 320 via subscription 317a (or via other suitable arrangements). Shared data repository 320 may be a centralized shared data repository or a distributed shared data repository, as described above, respectively, or may be a mixture of these data repository types, combining any characteristics of any type suitable for a given application. In other words, data repository 320 may reside anywhere along the continuum from a completely centralized data repository to a completely distributed data repository. Similarly, subscriptions may also be stored in a centralized or distributed manner. Centralized storage subscriptions may provide the ability to filter requests on the server side, which may be beneficial in some cases for reducing processing load and / or network bandwidth consumption on a local device. In any case, subscription 317a may communicate with the shared data source via communication link 320a, which may be any of the exemplary communication links discussed above or any other suitable type of communication link.

[0058] Distributed processing can advantageously allow subscriptions to express complex remote queries across a set of sensors / data on any given device. The subscription / query can be evaluated on the device as conditions change, and the device can use any available / appropriate communication channel to push updates related to the query / condition associated with the subscription directly to interested devices. Thus, in at least some cases, subscriptions can be distributed and evaluated directly in the private environment of each respective device rather than in a central location. Evaluating subscriptions on each respective device can provide privacy advantages, allowing context values ​​to be transmitted end-to-end encrypted between devices, meaning they cannot be read by any intermediate service provider.

[0059] Client 312a can be a sink or consumer of context 315a associated with subscription 318a. Client 312a can receive updates of context 315a from shared data repository 320 via subscription 318a. Subscription 318a can communicate with shared data source via communication link 320a. Client 313a can be a source and consumer of context 316a associated with subscription 319a. Client 313a can receive updates of context 316a from shared data repository 320 via subscription 319a. Subscription 319a can communicate with shared data source via communication link 320a.

[0060] Turning to the example of device 300b, clients 311b, 312b, and 313b may correspond to various applications or processes running on device 300b. Client 311b may be the source of context 314b associated with subscription 317b. Client 312b may be the sink or consumer of context 315b also associated with subscription 317b. Client 313b may be the source and consumer of context 316b also associated with subscription 317b. Subscription 317b is therefore different from subscription 317a-319a discussed above about device 300a, because a single subscription is associated with multiple contexts 314b, 315b, and 316b. A change in the state or condition associated with context 314b may cause client 311b to provide updated context to shared data repository 320 via subscription 317b (or via other suitable not). Client 312b may receive updates of context 315b from shared data repository 320 via subscription 317b. Client 313b may provide or receive updates of context 316b from shared data repository 320 via subscription 317b. Subscription 317b may communicate with the shared data source via communication link 320b, which may be any of the exemplary communication links discussed above or any other suitable type of communication link.

[0061] Turning to the example of device 300c, clients 311c, 312c, and 313c may correspond to various applications or processes running on device 300c. Client 311c may be the source of context 314c associated with subscription 317c. Client 311c may also be a consumer of context 315c that may be associated with different subscriptions 318c. Client 312c may be the sink or consumer of context 315c that is also associated with subscription 318c. Client 313c may be a consumer of context 315c, and a source and consumer of context 316c that may also be associated with subscription 318c. Thus, a client may be associated with more than one context, and a single context may be associated with more than one client. Similarly, more than one context may be associated with a subscription, and in some cases, different applications may have different subscriptions to substantially the same context. Subscriptions 317b and 318c may communicate with a shared data source via a communication link 320c, which may be any one of the exemplary communication links discussed above or any other suitable type of communication link. Each of the above-described device, client, context, subscription configurations is exemplary, and various combinations, permutations, or variations of these arrangements may be provided as appropriate in a given application.

[0062] Figure 4Multiple devices are illustrated synchronizing context information over various communication links. Device 1 may be a smart phone 100d. Device 2 may be a notebook / laptop computer 100b. Device 3 may be a tablet computer 100c. Device 4 may be a desktop computer 100a. As in the above examples, this combination is merely exemplary, and any combination of more, fewer, and / or different devices may be provided.

[0063] exist Figure 4 In the example shown, each device has six contexts, which can be shared with other devices. In some applications, a device may have more or fewer contexts, which may differ between different devices, etc. In the illustrated example, each context includes a key / value pair, typically identified as a "context key" and a "context value," respectively. However, other data structures and value types may also be used for specific applications.

[0064] The six exemplary contexts include a "Device Load" context, which may correspond to the workload of a device, such as CPU or GPU utilization or other performance metrics. The value of this context may be expressed as a percentage, or other suitable data type that conveys the required information of an application that may rely on the context with sufficient accuracy. Alternatively, it may be expressed as low, medium, high, or any other representation suitable for the application. For example, in the illustrated example, device 1 has a "Device Load" state of 10%, corresponding to relatively low utilization. Device 2 has a "Device Load" state of 85%, corresponding to relatively high utilization. Devices 3 and 4 have a "Device Load" of 0%, corresponding to idle devices.

[0065] The "thermal state" context may be a binary value indicating whether the device is above or below a corresponding thermal threshold (i.e., whether the thermal state is "high" or "normal"). Alternatively, the value may be expressed as a temperature, percentage, or other suitable data type. In the illustrated example, device 1 has a "normal" thermal state, which is associated with the relatively low "device load" context for that device discussed above. Device 2 has a "high" thermal state, which is associated with the high "device load" context for that device discussed above. Devices 3 and 4 have a "normal" thermal state, which is associated with the "device load" context for those devices discussed above.

[0066] The "location" context can store values ​​corresponding to known locations, such as the user's "work" or "home", as illustrated in the figure. Alternatively, the "location" context can store locations in other formats, such as latitude / longitude, address, etc. Devices 1 and 2 have a "work" location context, indicating that the user brought these devices to work. Devices 3 and 4 have a "home" location context, indicating that the user left these devices at home when working with devices 1 and 2. This example of the location difference between devices 1 and 2 and devices 3 and 4 also illustrates the potential differences in the communication path for context synchronization. More specifically, because devices 1 and 2 are in the same location (that is, the user's phone 100d and laptop computer 100b are both at work), they can exchange context with each other through a direct local link 425 such as a Bluetooth, WiFi or LAN connection. Similarly, because devices 3 and 4 are in the same location (that is, the user's desktop computer 100a and tablet computer 100c have been left at home), they can exchange context with each other through a direct local link 427. However, in order for device 1 or device 2 to communicate with device 3 or device 4, the Internet or WAN link 426 must be used. Although some devices can communicate directly locally, in some cases, even co-located devices may choose to communicate over the Internet or WAN connection to convey certain context or to communicate with certain co-located devices.

[0067] The "AppX state" context may indicate the state of a particular application on a device, such as whether the corresponding application (i.e., application "X") is open or closed. In other cases, the application state may indicate whether the application is installed or include information such as a version number or other information related to the application. In the illustrated example, device 1, device 2, and device 4 have an AppX state of "open", indicating that application "X" is open on these devices, while device 3 has an AppX state of "closed", indicating that application "X" is closed on the device.

[0068] The battery SoC (“state of charge”) state may indicate a percentage value corresponding to the battery charge state. Alternatively, the context may be provided as a voltage, high / medium / low indication, or other suitable state representation. In some cases, additional states or additional values ​​of the battery SoC state may be provided to indicate whether the battery is charging, discharging, or in a stable state where it is no longer charging or discharging. In other cases, a client using the “battery SoC” context may infer the charging, discharging, or stable state by looking at the SoC values ​​over a period of time. In the illustrated example, device 1 has a battery SoC of 75% (mostly charged), device 2 has a battery SoC of 35% (mostly discharged), device 3 has a battery SoC of 35% (mostly discharged), and device 4 has a battery SoC state of N / A (not applicable) because desktop computers typically do not have system batteries. In some cases, a not applicable context may have a null value, not applicable, or other similar values. In other cases, a device may not have a context that is not applicable to the device.

[0069] Finally, the context may include an "AC power" context, indicating whether the device is currently connected to AC power. In the illustrated example, device 1 has an AC power state of "false", indicating that it is not connected to AC power. Devices 2 and 3 have an AC power state of "true", indicating that they are connected to AC power.

[0070] The above contexts and "context key" / "context value" pairs are provided as illustrative examples corresponding to the following discussion of certain exemplary applications of the context synchronization systems and techniques described herein. These examples of both contexts and their applications should not be construed as limiting, as the example applications may rely on additional or alternative contexts not discussed herein, and numerous other contexts and applications may be developed based on the teachings contained herein.

[0071] Figure 5 The device receives and transmits context information. Figure 5, device B may transmit unfiltered contexts (box 535). These contexts may be transmitted to a shared data repository represented by cloud 207, which, as discussed above, may be a centralized shared data repository, a distributed shared data repository, or a data repository combining aspects of both centralized and shared. Unfiltered contexts are those contexts to which updates may be transmitted to the shared data repository regardless of the state of the device. In box 535, device B may check whether there are conditions for transmitting the filtered contexts. Based on specific conditions, context transmission may be filtered for various reasons. For example, some contexts may be important or relevant enough, so they should always be processed immediately. Other contexts may be important, but not relevant at a particular time, so their transmission may be suppressed or postponed until they become more relevant. Other contexts may be less important, so their transmission may be delayed or otherwise prioritized for transmission at a later time. For example, some contexts may not be relevant and / or important enough for "waking up" a "sleeping" receiving device so that the receiving device can process them immediately. ("Sleep" in this context means being placed in a low-power state in which some or all processing functions may be suspended to reduce power consumption. Similarly, "wake up" in this context means exiting a sleep state, thereby increasing power consumption.) In some cases, it may be preferred to transmit updates for such contexts later, when the receiving system is awakened for some other reason (e.g., other user interaction). The conditions regarding both relevance and importance may vary according to each particular context. For example, if a device is left at home and the user is at another location, many or all of its contexts may be designated as less relevant or less important because the user is less likely to interact with the device. As another example, contexts associated with background tasks may be deprioritized relative to other tasks and therefore transmitted less frequently or after more important or more relevant tasks. In general, each context may have an associated relevance and an associated importance, which may control the frequency with which updates are transmitted for each context, their scheduling, and their prioritization.

[0072] exist Figure 5, device A may receive contexts from a shared data repository represented by cloud 207. Device A may both receive context updates from the shared data repository and transmit context updates to the shared data repository, as described with respect to device B. Similarly, device B may both transmit context updates to the shared data repository and receive context updates from the shared data repository, as described below with respect to device A. In box 531, device A may subscribe to one or more contexts. These contexts may be contexts related to the device, and the subscribed contexts may include all or only a subset of the contexts available in the shared data repository, including all or only a subset of the contexts corresponding to each other device in the shared data repository. In addition, the subscription of each context may be customized according to importance and relevance information. Therefore, the subscription may be configured to update more important contexts more frequently, while updating less important contexts at a lower frequency. Similarly, the subscription may be configured to delay, reduce priority, or suspend updates to contexts that are not currently relevant to the device. As with the transmission of context updates described above, context importance can be used to prioritize updates so that more important information is received and updated more frequently, and resources such as battery life, network bandwidth, etc. are spent on these more important contexts. Context relevance can be used similarly, in that currently more relevant contexts can be received or synchronized more frequently, and when circumstances change making these contexts less relevant, their retrieval / synchronization frequency can be reduced or even suspended, again making more efficient use of limited resources such as energy usage, network bandwidth, processing power, etc.

[0073] In box 532, device A may receive a subscribed context from a shared data repository. As described above, the reception may be dynamically changed and prioritized based on changing conditions. In addition, a process running on device A (such as a client of a subscribed context) may evaluate both context and condition (box 533) to determine whether an action should be performed based on the result of the evaluation (box 534). In other words, the synchronization context may be optionally evaluated in conjunction with additional local conditions to determine whether, when, and how to perform the desired action. Such an action may involve one or more background tasks running on the device, and / or one or more user-oriented tasks on the device. Therefore, the above-mentioned context synchronization framework may be used to provide various enhanced user experiences given below as examples. These examples are merely illustrative, and many other applications of the context synchronization framework may also be implemented using these same principles.

[0074] Application Data Synchronization

[0075] Main references Figure 4 and Figure 5, an improved application data synchronization technology can be provided by using the above-mentioned context framework synchronization technology. As an example, a user can take multiple photos and / or videos using a mobile device such as a smart phone 100d. In addition, the user may have configured his device so that photos added to the photo library on one device are synchronized to other devices. In some cases, such photo synchronization may require the transmission of a relatively large amount of data. Therefore, a mobile device such as a mobile phone may be configured to delay uploading newly taken photos until the phone is connected to a WiFi network rather than a cellular data network to avoid consuming cellular data that may be more limited. Similarly, sending large amounts of data over cellular, WiFi or other data networks may consume a lot of energy. Therefore, a mobile device such as a mobile phone can be configured to delay uploading newly taken photos until the phone is plugged into an AC power source, or upload is allowed only when the phone battery level exceeds a certain level.

[0076] However, in some cases, the above-mentioned delay in uploading newly taken photos from the mobile phone may result in a poor user experience. For example, suppose a user takes a number of photos using a mobile device (such as a mobile phone), but then wants to view or edit these photos on another device (such as a laptop computer 100b that is also carried with him). In this case, when the user opens the photo processing application on the laptop computer 100b, a context such as "AppPhoto state" may change from "off" to "on". This context update may be passed to the mobile phone. When the photo processing application on the mobile phone receives notification that the user is trying to view photos on the laptop computer via the updated context, the mobile phone photo application may re-prioritize the discretionary workload to give it a higher priority and initiate the upload of the newly taken photos, even though such upload may be delayed or inhibited due to poor network connectivity, battery charge status, or other conditions present on the mobile phone.

[0077] The above-described context synchronization framework may allow for more sophisticated variations of the above-described application data synchronization techniques. Assume that in the same scenario described above (newly taken photos on the user's phone 100d), the user has also opened a desktop computer and is running a photo application. Based solely on the above logic, the desktop computer's "AppPhoto State" context of "Open" may itself trigger the upload of photos from the user's phone 100d. However, in this case, there are other contexts that indicate that this is not necessarily the action desired by the user. For example, the "Location" context of the desktop computer 100a has a value of "Home", while the "Location" context of the phone 100d has a value of "Work". Similarly, the "Device Load" context of the desktop computer 100a has a value of 0%, indicating that the device is idle. Therefore, it can be inferred that even though the photo processing application on the desktop computer may be open, the user is not currently there, so there is no urgent need to upload the newly taken photos (there is no sign of photo-related activity from the laptop computer 100b, which is located at the user's location inferred from the phone location and has a device load indicating interactive use). In some embodiments, because the user is not currently using the application and / or device, the "AppX Status" context update from the desktop computer 100a may be deprioritized or suppressed based on its lower importance or relevance.

[0078] The above-mentioned application data synchronization technology need not be limited to newly taken photos or photo-related applications. Similar logic can be applied to other user-oriented applications, including productivity applications such as word processors, spreadsheets, presentation software, etc., so as to allow the underlying data files to be synchronized immediately when the corresponding application is opened on another device, even if the synchronization may be delayed, deprioritized or suppressed due to other conditions. Similarly, the logic can be applied to media consumption software to provide synchronization of the media being consumed and / or the location in the media, such as timestamps in video or audio files, bookmarks in e-books, websites or articles, progress status in games, etc. In the most general sense, data synchronization can be triggered by a context update indicating that the corresponding application has been opened on another device. However, the client subscribing to the context can adopt additional logic, including evaluating other synchronization contexts and local conditions to determine whether to perform an action based on these contexts and conditions. In addition, the context itself can have synchronization priority sorting, delays, suppression, etc. based on relevance and / or importance. In addition, although there are existing application data synchronization schemes, these schemes rely on synchronization logic integrated with specific applications. In other words, each client relies on its own internal logic and data repository to perform synchronization tasks. In contrast, the context synchronization techniques described above may provide a more generally available synchronization framework that may allow multiple client applications to share context data but process the context data differently according to their own internal logic and priorities, thereby providing an appropriate experience for the user.

[0079] Distributed Data Processing

[0080] Another application of the above-mentioned context synchronization framework is distributed data processing. An example of such distributed processing can be based on the above scenario again, that is, a user takes a plurality of new photos using a mobile device such as a phone 100d. Distributed processing need not be limited to newly taken photos, or even more generally to photos, which is only used as an example for ease of discussion. In this example, the user may have a photo management application that is configured to analyze newly added photos to identify subjects such as people, places, etc., and automatically group the photos accordingly. The analysis of the newly added photos may be based on metadata included in the photos, such as GPS data, camera data, etc., or may be based on analysis of the photo information itself, such as machine learning processing of image data to identify the subject of the photo. In some cases, such processing may be relatively intensive in terms of processing requirements, and / or may be accelerated by using dedicated hardware (such as a graphics processing unit (GPU) or image processing unit (IPU) that may be present on another device). In some cases, even if there is suitable hardware on the local device, energy usage or completion time constraints may indicate that it is possible or desirable to assign part of the task to one or more other devices.

[0081] Go to again Figure 4 and Figure 5, assuming that the user has taken the photos that need to be analyzed using the phone 100d via distributed data processing. However, it is assumed that each of the laptop computer 100b, the tablet computer 100c, and the desktop computer 100a also includes suitable hardware and software to perform the required analysis in the same manner. By evaluating the specific context of each device, the phone 100d can request other devices to help with the analysis in a timely manner. Alternatively, each of the other devices can evaluate certain contexts to determine whether the device should participate in the queue processing without a specific request from the device 100d. Many contexts can be used alone, or more likely in various combinations, to facilitate distributed processing tasks. For example, the desktop computer 100a has a low device load, a normal thermal state, and is connected to an AC power source. Each of these contexts indicates that the desktop computer 100a can contribute a large amount of computing resources to the distributed processing task (photo analysis). Similarly, the tablet computer 100c also exhibits similar properties and may therefore also contribute. However, if the AC power context of tablet computer 100c is "false", indicating that it is not connected to AC power, then it may not be suitable for participating in the distributed processing task because this will further drain the battery beyond the already low 35% charge state. Similarly, laptop computer 100b exhibits high "device load" and "thermal state", each of which indicates that it may not be suitable for participating in the distributed data processing task. However, if any of these parameters are transformed or updated to a context value indicating that device 2 is suitable for participating in the distributed data processing task, then such device may participate in the task when such conditions occur.

[0082] Distributed data processing tasks may be but not necessarily be background tasks. In some cases, another device may be required to participate in the distributed task, which is a foreground or user / user interaction-oriented task. For example, playing a game or video editing task on a device with relatively limited graphics processing capabilities may shift graphics-intensive processing to another device with a more powerful GPU. This may be particularly advantageous when the devices are in the same location or have a relatively high network bandwidth between them. Additional context related to device capabilities, network connections, network speeds, etc. can be used to inform and control such distributed processing tasks.

[0083] Remotely optimize battery charging

[0084] The above context synchronization examples involve application-based processing. However, context synchronization can also be used to facilitate device management related tasks. For example, context synchronization can be used to facilitate remote optimization of battery charging. Figure 6 A generalized optimized battery charging routine for an electronic device is illustrated. More specifically, Figure 6A graph 600 of battery charge state on the vertical axis versus time on the horizontal axis is illustrated. Various events in the charging sequence are identified as times on the timeline. For example, before the device is plugged into an external power source (such as a main power source, an external battery pack, a car accessory adapter, etc.), the battery may be discharging as indicated by curve segment 641. After the device is plugged into the external power source, the battery may begin charging as indicated by curve segment 642. When plugged into the external power source, the device may determine an estimated disconnect time 640 at which it is expected to be disconnected from the external power source, which can be used to intelligently adjust the charging sequence, as described in more detail below. In addition, the estimated disconnect time can be determined based at least in part on the synchronization context, as described in more detail below.

[0085] The estimated disconnection time 640 may be determined in various ways based on sensor inputs (e.g., time of day, location, etc.) and machine learning models or other program structures that consider previous activity or otherwise infer possible disconnection times. As described above, this may include the use of synchronization context. For example, if a user typically plugs in a device at home around 10 p.m. and unplugs it around 6 a.m., the device may infer (if it is plugged in at the user's home location around 10 p.m.) that it will remain on the charger until around 6 a.m., and thus the charging sequence may be adjusted accordingly. The same is true if the user plugs in at the user's work location around 8 a.m. and unplugs around 12 p.m., which may allow the system to infer that the user is typically sitting at his or her desk at this time. Alternatively, if the device is plugged in at home while the user is at work (which may be determined by comparing the synchronized location-related context as described above), the system may infer that the device will remain plugged in at least until the user returns home. Inferences may be based on inputs other than time and location. For example, if the user is plugged in and the device can detect that it is moving at a high rate, the device may infer that it is in a car. Depending on the particular implementation of the machine learning model or other program structure, more or less detailed inferences may be drawn. In any case, the inferences may be used to modify the charging sequence as follows.

[0086] In the first example in the previous paragraph, where the device infers that it is at the user's home location and has been plugged in at around 10 PM, the device may assume that it will remain connected to the main power source until around 6 AM. Therefore, the device does not need to charge at the maximum rate (represented by the slope of curve segment 642) to fully charge as quickly as possible. In fact, it may be desirable to slow the charging rate and / or pause charging for a period of time (depicted by curve segment 643) to delay full charging of the battery. For example, the useful life of the battery (i.e., the battery health or the number of charging cycles that can maintain substantially full capacity) may be extended by reducing the amount of time the battery spends at full charge. Thus, in Figure 6In the optimized battery charging example, battery charging may be paused during interval 643. Additionally or alternatively, if the user plugs in the device but then leaves to go to another location (determined at least in part by the synchronization context), charging may also be slowed, paused, or the estimated disconnect time may be recalculated as appropriate based on the location context and other queues.

[0087] The estimated disconnection time 640 may be further used by the device to resume charging at a time selected to ensure that the battery reaches a fully charged state (represented by the charge level / curve segment 645) before the estimated disconnection time 640. The resumed charging is represented by curve segment 644. The charging segment may occur at a reduced rate, for example because the battery is closer to a full charge, as indicated by the reduced slope of the resumed charging segment 644 relative to the original charging segment 642. In any case, the machine learning model or other program structure that controls the optimized battery charging sequence may take into account the expected charging rate and the estimated disconnection time to ensure that the battery is fully charged before the user disconnects the device from the external power source. This can be achieved by selecting an estimated disconnection time that is before a possible or typical disconnection time and / or by ensuring that the battery is fully charged before the estimated disconnection time 640. In addition, the estimated disconnection time may be updated by a synchronization context that implies user behavior, for example, a user at a certain location indicates going to or arriving home, and normal usage patterns would not allow the user to be at home during this time period. Once the user disconnects the device from the external power source, the battery may begin to discharge, as illustrated by curve segment 646.

[0088] Relative to Figure 6 The optimized battery charging techniques described are "optimized" in the sense that battery health can be improved by reducing the amount of time the battery spends in a fully charged state. As described above, the optimized battery charging routine of the electronic device can be further optimized to adapt the battery charging to the contextual information as described above. The above examples involve the user's location or other location-related context, so that "remote" optimized battery charging can be achieved when the inserted device is in a different location from the user. Battery charging optimization measures that can be applied based on such context include adjusting the estimated disconnect time, slowing down the charging speed, pausing or resuming charging, etc. While location-based contexts may be most helpful in achieving battery charging optimization, other synchronization contexts may also be useful. For example, a battery charging profile can be recalibrated to allow the battery to be fully charged even when the device is consuming a large amount of power due to distributed processing tasks.

[0089] Otherwise, the described adaptive charging technique can proceed as described above. Figure 6In the example of optimized battery charging, battery charging may be suspended during an interval corresponding to curve segment 643, which may be determined at least in part based on the contextual information received from other devices. Battery charging may be resumed during an interval corresponding to curve segment 644 to ensure that the battery is fully charged before both the estimated disconnection time 640 and the actual disconnection time (represented by curve segment 645), after which the battery may begin to discharge, as shown by curve segment 646.

[0090] Under some operating conditions, it may be desirable to inhibit or otherwise forgo battery charging optimization. For example, if the battery state of charge is below a certain discharge level threshold (e.g., below 30%, 25%, etc.), then charging may need to be initiated immediately to ensure that the device has power available regardless of the context information. Similarly, once the battery reaches a state of charge corresponding to a certain charge level threshold (e.g., 75%, 80%, etc.), then it may be desirable to allow the battery to be fully charged just prior to the estimated disconnect time, regardless of the current state of the context information. Alternatively, it may be desirable to accelerate the predicted use / disconnect time based on changes in context information that occurred during the pause interval.

[0091] Figure 7 A flow chart of an optimized battery charging routine 700 for an electronic device for adjusting battery charging is illustrated. The flow chart depicts functionality that may be implemented by the electronic device 100 (including, for example, by the processor 101, which may include one or more processors as described above). In some cases, Figure 7The different functions depicted in the flowchart of can be implemented by different processors of the multi-processor system 100, or by separate processors, microcontrollers or other charger control circuits. As just one example, the processor 101 including a CPU, a GPU and an NPU (neural processing unit) can use the NPU to perform certain machine learning calculations. In any case, the adaptive optimized battery charging routine 700 based on synchronization context may include a machine learning model and a signal processing block 751, which can be used to detect when the electronic device is connected to an external power source and initiate an optimized charging routine as described above. These signals may include an indication of connection to an external power source, as well as other signals, including a synchronization remote environment, which allows the processor to make predictions about the possible duration of connection to the power source. For example, a location signal may indicate that the device is in a particular location, while a synchronization context from another device may indicate that the user is in another location. Alternatively, a changing location signal or a speed / vector speed sensor may indicate that the device is plugged into a vehicle accessory power source. Similarly, a changing location context or accumulated location context of another device that is more directly associated with the user's location may indicate that the user is returning, indicating that the predicted disconnection time may need to be updated. Other synchronization context signals from other devices (such as other devices associated with the user) may also be used as appropriate. These and other signals may be processed by a machine learning model to attempt to identify the power source and predict the disconnection time, as shown in block 752.

[0092] As described above, the estimated disconnection time can be derived from external signals including context signals synchronized from another device. For example, a time signal corresponding to late night and a signal corresponding to the location of the user's home and previous usage patterns can be used to infer that the nighttime charging cycle is about to begin. Alternatively, a time signal corresponding to noon and a context signal indicating that one or more other devices associated with the user are at another location (e.g., work) and the device implementing optimized charging is at another location (e.g., home) can indicate that the device will not be used at least until the user returns, which can be predicted based on previous usage patterns and / or changes in synchronization context. Alternatively, plugging in a power source at an unusual time or location and a low battery can be used to infer that the user needs to charge the device as quickly as possible. In any case, the predicted disconnection time or use time can be used to find a desired and / or undesired charging window (box 754), which can correspond to a preferred time when the battery is in certain states. Once the desired charging window is identified (box 754), the processor can operate the charging system of the device to charge the battery during the desired window, as depicted in box 755. In some cases, the processor may also communicate information about the charging process and the desired charging window to the user (block 756). Examples of such communications and optional user interactions are described below with reference to Figure 8 Discuss in more detail.

[0093] The electronic device 100 may be configured to implement an optimized battery charging routine that uses the synchronization context as described above to inform the optimized battery charging routine. More specifically, the electronic device 100 may include a charging controller as part of the power system 108. The charging controller may include an electronic circuit (including an analog circuit, a digital circuit, and / or a programmable circuit) that is configured to control whether, when, and at what rate the battery of the electronic device 100 is charged. It should be noted that in addition to allowing or inhibiting charging as described above, the optimized battery charging program can also be used to control the rate of battery charging in response to at least the synchronization context signal. Therefore, the system can be configured to slow down the battery charging speed during the pause time interval 643 and increase the battery charging rate when the estimated disconnection / use time 640 is approaching, rather than completely inhibiting battery charging during the pause time interval.

[0094] Figure 8 An electronic device 100 is illustrated that communicates parameters of an optimized battery charging routine to a user. Figure 8 The electronic device 100 is illustrated as a smart phone, but in fact it can be any of a variety of electronic devices, such as a tablet computer, a notebook computer or a laptop computer. As an example, the electronic device 100 can use the display 104 to present a message 857 to the user, which indicates the time when the charging is planned to be completed. In some cases, the electronic device 100 can provide a control element 858 (such as a UI button), which the user can use to bypass or override the optimized charging routine and complete the charging as soon as possible. In some embodiments, the control element 858 and the message 857 can be part of the same UI element, such as a GUI message / button. In other cases, one or more other output devices of the electronic device 100 can be used to provide instructions to the user, and one or more other input devices of the electronic device 100 can be used to receive input from the user, indicating that the user wants to bypass the optimized charging settings and complete the charging as quickly as possible. This can be used, for example, to allow another user who may share a remote device to accelerate charging so that the second user can use the device even if the main user may not be in the same location. There can also be cross-device optimized charging control. For example, there may be a user interface on a device carried by a user (eg, a smartphone) for controlling whether to immediately charge a remote device that would otherwise perform delayed charging as part of a remote optimized battery charging scheme.

[0095] Message 857 may also present additional information to the user. As an example, message 857 may specifically indicate that battery charging is suspended due to a state derived from one or more synchronization context signals, and / or battery charging is suspended to optimize battery health.

[0096] Enhanced power saving

[0097] In some cases, the synchronization context information as described above may be used to facilitate an enhanced power saving mode of a device. However, the enhanced power saving mode may also or alternatively be implemented without using the synchronization context information as described above. Fig. 9 Flowchart / block diagram 900 is illustrated to enable a device as described above to implement an enhanced power saving mode. The various activities described in flowchart / block diagram 1000 may be performed by the device, specifically by one or more processors of the device using data stored in one or more memories or storage locations of the device and / or retrieved via one or more communication or I / O interfaces of the device.

[0098] First, at block 961, the device may store or otherwise obtain or retrieve device usage history information, which may optionally include synchronization context information as described above. This may be done, for example, by one or more processes running on a processor of the device retrieving usage data from a local storage device / data repository and / or from a remote storage device / data repository. The usage history data (and optionally synchronization context data) may be provided to a usage predictor 962. Usage 962 may also be a process or processes running on a processor of the device. As described below with respect to Fig.10 and Fig.11 As described in more detail, the usage predictor can utilize the usage history data (and optionally the synchronization context data) to determine whether an extended period of inactivity is predicted. If so, the usage predictor 962 can communicate this information to the power management entity 963, which can be, for example, another process running on a processor of the device. In some cases, it can be a process running on a power management microcontroller or other suitable control circuit.

[0099] The power management entity 963 may also monitor various sensors, inputs, and / or optionally remote context information associated with the device to determine when a user of the device has become inactive (block 964). For example, the power management entity may detect that a user has become inactive by detecting a lack of input from the user. In the case of a handheld device, detecting a lack of motion (such as may be associated with the device being put down) may also be used to infer user inactivity. Alternatively, ambient light sensors, microphones, wireless signals from peripheral devices, etc. may be used to infer user inactivity. Additionally, a synchronization context as described above may optionally form part of the process. For example, a device (e.g., Figure 4 The location of the tablet computer 100c in FIG. 1 is home, while other devices associated with the user have another location, such as work (e.g., Figure 4If the user is using a mobile phone 100d and a laptop computer 100b, then it can be inferred that the former may be experiencing an extended period of inactivity. The precise period of inactivity can be inferred based on previous usage data and / or updates to the synchronization context signal. These and other cues that can be used to infer inactivity are all provided by Fig. 9 Box 964 in is represented.

[0100] In at least some cases, the power management entity 963 may be in bidirectional communication with the usage predictor 962. Thus, when the power management entity 963 detects user inactivity, it may query the usage predictor 962 to learn when the user activity is expected to resume, or alternatively, how long the user active period is expected to last. This may involve the power management entity 963 exchanging information received from the user inactivity detector 964 with the usage predictor 962. In other configurations, the data, signals, and information that trigger the detection of user inactivity may be provided to the usage predictor 962 or available to the usage predictor in other ways. The usage predictor 962 may implement any of a variety of programming and logic structures to infer the duration of the user's inactivity, including various combinations of traditional programming, machine learning algorithms, neural networks, "fuzzy logic" processing, and the like.

[0101] Once the usage predictor 962 has determined that an "extended" period of user inactivity is predicted, the usage predictor may notify the power management entity 963 that power saving optimization measures 965 may be implemented for a period of time that is up to but not longer than the expected duration of the user inactive period. These power saving optimization measures may include a variety of activities typically performed by the device that are slowed down, postponed, or otherwise delayed or interrupted during all or at least a portion of the predicted period of extended inactivity. For example, onboard radio components associated with cellular, WiFi, Bluetooth, ultra-wideband (UWB), etc. may be turned off or placed in low power mode. Background tasks such as obtaining email or text messages, synchronizing application data, processing newly received data, etc. may be slowed down (to reduce power consumption of related tasks) or postponed (to avoid power consumption of the particular task until it is restored). In addition, user notifications may be changed. For example, display notifications that would require activation of the display may be suppressed, although audio notifications or tactile notifications may still be desired. However, depending on the power consumption of various notification modes (e.g., visual, audio, tactile, etc.) and the expected or configured notification preferences, one or all of the notification modes may be suppressed in a timely manner. The enhanced power saving mode may be configured to modify the performance of any or all subsystems, foreground tasks, background tasks, user notifications, etc. of the electronic device as desired by the user and / or implementer of the system. For example, if the system is configured to periodically wake up from a non-enhanced low power state to perform background tasks, etc., then when in enhanced low power mode, these intervals may be extended or certain wake-ups may be suppressed.

[0102] Some existing electronic devices may employ low power modes in which certain background tasks, notifications, radios, or other system states are altered to provide reduced power consumption. However, the enhanced power saving modes described above may differ from such systems at least in that such pre-existing power saving modes are typically selected or manually configured by a user, whereas the enhanced power saving modes of the present invention are triggered based on the device's own inference of prolonged user inactivity.

[0103] Fig.10 A flowchart / block diagram 1000 for entering an enhanced power saving mode is illustrated. The various activities described in the flowchart / block diagram 1000 may be performed by the device, specifically by one or more processors of the device using data stored in one or more memories or storage locations of the device and / or retrieved via one or more communication or I / O interfaces of the device. Block 961 corresponds to retrieving or otherwise obtaining device usage history information, and optionally synchronization context information, as described above. Block 962 corresponds to a usage predictor as described above. The usage predictor may analyze the usage history and optional synchronization context information (as well as any other signal indicating user inactivity) to make a prediction of an extended inactivity period. As described above, the usage predictor 962 may implement any appropriate combination of algorithms including machine learning algorithms to perform the prediction. These predictions may be made continuously, periodically, or based on (for example) a specific request from a power management entity 963. If extended inactivity is predicted (block 1073), power saving optimization measures corresponding to the enhanced power saving mode may be implemented (block 965). These power saving optimization measures may include any of the specific optimization measures discussed above, or any other suitable power consumption reduction techniques.Otherwise, usage predictor 962 may continue to perform continuous, periodic, or on-request usage predictions.

[0104] Fig.11 A flowchart / block diagram 1100 for exiting an enhanced power saving mode is illustrated. The various activities described in the flowchart / block diagram 1000 may be performed by the device, specifically by one or more processors of the device using data stored in one or more memories or storage locations of the device and / or retrieved via one or more communication or I / O interfaces of the device. First, at block 961, a usage history (including current usage signals, such as user interactions with I / O devices, motion or ambient light sensors, etc.) and optional synchronization context signals may be analyzed for user activity associated with the device (block 1182). If user activity associated with the device is detected, the device may, for example, detect a user activity associated with the device by sending a request to a power management entity 963 ( Fig. 9 ) provides appropriate signaling to exit the enhanced low power state (box 1186).

[0105] Otherwise, if no user activity is detected, the predictor 962 (or other processing element of the device) can determine whether a user routine has been set. For example, the user can set the device to enter an enhanced power saving mode during certain intervals. For devices such as mobile phones, an example of such an interval may be a full night when the user is sleeping. Alternatively or additionally, for devices that are usually left at home or not used on weekdays (such as personal tablet computers), the weekday period of the weekday can be set as the expected inactive period. Conversely, for work devices such as laptops, the user can set the night and / or weekend as the time when the user routine will cause such devices to be inactive. The foregoing examples are not exhaustive, and the user can set any time period as the time when the user routine usually causes the device to be inactive.

[0106] In any case, if a user routine is set (box 1183), it can be determined whether the end of the inactive period associated with the user time has been reached (box 1185). If so, the enhanced low power state can be exited (box 1186), otherwise the usage history, usage signals and optional context information (box 961, box 1182) can continue to be monitored. Returning to box 1183, if a user routine is not set, it can be determined whether the time predicted for the end of the extended inactivity has been reached (box 1184). If so, the enhanced low power state can be exited (box 1186), otherwise the usage history, usage signals and optional context information (box 961, box 1182) can continue to be monitored. In summary, exiting the enhanced low power state can be triggered by any of the following situations: (1) user activity (e.g., detecting user interaction with the device), (2) the end of the extended inactive routine period set by the user, or (3) the end of the extended active prediction time period predicted by the device. In addition, the user routine may be, but is not necessarily, a period of time that is periodic or repetitive. In some cases, a user can manually set a device to enter an extended period of inactivity and specify a time to exit the extended period of inactivity.

[0107] As used throughout this disclosure, machine learning may refer to algorithms, statistical models, and the like that a computer system (such as electronic device 100) can use to perform a specific task with or without explicit instructions. For example, a machine learning process may generate a mathematical model based on a data sample (referred to as "training data") to make predictions or decisions without being explicitly programmed to perform a task. Depending on the inference to be made, the electronic device 100 (or its subsystems or associated devices) may implement different forms of machine learning. For example, in some embodiments (e.g., when there are specific known examples related to future predictions or estimates that a machine learning engine may be delegated to generate), the machine learning engine may implement supervised machine learning. In supervised machine learning, a mathematical model of a set of data contains both inputs and expected outputs. This data is referred to as "training data" and may include a set of training examples. Each training example may have one or more inputs and expected outputs, also referred to as a supervisory signal. In the mathematical model, each training example is represented by an array or vector (sometimes referred to as a feature vector), and the training data is represented by a matrix. By iteratively optimizing the objective function, a supervised learning algorithm can learn a function that can be used to predict an output associated with a new input. The optimal function may allow the algorithm to correctly determine outputs for inputs that were not part of the training data. An algorithm that improves the accuracy of its outputs or predictions over time is said to have learned to perform that task.

[0108] Supervised learning algorithms can include classification and regression techniques. Classification algorithms are used when the output is restricted to a finite set of values, while regression algorithms are used when the output has values ​​within a certain range. Similarity learning is a closely related area of ​​supervised machine learning that is related to regression and classification, but the goal is to learn from examples using a similarity function that measures how similar or related two objects are. Similarity learning has applications in ranking, recommendation systems, visual identity tracking, face verification, and speaker verification.

[0109] Additionally and / or alternatively, in some cases, it may be advantageous for a machine learning engine to utilize unsupervised learning (e.g., when a particular output type is unknown). An unsupervised learning algorithm takes a set of data containing only inputs and looks for structure in the data, such as groupings or clusters of data points. Thus, the algorithm learns from test data that has not yet been labeled, classified, or categorized. Instead of responding to feedback, an unsupervised learning algorithm identifies commonalities in the data and reacts based on the presence or absence of such commonalities in each new piece of data.

[0110] That is, the machine learning engine may implement cluster analysis, which is the assignment of a set of observations into subsets (called clusters) such that observations within the same cluster are similar according to one or more predetermined criteria, while observations drawn from different clusters are dissimilar. Different clustering techniques make different assumptions about the structure of the data, which are typically defined by some similarity measure and evaluated, for example, by internal compactness (or similarity between members of the same cluster) and separability (dissimilarity between clusters). In additional or alternative embodiments, the machine learning engine may implement other machine learning techniques, such as those based on estimated density and graph connectivity.

[0111] The above describes an exemplary embodiment of transferring certain tasks performed by an electronic device based on the power grid conditions associated with an external power source connected to the electronic device. Although many specific features and various embodiments have been described, it should be understood that unless otherwise indicated to be mutually exclusive, the various features and embodiments may be combined into various arrangements in a specific implementation. Therefore, the various embodiments described above are provided only by way of example and should not be interpreted as limiting the scope of the present disclosure. Various modifications and changes may be made to the principles and embodiments herein without departing from the scope of the present disclosure and without departing from the scope of the claims.

[0112] The foregoing describes exemplary embodiments of electronic systems that are capable of sending certain information between other systems and devices. The present disclosure contemplates that this information transfer will improve the functionality of the device. Entities implementing the present technology, to the extent that any sensitive information is used in a particular implementation, should take care to ensure compliance with established privacy policies and / or privacy practices. Specifically, such entities will be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Implementers should inform users where personally identifiable information is expected to be sent, and allow users to "opt in" or "opt out" to participate.

[0113] Once the data is no longer needed, risks can be minimized by limiting the collection of data and deleting the data. In addition, and when applicable, data de-identification can be used to protect the privacy of users. For example, a device identifier can be partially masked to convey the power characteristics of the device without uniquely identifying the device. De-identification can be promoted when appropriate by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than at the address level), controlling how data is stored (e.g., aggregating data across users), and / or other methods such as differential privacy. Robust encryption can also be used to reduce the likelihood that communications between devices can be intercepted, spoofed, or otherwise tampered with.

Claims

1. A method of reducing power consumption in an electronic device, the method being performed by one or more processors of the electronic device and comprising: analyzing device usage data associated with the device to predict an extended period of user inactivity, the usage data comprising at least one of historical usage data and current usage signals; as well as The enhanced low power state is entered by implementing one or more power saving optimization measures during at least a portion of the extended period of extended user inactivity, the one or more power saving optimization measures slowing down, delaying or interrupting one or more normal activities normally performed by the device. 2 . The method of claim 1 , further comprising exiting the enhanced low power state by suspending the one or more power saving optimization measures.

3. The method of claim 2, wherein exiting the enhanced low power state is performed in response to at least one of: user activity; a specified user routine; or a time predicted by analyzing device usage data. The method of claim 1 , wherein the device usage data comprises both historical usage data and current usage signals. The method of claim 1 , wherein the usage data comprises synchronization context information from one or more remote devices associated with a user of the device.

6. The method of claim 5, wherein the synchronization context information includes information corresponding to a location of a user, the information being comparable to a location of the device to trigger entry into the enhanced low power state.

7. The method of claim 1 , wherein the one or more power saving optimization measures include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low power mode; Slow down or postpone background tasks; changing at least one of an audio notification, a visual notification, or a tactile notification provided to a user; as well as Delay or suppress wake-up events for the device.

8. A method of reducing power consumption in an electronic device, the method being performed by one or more processors of the electronic device and comprising: analyzing device usage data associated with the device to predict an extended period of user inactivity, the usage data comprising historical usage data, current usage signals, and contextual information from one or more remote devices associated with a user of the device; as well as The enhanced low power state is entered by implementing one or more power saving optimization measures during at least a portion of the extended period of extended user inactivity, the one or more power saving optimization measures slowing down, delaying or interrupting one or more normal activities normally performed by the device.

9. The method of claim 8, further comprising exiting the enhanced low power state by suspending the one or more power saving optimization measures.

10. The method of claim 9, wherein exiting the enhanced low power state is performed in response to at least one of: user activity; a specified user routine; or a time predicted by analyzing device usage data.

11. The method of claim 8, wherein the synchronization context information includes information corresponding to a location of a user, the information being comparable to a location of the device to trigger entry into the enhanced low power state.

12. The method of claim 8, wherein the one or more power saving optimization measures include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low power mode; Slow down or postpone background tasks; changing at least one of an audio notification, a visual notification, or a tactile notification provided to a user; as well as Delay or suppress wake-up events for the device.

13. An electronic device, comprising one or more processors, a memory, a storage device, one or more input / output devices, and a power supply system, and further comprising: a usage predictor that analyzes device usage data to predict extended periods of user inactivity, the usage data comprising at least one of historical usage data and current usage signals; and a power management entity that causes the device to enter an enhanced low power state by implementing one or more power saving optimization measures during at least a portion of the extended period of extended user inactivity, the one or more power saving optimization measures slowing down, delaying, or interrupting one or more normal activities normally performed by the device; Wherein the usage predictor comprises one or more processes running on the one or more processors, and the power management entity comprises one or more processes running on the one or more processors.

14. An electronic device according to claim 13, wherein the power management entity further causes the device to exit the enhanced low power state by suspending the one or more power saving optimization measures, wherein the exit from the enhanced low power state is performed by the power management entity in response to at least one of the following: user activity; a specified user routine; or a time predicted by analyzing device usage data.

15. The electronic device of claim 14, wherein the usage data comprises synchronization context information from one or more remote devices associated with a user of the device.

16. The electronic device of claim 15, wherein the synchronization context information includes information corresponding to a location of a user, the information being comparable to a location of the device to trigger entry into the enhanced low power state.

17. The electronic device of claim 14, wherein the one or more power saving optimization measures include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low power mode; Slow down or postpone background tasks; changing at least one of an audio notification, a visual notification, or a tactile notification provided to a user; as well as Delay or suppress wake-up events for the device.

18. An electronic device, comprising one or more processors, a memory, a storage device, one or more input / output devices, and a power supply system, and further comprising: a usage predictor that analyzes device usage data to predict extended periods of user inactivity, the usage data comprising historical usage data, current usage signals, and synchronization context information from one or more remote devices associated with a user of the device; and a power management entity that causes the device to enter an enhanced low power state by implementing one or more power saving optimization measures during at least a portion of the extended period of extended user inactivity, the one or more power saving optimization measures comprising slowing down, delaying, or interrupting one or more normal activities normally performed by the device; Wherein the usage predictor comprises one or more processes running on the one or more processors, and the power management entity comprises one or more processes running on the one or more processors.

19. An electronic device according to claim 18, wherein the power management entity further causes the device to exit the enhanced low power state by suspending the one or more power saving optimization measures, wherein the exit from the enhanced low power state is performed by the power management entity in response to at least one of the following: user activity; a specified user routine; or a time predicted by analyzing device usage data.

20. The electronic device of claim 18, wherein the synchronization context information includes information corresponding to a location of a user, the information being comparable to a location of the device to trigger entry into the enhanced low power state.

21. The electronic device of claim 18, wherein the one or more power saving optimization measures include one or more items selected from the group consisting of: turning off one or more radio components of the electronic device or placing one or more radio components of the electronic device in a low power mode; Slow down or postpone background tasks; changing at least one of an audio notification, a visual notification, or a tactile notification provided to a user; as well as Delay or suppress wake-up events for the device.

Images