Derivative works

Of course. As a Senior Patent Strategist and Research Engineer specializing in Defensive Publishing, here is a comprehensive "Defensive Disclosure" document derived from the core claims of US patent 12,395,359. Today's date is April 26, 2026.

---

Defensive Disclosure and Prior Art Derivations for Physically Unclonable Function (PUF) Repair Mechanisms

Publication Date: April 26, 2026

Abstract: The following disclosures describe methods, systems, and applications related to the in-field detection, correction, and lifecycle management of errors in Physically Unclonable Functions (PUFs). These disclosures expand upon the concept of replacing faulty PUF response bits with pre-qualified, reliable spare bits by introducing alternative components, operational parameters, cross-domain applications, integration with emerging technologies, and defined failure modes. The intent of this document is to place these derivative concepts into the public domain, thereby establishing them as prior art.

1. Material & Component Substitution

1.1. Volatile Ferroelectric RAM (FeRAM) PUF with In-Situ Repair

• Enabling Description: A PUF is constructed from an array of Ferroelectric RAM (FeRAM) cells, operated below their data retention voltage to induce stochastic, unstable polarization states upon power-up. The remnant polarization of each cell is measured and digitized to form the PUF response. A subset of cells, characterized at manufacture as having high polarization stability, are reserved as "additional output bits." The "repair list" mapping erroneous bits to these stable replacements is stored in a separate, dedicated array of one-time programmable (OTP) anti-fuses. Upon detecting a hash mismatch of the PUF response, the system identifies the faulty FeRAM cell and blows the corresponding anti-fuse to permanently remap the address logic, redirecting the read request for the faulty cell's address to the address of the stable replacement cell.

graph TD
    A[Power On] --> B{Challenge PUF};
    B --> C[Read FeRAM Array at Stochastic Threshold];
    C --> D[Generate PUF Response];
    D --> E{Compute Hash(Response)};
    E --> F{Compare Hash vs. Stored Reference};
    F -- Mismatch --> G[Initiate Repair Sequence];
    G --> H[Identify Erroneous Bit Index 'i'];
    H --> I[Select Stable Replacement Bit Index 'j'];
    I --> J[Program Anti-Fuse with Mapping i->j];
    J --> K[Remap Address Logic];
    F -- Match --> L[Output Corrected PUF Response];
    K --> B;

1.2. Photonic Integrated Circuit (PIC) PUF with Optical Switch Repair

• Enabling Description: The PUF is instantiated on a Photonic Integrated Circuit (PIC), where the unique response is derived from minute variations in the path length and refractive index of a grid of interconnected Mach-Zehnder interferometers (MZIs). The response bit is a '1' or '0' based on constructive or destructive interference at a photodetector. A pool of redundant MZIs serves as the additional output bits. The repair list is implemented using a bank of non-volatile micro-electromechanical system (MEMS) optical switches. When an MZI path is determined to be faulty (e.g., due to thermal stress or material degradation), the system actuates the corresponding MEMS switch to optically bypass the faulty MZI and route the input light signal to a pre-selected, stable replacement MZI, thereby correcting the PUF response bit.

sequenceDiagram
    participant Controller
    participant InputLaser
    participant MZI_Grid
    participant MEMS_Switch_Bank
    participant Photodetector
    Controller->>InputLaser: Activate with Challenge;
    InputLaser->>MZI_Grid: Propagate Light;
    MZI_Grid->>Photodetector: Generate Optical Response;
    Photodetector->>Controller: Digitize Response & Detect Error;
    Controller->>MEMS_Switch_Bank: Actuate Switch for Faulty Path 'i';
    MEMS_Switch_Bank-->>MZI_Grid: Reroute light to replacement MZI 'j';
    Note right of MEMS_Switch_Bank: Path 'i' bypassed, Path 'j' engaged
    Controller->>InputLaser: Re-challenge PUF;
    InputLaser->>MZI_Grid: Propagate Light via new path;
    MZI_Grid->>Photodetector: Generate Corrected Response;
    Photodetector->>Controller: Verify Corrected Response;

2. Operational Parameter Expansion

2.1. Cryogenic Superconducting PUF for High-Fidelity Qubit Initialization

• Enabling Description: A PUF is implemented using an array of superconducting Josephson junctions operated at cryogenic temperatures (e.g., < 1 Kelvin). The PUF response is derived from quantum tunneling variations inherent in each junction. This PUF is used to generate unique, repeatable initialization vectors for qubits in a quantum computer, ensuring a consistent startup state. Due to the extreme sensitivity to magnetic fields and thermal cycling, individual junctions may become unstable. The repair mechanism operates at this cryogenic temperature, using a reference hash stored in a hardened NVM. Erroneous bits are identified, and a new mapping is written to a superconducting memory array (e.g., based on persistent current loops), which controls a multiplexer to select outputs from a pool of spare, stable Josephson junctions. This ensures the qubit initialization vector remains constant across thermal cycles.

