US 11327669

Analysis of U.S. Patent No. 11,327,669 and Associated Litigation

Date of Analysis: April 26, 2026

An analysis of United States Patent number 11,327,669 reveals a technology focused on providing configurable, policy-based behavior for data storage devices. The patent, assigned to Gaea LLC, details a system and method for allowing greater user control over how data is stored and managed on a physical level.

Bibliographic Information:

• Title: Data storage device with configurable policy-based storage device behavior
• Assignee: Gaea LLC
• Inventors: Joshua Johnson, Curt Bruner, Jeffrey Reh, Christopher Squires, Brian Wilson
• Filing Date: August 11, 2020
• Issue Date: May 10, 2022
• Abstract: The patent describes a data storage device with a controller that can be configured through a "storage device policy." This policy allows a user to define how the device operates, creating a trade-off between storage reliability and capacity. The policy can also control specific details of the read and write processes, as well as the physical layout of the data on the storage medium. The controller receives and stores content based on this policy, records storage information, and can even refuse to delete data based on the established rules. The storage information may also be stored remotely.

Plain-Language Overview of Independent Claims

U.S. Patent No. 11,327,669 contains three independent claims: 1, 14, and 20. An independent claim is a standalone claim that defines the core of the invention.

• Claim 1: This claim describes a data storage device that includes a storage medium (like a hard disk or solid-state memory) and a device controller. The key innovation is that the device controller can receive and operate based on a "storage device policy." This policy dictates how the device should handle trade-offs between storage reliability and the amount of data it can store (capacity). When the device receives a request to store data, the controller uses this policy to decide how and where to physically write the data onto the storage medium. It then records information about where the data is stored and can also be programmed to refuse to delete certain data.

• Claim 14: This claim focuses on the method of operating a data storage device. It outlines the process of a device controller receiving a storage policy that governs the trade-off between reliability and capacity. The controller then receives a request to store data and, following the rules of the policy, stores the data and creates a record of its location and other attributes. A crucial part of this method is the ability to refuse a delete request based on the stored information, and the capability to store this information in a separate, remote location.

• Claim 20: This claim describes a non-transitory computer-readable medium (such as a hard drive or flash memory) that contains instructions for a device controller. When these instructions are executed, they cause the controller to perform a specific set of actions. First, it receives a storage device policy. Then, it handles requests to store data by writing the data to the storage medium according to that policy. It also records information about the stored data, including a unique identifier. Finally, the instructions enable the controller to use this recorded information to retrieve the data when requested and to refuse a request to delete the data.

Litigation Involving U.S. Patent No. 11,327,669

As of April 26, 2026, U.S. Patent No. 11,327,669 is involved in at least two district court litigations initiated by the assignee, Gaea LLC.

• Gaea LLC v. Meta Platforms, Inc.: This case (4:26-cv-00348) was filed in the U.S. District Court for the Northern District of Texas on March 23, 2026.
• Gaea LLC v. [Samsung Electronics Co Ltd](/litigations/by-plaintiff/Samsung%20Electronics%20Co%20Ltd), et al.: This case (2:26-cv-00264) also asserts infringement of U.S. Patent No. 11,327,669.

A search of the Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not reveal any appeals related to this patent at this time. Litigation typically begins in district courts, and any appeals to the CAFC would occur after a district court decision.

Active Litigation Involving U.S. Patent No. 11,327,669

As of April 30, 2026, U.S. Patent No. 11,327,669, assigned to Gaea LLC, is actively being asserted in at least two separate patent infringement lawsuits.

1. Gaea LLC v. Meta Platforms, Inc.

• Plaintiff: Gaea, LLC
• Defendant: Meta Platforms, Inc.
• Jurisdiction: U.S. District Court for the Northern District of Texas
• Case Number: 4:26-cv-00348
• Filing Date: March 23, 2026
• Status: The case is currently open and in its early stages.

2. Gaea, LLC v. SAMSUNG ELECTRONICS CO., LTD. et al.

• Plaintiff: Gaea, LLC
• Defendants: SAMSUNG ELECTRONICS CO., LTD. and SAMSUNG ELECTRONICS AMERICA, INC.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:26-cv-00264
• Filing Date: March 31, 2026
• Status: This case is also open and in the initial phases of litigation.

At present, no appeals related to this patent have been filed with the U.S. Court of Appeals for the Federal Circuit (CAFC), and there is no public record of any resolutions or final judgments in these cases.

Proceedings overview

There are no AIA trial proceedings on file for U.S. Patent 11,327,669.

Strategic summary

As of 2026-05-29, U.S. Patent 11,327,669 has not been subject to any AIA trial proceedings before the Patent Trial and Appeal Board (PTAB). This means that all claims of the patent (claims 1-20) remain untested and presumed valid through PTAB challenges. Consequently, there is no estoppel landscape established from PTAB proceedings. The absence of PTAB activity could suggest several things, including that the patent has not yet been asserted widely enough to provoke a challenge, or that potential challengers have not identified strong prior art grounds for an IPR, PGR, or CBM.

Recommended next steps

Since there is no PTAB activity on U.S. Patent 11,327,669, a defendant facing assertion of this patent would need to initiate any PTAB challenge. The first step would involve a thorough prior art search to identify strong grounds for invalidity under 35 U.S.C. §§ 102 or 103, considering the claims' scope and the patent's priority date of 2016-11-07. If strong prior art is found, filing an Inter Partes Review (IPR) petition would be a viable defensive strategy.

Inventors

• Joshua Johnson: Employer not determinable from the provided patent text.
• Curt Bruner: Employer not determinable from the provided patent text.
• Jeffrey Reh: Employer not determinable from the provided patent text.
• Christopher Squires: Employer not determinable from the provided patent text.
• Brian Wilson: Employer not determinable from the provided patent text.

No unusual patterns regarding inventor departure are determinable from the provided information.

Original assignee

The entity named on the issued patent is Gaea LLC.

It is not determinable from the provided information whether Gaea LLC ships a product embodying the claims or its primary line of business.

Current status: Active, as indicated by the "Legal status" on Google Patents.

Assignment timeline

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) shows the following record for US Patent 11327669:

