System and method for application driven power management among intermittently coupled interoperable electronic devices

• US 20060010453A1
• Filed: 06/08/2005
• Published: 01/12/2006
• Est. Priority Date: 06/08/2004
• Status: Active Grant

• Current Assignee: David E. Kahn
• Original Assignee: DARTDevices Corp. (Covia Labs, Inc.)
• Inventors: Bernstein, Bruce, Mirabella, Richard, Pieb, Wolfgang, Illowsky, Daniel, Wenocur, Michael, Tiberi, Richard, Sidney, Raymond
• Granted Patent: US 7,409,569 B2
• Time in Patent Office: Days
• US Class Current: 719/318
• CPC Class Codes: G06F 1/3203 Power management, i.e. event-based initiation of a power-saving mode
• CPC Class Codes: G06F 11/2082 Data synchronisation
• CPC Class Codes: G06F 16/2365 Ensuring data consistency and integrity
• CPC Class Codes: G06F 21/445 by mutual authentication, e.g. between devices or programs
• CPC Class Codes: G06F 21/6218 to a system of files or objects, e.g. local or distributed file system or database
• CPC Class Codes: G06F 2209/5015 Service provider selection
• CPC Class Codes: G06F 2221/2113 Multi-level security, e.g. mandatory access control
• CPC Class Codes: G06F 2221/2149 Restricted operating environment
• CPC Class Codes: G06F 8/10 Requirements analysis; Specification techniques
• CPC Class Codes: G06F 8/20 Software design
• CPC Class Codes: G06F 8/24 Object-oriented
• CPC Class Codes: G06F 8/30 Creation or generation of source code
• CPC Class Codes: G06F 8/41 Compilation
• CPC Class Codes: G06F 8/61 Installation
• CPC Class Codes: G06F 8/63 Image based installation; Cloning; Build to order
• CPC Class Codes: G06F 8/658 Incremental updates; Differential updates
• CPC Class Codes: G06F 8/71 Version control security arrangements therefor G06F21/57; Configuration management
• CPC Class Codes: G06F 9/449 Object-oriented method invocation or resolution
• CPC Class Codes: G06F 9/4843 by program, e.g. task dispatcher, supervisor, operating system
• CPC Class Codes: G06F 9/5011 the resources being hardware resources other than CPUs, Servers and Terminals
• CPC Class Codes: G06F 9/5027 : the resource being a machine, e.g. CPUs, Servers, Terminals
• CPC Class Codes: G06F 9/5044 : considering hardware capabilities
• CPC Class Codes: G06F 9/5072 : Grid computing
• CPC Class Codes: G06F 9/54 : Interprogram communication
• CPC Class Codes: G06F 9/541 : via adapters, e.g. between incompatible applications
• CPC Class Codes: G06F 9/542 : Event management; Broadcasting; Multicasting; Notifications
• CPC Class Codes: H04L 65/1083 : In-session procedures
• CPC Class Codes: H04L 65/1094 : Inter-user-equipment sessions transfer or sharing
• CPC Class Codes: H04L 65/80 : Responding to QoS
• CPC Class Codes: H04L 67/10 : in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46
• CPC Class Codes: H04L 67/104 : Peer-to-peer [P2P] networks
• CPC Class Codes: H04L 67/1068 : Discovery involving direct consultation or announcement among potential requesting and potential source peers
• CPC Class Codes: H04L 67/1072 : Discovery involving ranked list compilation of candidate peers
• CPC Class Codes: H04L 67/1095 : Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• CPC Class Codes: H04L 67/14 : Session management for real-time applications in data packet communications networks H04L65/1066
• CPC Class Codes: H04L 67/51 : Discovery or management thereof, e.g. service location protocol [SLP] or web services
• CPC Class Codes: H04L 69/08 : Protocols for interworking; Protocol conversion
• CPC Class Codes: H04L 69/24 : Negotiation of communication capabilities
• CPC Class Codes: H04L 69/328 : in the presentation layer [OSI layer 6]
• CPC Class Codes: H04N 21/41265 : having a remote control device for bidirectional communication between the remote control device and client device unidirectional remote control device H04N21/42204
• CPC Class Codes: Y02D 10/00 : Energy efficient computing, e.g. low power processors, power management or thermal management
• CPC Class Codes: Y02D 30/00 : Reducing energy consumption in communication networks

Abstract

System, device, method, and computer program and computer program products for providing communicating between devices having similar or dissimilar characteristics and facilitating seamless interoperability between them. Computer program software and methods of and systems and devices for sharing of content, applications, resources and control across similar and dissimilar permanently or intermittently connected electronic devices. Devices, systems, appliances, and the like communicating and/or interoperating within the framework provided. Application driven power management. Applications built using linear tasking and/or vertical layering as embodied at least partially in n interoperability framework, keep track of their exact response time needs so that efficient power management techniques can extend the lifetime of batteries, limit amount of energy consumed, or limit amount of heat generated on devices.