stateDiagram-v2
    [*] --> Idle
    Idle --> Generating_Response: onChallenge()
    Generating_Response --> Checking_Hash: responseGenerated()
    state Checking_Hash {
        [*] --> Comparing
        Comparing --> Success: hashMatch()
        Comparing --> Failure: hashMismatch()
    }
    Success --> Idle
    Failure --> Repairing
    Repairing --> Idle: repairComplete()

2.2. High-Radiation Environment PUF with Parity-Based Bit Grouping

• Enabling Description: In a high-radiation environment such as deep space, single-event upsets (SEUs) can cause transient bit flips. The PUF repair mechanism is adapted for this by grouping response bits into small blocks (e.g., 8 bits) and storing a parity bit for each block. An SEU is detected when a parity check fails. To locate the erroneous bit, the system re-reads the PUF primitives for only the 8 bits in the affected block, which is faster than a full brute-force search. The repair mechanism replaces the unstable bit with a radiation-hardened memory cell that is pre-programmed with the correct value. The pool of "additional output bits" is a bank of such rad-hard cells. This provides rapid correction for transient errors while also allowing for permanent repair of bits damaged by total ionizing dose (TID) effects.

graph TD
    subgraph PUF Core
        direction LR
        Bits1_8 --- P1(Parity Bit 1)
        Bits9_16 --- P2(Parity Bit 2)
    end
    A[Generate Full Response] --> B{Check Parity};
    B -- All OK --> C[Output Response];
    B -- Parity Error in Block 'n' --> D{Initiate Localized Repair};
    D --> E[Re-read PUF Primitives for Block 'n'];
    E --> F[Identify Unstable Bit 'i' in Block 'n'];
    F --> G[Map 'i' to Rad-Hard Cell 'j'];
    G --> H[Update Repair List];
    H --> A;

3. Cross-Domain Application

3.1. Aerospace: Satellite Component Authentication

• Enabling Description: A satellite's Field-Programmable Gate Array (FPGA) is equipped with a self-repairing PUF. The PUF response acts as a unique identifier to authenticate commands from ground control, preventing spoofing. Over the mission's lifetime, radiation damage can degrade the FPGA fabric, causing PUF bits to become unstable. The satellite's flight computer periodically challenges the PUF and verifies its response against a stored hash. If an error is detected, the repair mechanism is triggered. It finds a spare, shielded block of logic cells on the FPGA to generate a replacement bit and updates a "repair list" stored in radiation-hardened EEPROM. This ensures the satellite maintains its ability to authenticate commands for its entire 15-year operational lifespan.

sequenceDiagram
    participant GroundControl
    participant SatelliteFPGA
    participant FlightComputer
    GroundControl->>SatelliteFPGA: Send Authenticated Command;
    SatelliteFPGA->>FlightComputer: Request PUF for Auth;
    FlightComputer->>SatelliteFPGA: Challenge PUF;
    SatelliteFPGA->>FlightComputer: Provide PUF Response;
    FlightComputer->>FlightComputer: Detect Error in Response;
    FlightComputer->>SatelliteFPGA: Initiate Repair(err_bit, spare_bit);
    SatelliteFPGA->>SatelliteFPGA: Reconfigure FPGA routing;
    FlightComputer->>SatelliteFPGA: Re-Challenge PUF;
    SatelliteFPGA->>FlightComputer: Provide Corrected Response;
    FlightComputer->>SatelliteFPGA: Authenticate and Execute Command;

3.2. AgTech: Secure Soil Sensor Network Integrity

• Enabling Description: A large-scale wireless network of soil moisture sensors uses a PUF in each sensor node to secure communications and prove the sensor's identity, preventing data injection attacks. The sensors are exposed to harsh environmental conditions (moisture, temperature swings, fertilizer corrosion) which cause silicon aging and PUF instability. A central gateway periodically sends a global challenge. Each sensor node checks its PUF response. If a node detects an error, it uses a spare set of ring oscillators as "additional output bits" to repair its response. It then reports the repair event (with the index of the failed and replacement bits) to the gateway. The gateway maintains a health record for each sensor, allowing the farm operator to preemptively replace sensors that have exhausted their repair capacity.

