US 8904194

US Patent 8904194: Secure Data Parser Method and System

Title: Secure data parser method and system
Assignee: Security First Innovations LLC (Current), Security First Corp (Original)
Inventors: Rick L. Orsini, Mark S. O'Hare, Roger S. Davenport, Steven Winick
Filing Date: 2012-05-10
Issue Date: 2014-12-02
Abstract: A secure data parser method and system is provided for securing data from unauthorized access or use. The method and system provide for parsing, splitting and/or separating the data to be secured into two or more portions. The portions may be encrypted. The portions may be stored in one or more locations. The system also comprises a data splitting module, a cryptographic handling module, and, optionally, a data assembly module.

Plain-Language Overview of Independent Claims:

Independent Claim 1:
Claim 1 describes a method for securing data. It involves taking the data and parsing it into at least two separate portions. These portions are then encrypted, and the encrypted portions are stored in multiple, distinct data storage facilities. Crucially, each individual data storage facility only holds a portion of the encrypted data, and this single portion is insufficient on its own to reconstruct the original data. The method also includes reassembling these stored portions to recreate the original data when authorized access is granted.

Independent Claim 14:
Claim 14 outlines a system for securing data. This system comprises multiple, distinct data storage facilities, each equipped with a computer-accessible storage medium. These facilities are designed to store portions of data to be secured. The core of the system includes a data splitting module that divides the original data into at least two portions, encrypts them, and distributes them such that no single storage facility can reconstruct the original data. There is also a data assembly module that works to process and reassemble the portions from these storage facilities to recreate the original data. A cryptographic handling module is included to encrypt and decrypt the data. The system is configured so that when data is reconstituted for use by an authorized user, the original data only exists in a usable form within the cryptographic handling module, thus preventing its broader exposure.

Independent Claim 22:
Claim 22 describes a secure cryptographic system, potentially accessible remotely. It includes a depository system with at least one server configured to store private cryptographic keys and enrollment authentication data for multiple users. Each user is linked to one or more of these private keys. The system also has an authentication engine that compares a user's current authentication data with their stored enrollment data, producing an authentication result. Furthermore, a cryptographic engine, upon successful authentication, performs cryptographic functions for the user using their associated private keys, without ever releasing these private keys to the user. A transaction engine routes data between users, the depository system, and the authentication and cryptographic engines.

Independent Claim 30:
Claim 30 presents a method for facilitating cryptographic functions. It begins by associating a user with one or more private cryptographic keys stored securely on a server. The method then involves receiving authentication data from the user and verifying their identity by comparing it to corresponding stored authentication data. Finally, the system utilizes the associated private keys to perform cryptographic functions on behalf of the user, critically, without ever releasing these private keys to the user.

Independent Claim 38:
Claim 38 describes a system for secure authentication. This system features multiple authentication engines. Each engine receives enrollment authentication data to uniquely identify a user and current authentication data for comparison, subsequently determining an authentication result. A key component is a redundancy system that receives authentication results from at least two of these authentication engines and then determines, based on these multiple results, whether the user has been uniquely identified.

Independent Claim 46:
Claim 46 outlines a method for securely storing data, specifically authentication data, in geographically remote secure data storage facilities to protect against compromise of any single facility. The method involves receiving data at a trust engine, combining this data with a first random value to create a first combined value, and also combining the data with a second random value to create a second combined value. It then creates a first pairing of the first random value with the second combined value and a second pairing of the first random value with the second random value. One of these pairings is stored in a first computer-accessible storage medium, and the other pairing is stored in a second computer-accessible storage medium, which is located remotely from the first.

No information regarding US patent 8904194 was found in the CAFC 2026 dockets through the conducted search.

I'll research litigation involving US Patent 8904194, prioritizing litigation databases and court records.

Let me search for the specific district court cases and verify the patent numbers involved.

Let me verify the current status of the IBM case and check for any appeals or additional cases.

Litigation Involving U.S. Patent 8,904,194

Based on searches of litigation databases (Justia Dockets, UniCourt, CourtListener, RPX, Unified Patents portal, PTAB/IPR records, and the Federal Circuit docket), the following proceedings involve U.S. Patent No. 8,904,194 specifically. I have been careful to exclude cases involving only sibling patents in the same family.

---

1. District Court Litigation

Security First Innovations, LLC v. International Business Machines Corporation

