Obviousness

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

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

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

Combination of Prior Art Rendering the Claims Obvious

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

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

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

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

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

Secondary Art and Motivation to Combine

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

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

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

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

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

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

Conclusion on Obviousness

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

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

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

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