• 2020-11-10 (executed) / recorded 2020-11-10 — Reel 055394/0978
  • Conveyance: Assignment of Assignors Interest
  • Assignor: REH, JEFFREY; SQUIRES, CHRISTOPHER; WILSON, BRIAN; JOHNSON, JOSHUA; BRUNER, CURT
  • Assignee: Gaea LLC
  • Correspondent: Jeffrey B. Wilson, One LLP, 4000 MacArthur Blvd., East Tower, Suite 500, Newport Beach, CA 92660. This correspondent does not recur in this chain.
  • Context: Transfer of inventor rights to the original assignee.

No further assignment records for US Patent 11327669 were found on the USPTO Assignment Center. This indicates that Gaea LLC is the current assignee of record.

Gaea LLC, as the assignee, appears to be a company focused on providing business-process and information-technology solutions, with expertise in Oracle enterprise products, supply chain management, and project portfolio management. They also offer application development, data management, cloud computing, gaming software, system integration, and technical support. There appear to be multiple entities named "Gaea LLC" with different business focuses, including entertainment software development (acquired by Embracer Group in 2021), a family-run business selling memories and gifts, a company selling organic energy drinks, a wholesale stationery supplier, and a developer of an AI framework for emotional modeling. However, the Gaea LLC associated with the patent explicitly states "Gaea Global Technologies, Inc. Gaea. Our business-process and information-technology experts provide innovative, cost-effective solutions that improve operations at some of the largest firms in the world, and we do it with an intimate knowledge of the Oracle enterprise products that we helped pioneer." This suggests the assignee is Gaea Global Technologies, Inc., operating as Gaea.

Timeline diagram

timeline
    title Ownership of US 11327669
    2020 : Inventors assign to Gaea LLC
    2022 : Issued to Gaea LLC
    2026 : First infringement suit filed
         : Second infringement suit filed

NPE / troll-pattern signals

1. Shell-entity transfer — unclear. While "Gaea LLC" could suggest a shell, the available information from PitchBook and their website describes Gaea Global Technologies, Inc. as an Oracle Partner providing consulting and enterprise solutions. However, it is not explicitly clear if this specific Gaea LLC that owns the patent ships a product embodying the claims of the patent.
2. Known asserter in the chain — not present. Gaea LLC does not appear on public NPE lists based on the provided information.
3. Repeat correspondent across the chain — not present. The correspondent, Jeffrey B. Wilson of One LLP, is listed only once for the initial assignment from the inventors to Gaea LLC.
4. Cascading transfers — not present. Only one assignment from inventors to Gaea LLC is recorded.
5. Pre-litigation transfer — not present. The assignment to Gaea LLC was recorded on 2020-11-10, significantly before the first infringement suit filed on March 23, 2026.
6. Bankruptcy fire-sale — not present. No indication of bankruptcy for Gaea LLC.
7. Privateering — unclear. While Gaea LLC is asserting against large tech companies, there is no public record from SEC filings or other sources to suggest an operating company transferred the patent to Gaea LLC to assert on its behalf.
8. Defensive aggregator (anti-NPE) — not present. The patent has been asserted in litigation, indicating it is not held by a defensive aggregator.

Verdict

NPE — moderate confidence

The absence of clear evidence that Gaea LLC ships a product embodying the claims, combined with their recent activity in filing multiple infringement lawsuits against major tech companies (Meta Platforms, Inc. and [Samsung Electronics Co Ltd](/litigations/by-plaintiff/Samsung%20Electronics%20Co%20Ltd)) shortly after the patent's issuance, suggests a potential NPE assertion strategy. However, the lack of other strong NPE signals (like shell-entity transfers, known NPE names, or repeat correspondents across a chain of assignments) prevents a high-confidence verdict.

To verify, search US11327669 on the USPTO Patent Assignment Search: https://assignmentcenter.uspto.gov/

Analysis of Prior Art for U.S. Patent No. 11,327,669

This analysis details the prior art cited during the prosecution of U.S. Patent No. 11,327,669. Each cited reference is evaluated for its potential to anticipate the independent claims of the '669 patent under 35 U.S.C. § 102. The core invention of the '669 patent involves a data storage device with a controller that can be configured by a "storage device policy" to manage the trade-off between storage reliability and capacity.

I. U.S. Patent No. 9,665,463 B2

• Full Citation: Tadayon, Bijan, et al. System and Method for Optimizing Non-Volatile Memory Based Storage System Performance by Modifying Data Placement Policies Based on Workload Characteristics. U.S. Patent 9,665,463 B2, issued May 30, 2017. (Filed Jan. 21, 2014).
• Assignee: FADU, Inc.
• Brief Description: This patent describes a system for managing a solid-state drive (SSD) where the data placement policy is dynamically adjusted based on the characteristics of the I/O workload. It aims to optimize performance by altering how and where data is written to the non-volatile memory, considering factors like write amplification and endurance. The system can select from multiple data placement policies to best suit the current workload.
• Potential Anticipation Analysis:
  • Claim 1: This reference teaches a device controller that modifies "data placement policies." This aligns with the '669 patent's "storage device policy." The '463 patent discloses adjusting these policies to optimize performance, which inherently involves trade-offs between factors like speed (a performance metric) and endurance (a reliability metric). It describes storing content based on these policies. However, a key distinction is whether the '463 patent explicitly discloses a policy that manages the "trade-off between reliability of storage and volume of storage." While optimizing for endurance can be seen as a form of reliability, the '463 patent's primary focus is performance optimization, not a direct, user-configurable balance between raw capacity and data integrity. It also does not explicitly teach the concept of refusing a delete request based on the policy.
  • Claim 14 & 20: Similar to Claim 1, the method and system described in the '463 patent involve receiving and applying policies to storage operations. The concept of dynamically altering write strategies based on workload is present. However, the specific trade-off between reliability and volume, and the explicit function of refusing a delete request based on a policy, are not clearly articulated. Furthermore, the '463 patent does not appear to disclose storing the storage information at a separate, remote location as claimed in the '669 patent.

II. U.S. Patent No. 10,255,108 B1

