The search confirms the existence of US Patent 12037004, titled "Controlling driving modes of self-driving vehicles", issued on July 16, 2024. The snippet provides the same abstract and background information as in the provided text, confirming consistency.

Now, proceeding with the "Defensive Disclosure" document.

Defensive Disclosure for US Patent 12037004

This document discloses derivative variations of the technology described in US Patent 12037004, titled "Controlling driving modes of self-driving vehicles," with the aim of establishing prior art for future incremental improvements by competitors. The derivations are based on the core method of comparing control processor competence and human driver competence during an operational anomaly to selectively assign vehicle control.

Derivative Variations of Core Claims

1. Material & Component Substitution

Enabling Description:
The disclosed invention can be implemented using alternative sensor technologies, processing architectures, and communication modalities. For sensor readings describing a current operational anomaly, instead of traditional camera or radar systems, a multi-modal sensor suite comprising solid-state LiDAR (e.g., Flash LiDAR with 1550nm wavelength for eye safety and atmospheric penetration) for dense 3D point cloud generation, quantum magnetometers for highly sensitive detection of metallic component fatigue (e.g., wheel bearing wear, suspension stress), and acoustic emission sensors (e.g., piezoelectric transducers mounted on drivetrain components) for early detection of mechanical faults via vibrational analysis can be used. The determination of both control processor competence level (CPCL) and human driver competence level (HDCL) can be offloaded from a general-purpose CPU to dedicated Application-Specific Integrated Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs). These specialized processors, optimized for real-time inference of complex neural network models, can execute the competence assessment algorithms with sub-millisecond latency. For instance, a low-power, high-performance ARM Cortex-M based microcontroller augmented with a custom AI accelerator (e.g., a tensor processing unit) could handle initial sensor data pre-processing and anomaly classification at the edge, while a more powerful FPGA array (e.g., Xilinx Versal ACAP) performs the complex comparative competence assessment. Communication between vehicle sub-systems, other vehicles, and infrastructure for aggregated historical competence data and environmental reports can utilize ultra-wideband (UWB) wireless transceivers for high-accuracy localization and secure, short-range data exchange (e.g., for platooning, immediate surrounding vehicle data), complemented by 5G New Radio (NR) sidelink (PC5 interface) for direct vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication, ensuring low latency and high bandwidth for critical safety messages. The selective assignment of control can then be executed by redundant electro-hydraulic actuation systems (e.g., for braking and steering) in conjunction with fly-by-wire or drive-by-wire electromechanical throttle control, each system equipped with independent power supplies and fail-safe mechanisms (e.g., hydraulic accumulators, mechanical override linkages).

graph TD
    A[Multi-modal Sensor Suite] --> B{Sensor Data Fusion};
    B --> C[Anomaly Detection Module (Edge AI Accelerator)];
    C --> D[CPCL Determination Unit (FPGA/ASIC)];
    C --> E[HDCL Determination Unit (FPGA/ASIC)];
    D --> F{Competence Comparison Logic};
    E --> F;
    F --> G{Control Assignment Decision};
    G --> H[Redundant Actuation Systems (Electro-hydraulic/Electromechanical)];
    A -- (LiDAR, Quantum Mag, Acoustic E.) --> B;
    F -- (UWB, 5G NR Sidelink) --> I[External Data Sources (Historical Competence, Env. Report)];
    I --> D;
    I --> E;

2. Operational Parameter Expansion

