DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is the initial Office Action based on the application filed 11/01/2024. Claims 1-20 are presented for examination and have been considered below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Berman (US 2016/0321135 A1) and further in view of Lee (US 9,927,998 B2).
Claim 1: Berman teaches a memory controller (e.g., FIG. 2A, element 1230; [0056], [0068]) comprising:
an error detection circuit configured to externally receive write data and a plurality of logical addresses corresponding to the write data, and generate error detection data corresponding to the write data (e.g., Berman teaches an error correction processor (ECC circuit 200) configured to obtain error location information for page data received from a source memory block over a memory channel. See claim 1, and para 0086. The page data constitutes "write data" in the context of memory operations. Berman further teaches, at para 0002 and 0052, operation within a Flash Translation Layer (FTL) utilizing Logical Block Addressing (LBA), which inherently involves receiving data with corresponding logical addresses. The error location information generated by the ECC circuit constitutes "error detection data" as it identifies the locations of errors in the received page data. See para 0086.).
Berman fails to explicitly teach:
a data compression circuit configured to compress the write data to generate compression data corresponding to partial logical addresses among the plurality of logical addresses; and
a map data controller configured to manage map data including a mapping relationship between the plurality of logical addresses and physical addresses of a memory device, and store physical addresses mapped to the partial logical addresses, the error detection data, and compression information related to the compression data in the map data.
As per item (a), Berman teaches a compression processor 201 configured to compress the obtained error location information. See claim 1, para [0087] and [0099]. While Berman compresses error location information rather than the write data itself, this teaches the structural element of a compression circuit operating on data associated with write operations. The compression generates compressed data that corresponds to portions of the overall data being processed. And as per item (b), Berman teaches operation within a Flash Translation Layer (FTL) that implements a logical to physical mapping system called Logical Block Addressing (LBA). See para [0002] and [0052]]. This inherently requires managing map data that maintains the mapping relationship between logical addresses (LBAs) and physical addresses in the NAND memory. A person having ordinary skill in the art (POSITA) would understand that an FTL necessarily includes a map data controller to perform this function.
Furthermore, regarding compressing write data to generate compression data,Lee explicitly teaches compressing a plurality of blocks of data (write data) to generate compressed blocks stored in a logical section of non-volatile memory. See claim 1 and para 0030. And regarding map data management and storage of physical addresses, error detection data, and compression information, Lee teaches managing a table relating logical identifiers to physical locations of compressed blocks. See para 0019 and claim 2. Lee further teaches generating headers that include compressed length information for each compressed block; this constitutes "compression information" as claimed. See claim 1 and 0030. The headers contain the lengths of compressed blocks, which function as offset data indicating where compressed data is located.While Lee stores these headers in a contiguous section of the logical section rather than in the map table itself, a POSITA would have been motivated to store this compression information in the map data because storing all metadata (physical addresses, error detection data, and compression information) in the map data consolidates information needed for data access, thus improving lookup efficiency. Besides, the function of compression information (indicating locations/offsets of compressed blocks) remains the same regardless of where it is stored. Moving this information from headers to the map table is a routine design optimization.
Therefore, a POSITA, before the effective filing date of the claimed invention, would have been motivated to combine Berman's error detection and compression architecture with Lee's compression management teachings in order to optimize memory controller performance.
Claim 2: Berman and Lee teach the memory controller of claim 1, but fail to teach that the compression information includes at least one of data indicating whether the write data is compressed and offset data indicating positions where the physical addresses are stored in storage areas allocated to each of the plurality of logical addresses. However, Lee explicitly teaches generating headers that include compressed length information for each compressed block (e.g., claim 1, [0030]). These headers function as compression information that would necessarily include data indicating whether blocks are compressed (as headers exist only for compressed blocks) and length information that enables calculation of offsets to locate specific compressed blocks (e.g., [0015], [0030]). Lee further teaches that the headers contain the compressed length of each compressed block (e.g., claim 1). Therefore, a POSITA would understand that length information directly provides offset data when combined with knowledge of preceding block lengths and header sizes. Therefore, Lee's headers inherently contain compression information that indicates compression status (through the presence of a header) and provides data (lengths) from which offsets can be derived. Berman's system, when combined with Lee's header structures, would necessarily include such compression information. The specific inclusion of offset data is a routine implementation of Lee's length-based location system.
Claim 3: Berman and Lee teach the memory controller of claim 1, but fail to teach that the map data controller is configured to: allocate storage areas to each of the plurality of logical addresses; and store the physical addresses, the error detection data, and the compression information in the storage areas allocated to each of the plurality of logical addresses. However, Berman teaches operation within a Flash Translation Layer (FTL) utilizing Logical Block Addressing (LBA) (e.g., [0002], [0052]). FTL inherently allocates storage areas to logical addresses as part of its mapping function. Berman's error correction processor generates error location information that would be stored in conjunction with mapping data. Furthermore, Lee teaches managing a table relating logical identifiers (logical addresses) to physical locations of compressed blocks (e.g., [0019], claim 2). Lee further teaches generating headers containing compression information (lengths) for compressed blocks (e.g., claim 1, [0030]). While Lee stores headers separately from the map table, a POSITA would recognize that storing compression information in the same storage areas allocated to logical addresses (i.e., in the map data) is a straightforward optimization. Berman's FTL framework provides the allocation mechanism, and Lee provides the compression information content. Combining these teachings yields a map data controller that stores all three types of information (physical addresses, error detection data, compression information) in allocated storage areas.
Claim 4: Berman and Lee teach the memory controller of claim 3, but fail to teach that the map data controller is configured to: store the physical addresses and the compression information in partial storage areas allocated to the partial logical addresses, among the storage areas allocated to each of the plurality of logical addresses; and store the error detection data in a remaining storage area except for the partial storage areas allocated to the partial logical addresses, among the storage areas allocated to each of the plurality of logical addresses. However, Berman teaches that error location information (error detection data) is generated separately from the page data and is handled distinctly by the compression processor (e.g., [0086]-[0087]). This separate handling would suggest storing error detection data separately from other metadata. Furthermore, Lee teaches storing headers (containing compression information) in a contiguous section of the logical section (e.g., [0030]). This demonstrates a preference for grouping compression-related metadata together. Therefore, a POSITA would understand that different types of metadata serve different purposes and could be stored in different portions of allocated storage areas. Storing physical addresses and compression information together in partial areas (as they relate directly to data location) while storing error detection data separately (as it relates to data integrity verification) is a logical organization scheme. Berman's separate handling of error information and Lee's grouping of compression information would have suggested this arrangement.
Claim 5: Berman and Lee teach the memory controller of claim 3, but fail to teach that the map data controller is configured to: store the physical addresses in partial storage areas among the storage areas allocated to each of the plurality of logical addresses; and store the error detection data and the compression information in a remaining storage area except for the partial storage areas among the storage areas allocated to each of the plurality of logical addresses. However, Berman teaches separate handling of error location information (e.g., [0086]-[0087]). Furthermore, Lee teaches grouping compression information (headers) together (e.g., [0030]). Therefore, a POSITA would recognize that both metadata types (error detection and compression information) could be grouped together for efficient access, as they are both ancillary to the primary physical address mapping. The arrangement is a routine design choice.
Claim 6: Berman and Lee teach the memory controller of claim 1, but fail to teach that the map data controller is configured to: store the error detection data and the compression information in the map data when a compression rate for the write data is equal to or greater than a preset critical value. However, Berman teaches compressing error location information to reduce channel traffic (e.g., [0087], [0099]). This demonstrates awareness that compression is beneficial only when it achieves meaningful savings. Furthermore, Lee teaches that "each LBA data have different compression rates" (e.g., [0015]) and that compressed data lengths are variable. A POSITA would understand that compression effectiveness varies and that storing compression-related metadata may only be worthwhile when compression achieves a threshold savings. Therefore, a POSITA would recognize that if compression does not achieve significant space savings (i.e., compression rate below a threshold), storing compression information may not be justified. This is a routine implementation of threshold-based decision-making in data management systems.
Claim 7: Berman and Lee teach the memory controller of claim 1, but fail to further teach comprising: a memory operation controller configured to: control a buffer memory to store the compression data; and control the buffer memory and the memory device to transmit the compression data from the buffer memory to the memory device according to an external request. However, Berman teaches a device controller 1230 that controls buffer memory 1240 and communicates with NAND devices (e.g., at FIG. 2A, [0068], [0095]). Berman's system buffers page data and transmits compressed error location information to target memory blocks (e.g., [0088], [0096]). Furthermore, Lee teaches using a read-out buffer to store compressed data and a hardware decoder to control data transmission (e.g., FIG. 4, [0030]). Therefore, a POSITA would have found it obvious to include such controller functionality, as it is necessary for basic memory operations.
Claim 8: Berman and Lee teach the memory controller of claim 7, but fail to teach that the memory operation controller is configured to: receive the compression data from the memory device based on the physical addresses stored in the map data; and provide the received compression data to the buffer memory. However, Berman teaches receiving page data from memory blocks based on physical addressing within the FTL/LBA framework (e.g., [0085]). Furthermore, Lee explicitly teaches reading compressed data blocks based on physical locations stored in the LBA table and transferring them to a buffer (e.g., [0030], claim 9). Therefore, it would have been obvious to a POSITA, before the effective filing date of the claimed invention, to combine the teaching of Berman with the one taught by Lee in order to implement compressed data read operations.
Claim 9: Berman and Lee teach the memory controller of claim 8, but fail to teach that the data compression circuit is configured to decompress the compression data based on the compression information stored in the map data. However, Berman teaches decompressing compressed error location information to obtain error locations (e.g., [0089], [0102]). Furthermore, Lee teaches decompressing compressed data blocks using header information that indicates lengths and offsets (e.g., [0030], claim 9). Therefore, a POSITA combining Berman's decompression capability with Lee's compression information structure would naturally perform decompression based on that information. Storing the compression information in map data rather than in separate headers is a predictable location choice.
Claim 10: Berman and Lee teach the memory controller of claim 9, but fail to teach that the error detection circuit is configured to perform an error detection operation on the decompressed data based on the error detection data stored in the map data. However, Berman teaches performing error detection on page data to obtain error location information (e.g., [0086], [0098]). Furthermore, Lee teaches decompressing data blocks (e.g., [0030]). Therefore, a POSITA would have found it obvious to perform error detection on decompressed data using previously stored error detection data. Error detection after decompression is a standard data integrity measure to ensure that decompression did not introduce or reveal errors. Berman provides the error detection mechanism, and the combination with Lee's decompression would naturally lead to this sequence.
Claim 11: Burman teaches a method of operating a memory controller for controlling a memory device that stores data and a buffer memory that temporarily stores data to be provided to the memory device or data received from the memory device, the method comprising:
externally receiving a read request corresponding to a plurality of logical addresses (e.g. [0085]);
obtaining physical addresses mapped to partial logical addresses among the plurality of logical addresses from map data (e.g. [0002], [0052];
performing error detection on data (e.g., [0086], [0098]);
moving data between memory and buffers (e.g., [0085], [0096]).
But Burman fails to teach:
controlling compression data stored in the memory device to move to the buffer memory based on the obtained physical addresses;
decompressing the compression data moved to the buffer memory based on compression information stored in the map data; performing an error detection operation on the decompressed data based on error detection data stored in the map data; and externally providing the decompressed data depending on the error detection operation.
However, Lee teaches:
reading compressed data blocks based on physical locations (e.g., [0030], claim 9);
decompressing compressed data using header information (e.g., [0030]);
providing decompressed data to a host device (e.g., claim 9); and
storing compression information (headers) in the logical section (e.g., [0030]).While Lee stores these headers in a contiguous section of the logical section rather than in the map table itself, a POSITA would have been motivated to store this compression information in the map data because storing all metadata (physical addresses, error detection data, and compression information) in the map data consolidates information needed for data access, thus improving lookup efficiency. Besides, the function of compression information (indicating locations/offsets of compressed blocks) remains the same regardless of where it is stored. Moving this information from headers to the map table is a routine design optimization.
Therefore, a POSITA, before the effective filing date of the claimed invention, would have been motivated to combine Berman's error detection and compression architecture with Lee's compression management teachings in order to optimize memory controller performance.
Claim 12: Berman and Lee teach the method of claim 11, but fail to teach that performing the error detection operation comprises generating a pass signal in response to a pass of the error detection operation. However, Berman's error correction processor performs error detection and would inherently generate signals indicating whether errors were found (e.g., [0086]). Besides, generating a pass signal upon successful error detection is a routine implementation detail and any error detection system must provide an indication of success or failure, which would have been obvious to a POSITA.
Claim 13: Berman and Lee teach the method of claim 12, but fail to teach that the externally providing the decompressed data comprises externally providing the decompressed data in response to the pass signal. However, Lee teaches providing decompressed data to a host (e.g., claim 9) and Berman teaches error detection (e.g., [0086]). Furthermore, conditioning data provision on successful error detection is a standard data integrity measure. Besides, Conditioning data provision on successful error detection is a standard data integrity measure. Therefore, a POSITA would naturally implement this to ensure that only verified data is provided to the host. The combination of Lee's data provision and Berman's error detection would have made this obvious.
Claim 14: Berman and Lee teach the method of claim 11, but fail to further teach comprising: decompressing the compression data moved to the buffer memory back in response to a failure of the error detection operation. However, Berman teaches error detection (e.g., [0086]] and Lee teaches decompression operations (e.g., [0030]). Therefore, upon error detection failure, a POSITA would attempt corrective actions such as re-decompression. This is a standard error recovery technique, wherein if data fails verification after decompression, re-attempting decompression (which may involve different parameters or re-reading from source) is an obvious troubleshooting step.
Claim 15: Berman and Lee teach the method of claim 11, but fail to further teach comprising: controlling, in response to a failure of the error detection operation, compression data stored in the memory device to be moved back to the buffer memory based on the obtained physical addresses. However, Berman teaches moving data between memory blocks and buffers (e.g., [0085], [0096]). Furthermore, Lee teaches reading compressed data based on physical addresses (e.g., [0030], claim 9). Besides, re-reading data upon error detection failure is a standard error recovery technique. And if decompressed data fails error detection, a POSITA would attempt to re-read the original compressed data from memory (based on the same physical addresses) and re-attempt decompression. This would have been obvious.
Claim 16: Berman and Lee teach the method of claim 11, further comprising: externally providing a read fail signal in response to a failure of the error detection operation. However, Berman's error detection would inherently require error reporting mechanisms (e.g., [0086]). Besides, providing failure indications to a host is a routine error handling mechanism. Therefore, a POSITA would have found it obvious to provide a read fail signal upon unrecoverable errors to inform the host of the failure.
Claim 17: Berman teaches a storage device comprising:
a memory device configured to store data (e.g., FIG. 2A, [0068]);
a buffer memory (e.g., item 1240, fig. 1) configured to temporarily store data provided from the memory device or data to be provided to the memory device (e.g., [0069], [0095]);
and a memory controller (e.g. item 1230) configured to control the buffer memory (e.g. [0068]) to externally receive write data (e.g. page data, [0085]), generate error detection data (e.g., error location information, [0086]) corresponding to the write data;
control the buffer memory to store data (e.g., [0095]); and
store data in the memory device (e.g., [0088], [0104]).
Not explicitly taught by Berman is to compress the write data. However, Lee explicitly teaches compressing write data to generate compression data and storing it in non-volatile memory (e.g., claim 1, [0030]). Therefore, a POSITA, before the effective filing date of the claimed invention, would have been motivated to combine Berman's error detection and compression architecture with Lee's compression management teachings in order to optimize memory controller performance.
Claim 18: Berman and Lee teach the storage device of claim 17, but fail to teach that the memory controller is configured to: store the physical addresses in a portion of a storage area allocated to a plurality of logical addresses corresponding to the write data in the map data; and store the compression information and the error detection data in a remainder of the storage area. However, Berman teaches separate handling of error location information (e.g., [0086]-[0087]). Furthermore, Lee teaches storing headers (containing compression information) in a contiguous section (e.g., [0030]). Therefore, a POSITA would recognize that both metadata types (error detection and compression information) could be grouped together for efficient access, as they are both ancillary to the primary physical address mapping. The arrangement is a routine design choice.
Claim 19: Berman and Lee teach the storage device of claim 17, but fail to teach that the memory controller is configured to: control the memory device and the buffer memory to store read data read from the memory device in the buffer memory according to a read request; and decompress the read data in response to a determination that the read data is compressed according to the compression information stored in the map data. However, Berman teaches read operations within the FTL/LBA framework and storing read data in buffers (e.g., [0085], [0096]). Furthermore, Lee explicitly teaches reading compressed data from memory, buffering it, and decompressing it based on header information (compression information) (e.g., [0030], claim 9). Therefore, it would have been obvious to a POSITA, before the effective filing date of the claimed invention, to implement compressed data read operations with decompression based on stored compression information by combining Burman’s teaching with Lee’s.
Claim 20: Berman and Lee teach the storage device of claim 19, but fail to teach that the memory controller is configured to: perform an error detection operation on the decompressed data based on the error detection data stored in the map data; and externally provide the decompressed data depending on a result of the error detection operation. However, Berman teaches performing error detection on data (e.g., [0086], [0098]). Furthermore, Lee teaches providing decompressed data to a host (e.g., claim 9). Therefore, a POSITA would have found it obvious to combine error detection with decompressed data provision, conditioning the latter on successful error detection. This is a standard data integrity practice that would naturally arise from combining Berman's error detection teachings with Lee's decompression and data provision.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GUERRIER MERANT whose telephone number is (571)270-1066. The examiner can normally be reached Monday-Friday 8:00 Am - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mark Featherstone can be reached at 571-270-3750. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GUERRIER MERANT/Primary Examiner, Art Unit 2111 3/2/2026