ENERGY SAVING FOR BATTERY-POWERED DEVICES

Abstract

Method for reducing the power consumption of an electronic device (100), wherein the method is carried out by one or more processors (101) of the electronic device (100), and comprising: Analyzing device usage data associated with the device (100) to predict a prolonged period of user inactivity, wherein the usage data includes synchronized contextual information from one or more remote devices associated with a user of the device; and Switching to an extended reduced energy state by implementing one or more power-saving optimizations for at least part of the predicted period of prolonged user inactivity, wherein the one or more power-saving optimizations slow down, delay or interrupt one or more normal activities normally performed by the device (100).

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS

[0001] This application claims priority over the preliminary US patent application No. 63 / 374,665, filed on September 6, 2022, entitled “Multi-Device Context Synchronization and Applications Thereof”. BACKGROUND

[0002] Users may possess a variety of electronic devices, including smartphones, tablets, laptops, desktop computers, smartwatches, and more. In some cases, users may own multiple such devices. There may be applications where sharing these devices would be desirable. For this purpose, exchanging information between such devices may be beneficial. While techniques already exist that enable such synchronization, these techniques can have drawbacks regarding query frequency, network bandwidth, and other issues as the number of devices to be synchronized increases.

[0003] US 2008 / 0005599A1 relates to a method and apparatus for user-activity-based dynamic power management and policy creation for mobile platforms. The method involves monitoring one or more sensor readings from a mobile platform device to collect sensor activity data. Once the sensor activity data is collected, the user state can be predicted based on the collected user activity and an updated user state model. The user state model is updated according to the sensor activity data. A switch from the current power management strategy to a new power management strategy occurs when the new user state differs from the current user state by a predetermined amount. At least one timeout parameter of a selected power management strategy can be adjusted to match a predicted user state.

[0004] US 2017 / 0357529 A1 concerns a user device that can schedule tasks based on user behavior. The user device can receive a task request that includes a time window and user / device context parameters for performing the task. Based on historical context data, the user device can predict a time when the user / device context is optimal for performing the task within the time window. The user device can generate an optimal context score for the task based on the context parameters and historical context data. The user device can execute the requested task at a current time within the time window if a context score for the current context exceeds a threshold determined based on the optimal context score.

[0005] Starting from the known state of the art, the present disclosure aims to specify a method and an electronic device that are each suitable to enrich the state of the art.

[0006] The problem is solved by the features of the independent claim. The dependent and subordinate claims each contain further developments of the disclosure. SUMMARY

[0007] This document discloses improved techniques for synchronizing data, particularly contextual data, between a multitude of electronic devices assigned to a user. It also discloses various exemplary applications that can be enabled by such contextual synchronization.

[0008] A method for reducing the power consumption of an electronic device, executed 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, wherein the usage data includes synchronized context information from one or more remote devices associated with a user of the device, and switching to an extended reduced power state by implementing one or more power-saving optimizations for at least part of the predicted period of extended user inactivity, wherein the one or more power-saving optimizations slow down, delay, or interrupt one or more normal activities normally performed by the device.The procedure can further include exiting the extended reduced energy state by suspending one or more power-saving optimizations. For example, exiting the extended reduced energy state can be performed in response to at least one of the following events: user activity; a specified user routine; or a time predicted by analyzing device usage data.

[0009] For example, device usage data can include both historical usage data and current usage signals. For example, usage data can include synchronized contextual information from one or more remote devices associated with a user of the device. The synchronized contextual information can include information corresponding to a user's location, which can be compared to a device location to trigger entry into the extended reduced energy state.The one or more power-saving optimizations include one or more elements selected from the group consisting of: turning off or placing one or more radios of the electronic device into a power-saving mode, or, for example, slowing down or postponing background tasks, changing at least one of the audible, visual or haptic notifications provided to a user, and delaying or suppressing wake-up events of the device.

[0010] A method for reducing the power consumption of 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, wherein the usage data includes historical usage data, current usage signals, and contextual information from one or more remote devices associated with a user of the device; and transitioning to an extended reduced power state by implementing one or more power-saving optimizations for at least part of the extended period of prolonged user inactivity, wherein the one or more power-saving optimizations slow down, delay, or interrupt one or more normal activities that are normally performed by the device.For example, the procedure can also include exiting the extended reduced energy state by suspending one or more power-saving optimizations. Exiting the extended reduced energy state can be performed in response to at least one of the following events: user activity; a specified user routine; or a time predicted by analyzing device usage data.

[0011] The synchronized contextual information can include information corresponding to a user's location, which can be compared to the device's location to trigger entry into the extended reduced power state. The one or more power-saving optimizations include one or more elements selected from the following: turning off or placing one or more of the electronic device's radios into a power-saving mode, slowing down or postponing background tasks, changing at least one of the audible, visual, or haptic notifications provided to a user, and delaying or suppressing device wake-up events.

[0012] An electronic device may include one or more processors, a memory, storage, one or more input / output devices, and a power supply system.The electronic device may further include a usage predictor that analyzes device usage data to predict a prolonged period of user inactivity, wherein the usage data includes synchronized contextual information from one or more remote devices associated with a user of the device; and a power management unit that causes the device to enter an extended reduced power state for at least part of the prolonged period of user inactivity by implementing one or more power-saving optimizations, wherein the one or more power-saving optimizations slow down, delay, or interrupt one or more normal activities that are normally performed by the device.The usage predictor can include one or more processes running on the one or more processors, and the power management unit can include one or more processes running on the one or more processors. The power management unit can further cause the device to exit the enhanced reduced-power state by suspending the one or more power-saving optimizations before the end of the predicted extended period of user inactivity. For example, the power management unit can initiate the exit from the enhanced reduced-power state in response to one or more of the following events: user activity; a specified user routine; or a time predicted by analyzing device usage data.

[0013] For example, usage data can include synchronized contextual information from one or more remote devices associated with a user of the device. This synchronized contextual information can include information corresponding to a user's location, which can be compared to the device's location to trigger entry into the extended reduced power state. The one or more power-saving optimizations can include one or more elements selected from the following: turning off or placing one or more of the electronic device's radios into a power-saving mode, slowing down or postponing background tasks, changing one or more of the audible, visual, or haptic notifications provided to a user, and delaying or suppressing device wake-up events.

[0014] An electronic device may include one or more processors, a memory, storage, one or more input / output devices, and a power supply system.The electronic device may also include a usage predictor that analyzes device usage data to predict a prolonged period of user inactivity, wherein the usage data includes historical usage data, current usage signals, and synchronized contextual information from one or more remote devices associated with a user of the device; and a power management unit that causes the device to enter an extended reduced power state for at least part of the prolonged period of user inactivity by implementing one or more power-saving optimizations, wherein the one or more power-saving optimizations include slowing down, delaying, or interrupting one or more normal activities that are normally performed by the device.The usage predictor can include one or more processes running on the one or more processors, and the power management unit can include one or more processes running on the one or more processors. The power management unit can further cause the device to exit the enhanced reduced power state by suspending one or more power-saving optimizations. Exiting the enhanced reduced power state can be performed by the power management unit in response to at least one of the following events: user activity; a specified user routine; or a time predicted by analyzing device usage data.

[0015] The synchronized contextual information can include information corresponding to a user's location, which can be compared to the device's location to trigger entry into the extended reduced power state. The one or more power-saving optimizations can include one or more elements selected from the following: turning off or placing one or more of the electronic device's radios into a power-saving mode, slowing down or postponing background tasks, changing at least one of the audible, visual, or haptic notifications provided to a user, and delaying or suppressing device wake-up events.

[0016] A method for synchronizing context information between a plurality of electronic devices assigned to a user, wherein each device comprises one or more processors, communication interfaces, and a memory or storage, may be executed by at least one of the devices and may include subscribing to one or more contexts, each context corresponding to one or more properties, states, or other information corresponding to another of the plurality of electronic devices; and receiving periodic updates of the one or more subscribed contexts from a data storage device shared by or distributed among the plurality of devices, wherein receiving periodic updates includes retrieving the periodic updates from the data storage device or receiving push updates from the data storage device.Each context can be a key / value pair. The one or more subscribed contexts can include a subset of the contexts available in the data store.

[0017] The subscribed contexts can be filtered based on at least one relevance or importance criterion, with the relevance or importance of each context controlling the frequency, scheduling, and prioritization of updates for that context. The process can further include evaluating the subscribed contexts and one or more conditions on a local device and executing an action based on the result of the evaluation. The at least one context can correspond to the state of an application on another device from among the multitude of electronic devices.In response to an update of at least one context indicating that the user is using the application on the other device, performing an action based on the result of the evaluation may include initiating a synchronization of application data associated with the application, which would otherwise be performed at a later time.The at least one context may include one or more contexts corresponding to the load, thermal state, or energy status of other devices of the plurality of electronic devices, and performing an action based on the result of the evaluation may include providing a distributed processing task to one or more of the other electronic devices in response to the one or more contexts corresponding to the load, thermal state, or energy status of other devices of the plurality of electronic devices.

