Derivative works

Defensive Disclosure: Methods and Systems for Dynamic, Context-Aware, and Secure Asset Access

Publication Date: May 13, 2026

Abstract:
This publication discloses a series of methods, systems, and architectural enhancements for the management of temporary and conditional access to assets, primarily vehicles, but applicable across various domains. The disclosed inventions extend the concept of a cloud-mediated electronic key (e-key) by integrating emerging technologies, applying the concept to non-automotive fields, and defining novel operational modes. The purpose of this disclosure is to place these concepts in the public domain, thereby establishing prior art against future patent applications on these and obvious variations thereof.

---

Claim Derivations: Broadening the Scope of E-Key Technology

1. Material & Component Substitution

1.1. E-Key Embodied in a Biometric-Authenticated Wearable Device

• Enabling Description: An e-key and its associated privileges are securely provisioned to a wearable device, such as a smart ring or bracelet equipped with a biometric sensor (e.g., fingerprint, vein pattern, or ECG signature). The server generates an encrypted access token and transmits it to the user's primary device (e.g., a smartphone), which then securely transfers it to the wearable's secure element via a short-range protocol like NFC or Bluetooth Low Energy (BLE). To use the vehicle, the user presents the wearable to a reader on the vehicle. The vehicle initiates a challenge-response protocol. The wearable requires a real-time biometric scan from the user to sign the challenge with the key stored in its secure element. This ensures that the key cannot be used if the wearable is lost or stolen. The vehicle validates the signed response to grant access.
• Mermaid Diagram:

  sequenceDiagram
      participant User
      participant Wearable
      participant Vehicle
      participant Server
  
      User->>Wearable: Puts on and Authenticates (e.g., initial PIN)
      Server->>Vehicle: Provisions vehicle with E-Key metadata (Key ID, policies)
      User->>Wearable: Touches vehicle reader
      Vehicle->>Wearable: Challenge Nonce
      Wearable->>User: Request Biometric Scan (e.g., Fingerprint)
      User->>Wearable: Provides Biometric Data
      Wearable->>Wearable: Verifies Biometric, Unlocks Secure Element
      Wearable->>Vehicle: Signs Nonce with Private Key -> Response
      Vehicle->>Vehicle: Verifies Response with E-Key Public Key
      alt Verification Successful
          Vehicle->>User: Unlock Doors & Grant Privileges
      else Verification Failed
          Vehicle->>User: Deny Access
      end
  

1.2. E-Key as a Non-Fungible Token (NFT) on a Distributed Ledger

