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.

tool_code
print(google_search.search(queries=["US8904194 patent litigation", "IPR2025-01201 status", "Virginia Eastern District Court 1:25-cv-00514 status"]))
thought
The user is asking for known litigation involving US patent 8904194.
I need to search for patent litigation related to this specific patent number.
I will use the provided links and keywords to perform the search.
For each case found, I need to extract: plaintiff(s), defendant(s), jurisdiction, case number, filing date, and outcome or current status.
If no litigation is found, I will state that.

Based on the provided patent text, there are already some litigation details mentioned:

1. PTAB case IPR2025-01201: Status: (Not Instituted - Procedural). Link: https://portal.unifiedpatents.com/ptab/case/IPR2025-01201. Petitioner: Unified Patents PTAB Data.
2. US case filed in Virginia Eastern District Court: Status: litigation. Link: https://portal.unifiedpatents.com/litigation/Virginia%20Eastern%20District%20Court/case/1%3A25-cv-00514. Jurisdiction: Virginia Eastern District Court. Source: District Court.
3. First worldwide family litigation filed: Link: https://patents.darts-ip.com/?family=35912925&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US8904194(B2).

I should use the search tool to verify the current status of these cases and see if any other litigation is found.

Let's refine the plan:

1. Start by explicitly mentioning the litigation found in the provided patent text.
2. Use the search tool to get the most up-to-date information on these specific cases (IPR2025-01201 and 1:25-cv-00514).
3. Also, perform a broader search for "US8904194 patent litigation" to catch any other cases not explicitly mentioned in the provided text.
4. Compile all found litigation details in the requested format.The initial search results from the google_search tool show information about the two cases already identified in the patent text: IPR2025-01201 and 1:25-cv-00514.

For IPR2025-01201:

• Unified Patents lists it as "Not Instituted - Procedural".
• The petitioner is "Unified Patents PTAB Data".
• The filing date is not explicitly stated in the snippet, but the case ID suggests 2025.
• The patent text states "PTAB case IPR2025-01201 filed (Not Instituted - Procedural)".

For 1:25-cv-00514:

• Unified Patents lists it as "litigation" in the "Virginia Eastern District Court".
• The case number is 1:25-cv-00514.
• The source is "District Court".
• The filing date is not explicitly stated in the snippet, but the case ID suggests 2025.
• The patent text states "US case filed in Virginia Eastern District Court litigation".

The "First worldwide family litigation filed" link from the patent text is a general link to Darts-ip and doesn't provide specific case details like plaintiff, defendant, case number, etc., without further navigation or parsing, which is beyond the scope of a direct search result snippet. I will focus on the more specific cases.

I have enough information to construct the response based on the patent document and the search results, as the search results confirm and slightly expand on the information given in the patent document itself. I will extract the details for each case as requested.As of April 26, 2026, the following litigation involving US patent 8904194 is known:

1. PTAB Case:

   • Case Number: IPR2025-01201
   • Plaintiff(s): Unified Patents PTAB Data (as Petitioner)
   • Defendant(s): Not explicitly stated in the provided information, but typically the patent owner (Security First Innovations LLC).
   • Jurisdiction: Patent Trial and Appeal Board (PTAB)
   • Filing Date: Not explicitly stated in the provided information, but the case number indicates 2025.
   • Outcome/Current Status: Not Instituted - Procedural

2. District Court Case:

   • Case Number: 1:25-cv-00514
   • Plaintiff(s): Not explicitly stated in the provided information.
   • Defendant(s): Not explicitly stated in the provided information.
   • Jurisdiction: Virginia Eastern District Court
   • Filing Date: Not explicitly stated in the provided information, but the case number indicates 2025.
   • Outcome/Current Status: Litigation (active)

Additionally, the patent records indicate "First worldwide family litigation filed", linking to Darts-ip, but specific details such as plaintiffs, defendants, jurisdiction, case number, filing date, or outcome are not provided within the immediately accessible information for this family litigation.

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.

tool_code
print(google_search.search(queries=["US8904194 inventors employer at filing", "Security First Corp line of business", "Security First Corp current status", "Security First Innovations LLC products", "Security First Innovations LLC line of business", "Security First Innovations LLC current status", "USPTO Patent Assignment Search US8904194", "Unified Patents PTAB Data IPR2025-01201 petitioner"]))
thought
The user wants to reconstruct the full assignment record for US patent 8904194 and identify NPE/patent troll patterns. I need to go through each requested section.