[0018] A method for synchronizing context information between a plurality of electronic devices, each device including one or more processors, communication interfaces, and a memory or storage device, can be executed 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 store shared by or distributed among the plurality of devices by responding to a pull request for periodic updates from the data store or by pushing updates to the data store. The one or more contexts can each comprise a key / value pair.The contexts can be filtered based on at least one of relevance or importance, with the relevance or importance of each context controlling the frequency, scheduling, and prioritization of updates for that context.

[0019] A method for data synchronization between a plurality of electronic devices assigned to a user may include, on one device of the plurality of electronic devices, subscribing to one or more contexts, wherein at least one context corresponds to a state of an application on another device of the plurality of electronic devices; receiving periodic updates of the one or more subscribed contexts from a data store shared by or distributed among the plurality of devices; and, in response to an update of the at least one context indicating that the user is using the application on the other device, initiating the synchronization of application data associated with the application, which would otherwise be performed at a later time.The one or more subscribed contexts can include at least one context corresponding to the location of one or more of the plurality of electronic devices. A communication interface used to synchronize application data can be selected, at least in part, based on the at least one context corresponding to the location of one or more of the plurality of electronic devices. The method can further include delaying the synchronization of application data to one of the plurality of electronic devices if the at least one context corresponding to the location of one or more of the plurality of electronic devices indicates that the user is not using the application on that device.

[0020] A method for distributed processing between a plurality of electronic devices assigned to a user may include, on one device of the plurality of electronic devices, subscribing to one or more contexts corresponding to the workload, thermal state, or energy status of other devices of the plurality of electronic devices; receiving periodic updates of the one or more subscribed contexts from a data storage location shared by or distributed among the plurality of devices; and providing a distributed processing task to one or more of the other electronic devices in response to the one or more contexts corresponding to the workload, thermal state, or energy status of other devices of the plurality of electronic devices.

[0021] The one or more subscribed contexts may include at least one context corresponding to the utilization of one of the other electronic devices, and the provision of a distributed processing task to one or more of the other electronic devices in response to the one or more contexts may further include assigning a distributed processing task to the other electronic device when the utilization is below a threshold, and not assigning a distributed processing task to the other electronic device when the utilization is above the threshold.

[0022] The one or more subscribed contexts may include at least one context corresponding to the thermal state of one of the other electronic devices, and the provision of a distributed processing task to one or more of the other electronic devices in response to the one or more contexts may further include assigning a distributed processing task to the other electronic device when the thermal state is below a threshold, and not assigning a distributed processing task to the other electronic device when the thermal state is above the threshold.The one or more subscribed contexts may include at least one context corresponding to an AC connection state for one of the other electronic devices, and the provision of a distributed processing task to one or more of the other electronic devices in response to the one or more contexts may further include assigning a distributed processing task to the other electronic device when it is connected to AC power, and not assigning a distributed processing task to the other electronic device when it is not connected to AC power.

[0023] The one or more subscribed contexts may include at least one context corresponding to the battery charge level of one of the other electronic devices, and the provision of a distributed processing task to one or more of the other electronic devices in response to the one or more contexts may further include assigning a distributed processing task to the other electronic device when the battery charge level is above a threshold, and not assigning a distributed processing task to the other electronic device when the battery charge level is below the threshold.

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

[0025] The synchronized context data can provide clues about the user's location. If the synchronized context data indicates that the user is located elsewhere than the device, the estimated separation time can be determined, at least in part, based on the expected time it will take the user to return to the device's location. One or more desired battery charging intervals can be selected to reduce the time it takes for the battery to fully charge. The processor can also be programmed to operate the power supply system so that the battery is charged from the external power source during the one or more identified desired battery charging intervals by regulating the battery charging rate to reduce the time it takes for the battery to fully charge.

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

[0027] A method for operating an electronic device, executed by a processor of the electronic device, may include detecting the 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, at least partially based on synchronized contextual data from one or more other devices associated with a user of the device, identifying one or more desired battery charging intervals prior to the estimated disconnection time, and operating the power supply system to charge the battery using the external power source during the identified one or more desired battery charging intervals. Determining the estimated disconnection time may further involve the use of a machine learning model.

[0028] The synchronized context data can provide an indication of the user's location. If the synchronized context data indicates that the user is located at a different location than the device, the estimated separation time can be determined, at least in part, based on the expected time the user will need to return to the device's location. One or more desired battery charging intervals can be selected to reduce the time it takes for the battery to fully charge. The method can further include regulating the battery charging rate to reduce the time it takes for the battery to fully charge. The method can also include transmitting information about the one or more desired battery charging intervals to a user via a display on the electronic device.The procedure may also include receiving user input for loading via an input to the electronic device.

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

[0030] The synchronized context data can provide clues about the user's location. If the synchronized context data indicates that the user is located elsewhere than the device, the one or more battery charging intervals are determined, at least in part, based on the estimated time the user will need to return to the device's location. The one or more desired battery charging intervals can be selected to minimize the time it takes for the battery to fully charge. The processor can also be programmed to operate the power supply system to charge the battery during the one or more battery charging intervals by regulating the charging rate to further reduce the time it takes for the battery to be fully charged. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 illustrates a block diagram of an electronic device. Fig. Figure 2 illustrates a variety of devices that synchronize context information. Fig. Figure 3 shows a more detailed view of a variety of devices that synchronize context information. Fig. Figure 4 illustrates a variety of devices that synchronize context information across different communication links. Fig. Figure 5 illustrates devices that receive and send context information. Fig. Figure 6 illustrates an optimized battery charging routine for an electronic device. Fig. Figure 7 shows a flowchart of an optimized battery charging routine for an electronic device that adjusts the battery charge. Fig. Figure 8 illustrates an electronic device that communicates parameters of an optimized battery charging routine to a user. Fig. Figure 9 shows a flowchart / block diagram of an enhanced power-saving mode for an electronic device. Fig. Figure 10 shows a flowchart / block diagram for switching to an enhanced power saving mode. Fig. Figure 11 shows a flowchart / block diagram for exiting an extended power saving mode. DETAILED DESCRIPTION

[0031] For illustrative purposes, numerous specific details are presented in the following description to provide a comprehensive understanding of the disclosed concepts. For the sake of simplicity, some drawings in this disclosure depict structures and devices in block diagram form. For clarity, not all features of an actual implementation are described in this disclosure. Furthermore, the language used in this disclosure was chosen for readability and teaching purposes, and not to delimit or restrict the subject matter disclosed. Rather, the accompanying claims are provided for that purpose.

[0032] Various embodiments of the disclosed concepts are illustrated in the accompanying drawings, where identical references denote identical elements, in an exemplary and non-limiting manner. For the sake of simplicity and clarity of illustration, reference numerals have been repeated in the various figures where appropriate to indicate corresponding or analogous elements. Furthermore, numerous specific details are set forth to provide a comprehensive understanding of the implementations described herein. In other cases, methods, procedures, and components have not been described in detail so as not to obscure the relevant function being described. References to “a,” “a particular,” or “another” embodiment in this disclosure do not necessarily refer to the same or a different embodiment, and they mean at least one.A given figure may be used to illustrate the features of more than one embodiment or more than one kind of disclosure, and not all elements in the figure may be necessary for a given embodiment or kind. A reference numeral, when provided in one drawing, refers to the same element in each of the different drawings, although it may not be repeated in every drawing. Unless otherwise indicated, the drawings are not to scale, and the proportions of certain parts may be exaggerated for better illustration of details and features of the present disclosure. introduction

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

[0034] For example, the electronic device 100 may include any suitable computing device, including a desktop or notebook computer (e.g., in the form of a MacBook®, MacBook® Pro, MacBook Air®, iMac®, Mac® mini or Mac Pro®, available from Apple Inc. of Cupertino, California, USA), a portable or handheld electronic device, such as a wireless electronic device or smartphone (e.g., in the form of a model of iPhone®, available from Apple Inc. of Cupertino, California, USA), a tablet (e.g., in the form of a model of iPad®, available from Apple Inc. of Cupertino, California, USA), a wearable electronic device (e.g., in the form of an Apple Watch® from Apple Inc. of Cupertino, California, USA) and other similar devices.

[0035] The processor 101 and other related elements in Fig. 1 can be implemented entirely as hardware or by hardware programmed to execute suitable software instructions. Furthermore, the processor 101 and other associated elements in Fig. 1. The processor 101 may be a single, self-contained processing module or may be wholly or partially integrated within any of the other elements within the electronic device 100. The processor 101 may be implemented with any combination of general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), controllers, state machines, gate-controlled logic, separate hardware components, dedicated finite hardware automata, or any other suitable entities capable of performing computations or other processing of information. The processor 101 may include one or more application processors, one or more baseband processors, or both, and may perform the various functions described herein.

