Abstract: Consumption of power by device components is profiled on a per-session basis of user interaction. A session engine determines start of a user interaction session with the device (e.g., by detecting screen turn on). The engine generates a session identifier (SID) and broadcasts same to device component(s). In response to the SID, the component(s) record power consumption data. Upon receiving a signal indicating end of the user interaction session (e.g., screen turn off), the session engine broadcasts a notice allowing component(s) to stop recording power consumption data. The components communicate aggregated data to the session engine for storage in a centralized location (e.g., trace buffer). In response to a query posed within a command line prompt, stored data may be parsed on a per-session basis for inclusion in a detailed report of power consumption. Power consumption inefficiencies endemic to components and/or user behaviors may be thus be identified and remediated.

Abstract: Consumption of power by device components is profiled on a per-session basis of user interaction. A session engine determines start of a user interaction session with the device (e.g., by detecting screen turn on). The engine generates a session identifier (SID) and broadcasts same to device component(s). In response to the SID, the component(s) record power consumption data. Upon receiving a signal indicating end of the user interaction session (e.g., screen turn off), the session engine broadcasts a notice allowing component(s) to stop recording power consumption data. The components communicate aggregated data to the session engine for storage in a centralized location (e.g., trace buffer). In response to a query posed within a command line prompt, stored data may be parsed on a per-session basis for inclusion in a detailed report of power consumption. Power consumption inefficiencies endemic to components and/or user behaviors may be thus be identified and remediated.

Abstract: Providing services within a network of service providers sharing an authentication service and a set of business rules. A central server receives a first request from a first server to provide a first service to a user via a client without forcing the user to present credentials. In response to the received first request, the central server stores data identifying the first service on the client. The central server further receives a second request from a second server to provide a second service to the user via the client after the user presents the credentials to the second service. After receiving the second request and the presented credentials, the central server allows the user access to the second service. In response to allowing the user access to the second service, the central server further allows the user access to the first service as a result of the stored data.

Abstract: An “audio challenger” operates by first defining a library of a finite number of discrete audio objects including spoken sounds, such as, for example, individual digits, letters, numbers, words, etc., or combinations of two or more digits, letters, numbers, or words. The spoken sounds are either automatically generated by a computer, or recorded from one or more actual spoken voices. Given this library of audio objects, the audio challenger automatically selects one or more audio objects from the library and concatenates the objects into an audio string that is then automatically processed to add one or more distortions to create a “challenge string.” The distorted challenge string is then presented to an unknown party for identification. If the unknown party correctly identifies the challenge string, then the unknown party is deemed to be a human operator. Otherwise, the unknown party is deemed to be another computer.