Derivative works — US Patent 12337715

Defensive Disclosure for U.S. Patent No. 12,337,715

Publication Date: May 13, 2026
Subject: Methods and Systems for Sharing E-Keys to Access Controllable Assets

This document is intended to enter the public domain as prior art. The following disclosures describe variations and new applications of the core concepts claimed in U.S. Patent 12,337,715 (henceforth '715 patent'), with the objective of making future incremental improvements obvious to a person skilled in the art. The core concept involves a server-mediated process for generating a time-bound or condition-limited electronic key (e-key) for a vehicle, transmitting it to a recipient's device, and monitoring vehicle use against the specified conditions.

Core Claim 1 Analysis (based on patent description)

The '715 patent describes a method executed by a server, comprising:

Receiving a request from an authorized user (e.g., owner, administrator) to generate an e-key for a recipient to use a specific vehicle.
The request includes recipient identification (e.g., phone number, email) and conditions of use (e.g., geo-fence, speed limit, time limit).
Generating the e-key associated with the vehicle and the conditions.
Transmitting the e-key to the recipient's device.
Transmitting enabling data to the vehicle.
Receiving use data from the vehicle during the e-key session.
Detecting violations of the conditions based on the use data.
Sending a warning notification to the recipient and/or vehicle upon violation.

Derivative Disclosures Based on Core Claim 1

1. Material & Component Substitution

Derivative 1.1: Quantum Key Distribution (QKD) for E-Key Generation and Transmission

Enabling Description: The server-side e-key generation module is replaced with a Quantum Key Distribution (QKD) system. The "e-key" is not a static code but a stream of single-use quantum keys generated in real-time. The server and the vehicle's telematics control unit (TCU) share a quantum communication channel (e.g., polarized photons over fiber optic or free-space laser). The recipient's smartphone acts as a "trusted node" to initiate the key exchange. When the owner sends a request, the server establishes a secure channel with the vehicle's TCU. The recipient's device, using a standard asymmetric encryption app (e.g., Signal Protocol), sends a signed token to the vehicle via NFC or UWB. The vehicle validates this token with the server over the quantum channel. The server then authorizes the vehicle to generate a local, short-lived cryptographic session key, which it shares with the recipient's device to enable vehicle functions. This substitutes the central server's "e-key" with a dynamically generated, physically unclonable key pair, rendering interception computationally impossible rather than just difficult.
```
sequenceDiagram
    participant OwnerApp
    participant EKey_QKD_Server as E-Key QKD Server
    participant VehicleTCU as Vehicle TCU (Quantum-enabled)
    participant RecipientDevice

    OwnerApp->>EKey_QKD_Server: Request E-Key(Recipient, Conditions)
    EKey_QKD_Server-->>VehicleTCU: Establish Quantum Channel
    Note over EKey_QKD_Server,VehicleTCU: Continuous Quantum Key Exchange
    EKey_QKD_Server->>RecipientDevice: Send Authorization Token (via SMS/Email)
    RecipientDevice->>VehicleTCU: Present Token (NFC/UWB)
    VehicleTCU->>EKey_QKD_Server: Verify Token via Quantum Channel
    EKey_QKD_Server-->>VehicleTCU: Token Valid. Authorize Session.
    VehicleTCU-->>RecipientDevice: Provide Local Session Key (BLE/UWB)
    RecipientDevice->>VehicleTCU: Unlock/Start commands (signed with Session Key)
```

Derivative 1.2: In-Vehicle Biometric Sensor as the "Device"

