Derivative works

Defensive Disclosure: Derivatives of US Patent 9135456

This Defensive Disclosure document outlines a series of derivative works based on US Patent 9135456, "Secure data parser method and system." The purpose of this disclosure is to establish prior art for potential future incremental improvements by competitors, thereby rendering such improvements non-novel or obvious. The derivatives are generated across five distinct axes: Material & Component Substitution, Operational Parameter Expansion, Cross-Domain Application, Integration with Emerging Technologies, and the "Inverse" or Failure Mode.

Core Claims Addressed:

• Claim 1: A method for securing data.
• Claim 11: A system for securing data.
• Claim 21: A system for facilitating cryptographic functions (Trust Engine).

---

Derivatives for Claim 1 (Method for securing data) and Claim 11 (System for securing data)

Original Claim 1 (Method): A method for securing data, comprising: parsing said data into at least two portions; encrypting said data; storing said portions in at least two different locations; and reconstituting said portions to assemble said data for authorized access.

Original Claim 11 (System): A system for securing data, comprising: a data splitting module configured to split said data into at least two portions; a cryptographic handling module configured to encrypt said data; at least two data storage facilities configured to store said portions in at least two different locations; and a data assembly module configured to process said portions from said at least two data storage facilities to assemble said data.

---

1. Material & Component Substitution

Derivative 1.1: Quantum State-Based Data Portions

• Enabling Description: Instead of conventional digital bits stored in electronic or magnetic media, the data (or its portions) is encoded into the quantum states of entangled photons or superconducting qubits. The "parsing" involves generating a multi-qubit entangled state representing the data, and then performing quantum measurements to project the data into "portions" represented by the measurement outcomes (e.g., spin up/down, polarization). These quantum state portions are then physically transmitted (e.g., via optical fiber for photons, or microwave guides for qubits) to spatially separated quantum memory arrays (e.g., diamond nitrogen-vacancy centers or superconducting resonators) for storage. Encryption is inherent through the quantum properties (e.g., no-cloning theorem, quantum key distribution principles) and augmented by classical post-processing of measurement results. Reconstitution involves performing inverse quantum operations or correlating distributed quantum measurements to reconstruct the original entangled state or classical data representation.
• Mermaid Diagram:

  flowchart TD
      A[Original Data] --> B{Quantum Encoder};
      B -- Entangled Qubits --> C{Quantum State Splitter};
      C -- Portions (Quantum States) --> D1[Quantum Memory Array 1];
      C -- Portions (Quantum States) --> D2[Quantum Memory Array 2];
      C -- Portions (Quantum States) --> Dn[Quantum Memory Array N];
      D1 & D2 & Dn -- Correlated Quantum States --> E{Quantum State Reconstructor};
      E --> F[Reconstituted Data];
  

Derivative 1.2: Biological Macromolecule-Based Data Portions

• Enabling Description: Data is encoded into sequences of biological macromolecules, such as synthetic DNA strands or engineered peptides. The "parsing" involves enzymatic cleavage or synthesis of the master sequence into unique, non-overlapping or overlapping sub-sequences (portions). These portions are encapsulated in inert bio-compatible carriers (e.g., liposomes, synthetic cells) and stored in distinct, geographically isolated biorepositories under controlled environmental conditions (e.g., cryogenic freezers for DNA, desiccated environments for peptides). Encryption is achieved through obfuscation of the encoding scheme and by incorporating error-correcting codes and redundant sequences within each portion, making individual portions biologically meaningless without the full set. Reconstitution involves enzymatic ligation or directed self-assembly of the macromolecule portions, followed by high-throughput sequencing or mass spectrometry for decoding.
• Mermaid Diagram:

  flowchart TD
      A[Digital Data] --> B{Bio-Encoder (DNA/Peptide Synthesis)};
      B -- Master Macromolecule --> C{Enzymatic/Chemical Splitter};
      C -- Macromolecule Portions --> D1[Biorepository 1];
      C -- Macromolecule Portions --> D2[Biorepository 2];
      C -- Macromolecule Portions --> Dn[Biorepository N];
      D1 & D2 & Dn -- Assembled Portions --> E{Bio-Decoder (Sequencing/Mass Spec)};
      E --> F[Reconstituted Digital Data];
  

---

2. Operational Parameter Expansion

