Derivative works — US Patent 9290153

Defensive Disclosure: Vehicle-Based Multimode Discovery and Connectivity

Publication Date: May 1, 2026

Abstract: This document discloses a series of methods, systems, and applications that build upon the concept of multi-stage wireless protocol switching for device-to-vehicle connectivity, as outlined in U.S. Patent 9,290,153. The purpose of this disclosure is to place in the public domain a variety of alternative embodiments, enhancements, and applications of this core technology to preclude patenting of these incremental improvements by others. The disclosed variations explore alternative components, expanded operational parameters, cross-domain applications, integration with emerging technologies, and specialized functional modes.

1. Material & Component Substitution

1.1. Ultra-Wideband (UWB) and Wi-Fi 6E Tri-Band Handover

Enabling Description: This embodiment replaces the initial Bluetooth Low Energy (BLE) link with an Ultra-Wideband (UWB) transceiver (compliant with IEEE 802.15.4z) for high-precision distance measurement. The vehicle's UWB anchors triangulate the position of the user's computational device with centimeter-level accuracy. The "predetermined physical proximity" is not a mere signal strength threshold but a precisely defined three-dimensional geofence around the vehicle (e.g., a 2-meter radius sphere). Upon the device entering this geofence, the vehicle's control unit initiates a high-throughput connection using Wi-Fi 6E (802.11ax) in the 6 GHz band, which is less congested than the 2.4 GHz and 5 GHz bands, allowing for more reliable, lower-latency data transfer for applications like in-car augmented reality displays or multi-channel high-resolution audio streaming.

Diagram:

sequenceDiagram
    participant UserDevice as User Device (UWB + Wi-Fi 6E)
    participant Vehicle as Vehicle (UWB Anchors + Wi-Fi 6E AP)

    loop UWB Ranging
        UserDevice->>Vehicle: UWB Pulse (Time of Flight)
        Vehicle-->>UserDevice: UWB Response
    end
    Vehicle->>Vehicle: Calculate precise distance
    alt Device enters < 2m geofence
        Vehicle->>UserDevice: Initiate Wi-Fi 6E Handshake (via UWB channel or pre-shared key)
        UserDevice->>Vehicle: Associate with 6 GHz BSSID
        Vehicle-->>UserDevice: Authentication Complete
        Note right of Vehicle: High-throughput link active
    end

1.2. Acoustic Ranging and Inductive Power/Data Link

Enabling Description: The initial discovery and proximity detection mechanism utilizes ultrasonic transducers embedded in the vehicle's side mirrors and door handles. The vehicle emits a coded ultrasonic chirp. The user's computational device, equipped with a microphone and a filter tuned to the chirp frequency, measures the time-of-flight of the acoustic signal to determine proximity. When the device is within a 1-meter range, it activates its NFC or Qi-compatible inductive coil. The vehicle's corresponding inductive charging pad (e.g., in the center console or door panel) establishes a high-bandwidth Near-Field Magnetic Induction (NFMI) communication link, which simultaneously provides wireless charging and a secure, high-speed data connection for syncing files or media, immune to common RF interference.

Diagram:

