The USPTO search confirms that I can find patent information using Patent Public Search (PPUBS) or Patent Center. I will proceed with generating the defensive disclosure as requested, using the provided patent text as the basis for the core claims. I will assume the absence of an explicit "References Cited" section means I should focus on the internal descriptions of prior art concepts within the patent's background and description for "Combination Prior Art" scenarios, or rely on general open-source standards.

Defensive Disclosure for US Patent 9069703

Date: June 25, 2026

Patent Title: Encrypted-transport solid-state disk controller
Patent Number: US9069703
Inventor: Farbod Michael Raam
Assignee: Seagate Technology LLC

Purpose

This Defensive Disclosure document aims to broaden the scope of existing prior art related to encrypted-transport solid-state disk controllers, making incremental advancements by competitors in this field "obvious" or "non-novel" under 35 U.S.C. § 103. This is achieved by detailing numerous derivative variations of the core inventive concepts disclosed in US9069703, encompassing a wide range of material substitutions, operational parameters, cross-domain applications, integrations with emerging technologies, and inverse/failure modes.

Derivative Variations of Core Claims

For this analysis, we will focus on derivative variations of the following core claims from US9069703:

Claim 1 (Method - Read Data Path): A method for retrieving data from NVM and providing it to a computing host, involving decryption, decompression (symmetric to lossless compression), re-encryption, and provision of re-encrypted data.
Claim 5 (Method - Write Data Path): A method for receiving data from a computing host, processing it through decryption, lossless compression, re-encryption, and providing the re-encrypted data for storage in NVM.
Claim 29 (System - Write Data Path with Modes): A system including means for receiving data, selectively enabling encrypted or non-encrypted write modes (involving decryption, compression, re-encryption, or just compression), selecting mode data, encrypting, and formatting for NVM storage.

Derivatives for Core Claim 5 (Write Data Path Method)

Original Claim 5 (Summary): A method for writing data from a host to NVM involving decrypting received host data, losslessly compressing the decrypted data, re-encrypting the compressed-decrypted data, and preparing it for NVM storage.

Derivative 5.1: Material & Component Substitution - Quantum-Resistant Encryption & Advanced NVM

Enabling Description:
This derivative implements the write data path method using quantum-resistant encryption algorithms for both the initial transport decryption (K_C) and the subsequent internal re-encryption (K_B or K_A), such as lattice-based cryptography (e.g., CRYSTALS-Kyber, CRYSTALS-Dilithium) or hash-based signatures (e.g., XMSS, SPHINCS+). The NVM is substituted with Ferroelectric RAM (FeRAM) or Spin-Transfer Torque MRAM (STT-MRAM) for enhanced endurance and non-volatility, necessitating adapted write-formatting layers for their specific memory cell characteristics and access protocols. The compression engine could be implemented as a specialized hardware accelerator (e.g., an Application-Specific Integrated Circuit (ASIC) block) optimized for Zstd, integrated within the SSD controller.

graph TD
    A[Host Encrypted Data (Quantum-Resistant)] --> B{Session Decryption Layer (Quantum-Resistant K_C)}
    B --> C[Decrypted Data]
    C --> D{Lossless Compression Layer (Zstd ASIC)}
    D --> E[Compressed Data]
    E --> F{Internal Re-Encryption Layer (Quantum-Resistant K_B/K_A)}
    F --> G[Re-Encrypted Data]
    G --> H{Write-Formatting Layer (FeRAM/STT-MRAM Protocol)}
    H --> I[NVM (FeRAM/STT-MRAM)]

Derivative 5.2: Operational Parameter Expansion - Hyperscale Data Center with Fine-Grained Compression

Enabling Description:
This derivative applies the method in a hyperscale data center environment, where data streams are massive (terabytes/second) and latency critical. The SSD controller processes data at extreme frequencies (e.g., 100 Gbps interfaces, multiple parallel pipelines). The lossless compression layer employs adaptive Huffman coding or arithmetic coding for optimal compression ratios on diverse, dynamically changing data types typical of multi-tenant cloud environments. The "preparing results" step includes dynamic wear-leveling and garbage collection algorithms tuned for petabyte-scale NVM arrays (e.g., 3D NAND with 512+ layers) and high write endurance demands, potentially involving active load balancing across multiple Flash Dies (Flash Die 194) and devices (Flash Device 192).