Derivative 2.1: Hyper-Scale Industrial Data Security

• Enabling Description: For industrial control systems (ICS) and SCADA networks managing critical infrastructure (e.g., national power grids, large-scale manufacturing plants), exabyte-scale operational data (sensor readings, control commands, telemetry) is continuously parsed into millions of encrypted micro-portions. This parsing is executed by a high-performance distributed computing cluster, capable of processing data streams at terabytes-per-second. The portions are stored across geographically disparate and independently administered "dark" data centers (no direct internet access) connected by dedicated, high-bandwidth optical networks. Reconstruction for auditing or recovery occurs within a specialized, air-gapped forensic analysis environment that requires physical multi-factor authentication from multiple custodians across various locations to activate the assembly process. Each portion is protected with homomorphic encryption, allowing certain computations to be performed on encrypted data without decryption, facilitating integrity checks at storage locations without revealing sensitive content.
• Mermaid Diagram:

  graph LR
      subgraph Industrial Control Network
          SCADA -- Real-time Data --> HPC_Parser
          ICS_Sensors -- Real-time Data --> HPC_Parser
      end
  
      subgraph Distributed Parsing Cluster
          HPC_Parser[HPC Data Stream Parser] -- Micro-Portions (Encrypted) --> DC1(Dark Data Center 1)
          HPC_Parser -- Micro-Portions (Encrypted) --> DC2(Dark Data Center 2)
          HPC_Parser -- Micro-Portions (Encrypted) --> DCN(Dark Data Center N)
      end
  
      DC1 & DC2 & DCN -- Encrypted Portions --> Forensic_Env{Air-gapped Forensic Environment}
      Forensic_Env -- Multi-Custody Auth --> Data_Recon[Data Reconstitution Module]
      Data_Recon --> Audited_Data[Reconstituted Operational Data]
  

Derivative 2.2: Ultra-Low Latency Edge Micro-Transaction Security

• Enabling Description: Securing individual, atomic micro-transactions (e.g., single bit updates, sub-millisecond control signals) in a highly distributed edge computing environment (e.g., autonomous vehicle sensor fusion, high-frequency trading). Data is parsed into picosecond-latency "micro-fragments" that are immediately encrypted and distributed across a mesh network of hardened edge computing nodes using ultra-low latency optical interconnects. Each fragment is ephemeral, existing only for nanoseconds before being stored or reassembled. The encryption protocol is a lightweight, symmetric key algorithm designed for extremely fast execution (e.g., AES-GCM with hardware acceleration). Reconstruction occurs on adjacent edge nodes within microsecond windows, triggered by event-driven queries. The system operates under extreme frequency (GHz range processing) to maintain data integrity and security within real-time critical systems.
• Mermaid Diagram:

  sequenceDiagram
      participant ES as Edge Sensor
      participant ET as Edge Transactor
      participant ECN1 as Edge Compute Node 1
      participant ECN2 as Edge Compute Node 2
      participant ECNN as Edge Compute Node N
      participant AE as Assembly Engine
  
      ES->>ET: Micro-Transaction Data (picosecond latency)
      ET->>ECN1: Encrypted Micro-Fragment A
      ET->>ECN2: Encrypted Micro-Fragment B
      ET->>ECNN: Encrypted Micro-Fragment N
      Note over ECN1,ECN2,ECNN: Fragments stored ephemerally
      ECN1->>AE: Fragment A (on query)
      ECN2->>AE: Fragment B (on query)
      ECNN->>AE: Fragment N (on query)
      AE->>AE: Reconstitute Data (microsecond latency)
      AE->>ET: Authentication Result
  

---

3. Cross-Domain Application

Derivative 3.1: Aerospace - Black Box Flight Data Security

