Obviousness

Obviousness Analysis under 35 U.S.C. § 103 for US Patent 7490263

This analysis identifies combinations of prior art references that would render the claims of US Patent 7490263 obvious to a person having ordinary skill in the art (PHOSITA) as of the priority date of January 17, 2006. The motivation for combining these references stems directly from the problems articulated in the background section of US7490263 itself.

Problem Addressed by US7490263:
US7490263 highlights a significant problem in existing storage systems:

• Storage controllers often issue "WRITE without verify" commands for performance, assuming successful writes.
• Even if no write error is immediately detected, a subsequent read operation at the same location might fail.
• Storage controllers may not remember or act upon previously reported read errors (especially marginally recovered ones, or when reporting is disabled) when a new write request comes in for that logical block address (LBA).
• Consequently, defective physical locations on the storage medium may remain unrecovered, even when updated data is written, because the controller does not initiate a reassignment.
• "Normally, when a data block needs to be updated, a WRITE command is issued by the storage controller, without prior knowledge or retained memory that the block on the HDD may have been determined by the HDD as defective... Merely rewriting a previously found erroneous block may not resolve the problem, especially when a reassignment for that block is already recommended by the HDD." [Description, Section "BACKGROUND OF THE INVENTION", Paragraph 14]

The invention seeks to address this by empowering the storage device (e.g., HDD) to "enforce" write recovery by the storage controller, specifically for blocks previously identified as defective during read operations.

Key Elements of Independent Claims (Claims 1, 6, 12):
The independent claims of US7490263 generally describe:

1. Reassignable Check Module: A module within the storage device that determines if the LBA of data specified by a "write without verify" command is included in an internal "reassignment log." This log stores LBAs of defective blocks (from unrecovered or marginally recovered read errors) recommended for reassignment by the storage controller. The log removes an LBA once the block is no longer deemed defective.
2. Auto Verify Module: If the LBA is in the reassignment log, this module automatically verifies that data is correctly written at the LBA after the write operation.
3. Error Posting Module: If the auto-verify fails, this module reports an "unrecovered write error" to the storage controller, triggering the controller's write error recovery procedure (which typically includes reassignment and re-write).

Prior Art References and their Teachings:
The following US patents, cited as prior art to US7490263, are highly relevant:

• US7017088B2 (Dynamic disk reassignment and write back capability for data storage, filed 2001-05-29, granted 2006-03-21): This patent teaches a method where, upon execution of a data transfer (read or write), a storage device checks a "list of bad blocks" (analogous to the "reassignment log" in US7490263) for the LBA to be written or read. If the LBA is found in the bad block list and data is to be written, the data is written directly to an associated spare sector. [Description, US7017088B2 Abstract]. This reference thus teaches the storage device maintaining an internal defect log and checking it during a write operation.
• US6745353B1 (SCSI disk drive write error recovery, filed 2002-06-21, granted 2004-06-01): This patent describes a SCSI disk drive write error recovery method. It explicitly mentions that the disk drive "stores information identifying the data sector as a previously defective data sector." [Description, US6745353B1 Abstract]. Furthermore, it teaches that "If the disk drive detects an error during a write command and the data sector is identified as the previously defective data sector, the write process of the data is retried a predetermined number of times, after which the data sector is reallocated to a spare sector if the error persists. Otherwise, a write fault is generated without retrying the write process." [Description, US6745353B1 Abstract]. This reference demonstrates the concept of the drive knowing about and acting upon previously identified defects during a write, including generating a "write fault" (error report).
• US6912686B2 (Managing errors in a data storage system, filed 2002-03-21, granted 2005-06-28): This patent describes a storage device having a "defect list" and being configured to "report the defect to the storage controller." The storage controller, in turn, is "configured to receive the defect... and to reassign the defect." [Description, US6912686B2 Abstract]. This teaches the storage device reporting defects to the controller for reassignment.
• General knowledge in the art: The concept of "WRITE AND VERIFY" commands and the associated internal data verification (e.g., ECC check) within storage devices was well-known at the time. US7490263 itself describes the WRITE AND VERIFY command as one that "requests that the HDD 115 write the data transferred... and then verify that the data is correctly written. Normally, for the verify portion of the command, the HDD 115 performs an ECC check..." [Description, Section "DETAILED DESCRIPTION OF THE INVENTION", Paragraph 35].

Obviousness Combination and Motivation:

A PHOSITA, faced with the persistent problem of storage controllers failing to reassign defective blocks (especially those identified during prior read operations, or marginally recovered errors not explicitly reported by the HDD) when a "write without verify" command is issued, would be motivated to combine the teachings of the cited prior art to ensure data integrity and proper defect management.

1. Starting Point - Internal Defect Tracking and Write Action:

   • US7017088B2 provides the foundational idea that a storage device should internally track "bad blocks" and consult this list upon receiving a write command. It teaches that if an LBA is on this list during a write, the data should be written to a spare sector. This addresses the "reassignable check module" and the core idea of acting on known defects during a write.

2. Addressing Controller Inaction and Forcing Recovery:

   • The limitation of US7017088B2 (from the perspective of US7490263's problem) is that it describes the HDD internally handling the reassignment. However, as noted in US7490263, storage systems might require the storage controller to perform the reassignment (e.g., due to system configurations disabling automatic reallocation by the drive, or for RAID consistency and logging).
   • A PHOSITA would recognize the need to involve the controller. US6912686B2 teaches the general principle of a storage device reporting defects to the controller to enable the controller to reassign. US6745353B1 further supports this by teaching a drive generating a "write fault" (error report) for a previously defective sector under certain write error conditions, prompting controller action.

3. Introducing Automatic Verification for "Write Without Verify" Commands:

   • The crucial gap for "write without verify" commands is that no immediate write error might occur. However, the art widely understood the importance of data verification, as evidenced by the existence and functionality of "WRITE AND VERIFY" commands.
   • A PHOSITA, motivated to ensure data integrity for blocks previously deemed defective (per the problem statement), would find it obvious to apply the known concept of data verification (e.g., an ECC check, as used in WRITE AND VERIFY commands) automatically after a "write without verify" operation if the target LBA is found in the device's internal defect log (as taught by US7017088B2). This automatically performed verification addresses the "auto verify module."

4. Reporting an "Unrecovered Write Error" to Trigger Controller Recovery:

   • If this automatic internal verification fails, the PHOSITA would then combine this with the teachings of US6745353B1 and US6912686B2: the storage device should report an error to the controller. Specifically, reporting an "unrecovered write error" (which is a standard error type that triggers controller write recovery procedures, as described in US7490263's background) would be an obvious choice. This directly addresses the "error posting module." This effectively "forces" the storage controller to initiate its predefined write recovery procedure, including issuing a REASSIGN BLOCKS command and re-writing the data, thus solving the problem of unhandled defective blocks.

Therefore, combining the teachings of US7017088B2 (internal defect tracking and checking during a write), the general knowledge of write verification (e.g., via WRITE AND VERIFY commands), and US6745353B1 (storing previously defective sector information and generating write faults) or US6912686B2 (reporting defects to the controller for reassignment) would render the apparatus, system, and method of US7490263 obvious. The motivation is to proactively address the well-understood problem of persistent media defects going unaddressed by a storage controller that lacks specific memory of prior read errors and issues "write without verify" commands, thereby improving data reliability and system performance by avoiding futile read attempts.