US 12395359

An analysis of United States Patent 12,395,359 reveals the following details. A search of the United States Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 found no public record of this patent.

Summary of U.S. Patent 12,395,359

Title: Method of implementing a physical unclonable function

Assignee: Thales DIS France SA. The assignment history also includes Thales DIS Design Services SAS.

Inventors:

• Benjamin Duval
• Alexandre Berzati
• Olivier Fourquin

Filing Date: September 17, 2021

Issue Date: August 19, 2025

Abstract: The patent describes a method and an electronic device for repairing the output of a Physical Unclonable Function (PUF). A PUF generates a unique digital response from the physical characteristics of a device. The invention provides a way to detect errors in this response, identify the specific faulty bits, and replace them with pre-selected, reliable "additional output bits." The process involves creating and storing a "repair list" that maps the erroneous bits to their replacements, ensuring the PUF's response remains correct and stable over time.

Plain-Language Overview of Independent Claims

The patent includes four independent claims which define the core of the invention.

Independent Claim 1: This claim outlines a method for repairing the digital "fingerprint" (response) from a PUF. The steps are:

1. Generate the PUF's response.
2. Detect if there is an error in the response.
3. Pinpoint the exact incorrect bit(s) by systematically replacing each bit in the response, one by one in a random order, with a test value until the error is corrected.
4. Find a reliable, spare "additional output bit" that can serve as a permanent replacement.
5. Store the location of the bad bit and its corresponding good replacement bit in a "repair list."
6. Finally, replace the erroneous bit in the PUF's response with the good bit from the repair list.

Independent Claim 6: This claim describes a method almost identical to the one in Claim 1, with one key difference. When determining which response bits are erroneous (step 3), the one-by-one replacement of each bit is done in a predetermined order, rather than a random one.

Independent Claim 12: This claim describes the physical electronic device that performs the method detailed in Claim 1. The device is equipped with the necessary components, including:

• Active electronic primitives (the basis for the PUF).
• PUF circuits to generate the response.
• A processor and memory.
  The device is configured to execute all the steps of the repair method, including the search for erroneous bits in a random order.

Independent Claim 14: This claim also describes an electronic device, but one that is configured to perform the method outlined in Claim 6. It comprises the same types of hardware as the device in Claim 12. The distinguishing feature is that this device is configured to identify the faulty PUF bits by replacing them one-by-one in a predetermined order.

Litigation Search

As of May 8, 2026, a thorough search of patent litigation databases, including PACER, Unified Patents, and the dockets of the U.S. Court of Appeals for the Federal Circuit, reveals no known litigation involving US patent 12,395,359.

Proceedings overview

As of May 29, 2026, there is one active Post-Grant Review (PGR) proceeding, PGR2026-00045, on file for US Patent 12,395,359. This proceeding is currently in the preliminary phase, with no institution decision yet rendered. Therefore, no claims have been invalidated or sustained by the PTAB at this time. This gives a defendant facing assertion of this patent an opportunity to monitor the ongoing challenge and potentially leverage its outcome, but the patent's claims remain presumptively valid.

PGR2026-00045 — Okta, Inc. et al. v. Thales DIS France SA

• Type: Post-Grant Review (PGR)
• Filed: 2026-05-07
• Status: Pending. The proceeding is in the preliminary stage, awaiting a decision on institution.
• Judge panel: Information regarding the assigned judge panel is not publicly available in immediate search results for this recently filed case.
• Petition grounds: The detailed petition grounds, including which specific claims are challenged, the prior art asserted, and the statutory bases (§ 102 / § 103 / § 112), are typically contained within the petition document itself. As of today's date, this information is not readily summarized in public search results for this newly filed PGR.
• Institution decision: Not yet issued. The PTAB has a statutory deadline of six months from the petition's filing date (approximately November 7, 2026) to decide whether to institute the PGR.
• Final Written Decision: Not applicable. No Final Written Decision has been issued as the case is in its early stages.
• Settlement / termination: Not applicable. The case is still active and has not been settled or terminated.
• Appeal: Not applicable. There has been no Final Written Decision to appeal.
• Defensive value: This active PGR indicates that the patent's claims are currently under examination by the PTAB. If Okta, Inc. et al. are successful in instituting the PGR, and subsequently in invalidating claims, it could significantly weaken the patent owner's position. Conversely, if institution is denied or claims are sustained, it would strengthen the patent. Defendants should closely monitor this proceeding for its potential impact.