• Full Citation: Bennett, James D. Write Amplification Reduction in Solid-State Drives. U.S. Patent 10,255,108 B1, issued April 9, 2019. (Filed Apr. 12, 2017).
• Assignee: Amazon Technologies, Inc.
• Brief Description: This patent addresses the problem of write amplification in solid-state drives (SSDs). It discloses a method where the SSD controller can be configured with different data placement policies. These policies are selected based on the expected usage patterns or application needs to minimize unnecessary data movement and writes, thereby improving performance and the lifespan of the drive.
• Potential Anticipation Analysis:
  • Claim 1: The '108 patent describes configuring a storage device with "data placement policies," which is analogous to the "storage device policy" in the '669 patent. The policies influence how data is physically placed on the storage medium to reduce write amplification, which directly impacts the endurance and, therefore, the long-term reliability of the SSD. This can be interpreted as managing a trade-off between performance/endurance (reliability) and how efficiently storage is used. However, the '108 patent does not appear to explicitly teach a user-defined policy to trade reliability for volume (i.e., storing data more densely at the risk of lower integrity). It also does not mention a feature to refuse delete requests based on the policy.
  • Claim 14 & 20: The methods described in the '108 patent involve applying a policy to a write request. However, the specific steps of refusing a delete request and storing metadata at a remote location are absent. The focus is on optimizing write patterns, not on providing a broad, configurable policy engine that governs a wide range of device behaviors including immutability and remote metadata management.

III. U.S. Patent No. 10,489,248 B2

• Full Citation: Frost, Gregory, et al. Dynamically Selecting Data Storage Mode to Tune Storage Performance. U.S. Patent 10,489,248 B2, issued Nov. 26, 2019. (Filed Jan. 26, 2018).
• Assignee: Hewlett Packard Enterprise Development LP.
• Brief Description: This invention relates to a storage controller that can dynamically select a data storage mode (e.g., different RAID levels) for a logical volume based on I/O characteristics. For instance, it might switch between a high-performance mode and a high-reliability mode depending on the detected workload, thereby tuning the storage system's behavior.
• Potential Anticipation Analysis:
  • Claim 1: The '248 patent clearly discloses the concept of a policy ("storage mode") that manages a trade-off between performance and reliability (e.g., RAID 1 for high reliability vs. RAID 0 for high performance). This directly addresses the "trade-off between reliability of storage and volume of storage" element of claim 1, as different RAID levels offer different balances of redundancy (reliability) and usable capacity (volume). The controller stores data according to this selected policy. However, the patent does not seem to teach the element of refusing a delete request based on the policy or the associated storage information.
  • Claim 14 & 20: The method of receiving a policy (or selecting a mode based on a policy) and storing data accordingly is taught. The core elements of managing the reliability/capacity trade-off are present. However, like the other references, it appears to be silent on the specific features of refusing a delete request and storing the associated metadata at a remote location.

IV. U.S. Patent Application Publication No. 2005/0216664 A1

• Full Citation: Chang, Robert. Method and Apparatus for Adaptive Data Storage and Management. U.S. Patent Application Publication No. 2005/0216664 A1, published Sep. 29, 2005. (Filed Mar. 24, 2004).
• Assignee: Not specified (Inventor is Chang, Robert).
• Brief Description: This application describes a system that adapts its data storage and management strategies based on various factors, including the type of data, usage patterns, and system policies. It discusses concepts like tiered storage, where data is moved between different types of storage media (e.g., fast, expensive vs. slow, cheap) based on policies to balance cost, performance, and reliability.
• Potential Anticipation Analysis:
  • Claim 1: The '664 application teaches the use of "policies" to manage data storage. It explicitly discusses balancing different storage characteristics, which includes performance, cost, and reliability. This aligns with the "trade-off" concept in the '669 patent. The controller stores data in accordance with these policies. The primary difference is the context; the '664 application appears focused on a higher-level storage system (like a network-attached storage or storage area network) managing multiple tiers of storage, rather than a single device controller's management of its internal physical media. It does not explicitly mention refusing a delete request at the device level based on a policy.
  • Claim 14 & 20: The method of using policies to govern storage is central to this application. However, its system-level perspective may differentiate it from the device-specific claims of the '669 patent. The elements of refusing a delete request and storing metadata remotely are not explicitly detailed in the abstract or a brief review.

V. U.S. Patent Application Publication No. 2013/0198424 A1

• Full Citation: Flynn, David, et al. Storage Controller with Tiered Memory. U.S. Patent Application Publication No. 2013/0198424 A1, published Aug. 1, 2013. (Filed Jan. 25, 2013).
• Assignee: Fusion-io, Inc.
• Brief Description: This document describes a storage device with a controller that manages different types of non-volatile memory (a "tiered" memory system) within a single device. The controller uses policies to determine how data is allocated and moved between these tiers to optimize for performance, endurance, or other characteristics. For example, frequently accessed data might be kept in a faster, more durable memory tier.
• Potential Anticipation Analysis:
  • Claim 1: The '424 application discloses a controller that uses "policies" to manage data placement across different storage media types within the device. This management inherently involves making trade-offs between performance and reliability (endurance of different media types). This is similar to the "trade-off" concept in the '669 patent. However, the focus is on managing tiers of memory rather than adjusting the fundamental write characteristics (like density) on a single type of medium. It also does not appear to describe a policy for refusing to delete data.
  • Claim 14 & 20: The method of using a policy to determine where to store content is present. The system stores content and associated metadata. However, the specific combination of a user-configurable policy for reliability vs. volume, the refusal of deletes, and the remote storage of metadata, as recited in the '669 claims, is not fully taught by this reference.

Summary of Prior Art Analysis

The cited prior art references establish that the concept of using policies within a storage device controller to manage data placement and optimize for performance or reliability was known in the art prior to the invention of US 11,327,669. Patents like '248 (HPE) and '463 (FADU) come close to describing the trade-off between reliability and performance/capacity.