• Court / Jurisdiction: U.S. District Court for the Eastern District of Virginia (Alexandria Division); E.D. Va.
• Case Number: 1:25-cv-00514
• Filed / Date: March 24, 2025
• Plaintiff: Security First Innovations, LLC ("SFI")
• Defendant: International Business Machines Corporation ("IBM")
• Patents-in-suit: U.S. Patent Nos. 8,271,802; 8,904,194 ('194 patent); and 9,135,456
• Accused products/technology: IBM's Cloud Object Storage system and related products (data parsing and encryption at rest).
• Current status: Open but STAYED. IBM filed (i) a motion to transfer the case to the Northern District of Illinois under 28 U.S.C. § 1404, (ii) a motion to dismiss the request for injunctive relief for failure to state a claim, and (iii) a motion for judicial notice (hearings noticed for July 11, 2025). The court subsequently stayed the case — a stay decision is recorded at ECF No. 88 (dated Aug. 20, 2025), and SFI's opposition to the stay is cited in the IPR record.
• Judge assignment (discrepancy noted): The Justia/UniCourt dockets list District Judge Claude M. Hilton (with Magistrate Judge William E. Fitzpatrick); one secondary source (RPX/Unified coverage) references Judge Anthony J. Trenga as the initial assignment. Treat the Hilton assignment as the more current docketed record, but note this inconsistency in the sources.
• Sources:
  • https://dockets.justia.com/docket/virginia/vaedce/1:2025cv00514/[570793](/patent/570793)
  • https://unicourt.com/case/pc-db5-casegubc0749f02d6f-[2063043](/patent/2063043)
  • https://portal.unifiedpatents.com/litigation/Virginia%20Eastern%20District%20Court/case/1%3A25-cv-00514

This is the only district court case that has asserted the '194 patent that the searches surfaced. SFI's earlier campaign, Security First Innovations, LLC v. Google LLC, No. 2:23-cv-00097 (E.D. Va.) (filed Mar. 10, 2023), asserted the '854, '609, '116, and '140 patents — not the '194 patent — so it should not be counted as '194 litigation, even though it is part of the same family-wide dispute.

---

2. PTAB Proceedings on the '194 Patent

International Business Machines Corporation v. Security First Innovations, LLC — IPR2025-01201

• Type: Inter Partes Review (post-grant AIA trial)
• Filed: July 9, 2025
• Patent challenged: U.S. Patent No. 8,904,194
• Petitioner: IBM; Patent Owner: Security First Innovations, LLC
• Outcome / Status: Institution DENIED (discretionary denial). Deputy Director Stewart denied institution. Public reporting (Lowenstein & Weatherwax, Nov. 21, 2025) confirms three companion non-institutions covering US 8,271,802; 8,904,194; and 9,135,456. No Final Written Decision; the merits were not reached.
• Sources:
  • https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2025-01201
  • http://lowensteinweatherwax.com/lw-obtains-three-non-institutions-on-behalf-of-security-first/

⚠️ Contradiction to flag: The earlier-generated "PTAB challenges" section of this analysis states the institution denial occurred 2025-12-23. The live search results (GreyB/IPverse case detail and the contemporaneous L&W press release dated Nov. 21, 2025) indicate the discretionary denial issued ~Nov. 20, 2025. Per the operating rules, I defer to the search results as ground truth: the denial date is November 20, 2025, not December 23, 2025.

---

3. Related-but-Distinct Proceedings (NOT '194 litigation — listed to avoid confusion)

These concern sibling patents in the same family and are sometimes conflated with '194 litigation:

---

4. Appellate (CAFC) Litigation

None found. No Federal Circuit appeal involving 8,904,194 appears in the searches. This is consistent with the record: IPR2025-01201 never reached a Final Written Decision (nothing appealable on the merits), and the E.D. Va. case (1:25-cv-00514) remains stayed at the district court level. (Note: the earlier-generated summary likewise reported no CAFC 2026 docket entries for this patent.)

---

Summary Table

---

Caveats / Confidence

• I have high confidence in the two proceedings above, which are directly grounded in cited dockets and PTAB records.
• I could not retrieve the contents of the exhibit captioned "List of Cases Involving the '194 Patent" (EX1040) filed in IPR2025-01201. Given that this exhibit was compiled close to the filing date, it is possible it enumerates additional, lower-profile assertions of the '194 patent that did not surface in my searches (e.g., short-lived or voluntarily dismissed suits). Based on everything retrieved, however, the IBM case (1:25-cv-00514) is the sole assertion of the '194 patent identified. Where I am uncertain, I have said so rather than infer.

Proceedings overview

There is one AIA trial proceeding on file for US Patent 8904194, which resulted in a discretionary denial of institution. This outcome means the patent claims were not reviewed on their merits by the PTAB and remain untested by IPR. The defensive posture for a defendant is that the patent claims have not been challenged or narrowed through this PTAB proceeding, and any IPR-based defense would need to initiate a new petition.

IPR2025-01201 — International Business Machines Corporation v. Security First Innovations LLC

• Type: Inter Partes Review
• Filed: 2025-07-09
• Status: Discretionary Denial. The PTAB declined to institute the IPR based on procedural grounds rather than a decision on the merits of patentability.
• Judge panel: Not publicly available from the search results.
• Petition grounds: Not publicly available from the search results.
• Institution decision: Denied on 2025-12-23. The Board exercised its discretion to deny institution, as indicated by the status "Discretionary Denial". The specific reasoning for the discretionary denial is not detailed in the provided snippet but typically relates to factors like parallel district court litigation, advanced stage of litigation, or inefficient use of Board resources (e.g., under Fintiv or NHK Spring factors).
• Final Written Decision (if issued): Not issued, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: Not applicable, as no Final Written Decision was issued.
• Defensive value: This proceeding does not affect the patentability of any claims of US8904194. A future defendant could file a new IPR petition against the patent, as the merits of the claims were not addressed.

Strategic summary

Currently, none of the claims of US8904194 have been canceled or invalidated through an AIA trial proceeding. All claims remain untested by the PTAB. The sole IPR filed, IPR2025-01201 by International Business Machines Corporation, was met with a discretionary denial of institution. This means the PTAB did not reach the merits of the patentability challenge, and therefore, no claims were sustained or canceled in that proceeding.

Regarding the estoppel landscape, since IPR2025-01201 was denied institution, the statutory estoppel provisions of § 315(e)(2) are not triggered for International Business Machines Corporation or its privies concerning any grounds that were or reasonably could have been raised in that petition. Therefore, for any new defendant, all prior-art grounds remain available for potential future IPR petitions.

No clear pattern signals emerge from this single proceeding. It's a single IPR filing by a major technology company, which was procedurally denied rather than being decided on the merits. This outcome doesn't indicate a "hardened" patent that has survived multiple challenges, nor does it point to specific claim vulnerabilities. The presence of Unified Patents in the related district court litigation and other PTAB data suggests a defensive aggregator's involvement in the broader patent family, but the specific IPR on this patent was filed by IBM.

Recommended next steps

For a potential defendant facing assertion of US8904194 today:

• Since IPR2025-01201 was denied institution on procedural grounds, the patent claims were not evaluated for patentability. This means that an IPR challenge on the merits of the claims (e.g., based on novelty or obviousness) is still a viable option. Thoroughly analyze the patent claims against the prior art to identify strong grounds for a new IPR petition.
• The absence of an instituted and completed IPR means there is no PTAB decision to leverage for claim invalidation in district court.
• Monitor the district court case 1:25-cv-00514 in the Virginia Eastern District Court, as the progress and any claim construction orders in that litigation could provide valuable insights for a potential IPR.
• Given that the patent is listed as "Expired - Lifetime" as of 2025-10-25, any new IPR petition would be subject to the one-year statutory deadline from the date the petitioner or real party in interest was served with a complaint alleging infringement of the patent. However, the expiration may also impact the patent owner's willingness to assert the patent vigorously, as damages for infringement would be limited to the period before expiration.

I'll research the assignment chain for US 8904194 using multiple search queries in parallel.

I have strong leads. Let me dig deeper on specific reel/frame records, correspondents, and the 2022 transfer.

Ownership & Assignment Reconstruction — US Patent 8904194

Sources used: USPTO Assignment Center (https://assignmentcenter.uspto.gov/), Google Patents legal events (https://patents.google.com/patent/US8904194/en), USPTO PTAB filings in IPR2025-01201/01202, E.D. Va. docket records for SFI v. Google and SFI v. IBM, and RPX/UniCourt litigation documents. Where the Assignment Center snippet did not return a reel/frame, I say so rather than guess.

---

Inventors

Unusual-pattern check — NOT present. The "all inventors bolt within 12 months of filing" precursor to a fire‑sale is not observed here. O'Hare remained publicly tied to SFC well past filing (his own March 4, 2015 board presentation, cited as Ex. 2004 in IPR2025‑01202, is authored while he was still running the company; James Varner was signing as "President & CEO, Security First Corp." in a March 17, 2017 USPTO paper). The ownership change here was driven by corporate insolvency, not inventor attrition. All four inventors assigned to the company on the filing date of this continuation (2012‑05‑10), consistent with a standard employee/contractor obligation.

---

Original assignee

Security First Corp. ("SFC") — 29811 Santa Margarita Parkway, Suite 600, Rancho Santa Margarita, CA 92688.

• Business: Software‑defined, data‑centric security — its SecureParser / Secure Parser Extended ("SPx") cryptographic bit‑splitting technology.
• Did it ship product embodying the claims? Yes. Public product history documents SPxSHARC, SPxGateway, ParsedCloud, and SPxBitFiler‑IPS, plus OEM licensing (Unisys Stealth from 2008; IBM chip/cloud integration announcements 2011 and 2015). Caveat: in the parallel IPR2025‑01202, IBM argued "there is no evidence that the … claims were ever commercialized, practiced, or marked" for that sibling patent — so commercialization evidence is contested for individual family members, though SFC clearly operated as a going concern.
• Current status: Failed and dissolved. Filed Chapter 11 on 2020‑08‑31 (Case 1:2020bk12053, Bankr. D. Del.; assets $1–10M, liabilities $10–50M per the IPVal patent‑backed bankruptcy report). Reported sold to ESW Capital in 2020; company profiles now list it "Out of Business" / "deadpooled."

---

Assignment timeline

Reel/frame confirmed where explicitly cited below. The SFC → Security First Innovations link is confirmed at Reel 061262 / Frame 0865 (this exact reel/frame appears as the chain‑of‑title entry for multiple SFC family patents, including in the 2023 Applications Data Sheets and the 2023 Terrile Cannatti & Chambers filing). Family‑specific reels for the initial inventor→SFC assignments vary by sibling patent (e.g., 045783/0985 and 049184/0302 on related filings); the reel for US 8,904,194's own 2012 assignment was not resolvable from available snippets.

• 2012‑05‑10 (executed) / recorded 2012‑05‑10 — Reel not confirmed for this patent

  • Conveyance: Assignment
  • Assignor: Orsini, Rick L.; O'Hare, Mark S.; Davenport, Roger S.; Winick, Steven
  • Assignee: Security First Corp.
  • Correspondent: Not determinable from available records.
  • Context: Initial inventor‑to‑company assignment, executed on the filing date of the continuation (13/468,562). Routine.

• 2016‑04‑12 (executed) / recorded 2016‑06‑24 — Reel 039153 / 0321

  • Conveyance: Patent Security Agreement (grant of security interest — securitization)
  • Assignor / Grantor: Security First Corp.
  • Assignee / Secured Parties: LG Management LLC; Topspin SFC Holdings LLC; plus ~50 individual and family‑office lenders (Altmann, Auber Investments Ltd., Barle, Coleman family, Gyenes, Lakoff, Rautenberg, Simons, Zug Ventures LLC, etc.)
  • Correspondent: Not confirmed from snippets; a related USPTO termination of security interest in the SFC file was submitted by Alan Ederer (name alone; firm not resolved — flagged as a possible recurring recording agent, not established).
  • Context: Securitization — SFC pledged essentially its entire patent portfolio as collateral to a private lender group to raise capital (matched to SEC‑reported debt/equity raises of ~$29M Dec 2014 and ~$36M Apr 2016). This is the financial distress precursor.

• 2022‑08‑29 (executed) / recorded 2022‑08‑29 — Reel 061262 / 0865

  • Conveyance: Assignment
  • Assignor: Security First Corp.
  • Assignee: Security First Innovations, LLC ("SFI")
  • Correspondent: Not confirmed for the recording itself. SFI's prosecution correspondence address of record on a 2023 family filing is c/o Farjami & Farjami LLP, 26522 La Alameda Ave (Mission Viejo, CA); SFI's own correspondence address on that filing was 44095 Pipeline Plaza, Suite 140, Ashburn, VA 20147.
  • Context: Transfer‑to‑asserter / post‑bankruptcy acquisition. SFI is described in its own complaint as "formed by the longtime former chairman of SFC" and acquired the patents "in 2022… today is their sole assignee."

• 2022‑09‑30 (executed) / recorded 2022‑09‑30 — Reel not confirmed

  • Conveyance: Release by Secured Party
  • Assignor (releasing parties): LG Management LLC; Topspin SFC Holdings LLC; Altmann, Eric; Auber Investments Ltd.; Barle, Stanko; and the remainder of the 2016 lender group
  • Assignee (released party): Security First Corp.
  • Correspondent: Not confirmable.
  • Context: Release of the 2016 security interest, clearing title so the 2022 transfer to SFI stands free of lien.

Naming discrepancy to flag: pleadings and filings use both "Security First Innovations, LLC" and "Security First Innovations, Inc." — treat as the same current owner pending a title record check.

---

Timeline diagram

timeline
    title Ownership of US 8904194
    2004 : Priority date Oct 25
    2012 : Continuation filed May 10
         : Inventors assign to Security First Corp
    2014 : Patent issued Dec 2
    2016 : Portfolio pledged to lender group
         : Reel 039153 Frame 0321
    2020 : Security First Corp files Chapter 11
         : Assets sold to ESW Capital
    2022 : Patents assigned to Security First Innovations
         : Reel 061262 Frame 0865
         : Secured parties release lien
    2023 : SFI sues Google in E D Virginia
    2025 : SFI sues IBM in E D Virginia

---

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT. Reel 061262/0865 (2022‑08‑29) moves the patent from operating company Security First Corp to Security First Innovations, LLC, a licensing‑only entity that (per SFI's own E.D. Va. complaint) was "formed by the longtime former chairman of SFC" and holds no product. Concrete corroboration beyond the name: no products in commerce, the entity exists to hold and assert the portfolio, and it litigates through outside counsel (Farjami & Farjami as prosecution correspondent; Poynter/Molster/Iancu as litigation counsel). Reel 061262/0865 is the specific entry.

2. Known asserter in the chain — UNCLEAR (leaning present on frequency, not on list membership). SFI does not appear on the classic enumerated NPE lists (Acacia, Marathon, IV, Wi‑LAN, etc.) in anything I could retrieve. However, it is a repeat plaintiff — SFI v. Google, 2:23‑cv‑00097 (E.D. Va., filed 2023‑03‑10) and 1:23‑cv‑00329 (E.D. Va., filed 2023‑03‑10), and SFI v. IBM, 1:25‑cv‑00514 (E.D. Va., filed 2025‑03‑24) — and is tracked by both Unified Patents and RPX. Mark as unclear for "known list" membership, but note high assertion frequency.

3. Repeat correspondent across the chain — UNCLEAR / weakly present. The clearest recurring name I can tie to the SFC/SFI family is Farjami & Farjami LLP (SFI's correspondence address of record in 2023) and a submitting agent, Alan Ederer, on a security‑interest termination in the SFC file. I could not confirm the same attorney/firm appearing as correspondent on multiple links of this specific chain (2012, 2016, 2022 recordings), so I decline to call this a finding. This is the one signal the assignment‑center correspondent field would resolve and that I could not fully retrieve.

4. Cascading transfers — NOT PRESENT. The 2016 lien, 2022 assignment, and 2022 release describe one transaction unfolding over years, not a rapid series of chained LLCs within 24 months. No evidence of multiple anonymous assignees sharing a correspondent address.

5. Pre-litigation transfer — PRESENT (borderline on the 6‑month window). Assignment to SFI executed 2022‑08‑29; the first suits asserting this portfolio, SFI v. Google (2:23‑cv‑00097 / 1:23‑cv‑00329), were filed 2023‑03‑10 — roughly 6 months, 10 days later. Just outside a strict 6‑month line, but the sequence is unmistakably "acquire → assert," which is the substance of the signal.

6. Bankruptcy fire-sale — PRESENT (strongest signal). SFC filed Chapter 11 on 2020‑08‑31 (1:2020bk12053, D. Del.); per IPR2025‑01202 pleadings, "SFC declared bankruptcy, and its patents were acquired by SFC's former chairman through his company SFI." The 2016 security agreement (Reel 039153/0321) and the 2022 release document the distress‑to‑sale arc. This is the textbook bankruptcy‑to‑asserter path.

7. Privateering — NOT PRESENT (defined sense). Privateering requires an operating company transferring to an NPE that asserts on the operating company's behalf. SFC is defunct and derives no competitive benefit; the former chairman's entity asserts purely for its own account. Thematic resemblance only.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. To the contrary, Unified Patents appears as the challenger side in the broader family.

---

Verdict

NPE — high confidence.

Two or more strong signals are independently documented. First, a bankruptcy fire‑sale: Security First Corp filed Chapter 11 on 2020‑08‑31 (1:2020bk12053, D. Del.) and its portfolio was acquired by a company formed by its former chairman. Second, a shell‑entity / transfer‑to‑asserter event: Reel 061262/0865 (executed 2022‑08‑29) moved the patent from the operating company to Security First Innovations, LLC, a non‑practicing holder, immediately after which the 2016 security interest (Reel 039153/0321) was released (2022‑09‑30) to give clean title. Third, an acquire‑then‑assert sequence: SFI sued Google in E.D. Va. on 2023‑03‑10, roughly six months after the transfer, and sued IBM there on 2025‑03‑24 — an assertion campaign, not product competition.

Verify at: https://assignmentcenter.uspto.gov/ (search "8904194" or assignee "Security First Innovations"). Reconfirm the exact reel/frame for the 2012 inventor assignment and the 2022 release, and capture the correspondent of record on Reel 061262/0865 and Reel 039153/0321 — those two correspondent fields are the remaining gaps in signal #3.

One contradiction to flag with the earlier sections: the pre‑existing "PTAB challenges" section states the institution denial date as 2025‑12‑23, while the proceeding data (GreyB/IPVerse) shows the Director Discretionary Decision: Deny on 2025‑11‑20. Reconcile against the PTAB docket before relying on either date.

The USPTO database (via Google Patents, which aggregates USPTO data) lists the following "Cited by" references for US Patent 8904194. It's important to note that a "Cited by" reference indicates that a later patent cited US8904194, not that US8904194 cited it as prior art. To find prior art for US8904194, we need to look at the "Prior Art Citations" section of US8904194 itself.

Based on the full patent text provided for US8904194, the "Prior Art References" section is usually where these citations would be found. However, in the provided text, there is no explicit section titled "Prior Art References" or "U.S. Patent Documents" that typically lists the examiner-cited prior art. The "Prior art keywords" and "Prior art date" are general descriptive metadata, not specific patent citations.

To fulfill the request, I need to look for the "Cited Patent References" or "Other References" section within the actual patent document US8904194. Since the provided text is a full patent text and does not contain this section, I will explicitly state this and explain how prior art would typically be identified for anticipation claims.

Clarification on Prior Art and Anticipation (35 U.S.C. § 102):
Under 35 U.S.C. § 102, a patent claim is "anticipated" if every element of the claimed invention is found, either expressly or inherently described, in a single prior art reference that existed before the effective filing date of the claimed invention. The prior art reference must disclose exactly what is claimed, with the elements arranged as in the claim.

Since the full patent text provided does not explicitly list the prior art documents cited during the prosecution of US8904194, I cannot identify specific references to analyze for potential anticipation under 35 U.S.C. § 102.

To conduct a thorough prior art analysis for US8904194, one would typically obtain the official patent document from the USPTO and review the "References Cited" section, which lists both U.S. Patent Documents and Other Publications considered by the examiner.

The provided "Prior art" section explicitly states that the full patent text for US8904194 does not contain a list of specific prior art references (e.g., U.S. Patent Documents or Other Publications) that were cited during its prosecution. Therefore, without specific prior art documents to analyze, it is not possible to perform an obviousness analysis under 35 U.S.C. § 103.

An obviousness analysis requires identifying combinations of existing prior art references and demonstrating why a person having ordinary skill in the art (PHOSITA) would have been motivated to combine these references to arrive at the claimed invention, with a reasonable expectation of success. Since no specific prior art references have been identified or provided, such an analysis cannot be conducted.

To perform this analysis, one would typically consult the "References Cited" section of the official US8904194 patent document from the USPTO to obtain a list of examiner-cited prior art.

I'll research the patent term details, family relationships, and expiration for US 8904194.

I have substantial family data. Let me pin down the specific term adjustment, priority chain, and continuation parent for application 13/468,562.

Patent Term, Family, and Expiration Analysis — US 8,904,194

Important preliminary flags (per operating rules):

• Date discrepancy: The task states the current date is April 26, 2026; the tool environment reports 2026‑09‑25. Either way, the patent's term has already run and it is expired, so the analysis conclusion is unaffected. I flag it rather than silently reconciling.
• Verification limit: I was able to retrieve the family/priority/status data below from Google Patents, Unified Patents, Justia, uspto.report, and PTAB‑filed provenance documents, but I could not retrieve the USPTO's specific PTA certificate figure (adjusted‑term day count) or confirm terminal‑disclaimer recordings for US 8,904,194 from the sources surfaced. Where I cannot verify a number, I say so rather than estimate it.

---

1. Patent identification

The docket suffix "‑C1‑I" ("first continuation") corroborates the continuation status described below.

---

2. Patent Term Adjustment (PTA)

Statutory background (35 U.S.C. § 154(b)): The 20‑year term runs from the earliest effective U.S. non‑provisional filing date. PTA adds day‑for‑day credit for USPTO delay:

• A‑delay — failure to meet the "14‑4‑4‑4" action deadlines;
• B‑delay — pendency exceeding 3 years (excluding RCE time);
• C‑delay — interferences, secrecy orders, successful appeals;
• reduced by any applicant‑caused delay and capped by any terminal disclaimer.

Application to the '194 patent:

• Term base date: The 20‑year clock is measured from the earliest non‑provisional application in the benefit chain, namely Ser. No. 11/258,839, filed 2005‑10‑25 — not the 2012‑05‑10 continuation filing. (The 2012 filing is a continuation, so it does not restart the term.)
• Unadjusted 20‑year date: 2005‑10‑25 + 20 years = 2025‑10‑25.
• Reported (adjusted) expiration: Both Google Patents and Unified Patents list the anticipated expiration as 2025‑10‑25, with legal status "Expired – Lifetime." Because the reported expiration equals the unadjusted 20‑year date, the data indicates no net PTA was carried by this particular continuation (or any PTA was fully offset/reduced).
• What I could NOT verify: the precise USPTO PTA certificate day‑count for 13/468,562, and whether a terminal disclaimer was recorded in this application that would cap its term to a family member. (Terminal disclaimers are common across obviousness‑type‑double‑patenting families such as this one and can cancel out PTA.) I state this as an open verification item, not a conclusion.

Note on a family inconsistency: sibling US 9,338,140 (App. 13/468,383) is listed on Unified Patents with expiration 2025‑10‑24, while the subject patent is listed 2025‑10‑25. This one‑day spread almost certainly reflects the 2004‑10‑24 vs. 2004‑10‑25 priority‑date/time‑zone ambiguity (see §5), not a real term difference.

---

3. Patent Term Extension (PTE — 35 U.S.C. § 156)

Not applicable. PTE under § 156 is available only for patents whose term is consumed by regulatory review of a drug, medical device, food additive, or color additive (Hatch‑Waxman‑type extensions). US 8,904,194 is a data‑security/cryptography patent (secure data parser, cryptographic splitting, trust engine). No FDA regulatory‑review basis exists, and no PTE‑related regulatory‑review certificate applies. PTE = none.

---

4. Continuation and Divisional Relationships

4.1 Immediate parent — continuation

App. 13/468,562 is a continuation of App. 11/258,839, filed 2005‑10‑25 (issued as US 8,266,438 B2 on 2012‑09‑11, same title). The benefit claim in the pre‑grant publication states:

"This application claims the benefit of U.S. patent application Ser. No. 11/258,839, filed on Oct. 25, 2005, which claims priority benefit from U.S. provisional application No. 60/622,146, filed on Oct. 25, 2004, and U.S. provisional application No. 60/718,185, filed Sep. 16, 2005."

The absence of "continuation‑in‑part" language plus the "‑C1‑I" docket indicates a straight continuation (not a CIP).

4.2 Divisional status

The record I retrieved designates 13/468,562 as a continuation of 11/258,839. I did not find record evidence that it is a divisional (i.e., the product of a restriction requirement in the parent). Its siblings (see 4.3) were likewise filed as continuations on the same day. I flag the distinction explicitly rather than assume.

4.3 Sibling continuations filed the same day (2012‑05‑10)

Seven co‑pending continuations were filed on 2012‑05‑10, all sharing the 2004‑10‑25 priority and the "Secure data parser method and system" title:

---

5. Related Family Members

The '194 patent belongs to a large family (Unified Patents reports ~50 members) under Family ID 35912925, sharing priority to provisional 60/622,146 (2004‑10‑25) and provisional 60/718,185 (2005‑09‑16) via non‑provisional 11/258,839 (2005‑10‑25).

5.1 Additional U.S. continuations in the same priority chain

• 13/371,361 → US 8,271,802 (2012‑02‑10)
• 13/371,363 → US 9,294,444 (2012‑02‑10)
• 13/371,364 → US 9,935,923 (2012‑02‑10)
• 13/915,081 → US 9,992,170 (2013‑06‑11)
• 13/915,518 → US 9,177,159 (2013‑06‑11)
• 13/915,570 → US 9,871,770 (2013‑06‑11)
• 14/473,387 → US 9,298,937 (2014‑08‑29)
• 14/473,813 → US 9,135,456 (2014‑08‑29)
• 14/710,528 → US 9,906,500 (2015‑05‑12)
• Later members include US 11,178,116 and US 11,968,186 (per Unified Patents family list).

5.2 Foreign family members (same priority)

• WO 2006/047694 A1 (2006‑05‑04)
• EP 1825412 A1 (2007‑08‑29)
• CA 2584525 A1 / A2 / C; CA 2922172 A1; CA 2922200 A1
• AU 2005299317 A1
• BR PI0517026 A
• CN 101375284 A / B; CN 102609640 A / B

5.3 A separate, related earlier chain (distinct priority)

A related but distinct "Secure data parser" family traces to App. 10/458,928 (filed 2003‑06‑11) → US 7,391,865. It shares title/inventors but a different priority claim (a 2002 provisional), and should not be conflated with the 2004‑10‑25 chain. (I could not confirm from the retrieved sources whether 11/258,839 is a CIP of 10/458,928; I flag this as unverified.)

---

6. Projected / Actual Expiration Date

Conclusion: The projected/actual expiration for US 8,904,194 is 2025‑10‑25, driven by the 20‑year term running from the 2005‑10‑25 parent non‑provisional filing, with no net PTA reflected in the databases and no PTE. As of the analysis date (April 26, 2026), the patent has already expired, consistent with the "Expired – Lifetime" status and the "Anticipated expiration 2025‑10‑25" entry on Google Patents and Unified Patents.

---

7. Items I could not verify (stated explicitly rather than estimated)

1. The exact USPTO PTA day‑count for App. 13/468,562 (the certificate/reconsideration figure) — not surfaced.
2. Whether any terminal disclaimer was recorded in 13/468,562 (which would cap its term to a family member and can zero‑out PTA). This matters because at least one family member (the parent US 8,266,438) is indexed with an apparently later "active" date (2030‑10‑12), and terminal disclaimers are typical in such obviousness‑type‑double‑patenting families.
3. Whether 11/258,839 is itself a continuation‑in‑part of the earlier 10/458,928 chain.

Recommended verification paths: USPTO PatentCenter for App. 13/468,562 (PTA certificate / "Patent Term Adjustment" tab, and any recorded terminal disclaimer), and the Assignment Center / reel‑frame records for terminal‑disclaimer and assignment entries.

Sources: Google Patents — https://patents.google.com/patent/US8904194 ; Unified Patents portal — https://portal.unifiedpatents.com/patents/patent/US-[8904194](/patent/8904194)-B2 ; Justia — https://patents.justia.com/patent/8904194 ; uspto.report — https://uspto.report/patent/grant/8,904,194 ; PTAB provenance listing App. 13/468,562 (family/Exhibit A) — https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1558110](/patent/1558110)/download-documents .

Defensive Disclosure Document: US Patent 8904194 Derivatives

Date: April 26, 2026

This document describes various derivative works and technical disclosures related to US Patent 8904194, titled "Secure data parser method and system." The aim is to expand upon the core concepts of the patent to establish prior art for future incremental improvements or obvious variations that competitors might attempt to claim as novel. Each derivative focuses on a specific aspect of the original claims, applying different materials, operational parameters, cross-domain applications, emerging technologies, or inverse/failure modes.

---

Core Claim 1: Method for securing data

Claim 1: A method for securing data, comprising: parsing data to be secured into at least two portions; encrypting the at least two portions of data; storing the encrypted at least two portions of data in a plurality of distinct data storage facilities, wherein any one individual data storage facility does not include sufficient encrypted data to reconstruct the original data; and reassembling the stored encrypted at least two portions of data to recreate the original data for authorized access or use.

---

C1.D1.1: Material & Component Substitution - Quantum-Resistant Encryption Primitives

Derivative Title: Data Security Method with Lattice-Based Quantum-Resistant Encryption
Enabling Description: This derivative employs a method wherein the encryption of the at least two parsed data portions utilizes a lattice-based cryptographic algorithm, specifically CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium for digital signatures. The parsing operation divides the data into fixed-size blocks of 1024 bytes. Each block is encrypted using a symmetric cipher (e.g., AES-256 in GCM mode) with a unique ephemeral key. This ephemeral key is then encapsulated using a 512-bit CRYSTALS-Kyber public key, and the encapsulated key, along with a CRYSTALS-Dilithium signature of the encrypted data portion, is stored with the respective encrypted portion. Storage occurs across geographically distributed, non-volatile memory arrays composed of Resistive RAM (ReRAM), specifically utilizing a 1T1R (one transistor, one resistor) architecture for enhanced read/write endurance and non-volatility. Reconstruction involves authenticating the signature with CRYSTALS-Dilithium, decapsulating the ephemeral key with the corresponding CRYSTALS-Kyber private key, decrypting the data portion, and then sequentially reassembling the blocks.

graph TD
    A[Original Data] --> B{Parse into Blocks};
    B --> C{Generate Ephemeral Key (AES-256)};
    B --> D{Encrypt Block (AES-256 GCM)};
    C --> E{Encapsulate Key (CRYSTALS-Kyber)};
    D --> F{Sign Encrypted Block (CRYSTALS-Dilithium)};
    E & F --> G{Store in ReRAM Facility (1 of N)};
    G --> H[Distributed Encrypted Portions];
    H --> I{Retrieve N-1 Portions};
    I --> J{Decapsulate Key & Verify Signature};
    J --> K{Decrypt Block};
    K --> L[Reassembled Original Data];

C1.D1.2: Material & Component Substitution - DNA Storage of Encrypted Portions

Derivative Title: Biotechnological Data Security Method via DNA Encoding and Storage
Enabling Description: The data to be secured is initially parsed into 200-byte segments. Each segment undergoes encryption using ChaCha20-Poly1305 with a 256-bit key. The resulting encrypted segments, along with their respective keys (also encrypted using a master key), are then translated into DNA sequences. This translation employs a non-degenerate, 4-base codon system where each byte maps to a specific sequence of DNA bases (A, C, G, T). These synthetic DNA strands, approximately 500 base pairs in length, are then chemically synthesized and stored within a lyophilized bacterial spore solution (e.g., Bacillus subtilis) distributed across five distinct, climate-controlled biological storage facilities. Reconstruction involves retrieving a quorum of the biological samples, extracting and sequencing the DNA, decoding the DNA into encrypted data segments, decrypting the segments with the master key, and finally reassembling the original data.

graph TD
    A[Original Data] --> B{Parse into 200-byte Segments};
    B --> C{Encrypt Segment (ChaCha20-Poly1305)};
    C --> D{Translate Encrypted Segment to DNA Sequence};
    D --> E{Synthesize DNA Strands};
    E --> F{Lyophilize in Spore Solution};
    F --> G{Store in Biological Facility (1 of 5)};
    G --> H[Distributed Encrypted DNA Portions];
    H --> I{Retrieve Quorum of Samples};
    I --> J{Extract & Sequence DNA};
    J --> K{Decode DNA to Encrypted Data};
    K --> L{Decrypt Data Segment};
    L --> M[Reassembled Original Data];

C1.D2.1: Operational Parameter Expansion - Nanoscale Data Fragment Distribution

Derivative Title: Nanoscale Data Fragment Security for Distributed Quantum Information Systems
Enabling Description: A method for securing sensitive quantum state information, where the "data" consists of a sequence of entangled qubit states. The method parses this quantum data into individual qubit fragments (e.g., Bell states or GHZ states). Each qubit fragment is then encoded using quantum error-correcting codes (e.g., Steane code) and distributed via quantum entanglement swapping across a network of superconducting qubit registers maintained at milliKelvin temperatures. The "encryption" is inherent in the quantum state's fragility and the distribution, requiring all fragments to be coherently reassembled for information extraction, where any single fragment provides insufficient data. The "distinct data storage facilities" are geographically separated quantum computing nodes. Reassembly involves controlled quantum operations to reverse the entanglement swapping and error correction, reconstructing the original entangled state for quantum computation or measurement.

graph TD
    A[Quantum Data (Entangled Qubits)] --> B{Parse into Individual Qubit Fragments};
    B --> C{Encode with Quantum Error Correction (Steane Code)};
    C --> D{Distribute via Quantum Entanglement Swapping};
    D --> E{Store in Superconducting Qubit Register (1 of N)};
    E --> F[Distributed Encoded Qubit Fragments];
    F --> G{Retrieve N-1 Fragments};
    G --> H{Perform Inverse Entanglement Swapping};
    H --> I{Apply Quantum Error Correction Decoding};
    I --> J[Reassembled Quantum Data];

C1.D2.2: Operational Parameter Expansion - Petabyte-Scale Cross-Cloud Archival

Derivative Title: Petabyte-Scale Secure Archival Method for Cross-Cloud Data Lakes
Enabling Description: This method applies to petabyte-scale datasets (e.g., scientific simulation outputs or large enterprise backups). The data is parsed into 256 MB chunks. Each chunk is encrypted using AES-256-GCM and then further processed with a (3, 5) Reed-Solomon erasure coding scheme to generate five redundant data portions for each chunk. These portions are then stored across five distinct hyperscale cloud object storage services (e.g., AWS S3, Azure Blob Storage, Google Cloud Storage, IBM Cloud Object Storage, Alibaba Cloud OSS), each located in a different geographical region (e.g., US-East, Europe-West, Asia-Pacific). The storage is configured for archive-tier storage with long retrieval times (e.g., Glacier Deep Archive equivalent). Any three of the five portions are sufficient to reconstruct the original chunk. Reassembly involves parallel retrieval from the cloud providers, erasure decoding, decryption, and concatenation of the original 256 MB chunks into the full dataset. This operates at an industrial scale, with network latencies potentially in the hundreds of milliseconds per retrieval.

graph TD
    A[Petabyte Dataset] --> B{Parse into 256MB Chunks};
    B --> C{Encrypt Chunk (AES-256 GCM)};
    C --> D{Apply (3,5) Reed-Solomon Erasure Coding};
    D --> E{Store 5 Portions across 5 Cloud Object Storage Services (Geo-Distributed)};
    E --> F[Distributed Encrypted Erasure-Coded Portions];
    F --> G{Initiate Parallel Retrieval from >=3 Cloud Services};
    G --> H{Perform Erasure Decoding};
    H --> I{Decrypt Chunk};
    I --> J[Reassembled Original Dataset];

C1.D3.1: Cross-Domain Application - Secure Medical Imaging Data Sharing

Derivative Title: Secure Multi-Institutional Medical Imaging Data Sharing with Partial Data Obfuscation
Enabling Description: A method for sharing high-resolution medical imaging data (e.g., DICOM files from MRI/CT scans) across multiple healthcare institutions while maintaining patient privacy. The DICOM data is parsed into two types of portions:

1. Patient-identifiable metadata (e.g., patient ID, name, date of birth)
2. Anonymized image pixel data.
   The identifiable metadata portion is then cryptographically hashed and XOR'd with a random salt to form a first encrypted portion. The anonymized image pixel data is encrypted with a distinct symmetric key. Both encrypted portions are stored in separate, distinct data storage facilities: the hashed metadata in a hospital's patient record system, and the encrypted image data in a research institution's secure archive. Neither facility alone contains sufficient information to link the image to an uncompromised patient identity. Authorized access involves a medical researcher receiving the encrypted image data and a secure token from the hospital, allowing them to retrieve the metadata pairing, which, when combined, allows for verification and re-identification if required for a specific, audited study.

graph TD
    A[Medical Imaging Data (DICOM)] --> B1{Parse Identifiable Metadata};
    A --> B2{Parse Anonymized Image Data};
    B1 --> C1{Hash Metadata + XOR with Random Salt};
    B2 --> C2{Encrypt Image Data (Symmetric Key)};
    C1 --> D1[Store in Hospital Patient Record System (Facility 1)];
    C2 --> D2[Store in Research Archive (Facility 2)];
    D1 & D2 --> E[Distributed Encrypted Portions];
    E --> F{Authorized Access Request};
    F --> G{Retrieve Hashed Metadata & Encrypted Image};
    G --> H{Combine & Verify (e.g., re-link with patient data when needed)};
    H --> I[Reconstructed DICOM Data];

C1.D3.2: Cross-Domain Application - Secure Smart Grid Control Command Distribution

Derivative Title: Secure Distribution of Critical Control Commands in Smart Grid Infrastructure
Enabling Description: A method for securing critical control commands (e.g., substation trip commands, load shedding instructions) within a distributed smart grid infrastructure. Each command, typically a small data packet, is parsed into three portions:

1. Command payload (e.g., trip code, target ID).
2. Timestamp and sequence number.
3. Originator digital signature.
   Each of these portions is individually encrypted using AES-256 with distinct keys. The three encrypted portions are then transmitted and stored across three physically isolated data storage facilities:
4. The primary utility operator's control center.
5. A regional independent system operator (ISO) data center.
6. A government energy oversight agency's secure archive.
   No single facility possesses enough encrypted data to reconstruct or execute the command without collusion. Reassembly for authorized execution requires retrieving all three encrypted portions, decrypting them, verifying the digital signature against a trusted public key, and then reassembling the original control command for dispatch to the grid device.

graph TD
    A[Critical Smart Grid Command] --> B1{Parse Command Payload};
    A --> B2{Parse Timestamp & Sequence};
    A --> B3{Parse Originator Digital Signature};
    B1 --> C1{Encrypt Payload (AES-256)};
    B2 --> C2{Encrypt Timestamp (AES-256)};
    B3 --> C3{Encrypt Signature (AES-256)};
    C1 --> D1[Store in Utility Control Center (Facility 1)];
    C2 --> D2[Store in Regional ISO Data Center (Facility 2)];
    C3 --> D3[Store in Government Energy Archive (Facility 3)];
    D1 & D2 & D3 --> E[Distributed Encrypted Command Portions];
    E --> F{Authorized Execution Request};
    F --> G{Retrieve All 3 Portions};
    G --> H{Decrypt & Verify Signature};
    H --> I[Reassembled & Executable Command];

C1.D4.1: Integration with Emerging Tech - AI-Driven Optimal Data Splitting and Storage

Derivative Title: AI-Optimized Adaptive Data Splitting and Storage Method
Enabling Description: The method begins by parsing data into an initial set of portions. An AI-driven optimization module, utilizing a Deep Reinforcement Learning (DRL) agent, continuously monitors access patterns, threat intelligence feeds (e.g., CVE databases, dark web monitoring), and network latency/cost metrics across a globally distributed network of data storage facilities. Based on these real-time inputs, the DRL agent dynamically adjusts:

1. The optimal number of portions to split the data into (e.g., between 2 and 10).
2. The encryption algorithm strength and key rotation frequency for each portion.
3. The specific geographic locations and types of storage facilities (e.g., hot/cold, cloud/on-premise) for each encrypted portion to minimize risk and cost while maintaining performance.
   When a data access request is authorized, the DRL agent provides the optimal strategy for reassembly, dynamically identifying the fastest or most secure subset of portions required for reconstruction. This enables adaptive security posture and resource optimization.

graph TD
    A[Original Data] --> B{Initial Parse & Encrypt};
    B --> C{Store in Distributed Facilities};
    C --> D[Access Patterns & Threat Intelligence (Real-time)];
    D --> E[Network Latency & Cost Metrics];
    E --> F{AI-Driven DRL Agent};
    F --> G{Dynamic Adjustment of: # Portions, Encryption, Storage Location};
    G -- "Re-parse & Re-encrypt if needed" --> B;
    G --> C;
    C --> H{Authorized Access Request};
    H --> I{DRL Agent Provides Optimal Reassembly Strategy};
    I --> J{Retrieve & Reassemble};
    J --> K[Reconstructed Original Data];

C1.D4.2: Integration with Emerging Tech - IoT Sensor-Verified Data Integrity with Blockchain Metadata

Derivative Title: IoT-Monitored, Blockchain-Anchored Secure Data Parsing and Storage
Enabling Description: The data is parsed into portions, encrypted, and stored across distinct data storage facilities as per Claim 1. Each data storage facility is augmented with a network of IoT sensors (e.g., environmental sensors for temperature/humidity, physical access sensors, network traffic monitors) that continuously collect integrity metrics. These metrics (e.g., hash of stored data, access logs, environmental parameters) are periodically signed by the IoT device's TPM (Trusted Platform Module) and published as immutable transaction metadata onto a permissioned blockchain (e.g., Hyperledger Fabric). If a threshold of IoT sensor data indicates potential tampering, unauthorized access, or environmental anomaly in a storage facility, the blockchain logs this event. This triggers the re-splitting and re-distribution of the compromised portions to new facilities, informed by the blockchain's auditable history. Data reassembly includes cross-referencing the blockchain for the latest valid metadata hashes to ensure integrity before reconstruction.

graph TD
    A[Original Data] --> B{Parse & Encrypt Portions};
    B --> C{Store in Data Storage Facility (1 of N)};
    C --> D[IoT Sensors];
    D -- "Integrity Metrics" --> E{Sign with TPM};
    E --> F{Publish to Permissioned Blockchain (Metadata Tx)};
    F --> G{Blockchain Monitors for Anomalies};
    G -- "Anomaly Detected" --> B;
    C --> H{Authorized Access};
    H --> I{Verify Blockchain Metadata Hashes};
    I --> J{Retrieve & Reassemble};
    J --> K[Reconstructed Original Data];

C1.D5.1: The "Inverse" or Failure Mode - Time-Locked Self-Destructing Data

Derivative Title: Time-Locked Self-Destructing Data Method for Ephemeral Information
Enabling Description: A method for handling highly sensitive data requiring strict ephemerality. Data is parsed into three portions, encrypted with AES-256, and then stored in three distinct data storage facilities. Crucially, each encrypted portion is also combined with a time-lock mechanism. This mechanism involves encrypting each portion's symmetric key with a public key that can only be decrypted after a predetermined future time T has passed (e.g., using a Verifiable Delay Function or a time-release crypto puzzle). Additionally, each storage facility runs an independent, immutable timer. Upon reaching T, each facility's software is designed to cryptographically shred its stored portion and associated time-locked key, rendering the entire data permanently unrecoverable by anyone, including authorized users, after the specified time. This ensures absolute data destruction without reliance on active deletion commands, even in the event of system compromise.

graph TD
    A[Original Data] --> B{Parse into 3 Portions};
    B --> C{Encrypt Portion (AES-256)};
    C --> D{Combine with Time-Lock Mechanism (Future Key Release)};
    D --> E{Store in Data Storage Facility (1 of 3) + Independent Timer};
    E --> F[Distributed Time-Locked Portions];
    F -- "Time T Reached" --> G{Cryptographically Shred Portion & Key};
    G --> H[Data Permanently Unrecoverable];
    F -- "Before Time T" --> I{Authorized Access Request};
    I --> J{Retrieve & Reassemble};
    J --> K[Reconstructed Original Data];

---

Core Claim 14: System for securing data

Claim 14: A system for securing data, comprising: a plurality of distinct data storage facilities, wherein each data storage facility includes a computer accessible storage medium which stores portions of data to be secured; a data splitting module which operates on data to be secured to create at least two portions of the data, encrypts the at least two portions of data, and distributes the encrypted at least two portions of data to the plurality of distinct data storage facilities, wherein any one individual data storage facility does not include sufficient encrypted data to reconstruct the original data; a data assembly module which processes the encrypted at least two portions of data from at least two of the data storage facilities to assemble the original data; and a cryptographic handling module which encrypts and decrypts data, wherein when data is reconstituted for use by an authorized user, the original data exists in a useable form only in the cryptographic handling module.

---

C14.D1.1: Material & Component Substitution - Decentralized Storage & Trusted Execution Environment

Derivative Title: Secure Data System with IPFS Storage and SGX-Protected Cryptographic Handling
Enabling Description: This system employs a plurality of distinct data storage facilities implemented as nodes in an InterPlanetary File System (IPFS) network, each hosting a computer-accessible storage medium. The data splitting module, executing within a Trusted Execution Environment (TEE) such as Intel SGX enclave, receives data, creates at least two portions, encrypts them using AES-256-GCM, and distributes the encrypted portions as content-addressed objects to the IPFS facilities. The cryptographic handling module, also executing within an Intel SGX enclave, is responsible for encryption and decryption. The data assembly module, similarly TEE-protected, processes the encrypted IPFS objects retrieved from multiple IPFS nodes to reconstruct the original data. A critical aspect is that the original data, upon reassembly, exists in a usable form exclusively within the cryptographic handling module's SGX enclave, ensuring that plaintext data is never exposed to the host operating system or external memory.

graph TD
    A[Data to be Secured] --> B{Data Splitting Module (SGX Enclave)};
    B --> C{Encrypt Portions (AES-256-GCM)};
    C --> D{Distribute to IPFS Nodes (Content-Addressed Objects)};
    D --> E[IPFS Node 1 (Storage Facility)];
    D --> F[IPFS Node 2 (Storage Facility)];
    D --> G[IPFS Node N (Storage Facility)];
    E & F & G --> H{Data Assembly Module (SGX Enclave)};
    H --> I{Cryptographic Handling Module (SGX Enclave)};
    I --> J[Usable Original Data (ONLY in Crypto Module)];

C14.D1.2: Material & Component Substitution - Homomorphic Encryption for Cryptographic Operations

Derivative Title: Homomorphic Data System for Encrypted Computation and Secure Storage
Enabling Description: This system features data storage facilities that store encrypted data portions. The data splitting module creates and encrypts portions using a partially homomorphic encryption scheme (e.g., Paillier for additive homomorphic operations) before distribution. The cryptographic handling module is enhanced with homomorphic evaluation capabilities. When an authorized user requires processing of the data but not its direct viewing, the cryptographic handling module can perform certain computations (e.g., aggregation, sum, average) directly on the encrypted portions without ever decrypting them. The result of these homomorphic operations is also encrypted. Only for final, authorized access is the encrypted result fully decrypted. The data assembly module reconstructs the homomorphically encrypted data. This ensures the original data or even its intermediate plaintext derivations do not exist in usable form outside a highly restricted decryption context within the cryptographic handling module.

graph TD
    A[Data to be Secured] --> B{Data Splitting Module};
    B --> C{Encrypt Portions (Partially Homomorphic)};
    C --> D{Distribute to Storage Facilities (N)};
    D --> E[Encrypted Portions];
    E --> F{Cryptographic Handling Module (Homomorphic Evaluation)};
    F -- "Perform Computation on Encrypted Data" --> G[Encrypted Result];
    G --> H{Authorized Decryption Request};
    H --> I[Decrypted Result/Original Data (ONLY in Crypto Module)];

C14.D2.1: Operational Parameter Expansion - Hyper-Scale Serverless Cross-Cloud Deployment

Derivative Title: Hyper-Scale Serverless Data Security System with Cross-Cloud Object Storage
Enabling Description: The system is deployed in a hyper-scale, multi-cloud environment. Data storage facilities are ephemeral object storage buckets across three distinct public cloud providers (e.g., AWS S3, Google Cloud Storage, Azure Blob Storage) in different geographical regions, managed by serverless functions (e.g., AWS Lambda, Google Cloud Functions, Azure Functions). The data splitting module is implemented as a serverless function that triggers upon data ingestion. It parses data into variable-sized chunks, encrypts each chunk using KMS-managed keys specific to each cloud provider, and then uploads the encrypted chunks to the respective cloud object storage buckets. The data assembly module is also a serverless function that fetches encrypted chunks from the chosen cloud providers, decrypts them using the respective KMS, and streams them for reassembly. The cryptographic handling module, responsible for key management and decryption, operates within a FIPS 140-2 Level 3 compliant hardware security module (HSM) provisioned by the cloud provider, ensuring keys never leave the HSM. This architecture scales automatically to petabytes of data and handles millions of requests, with dynamic provisioning of computing resources.

graph TD
    A[Data Ingestion] --> B{Serverless Data Splitting Module};
    B --> C{Encrypt & Upload to S3 (Cloud 1)};
    B --> D{Encrypt & Upload to GCS (Cloud 2)};
    B --> E{Encrypt & Upload to Azure Blob (Cloud 3)};
    C & D & E --> F[Distributed Encrypted Chunks];
    F --> G{Serverless Data Assembly Module};
    G --> H{Decrypt with Cloud KMS/HSM};
    H --> I[Original Data (ONLY in Crypto Module)];

C14.D2.2: Operational Parameter Expansion - Edge Computing Data Security for Industrial IoT

Derivative Title: Edge-Deployed Data Security System for Industrial IoT with Localized Splitting
Enabling Description: This system is tailored for industrial IoT deployments where sensitive sensor data (e.g., from critical infrastructure machinery) needs local processing and secure storage. The distinct data storage facilities are robust, localized edge gateways, each with a secure, hardened computer-accessible storage medium. The data splitting module resides on a central edge aggregation server. It receives raw telemetry data streams, parses them into micro-batches (e.g., 1-second intervals), encrypts these batches using lightweight stream ciphers (e.g., XSalsa20), and distributes the encrypted portions to a subset of nearby edge gateways (e.g., 3 out of 5 closest gateways). The data assembly module also operates on an edge aggregation server, fetching portions from active gateways. The cryptographic handling module, embedded as a hardware security module (HSM) on each edge gateway, performs encryption/decryption. The system is designed to operate with minimal network connectivity to a central cloud, prioritizing local resilience and low-latency processing, with reconstructed data usable only within the edge HSM for local control decisions.

graph TD
    A[Raw Telemetry Data (IoT Sensors)] --> B{Edge Aggregation Server};
    B --> C{Data Splitting Module (Micro-batching)};
    C --> D{Encrypt Micro-batch (XSalsa20)};
    D --> E{Distribute to Edge Gateway 1 (Storage Facility)};
    D --> F{Distribute to Edge Gateway 2 (Storage Facility)};
    D --> G{Distribute to Edge Gateway N (Storage Facility)};
    E & F & G --> H{Edge Aggregation Server (Data Assembly Module)};
    H --> I{Cryptographic Handling Module (Embedded HSM)};
    I --> J[Usable Micro-batch Data (ONLY in Edge HSM)];

C14.D3.1: Cross-Domain Application - Decentralized Financial Transaction Archiving

Derivative Title: Decentralized Financial Transaction Archiving System for Regulatory Compliance
Enabling Description: This system is applied to financial services for long-term, tamper-evident archiving of transaction records to meet regulatory compliance requirements. The distinct data storage facilities are managed by different entities involved in a transaction: the originating bank, the receiving bank, and a central regulatory authority, each operating a secure database. The data splitting module, typically within a bank's secure transaction processing environment, takes a complete transaction record (e.g., SWIFT message, ACH batch) and parses it into three logical portions:

1. Sender details and amount.
2. Recipient details and transaction type.
3. Audit trail hash and timestamp.
   Each portion is then encrypted with separate keys and distributed to the respective distinct data storage facilities. No single facility holds enough information to fully reconstruct the transaction. The data assembly module, invoked by an authorized auditor or investigator, retrieves necessary portions from at least two facilities. The cryptographic handling module, residing within the auditor's secure analysis environment, decrypts and reconstitutes the transaction record, ensuring its usability only within that audited environment.

graph TD
    A[Financial Transaction Record] --> B1{Parse Sender/Amount};
    A --> B2{Parse Recipient/Type};
    A --> B3{Parse Audit Hash/Timestamp};
    B1 --> C1{Encrypt Portion 1};
    B2 --> C2{Encrypt Portion 2};
    B3 --> C3{Encrypt Portion 3};
    C1 --> D1[Originating Bank DB (Facility 1)];
    C2 --> D2[Receiving Bank DB (Facility 2)];
    C3 --> D3[Regulatory Authority Archive (Facility 3)];
    D1 & D2 & D3 --> E[Distributed Encrypted Portions];
    E --> F{Authorized Audit Request};
    F --> G{Data Assembly Module (Auditor)};
    G --> H{Cryptographic Handling Module (Auditor)};
    H --> I[Usable Transaction Record (ONLY in Auditor Crypto Module)];

C14.D4.1: Integration with Emerging Tech - Federated Learning for Key Management

Derivative Title: Federated Learning-Driven Key Management with Secure Data Splitting
Enabling Description: In this system, the cryptographic handling module's master keys, used for encrypting and decrypting data portions, are managed through a federated learning (FL) approach. Instead of a single master key, multiple "key shares" are generated. These key shares are used as parameters in local FL models, which are trained on encrypted portions (or their metadata) to predict optimal splitting parameters or threat levels. The FL server aggregates these model updates (not the raw key shares) without ever seeing individual shares. Periodically, new key shares are generated and distributed, improving the overall security and resilience. The data splitting module and data assembly module are integrated into this FL framework, using the dynamically updated key shares to perform their operations. When data is reconstituted, the cryptographic handling module temporarily brings together sufficient key shares (via secure multi-party computation) to form the master key, performs decryption, and then immediately disperses the key shares, ensuring the original data exists in usable form only momentarily within a protected execution environment.

graph TD
    A[Data to be Secured] --> B{Data Splitting Module};
    B --> C{Encrypt Portions (using Federated Key Shares)};
    C --> D{Distribute to Storage Facilities (N)};
    D --> E[Encrypted Portions & Metadata];
    E --> F{Local FL Model (uses Key Share)};
    F --> G{FL Server (Aggregates Model Updates, NO Key Shares)};
    G -- "Updated Model" --> F;
    F --> H{Data Assembly Module};
    H --> I{Cryptographic Handling Module (MPC for Key Assembly)};
    I --> J[Usable Original Data (ONLY in Crypto Module, fleetingly)];

C14.D5.1: The "Inverse" or Failure Mode - Graceful Degradation of Data Recovery

Derivative Title: Data Security System with Graceful Degradation for Partial Data Recovery
Enabling Description: This system is designed to provide a "graceful degradation" capability in the event of partial storage facility failures. The data splitting module, in addition to creating at least two encrypted portions (e.g., using a (k,n) Shamir's Secret Sharing scheme), also generates progressively degraded versions of the original data (e.g., lower resolution images, text summaries, truncated audio files). These degraded versions are also split and encrypted, but with lower redundancy thresholds or stored in more robust, higher-availability facilities. The data assembly module includes logic to detect the number of available healthy storage facilities. If fewer than k primary facilities are available, it attempts to reconstruct the highest possible fidelity degraded version of the original data from the available secondary portions. The cryptographic handling module still ensures that any reconstructed data (original or degraded) exists in a usable form only within its secure boundaries, but the system guarantees some level of information recovery even under significant operational duress.

graph TD
    A[Original Data] --> B{Data Splitting Module};
    B --> C1{Create Full-Fidelity Portions (k,N Shamir)};
    B --> C2{Create Degraded Portions 1 (k1,N1)};
    B --> C3{Create Degraded Portions 2 (k2,N2)};
    C1 --> D1[Store in Primary Facilities];
    C2 --> D2[Store in Secondary Facilities 1];
    C3 --> D3[Store in Secondary Facilities 2];
    D1 & D2 & D3 --> E[Distributed Encrypted Portions];
    E --> F{Authorized Access/Recovery Request};
    F --> G{Data Assembly Module (Checks Available Facilities)};
    G -- "If < k Primary" --> H{Reconstruct Degraded Data (Best Effort)};
    G -- "If >= k Primary" --> I{Reconstruct Full-Fidelity Data};
    H & I --> J{Cryptographic Handling Module};
    J --> K[Usable (Full or Degraded) Data (ONLY in Crypto Module)];

---

Core Claim 22: Secure cryptographic system

Claim 22: A secure cryptographic system, remotely accessible, comprising: a depository system having at least one server which stores at least one private cryptographic key and enrollment authentication data, wherein each user from a plurality of users is associated with one or more different keys from the at least one private cryptographic key; an authentication engine which compares authentication data received by one of the plurality of users to enrollment authentication data corresponding to the one of the plurality of users and received from the depository system, thereby producing an authentication result; a cryptographic engine which, when the authentication result indicates proper identification of the one of the plurality of users, performs cryptographic functions on behalf of the one of the plurality of users using the associated one or more different keys received from the depository system, without releasing the at least one private cryptographic key to the one of the plurality of users; and a transaction engine connected to route data from the plurality of users to the depository system, the authentication engine, and the cryptographic engine.

---

C22.D1.1: Material & Component Substitution - Hardware Security Modules for Keys

Derivative Title: Secure Cryptographic System with HSM-Protected Private Keys and Authentication
Enabling Description: This system incorporates FIPS 140-3 Level 4 certified Hardware Security Modules (HSMs) directly into the depository system and the cryptographic engine. The depository system stores all private cryptographic keys and enrollment authentication data within dedicated, tamper-resistant HSMs. When the authentication engine, operating in a secure enclave, requests enrollment authentication data, it is retrieved from the HSM through a tightly controlled API, never exposing it in plaintext. Similarly, when the cryptographic engine performs cryptographic functions (e.g., signing, decryption) on behalf of an authenticated user, the associated private keys are retrieved by the cryptographic engine from its own dedicated HSM. All cryptographic operations involving these private keys are executed inside the HSM, ensuring the private keys never leave the hardware boundary and are never exposed in software memory, fulfilling the "without releasing" requirement with the highest level of hardware-rooted trust.

graph TD
    A[User] --> B{Transaction Engine};
    B --> C{Authentication Engine};
    C --> D[Depository System (HSM for Keys & Auth Data)];
    D --> C;
    C -- "Auth Result" --> E{Cryptographic Engine (HSM for Private Keys)};
    E -- "Crypto Function Request" --> B;
    B --> A;
    style D fill:#f9f,stroke:#333,stroke-width:2px;
    style E fill:#f9f,stroke:#333,stroke-width:2px;

C22.D1.2: Material & Component Substitution - Verifiable Delay Functions for Authentication

Derivative Title: Cryptographic System with VDF-Enhanced Anti-Brute-Force Authentication
Enabling Description: The authentication engine in this derivative is augmented with a Verifiable Delay Function (VDF) mechanism. During user enrollment, a unique VDF proof is generated and stored as part of the enrollment authentication data. When a user attempts to authenticate, the authentication data received (e.g., password hash, biometric challenge response) is combined with a fresh nonce. The authentication engine then requires the client device to compute a new VDF proof based on this combined input and a specified delay parameter. The client-side VDF computation is computationally intensive, taking a predetermined minimum time (e.g., 5 seconds) to complete, thus preventing rapid, iterative brute-force attacks. The authentication engine's comparator verifies the VDF proof's correctness and the authentication data simultaneously. A valid, hard-to-forge VDF proof is a prerequisite for a positive authentication result.

graph TD
    A[User] --> B{Client Device};
    B -- "Auth Data + Nonce" --> C{Generate VDF Proof (Client-side, Time-Delayed)};
    C --> D{Transaction Engine};
    D --> E{Authentication Engine (VDF Verifier)};
    E --> F[Depository System (Stores VDF-Enhanced Auth Data)];
    F --> E;
    E -- "Verify Auth Data + VDF Proof" --> G{Authentication Result};
    G --> H{Cryptographic Engine};
    H --> D;
    style E fill:#ccf,stroke:#333,stroke-width:2px;

C22.D2.1: Operational Parameter Expansion - Multi-Cloud Distributed Trust Engine

Derivative Title: Globally Distributed Cryptographic System with Multi-Cloud Resilience
Enabling Description: The entire cryptographic system (depository, authentication, cryptographic, and transaction engines) is distributed across multiple independent cloud providers (e.g., AWS, Azure, GCP) and geographical regions. Each engine component exists as multiple instances within each cloud, providing active-active redundancy. The depository system stores encrypted key shares and enrollment authentication data portions across these disparate cloud storage services, using a (k,n) threshold scheme to prevent single-cloud compromise. The transaction engine employs a global load balancer and intelligent routing to direct user requests to the nearest healthy instance of any engine, ensuring low latency and high availability. Authentication and cryptographic operations are performed by the closest available engine instance, utilizing cryptographic key shares retrieved from the distributed depository. The system is designed to tolerate the complete failure of one or more cloud providers or entire geographical regions while maintaining full functionality.

graph TD
    subgraph Cloud Provider A (Region 1)
        TA1(Transaction Engine A1)
        AA1(Auth Engine A1)
        CA1(Crypto Engine A1)
        DA1(Depository A1)
    end
    subgraph Cloud Provider B (Region 2)
        TB1(Transaction Engine B1)
        AB1(Auth Engine B1)
        CB1(Crypto Engine B1)
        DB1(Depository B1)
    end
    subgraph Cloud Provider N (Region N)
        TN1(Transaction Engine N1)
        AN1(Auth Engine N1)
        CN1(Crypto Engine N1)
        DN1(Depository N1)
    end
    User --> GlobalLB(Global Load Balancer)
    GlobalLB --> TA1
    GlobalLB --> TB1
    GlobalLB --> TN1
    TA1 <--> DA1
    TA1 <--> AA1
    TA1 <--> CA1
    TB1 <--> DB1
    TB1 <--> AB1
    TB1 <--> CB1
    TN1 <--> DN1
    TN1 <--> AN1
    TN1 <--> CN1
    AA1 <--> DA1
    CA1 <--> DA1
    AB1 <--> DB1
    CB1 <--> DB1
    AN1 <--> DN1
    CN1 <--> DN1
    User -- "Requests" --> GlobalLB

C22.D3.1: Cross-Domain Application - Digital Identity for National Citizens

Derivative Title: National Digital Identity System for Citizen Services
Enabling Description: This cryptographic system functions as a national digital identity platform. The depository system, operated by a government agency, stores private cryptographic keys and highly secure enrollment authentication data (e.g., multi-modal biometrics, national ID numbers) for all citizens. Each citizen is associated with unique private keys for signing official documents and authenticating for public services. The authentication engine verifies citizen identity against enrollment data when accessing services like tax filing, voting, or passport renewal. Upon successful authentication, the cryptographic engine, without releasing the private key, performs digital signing of government forms, attestation of identity for online transactions, or generation of verifiable credentials on behalf of the citizen. The transaction engine routes citizen requests from various government portals and mobile applications to the appropriate engines, ensuring secure, verifiable interactions with public services.

graph TD
    A[Citizen (User)] --> B{Government Portal/App};
    B --> C{Transaction Engine (Routes Requests)};
    C --> D{Authentication Engine};
    C --> E{Cryptographic Engine};
    D --> F[Depository System (Citizen Keys & Biometrics)];
    E --> F;
    F --> D;
    D -- "Auth Result" --> E;
    E -- "Signed Document/VC" --> B;
    B --> A;

C22.D4.1: Integration with Emerging Tech - Behavioral Biometrics and AI-Driven Risk Scoring

Derivative Title: AI-Enhanced Secure Cryptographic System with Continuous Behavioral Biometrics
Enabling Description: The authentication engine in this system integrates continuous, passive behavioral biometrics (e.g., typing cadence, mouse movement patterns, gait analysis from device sensors) and an AI-driven risk scoring module. During enrollment, a baseline behavioral profile is established. The authentication engine continuously monitors the user's interaction throughout a session. The AI module, utilizing deep neural networks trained on vast datasets of user interaction, assigns a real-time risk score based on deviations from the baseline and known fraud patterns. The initial authentication (e.g., fingerprint, password) uses a static comparison. However, ongoing cryptographic functions by the cryptographic engine are permitted only if the AI-driven risk score remains below a dynamic threshold. If the risk score exceeds the threshold, the cryptographic engine automatically suspends operations or triggers re-authentication, without explicitly prompting the user, providing a "step-up" authentication that is context-aware and continuous.

graph TD
    A[User] --> B{Transaction Engine};
    B --> C{Authentication Engine};
    C --> D[Depository (Enrollment Auth Data & Behavioral Baseline)];
    D --> C;
    C -- "Initial Auth Result" --> E{Cryptographic Engine};
    B -- "Continuous Interaction" --> F{Behavioral Biometrics Module};
    F --> G{AI Risk Scoring Module (Deep NN)};
    G --> E;
    E -- "Risk Score OK" --> H[Perform Crypto Functions];
    E -- "Risk Score HIGH" --> I{Suspend Crypto / Re-Auth};
    H --> B;

C22.D5.1: The "Inverse" or Failure Mode - Failsafe Cryptographic Freeze

Derivative Title: Failsafe Cryptographic Freeze System for Catastrophic Compromise
Enabling Description: This secure cryptographic system incorporates a "Failsafe Cryptographic Freeze" mechanism designed for rapid response to detected catastrophic compromise events (e.g., exfiltration attempt from depository, zero-day exploit on cryptographic engine). A dedicated "Watchdog Module" continuously monitors the integrity of the depository system and cryptographic engine using a combination of heuristics, intrusion detection system alerts, and hardware-level attestation. Upon detection of a confirmed catastrophic compromise, the Watchdog Module, through a hardware-enforced mechanism (e.g., triggering a self-locking fuse or disabling cryptographic co-processors), immediately and irrevocably causes the cryptographic engine to cease all cryptographic operations. All active sessions are terminated, and the private keys within the cryptographic engine (which were never released) are moved to an immutable, forensic-only state within the HSM, preventing further use but allowing for post-compromise analysis without further risk of key exfiltration. The system prioritizes key security over service availability in such extreme scenarios.

graph TD
    A[User] --> B{Transaction Engine};
    B --> C{Authentication Engine};
    C --> D[Depository System (Keys & Auth Data)];
    D --> C;
    C -- "Auth Result" --> E{Cryptographic Engine};
    E -- "Crypto Function" --> B;
    WDM(Watchdog Module) --> D;
    WDM --> E;
    subgraph Monitoring
        D -- "Integrity Checks" --> WDM
        E -- "Activity Logs" --> WDM
        WDM -- "Detect Compromise" --> F{Failsafe Trigger (Hardware Enforced)};
    end
    F --> G[Cryptographic Engine FREEZE];
    G --> H[Private Keys to Forensic-Only State];
    G --> I{Terminate All Sessions};

---

Core Claim 30: Method of facilitating cryptographic functions

Claim 30: A method of facilitating cryptographic functions, comprising: associating a user from a plurality of users with one or more keys from a plurality of private cryptographic keys stored on a secure server; receiving authentication data from the user; comparing the authentication data received to authentication data corresponding to the user, thereby verifying the identity of the user; and utilizing the one or more keys to perform cryptographic functions without releasing the one or more keys to the user.

---

C30.D1.1: Material & Component Substitution - Multi-Party Computation for Key Utilization

Derivative Title: Multi-Party Computation (MPC) Method for Private Key Utilization
Enabling Description: This method enhances the "utilizing the one or more keys" step by employing Secure Multi-Party Computation (MPC) protocols. Instead of the entire private key residing on a single secure server, the private key is generated and stored as multiple shares distributed across N independent, secure computing nodes (e.g., utilizing Shamir's Secret Sharing with an (N-1, N) threshold). Upon successful user authentication, the cryptographic function request is routed to these N nodes. The cryptographic function (e.g., digital signing) is then performed collaboratively by the N nodes using an MPC protocol (e.g., based on SPDZ or ABY3 frameworks). Each node performs its part of the computation on its share of the private key and intermediate encrypted values, without ever reconstructing the full private key on any single node. The final cryptographic output is then assembled from the individual node results and returned to the user, ensuring the private key is never fully assembled or released to any single entity or the user.

graph TD
    A[User] --> B{Auth Data};
    B --> C{Secure Server (Authentication)};
    C -- "Auth Result: Success" --> D{Crypto Function Request};
    D --> E{MPC Coordinator};
    E --> F1[Secure Computing Node 1 (Key Share 1)];
    E --> F2[Secure Computing Node 2 (Key Share 2)];
    E --> FN[Secure Computing Node N (Key Share N)];
    F1 -- "MPC Protocol" --> F2;
    F2 -- "MPC Protocol" --> FN;
    FN -- "Partial Results" --> E;
    E -- "Assemble Final Output" --> G[Cryptographic Function Result];
    G --> A;

C30.D1.2: Material & Component Substitution - Decentralized Identifiers (DIDs) for User Association

Derivative Title: Decentralized Identifier (DID)-Based User Key Association Method
Enabling Description: This method integrates Decentralized Identifiers (DIDs) for user association with private cryptographic keys. Instead of a centralized server storing all user identities, each user is associated with a DID, which is a globally unique, resolvable identifier that does not require a centralized registration authority. The secure server stores a mapping between the user's DID and a set of private cryptographic keys. The authentication data received from the user includes a verifiable credential (VC) signed by a trusted issuer, which references their DID. The secure server verifies the VC and the user's identity through the DID resolution process. Upon successful verification, the method utilizes the private keys linked to the user's DID to perform cryptographic functions, ensuring that the identity management is decentralized while key management remains server-centric and keys are not released.

graph TD
    A[User] --> B{User Wallet (Auth Data / Verifiable Credential)};
    B --> C{Secure Server (Receives VC)};
    C --> D{DID Resolver (Verifies VC & DID)};
    D --> E[Secure Server (Maps DID to Private Keys)];
    E --> F{Utilize Keys (Crypto Functions)};
    F -- "Crypto Result" --> G[User];

C30.D2.1: Operational Parameter Expansion - Ephemeral, Single-Use Key Generation

Derivative Title: Ephemeral, Single-Use Private Key Generation and Utilization Method
Enabling Description: This method extends the concept of server-side key management by generating private cryptographic keys that are ephemeral and strictly single-use for each cryptographic function request. Upon successful user authentication, instead of retrieving a pre-existing long-term private key, the secure server's cryptographic module generates a fresh, new private cryptographic key and its corresponding public key pair on-the-fly. This newly generated key is used immediately to perform the requested cryptographic function (e.g., signing a single transaction, encrypting a single message). Immediately after the function is completed and the result is returned, the ephemeral private key is cryptographically shredded from memory, ensuring zero persistence. This significantly reduces the window of opportunity for key compromise and enhances forward secrecy, as no two cryptographic operations rely on the same private key.

graph TD
    A[User] --> B{Auth Data};
    B --> C{Secure Server (Authentication)};
    C -- "Auth Success" --> D{Crypto Function Request};
    D --> E{Generate Ephemeral Private Key (On-the-fly)};
    E --> F{Utilize Ephemeral Key (Perform Crypto Function)};
    F -- "Crypto Result" --> G{User};
    F --> H{Cryptographically Shred Ephemeral Key};

C30.D3.1: Cross-Domain Application - Secure Digital Currency Transaction Signing

Derivative Title: Secure Digital Currency Transaction Signing Method for User Wallets
Enabling Description: This method is specifically applied to digital currency (cryptocurrency) transactions. The secure server is operated by a trusted digital asset custodian or a decentralized autonomous organization (DAO). It stores fragmented private keys for users' cryptocurrency wallets. Upon receiving a request from a user to sign a cryptocurrency transaction (e.g., spending Bitcoin, transferring Ethereum tokens), the system first performs user authentication. After identity verification, the secure server utilizes the associated fragmented private key(s) to sign the transaction, directly broadcasting the signed transaction to the blockchain network. Critically, the user's private key material is never exposed to the user's client-side wallet application, only the signed transaction is returned. This provides enhanced security against client-side malware and phishing attacks that aim to steal private keys, shifting the custody risk to the highly secured server environment.

graph TD
    A[User] --> B{Client Wallet (Transaction Request)};
    B --> C{Secure Server (Authentication)};
    C -- "Auth Success" --> D{Retrieve Fragmented Private Key};
    D --> E{Utilize Key (Sign Crypto Transaction)};
    E -- "Signed Transaction" --> F{Broadcast to Blockchain Network};
    F --> G[Blockchain];
    E --> H{User (Confirmation)};

C30.D4.1: Integration with Emerging Tech - AI-Driven Risk-Adaptive Cryptographic Function Provisioning

Derivative Title: AI-Driven Risk-Adaptive Cryptographic Function Method
Enabling Description: The method incorporates an AI-driven risk assessment engine that continuously evaluates contextual parameters (e.g., user's current location, device posture, time of day, transaction value, historical behavior patterns) in real-time. After initial user authentication, the AI engine dynamically determines the "trust level" for the current session. Based on this trust level, the secure server adaptively determines which cryptographic functions are permitted and with what strength. For example, a low-risk session might allow basic document signing, while a high-risk session (e.g., large financial transfer from an unusual location) might require additional multi-factor authentication or restrict access to only viewing operations. The secure server then utilizes the appropriate keys to perform the cryptographic functions, without releasing them, enforcing dynamic security policies based on AI-derived risk assessment.

graph TD
    A[User] --> B{Auth Data};
    B --> C{Secure Server (Authentication)};
    C -- "Auth Success" --> D{Contextual Data (Location, Device, Time, Value)};
    D --> E{AI Risk Assessment Engine (Real-time)};
    E -- "Trust Level Score" --> F{Policy Enforcement Module};
    F -- "Allowed Crypto Ops & Strength" --> G{Utilize Keys (Perform Crypto Functions)};
    G -- "Crypto Result" --> H[User];

C30.D5.1: The "Inverse" or Failure Mode - Revocable Delegated Authority for Limited Functions

Derivative Title: Method for Revocable Delegated Authority for Cryptographic Functions
Enabling Description: This method includes a feature for granting revocable, limited delegated authority for cryptographic functions. After a user is authenticated, they can explicitly authorize a third-party agent (e.g., a power-of-attorney, a temporary assistant) to perform a specific subset of cryptographic functions (e.g., view encrypted documents, sign approvals below a certain value) for a defined period, using the user's associated private keys. The secure server records this delegation, including its scope and duration. When the agent attempts to perform a delegated function, the server authenticates the agent, checks the delegation's validity and scope, and if authorized, utilizes the user's keys to perform the function on behalf of the user without releasing the keys to the agent. The user retains the ability to instantly revoke this delegated authority at any time, rendering any further attempts by the agent unauthorized.

graph TD
    A[User] --> B{Secure Server (Auth)};
    B -- "Auth Success" --> C{Delegate Authority Request (to Agent, Scope, Duration)};
    C --> D[Secure Server (Records Delegation)];
    SA[Third-Party Agent] --> E{Agent Auth Data};
    E --> F{Secure Server (Authenticates Agent)};
    F -- "Auth Success & Delegation Check" --> G{Utilize User's Keys (Perform delegated Crypto Function)};
    G -- "Crypto Result" --> SA;
    A -- "Revoke Delegation" --> D;

---

Core Claim 38: System for secure authentication

Claim 38: A system for secure authentication, comprising: a plurality of authentication engines, wherein each authentication engine receives enrollment authentication data designed to uniquely identify a user to a degree of certainty, wherein each authentication engine receives current authentication data to compare to the enrollment authentication data, and wherein each authentication engine determines an authentication result; and a redundancy system which receives the authentication result of at least two of the authentication engines and determines whether the user has been uniquely identified.

---

C38.D1.1: Material & Component Substitution - Multi-Modal Biometric Sensors with Liveness Detection

Derivative Title: Multi-Modal Biometric Authentication System with AI-Powered Liveness Detection
Enabling Description: This secure authentication system integrates advanced multi-modal biometric sensors at the user interface. Each authentication engine is dedicated to processing a specific biometric modality: one for 3D facial recognition (using structured light or time-of-flight sensors with AI-powered liveness detection algorithms to prevent spoofing from photos or masks), another for active voice print analysis (analyzing intonation, cadence, and performing challenge-response phrases to detect deepfakes), and a third for vascular pattern recognition (e.g., finger vein or palm vein scanning with IR illumination for sub-dermal liveness detection). Each engine receives enrollment data specific to its modality and compares it to current data, producing a confidence-based authentication result. The redundancy system then employs a weighted fusion algorithm to combine these results, potentially requiring a higher confidence from the liveness-detected biometrics to determine unique identification.

graph TD
    A[User] --> B1(3D Facial Sensor + Liveness AI);
    A --> B2(Voice Print Sensor + Deepfake Detection);
    A --> B3(Vascular Pattern Sensor + IR Liveness);
    B1 --> C1(Auth Engine 1 - Facial);
    B2 --> C2(Auth Engine 2 - Voice);
    B3 --> C3(Auth Engine 3 - Vascular);
    C1 -- "Auth Result (Confidence)" --> D{Redundancy System (Weighted Fusion)};
    C2 -- "Auth Result (Confidence)" --> D;
    C3 -- "Auth Result (Confidence)" --> D;
    D --> E[User Uniquely Identified? (YES/NO)];

C38.D1.2: Material & Component Substitution - Decentralized Identifiers (DIDs) as Authentication Data

Derivative Title: Decentralized Identifier (DID)-Based Secure Authentication System
Enabling Description: In this system, the "enrollment authentication data" and "current authentication data" are represented by Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs). Each authentication engine is configured to verify a specific type of VC issued by different trusted parties (e.g., a VC from a government-issued identity provider, a VC from an employer, a VC from a bank). When a user presents authentication data, it consists of a set of VCs signed by their respective issuers, along with a proof of control over their DID. Each authentication engine validates one VC against its stored enrollment data (which includes a reference to the user's DID and accepted VC schemas). The redundancy system aggregates the verification results from multiple engines (e.g., requiring at least two valid VCs from different issuers) to determine if the user, identified by their DID, has been uniquely authenticated. This provides a privacy-preserving and robust authentication framework.

graph TD
    A[User (DID Holder)] --> B{User Wallet (Presents VCs)};
    B --> C1(Auth Engine 1 - Verifies Gov't VC);
    B --> C2(Auth Engine 2 - Verifies Employer VC);
    B --> C3(Auth Engine 3 - Verifies Bank VC);
    C1 -- "VC Verification Result" --> D{Redundancy System (Quorum Check)};
    C2 -- "VC Verification Result" --> D;
    C3 -- "VC Verification Result" --> D;
    D --> E[User Uniquely Identified (by DID)?];

C38.D2.1: Operational Parameter Expansion - Continuous and Adaptive Authentication

Derivative Title: Continuous and Adaptive Authentication System with Dynamic Policy Enforcement
Enabling Description: This system implements continuous authentication beyond an initial login. The plurality of authentication engines constantly monitors various user and environmental factors throughout an active session. For instance, one engine monitors typing cadence and mouse behavior, another monitors network location changes and IP reputation, and a third monitors application usage patterns. Each engine provides a continuous, real-time risk score. The redundancy system receives these ongoing risk scores. Instead of a binary "identified/not identified" result, it maintains a dynamic "trust level" for the user. If the trust level drops below a threshold (e.g., due to unusual behavior or change in network context), the system adapts by:

1. Silently increasing logging.
2. Prompting for step-up authentication (e.g., re-entry of a biometric).
3. Automatically restricting access to sensitive features.
4. Ultimately, terminating the session.
   The system thus adapts its security posture to the ongoing context and perceived risk, providing robust, dynamic protection.

graph TD
    A[User Session Start] --> B(Initial Authentication);
    B --> C1(Auth Engine - Typing/Mouse Biometrics);
    B --> C2(Auth Engine - Network Context/IP);
    B --> C3(Auth Engine - Application Usage Patterns);
    C1 -- "Real-time Risk Score" --> D{Redundancy System (Dynamic Trust Level)};
    C2 -- "Real-time Risk Score" --> D;
    C3 -- "Real-time Risk Score" --> D;
    D -- "Trust Level changes" --> E{Adaptive Policy Enforcement};
    E -- "Increase Logging / Step-Up Auth" --> C1;
    E -- "Restrict Access / Terminate Session" --> F[Secure Session State];
    F --> A;

C38.D3.1: Cross-Domain Application - High-Security Data Center Physical Access

Derivative Title: Multi-Layered Physical Access Authentication System for Data Centers
Enabling Description: This system is deployed for secure physical access control in a high-security data center. The plurality of authentication engines is strategically placed at different security checkpoints (e.g., perimeter gate, building entrance, server rack row). Each engine integrates a distinct biometric sensor:

1. Engine 1 (Perimeter): Long-range gait analysis and thermal signature recognition.
2. Engine 2 (Building Entrance): Multi-spectral iris scanner and fingerprint reader with active liveness detection.
3. Engine 3 (Server Room): Hand geometry and voice print verification (challenge-response).
   Each engine receives enrollment data for authorized personnel and current data, producing an authentication result with a confidence score. The redundancy system, located in a secure operations center, receives results from at least two engines. It then determines if the user (i.e., the person attempting access) has been uniquely identified, potentially requiring sequential positive authentication results across multiple checkpoints to grant progressively higher levels of physical access.

graph TD
    A[Personnel Arrives] --> B1(Engine 1 - Gait/Thermal (Perimeter));
    B1 --> C1(Auth Result);
    C1 --> D{Redundancy System};
    D -- "Access Granted to Building" --> B2(Engine 2 - Iris/Fingerprint (Entrance));
    B2 --> C2(Auth Result);
    C2 --> D;
    D -- "Access Granted to Room" --> B3(Engine 3 - Hand/Voice (Server Room));
    B3 --> C3(Auth Result);
    C3 --> D;
    D -- "Final Access Decision" --> E[Physical Access Granted/Denied];

C38.D4.1: Integration with Emerging Tech - AI/ML Fusion of Authentication Results with Adversarial Training

Derivative Title: AI/ML Fusion Authentication System with Adversarial Training for Robustness
Enabling Description: The redundancy system in this derivative utilizes a machine learning model, specifically a deep neural network, for fusing authentication results. Each authentication engine (e.g., processing different biometrics, tokens, or contextual data) outputs a vector of features and a confidence score. These outputs are fed as inputs to the ML fusion model. This ML model is continuously trained using both real-world authentication data and synthetic adversarial examples (e.g., generated using Generative Adversarial Networks - GANs) representing sophisticated spoofing attempts. The adversarial training significantly enhances the model's ability to distinguish legitimate users from malicious actors, even those employing advanced evasion techniques. The fusion model produces a unified, nuanced authentication decision (e.g., a probabilistic score or a categorical risk level) that is far more robust than simple thresholding or weighted averages.

graph TD
    A[User Input] --> B1(Auth Engine 1 - Features/Score);
    A --> B2(Auth Engine 2 - Features/Score);
    A --> BN(Auth Engine N - Features/Score);
    B1 & B2 & BN --> C{ML Fusion Model (Deep NN)};
    C -- "Real-time Data" --> D(Adversarial Training Module - GANs);
    D -- "Synthetic Attacks" --> C;
    C --> E[Unified Authentication Decision (Probabilistic)];

C38.D5.1: The "Inverse" or Failure Mode - Deceptive Authentication for Intruder Tracking

Derivative Title: Deceptive Authentication System for Covert Intruder Engagement and Tracking
Enabling Description: This system includes a "deceptive authentication" mode designed to covertly identify, engage, and track malicious intruders. If the initial authentication results from the plurality of engines strongly indicate a malicious attempt (e.g., multiple failed biometric attempts from a known suspicious IP address, or detection of specific attack signatures), the redundancy system does not immediately deny access. Instead, it subtly shifts into a deceptive mode. It then directs the intruder to a set of specially crafted "honey-pot" authentication engines that simulate a successful authentication, providing access to a decoy environment (e.g., fake data, simulated control panels). All interactions within this decoy environment are logged in extreme detail, allowing the system operators to track the intruder's methods, tools, and objectives, without compromising legitimate systems or revealing the deception until an appropriate intervention is planned.

graph TD
    A[User Attempt] --> B1(Auth Engine 1);
    A --> B2(Auth Engine 2);
    B1 & B2 --> C{Redundancy System};
    C -- "Strong Malicious Indicator" --> D{Activate Deceptive Mode};
    D --> E(Honey-Pot Auth Engine 1);
    D --> F(Honey-Pot Auth Engine 2);
    E & F --> G{Simulated Success (Access to Decoy Env)};
    G --> H[Intruder (Engaged in Decoy Env)];
    G --> I[Detailed Logging & Tracking];
    C -- "Legitimate User" --> J[Normal Authentication Flow];

---

Core Claim 46: Method of storing authentication data

Claim 46: A method of storing any type of data, including, but not limited to, authentication data comprising: receiving data at a trust engine; combining at the trust engine the data with a first substantially random value to form a first combined value; combining the data with a second substantially random value to form a second combined value; creating a first pairing of the first substantially random value with the second combined value; creating a second pairing of the first substantially random value with the second substantially random value; storing one of the first and second pairings in a first computer accessible storage medium; and storing the other of the first and second pairings in a second computer accessible storage medium remote from the first computer accessible storage medium.

---

C46.D1.1: Material & Component Substitution - Quantum Random Number Generators (QRNGs)

Derivative Title: Quantum-Enhanced Secure Data Storage with QRNG-Derived Random Values
Enabling Description: This method employs quantum random number generators (QRNGs) to produce the first and second substantially random values (R1 and R2). The QRNGs are integrated as dedicated hardware modules within the trust engine, ensuring true randomness derived from quantum phenomena (e.g., photon emission, vacuum fluctuations). When authentication data (D_auth) is received, the trust engine generates R1 and R2 from the QRNGs. CV1 (= D_auth + R1) and CV2 (= D_auth + R2) are computed using a cryptographically secure XOR operation. P1 = (R1, CV2) and P2 = (R1, R2) are formed. P1 and P2 are then stored in secure storage mediums. This ensures the foundational randomness is uncompromisable by classical means, enhancing the security properties of the data splitting, where the "combination" operation is interpreted as an XOR for simplicity.

graph TD
    A[Auth Data (D_auth)] --> B{Trust Engine (QRNG)};
    B -- "Generate R1" --> C1[First Random Value (R1)];
    B -- "Generate R2" --> C2[Second Random Value (R2)];
    D_auth & C1 --> D1{Compute CV1 (D_auth XOR R1)};
    D_auth & C2 --> D2{Compute CV2 (D_auth XOR R2)};
    C1 & D2 --> E1{Create P1 (R1, CV2)};
    C1 & C2 --> E2{Create P2 (R1, R2)};
    E1 --> F1[First Storage Medium];
    E2 --> F2[Second Storage Medium (Remote)];
    F1 & F2 --> G{Reconstruct D_auth (CV2 XOR R2)};

C46.D1.2: Material & Component Substitution - Immutable Object Storage for Pairings

Derivative Title: Immutable Object Storage Method for Randomly Paired Authentication Data
Enabling Description: This method utilizes immutable object storage systems as the computer-accessible storage mediums for the pairings. Specifically, one pairing (P1) is stored in an Amazon S3 Glacier Vault Lock-enabled bucket, ensuring WORM (Write Once Read Many) compliance and immutability for a defined retention period. The other pairing (P2) is stored in a geographically remote Google Cloud Storage bucket configured with Object Lock in retention mode. The "combining" operation is a simple bitwise XOR. Once P1 and P2 are written, they cannot be deleted or modified until their respective retention periods expire, even by root users. This provides strong guarantees against tampering or accidental deletion of the authentication data shares, effectively creating an unalterable audit trail for the storage of these crucial pairings.

graph TD
    A[Auth Data (D_auth)] --> B{Trust Engine};
    B -- "Generate R1, R2" --> C{Combine D_auth with R1, R2};
    C --> D1{Create P1 (R1, CV2)};
    C --> D2{Create P2 (R1, R2)};
    D1 --> E1[Amazon S3 Glacier Vault Lock (Immutable)];
    D2 --> E2[Google Cloud Storage Object Lock (Remote, Immutable)];
    E1 & E2 --> F{Reconstruct D_auth};

C46.D2.1: Operational Parameter Expansion - Dynamic Re-Splitting with Ephemeral Randomness

Derivative Title: Dynamic Re-Splitting Method with Time-Varying Randomness for Enhanced Security
Enabling Description: This method introduces a dynamic re-splitting mechanism. The authentication data (D_auth) is initially combined with R1 and R2, and pairings P1 and P2 are stored. However, at predetermined intervals (e.g., every 24 hours) or upon detection of a high-risk event (e.g., suspected compromise of a storage medium), the trust engine initiates a re-splitting process. It retrieves P1 and P2, reconstructs D_auth, then generates new substantially random values (R1', R2'). It then creates new combined values (CV1' = D_auth + R1', CV2' = D_auth + R2') and new pairings (P1' = (R1', CV2'), P2' = (R1', R2')). These new pairings P1' and P2' are stored in potentially new remote storage mediums, and the old pairings P1 and P2 are cryptographically shredded. This continuous refreshment of the random components and storage locations significantly limits the utility of any compromised static pairings over time.

graph TD
    A[Auth Data (D_auth)] --> B{Trust Engine (Initial Split)};
    B -- "Generate R1, R2" --> C{Store P1(R1,CV2), P2(R1,R2)};
    C --> D[Storage Mediums (Initial)];
    subgraph Dynamic Re-Splitting Cycle
        E{Timer / Risk Event Trigger} --> F{Retrieve P1, P2};
        F --> G{Reconstruct D_auth};
        G --> H{Generate New R1', R2'};
        H --> I{Create New P1'(R1',CV2'), P2'(R1',R2')};
        I --> J[Storage Mediums (New)];
        J --> K{Cryptographically Shred Old P1, P2};
    end
    K --> C;

C46.D3.1: Cross-Domain Application - Secure Firmware Key Distribution for Embedded Systems

Derivative Title: Secure Firmware Key Distribution Method for Distributed Embedded Systems
Enabling Description: This method is applied to securely distributing and storing cryptographic keys used for signing firmware updates in a fleet of embedded systems (e.g., IoT devices, industrial controllers). The "data" is the firmware signing private key for a specific device or device class. This private key is received at a trust engine (e.g., a secure provisioning server). It is combined with two substantially random values (R1, R2) to form CV1 and CV2. P1=(R1, CV2) and P2=(R1, R2) are created. P1 is stored in a secure hardware enclave (e.g., a TPM or Secure Element) on the embedded device itself. P2 is stored in a remote, cloud-based secure key vault managed by the manufacturer. Neither the device nor the cloud vault alone possesses the full firmware signing key. When a firmware update needs to be signed, both P1 and P2 are retrieved by a secure, temporary signing service which reconstructs the private key only momentarily within a trusted execution environment, signs the firmware, and then immediately destroys the key.

graph TD
    A[Firmware Signing Private Key] --> B{Trust Engine (Provisioning Server)};
    B -- "Generate R1, R2" --> C{Combine Key with R1, R2};
    C --> D1{Create P1 (R1,CV2)};
    C --> D2{Create P2 (R1,R2)};
    D1 --> E1[Embedded Device (Secure Enclave - stores P1)];
    D2 --> E2[Manufacturer Cloud Key Vault (Remote - stores P2)];
    E1 & E2 --> F{Firmware Signing Service (Trusted Execution Env)};
    F --> G{Reconstruct Key, Sign Firmware, Destroy Key};
    G --> H[Signed Firmware];

C46.D4.1: Integration with Emerging Tech - Verifiable Random Functions (VRFs) for Randomness

Derivative Title: Blockchain-Anchored Data Storage with VRF-Generated Random Values
Enabling Description: This method integrates Verifiable Random Functions (VRFs) with a blockchain to generate the first and second substantially random values (R1 and R2). The trust engine triggers a VRF computation, which generates a pseudo-random output and a proof that this output was correctly generated by the VRF using a secret key. This VRF output serves as R1. A second, independent VRF computation generates R2. Both the VRF outputs (R1, R2) and their proofs are published to a public blockchain, making the randomness verifiable and auditable. The authentication data (D_auth) is then combined with R1 and R2 to form CV1 and CV2, and pairings P1 and P2 are created and stored in remote facilities. The blockchain record of R1 and R2 serves as an immutable, transparent source of the random values used, enhancing trust and preventing manipulation of the splitting process.

graph TD
    A[Auth Data (D_auth)] --> B{Trust Engine};
    B --> C1{VRF Computation 1 (Generates R1 + Proof1)};
    B --> C2{VRF Computation 2 (Generates R2 + Proof2)};
    C1 & C2 --> D{Publish R1, R2, Proof1, Proof2 to Blockchain};
    D --> E[Blockchain (Verifiable Randomness Source)];
    D_auth & C1 --> F1{Combine D_auth with R1 (CV1)};
    D_auth & C2 --> F2{Combine D_auth with R2 (CV2)};
    C1 & F2 --> G1{Create P1 (R1, CV2)};
    C1 & C2 --> G2{Create P2 (R1, R2)};
    G1 --> H1[First Storage Medium];
    G2 --> H2[Second Storage Medium (Remote)];
    H1 & H2 & E --> I{Reconstruct D_auth (Verify R1,R2 from Blockchain)};

C46.D5.1: The "Inverse" or Failure Mode - Time-Locked Irreversible Partial Corruption

Derivative Title: Time-Locked Irreversible Partial Corruption Method for Data Decommissioning
Enabling Description: This method includes a deliberate "irreversible partial corruption" feature, intended for secure data decommissioning or legal hold expiry. The "combining" steps for CV1 and CV2 are performed normally. However, after the pairings P1 and P2 are stored, a time-lock mechanism is associated with one of the pairings (e.g., P1). After a predetermined time T (e.g., data retention policy expiry), a scheduled process within the first storage medium (containing P1) intentionally alters a non-recoverable part of P1 (e.g., by flipping a random bit within the CV2 component of P1). This small, targeted corruption renders the entire original authentication data (D_auth) irrecoverable by mathematical means, even if the other pairing (P2) is intact, because the corrupted P1 can no longer correctly reconstruct D_auth when combined with P2. The process records this corruption event in an immutable audit log, ensuring that data is permanently decommissioned without full deletion.

graph TD
    A[Auth Data (D_auth)] --> B{Trust Engine};
    B -- "Generate R1, R2" --> C{Combine D_auth with R1, R2};
    C --> D1{Create P1 (R1,CV2)};
    C --> D2{Create P2 (R1,R2)};
    D1 --> E1[First Storage Medium (with Time-Lock)];
    D2 --> E2[Second Storage Medium (Remote)];
    E1 -- "Time T Reached" --> F{Intentional Partial Corruption of P1};
    F --> G[P1 (Corrupted)];
    G & E2 --> H{Attempted Reconstruction (FAILS)};
    E1 -- "Before Time T" --> I{Authorized Reconstruction (SUCCESS)};

---

Combination Prior Art Scenarios

Here are three combination prior art scenarios where the concepts of US Patent 8904194 are integrated with existing open-source standards. These scenarios describe systems or methods that a person having ordinary skill in the art could readily construct, rendering similar future claims obvious.

Combination Prior Art Scenario 1: Secure Document Storage with IPFS and US8904194 Principles

Enabling Description: A system for secure document storage that combines the data splitting and encryption principles of US8904194 with the InterPlanetary File System (IPFS) open-source distributed file system. A client-side application or a secure gateway parses a document (data to be secured) into multiple chunks. Each chunk is then encrypted using AES-256-GCM. These encrypted chunks become the "at least two portions of data" as described in Claim 1. Instead of proprietary "distinct data storage facilities," the encrypted chunks are added to an IPFS network. Each chunk receives a unique Content Identifier (CID) from IPFS. These CIDs are then stored in a secure, private metadata store (e.g., a local database or a private blockchain ledger). To reconstruct the document, the client-side application retrieves the CIDs from the metadata store, fetches the corresponding encrypted chunks from the IPFS network (which itself replicates data across many nodes), decrypts the chunks, and reassembles the original document. Crucially, any single IPFS node or retrieved CID/chunk is insufficient to reconstruct the original document, aligning with Claim 1's "any one individual data storage facility does not include sufficient encrypted data to reconstruct the original data" principle. The cryptographic handling and assembly are performed client-side within a browser extension or a local application using established open-source cryptographic libraries (e.g., OpenSSL).

sequenceDiagram
    participant User
    participant ClientApp
    participant IPFSNetwork
    participant MetadataStore

    User->>ClientApp: Upload Document
    ClientApp->>ClientApp: Parse Document into Chunks
    ClientApp->>ClientApp: Encrypt Chunks (AES-256-GCM)
    ClientApp->>IPFSNetwork: Add Encrypted Chunks (get CIDs)
    IPFSNetwork-->>ClientApp: Return CIDs for each chunk
    ClientApp->>MetadataStore: Store CIDs
    User->>ClientApp: Request Document
    ClientApp->>MetadataStore: Retrieve CIDs
    MetadataStore-->>ClientApp: Return CIDs
    ClientApp->>IPFSNetwork: Fetch Encrypted Chunks by CIDs
    IPFSNetwork-->>ClientApp: Return Encrypted Chunks
    ClientApp->>ClientApp: Decrypt Chunks
    ClientApp->>ClientApp: Reassemble Document
    ClientApp->>User: Display Document

Combination Prior Art Scenario 2: Secure User Authentication with OpenID Connect and US8904194 Principles

Enabling Description: This scenario describes a secure authentication system employing the principles of US8904194 for storing enrollment authentication data, integrated with the OpenID Connect (OIDC) open-source standard for identity layer on top of OAuth 2.0. The "trust engine" (as per Claim 22) acts as the OIDC Provider. During user enrollment, sensitive authentication data (e.g., biometric template, high-entropy password hash) is received by the OIDC Provider. The OIDC Provider then uses a data splitting module (as per Claim 14) to create multiple encrypted portions of this enrollment authentication data, distributing them across a plurality of distinct, geographically remote backend data storage facilities (e.g., different relational databases or object stores). Any single storage facility does not hold enough information to reconstruct the original enrollment data. When a user attempts to authenticate (ee.g., via a web browser to an OIDC Relying Party), the OIDC Provider receives the current authentication data. Its authentication engine (as per Claim 22) then retrieves and reassembles the enrollment data from the distributed facilities. The engine compares the current authentication data against the reassembled enrollment data to produce an authentication result. Upon successful authentication, the OIDC Provider issues an ID Token to the Relying Party, without ever exposing the sensitive enrollment authentication data or the raw comparison process to the user or the Relying Party.

sequenceDiagram
    participant User
    participant RelyingParty
    participant OIDCProvider
    participant AuthEngine
    participant DataStorage1
    participant DataStorage2
    participant DataStorageN

    User->>RelyingParty: Access Protected Resource
    RelyingParty->>OIDCProvider: Authentication Request (OIDC)
    OIDCProvider->>User: Redirect for Authentication
    User->>OIDCProvider: Submit Current Auth Data (e.g., username/password, biometric)
    OIDCProvider->>AuthEngine: Forward Current Auth Data
    AuthEngine->>DataStorage1: Retrieve Portion 1 (Enrollment Data)
    AuthEngine->>DataStorage2: Retrieve Portion 2 (Enrollment Data)
    AuthEngine->>DataStorageN: Retrieve Portion N (Enrollment Data)
    AuthEngine->>AuthEngine: Reassemble Enrollment Auth Data
    AuthEngine->>AuthEngine: Compare Current vs Reassembled
    AuthEngine-->>OIDCProvider: Authentication Result (Success/Fail)
    OIDCProvider-->>RelyingParty: ID Token (if success)
    RelyingParty->>User: Grant Access (if ID Token valid)

Combination Prior Art Scenario 3: Secure Data in Motion with QUIC Protocol and US8904194 Principles

Enabling Description: This scenario describes a system for "secure data in motion" that integrates the data parsing, splitting, and encryption techniques of US8904194 with the QUIC (Quick UDP Internet Connections) open-source transport protocol. The "data to be secured" is a stream of information being transmitted between two endpoints (e.g., a client and a server). The client-side system incorporates a data splitting module. This module parses the data stream into segments (e.g., 1KB blocks), encrypts each segment using a session-specific AES-256-GCM key, and then further processes these encrypted segments by splitting them into multiple redundant sub-segments using an erasure coding scheme (e.g., (k,n) Reed-Solomon). These sub-segments (the "portions of data") are then transmitted in parallel over multiple independent QUIC streams or connections to the receiving server. The QUIC protocol, with its built-in stream multiplexing, connection migration, and TLS 1.3 encryption, provides the secure and reliable transport for these sub-segments. The receiving server's data assembly module collects the incoming sub-segments from the QUIC streams, performs erasure decoding to reconstruct the encrypted segments, decrypts them, and reassembles the original data stream. The parallel transmission of redundant, encrypted sub-segments over multiple QUIC streams means that the compromise of any single stream or individual sub-segment does not provide sufficient information to reconstruct the original data, embodying the "secure data in motion" aspect of the patent.

sequenceDiagram
    participant Client
    participant DataSplittingModule
    participant QUICStream1
    participant QUICStream2
    participant QUICStreamN
    participant ReceivingServer
    participant DataAssemblyModule

    Client->>DataSplittingModule: Data Stream
    DataSplittingModule->>DataSplittingModule: Parse into Segments
    DataSplittingModule->>DataSplittingModule: Encrypt Segments (AES-256-GCM)
    DataSplittingModule->>DataSplittingModule: Erasure Code into Sub-segments
    DataSplittingModule->>QUICStream1: Transmit Sub-segments (over QUIC)
    DataSplittingModule->>QUICStream2: Transmit Sub-segments (over QUIC)
    DataSplittingModule->>QUICStreamN: Transmit Sub-segments (over QUIC)
    QUICStream1-->>ReceivingServer:
    QUICStream2-->>ReceivingServer:
    QUICStreamN-->>ReceivingServer:
    ReceivingServer->>DataAssemblyModule: Receive Sub-segments
    DataAssemblyModule->>DataAssemblyModule: Erasure Decode to Encrypted Segments
    DataAssemblyModule->>DataAssemblyModule: Decrypt Segments
    DataAssemblyModule->>DataAssemblyModule: Reassemble Data Stream
    DataAssemblyModule->>ReceivingServer: Reconstructed Data Stream