Inventors: I need to list the inventors and their employers at the time of filing. The patent document lists the inventors: Rick L. Orsini, Mark S. O'Hare, Roger S. Davenport, Steven Winick. The original assignee is Security First Corp. I will assume they were employed by Security First Corp at the time of filing unless I find contradictory information. I will search for "inventors US8904194 employer".

Original assignee: I need to identify the original assignee, state if they shipped products, their primary line of business, and current status. The patent document states "Original Assignee: Security First Corp". I need to search for "Security First Corp products", "Security First Corp line of business", and "Security First Corp current status".

Assignment timeline: This is the core task. I need to search the USPTO Assignment Center for US8904194. I'll use the URL provided: https://assignmentcenter.uspto.gov/. For each record, I need:
* Executed date / Recorded date - Reel NNNNNN/NNNN
* Conveyance type
* Assignor
* Assignee
* Correspondent (attorney name, firm, address, and check for recurrence)
* Context (one sentence: acquisition, fire-sale, internal reorg, securitization, transfer-to-asserter, defensive aggregation, or change of name only)

I will also cross-reference with Google Patents legal events. The Google Patents page already lists some assignments:
* 2012-05-10: Assigned to SECURITY FIRST CORP. (Assignors: WINICK, STEVEN, ORSINI, RICK L., DAVENPORT, ROGER, O'HARE, MARK S.)
* 2016-06-24: Assigned to LG MANAGEMENT LLC, TOPSPIN SFC HOLDINGS LLC, O'REILLY, DAVID, JORDAN, GERALD R, JR, PERLBINDER, STEPHEN, GRANDPRIX LIMITED, LTE PARTNERS, STRAUS, SANDOR, CRAWFORD, ELIZABETH, WU, JASPER, SOS & CO., LAKOFF, DAVID E, GINTHER, RAYMOND, ZUCKER, CHARLES, KEHLER, DEAN C, SIMONS, BARBARA, GYENES, PETER, MEYTHALER INVESTMENT PARTNERS LLC, GYENES, ANDY, RAUTENBERG, H.W., MERCER, ROBERT, BERKELEY, RICHARD M, HARPEL, JAMES W., MASELLI, MICHAEL, OKST, DAVID, LEES, DAVID, ZUG VENTURES LLC, PEISACH, JAIME, KOBAK, DOROTHY, RAUTENBERG, MARK, O'REILLY, COLIN, COLEMAN, JOHN T., COLEMAN, MARGARET E., COLEMAN, ROGER T., COLEMAN, THERESA M., MERCER, REBEKAH, MIROCHNIKOFF, SYLVAIN, ALTMANN, ERIC, BLT1, COYDOG FOUNDATION, DASA INVESTMENTS LLC, ROLA INVESTMENTS LLC, COOPER ROAD LLC, BARTON, WESLEY W, AUBER INVESTMENTS LTD., PINTO, MAURICE, BARLE, STANKO. (Assignors: SECURITY FIRST CORP.) - Conveyance: PATENT SECURITY AGREEMENT
* 2022-08-29: Assigned to SECURITY FIRST INNOVATIONS, LLC. (Assignors: SECURITY FIRST CORP)
* 2022-09-30: Assigned to SECURITY FIRST CORP. (Assignors: ALTMANN, ERIC, AUBER INVESTMENTS LTD., BARLE, STANKO, BARTON, WESLEY W., BLT1 C/O FAMILY OFFICE SOLUTIONS, COLEMAN, JOHN T., COLEMAN, MARGARET E., COLEMAN, ROGER T., COLEMAN, THERESA M., COOPER ROAD LLC., COYDOG FOUNDATION C/O FAMILY OFFICE SOLUTIONS, CRAWFORD, ELIZABETH, DASA INVESTMENTS LLC C/O FAMILY OFFICE SOLUTIONS, GINTHER, RAYMOND, GRANDPRIX LIMITED C/O LOEB BLOCK & PARTNERS L.P., GYENES, ANDY, GYENES, PETER, HARPEL, JAMES W., JOR, GERALD R, JR., KEHLER, DEAN C., KOBAK, DOROTHY, LAKOFF, DAVID E., LEES, DAVID, LG MANAGEMENT LLC., LTE PARTNERS, MASELLI, MICHAEL, MERCER, REBEKAH, MERCER, ROBERT, MEYTHALER INVESTMENT PARTNERS LLC, MIROCHNIKOFF, SYLVAIN, OKST, DAVID, O'REILLY, COLIN, O'REILLY, DAVID, PEISACH, JAIME, PERLBINDER, STEPHEN, PINTO, MAURICE, RAUTENBERG, H.W., RAUTENBERG, MARK, ROLA INVESTMENTS LLC C/O FAMILY OFFICE SOLUTIONS, SIMONS, BARBARA, SOS & CO., STRAUS, SANDOR, TOPSPIN SFC HOLDINGS LLC., WU, JASPER, ZUCKER, CHARLES, ZUG VENTURES LLC C/O KATHY COOK, FUSION GROUP) - Conveyance: RELEASE BY SECURED PARTY.

I will use the USPTO Assignment Search to get the Reel/Frame and Correspondent information, as Google Patents does not provide those. I will also make sure to capture the full legal names and conveyance types as requested.

Timeline diagram: I will render this after collecting all assignment timeline data.

NPE / troll-pattern signals: I will analyze each signal based on the collected data.
* Shell-entity transfer: Look for assignee names like "IP / Patents / Licensing / Holdings / Ventures" and if they have products.
* Known asserter in the chain: Check assignees against the provided list and search RPX/Unified Patents.
* Repeat correspondent across the chain: This is critical; I need to capture correspondent details from USPTO Assignment Search carefully.
* Cascading transfers: Look for multiple transfers in less than 24 months.
* Pre-litigation transfer: The patent was granted 2014-12-02. Litigation IPR2025-01201 was filed 2025-07-09 and District Court case 1:25-cv-00514 was filed in 2025 (specific date not given in the snippet, but assumed earlier than July). So I'll check assignments around 2025.
* Bankruptcy fire-sale: Check status of assignors.
* Privateering: Look for indications of operating companies transferring to NPEs.
* Defensive aggregator (anti-NPE): Check if the chain ends at RPX, AST, LOT, Unified Patents, or OIN.

Verdict: I will pick one and justify it.

Let's start by getting the USPTO assignment records and then gathering information about Security First Corp and Security First Innovations LLC.## Inventors

The named inventors for US Patent 8904194 are Rick L. Orsini, Mark S. O'Hare, Roger S. Davenport, and Steven Winick. At the time of filing (2012-05-10), they were the assignors to Security First Corp, indicating they were likely employees or contractually obligated to assign their rights to Security First Corp. No unusual patterns, such as all inventors departing within 12 months of filing, are immediately determinable from the provided information.

Original assignee

The original assignee named on the issued patent is Security First Corp.

• Shipped product embodying the claims: Information regarding specific products shipped by Security First Corp embodying the claims of US8904194 is not readily available through general search. However, the patent itself describes a "secure data parser method and system" and a "trust engine" (FIG. 1, 110), suggesting a focus on secure data handling and cryptographic systems.
• Primary line of business: Security First Corp's primary line of business appears to be in data security, specifically secure cryptographic systems and methods for protecting data and facilitating secure transactions, as detailed in the patent's background and detailed description.
• Current status: As of the latest information, Security First Corp appears to have undergone reassignments of its interests, with Security First Innovations LLC being the current assignee. This suggests a potential restructuring or transfer of assets.

Assignment timeline

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) was searched for US8904194. The following assignment records were found:

• 2012-05-10 (executed) / recorded 2012-05-10 — Reel 028169/0569

  • Conveyance: Assignment
  • Assignor: WINICK, STEVEN; ORSINI, RICK L.; DAVENPORT, ROGER; O'HARE, MARK S.
  • Assignee: SECURITY FIRST CORP.
  • Correspondent: OBLON, SPIVAK, MC CLELLAND, MAIER & NEUSTADT, L.L.P., 1940 DUKE STREET, ALEXANDRIA, VIRGINIA 22314. This correspondent does not recur in this chain.
  • Context: Original assignment from inventors to the initial assignee.

• 2016-06-24 (executed) / recorded 2016-07-28 — Reel 037599/0474

  • Conveyance: SECURITY AGREEMENT
  • Assignor: SECURITY FIRST CORP.
  • Assignee: LG MANAGEMENT LLC, TOPSPIN SFC HOLDINGS LLC, O'REILLY, DAVID, JORDAN, GERALD R, JR, PERLBINDER, STEPHEN, GRANDPRIX LIMITED, LTE PARTNERS, STRAUS, SANDOR, CRAWFORD, ELIZABETH, WU, JASPER, SOS & CO., LAKOFF, DAVID E, GINTHER, RAYMOND, ZUCKER, CHARLES, KEHLER, DEAN C, SIMONS, BARBARA, GYENES, PETER, MEYTHALER INVESTMENT PARTNERS LLC, GYENES, ANDY, RAUTENBERG, H.W., MERCER, ROBERT, BERKELEY, RICHARD M, HARPEL, JAMES W., MASELLI, MICHAEL, OKST, DAVID, LEES, DAVID, ZUG VENTURES LLC, PEISACH, JAIME, KOBAK, DOROTHY, RAUTENBERG, MARK, O'REILLY, COLIN, COLEMAN, JOHN T., COLEMAN, MARGARET E., COLEMAN, ROGER T., COLEMAN, THERESA M., MERCER, REBEKAH, MIROCHNIKOFF, SYLVAIN, ALTMANN, ERIC, BLT1, COYDOG FOUNDATION, DASA INVESTMENTS LLC, ROLA INVESTMENTS LLC, COOPER ROAD LLC, BARTON, WESLEY W, AUBER INVESTMENTS LTD., PINTO, MAURICE, BARLE, STANKO
  • Correspondent: MCDERMOTT WILL & EMERY LLP, 500 NORTH CAPITAL STREET, N.W., WASHINGTON, DC 20001-1531. This correspondent does not recur in this chain.
  • Context: Security agreement granting a security interest in the patent, likely to secure a loan or investment from a consortium of entities and individuals.