graph TD
    A(Gateway) -- Global Challenge --> B((Sensor 1));
    A -- Global Challenge --> C((Sensor 2));
    A -- Global Challenge --> D((Sensor N));
    subgraph Sensor 2
        C1[Generate PUF Response] --> C2{Check Hash};
        C2 -- Mismatch --> C3[Repair with Spare RO];
        C3 --> C4[Store New Mapping];
        C4 -- Repair Event Log --> A;
        C2 -- Match --> C5[Transmit Data];
    end
    C5 -- Sensor Data --> A;

3.3. Medical Devices: Implantable Pacemaker Firmware Validation

• Enabling Description: An implantable pacemaker uses a PUF-derived key to decrypt and authenticate firmware updates transmitted wirelessly. This prevents malicious updates. The device's silicon ages over many years in the body. To ensure the PUF remains stable, the pacemaker's controller, during its daily self-check, generates the PUF response and verifies it. If an error is detected, it identifies the failing bit and replaces it with an output from a set of "additional bits" that were characterized and selected at the time of manufacture for their exceptional stability and low drift over time. The "repair list" is stored in a small, low-power e-fuse array. This ensures the device can always authenticate critical firmware updates, even after a decade of operation.

sequenceDiagram
    participant Programmer
    participant Pacemaker
    loop Daily Self-Check
        Pacemaker->>Pacemaker: Generate PUF and Check for Errors
    end
    Programmer->>Pacemaker: Transmit Encrypted Firmware Update
    Pacemaker->>Pacemaker: Generate PUF Response (with repairs applied)
    Pacemaker->>Pacemaker: Derive Key from PUF Response
    Pacemaker->>Pacemaker: Decrypt and Authenticate Firmware
    alt Authentication OK
        Pacemaker->>Pacemaker: Apply Update
    else Authentication Fails
        Pacemaker->>Pacemaker: Discard Update & Log Event
    end

4. Integration with Emerging Tech

4.1. AI-Driven Predictive PUF Failure Analysis

• Enabling Description: The PUF controller integrates a lightweight, on-chip neural network (NN). Instead of only measuring the digital '0' or '1' output, the controller samples the analog properties of each PUF primitive (e.g., ring oscillator frequency, SRAM cell startup voltage). These analog readings are fed into the NN, which has been trained to recognize subtle signatures of component degradation that precede a catastrophic bit flip. When the NN flags a bit with a high probability of future failure, the system preemptively remaps this "at-risk" bit to a stable additional bit before it can cause an error. This proactive repair minimizes downtime and increases overall system reliability.

graph TD
    A[Challenge PUF] --> B[Sample Analog Values from Primitives];
    B --> C[Digitize to create PUF Response];
    B --> D[Feed Analog Values into On-Chip NN];
    C --> E{Check Hash of Response};
    D --> F{NN Predicts Impending Failure?};
    F -- Yes, for Bit 'i' --> G[Proactive Repair];
    G --> H[Remap Bit 'i' to Spare Bit 'j'];
    H --> I[Update Repair List];
    E -- Error Detected --> J[Reactive Repair];
    J --> H;

4.2. IoT Fleet Management with Centralized PUF Repair Auditing

• Enabling Description: A fleet of IoT devices, each with a self-repairing PUF, connects to a cloud management platform. Each time a device performs an internal PUF repair, it sends a signed message to the platform containing its unique ID, the index of the failed bit, the index of the replacement bit, and a timestamp. The platform maintains a health database for the entire fleet. An administrator can monitor the rate of PUF degradation across the fleet, identify batches of devices with premature failures (indicating a manufacturing defect), and remotely issue a command to decommission devices that have exhausted their pool of spare bits.