graph TD
    A[Host Encrypted Data Stream (Tbps)] --> B{Parallel Session Decryption Units}
    B --> C[Decrypted Data Streams]
    C --> D{Adaptive Huffman/Arithmetic Compression Engines}
    D --> E[Compressed Data Streams]
    E --> F{Parallel Re-Encryption Units}
    F --> G[Re-Encrypted Data Streams]
    G --> H{Hyperscale Write-Formatting & NVM Manager}
    H --> I[Petabyte NVM Array (3D NAND)]

Derivative 5.3: Cross-Domain Application - Automotive ADAS Secure Data Logger

Enabling Description:
This method is adapted for an Automotive Advanced Driver-Assistance Systems (ADAS) secure data logger. The "computing host" is the ADAS processing unit within an autonomous vehicle, sending real-time sensor data (LiDAR, radar, camera feeds) that is transport-encrypted. The SSD controller, ruggedized for automotive environments (e.g., -40°C to +105°C), decrypts the incoming ADAS data stream, compresses it (e.g., using a high-throughput, low-latency algorithm like LZ4 optimized for sensor data patterns), and re-encrypts it for storage in NVM (e.g., industrial-grade 3D TLC/QLC NAND) that is resilient to vibration and temperature extremes. The "preparing results" includes error correction codes (ECC) with extended capabilities to mitigate data corruption in harsh conditions.

sequenceDiagram
    participant ADAS_ECU as ADAS Computing Host
    participant SSD_Controller as Encrypted Transport SSD Controller
    participant NVM as Automotive NVM (3D NAND)

    ADAS_ECU->>SSD_Controller: Encrypted ADAS Sensor Data (K_H)
    SSD_Controller->>SSD_Controller: Decrypt Data (K_C)
    SSD_Controller->>SSD_Controller: Compress Decrypted Data (LZ4)
    SSD_Controller->>SSD_Controller: Re-Encrypt Compressed Data (K_B/K_A)
    SSD_Controller->>NVM: Store Re-Encrypted Formatted Data (with Robust ECC)
    Note over SSD_Controller: Operate -40C to +105C, vibration resistant

Derivative 5.4: Integration with Emerging Tech - AI-Optimized Adaptive Compression for Multi-Tenant Cloud

Enabling Description:
The write path method is enhanced with an AI-driven optimization engine. The "computing host" could be a virtual machine in a multi-tenant cloud environment. The AI-driven engine, residing on the SSD controller (CPU Core 172 or a dedicated AI accelerator), continuously analyzes incoming "decrypted data" entropy and characteristics. Based on this, it dynamically selects the optimal lossless compression algorithm (e.g., switching between LZ77, Zlib, or specialized algorithms for database logs, virtual disk images, or user files) and compression level to maximize throughput and compression ratio, while minimizing latency. The AI also influences the re-encryption key management (K_B) by associating specific keys with data types or tenant policies.

graph TD
    A[Host Encrypted Data (VM)] --> B{Session Decryption Layer}
    B --> C[Decrypted Data]
    C --> D[AI-Driven Compression Engine]
    D -- (Data Characteristics) --> E(AI Model: Algorithm/Level Selector)
    E --> F{Dynamically Selected Lossless Compression}
    F --> G[Compressed Data]
    G --> H{Internal Re-Encryption Layer}
    H --> I[Re-Encrypted Data]
    I --> J{Write-Formatting Layer}
    J --> K[NVM]

Derivative 5.5: The "Inverse" / Failure Mode - Secure Data Shredding on Critical Event