Enabling Description: The recipient's "device" is substituted with the vehicle's own biometric sensors (e.g., fingerprint scanner on the door handle, facial recognition camera in the B-pillar, or palm vein scanner on the steering wheel). The owner enrolls the recipient's biometric template (e.g., a hashed fingerprint or facial map) into the cloud server profile. When the owner grants access, the server pushes the encrypted biometric template to the vehicle's secure enclave. The recipient approaches the vehicle and presents their biometric data. The vehicle's onboard processor performs a 1:1 match against the downloaded template. If successful, the vehicle authenticates and unlocks. This removes the dependency on a secondary electronic device like a smartphone, making the user's biological identity the key. Communication with the server is only needed for the initial template download and subsequent use logging.
```
flowchart TD
    A[Owner on App] -- 1. Request E-Key --> B{Cloud Server};
    B -- 2. Enroll Biometric Data --> C[Recipient provides fingerprint scan];
    B -- 3. Push Encrypted Template --> D[Vehicle's Secure Enclave];
    E[Recipient places finger on door handle] -- 4. Biometric Scan --> F{Vehicle's Onboard Processor};
    F -- 5. Compare Scan to Template --> G{Match?};
    G -- Yes --> H[Unlock Vehicle & Apply Conditions];
    G -- No --> I[Access Denied];
    H -- 6. Log access & usage data --> B;
```

2. Operational Parameter Expansion

Derivative 2.1: E-Key for Deep-Sea Autonomous Underwater Vehicles (AUVs)

Enabling Description: The system is adapted for a fleet of AUVs operating at depths up to 11,000 meters (e.g., in the Mariana Trench). The "e-key" grants access to specific sensor payloads or mission plans. Due to the lack of real-time connectivity, the e-key and its associated conditions are pre-loaded onto the AUV before deployment. The "server" is a surface vessel's mission control computer. A scientist (the "owner") issues a mission-specific e-key to another researcher (the "recipient") via a secure ship-to-shore link. The e-key, with conditions like "activate sonar only below 5,000 meters" or "disable propulsion if pressure exceeds 110 MPa," is bundled into the mission plan file. The AUV's hardened flight computer continuously monitors its depth, pressure, and system status. If a condition is violated, the AUV's software triggers a fail-safe action, such as aborting the current sub-mission, surfacing, or jettisoning the payload to ensure vehicle survival. Usage logs are stored on solid-state drives and retrieved upon the AUV's return.
```
stateDiagram-v2
    [*] --> Deployed
    Deployed: AUV descending
    Deployed --> Mission_Active: Depth > 1000m
    Mission_Active: Executing pre-loaded plan
    Mission_Active --> Fail_Safe: Pressure > 110 MPa
    Mission_Active --> Data_Logging_Violation: Sonar activated at 4500m
    Data_Logging_Violation --> Mission_Active: Log event, continue mission
    Fail_Safe: Abort sub-mission, surface
    Fail_Safe --> Surfaced: Reach surface
    Mission_Active --> Surfaced: Mission Complete
    Surfaced --> [*]
```

Derivative 2.2: Nanorobotic E-Keys for Targeted Drug Delivery

Enabling Description: The "vehicle" is a swarm of programmable nanorobots injected into a patient's bloodstream. The "e-key" is a specific biochemical or frequency-based signal that activates the nanorobots. A physician uses a central server to program a treatment plan, which defines the activation e-key and the conditions for drug release. The conditions could be "release payload only when pH level is below 6.5" (indicative of a tumor microenvironment) or "remain inert if body temperature exceeds 39°C." The e-key signal is transmitted to the nanorobots via a wearable ultrasonic transducer worn by the patient. The nanorobots, equipped with chemical and thermal sensors, continuously monitor the local environment. When the correct e-key signal is received AND the environmental conditions are met, they release their therapeutic payload. Any release event is recorded by detecting a byproduct, which is then sensed by the wearable and transmitted back to the server for a use log. Violation notifications are triggered on the physician's dashboard.
```
graph TD
    subgraph Wearable Device (Recipient)
        A[Ultrasonic Transducer]
    end
    subgraph Bloodstream (Vehicle)
        B{Nanorobot Swarm}
        B -- Senses Environment --> C{Condition Met? (pH < 6.5)};
    end
    subgraph Remote System
        D[Physician's Server]
    end
    D -- 1. Program E-Key & Conditions --> A;
    A -- 2. Transmit E-Key Signal --> B;
    C -- Yes --> E[Release Drug Payload];
    C -- No --> F[Remain Inert];
    E -- 3. Release Byproduct Detected --> A;
    A -- 4. Send Usage Log to Server --> D;
```

3. Cross-Domain Application

Derivative 3.1: Aerospace - Satellite Payload Access Management