• Enabling Description: A "Vehicle Access Token" (VAT) is minted as an NFT on a permissioned or public blockchain. The NFT's metadata, stored on-chain or via a decentralized storage link (e.g., IPFS), contains the conditions of use: VIN, valid time window, geo-fenced boundaries, speed limits, etc. The vehicle owner uses a crypto wallet to transfer the VAT to the recipient's wallet address. The vehicle is equipped with a blockchain node or light client. To gain access, the recipient's device (acting as a wallet) signs a transaction proving ownership of the VAT. The vehicle's client verifies this signature and checks the on-chain metadata for current validity and privileges. Usage events (e.g., trip start/end, violations) are recorded as subsequent transactions on the ledger, creating an immutable, auditable log.
• Mermaid Diagram:

  graph TD
      A[Owner's Wallet App] -- 1. Mints E-Key NFT with Use Conditions --> B(Blockchain);
      A -- 2. Transfers NFT --> C(Recipient's Wallet App);
      C -- 3. Presents NFT Ownership Proof --> D{Vehicle's Onboard Node};
      D -- 4. Verifies Ownership & Conditions on --> B;
      subgraph Vehicle System
          D -- 5. If Valid --> E[Unlock & Enforce Privileges];
          E -- 6. Logs Usage Data --> F[Create Usage Transaction];
      end
      F -- 7. Submits Usage Log to --> B;
  

1.3. E-Key Transfer via Acoustic Near-Field Communication

• Enabling Description: For environments where RF signals are jammed or insecure, the e-key is modulated into an inaudible, high-frequency acoustic signal. The user's device, using its microphone and speaker, establishes a secure, near-field acoustic channel with the vehicle's corresponding transducers. The server transmits the encrypted e-key to the user's app. The app encodes this key into a multi-tone acoustic data packet with error correction. The user holds their device near a designated point on the vehicle's body or window. The vehicle's microphones receive the acoustic signal, demodulate it, and decrypt the e-key. This method provides a highly directional and short-range transmission, preventing remote interception.
• Mermaid Diagram:

  sequenceDiagram
      participant Server
      participant Smartphone
      participant Vehicle
      Server->>Smartphone: Sends Encrypted E-Key
      Smartphone->>Smartphone: Encodes Key into Acoustic Signal
      activate Smartphone
      Smartphone-->>Vehicle: Transmits Inaudible Acoustic Data Packet
      deactivate Smartphone
      activate Vehicle
      Vehicle->>Vehicle: Receives & Decodes Acoustic Signal
      Vehicle->>Vehicle: Decrypts & Validates E-Key
      Vehicle-->>Smartphone: Acoustic Acknowledgment Signal
      deactivate Vehicle
  

2. Operational Parameter Expansion

2.1. Industrial Fleet Management with Dynamic Geofencing

• Enabling Description: A cloud system manages a fleet of heavy construction vehicles (e.g., bulldozers, haul trucks) on a large, evolving worksite. The site manager, via a web interface, draws and updates geofenced zones (e.g., "Active Blasting Zone," "Excavation Pit," "Fuel Depot") on a site map. E-keys are issued to operators' ruggedized tablets. The e-key's privileges are dynamically linked to these geofences. If a vehicle approaches a "Blasting Zone," its e-key automatically receives an updated "Engine Kill" command from the server, which is executed by the vehicle's control unit unless an override is received from the site manager. If the vehicle enters the "Fuel Depot," the e-key enables the vehicle's refueling pump interface. All movements and state changes are logged for safety and operational audits.
• Mermaid Diagram:

  graph TD
      subgraph Cloud Management System
          A[Site Manager UI] --> B{Geofence Database};
          B --> C{E-Key Logic Server};
          D[Vehicle GPS/Telemetry] --> C;
      end
      subgraph Vehicle
          E[Onboard Controller]
          F[Actuator Systems: Engine, Brakes]
      end
      C -- E-Key with Dynamic Privileges --> G(Operator's Tablet);
      G -- Local Comms --> E;
      E --> F;
      D -- Real-time Position --> C;
      C -- Updates Privileges based on Geofence --> G;
  

2.2. E-Key System for Sterile Laboratory Access and Equipment Enablement

• Enabling Description: In a biotechnology lab, access to sensitive equipment (e.g., gene sequencers, electron microscopes) and restricted cleanrooms is controlled by e-keys. A researcher's smart badge receives an e-key from the lab management server. The key is generated based on the researcher's project permissions and training certifications. When the researcher enters a cleanroom, an RFID gate authenticates the e-key and logs the entry. To operate a specific machine, the researcher taps their badge on the machine's reader. The machine's controller verifies the e-key contains the specific privilege for that machine model. The key then enables only the specific functions required for the scheduled experiment, and logs all usage data, reagent consumption, and operational parameters directly to the project's electronic lab notebook via the server.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Unauthenticated
      Unauthenticated --> Authenticated: Badge taps door reader
      Authenticated --> In_Cleanroom: E-Key valid for Zone A
      In_Cleanroom --> Equipment_Enabled: Badge taps equipment
      state Equipment_Enabled {
          [*] --> Idle
          Idle --> Running: E-Key allows 'Run_Sequencer'
          Running --> Logging: Usage data sent to server
          Logging --> Idle: Experiment complete
      }
      Equipment_Enabled --> In_Cleanroom: User moves away
      In_Cleanroom --> Unauthenticated: User exits Cleanroom
  

3. Cross-Domain Application

3.1. Aerospace: Time-Limited, Tool-Specific Maintenance E-Keys

• Enabling Description: An airline's maintenance, repair, and overhaul (MRO) system issues e-keys to a certified mechanic's tablet for a specific work order on an aircraft. The e-key contains the aircraft tail number, the specific task ID, and a list of authorized actions (e.g., "Actuate Flaps," "Run APU Diagnostic," "Access Avionics Bay 3"). When the mechanic connects their tablet to the aircraft's maintenance port, the e-key is authenticated. The aircraft's central maintenance computer then grants the tablet's software access only to the APIs corresponding to the authorized actions for the specified time window. For instance, the hydraulic system API will reject commands unless the e-key explicitly lists "Hydraulic System Bleed" as a privilege. This prevents accidental or unauthorized system changes and creates a secure, auditable maintenance record.
• Mermaid Diagram:

  erDiagram
      AIRCRAFT ||--o{ "MAINTENANCE_PORT" : ""
      MECHANIC_TABLET ||--|{ E_KEY : "holds"
      E_KEY {
          string keyID
          string tailNumber
          string workOrderID
          string[] authorizedAPIs
          datetime expiry
      }
      MAINTENANCE_PORT ||--|{ "CENTRAL_MAINTENANCE_COMPUTER" : ""
      CENTRAL_MAINTENANCE_COMPUTER }|--|{ "AIRCRAFT_SYSTEM_API" : "controls"
      MECHANIC_TABLET }o--|| MAINTENANCE_PORT : "connects to"
      CENTRAL_MAINTENANCE_COMPUTER {
          string currentTailNumber
      }
      AIRCRAFT_SYSTEM_API {
          string apiName
      }
      CENTRAL_MAINTENANCE_COMPUTER ||--|{ E_KEY : "validates"
  

3.2. AgTech: Consumable-Based E-Keys for Autonomous Farm Implements

• Enabling Description: A smart seeder implement is equipped with its own control module and wireless communication. A farm operator purchases a specific amount of a proprietary, high-yield seed. The seed vendor's server generates an e-key and sends it to the farmer's management app. This e-key represents the purchased quantity (e.g., "500kg of XYZ Seed"). The farmer assigns this key to a specific autonomous tractor. When the tractor attaches the seeder, the seeder's controller requests the e-key. The e-key authorizes the seeder to dispense up to 500kg of seed. The seeder's internal weight sensors and flow meters track the amount dispensed. Once the limit is reached, the e-key is invalidated, and the seeder's dispensing mechanism is disabled until a new key is provided. This enables pay-per-use or subscription models for agricultural consumables.
• Mermaid Diagram:

  flowchart TD
      subgraph Cloud_Platform
          A[Farmer purchases 500kg of seed] --> B(Generate E-Key <br> {type: 'seed', amount: 500kg});
          B --> C{Assign E-Key to Tractor-A};
      end
      subgraph In_The_Field
          D(Tractor-A) -- Attaches to --> E(Smart Seeder);
          E -- Requests Key --> D;
          D -- Provides E-Key --> E;
          E -- Verifies Key & Enables Dispenser --> F[Dispense Seed];
          F -- Dispense Events --> G{Decrement Amount};
          G -- Amount > 0 --> F;
          G -- Amount <= 0 --> H[Invalidate E-Key & Disable Dispenser];
      end
      E -- Real-time usage data --> Cloud_Platform;
  

3.3. Smart Home: Guest Access E-Keys with IoT Device Privileges

• Enabling Description: A homeowner uses a smart home app to generate an e-key for a guest. Instead of just door access, the e-key contains a JSON object defining granular permissions for specific IoT devices. For example, a "Weekend Guest" e-key might grant access to the front door lock, specific lights, the thermostat (but with a temperature range limit of 68-75°F), and the living room media center. It would explicitly deny access to the master bedroom, the home office computer, and the security system controls. When the guest's phone is on the home's Wi-Fi, their guest app uses the e-key to authenticate with the local smart home hub. The hub then acts as a policy enforcement point, granting or denying control requests to various IoT devices based on the privileges defined in the e-key.
• Mermaid Diagram:

  classDiagram
  class EKey {
      +keyId: string
      +validFrom: datetime
      +validTo: datetime
      +permissions: Permission[]
  }
  class Permission {
      +deviceId: string
      +allowedActions: string[]
      +constraints: map
  }
  class SmartHomeHub {
      +validateKey(EKey)
      +enforcePolicy(request)
  }
  class GuestDevice {
      +activeKey: EKey
      +sendControlRequest(deviceId, action)
  }
  class IoT_Device {
      +deviceId: string
  }
  HomeownerApp "1" -- "many" EKey : generates
  GuestDevice "1" -- "1" EKey : holds
  SmartHomeHub "1" -- "many" EKey : validates
  SmartHomeHub "1" -- "many" IoT_Device : controls
  GuestDevice ..> SmartHomeHub : sends control requests
  

4. Integration with Emerging Tech

4.1. AI-Powered Predictive E-Key Generation

• Enabling Description: A corporate vehicle fleet management system integrates with the employees' work calendars and historical travel data. An AI/ML model analyzes upcoming appointments, typical travel times, and real-time traffic data. The evening before a scheduled client visit, the system predicts the required travel duration and optimal departure time. It then automatically generates and issues an e-key to the assigned employee's smartphone. The e-key's validity period is dynamically calculated to be the predicted trip time plus a 30% buffer. The privileges might also be adjusted; for example, if the destination is a high-crime area (based on external data feeds), the e-key might require the vehicle's "sentry mode" to be active and disallow stopping for more than 5 minutes in non-designated parking areas.
• Mermaid Diagram:

  graph TD
      subgraph Prediction & Issuance Engine (Server)
          A[Calendar API] --> C{AI Prediction Model};
          B[Historical Trip Data] --> C;
          C -- Predicted Trip Details --> D[E-Key Generator];
          E[Real-time Traffic/Risk Data] --> D;
          D -- Generates Dynamic E-Key --> F[Send to User's Device];
      end
      subgraph User & Vehicle
          G[Employee's Smartphone] -- Receives E-Key --> H(Vehicle);
          H -- Usage Telemetry --> I[Feedback Loop];
      end
      I --> B;
  

4.2. E-Key with Integrated Blockchain-Verified Service History

• Enabling Description: The e-key system is integrated with a blockchain-based vehicle service ledger. Before an e-key is issued to a renter, the server queries the vehicle's service history on the blockchain to verify that all required maintenance (e.g., oil change, tire rotation, recall services) is up-to-date. If a critical service is overdue, the system refuses to issue a standard driving e-key. Instead, it can issue a restricted "Service-Only E-Key" valid only for a trip to an authorized service center. This ensures rental and shared vehicles are verifiably safe and properly maintained before each use, with the verification process being transparent and tamper-proof.
• Mermaid Diagram:

  sequenceDiagram
      participant Renter
      participant RentalServer
      participant Vehicle
      participant ServiceLedger_Blockchain
  
      Renter->>RentalServer: Request E-Key for Vehicle_123
      RentalServer->>ServiceLedger_Blockchain: Query Service Record for VIN_123
      ServiceLedger_Blockchain-->>RentalServer: Return Latest Service Status
      alt Service OK
          RentalServer->>Vehicle: Authorize E-Key
          RentalServer->>Renter: Issue E-Key
      else Service Overdue
          RentalServer->>Renter: Deny Request, Notify of Service Need
          RentalServer->>Vehicle: Issue Restricted "Service-Only" Key
      end
  

5. The "Inverse" or Failure Mode

5.1. Graceful Degradation E-Key for Disconnected States

• Enabling Description: A vehicle is designed to operate in areas with intermittent or no network connectivity. Before entering a known dead zone (e.g., a national park, underground garage), the user's app, when connected, pre-fetches a "Degraded Mode E-Key" from the server. This key has a longer, pre-defined validity period (e.g., 24 hours) but with reduced privileges. When the vehicle detects a loss of server connectivity for more than a specified duration (e.g., 10 minutes), it automatically switches to a mode where it will only accept this pre-fetched, offline key. Privileges in this mode might be limited to basic driving functions, with features like in-car purchases or streaming media disabled. The vehicle logs all actions taken during the offline period. When connectivity is restored, the vehicle synchronizes its log with the server, and the degraded mode e-key is invalidated.
• Mermaid Diagram:

  stateDiagram-v2
      state "Online" as Online
      state "Offline" as Offline
  
      [*] --> Online: Connected to Server
      Online --> Offline: Heartbeat to Server Fails (timeout)
      Offline --> Online: Server Connection Restored
  
      Online: Uses standard real-time E-Keys
      Online: Pre-fetches 'Degraded Mode E-Key'
  
      Offline: Rejects standard E-Keys
      Offline: Accepts 'Degraded Mode E-Key' only
      Offline: Logs all vehicle activity locally
      Offline: Disables non-essential connected features
  

5.2. Biometric Deadman's Switch E-Key Revocation

• Enabling Description: For high-security vehicle transport, the driver uses a wearable (e.g., smartwatch) that continuously monitors their vital signs (heart rate, blood oxygen). This wearable is paired with the vehicle's e-key system. The primary e-key is augmented with a "biometric keep-alive" privilege. If the wearable detects a reading outside of normal parameters (e.g., heart rate drops to zero, or the watch is removed from the wrist), it sends an immediate alert via a dedicated, redundant communication channel (e.g., satellite link). If the alert is not canceled by the driver within 60 seconds, the central server automatically revokes the e-key and sends a command to the vehicle to enter a "safe shutdown" mode. This mode involves gradually slowing the vehicle to a stop, activating hazard lights, and locking all cargo doors.
• Mermaid Diagram:

  flowchart LR
      subgraph Driver
          A[Smartwatch] -- Monitors Vitals --> B{Biometric Status};
      end
      subgraph Vehicle
          C[E-Key Module]
      end
      subgraph Server
          D[Monitoring & Revocation Service]
      end
  
      B -- "Normal" --> C;
      C -- "Valid Key" --> Vehicle_Systems[Operate Normally];
      B -- "Anomaly Detected" --> A;
      A -- Sends Alert --> D;
      D -- Starts 60s Timer --> D;
      D -- "If no cancel signal" --> C{Revoke E-Key};
      D -- "If no cancel signal" --> Vehicle_Systems;
      C --> Vehicle_Systems[Initiate Safe Shutdown];
  

---

Combination Prior Art Scenarios

1. E-Key Management via Matter and Thread Protocols

• Description: The vehicle's local communication system is built upon the Matter application layer protocol, running over a Thread mesh network. The user's smartphone, acting as a Matter controller, securely commissions the vehicle onto the local Thread network. The e-key, received from the cloud, is encapsulated as a set of Matter-defined access control list (ACL) entries. When the user's phone is near the car, it uses the low-power, resilient Thread mesh to transmit the e-key's ACLs to the vehicle's onboard Matter device. The vehicle's door locks, ignition, and infotainment systems are all represented as Matter endpoints. The e-key's privileges directly map to the permissions granted in the Matter ACLs (e.g., Allow User_X to invoke 'unlock' on Endpoint_DoorLock_DriverSide). This leverages an open, standardized, and secure local communication framework, making the system interoperable with a wide range of smart devices.

2. Authentication via OpenID Connect (OIDC) and FIDO2/WebAuthn

• Description: The cloud service for generating e-keys acts as an OpenID Connect (OIDC) Identity Provider. A user (e.g., a vehicle owner) authenticates to the e-key management web application using a phishing-resistant FIDO2/WebAuthn authenticator (like a YubiKey or a platform authenticator like Windows Hello or Face ID). Upon successful authentication, the user is authorized to generate an e-key for a recipient. The e-key itself is delivered as a JSON Web Token (JWT) with custom claims defining the vehicle privileges. The recipient's smartphone app stores this JWT. To use the vehicle, the app presents the JWT to the vehicle's telematics unit. The vehicle, acting as an OIDC Relying Party, validates the JWT's signature using the public key of the OIDC provider (the server). This combines a robust, open standard for web-based authentication with a standardized token format for asserting permissions.

3. Vehicle Telemetry Reporting using MQTT

• Description: The vehicle's communication with the cloud server for reporting "use data" (as described in Claim 1) is implemented using the MQTT (Message Queuing Telemetry Transport) protocol, a standard for IoT communication. The vehicle acts as an MQTT client and publishes its data (GPS location, speed, CAN bus data, etc.) to specific topics on a central MQTT broker hosted in the cloud (e.g., vehicles/VIN123/location, vehicles/VIN123/speed). The e-key management server subscribes to these topics. When a "condition of use" is violated (e.g., speed exceeds the limit defined in the e-key), the vehicle publishes a message to a specific alert topic (e.g., vehicles/VIN123/alerts). The server, subscribed to this topic, immediately receives the alert and can trigger the warning notification to the user. This use of MQTT provides an efficient, lightweight, and reliable publish/subscribe mechanism for real-time data streaming from the vehicle to the cloud infrastructure.