Microsoft Technology Licensing, LLC

Dejun Zhang

Robert Zhu

Ying Chin

Bin Wang

Pengxiang Zhao

Satyendra Bahadur

Weiyou Cui

Lei Zhang

Wei Huang

Carlos Picoto

Daryl A Welsh

Qipeng Wu

Xuejun Chen

Sailesh Baidya

Ying N Chin

Robert Yu Zhu

A loose coupling between Internet of Things ('IoT') devices and environmental sensors is generated. Once the loose coupling has been generated, conditions in a physical environment can be managed utilizing the loosely coupled devices. For example, a hybrid machine learning/expert system can be utilized to activate the IoT devices in an environment to achieve a desired condition in an optimized manner.

Management and operation of loosely coupled internet of things devices

The techniques disclosed herein provide improvements over existing systems by dynamically controlling communication connections between two or more computing devices based on the detection of specific events. Instead of requiring a device, such as an IoT device, to be continually connected to a network or a remote device, the techniques disclosed herein enable the device to remain offline until a specific event is detected. The disclosed technologies can avoid always-on network configurations while providing a desired functionality for an IoT device. For instance, some devices only connect with other computing devices or at network in response to detection of an event, then disconnect after an exchange of specific information. Such technologies can significantly reduce the power consumption of a device by only invoking connections at appropriate times.

Dynamic control of communication connections for computing devices based on detected events

A communications link between a computing device and an external device is monitored. A driver for the communications link is executed on the computing device. The driver is configured to monitor data traffic over the communications link. Data indicative of the monitored data traffic is received from the driver. The data is sent to an analysis function configured to identify a condition of the communications link based on accumulated data indicative of the data traffic. Data indicative of an identified condition of the communications link is received from the analytics function. An indication of the identified condition is rendered on a display device of the computing device.

Monitoring peripheral transactions

The disclosed technology adjusts hardware settings to map preferences consistently of a user experience across multiple hardware devices, despite there being different hardware capabilities and performance parameters among the different devices. A hardware settings translation engine receives a reference hardware setting of a reference computing device, a set of reference hardware performance parameter values, and a set of target hardware performance parameter values. The hardware settings translation engine then maps the set of target hardware performance parameter values to the set of reference hardware performance parameter values to yield a hardware adjustment map. The hardware settings translation engine determines the target hardware setting based on the reference hardware adjustment map and the reference hardware setting. The hardware settings translation engine sets the target hardware to the target hardware setting.

Computing device resource management

An apparatus may be manipulated using non-touch or hover techniques. Hover techniques may be associated with zooming, virtual feedback, authentication, and other operations. For example, a mobile device may receive data indicative of a hover gesture. The hover gesture may be sensed proximate to a rear of the mobile device. The level of zoom of a rendered image may be altered based on the hover gesture.

Device manipulation using hover

A facility for responding to the crash of a computing system subsystem is described. The facility detects a crash of the subsystem. In response to this detecting, the facility provides diagnostic information representing state of the peripheral subsystem to a crash analysis service, and restarts the subsystem without restarting the computing system.

Handling crashes of a device's peripheral subsystems

Examples for an intelligent watchdog timer for a computing device are described herein. The watchdog timer operates a watchdog counter that repetitively counts a watchdog count interval from an initial value to a final value. The watchdog counter is continually reset if the device is functioning properly. If the watchdog timer is allowed to reach a final count value, a processor reset is initiated. Several components operate to detect the current mode of operation of the processor or an operating system, and predict, in part based on user context, when different power states may occur. The components also forecast when the watchdog timer is scheduled to reach the final count value. Based on the forecasts of when the watchdog timer will reach the final count value and the predictions of future power states of the processor or operating system, the watchdog counter is selectively disabled or reset.

High availability and energy-efficient watchdog timer

Embodiments are disclosed that relate to multi boot mobile phone devices. In one example, a mobile phone device comprises one or more non-volatile storage devices including an empty partition, a blob partition storing two or more operating systems in a compressed format, a boot selection module configured to recognize user selection of at least one of the two or more operating systems, and a boot allocation module configured to, responsive to user selection of at least one of the two or more operating systems, split the empty partition into a different operating system partition for each selected operating system, decompress each selected operating system, and store each decompressed operating system on its respective operating system partition.

Dynamic partition dual boot mobile phone device

A crash dump system in a device includes firmware that determines when an atypical reboot of the device is about to occur and both sets a flag indicating there was an atypical reboot and stores in nonvolatile memory crash dump data based on the type of event that caused the atypical reboot. The crash dump data includes a reboot code indicating the type of event that was detected. When the device is subsequently restarted due to the reboot, the operating system detects that the flag was set, and in response to the flag being set collects and analyzes the crash dump data from the reserved memory. Crash analysis data is generated based on this analysis and sent is to a remote service for possible further action (e.g., analysis, notification of a developer, and so forth).

Growing community of inventors

Bellevue, WA, United States of America

Dejun Zhang