Enabling Description:
This derivative describes a "secure data shredding" mode activated upon detection of a critical security event or physical tamper. When activated, the SSD controller, upon receiving data, still decrypts and losslessly compresses it. However, the "re-encrypting" step uses a transient, single-use encryption key. The "preparing results" includes a "cryptographic erase" instruction that effectively renders the stored data permanently unrecoverable by destroying the key metadata, rather than overwriting the entire physical blocks. Additionally, a "low-power" or "limited-functionality" mode could involve the controller rejecting write commands if it cannot establish a secure link or if its internal encryption module is compromised, falling back to a diagnostic read-only mode, or performing only essential system data writes.

stateDiagram
    [*] --> Operational
    Operational --> Critical_Event: Tamper Detected / Security Breach
    Critical_Event --> Secure_Shredding: Activate Shredding
    Secure_Shredding --> Writing_with_Transient_Key: Receive Write Data
    Writing_with_Transient_Key --> Decrypting_Transient: Decrypt Data
    Decrypting_Transient --> Compressing_Transient: Compress Data
    Compressing_Transient --> ReEncrypting_Transient_Key: Re-encrypt with Transient Key
    ReEncrypting_Transient_Key --> Cryptographic_Erase_NVM: Store & Cryptographically Erase Key
    Cryptographic_Erase_NVM --> Data_Irretrievable
    Critical_Event --> Limited_Functionality: Cannot establish secure link
    Limited_Functionality --> Diagnostic_Mode: Enter Diagnostic Read-Only
    Diagnostic_Mode --> Operational: Recovery/Repair
    Data_Irretrievable --> [*]

Derivatives for Core Claim 1 (Read Data Path Method)

Original Claim 1 (Summary): A method for reading data from NVM and providing it to a host, involving receiving prepared data, decrypting it, decompressing the decrypted data (symmetric to lossless compression), re-encrypting the decompressed data, and providing the re-encrypted data to the host.

Derivative 1.1: Material & Component Substitution - Multi-Dimensional Memory & Neuromorphic Decompression

Enabling Description:
This derivative utilizes multi-dimensional NVM (e.g., 3D XPoint memory) where data is stored with intrinsic parallelism and lower access latency. The "receiving data from NVM" step involves accessing data across multiple planes of this memory. The "decrypting the prepared data" employs a hardware-accelerated decryption unit for Post-Quantum Cryptography (PQC) algorithms. The "decompressing the decrypted data" uses a neuromorphic computing accelerator, trained to recognize data patterns and efficiently decompress, particularly effective for highly variable data streams or image/video data that underwent advanced compression. The final "re-encrypting" also leverages PQC.

graph TD
    A[3D XPoint NVM] --> B{Multi-Plane Data Retrieval & Preparation}
    B --> C{PQC Decryption Unit}
    C --> D[Decrypted Data (Raw Stream)]
    D --> E{Neuromorphic Decompression Accelerator}
    E --> F[Decompressed Data]
    F --> G{PQC Re-Encryption Unit}
    G --> H[Re-Encrypted Data to Host]

Derivative 1.2: Operational Parameter Expansion - Cryogenic Storage for Quantum Computing Facilities

Enabling Description:
This method operates in a cryogenic environment, such as for data storage supporting quantum computing or ultra-cold atomic experiments, where temperatures can be near absolute zero (e.g., <4 Kelvin). The SSD controller and NVM (e.g., cryo-compatible MRAM or specialized silicon-on-insulator flash) are designed to function at these extreme low temperatures. The "decrypting" and "re-encrypting" operations must account for potential quantum effects or specific material properties at these temperatures, ensuring cryptographic integrity. Decompression algorithms (e.g., specialized dictionary-based variants) are optimized for minimal heat dissipation during execution, and the read pathways are shielded to prevent interference.

graph TD
    A[Cryogenic NVM (<4K)] --> B{Cryo-Hardened Read De-Formatting}
    B --> C[Prepared Data (Cryo-Decrypted)]
    C --> D{Cryo-PQC Decryption Unit}
    D --> E[Decrypted Data]
    E --> F{Low-Power Decompression Engine}
    F --> G[Decompressed Data]
    G --> H{Cryo-PQC Re-Encryption Unit}
    H --> I[Re-Encrypted Data to Host (Warm Zone)]