[0036] In the electronic device 100 of Fig. 1. The processor 101 can be operationally coupled with a memory 102 and non-volatile memory 103 to execute various algorithms. Such programs or instructions executed by the processor 101 can be stored in any suitable manufacturing article that includes one or more physical, computer-readable media. The physical, computer-readable medium can include the memory 102 and / or the non-volatile memory 103 individually or together to store the instructions or routines. The memory 102 and the non-volatile memory 103 can include any suitable manufacturing article for storing data and executable instructions, such as random-access memory, read-only memory, rewritable flash memory, hard disks, and optical disks. Furthermore, programs encoded on such a computer program product (e.g.,an operating system) also include instructions that can be executed by the processor 101 to enable the electronic device 100 to provide various functionalities.

[0037] In certain embodiments, the display 104 can allow users to view images generated on the electronic device 100. In some embodiments, the display 104 can include a touchscreen, which can facilitate user interaction with a user interface of the electronic device 100. Furthermore, it is understood that in some embodiments, the display 104 can include one or more liquid crystal displays (LCDs), light-emitting diode displays (LEDs), organic light-emitting diode displays (OLEDs), active-matrix organic light-emitting diode displays (AMOLEDs), or a combination of these and / or other display technologies.

[0038] The input devices 105 of the electronic device 100 enable a user to interact with the electronic device 100 (e.g., by pressing a button to increase or decrease a volume level). The I / O interface 106 enables the electronic device 100 to connect to various other electronic devices via an interface, as does the network interface 107. In some embodiments, the I / O interface 106 may include an I / O port for a hardwired connection for charging and / or manipulating content using a standard connector and protocol, such as the Lightning connector provided by Apple Inc. of Cupertino, California, USA, a Universal Serial Bus connector (USB connector), or another similar connector and protocol.The network interface 107 can, for example, provide one or more interfaces for a personal area network (PAN), such as an ultra-wideband (UWB) or a BLUETOOTH® network, a local area network (LAN), or a wireless local area network (WLAN), such as a network using one of the IEEE-802 protocols. 11x family (e.g., Wi-Fi®), and / or a wide area network (WAN), such as all standards relating to the mobile network of the Third Generation Partnership Project (3GPP), including, for example, a 3rd generation mobile network (3G), a universal mobile telecommunications system (UMTS), a 4th generation mobile network (4G), a Long Term Evolution mobile network (LTE® mobile network), a Long Term Evolution License Assisted Access mobile network (LTE-LAA mobile network), a 5th generation mobile network (5G) and / or a New Radio mobile network (NR mobile network), a 6th generation mobile network.The network interface 107 may include, for example, one or more interfaces for using a mobile communication standard of the 5G specifications, which includes the millimeter wave frequency range (mm-wave frequency range) (e.g., 24.25 to 300 gigahertz (GHz)), defining and / or enabling frequency ranges used for wireless communication. The network interface 107 of the electronic device 100 may enable communication over the aforementioned networks (e.g., 5G, Wi-Fi, LTE-LAA, and the like).

[0039] The network interface 107 can also include one or more interfaces, for example, for Broadband Fixed Wireless Access networks (e.g., WiMAX®), mobile wireless broadband networks (mobile WiMAX®), asynchronous digital subscriber lines (e.g., ADSL, VDSL), a Digital Video Broadcasting Terrestrial network (DVB-T® network) and its DVB Handheld Extension Network (DVB-H® extension network), an Ultra Broadband Network (UWB network), AC power lines (WS power lines), and the like.

[0040] The power supply system 108 of the electronic device 100 can include any suitable power source, such as a rechargeable battery (e.g., a lithium-ion or lithium-polymer battery (Li-Poly)) and / or a current transformer, including a DC / DC current transformer, an AC / DC current transformer, a power supply (which may be external), etc. Context synchronization

[0041] Fig. Figure 2 illustrates a variety of devices that synchronize contextual information. These devices can all be assigned to a specific user, such as a desktop computer 100a, a laptop or notebook computer 100b, a tablet 100c, a smartphone 100d, and / or a smartwatch 100e. Furthermore, other electronic devices can be included, such as wireless earbuds, styluses, keyboards, mice, trackpads, or other input peripherals, as well as smart home devices like hubs, sensors, actuators, and so on. These various devices can exchange or synchronize data with each other, which can be used in a variety of ways to enhance the user experience with the devices.As described in more detail below, this data can include one or more "contexts," which can be key / value pairs describing a specific property, status, or other information available on one device that may be relevant to one or more other devices. These contexts can be synchronized between devices in various ways, as described in more detail below. In the illustration of... Fig. 2. These contexts are represented as if they were exchanged via a cloud 207. Various implementations of such systems are described in more detail below, but can include any suitable combination of shared or distributed data storage and communication paths over which the context data is exchanged. For devices that are in the same location (e.g., smartphone 100d and smartwatch 100e), the exchange can take place over local communication channels 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 a tablet 100c that a user takes to a café, in contrast to a desktop computer 100a that remains at home or at work, communication can take place over the internet or another WAN connection while the devices are not in the same location.Once the user returns and the devices are in the same location, the previously remote devices, which communicated over the internet or another WAN connection, may switch to a more local connection. In other cases, two devices associated with a user may never be in the same location, such as a desktop computer at home and a desktop computer at work, and may therefore always rely on internet or WAN communication.

[0042] Fig. Figure 3 shows a more detailed view of a variety of devices that synchronize contextual information. More specifically, it shows Fig. 3 Three devices 300a, 300b, and 300c that exchange information via a data storage device 320, although more or fewer devices could optionally be used. In some embodiments, the data storage device 320 can be a shared, centralized database that each device can access. Such a shared, centralized database can be hosted on a server that each device can access, or it can be stored on one of the shared devices, which can be considered primary.Even in the case of a shared, centralized database, any device using such a shared, centralized database for the context synchronization described herein may cache all or part of the shared, centralized database locally, for example, to improve performance or reliability, or to adapt to different connections with varying bandwidth, power consumption, or other characteristics, etc. Nevertheless, the centralized database can be considered "authoritative" if the cached data differs from the data in the shared, centralized data storage.In other cases, the shared data store 320 can be implemented as a distributed database in which each device maintains a copy of either the entire database or the portions of the database relevant to that device. In this case, mechanisms can be provided to determine which copy of a given entry is "authoritative." For example, each entry can be assigned one and only one owner, such that the copy of that owner can be considered authoritative for all distributed copies. Between two non-owners, other mechanisms can be used to determine which copy is authoritative, such as a most recently updated copy, etc. Any of the numerous techniques can be applied as needed, provided they are not otherwise inconsistent with the teachings described herein.

[0043] Referring to the devices from Fig. 3. The device includes a variety of clients, a variety of contexts, and a variety of subscriptions, which are described in more detail below. For illustrative purposes, each device has a slightly different configuration of these elements. These configurations are provided as examples, and several combinations, permutations, and variations of these configurations are also possible. Initially, a device (e.g., Device 300a) can include a variety of "clients" 311a, 312a, 313a. More or fewer clients can be provided. The client can be either a source or a sink of one or more contexts. A client can include a process or application that runs on the device and uses the information related by the contexts.

[0044] Each client can be associated with one or more contexts. For example, device 300a includes three contexts, 314a, 315a, and 316a, each associated with clients 311a, 312a, and 313a, respectively. Contexts, as described in more detail below, are data created or used by a client. A context can be used by multiple clients on the same device and / or by one or more clients on one or more different devices, as the examples below illustrate more clearly. A context may, but does not necessarily, include a key / value pair representing a state or condition.

[0045] A subscription can be the mechanism by which a context is received from or transmitted to the shared data store and / or from clients on other devices. For example, the device 300a includes three subscriptions 317a, 318a, and 319a, each associated with contexts 314a, 315a, and 316a, respectively. A subscription can manage transmission to and from a client, or optionally, in some embodiments, only transmission to a client, with contexts being transmitted from a client directly or otherwise to the shared data store 320.In both cases, a subscription can be based on a push action, where the client that is the source of the context sends or “pushes” the context to one or more clients, or on a pull action, where the client that is a consumer of the context retrieves or “pulls” the context from the data store or optionally from another client and / or device.