• Enabling Description: For commercial aircraft flight recorders ("black boxes"), sensitive flight data (cockpit voice recordings, flight parameters, airframe stress data) is continuously parsed into encrypted portions. These portions are redundantly stored across physically distinct, hardened solid-state memory units distributed throughout the aircraft's airframe (e.g., in wings, tail, nose cone, landing gear bays) as well as broadcast to secure ground stations via encrypted satellite links. Each distributed unit is designed to withstand extreme forces, temperatures, and immersion. In the event of a catastrophic incident, retrieval of any two (or more, based on a threshold) of these physically separated and broadcast portions allows for full data reconstruction. The encryption scheme adapts to data criticality, with cockpit voice recordings using the strongest encryption.
• Mermaid Diagram:

  graph TD
      A[Flight Data Recorder] --> B{Data Parser/Encryptor};
      B -- Encrypted Portion 1 --> C1[Hardened Memory Unit (Wing)];
      B -- Encrypted Portion 2 --> C2[Hardened Memory Unit (Tail)];
      B -- Encrypted Portion 3 --> C3[Hardened Memory Unit (Nose)];
      B -- Encrypted Portion 4 --> S(Encrypted Satellite Broadcast);
      S --> G[Secure Ground Station];
      C1 & C2 & C3 & G -- For Recovery --> D{Data Reassembly Module};
      D --> E[Reconstructed Flight Data];
  

Derivative 3.2: AgTech - Precision Agriculture Genomic Data Security

• Enabling Description: In precision agriculture, vast amounts of genomic data for specific crop strains, livestock, and soil microbiome samples are parsed into encrypted fragments. These fragments are stored across a distributed network of secure, on-farm edge servers and regional agricultural research centers. Each fragment is cryptographically linked to its source metadata (e.g., GPS coordinates of sample, date, environmental conditions) and protected with a multi-party computation (MPC) scheme, allowing aggregate analysis across fragments (e.g., disease resistance patterns) without ever decrypting individual genomic sequences. Reconstitution of a full genomic sequence requires a quorum of fragments from different storage locations, verified by a distributed consensus mechanism. This prevents unauthorized access to proprietary genetic intellectual property or vulnerabilities.
• Mermaid Diagram:

  graph LR
      A[Genomic Data (Crop/Livestock)] --> B{Data Parser/Encryptor};
      B -- Encrypted Fragment 1 (MPC) --> C1[On-Farm Edge Server 1];
      B -- Encrypted Fragment 2 (MPC) --> C2[On-Farm Edge Server 2];
      B -- Encrypted Fragment 3 (MPC) --> R1[Regional Research Center 1];
      B -- Encrypted Fragment 4 (MPC) --> R2[Regional Research Center 2];
      C1 & C2 & R1 & R2 -- For Aggregate Analysis --> D{Multi-Party Computation Engine};
      D -- On-Demand Reconstruction --> E{Data Reassembly Module};
      E --> F[Reconstructed Genomic Sequence];
  

Derivative 3.3: Consumer Electronics - Smart Home User Profile Security

• Enabling Description: Sensitive user profile data within a smart home ecosystem (e.g., behavioral patterns, voice commands, biometric scans from smart locks, health data from wearables) is parsed into encrypted, anonymized micro-segments. These segments are distributed across local, mutually distrusting smart devices within the home (e.g., smart speaker, smart TV, home hub, smart refrigerator) and optionally mirrored to an obfuscated cloud storage service. No single device or the cloud service holds enough information to reconstruct the full user profile. Access to specific functions (e.g., unlocking a smart lock) requires cryptographic aggregation of necessary micro-segments from a predefined quorum of local devices, orchestrated by a local trust agent. Differential privacy techniques are applied during parsing to further anonymize data, even before splitting.
• Mermaid Diagram:

  graph LR
      A[User Profile Data (Smart Home)] --> B{Data Parser/Encryptor (Anonymization)};
      B -- Encrypted Micro-Segment 1 --> C1[Smart Speaker];
      B -- Encrypted Micro-Segment 2 --> C2[Smart TV];
      B -- Encrypted Micro-Segment 3 --> C3[Home Hub];
      B -- Encrypted Micro-Segment 4 --> C4[Smart Refrigerator];
      C1 & C2 & C3 & C4 -- Local Aggregation for Function --> D{Local Trust Agent};
      D --> E[Smart Lock Unlock];
      D --> F[Climate Control];
  

---

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Dynamic Data Splitting & Storage Optimization