erDiagram
    IoT_FLEET ||--o{ IoT_DEVICE : contains
    IoT_DEVICE {
        string deviceId PK
        string pufStatus
    }
    IoT_DEVICE ||--|{ REPAIR_EVENT : logs
    REPAIR_EVENT {
        int eventId PK
        string deviceId FK
        int failedBitIndex
        int replacementBitIndex
        timestamp eventTime
    }

4.3. Blockchain-Based Verifiable Device Lifecycle Log

• Enabling Description: The electronic device contains a hardware wallet module. Each time a PUF repair operation occurs, the device's processor creates a log entry detailing the repair. This log entry is signed using the private key derived from the PUF itself and is then committed as a transaction to a permissioned blockchain. This creates an immutable, auditable, and verifiable record of the device's physical health and maintenance history over its entire lifecycle. This is valuable for high-value assets where proving that the device has not been tampered with and is still operating on its original hardware is critical for resale or regulatory compliance.

sequenceDiagram
    participant DevicePUF
    participant DeviceProcessor
    participant HardwareWallet
    participant Blockchain
    DeviceProcessor->>DevicePUF: PUF Repair Occurs (bit 'i' -> 'j');
    DeviceProcessor->>DeviceProcessor: Create Repair Log {device_id, i, j, timestamp};
    DeviceProcessor->>HardwareWallet: Sign(Repair Log) using PUF-Key;
    HardwareWallet-->>DeviceProcessor: signedLog;
    DeviceProcessor->>Blockchain: Commit Transaction(signedLog);
    Blockchain->>Blockchain: Add to Immutable Ledger;

5. The "Inverse" or Failure Mode

5.1. Graceful Degradation Mode Upon Repair Exhaustion

• Enabling Description: The device maintains a counter for the number of available "additional output bits." When a repair is needed but the counter is zero, the device enters a "graceful degradation" mode. In this mode, it flags its own PUF response as "unreliable." For cryptographic operations, it will now require an additional factor of authentication (e.g., user PIN, or a secondary key from a server) to be combined with its unreliable PUF response before proceeding. The device may also reduce its functionality, for example, by disabling non-essential high-security transactions while still allowing basic operations.

stateDiagram-v2
    state "Fully Functional" as F {
        [*] --> Normal
        Normal --> Repairing: error detected AND spares > 0
        Repairing --> Normal: repair complete
    }
    F --> Degraded: error detected AND spares == 0
    Degraded --> Decommissioned: critical failure
    Degraded: PUF output flagged as unreliable
    Degraded: Requires 2nd factor authentication

5.2. Secure "Bricking" on Detection of Coordinated Attack

• Enabling Description: The PUF repair mechanism monitors the spatial and temporal distribution of bit failures. A single, random bit failure is treated as natural aging. However, if the system detects multiple, simultaneous failures in physically adjacent PUF primitives, or a number of failures exceeding a predefined threshold within a short time window (e.g., >5 bit errors in <1 millisecond), it interprets this as a sophisticated physical attack (e.g., laser fault injection, EM glitching). Upon such a detection, the device's security policy triggers a "bricking" procedure, where it deliberately shorts a critical power rail via an internal fuse or permanently wipes the NVM containing the reference hash and repair list, rendering itself permanently inoperable and protecting its secrets.

graph TD
    A{Error Detected} --> B{How many bits?};
    B -- One --> C[Normal Repair];
    B -- Many --> D{Are they physically adjacent?};
    D -- No --> C;
    D -- Yes --> E[Trigger Secure Bricking];
    E --> F[Wipe Keys & Reference Hash];
    F --> G[Permanently Disable Device];

6. Combination Prior Art with Open-Source Standards

6.1. RISC-V Custom ISA Extension for PUF Repair

• Enabling Description: A RISC-V processor core is modified with a custom instruction set architecture (ISA) extension for hardened, accelerated PUF management. The new instructions include:
  • puf.gen rd, rs1: Challenges the PUF using a challenge value in register rs1 and places the response address in rd.
  • puf.check rs1: Performs a hardware-accelerated hash and comparison of the PUF response at address rs1. Sets a status flag on mismatch.
  • puf.repair: A privileged instruction that, upon a hash mismatch, automatically initiates the hardware-based brute-force search (in either a predetermined or random order, based on a control register setting) for the faulty bit, identifies a spare bit, and updates the repair list in a protected memory region, all without intervention from the main operating system.

6.2. FIDO2 Authenticator with Self-Healing Private Key Source

• Enabling Description: A FIDO2/WebAuthn compliant security key uses the self-repairing PUF as the ultimate source of entropy for generating its private keys. The PUF response is not the key itself but is used to seed a key derivation function (KDF). The device stores the "helper data" (the reference hash for the PUF response) in its flash memory. Each time an authentication ceremony is requested, the device first generates and verifies its PUF response. If a repair is necessary, it performs it transparently. This ensures that the same stable PUF response is always fed to the KDF, guaranteeing that the derived private key remains constant throughout the life of the authenticator, even as the underlying silicon ages.

6.3. TPM Integration with Verifiable Repair Logging

• Enabling Description: A Trusted Platform Module (TPM) 2.0 device integrates the self-repairing PUF as its Endorsement Key (EK) source. The EK is fundamental to the TPM's identity. The reference hash for the PUF is stored in the TPM's shielded non-volatile memory. Each time a PUF repair is performed, the details of the repair (failed bit index, new bit index, timestamp) are "extended" into a dedicated Platform Configuration Register (PCR). This means a hash of the repair event log is chained with the existing value in the PCR. A remote challenger can then perform an attestation ceremony where the TPM quotes its PCR values. By inspecting the value of the PUF repair PCR, the challenger can verify the integrity of the TPM's hardware and know exactly how many repairs have occurred in its lifetime.