graph TD
    A[Vehicle emits ultrasonic chirp] --> B{Device microphone detects chirp?};
    B -- No --> A;
    B -- Yes --> C[Device calculates Time-of-Flight];
    C --> D{Distance < 1 meter?};
    D -- No --> A;
    D -- Yes --> E[Activate Inductive Coil];
    E --> F[Vehicle's charging pad detects device];
    F --> G[Establish NFMI Communication Link];
    G --> H[Initiate Data Sync & Wireless Charging];

2. Operational Parameter Expansion

2.1. Cryogenic and High-Temperature Operation for Industrial/Exploration Vehicles

Enabling Description: This system is designed for vehicles operating in extreme environments, such as polar exploration rovers (-80°C) or foundry transport vehicles (+150°C). The initial low-power link uses a hardened, temperature-resilient Zigbee (IEEE 802.15.4) mesh network transceiver operating in the 900 MHz band for better material penetration. The proximity check uses a differential time-domain reflectometry (TDR) algorithm to account for thermal expansion/contraction of vehicle components. Upon operator proximity confirmation, a secondary link is established via a Free-Space Optics (FSO) laser communication system. The FSO transceivers are housed in hermetically sealed, nitrogen-purged enclosures with active heating/cooling (Peltier elements) to maintain operational temperature, ensuring a multi-gigabit, interference-proof data link for downloading high-resolution sensor data or uploading complex operational parameters.

Diagram:

stateDiagram-v2
    [*] --> Idle
    Idle --> Listening: Operator Enters Zone
    Listening --> ProximityCheck: Zigbee Signal Detected
    ProximityCheck --> Listening: Signal Strength Too Low
    ProximityCheck --> FSO_Handshake: Signal Strength > Threshold
    FSO_Handshake --> DataLink_Active: Laser Lock Acquired
    DataLink_Active --> Idle: Transfer Complete or Operator Leaves
    FSO_Handshake --> ProximityCheck: Handshake Failed
    state FSO_Handshake {
        [*] --> Aligning_Optics
        Aligning_Optics --> Authenticating
        Authenticating --> [*]
    }

2.2. Swarm Robotics Micro-Scale Implementation

Enabling Description: A swarm of millimeter-scale robots operates within a defined workspace. Each robot communicates via a low-power, low-data-rate backscatter communication protocol for basic positioning and status updates, reflecting signals from a central RF source. When a robot needs to offload a large sensor reading or receive a new complex instruction set, it physically navigates to a "data port." Proximity is determined when the robot's unique metallic signature is detected by a micro-eddy current sensor at the port. This triggers the activation of a direct, pin-based electrical contact or a microscopic optical link (e.g., via an integrated VCSEL laser and photodiode pair), establishing a high-speed serial communication link for the duration of the data transfer.

Diagram:

flowchart LR
    subgraph Swarm Operation
        A[Robot Navigates] -- Backscatter Comm --> B(Central Controller)
        B -- Basic Commands --> A
    end

    subgraph Data Offload
        C(Data Port) -->|Emits Eddy Field| D{Micro-Robot Nearby?}
        A -- Moves To --> C
        D -- Yes --> E[Activate Optical Link]
        E -- High-Bandwidth --> F[Data Transfer]
        F --> G[Robot Undocks]
    end

    A --> D

3. Cross-Domain Application

3.1. Aerospace: Smart Space Suit and Habitat Integration

Enabling Description: An astronaut's Extravehicular Mobility Unit (EMU) or space suit maintains a constant low-power, encrypted radio link to the spacecraft or habitat's main communication system for vital signs telemetry. When the astronaut approaches a specific external workstation or airlock (detected by Li-Fi receivers on the suit reading a unique modulated LED pattern from the workstation), a high-bandwidth, line-of-sight Ka-band RF link is automatically established. This secondary link allows for the transmission of high-definition video from the suit's helmet camera, the transfer of large scientific data files from portable instruments, and the downloading of complex task procedures to the astronaut's heads-up display (HUD). Proximity is confirmed by the Li-Fi signal exceeding a specific luminosity and data integrity threshold.

Diagram:

sequenceDiagram
    participant Astronaut as Astronaut EMU
    participant Spacecraft as Spacecraft/Habitat

    Astronaut->>+Spacecraft: Continuous Telemetry (Low-Power Radio)
    loop Proximity Scan
        Spacecraft->>Spacecraft: Emit coded Li-Fi signal from Workstation
        Astronaut->>Astronaut: Scan for Li-Fi signal
    end
    Note over Astronaut,Spacecraft: Astronaut approaches Workstation
    Astronaut->>Spacecraft: Li-Fi Signal Detected (Proximity Confirmed)
    Spacecraft->>Astronaut: Initiate Ka-Band Link
    Astronaut-->>Spacecraft: Authenticate and Connect
    par HD Video Stream
        Astronaut->>Spacecraft: Helmet Cam Feed
    and Data Transfer
        Astronaut->>Spacecraft: Scientific Data Upload
    end

3.2. Medical: Intelligent Hospital Bed and Patient Monitoring

Enabling Description: A patient wears a biosensor wristband that communicates vital signs (ECG, SpO2, temp) to a central nursing station via a hospital-wide Medical Body Area Network (MBAN) or BLE mesh. When a specific piece of diagnostic equipment (e.g., a portable ultrasound machine or a smart IV pump) is brought within a pre-set range of the patient's bed (e.g., 1 meter, determined by the signal strength of the wristband's BLE beacon), the diagnostic machine establishes a direct, high-bandwidth Wi-Fi Direct connection. This allows the machine to pull the patient's full electronic health record (EHR) from the hospital network, stream high-resolution diagnostic images in real-time to a doctor's tablet, and log all procedure data directly back to the patient's EHR, ensuring the right data is associated with the right patient at the point of care.

