EFFICIENT CONTEXT MONITORING

• US 20200137193A1
• Filed: 12/26/2019
• Published: 04/30/2020
• Est. Priority Date: 06/05/2015
• Status: Active Grant

• Current Assignee: Apple Inc.
• Original Assignee: Apple Inc.
• Inventors: Brown, Alexander Barraclough, Vaishampayan, Umesh S.
• Granted Patent: US 10,986,211 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 11/30 Monitoring
• CPC Class Codes: G06F 11/3024 where the computing system component is a central processing unit [CPU]
• CPC Class Codes: G06F 11/3055 Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available error or fault processing without redundancy G06F11/0703; error detection or correction by redundancy in data representation G06F11/08; error detection or correction by redundancy in operation G06F11/14; error detection or correction by redundancy in hardware G06F11/16
• CPC Class Codes: G06F 8/61 Installation
• CPC Class Codes: G06F 9/445 Program loading or initiating bootstrapping G06F9/4401; security arrangements for program loading or initiating G06F21/57
• CPC Class Codes: G06F 9/461 Saving or restoring of program or task context
• CPC Class Codes: G06F 9/542 Event management; Broadcasting; Multicasting; Notifications
• CPC Class Codes: G06F 9/546 Message passing systems or structures, e.g. queues
• CPC Class Codes: G06N 7/01 Probabilistic graphical models, e.g. probabilistic networks
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066
• CPC Class Codes: H04L 67/55 Push-based network services
• CPC Class Codes: H04L 67/63 Routing a service request depending on the request content or context
• CPC Class Codes: H04W 24/02 Arrangements for optimising operational condition
• CPC Class Codes: H04W 52/0264 by selectively disabling software applications
• CPC Class Codes: Y02D 10/00 Energy efficient computing, e.g. low power processors, power management or thermal management
• CPC Class Codes: Y02D 30/70 in wireless communication networks

Abstract

Disclosed are systems, methods, and non-transitory computer-readable storage media for efficiently monitoring the operating context of a computing device. In some implementations, the context daemon and/or the context client can be terminated to conserve system resources. For example, if the context daemon and/or the context client are idle, they can be shutdown to conserve battery power or free other system resources (e.g., memory). When an event occurs (e.g., a change in current context) that requires the context daemon and/or the context client to be running, the context daemon and/or the context client can be restarted to handle the event. Thus, system resources can be conserved while still providing relevant context information collection and callback notification features.

Claims

1. A method comprising:

obtaining, by a context daemon executing on a computing device, current context information related to a current state of the computing device;

in response to determining that the current context information corresponds to a first context callback request associated with a context client, determining, by the context daemon, whether a communication session exists with the context client; and

in response to determining that the communication session does not exist with the context client, sending, by the context daemon, a restart message to a launch daemon requesting that the launch daemon restart the context client.

2. The method of claim 1, wherein the current context information includes one or more context items derived from:

a current hardware state of the computing device, a current software state of the computing device, or a combination thereof.

3. The method of claim 1, wherein the first context callback request specifies conditions for notifying the context client based on the current context information obtained by the context daemon.

4. The method of claim 3, further comprising:

in response to determining that the current context information corresponds to the first context callback request and after the context client is restarted, notifying, by the context daemon, the context client that the conditions of the first context callback request are satisfied.

5. The method of claim 1, further comprising:

prior to obtaining the current context information, receiving, at the context daemon, the first context callback request from the context client, the first context callback request initiating a first communication session between the context client and the context daemon.

6. The method of claim 5, further comprising:

determining whether the context client is idle; and

terminating the context client in response to a determination that the context client is idle after the context daemon receives the first context callback request.

7. The method of claim 1, further comprising:

after the context client has been restarted, receiving, by the context daemon, a second context callback request from the context client;

comparing the second context callback request to the current context information; and

in response to determining that the current context information corresponds to the second context callback request, notifying the context client that a condition of the second context callback request is satisfied.

8. A non-transitory computer-readable medium comprising instructions that, when executed by a computing device, cause a context daemon of the computing device to:

obtain current context information related to a current state of the computing device;

in response to determining that the current context information corresponds to a first context callback request associated with a context client, determine whether a communication session exists with the context client; and

in response to determining that the communication session does not exist with the context client, send a restart message to a launch daemon requesting that the launch daemon restart the context client.

9. The non-transitory computer-readable medium of claim 8, wherein the current context information includes one or more context items derived from:

a current hardware state of the computing device, a current software state of the computing device, or a combination thereof.

10. The non-transitory computer-readable medium of claim 8, wherein the first context callback request specifies conditions for notifying the context client based on the current context information obtained by the context daemon.

11. The non-transitory computer-readable medium of claim 10, further comprising instructions, which when executed, cause the context daemon to:

in response to determining that the current context information corresponds to the first context callback request and after the context client is restarted, notify the context client that the conditions of the first context callback request are satisfied.

12. The non-transitory computer-readable medium of claim 8, further comprising instructions, which when executed, cause the context daemon to:

prior to obtaining the current context information, receive the first context callback request from the context client, the first context callback request initiating a first communication session between the context client and the context daemon.

13. The non-transitory computer-readable medium of claim 12, further comprising instructions, which when executed, cause the context daemon to:

determine whether the context client is idle; and

terminate the context client in response to a determination that the context client is idle after the context daemon receives the first context callback request.

14. The non-transitory computer-readable medium of claim 8, further comprising instructions, which when executed, cause the context daemon to:

after the context client has been restarted, receive a second context callback request from the context client;

compare the second context callback request to the current context information; and

in response to determining that the current context information corresponds to the second context callback request, notify the context client that a condition of the second context callback request is satisfied.

15. A computing device comprising:

one or more hardware processors; and

logic, which when executed by the one or more hardware processors on the computing device, causes a context daemon to;

obtain current context information related to a current state of the computing device;

in response to determining that the current context information corresponds to a first context callback request associated with a context client, determine whether a communication session exists with the context client; and

in response to determining that the communication session does not exist with the context client, send a restart message to a launch daemon requesting that the launch daemon restart the context client.

16. The computing device of claim 15, wherein the current context information includes one or more context items derived from:

a current hardware state of the computing device, a current software state of the computing device, or a combination thereof.

17. The computing device of claim 15, wherein the first context callback request specifies conditions for notifying the context client based on the current context information obtained by the context daemon.

18. The computing device of claim 17, wherein the logic is further executed to cause the context daemon to:

in response to determining that the current context information corresponds to the first context callback request and after the context client is restarted, notify the context client that the conditions of the first context callback request are satisfied.

19. The computing device of claim 15, wherein the logic is further executed to cause the context daemon to:

prior to obtaining the current context information, receive the first context callback request from the context client, the first context callback request initiating a first communication session between the context client and the context daemon.

20. The computing device of claim 19, wherein the logic is further executed to cause the context daemon to:

determine whether the context client is idle; and

terminate the context client in response to a determination that the context client is idle after the context daemon receives the first context callback request.