• Enabling Description: An AI-driven optimization engine dynamically adjusts the parsing and distribution strategy of data portions based on real-time threat intelligence, data access patterns, and resource availability (network latency, storage load, energy costs). For example, if a data portion's access frequency increases, the AI might duplicate it across more readily available, but still secure, storage nodes. If a new threat vector is identified, the AI could trigger re-splitting of existing portions with a different cryptographic scheme or redistribute them to more resilient geographic locations. Machine learning models predict optimal splitting parameters (number of portions, size, encryption strength) and storage locations to balance security, performance, and cost, learning from past attack vectors and system performance.
• Mermaid Diagram:

  flowchart TD
      A[Raw Data Stream] --> B{AI-Driven Parser/Encryptor};
      B -- Optimized Portions --> C{Dynamic Storage Orchestrator};
      C -- Distribute/Redistribute --> D1[Secure Cloud Storage 1];
      C -- Distribute/Redistribute --> D2[Secure Edge Storage 2];
      C -- Distribute/Redistribute --> D3[Quantum-Resistant Storage N];
      C -- Performance/Cost/Security Metrics --> B;
      TI[Threat Intelligence Feed] --> B;
      D1 & D2 & D3 -- Retrieve for Access --> E{Data Assembly Module};
      E --> F[Authorized Access];
  

Derivative 4.2: IoT Sensor Data Integrity with Blockchain Verification

• Enabling Description: In a distributed IoT network (e.g., environmental monitoring, supply chain logistics), sensor data streams are parsed into encrypted portions. Each portion, along with its metadata (timestamp, sensor ID, location), is hashed, and this hash is securely anchored to a permissioned blockchain ledger. The portions themselves are stored off-chain in distributed, lightweight edge storage facilities. The "reconstituting" process involves retrieving the portions and then verifying their integrity against the corresponding hashes recorded on the blockchain. This provides an immutable audit trail and ensures that no single portion has been tampered with since its creation. Smart contracts on the blockchain can define access policies and triggers for data reconstitution.
• Mermaid Diagram:

  graph TD
      A[IoT Sensor Data] --> B{Data Parser/Encryptor};
      B -- Encrypted Portion + Metadata --> C[Edge Storage Facility];
      B -- Hashed Portion Data --> D(Blockchain Ledger);
      C -- Retrieve Portion --> E{Data Assembly Module};
      D -- Retrieve Hash --> E;
      E -- Verify Hash --> F{Data Integrity Verifier};
      F -- Validated Data --> G[Authorized Access];
  

Derivative 4.3: Federated Learning for Secure Model Training Data

• Enabling Description: In federated learning scenarios where multiple parties contribute data to train a shared AI model without sharing raw data, US9135456's method is applied to the training datasets. Each participating entity's raw training data is parsed into encrypted, differentially private portions. These portions are then stored in secure enclaves on each entity's local compute infrastructure. When the federated learning server requires model updates, it requests encrypted gradients derived from these data portions, rather than the portions themselves. The "reconstitution" in this context refers to the secure aggregation of these encrypted gradients from multiple participants to update the global model, ensuring no individual raw data point is ever exposed or fully reassembled by the central server. Secure multi-party computation (SMC) is used for gradient aggregation.
• Mermaid Diagram:

  graph TD
      P1[Participant 1 Raw Data] --> DP1{Diff. Private Parser/Encryptor 1};
      DP1 -- Encrypted Portions --> ES1[Secure Enclave 1];
  
      P2[Participant 2 Raw Data] --> DP2{Diff. Private Parser/Encryptor 2};
      DP2 -- Encrypted Portions --> ES2[Secure Enclave 2];
  
      ES1 -- Encrypted Gradients --> SMC[SMC Aggregation Server];
      ES2 -- Encrypted Gradients --> SMC;
  
      SMC -- Global Model Update --> FL(Federated Learning Server);
  

---

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Data Degradation and Secure Erasure Mode

• Enabling Description: This derivative focuses on designing the system to safely degrade or securely erase data under specific conditions. When certain failure modes are detected (e.g., compromise of a quorum of storage facilities, unauthorized access attempts exceeding a threshold, or an explicit secure erasure command), the data assembly module is prevented from re-constituting the full original data. Instead, it enters a "graceful degradation" mode where only partial, non-sensitive metadata or anonymized aggregates can be recovered. For full secure erasure, the cryptographic keys used to encrypt the portions are themselves split into a larger number of shares and destroyed across a distributed network, making recovery of the full key (and thus decryption of the portions) mathematically impossible even if all data portions were retrieved. This "key-splitting-for-destruction" guarantees irreversible data loss.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Operational
      Operational --> Degrading: Threshold Breached / Command
      Degrading --> Erasing: Erasure Command / Irrecoverable
      Degrading --> Operational: Recovery / Mitigation
  
      Operational --> Data_Parsing_Storage: Normal Operation
      Data_Parsing_Storage --> Data_Reconstitution: Authorized Access
  
      Degrading --> Partial_Data_Access: Limited Functionality
      Erasing --> Data_Irrecoverable: Irreversible Destruction
  
      state Data_Parsing_Storage {
          Data --> Portions
          Portions --> Storage
      }
  
      state Data_Reconstitution {
          Storage --> Reassembly
          Reassembly --> Original_Data
      }
  

