DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to amendment filed on 3/17/2026.
Claims 1 and 8 have been amended.
Claims 14-20 have been cancelled.
New claims 21-27 have been added and examined.
The objections and rejections from the prior correspondence that are not restated herein are withdrawn.
Claim Rejections - 35 USC § 103
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-3, 7-9, and 21-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bjorling et al. (US 2022/0050599) and Kesiraju et al. (US 11,500,638).
With respect to claim 1, Bjorling teaches of a memory buffer device comprising: a host-side interface to receive a request from a host device to compress a selected page into a compressed page (fig. 1, 8; item 114; paragraph 30-32, 35, 68; where the interface of the data storage device exchanges data and commands from the host including the write data command to compress and write the compressed data to the non-volatile memory. Data is accessed in the memory at the page level), and
to send at least a subset of compression context metadata to the host device that enables the host device to subsequently obtain data from the compressed page (fig. 1, 8; paragraph 30-32, 70 where the controller reports the information concerning the compression to the host via the interface. This information includes the location (LBA) of the compressed data);
a memory-side interface to communicate with the memory array (fig. 1, items 108, 116; paragraphs 31, 33, 38; where the controller communicates with the non-volatile memory via the buffer); and
a compression controller to determine an address in the memory array for storing the compressed page in association with the request (fig. 1, 8; paragraph 6, 38, 68-70; the controller maintains the pointers for each zone indicating the location the compressed data is to be written within the zone, i.e. the address),
to perform compression of the selected page (fig. 1, 8; paragraph 38, 68-70; the controller includes a compression engine that compresses the data),
to issue a write operation via the memory-side interface to write the compressed page to the address in the memory array (fig. 1, 8; paragraph 6, 38, 68-70; the controller temporarily stores the compressed data in the write buffer before sending it to the NVM to be stored at the address), and
to generate the compression context metadata (fig. 7-8; paragraph 67, 70; where the controller returns to the host the location information (LBA) of the compressed data which was determined by the controller).
Bjorling fails to explicitly teach of (1) the selected page stored to a memory array; (2) a compression controller to issue a read operation via the memory-side interface to read the selected page from the memory array in response to the request.
However, Kesiraju teaches of to receive a request to compress a selected page stored to a memory array into a compressed page (fig. 10; column 12, lines 16-27; where an instruction that is a compression instruction is received);
a compression controller to issue a read operation via the memory-side interface to read the selected page from the memory array in response to the request (fig. 10; column 12, lines 22-37; where if the instruction is a compression instruction, a prefetch of the page of data is initiated. In the combination with Bjorling, the page of data is retrieved from Bjorling’s NVM),
to issue a write operation via the memory-side interface to write the compressed page to the address in the memory array (fig. 10; column 12, lines 38-49; where the results of the compression operation are stored in a write buffer and are then stored into the target location).
Bjorling and Kesiraju are analogous art because they are from the same field of endeavor, as they are directed to data compression management.
It would have been obvious to one of ordinary skill in the art having the teachings of Bjorling and Kesiraju before the time of the effective filing of the claimed invention to incorporate the compression of data already stored in Bjorling as taught in Kesiraju. Their motivation would have been to increase the flexibility of the system.
With respect to claim 21, the combination of Bjorling and Kesiraju teaches of the limitations cited and described above with respect to claim 1 for the same reasoning as recited with respect to claim 1.
Bjorling also teaches of a memory module comprising a memory array; a memory buffer device (fig. 1; paragraph 29, 38; non-volatile memory, 110 and the controller is analogous to a memory buffer device as it stores data associated with commands in its internal memory, i.e. a buffer).
With respect to claims 2 and 22, Bjorling teaches of wherein the host-side interface further receives a request from the host device referencing the compressed page (fig. 1, 9; paragraph 30-32, 71; where a read command is received via the interface for the compressed data), and
wherein the compression controller is further configured to facilitate access to the data from the compressed page responsive to the request (fig. 1, 9; paragraph 30-32, 71-72; where the controller determines the location of the compressed data via the LBA and reads the compressed data).
With respect to claim 3 and 23, Bjorling teaches of wherein the compression controller decompresses the compressed page based on the compression context metadata to generate a decompressed page (fig. 9; paragraph 71-72; where the controller determines the location of the compressed data via the LBA (claimed compression context metadata), reads the compressed data, and decompresses the compressed data), and
enables the host device to access the decompressed page via the host-side interface (fig. 1, 9; paragraph 30, 32, 72; the controller delivers the decompressed data to the host via the interface).
With respect to claims 7 and 27, Bjorling teaches of wherein the memory buffer device is integrated in a serial-attached memory module and wherein the host-side interface comprises a serial communication link (fig. 1; paragraph 32; where the interface 114 is a serial-ATA interface or a serially attached SCSI interface. Thus, the data storage device is a serial-attached memory module).
With respect to claim 8, Bjorling teaches of a method for managing a compression and decompression of data in a memory array, the method comprising: receiving, at a host-side interface of a memory buffer device, a request from a host device to compress a selected page into a compressed page (fig. 1, 8; item 110, 112, 114, 116; paragraph 29-32, 35, 68; where the interface of the data storage device exchanges data and commands from the host including the write data command to compress and write the compressed data to the non-volatile memory. As there are a plurality of storage devices that can operate as a storage array in the data storage device, the volatile memory, buffer, and non-volatile memory from the data storage device make up the claimed memory array);
determining, by the memory buffer device, an address in the memory array for storing the compressed page (fig. 1, 8; paragraph 6, 38, 68-70; the controller maintains the pointers for each zone indicating the location the compressed data is to be written within the zone, i.e. the address);
performing, by the memory buffer device, compression of the selected page (fig. 1, 8; paragraph 38, 68-70; the controller includes a compression engine that compresses the data);
facilitating, by the memory buffer device, a write operation to store the compressed page to the address in the memory array (fig. 1, 8; paragraph 6, 38, 68-70; the controller temporarily stores the compressed data in the write buffer before sending it to the NVM to be stored at the address);
generating, by the memory buffer device, compression context metadata that enables the host device to subsequently obtain data from the compressed page (fig. 7-8; paragraph 67, 70; where the controller returns to the host the location information (LBA) of the compressed data which was determined by the controller); and
sending at least a subset of the compression context metadata to the host device via the host-side interface of the memory buffer device (fig. 1, 8; paragraph 30-32, 70 where the controller reports the information concerning the compression to the host via the interface. This information includes the location (LBA) of the compressed data).
Kesiraju teaches of to compress the selected page stored to a memory array of a memory device into a compressed page (fig. 10; column 12, lines 16-27; where an instruction that is a compression instruction is received);
performing a read operation to read the selected page from the memory array (fig. 10; column 12, lines 22-37; where if the instruction is a compression instruction, a prefetch of the page of data is initiated. In the combination with Bjorling, the page of data is retrieved from Bjorling’s NVM);
facilitating, by the memory buffer device, a write operation to store the compressed page to the address in the memory array (fig. 10; column 12, lines 38-49; where the results of the compression operation are stored in a write buffer and are then stored into the target location).
The reasons for obviousness are the same as indicated above with respect to claim 1.
With respect to claim 9, Bjorling teaches of the limitations cited and described above with respect to claims 2-3 for the same reasoning as recited with respect to claims 2-3.
Bjorling also teaches of receiving, at the host-side interface of the memory buffer device, a request from the host device to decompress the compressed page (fig. 1, 9; paragraph 30-32, 71-72; where a read command is received via the interface for the compressed data which results in the compressed data being decompressed).
Claim(s) 4, 10, and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bjorling and Kesiraju as applied to claims 2, 8, and 22 above and in further view of Nakanishi et al. (US 2022/0171724).
With respect to claims 4 and 24, Bjorling teaches of wherein the compression controller is further configured to receive a memory access from the host device for compressed data of the compressed page (fig. 1, 9; paragraph 30-32, 71-72; where a read command is received via the interface for the compressed data).
The combination of Bjorling and Kesiraju fails to explicitly teach of to send the compressed data to the host device via the host-side interface responsive to the memory access.
However, Nakanishi teaches of to receive a memory access from the host device for compressed data of the compressed page and to send the compressed data to the host device via the host-side interface responsive to the memory access (paragraph 56-59; where a read command for the compressed data is issued by the host, the compressed data is read from the NAND flash memory based on the command and when the frequency of read commands are high, the decoding/decompression is performed on the host side, thus the compressed data is sent to the host device via Bjorling’s interface).
Bjorling, Kesiraju, and Nakanishi are analogous art because they are from the same field of endeavor, as they are directed to data compression management.
It would have been obvious to one of ordinary skill in the art having the teachings of Bjorling, Kesiraju, and Nakanishi before the time of the effective filing of the claimed invention to incorporate the performing decompression in the host of the combination of Bjorling and Kesiraju as taught in Nakanishi. Their motivation would have been to increase the flexibility of the system to handle adverse load situations (Nakanishi, paragraph 58).
With respect to claim 10, the combination of Bjorling, Kesiraju, and Nakanishi teaches of the limitations cited and described above with respect to claim 4 for the same reasoning as recited with respect to claim 4.
Claim(s) 5-6, 11-13, and 25-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bjorling and Kesiraju as applied to claims 1, 8, and 21 above and in further view of Iyer et al. (US 2019/0138446).
With respect to claims 5 and 25, Bjorling teaches of wherein the compression context metadata includes a pointer to the compressed page (fig. 7-8; paragraph 67, 70; where the controller returns to the host the location information (LBA) of the compressed data which was determined by the controller) and
wherein the compression controller sends the pointer to the host device via the host-side interface (fig. 7-8; paragraph 67, 70; where the controller returns to the host the location information (LBA) of the compressed data which was determined by the controller).
The combination of Bjorling and Kesiraju fails to explicitly teach of the compression context metadata includes one or more decompression parameters, and wherein the compression controller stores the one or more decompression parameters in uncompressed form at a physical address of the memory array associated with the compressed page.
However, Iyer teaches of the compression context metadata includes one or more decompression parameters (fig. 5; paragraph 48, 50; the compression metadata includes the compression algorithm and version id), and
wherein the compression controller stores the one or more decompression parameters in uncompressed form at a physical address of the memory array associated with the compressed page (fig. 5; paragraph 38, 43, 48, 50; where the compressed page includes the compression data stored in an uncompressed format. The compressed page including the compression metadata is stored at the physical page address for the page).
Bjorling, Kesiraju, and Iyer are analogous art because they are from the same field of endeavor, as they are directed to data compression management.
It would have been obvious to one of ordinary skill in the art having the teachings of Bjorling, Kesiraju, and Iyer before the time of the effective filing of the claimed invention to incorporate the compression metadata management of Iyer into the combination of Bjorling and Kesiraju. Their motivation would have been to efficiently track how the data is compressed.
With respect to claim 11, the combination of Bjorling, Kesiraju, and Iyer teaches of the limitations cited and described above with respect to claim 5 for the same reasoning as recited with respect to claim 5.
With respect to claims 6 and 26, Bjorling teaches of wherein the host-side interface further receives a request from the host device to decompress the compressed page (fig. 1, 9; paragraph 30-32, 71-72; where a read command is received via the interface for the compressed data and the data is decompressed),
wherein the request includes the pointer to the compressed page (paragraph 71; where the host LBA of the data to be read is included in the command).
Iyer teaches of wherein the compression controller is further configured to retrieve the one or more decompression parameters in response to the request (paragraph 48, 63-64; where the compression algorithm and compression algorithm version from the compression metadata are used to decompress the data).
The reasoning for obviousness is the same as indicated above with respect to claim 5.
With respect to claim 12, Bjorling teaches of receiving, at the host-side interface, a request from the host device to access the compressed page, the request including the pointer to the compressed page (fig. 1, 9; paragraph 30-32, 71-72; where a read command is received via the interface for the compressed data. The command includes the host LBA of the data and the data is decompressed).
Iyer teaches of retrieving the one or more decompression parameters in response to the request (paragraph 48, 63-64; where the compression algorithm and compression algorithm version from the compression metadata are used to decompress the data).
The combination of Bjorling, Kesiraju, and Iyer decompressing the page to a physical address of the memory array based on the decompression parameters (Bjorling, paragraph 37; Iyer, paragraph 64; where the decompressed data is stored into the data cache before being sent to the requesting entity. In the combination with Bjorling, it is stored to the buffer, then the volatile cache memory before being sent to the host).
The reasoning for obviousness is the same as indicated above with respect to claim 5.
With respect to claim 13, Bjorling teaches of the limitations cited and described above with respect to claim 7 for the same reasoning as recited with respect to claim 7.
Response to Arguments
Applicant's arguments with respect to independent claims 1, 8, and 21 have been considered but are moot because of the new reference(s) being applied, in light of the amendment, to the particular limitations the arguments are referencing. Thereby the arguments no longer apply to the rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sazegari et al. (US 2019/0034333) discloses in response to a compression operation, fetching source page data into a source buffer, compressing the data into compressed data packets and storing the compressed packets into a write buffer before they are stored to the target location.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL C KROFCHECK whose telephone number is (571)272-8193. The examiner can normally be reached on Monday - Friday 8am -5pm, first Friday off.
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, Tim Vo can be reached on (571) 272-3642. 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.
/Michael Krofcheck/Primary Examiner, Art Unit 2138
Prosecution Insights