Diagram:

graph TD
    subgraph "Continuous Monitoring"
        A[Patient Biosensor] -- BLE Mesh --> B[Nursing Station]
    end
    subgraph "Bedside Procedure"
        C[Ultrasound Cart] --> D{Detects Patient BLE Beacon};
        D -- Strong Signal --> E[Establish Wi-Fi Direct Link with Bedside Hub];
        E --> F[Pull EHR Data];
        E --> G[Stream Ultrasound Video];
        G --> H[Log Procedure to EHR];
    end
    A --> D

3.3. Retail: Smart Shopping Cart and Personalized Offers

Enabling Description: A smart shopping cart is equipped with a BLE beacon for in-store location tracking. As a customer pushes the cart, their loyalty app on their smartphone maintains a low-power connection to the cart. When the cart's location system (e.g., UWB or computer vision) determines it is dwelling in front of a specific high-value "endcap" display for more than a set time (e.g., 10 seconds), the display's integrated Wi-Fi access point establishes a direct connection with the customer's phone. This high-bandwidth link pushes a rich media advertisement, an interactive product demo, or a limited-time digital coupon for the products on that specific display directly to the customer's app, bypassing the congested general store Wi-Fi.

Diagram:

sequenceDiagram
    participant Phone as Customer's Phone
    participant Cart as Smart Cart (BLE)
    participant Display as Endcap Display (Wi-Fi)

    Phone->>Cart: Initial BLE Pairing (Loyalty App)
    loop Shopping
        Cart-->>Phone: Location & Status Updates
    end
    Note over Cart,Display: Cart dwells at Endcap
    Display->>Phone: Detect strong BLE signal from Cart
    Display->>Phone: Initiate Wi-Fi Direct Handshake
    Phone-->>Display: Connect to Display's Wi-Fi
    Display->>Phone: Push Rich Media Ad/Coupon

4. Integration with Emerging Technologies

4.1. AI-Based Predictive Resource Allocation

Enabling Description: The vehicle's onboard AI learns the driver's daily routines (commute times, common destinations) by analyzing historical GPS, calendar, and vehicle usage data. The system predicts the driver's approach to the vehicle. 1-2 minutes before the predicted arrival, it wakes the vehicle's Body Control Module (BCM) and the primary low-power radio (e.g., BLE). The AI also analyzes real-time environmental data (e.g., cellular network congestion, ambient RF noise from a network analyzer). Based on this analysis, it pre-selects the optimal channel and band for the secondary high-bandwidth (Wi-Fi) connection before the user is even in range. This minimizes handshake time and avoids interference, creating a near-instantaneous connection upon arrival.

Diagram:

flowchart TD
    A[Data Sources: GPS, Calendar, Time] --> B(Predictive AI Model);
    B --> C{Predicts User Arrival?};
    C -- Yes --> D[Wake BCM & BLE Radio];
    D --> E[Scan RF Environment];
    E --> F[AI Selects Optimal Wi-Fi Channel];
    F --> G[Wait for BLE Proximity Trigger];
    G --> H[Establish Wi-Fi Link on Pre-Selected Channel];
    C -- No --> B;

4.2. IoT-Enhanced Geofencing and Authentication

Enabling Description: The system integrates with a user's home or office IoT network. The initial trigger is not the detection of the user's device, but a message received from the user's smart home hub (e.g., via MQTT protocol over the vehicle's LTE connection) that the user's smartphone has disconnected from the home Wi-Fi. The vehicle then enters a "standby" mode. A secondary trigger comes from a smart garage door opener, confirming the door is open. Only after receiving these two IoT signals does the vehicle activate its BLE scanner to establish the first link. The final transition to the high-bandwidth Wi-Fi is triggered by a combination of BLE signal strength and the in-cabin weight sensor detecting the driver's weight in the seat, providing a multi-factor "proof of presence" before enabling access to sensitive data or vehicle controls.