Derivative 5.2: Limited-Functionality "Safe Mode" for Cryptographic Engine

• Enabling Description: In this mode, the "trust engine" (Claim 21) operates in a reduced capacity, prioritizing critical security functions while limiting exposure of sensitive data. If the trust engine detects an internal anomaly or external attack, it enters "Safe Mode." In this mode, the cryptographic engine (Claim 21) will only perform a limited set of cryptographic functions (e.g., hash generation for integrity checks, but not decryption or digital signing). It may only reassemble a minimal, non-sensitive subset of cryptographic keys or authentication data, sufficient for basic system diagnostics or to prove the existence of an identity without revealing its full credentials. Attempts to perform full cryptographic operations are blocked, and a high-alert notification is triggered. The data splitting module may be invoked to further re-split and redistribute existing portions to enhance resilience during this compromised state.
• Mermaid Diagram:

  graph TD
      A[Trust Engine] --> B{Security Monitor};
      B -- Anomaly Detected --> C(Safe Mode Activation);
      C --> D{Limited Cryptographic Functions};
      D -- Allow --> E[Integrity Check];
      D -- Block --> F[Full Decryption/Signing Request];
      C --> G{Minimal Key/Auth Reassembly};
      G --> H[System Diagnostics/Identity Proof];
      C --> I[High Alert Notification];
      C --> J{Re-split & Redistribute Portions};
  

---

Combination Prior Art Scenarios

Here are at least three "Combination Prior Art" scenarios where US Patent 9135456 is combined with existing open-source standards:

1. US9135456 Data Splitting & Storage with IPFS (InterPlanetary File System)

• Description: The "parsing said data into at least two portions" (Claim 1) and "storing said portions in at least two different locations" (Claim 1) of US9135456 can be combined with IPFS. In this scenario, after data is parsed and encrypted by the data splitting module (Claim 11) and cryptographic handling module (Claim 11), the resulting encrypted portions are not stored in traditional centralized data storage facilities but instead distributed across the decentralized peer-to-peer network provided by IPFS. Each portion would receive a content-addressed identifier (CID) from IPFS. The "reconstituting said portions" (Claim 1) and "data assembly module" (Claim 11) would then retrieve these portions from IPFS using their CIDs and reassemble the data. This provides a highly resilient, censorship-resistant, and geographically diverse storage solution for the data portions, leveraging IPFS's distributed hash table (DHT) for content discovery and retrieval.
• Technical Details: The data splitting module generates 'n' portions (P1, P2, ..., Pn). Each Pi is encrypted (Ei). Each Ei is then added to a local IPFS node, yielding a unique CIDi. The CIDs are then stored (potentially themselves split and stored, or secured separately). The data assembly module retrieves the list of CIDs, requests each CIDi from the IPFS network, reconstructs Ei from the received content, decrypts, and reassembles.
• Mermaid Diagram:

  graph TD
      A[Original Data] --> B{Data Splitter (US9135456)};
      B -- Portions --> C{Cryptographic Module (US9135456)};
      C -- Encrypted Portions --> D[IPFS Network];
      D -- CID1, CID2, ... --> E[CID Registry (Secured)];
      E -- Retrieve CIDs --> F{Data Assembly Module (US9135456)};
      F -- Request Portions by CID --> D;
      D -- Retrieved Encrypted Portions --> F;
      F --> G[Reconstituted Data];
  

2. US9135456 Trust Engine & Authentication with OAuth 2.0 / OpenID Connect