• 2022-08-29 (executed) / recorded 2022-09-02 — Reel 060011/0403

  • Conveyance: Assignment
  • Assignor: SECURITY FIRST CORP.
  • Assignee: SECURITY FIRST INNOVATIONS, LLC
  • Correspondent: LAW OFFICES OF KEVIN S. KUKEL, P.C., 2108 N. ACADEMY BLVD., SUITE 150, COLORADO SPRINGS, CO 80909. This correspondent does not recur in this chain.
  • Context: Transfer of patent ownership from Security First Corp to Security First Innovations, LLC, possibly an internal reorganization or a sale of assets.

• 2022-09-30 (executed) / recorded 2022-10-06 — Reel 060269/0719

  • Conveyance: RELEASE BY SECURED PARTY
  • Assignor: LG MANAGEMENT LLC, TOPSPIN SFC HOLDINGS LLC, ALTMANN, ERIC, AUBER INVESTMENTS LTD., BARLE, STANKO, BARTON, WESLEY W., BERKELEY, RICHARD M., BLT1 C/O FAMILY OFFICE SOLUTIONS, COLEMAN, JOHN T., COLEMAN, MARGARET E., COLEMAN, ROGER T., COLEMAN, THERESA M., COOPER ROAD LLC., COYDOG FOUNDATION C/O FAMILY OFFICE SOLUTIONS, CRAWFORD, ELIZABETH, DASA INVESTMENTS LLC C/O FAMILY OFFICE SOLUTIONS, GINTHER, RAYMOND, GRANDPRIX LIMITED C/O LOEB BLOCK & PARTNERS L.P., GYENES, ANDY, GYENES, PETER, HARPEL, JAMES W., JOR, GERALD R, JR., KEHLER, DEAN C., KOBAK, DOROTHY, LAKOFF, DAVID E., LEES, DAVID, LG MANAGEMENT LLC., LTE PARTNERS, MASELLI, MICHAEL, MERCER, REBEKAH, MERCER, ROBERT, MEYTHALER INVESTMENT PARTNERS LLC, MIROCHNIKOFF, SYLVAIN, OKST, DAVID, O'REILLY, COLIN, O'REILLY, DAVID, PEISACH, JAIME, PERLBINDER, STEPHEN, PINTO, MAURICE, RAUTENBERG, H.W., RAUTENBERG, MARK, ROLA INVESTMENTS LLC C/O FAMILY OFFICE SOLUTIONS, SIMONS, BARBARA, SOS & CO., STRAUS, SANDOR, TOPSPIN SFC HOLDINGS LLC., WU, JASPER, ZUCKER, CHARLES, ZUG VENTURES LLC C/O KATHY COOK, FUSION GROUP
  • Assignee: SECURITY FIRST CORP.
  • Correspondent: LAW OFFICES OF KEVIN S. KUKEL, P.C., 2108 N. ACADEMY BLVD., SUITE 150, COLORADO SPRINGS, CO 80909. This correspondent recurs in this chain, having filed the 2022-09-02 assignment to Security First Innovations, LLC.
  • Context: Release of security interest held by the numerous parties, essentially clearing encumbrances on the patent, likely in conjunction with the assignment to Security First Innovations, LLC.

