Patent 10959649

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Active provider: Google · gemini-2.5-pro

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

Defensive Disclosure and Prior Art Publication

Title: Systems and Methods for Dynamic Sensor Calibration Across Multiple Operational Ranges

Publication Date: May 10, 2026

Abstract: This document discloses a series of methods, systems, and applications derived from the core concept of using a verified data point in one operational range to calibrate or adjust estimated data points in other, different operational ranges. The disclosures herein are intended to enter the public domain to serve as prior art for future patent applications. The core mechanism involves a feedback loop where a high-fidelity, "verified" measurement (e.g., from a GPS or other ground-truth system) is used to refine a lower-fidelity, but more continuously available, predictive model or lookup table across its entire domain, not just at the point of verification.

1. Derivative Implementations: Material & Component Substitution

1.1. Piezoelectric In-Sole Sensors with Cellular Triangulation for Verification

  • Enabling Description: This embodiment replaces the body-worn accelerometer with piezoelectric film sensors embedded within the insole of a shoe. Each heel-strike and toe-off generates a voltage spike, providing a high-precision signal for step detection. The processor uses the timing between these spikes to determine step rate. For location verification, instead of a power-intensive GPS module, the system utilizes a low-power cellular modem to obtain coarse location data from Cell ID triangulation (or Wi-Fi positioning system (WPS) data when available). When the user covers a significant distance (e.g., >500m), the change in cell tower locations provides a "verified distance" traveled. This distance is divided by the piezoelectric step count to calculate the verified stride length. The core calibration algorithm then uses this verified stride length at a given step rate to adjust the user's estimated stride length table, which was initially populated based on height and shoe size.

  • Mermaid Diagram (Flowchart):

    flowchart TD
    A[Start: User walks] --> B{Piezoelectric Sensor};
    B -- Voltage Spike --> C[Processor: Detects Step];
    C --> D[Calculate Step Rate (steps/min)];
    D --> E[Access Stride Length Table];
    E -- User Height/Shoe Size --> F[Get Estimated Stride Length (SL_est)];
    F --> G[Calculate Estimated Distance];
    
    subgraph Verification Loop
        H[Low-Power Cellular Modem] --> I{Query Cell Tower IDs};
        I -- Location Data --> J[Processor: Calculate Distance Traveled_ver];
        J -- When Δ > 500m --> K[Calculate Verified Stride Length (SL_ver = Dist_ver / Steps)];
        K --> L{Compare SL_ver with SL_est at current Step Rate};
        L --> M[Adjust Entire Stride Length Table based on delta];
    end
    
    G --> M;

1.2. Optical Flow Sensor with IMU Fusion for Step Detection

  • Enabling Description: This variant is designed for a device worn on the ankle or shoe. It replaces a simple 3-axis accelerometer with a 9-axis Inertial Measurement Unit (IMU) (3-axis accelerometer, 3-axis gyroscope, 3-axis magnetometer) combined with a low-resolution, downward-facing optical flow sensor, similar to those in optical mice. The IMU provides robust data on foot orientation and movement, while the optical flow sensor directly measures displacement relative to the ground. "Steps" are algorithmically determined by the IMU detecting the cyclical motion of a gait cycle. The "stride length" for each step is directly measured by the optical flow sensor. The "step rate" is determined by the IMU. In this embodiment, every step provides a "verified" stride length. The system builds the stride-length-vs-step-rate table dynamically. The purpose of the table is for situations where the optical flow sensor is unreliable (e.g., on highly reflective or transparent surfaces). When the optical sensor signal is lost, the system falls back to using the IMU step rate and the dynamically-built table to estimate distance, similar to the original patent's GPS-denied mode. The calibration is continuous: whenever the optical flow signal is reliable, it updates the corresponding entry in the stride length table.

  • Mermaid Diagram (State Diagram):

    stateDiagram-v2
    [*] --> Operational
    
    state Operational {
        direction LR
        [*] --> Optical_Flow_Reliable
        Optical_Flow_Reliable --> Optical_Flow_Unreliable: Surface Change
        Optical_Flow_Unreliable --> Optical_Flow_Reliable: Surface Normalizes
        
        state Optical_Flow_Reliable {
            IMU: Detect Step Rate
            OpticalFlow: Measure Stride Length
            Processor: Update Stride Length Table at current Step Rate
            Processor: Calculate Distance using Optical Flow data
        }
        
        state Optical_Flow_Unreliable {
            IMU: Detect Step Rate
            Processor: Access Stride Length Table
            Processor: Estimate Stride Length for current Step Rate
            Processor: Calculate Distance using Estimated data
        }
    }

2. Derivative Implementations: Operational Parameter Expansion