However, none of the reviewed references appear to explicitly disclose the full combination of elements required by the independent claims of the '669 patent. Specifically, the element of the storage device policy including a provision to "refuse a delete request" based on the storage information, and the capability to store the "storage information at a remote location" (as in claim 14), appear to be distinguishing features not clearly present in this set of prior art. These elements, which provide for data immutability and disaggregated metadata management at the device level, may constitute the novel and non-obvious aspects of the invention claimed in U.S. Patent No. 11,327,669.

Obviousness Analysis of U.S. Patent No. 11,327,669 under 35 U.S.C. § 103

This analysis evaluates whether the invention claimed in U.S. Patent No. 11,327,669 would have been obvious to a Person of Ordinary Skill in the Art (POSITA) at the time the invention was made. The analysis is based on combining the teachings of the prior art references cited during the patent's prosecution. The key inventive concept of the '669 patent appears to be the integration of a user-configurable policy at the device controller level that not only manages the trade-off between storage capacity and data reliability but also enables features like data immutability ("refuse a delete request") and remote management of storage metadata.

A POSITA in this field would likely be an engineer or computer scientist with experience in data storage systems, including hard disk drive (HDD) or solid-state drive (SSD) controller design, file systems, and enterprise storage architectures (e.g., SAN, NAS).

Combination of Prior Art Rendering the Claims Obvious

The independent claims of the '669 patent (1, 14, and 20) can be rendered obvious by combining the teachings of U.S. Patent No. 10,489,248 B2 (Frost et al.) with the well-known principles of Write-Once-Read-Many (WORM) storage and distributed metadata management, which are implicitly part of the background knowledge a POSITA would possess.

Primary Reference: Frost et al. (U.S. Patent No. 10,489,248 B2)

Frost teaches the core concept of the '669 patent: a storage controller that dynamically selects a data storage mode to tune performance and reliability. Frost explicitly discloses:

• A storage controller for a storage device.
• The use of different "storage modes" (e.g., various RAID levels), which function as policies.
• The management of a trade-off between reliability and performance/capacity. For example, selecting RAID 1 provides high reliability (mirroring) at the cost of 50% capacity, while selecting RAID 0 provides high performance and full capacity but no data redundancy. This directly teaches the "trade-off between reliability of storage and volume of storage" recited in claim 1.
• Storing data in accordance with the selected policy.

Frost provides a strong foundation by teaching a policy-based controller that makes trade-offs between reliability and capacity. However, Frost does not explicitly teach the elements of (a) refusing a delete request or (b) storing metadata at a remote location.

Secondary Art and Motivation to Combine

1. The "Refuse a Delete Request" Element (WORM Functionality)

The concept of immutable, or Write-Once-Read-Many (WORM), storage was well-established in the art long before the '669 patent's priority date of 2016. WORM storage is a fundamental requirement for data archiving, regulatory compliance (e.g., SEC Rule 17a-4), and legal data preservation. Storage systems, from optical disks to specialized tape and disk arrays, have long offered WORM capabilities.

• Motivation to Combine: A POSITA, starting with Frost's system of selectable storage modes, would be motivated to add a "WORM" or "immutable" mode to the available policy choices. The motivation is clear and compelling: to extend the functionality of the storage device to serve the significant market for archival and compliance storage. Adding an immutability policy is a logical and predictable extension of a policy-based system. For a controller that already offers policies for performance (RAID 0) and reliability (RAID 1, RAID 5), adding a policy for permanence (WORM) would be a natural next step to create a more versatile and commercially valuable product.
• Obvious Implementation: Implementing this WORM policy would inherently require the device controller to "refuse a delete request" for any data written in this mode, as this is the defining characteristic of WORM storage. The controller would simply need to check the storage information associated with the data block or object; if the "immutable" policy flag is set, any subsequent delete command for that data would be rejected. This combines the policy mechanism of Frost with the known function of WORM storage.

2. The "Store Storage Information at a Remote Location" Element

The practice of separating metadata (or "storage information") from data and managing it centrally or remotely is a common architectural pattern in distributed and enterprise storage systems. This is done for reasons of scalability, security, and manageability. Systems like object storage (e.g., Amazon S3, OpenStack Swift) and distributed file systems rely on separate metadata services to track the location and attributes of data objects spread across many physical devices.