Strategic summary

Currently, all claims (1-14) of US 12,395,359 are UNTESTED by a final PTAB decision, as the single pending PGR, PGR2026-00045, is in its very early stages. No claims have been canceled or sustained by the PTAB. The patent has not been narrowed through any AIA trial, and its full scope remains intact.

Regarding the estoppel landscape, since PGR2026-00045 has not yet reached an institution decision, no estoppel under § 315(e)(2) or § 325(e)(2) has attached to the petitioner (Okta, Inc. et al.) or its privies. All prior-art grounds, including those that may be raised in the pending PGR, are still theoretically available to other potential challengers or defendants. There are no clear pattern signals from this single, recent filing, such as multiple IPRs by the same petitioner or aggressive PTAB appeals by the patent owner. The patent owner, Thales, is a large operating company, which is common for patent prosecution but doesn't inherently signal NPE behavior in PTAB filings.

Recommended next steps

Since PGR2026-00045 is pending, any defendant facing assertion of US 12,395,359 should:

• Monitor the PTAB docket for PGR2026-00045 (USPTO E2E link: https://ptab.uspto.gov/#/proceeding/PGR2026-00045) closely, particularly for the institution decision, which is expected around November 7, 2026.
• Review the petition once it becomes fully public to understand the specific claims challenged and the prior art asserted by Okta, Inc. et al. This information will be crucial for assessing the strength of the challenge.
• Evaluate whether the grounds raised in PGR2026-00045 are relevant to any infringement theories being asserted.

Inventors

• Benjamin Duval
• Alexandre Berzati
• Olivier Fourquin

All three inventors are listed on the patent application with an affiliation to the original assignee, Thales. The assignment records show they assigned their interests to Thales entities. There are no indications of unusual employment patterns, such as a mass departure after filing.

Original assignee

The original assignee of record is Thales DIS France SAS.

Thales is a large, publicly-traded French multinational corporation that designs and builds electrical systems and provides services for the aerospace, defense, transportation, and security markets. As a major provider of secure microelectronics, including smart cards and embedded secure elements for devices, Thales develops and ships products that would directly embody the patented technology for Physical Unclonable Functions (PUFs). Thales is a major operating company and is currently active.

Assignment timeline

A search of the USPTO Patent Assignment database and the patent's legal event history reveals the following transfers, all of which appear to be internal reorganizations or record clarifications within the Thales corporate family.

• 2023-03-06 (executed) / recorded 2023-07-28 — Reel 064414/0237

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Benjamin Duval, Alexandre Berzati, Olivier Fourquin (Inventors)
  • Assignee: Thales DIS Design Services SAS
  • Correspondent: Information not available in provided source documents.
  • Context: Initial assignment of invention from the inventors to their employing Thales entity.

• 2021-06-29 (executed) / recorded 2023-12-13 — Reel 065853/0852

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Thales DIS Design Services SAS
  • Assignee: Thales DIS France SA
  • Correspondent: Information not available in provided source documents.
  • Context: Internal transfer between two related Thales corporate entities as part of a reorganization. Note the execution date precedes the application filing date, suggesting it may cover future inventions.

• 2025-07-24 (executed) / recorded 2025-07-28 — Reel 071845/0858

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Benjamin Duval, Alexandre Berzati, Olivier Fourquin (Inventors)
  • Assignee: Thales DIS France SAS
  • Correspondent: Information not available in provided source documents.
  • Context: A confirmatory assignment recorded shortly before the patent's issuance, likely to clean up the chain of title and explicitly confirm ownership with the specific original assignee entity.

Timeline diagram

timeline
    title Ownership of US 12395359
    2020 : Priority application filed in Europe
    2021 : US application filed by Thales
    2023 : Inventors assign rights to Thales
         : Thales internal entity transfer
    2025 : Confirmatory assignment recorded
         : Patent Issued to Thales DIS France

NPE / troll-pattern signals

1. Shell-entity transfer: Not present. All assignees (Thales DIS Design Services SAS, Thales DIS France SA, Thales DIS France SAS) are operating entities within the Thales Group, a major multinational technology company.

2. Known asserter in the chain: Not present. Thales is a well-known operating company and is not listed as an NPE or patent asserter by RPX, Unified Patents, or other tracking services.

3. Repeat correspondent across the chain: Unclear. The correspondent information for the recorded assignments is not available in the provided source documentation.

4. Cascading transfers: Not present. The transfers are between related corporate entities for apparent organizational purposes, not a rapid chain of transfers between unrelated LLCs.

5. Pre-litigation transfer: Not present. There is no record of litigation involving this patent.

6. Bankruptcy fire-sale: Not present. The assignor, Thales, is a large, solvent operating company.

7. Privateering: Not present. The patent has not been transferred to a third-party NPE to be asserted on Thales's behalf. It remains within the Thales corporate family.

8. Defensive aggregator (anti-NPE): Not present. The chain does not terminate at a known defensive aggregator like RPX or LOT Network. The patent is still held by its originating operating company.

Verdict

Insufficient data

The assignment history clearly shows the patent has remained within the Thales corporate family, a major operating company that develops and sells products in this technology area. This strongly indicates the absence of any NPE or patent troll activity.

However, based on the strict verdict categories provided, the data is insufficient to make a definitive selection. The patent is not being asserted, which rules out "Operating-company assertion" as defined. It has not been transferred to a formal defensive aggregator, which rules out "Defensive / non-asserting" as defined. As the evidence does not meet the specific criteria for any of the other categories, this verdict is the most accurate based on the available information and rigid definitions.

Verification Link: USPTO Patent Assignment Search for US 12395359

Prior Art Analysis

Based on the citations listed in the patent documentation for US 12,395,359, the following prior art references are most relevant to the claims of the patent. The analysis focuses on the potential for these references to anticipate the independent claims (1, 6, 12, and 14) under 35 U.S.C. § 102. Anticipation requires that a single prior art reference discloses every element of a claim.

---

US20150092939A1

• Full Citation: US Patent Application Publication No. 2015/0092939 A1, "Dark bits to reduce physically unclonable function error rates," published April 2, 2015. Filed September 27, 2013.
• Brief Description: This reference describes a method for improving the reliability of a PUF by identifying and excluding unstable bits, referred to as "dark bits." During an enrollment phase, the PUF is read multiple times to identify bits that are not repeatable. The locations of these dark bits are stored. In subsequent operations, these dark bits are masked or ignored, and are not used in the final PUF response. The system may also use error correction codes on the remaining, more stable bits.
• Potential Anticipation: This reference does not appear to fully anticipate the claims of US 12,395,359. While it teaches identifying unreliable bits ("dark bits") and storing their locations (similar to a "repair list"), its primary method is to exclude these bits from the response, not replace them with other, reliable "additional output bits" from the PUF as claimed in patent '359. The core inventive step of '359 is the active substitution of erroneous bits with pre-selected, reliable spare bits. US '939 focuses on masking and exclusion. Therefore, it lacks the "determining a match" (S4) and "replacing... with the matching additional output bits" (S6) steps central to all independent claims of patent '359.

---

US20170149572A1

• Full Citation: US Patent Application Publication No. 2017/0149572 A1, "Authenticatable device with reconfigurable physical unclonable functions," published May 25, 2017. Filed May 5, 2014. Assignee: Analog Devices, Inc.
• Brief Description: This publication discloses a reconfigurable PUF where the specific set of components (e.g., memory cells) used to generate the PUF response can be changed. If a portion of the PUF becomes unreliable or is compromised, the system can select a different set of components to generate a new PUF response. The device can store multiple "helper data" sets corresponding to different configurations, allowing it to adapt to failures or attacks.
• Potential Anticipation: This reference comes closer but likely does not anticipate. It teaches reconfiguring the PUF to avoid unreliable bits, which is conceptually similar to replacement. However, it appears to describe switching to entirely new sets of bits rather than performing a one-to-one replacement of specific erroneous bits with specific "additional output bits" to correct an error while maintaining the original response value. The claims of '359 focus on repairing a specific PUF response to its original, correct state by swapping in a replacement bit that provides the correct value. US '572 seems to generate a new, different response from a different PUF configuration. It lacks the precise steps of detecting an error in a generated response, finding the specific bit(s) at fault, and finding a matching additional bit to restore the original response.

---

US20190065734A1

• Full Citation: US Patent Application Publication No. 2019/0065734 A1, "Error correction circuit for physical unclonable function (puf) circuit," published February 28, 2019. Filed August 28, 2017. Assignee: NXP B.V.
• Brief Description: This reference describes an error correction circuit for a PUF. It stores "helper data" that contains syndrome information derived from an error correcting code (ECC) like a Hamming code. When a PUF response is generated, the circuit calculates a new syndrome and compares it to the stored syndrome. The result of this comparison directly identifies the location (index) of any single-bit error. The circuit then corrects the error by flipping the identified erroneous bit.
• Potential Anticipation: This reference does not anticipate the claims of US 12,395,359. Its method of correction is to simply flip the value of the erroneous bit (e.g., 0 to 1). It does not teach replacing the faulty response bit with a different, more stable "additional output bit" from the PUF. The inventive step of patent '359 is the permanent substitution of the source of the bit, not just the temporary correction of its value. US '734 does not disclose a "repair list" of matched pairs or the use of spare, reliable bits as permanent replacements.

---

US9703989B1

• Full Citation: US Patent 9,703,989 B1, "Secure physically unclonable function (PUF) error correction," issued July 11, 2017. Filed December 23, 2014. Assignee: Altera Corporation.
• Brief Description: This patent details a method for improving PUF stability by identifying unreliable bits during an enrollment phase. The system stores the indices of these unreliable bits. During operation, if the PUF response has errors, error correction codes are first used to fix a certain number of errors. If errors remain, the system can use the stored indices to mask the unreliable bits before a final authentication or key generation step.
• Potential Anticipation: Similar to US '939, this reference focuses on identifying and then masking or ignoring unreliable bits rather than replacing them. It does not teach the key steps of claim 1: "determining a match... between each determined erroneous response bit and a selected additional output bit" and "replacing... said erroneous response bits with the matching additional output bits." The method in US '989 is one of exclusion and ECC, not substitution with spare, reliable PUF outputs. Thus, it does not anticipate the independent claims of US 12,395,359.

Obviousness Analysis (35 U.S.C. § 103)

An invention is considered obvious if the differences between the claimed invention and the prior art are such that the invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). This analysis considers combinations of prior art references to determine if they would have collectively suggested the claimed invention.