Diagram:

graph LR
    A[Smart Home Hub] -- "User Left" --> C(Vehicle ECU);
    B[Garage Door] -- "Is Open" --> C;
    C -- Receives Both Signals --> D[Activate BLE Scanner];
    D -- Device Detected --> E[Establish BLE Link];
    F[Seat Weight Sensor] -- "Occupied" --> G[Confirm Presence];
    E -- Proximity Confirmed --> G;
    G -- All Conditions Met --> H[Establish Wi-Fi Link];

5. The "Inverse" or Failure Mode

5.1. Graceful Degradation Mode

Enabling Description: The vehicle's connectivity manager constantly monitors the link quality (packet loss, latency, jitter) of the secondary high-bandwidth connection (e.g., Wi-Fi). If the quality drops below a predefined Quality of Service (QoS) threshold for a sustained period (e.g., >50% packet loss for 3 seconds), the system does not disconnect entirely. Instead, it "gracefully degrades." It signals the user's device to fall back to the primary low-power link (e.g., Bluetooth) and simultaneously instructs the vehicle's infotainment system to switch to a "low-bandwidth UI." This UI disables data-intensive widgets (e.g., satellite maps, video streaming) and presents a simplified interface with only functions that can operate reliably over Bluetooth, such as basic call controls and standard-quality audio streaming. The system continues to probe for a stable Wi-Fi connection in the background and will automatically re-establish the full-featured mode when possible.

Diagram:

stateDiagram-v2
    state "High-Bandwidth Mode (Wi-Fi)" as High
    state "Low-Bandwidth Mode (BT)" as Low
    [*] --> Low: Initial Connection
    Low --> High: Proximity Confirmed & Wi-Fi Stable
    High --> Low: Wi-Fi QoS Degrades
    Low --> High: Wi-Fi QoS Restored
    High --> [*]: User Disconnects
    Low --> [*]: User Disconnects

5.2. Anti-Relay Attack "Faraday" Mode

Enabling Description: To counter sophisticated relay attacks where the signal from a keyfob or phone is amplified to trick the vehicle into unlocking, this embodiment uses the dual-protocol system for security. The initial BLE link is established as normal. However, to authorize a high-security action like starting the engine, the system requires the establishment of the secondary link. This secondary link is an extremely low-power, short-range (sub-10cm) protocol, such as NFC or Magnetic Secure Transmission (MST). The user must physically tap their device to a designated spot on the dashboard or center console. The vehicle's processor will only enable the ignition/drivetrain if both the BLE link is active (confirming the authorized device is generally nearby) and the NFC/MST link is successfully established (confirming the device is physically inside the vehicle and not part of a relay attack).

Diagram:

sequenceDiagram
    participant UserDevice as User Device (BLE + NFC)
    participant Vehicle as Vehicle (BLE + NFC)
    UserDevice->>Vehicle: BLE Advertisement
    Vehicle-->>UserDevice: BLE Connection Established
    UserDevice-->>Vehicle: Request Engine Start
    Vehicle-->>UserDevice: Prompt for NFC Tap
    UserDevice->>Vehicle: Physical Tap (NFC Handshake)
    alt NFC Success
        Vehicle->>Vehicle: Authorize Ignition
    else NFC Fail/Timeout
        Vehicle->>Vehicle: Deny Ignition
    end

6. Combination Prior Art Scenarios

6.1. Combination with AUTOSAR (Automotive Open System Architecture)

Description: The disclosed multimode discovery process is implemented as a set of standardized software components (SW-Cs) within an AUTOSAR-compliant architecture. A "Wireless Interface Manager" (WIM) SW-C runs on the vehicle's central computing platform. It communicates with lower-level Basic Software (BSW) modules, including a Bluetooth Stack and a TCP/IP stack for Wi-Fi. The proximity detection logic (signal strength analysis) is encapsulated within the WIM. Upon reaching the proximity threshold, the WIM sends a trigger signal via the AUTOSAR Runtime Environment (RTE) to the "Communication Manager" (ComM) BSW module, instructing it to activate the Wi-Fi network interface and establish the secondary connection. This modular, standards-based approach allows the feature to be integrated into any AUTOSAR-compliant vehicle ECU from any manufacturer, treating the dual-mode switching as a standardized service.