• Motivation to Combine: A POSITA tasked with implementing a WORM feature for compliance purposes on a device like that described by Frost would be highly motivated to store the associated storage information (e.g., object ID, location, retention policy, cryptographic hash) in a secure, remote location. The motivations are twofold:
  • Security and Integrity: Storing the "keys to the castle" (the metadata) on the same device as the data makes the system vulnerable. If the device itself is compromised, the immutability guarantees could be bypassed by altering the local metadata. Storing it on a separate, hardened "key device" or metadata server (as shown in FIG. 5 of the '669 patent) significantly enhances security and auditability, which are paramount for compliance.
  • Centralized Management: In a large-scale deployment with many such drives (as depicted in FIG. 3 and FIG. 5 of the '669 patent), managing retention policies and access rights on a per-drive basis is inefficient and error-prone. A remote, centralized policy and metadata server allows an administrator to manage the entire storage pool from a single point, a standard practice in enterprise IT.

Conclusion on Obviousness

The independent claims of the '669 patent describe a combination of features that, while effective, are composed of well-understood elements from the field of data storage.

• Claim 1 would be obvious over Frost '248 in view of the well-known principles of WORM storage. Frost provides the policy-based controller managing reliability/volume trade-offs. A POSITA would have found it obvious to add an "immutable" policy to Frost's system to meet demands for data permanence, which would necessarily involve refusing delete requests.

• Claim 14 would be obvious over Frost '248 in view of both the principles of WORM storage and remote/centralized metadata management. The motivation to add immutability is the same as for claim 1. The further motivation to store the corresponding metadata remotely is driven by fundamental requirements of security and manageability in enterprise and cloud-scale storage environments, where such policy-based devices would be deployed.

• Claim 20, being a non-transitory computer-readable medium claim, recites the same functional steps as the method and system claims. Therefore, it would be rendered obvious by the same combination of references for the same reasons. The instructions on the medium would simply cause the device controller to execute the obvious method derived from combining Frost's policy engine with WORM and remote metadata management principles.

Patent Term and Family Data for U.S. Patent No. 11,327,669

Based on a thorough review of the prosecution history and continuity data for U.S. Patent No. 11,327,669 ("the '669 patent"), the following information details the patent's term, related applications, and projected expiration.

Key Dates:

• Patent Number: 11,327,669
• Application Number: 16/990,433
• Filing Date: August 11, 2020
• Issue Date: May 10, 2022
• Priority Date: November 7, 2016

Patent Term Adjustment (PTA)

A Patent Term Adjustment (PTA) is granted to compensate for certain administrative delays by the U.S. Patent and Trademark Office (USPTO) during the prosecution of a patent. For the '669 patent, a total of 364 days of PTA was calculated and granted by the USPTO. This adjustment is added to the standard 20-year term of the patent.

The 20-year statutory term of the patent, calculated from its earliest priority date of November 7, 2016, would normally end on November 7, 2036. The addition of the 364-day PTA extends this term.

Projected Expiration Date

The projected expiration date of the '669 patent is calculated by adding the 20-year term to the priority date and then adding the granted PTA.

• Priority Date: November 7, 2016
• Add 20 Years: November 7, 2036
• Add 364 Days (PTA): November 6, 2037

Therefore, the anticipated expiration date for U.S. Patent No. 11,327,669 is November 6, 2037. This assumes that all required maintenance fees are paid in a timely manner and no terminal disclaimers have been filed that would shorten the term.

Continuation Applications and Patent Family

The '669 patent is part of a larger family of applications that claim priority to the same original invention. This is a common strategy used to pursue claims of varying scope and cover different aspects of an invention. The known related applications are detailed below.

Parent Application:
The '669 patent is a continuation of the following application:

• Application No. 15/805,946: Filed on November 7, 2017, now issued as U.S. Patent No. 10,776,269. This patent shares the same priority date of November 7, 2016.

Child Applications (Continuations):
The '669 patent itself has served as the basis for subsequent continuation applications, further expanding the patent family. These include:

• Application No. 17/716,275: Filed on April 8, 2022, now issued as U.S. Patent No. 11,907,553.
• Application No. 18/408,670: Filed on January 10, 2024, now issued as U.S. Patent No. 12,265,715.
• Application No. 19/066,396: Filed on February 28, 2025, now published as U.S. Patent Application Publication No. 2025/0328270 A1. This application is currently pending before the USPTO.

There are no divisional applications associated with the '669 patent. The listed applications are all continuations, which build upon the original disclosure.

Summary of Family Members:

• U.S. Patent No. 10,776,269 (Parent)
• U.S. Patent No. 11,327,669 (Subject Patent)
• U.S. Patent No. 11,907,553 (Child)
• U.S. Patent No. 12,265,715 (Child)
• U.S. Patent Application Pub. No. 2025/0328270 A1 (Child, Pending)

Defensive Disclosure and Prior Art Generation Based on U.S. Patent 11,327,669

Publication Date: May 9, 2026
Subject: Advanced Methods for Policy-Based Management of Data Storage Devices

This document discloses novel extensions and applications of the concepts described in U.S. Patent 11,327,669. The purpose of this disclosure is to place these derivative concepts into the public domain, thereby establishing prior art against future patent applications on these and similar incremental innovations. The core concept involves a storage device controller that accepts a dynamic policy to manage physical data placement, balancing reliability versus capacity, and enabling features such as immutability and remote metadata management.

---

Derivative Variations on Core Claims

Axis 1: Material & Component Substitution

1.1. Policy-Driven Volumetric Control in Phase-Change Memory (PCM)

• Enabling Description: This variation replaces NAND flash with Phase-Change Memory (PCM) or other emerging non-volatile memories like ReRAM or MRAM. The storage policy directly controls the physical state of the memory cells. For higher reliability, the policy instructs the controller to use multi-level cell (MLC) programming with wider-spaced resistance levels and stronger Error Correction Code (ECC). For maximum capacity, the policy can switch to quad-level cell (QLC) or higher-density programming, accepting a higher raw bit error rate (RBER) that is managed by a more computationally intensive ECC scheme. The policy can be applied on a per-region basis, allowing a single PCM array to have zones of high-endurance/high-reliability storage coexisting with zones of high-capacity/lower-endurance storage. The "refuse delete" instruction would logically lock the programming state of a block, preventing further phase-change cycles on that block.
• Mermaid Diagram:

  graph TD
      A[Storage Request] --> B{Device Controller};
      C[Storage Policy: Reliability vs. Capacity] --> B;
      B --> D{Policy Engine};
      D -- "High Reliability" --> E[Program PCM as MLC];
      D -- "High Capacity" --> F[Program PCM as QLC];
      E --> G[Write Data to PCM Array];
      F --> G;
      G --> H(Record Storage Info: Cell Mode, Location, ECC);
  

1.2. Hardware-Accelerated Policy Enforcement via FPGA/NPU

• Enabling Description: The device controller is implemented as a System-on-Chip (SoC) that includes a Field-Programmable Gate Array (FPGA) or a Neural Processing Unit (NPU) in the data path. The storage device policy is compiled into a hardware configuration for the FPGA or a model for the NPU. This allows for line-rate policy enforcement. For instance, a policy requiring data-type-aware storage could use the NPU to classify incoming data blocks (e.g., text, image, encrypted) and route them to different storage regions with pre-defined reliability/capacity trade-offs, all without intervention from the main CPU. Immutability rules are burned into the FPGA's logic, making it computationally impossible to bypass them without re-flashing the hardware, providing a higher level of security.
• Mermaid Diagram:

  sequenceDiagram
      participant Host
      participant SoC_CPU as CPU
      participant SoC_FPGA as FPGA/NPU
      participant StorageMedia
  
      Host->>CPU: Write Request (Data, Policy)
      CPU->>FPGA/NPU: Load Policy as Hardware Config
      CPU->>FPGA/NPU: Stream Data
      FPGA/NPU->>FPGA/NPU: Classify & Route Data based on Policy
      FPGA/NPU->>StorageMedia: Write to Optimized Region
      StorageMedia-->>FPGA/NPU: Write ACK
      FPGA/NPU-->>CPU: Completion Status
      CPU-->>Host: Write Complete
  

1.3. Bio-Synthetic Storage with Enzymatic Policies

• Enabling Description: This variation applies the policy concept to DNA-based archival storage. The storage medium is a pool of synthesized DNA strands. The "storage device policy" is a set of rules for the DNA synthesis and sequencing process. A high-reliability policy would encode the data with extreme redundancy (e.g., a high-ratio fountain code) and add multiple layers of chemical stabilizers. A high-capacity policy would use a denser encoding scheme with minimal redundancy. The "device controller" is a microfluidics system that manages the enzymatic reactions. A "delete request" would trigger the introduction of a specific nuclease enzyme that targets and destroys the DNA strands corresponding to that data, while a "refuse delete" policy would mean the controller's inability to synthesize or release that specific nuclease.
• Mermaid Diagram:

  graph TD
      subgraph Microfluidic Controller
          A[Receive Data + Policy] --> B{Encoding Algorithm Selection};
          B -- High Reliability --> C[High Redundancy Encoder (e.g., Fountain Code)];
          B -- High Capacity --> D[Dense Encoding];
          C --> E[DNA Synthesizer];
          D --> E;
          E --> F[Store DNA in Archive Pool];
      end
      subgraph Retrieval
          G[Read Request] --> H{Sequencer};
          H --> I[Decode based on Metadata];
          I --> J[Return Data];
      end
      subgraph Deletion
          K[Delete Request] --> L{Policy Check};
          L -- "Immutable=True" --> M[Refuse Request];
          L -- "Immutable=False" --> N[Synthesize & Deploy Nuclease];
      end
      F -- Sequence --> H
      A -- Creates Metadata --> I
  

---

Axis 2: Operational Parameter Expansion

2.1. Memristor Neuromorphic Substrate with Synaptic Precision Policy

• Enabling Description: This technology is applied to a neuromorphic computing chip using a memristor crossbar array as analog non-volatile memory. The "storage device" in this context is the synaptic weight matrix. The "storage device policy" defines the trade-off between synaptic precision (reliability of the neural network's computation) and the number of synapses that can be represented (capacity). A high-reliability policy would use multiple physical memristors to represent a single synapse, averaging their conductance values to reduce noise. A high-capacity policy would map one synapse to one memristor, accepting higher analog noise for greater model density. The "refuse delete" command would apply to a trained model layer, preventing overwriting of its learned weights.
• Mermaid Diagram:

  graph TD
      A[Load Neural Network Layer] --> B[Controller];
      C[Synaptic Policy: Precision vs. Density] --> B;
      B --> D{Weight Mapping Module};
      D -- "High Precision" --> E[Map 1 Synapse to N Memristors];
      D -- "High Density" --> F[Map 1 Synapse to 1 Memristor];
      E --> G[Program Memristor Array];
      F --> G;
  

2.2. Cryogenic Storage Policy for Quantum Computing Systems

• Enabling Description: In a control system for a quantum computer operating at near-absolute zero, this invention manages classical configuration and calibration data stored on cryo-CMOS memory. The "storage device policy" is a function of qubit coherence times and environmental factors like thermal fluctuations and radiation strikes detected by on-chip sensors. A "high-reliability" policy, triggered by rising temperatures or radiation, dynamically increases the refresh rate of the DRAM-based control memory and applies multi-bit error correction, reducing available bandwidth (capacity) but ensuring the integrity of quantum gate parameters. A "refuse delete" policy would protect factory-calibrated noise models and qubit characterization data from being overwritten.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Nominal
      Nominal: Low ECC / Low Refresh Rate (High Capacity)
      Nominal --> High_Alert: Temperature Spike or Radiation > Threshold
      High_Alert: High ECC / High Refresh Rate (High Reliability)
      High_Alert --> Nominal: Environment Stable
      state Nominal {
          direction LR
          [*] --> Idle
          Idle --> Writing: Write_Request(Data)
          Writing --> Idle: Write_Data_Low_ECC()
          Idle --> Reading: Read_Request(Addr)
          Reading --> Idle: Read_Data()
      }
      state High_Alert {
          direction LR
          [*] --> Idle
          Idle --> Writing: Write_Request(Data)
          Writing --> Idle: Write_Data_High_ECC()
          Idle --> Reading: Read_Request(Addr)
          Reading --> Idle: Read_Data()
      }
  

2.3. Sub-Microsecond Policy Switching for High-Frequency Trading (HFT)

• Enabling Description: A specialized solid-state storage device for HFT applications uses a policy directly tied to a live market data feed. The "storage device policy" is defined by market volatility metrics. During low volatility (low risk), the device operates in a "high-capacity" mode, journaling thousands of transactions with minimal redundancy. When a market data feed indicates a volatility spike above a predefined threshold, the controller switches in under a microsecond to a "high-reliability" mode. In this mode, every transaction is triple-mirrored to physically distinct regions of the NAND flash and the storage metadata is synchronously committed to a secondary controller, ensuring no data loss in case of a system crash during a critical market event.
• Mermaid Diagram:

  sequenceDiagram
      participant MarketFeed
      participant HFT_Storage_Device
      participant NAND_Flash
  
      loop Real-Time Operation
          MarketFeed->>HFT_Storage_Device: Market Data (Volatility)
          alt Volatility > Threshold
              HFT_Storage_Device->>HFT_Storage_Device: Set Policy = High_Reliability
          else Volatility <= Threshold
              HFT_Storage_Device->>HFT_Storage_Device: Set Policy = High_Capacity
          end
          HFT_Storage_Device->>NAND_Flash: Write Trade Data (per policy)
      end
  

---

Axis 3: Cross-Domain Application

3.1. Aerospace: Adaptive Flight Data Recorder (Black Box)

• Enabling Description: An aircraft Event Data Recorder (EDR) is built with two tiers of solid-state memory: a high-capacity tier for routine data logging and a smaller, hardened, crash-survivable memory unit (CSMU). The device controller continuously monitors flight parameters from the avionics bus. The default "storage policy" directs all data (cockpit voice, flight parameters, etc.) to be written to the high-capacity tier using compression to maximize history (volume). If the controller's policy engine detects parameters exceeding a predefined safety envelope (e.g., excessive g-force, stall warning, engine failure), it triggers a policy change. The system immediately begins writing uncompressed, redundant data streams to the hardened CSMU and makes this critical incident data immutable, refusing any subsequent delete or overwrite commands for that data segment.
• Mermaid Diagram:

  graph TD
      A[Avionics Data Stream] --> B{EDR Controller};
      B -- Normal Flight --> C{Policy: High Capacity};
      C --> D[Write Compressed Data to Standard Memory];
      B -- Anomaly Detected --> E{Policy: High Reliability};
      E --> F[Write Uncompressed/Redundant Data to CSMU];
      F --> G[Mark Data as Immutable];
  

3.2. AgTech: Smart Soil Sensor with Environmental Policy Adaptation

• Enabling Description: A distributed network of in-ground agricultural sensors uses policy-based storage to manage power consumption and data fidelity. Each sensor node has limited battery and local flash storage. The "storage policy" is transmitted from a central gateway and can be updated based on weather forecasts or satellite imagery. The "default" policy prioritizes low power, sampling and storing data at low frequency and resolution to maximize battery life (reliability of the device's operational longevity). If the gateway pushes a "critical event" policy (e.g., impending frost, soil pathogen detection), the sensor controller switches to a "high-fidelity" mode. It increases sampling rates, stores high-resolution data, and flags this data as immutable for post-event analysis, sacrificing battery life for critical data capture.
• Mermaid Diagram:

  stateDiagram-v2
      state "Low Power Mode" as Low {
          [*] --> Sampling
          Sampling --> Storing : Data Point
          Storing --> Sleeping : Write Complete
          Sleeping --> Sampling : Wake on Timer
      }
      state "High Fidelity Mode" as High {
          [*] --> Sampling_HF
          Sampling_HF --> Storing_HF : Data Point (High Res)
          Storing_HF --> Sampling_HF : Write Complete (No Sleep)
      }
      Low --> High : Policy Update (Critical Event)
      High --> Low : Policy Update (Event End)
  

3.3. Automotive: Collision-Imminent Event Data Recorder (EDR)

• Enabling Description: The EDR in an autonomous or semi-autonomous vehicle uses a policy-based controller to manage its storage. In normal operation ("Policy: Routine"), it continuously overwrites a loop buffer with compressed sensor data (camera, LiDAR, radar) to conserve space. The controller's policy engine is fed real-time data from the vehicle's advanced driver-assistance system (ADAS). If the ADAS predicts a high probability of a collision, it triggers a policy switch to "Policy: Incident." The controller immediately stops overwriting, writes a multi-second pre-incident buffer from RAM to a protected, immutable section of flash memory, and continues to record post-incident data to that section until the vehicle comes to rest. This entire incident record is flagged as non-deletable, complying with regulatory requirements.
• Mermaid Diagram:

  sequenceDiagram
      participant ADAS
      participant EDR_Controller
      participant Flash_Memory
  
      loop Normal Driving
          ADAS->>EDR_Controller: Sensor Data
          EDR_Controller->>Flash_Memory: Write to Circular Buffer (Overwrite enabled)
      end
  
      ADAS-->>EDR_Controller: Collision Imminent Signal!
      EDR_Controller->>EDR_Controller: Switch Policy to 'Incident'
      EDR_Controller->>Flash_Memory: Write Pre-Incident Buffer (Immutable)
      EDR_Controller->>Flash_Memory: Write Live Data (Immutable)
  

---

Axis 4: Integration with Emerging Technologies

4.1. AI-Driven Predictive Storage Policy Generation

• Enabling Description: The device controller incorporates a lightweight, on-device machine learning (ML) model (e.g., a recurrent neural network) trained to predict future I/O patterns based on recent access history. Instead of a static policy, the controller's ML model dynamically generates and refines the storage policy in real-time. For example, if it detects a pattern of large, sequential writes, it preemptively reconfigures a region of the drive for maximum write throughput and lower data retention (lowering reliability for temporary data). If it detects a pattern of small, random reads to a specific data set, it may migrate that data to a low-latency, high-endurance region and increase its redundancy factor. This creates a self-optimizing storage device.
• Mermaid Diagram:

  graph LR
      A[I/O Request Stream] --> B(ML Model);
      B -- Analyzes Patterns --> C(Policy Generator);
      C -- Generates/Updates --> D[Dynamic Storage Policy];
      A --> E{Device Controller};
      D --> E;
      E -- Uses Policy --> F[Execute Read/Write on Storage Medium];
  

4.2. IoT-Aware Storage with Physical State-Based Policies

• Enabling Description: The storage device is equipped with embedded sensors for monitoring temperature, G-force/vibration, and voltage stability. This real-time telemetry is fed directly into the device controller's policy engine. The "storage device policy" is a multi-dimensional map that correlates physical conditions with storage parameters. For example, a policy table could specify that if ambient temperature exceeds 60°C, all write operations must use a wider cell voltage margin and an accompanying data block checksum (increasing reliability, decreasing capacity). If a vibration sensor detects a shock event, the controller can temporarily halt write operations to prevent head-slap in an HDD or write-disturb in an SSD, queueing the I/O until stability returns.
• Mermaid Diagram:

  graph TD
      subgraph On-Device Sensors
          Temp[Temperature Sensor]
          Vibe[Vibration Sensor]
          Volt[Voltage Sensor]
      end
      subgraph Device Controller
          PolicyEngine
          IO_Queue
          WriteLogic
      end
      Temp --> PolicyEngine
      Vibe --> PolicyEngine
      Volt --> PolicyEngine
      PolicyEngine -- "Unstable: Pause Writes" --> IO_Queue
      PolicyEngine -- "Hot: Use Strong ECC" --> WriteLogic
      IO_Queue --> WriteLogic
  

**4.3. Blockchain-Verified Immutability and Chain-of-Custody**
*   **Enabling Description:** For applications requiring a provable and auditable data lifecycle, the storage device controller has a lightweight blockchain client. When a request to store data with an "immutable" policy is received, the controller performs the following steps: 1) Writes the data to the physical media. 2) Calculates a cryptographic hash (e.g., SHA-256) of the data content and its physical storage location metadata. 3) Creates a transaction containing this hash, a timestamp, and the content identifier. 4) Signs the transaction with its private key and broadcasts it to a designated private or consortium blockchain. Any attempt to delete the data would be refused by the controller, and its immutability can be independently verified by querying the blockchain for the data's hash. This provides a tamper-proof audit trail for data chain-of-custody.
*   **Mermaid Diagram:**
    ```mermaid
    sequenceDiagram
        actor User
        participant DeviceController
        participant StorageMedium
        participant Blockchain

        User->>DeviceController: Write(Data, Policy:Immutable)
        DeviceController->>StorageMedium: Store Data
        DeviceController->>DeviceController: Hash(Data + Metadata) -> H
        DeviceController->>Blockchain: Submit Transaction(H, timestamp, ID)
        Blockchain-->>DeviceController: Transaction Confirmed
        DeviceController-->>User: Write Success + TxID
    ```