Claims

1. A method for device energy and power management and energy and power consumption reduction comprising:

establishing an event driven runtime environment within at least one device for which the energy and power management and consumption reduction is to be achieved;

generating and maintaining at least one event queue identifying all synchronous and asynchronous processing events and associated minimum expected processing times for the processing events in the queue; and

selecting a final minimum estimated response time based on the expected minimum synchronous and asynchronous event processing times in the queue.

2. A method as in claim 1, further comprising:

searching through all the events on a first asynchronous event queue that drive all the asynchronous processing and collect the minimum time needed before any of the asynchronous events need to be processed;

searching through all the events on a second synchronous event queue that drive all the synchronous processing and collect the minimum time needed before any of the synchronous events need to be processed; and

determining the final minimum response time needed by selecting the lesser of the minimum time needed for the asynchronous events and the minimum time needed for the synchronous events.

3. A method as in claim 2, further comprising:

performing power management or power consumption reduction tasks using the final minimum response time value before further processing any events.

4. A method as in claim 2, wherein the first asynchronous event queue and the second asynchronous event queue are the same single unified event queue.

5. A method as in claim 2, wherein the first asynchronous event queue and the second asynchronous event queue are different event queues.

6. A method as in claim 3, wherein the events are DartEvents.

7. A method as in claim 3, wherein both synchronous and asynchronous events are maintained on a single unified queue.

8. A method as in claim 7, wherein the unified queue is managed by an interoperability engine or by the DartEngine

9. A method as in claim 3, wherein the event driven runtime is any interoperability runtime or is a DartRuntime.

10. A method as in claim 3, wherein the synchronous events are queueable events which drive the synchronous processing needed to carry out the intent of the application by getting processed by the event processing units of an application that is compiled and linked.

11. A method as in claim 3, wherein asynchronous events are queuable events which drive the asynchronous processing needed to carry out the intent of an application, drive state machine driven hardware functions, or create, maintain, or make use of the communications of one device with another by getting processed by an Interoperability Engine or a DartEngine.

12. A method as in claim 3, wherein the power management and/or power consumption reduction tasks are carried out by one or more of the following in any combination:

(a) making a native threaded operating system call to initiating the blocking of the current thread of execution until such time as an external stimulus or an explicit timeout based on the final minimum response time needs, or an implied or device specific timeout period has expired;

(b) returning control to a calling cooperative processes which is given the time period for which no processing by the events on the queue or queues in needed;

(c) directly or indirectly instructing the hardware and or processor to slow down, speed up, or shut down its clock(s) or various hardware units;

(d) directly or indirectly instructing device hardware and/or processor and/or logic to control the amount of voltage and or current in one or more circuits or electrical units; and

(e) any other method wherein power use is regulated based on the final minimum response time.

14. The method of claim 2, further comprising:

performing power management or power consumption reduction tasks using the final minimum response time value before further processing any events; and

the first asynchronous event queue and the second asynchronous event queue are the same single unified event queue managed by an interoperability engine or by the DartEngine.

15. The method of claim 2, further comprising:

(1) at the start of each processing pass through an event driven application, setting a minimum response time variable to its expected highest-value, which expected highest-value is interpreted by the system as a value indicating an infinite response time need of the application event processing and any asynchronous event processing driven by events already in the runtime event queue;

(2) when the first synchronous event processing unit of an application is called, the first synchronous event processing unit checking to determine if the event reference passed into the processing unit as a parameter reference points to an actual event instance to be processed;

(3) if there is no event referenced, the processing unit makes a system call directly or indirectly by way of executing an instruction to request the next synchronous application event that needs processing, the system call causing the run-time to look through all the asynchronous operations that are being driven by events on the queue, and if there is an event to be processed, then processing continues at step (8) so that the synchronous application event is inspected by all application event processing units in a predefined order according to the software run-time model;

(4) asynchronous events on the queue which are ready for processing cause an operation corresponding to each asynchronous event to be executed;

(5) as each asynchronous event on the queue is inspected to see if it is ready to be processed, the minimum time until the next asynchronous event will be ready to be processed is gathered in the minimum response time variable, replacing the highest wait time value with any gathered minimum time value which is less than the highest value;

(6) when the system call returns, a return value is tested to determine whether there is a synchronous application event now at the head of the queue which needs to be processed by the application;

(7) if there is no synchronous application event at the head of the queue which needs to be processed, then a synchronous application processing event of a type to indicate general processing is generated for application processing;

(8) the synchronous application event is inspected by all application event processing units in a predefined order according to the software run-time model;

(9) any synchronous application event processing unit that needs to continue processing after it processes the current synchronous event will change the minimum response time variable value to the minimum of the minimum response time variable value and that of its own continued processing unit needs;

(10) when the first synchronous event processing procedure regains control, a device specific power management function is called with the minimum response time variable value as a parameter; and

