US 10776023

Based on the information from the initial search and the provided patent text, here is a summary of U.S. Patent No. 10,776,023.

U.S. Patent 10,776,023: Summary

• 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: November 6, 2017
• Issue Date: September 15, 2020
• Abstract: Aspects of the disclosure are related to data storage devices and in particular to data storage devices with configurable policy-based read and write behavior. A storage device is provided. A device controller with a memory is coupled with the storage device. The memory stores an application with instructions that direct the controller to receive a storage device policy. The instructions further direct the controller to store content from a storage request in accordance with the storage device policy, and record storage information, including at least a content identifier, to the memory. The instructions further direct the controller to retrieve the content according to the storage information received in a storage request. The instructions further provide instruction to refuse a delete request in accordance to the storage information. The instructions provide direction to store the storage information at a remote location.

Plain-Language Overview of Independent Claims

U.S. Patent 10,776,023 has one independent claim.

• Claim 1: This claim describes a method for a data storage device to manage data. The device's controller receives a "storage device policy" which acts as a set of rules. When a request to store data (content) comes in, the controller uses this policy to decide how and where to save the data on the storage media. It then records information about this stored data, including a unique identifier, in its memory. When a request to read the data is received, the controller uses this stored information to find and retrieve the correct content. The policy can also instruct the controller to refuse to delete certain data and can specify that the storage information should be saved in a separate, remote location for added security or management. This allows for flexible and customizable control over how the storage device behaves, a departure from traditional drives with fixed, built-in firmware.

Litigation

As of April 2026, U.S. Patent 10,776,023 has been asserted in litigation. Gaea LLC has filed a lawsuit against Meta Platforms, Inc. in the U.S. District Court for the Northern District of Texas. The patent has also been asserted against Samsung. There is an active effort by Unified Patents, a company that works to deter patent assertions from non-practicing entities (NPEs), to find prior art that could invalidate claims of this patent. A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not yield any specific results for this patent number at this time.

Known Litigation Involving U.S. Patent 10,776,023

Based on a review of available data as of April 30, 2026, U.S. Patent No. 10,776,023 is involved in the following litigation:

• Plaintiff(s): Gaea LLC

• Defendant(s): Meta Platforms, Inc.

• Jurisdiction: U.S. District Court for the Northern District of Texas

• Case Number: 4:26-cv-00348

• Filing Date: The exact filing date for this specific case in 2026 is not detailed in the provided search snippet, but related litigation activity involving the patent family exists.

• Status/Outcome: This case is currently active. According to Unified Patents, this litigation is part of a broader assertion campaign by Gaea LLC, which has also targeted other companies. Unified Patents has initiated a contest seeking prior art to challenge the validity of this patent, indicating ongoing dispute over its claims.

• Plaintiff(s): Gaea LLC

• Defendant(s): [[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.); Samsung Electronics America, Inc.

• Jurisdiction: U.S. District Court for the Western District of Texas

• Case Number: 6:23-cv-00522

• Filing Date: July 21, 2023

• Status/Outcome: This case is currently active. It is part of the same assertion campaign as the case against Meta Platforms, Inc.

• Plaintiff(s): Gaea LLC

• Defendant(s): Pure Storage, Inc.

• Jurisdiction: U.S. District Court for the Western District of Texas

• Case Number: 6:23-cv-00521

• Filing Date: July 21, 2023

• Status/Outcome: This case is currently active.

• Plaintiff(s): Gaea LLC

• Defendant(s): Oracle Corporation

• Jurisdiction: U.S. District Court for the Western District of Texas

• Case Number: 6:23-cv-00520

• Filing Date: July 21, 2023

• Status/Outcome: This case is currently active.

• Plaintiff(s): Gaea LLC

• Defendant(s): NetApp, Inc.

• Jurisdiction: U.S. District Court for the Western District of Texas

• Case Number: 6:23-cv-00519

• Filing Date: July 21, 2023

• Status/Outcome: This case is currently active.

• Plaintiff(s): Gaea LLC

• Defendant(s): Dell Technologies Inc.; Dell Inc.; EMC Corporation

• Jurisdiction: U.S. District Court for the Western District of Texas

• Case Number: 6:23-cv-00518

• Filing Date: July 21, 2023

• Status/Outcome: This case is currently active.

• Plaintiff(s): Gaea LLC

• Defendant(s): Hewlett Packard Enterprise Company

• Jurisdiction: U.S. District Court for the Western District of Texas

• Case Number: 6:23-cv-00517

• Filing Date: July 21, 2023

• Status/Outcome: This case is currently active.

Proceedings overview

As of May 26, 2026, there are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method) on file for U.S. Patent No. 10,776,023 with the USPTO PTAB. This means that all claims of the patent remain untested at the PTAB, offering no pre-adjudicated grounds for a defendant to rely on, but also leaving all avenues of PTAB challenge open.

Strategic summary

Currently, all claims of U.S. Patent No. 10,776,023 remain SUSTAINED as they have not been challenged or invalidated through any PTAB proceeding. Therefore, no claims are canceled, and all claims are considered UNTESTED by the PTAB.

Since no PTAB proceedings have been initiated for US 10776023, there is no estoppel landscape to consider under § 315(e)(2). All potential prior-art grounds, whether raised in other litigation or newly discovered, are still available for a future PTAB petition.

The absence of PTAB activity is a notable signal for a patent that is actively being asserted in litigation, as indicated by the lawsuits filed by Gaea LLC against Meta Platforms, Inc., Samsung, Pure Storage, Oracle, NetApp, Dell, and [Hewlett Packard Enterprise Company.](/litigations/by-defendant/Hewlett%20Packard%20Enterprise%20Company.) Often, patents asserted against multiple defendants attract IPR challenges as defendants seek to invalidate the patent efficiently. The fact that Unified Patents has initiated a contest seeking prior art to challenge the validity of this patent further highlights its potential vulnerability and the interest from the defense community in challenging its claims, even though no formal PTAB petitions have been filed yet.

Recommended next steps

Since no PTAB activity exists for U.S. Patent No. 10,776,023, the recommended next steps for a defendant currently facing assertion of this patent would include:

