Derivative works

Defensive Disclosure and Prior Art Generation for U.S. Patent 8,958,853

Publication Date: April 26, 2026
Subject: Derivative Works and Obvious Variations of Mobile Device Inactive Mode and Verification
Reference Patent: U.S. Patent 8,958,853 (the "'853 patent")

This document discloses a series of technical variations, enhancements, and alternative implementations of the core methods described in the '853 patent. The purpose of this disclosure is to establish prior art for subsequent inventions that may be considered incremental or obvious improvements upon the original concepts.

---

Derivative Works Based on Core Claims

1. Ultra-Wideband (UWB) Proximity-Based Inactive Mode with Biometric Driver Authentication

• Axis of Derivation: Material & Component Substitution
• Enabling Description: This variation replaces the generic "pairing" mechanism (e.g., Bluetooth) with a high-precision, low-latency positioning system using Ultra-Wideband (UWB) technology. The vehicle is instrumented with at least three UWB anchors to create a coordinate system. The mobile device, equipped with a UWB transceiver, performs two-way time-of-flight ranging with the anchors to determine its precise 3D position within the vehicle cabin with sub-10cm accuracy. The "inactive mode" is triggered only when two conditions are met: (1) the device's calculated position is within a predefined geometric volume corresponding to the driver's seat and immediate console area, and (2) a secondary authentication factor confirms the user is the driver. This secondary factor can be a biometric input, such as a fingerprint scan from a sensor integrated into the vehicle's ignition button or steering wheel, or an infrared facial recognition scan from a driver-facing camera. This dual-factor trigger mechanism robustly prevents false positives from passengers' devices.

sequenceDiagram
    participant Device as Mobile Device (UWB)
    participant Anchors as Vehicle UWB Anchors
    participant VCU as Vehicle Control Unit
    participant BioSensor as Biometric Sensor

    loop Ranging
        Device->>Anchors: Poll for Ranging
        Anchors-->>Device: Ranging Response (Time-of-Flight)
    end
    Device->>Device: Calculate 3D Position
    alt Position in Driver Zone
        Device->>VCU: Request Driver Authentication
        VCU->>BioSensor: Activate Sensor
        BioSensor-->>VCU: Biometric Data (e.g., fingerprint hash)
        VCU-->>Device: Authentication Token (Success/Fail)
        alt Authentication Success
            Device->>Device: Initiate Inactive Mode
        else Authentication Fail
            Device->>Device: Remain in Active Mode
        end
    else Position Outside Driver Zone
        Device->>Device: Remain in Active Mode
    end

2. AI-Powered Predictive Inactive Mode and Dynamic Message Generation

• Axis of Derivation: Integration with Emerging Tech (AI)
• Enabling Description: This derivative employs an on-device machine learning model to predict the need for an inactive mode and to dynamically generate context-aware away messages. The model is trained on user behavior patterns, calendar data, GPS history, and time of day. It can proactively suggest or automatically engage the inactive mode even before a vehicle pairing occurs, for example, when the user begins walking a route that historically precedes driving. More significantly, the away message functionality is enhanced by a local, quantized Large Language Model (LLM). When a communication is received, the LLM fuses data from the vehicle's navigation system (destination, ETA), the user's calendar, and the sender's relationship from the contact graph to generate a highly specific reply. For instance: "I am currently driving to the 'ACME Corp' meeting and am 12 minutes away. My ETA is 3:15 PM. I will respond then. If this is an emergency, reply with 'URGENT'." The system uses Natural Language Understanding (NLU) to parse incoming replies for such keywords to trigger an emergency alert to the user.

flowchart TD
    A[Incoming Communication Received] --> B{Inactive Mode Active?};
    B -->|Yes| C[Gather Context Data];
    B -->|No| Z[Provide Standard Notification];

    subgraph Context Aggregation
        C1[Navigation System: ETA, Destination]
        C2[Calendar: Current/Next Appointment]
        C3[Contacts Graph: Sender Relationship]
        C4[Message Content: NLP Analysis]
    end

    C --> C1 & C2 & C3 & C4;
    C1 & C2 & C3 & C4 --> D[On-Device LLM];
    D --> E[Generate Dynamic Away Message];
    E --> F[Transmit Message via Wireless Module];
    F --> G{Parse Incoming Reply for Urgency};
    G -->|'URGENT' Detected| H[Alert User];
    G -->|No Urgency| I[Log Communication];

3. Sterile Field Mode for Medical Devices in Surgical Theaters

• Axis of Derivation: Cross-Domain Application
• Enabling Description: The core concept is adapted for sterile environments like a surgical operating room (OR). A surgeon's or nurse's tablet/mobile device automatically enters a "Sterile Field Mode" upon entry into the OR. The trigger is the device's association with a specific medical-grade Wi-Fi network (SSID) that is geographically confined to the OR. In this mode, all standard notifications (emails, texts, non-critical app alerts) are suppressed to prevent distraction and maintain focus. The device's user interface is locked to a specific set of sanctioned applications, such as vital sign monitors, surgical checklists, or patient imaging viewers. For any incoming external communication, a server-side rule in the hospital's communication system (e.g., Microsoft Exchange) intercepts the message and sends a reply: "Dr. Smith is currently in a surgical procedure and cannot be reached. For urgent matters, please contact the OR front desk at ext. 555."

