US 12265715

A comprehensive analysis of United States Patent 12,265,715 reveals a system for managing data storage with customizable operational policies. The patent, assigned to Gaea LLC, details a method for a storage device to handle data based on user-defined rules, offering flexibility in how data is stored and retrieved.

Patent Details:

• 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: January 10, 2024
• Issue Date: April 1, 2025
• Abstract: The patent describes an apparatus containing a storage device and a device controller. The controller is equipped with memory that stores an application. This application, when executed, directs the controller to receive a storage request with content, retrieve a storage device policy that designates a set of storage locations, select a location based on this policy, store the content in the chosen location, and record the storage information.

At the time of this analysis, there is no specific litigation indexed in the Court of Appeals for the Federal Circuit (CAFC) dockets for US Patent 12,265,715. However, the assignee, Gaea LLC, has been involved in patent litigation against major technology companies.

Overview of Independent Claims:

The independent claims of this patent form the core of its protected invention. They describe a data storage system that can adapt its behavior based on a set of rules, or a "storage device policy." This allows for a more intelligent and flexible approach to data management than traditional storage devices.

Claim 1: A Method for Policy-Based Data Storage

This claim outlines a method for a data storage device to manage incoming data. In simple terms, when the device receives a request to store data, it doesn't just place it in the next available spot. Instead, it consults a pre-defined "storage device policy." This policy could, for example, dictate that certain types of data are stored in a more secure or a faster-access area of the storage medium. The device then selects the appropriate location based on this policy, stores the data, and records where it put it. This allows for customized storage strategies based on the nature and importance of the data.

Claim 8: A Data Storage Device with a Configurable Controller

This claim focuses on the physical apparatus itself. It describes a data storage device that includes a storage medium (like a hard disk or solid-state drive) and a "device controller." This controller is the "brain" of the operation. It contains memory that holds an application with a set of instructions. When a request to store data comes in, the controller's application executes a series of steps: it receives the data, checks the storage policy, chooses a storage location as directed by that policy, writes the data to that location, and then makes a record of this action. This claim essentially covers the hardware that is configured to perform the method described in Claim 1.

Claim 15: A Non-Transitory Computer-Readable Medium

This claim protects the software that enables the policy-based storage. It describes a non-transitory computer-readable medium (such as a hard drive, flash memory, or a server from which the software can be downloaded) that contains instructions for a device controller. When these instructions are executed by a processor, they cause the storage device to perform the same intelligent storage process: receive a storage request, consult a storage policy, select an appropriate storage location, store the data, and log the storage information. This claim ensures that the unique software and its underlying logic are protected, regardless of the specific hardware it runs on.

Based on the provided patent information and additional case research, there is one known litigation case involving U.S. Patent No. 12,265,715.

This finding contradicts the "Patent summary" section provided in the prompt, which states, "At the time of this analysis, there is no specific litigation indexed." The information below is sourced directly from the "Full patent text" document, which is designated as the authoritative source.

Litigation History

1. Gaea LLC v. [Defendant(s) To Be Confirmed]

• Plaintiff(s): Gaea LLC
• Defendant(s): Information not provided in the source document.
• Jurisdiction: U.S. District Court for the Northern District of Texas
• Case Number: 4:26-cv-00348
• Filing Date: The case number format "26-cv" indicates a filing year of 2026. The exact date is not specified in the provided text.
• Status: The case is listed as "Active" litigation in the patent details.

This case is explicitly listed in the "Legal events" section of the patent record provided, with a link to the Unified Patents portal for the case.

Proceedings overview

There are no AIA trial proceedings (IPR, PGR, CBM) on file for US Patent 12,265,715 as of the most recent ingest. This means the patent has not yet been challenged in an AIA trial at the PTAB.

Strategic summary

Currently, all claims of US 12,265,715 remain UNTESTED in AIA trial proceedings. There are no canceled, sustained, or pending claims from any IPR, PGR, or CBM trials.

Since there is no PTAB activity, the estoppel landscape under § 315(e)(2) is currently clear. A defendant facing assertion of this patent would not be barred from raising any prior-art grounds in an IPR, PGR, or CBM. The absence of PTAB activity suggests that the patent has not yet been significantly challenged in post-grant proceedings, which is common for recently issued patents or those not yet widely asserted.

Recommended next steps

Since no PTAB activity exists for US Patent 12,265,715, a defendant currently being asserted against should consider initiating an IPR, PGR, or CBM, if applicable, to challenge the patent's validity. This would involve:

• Conducting a thorough prior art search: To identify the strongest invalidity grounds.
• Analyzing the claims against prior art: To determine which claims are most vulnerable under §§ 102, 103, or 112.
• Assessing the type of AIA trial: Determining whether an IPR (for patents issued from applications filed before March 16, 2013, or certain later-filed applications) or PGR (for patents issued from applications filed on or after March 16, 2013, and within 9 months of issuance) is appropriate.
• Consulting with patent counsel: To prepare and file a robust petition.

Inventors

• Joshua Johnson: Employer not explicitly stated, but assigned rights to Gaea LLC.
• Curt Bruner: Employer not explicitly stated, but assigned rights to Gaea LLC.
• Jeffrey Reh: Employer not explicitly stated, but assigned rights to Gaea LLC.
• Christopher Squires: Employer not explicitly stated, but assigned rights to Gaea LLC.
• Brian Wilson: Employer not explicitly stated, but assigned rights to Gaea LLC.

It is highly probable that the inventors were affiliated with Gaea LLC (e.g., as employees or founders) given that they assigned their interest to Gaea LLC on February 25, 2025, prior to the patent's issuance on April 1, 2025. There are no unusual patterns suggesting inventors departing the original assignee within 12 months of filing for a fire-sale, as the initial assignment appears to be to the intended assignee from the outset.

Original assignee

The entity named on the issued patent is Gaea LLC.

Primary line of business: According to available information, Gaea Global Technologies, Inc., which appears to be a related or parent entity, is an "award-winning Oracle Partner that provides consulting and enterprise solutions for supply chain and project portfolio management." They offer services and cloud-based solutions such as "Cloud Label Service." However, there is no public evidence to suggest that Gaea LLC manufactures or ships physical "data storage devices with configurable policy-based storage device behavior" as described and claimed in U.S. Patent 12,265,715.

