Microsoft Technology Licensing, LLC

Randall Edward Aull

Firdosh Kersy Bhesania

Doron J Holan

Vivek Gupta

Glen T Slick

Andrea A Keating

Robert E Harris, Jr

Mukund Sankaranarayan

James George Cavalaris

Narayanan Ganapathy

Christopher Mark Dreher

Andrew C Glass

Philip Albert Froese

Steven Nabil Bathiche

Craig Steven Ranta

Timothy T Brewer

Hirofumi Yamamoto

Esaias Engelbertus Greeff

Douglas Keith Brubacher

Mark E Maszak

Michael William John McCracken

Anthony Yuting Chen

Ellick H Sung

David Abzarian

Janet Lynn Schneider

Arvind R Aiyar

Eliyas Yakub

Bernard J Thompson

Rahul Ramadas

Robbie Harris

Martin Richard Borve

Jayson L Kastens

Cong Yang

Gary Rensberger

John Charles Dunn

Poovanpilli G Madhavan

Paresh J Maisuria

Peter E H Hauser

Venkatesh-Prasad Ranganath

Benjamin Allen Pullen

Neil Sandlin

Pankaj Bharti Gupta

Pradip Harindran Vallathol

Bradley L Fosdick

Chih Jen Wen

Jane Evguenia Lawrence

Kiran Kudli Anantha Shastry

Robert Harris

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

Described are examples for synchronizing multiple timing sources in a computing device. At least a first clock associated with a first timing source and a second clock associated with a second timing source can be maintained at the computing device. A request for an indication of a difference in values between the first clock and the second clock can be received from the application. A first elapsed time of the first clock and a second elapsed time of the second clock from a previous instance of an event can be determined by the computing device at an instance of a reoccurring event in a domain of one of the first timing source or the second timing source. An indication related to the first elapsed time and the second elapsed time can be provided to the application.

Synchronizing timing sources in computing devices

A universal serial bus stack may use an emulation layer to grant a non-universal serial bus device access to universal serial bus drivers and applications. The universal serial bus stack may exchange a device communication at an emulation layer. The universal serial bus stack may translate between a universal serial bus communication and the device communication at the emulation layer, and then may exchange the universal serial bus communication at a universal serial bus client interface.

Universal serial bus emulation layer

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

This document describes techniques for detecting state loss on a device. These techniques permit a computer connected to a device to forgo, in many cases, reinitializing the device when returning to a normal-power mode.

Detecting state loss on a device

In embodiments of driver interface functions to interface client function drivers, a set of serial communication protocol driver interfaces are exposed by a core driver stack, and the serial communication protocol driver interfaces include driver interface functions to interface with client function drivers that correspond to client devices configured for data communication in accordance with the serial communication protocol. A client function driver can check for the availability of a driver interface function before interfacing with the core driver stack via the serial communication protocol driver interfaces. A contract version identifier can also be received from the client function driver via an extension of the driver interface functions, where the contract version identifier indicates a set of operation rules by which the client function driver interfaces with the core driver stack.

Driver interface functions to interface client function drivers

A computer receives data from a keyboard having one or more keys which cause generation of keyboard data that quantitatively describe the relative force applied to those keys. The keyboard data are transmitted in an HID report containing identifiers for one or more keys that have been pressed and force data for each key. The force data may be a multi-bit value quantifying the key force, or a null indicator signaling that the key is not force-sensing. Keyboard data messages are then prepared which identify keys pressed, contain force data, and may indicate whether the force data updates previous force data. Force updates are only provided to application programs registering for key force data. In other aspects of the disclosed subject matter, key repeat messages are automatically generated for a key held pressed by a user. The key repeat messages are generated at a rate controlled by the amount of force applied to the key.

Method for processing data quantifying force applied to one or more keys of a computer keyboard

A computer system that recognizes multi-function devices and associates functions with multi-function devices. Each multi-function device may be represented by a multi-function object, allowing tools, applications or other components within the computer to take actions relating to the entire device or relating to a function based on the association of that function with other functions in the same device. These actions include displaying information about devices, instead of or in addition to information about functions. Actions also include selecting functions based on proximity within a device. Functions may be associated with a multi-function device using a unique device identifier provided by the device or generated for the function based on a connection hierarchy between functions and the computer. Devices may be configured to provide the same identifier regardless of the transport over which the device is accessed.

Multi-function device ID with unique identifier

A computer system that accesses multi-transport devices and associates device instances of the multi-transport device with each other. Devices provide the same device identifier such as a device unique identifier regardless of the transport over which the device is accessed. A visual representation for the multi-transport device may be provided to a user using the device identifier. Also, a single functional representation for the multi-transport device may be provided based on an identifier provided by each function of the device. The functional representation may be independent of the addition and removal of transports and allows abstracting device access via multiple transports from a user and an application. Transports may be selected at an application and/or a system level. Operating characteristics of available transports may be used to select a desired transport, based on transport requirements specified by the application, the user or the system.

Generalized architecture to support representation of multi-transport devices

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

An automated power reporting system is provided in one aspect. The system includes one or more devices that can report or transmit power status information over a bus or network. A protocol component utilizes a generalized protocol to process or convert the power status information over the network in order to facilitate power management operations for a plurality of devices. In this manner, devices that send power information can interact and exploit personal computing resources in order to better help users manage limited power resources for their respective devices.

Protocols for reporting power status over multiple buses

Growing community of inventors

Bothell, WA, United States of America

Randall Edward Aull