stateDiagram-v2
    [*] --> Active

    state Active {
        description Tablet has full functionality
        [*] --> Unrestricted_UI
        Unrestricted_UI --> Connected_Hospital_WiFi : Connects to general WiFi
    }

    state Sterile_Field_Mode {
        description Limited functionality, suppressed notifications
        [*] --> Restricted_UI
        Restricted_UI : Sanctioned Apps Only
        suppress_notifications: All non-critical alerts blocked
        auto_reply: Server sends "in surgery" message
    }

    Active --> Sterile_Field_Mode: Enters OR Geofence & Connects to 'OR_WiFi_SSID'
    Sterile_Field_Mode --> Active: Disconnects from 'OR_WiFi_SSID'

4. Blockchain-Based Immutable Certification Ledger for Insurance and Forensics

• Axis of Derivation: Integration with Emerging Tech (Blockchain)
• Enabling Description: This variation replaces the centralized certification server described in claims 8 and 9 of the '853 patent with a distributed ledger. When inactive mode is initiated, the mobile device constructs a data block containing the device's pseudonymous identifier, a vehicle identifier, a GPS timestamp, and a "mode_start" event flag. This block is cryptographically signed using the device's private key and submitted as a transaction to a permissioned blockchain (e.g., one based on Hyperledger Fabric). A similar "mode_end" transaction is sent upon deactivation. Authorized third parties, such as insurance providers or accident investigators, can be granted read-only access to this immutable ledger to verify the device's state at a specific time, without relying on a single, potentially fallible, central server.

sequenceDiagram
    participant Device as Mobile Device
    participant Blockchain as Permissioned Blockchain Network
    participant InsuranceCo as Insurance/Legal Entity

    Device->>Device: Initiate Inactive Mode
    Device->>Blockchain: Submit Signed Transaction (type: 'start', timestamp, deviceID, vehicleID)
    Blockchain->>Blockchain: Consensus & Add Block
    Note over Device, Blockchain: Device is now in certified inactive mode

    Device->>Device: Exit Inactive Mode
    Device->>Blockchain: Submit Signed Transaction (type: 'end', timestamp)
    Blockchain->>Blockchain: Consensus & Add Block

    Note over Blockchain, InsuranceCo: At a later time (e.g., for claim processing)
    InsuranceCo->>Blockchain: Query Ledger for deviceID and time period
    Blockchain-->>InsuranceCo: Return Immutable Record of Inactive Session

5. Graceful Degradation and Failsafe Emergency Override Mode

• Axis of Derivation: The "Inverse" or Failure Mode
• Enabling Description: This design accounts for unreliable connectivity and emergency situations. If the primary trigger connection (e.g., Bluetooth) is lost intermittently for a period below a defined threshold (e.g., 45 seconds), the system enters a "Limited Interaction Mode" rather than fully deactivating the safety feature. In this mode, the screen remains off, but it allows for hands-free, voice-activated interaction with whitelisted contacts or a navigation app. If the connection is lost for longer, the inactive mode is fully disengaged. A critical failsafe is also included: an "Emergency Override" can be triggered by a specific, hard-to-spoof voice command (e.g., a user-defined safe-phrase) or by receiving an incoming call from a pre-designated emergency contact. When triggered, the inactive mode is immediately terminated, the device volume is maximized, and GPS location data is sent via SMS to that emergency contact.

stateDiagram-v2
    state "Inactive" as Inactive
    state "Limited Interaction" as Limited
    state "Active" as Active

    [*] --> Active
    Active --> Inactive: Vehicle Paired
    Inactive --> Active: Vehicle Unpaired (>45s)

    Inactive --> Limited: Connection Lost (<45s)
    Limited --> Inactive: Connection Restored
    Limited --> Active: Connection Lost (>45s)

    Inactive --> Active: Emergency Override Triggered
    Limited --> Active: Emergency Override Triggered

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with W3C Vehicle Information Service Specification (VISS)

• Scenario: The trigger for initiating the inactive mode is not merely the establishment of a Bluetooth link, but a more intelligent determination made by subscribing to standardized vehicle data signals using the W3C VISS protocol. A web-based application on the mobile device acts as a VISS client, connecting to the vehicle's onboard server. The application subscribes to the Vehicle.Chassis.Speed and Vehicle.Cabin.Seat.Row1.Pos1.IsOccupied data paths. The inactive mode logic is programmed to engage only when Speed is greater than a threshold (e.g., 5 km/h) AND IsOccupied is true, ensuring the mode is active only when the car is moving and someone is in the driver's seat. This leverages a public, open standard to create a more robust and context-aware trigger than simple device pairing.

2. Combination with Free and Open Source Software (FOSS) Authenticator (FreeOTP)

• Scenario: This applies to the remote activation feature (e.g., for parental control). A remote server can request that a device enter inactive mode. To prevent spoofing or unauthorized activation, this request must be validated using a Time-based One-Time Password (TOTP) compliant with RFC 6238. The target mobile device runs a service that acts as a TOTP validator. The authenticating entity (e.g., a parent's phone) uses an open-source application like FreeOTP to generate a code from a shared secret. The activation command sent to the target device must include this valid TOTP. This combines the patent's remote activation concept with a well-established, open-source security standard for command authentication.

3. Combination with the Matrix Communication Protocol

• Scenario: The "away message" functionality is integrated into a decentralized, end-to-end encrypted communication network using the open Matrix protocol. Upon entering inactive mode, the user's Matrix client application (e.g., Element) automatically executes three actions: (1) it updates the user's global presence state to "Driving" with a custom status message (the selected "away message"), (2) it enables an auto-reply "bot" feature within the client that responds to any direct messages or mentions with the away message, and (3) for designated high-priority "rooms" (e.g., family chat), it mutes notifications instead of auto-replying, allowing messages to be received silently. This extends the simple SMS/email reply concept into a modern, secure, and richer communication ecosystem.