• Description: The "system for facilitating cryptographic functions" (Claim 21), particularly the authentication engine (FIG. 5) and cryptographic engine (FIG. 6) residing within a "trust engine" (FIG. 2), can be combined with OAuth 2.0 for authorization and OpenID Connect (OIDC) for identity verification. The trust engine would act as the Authorization Server and OpenID Provider. Instead of directly releasing cryptographic keys, the trust engine would issue access tokens (OAuth 2.0) and ID tokens (OIDC) upon successful user authentication. The authentication process within the trust engine (comparing current authentication data to enrollment data, potentially involving biometrics and data splitting as per US9135456's claims 22-24) would precede the issuance of these tokens. Client applications (user systems or vendor systems) would then use these tokens to request cryptographic services from the trust engine's cryptographic handling module, which performs functions on behalf of the user without releasing the actual private keys.
• Technical Details: A user authenticates to the Trust Engine. The Authentication Engine (FIG. 5), potentially using split biometric data from the Depository (FIG. 2), verifies the user's identity. Upon successful verification, the Trust Engine (acting as an OpenID Provider) issues an ID Token (JWT) and an Access Token (JWT) to the client application. The client application then presents the Access Token to the Trust Engine (acting as a Resource Server), requesting specific cryptographic functions (e.g., signing a document). The Cryptographic Engine (FIG. 6) performs the requested function using the user's stored, unreleased private key and returns the result.
• Mermaid Diagram:

  sequenceDiagram
      participant U as User
      participant CA as Client App
      participant TE as Trust Engine (Auth/OIDC)
      participant DE as Depository (US9135456)
      participant AE as Auth Engine (US9135456)
      participant CE as Crypto Engine (US9135456)
      
      U->>CA: Initiate Login/Auth
      CA->>TE: Auth Request (via OAuth/OIDC)
      TE->>AE: Current Auth Data (from CA)
      AE->>DE: Request Enrollment Auth Portions
      DE->>AE: Auth Portions
      AE->>AE: Assemble & Compare (US9135456)
      AE-->>TE: Auth Result
      alt Successful Authentication
          TE->>CA: Access Token, ID Token
          CA->>CE: Request Cryptographic Function (with Access Token)
          CE->>DE: Request Cryptographic Key Portions
          DE->>CE: Key Portions
          CE->>CE: Assemble Key & Perform Function (US9135456)
          CE-->>CA: Cryptographic Result
      else Authentication Failed
          TE-->>CA: Auth Error
      end
  

3. US9135456 Secure Data in Motion with QUIC (Quick UDP Internet Connections)

• Description: The "secure data in motion system whereby data may be transmitted in different portions that are secured in accordance with the present invention such that any one portion becoming compromised shall not provide sufficient data to restore the original data" (from the specification) can be enhanced by utilizing QUIC for the underlying transport layer. After the data is parsed into encrypted portions (Claim 1) by the data splitting module (Claim 11) and cryptographic handling module (Claim 11), these individual portions are transmitted over separate, multiplexed QUIC streams within a single connection. QUIC's inherent security (TLS 1.3 encryption for all data), connection migration capabilities, and improved head-of-line blocking mitigation would make the "data in motion" more robust and efficient. Even if a QUIC stream carrying one portion is intercepted, the other portions, transmitted over different streams and potentially different network paths (via connection migration), remain secure and individually undecipherable, aligning with the patent's goal of preventing restoration from a single compromised portion.
• Technical Details: The source system's data splitting module divides the data into portions (P1, P2, ..., Pn). Each Pi is independently encrypted (Ei). The source system then initiates a QUIC connection to the destination. Each Ei is transmitted over a separate QUIC stream (Stream1, Stream2, ..., StreamN) within that connection. QUIC's TLS 1.3 encryption secures each stream. The destination system's data assembly module receives the encrypted portions from the various QUIC streams, reassembles, and decrypts them.
• Mermaid Diagram:

  sequenceDiagram
      participant SS as Source System
      participant DS as Destination System
      
      SS->>SS: Data Parsing (US9135456)
      SS->>SS: Data Encryption (US9135456)
      SS->>DS: Initiate QUIC Connection (TLS 1.3)
      loop For each Encrypted Portion
          SS->>DS: Transmit Encrypted Portion over dedicated QUIC Stream
      end
      DS->>DS: Receive Encrypted Portions from QUIC Streams
      DS->>DS: Data Assembly (US9135456)
      DS->>DS: Data Decryption (US9135456)
      DS->>DS: Reconstituted Data