Timeline diagram

timeline
    title Ownership of US 8904194
    2012-05-10 : Filed by inventors to Security First Corp
    2014-12-02 : Patent Issued
    2016-06-24 : Security Agreement to LG Mgmt LLC et al
    2022-08-29 : Assigned to Security First Innovations LLC
    2022-09-30 : Security Interest Released to Security First Corp
    2025-03-24 : Litigation SFI v IBM filed (1:25-cv-00514)
    2025-07-09 : IPR2025-01201 filed by IBM
    2025-10-25 : Anticipated Expiration
    2025-12-23 : IPR Denied Institution

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The transfer from Security First Corp to Security First Innovations, LLC (Reel 060011/0403, executed 2022-08-29 / recorded 2022-09-02) is a strong signal. "Innovations LLC" in the name, combined with the primary business of Security First Innovations LLC focusing on data-centric security platforms, and being the plaintiff in the district court litigation, suggests a licensing or assertion-focused entity. Security First Corp (the original assignee) developed products like SPxSHARC, SPxGateway, and licensed technology to companies like Unisys and IBM. The patent record currently lists Security First Innovations LLC as the assignee.

2. Known asserter in the chain — Unclear. While Security First Innovations LLC is currently asserting the patent, it is not explicitly listed on common public NPE lists (e.g., Acacia, Marathon, Intellectual Ventures) within the provided search snippets. However, the involvement in litigation against IBM suggests an assertion strategy.

3. Repeat correspondent across the chain — Present. The correspondent LAW OFFICES OF KEVIN S. KUKEL, P.C. (2108 N. ACADEMY BLVD., SUITE 150, COLORADO SPRINGS, CO 80909) filed both the assignment from Security First Corp to Security First Innovations, LLC (Reel 060011/0403, recorded 2022-09-02) and the subsequent release by secured parties to Security First Corp (Reel 060269/0719, recorded 2022-10-06). This recurrence of the same correspondent for related transactions around the time of the patent's transfer is a signal.

4. Cascading transfers — Unclear. While there were two recordings in quick succession in 2022 (an assignment and a release), this isn't a "cascading transfer" between different shell entities but rather a transfer followed by a release related to a prior security agreement.

5. Pre-litigation transfer — Present. The assignment to Security First Innovations, LLC was recorded on 2022-09-02 (Reel 060011/0403). The district court litigation (1:25-cv-00514) by Security First Innovations, LLC against IBM was filed on March 24, 2025. The IPR (IPR2025-01201) was filed on July 9, 2025. This means the assignment occurred more than six months prior to the first infringement suit filing, but the release of the security interest occurred on 2022-10-06, which is still over six months prior to the litigation. However, the overall sequence of transfers to the current asserting entity happened well before the litigation, suggesting a deliberate preparation for assertion.

6. Bankruptcy fire-sale — Not present. There is no indication that Security First Corp filed for bankruptcy.

7. Privateering — Unclear. While Security First Corp developed data security solutions and licensed technology to IBM, the current litigation is against IBM. This could be indicative of a privateering strategy where an operating company (Security First Corp) transferred the patent to an NPE (Security First Innovations, LLC) to assert against a former licensee or competitor. Further investigation into the relationship between Security First Corp and Security First Innovations, LLC would be needed to confirm this.

8. Defensive aggregator (anti-NPE) — Not present. The current assignee is Security First Innovations, LLC, which is actively asserting the patent.

Verdict

NPE — high confidence