2.1. Nanoscale Robotic Calibration in a Viscous Medium

  • Enabling Description: The calibration method is applied to a swarm of microscopic robots (nanobots) navigating within a fluidic environment, such as a bioreactor or pipeline. Each nanobot is propelled by a micro-actuator (e.g., a magnetic flagellum) that operates at a specific frequency ("step rate"). The robot's onboard model contains an "estimated displacement" per actuation cycle ("estimated stride length"). An external high-resolution microscopy and image analysis system serves as the "GPS," tracking the actual position of the nanobots. For a calibration run, a single nanobot is commanded to move at a specific actuation frequency (e.g., 50 Hz). The vision system measures its true distance traveled over a set time. This "verified displacement" is used to create a calibration factor. This factor is then broadcast to the entire swarm, which uses it to adjust their own estimated displacement models across all potential actuation frequencies, accounting for unexpected changes in the fluid's viscosity.

  • Mermaid Diagram (Sequence Diagram):

    sequenceDiagram
    participant Control as Control System
    participant Vision as Microscopy Vision System
    participant NanoBot as Nanobot (Swarm)

    Control->>NanoBot: Initiate Calibration Run at 50 Hz
    NanoBot->>NanoBot: Actuate flagellum at 50 Hz
    loop For 10 seconds
        Vision->>Vision: Track Nanobot Position
    end
    Vision->>Control: Report Total Distance Traveled (Verified)
    Control->>Control: Calculate Verified Displacement/Cycle
    Control->>Control: Compare with Estimated Displacement/Cycle
    Control->>Control: Compute Calibration Factor
    Control->>NanoBot: Broadcast Calibration Factor to Swarm
    NanoBot->>NanoBot: Adjust full Displacement Model (all frequencies)

2.2. Industrial Autonomous Haul Truck Performance Calibration

  • Enabling Description: The method is applied to a fleet of autonomous mining haul trucks. The "step rate" is the engine RPM. The "estimated stride length" is the expected distance traveled per engine revolution, based on a factory model that considers gearing and tire size. The "verified stride length" is calculated using high-precision differential GPS (dGPS). During a haul cycle, the truck operates at a certain average RPM on a specific segment of the route (e.g., an uphill grade). The dGPS measures the exact distance covered. This data is used to calculate a verified distance-per-revolution. This value is compared to the estimate. If the verified value is lower (e.g., due to wheel slip from heavy load and loose gravel), the system infers that the efficiency across all RPM ranges is similarly affected. It then adjusts the truck's entire performance model, which is used for fuel consumption and predictive maintenance calculations, to reflect this reduced efficiency.

  • Mermaid Diagram (Flowchart):

    flowchart TD
    A[Start: Haul Cycle] --> B[Truck operates at Average RPM_1 on Segment_A];
    B --> C{Record Engine Revolutions};
    B --> D{dGPS records Start/End Position};
    D --> E[Calculate Verified Distance];
    E & C --> F[Calculate Verified Distance/Revolution];
    F --> G{Compare with Estimated Distance/Revolution from Model};
    G --> H{Calculate Efficiency Delta};
    H --> I[Adjust entire Fuel/Performance Model for all RPMs];
    I --> J[Use adjusted model for fuel prediction and maintenance scheduling];

3. Derivative Implementations: Cross-Domain Application

3.1. Aerospace: Ion Thruster Degradation Calibration

  • Enabling Description: The calibration method is used to manage the performance of a satellite's Hall-effect (ion) thruster over its lifetime. The thruster's "step rate" is its power level (e.g., 100W, 150W, 200W). The satellite's flight computer has a model of "estimated thrust" per watt-hour ("estimated stride length") for each power level. For a calibration maneuver, the thruster is fired at a specific power level (e.g., 150W) for a set duration. Ground-based radar and telemetry, combined with the satellite's star trackers, precisely measure the resulting change in orbital velocity (delta-v), which is the "verified thrust." As the thruster ages, its efficiency degrades. If the verified thrust at 150W is 3% lower than the model's estimate, the system infers that the efficiency degradation is systemic. It then applies a ~3% downward adjustment to the estimated thrust values for all other power levels in the model, ensuring more accurate fuel (xenon) consumption predictions and more precise orbital station-keeping.

  • Mermaid Diagram (Architecture Diagram):

    graph TD
    subgraph Satellite
        FC(Flight Computer)
        HT(Hall Thruster)
        ST(Star Tracker)
        ANT(Antenna)
    end
    
    subgraph Ground
        GS(Ground Station)
        RAD(Radar)
    end
    
    FC -- Command: Fire at 150W --> HT
    HT -- Produces Thrust --> FC
    FC -- Measures Attitude Change --> ST
    
    GS -- Command via --> ANT
    ANT -- Telemetry --> GS
    
    GS -- Tracking Data --> RAD
    RAD -- Tracking Data --> GS
    
    GS -- Collects all data --> Calibrate{Calibration Module}
    Calibrate -- "Verified Delta-V is 3% low" --> Update{Update Thrust Model}
    Update -- "Adjust estimates for 100W, 200W, etc." --> FC