Enabling Description:
The core method can be extended to extreme operational scales and environments. Consider its application to autonomous deep-sea exploration submersibles or extra-terrestrial rover systems. In deep-sea applications (pressures up to 100 MPa, temperatures near 0°C), anomalies could include manipulator arm entanglement, thruster degradation, or sonar malfunction. Sensor readings would involve high-pressure-tolerant acoustic arrays, extreme-depth cameras with specialized lighting, and redundant inertial navigation units. CPCL would assess the submersible's AI navigation and object avoidance capabilities under current acoustic distortion or thruster efficiency degradation. HDCL would assess a human pilot's remote operation competence, factoring in communication latency, physiological stress monitors (e.g., galvanic skin response, heart rate variability from biometric sensors on the human operator's console), and prior experience with specific deep-sea anomalies. Control assignment would prioritize the more competent entity for tasks like emergency ascent, obstacle avoidance, or localized repair. At the nanoscale, within robotic surgical systems, an anomaly could be a micro-tool breakage or unexpected tissue response. Sensors would be femtosecond-pulse lasers for tissue ablation monitoring, force feedback micro-sensors on robotic effectors, and real-time cellular imaging. CPCL would be the AI's ability to maintain surgical precision despite tool degradation, while HDCL would be the surgeon's ability to compensate via haptic feedback and visual cues. The system would dynamically assign control for micro-manipulation based on which entity has higher competency in that specific, highly granular operational context, minimizing collateral damage and ensuring patient safety.

stateDiagram-v2
    state NormalOperatingMode {
        SDVControl: Autonomous
        HumanControl: Manual
        entry / Initial checks
    }

    state AnomalyDetected {
        CPCL_Eval: Evaluate SDV AI Competence
        HDCL_Eval: Evaluate Human Competence
        Comparison: Compare CPCL vs HDCL
        entry / Sensor readings indicate anomaly
    }

    state ExtremeEnvironmentApplication {
        DeepSea: Autonomous Submersible
        SpaceRover: Extra-Terrestrial Rover
        NanoSurgery: Robotic Surgical System
        entry / Specific environmental adaptations
    }

    NormalOperatingMode --> AnomalyDetected: Anomaly detected
    AnomalyDetected --> AssignAutonomous: CPCL > HDCL
    AnomalyDetected --> AssignManual: HDCL > CPCL
    AnomalyDetected --> EmergencyShutdown: Neither > Threshold

    AssignAutonomous --> NormalOperatingMode
    AssignManual --> NormalOperatingMode
    EmergencyShutdown --> SystemHalt

    state AssignAutonomous {
        Control: AI (Autonomous)
        entry / AI assumes control
    }

    state AssignManual {
        Control: Human (Manual)
        entry / Human assumes control
    }

    state EmergencyShutdown {
        Action: Safe Stop Initiated
        entry / Halt vehicle operation
    }

    DeepSea --> AnomalyDetected
    SpaceRover --> AnomalyDetected
    NanoSurgery --> AnomalyDetected

3. Cross-Domain Application

3.1. Autonomous Marine Vessels (Shipping/Logistics)

Enabling Description:
In autonomous marine vessels, such as cargo ships or survey boats, the system identifies operational anomalies like radar system failure during fog, propulsion system degradation, or unusual wave patterns. Sensors include marine radar, sonar, GPS/GNSS, AIS transponders, engine diagnostics, and motion reference units (MRUs) detecting vessel pitch, roll, and heave. The control processor competence level (CPCL) is determined by the vessel's AI navigation system's historical performance in similar degraded conditions (e.g., navigating through dense fog with partial sensor loss, maintaining course with reduced propulsion power, avoiding collisions in heavy seas using only AIS and reduced radar range). The human driver (captain or remote operator) competence level (HDCL) is derived from their training records, certification levels, recent simulation performance, fatigue monitoring (e.g., eye-tracking, psychometric assessments), and real-time physiological data. For instance, if the vessel's AI is highly proficient at maintaining station in severe weather but the radar fails in dense fog, while the human captain has extensive experience navigating visually or with backup systems in such conditions, control would be assigned to the human. Conversely, if the human operator shows signs of fatigue during a complex navigation sequence that the AI has mastered, the AI would retain or assume control.

graph TD
    A[Marine Sensor Suite] --> B{Anomaly Detection (Radar, Engine, Weather)};
    B --> C[Vessel AI Navigator (CPCL)];
    B --> D[Human Captain Profile (HDCL)];
    C --> E{Competence Comparison};
    D --> E;
    E --> F{Control Assignment Decision};
    F -- AI > Human --> G[Autonomous Navigation System];
    F -- Human > AI --> H[Manual Bridge Control];
    G --> I[Marine Propulsion & Steering];
    H --> I;
    A -- (Radar, Sonar, GPS, Engine Diags, MRU) --> B;
    D -- (Training, Certs, Fatigue Monitor) --> D;

3.2. Industrial Robotics (Manufacturing/Assembly)

Enabling Description:
In an advanced manufacturing facility, complex robotic arms perform delicate assembly or hazardous material handling. An operational anomaly could be a gripper mechanism malfunction (e.g., losing grip precision), a vision system sensor drift, or an unexpected vibration in the robotic arm. Sensors include force/torque sensors at the end-effector, high-resolution cameras with optical encoders, accelerometers on robotic joints, and material property sensors (e.g., infrared for temperature, conductivity for material identification). The control processor competence level (CPCL) reflects the robot's AI's ability to maintain assembly tolerance or safely manipulate materials despite sensor inaccuracies or mechanical play. The human driver (remote operator or on-site technician) competence level (HDCL) is derived from their manual dexterity test scores, training in specific hazardous scenarios, real-time physiological indicators (e.g., tremor detection, cognitive load from EEG sensors), and response times to simulated faults. If, for example, the robot's gripper experiences a slight slip due to a software glitch, but the task involves delicate, high-value components, and the human operator has demonstrated superior fine motor control in handling such incidents, control is transferred to the human. If the human operator is performing another critical task or shows diminished response, the AI maintains control, potentially initiating a safe-hold state.

graph TD
    A[Robotic Arm Sensor Array] --> B{Anomaly Detection (Gripper, Vision, Vibration)};
    B --> C[Robot Control AI (CPCL)];
    B --> D[Human Operator Profile (HDCL)];
    C --> E{Competence Comparison};
    D --> E;
    E --> F{Control Assignment Decision};
    F -- AI > Human --> G[Autonomous Robotic Task Execution];
    F -- Human > AI --> H[Manual Remote Manipulation];
    G --> I[Robotic Actuators & End-Effectors];
    H --> I;
    A -- (Force/Torque, Camera, Accelerometer, Material Sensors) --> B;
    D -- (Dexterity Scores, Training, Physiological Monitor) --> D;

3.3. Aerospace (UAVs/Drones for Cargo/Passenger eVTOL)

Enabling Description:
For Unmanned Aerial Vehicles (UAVs), particularly large cargo drones or future Electric Vertical Take-Off and Landing (eVTOL) passenger aircraft, an operational anomaly could be a partial motor failure, an avionics sensor malfunction (e.g., faulty altimeter), or a sudden unpredicted wind shear. Sensors include redundant IMUs, GPS/GNSS, air data systems (pitot-static), magnetometers, motor health sensors (temperature, RPM, current), and radar altimeters. The control processor competence level (CPCL) represents the autopilot's capability to maintain stable flight, execute emergency procedures (e.g., autorotation, glide to nearest safe landing zone) or recover from stalls, given the specific anomaly. The human driver (remote pilot or on-board safety pilot in eVTOL) competence level (HDCL) is based on flight hours, emergency procedure training, real-time stress/cognitive load assessment (e.g., from eye-tracking and voice analysis on the ground control station), and physiological monitoring. For instance, in a cargo drone experiencing a partial motor failure over rugged terrain, if the autopilot has a proven track record of successful single-motor landings under similar conditions and the remote pilot is currently distracted, the AI maintains control. Conversely, if the anomaly presents an unprecedented scenario requiring creative problem-solving and the human pilot demonstrates superior judgment and real-time adaptability, control can be transferred.

graph TD
    A[Avionics Sensor Suite] --> B{Anomaly Detection (Motor, Sensor, Weather)};
    B --> C[Autopilot AI (CPCL)];
    B --> D[Human Pilot Profile (HDCL)];
    C --> E{Competence Comparison};
    D --> E;
    E --> F{Control Assignment Decision};
    F -- AI > Human --> G[Autonomous Flight Control];
    F -- Human > AI --> H[Remote Pilot Control];
    G --> I[Flight Actuators (Propulsion, Control Surfaces)];
    H --> I;
    A -- (IMU, GPS, Air Data, Mag, Motor Health, Radar Altimeter) --> B;
    D -- (Flight Hours, Emergency Training, Stress/Cognitive Monitor) --> D;

4. Integration with Emerging Tech

Enabling Description:
The system can be significantly enhanced through integration with AI-driven optimization, a vast network of IoT sensors for real-time environmental context, and blockchain for immutable data logging and verifiable trust.

AI-Driven Optimization: The determination of CPCL and HDCL is continuously optimized using a reinforcement learning (RL) agent. This agent observes past control assignments, the resulting outcomes (e.g., accident rates, efficiency metrics, passenger comfort scores), and continuously refines the weighting factors for various sub-competence criteria and anomaly types. Predictive anomaly detection is achieved through deep learning models (e.g., recurrent neural networks, transformers) analyzing sensor data streams for subtle pre-cursors to faults (e.g., abnormal vibrational signatures, slight deviations in motor current, tiny inconsistencies in steering feedback) that might indicate an impending operational anomaly hours or days in advance. This allows for proactive maintenance scheduling or pre-emptive mode-switching recommendations.

IoT Sensors for Real-time Monitoring: Beyond the vehicle's onboard sensors, a dense network of roadside IoT sensors (e.g., low-power wide-area network (LPWAN) connected nodes with micro-radar, environmental gas sensors, high-definition cameras, pavement friction sensors) provides hyper-local, real-time environmental data. This data (e.g., specific lane-level ice patches, presence of debris, localized air quality, real-time traffic density on a micro-segment) is streamed to the SDV and/or a coordinating edge server. This allows for extremely granular and dynamic adjustments to both CPCL and HDCL assessments. For example, knowing a specific 10-meter stretch of road has reduced friction due to an oil spill (from an IoT sensor) would dramatically alter competence levels for both AI and human for that specific segment.

Blockchain for Supply Chain Verification and Competence Audit: All operational anomaly detections, competence level calculations, control assignment decisions, and subsequent outcomes (e.g., successful mitigation, incident reports) are cryptographically signed and logged onto a distributed ledger (blockchain). This creates an immutable, transparent, and auditable record of the SDV's operational history, the AI's performance, and the human driver's interventions. This blockchain ledger can also store verified driver profiles, including training certifications, medical clearances, and historical performance data (anonymized where necessary), allowing for secure and trustless sharing of HDCL information across different vehicle manufacturers or regulatory bodies. Furthermore, vehicle component supply chain data, including sensor calibration logs and maintenance records, can be stored on the blockchain, influencing initial CPCL baselines based on verifiable component provenance and service history.

sequenceDiagram
    participant SDV as Self-Driving Vehicle
    participant IoT as IoT Sensor Network
    participant EdgeAI as Edge AI/RL Agent
    participant CloudDB as Cloud Database/Blockchain
    participant Driver as Human Driver Interface

    IoT-->>SDV: Stream Real-time Environmental Data
    SDV-->>SDV: Onboard Sensor Data
    SDV->>SDV: Detect Operational Anomaly
    SDV->>EdgeAI: Send Anomaly & Context Data

    EdgeAI->>EdgeAI: Refine CPCL/HDCL Models (RL)
    EdgeAI->>SDV: Provide Updated Competence Factors & Predictions
    
    SDV->>SDV: Determine CPCL & HDCL (using updated factors)
    SDV->>SDV: Compare Competence Levels
    SDV->>SDV: Selectively Assign Control (AI/Human)

    SDV-->>Driver: Display Alert/Request for Handover (if human assigned)
    Driver-->>SDV: Human Control Input (if assigned)

    SDV->>CloudDB: Log Anomaly, Competence, Decision, Outcome (Blockchain Transaction)
    CloudDB->>CloudDB: Verify & Store Immutable Record
    CloudDB->>EdgeAI: Provide Historical Data for RL Training

5. The "Inverse" or Failure Mode

Enabling Description:
In a scenario where a severe operational anomaly occurs, and the system determines that neither the on-board SDV control processor nor the human driver meets a predetermined minimum competence level threshold (e.g., due to catastrophic brake failure on an icy road, or a sudden, complete sensor outage in a complex urban environment), the system initiates a "Guardian Mode" or "Minimum Risk Maneuver (MRM) Mode" instead of an immediate full stop. This mode is designed for safe, graceful degradation and maximizes survivability.
In Guardian Mode, all non-critical systems are powered down. The vehicle's control is handed over to a simplified, highly robust, and computationally light "safety kernel" which prioritizes only fundamental vehicle dynamics control:

Reduced Speed & Directional Stability: The safety kernel attempts to minimize speed while maintaining the vehicle within its current lane or a designated emergency lane, avoiding abrupt maneuvers. It utilizes only the most reliable, redundant sensors (e.g., IMU, simplified radar for immediate frontal collision avoidance) and highly constrained control policies.
Hazard Communication: The vehicle automatically activates hazard lights, broadcasts emergency V2X messages (e.g., "IMPACT ALERT," "LIMITED FUNCTIONALITY VEHICLE"), and initiates an automated emergency call (e.g., eCall) with location and anomaly details.
Path Planning to Safe Haven: Concurrently, a "Safe Haven Planner" module, operating on pre-computed or dynamically identified safe pull-over locations (e.g., wide shoulders, rest stops, low-traffic areas, or hard shoulders of highways) with minimal environmental complexity, calculates a trajectory to the nearest such location. This planner considers factors like vehicle kinetic energy, remaining brake capacity (if any), road grade, and potential obstacles.
Remote Override & Monitoring: If available, a remote fleet operator gains limited, high-level supervisory control, able to issue coarse directional commands or activate emergency braking via a secure, low-latency satellite link, while the on-board system maintains primary Guardian Mode operations.

The decision to enter Guardian Mode is triggered if CPCL < Min_Threshold AND HDCL < Min_Threshold. The system continuously attempts to re-evaluate CPCL and HDCL. If at any point either rises above the minimum threshold and the anomaly is still manageable, control can be restored to the more competent entity.

stateDiagram-v2
    [*] --> NormalDriving: System Initialized
    NormalDriving --> AnomalyDetected: Operational Anomaly Detected
    AnomalyDetected --> EvaluateCompetence: Sensor Readings Processed
    EvaluateCompetence --> AssignAutonomous: CPCL >= HDCL AND CPCL >= Min_Threshold
    EvaluateCompetence --> AssignManual: HDCL > CPCL AND HDCL >= Min_Threshold
    EvaluateCompetence --> GuardianMode: CPCL < Min_Threshold AND HDCL < Min_Threshold
    
    AssignAutonomous --> NormalDriving: AI manages anomaly
    AssignManual --> NormalDriving: Human manages anomaly

    state GuardianMode {
        entry: Activate Hazard Lights, Broadcast V2X, eCall
        state ReducedSpeedAndStability <<fork>>
        state SafeHavenPlanning <<fork>>
        state RemoteSupervisoryControl <<fork>>

        ReducedSpeedAndStability --> SafeStopPoint: Guide to Safe Pull-over
        SafeHavenPlanning --> SafeStopPoint
        RemoteSupervisoryControl --> SafeStopPoint: Remote input
        SafeStopPoint --> [*]: Vehicle Stopped Safely
        exit: Deactivate all systems, Secure vehicle
    }

    GuardianMode --> EvaluateCompetence: Re-evaluate if conditions improve

Combination Prior Art Scenarios with Open-Source Standards

Integration with AUTOSAR Adaptive Platform:
The competence management module (LMSDV 147, driving mode module 307, SDV on-board computer 301) and its associated functions (anomaly detection, CPCL/HDCL determination, comparison, and control assignment) can be implemented as a set of Adaptive Applications within an AUTOSAR Adaptive Platform architecture. The sensor readings (from sensors 153, navigation and control sensors 309, roadway sensor(s) 206) would be received via the AUTOSAR Communication Management (COM) and diagnostics interfaces, leveraging standardized service-oriented communication. The AI/ML models for competence assessment could run on a dedicated Machine Learning runtime environment (part of the Execution Management or Adaptive Platform Foundation). The control assignment decision, being safety-critical, would be managed by a dedicated safety monitor application, ensuring compliance with ASIL (Automotive Safety Integrity Level) requirements. Historical competence data and driver profiles could be stored and retrieved using AUTOSAR Persistent Memory services, and external environmental reports could be integrated via the Gateway to external networks. This framework provides a standardized, modular, and scalable approach to developing and deploying the patent's core functionality, enabling clear interfaces and ensuring interoperability within complex E/E architectures.
Integration with IEEE 802.11p/DSRC or 5G NR V2X:
The system's ability to receive environmental reports from an "environmental reporting service" (e.g., a weather service) and information from other SDVs (SDV 210, SDV 212) or roadway monitoring systems (208) (as described in FIG. 4, and the general communication described in the patent) can be fully realized using open-source V2X communication standards. IEEE 802.11p (Dedicated Short Range Communications - DSRC) or its successor, 5G New Radio (NR) V2X, would serve as the communication backbone (e.g., via network 127, transceiver 123). SDVs could broadcast Basic Safety Messages (BSM) containing vehicle state, position, and detected operational anomalies (e.g., "tire pressure low," "braking system fault"). Roadside Units (RSUs) or other SDVs could broadcast Cooperative Awareness Messages (CAM) or Decentralized Environmental Notification Messages (DENM) providing real-time local road conditions (e.g., "icy patch ahead," "debris on road," "heavy rain"). This allows the SDV (e.g., SDV 202) to receive highly localized, granular data about the operational anomalies of nearby vehicles and environmental conditions, which directly informs the comparison of CPCL and HDCL for the "roadway specific" competence assessment mentioned in the patent. The low latency and direct communication capabilities of V2X are crucial for safety-critical decisions.
Implementation using ROS 2 (Robot Operating System 2):
The modular nature of the patent's method – sensor input, competence determination, comparison, and control assignment – lends itself well to implementation using ROS 2. Each functional block, such as the anomaly detection module, the CPCL calculation module, the HDCL profile manager, the competence comparison logic, and the driving mode module (307), can be implemented as independent ROS 2 nodes. Sensor data (sensors 153, navigation and control sensors 309) would be published as ROS 2 messages on defined topics (e.g., /sensor/camera, /vehicle/IMU). The competence calculation nodes would subscribe to these topics, perform their processing, and publish CPCL and HDCL values to a /competence/levels topic. The central decision-making node would subscribe to this, perform the comparison, and publish a /vehicle/control_mode_command message (e.g., mode: AUTONOMOUS, mode: MANUAL). This data-centric publish-subscribe architecture, with its robust inter-process communication (DDS-based), introspection tools, and multi-platform support, allows for flexible development, testing, and deployment of complex autonomous driving software, adhering to the logical flow described in the patent. Furthermore, ROS 2's security features (SROS 2) can ensure the integrity and authenticity of critical data flows, especially for driver profiles and control commands.

Derivative works