Derivative 1.3: Cross-Domain Application - Secure Drone Data Recorder

Enabling Description:
This method is implemented in a secure data recorder for unmanned aerial vehicles (UAVs) or drones, which serves as the "computing host." The NVM stores flight telemetry, sensor data, and mission-critical information. Upon retrieval, the recorded data, which may be stored as back-end encrypted (K_A) and internal encrypted (K_B) data in the NVM, is first decrypted. The decrypted data is then decompressed (e.g., optimized for time-series flight data or compressed video feeds). This decompressed data is then re-encrypted with a session key (K_C) established with the UAV's flight controller or ground station for secure transmission, ensuring data integrity even if the drone is compromised.

sequenceDiagram
    participant NVM as Drone NVM
    participant SSD_Controller as Drone SSD Controller
    participant Flight_Controller as UAV Computing Host

    NVM->>SSD_Controller: Encrypted-Formatted Flight Data
    SSD_Controller->>SSD_Controller: Read De-Formatting
    SSD_Controller->>SSD_Controller: Back-End Decryption (K_A)
    SSD_Controller->>SSD_Controller: Internal Decryption (K_B)
    SSD_Controller->>SSD_Controller: Decompress Flight Data
    SSD_Controller->>SSD_Controller: Re-Encrypt for Transport (K_C)
    SSD_Controller->>Flight_Controller: Re-Encrypted Flight Data

Derivative 1.4: Integration with Emerging Tech - IoT Edge Gateway with Real-time Anomaly Detection

Enabling Description:
The SSD controller is integrated into an IoT edge gateway, where the "computing host" is the gateway's analytics engine. The NVM stores historical encrypted sensor data from various IoT devices. The method involves receiving the stored encrypted data, decrypting it, and then decompressing it. Critically, before re-encryption, the "decompressed data" is fed to a lightweight, on-controller machine learning (ML) model (e.g., a TinyML inference engine on CPU Core 172 or a dedicated accelerator) for real-time anomaly detection. Only filtered, potentially anomalous data or aggregated insights are then re-encrypted using a secure session key with a cloud backend and provided to the host, reducing data egress and enhancing security.

graph TD
    A[NVM (IoT Sensor Data)] --> B{Read De-Formatting}
    B --> C{Back-End Decryption}
    C --> D{Internal Decryption}
    D --> E[Decrypted Compressed Data]
    E --> F{Decompression Layer}
    F --> G[Decompressed Data Stream]
    G --> H(On-Controller ML Anomaly Detection)
    H -- (Anomalous/Filtered Data) --> I{Session Re-Encryption Layer (to Cloud)}
    I --> J[Re-Encrypted Data to Edge Gateway Host]

Derivative 1.5: The "Inverse" / Failure Mode - Forensic Recovery Mode with Selective Decryption

Enabling Description:
In a "forensic recovery mode," the SSD controller, upon detecting an unauthorized access attempt or physical distress, shifts its read operation. Instead of automatically re-encrypting the decompressed data for the host, it can selectively decrypt and decompress only specific, authorized portions of the "prepared data" (e.g., boot logs, critical metadata) to provide diagnostic information. The re-encryption step is bypassed or uses a special "forensic key" that only authorized tools can decrypt. This mode prioritizes secure access to forensic evidence over normal data delivery. A "low-power" read mode could involve increasing read latency in exchange for significant power savings, perhaps by partially disabling NVM channels or reducing clock frequencies of decompression/decryption engines.

