Derivative works — US Patent 7482916

Defensive Disclosure and Prior Art Generation for U.S. Patent No. 7,482,916

Publication Date: May 1, 2026
Subject: Derivatives and extensions of automatic vehicle signaling systems based on lane position sensing.
Reference Patent: U.S. Patent No. 7,482,916, "Automatic signaling systems for vehicles" (the '916 patent).

This document serves as a defensive disclosure to establish prior art for innovations and improvements related to the automatic activation of vehicle turn signals based on sensor data, as broadly described in the '916 patent. The following disclosures detail derivative inventions, cross-domain applications, and integrations with emerging technologies.

Derivatives of Core Claim 1: The Basic System

Claim 1: An automatic signaling system, comprising: a processor having an input for receiving a signal from a sensor, and an output configured to be coupled to a signaling system of a vehicle, the signaling system having a turn signal light, wherein the processor is configured to automatically activate the turn signal light based at least in part on the signal received from the sensor.

Derivative 1.1: Multi-Sensor Fusion with Redundancy

Enabling Description: This system utilizes a sensor array comprising a primary forward-facing CMOS camera, a Long-Wave Infrared (LWIR) thermal camera, and a 77 GHz RADAR sensor. The processor is a Field-Programmable Gate Array (FPGA) executing a sensor fusion algorithm. The algorithm weights inputs based on environmental conditions; for instance, in fog or heavy rain, RADAR data is weighted more heavily than visual data from the CMOS camera. The LWIR camera provides robust lane marking detection at night or in low-light conditions by detecting temperature differences between the road surface and paint. If one sensor provides anomalous data (e.g., due to obstruction or failure), it is automatically discounted by the processor, which then relies on the remaining sensors to maintain system functionality, thereby providing a fail-operational capability.

Mermaid Diagram:

graph TD
    A[CMOS Camera] --> C{FPGA Processor};
    B[LWIR Thermal Camera] --> C;
    D[77 GHz RADAR] --> C;
    C -- Fused Data --> E[Lane Position Analysis];
    E -- Position Exceeds Threshold --> F[Activate Turn Signal];

Derivative 1.2: Solid-State LiDAR and Predictive Path Analysis

Enabling Description: The sensor is a solid-state LiDAR unit, providing a high-density 3D point cloud of the road ahead. The processor, an automotive-grade System-on-a-Chip (SoC) with an integrated Neural Processing Unit (NPU), uses the point cloud data to not only identify lane boundaries but also to model the road's curvature and predict the vehicle's trajectory. The system activates the turn signal not just when a boundary is approached, but when the vehicle's projected path, calculated over a 3-second future time horizon, indicates a lane departure. The activation threshold is dynamically adjusted based on vehicle speed, with a lower proximity tolerance at higher speeds.

Mermaid Diagram:

sequenceDiagram
    participant LiDAR as Solid-State LiDAR
    participant SoC as Automotive SoC (NPU)
    participant VCU as Vehicle Control Unit

    LiDAR->>SoC: Transmit Point Cloud Data
    SoC->>SoC: Analyze Point Cloud for Lane Boundaries
    SoC->>SoC: Calculate Vehicle's 3-Second Projected Path
    alt Projected Path Crosses Lane Boundary
        SoC->>VCU: Send Turn Signal Activation Command
    end

Derivative 1.3: Ultrasonic Side-Sensing for Urban Environments

Enabling Description: In this embodiment, the system uses a distributed network of twelve ultrasonic sensors embedded along the vehicle's sides and bumpers, similar to those used for parking assist. The processor continuously monitors the time-of-flight data from these sensors to map the precise distance to curbs, barriers, and adjacent lane markings. This is particularly effective in low-speed, urban environments where forward-looking cameras may have limited fields of view. The system triggers the turn signal when the vehicle's lateral drift rate, calculated from changes in sensor readings over time, exceeds a pre-set threshold (e.g., 0.5 meters/second) while in close proximity (e.g., less than 0.75 meters) to a lane line.

Mermaid Diagram:

graph LR
    subgraph Vehicle
        US1[Ultrasonic Sensor 1]
        US2[Ultrasonic Sensor 2]
        US3[...]
        US12[Ultrasonic Sensor 12]
    end
    subgraph Processing Unit
        CPU[Processor]
        MEM[Memory with Thresholds]
    end
    US1 --> CPU
    US2 --> CPU
    US3 --> CPU
    US12 --> CPU
    CPU -- Compares to Thresholds --> MEM
    CPU -- Drift Rate Exceeded --> TS[Turn Signal System]

Derivative 1.4: Geomagnetic Sensor Integration

Enabling Description: This system uses a sensitive three-axis magnetometer as the primary sensor. It is designed for road systems where magnetic tape or magnetically charged markers are embedded in the road surface to define lane boundaries. The processor analyzes the magnetic field data to determine the vehicle's lateral position relative to these markers. This provides a highly reliable signal that is immune to weather conditions like snow, rain, or fog that can obscure visual markings. An activation signal is sent to the turn signal system when the magnetometer detects a lateral deviation greater than 50% of the distance to the adjacent magnetic marker.

Mermaid Diagram:

stateDiagram-v2
    [*] --> In_Lane
    In_Lane: Monitoring Magnetic Field
    In_Lane --> Approaching_Boundary: Lateral Deviation > 50%
    Approaching_Boundary: Activate Turn Signal
    Approaching_Boundary --> In_Adjacent_Lane: Lane Change Confirmed
    Approaching_Boundary --> In_Lane: Corrective Steering Detected
    In_Adjacent_Lane --> [*]

Derivative 1.5: Graphene-Based Strain Sensors in Tires

Enabling Description: The system uses graphene-infused piezoelectric strain sensors integrated into the sidewalls of the vehicle's tires. These sensors detect minute changes in tire deformation as it passes over different surfaces. The processor is trained to recognize the unique deformation signature created when a tire rolls over a painted lane marking, a rumble strip, or a Botts' dot. By comparing inputs from the left and right tires, the processor can determine if the vehicle is drifting. If the right-side tire registers a lane marking signature without a corresponding manual signal from the driver, the system activates the right turn signal.

Mermaid Diagram:

classDiagram
class TireSensor {
  +string sensorID
  +float strainValue
  +detectSurfaceType()
}
class Processor {
  +analyzeTireData(left_sensor, right_sensor)
  +activateSignal(direction)
}
class TurnSignalSystem {
  +activate(direction)
}
Processor --> TireSensor : receives data from
Processor --> TurnSignalSystem : controls

Derivatives of Core Claim 20: The Method

Claim 20: A method for activating a turn signal light of a vehicle, comprising: receiving a signal from a sensor; and automatically activating the turn signal light of the vehicle based at least in part on the received signal.

Derivative 2.1: Cross-Domain Application - Agricultural Robotics

Enabling Description: The method is applied to an autonomous agricultural tractor. The "lanes" are crop rows detected by a stereo-vision camera system (the sensor). The "turn signal" is a set of high-intensity LED strobe lights (e.g., amber and green) mounted on a mast. When the tractor's guidance system determines a turn is imminent to enter the next crop row, it receives a signal from the camera system confirming it is at the end of a row. The processor then automatically activates the appropriate strobe light to signal its intent to other autonomous or human-operated vehicles in the field, preventing collisions during coordinated harvesting operations.

Mermaid Diagram:

flowchart TD
    A[Stereo-Vision Sensor Detects End of Crop Row] --> B{Processor Receives Signal};
    B --> C{Is Turn Imminent?};
    C -- Yes --> D[Activate Directional Strobe Light];
    C -- No --> A;
    D --> E[Execute Turn into Next Row];

Derivative 2.2: Cross-Domain Application - Aerospace Autopilot

Enabling Description: The method is adapted for an unmanned aerial vehicle (UAV) operating in a designated air corridor. The "sensor" is a combination of GPS and an ADS-B (Automatic Dependent Surveillance-Broadcast) receiver. The "lane boundaries" are the geofenced perimeters of the flight corridor. If the UAV's flight path, as reported by its GPS, is projected to deviate from the corridor, the processor automatically activates a change in the UAV's transponder squawk code or a dedicated digital flag in its ADS-B out-stream. This "signal" alerts air traffic control and other ADS-B equipped aircraft of an unplanned maneuver.

Mermaid Diagram:

sequenceDiagram
    participant UAV
    participant ATC as Air Traffic Control
    participant OtherAircraft as Other Aircraft

    UAV->>UAV: Project Flight Path vs. Geofence
    alt Path Deviation Detected
        UAV->>ATC: Transmit Alert Squawk Code
        UAV->>OtherAircraft: Broadcast ADS-B Deviation Flag
    end

Derivative 2.3: Cross-Domain Application - Personal Mobility Device Safety

Enabling Description: The method is implemented on an electric scooter or e-bike. The sensor is a 6-axis Inertial Measurement Unit (IMU). The processor analyzes the IMU data to detect a sharp lean angle (e.g., > 15 degrees) sustained for more than 500 milliseconds, which is indicative of a turn. This automatically activates integrated LED light strips on the corresponding side of the scooter, providing a turn signal without requiring the rider to remove their hands from the handlebars. The system is calibrated for a speed threshold (e.g., > 5 mph) to avoid activation during stationary balancing.

Mermaid Diagram:

stateDiagram-v2
    state "Stationary or Straight" as Straight
    [*] --> Straight
    Straight --> Turning: Lean Angle > 15° for >500ms
    Turning --> Straight: Lean Angle < 5°

    state Turning {
        entry / activate_led_signal()
        exit / deactivate_led_signal()
    }

Derivatives of Core Claim 33: The Computer Program Product

Claim 33: A computer program product for use with an automatic signaling system of a vehicle...the process includes automatically activating a turn signal light of the vehicle based at least in part on a signal received from a sensor.

Derivative 3.1: AI/Machine Learning Integration for Predictive Signaling

Enabling Description: The computer program product is an AI model, specifically a Long Short-Term Memory (LSTM) network, trained on a massive dataset of real-world driving scenarios. The software receives input not just from the lane-detection camera, but also from sensors monitoring the driver's head position and eye gaze, surrounding vehicle positions (via V2X communication), and navigation system data (upcoming turns or exits). The AI model predicts the probability of an intentional lane change. When this probability exceeds a confidence threshold (e.g., 95%), the software triggers the turn signal before the vehicle begins to deviate from its lane, providing an earlier warning to other drivers.

Mermaid Diagram:

graph TD
    subgraph Inputs
        A[Lane Camera Data]
        B[Driver Head/Gaze Data]
        C[V2X Traffic Data]
        D[Navigation Route]
    end
    subgraph AI Core
        E[LSTM Network]
    end
    subgraph Output
        F[Turn Signal Activation]
    end
    A & B & C & D --> E
    E -- Lane Change Probability > 95% --> F

Derivative 3.2: IoT Integration for Smart City Communication

Enabling Description: The software is an IoT client running on the vehicle's telematics control unit. Upon receiving a lane departure signal from the primary sensor processor, the program does two things: 1) activates the local turn signal, and 2) publishes an MQTT message to a smart city traffic management broker. The message payload includes the vehicle's ID, location, and intended direction of movement (e.g., {"VID": "A4B3C2", "lat": 40.7128, "lon": -74.0060, "action": "LANE_CHANGE_RIGHT"}). This allows traffic infrastructure, such as smart traffic lights or digital signage, to anticipate the vehicle's maneuver, potentially adjusting light timing or warning other vehicles in a blind spot.

Mermaid Diagram:

sequenceDiagram
    participant Sensor
    participant Vehicle_Processor
    participant Vehicle_TCU as "TCU (IoT Client)"
    participant MQTT_Broker as "City MQTT Broker"
    participant Traffic_Infra as "Smart Infrastructure"

    Sensor->>Vehicle_Processor: Lane Deviation Detected
    Vehicle_Processor->>Vehicle_TCU: Signal Lane Change Intent
    Vehicle_TCU->>MQTT_Broker: PUBLISH (VID, location, action)
    MQTT_Broker->>Traffic_Infra: Forward Message
    Traffic_Infra->>Traffic_Infra: Adjust Signals/Signage

Derivative 3.3: Blockchain Integration for Auditable Event Logging

Enabling Description: The computer program product includes a module for creating and signing a cryptographic transaction whenever the automatic signaling system is activated. The sensor data (timestamp, image hash, distance to lane line) and the activation command are bundled into a data packet. This packet is hashed and anchored to a private, permissioned blockchain maintained by the vehicle manufacturer or a consortium. This creates an immutable, tamper-proof log of every automatic signaling event. In the event of an accident, this log can be audited by insurance companies or regulatory bodies to verify that the system functioned correctly and provided adequate warning.

Mermaid Diagram:

flowchart LR
    A[Sensor Detects Lane Drift] --> B{Processor Activates Signal};
    B --> C[Create Data Packet: Timestamp, Image Hash, GPS];
    C --> D[Cryptographically Hash Packet];
    D --> E[Sign & Submit Transaction to Blockchain];
    E --> F((Immutable Ledger));

Derivatives of Core Claims 47 & 51: The User Control

Claims 47 & 51 describe a control lever with a switch or a distinct movement (e.g., forward push) to enable/disable the automatic system.

Derivative 4.1: Haptic Feedback Control with Adaptive Sensitivity

Enabling Description: The turn signal lever incorporates a haptic feedback motor. The system has three modes, selected by a capacitive touch sensor on the end of the stalk: Off, Standard, and Aggressive. When the automatic system is active and detects a lane drift, it first provides a haptic "nudge" or vibration through the lever, alerting the driver. If the driver does not correct the drift within 750ms, the system then automatically activates the visual signal. The "Aggressive" mode has a shorter haptic-to-visual delay (250ms) and higher sensitivity, intended for highway driving.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Off
    Off --> Standard: Tap on Stalk
    Standard --> Aggressive: Tap on Stalk
    Aggressive --> Off: Tap on Stalk

    state Standard {
        [*] --> Idle
        Idle --> HapticAlert: Lane Drift Detected
        HapticAlert --> VisualSignal: No Correction in 750ms
        HapticAlert --> Idle: Correction Detected
        VisualSignal --> Idle: Lane Change Complete
    }
    state Aggressive {
        [*] --> Idle
        Idle --> HapticAlert: Lane Drift Detected
        HapticAlert --> VisualSignal: No Correction in 250ms
        HapticAlert --> Idle: Correction Detected
        VisualSignal --> Idle: Lane Change Complete
    }

Derivative 4.2: "Inverse" or Failure Mode Operation

Enabling Description: This design prioritizes safe failure. If the processor detects a fault in the primary lane detection sensor (e.g., camera lens obscured, no valid data for >2 seconds), it immediately enters a "manual-only" mode. In this mode, the automatic function is disabled, a "System Fault" icon is illuminated on the instrument cluster, and the turn signal stalk will pulse with a low-frequency vibration every 30 seconds to remind the driver that the automatic feature is inoperative. This prevents the driver from relying on a non-functional system and ensures they revert to manual signal operation. The system can only be re-activated after a successful self-test on the next ignition cycle.

Mermaid Diagram:

graph TD
    A{System On} --> B{Monitor Sensor Health};
    B -- No Fault --> C[Automatic Mode Active];
    C --> B;
    B -- Fault Detected --> D[Enter Fail-Safe Mode];
    D --> E[Disable Automatic Activation];
    D --> F[Display Fault on Dash];
    D --> G[Activate Periodic Haptic Alert in Stalk];

Combination Prior Art Scenarios

Combination with CAN Bus Protocol (ISO 11898): The automatic signaling system's processor (as in Claim 1) does not directly interface with the turn signal bulbs. Instead, it acts as a node on the vehicle's Controller Area Network (CAN) bus. When a lane departure is detected, the processor broadcasts a standard CAN message (e.g., with identifier 0x2C4) containing a data payload that commands the Body Control Module (BCM) to activate the turn signals. The BCM, which already controls lighting, receives and executes this command. This integrates the invention into standard automotive electronic architecture, making it an obvious implementation for a person skilled in the art of vehicle electronics.
Combination with Robot Operating System (ROS): The method of Claim 20 is implemented as a ROS node within an autonomous vehicle's software stack. A publicly available ROS package for camera-based lane detection (e.g., opencv_lane_detector) publishes lane boundary data to a ROS topic called /lane_info. A new "auto_signal_node" subscribes to this topic. When the data on /lane_info indicates the vehicle is within a threshold distance of a boundary, this node publishes a std_msgs/Bool message to a /turn_signal_cmd topic, which is then translated into a CAN bus message by a separate ros_can_bridge node. This uses an open-source framework to achieve the patented method.
Combination with MQTT Protocol: The IoT-integrated derivative (Derivative 3.2) is implemented using the open-source MQTT (Message Queuing Telemetry Transport) protocol, an ISO standard (ISO/IEC 20922). The vehicle's processor runs a Paho MQTT client library to connect to a public or private MQTT broker. This combination allows the vehicle's lane departure data to be transmitted in a standardized, lightweight format, making the integration with disparate smart city systems (which also support the open MQTT standard) an obvious step for creating a V2X (Vehicle-to-Everything) safety system.