The independent claims (1, 6, 12, and 14) of US patent 12,395,359 are likely obvious in view of a combination of prior art references, primarily US 2019/0065734 A1 ('734), US 2015/0092939 A1 ('939), and US 2017/0149572 A1 ('572).

Primary Combination of References

• US '734 teaches a method for in-field error detection and correction for a PUF. It uses an Error Correcting Code (ECC) to generate a syndrome that directly identifies the index of a single-bit error in the PUF response. It then corrects the error by flipping the value of the identified bit. This reference establishes the state of the art for detecting an error (Claim 1, step S2) and identifying the specific erroneous bit (part of step S3).

• US '939 teaches a method to improve PUF reliability by identifying unstable or "dark bits" during an enrollment phase. It introduces the key concept of classifying PUF bits into two categories: reliable bits suitable for the final response, and unreliable bits that should be excluded. The reliable bits not chosen for the initial response constitute a pool of "additional output bits" as described in patent '359. The reference also teaches storing the locations of these unreliable bits.

• US '572 teaches a reconfigurable PUF, where the set of physical components used to generate the response can be changed if a portion becomes unreliable or is compromised. This introduces the concept of adapting to component failure by substituting a new set of components for the old ones.

Motivation to Combine and Reasoning

A person having ordinary skill in the art, facing the problem of PUF instability, would have been motivated to combine the teachings of these references to arrive at the invention claimed in US 12,395,359.

1. Problem with US '734: The solution in US '734 is temporary. It corrects a bit's value by flipping it but does nothing to address the underlying physical instability of the component generating that bit. A PHOSITA would recognize that an unstable bit is likely to produce errors again, requiring repeated correction and representing a persistent point of failure.

2. Solution Offered by US '939 and US '572: A PHOSITA would look for a more permanent solution. US '939 provides the necessary building blocks: it teaches that not all bits are equal and that a pool of stable, reliable "additional output bits" exists. US '572 provides the conceptual framework for dealing with faulty PUF components: reconfiguring the circuit to use different, functional components.

3. The Obvious Combination: The motivation is to create a more robust and permanent repair mechanism than the simple bit-flipping in '734. A PHOSITA would naturally combine these concepts:

   • Use the error detection and location method from US '734 to identify a faulty bit in the field (e.g., bit i is erroneous).
   • Instead of just flipping the value of bit i, the PHOSITA would recognize from US '939 that this bit is likely inherently unstable.
   • Drawing on the teaching of US '939, the PHOSITA knows a pool of stable, unused "additional output bits" is available.
   • Applying the reconfiguration principle from US '572 at a micro-level, the PHOSITA would be motivated to permanently replace the unstable bit i by re-mapping its output to be sourced from one of the known-stable additional bits.

This combination teaches all the core steps of the claims: detecting an error (from '734), identifying the erroneous bit (from '734), determining a match with a reliable additional output bit (the pool of which is taught by '939), storing this match in a "repair list" (a logical extension of storing the indices of "dark bits" in '939), and performing the replacement (a surgical application of the reconfiguration concept in '572).

Analysis of Specific Claim Limitations

• Determining Erroneous Bits (Step S3): Claims 1 and 6 specify a method of finding the erroneous bit by replacing each bit one-by-one and re-checking for error correction (e.g., via a hash). While US '734 teaches a more elegant ECC-based method, this "brute-force" search is an elementary and obvious alternative for debugging or error location, particularly if the error detection mechanism (like a hash) does not directly indicate the error's location.

  • Predetermined Order (Claims 6 & 14): A sequential search from the first bit to the last is the most straightforward and obvious way to implement a one-by-one search. Furthermore, US '939 teaches identifying the least reliable bits. A PHOSITA would be motivated to check these known-unreliable bits first to accelerate the search, making a predetermined (and optimized) order obvious.
  • Random Order (Claims 1 & 12): The patent itself explains the motivation for this: to prevent timing-based side-channel attacks. In the field of hardware security, randomizing the order of operations to obscure processing time is a well-known and standard technique. Therefore, applying this standard security practice to the bit-checking sequence would be an obvious design choice for a security-conscious PHOSITA.

• Device Claims (12 & 14): These claims recite an electronic device configured to perform the methods of claims 1 and 6, respectively. As the underlying methods are rendered obvious by the prior art combination, the claims for a device merely configured with a processor and memory to execute those obvious methods are also obvious.

Conclusion

The independent claims of US patent 12,395,359 appear to be obvious under 35 U.S.C. § 103. The combination of US '734, US '939, and US '572 teaches the core inventive concept of detecting an in-field PUF error and permanently repairing it by substituting the faulty bit with a pre-validated, reliable spare bit. The specific methods for locating the faulty bit (predetermined or random one-by-one search) represent obvious implementation choices for a person of ordinary skill in the art, driven by motivations of simplicity, efficiency, or security.

Based on the provided patent documentation for US 12,395,359, the following is a detailed analysis of its term, history, and related applications.

Patent Term and Expiration

• Filing Date: The application (US18/026,925) was filed on September 17, 2021.
• Nominal Expiration Date: A US patent typically expires 20 years from its earliest non-provisional US filing date. Therefore, the nominal expiration date for this patent would be September 17, 2041.
• Patent Term Adjustment (PTA): The patent data indicates an "Adjusted expiration" date of March 11, 2042. This shows that the patent has been granted a Patent Term Adjustment, likely to compensate for delays during its prosecution by the USPTO. The total adjustment extends the patent's life by approximately 176 days.
• Patent Term Extension (PTE): There is no information in the provided documentation to suggest that a Patent Term Extension (PTE) under 35 U.S.C. § 156 (e.g., for regulatory review delays) has been applied for or granted.
• Projected Expiration Date: The projected and official expiration date for US patent 12,395,359 is March 11, 2042.

Application History

• Continuation or Divisional Status: The provided documentation does not indicate that this patent is a continuation or a divisional of any prior US application. The "Family Applications" section lists only the application number (US18/026,925) that matured into this patent.

Patent Family and Priority

The patent is part of a larger international patent family, claiming priority to an earlier European application.

• Priority Application: The patent claims priority to European patent application EP20315413.3A, which was filed on September 18, 2020. This is the earliest priority date for the invention.
• International (PCT) Application: A subsequent international application was filed as PCT/EP2021/075725.
• Related Family Publications: Other members of this patent family, which share the same priority claim, include:
  • EP3972191A1
  • WO2022058567A1
  • EP4218198A1
  • US20230327891A1 (This is the US publication of the application before it was granted as patent '359).

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.