Microsoft Technology Licensing, LLC

Microsoft Corporation

Matthew P Rhoten

Andrew John Fuller

Daniel J Polivy

Curt Andrew Steeb

Michael S Bernstein

Juan J Perez

Roger H Wynn

Niels Van Dongen

Philip Ti-Fei Su

Christopher Allen Schoppa

Sriram Viji

Zoltan C Szilagyi

Richard J Swaney

Jerry R Hughson, Jr

Alexander G Gounares

William Jefferson Westerinen

Robert L Chambers

Bodin Dresevic

Sashi Raghupathy

Adrian Mark Chandley

Sterling M Reasor

Steve Dodge

Arin J Goldberg

Ravipal S Soin

Gregory H Parks

Kevin Phillip Paulson

Timothy H Kannapel

Tobiasz Alexander Zielinski

Seiya Ohta

Jason Michael Anderson

Otto G Berkes

Jerome J Turner

John Scott Stephens

William Mak

Daniel J Makoski

Michael Milirud

Brian Teutsch

Teague Curtiss Mapes

Stephen Richard Drake

Suresh Babu Velagapudi

Kurt Allen Geisel

Cy Anne Cedar

Krishna V Kotipalli

Piero Sierra

Paula L Tomlinson

In a main computer system coupled to an auxiliary display device, described is an interface set for implementation by an auxiliary display device driver, to couple the driver to an auxiliary display platform. Commands received from the auxiliary display platform may be handled by code external to the driver, such as a class extension object. For example, the class extension object may interpret and/or translate commands received from the auxiliary display platform into a format understood by the driver code. The auxiliary display device driver may then provide corresponding command information including data to the auxiliary display device via the transport. Event data may be returned from the auxiliary display device driver via the interface set to the class extension object, such that corresponding event information, e.g., received at the auxiliary display device, may be returned to the auxiliary display platform.

Auxiliary display device driver interface

Described is a mechanism by which application programs (or plug-ins) and an auxiliary service adjust the output and/or data available for output on an auxiliary device based on changes detected in the current context of the auxiliary display. Context sensors detect and report changes in context, whereby some action is taken with respect to what information is displayed or can be displayed on the auxiliary display device. Examples of context data that can change include the physical location of the display, detected movement or motion data, presence of a particular user or others, power state, network connectivity status, privacy status and so forth. The auxiliary device can have context as to its position relative to the main display. Information sensitivity levels may be used to specify whether an application program's data can be displayed, based on the perceived sensitivity of the information and the user's current context.

Context aware auxiliary display platform and applications

An auxiliary processing state of a computing device provides an auxiliary display within a primary display device of the computing device. As such, a computing device can switch from a primary processing state (e.g., full power, full operating system, full functionality) to an auxiliary processing state and yet still provide a user interface through the primary display device. The auxiliary processing state may employ a different processor than the primary processing state. Alternatively, auxiliary processing state and the primary processing state may employ different processing modes of the same processor. Transitions between the auxiliary display of the auxiliary processing state and the primary display of the primary processing state may be transitioned to preserve some consistency between the two displays.

Auxiliary display within a primary display system

Described is a system and method including an auxiliary display platform having an interface (API) set that provides a way for client applications running on a main computer system to interact with various types of auxiliary displays, irrespective of differences between various device implementations. Interaction includes displaying content and notifications provided by the application, and returning events to the application. In one implementation the API set comprises a set of COM objects that register and perform configuration checks of a client application, send content and notifications to attached devices, and return events from the attached devices. The application may send data to an endpoint corresponding to a communication destination (e.g., a particular auxiliary device application) and a contract (e.g., a format) for the data. The platform and API set thus provide an abstraction layer for applications to provide information independent of any particular auxiliary device implementation.

Interface for consistent program interaction with auxiliary computing devices

Described is a technology by which a device pre-enables application programs of a computer system to work with the device when the device is connected to the computer system. A set of data is obtained from a device, such as by an installer at installation time. The set of data includes information that identifies one or more computer system application programs that the device desires to work with when each application program runs. When the data set is obtained, the application program is enabled (e.g., given appropriate permissions) such that the application program may communicate data with the device when the program is run on the computer system. In one implementation, a device driver provides an installer with access to the data set, which may also include additional information such as application configuration parameters. The installer may be automatically run on the computer system upon initial device detection.

Automated application configuration using device-provided data

An auxiliary computing device wakes an associated main computer system to obtain data as needed, on-demand and/or in anticipation of demand. The wakeup operation is ordinarily temporary to fetch data, whereby only a small amount of power is consumed by the main computer system. In one implementation, a control channel between the auxiliary device and the main computer system is used to signal a wakeup. A main data channel is used to obtain the data, whereby the auxiliary device has access to a larger amount of data than it can cache. Moreover, the components of the main computer system may be leveraged, such as to use the main computer system's digital rights management mechanisms. Additional data may be intelligently requested by the auxiliary device while the main computer system is powered up, e.g., to buffer media, and/or request a synchronization of calendar data, email data, and so forth.

Waking a main computer system to pre-fetch data for an auxiliary computing device

Described is an architecture by which application programs can provide data to auxiliary display devices of essentially any type for display to a user. A defined application layer (e.g., accessed via interfaces) allows programs to provide data to a service that controls the output of data to an auxiliary display device, and returns navigational data to the application upon appropriate user interaction with the device via actuators. Enumeration allows applications to discover the capabilities of a device, while arbitration determines which application has input-output rights to the device. The architecture further provides a protocol layer including pluggable protocol proxies that allow various types of displays to serve as an auxiliary display. This platform-like model allows program developers the ability provide programs that leverage auxiliary displays when available, and provides display manufacturers the ability to provide displays with extensible capabilities.

