OS Driver Wake Detection for Mobile Connectivity Battery Drain

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing systems fail to address the inefficiencies in battery-powered devices, specifically due to high counts of suspicious wake instances in mobile connectivity chipsets like Wi-Fi chipsets during modern standby sessions, leading to poor battery performance.

Innovation Solution

Implement mobile connectivity device wake detection and diagnosis through an OS control message support driver that determines the cause of awakening, using reports from mobile connectivity and network adapters, and sends corresponding reports for further action.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Use of energy by moving object

If mobile connectivity chipset enters modern standby mode to save battery, then energy consumption is reduced, but suspicious wake instances occur causing poor battery performance

Engineering Contradiction:
Improvebattery consumptionVSAvoidbattery performance
Core Design Contradiction:
Use of energy by moving objectVSReliability

Solution Approach 1:

The patent segments the wake detection process into distinct categories (control path wake reasons, firmware-based wake reasons, data path wake reasons, and PCI bus-based wake reasons). Each category is handled by specific driver components that independently detect and report their respective wake causes, enabling granular analysis of suspicious wake instances while maintaining overall system power management.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements feedback mechanisms where wake reason information flows from chipset drivers through OS control message support drivers to diagnostic systems. This feedback loop enables continuous monitoring and analysis of wake events, allowing the system to identify patterns in suspicious wakes and implement corrective actions to improve battery performance.

Inventive Principle:
Principle #23Feedback

2Reliability

If wake detection and diagnosis system is implemented to improve battery performance, then battery performance improves, but system complexity increases

Engineering Contradiction:
Improvebattery performanceVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent creates a universal diagnostic framework that handles multiple types of wake reasons through a common architecture. The OS control message support driver and reporting mechanisms serve multiple functions: detecting wakes, categorizing causes, generating reports, and enabling diagnostics across different connectivity chipsets and scenarios, thereby managing complexity through consolidation.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces intermediary components (OS control message support drivers, report generation systems) that mediate between the chipset hardware and the diagnostic analysis system. These intermediaries abstract the complexity of wake detection details, providing a standardized interface for analyzing suspicious wakes without requiring direct complex interactions between all system components.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS20260003417A1Mobile connectivity device wake detection and diagnosis
Publication Date: 2026.01.01 MICROSOFT TECHNOLOGY LICENSING LLC
  • US20260003417A1 patent drawing
  • US20260003417A1 patent drawing
  • US20260003417A1 patent drawing

AI summary

Systems and methods are provided for implementing mobile connectivity device wake detection and diagnosis. After detecting that a mobile connectivity device on a device has been awakened, an operating system (“OS”) control message support driver running on an OS determines a cause of awakening of the mobile connectivity device. The determined cause of awakening of the mobile connectivity device includes one of a control path reason, a firmware-based reason, a data path reason, or a peripheral component interconnect (“PCI”) bus-based reason. Based on each of these determined causes of awakening of the mobile connectivity device, a corresponding report (e.g., a control path wake reason report, a firmware-based wake reason report, a data path wake reason report, or a PCI bus-based wake reason report) is sent for further action (e.g., analysis of the wake reasons for subsequent system updates or patches to address the underlying issues associated with the wake reasons).