stateDiagram
    [*] --> Normal_Operation
    Normal_Operation --> Forensic_Recovery_Triggered: Unauthorized Access / Distress
    Forensic_Recovery_Triggered --> Authenticate_Forensic_Agent: Host Request
    Authenticate_Forensic_Agent --> Read_NVM_Data
    Read_NVM_Data --> Decrypt_Selectively_Prepared_Data
    Decrypt_Selectively_Prepared_Data --> Decompress_Selectively_Decrypted_Data
    Decompress_Selectively_Decrypted_Data --> Provide_Raw_Or_Forensic_Encrypted_Data: (Bypass Re-encryption or use Forensic Key)
    Provide_Raw_Or_Forensic_Encrypted_Data --> Forensic_Agent_Host
    Forensic_Recovery_Triggered --> Low_Power_Read_Mode: Power Constraint
    Low_Power_Read_Mode --> Reduced_Performance_Read: Increase Latency / Reduce Channels
    Reduced_Performance_Read --> Normal_Operation: Power Restored

Derivatives for Core Claim 29 (System - Write Data Path with Modes)

Original Claim 29 (Summary): A system with means for receiving host data, selectively enabling an "encrypted mode" (decrypt, compress, re-encrypt) or "non-encrypted mode" (compress), selecting data, encrypting, and formatting for NVM.

Derivative 29.1: Material & Component Substitution - Photonics-Based Interconnects & Reconfigurable Hardware

Enabling Description:
The "means for receiving data" and "means for interfacing with NVMs" utilize silicon photonics-based interconnects (e.g., optical transceivers for External Interfaces 110 and Device Interfaces 190) for extremely high bandwidth and low power consumption, especially relevant for future high-speed standards like PCIe Gen6+. The internal "means for decrypting," "means for compressing," and "means for re-encrypting" are implemented using a field-programmable gate array (FPGA) or a reconfigurable computing fabric (RCF) where the cryptographic and compression algorithms can be dynamically updated or swapped to adapt to new security threats or data types, including quantum-resistant primitives or new compression standards.

graph TD
    A[Computing Host (Optical Interface)] --> B{Photonic Host Interface}
    B --> C{Reconfigurable Cryptographic/Compression Fabric (FPGA/RCF)}
    C -- (Encrypted Mode Data) --> D{Decrypt Module}
    C -- (Non-Encrypted Mode Data) --> E{Bypass Decrypt}
    D --> F{Compress Module}
    E --> F
    F --> G{Re-Encrypt Module}
    G --> H{Optical NVM Interface}
    H --> I[NVM]

Derivative 29.2: Operational Parameter Expansion - Edge AI Inferencing with Data Tiering

Enabling Description:
This system is deployed as a high-performance, low-latency edge AI inferencing accelerator with integrated storage. The "plurality of modes" includes a real-time inferencing mode (decryption, compression of raw input data for efficiency, re-encryption, and storage in a "hot" tier NVM, followed by immediate read/decryption/decompression for AI processing) and an archival mode (similar processing but for storage in a "cold" tier NVM with higher density, potentially different compression and encryption parameters). The "means for compressing" adapts its algorithm based on the AI model's input data type (e.g., image, video, time-series) and the selected NVM tier. The system operates autonomously at remote locations, handling bursty data streams.

flowchart TD
    A[Computing Host (Edge AI)] --> B{Data Reception & Mode Selection}
    B -- Encrypted Mode --> C{Decrypt & Compress (Real-time)}
    B -- Non-Encrypted Mode --> D{Compress (Archival)}
    C --> E{Re-Encrypt & Hot Tier Storage}
    D --> F{Re-Encrypt & Cold Tier Storage}
    E --> G[Hot Tier NVM (High Perf)]
    F --> H[Cold Tier NVM (High Density)]
    G -- Read for Inference --> I{Read, Decrypt, Decompress}
    I --> J[AI Inference Engine]

Derivative 29.3: Cross-Domain Application - Smart City Infrastructure Data Collector

Enabling Description:
The system is integrated into smart city infrastructure, acting as a secure data collector for various sensors (traffic, environmental, surveillance). The "computing host" could be a local smart city hub. The "means for receiving data" handles diverse sensor streams. The "plurality of modes" would correspond to different data types or security classifications: e.g., a highly sensitive "encrypted mode" for personal identifiable information (PII) from surveillance, involving strong decryption and re-encryption with geo-fenced keys, and a "non-encrypted mode" for aggregated traffic flow data that is merely compressed before being back-end encrypted. The "means for formatting" prepares data for long-term archival in ruggedized NVM modules distributed across the city.

