Derivative works — US Patent 9766801

Defensive Disclosure: In-Car Information and Control Systems

Publication Date: April 30, 2026
Reference Technology: U.S. Patent No. 9,766,801

This document describes a series of inventions and improvements related to the integration of portable information terminals with in-vehicle systems. The purpose of this disclosure is to place these concepts in the public domain, thereby establishing prior art against future patent applications that might claim these or similar ideas.

Derivative 1: Haptic Feedback Surface as a Dynamic Control Interface

Enabling Description: The in-car device's physical actuation unit is replaced with a solid-state, pressure-sensitive surface incorporating a haptic feedback engine (e.g., using piezoelectric actuators or linear resonant actuators). Instead of transmitting a fixed list of buttons and knobs, the in-car device transmits "actuation information" defining programmable haptic zones. This information includes the coordinates, shape (e.g., circle, rectangle), and supported gesture types (e.g., tap, long-press, swipe, rotary gesture, pressure-sensitivity) for each zone. A portable terminal, upon connection, receives this haptic zone map. The terminal's assignment unit, using its pre-defined operation assignment information, maps its functions to specific gestures within these zones. For instance, a "volume control" function might be assigned to a circular gesture within a designated haptic zone, and the terminal would instruct the in-car device to render a corresponding virtual dial on its display and provide detent-like haptic feedback as the user's finger rotates within that zone. The actuation signal sent from the car to the phone would consist of a data stream containing the zone ID, gesture type, and associated vector/pressure data, which the terminal's conversion unit interprets into the appropriate application command.

Mermaid Diagram:

sequenceDiagram
    participant InCar as In-Car Haptic Surface
    participant PTerminal as Portable Terminal
    InCar->>PTerminal: Transmit ActuationInfo: {zones:[{id:'Z1', shape:'rect', gestures:['tap', 'swipe']}, {id:'Z2', shape:'circle', gestures:['rotate', 'press']}]}
    PTerminal->>PTerminal: Assignment: Map('Next Track', {zone:'Z1', gesture:'swipe_right'}), Map('Volume', {zone:'Z2', gesture:'rotate'})
    PTerminal->>InCar: Send ActuationCorrespondenceInfo: {UI_Overlay_Map, Haptic_Feedback_Profile_for_Z2}
    InCar->>InCar: Renders UI overlay and configures haptic engine for 'detent' feel in Zone 2
    User-->>InCar: Performs rotary gesture in Zone 2
    InCar->>PTerminal: Send ActuationSignal: {zone:'Z2', gesture:'rotate', delta_angle: +5.0}
    PTerminal->>PTerminal: Convert gesture to 'VolumeUp(1)' command
    PTerminal->>PTerminal: Execute command on media application

Derivative 2: In-Cabin Gesture Recognition Control System

Enabling Description: The physical actuation unit is replaced or augmented by an optical sensor array (e.g., infrared, Time-of-Flight) that monitors a defined interaction space within the vehicle cabin. The in-car device's "actuation information" is a list of supported, high-level gestures it can reliably recognize (e.g., "swipe-horizontal", "swipe-vertical", "circle-cw", "circle-ccw", "thumb-up", "open-palm"). The portable terminal's application, containing its operation assignment information, receives this gesture dictionary and assigns functions based on a "recommended gesture" classification and priority. For example, a music application could assign "swipe-horizontal" to track changes, "circle-cw/ccw" to volume, and "thumb-up" to 'like' a song. The in-car device's role is to process the camera feed, identify a defined gesture, and transmit the corresponding gesture ID as the "actuation signal" to the terminal. The terminal's conversion unit then looks up this ID in its current assignment map and executes the associated command.

Mermaid Diagram:

graph TD
    subgraph Vehicle
        A[User makes 'swipe-right' hand gesture] --> B(ToF Camera);
        B --> C[Gesture Recognition Engine];
        C --> D[Generate Actuation Signal: "swipe-horizontal, direction: right"];
    end
    subgraph Portable Terminal
        E(Communication Interface) --> F{Assignment & Conversion Logic};
        G[Operation Assignment Table<br>swipe-horizontal -> nextTrack()<br>circle-cw -> volumeUp()] --> F;
        F --> H[Execute Application Command: nextTrack()];
    end
    D -- Bluetooth/USB --> E;

Derivative 3: Micro-Electro-Mechanical System (MEMS) Control Array