• Prior Art Search: Conduct a comprehensive prior art search to identify strong invalidity grounds that could form the basis of an IPR petition. The analysis of prior art cited during prosecution (US 2012/0159085 A1 by LSI in particular) suggests potential avenues for challenge. The Unified Patents contest also indicates an ongoing search for robust prior art.
• Petition Drafting: If strong prior art is found, consider drafting an IPR petition to challenge the asserted claims. This would be a proactive step to potentially invalidate the patent or at least stay the district court litigation.
• Monitoring PTAB Dockets: Continuously monitor the PTAB's Electronic Filing System (E2E) for any newly filed petitions against U.S. Patent No. 10,776,023, as other defendants in the ongoing litigation may initiate proceedings.## Proceedings overview

As of May 26, 2026, there are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method) on file for U.S. Patent No. 10,776,023 with the USPTO PTAB. This means that all claims of the patent remain untested at the PTAB. For a defendant, this indicates that the patent's claims have not been subjected to PTAB scrutiny, meaning all potential prior art avenues are still available for challenge, but also that no claims have been invalidated by the PTAB.

Strategic summary

All claims of U.S. Patent No. 10,776,023 are currently UNTESTED by the PTAB. No claims have been canceled or confirmed as patentable by the Board in an AIA trial.

Since there are no PTAB proceedings on file for US 10776023, there is no estoppel landscape to consider under 35 U.S.C. § 315(e)(2). This means that a defendant currently facing assertion of this patent is not barred from raising any ground of invalidity in a PTAB petition that they raised or reasonably could have raised, as no such proceeding has occurred.

The absence of PTAB activity is noteworthy, especially given the patent's active involvement in multiple district court litigations filed by Gaea LLC against various companies, including Meta Platforms, Inc., Samsung, Pure Storage, Oracle, NetApp, Dell Technologies Inc., and Hewlett Packard Enterprise Company. Typically, patents asserted against multiple entities, particularly by non-practicing entities (NPEs) like Gaea LLC, become targets for AIA trial proceedings as defendants seek efficient means to challenge validity. The fact that Unified Patents is actively seeking prior art to challenge this patent further suggests its potential vulnerability to PTAB review.

Recommended next steps

Given the lack of PTAB activity for U.S. Patent No. 10,776,023, recommended next steps for a defendant facing assertion of this patent include:

• Comprehensive Prior Art Search: Intensify efforts to identify the most relevant prior art, particularly focusing on the combination arguments outlined in the "Obviousness" section (e.g., US 2012/0159085 A1 in view of US 9,489,204 B2 or US 7,539,823 B2). This is crucial for building a strong invalidity case.
• Evaluate IPR Petition: If a robust prior art package is identified, carefully evaluate the merits of filing an Inter Partes Review (IPR) petition. An IPR could offer a cost-effective and efficient path to challenge the validity of the asserted claims.
• Monitor PTAB Dockets: Continuously monitor the USPTO Patent Trial and Appeal Board End-to-End (PTAB E2E) system for any newly filed petitions against U.S. Patent No. 10,776,023 by other defendants in the ongoing litigation. The initiation of a proceeding by one party could impact the strategy of others. If a petition is instituted, it would provide an opportunity to join the proceeding or leverage its outcome.

Inventors

• Joshua Johnson: Employer likely Gaea LLC or an entity from which Gaea LLC acquired rights, given the assignment date predates the application filing.
• Curt Bruner: Employer likely Gaea LLC or an entity from which Gaea LLC acquired rights.
• Jeffrey Reh: Employer likely Gaea LLC or an entity from which Gaea LLC acquired rights.
• Christopher Squires: Employer likely Gaea LLC or an entity from which Gaea LLC acquired rights.
• Brian Wilson: Employer likely Gaea LLC or an entity from which Gaea LLC acquired rights.

The assignments of interest from all named inventors to Gaea LLC were executed on November 7, 2016, preceding the patent application's filing date of November 6, 2017. This pattern is common and indicates that the rights to the invention were assigned to Gaea LLC either as a condition of employment or through a separate agreement prior to the patent application being filed. There is no unusual pattern of inventors departing the original assignee within 12 months of filing.

Original assignee

The original assignee named on the issued patent is Gaea LLC.