classDiagram
    class SmartCityHub {
        +sendSensorData()
        +receiveProcessedData()
    }
    class SSDController {
        +receiveData()
        +selectMode()
        +decryptData()
        +compressData()
        +reEncryptData()
        +provideWriteData()
        +encryptSelectedData()
        +formatData()
    }
    class NVMSensors {
        +storeData()
    }

    SmartCityHub --|> SSDController : Host Interface
    SSDController --|> NVMSensors : NVM Interface

    SSDController : <<mode>> EncryptedMode
    SSDController : <<mode>> NonEncryptedMode
    EncryptedMode : +decrypt(data)
    EncryptedMode : +compress(data)
    EncryptedMode : +reEncrypt(data)
    NonEncryptedMode : +compress(data)

Derivative 29.4: Integration with Emerging Tech - Blockchain-Enabled Secure Provenance Logging

Enabling Description:
This system uses blockchain technology for enhanced data provenance and integrity. When data is received from the "computing host," an "encrypted mode" ensures that after decryption, compression, and re-encryption, a cryptographic hash of the processed data (or a metadata block associated with it) is recorded onto a distributed ledger via an on-controller blockchain client. This hash, along with the NVM storage address and relevant encryption key IDs, forms an immutable record. The "non-encrypted mode" similarly logs hashes of compressed data. This provides an auditable trail, verifying that data stored in NVM has not been tampered with since its write operation, and that the correct encryption/compression policies were applied. Key management (for K_C, K_B, K_A) could also be managed through smart contracts.

sequenceDiagram
    participant Host as Computing Host
    participant SSD_Controller as SSD Controller
    participant NVM as Non-Volatile Memory
    participant Blockchain as Distributed Ledger

    Host->>SSD_Controller: Encrypted Data (Write Request)
    SSD_Controller->>SSD_Controller: Select Mode (e.g., Encrypted)
    SSD_Controller->>SSD_Controller: Decrypt, Compress, Re-Encrypt Data
    SSD_Controller->>NVM: Store Formatted Data
    SSD_Controller->>SSD_Controller: Generate Data Hash & Metadata
    SSD_Controller->>Blockchain: Record Transaction (Hash, Address, Key_ID)
    Blockchain-->>SSD_Controller: Transaction Confirmation
    SSD_Controller-->>Host: Write Acknowledge

Derivative 29.5: The "Inverse" / Failure Mode - Self-Healing Redundancy with Gradual Degradation

Enabling Description:
This system incorporates advanced self-healing capabilities and a graceful degradation mode. The "means for formatting" NVM data includes distributed redundancy and advanced Error-Correcting Codes (ECC) that allow the system to tolerate the failure of multiple NVM blocks or even entire Flash Die (Flash Die 194). Upon detection of NVM degradation (e.g., increasing uncorrectable errors), the controller enters a "limited-functionality mode" where it prioritizes data integrity by reducing write amplification (e.g., using more aggressive compression, even potentially lossy compression for less critical data if allowed by policy) and increasing internal redundancy, even at the cost of reduced performance or capacity. The "means for encrypting" might dynamically increase key lengths or re-key more frequently for remaining healthy NVM sections.

stateDiagram
    [*] --> Healthy_Operation
    Healthy_Operation --> Degradation_Detected: NVM Errors Exceed Threshold
    Degradation_Detected --> Limited_Functionality_Mode: Activate Self-Healing
    Limited_Functionality_Mode --> Prioritize_Integrity: Reduce WA, Increase Redundancy
    Prioritize_Integrity --> Adjust_Compression_Encryption: Adaptive Algorithms/Keys
    Adjust_Compression_Encryption --> Operate_Degraded: Reduced Perf/Capacity
    Operate_Degraded --> Healthy_Operation: Self-Healing Complete / NVM Replacement
    Operate_Degraded --> Critical_Failure: Unrecoverable Errors
    Critical_Failure --> Fail_Safe_Shutdown: Data Protection Protocol