[0046] Returning to the example of device 300a, clients 311a, 312a, and 313a can correspond to different applications or processes running on device 300a. Client 311a can be a source of context 314a, which is associated with subscription 317a. A change in the state or condition associated with context 314a can cause client 311a to provide an updated context to shared datastore 320 via subscription 317a (or through another suitable arrangement). Shared datastore 320 can be a centralized shared datastore or a distributed shared datastore, as described above, or it can be a hybrid of these datastore types, incorporating all the features of both types that are appropriate for a given application.In other words, data storage 320 can be located anywhere along a continuum from a fully centralized data storage to a fully distributed data storage. Likewise, subscriptions can be stored centrally or distributed. Centralized storage of subscriptions allows for a server-side request filtering function, which in some cases can be advantageous for reducing the processing load and / or network bandwidth consumption on a local device. In any case, subscription 317a can communicate with the shared data source via a communication link 320a, which can be any of the example communication links described above or any other suitable type of communication link.

[0047] Distributed processing allows the subscription to advantageously formulate a complex remote query across a range of sensors / data on any given device. This subscription / query can be evaluated on that device when conditions change, and the device can use any available / appropriate communication channel to send an update regarding the query / conditions associated with the subscription directly to interested devices. Thus, at least in some cases, the subscription can be distributed and evaluated directly within the private environment of each device, rather than in a central location. Evaluating subscriptions on individual devices can offer a privacy advantage, as the contextual values ​​can be transmitted end-to-end encrypted between devices, meaning they cannot be read by any intermediary service provider.

[0048] Client 312a can be a sink or a consumer of context 315a, which is associated with subscription 318a. Client 312a can receive updates to context 315a from the shared data store 320 via subscription 318a. Subscription 318a can communicate with the shared data source via communication link 320a. Client 313a can be a source and a consumer of context 316a, which is associated with subscription 319a. Client 313a can receive updates to context 316a from the shared data store 320 via subscription 319a. Subscription 319a can communicate with the shared data source via communication link 320a.

[0049] Referring to the example of device 300b, clients 311b, 312b, and 313b can correspond to different applications or processes running on device 300b. Client 311b can be a source of context 314b, which is associated with subscription 317b. Client 312b can be a sink or consumer of context 315b, which is associated with subscription 317b. Client 313b can be both a source and a consumer of context 316b, which is associated with subscription 317b. Subscription 317b thus differs from subscriptions 317a-319a, discussed above in relation to device 300a, in that a single subscription is associated with multiple contexts 314b, 315b, and 316b. A change in the status or condition associated with context 314b may cause client 311b to provide an updated context to the shared data store 320 via subscription 317b (or via another suitable agreement).Client 312b can receive updates to context 315b from shared data store 320 via subscription 317b. Client 313b can provide or receive updates to context 316b from shared data store 320 via subscription 317b. Subscription 317b can communicate with the shared data source via a communication link 320b, which can be any of the example communication links described above or any other suitable type of communication link.

[0050] Referring to the example of device 300c, clients 311c, 312c, and 313c can correspond to different applications or processes running on device 300c. Client 311c can be a source of context 314c, which is associated with subscription 317c. Client 311c can also be a consumer of context 315c, which may be associated with another subscription, 318c. Client 312c can be a sink or a consumer of context 315c, which is also associated with subscription 318c. Client 313c can be a consumer of context 315c, as well as a source and a consumer of context 316c, which may also be associated with subscription 318c.

[0051] Thus, a client can be associated with more than one context, and a single context can be associated with more than one client. Likewise, a subscription can be associated with more than one context, and in some cases, different applications may have different subscriptions for essentially the same contexts. Subscriptions 317b and 318c can communicate with the shared data source via a communication link 320c, which may be one of the exemplary communication links described above or another suitable type of communication link. Each of the device, client, context, and subscription configurations described above is exemplary, and various combinations, permutations, or variations of these arrangements may be provided in a particular application, as appropriate.

[0052] Fig. Figure 4 illustrates a variety of devices that synchronize contextual information across different communication links. Device 1 can be a smartphone (100d). Device 2 can be a notebook / laptop computer (100b). Device 3 can be a tablet (100c). Device 4 can be a desktop computer (100a). As in the examples explained above, this combination is merely illustrative, and any combination of more, fewer, and / or other devices could be provided.

[0053] In the example of Fig. Each device has six contexts that can be shared with other devices. In some applications, devices may have more or fewer contexts, the contexts may differ between devices, and so on. In the illustrated example, each context includes a key / value pair, commonly referred to as a "context key" and "context value," respectively. However, other data structures and value types may be used if appropriate for a particular application.

[0054] The six example contexts include a Device Utilization context, which can correspond to a device's workload, such as CPU or GPU utilization, or other performance metrics. The value for this context can be expressed as a percentage or another suitable data type that conveys the desired information with sufficient accuracy for applications that rely on such a context. Alternatively, it could be expressed as low, medium, high, or in another representation appropriate to the application. In the illustrated example, Device 1 has a Device Utilization state of 10%, which corresponds to relatively low utilization. Device 2 has a Device Utilization state of 85%, which corresponds to relatively high utilization. Devices 3 and 4 have a Device Utilization state of 0%, which corresponds to an inactive device.

[0055] The thermal state context can 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, this value could be expressed as a temperature, percentage, or another suitable data type. In the illustrated example, device 1 has a normal thermal state, which correlates with the context of relatively low device utilization for that device, as described above. Device 2 has a high thermal state, which correlates with the context of high device utilization for that device, as described above. Devices 3 and 4 have a normal thermal state, which correlates with the device utilization contexts for those devices, as described above.

