Microsoft Technology Licensing, LLC

Robert E Harris, Jr

Randall Edward Aull

Firdosh Kersy Bhesania

Vivek Gupta

Andrea A Keating

Philip Albert Froese

Sathyanarayanan Karivaradaswamy

Sanjeev Chandra Reddy

Ugan Sivagnanenthirarajah

Sanjana Ramakrishnan Sunder

Eliyas Yakub

Rahul Ramadas

Anthony Yuting Chen

Michael Jeffrey Ajax

Sergii Viktorovych Liashenko

Jayson L Kastens

Sayak Chatterjee

Sarah Anne Barnette

Cong Yang

Martin Richard Borve

Mark Lin

Venkatesh-Prasad Ranganath

Pankaj Bharti Gupta

Pradip Harindran Vallathol

Jane Evguenia Lawrence

Mike Ajax

A computer system receives a sensor payload from a human presence sensor that is associated with the computer system. The computer system determines, based on an arbitration policy, that the computer system is enabled to perform a particular action based on the priority of the human presence sensor. The arbitration policy determines the priority of the human presence sensor among a plurality of human presence sensors that are associated with the computer system. The computer system triggers the particular action based on the computer system being enabled to perform the particular action based on the content of the sensor payload.

Method for prioritizing human presence sensors in a computer system based on arbitration policies

User engagement is detected and used to control operation of a computing device. User engagement is detected by a sensor such as a camera that identifies if a user's face is oriented towards a display device. If the user is not facing the display device, the sensor determines that the user is unengaged. The computing device is thus able to perform a power-saving operation, such as dimming the display device, when the user is unengaged. The computing device includes an API that abstracts sensor data into a user engagement signal indicating that the user is either engaged or unengaged. The OS and applications running on the computing device act on the user engagement signal provided by the API without communicating directly with the sensor. The user engagement signal may be provided as an input to a state machine.

User engagement surfaced through an application programming interface (API)

A device receives a sensor payload at a sensor service. The sensor payload includes a data field that comprises a first value that corresponds to a reading by a sensor device. The device sends the sensor payload to a broker process that is separate from the sensor service and that hosts plug-in logic. The device receives a sensor payload update from the broker process. The sensor payload update includes a second value for the data field that is different from the first value. The second value was determined by the plug-in logic. The device creates a modified sensor payload from the sensor payload, including updating the data field to comprise the second value. The device initiates an operating system action based on the modified sensor payload.

Sensor broker for plug-ins

Embodiments described herein are directed to mechanisms that enable roles (e.g., host vs. function, power provider vs. power consumer, master vs. slave, server vs. client, source vs. sink, upstream vs. downstream) to be dynamically assigned between two interconnected dual-role devices in an intelligent and deterministic manner based on the available context on each device.

Intelligent role selection for dual-role devices

Systems and methods for specifying extended descriptor information in a device accessed using a communication interface are disclosed. One method includes transmitting a request to a device from a host computing system, and receiving an extended capability descriptor identifying to the host computing system at least one extended descriptor set stored on the device. The extended capability descriptor identifies a minimum operating system version able to support a corresponding extended descriptor set.

Extraction of operating system-specific characteristics via a communication interface

A 'Compatibility Tester' extracts observable behaviors from different system implementations (e.g., software, operating systems, device drivers, hardware interfaces, etc.), then performs compatibility testing via comparisons of the extracted behaviors. Traces (e.g., bus level signals between controllers and hardware devices or commands between software components) representing observable behaviors of different implementations of a system are captured. Temporal and structural rules are then mined from these traces. The mined rules (or a model constructed from those rules) are used by a 'Rule Checking' process that determines whether reference rules (mined from a known compatible system) are compatible with rules mined from test traces of a second system. Invalid rules are flagged as behavioral compatibility bugs. Alternately, the mined rules are used by a &#x201c;Rule Diffing&#x201d; process that performs set differencing of the behavioral and structural rules mined from the different system implementations, with differences between the systems flagged as behavioral compatibility bugs.

Compatibility testing using traces, linear temporal rules, and behavioral models

Growing community of inventors

Woodinville, WA, United States of America

Robert E Harris, Jr