Combination Prior Art Scenarios

Here are at least three "Combination Prior Art" scenarios where the concepts of US9069703 could be combined with existing open-source standards to demonstrate obviousness of future incremental improvements.

US9069703 + NVM Express (NVMe) Standard + LZ4 Compression Library:
- Scenario: An encrypted-transport SSD controller, as described in US9069703 (e.g., Claim 29's system for handling write data), integrated with the NVMe standard (an open-source logical device interface specification for accessing non-volatile storage media attached via a PCI Express (PCIe) bus). The "means for receiving data from a computing host" would be an NVMe-compatible host interface (External Interfaces 110, compatible with PCIe), and the "means for formatting the encrypted, selected mode write data for storage in one or more NVMs" would adhere to NVMe's data structure and command set for flash management. The "means for compressing" (e.g., Lossless Compression Layer 316) would specifically utilize the publicly available and widely adopted LZ4 lossless compression algorithm, whose source code and specification are open.
- Obviousness Argument: For a person skilled in the art, combining an encrypted and compressed SSD controller architecture with a prevalent high-performance storage interface like NVMe, and employing a well-known, high-speed lossless compression algorithm like LZ4, would be an obvious design choice to achieve faster, more efficient, and secure data storage in SSDs. The functional benefits (speed, efficiency, security) are well-understood for each component individually.
US9069703 + TCG Opal Security Subsystem Class Specification + AES-GCM Implementation:
- Scenario: An encrypted-transport SSD controller, particularly the aspects of internal encryption (Internal Encryption Layer 318, utilizing key K_B determined by metadata) and secure key exchange (FIG. 4's secure communication link for K_C), is implemented in strict adherence to the Trusted Computing Group (TCG) Opal Security Subsystem Class (SSC) specification. TCG Opal defines security protocols for self-encrypting drives (SEDs) where encryption/decryption is performed within the drive. The "means for decrypting," "means for re-encrypting," and "means for encrypting the selected mode write data" would specifically use the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM), a NIST-recommended and widely adopted authenticated encryption algorithm, whose implementations are available in numerous open-source cryptographic libraries (e.g., OpenSSL, Libgcrypt).
- Obviousness Argument: The patent explicitly mentions TCG Opal (e.g., "a security protocol, such as a storage security sub-system class (e.g. TCG Opal)"). Combining the described encrypted transport SSD with the full TCG Opal specification for internal security management and utilizing a standard, robust, and commonly implemented authenticated encryption mode like AES-GCM for the various encryption layers, would be an obvious and desirable engineering practice to ensure interoperability, strong security, and compliance in enterprise environments.
US9069703 + Linux F2FS File System Integration + Zlib Compression Library:
- Scenario: The methods (Claim 1 and Claim 5) and system (Claim 29) of US9069703 are implemented within an SSD managed by a host running a Linux operating system, specifically optimized for interaction with the Flash-Friendly File System (F2FS). F2FS is an open-source file system designed for NAND flash memory, aiming to reduce write amplification and improve endurance. The "computing host" (Host 102) utilizes an F2FS driver (Driver 107) that can communicate with the SSD controller to provide hints or commands (e.g., de-allocation commands, specific write patterns beneficial for F2FS). The "means for compressing" (Lossless Compression Layer 316) or "means for decompressing" (Read Decompression Layer 342) employs the well-known Zlib compression library, which is widely used in Linux and other open-source projects.
- Obviousness Argument: For a developer working with flash-based storage in a Linux environment, it would be obvious to leverage a flash-optimized file system like F2FS in conjunction with a hardware-accelerated encrypted-transport SSD controller. Using a widely available and robust compression library like Zlib within the controller's compression pipeline (instead of a custom implementation) further makes this integration an obvious engineering choice for performance, compatibility, and maintainability. The synergy between F2FS's flash management and the SSD controller's compression/encryption directly addresses common flash storage challenges.

Derivative works