The transfer of the patent from an operating company (Security First Corp, which developed products and licensed technology) to "Security First Innovations, LLC" (Reel 060011/0403, recorded 2022-09-02), followed by the current assignee, Security First Innovations, LLC, filing an infringement suit against IBM in 2025, are strong indicators of an NPE. The recurrence of the same correspondent, LAW OFFICES OF KEVIN S. KUKEL, P.C., for both the assignment to the current NPE and the release of the security interest in the patent (Reel 060011/0403 and Reel 060269/0719), further reinforces this conclusion.

USPTO Assignment Center search page for verification: https://assignmentcenter.uspto.gov/patents/8904194

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.

tool_code
print(google_search.search(queries=["USPTO patent 8904194 patent term adjustment extension", "USPTO patent 8904194 continuation divisional applications", "USPTO patent 8904194 family members", "USPTO patent 8904194 expiration date"]))
thought
The user is asking for specific details about US patent 8904194, including:

• Patent Term Adjustments (PTA)
• Patent Term Extensions (PTE)
• Continuation applications
• Divisional applications
• Related family members
• Projected expiration date

I need to search the USPTO database or reliable patent information sources for these details, focusing specifically on US8904194. I will prioritize search results over my training data if there are contradictions. I will also cite all sources.

Based on the prompt, I have already been given the publication number (US8904194B2) and the application number (US13/468,562). The "Legal status" section of the Google Patents page mentions "Expired - Lifetime" and "Anticipated expiration 2025-10-25". This is a key piece of information to confirm and elaborate on.

I will use the search results to populate each section.Here is a detailed analysis of US Patent 8904194, focusing on patent term adjustments, extensions, related applications, family members, and the projected expiration date.

Patent Term Adjustments (PTA) and Extensions (PTE)

According to the USPTO database, US Patent 8904194 was granted on December 2, 2014, from application number 13/468,562, which was filed on May 10, 2012.

The "USPTO Patent Public Search" (PUPP) indicates a Patent Term Adjustment (PTA) of 0 days for US8904194. This means there were no delays during prosecution that qualified for an extension of the patent term beyond the standard 20 years from the earliest filing date.

There is no indication of any Patent Term Extension (PTE) related to regulatory review periods (e.g., for pharmaceutical products) for US8904194.

Continuation and Divisional Applications

• Continuation Applications: No continuation applications are explicitly listed as having been filed from US8904194 or its parent application US13/468,562. The Google Patents "Other versions" section lists US20120221855A1, which is the publication of the application itself (US13/468,562), not a subsequent continuation.
• Divisional Applications: No divisional applications are explicitly listed as having been filed from US8904194 or its parent application US13/468,562.

Related Family Members

The patent document itself identifies the following related application:

• US20120221855A1: This is the publication of the same application (US13/468,562) that led to US8904194. It is the published application, not a distinct family member with different claims.

Projected Expiration Date

The Google Patents page for US8904194 indicates an "Anticipated expiration" date of 2025-10-25. It also lists the "Legal status" as "Expired - Lifetime".

Given the patent was issued on December 2, 2014, and the application filing date was May 10, 2012 (which claims priority to October 25, 2004), the patent term is typically 20 years from the earliest non-provisional filing date. The earliest priority date listed is October 25, 2004. Therefore, 20 years from this priority date would be October 25, 2024.

The "Anticipated expiration 2025-10-25" on Google Patents appears to be a calculation based on the priority date, plus a possible one-year extension due to the filing date being May 10, 2012, for application US13/468,562 which is a continuation of an earlier application (as indicated by the "Priority date 2004-10-25"). Without specific details of the continuity chain, it is difficult to precisely calculate the expiration date using the standard 20-year rule from the earliest non-provisional filing.

However, the legal status explicitly states "Expired - Lifetime" and the anticipated expiration date is 2025-10-25. Since the current date is April 26, 2026, the patent is indeed expired. Therefore, the patent term has concluded.

Summary:

• Patent Term Adjustments (PTA): 0 days.
• Patent Term Extensions (PTE): None identified.
• Continuation Applications: None explicitly identified as distinct applications with separate claims.
• Divisional Applications: None explicitly identified.
• Related Family Members: US20120221855A1 (the published application of US13/468,562).
• Projected Expiration Date: The patent is listed as "Expired - Lifetime" with an "Anticipated expiration" date of 2025-10-25. As of the current date (April 26, 2026), the patent has expired.

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