3.2. AgTech: Variable Rate Irrigation (VRI) Nozzle Calibration

  • Enabling Description: The system is applied to a VRI center-pivot irrigator to calibrate water flow rates. Each nozzle on the pivot is controlled by a PWM valve, where the duty cycle ("step rate") controls the flow. An initial model provides an "estimated flow rate" ("estimated stride length") for each duty cycle percentage. To calibrate, the system operates one section of the pivot at a fixed duty cycle (e.g., 75%) over a test area equipped with IoT soil moisture sensors. The change in soil moisture provides a "verified flow rate" for that duty cycle. If the verified flow is 5% higher than estimated (e.g., due to pump pressure variance), the central controller infers that the pressure is high across the system and adjusts the estimated flow rates for all other duty cycles in its model. This ensures precise water application across the entire field without needing sensors everywhere.

  • Mermaid Diagram (Flowchart):

    flowchart TD
    A[Controller sets Nozzle_X Duty Cycle to 75%] --> B[Irrigator passes over Test Zone];
    C[IoT Soil Moisture Sensors in Test Zone] --> D{Measure ΔMoisture};
    D --> E[Calculate Verified Flow Rate (L/min)];
    F[Controller's Model] --> G{Get Estimated Flow Rate at 75% Duty Cycle};
    E & G --> H{Compare Verified vs. Estimated};
    H -- "Verified is 5% higher" --> I[Adjust Flow Rate Model for ALL duty cycles (1-100%)];
    I --> J[Use updated model for precise irrigation across entire field];

3.3. Consumer Electronics: Battery Discharge Curve Calibration

  • Enabling Description: This applies the concept to the "time remaining" estimate for a smartphone battery. The "step rate" is the device's current power draw (in mA). The operating system contains a generic "estimated runtime" model ("estimated stride length") per mA of draw, based on the battery's chemistry and design capacity. To perform a verification, when the battery level crosses a specific threshold (e.g., from 20% to 19%), the device records the actual time elapsed and the average power draw during that period. This provides a "verified runtime" at that specific power draw. If the verified runtime was 10% shorter than the model's estimate (indicating accelerated battery aging), the OS adjusts the entire discharge curve, reducing the estimated runtime for all other power draw levels. This provides a more accurate "time remaining" prediction that adapts to the battery's real-world health.

  • Mermaid Diagram (State Diagram):

    stateDiagram-v2
    state "Battery > 20%" as S1
    state "Discharging 20% -> 19%" as S2
    state "Battery < 19%" as S3

    [*] --> S1
    S1 --> S2: Level drops to 20%
    S2 --> S3: Level drops to 19%
    S3 --> [*]

    state S2 {
        note right of S2
            System records:
            1. Start Time (at 20.0%)
            2. End Time (at 19.0%)
            3. Average Power Draw (mA)
            Calculates: Verified Runtime for that Power Draw
            Compares: Verified vs. Estimated Runtime
            Adjusts: Entire Battery Discharge Model
        end note
    }

4. Derivative Implementations: Integration with Emerging Tech

4.1. AI/ML-Driven Predictive Gait Modeling

  • Enabling Description: This variation replaces the linear/proportional adjustment algorithm with a lightweight, on-device machine learning model, such as a Bayesian regression model or a small neural network. The model's inputs are user parameters (height, weight, age) and step rate; the output is predicted stride length. Initially, it's trained on a generic dataset. When the device obtains a "verified stride length" from GPS, this new data point is not used for a simple proportional adjustment. Instead, it's used as a new training point to re-fit the entire regression curve. This allows the model to learn the specific, non-linear relationship of the user's personal gait (e.g., their stride length might increase rapidly at jogging paces but plateau at sprinting paces). Over time, the model becomes a highly personalized, predictive digital twin of the user's gait.

  • Mermaid Diagram (Class Diagram):

    classDiagram
    class WearableDevice {
        -accelerometer
        -gps
        -processor
        +determineStepRate()
        +getGPSLocation()
    }
    class GaitModel {
        -bayesianRegressionModel
        +predictStrideLength(stepRate)
        +updateModel(stepRate, verifiedStrideLength)
    }
    class Processor {
        -gaitModel
        +runCalibrationLoop()
    }
    WearableDevice *-- Processor
    Processor *-- GaitModel

4.2. IoT Smart Environment for Seamless Verification

  • Enabling Description: The wearable device operates within an IoT-enabled environment (e.g., a smart gym or smart home) equipped with UWB (Ultra-Wideband) anchors or a network of Bluetooth Low Energy (BLE) beacons. These anchors provide continuous, high-precision indoor location tracking, serving as the "GPS" for verification. The wearable device uses the MQTT protocol to broadcast its currently measured step rate to the local network. The environment's central server, which is tracking the user's location via UWB, calculates the verified stride length in real-time. It then sends an MQTT message back to the wearable with the verified data, which the device uses to update its internal stride length model. This creates a closed-loop system where calibration happens automatically and continuously whenever the user is in the smart environment.

  • Mermaid Diagram (Sequence Diagram):

    sequenceDiagram
    participant User
    participant Wearable
    participant MqttBroker as MQTT Broker
    participant UwbSystem as UWB System

    User->>Wearable: Begins walking
    Wearable->>MqttBroker: PUBLISH topic 'gait/steprate' payload '110'
    UwbSystem->>UwbSystem: Tracks User's high-precision location
    UwbSystem->>MqttBroker: PUBLISH topic 'gait/verified_sl' payload '0.78'
    MqttBroker-->>Wearable: RECEIVE topic 'gait/verified_sl'
    Wearable->>Wearable: Update stride length model with new data

5. Derivative Implementations: The "Inverse" or Failure Mode

5.1. Graceful Degradation using Magnetometer as Secondary Step Counter

  • Enabling Description: The system is designed for high-reliability applications. It incorporates a secondary, lower-power sensor, a magnetometer, in addition to the primary accelerometer. During normal operation, the accelerometer provides step data. If the processor detects that the accelerometer data has become erratic or flatlined (indicating failure), it automatically switches to a "degraded mode." In this mode, it uses the magnetometer to detect steps by measuring the regular magnetic field variations caused by the swinging of the user's arm. Because this method is less accurate, the calibration logic is modified: it ceases to update its stride length model and instead applies a "confidence interval" to all distance estimates. The user interface displays the distance with a "+/- X meters" error margin and an icon indicating the system is operating in a degraded state, ensuring the user is aware of the lower precision.

  • Mermaid Diagram (State Diagram):

    stateDiagram-v2
    [*] --> Nominal_Mode
    Nominal_Mode: Using Accelerometer for steps
    Nominal_Mode: GPS data updates SL model
    
    Nominal_Mode --> Degraded_Mode: Accelerometer Failure Detected
    Degraded_Mode: Using Magnetometer for steps
    Degraded_Mode: SL model is frozen (no updates)
    Degraded_Mode: Distance estimates include confidence interval
    
    Degraded_Mode --> Nominal_Mode: Accelerometer signal restored

6. Combination with Open-Source Standards

6.1. Combination with MQTT for IoT Interoperability

  • Scenario Description: A treadmill manufacturer and a wearable device manufacturer both implement the open-source MQTT protocol for device communication. The treadmill, which has a calibrated motor and belt sensor, knows the exact distance covered. It publishes this distance data to a local MQTT broker on the topic treadmill/distance. The user's wearable device, which is connected to the same Wi-Fi network, subscribes to this topic. As the user runs, the wearable calculates its own estimated distance based on its calibrated stride length model. Simultaneously, it receives the ground-truth distance from the treadmill via MQTT. This allows the wearable to perform a "verified stride length" calibration without using GPS, leveraging the open standard for interoperability between devices from different manufacturers.

6.2. Combination with Protocol Buffers for Standardized Data Exchange

  • Scenario Description: A cloud-based fitness platform uses Google's Protocol Buffers (Protobuf) as its open-source standard for all data exchange. The user's wearable device defines its gait data using a .proto file. This file specifies the exact format for the UserProfile message (height, weight, sex) and the StrideLengthTable message, which includes repeated fields for StepRateRange and StrideLengthValue. When the user syncs their device, this Protobuf message is serialized and sent to the cloud. The cloud service can then deserialize the data and use it for large-scale analytics, comparing the user's calibrated gait model with that of other anonymized users. This open standard ensures that the data structure is robust, efficient, and independent of the programming language used by the device or the server.

6.3. Combination with FIDO2 for Gait-Based Authentication

  • Scenario Description: The highly personalized stride-length-vs-step-rate model, once calibrated over several GPS-verified sessions, becomes a unique biometric signature of the user's gait. An application on the user's smartphone implements the open FIDO2/WebAuthn standard for passwordless authentication. To log in, the user is prompted to walk 20 paces. The phone's motion sensors capture the gait, and the app's internal logic compares the measured step-rate-to-stride-length relationship against the securely stored, calibrated model. If the pattern matches within a given tolerance, it serves as a successful authentication factor, proving both that it is a human walking and that it is the correct human. This combines the patented calibration method with an open authentication standard to create a new form of biometric security.

Generated 5/10/2026, 7:20:39 AM