Enabling Description: A multi-tenant satellite operated by a commercial entity rents out payload capacity (e.g., cameras, transponders) to different clients. The satellite operator's ground station acts as the server. A client (e.g., a university research team) can issue temporary e-keys to guest researchers to access a specific instrument. The request, sent to the ground station, specifies the recipient, the instrument (the "vehicle"), and conditions like "access allowed only during orbital pass over Antarctica" or "maximum power draw of 50W." The e-key, in the form of an encrypted command token, is sent to the guest researcher's terminal. The researcher embeds this token in their command uplink. The satellite's onboard computer validates the token and checks the orbital position and power telemetry against the conditions before granting access. All command executions and telemetry are logged as "use data" and sent back to the ground station. Violations trigger an automated lockout of the user's credentials and an alert to the satellite operator.
```
sequenceDiagram
    autonumber
    Client->>GroundStation: Request E-Key (Instrument, Researcher, Orbit-Condition)
    GroundStation->>Researcher: Issue Command Token
    Researcher->>Satellite: Uplink Command(Token, Action)
    Satellite->>Satellite: Validate Token
    Satellite->>Satellite: Check Telemetry vs. Orbit-Condition
    alt Conditions Met
        Satellite->>Satellite: Execute Instrument Command
        Satellite->>GroundStation: Downlink Log(Success, Telemetry)
    else Conditions Not Met
        Satellite->>GroundStation: Downlink Log(Violation, Telemetry)
        GroundStation->>Client: Send Violation Alert
    end
```

Derivative 3.2: AgTech - Autonomous Tractor & Implement Permissioning

Enabling Description: A large farm cooperative manages a fleet of autonomous tractors and various implements (planters, sprayers, harvesters). The farm manager uses a central server to assign e-keys to contract workers or other farms in the co-op. A request might grant a worker access to "Tractor #7" with the "Fungicide Sprayer" implement for a specific field (defined by a geofence) between 4 AM and 8 AM. The e-key is sent to the worker's tablet. The tablet communicates with the tractor via a local mesh network (e.g., LoRaWAN). The tractor's onboard computer verifies the e-key and enables the specified functions. "Use data" includes GPS logs, fuel/charge consumed, amount of fungicide dispensed, and video feeds from onboard cameras. If the tractor strays from the geofence or the worker attempts to operate it outside the permitted time, the system sends an alert and can immobilize the vehicle.
```
erDiagram
    FARM_MANAGER ||--o{ E_KEY_REQUEST : creates
    E_KEY_REQUEST {
        string recipient_id
        string tractor_id
        string implement_id
        string geofence_data
        datetime start_time
        datetime end_time
    }
    SERVER ||--|{ E_KEY_REQUEST : processes
    SERVER }|..|{ WORKER_TABLET : sends_ekey
    WORKER_TABLET ||--|{ TRACTOR : controls
    TRACTOR {
        string tractor_id
        string current_implement
        string gps_location
        float fuel_level
    }
    TRACTOR ||--|{ USAGE_LOG : generates
    USAGE_LOG {
        datetime timestamp
        string event_type
        string event_data
    }
    SERVER ||--|{ USAGE_LOG : receives
```

Derivative 3.3: Consumer Electronics - Smart Home Guest Access with Appliance-Level Control

Enabling Description: A homeowner uses a smart home hub (server) to grant temporary e-keys to a house sitter. The e-key, sent to the sitter's smartphone, provides tiered access to different devices. The associated conditions are granular: "Thermostat control enabled, but only between 18°C and 22°C," "Smart TV access granted, but parental controls are locked," "Front door lock can be operated, but not between 1 AM and 5 AM." The sitter's phone communicates with the home hub via Wi-Fi/Bluetooth. The hub acts as a central policy enforcement point, checking each command from the sitter's phone against the e-key's conditions before relaying it to the target device (e.g., a Zigbee light bulb or Z-Wave lock). Every action is logged, and if the sitter attempts to change the thermostat to 25°C, the command is rejected, and the homeowner receives a push notification.
```
flowchart LR
    subgraph Homeowner
        A[App on Phone] -- Request E-Key --> B[Smart Home Hub (Server)];
    end
    subgraph House Sitter
        D[App on Phone]
    end
    B -- Sends E-Key & Conditions --> D;
    D -- Command: Set Temp to 25°C --> B;
    B -- Checks Condition (Max 22°C) --> E{Violation?};
    E -- Yes --> F[Reject Command];
    F --> G[Send Notification to Homeowner];
    E -- No --> H[Execute Command on Device];
    H --> I[Log Usage Data];

    style F fill:#f99,stroke:#333,stroke-width:2px
    style G fill:#f99,stroke:#333,stroke-width:2px
```

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Dynamic Condition Generation