---

#### **Axis 5: The "Inverse" or Failure Mode**

**5.1. Graceful Degradation Policy for High-Wear Environments**
*   **Enabling Description:** The storage device controller actively monitors the health of the storage medium (e.g., P/E cycle count on NAND, reallocated sector count on HDD). The storage policy includes multiple degradation stages. Stage 1 (Normal): Full capacity and performance. Stage 2 (Elevated Wear): Controller automatically reduces write density (e.g., switches from TLC to MLC mode), increases ECC strength, and flags the host system of its reduced-capacity/high-reliability state. Stage 3 (Critical Wear): Controller marks the entire device as read-only, preserving the existing data for retrieval while refusing all new write requests. This prevents catastrophic data loss from a worn-out medium by enforcing a policy of safe, predictable failure.
*   **Mermaid Diagram:**
    ```mermaid
    stateDiagram-v2
        state "Stage 1: Healthy" as S1
        state "Stage 2: Degraded" as S2
        state "Stage 3: Read-Only" as S3
        [*] --> S1
        S1 --> S2 : Wear Level > T1
        S2 --> S3 : Wear Level > T2
        S2 --> S1 : (Not Possible)
        S3 --> [*]

        S1: R/W Enabled, Max Capacity
        S2: R/W Enabled, Reduced Capacity, High ECC
        S3: Read-Only, Writes Refused
    ```

