Derivative works — US Patent 7305442

Defensive Disclosure: Asynchronous Content Delivery Based on Compound Device State Triggers

Publication Date: May 12, 2026
Subject: Methods and systems for triggering the delivery or display of content on a terminal based on the concurrent detection of an idle state and a substantially stationary state. This document is intended to enter the public domain and serve as prior art for future inventions in this field.

Derivative 1: Component Substitution for State Detection

1.1 Biometric and Ambient Sensor-Based Idle State Detection

Enabling Description: The determination of a device's "idle" state is enhanced by moving beyond keyboard or screen-touch events. A forward-facing camera on a mobile terminal or AR headset is used in conjunction with a lightweight computer vision model to perform eye-tracking. An "idle" state is triggered when the user's gaze is detected as being directed away from the device's screen for a configurable period (e.g., >15 seconds). Alternatively, an integrated biometric sensor, such as a photoplethysmography (PPG) sensor in a smartwatch, can determine a user's resting heart rate. An "idle" state is inferred when the heart rate drops below a personalized resting threshold, indicating user inactivity. A proximity sensor can also be used; if the device detects it is face-down on a surface or inside a pocket or bag, it is deemed "idle."

Diagram:

stateDiagram-v2
    [*] --> Active: User Interaction
    Active --> Idle: Gaze Averted > 15s
    Active --> Idle: Proximity Sensor Obscured
    Active --> Idle: Heart Rate < Resting Threshold
    Idle --> Active: Gaze Detected on Screen
    Idle --> Active: Device Picked Up

1.2 Wi-Fi RTT and Inertial Measurement Unit (IMU) for Stationary State Detection

Enabling Description: Instead of relying solely on a power-intensive Global Positioning System (GPS) receiver, the "substantially stationary" state is determined using a combination of high-frequency, low-power sensors. For indoor environments, the system utilizes the IEEE 802.11mc Wi-Fi Round-Trip Time (RTT) protocol to triangulate the device's position relative to nearby Wi-Fi access points. A "stationary" state is declared when the calculated position remains within a 1-meter-radius circle for a period of at least 60 seconds. Concurrently, data from the device's internal IMU (accelerometer and gyroscope) is processed by a Kalman filter to detect micro-movements. A lack of significant motion vectors from the IMU data corroborates the stationary state, allowing the GPS radio to remain powered down to conserve energy.

Diagram:

flowchart TD
    subgraph Stationary State Determination
        A[Wi-Fi APs] -- RTT Ping --> B(Device Wi-Fi Chipset);
        C[IMU Sensor] -- Raw Data --> D(On-device Kalman Filter);
        B --> E{Position Calculation};
        D --> F{Motion Vector Analysis};
        E -- Positional Data --> G[State Aggregator];
        F -- Motion State --> G;
        G --> H{Is ΔPosition < 1m for 60s?};
        G --> I{Is Motion Vector Null?};
        H -- Yes --> J[Trigger Stationary Flag];
        I -- Yes --> J;
    end

Derivative 2: Cross-Domain Applications

2.1 Aerospace: Sterile Cockpit Integrity System

Enabling Description: The core mechanism is adapted to manage information flow to an aircraft's Electronic Flight Bag (EFB) to enforce "sterile cockpit" rules. Non-essential communications from Airline Operations (e.g., gate change information for the next flight leg, passenger manifest updates) are queued on a ground server. The system monitors the aircraft's state. The "idle" state is defined as the aircraft's engines being spooled down (via ACARS data link). The "stationary" state is defined by the aircraft's GPS reporting a ground speed of zero and its position being within the geofenced coordinates of a designated airport gate or hardstand. Only when both conditions are met is the queued, non-essential data transmitted to the EFB for the flight crew to review, preventing distraction during taxi, takeoff, approach, and landing phases.

Diagram:

sequenceDiagram
    participant GroundServer
    participant AircraftSystem
    participant EFB

    GroundServer->>AircraftSystem: Queue Non-Essential Update
    loop State Check
        AircraftSystem->>AircraftSystem: Monitor Engine RPM (ACARS)
        AircraftSystem->>AircraftSystem: Monitor GPS Ground Speed & Position
    end
    Note right of AircraftSystem: Trigger: Engine RPM = 0 AND<br/>Ground Speed = 0 AND<br/>Position = Gate Coordinates
    AircraftSystem->>EFB: Transmit Queued Update
    EFB-->>GroundServer: Acknowledge Receipt

2.2 AgTech: Autonomous Vehicle Task Package Delivery