Enabling Description: The server integrates a machine learning model (e.g., a recurrent neural network) trained on historical vehicle usage data, traffic patterns, weather forecasts, and the driver's known skill level (e.g., from an insurance telematics profile). When an owner requests an e-key for a teenage driver, instead of manually setting a speed limit, they select a "Safe Teen Driver" policy. The AI model dynamically generates and updates the conditions. If it's raining, the AI lowers the maximum allowed speed and increases the required following distance, sending these updates to the vehicle in real-time. If the vehicle enters a known high-crime area at night, the AI might add a condition to disable engine-off events for more than 5 minutes. The "use data" feeds back into the model to continually refine its risk assessments.
```
graph TD
    U[User Request: "E-Key for Teen"] --> S[Server];
    S --> AI[AI Policy Engine];
    subgraph External Data
        W[Weather API] --> AI;
        T[Traffic API] --> AI;
        D[Driver History DB] --> AI;
    end
    AI --> C[Generate Conditions: speed=f(rain), geofence=f(time)];
    S -- 1. Send E-Key & Conditions --> R[Recipient Device];
    S -- 2. Send Policy to Vehicle --> V[Vehicle];
    V -- 3. Usage Data --> S;
    S -- 4. Feedback Loop --> AI;
```

Derivative 4.2: IoT Sensor Fusion for Condition Verification

Enabling Description: The "condition of use" is not limited to GPS and speed but incorporates data from a wide array of IoT sensors both inside and outside the vehicle. The e-key may have a "No Smoking" condition. The vehicle's built-in air quality sensor (an IoT device) detects particulate matter consistent with cigarette smoke, triggering a violation warning. An "Authorized Driver Only" condition is verified not just by the phone's proximity but by an in-car weight sensor in the driver's seat and a BLE beacon worn by the authorized driver, ensuring the correct person is in control. A "No Heavy Cargo" condition for a rental car is monitored by aftermarket strain gauges placed on the suspension axles, which report anomalous load data to the server, triggering a violation if the pre-set payload is exceeded.
```
classDiagram
    class Server {
      +receiveEKeyRequest()
      +generateEKey(conditions)
      +monitorUsage()
    }
    class Vehicle {
      +onboardComputer
      +gpsSensor
      +speedSensor
      +receiveEKey()
      +reportTelemetry()
    }
    class IoTSensor {
      <<interface>>
      +readData()
    }
    class AirQualitySensor {
      +particulateMatterLevel
    }
    class SeatWeightSensor {
      +currentWeight
    }
    class SuspensionStrainGauge {
      +loadValue
    }
    Server "1" -- "1..*" Vehicle : Manages
    Vehicle "1" -- "1..*" IoTSensor : Aggregates_Data_From
    IoTSensor <|-- AirQualitySensor
    IoTSensor <|-- SeatWeightSensor
    IoTSensor <|-- SuspensionStrainGauge
```

Derivative 4.3: Blockchain for Immutable E-Key Auditing (Rental & Fleet)