Enabling Description: This invention is applied at a microscopic scale for laboratory or industrial process control. The "in-car device" is a MEMS-based microfluidic chip controller, and the "portable terminal" is a control computer or specialized tablet. The MEMS controller sends "actuation information" detailing its available micro-actuators, such as specific micropumps (e.g., pump_A, pump_B), microvalves (valve_1, valve_2), and heating elements (heater_z1). The control computer, running an experiment protocol application, has a library of high-level operations ("Inject Reagent," "Incubate," "Flush Channel") with associated priorities and sequences. The "assignment unit" on the computer maps these high-level operations to the available micro-actuators. A user command to "Inject Reagent" on the computer interface is the "actuation signal." The computer's "conversion unit" then translates this into a timed sequence of low-level "operating commands" (e.g., OPEN valve_1; ACTUATE pump_A for 500ms; CLOSE valve_1) which are sent to the MEMS controller for execution.

Mermaid Diagram:

sequenceDiagram
    participant ControlPC as "Control Computer (Terminal)"
    participant MEMS_Ctrl as "MEMS Controller (Device)"
    MEMS_Ctrl->>ControlPC: ActuationInfo: {actuators: ['pump_A', 'valve_1', 'heater_z1']}
    ControlPC->>ControlPC: Assigns 'Incubate' op to heater_z1
    User-->>ControlPC: Clicks "Incubate for 60s at 45C"
    ControlPC->>ControlPC: Convert UI action to operating command
    ControlPC->>MEMS_Ctrl: Command: {target: 'heater_z1', setpoint: 45, duration: 60000}
    MEMS_Ctrl-->>ControlPC: Acknowledged

Derivative 4: Integration with Smart Factory/Industrial IoT (IIoT) Environment

Enabling Description: This concept is applied to an industrial automation setting. The "in-car device" is a programmable logic controller (PLC) or a Human-Machine Interface (HMI) panel on a factory floor. The "portable terminal" is an industrial tablet or ruggedized smartphone used by a technician. The PLC broadcasts its available control points and their states ("actuation information") over a protocol like OPC-UA. This information includes actuators like 'Conveyor_Motor_Speed', 'Robot_Arm_Gripper_State', and 'Valve_Position_3'. A diagnostic or control application on the technician's tablet contains a set of "operations" (e.g., 'Jog Conveyor', 'Cycle Gripper', 'Purge Line 3') with priorities. Based on the connected PLC's advertised capabilities, the tablet's "assignment unit" dynamically populates its user interface, assigning these operations to on-screen buttons or linking them to the physical controls of the HMI panel. When the technician presses a button on the tablet, it sends the corresponding "actuation signal" to its "conversion unit," which then formulates and transmits the correct OPC-UA write command back to the PLC to execute the physical action.

Mermaid Diagram:

graph LR
    subgraph Technician Tablet
        A[App UI]
        B[Assignment Unit]
        C[Conversion Unit]
        D[OPC-UA Client]
    end
    subgraph Factory Floor
        E[PLC / HMI Panel]
        F[OPC-UA Server]
        G[Physical Machine]
    end
    F -- Publishes Actuation Info --> D
    D --> B
    A -- User Input --> C
    C --> D
    D -- Writes 'Operating Command' --> F
    E <--> F
    E -- Controls --> G

Derivative 5: AI-Powered Contextual and Predictive Control Assignment

Enabling Description: The "assignment unit" on the portable terminal is augmented with a machine learning model. This model is trained on historical usage data, vehicle telematics (GPS, speed, time), user calendar data, and real-time environmental data (e.g., weather, traffic). The in-car device sends its standard "actuation information" (available controls). The AI assignment unit, however, does not use a static priority list. Instead, it predicts the user's most probable desired actions in the current context. For example, when leaving the office in the evening, it might assign the highest priority to "Navigate Home" and "Call Spouse," mapping them to the most prominent physical buttons. If traffic is heavy, it might prioritize "Play 'Podcasts'" over "Play 'High-Energy Music'". This dynamic "operation assignment information" is then used to create the control map, which is sent to the in-car device as "actuation correspondence information." The system learns and adapts over time to individual user behavior.
Mermaid Diagram:
mermaid graph TD subgraph Data Inputs A[Vehicle Telematics] B[User Calendar] C[Time/Location Data] D[In-Car Control Info] end subgraph Portable Terminal E[AI/ML Assignment Engine] F[Operations Library] G[Conversion Unit] end subgraph In-Car Device H[Physical Controls] I[Display] end A & B & C & D --> E E -- Selects & Prioritizes --> F E -- Generates Control Map --> I User -- Interacts with --> H H -- Actuation Signal --> G G -- Mapped Command --> F