Diagram:

graph TD
    subgraph Application Layer
        A[Infotainment App SW-C]
    end
    subgraph AUTOSAR RTE
        RTE
    end
    subgraph BSW - Services Layer
        B[Wireless Interface Manager SW-C]
        C[Communication Manager (ComM)]
    end
    subgraph BSW - ECU Abstraction Layer
        D[Bluetooth Driver]
        E[Wi-Fi Driver]
    end
    subgraph Hardware
        F[Bluetooth Radio]
        G[Wi-Fi Radio]
    end
    A -- Request Data --> RTE
    RTE -- Trigger --> B
    B -- Monitor Signal --> RTE
    RTE -- Read Signal Strength --> D
    D -- RF Data --> F
    B -- "Proximity OK" --> RTE
    RTE -- "Activate WiFi" --> C
    C -- "Start Interface" --> RTE
    RTE -- "Enable Driver" --> E
    E -- Control --> G

6.2. Combination with W3C WebAuthn Standard

Description: The establishment of the second, high-bandwidth connection is secured using the FIDO/WebAuthn standard for phishing-resistant authentication. After proximity is determined via the first link (e.g., Bluetooth RSSI), the vehicle's infotainment system (acting as a "relying party") initiates a WebAuthn authentication ceremony over the nascent Wi-Fi link. The user's smartphone (acting as a "FIDO authenticator") prompts the user for a biometric verification (e.g., fingerprint or face scan). Upon successful biometric authentication on the phone, the phone signs a cryptographic challenge sent by the vehicle and returns it. This securely authenticates the user to the vehicle's systems, enabling access to personalized profiles, saved credentials for in-car payments, and other sensitive data, all without the user needing to enter a password.

Diagram:

sequenceDiagram
    participant Phone as User Phone (Authenticator)
    participant Vehicle as Vehicle (Relying Party)
    Note over Phone, Vehicle: Proximity established via BLE; Wi-Fi link starting
    Vehicle->>Phone: Initiate WebAuthn Assertion Request
    Phone->>Phone: Prompt user for Biometric (Fingerprint/FaceID)
    alt User Authenticates
        Phone->>Phone: Use Private Key to Sign Challenge
        Phone->>Vehicle: Return Signed Assertion
        Vehicle->>Vehicle: Verify Signature with Stored Public Key
        Vehicle->>Phone: Grant Access to Secure Services
    else User Fails/Cancels
        Phone->>Vehicle: Authentication Failed
        Vehicle->>Vehicle: Deny Access
    end

6.3. Combination with MQTT for Fleet Management

Description: For a fleet of commercial vehicles (e.g., delivery vans), the state of the vehicle's multi-modal connectivity is reported to a central fleet management server using the lightweight MQTT (Message Queuing Telemetry Transport) protocol. The vehicle's telematic control unit (TCU) acts as an MQTT client. It publishes messages to specific topics on a central broker, such as fleet/vehicle_123/status/ble with a payload of {"device_id": "phone_xyz", "rssi": -55} or fleet/vehicle_123/status/wifi with a payload of {"status": "connected", "ip": "192.168.1.10"}. A central server subscribed to these topics can monitor driver presence, verify that data offloads (e.g., delivery manifests, camera footage) are occurring correctly over the high-bandwidth link, and remotely troubleshoot connectivity issues by observing the state transitions without needing a heavy polling-based system.

Diagram:

flowchart LR
    subgraph Vehicle
        A[BLE Radio] -- RSSI --> B(TCU/MQTT Client)
        C[Wi-Fi Radio] -- Status --> B
    end
    subgraph Internet
        D[MQTT Broker]
    end
    subgraph Cloud Server
        E[Fleet Management App]
    end

    B -- Publish "fleet/vehicle_123/status/ble" --> D
    B -- Publish "fleet/vehicle_123/status/wifi" --> D
    E -- Subscribe to "fleet/vehicle_123/#" --> D
    D -- Pushes Messages --> E