Microsoft Technology Licensing, LLC

Michael S Bernstein

Daniel J Polivy

Andrew John Fuller

Matthew P Rhoten

Roger H Wynn

David Switzer

Gerhard A Schobbe

Eric J Horvitz

Susan Theresa Dumais

Jeffrey West Pettiross

Matthew Rubin Lerner

Meredith June Morris

Jaime Brooks Teevan

Ravipal S Soin

Ross Nathaniel Luengen

Issa Yousef Khoury

Vikram Madan

Daniel John Liebling

Bhrighu Sareen

Otto G Berkes

Sriram Viji

Shawna Swanson

Matthew H Holle

Jin-Woo Jeong

Kamesh C Tumsi Dayakar

Kurt Allen Geisel

Steve Weil

Gregory H Manto

Huat Chye Lim

HyunSuk Kim

Kamesh Chander Tumsi Dayakar

Geralyn M Miller

Technologies pertaining to generating crowd-sourced answers are described herein. A text string is received, and the text string is parsed to determine if the text string represents an information need that is desirably answered by a collective of crowd workers. When it is determined that the information need is desirably answered by the collective of crowd workers, a query or question that represents the information need is provided to a first plurality of crowd workers, who generate proposed answers for the information need. The proposed answers are provided to a second plurality of crowd workers, who vote on the proposed answers. An answer to the information need is output based upon responses of the crowd workers.

Providing crowdsourced answers to information needs presented by search engine and social networking application users

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

Using channel concepts to control computer networking

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

Computer systems and methods allow users to receive, save, access, and/or display handwritten information as electronic ink in objects managed by an operating system and/or that are accessible by the operating system. Such systems and methods may allow the operating system to receive, save, access, and/or display electronic ink file names, author identifiers, keywords or comments, and the like. Some examples of such systems and methods include: (a) receiving electronic ink data associated with a document or file; (b) storing the electronic ink data; and (c) providing operating system access to the stored electronic ink data. Then, whenever the file name (or other information) is displayed in an object managed by the operating system, it will be displayed in electronic ink format. Additionally, aspects of the invention relate to computer-readable media including instructions stored thereon for performing the methods and operating the systems described above.

Handwritten file names

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 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 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

A user interface and scheme is provided for facilitating shutting down an operating system. A shut down command is initiated in an operating system, and applications running on the system are issued a shut down request. Aspects allow running applications to delay the system shut down and to register information to explain the delay, for example, a non-interruptible task (e.g., a CD burn) is being performed by the application. A user interface displays applications running on the system and delay information registered by the applications, providing the user an opportunity to terminate the applications or cancel the system shut down based on the applications and any delay information provided.

Operating system shut down

Described is a mechanism that preserves the state of computer system shared resources and/or settings, and ensures that changes thereto are reverted when an application exits. A shared resource change bubble logically surrounds application code that causes system resource and/or setting data to change. The bubble preserves existing data before it gets changed, and restores the data when the application program code exits. In one implementation, the bubble is implemented as a library loaded by the application. In an alternative implementation, the bubble is run in a separate process, whereby the bubble can restore changed data even if the application program crashes. In another implementation, a bubble is automatically run for any application that the user has specified needs a bubble. Multiple settings and states may be preserved in a bubble for multiple applications, allowing changes to be undone and reapplied per application, e.g., whenever focus changes.

Transient shared computer resource and settings change bubble for computer programs

A system and method for creating an ad-hoc network is described. A user may navigate a number of options to create an ad-hoc network and/or join an ad-hoc network using the described system.

User experience for collaborative ad-hoc networks

A method of controlling power management is provided. In an embodiment, the user provides feedback that the inactivity period before a display blanks is too short. In response to the user feedback, a behavior tracking mode is entered and the inactivity period is adjusted to a period that is more suitable to the user's needs. In an embodiment, the adjustment may be done through incrementing a counter and changing the inactivity period based on the value of the counter.

Keep awake heuristic

A system and method for associating an ink title with a note is described. A user may hand write a title for a document or note and have the handwritten ink title be displayed when interacting with the system when, for example, viewing the contents of a directory, reviewing the results of a search, viewing a list of most recently used documents, viewing a history of which documents were used, and the like. The use of a handwritten ink title speeds a user's recall of the content of the note over textual titles.

Organization of handwritten notes using handwritten titles

A system and process for quickly rendering ink is described. Rendered ink information is placed into a transparency map of an image. The image is combined with foreground and background information to produce a final image. Using this process, the painting of ink using transparency map information may be performed quickly and with less processor work than a slow rendering process.

Growing community of inventors

Bothell, WA, United States of America

Michael S Bernstein