Microsoft Technology Licensing, LLC

Hirofumi Yamamoto

Firdosh Kersy Bhesania

Alex G Snitkovskiy

Steven Nabil Bathiche

Randall Edward Aull

Tsz Yan Wong

Miron Vranjes

Timothy T Brewer

Brian Daniel Beck

Yaou Wei

Christopher E Swan

Steven Joseph Tricanowicz

Michael William John McCracken

Paul Cador Roberts

Idan Avraham

John E Paff

Yashabh Sethi

Christine M Chew

David Abzarian

Reed L Townsend

Richard Bruce Ward

Doron J Holan

Alain L Michaud

Nathan C Sherman

Stephen Harry Wright

Lawrence William Osterman

Gerardo Bermudez

Jacob Rossi

Krishnan Menon

Jay Senior

Raju Ramanathan

Rouella J Mendonca

Alan Stephenson

Alice Tang

Pak Kiu Chung

Mohamed E Fathalla

Kelli Marie Zielinski

Jason A Schroeder

Steve Wright

Youlian Simidjiyski

Ramachandran Gurumoorthy

Alain Michaud

A computer-implemented technique is described herein for efficiently and reliably interacting with a nonconforming application component in a windowing environment. The nonconforming application component corresponds to a type of application (such as, but not limited to, an immersive-type full-screen application) that was not originally designed for presentation of application content in a windowing environment, or was not originally designed for presentation of application content in a windowing environment of a certain type. In some implementations, the computer-implemented technique generates a composite window by: creating a system-owned frame; receiving an application-owned window; and creating the composite window by combining the frame and the application-owned window. The technique can thereafter control the composite window by performing operations on the composite window via its system-owned frame.

Interacting with nonconforming applications in a windowing environment

In some examples, input received from an input device, such as a keyboard, is modified by a component associated with an operating system before the input is delivered to an application. For instance, a component associated with the operating system may become registered for modifying input. In some situations, the input is modified based at least in part on metadata associated with the input device. For example, a location of a fingertip on a touch-sensitive display may be used to modify the input before delivery to an application.

Modifying input delivery to applications

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

In one embodiment, a unified pointer messagemay describe in a single type of pointer message a coordinate input from a user via multiple types of pointer devices. An input device interfacemay receive a coordinate inputfrom an input device. A processormay execute an application programming interface layerthat creates a unified pointer messagefor the coordinate input. The processormay send the unified pointer messageto an application. The processormay process a device specific data setunhandled by the application.

Device specific data in a unified pointer message

Computer-readable media, computerized methods, and computer systems for alerting a user that an operating system has entered a secure mode is provided. Initially, inputs are received at an operating system residing in a default mode. Typically, the default mode allows applications running on the operating system to access the inputs. If the inputs are identified as a call to perform a protected operation, the operating system is transitioned from the default mode to the secure mode. Typically, the secure mode restricts the applications from intercepting the inputs. The transition to the secure mode is automatically communicated to the user via an indicator device. Generally, automatic communication includes providing a message from the operating system to the indicator device over a secure pathway that triggers the indicator device to generate a user-perceivable output. Accordingly, the operating system exerts exclusive control over the operation of the indicator device.

User indicator signifying a secure mode

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

Methods for maintaining the security of a secured execution environment on a system comprising said secured execution environment and a second execution environment are disclosed. A maintained current state for the secured execution environment is selected from among a group of possible states including a standard input mode state and a nexus input mode state. A flow of user input is directed according to the current state through a secure kernel of both the second environment and the secured execution environment.

Providing secure input to a system with a high-assurance execution environment

In aspects, interactions between processes of a desktop are allowed or denied based on security data. The security data may comprise a first bitmap that indicates whether a requesting process is allowed to cause an action to occur, a second bitmap that indicates whether a process is protected from having an action occur, and a third bitmap that indicates whether the requesting process may override protection, if any, in causing the action to occur.

Desktop security

Techniques are disclosed to provide security for user input in which a first, host operating system is used along with a second, high assurance operating system, where the first system provides at least some of the infrastructure for the second system. Two modes are presented. In a first mode, user data is passed to the host operating system. In a second mode, user data is retained in the second operating system for the use of the second operating system or processes running on the second operating system. Transitions between the nodes can be accomplished according to hypothecated user actions such as keystroke combinations, or when the user performs an action which indicates a programmatic activation of a process running in the second operating system. Where shadow graphical elements are run by the first operating system to indicate the location of graphical elements from processes running on the second operating system, this programmatic activation may be indicated by programmatic activation of a shadow graphical element.

A manager component for managing input from legacy and non-legacy devices in a similar manner is disclosed. An inventive manager component receives input from both non-legacy input drivers for non-legacy input devices, and legacy input drivers for legacy input devices. The manager component provides the input to application programs that desirably have previously registered to receive input from one or more types of input devices. The application programs receive this input without directly communicating with the drivers.

Manager component for managing input from existing serial devices and added serial and non-serial devices in a similar manner

Growing community of inventors

Bellevue, WA, United States of America

Hirofumi Yamamoto