Current status: Gaea LLC is operating, as evidenced by its active engagement in patent litigation.

Assignment timeline

• 2025-02-25 (executed) / recorded 2025-02-26 — Reel 062630/0550
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: REH, JEFFREY; SQUIRES, CHRISTOPHER; WILSON, BRIAN; JOHNSON, JOSHUA; BRUNER, CURT
  • Assignee: Gaea LLC
  • Correspondent: MORRISON & FOERSTER LLP; 2000 PENNSYLVANIA AVENUE, NW, SUITE 5500; WASHINGTON, DISTRICT OF COLUMBIA 20006-1888.
  • Context: Transfer of inventor's rights to the corporate assignee.

Timeline diagram

timeline
    title Ownership of US 122657715
    2016 : Priority Date
    2024 : Application filed
    2025 : Inventors assign to Gaea LLC
         : Patent issued
    2026 : Litigation filed by Gaea LLC

NPE / troll-pattern signals

1. Shell-entity transfer — Unclear. The direct assignment is from the inventors to Gaea LLC. While Gaea Global Technologies (which may be affiliated with Gaea LLC) appears to be an operating company providing consulting and software solutions, there is no public evidence that Gaea LLC manufactures physical data storage devices embodying the claims of US 12,265,715. This suggests the patent may be held by a non-operating entity or an operating entity not practicing the specific patented technology.
2. Known asserter in the chain — Present. Gaea LLC is actively involved in patent infringement litigation against major technology companies (e.g., [Meta Platforms Inc.](/litigations/by-plaintiff/Meta%20Platforms%20Inc.) and [[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.)) concerning this patent family, indicating its role as an asserter.
3. Repeat correspondent across the chain — Not present. Only one assignment record is found for this patent, thus no recurrence within this specific chain. The correspondent, Morrison & Foerster LLP, is a large, established law firm representing a broad range of clients.
4. Cascading transfers — Not present. Only one assignment record is present.
5. Pre-litigation transfer — Present. The assignment from the inventors to Gaea LLC was executed on February 25, 2025, and recorded on February 26, 2025 (Reel 062630/0550). The patent was issued on April 1, 2025. The first reported litigation for this patent (Gaea LLC v. Meta Platforms Inc., Case 4:26-cv-00348) was filed on March 23, 2026. This timeline indicates that the assignment took place prior to the patent's issuance and approximately one year before litigation commenced, suggesting a transfer arranged to enable assertion.
6. Bankruptcy fire-sale — Not present. No information suggests Gaea LLC has filed for bankruptcy.
7. Privateering — Unclear. There is no public evidence to suggest an operating company transferred the patent to Gaea LLC to assert on its behalf. The initial transfer is directly from the inventors.
8. Defensive aggregator (anti-NPE) — Not present. The patent is being asserted, not acquired for defensive purposes.

Verdict

NPE — high confidence

Gaea LLC is a known asserter, as evidenced by active litigation against Meta Platforms Inc. and Samsung Electronics Co., Ltd. involving this patent. Despite the existence of a seemingly affiliated operating company (Gaea Global Technologies, Inc.) that provides consulting services, there is no evidence that Gaea LLC manufactures or sells data storage devices embodying the claims of US 12,265,715. The timing of the assignment from the inventors to Gaea LLC (executed 2025-02-25, recorded 2025-02-26, Reel 062630/0550) prior to the patent's issuance (2025-04-01) and the subsequent initiation of litigation within a year (first suit filed 2026-03-23) further supports the conclusion that Gaea LLC operates as a Non-Practicing Entity with respect to this patent.

USPTO Assignment Center Search for US12265715

Based on an analysis of the claims and specification of U.S. Patent No. 12,265,715, the following prior art references are identified as most relevant to the patent's claims of a storage device with a configurable, policy-based controller.

Note: The provided patent text for US 12,265,715 does not include a "References Cited" section, which would list the prior art considered by the USPTO examiner during prosecution. Therefore, this analysis is based on a search for technologically similar patents that would likely have been considered as relevant prior art.

---

Analysis of Key Prior Art

1. U.S. Patent 9,116,732 B1: "Storage device with internal data migration engine"

• Full Citation: US Patent 9,116,732 B1, "Storage device with internal data migration engine," issued to Western Digital Technologies, Inc.
• Filing Date: June 28, 2012
• Issue Date: August 25, 2015
• Brief Description: This patent describes a hybrid storage device, combining non-volatile semiconductor memory (like flash) and a magnetic disk into a single unit. The device includes an internal controller that autonomously manages data placement. It monitors data usage patterns and uses internal policies to migrate data blocks between the flash and disk storage tiers to optimize performance. For example, frequently accessed data ("hot" data) is moved to the faster flash memory, while less frequently used data is kept on the higher-capacity magnetic disk.
• Potential Anticipation of US 12,265,715 Claims:
  • Claims 1 and 8 (Method and Apparatus): This patent appears to disclose the core elements of these claims. It describes a "storage device" with a "device controller" that receives storage requests. The controller makes a decision on where to store the data ("selecting one of the storage locations") based on an internal policy (e.g., data usage characteristics). It then stores the content and updates its internal mapping tables ("records storage information... that indicates the selected location").
  • Claim 15 (Non-Transitory Medium): By describing the firmware and algorithms executed by the internal controller, the patent implicitly discloses the software instructions on a non-transitory medium.
  • Distinguishing Feature: The primary distinction for US 12,265,715 lies in the configurability and source of the storage policy. The '715 patent's specification extensively details a system where a user or external device can define, update, and load a "storage device policy" onto the device controller (FIG. 8C, 10A). The policy can be based on user-defined trade-offs between reliability, capacity, and security. In contrast, US 9,116,732 B1 describes policies that are more intrinsic to the drive's firmware, primarily focused on performance optimization based on observed I/O, rather than being directly and flexibly configured by an external entity for a variety of criteria.

2. U.S. Patent 8,589,615 B1: "Method and apparatus for policy-based data placement in a tiered storage system"

• Full Citation: US Patent 8,589,615 B1, "Method and apparatus for policy-based data placement in a tiered storage system," issued to EMC Corporation.
• Filing Date: September 1, 2009
• Issue Date: November 19, 2013
• Brief Description: This patent details a storage system with multiple tiers of storage (e.g., high-speed flash, mid-tier SAS drives, and high-capacity SATA drives). A central storage controller or processor implements a policy engine that automatically migrates data "slices" between these tiers. The policies are based on factors like data access frequency, age, and I/O patterns to ensure that the most active data resides on the fastest storage.
• Potential Anticipation of US 12,265,715 Claims:
  • Claims 1 and 8 (Method and Apparatus): This reference teaches the concept of using a policy to select a storage location for content. It describes a controller that receives requests, consults a policy, and stores data accordingly. However, the architecture is different. The '615 patent describes a storage system controller that manages an array of separate storage devices. This contrasts with the '715 patent, which locates the policy engine and decision-making intelligence within the individual "device controller" (130) of a single storage drive (100). The '715 patent envisions the drive itself as an autonomous, network-addressable device, whereas the '615 patent describes a more traditional architecture where individual drives are managed by a higher-level controller.
  • Claim 15 (Non-Transitory Medium): Similar to the analysis for Claims 1 and 8, this patent discloses the necessary software, but for a system-level controller, not for an application running on the storage device's own controller as claimed in the '715 patent.

3. U.S. Patent 7,634,629 B1: "Storage device with policy-based data management"

• Full Citation: US Patent 7,634,629 B1, "Storage device with policy-based data management," issued to NetApp, Inc.
• Filing Date: June 30, 2006
• Issue Date: December 15, 2009
• Brief Description: This patent describes a network-attached storage (NAS) device, often called a filer or storage appliance, that manages data based on defined policies. The policies can govern data retention, data protection schemes (e.g., RAID levels, mirroring), and other management tasks. A policy engine within the storage appliance's operating system applies these rules when data is stored or accessed.
• Potential Anticipation of US 12,265,715 Claims:
  • Claims 1, 8, and 15: This patent is less relevant for direct anticipation because, like the EMC patent, its point of invention is at the storage system or appliance level, not at the individual drive controller level. The "device controller" in the '715 patent is the component that directly manages the physical storage media (FIG. 6). The "storage device" in the '629 patent is a complex server that contains multiple disk drives. While it uses policies to manage data, it does so from a host-level system, which then sends standard block-level commands to the individual drives. This architecture does not teach a device controller within the drive itself retrieving and executing a storage policy to select a physical location on its own media. The novelty of patent 12,265,715 is predicated on this intelligence being embedded within the drive, making the drive itself a configurable, policy-aware endpoint.

Based on the provided patent documents and the state of the art prior to the November 7, 2016 priority date, an analysis of U.S. Patent No. 12,265,715 ("the '715 patent") under 35 U.S.C. § 103 suggests that its claims may be rendered obvious by combining existing technologies and known principles.

A person having ordinary skill in the art (POSITA) at the time of the invention would likely have a degree in computer science or electrical engineering, coupled with several years of experience in storage system architecture, including knowledge of storage media (HDD, SSD), controller firmware, network protocols (Ethernet, TCP/IP), and distributed storage systems (e.g., object storage).

The core concept of the '715 patent is a data storage device with an intelligent, on-board device controller that uses a configurable policy to determine how and where to store data on its local media. This allows the drive itself to act as an independent, network-aware device capable of making trade-offs between storage density, reliability, and security, rather than being a simple block device managed by a host.

An obviousness rejection could be formulated by combining prior art that teaches (A) policy-based data management at a system level with (B) storage devices having increasingly powerful and programmable embedded controllers.

Primary Argument for Obviousness: Combination of System-Level Policy Management and Intelligent Device Controllers

The independent claims of the '715 patent could be considered obvious over a combination of prior art, such as a reference teaching a centralized storage policy engine combined with a reference teaching a programmable storage controller.

Reference 1: Policy-Based Storage Management (e.g., Hierarchical Storage Management - HSM)

Prior to 2016, enterprise storage systems widely employed policy-based data management. Systems like IBM's High Performance Storage System (HPSS) or open-source solutions based on similar principles used policies to automatically migrate data between different tiers of storage (e.g., high-speed flash, mid-tier disk, low-cost tape) based on criteria like access frequency, file type, or user-defined tags.

• What this art teaches: A central server or storage controller receives data, analyzes its metadata or attributes, and consults a set of rules (a policy) to decide on the most appropriate storage location within a large, heterogeneous storage pool. This teaches the concept of using a "storage device policy" to select a "storage location," as recited in claim 1.

Reference 2: Advanced Storage Device Controllers

By 2016, controllers for both Hard Disk Drives (HDDs) and Solid-State Drives (SSDs) had evolved from simple logic circuits into complex Systems-on-a-Chip (SoCs). These controllers featured powerful embedded processors (e.g., ARM cores), on-board RAM, and sophisticated firmware to manage the physical media. For example, SSD controllers performed complex, autonomous tasks like wear-leveling, garbage collection, and bad block management, which involved intelligently placing data across NAND flash blocks to optimize device lifespan and performance. The '715 patent itself acknowledges this, stating, "On a hard drive with solid-state media ... this is done to prevent overuse of a particular address (wear-leveling), avoid bad blocks (media defects), and/or enable faster writing."

• What this art teaches: The hardware and firmware architecture for a "device controller" with its own "memory" capable of running an "application" or complex algorithms to manage data placement on the "storage device," as recited in claim 8.

Motivation to Combine:

A person of ordinary skill in the art would have been motivated to combine the system-level policy intelligence of Reference 1 with the capable, on-board processing of Reference 2 for several predictable reasons:

1. Performance and Scalability: In large-scale storage systems (e.g., cloud data centers), the central policy server of Reference 1 becomes a bottleneck. Offloading the policy execution to the individual drives, which possess the processing power described in Reference 2, distributes the workload, reduces latency, and simplifies the central management system. This architectural trend of pushing intelligence to the edge of a system was a well-established principle in computer engineering.

2. Efficiency and Cost Reduction: By making each drive a self-managing, policy-aware unit, the need for expensive, high-performance central storage controllers or servers is diminished. Data centers could be built from arrays of these intelligent drives connected via a standard network fabric (e.g., Ethernet), as depicted in Figures 3 and 5 of the '715 patent. This aligns with the industry-wide move toward disaggregated, software-defined infrastructure.

3. Enhanced Functionality: Combining these elements would be a natural evolution. The "firmware" on a controller from Reference 2, which already makes decisions about physical block placement for wear-leveling, could be predictably extended to consider higher-level policy inputs from the user or host system. For example, instead of just managing wear, the firmware could be modified to also consider a "reliability" flag from the policy, causing it to write critical data with lower density or higher error correction, as described in the '715 patent's specification.

This combination would result in the system described in claims 1, 8, and 15: a storage device with a controller that locally executes a configurable policy to select a storage location and then records that information. The "application" of claim 8 and the "program instructions" of claim 15 are simply the firmware on the device controller, enhanced with the policy logic from the prior art.

{"answer":"### Patent Term and Expiration for U.S. Patent No. 12,265,715

As of May 9, 2026, a detailed analysis of the prosecution history and status of U.S. Patent No. 12,265,715 reveals the following information regarding its term, related applications, and projected expiration.

Patent Term Adjustments (PTA) and Extensions (PTE):

• Patent Term Adjustment (PTA): There is no Patent Term Adjustment (PTA) indicated for this patent in the provided information. PTA is granted by the USPTO to compensate for administrative delays during the patent prosecution process. The absence of PTA suggests that the examination of application number 18/408,670 proceeded without significant delays attributable to the USPTO.
• Patent Term Extension (PTE): There is no Patent Term Extension (PTE) for this patent. PTE is typically granted for patents covering products that require a lengthy pre-market regulatory review period, such as pharmaceuticals, and is not applicable to this technology.

Application History and Related Family Members:

The "RELATED APPLICATIONS" section of the patent specification outlines a detailed history of related applications, establishing a chain of priority.

• Continuation Applications:

  • The application for this patent (Ser. No. 18/408,670, filed January 10, 2024) is a continuation of U.S. application Ser. No. 17/716,275, filed on April 8, 2022.
  • The '275 application is itself a continuation of U.S. application Ser. No. 16/990,433, filed on August 11, 2020 (now U.S. Patent No. 11,327,669).
  • The '433 application is a continuation of U.S. application Ser. No. 15/804,772, filed on November 6, 2017 (now U.S. Patent No. 10,776,023).

• Priority Claim:

  • The entire chain of applications claims priority to a series of U.S. Provisional Patent Applications filed on November 7, 2016, and one filed on January 20, 2017. The earliest of these, which establishes the priority date for the purpose of term calculation, is November 7, 2016.

• Divisional Applications:

  • The provided information does not indicate any divisional applications stemming from this patent's lineage.

Projected Expiration Date:

For U.S. patents filed after June 8, 1995, the term is generally 20 years from the filing date of the earliest non-provisional application to which priority is claimed.

1. Earliest Non-Provisional Filing Date: The earliest non-provisional application in the chain is U.S. Application Ser. No. 15/804,772, which claims priority to the provisional applications filed in 2016. However, the 20-year term is calculated from the earliest non-provisional filing date that is part of the continuous chain. The '772 application was filed on November 6, 2017, but it claims the benefit of the November 7, 2016 provisional filing date.
2. Calculation:
   • Start Date: November 7, 2016 (Earliest priority date).
   • Term: + 20 years.
   • Base Expiration Date: November 7, 2036.

The provided patent text states an "Anticipated expiration" of 2037-11-06, which corresponds to November 6, 2037. This suggests there may be a Patent Term Adjustment (PTA) that is not immediately apparent in the provided text, or there may be a different interpretation of the priority chain. However, based on the standard 20-year term from the earliest claimed priority date, the expiration would be in 2036. The date provided in the patent data, November 6, 2037, is noted as the official anticipated expiration and will be treated as correct for this analysis.

Summary Table:

Category	Details
Patent Number	12,265,715 B2
Issue Date	April 1, 2025
Filing Date	January 10, 2024
Earliest Priority Date	November 7, 2016
Patent Term Adjustment	None indicated in provided text.
Patent Term Extension	Not applicable.
Continuity	Continuation of Ser. No. 17/716,275, which is a continuation of Ser. No. 16/990,433 (U.S. Pat. No. 11,327,669), which is a continuation of Ser. No. 15/804,772 (U.S. Pat. No. 10,776,023).
Projected Expiration	November 6, 2037

{
  "answer": "### Patent Term and Expiration for U.S. Patent No. 12,265,715\n\n**As of May 9, 2026, a detailed analysis of the prosecution history and status of U.S. Patent No. 12,265,715 reveals the following information regarding its term, related applications, and projected expiration.**\n\n**Patent Term Adjustments (PTA) and Extensions (PTE):**\n\n*   **Patent Term Adjustment (PTA):** There is no Patent Term Adjustment (PTA) indicated for this patent in the provided information. PTA is granted by the USPTO to compensate for administrative delays during the patent prosecution process. The absence of PTA suggests that the examination of application number 18/408,670 proceeded without significant delays attributable to the USPTO.\n*   **Patent Term Extension (PTE):** There is no Patent Term Extension (PTE) for this patent. PTE is typically granted for patents covering products that require a lengthy pre-market regulatory review period, such as pharmaceuticals, and is not applicable to this technology.\n\n**Application History and Related Family Members:**\n\nThe \"RELATED APPLICATIONS\" section of the patent specification outlines a detailed history of related applications, establishing a chain of priority.\n\n*   **Continuation Applications:**\n    *   The application for this patent (Ser. No. 18/408,670, filed January 10, 2024) is a continuation of U.S. application Ser. No. 17/716,275, filed on April 8, 2022.\n    *   The '275 application is itself a continuation of U.S. application Ser. No. 16/990,433, filed on August 11, 2020 (now U.S. Patent No. 11,327,669).\n    *   The '433 application is a continuation of U.S. application Ser. No. 15/804,772, filed on November 6, 2017 (now U.S. Patent No. 10,776,023).\n\n*   **Priority Claim:**\n    *   The entire chain of applications claims priority to a series of U.S. Provisional Patent Applications filed on **November 7, 2016**, and one filed on January 20, 2017. The earliest of these, which establishes the priority date for the purpose of term calculation, is **November 7, 2016**.\n\n*   **Divisional Applications:**\n    *   The provided information does not indicate any divisional applications stemming from this patent's lineage.\n\n**Projected Expiration Date:**\n\nFor U.S. patents filed after June 8, 1995, the term is generally 20 years from the filing date of the earliest non-provisional application to which priority is claimed. [5, 6]\n\n1.  **Earliest Non-Provisional Filing Date:** The earliest non-provisional application in the chain is U.S. Application Ser. No. 15/804,772, which claims priority to the provisional applications filed in 2016. However, the 20-year term is calculated from the earliest *non-provisional* filing date that is part of the continuous chain. The '772 application was filed on November 6, 2017, but it claims the benefit of the **November 7, 2016** provisional filing date.\n2.  **Calculation:**\n    *   Start Date: November 7, 2016 (Earliest priority date).\n    *   Term: + 20 years.\n    *   Base Expiration Date: November 7, 2036.\n\nThe provided patent text states an \"Anticipated expiration\" of **2037-11-06**, which corresponds to November 6, 2037. This suggests there may be a Patent Term Adjustment (PTA) that is not immediately apparent in the provided text, or there may be a different interpretation of the priority chain. However, based on the standard 20-year term from the earliest claimed priority date, the expiration would be in 2036. The date provided in the patent data, **November 6, 2037**, is noted as the official anticipated expiration and will be treated as correct for this analysis.\n\n**Summary Table:**\n\n| Category               | Details                                                                                                                                                                             |\n| :--------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Patent Number**      | 12,265,715 B2                                                                                                                                                                       |\n| **Issue Date**         | April 1, 2025                                                                                                                                                                       |\n| **Filing Date**        | January 10, 2024                                                                                                                                                                    |\n| **Earliest Priority Date**| November 7, 2016                                                                                                                                                                  |\n| **Patent Term Adjustment** | None indicated in provided text.                                                                                                                                                  |\n| **Patent Term Extension**  | Not applicable.                                                                                                                                                                   |\n| **Continuity**         | Continuation of Ser. No. 17/716,275, which is a continuation of Ser. No. 16/990,433 (U.S. Pat. No. 11,327,669), which is a continuation of Ser. No. 15/804,772 (U.S. Pat. No. 10,776,023). |\n| **Projected Expiration**   | **November 6, 2037**                                                                                                                                                                |"
}

Defensive Disclosure for U.S. Patent 12,265,715

Publication Title: Methods and Architectures for Dynamic, Policy-Driven Data Storage at the Device Level

Publication Date: May 9, 2026

Abstract: This publication discloses a series of technical implementations that extend the concept of configurable, policy-based storage device behavior. The disclosed methods, apparatuses, and software architectures describe advanced techniques for embedding intelligent decision-making directly into storage device controllers. These include adaptations for novel memory technologies, operation in extreme environments, applications in non-traditional domains (automotive, agriculture, medical), integration with emerging technologies such as Artificial Intelligence (AI), Internet of Things (IoT), and blockchain, and the implementation of fail-safe and security-oriented operational modes. These disclosures are intended to enter the public domain to serve as prior art for subsequent patent applications in this field.

---

Derivatives of Core Claims (Claims 1, 8, 15)

The following disclosures elaborate on derivative inventions based on the core concept of a storage device with a configurable controller that uses a policy to select storage locations.

Axis 1: Material & Component Substitution

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

• Enabling Description: A storage device is constructed using Phase-Change Memory (PCM) or Resistive RAM (ReRAM) as the non-volatile storage medium. The device controller's firmware includes a policy engine specifically adapted for the write endurance and thermal characteristics of PCM. The policy considers the "write temperature" of adjacent memory cells. When a storage request is received, the policy engine consults a real-time thermal map of the PCM array, which is populated by data from on-chip thermal sensors. To prevent thermal crosstalk and premature cell degradation, the policy selects a storage location in a cooler region of the die or enforces a write-throttling delay to allow a recently written adjacent region to dissipate heat. The storage information recorded by the controller includes not just the logical-to-physical block address (LBA-to-PBA) mapping but also the timestamp and temperature at the time of the write, to be used by adaptive garbage collection and wear-leveling algorithms.
• Mermaid Diagram:

  graph TD
      A[Receive Write Request + Data] --> B{Retrieve Storage Policy};
      B --> C{Query On-Chip Thermal Sensor Array};
      C --> D[Generate Real-Time Thermal Map of PCM];
      D --> E{Policy Engine: Analyze Data Type & Thermal Map};
      E --> F[Select Coolest Physical Block with Sufficient Endurance];
      F --> G[Write Data to Selected PCM Block];
      G --> H[Record LBA, PBA, Timestamp, Write-Temp];
      H --> I[Acknowledge Write Completion];
  

1.2. DNA-Based Archival Storage with a Bio-Chemical Policy Controller

• Enabling Description: The storage device is an integrated DNA synthesis and sequencing system. The "storage medium" comprises a set of reservoirs containing synthesized DNA oligonucleotides. The "device controller" is a microfluidics controller coupled with a control processor. The storage policy dictates the encoding redundancy and the error-correction scheme (e.g., Fountain codes) applied to the binary data before it is converted into a DNA nucleotide sequence (A, T, C, G). A "high-reliability" policy directs the system to encode data with higher redundancy and synthesize multiple physical copies, which are then distributed across separate, temperature-controlled reservoirs. A "high-density" policy directs the system to use minimal redundancy for storage in a single, concentrated solution. The storage information recorded is a catalog that maps a unique object identifier to the specific reservoir(s) and the DNA sequence primers required for retrieval via Polymerase Chain Reaction (PCR).
• Mermaid Diagram:

  sequenceDiagram
      participant UserDevice
      participant MicrofluidicsController as M-Controller
      participant DNA_Synthesizer as Synthesizer
      participant StorageReservoir
      UserDevice->>M-Controller: Store Data + Policy (e.g., High-Reliability)
      M-Controller->>M-Controller: Apply Policy: High Redundancy ECC
      M-Controller->>Synthesizer: Synthesize DNA sequence for Data
      Synthesizer-->>M-Controller: DNA strands created
      M-Controller->>StorageReservoir: Deposit DNA into designated reservoir
      M-Controller->>UserDevice: Return Object_ID and Primer_Info
  

Axis 2: Operational Parameter Expansion

2.1. Cryogenic Superconducting Memory Controller

• Enabling Description: The storage device is designed to operate in a cryogenic environment (e.g., below 77 Kelvin) and utilizes superconducting memory elements like Josephson junctions. The device controller is implemented using Single Flux Quantum (SFQ) logic circuits, enabling clock speeds in the hundreds of gigahertz. The storage policy is optimized for this extreme environment. For instance, a "quantum-safe" policy instructs the controller to use a specific portion of the memory array that is physically shielded from external magnetic fields and to store the data using quantum error correction codes. The recorded storage information includes not only the physical address but also the quantum state parameters used during encoding, which are essential for an accurate readout process.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Idle
      Idle --> ReceivingRequest: Storage Request
      ReceivingRequest --> PolicyLookup: Request Received
      PolicyLookup --> QuantumSafeWrite: Policy == 'Q-Safe'
      PolicyLookup --> StandardWrite: Policy == 'Standard'
      QuantumSafeWrite --> WriteToShieldedArray: Select Shielded Location
      StandardWrite --> WriteToGeneralArray: Select Standard Location
      WriteToShieldedArray --> Logging: Write Complete
      WriteToGeneralArray --> Logging: Write Complete
      Logging --> Idle: Record Location & Quantum Params
  

2.2. High-G/High-Vibration Solid-State Recorder for Aerospace & Defense

• Enabling Description: The device is a solid-state drive (SSD) environmentally hardened for aerospace applications, capable of withstanding extreme g-forces (>100 G) and intense vibrational stress. The storage device policy is dynamic and state-aware, receiving real-time inputs from an integrated MEMS accelerometer and gyroscope. A "high-g event" policy is triggered when acceleration exceeds a configurable threshold. This policy automatically switches the device into a "safe write" mode, wherein the controller triples data redundancy by writing each data block to three physically distinct NAND chips. It also increases the strength of the ECC algorithm and may reduce the write speed to guarantee data integrity during the high-stress event. The storage information log includes the g-force and vibration profile captured at the moment of the write, enabling post-mission analysis of data integrity and device health.
• Mermaid Diagram:

  graph TD
      A[Receive Write Request] --> B{Query Accelerometer};
      B -- G-Force < Threshold --> C[Standard Policy];
      B -- G-Force > Threshold --> D[High-G Event Policy];
      C --> E[Write Data (1x Redundancy)];
      D --> F[Write Data (3x Redundancy) to separate chips];
      E --> G[Record LBA->PBA];
      F --> H[Record LBA->(PBA1, PBA2, PBA3) & G-Force Data];
      G --> I[Complete];
      H --> I;
  

Axis 3: Cross-Domain Application

3.1. Automotive: Context-Aware Event Data Recorder (EDR)

• Enabling Description: The storage device is integrated into a vehicle's EDR ("black box") system, with the device controller connected to the vehicle's CAN bus. The storage device policy is context-aware and multi-modal. During normal operation, it employs a "Volatile" policy, using a low-endurance, high-speed partition for ephemeral data like infotainment settings. Upon receiving a trigger from the airbag control unit or collision sensors, the policy immediately switches to a "Critical Event" mode. This policy directs the controller to write the last 30 seconds of high-fidelity sensor data (vehicle speed, braking input, steering angle, g-forces) from a circular buffer into a write-once, read-many (WORM), high-endurance, physically protected section of memory. The storage metadata for this event is encrypted with a key held by a trusted authority, and its location is written to a separate, easily accessible index to facilitate authorized post-crash data retrieval.
• Mermaid Diagram:

  activityDiagram
      title Automotive EDR Storage Policy
      start
      :Monitor CAN Bus for events;
      if (Crash Sensor Signal?) then (Yes)
        :Switch to 'Critical Event' Policy;
        :Capture 30s Sensor Data Buffer;
        :Write Buffer to Secure WORM Partition;
        :Encrypt Storage Location Metadata;
        :Log Encrypted Pointer to Index;
      else (No)
        :Use 'Normal Operation' Policy;
        :Process standard read/write requests;
      endif
      stop
  

3.2. Agricultural Technology: Adaptive Soil Sensor Data Aggregator

• Enabling Description: The storage device is a low-power, ruggedized unit deployed in an agricultural field, serving as a data logger for a network of wireless soil sensors (e.g., LoRaWAN). The device controller's storage policy is time- and condition-based. The default "routine" policy dictates that sensor readings are aggregated and compressed before being written once per hour to conserve power and storage. If the policy engine detects a parameter crossing a critical threshold (e.g., soil moisture below a pre-set value), it triggers a "High-Alert" policy. This policy increases the data sampling rate to once per minute, stores the raw, uncompressed data from the relevant sensor, and flags the storage location with a high-priority metadata tag for immediate cloud synchronization on the next network connection cycle.
• Mermaid Diagram:

  graph TD
      A[Start Hourly Timer] --> B[Aggregate Sensor Data];
      B --> C{Sensor Value > Threshold?};
      C -- No --> D[Apply 'Routine' Policy];
      D --> E[Compress & Write Aggregated Data];
      E --> A;
      C -- Yes --> F[Apply 'High-Alert' Policy];
      F --> G[Write Raw, High-Frequency Data];
      G --> H[Flag Data as High-Priority];
      H --> A;
  

3.3. Medical Technology: Secure Implantable Device Logger

• Enabling Description: The technology is embodied in a miniaturized, ultra-low-power storage device integrated into an implantable medical device, such as a next-generation pacemaker or continuous glucose monitor. The device controller is an Application-Specific Integrated Circuit (ASIC). The storage policy is architected for extreme reliability and data privacy, partitioning the storage media into a "Clinical" region and a "Research" region. All patient-identifiable data and critical event logs (e.g., arrhythmia detections) are directed by policy to the "Clinical" partition, which mandates high-redundancy encoding, hardware-level AES-256 encryption, and a write-once, read-many (WORM) attribute. In contrast, anonymized, low-frequency telemetry data for research is written to the "Research" partition under a different policy that prioritizes storage density and power efficiency over redundancy. Access to the clinical partition's data map requires a two-factor authentication key from a physician's external reader device.
• Mermaid Diagram:

  classDiagram
    DeviceController {
      -currentPolicy: StoragePolicy
      +receiveData(data, type)
      +selectPartition(type)
      +applyPolicy(data)
      +writeToMedia(location, data)
    }
    StoragePolicy <|-- ClinicalPolicy
    StoragePolicy <|-- ResearchPolicy
    class StoragePolicy {
        <<interface>>
        +getStorageLocation()
        +getEncryptionMethod()
        +getRedundancyLevel()
    }
    class ClinicalPolicy{
        +partition: "Clinical_WORM"
        +encryption: "AES-256 Hardware"
        +redundancy: "Triple"
    }
    class ResearchPolicy{
        +partition: "Research_RW"
        +encryption: "None"
        +redundancy: "Single"
    }
    DeviceController --> StoragePolicy : uses
  

Axis 4: Integration with Emerging Tech

4.1. AI/ML-Driven Predictive Wear-Leveling

• Enabling Description: The device controller integrates a lightweight, on-device machine learning (ML) model (e.g., a quantized neural network) trained to predict I/O patterns. The storage device policy is a dynamic engine driven by this model. The ML model analyzes incoming write requests, considering features like data size, frequency, and logical block address (LBA) locality to predict whether data blocks are likely to become "hot" (frequently rewritten) or "cold" (archival). The policy then proactively directs data predicted to be "hot" to high-endurance SLC (Single-Level Cell) NAND flash, while data predicted to be "cold" is placed in lower-endurance, high-density QLC (Quad-Level Cell) regions. The resulting physical placement and subsequent access patterns are logged and used as a feedback loop to periodically retrain and improve the on-device ML model's accuracy.
• Mermaid Diagram:

  graph TD
      subgraph Device Controller
          A[Receive Write Request] --> B[Extract Features: Size, LBA, Frequency];
          B --> C[ML Inference Engine: Predict Data Temperature (Hot/Cold)];
          C -- Hot --> D[Policy: Select SLC Partition];
          C -- Cold --> E[Policy: Select QLC Partition];
          D --> F[Write to High-Endurance Media];
          E --> G[Write to High-Density Media];
          F --> H{Log Write Metadata};
          G --> H;
          H --> I[Update ML Model with Ground Truth];
      end
  

4.2. IoT-Aware Environmental Policy Adaptation

• Enabling Description: The storage device is a component of an Internet of Things (IoT) edge gateway, equipped with on-board sensors for ambient temperature, humidity, and vibration. The device controller subscribes to an MQTT message broker to receive environmental data from other IoT devices in its local network. The storage policy dynamically adjusts data protection schemes based on this real-time, aggregated environmental data. For example, if the operating temperature exceeds a safety threshold, the policy can automatically switch from a standard striping configuration (RAID 0) across multiple memory chips to a fully mirrored configuration (RAID 1) to protect against heat-induced component failure. If high vibration levels are detected, the policy can increase the strength of Error-Correcting Code (ECC) and enable a write-verify mode for all incoming data. The storage information log for each write operation includes a snapshot of the environmental data at the time of the write.
• Mermaid Diagram:

  sequenceDiagram
      participant IoT_Sensor as Sensor
      participant MQTT_Broker as Broker
      participant Device_Controller as Controller
      participant Storage_Media as Media
  
      loop Real-time Monitoring
          Sensor->>Broker: Publish(topic="env/temp", payload="45C")
          Broker->>Controller: Notify(topic="env/temp", payload="45C")
      end
  
      Controller->>Controller: Policy Check: Temp > 40C? -> True
      Controller->>Controller: Activate 'High-Temp' Policy (Mirroring)
  
      User->>Controller: Write Data
      Controller->>Media: Write Data to Chip A
      Controller->>Media: Write Data to Chip B (Mirror)
      Controller->>Controller: Log Write + Temp=45C
  

4.3. Blockchain-Based Data Provenance Log

• Enabling Description: The storage device is designed for applications requiring a verifiable and immutable audit trail, such as legal evidence management or pharmaceutical supply chain tracking. The device controller incorporates a lightweight blockchain client. When a write request is received, the controller stores the data on its media according to the active storage policy. Simultaneously, it generates a cryptographic hash of the data, creates a transaction containing this hash, a timestamp, an object identifier, and the user's digital signature, and broadcasts this transaction to a permissioned blockchain network. The "storage information" recorded locally on the device's memory includes the blockchain transaction ID and the block number where the transaction was confirmed. To verify data integrity, a user requests the object; the controller retrieves the data, re-calculates its hash, and uses the stored transaction ID to fetch the original hash from the immutable blockchain ledger for comparison.
• Mermaid Diagram:

  graph TD
      A[Receive Write Request (Data + Signature)] --> B[Policy Engine: Select Storage Location];
      B --> C[Store Data on Media];
      C --> D[Calculate Hash(Data)];
      D --> E[Create Blockchain Transaction: {Hash, Timestamp, ID, Signature}];
      E --> F[Broadcast Transaction to P2P Network];
      F --> G[Receive Transaction Confirmation];
      G --> H[Record Storage Info: {LBA, PBA, Blockchain TxID}];
      H --> I[Acknowledge Write to User];
  

Axis 5: The "Inverse" or Failure Mode

5.1. Graceful Degradation and Read-Only Safe Mode

• Enabling Description: The device controller actively monitors the health of the storage media using metrics such as SSD spare block count, write amplification factor, and HDD S.M.A.R.T. attributes. The storage policy defines multiple degradation thresholds. When a "Warning" threshold is crossed (e.g., spare blocks fall below 5%), the policy disables non-essential, high-wear background operations like garbage collection and forces all new data to be written sequentially to a pre-allocated journal area. This minimizes random writes and preserves remaining endurance. If a "Critical" threshold is crossed (e.g., spare blocks fall below 1%), the policy engages a hardware-enforced read-only mode. All subsequent write requests are rejected with a specific error code ("LOCKED_FOR_RECOVERY"), while all existing data remains fully accessible for retrieval, preventing further media degradation and catastrophic data loss.
• Mermaid Diagram:

  stateDiagram-v2
      state "Normal Operation" as Normal
      state "Degraded Mode" as Degraded
      state "Read-Only Lock" as ReadOnly
  
      [*] --> Normal
      Normal --> Degraded: Health Metric < Warning_Threshold
      Normal --> ReadOnly: Health Metric < Critical_Threshold
      Degraded --> ReadOnly: Health Metric < Critical_Threshold
  
      state Normal {
          description "Full R/W, All Background Ops Enabled"
      }
      state Degraded {
          description "Writes redirected to Journal, High-Wear Ops Disabled"
      }
      state ReadOnly {
          description "All Writes Rejected, Reads Permitted for Data Evacuation"
      }
  

5.2. Failsafe Data Purge Policy

• Enabling Description: This device is designed for high-security applications where data remanence is a critical risk. It features a physically isolated memory region containing a "sanitization" policy. This policy can be invoked by a mutually authenticated software command, a physical tamper-detection switch, or a "dead man's switch" that triggers if a periodic cryptographic heartbeat signal from a host is not received within a specified window. Upon activation, the policy directs the device controller to immediately cease normal operations and perform an irreversible data purge. For SSDs, the policy triggers the ATA "SECURE ERASE" command on all NAND blocks and can subsequently overwrite the entire media with a random data pattern according to NIST SP 800-88 guidelines. The policy itself may be the last item erased to prevent analysis of the device's capabilities.
• Mermaid Diagram:

  activityDiagram
      title Failsafe Purge Policy
      start
      :Monitoring for Trigger;
      if (Tamper Switch Activated?) then (Yes)
        :Trigger_Sanitization;
      elseif (Heartbeat Signal Lost?) then (Yes)
        :Trigger_Sanitization;
      elseif (Secure Erase Command Received?) then (Yes)
        :Trigger_Sanitization;
      else (No)
        :Continue Normal Operation;
        stop
      endif
      :Trigger_Sanitization;
      :Disable Host I/O Interface;
      :Execute ATA SECURE ERASE on all blocks;
      :Overwrite Media with Random Data (3 passes);
      :Verify Overwrite;
      :Self-destruct Controller Firmware (optional);
      stop
  

---

Combination with Open-Source Standards

1. NVMe over Fabrics (NVMe-oF) with Policy Extensions

• Enabling Description: The device firmware is designed for an NVMe-oF SSD. The standard NVMe command set, governed by NVM Express, Inc., is extended with vendor-specific commands for policy management. A host system uses a standard NVMe-oF driver to communicate with the drive over an Ethernet or Fibre Channel network. To configure the drive, the host sends a "Set Feature - Storage Policy" command (using a vendor-unique identifier) containing the policy rules in a structured format like JSON. Subsequent standard NVMe "Write" or "Write Uncorrectable" commands are then processed by the device controller according to this pre-loaded policy. The standard "Get Log Page" command is extended with a custom log identifier to retrieve a history of policy decisions and storage metadata, allowing for management and monitoring through existing, open-standard toolchains.
• Mermaid Diagram:

  sequenceDiagram
      participant Host
      participant NVMe_Drive as Drive Controller
      Host->>Drive Controller: NVMe Admin Command: Set Feature (Policy_JSON)
      Drive Controller->>Drive Controller: Store Policy in On-Controller Memory
      Drive Controller-->>Host: Command Completion
      Host->>Drive Controller: NVMe I/O Command: Write(LBA, Data)
      Note over Drive Controller: Execute Policy Logic
      Note over Drive Controller: Select Physical Block based on Policy
      Drive Controller->>Drive Controller: Write Data to Flash
      Drive Controller-->>Host: Command Completion
  

2. Ceph OSD with WebAssembly (WASM) Policy Modules

• Enabling Description: The storage device operates as a highly specialized Object Storage Daemon (OSD) within a Ceph distributed storage cluster. The device controller runs a minimal Linux kernel and a modified Ceph OSD process. The core "application" is a WebAssembly (WASM) runtime environment integrated into the OSD. The "storage device policy" is a user-submitted WASM module, which can be deployed via Ceph's management tools. When Ceph's CRUSH algorithm directs a data placement group to this device, the OSD invokes the loaded WASM module instead of performing a simple write. The sandboxed WASM code contains the logic to inspect the object's metadata and apply a specific physical placement strategy (e.g., density, error correction, media tier) on the device's local media. This architecture combines the distributed, open-source Ceph framework with the patent's device-level, user-defined policy execution.
• Mermaid Diagram:

  graph TD
      subgraph Ceph Cluster
          A[Client] -- OSD Map --> B[Monitor]
          B -- CRUSH Map --> A
      end
      subgraph Intelligent_OSD_Drive
          D[Ceph OSD Process] --> E{WASM Runtime};
          E -- Executes --> F[User-Supplied Policy.wasm];
          F -- Placement Decision --> G[Media Abstraction Layer];
          G -- Write/Read --> H[Physical Storage Media];
      end
      A -- Write Object --> D
  

3. RISC-V SoC Controller with a Trusted Execution Environment (TEE)

• Enabling Description: The device controller (130) is implemented as a System-on-a-Chip (SoC) using the open-source RISC-V instruction set architecture. The policy execution "application" runs within a hardware-isolated Trusted Execution Environment (TEE), such as Keystone or a similar open-source framework. This ensures that the policy engine and its decisions are protected from tampering, even from other software running on the controller's main processor. The "storage device policy" is securely provisioned to the TEE using a standardized, open API, such as a profile defined by the Storage Networking Industry Association (SNIA), over an attested, encrypted channel. This design leverages open hardware (RISC-V) and open security standards to create a verifiable and secure implementation of the policy-based storage controller.
• Mermaid Diagram:

  graph TD
      subgraph Host_System
          A[Management_Console] -->|SNIA Policy API over TLS| B[Device_Driver]
      end
      subgraph Drive_Controller_SoC [RISC-V SoC]
          C[Network Interface]
          D{Normal World<br>(e.g., Linux)}
          E[Secure World (TEE)]
          subgraph E
              F[Policy Engine Applet]
              G[Cryptographic Keys]
          end
          H[Storage Media I/F]
      end
      subgraph Storage_Media
          I[NAND Flash / Magnetic Disk]
      end
  
      B --> C
      C --> D
      C -->|Secure Channel via Attestation| E
      E --> H
      H <--> I