Abstract: A sensor application programming interface (API) is capable of restricting an application's access to sensor data measured by a sensor, while at the same time providing access to sensor properties of the sensor, even if access has not been granted to the application for the sensor.

Abstract: 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.

Abstract: In one aspect, the present disclosure describes a process for maintaining file allocation tables (FATs) for a volume of storage medium. The process includes triggering, by a write operation, modification of data in an existing sector of a data file by writing of data to a new sector of the storage medium. The process also includes writing revised used/unused sector information into one FAT and setting a variable indicative of a number of FATs (NOF) to a first value. The process additionally includes copying the one FAT to another FAT and re-setting the variable to a second value.

Abstract: 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.

Abstract: Described is a system and method comprising a content format by which client programs running on a main computer system may provide data to various types of auxiliary display devices. The format, which may be XML-based, provides menu pages comprising a list of selectable items, content pages comprising text and images, and dialog pages providing text, images and one or more actionable options. The text and images may be accompanied by requested formatting information, e.g., specifying emphasis, color, alignment, wrapping and/or fit to the screen. An auxiliary device can parse the content to display as much as possible, particularly information recognized (via content tags) as significant, and use the formatting information to the extent of its capabilities. Virtual buttons may be defined for page navigation and/or item selection. Pages of the content format may be cached for operation when the main computer system is offline from the auxiliary display device.

Abstract: Described is a system and method that use the concept of channels by which computer users select an appropriate set of network settings maintained in the computer system for a particular network. Upon selection, the corresponding settings are automatically applied by the system. A channel manager manages sets of network settings for various networks, including ad hoc networks, wherein each set contains the information that is necessary to connect to a network. A user interface allows selection of a channel, e.g., via a friendly name. The network settings may be stored in files to allow users to easily copy settings. Complex channels are capable of connecting to different networks at different times in a priority ordering, depending on network availability. The channel manager is able to determine the current channel from current network settings. Metadata may be received and displayed in conjunction with the channel-related user interface.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.