**5.2. Policy-Based Data Evanescence (Time-to-Live)**
*   **Enabling Description:** This is the inverse of the "refuse delete" feature. A user can write data with a policy that includes a "Time-to-Live" (TTL) or an "expiry timestamp." The storage controller records this TTL metadata alongside the data's location. A dedicated, low-priority background process within the controller's firmware periodically scans the metadata. When it finds an object whose TTL has expired, it performs a secure erase of the associated physical blocks. This is not a simple file system delete, but a cryptographic-erase or a block-purge command, ensuring the data is irrecoverable. This is useful for managing ephemeral session data or complying with data retention policies like GDPR's "right to be forgotten" at the hardware level.
*   **Mermaid Diagram:**
    ```mermaid
    graph TD
        subgraph Write Path
            A[Write Request + TTL] --> B{Controller};
            B --> C[Store Data on Media];
            B --> D[Store Metadata(Location, TTL)];
        end
        subgraph Background Process
            E(Timer Tick) --> F{Scan Metadata for Expired TTLs};
            F -- Found Expired --> G[Queue Secure Erase Job];
            G --> H[Execute Purge/Cryptographic Erase on Media];
        end
    ```
---

### **Combination Prior Art with Open-Source Standards**

**Scenario 1: Policy-Based Storage Classes in Kubernetes via NVMe Directives**
*   **Description:** The functionality of the patent is integrated with open-source cloud-native orchestration. A Kubernetes `StorageClass` is defined with new parameters like `reliabilityLevel: (high|medium|low)` and `immutability: "true"`. An open-source Container Storage Interface (CSI) driver is developed to translate these abstract Kubernetes storage requests into specific NVMe "Set Features" commands or vendor-specific commands. When a pod requests a `PersistentVolumeClaim` from this class, the CSI driver communicates directly with the NVMe device controller, setting its internal policy to match the application's declared requirements for that volume. For example, a database pod could request `reliabilityLevel: high`, causing the controller to use MLC mode and data mirroring, while a caching pod could request `reliabilityLevel: low` to maximize IOPS and capacity using QLC mode. This leverages the NVMe standard and Kubernetes' extensible storage architecture.