Enabling Description: A system for managing autonomous agricultural drones or tractors. New task packages (e.g., updated crop-spraying flight paths, soil-sampling coordinates) are prepared at a central server. The system will not push an update to a vehicle while it is in operation. Delivery is triggered only when the vehicle reports a state of "idle," defined as the completion of its currently assigned task package, and "stationary," defined as the vehicle being physically docked at its designated recharging or refueling station, confirmed by an NFC or QR code handshake at the station. This ensures that operational parameters are not changed mid-task, which could result in mission failure or physical damage.

Diagram:

flowchart LR
    A[Central Server] -- New Task Package --> B(Queue);
    B -- Ready --> C{Check Vehicle State};
    D[Autonomous Tractor] -- Task Complete --> E(Idle Flag);
    D -- Docked at Station --> F(Stationary Flag);
    E & F --> C;
    C -- Idle AND Stationary --> G[Push Update to Tractor];
    G --> D;

2.3 Medical: Patient-Centric Device Firmware Management

Enabling Description: A system for delivering firmware updates to a patient's wearable insulin pump. To ensure patient safety, updates are never pushed during active insulin delivery. An update is queued on the manufacturer's server. The "idle" state is triggered when the pump's internal log confirms no active bolus or basal rate adjustment has occurred for a predetermined time (e.g., 30 minutes). The "stationary" state is triggered when the patient's paired smartphone, using accelerometer data, determines the patient is in a state of rest or sleep (e.g., minimal movement for over 20 minutes). When both the pump is functionally idle and the patient is physically at rest, the firmware update is downloaded and installed, followed by an automatic self-check, minimizing any risk or disruption to the patient.

Diagram:

stateDiagram-v2
    state "Firmware Update" as Update {
        state "Queued" as Q
        state "Delivering" as D
        state "Installed" as I
        [*] --> Q: New Firmware Available
        Q --> D: on_trigger(pump_idle AND patient_stationary)
        D --> I: Download & Install Complete
        I --> [*]
    }
    state "Pump State" as Pump {
        Active_Delivery --> Idle: No Bolus/Basal Change > 30min
        Idle --> Active_Delivery: Insulin Delivery Initiated
    }
    state "Patient State" as Patient {
        Active --> Stationary: Accelerometer Detects Rest > 20min
        Stationary --> Active: Movement Detected
    }

Derivative 3: Integration with Emerging Technology

3.1 AI-Optimized Predictive Content Triggering

Enabling Description: The fixed thresholds for "idle" and "stationary" are replaced with a predictive model running on the device or at the network edge. The model is trained on user-specific historical data, including time of day, calendar appointments, device sensor readings (accelerometer, ambient light), and location semantics (home, work, transit). The AI predicts moments of high user receptivity, which dynamically defines the trigger conditions. For example, the model may learn that a user is receptive to food delivery ads when they are stationary at their work location between 11:30 AM and 12:30 PM and their device has been idle for >2 minutes. The AI generates a "receptivity score," and content is delivered when this score exceeds a threshold, rather than being based on rigid rules.

Diagram:

flowchart TD
    A[Device Sensors] --> B(Feature Extraction);
    C[User Calendar] --> B;
    D[Location History] --> B;
    B --> E[Recurrent Neural Network Model];
    E -- Receptivity Score --> F{Score > Threshold?};
    F -- Yes --> G[Trigger Content Delivery];
    F -- No --> A;
    G -- Feedback (Dismiss/Engage) --> H(Model Retraining);
    H --> E;

3.2 IoT-Correlated Environmental Triggering

Enabling Description: The trigger event is expanded beyond the state of the mobile terminal to include real-time data from disparate IoT sensors in the user's environment. Authorization for content is associated with specific environmental conditions. For example, a user authorizes "smart home" related offers. A content delivery trigger occurs only when the user's mobile phone is idle and stationary within their home's geofence, AND a separate IoT smart plug reports that the connected, non-smart air conditioning unit has been running for more than 4 hours, AND an IoT weather sensor reports an external temperature above 30°C. This compound, multi-device trigger initiates the delivery of an ad for a smart thermostat upgrade.

Diagram:

sequenceDiagram
    participant UserPhone
    participant SmartPlug
    participant WeatherSensor
    participant AdServer

    loop Continuous Monitoring
        UserPhone->>UserPhone: Check Idle & Stationary State
        SmartPlug->>AdServer: Report AC Runtime > 4hrs
        WeatherSensor->>AdServer: Report Temp > 30°C
    end
    Note over UserPhone, AdServer: Trigger: Phone Idle/Stationary at Home<br/>AND AC Runtime > 4hrs<br/>AND Temp > 30°C
    AdServer->>UserPhone: Send Smart Thermostat Ad