Based on the provided information, Gaea LLC is actively asserting this patent in litigation against multiple large technology companies (Meta Platforms, Inc., [[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.), Pure Storage, Inc., Oracle Corporation, NetApp, Inc., Dell Technologies Inc., Dell Inc., EMC Corporation, Hewlett Packard Enterprise Company). This pattern, coupled with the lack of any information indicating Gaea LLC manufactures or sells products embodying the claims of the patent, strongly suggests that Gaea LLC operates as a Non-Practicing Entity (NPE) or patent assertion entity. Their primary line of business appears to be patent licensing and assertion.

Current status: Gaea LLC is currently operating as a plaintiff in patent infringement litigation.

Assignment timeline

The following assignments are recorded for U.S. Patent No. 10,776,023:

1. 2016-11-07 (executed) / recorded 2017-01-05 — Reel 042079/0179

   • Conveyance: ASSIGNMENT
   • Assignor: JOSHUA A JOHNSON, CURT BRUNER, JEFFREY REH, CHRISTOPHER SQUIRES, BRIAN WILSON
   • Assignee: GAEA LLC
   • Correspondent: RYAN M. KAISER, THE LAW OFFICE OF RYAN M. KAISER, PLLC, 701 FIFTH AVE SUITE 4200, SEATTLE WA 98104. This correspondent recurs in this chain.
   • Context: Original assignment of invention rights from all listed inventors to Gaea LLC, prior to the patent application filing.

2. 2018-04-04 (executed) / recorded 2018-05-02 — Reel 044733/0861

   • Conveyance: ASSIGNMENT
   • Assignor: JEFFREY REH, CHRISTOPHER SQUIRES, BRIAN WILSON, JOSHUA JOHNSON, CURT BRUNER
   • Assignee: GAEA LLC
   • Correspondent: RYAN M. KAISER, THE LAW OFFICE OF RYAN M. KAISER, PLLC, 701 FIFTH AVE SUITE 4200, SEATTLE WA 98104. This correspondent recurs in this chain.
   • Context: Confirmatory assignment of invention rights from all listed inventors to Gaea LLC.

Timeline diagram

timeline
    title Ownership of US 10776023
    2016 : Inventors assign to Gaea LLC
    2017 : App filed by Gaea LLC
    2018 : Inventors confirm assignment
    2020 : Patent issued to Gaea LLC
    2023 : Litigation filed by Gaea LLC
    2026 : Further litigation by Gaea LLC

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The initial assignment is from the inventors to Gaea LLC (Reel 042079/0179), which is the plaintiff in numerous active patent infringement lawsuits without any indication of manufacturing or selling products. The generic name "Gaea LLC" is also consistent with a shell entity.
2. Known asserter in the chain — Present. Gaea LLC is identified as a plaintiff in multiple district court litigations concerning this patent, including cases against Meta Platforms, Inc. and Samsung Electronics Co., Ltd., as detailed in the provided litigation summary.
3. Repeat correspondent across the chain — Present. Ryan M. Kaiser of The Law Office of Ryan M. Kaiser, PLLC, is listed as the correspondent for both recorded assignments (Reel 042079/0179 and Reel 044733/0861).
4. Cascading transfers — Not present. There are only two assignments, both directly from the inventors to Gaea LLC, which is the original assignee and the asserting entity. There are no multiple consecutive assignments through chained LLCs.
5. Pre-litigation transfer — Not present. Gaea LLC acquired the patent rights in 2016/2017, well before the first reported litigation filings in 2023.
6. Bankruptcy fire-sale — Not present. There is no information to suggest that the patent was acquired through bankruptcy proceedings.
7. Privateering — Unclear. While Gaea LLC appears to be an NPE, the provided information does not contain explicit evidence of an operating company transferring the patent to Gaea LLC for assertion against competitors on its behalf.
8. Defensive aggregator (anti-NPE) — Not present. The patent is currently held and asserted by Gaea LLC, not a defensive aggregator.

Verdict

NPE — high confidence

Justification: Gaea LLC, the sole assignee since the invention's inception (per Reel 042079/0179 and Reel 044733/0861), is actively asserting this patent in numerous infringement lawsuits against major technology companies, with no indication of producing products. The recurrence of Ryan M. Kaiser as the correspondent for both assignments further supports the pattern of an entity focused on patent assertion.

Verification link: USPTO Patent Assignment Search for 10776023

Analysis of Prior Art Cited in U.S. Patent No. 10,776,023

This analysis examines the prior art references cited during the prosecution of U.S. Patent No. 10,776,023. Each reference is evaluated for its potential to anticipate the claims of the '023 patent under 35 U.S.C. § 102. The core invention of the '023 patent is a data storage device with a controller that uses a configurable "storage device policy" to manage how and where data is stored, and to control access and deletion based on that policy.

Independent Claim 1 of U.S. Patent No. 10,776,023

A method for a data storage device, comprising:

• Receiving, by a device controller of the data storage device, a storage device policy.
• In response to a storage request, storing content included in the storage request in a storage media of the data storage device in accordance with the storage device policy.
• Recording storage information for the content to a memory of the data storage device, wherein the storage information includes a content identifier for the content.
• In response to a retrieval request including the content identifier, retrieving the content from the storage media in accordance with the storage information.
• Refusing a delete request for the content based on the storage information.
• Storing the storage information at a remote location.

Below is an assessment of key prior art references cited by the patent examiner.

---

U.S. Patent No. 9,489,204 B2

• Full Citation: US 9489204 B2, "System and method for enforcing storage policies for data objects"
• Filing Date: March 15, 2013
• Publication Date: November 8, 2016
• Assignee: NetApp, Inc.
• Brief Description: This patent describes a system for managing data storage in a networked environment. It details a "policy engine" that enforces storage policies for data objects across various storage systems. These policies can dictate where data is stored, how it's protected (e.g., replication, snapshots), and its retention period. A central management server can define and distribute these policies to the storage systems.
• Potential Anticipation of Claim(s):
  • Claim 1: This reference appears to disclose several elements of claim 1. It describes receiving and using storage policies to manage data storage. The system stores objects and metadata (storage information) and uses this to retrieve the data. It also covers data retention policies, which aligns with the concept of refusing a delete request. The management of data across a network could be interpreted as storing some information at a remote location. However, the '204 patent focuses on a higher-level, network-wide policy enforcement rather than a policy operating within the device controller of a single storage device, which is a key aspect of the '023 patent. The '023 patent's novelty may lie in the device-level customizability and control, as opposed to a centralized network management approach.

U.S. Patent No. 8,832,367 B2

• Full Citation: US 8832367 B2, "Method and apparatus for data object storage and retrieval"
• Filing Date: March 26, 2012
• Publication Date: September 9, 2014
• Assignee: Cleversafe, Inc.
• Brief Description: This patent discloses a method for storing data objects in a dispersed storage network. It involves encoding a data object into a plurality of "slices" and distributing these slices across different storage units. The system uses a "storage matrix" and access policies to manage how these slices are stored and retrieved. Policies can define the level of redundancy and security.
• Potential Anticipation of Claim(s):
  • Claim 1: This reference teaches the use of policies to determine how data is stored (e.g., the encoding and dispersal method). It also involves storing metadata (storage information) to locate and reassemble the data object. While it deals with storage policies, the focus is on a distributed network of storage units (a "storage grid") and the mathematical transformation of data for that environment. It does not appear to describe a single, self-contained storage device with an on-board, user-configurable controller that manages its own internal media based on a received policy in the manner described in the '023 patent. The concept of refusing a delete request or storing information remotely is also not central to this disclosure.

U.S. Patent No. 8,683,163 B2

• Full Citation: US 8683163 B2, "System and method for providing policy-based cloud storage"
• Filing Date: March 24, 2011
• Publication Date: March 25, 2014
• Assignee: Symantec Corporation
• Brief Description: This patent describes a system that provides policy-based storage in a cloud environment. A "policy engine" receives data and associated policies from a user. Based on these policies, the engine determines which cloud storage provider(s) to use for storing the data. Policies can relate to cost, performance, security, and geographic location.
• Potential Anticipation of Claim(s):
  • Claim 1: While this patent uses the term "policy-based storage," its implementation is at the cloud gateway or broker level, not at the individual storage device level. The "device controller" in this context is a system that decides which cloud service to send the data to, rather than how to physically place data on its own internal storage media. It does not disclose the low-level, device-specific customization that is central to the '023 patent, such as altering recording density or managing media defects based on a user-defined policy.

U.S. Patent Application Publication No. 2012/0159085 A1

• Full Citation: US 20120159085 A1, "Storage device with adaptable parameters"
• Filing Date: December 20, 2010
• Publication Date: June 21, 2012
• Assignee: LSI Corporation
• Brief Description: This application describes a storage device (like an SSD) that can adapt its internal operating parameters based on its usage history or commands from a host system. For example, it might adjust error correction levels, wear-leveling algorithms, or cache management strategies based on the workload it experiences.
• Potential Anticipation of Claim(s):
  • Claim 1: This is a highly relevant prior art reference. It teaches a storage device that can modify its behavior based on a set of parameters, which is analogous to a "storage device policy." A host can send commands to alter these parameters, which is similar to "receiving a storage device policy." The device then stores data according to these new parameters. The key distinction may be the scope and flexibility of the "policy" in the '023 patent. The '085 application appears to focus on pre-defined, adaptable parameters, whereas the '023 patent suggests a more open-ended system where a user could provide new algorithms or a more complex set of rules (e.g., via libraries as shown in Fig. 7A and 7B). However, this reference does challenge the novelty of a storage device's behavior being configurable by an external entity.

U.S. Patent No. 7,539,823 B2

• Full Citation: US 7539823 B2, "Method and system for automatically preserving persistent storage"
• Filing Date: August 8, 2001
• Publication Date: May 26, 2009
• Assignee: Microsoft Corporation
• Brief Description: This patent describes a system that protects a storage device from unwanted alterations. A "Redirection Driver" intercepts read/write requests. Based on a policy, it can redirect writes to a separate, non-protected area, leaving the original data intact. This is often used for creating a "snapshot" or a protected state for a system.
• Potential Anticipation of Claim(s):
  • Claim 1: This reference is relevant to the "refusing a delete request" element of the claim. The redirection driver, based on a policy, effectively prevents the overwriting or deletion of data in a protected area. It demonstrates a form of policy-based control over storage operations. However, the primary purpose is system protection and redirection, not the granular, user-defined control over physical storage characteristics (like recording density or defect management) as envisioned in the '023 patent. The '823 patent's "policy" seems less about optimizing storage trade-offs and more about enforcing a binary "protected" or "unprotected" state. It also does not explicitly teach storing the full set of "storage information" at a remote location as a primary mode of operation.

Conclusion

While several prior art references touch upon policy-based data management, they generally do so at a higher level of abstraction, such as in a distributed network or a cloud storage gateway. The most challenging reference for the novelty of claim 1 appears to be US 2012/0159085 A1, which discloses a storage device with adaptable internal parameters that can be set by a host. The patentability of the '023 patent's claims likely hinges on the specific implementation of the "storage device policy" as a more flexible and powerful framework than simply adjusting pre-set parameters, allowing for custom algorithms and fine-grained control over the physical storage media, as well as the combination of all the claimed elements, including the remote storage of metadata and the refusal of delete requests based on this policy.

Analysis of Obviousness Under 35 U.S.C. § 103

Under United States patent law, a patent claim is invalid as obvious under 35 U.S.C. § 103 if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (a "POSITA"). An obviousness analysis often involves combining the teachings of multiple prior art references, but there must be a reasoned basis for a POSITA to have made such a combination.

The core of Independent Claim 1 of U.S. Patent 10,776,023 ('023 patent) is a data storage device whose internal controller can receive a "storage device policy" and use it to manage how data is written, read, and deleted, including storing metadata remotely.

Based on the cited prior art, the claims of the '023 patent appear to be vulnerable to an obviousness challenge by combining teachings from multiple references.

Primary Combination: U.S. 2012/0159085 A1 (LSI) in view of U.S. 9,489,204 B2 (NetApp)

A strong argument for obviousness can be made by combining the teachings of the LSI '085 application with the NetApp '204 patent. LSI discloses the core concept of a device-level controller that adapts its behavior, while NetApp teaches the high-level policy management features missing from LSI.

1. Base Reference: U.S. 2012/0159085 A1 (LSI)

LSI teaches a storage device, such as an SSD, with a controller that can modify its internal operating parameters based on commands from a host system. This is directly analogous to the '023 patent's concept of a device controller receiving and acting upon a "storage device policy."

• Receiving a policy (Claim 1b): LSI discloses a host sending commands to the storage device to "adapt its internal operating parameters." A POSITA would understand this set of parameters and commands to constitute a "storage device policy."
• Storing content according to the policy (Claim 1c): LSI describes that upon receiving these parameters, the device modifies its behavior, such as adjusting error correction or wear-leveling algorithms. This directly teaches storing content in accordance with the received policy.
• Recording and retrieving using storage information (Claim 1d, 1e): As a functioning storage device, the LSI device inherently performs the fundamental operations of recording information about where data is physically stored (e.g., in a Flash Translation Layer or LBA-to-PBA map) and using that information to retrieve the data upon request. This corresponds to the "storage information" and "content identifier" of the claim.

LSI, however, does not explicitly teach refusing a delete request based on a policy or storing the storage information at a remote location.

2. Secondary Reference: U.S. 9,489,204 B2 (NetApp)

The NetApp patent teaches a system for enforcing storage policies across a network. Its teachings fill the gaps left by LSI.

• Refusing a delete request (Claim 1f): NetApp explicitly describes enforcing "storage policies" which can include "data retention" rules. A data retention policy, by definition, prevents the deletion of data until a certain condition is met or time has passed. A POSITA would understand that implementing a retention policy necessitates the system "refusing a delete request" for data that is still within its retention period.
• Storing information at a remote location (Claim 1g): NetApp's system is architected around a central management server that defines and distributes policies to storage systems. This central server is a "remote location" relative to the individual storage systems. It is common practice in such architectures for metadata, policies, and system status (i.e., "storage information") to be managed, backed up, or logged at this central location.

3. Motivation to Combine

A person of ordinary skill in the art would have been motivated to combine the teachings of LSI and NetApp for several reasons:

• Enhancing Functionality: A POSITA, starting with the performance-tunable storage device of LSI, would recognize the market demand for more advanced, enterprise-level data management features. The policy-based retention and data protection taught by NetApp were standard features in enterprise storage systems. Integrating these capabilities directly into the device controller, as taught by LSI, would create a more powerful and versatile "intelligent" drive.
• Predictable Result: Combining a host-configurable controller (LSI) with policy-based retention (NetApp) would predictably result in a storage device that can enforce deletion rules sent by the host. There is no technical incompatibility that would prevent a controller from evaluating a "do not delete" flag (derived from a retention policy) before executing a delete or overwrite command.
• Centralized Management: As individual storage devices become more intelligent and configurable (per LSI), the need for centralized management increases. A POSITA would naturally look to existing network storage management paradigms, such as the central policy engine described by NetApp. It would be a logical step to have the LSI-type device not only receive its policy from a remote source but also report its storage information back to that remote source (e.g., a central key manager or metadata server) for reasons of security, durability, and system-wide management.

By combining LSI's device-level policy execution with NetApp's higher-level data retention and networked management policies, a POSITA would have arrived at the invention claimed in claim 1 of the '023 patent.

---

Alternative Combination: U.S. 2012/0159085 A1 (LSI) in view of U.S. 7,539,823 B2 (Microsoft)

This combination provides a particularly strong argument for the "refusing a delete request" element.

• Base Reference: LSI ('085), as described above.
• Secondary Reference: Microsoft ('823) teaches a system that uses a policy to intercept write/delete operations and redirect them, thereby protecting the original data. This is a direct implementation of "refusing a delete request" based on a policy.
• Motivation to Combine: A POSITA would be motivated to integrate the data protection mechanism of Microsoft into the configurable device of LSI to create a device with a built-in, hardware-level Write-Once-Read-Many (WORM) or snapshot capability. This would be a valuable feature for compliance, archiving, and data security. The host could send a policy command to the LSI device to make a specific logical block range or object read-only, and the controller would then enforce this policy by rejecting any subsequent write or delete commands to that area, as taught by Microsoft.

This combination strongly teaches elements (a) through (f) of claim 1. To fully meet claim 1, this combination would need to be supplemented by the general knowledge of a POSITA or another reference (like NetApp '204) showing that in a managed storage environment, it is conventional to store critical metadata or keys at a remote location for security and management.

Patent Term and Expiration Analysis for U.S. Patent No. 10,776,023

Date of Analysis: May 9, 2026

This analysis details the term adjustments, related applications, and the projected expiration date for U.S. Patent No. 10,776,023 ('023 patent).

Patent Term Adjustment (PTA) / Patent Term Extension (PTE)

• PTA: A review of the prosecution history for the '023 patent indicates that there has been no Patent Term Adjustment (PTA) granted. The patent's term was not extended due to delays by the USPTO during its examination.
• PTE: There is no indication of any Patent Term Extension (PTE) for this patent. PTE is typically granted for delays caused by regulatory review (e.g., by the FDA) and is not applicable in this case.

Continuity and Family Data

The '023 patent is part of a larger family of applications that claim priority to each other, indicating a continuing prosecution of the underlying invention.

• Application Number: 15/804,772
• Filing Date: November 6, 2017

Continuation Applications (Child Applications):

The application for the '023 patent has served as the basis for several subsequent continuation applications, leading to additional patents. This strategy is often used to pursue claims of varying scope or to cover new embodiments of the invention.

• U.S. Patent No. 11,327,669:

  • Title: Data storage device with configurable policy-based storage device behavior
  • Application No.: 16/990,433
  • Filing Date: August 11, 2020
  • Issue Date: May 10, 2022
  • Relationship: This is a continuation of the '023 patent's application (15/804,772).

• U.S. Patent No. 11,907,553:

  • Title: Data storage device with configurable policy-based storage device behavior
  • Application No.: 17/716,275
  • Filing Date: April 8, 2022
  • Issue Date: February 13, 2024
  • Relationship: This is a continuation of the application for the '669 patent (16/990,433).

• U.S. Patent No. 12,265,715:

  • Title: Data storage device with configurable policy-based storage device behavior
  • Application No.: 18/408,670
  • Filing Date: January 10, 2024
  • Issue Date: March 25, 2025
  • Relationship: This is a continuation of the application for the '553 patent (17/716,275).

• U.S. Patent Application Pub. No. 2025/0328270 A1:

  • Title: Data storage device with configurable policy-based storage device behavior
  • Application No.: 19/066,396
  • Filing Date: February 28, 2025
  • Status: Pending
  • Relationship: This is a continuation of the application for the '715 patent (18/408,670).

There are no divisional applications noted for this patent family. All subsequent filings are continuations.

Projected Expiration Date

The term of a U.S. patent is 20 years from the filing date of the earliest U.S. non-provisional application to which it claims priority. Since all patents in this family share the same priority date and there are no terminal disclaimers or patent term adjustments indicated, they will all share the same expiration date.

• Earliest Filing Date: November 6, 2017 (from application 15/804,772)
• Term: 20 years
• Patent Term Adjustment (PTA): 0 days
• Projected Expiration Date: November 6, 2037

This expiration date is contingent upon the timely payment of all required maintenance fees.

Defensive Disclosure: Configurable Policy-Based Storage Device Behavior

Publication Date: May 9, 2026
Relevant Technology Field: Data Storage, Embedded Systems, System-on-Chip (SoC) Architecture, Information Lifecycle Management (ILM).

This document discloses derivative inventions and enhancements to the concepts described in U.S. Patent 10,776,023. The purpose of this disclosure is to place these concepts in the public domain, thereby establishing them as prior art for any future patent applications.

---

Derivative Set 1: Material & Component Substitution

1.1. Phase-Change Memory (PCM) with Thermal-Aware Policy Engine

• Enabling Description: This embodiment replaces the NAND flash or magnetic media of the original patent with Phase-Change Memory (PCM). The device controller's policy engine is specifically adapted to manage the unique properties of PCM. A "write policy" for PCM would not control recording density in a magnetic sense, but would instead modulate the amplitude and duration of the heating pulse used to set the phase (amorphous or crystalline) of the PCM cells. A high-reliability policy would use a longer, more precise pulse to ensure a stable phase change, at the cost of slower write speeds and higher power consumption. A high-speed policy would use a shorter pulse, accepting a slightly higher bit-error rate that is compensated for by a more robust Error Correction Code (ECC) algorithm, also selected by the policy. The policy engine interfaces with on-chip temperature sensors. If a write-intensive operation causes a localized temperature increase, the policy can dynamically switch to a lower-power write mode or throttle requests to prevent thermal crosstalk between adjacent PCM cells, thus preserving data integrity.
• Mermaid Diagram:

  graph TD
      A[Storage Request] --> B{Policy Engine};
      B -- Policy: High-Reliability --> C[PCM Controller: Long-Pulse Write];
      B -- Policy: High-Speed --> D[PCM Controller: Short-Pulse Write + Strong ECC];
      E[Thermal Sensor] -- Temp > Threshold --> B;
      B -- Thermal Throttling --> F[PCM Controller: Low-Power Pulse / Queue Writes];
      C --> G[PCM Media];
      D --> G;
      F --> G;
  

1.2. Ferroelectric RAM (FeRAM) with Endurance-Balancing Policy

• Enabling Description: This variation utilizes Ferroelectric RAM (FeRAM) as the storage media, prized for its low power consumption and high write endurance. The device controller's policy engine implements an "endurance-balancing" algorithm. Storage information for each data object includes not only its location but also a "write-volatility" attribute provided by the host (e.g., 'temporary', 'long-term-archive', 'frequently-updated'). The layout library within the policy engine uses this attribute to segregate data. Frequently-updated data is written to a dedicated, high-endurance FeRAM partition, while archival data is placed in a separate partition. The policy engine periodically remaps the logical-to-physical addresses for the high-traffic partition to ensure write operations are evenly distributed, a form of advanced wear-leveling. The "refuse delete" instruction could be implemented by setting a permanent polarization state on a block of FeRAM cells that cannot be reversed by standard write commands, creating a hardware-level WORM (Write-Once-Read-Many) capability.
• Mermaid Diagram:

  sequenceDiagram
      participant Host
      participant DeviceController
      participant PolicyEngine
      participant FeRAM
      Host->>+DeviceController: Write(Data, {volatility: 'high'})
      DeviceController->>+PolicyEngine: AnalyzeRequest(Data, Metadata)
      PolicyEngine->>-DeviceController: Instruct: Use High-Endurance Zone
      DeviceController->>+FeRAM: Write to PhysicalAddr_A
      FeRAM-->>-DeviceController: Ack
      DeviceController-->>-Host: Write OK, ContentID: 123
      Host->>+DeviceController: Write(Data, {volatility: 'archive'})
      DeviceController->>+PolicyEngine: AnalyzeRequest(Data, Metadata)
      PolicyEngine->>-DeviceController: Instruct: Use Archive Zone
      DeviceController->>+FeRAM: Write to PhysicalAddr_B
      FeRAM-->>-DeviceController: Ack
      DeviceController-->>-Host: Write OK, ContentID: 456
  

1.3. Neuromorphic Controller for Predictive Data Placement

• Enabling Description: The general-purpose "device controller" is substituted with a neuromorphic processor core co-located with a traditional CPU. This neuromorphic core runs a Spiking Neural Network (SNN) that is trained to recognize complex I/O patterns in real-time. The storage device policy is no longer a static set of rules but a goal-oriented directive (e.g., "minimize 99th percentile read latency" or "maximize device lifespan"). The SNN observes sequences of reads and writes, cluster sizes, and inter-command delays. It predicts which data blocks are likely to be accessed together in the near future. The layout library then uses these predictions to physically co-locate related data blocks on the storage media, even if they were written at different times. For a hard disk, this minimizes actuator arm movement. For an SSD, this ensures that data for a predicted workload is placed in the same erase block to minimize read-disturb and write-amplification. The SNN's predictive model is the "storage information" and is continuously updated.
• Mermaid Diagram:

  flowchart LR
      subgraph Device Controller
          A[I/O Command Queue] --> B(Neuromorphic Core - SNN);
          B --Predicts Access Pattern--> C(Policy Engine);
          C --Generates Placement Policy--> D[Layout Library];
          D --Physical Address--> E[Media Interface];
      end
      E --> F[Storage Media];
      A --Data--> E;
  

---

Derivative Set 2: Operational Parameter Expansion

2.1. Policy-Based Storage for Cryogenic Quantum Computing

• Enabling Description: This application applies the invention to a storage device operating within a dilution refrigerator at milli-Kelvin temperatures, providing data storage for a quantum computer. The storage media consists of superconducting memory elements. The "storage device policy" is critical for minimizing heat generation, which is a primary source of quantum decoherence. The policy engine, operating at a warmer stage of the refrigerator, receives a "computation schedule" from the quantum computer's control system. The policy dictates that data read/write operations are only performed during specific, non-critical phases of the quantum computation to avoid RF interference. For critical qubit state data, the policy enforces a "triplicate redundant storage" mode across physically separated memory chips to mitigate loss from cosmic ray strikes or localized heating events. Storage information is stored remotely outside the cryogenic environment.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Idle
      Idle --> Receiving_Policy: Quantum Control System
      Receiving_Policy --> Idle: Policy Updated
  
      state "Quantum Computation Active" as Active {
          state "Qubit Measurement" as Measure
          state "Gate Operation" as Gate
          
          [*] --> Gate
          Gate --> Measure: Read Qubit State
          Measure --> Gate: Apply Correction
      }
  
      Idle --> Active: Start Computation
      Active --> Idle: End Computation
  
      state "Storage Operation" as Storage {
          policy_check: Policy allows access?
          read_op: Read from Superconducting RAM
          write_op: Write to Superconducting RAM
      }
  
      Idle --> Storage: Host I/O Request
      Storage --> Idle: Operation Complete
      
      note right of Active
        During this state, policy
        disallows any storage I/O
        to prevent decoherence.
      end note
  

2.2. Planetary-Scale Inter-Satellite Storage Network

• Enabling Description: A constellation of satellites (e.g., in Earth orbit, lunar orbit, and on Mars) forms a single, logical, distributed storage device. Each satellite contains a '023-style storage device. The "storage device policy" is location and-link-aware. A policy manager on Earth transmits policies that account for orbital mechanics and communication windows. When a satellite in low Earth orbit collects high-resolution imagery, its local policy dictates "local-first, high-density storage." As the satellite's orbit approaches a ground station, the policy dynamically shifts to "prepare for downlink," re-ordering data in the buffer for high-speed transmission. If the data is critical and the satellite will soon be out of contact, the policy instructs the device controller to transmit a copy to a nearby satellite in the constellation, which acts as a "remote location" for redundant storage information and content. The "refuse delete" command is used to protect raw scientific data until it has been confirmed as received by at least two ground stations.
• Mermaid Diagram:

  graph TD
      subgraph Satellite_A
          A1[Device Controller]
          A2[Storage Media]
          A1 -- policy: local_store --> A2
      end
      subgraph Satellite_B
          B1[Device Controller]
          B2[Storage Media]
      end
      subgraph GroundStation
          GS[Policy Manager]
      end
  
      GS -- Update Policy (Orbital Position) --> A1
      A1 -- policy: replicate_critical_data --> B1
      B1 -- store_copy --> B2
      A1 -- policy: downlink_data --> GS
  

---

Derivative Set 3: Cross-Domain Application

3.1. Automotive: Black Box with Dynamic Event-Triggered Policies

• Enabling Description: The invention is embodied in the central data recorder ("black box") of an autonomous vehicle. In normal operation, the device controller uses a "looping-cache" policy, storing high-bandwidth sensor data (LIDAR, camera feeds) with low retention, constantly overwriting the oldest data. This storage information is kept locally. However, the controller is also connected to the vehicle's CAN bus. If it detects an event from the inertial measurement unit (IMU) indicating a crash (e.g., deceleration > 5G), the policy immediately changes to "event-lockdown." The last 30 seconds of sensor data are flagged as non-deletable ("refuse delete"). Furthermore, a secondary policy triggers, storing a compressed summary of the event (location, speed, G-force data) with a cryptographic signature to a separate, physically hardened section of the memory. This "storage information" and the summary data are also transmitted via a cellular link to a remote server ("remote location") managed by the manufacturer or insurer.
• Mermaid Diagram:

  stateDiagram-v2
      state "Normal Operation" as Normal
      state "Event Lockdown" as Lockdown
  
      [*] --> Normal
      Normal --> Normal: Write Sensor Data (Overwrite Old)
      Normal --> Lockdown: IMU Event (G-force > 5g)
      
      Lockdown --> [*]: Power Off
  
      state "In Lockdown" as S1 {
          direction LR
          [*] --> Mark_Immutable
          Mark_Immutable --> Store_Summary: Compress & Sign Event Data
          Store_Summary --> Transmit_Remote: Send Summary to Cloud
          Transmit_Remote --> [*]
      }
  

3.2. AgTech: Smart Implement with Soil-Condition-Based Policies

• Enabling Description: A smart agricultural seed drill uses a policy-driven storage device. The device is connected to real-time sensors measuring soil moisture, pH, and nitrogen levels. The "storage device policy" is downloaded from a central farm management system based on the specific field's prescription map. As the drill moves across the field, the device controller receives sensor data. The policy contains rules such as: "IF soil_moisture < 20% THEN set_data_priority=HIGH and store_geotagged_data_redundantly." This ensures that data from problem areas is preserved with higher fidelity. The layout policy also adapts; for uniform field sections, it uses a highly compressed format to save space. For highly variable sections, it stores raw sensor readings. The storage information, including the precise GPS coordinates linked to each data point, is periodically synced to a "remote location" (the farm's cloud database) via a low-power LoRaWAN or satellite uplink.
• Mermaid Diagram:

  flowchart TD
      A[GPS + Soil Sensors] --> B{Device Controller};
      C[Farm Cloud Server] -- Prescription Map / Policy --> B;
      
      subgraph "Policy Execution"
          B -- Sensor Readings --> P{Policy Engine};
          P -- "Moisture < 20%"? --> R1[Rule 1: High Reliability];
          P -- "pH > 7.5"? --> R2[Rule 2: Store Raw Data];
          P -- "Default" --> R3[Rule 3: Compressed Storage];
      end
  
      R1 --> S[Store on Media];
      R2 --> S;
      R3 --> S;
      S -- Storage Info --> B;
      B -- Sync Storage Info --> C;
  

3.3. Consumer Electronics: Wearable Health Monitor with Privacy Policies

• Enabling Description: A smartwatch or health tracker incorporates a storage device with a user-configurable privacy policy. The user, via a smartphone app, defines the policy. Options could include: "Store heart rate data locally only," "Anonymize and upload activity data," or "In case of fall detection, make location and vital signs data available to emergency contacts." The device controller receives this policy. When it logs a heart rate measurement, it checks the policy. If the policy is "local only," the storage information is recorded to internal memory and marked as non-exportable. If a fall is detected, the policy instructs the controller to retrieve the latest vital signs and location data, package it, and transmit it, overriding the normal privacy restrictions. The "remote location" for storage can be a user's personal cloud account, and the policy can dictate that the storage information (metadata) sent to this remote location is encrypted with a key held only on the user's phone, preventing the cloud provider from analyzing the raw data.
• Mermaid Diagram:

  sequenceDiagram
      autonumber
      participant App
      participant DeviceController
      participant StorageMedia
      participant EmergencyContact
      
      App->>DeviceController: Set Policy (privacy_mode='local', emergency_unlock=true)
      loop Normal Operation
          DeviceController->>StorageMedia: Store Vitals (Heart Rate, etc.)
      end
      
      DeviceController->>DeviceController: Event: Fall Detected!
      DeviceController->>DeviceController: Policy Check: emergency_unlock is true
      DeviceController->>StorageMedia: Retrieve Last 60s Vitals + GPS
      DeviceController->>EmergencyContact: Transmit Emergency Data Packet
  

---

Derivative Set 4: Integration with Emerging Tech

4.1. AI-Optimized Wear Leveling and Data Freshening

• Enabling Description: The device controller integrates a TinyML model trained to predict data "temperature" (access frequency) and media degradation. The "storage device policy" is not a fixed set of rules but a target goal, e.g., "Achieve 5-year lifespan under 90th percentile enterprise workload." The AI model continuously monitors Logical Block Address (LBA) access patterns and internal media health metrics (e.g., NAND block erase counts, SSD temperature). It predicts which data blocks will become "hot" (frequently written) and preemptively moves them to fresh, low-wear blocks. Conversely, it identifies "cold" data that has not been accessed for a long time and schedules a "data freshening" operation, where the data is read and re-written to mitigate charge leakage or magnetic bit decay. This entire process is autonomous within the drive, using the AI model to dynamically generate and execute the optimal layout and maintenance policy to meet the high-level goal.
• Mermaid Diagram:

  graph LR
      subgraph "AI-Driven Controller"
          A[I/O Stream] --> B[Pattern Recognition ML Model];
          C[Media Health Sensors] --> B;
          B -- "Predicts Hot/Cold Data" --> D{Policy Generator};
          D -- "Target: 5-Yr Lifespan" --> E{Policy};
          E -- "Wear-Leveling & Freshening Ops" --> F[Flash Translation Layer];
      end
      F <--> G[NAND Flash Media];
  

4.2. IoT-Aware Environmental Adaptation

• Enabling Description: The storage device is designed for edge IoT deployments and includes an integrated environmental sensor suite (temperature, humidity, vibration, power quality). The device controller's policy library includes multiple modes optimized for different conditions. A remote IoT management platform (like AWS IoT Core or Azure IoT Hub) can push a new policy to the device. For example, a device on a vibrating industrial robot might receive a policy that increases the robustness of its ECC and physically duplicates critical configuration data. If the power quality sensor detects unstable voltage, the controller can activate a "safe-write" policy that uses more power to verify every write operation and journals all metadata to a separate, power-fail-safe memory region (e.g., MRAM) before committing it to the primary media. This ensures data integrity even in harsh and unpredictable physical environments.
• Mermaid Diagram:

  graph TD
      subgraph "IoT Device"
          A[Vibration Sensor] --> C;
          B[Power Sensor] --> C;
          C[Device Controller] -- reads --> D[Storage Media];
          C -- writes --> D;
      end
      subgraph "Cloud Management"
          E[IoT Platform]
      end
      E -- "Push Policy: HighVibration" --> C;
      C -- "Current Policy: HighVibration" --> F{"Execute Write with Extra ECC & Verification"};
      F --> D;
  

---

Derivative Set 5: The "Inverse" or Failure Mode

5.1. Policy-Driven Graceful Degradation and Forensics

• Enabling Description: The device controller actively monitors media health (e.g., reallocated sector count, wear-leveling delta). The storage policy includes a set of degradation thresholds. When a threshold is crossed (e.g., >5% of blocks are reallocated), the controller autonomously triggers a "degraded mode" policy. This policy might: 1) Mark the device as "read-only" to prevent further wear and data loss. 2) Reduce the reported capacity to the host, taking the weakest parts of the media offline. 3) Increase the strength of the ECC applied to all reads to maximize the chance of recovering data from failing cells. Critically, before entering a read-only state, the controller stores a final "state-of-health" log, including all SMART data and a map of bad blocks, in a reserved, immutable area. This log, protected by a "refuse delete" policy, can be retrieved for forensic analysis to understand the cause of the failure.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Healthy: Power On
      Healthy: Normal R/W Operations
      Healthy --> Degraded_Mode: Wear > Threshold 1
      Degraded_Mode: Reduced Capacity, Stronger ECC
      Degraded_Mode --> Read_Only_Mode: Wear > Threshold 2
      Read_Only_Mode: Writes disabled, Final Log Stored
      Read_Only_Mode --> Failed: Critical Error
      Failed --> [*]
  

---

Combination Prior Art Scenarios

1. Integration with Ceph via CRUSH Ruleset Extension: A storage policy as defined in the '023 patent is mapped to a new device class attribute within the Ceph CRUSH map. A CRUSH rule can be written to explicitly place data based on this policy attribute. For example: rule replicated_worm { ruleset 0; type replicated; min_size 1; max_size 10; step take default; step chooseleaf firstn 0 type host; step chooseleaf firstn 3 type drive_policy_worm; step emit; }. A Ceph client requesting WORM storage would use this rule. The Ceph OSD daemon, running on the storage node, would not simply write to a generic block device. It would first issue a command to the '023-enabled drive to activate its internal, hardware-enforced "WORM" policy for the specified logical blocks before writing the object data. This moves policy enforcement from the software OSD layer to the device firmware, providing a more robust and secure implementation.

2. Integration with Kubernetes via Container Storage Interface (CSI): A CSI driver is developed for the '023-enabled storage device. The StorageClass object in Kubernetes is extended with a parameters field for policy definition. A DevOps engineer can define a class like this:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: high-reliability-db
   provisioner: csi.gaea.com
   parameters:
     read_retry: "heroic"
     write_policy: "replicated_nvram"
     defect_avoidance: "aggressive"
   

   When a PersistentVolumeClaim requests this StorageClass, the CSI driver communicates with the device controller via a proprietary vendor command or a standardized protocol like NVMe-MI. It passes these parameters, which the controller uses to load the corresponding algorithms from its firmware libraries (as described in FIG. 7A/7B of the '023 patent), thus configuring the physical volume for the specific needs of the database application running in the pod.

3. Integration with Apache Zookeeper for Distributed Policy Management: A cluster of '023-enabled storage devices uses Zookeeper as the "remote location" for storing both policies and storage information (metadata). Each device controller runs a lightweight Zookeeper client. The canonical storage policies are stored in a ZNode, e.g., /storage_policies/active_policy. Each device controller places a watch on this ZNode. When an administrator updates the policy, all devices are notified and atomically switch to the new policy. Furthermore, when a device writes an object, it stores the content ID and its physical location information in an ephemeral ZNode (e.g., /object_locations/object-xyz-123). This provides a fault-tolerant, distributed, and consistent metadata map that is managed by the storage devices themselves, reducing the need for a traditional centralized file system metadata server. If a device fails, its ephemeral nodes disappear, signaling to the cluster that its objects are offline.