[0056] The Location context can store a value corresponding to known locations, such as the user's work or home, as shown. Alternatively, the Location context could store the location in other formats, such as latitude / longitude, addresses, etc. Devices 1 and 2 have the location context "Work," indicating that the user took these devices to work. Devices 3 and 4 have the location context "Home," indicating that the user left these devices at home while at work with Devices 1 and 2. This example of a location difference between Devices 1 and 2 and Devices 3 and 4 also illustrates a possible difference in the communication path used for context synchronization. More specifically, Device 1 and Device 2, because they are in the same location (i.e.,Device 1 (the user's phone 100d and laptop 100b are located at the workplace) can exchange contexts with each other via a direct local connection 425, such as Bluetooth, WiFi, or a LAN connection. Since Device 3 and Device 4 are located in the same location (i.e., the user's desktop 100a and tablet 100c were left at home), they can also exchange contexts with each other via a direct local connection 427. However, for Device 1 or Device 2 to communicate with Device 3 or Device 4, an Internet or WAN connection 426 must be used. Notwithstanding the possibility of direct local communication for certain devices, in some cases, even devices located in the same location may communicate with certain devices in the same location via an Internet or WAN connection.

[0057] The AppX status context can indicate the status of a specific application on the device, such as whether the corresponding application (i.e., application "X") is open or closed. In other cases, an application status might indicate whether the application is installed or not, or include information such as a version number or other information about the application. In the illustrated example, Device 1, Device 2, and Device 4 have an AppX status of "Open," meaning that application "X" is open on these devices, while Device 3 has an AppX status of "Closed," meaning that application "X" is closed on this device.

[0058] The battery state of charge can be specified as a percentage representing the battery's charge level. Alternatively, this context could be expressed as voltage, as a high / medium / low indication, or in another suitable state representation. In some cases, an additional state or value for the battery state of charge could be provided to indicate whether the battery is charging, discharging, or in a stable state where it is neither charging nor discharging. In other cases, a client using the battery state of charge context could infer the charging, discharging, or stable state from the state of charge values ​​over a specific period.In the illustrated example, Device 1 has a battery charge level of 75% (mostly charged), Device 2 has a battery charge level of 35% (mostly discharged), Device 3 has a battery charge level of 35% (mostly discharged), and Device 4 has a battery charge level of N / A (not applicable), because desktop computers typically do not have system batteries. In some cases, a not applicable context may be specified as "zero," "not applicable," or a similar value. In other cases, a device may not have a context that is not applicable to it.

[0059] Finally, the contexts could include an AC context, indicating whether the device is currently connected to AC power. In the illustrated example, device 1 has an AC status of "False," indicating that it is not connected to AC power. Devices 2 and 3 have an AC status of "True," indicating that they are connected to AC power.

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

[0061] Fig. Figure 5 illustrates devices that receive and send contextual information. On the right side of Fig. Device B can send unfiltered contexts (Block 535). These contexts can be sent to a shared data store, represented by Cloud 207, which, as explained above, can be a centralized shared data store, a distributed shared data store, or a data store that combines aspects of both centralized and shared data stores. Unfiltered contexts are those for which updates can be sent to the shared data store regardless of the device's state. In Block 535, Device B can check whether the condition for sending filtered contexts is met. Context sending can be filtered for various reasons, depending on specific conditions. For example, some contexts might be so important or relevant that they should always be processed immediately.Other contexts may be important but not relevant at a given time, and therefore their transmission may be suppressed or postponed until they become more relevant. Other contexts may be less important and therefore sent with a delay, or their transmission may be prioritized at a later time. For example, some contexts may not be relevant and / or important enough to "wake up" a "sleeping" receiving device so that it can process them immediately. ("Sleeping" in this context means being put into a low-power state in which some or all processing functions may be suspended to reduce power consumption. Similarly, "waking up" in this context means exiting the sleep state, which results in increased power consumption.)In some cases, it may be preferable to send an update of such contexts at a later time, when the receiving system is woken up for another reason (e.g., by another user interaction). The conditions regarding relevance and importance can vary depending on the context. For example, if a device is left at home while a user is elsewhere, many or all of its contexts may be considered less relevant or important, as the user is unlikely to interact with the device. Another example is that contexts relating to background tasks have a lower priority compared to other tasks and are therefore sent less frequently or after more important or relevant tasks.In general, each context can be assigned both relevance and importance, which can control the frequency, planning, and prioritization of sending updates for each context.

[0062] On the left side of Fig. Device A can receive contexts from the shared data store represented by Cloud 207. Device A can both receive context updates from the shared data store and send context updates to the shared data store, as described with respect to Device B. Likewise, Device B can both send context updates to the shared data store and receive context updates from the shared data store, as described below with respect to Device A. In Block 531, Device A can subscribe to one or more contexts.These contexts can be relevant to this device, and the subscribed contexts can include all or only a subset of the contexts available in the shared data store, including all or only a subset of the contexts corresponding to any other device in the shared data store. Furthermore, the subscription can be customized for each context with information about its importance and relevance. Thus, the subscription could be configured to update more important contexts more frequently and less important contexts less frequently. Likewise, the subscription could be configured to delay, deprioritize, or suspend updates for contexts that are not currently relevant to the device in question.As with sending context updates described above, context importance can be used to prioritize updates, ensuring that more important information is received and updated more frequently, and that resources such as battery life, network bandwidth, etc., are allocated more to these more important contexts. Similarly, context relevance can be used by allowing contexts that are currently more relevant to be received or synchronized more frequently. If the situation changes and these contexts become less relevant, their fetch / synchronization frequency can be reduced or even suspended, which in turn allows for more effective use of limited resources such as power consumption, network bandwidth, processing power, and the like.

[0063] In Block 532, Device A can receive subscribed contexts from the shared data store. As mentioned above, this receiving can be dynamically modified and prioritized based on various conditions. Furthermore, a process running on Device A, such as a client of the subscribed contexts, can evaluate both the contexts and the conditions (Block 533) to determine, based on the evaluation results, whether an action should be performed (Block 534). In other words, the synchronized contexts can be evaluated, optionally in conjunction with additional local conditions, to determine if, when, and how a desired action should be performed. Such an action can relate to one or more background tasks running on the device and / or to one or more user-facing tasks on the device.Thus, the context synchronization framework described above can be used to deliver a variety of enhanced user experiences, some of which are listed as examples below. These examples are for illustrative purposes only, and many other applications of the context synchronization framework can be implemented using the same principles. Application data synchronization

[0064] Referring mainly to Fig. 4 and Fig. 5. An improved application data synchronization technique can be provided by using the context framework synchronization technique described above. For example, a user with a mobile device, such as the 100d smartphone, might take a series of photos and / or videos. Furthermore, the user may have configured their devices to synchronize photos added to a photo library on one device with other devices. Such photo synchronization may require the transfer of relatively large amounts of data. Therefore, a mobile device like a phone can be configured to delay the uploading of newly taken photos until the phone is connected to a Wi-Fi network, rather than a cellular data network, to avoid consuming potentially limited cellular data.Similarly, transferring large amounts of data over a mobile, Wi-Fi, or other data network can consume a significant amount of energy. Therefore, a mobile device such as a phone can be configured, for example, to delay the uploading of newly taken photos until the phone is connected to an AC power source, or such an upload can be allowed only when the phone's battery exceeds a certain charge level.

[0065] The delay described above in uploading newly taken photos from the phone can, however, lead to a less than optimal user experience. Suppose a user takes a series of photos with a mobile device, such as a phone, but then wants to review or edit these photos on another device, such as a laptop computer 100b, also owned by the user. In this case, when the user opens a photo processing application on the laptop 100b, a contextual information such as the AppPhoto status might change from "Closed" to "Open." This contextual update can then be propagated to the phone.When the photo editing application on the phone receives a notification via the updated context that the user is attempting to view photos on the laptop computer, the phone's photo application can reprioritize any workload so that it has a higher priority and initiate the upload of the newly taken photos, even if this upload might otherwise be delayed or prevented due to a less than optimal network connection, the battery level, or other conditions existing on the phone.

[0066] The context synchronization framework described above can enable even more finely tuned variations of the application data synchronization technique described above. Suppose that, in the same scenario as above (newly taken photos on the user's phone 100d), the user has also left their desktop computer powered on and the photo application running. Based solely on the logic described above, the AppPhoto status context "Open" on the desktop computer could trigger an upload of the photos from the user's phone 100d. However, in this case, other contexts indicate that this is not necessarily a desired action for the user. For example, the location context of the desktop computer 100a is "Home," while the location context of the phone 100d is "Work."Similarly, the device utilization context of desktop 100a has a value of 0%, indicating that the device is idle. This suggests that the user is not currently present, even if the photo processing application is running on the desktop computer, and therefore there is no urgent need to upload the newly captured photos (unless there is evidence of photo-related activity on laptop 100b, which is located at the user's presumed location based on the phone's location and has a device utilization level indicating interactive use). In some embodiments, the AppX state context updates from desktop computer 100a may be deprioritized or suppressed due to their lower importance or relevance, provided that the user is not currently using the application and / or the device.

[0067] The application data synchronization techniques described above need not be limited to newly taken photos or photo-related applications. Similar logic could be applied to other user-facing applications, including productivity applications such as word processors, spreadsheets, presentation software, and the like, enabling the synchronization of the underlying data files immediately upon opening a corresponding application on another device, even if synchronization might otherwise be delayed, deprioritized, or prevented due to other conditions.Similarly, this logic could be applied to media consumption software to enable the synchronization of consumed media and / or a specific point within the media, such as a timestamp in a video or audio file, a bookmark in an ebook, website, or article, a progress status in a game, and so on. In the broadest sense, data synchronization can be triggered by a context update indicating that a corresponding application has been opened on another device. However, the client subscribed to this context can employ additional logic, including evaluating other synchronized contexts and local conditions, to determine whether to perform an action based on these contexts and conditions. Furthermore, the contexts themselves can incorporate prioritization based on relevance and / or importance, delays, synchronization inhibition, and so forth.Furthermore, while schemes for synchronizing application data already exist, these are based on synchronization logic integrated into each individual application. In other words, each client relies on its own internal logic and data stores to perform the synchronization task. Conversely, the context synchronization techniques described above can provide a more widely available synchronization framework that allows multiple client applications to share context data, but process this context data differently with respect to their own internal logic and priorities to deliver a suitable user experience. Distributed data processing

[0068] Another application of the context synchronization framework described above is distributed data processing. An example of such distributed processing could again be based on the scenario where a user takes a series of new photos with a mobile device, such as a iPhone 100d. Distributed processing need not be limited to newly taken photos, or even photos in general, but is merely used as a practical example. In this example, a user might have a photo management application 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 could be based on metadata contained within the photos, such as GPS data, camera data, etc....or based on an analysis of the photographic information itself, such as machine learning processing of the image data to identify the subjects of the photos. Such processing can be relatively demanding in some cases, in terms of processing requirements, and / or it can be accelerated by using specialized hardware, such as graphics processing units (GPUs) or image processing units (IPUs), which may be located on a separate device. Even if suitable hardware is available on the local device, in some cases, due to limitations in power consumption or completion time, it may be possible or desirable to distribute part of the task to one or more other devices.

[0069] With renewed reference to Fig. 4 and Fig. 5. Assume that the user took the photos to be analyzed using distributed data processing with phone 100d. Assume, however, that laptop 100b, tablet 100c, and desktop computer 100a each also include suitable hardware and software to perform the desired analysis. By evaluating certain contexts from each device, phone 100d can, if necessary, request the other devices to assist in the analysis. Alternatively, each of the other devices can evaluate certain contexts to determine whether it should participate in the queued processing without a specific request from device 100d. Numerous contexts could be used alone or, more likely, in various combinations to facilitate distributed processing.For example, Desktop 100a has low device utilization, a normal thermal state, and is connected to AC power. Each of these contexts suggests that Desktop 100a could provide significant computing resources for the distributed processing task (photo analysis). Tablet 100c also has similar characteristics and could therefore contribute as well. However, if Tablet 100c had an AC context of "False," indicating that it is not connected to AC power, it might not be desirable for it to contribute to the distributed processing task, as this would further discharge the battery beyond its already low 35% charge level.Similarly, Laptop 100b exhibits high device utilization and a high thermal state, each suggesting that it may not be suitable for distributed data processing. However, if either of these parameters changes or is updated to a contextual value indicating that it would be appropriate for Device 2 to contribute to the distributed data processing task, then such devices could contribute to this task if such conditions occur.

[0070] Distributed data processing tasks can be, but do not have to be, background tasks. In some cases, it may be desirable for another device to contribute to a distributed task that is a foreground task or a user-facing / user-interactive task. For example, in a game or video editing task on a device with relatively limited graphics processing capabilities, the graphics-intensive processing could be offloaded to another device with a more powerful GPU. This can be particularly advantageous if the devices are located in the same location or if there is relatively high network bandwidth between them for other reasons. Additional contexts related to device capabilities, network connectivity, network speed, and so on can be used to inform and control such a distributed processing task. Optimized remote battery charging

[0071] The context synchronization examples described above relate to application-based processing. However, context synchronization can also be used to facilitate tasks related to device management. For example, context synchronization can simplify optimized remote battery charging. Fig. Figure 6 illustrates a generalized, optimized battery charging routine for an electronic device. More precisely, it shows Fig. Figure 6 shows a diagram 600 of the battery's state of charge on the vertical axis versus time on the horizontal axis. Different events in the charging process are indicated as points in time on the time axis. For example, before the device is connected to an external power source (such as the mains, an external battery pack, a car accessory adapter, etc.), the battery may discharge, as shown by curve segment 641. After the device is connected to the external power source, the battery charging process may begin, as shown by curve segment 642. Once connected to the external power source, the device can determine an estimated disconnection time 640, at which it is expected to be disconnected from the external power source. This can be used to intelligently adjust the charging process, as described in more detail below.Furthermore, the estimated separation time can be based, at least partially, on synchronized contexts, as also described in more detail below.

[0072] The determination of the estimated disconnection time 640 can be achieved in various ways based on sensor inputs (e.g., time of day, location, etc.) and a machine learning model or other program structure that considers previous activities or otherwise infers a likely disconnection time. This can include the use of synchronized contexts, as described above. For example, if a user typically plugs in a device at home around 10:00 PM and unplugs it around 6:00 AM, the device can infer that if it is plugged in at the user's residence around 10:00 PM, it will remain connected to the charging device until approximately 6:00 AM and adjust the charging process accordingly.The same applies if a user plugs in the device at their workplace around 8:00 AM and unplugs it around 12:00 PM, from which the system might infer that the user is usually at their desk at that time. Alternatively, if a device is plugged in at home while the user is at work, the system might infer, by comparing location-based contexts synchronized as described above, that the device will remain plugged in at least until the user arrives home. These inferences can be based on inputs other than time and location. For example, if a user plugs in their device and it detects that they are moving at a relatively high speed, the device might infer that they are in a car.Depending on the specific implementation of the machine learning model or other program structure, more or less detailed conclusions can be drawn. In any case, the conclusion can be used to modify the loading process as follows.

[0073] In the first example of the preceding paragraph, where the device concludes that it is located at the user's residence and was plugged in at approximately 10:00 PM, the device can assume that it will remain connected to mains power until approximately 6:00 AM. Therefore, the device does not need to charge at the maximum rate (represented by the slope of curve segment 642) to achieve a full charge as quickly as possible. In fact, it may be desirable to reduce the charging rate and / or interrupt the charging process for a certain period, as shown in curve segment 643, to delay the battery from reaching a full charge. For example, the service life of a battery (i.e., battery state or the number of charge cycles over which essentially full capacity is maintained) can be extended by reducing the time it takes to fully charge the battery.Therefore, in the example of optimized battery charging of . Fig. 6. Battery charging may be interrupted during interval 643. Additionally or alternatively, charging may also be slowed down or interrupted if the user plugs in a device but then leaves for another location, which is determined at least partially by synchronized contexts, or the estimated separation time may be recalculated based on the location context and other queues.

[0074] The estimated disconnection time 640 can also be used by the device to resume charging at a selected time to ensure that the battery reaches a fully charged state before the estimated disconnection time 640 (represented by state of charge / curve segment 645). This resumption of charging is represented by curve segment 644. This charging segment may occur at a reduced rate, for example, because the battery is closer to full charge, as indicated by the shallower slope of the resumed charging segment 644 compared to the original charging segment 642.In any case, the machine learning model or other program structure controlling the optimized battery charging process can consider the expected charging rate and the estimated disconnection time to ensure the battery is fully charged before the user disconnects the device from the external power source. This can be achieved by choosing an estimated disconnection time earlier than the likely or usual disconnection time and / or by ensuring the battery is fully charged before the estimated disconnection time. Furthermore, the estimated disconnection time can be updated by synchronized contexts that imply user behavior, such as a user with a location indicating they are on their way home or have arrived home, even though, according to a normal usage pattern, the user would not be at home during that time.As soon as the user disconnects the device from the external power source, the battery can begin to discharge, as shown in curve segment 646.

[0075] The in relation to Fig. The optimized battery charging technique described in Section 6 is "optimized" in the sense that it can improve battery health by reducing the time the battery spends in a fully charged state. As suggested above, the optimized battery charging routine for an electronic device can be further optimized to adapt the battery charging to contextual information, as described above. The examples mentioned above relate to the user's location or other location-based contexts, thus enabling optimized "remote" battery charging when a connected device is located in a different location than the user. Battery charging optimizations applicable based on such contexts can include adjusting the estimated disconnection time, slowing the charging rate, pausing or resuming the charging process, and so on.Although location-based contexts may be most useful for optimizing battery charging, other synchronized contexts can also be beneficial. For example, battery charging profiles can be recalibrated to allow for a full battery charge even when the device is experiencing significant power consumption for a distributed processing task.

[0076] Otherwise, the adaptive charging technology shown can proceed as described above. Therefore, in the example of optimized battery charging from Fig. 6. Battery charging may be interrupted during the interval corresponding to curve segment 643, which can be determined at least partially from received contextual information for other devices. Battery charging may continue during the interval corresponding to curve segment 644 to ensure that the battery is fully charged, as represented by curve segment 645 before the estimated disconnection time 640 and the actual disconnection time, after which the battery may begin discharging, as represented by curve segment 646.

[0077] Under certain operating conditions, it may be desirable to prevent or otherwise forgo battery charging optimization. For example, if the battery's state of charge falls below a certain discharge threshold (e.g., below 30%, 25%, etc.), it may be desirable to begin charging immediately to ensure the device is powered regardless of contextual information. Similarly, once the battery reaches a state of charge corresponding to a certain threshold (e.g., 75%, 80%, etc.), it may be desirable to allow the battery to fully charge immediately before the estimated disconnection time, regardless of the current status of the contextual information. Alternatively, it may be desirable to accelerate the predicted use / disconnection time based on a change in contextual information that occurs during the interrupted interval.

[0078] Fig. Figure 7 shows a flowchart of an optimized battery charging routine 700 for an electronic device that adjusts the battery charge. This flowchart represents functionality that can be implemented by the electronic device 100, including, for example, the processor 101, which may include one or more processors as described above. In some cases, different functions may be shown in the flowchart. Fig. The functions shown in Figure 7 can be performed by different processors of a multiprocessor system 100 or by a separate processor, microcontroller, or other charger control switching logic. As just one example, a processor 101, which includes a CPU, a GPU, and an NPU (Neural Processing Unit), can use the NPU to perform certain machine learning computational operations. In each case, a synchronized context-based adaptive optimized battery charging routine 700 can 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 to initiate the optimized charging routine as described above.These signals can include indications of a connection to an external power source, as well as other signals, including synchronized remote contexts, which allow the processor to make predictions about the expected duration of the connection to the power source.

[0079] For example, a location signal might indicate that the device is at a specific location, while a synchronized context from another device might indicate that the user is at a different location. Alternatively, a changing location signal or a speed sensor might indicate that the device is connected to a power source for vehicle accessories. Similarly, a changing location context, or aggregated location contexts for another device more directly associated with a user's location, might indicate that the user is returning, which in turn means that the predicted disconnection time may need to be updated. Other synchronized context signals from other devices, such as other devices connected to the user, may also be used where appropriate.These and other signals can be processed by a machine learning model to attempt to identify the power source and predict a disconnection time, as specified in Block 752.

[0080] As indicated above, the estimated disconnection time can be derived from external signals, including context signals synchronized by another device. For example, a time signal corresponding to late evening and a location signal corresponding to a user's home, along with a pattern of previous usage, can indicate that a nightly charging cycle is beginning. Similarly, a time signal corresponding to midday, combined with a context signal indicating that one or more other devices connected to the user are in a different location (e.g., at their workplace), while the device performing the optimized charging is in a different location (e.g., at their home office), can indicate the start of a nightly charging cycle.(e.g., at home), can indicate that the device will not be used at least until the user returns, which can be predicted based on past usage patterns and / or a change in synchronized contexts. Alternatively, connecting the device at an unusual time or in an unusual place, as well as a low battery charge, can indicate that the user needs to charge the device as soon as possible. In either case, the predicted disconnection or usage time can be used to determine desired and / or undesired charging windows (Block 754), which may correspond to preferred times when the battery is in certain states. Once the desired and / or undesired charging windows are identified (Block 754), the processor can operate the device's charging system to charge the battery during the desired windows, as shown in Block 755.In some cases, the processor can also provide the user with information about the loading process and the desired loading windows (Block 756). Examples of such communication and optional user interaction are discussed further below. Fig. 8 explained in more detail.

[0081] The electronic device 100 can be configured to implement an optimized battery charging routine that uses synchronized contexts, as described above, to inform the optimized battery charging routine. More specifically, the electronic device 100 can include a charging controller as part of the power supply system 108. The charging controller can include electronic switching logic (including analog, digital, and / or programmable switching logic) configured to control whether, when, and at what rate a battery of the electronic device 100 is charged. It should be noted that, in addition to or instead of allowing or preventing charging as described above, the optimized battery charging routine could also be used to control the rate at which the battery is charged, at least in response to the synchronized context signals.Instead of completely preventing battery charging during the interruption time interval of 643, the system could be configured to slow down battery charging during such intervals and increase the battery charging speed as the estimated disconnection / use time of 640 approaches.

[0082] Fig. Figure 8 illustrates an electronic device 100 that communicates parameters of an optimized battery charging routine to a user. Fig. Figure 8 illustrates the electronic device 100 as a smartphone, but it could actually be any of a variety of electronic devices, such as a tablet computer, a notebook, or a laptop computer, etc. For example, the electronic device 100 could use a display 104 to present the user with a message 857 indicating a time when the charging process is expected to be completed. In some cases, the electronic device 100 could present a control element 858, such as a UI button, that would allow the user to bypass the optimized charging routine and complete the charging process as quickly as possible. In some embodiments, the control element 858 and the message 857 could be part of the same UI element, such as a GUI message / button, etc.In other cases, one or more other output devices of the electronic device 100 could be used to provide the user with the notification, and one or more other input devices of the electronic device 100 could be used to receive input from the user indicating that the user wishes to bypass the optimized charging device and complete the charging process as quickly as possible. This could be used, for example, to allow another user who is also using the remote device to expedite the charging process so that this second user can use the device even if the primary user is not in the same location. There could also be a cross-device optimized charging control. For example, on a device that the user carries with them (e.g.,a smartphone), provide a user interface that can control whether a remotely located device should be charged immediately, which would otherwise undergo a delayed charging process as part of a remotely optimized battery charging scheme.

[0083] Message 857 could also present additional information to the user. For example, message 857 could specifically indicate that battery charging was interrupted due to a status derived from one or more synchronized context signals, and / or that charging was paused to optimize battery health. Enhanced energy saving

[0084] In some cases, synchronized context information, as described above, can be used to enable an enhanced power-saving mode for a device. However, an enhanced power-saving mode can also be implemented without using synchronized context information, as described above. Fig. Figure 9 shows a flowchart / block diagram 900 that enables a device as described above to implement an enhanced power-saving mode. The various activities described in flowchart / block diagram 1000 can be performed by the device, in particular by one or more processors of the device, using data stored in one or more memory or storage locations of the device and / or retrieved through one or more communication or I / O interfaces of the device.

[0085] Starting with block 961, the device can store, otherwise obtain, or retrieve information about the device's usage history, which may optionally include synchronized contextual information as described above. This can occur, for example, when one or more processes running on a processor of the device retrieve usage data from local storage / datastore and / or remote storage / datastore. This usage history data (and optionally synchronized contextual data) can be provided to a usage predictor 962. The usage 962 can also be an operation or process running on a processor of the device. As further described below with regard to Fig. 10 and Fig. As described in more detail in section 11, the usage predictor can use the usage history data (and optionally synchronized context data) to determine whether a prolonged period of inactivity is predicted. If so, the usage predictor 962 can transmit this information to a power management unit 963, which may be, for example, another process running on a processor of the device. In some cases, this may be a process running on a power management microcontroller or other suitable control switching logic.

[0086] The power management unit 963 can also monitor various sensors, inputs, and / or optional remote contextual information associated with the device to determine when a device user becomes inactive (block 964). For example, the power management unit can detect user inactivity by observing the absence of user input. For handheld devices, user inactivity can also be inferred from the detection of a lack of movement, such as putting the device down. Alternatively, ambient light sensors, microphones, radio signals from peripheral devices, etc., can be used to infer user inactivity. Furthermore, synchronized contexts, as described above, can optionally be part of this process. For example, for a device with the location "Home" (e.g., Tablet 100c in Fig. 4), while other devices connected to the user have a different location, for example “work” (e.g., phone 100d and laptop 100b in Fig. 4) suggests that it may have been inactive for an extended period. The precise period of inactivity can be inferred from previous usage data and / or updates to synchronized context signals. These and other indicators of inactivity are all found in block 964 in Fig. 9 shown.

[0087] In at least some cases, the power management unit 963 can communicate bidirectionally with the usage predictor 962. Thus, when the power management unit 963 detects user inactivity, it can query the usage predictor 962 to determine when user activity is expected to resume or, alternatively, how long the period of user activity is likely to last. This may involve an exchange of information that the power management unit 963 receives from the user inactivity detector 964 with the usage predictor 962. In other configurations, the data, signals, and information that trigger user inactivity detection may be provided to or available to the usage predictor 962 in other ways.The Usage Predictor 962 can implement a variety of programming and logic structures to derive the duration of user inactivity, including various combinations of traditional programming, machine learning algorithms, neural networks, fuzzy logic processing, and the like.

[0088] Once the usage predictor 962 has determined that a period of "extended" user inactivity is predicted, it can notify the power management unit 963 that power-saving optimizations 965 can be implemented for a period up to the expected duration of the user inactivity period, but no longer. These power-saving optimizations can include a variety of activities normally performed by the device that can be slowed down, postponed, or otherwise delayed or interrupted for all or at least part of the predicted extended inactivity period. For example, integrated radios related to cellular, Wi-Fi, Bluetooth, ultra-wideband (UWB), etc., can be turned off or placed into a power-saving mode.Background tasks such as retrieving emails or text messages, synchronizing application data, processing newly received data, etc., can be slowed down (to reduce the power consumption of the respective task) or postponed (to eliminate the power consumption of that particular task until it is resumed). Furthermore, user notifications can be modified. For example, display notifications that would require the display to be enabled can be suppressed—although it might still be desirable to provide audible or haptic notifications. Depending on the power consumption of the various notification modes (e.g., visual, audible, haptic, etc.) and the expected or configured notification settings, one or all notification modes can be suppressed as needed.The enhanced power-saving mode can be configured to modify the performance of individual or all subsystems, foreground tasks, background tasks, user notifications, etc., of an electronic device according to the user's and / or the system's implementers' requirements. For example, if the system is configured to regularly wake from a non-enhanced power-saving mode to perform a background task, these intervals can be extended, or certain wake-up operations can be prevented in enhanced power-saving mode.

[0089] Some electronic devices have a power-saving mode in which certain background tasks, notifications, radio or other system states are modified to provide lower power consumption. However, the enhanced power-saving mode described above differs from such systems at least in that the existing power-saving modes are usually selected or manually configured by the user, whereas the enhanced power-saving modes described above are triggered when the device itself infers a prolonged period of user inactivity.

[0090] Fig. Figure 10 shows a flowchart / block diagram 1000 for switching to an extended power-saving mode. The various activities described in flowchart / block diagram 1000 can be performed by the device, specifically by one or more of the device's processors, using data stored in one or more of the device's memory or storage locations and / or retrieved through one or more of the device's communication or I / O interfaces. Block 961 corresponds to retrieving or otherwise obtaining information about the device's usage history and optionally synchronized contextual information, as described above. Block 962 corresponds to the usage predictor described above.The usage predictor can analyze usage history and optionally synchronized contextual information (as well as any other signals indicating user inactivity) to make a prediction about a prolonged period of inactivity. As mentioned above, the usage predictor 962 can implement any suitable combination of algorithms, including machine learning algorithms, to perform this prediction. These predictions can be made continuously, at regular intervals, or in response to a specific request, such as from the power management unit 963. If a prolonged period of inactivity is predicted (block 1073), the power-saving optimizations can be implemented according to the extended power-saving mode (block 965). These power-saving optimizations can include all the optimizations described above or any other suitable technique for reducing power consumption.Otherwise, the usage predictor 962 can continue to make continuous, periodic, or requested usage predictions.

[0091] Fig. Figure 11 shows a flowchart / block diagram 1100 for exiting an extended power-saving mode. The various activities described in flowchart / block diagram 1000 can be performed by the device, specifically by one or more of the device's processors, using data stored in one or more of the device's memory or storage locations and / or retrieved through one or more of the device's communication or I / O interfaces. Starting with block 961, the usage history (including current usage signals such as user interaction with an I / O device, motion or ambient light sensors, etc.) and optionally synchronized context signals can be analyzed for user activities associated with the device (block 1182).When user activity associated with the present device is detected, the device can exit the extended reduced energy state (block 1186) by, for example, providing appropriate signaling to the power management unit 963 (. Fig. 9).

[0092] Otherwise, if no user activity is detected, predictor 962 (or another processing element of the device) can determine whether a user routine has been set. For example, a user might set a device to enter an extended power-saving mode at specific intervals. An example of such an interval for a device like a mobile phone might be overnight while the user sleeps. Alternatively or additionally, for a device that is typically left at home or not used during the workday, such as a personal tablet, the workday period on weekdays might be set as the period of expected inactivity. Conversely, for a work device, such as a laptop, the nights and / or weekends might be set by the user as the times when the user's routine would leave such devices inactive.The above examples are not exhaustive, and a user could specify any period or periods as times when the device is normally inactive as part of the user's routine.

[0093] In any case, if a user routine is defined (block 1183), it can be determined whether the end of the inactivity period associated with user time has been reached (block 1185). If so, the extended reduced power state can be terminated (block 1186); otherwise, the usage history, usage signals, and optional context information can continue to be monitored (blocks 961, 1182). Referring again to block 1183, if no user routine has been defined, it can be determined whether the time predicted for the end of the extended inactivity period has been reached (block 1184). If so, the extended reduced power state can be terminated (block 1186); otherwise, the usage history, usage signals, and optional context information can continue to be monitored (blocks 961, 1182).In summary, exiting the extended reduced energy state can be triggered by one of the following: (1) user activity (e.g., detected user interaction with the device), (2) the end of a user-defined routine period of extended inactivity, or (3) the end of a device-predicted period of extended activity. Furthermore, the user routine can be a periodic or recurring period, but this need not be the case. In some instances, the user can manually configure the device to enter a period of extended inactivity, specifying a time at which such a period of extended inactivity should end.

[0094] As used at various points in this disclosure, the term “machine learning” can refer to algorithms, statistical models, and the like that computer systems (such as the electronic device 100) can use to perform a particular task, with or without the use of explicit instructions. For example, a machine learning process can generate a mathematical model based on a sample of data known as “training data” to make predictions or decisions without being explicitly programmed to perform this task. Depending on the conclusions to be drawn, the electronic device 100 (or a subsystem or associated device thereof) can implement different forms of machine learning. For example, in some embodiments (e.g.,For example, if certain known examples exist that correlate with future predictions or estimates that the machine learning engine might generate, a machine learning engine implements supervised machine learning. In supervised machine learning, a mathematical model of a dataset contains both inputs and desired outputs. This data is referred to as "training data" and can contain a set of training examples. Each training example can have one or more inputs and a desired output, also known as a monitoring signal. In a mathematical model, each training example is represented by an array or a vector, sometimes called a feature vector, and the training data is represented by a matrix.Through iterative optimization of an objective function, supervised learning algorithms can learn a function that can be used to predict an output associated with new inputs. An optimized function can enable the algorithm to correctly determine the output for inputs that were not part of the training data. An algorithm that improves the accuracy of its outputs or predictions over time has supposedly learned to perform this task.

[0095] Supervised learning algorithms can include classification and regression techniques. Classification algorithms can be used when outputs are limited to a finite number of values, and regression algorithms can be used when outputs have a numerical value within a range. Similarity learning is an area of ​​supervised machine learning closely related to regression and classification, but its goal is to learn from examples using a similarity function that measures how similar or related two objects are. Similarity learning finds application in rankings, recommendation systems, visual identity tracking, facial verification, and speaker verification.

[0096] Additionally and / or alternatively, in some situations it can be advantageous for the machine learning engine to use unsupervised learning (e.g., when certain output types are unknown). Unsupervised learning algorithms use a dataset containing only inputs and find structures in the data, such as the grouping or clustering of data points. The algorithms therefore learn from test data that has not been labeled, classified, or categorized. Instead of reacting to feedback, unsupervised learning algorithms identify commonalities in the data and react based on the presence or absence of such commonalities in each new data element.

[0097] This means the machine learning engine can perform cluster analysis, which involves assigning a set of observations to subsets (called clusters) such that observations within the same cluster are similar with respect to one or more predefined criteria, while observations from different clusters are different. Different clustering techniques make different assumptions about the structure of the data, often defined by a similarity metric and evaluated, for example, according to internal compactness or the similarity between members of the same cluster, and separation, the difference between clusters. In additional or alternative implementations, the machine learning engine can implement other machine learning techniques, such as those based on estimated density and graph connectivity.

Claims

[1] Method for reducing the power consumption of an electronic device (100), wherein the method is carried out by one or more processors (101) of the electronic device (100), and comprising: Analyzing device usage data associated with the device (100) to predict a prolonged period of user inactivity, wherein the usage data includes synchronized contextual information from one or more remote devices associated with a user of the device; and Switching to an extended reduced energy state by implementing one or more power-saving optimizations for at least part of the predicted period of prolonged user inactivity, wherein the one or more power-saving optimizations slow down, delay or interrupt one or more normal activities normally performed by the device (100). [2] Method according to claim 1, further comprising exiting the extended reduced energy state by suspending one or more energy-saving optimizations before the end of the predicted extended period of user inactivity. [3] Method according to claim 1, wherein one or more energy-saving optimizations include slowing down or delaying background tasks. [4] Method according to claim 1, wherein the one or more energy-saving optimizations comprise changing at least one of the acoustic, visual or haptic notifications provided to a user. [5] Method according to claim 1, wherein the one or more energy-saving optimizations comprise delaying or preventing wake-up events of the device (100). [6] Method according to claim 1, wherein the synchronized context information includes information corresponding to a user's location that can be compared to a location of the device (100) to trigger the transition to the extended reduced energy state. [7] Method according to claim 1, wherein the one or more energy-saving optimizations consist of: Switching off or placing one or more radio devices of the electronic device (100) into a power-saving mode. [8] Method for reducing the power consumption of an electronic device (100), wherein the method is carried out by one or more processors (101) of the electronic device (100), and comprising: Analyzing device usage data associated with the device (100) to predict a prolonged period of user inactivity, wherein the usage data includes contextual information from one or more remote devices associated with a user of the device (100); and Switching to an extended reduced energy state by implementing one or more power-saving optimizations for at least part of the extended period of prolonged user inactivity, wherein the one or more power-saving optimizations slow down, delay, or interrupt one or more normal activities normally performed by the device (100); and Exiting the extended reduced power state by suspending one or more power-saving optimizations before the end of the predicted extended period of user inactivity and at least partially in response to context information. [9] Method according to claim 8, wherein the synchronized context information includes information corresponding to a user's location that can be compared to a location of the device to trigger the transition to the extended reduced energy state. [10] The method of claim 8, wherein the one or more energy-saving optimizations include one or more elements selected from the group consisting of: Switching off or placing one or more radio devices of the electronic device (100) into a power-saving mode; Slowing down or delaying background tasks; Changing at least one of the acoustic options provided to a user, visual or haptic notifications; and Delaying or preventing wake-up events of the device (100). [11] Electronic device (100) comprising one or more processors (101), a memory (102), a storage device, one or more input / output devices (105; 104) and a power supply system (108), the electronic device (1000) further comprising: a usage predictor that analyzes device usage data to predict a prolonged period of user inactivity, wherein the usage data includes synchronized contextual information from one or more remote devices associated with a user of the device; and a power management unit (963) which causes the device (100) to enter an extended reduced power state for at least part of the extended period of prolonged user inactivity by implementing one or more power-saving optimizations, wherein the one or more power-saving optimizations slow down, delay or interrupt one or more normal activities normally performed by the device (100); wherein the usage predictor (982) includes one or more processes running on the one or more processors (101), and the power management unit (963) includes one or more processes running on the one or more processors (101). [12] Electronic device (100) according to claim 11, wherein the power management unit (963) further causes the device (100) to exit the extended reduced energy state by suspending one or more power-saving optimizations before the end of the predicted extended period of user inactivity. [13] Electronic device (100) according to claim 12, wherein the synchronized context information includes information corresponding to a user's location that can be compared to a location of the device (100) to trigger the transition to the extended reduced energy state. [14] Electronic device (100) according to claim 12, wherein the one or more energy-saving optimizations include one or more elements selected from the group consisting of: Switching off or putting one or more radio devices of the electronic device into a power-saving mode; Slowing down or delaying background tasks; Changing at least one of the audible, visual, or haptic notifications provided to a user; and Delaying or preventing wake-up events of the device (100).

Images