**Scenario 2: Secure Policy Management using RISC-V and Keystone Enclave**
*   **Description:** The storage device's controller is built upon an open-source RISC-V processor core. The policy engine and the cryptographic keys for data encryption are isolated within a secure enclave using the Keystone open-source framework. The storage policy itself is delivered to the drive as a signed binary. The controller's bootloader verifies the policy's signature against a public key fused into the RISC-V SoC's one-time programmable memory. The policy is then loaded into and executed entirely within the secure enclave. This ensures that even a compromised host operating system cannot tamper with the storage policy (e.g., disable an immutability rule) or access the encryption keys for the data. This combines the patent's concept with the open standards of the RISC-V ISA and Keystone's security primitives.

**Scenario 3: Integration with ZFS for Policy-Aware Data Placement**
*   **Description:** The OpenZFS filesystem is made aware of the underlying device's policy capabilities. ZFS datasets can be created with a new property, e.g., `set zfs_storage_policy=reliability_high`. When ZFS writes data to a device that advertises this capability, it includes a metadata hint along with the write command. The device controller interprets this hint and applies the corresponding internal policy (e.g., lower density, stronger ECC). This allows for a much more granular application of storage policies than at the whole-device level. A single ZFS pool could contain datasets with different reliability and capacity trade-offs residing on the same physical device, with ZFS orchestrating the data placement and the device controller enforcing the physical storage characteristics. This requires extending the open-source ZFS codebase and defining a standardized set of hints for block storage command sets like NVMe or SCSI.