Derivative 6: Graceful Degradation and Failsafe Operation Mode

Enabling Description: The system is designed to enter a restricted, failsafe mode under specific conditions, such as the detection of a critical vehicle diagnostic trouble code (DTC), low battery on the portable terminal (<15%), or activation of the vehicle's "limp home" mode. In this state, the in-car device transmits "actuation information" that includes a "FAILSAFE" or "LIMITED_FUNCTIONALITY" flag. The portable terminal's "assignment unit" is programmed to recognize this flag. Upon detection, it ignores its standard, feature-rich "operation assignment information" and instead loads a minimal, pre-defined "safe mode" assignment map. This map only assigns the most critical, low-distraction functions (e.g., 'Emergency Call', 'Hazard Lights Toggle' if permitted, 'Navigation Audio Mute') to the in-car controls. All non-essential functions are unassigned and their icons are removed from the in-car display to minimize driver distraction and conserve terminal battery power during an emergency.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Normal_Mode
    Normal_Mode: Full feature set available
    Safe_Mode: Only critical functions assigned
    Normal_Mode --> Safe_Mode: on (DTC_Received or LowBattery_Signal)
    Safe_Mode --> Normal_Mode: on (Clear_DTC or Battery_Charged)
    state Normal_Mode {
      state "Receive Full Actuation Info" as S1
      state "Assign All Operations" as S2
      state "Display Full UI" as S3
       S1 --> S2
       S2 --> S3
    }
    state Safe_Mode {
      state "Receive Actuation Info with 'SAFE' flag" as S4
      state "Assign Emergency-Only Operations" as S5
      state "Display Minimalist UI" as S6
       S4 --> S5
       S5 --> S6
    }

Combination Prior Art Scenarios

Combination with W3C Vehicle Information Service Specification (VISS): The communication protocol between the in-car device and the portable terminal is implemented entirely using the open W3C VISS standard. The in-car device acts as a VISS server, exposing its physical controls (buttons, dials) as nodes in the standard vehicle data tree (e.g., Vehicle.Cabin.Infotainment.HMI.Controls.Button[0-5] and Vehicle.Cabin.Infotainment.HMI.Controls.Rotary[0-1]). The portable terminal, as a VISS client, connects via WebSocket and uses a get request to retrieve this control structure, which serves as the "actuation information." The terminal then uses subscribe to listen for events on these nodes. An "actuation signal" is a data-change notification published by the server when a control is used. The terminal's "conversion unit" is its event handler, which maps these notifications to its internal application functions based on the "operation assignment information." The "actuation correspondence information" can be sent back as a set request to a separate node (e.g., Vehicle.Cabin.Infotainment.HMI.Display.SoftkeyLabels), populating the in-car display with the correct icons.
Combination with Controller Area Network (CAN) Bus and J1939 Standard: For direct vehicle control applications (e.g., aftermarket accessories), the in-car device acts as a gateway to the vehicle's CAN bus. The "actuation information" sent to the portable terminal includes a list of available Society of Automotive Engineers (SAE) J1939 Parameter Group Numbers (PGNs) that the in-car device is authorized to transmit (e.g., controlling auxiliary lighting, PTO engagement). The "operation assignment information" on the portable terminal maps application functions (e.g., a "Strobe Lights" button in a utility vehicle app) to these PGNs. When the user activates a function, the "actuation signal" is processed by the terminal's "conversion unit" to construct a valid J1939-compliant CAN message frame. This "operating command" is sent to the in-car gateway, which then broadcasts it directly onto the vehicle's CAN bus to control the target electronic control unit (ECU).
Combination with MQTT (Message Queuing Telemetry Transport) for Fleet Management: In a commercial vehicle context, the system uses the open MQTT protocol. The "in-car device" is an IoT gateway in the truck, and the "portable terminal" is a centralized dispatch/management application on a server. The in-car device publishes its available controls and capabilities to a specific MQTT topic (e.g., vehicle/VIN123/hmi/info). The server-side application (the "terminal") subscribes to this topic. Its "assignment unit" processes this information and can remotely push an "operation assignment" configuration back to the truck's device on another topic (e.g., vehicle/VIN123/hmi/assignment). This allows a fleet manager to remotely define what functions (e.g., 'Log Arrival', 'Report Fuel Level', 'Initiate Panic Alert') are available to the driver and which physical buttons they are mapped to. A button press in the cab publishes a message (the "actuation signal") to an event topic (e.g., vehicle/VIN123/hmi/events), which the server consumes and converts into a backend "operating command," such as updating the fleet logistics database.