(11) the device specific power management function uses the value to stop, slow down, modify an operating voltage or other parameter of the power consuming components of the device until an externally generated stimulus occurs or the time specified it the parameter occurs.

17. The method of claim 15, wherein the synchronous events are processed by Dart Gizmo class instances or instances of classes that inherit directly or indirectly from the Dart Gizmo class.

13. A method for device power management and/or power consumption reduction carried out at least in part by an event driven runtime, the method comprising:

(1) at the start of each processing pass through an event driven application, setting a minimum response time variable to its expected highest-value, which expected highest-value is interpreted by the system as a value indicating an infinite response time need of the application event processing and any asynchronous event processing driven by events already in the runtime event queue;

(2) when the first synchronous event processing unit of an application is called, the first synchronous event processing unit checking to determine if the event reference passed into the processing unit as a parameter reference points to an actual event instance to be processed;

(3) if there is no event referenced, the processing unit makes a system call directly or indirectly by way of executing an instruction to request the next synchronous application event that needs processing, the system call causing the run-time to look through all the asynchronous operations that are being driven by events on the queue, and if there is an event to be processed, then processing continues at step (8) so that the synchronous application event is inspected by all application event processing units in a predefined order according to the software run-time model.

(4) asynchronous events on the queue which are ready for processing cause an operation corresponding to each asynchronous event to be executed;

(5) as each asynchronous event on the queue is inspected to see if it is ready to be processed, the minimum time until the next asynchronous event will be ready to be processed is gathered in the minimum response time variable, replacing the highest wait time value with any gathered minimum time value which is less than the highest value;

(6) when the system call returns, a return value is tested to determine whether there is a synchronous application event now at the head of the queue which needs to be processed by the application;

(7) if there is no synchronous application event at the head of the queue which needs to be processed, then a synchronous application processing event of a type to indicate general processing is generated for application processing;

(8) the synchronous application event is inspected by all application event processing units in a predefined order according to the software run-time model;

(9) any synchronous application event processing unit that needs to continue processing after it processes the current synchronous event will change the minimum response time variable value to the minimum of the minimum response time variable value and that of its own continued processing unit needs;

(10) when the first synchronous event processing procedure regains control, a device specific power management function is called with the minimum response time variable value as a parameter; and

(11) the device specific power management function uses the value to stop, slow down, modify an operating voltage or other parameter of the power consuming components of the device until an externally generated stimulus occurs or the time specified it the parameter occurs.

16. The method of claim 13, wherein the synchronous events are processed by Dart Gizmo class instances or instances of classes that inherit directly or indirectly from the Dart Gizmo class.

18. A computer program product for use in conjunction with a computer system or information appliance, the computer program product comprising a computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism comprising:

a program module that directs the computer system or information appliance to function in a specified manner for device energy and power management and energy and power consumption reduction of the computer system or information appliance, the program module including instructions for;

establishing an event driven runtime environment within at least one device for which the energy and power management and consumption reduction is to be achieved;

generating and maintaining at least one event queue identifying all synchronous and asynchronous processing events and associated minimum expected processing times for the processing events in the queue; and

selecting a final minimum estimated response time based on the expected minimum synchronous and asynchronous event processing times in the queue.

19. A computer program product as in claim 18, further comprising instructions for:

searching through all the events on a first asynchronous event queue that drive all the asynchronous processing and collect the minimum time needed before any of the asynchronous events need to be processed;

searching through all the events on a second synchronous event queue that drive all the synchronous processing and collect the minimum time needed before any of the synchronous events need to be processed; and

determining the final minimum response time needed by selecting the lesser of the minimum time needed for the asynchronous events and the minimum time needed for the synchronous events.

20. A computer program product as in claim 19, further comprising instructions for:

performing power management or power consumption reduction tasks using the final minimum response time value before further processing any events.

21. An apparatus for energy and power managemerit and energy and power consumption reduction within at least one device, the apparatus comprising:

a logic circuit within the at least one device utilizing energy and power to perform a logic processing operation;

means for establishing an event driven runtime environment within at the least one device for which the energy and power management and consumption reduction is to be achieved;

means for generating and maintaining at least one event queue identifying all synchronous and asynchronous processing events and associated minimum expected processing times for the processing events in the queue;

means for selecting a final minimum estimated response time based on the expected minimum synchronous and asynchronous event processing times in the queue; and

means for searching through all the events on a first asynchronous event queue that drive all the asynchronous processing and collect the minimum time needed before any of the asynchronous events need to be processed;

means for searching through all the events on a second synchronous event queue that drive all the synchronous processing and collect the minimum time needed before any of the synchronous events need to be processed;

means for determining the final minimum response time needed by selecting the lesser of the minimum time needed for the asynchronous events and the minimum time needed for the synchronous events; and

means for performing power management or power consumption reduction tasks for the logic circuit using the final minimum response time value before further processing any events.