Auxiliary display system architecture

A locking arrangement for data structures is provided that prevents deadlocks, but still allows different threads to simultaneously obtain locks on different nodes of a data structure for both read and write operations. The locking system differentiates locks based on a priority hierarchy. The locking system will fail a request to lock one or more resources in a data structure if access to those resources has already been restricted by a conflicting lock of an equal or higher priority. The locking system may also employ preemptable and non-preemptable locks such that, if a preemptable lock with a lower priority has restricted access to resources, then the locking system will preempt the lower priority lock in favor of a conflicting higher priority lock. Alternately, if a non-preemptable lock with a lower priority has restricted access to resources, then the locking system will wait until the lower priority lock is removed before implementing a requested conflicting higher priority lock. This locking arrangement allows high priority operations that require higher performance and efficiency to receive preferential access to a data structure without preventing lower priority operations from accessing the data structure, while preventing deadlocks between different operations.

Priority differentiated subtree locking

Described is a system and method by which application programs running on a main computer system communicate with an auxiliary display device (such as a cell phone, pocket-sized computer, alarm clock, television, digital picture frame and so forth) to provide viewable information on the device, remote control capabilities, and notifications. Via API calls, programs provide information in the same format regardless of the device capabilities and/or the connection type. An auxiliary display platform converts the information into a format understood by a device driver, which then filters the information as desired for its particular hardware device before the information is communicated. Return communications return data such as status and user interaction with the displayed information. Software vendors may thus write code once to output information on auxiliary displays, while hardware manufacturers can have their devices work as auxiliary displays, with little or no modification to existing hardware.

Method and system for exchanging data between computer systems and auxiliary displays

Described is a technology by which an application program such as a gadget may communicate with a sidebar program to output content for consumption by an auxiliary display device. The gadget may communicate with the sidebar program via sidebar APIs, and in turn the sidebar program communicates with an auxiliary display device platform via auxiliary display device APIs. Among its capabilities, the sidebar program may install gadgets on a host computer system, and upon detecting that the host computer system is configured to operate with an auxiliary display device, may install the gadget such that the gadget is configured to work with an auxiliary display device. The installation may be accomplished by having the sidebar program write information to a system registry.

Auxiliary display sidebar integration

Described is a system and method by which application programs running on a main computer system communicate with an auxiliary display device (such as a cell phone, pocket-sized computer, alarm clock, television, digital picture frame and so forth) to provide viewable information on the device, remote control capabilities, and notifications. Via API calls, programs provide information in the same format regardless of the device capabilities and/or the connection type. An auxiliary display platform converts a notification into a format understood by a device driver, which then filters the notification as desired for its particular hardware device before the notification is communicated. Return communications return data such as status and user interaction with the displayed information. Software vendors may thus write code once to output notifications on auxiliary displays, while hardware manufacturers can have their devices work as auxiliary displays, with little or no modification to existing hardware.

Sending notifications to auxiliary displays

Described is a system and system by which application programs provide data to auxiliary display device (that is associated with a main computer system) for display, including at times when the main computer system is powered down. The cache maintains the user data in association with structured navigational information, to allow navigation within the data via the structure. When online, the main computer system prepares the data cache from program data in combination with navigational information, and transfers the cache to an offline medium such as auxiliary storage in firmware. The cache may be arranged as a tree structure, such that navigation commands result in output according to data in the tree. Other events such as time-based events can change the auxiliary device output.

Caching data for offline display and navigation of auxiliary information

Described is a mechanism for receiving new data at an auxiliary device associated with a main computer system, and processing that new data within the auxiliary device firmware to take some action. The receipt and processing of the data is independent of whether the main computer system is in a powered-up state (online) or powered-down state (offline). A cache that maintains the user application data for offline navigation may be updated with new data, either to change existing data in the cache or add a new navigation path. The received data can be processed to perform other actions, depending on the context of that data as determined by auxiliary processing.

Processing information received at an auxiliary computing device

Described is a system and method by which an auxiliary computing device having an auxiliary display platform that displays information corresponding to data that originated on the main computer system may be extended by a device manufacturer. Extended hardware is added to the device, such as a radio receiver and/or an audio decoder. The auxiliary display platform is layered and extensible at each layer, and includes an extensible hardware abstraction layer that is extensible to support extended hardware if needed, and a driver layer that is extensible by adding driver code for the extended hardware. A runtime layer is also extensible to support the extended hardware as needed, as are libraries, the auxiliary shell program and other managed code. The client API is also extensible to allow applications on the main computer system to communicate with extended hardware via the device runtime layer.

Extensible architecture for auxiliary displays

An auxiliary computing device normally used for remotely controlling a primary device may change its functionality and extend its usefulness based on a usage context. An auxiliary device may change its usage context by connecting differently to a primary device depending on any number of parameters including distance from the device, battery life, connection method, and proximity to other devices. The device may change its usage context by interfacing with a primary device service that communicates with various applications to feed the auxiliary device different information in different usage contexts. Further, the device may control different functions of the primary device based on the usage context.

Controlling an auxiliary display user interface based on usage context

Growing community of inventors

Kirkland, WA, United States of America

Matthew P Rhoten