Enabling Description: Every e-key issuance, modification, revocation, and vehicle usage event is recorded as a transaction on a private, permissioned blockchain (e.g., Hyperledger Fabric). The server, the vehicle, and the owner's/recipient's devices are all nodes on this network. When an e-key is generated, a smart contract is created on the blockchain that codifies the conditions of use. The vehicle's TCU directly writes telemetry data (signed with its private key) to the blockchain. This creates an immutable, non-repudiable audit trail. This is particularly useful for rental companies to resolve disputes over speeding fines, damages (by correlating accelerometer data with a specific time), or unauthorized usage. The "warning notification" is also a transaction on the chain, providing proof that the user was alerted.
```
sequenceDiagram
    participant User
    participant RentalServer
    participant Blockchain
    participant Vehicle

    User->>RentalServer: Request E-Key
    RentalServer->>Blockchain: Deploy SmartContract(Conditions)
    RentalServer->>User: Send E-Key (references SmartContract)
    User->>Vehicle: Present E-Key
    Vehicle->>Blockchain: Query SmartContract(Conditions)
    loop While Driving
        Vehicle->>Blockchain: WriteTransaction(Signed Telemetry)
    end
    Vehicle->>Blockchain: DetectViolation()
    Blockchain->>RentalServer: Emit ViolationEvent
    RentalServer->>User: Send Warning Notification
```

5. The "Inverse" or Failure Mode

Derivative 5.1: Fail-Secure "Limp Home" Mode

Enabling Description: If the vehicle detects a potential security breach of the e-key system (e.g., GPS spoofing, repeated failed authentication attempts, or loss of heartbeat signal from the server for an extended period), it enters a "Limp Home" mode. In this state, functionality is severely restricted based on a pre-loaded policy. For example, the engine power is reduced to 25%, the maximum speed is capped at 30 km/h, the infotainment system is disabled (displaying only a "Security Alert" message), and the climate control is turned off. The vehicle will only permit travel towards a pre-defined "safe address" (e.g., the owner's home or a registered dealer service center), using its last known valid GPS location to determine the correct direction. Any deviation from this route will cause the vehicle to safely coast to a stop and engage its hazard lights.
```
stateDiagram-v2
    state "Normal Operation" as Normal
    state "Limp Home Mode" as Limp
    state "Secure Shutdown" as Shutdown

    [*] --> Normal
    Normal --> Limp: Security Breach Detected
    Limp --> Limp: Driving towards Safe Zone
    Limp --> Shutdown: Deviates from Safe Route
    Limp --> Normal: Owner remotely authenticates & resets
    Shutdown --> [*]: Manual override by technician
    note right of Limp
        - Max speed: 30 km/h
        - Engine Power: 25%
        - Infotainment: Disabled
        - Route: Locked to Safe Zone
    end note
```

Combination Prior Art Scenarios

Combination with OAuth 2.0: The process of granting an e-key is implemented using the OAuth 2.0 Authorization Code Grant flow. The vehicle owner's app acts as the Resource Owner. The vehicle itself is the Resource Server. The server from the '715 patent is the Authorization Server. The recipient's app is the Client. The "e-key" is an access token with custom scopes corresponding to vehicle functions (door:unlock, engine:start) and claims encoding the usage conditions (max_speed:80, geo_fence:polygon(...)). This combines the method of the '715 patent with a widely-used, open standard for delegated authorization, making the implementation obvious to any software engineer familiar with web security.
Combination with MQTT (Message Queuing Telemetry Transport): The communication between the server, vehicle, and recipient's device is performed over an MQTT message broker, a standard ISO/IEC 20922 protocol for IoT. The vehicle subscribes to a topic like vehicle/[VIN]/commands. The server publishes e-key authorizations and condition updates to this topic. The vehicle publishes its telemetry to vehicle/[VIN]/telemetry. The recipient's device is granted temporary publish rights to vehicle/[VIN]/user_actions. This combination uses an open-source, lightweight pub/sub protocol to achieve the data transmission steps of the '715 patent, representing a standard and obvious design pattern for IoT device management.
Combination with W3C Verifiable Credentials (VC): The e-key is structured as a W3C Verifiable Credential. The server (Issuer) issues a VC to the recipient (Holder). The VC contains claims about the granted permissions (e.g., canOperateVehicle: "VIN123") and nested evidence defining the conditions (validFrom, validUntil, maxSpeed). The recipient's device stores this VC in a digital wallet and presents it to the vehicle (Verifier) as a Verifiable Presentation. The vehicle can then cryptographically verify the issuer's signature and the credential's integrity without a live connection to the server. This combines the method of the '715 patent with an open standard for decentralized identity, making the e-key a portable, interoperable, and self-verifiable piece of data.