3.3 Blockchain-Verified Consent and Delivery Ledger

Enabling Description: The entire advertising process is managed via a decentralized ledger. When a user authorizes advertising, a non-fungible token (NFT) representing consent is minted to their crypto wallet. This "Consent NFT" contains the specific rules of engagement (e.g., max ads per day, categories allowed). To deliver an ad, an advertiser's smart contract must first verify the existence and validity of this NFT in the user's wallet. When the network-side server detects the idle/stationary trigger conditions, it calls a function in the smart contract. The smart contract then logs the trigger event (with hashed location and timestamp) to the blockchain as proof of compliant delivery and automatically executes a micropayment from the advertiser's wallet to the user's and/or network operator's wallet.

Diagram:

erDiagram
    USER ||--o{ CONSENT_NFT : "has"
    ADVERTISER ||--o{ SMART_CONTRACT : "deploys"
    SMART_CONTRACT {
        string function "verifyConsent"
        string function "logDelivery"
        string function "executePayment"
    }
    CONSENT_NFT {
        string rules
        string wallet_address
    }
    DELIVERY_LOG {
        string trigger_event_hash
        string timestamp
        string ad_id
    }
    SMART_CONTRACT }o--|| CONSENT_NFT : "verifies"
    SMART_CONTRACT }o--o{ DELIVERY_LOG : "creates"

Derivative 4: Inverse and Limited-Functionality Modes

4.1 Graceful Degradation Mode for Low-Resource States

Enabling Description: The system is designed to operate in a resource-aware, limited-functionality mode. The mobile terminal monitors its own battery level, network connectivity (e.g., 5G vs. congested 3G), and available memory. If the battery is below 20% or the network signal is weak, the content delivery logic changes. Upon receiving authorization, the server sends a low-footprint "manifest" file instead of a full rich-media ad. This manifest contains a text-only description, a thumbnail URL, and the full ad URL. When the idle/stationary trigger occurs, the device displays only the text and thumbnail. The user can then choose to tap and download the full ad, giving them control over resource usage. The "stationary" check may also be disabled in this mode to save sensor power, relying only on the "idle" trigger.

Diagram:

graph TD
    A{Device State Check};
    A -- Normal --> B[Download Full Ad];
    A -- Low Battery / Weak Signal --> C[Download Low-Footprint Manifest];
    B --> D{Trigger: Idle & Stationary};
    D --> E[Display Full Ad];
    C --> F{Trigger: Idle Only};
    F --> G[Display Text & Thumbnail];
    G -- User Tap --> H[Download & Display Full Ad];

Combination Prior Art with Open-Source Standards

1. Combination with AOSP Notification and Power Management APIs: The patented method is implemented as a core service within the Android Open Source Project (AOSP). The JobScheduler and PowerManager services are extended to include a "stationary" state flag, derived efficiently from the system's existing fused location provider. A new API, OpportunisticContentManager, is exposed to third-party apps. Apps can register content (e.g., a pre-fetch for a social media feed, a news article update, or an advertisement) with this manager, flagging it for delivery when the PowerManager reports both isDeviceIdle() and isDeviceStationary() are true. This makes the invention a standardized, power-efficient, and publicly documented feature of the operating system.
2. Combination with Matter Smart Home Standard: An advertising or content delivery system operates as a "Matter Device" on a user's local network. The user's mobile phone acts as the "Matter Commissioner" and grants consent for content delivery via the standard Matter Distributed Compliance Ledger. The trigger for content display on a Matter-enabled device (like a smart display or TV) is a compound event defined by the Matter interaction model. The trigger is satisfied when the user's mobile phone (another Matter device) reports its state as idle:true and stationary:true, AND the target display device reports its own state as power:on and input:home_screen. This creates a standardized, interoperable, and secure method for contextual content delivery in a smart home environment.
3. Combination with IETF Geopriv Standards (RFC 6280): The system adheres to the IETF's Geopriv framework for managing location information with privacy controls. The user creates a policy document (a "rule") that is stored on their device or by their network provider (the "Location Server"). This rule states that a "Location Recipient" (the advertising system) is permitted to receive the user's location only when a secondary condition is met: the device's idle status is true. The advertising system, upon receiving an ad request, first queries the Location Server. The Location Server checks the Geopriv rule: it queries the device for its idle status, and if true, it then determines the location and "stationary" state and provides a "YES" or "NO" answer to the ad system, without necessarily revealing the precise location, thus triggering the ad delivery in a standardized, privacy-preserving manner.