The present application, filed on or after March 16, 2013, is being examined under first to invent provisions of the AIA .
DETAILED ACTION
This Action is in response to communications filed 4/30/2025.
Claims 2, 3, 5, 6, 8, 9, 11, 12, 14, 15, 17 and 18 are cancelled.
Claims 1, 4, 7, 10, 13 and 16 are pending.
Claims 1, 4, 7, 10, 13 and 16 are rejected.
Response to Arguments
Applicant`s arguments filed January 7, 2026 have been fully considered and they are persuasive with respect to prior art rejection.
As per the 103 rejection of claims 1, 7 and 13, Applicant argued Adler/Gopal fails to disclose or suggest the feature of " transferring the compressed data from the controller memory buffer to a decompressor device by initiating a direct memory access (DMA) transaction by the decompressor to transfer the compressed data from the address of the controller memory buffer directly to the decompressor device"; where Applicant argued that Gopal describes using a DMA circuit to "transfer the decompressed data to the memory using the specified destination address of the available location"; "in response to receiving the second descriptor, writing the decompressed data from the buffer to memory external to the accelerator circuit by the direct memory access circuit"; and "cause the decompressed data to be written from the buffer to the memory external to the accelerator circuit by the direct memory access circuit, and resume decompression of the compressed data". However, these examples describe using a DMA circuit to transfer already decompressed data to a particular destination address. By clear and direct contrast, amended independent claim 1 recites transferring the compressed data from the controller memory buffer to a decompressor device by initiating a direct memory access (DMA) transaction by the decompressor to transfer the compressed data from the address of the controller memory buffer directly to the decompressor device. As such, Applicant respectfully submits that the combination of Appu, Adler, Gopal, Kato, and/or Nelogal is not understood to teach, disclose, or suggest Applicant's claimed "transferring the compressed data from the controller memory buffer to a decompressor device by initiating a direct memory access (DMA) transaction by the decompressor to transfer the compressed data from the address of the controller memory buffer directly to the decompressor device".
However, Gopal teaches where the engine will start reading the source data from the source address (e.g., in compressed data 116) specified in the descriptor, and the DMA circuit 122 will send a stream of input data into the decompressor circuit 124; FIG. 5 illustrates an example format of a descriptor 500 including a source address according to embodiments of the disclosure. In certain embodiments, operation code 502 (e.g., JOB1) is a value that indicates an (e.g., decompression or compression) operation where a first descriptor 500 (of a pair of descriptors) identifies the source address but does not have a destination address specified (e.g., destination field 504 is ignored or not present), and instead of the DMA circuit 122 taking the output stream from the decompressor circuit 124 and writing it out to memory 108 (e.g., as uncompressed data 114) in response to this descriptor 500, the accelerator circuit (e.g., decompressor circuit 124) that is decompressing that data is to instead store it internally (e.g., within buffer 306 as shown in FIG. 3). In the second mode (e.g., as indicated by a second descriptor 302 having its destination address specified and corresponding to the first descriptor which did not have its destination address specified), the DMA circuit 122 will then output the stream from the internal storage (e.g., buffer 306 as shown in FIG. 3) of decompressor circuit 124 and write it out to memory 108 (e.g., as uncompressed data 114) in response to the second descriptor (Paragraphs 0065-0067).
Further, Gopal teaches, at operation 704, direct memory access circuit of the accelerator is setup for reading an input stream of compressed data. The operations 700 further include, at 706, decompressor circuit (e.g., pipeline) is setup to suppress generating an output stream of decompressed data. The operations 700 further include, at 708, decompression operation proceeds consuming the input stream of compressed data and generating decompressed data (for example, a maximum of a page size, e.g., 4 KB) which is written to the local history buffer memory in the decompressor circuit (paragraph 0070); the local shared memory (e.g., local memory 148 in FIG. 1) is used to temporarily store the entire compression and/or decompression results for several jobs. For example, for a large local memory shared across all pipelines in the instance. These regions can be addressed by descriptors using a special flag (e.g., not DRAM/system memory, but a region in local device). In certain embodiments, a first descriptor causes an accelerator circuit to write compression and/or decompression output to the local memory 148, and a second descriptor moves data from the local memory 148 to the destination address, for example, in LLC of core(s) (e.g., LLC as cache 212 in FIG. 2) for decompression or DRAM (e.g., Double Data Rate Synchronous Dynamic Random-Access Memory (DDR SDRAM))) for compression (Paragraphs 0083-0084) where the DMA sending the stream of compressed input data in different modes utilizing the addresses provided for decompression to correspond to the claimed limitations of transferring the compressed data from the controller memory buffer to a decompressor device by initiating a direct memory access (DMA).
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 of this title, 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.
Claims 1, 7 and 13 are rejected under 35 U.S.C. 103(a) as being disclosed by Appu et al. (US PGPUB 2021/0142438 hereinafter referred to as Appu), in view of Adler (US 8,407,407 hereinafter referred to as Adler), in view of Gopal (US PGPUB 2022/0206975 hereinafter referred to as Gopal), and further in view of Kato et al. (US PGPUB 2009/0259789 hereinafter referred to as Kato).
As per independent claim 1, Appu discloses a computer-implemented method, executed on a computing device, comprising: transferring compressed data from a flash memory [(Paragraphs 0035, 0188; FIGs. 1 and 14 and related text) wherein Appu teaches where the memory device 120 can be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as process memory; FIG. 14 depicts a block diagram of a memory and reorder buffer (ROB) system. ROB system 1400 receives compressed data from memory 1450, stores the data, and provides data in-order to decompressor 1420. In some examples, in response to a read request, compressed data are sent from memory 1450 in multiple segments or entries and the compressed data are stored in data buffer 1410 prior to being sent or copied in-order to decompressor 1420 to correspond to the claimed limitation].
Appu does not appear to explicitly disclose transferring data from a flash memory of a solid state drive (SSD) storage device internally within the SSD storage device to a controller memory buffer on the SSD storage device.
However, Adler discloses transferring data from a flash memory of a solid state drive (SSD) storage device internally within the SSD storage device to a controller memory buffer on the SSD storage device [(Column 4, lines 66-67 and Column 5, lines 1-20; FIGs. 1 and 12) where Adler teaches where data is read from the flash memory 26, is transferred to the data buffer 28, and is then transferred to the host 12 via the interfaces 18, 20. The data buffer 28 may be distinct from the drive control module 22 and the flash memory 26 and may be used as a temporary storage device. The data buffer 28 may be, for example, volatile memory, such as random access memory (RAM) to correspond to the claimed limitation].
Appu and Adler are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Appu and Adler before him or her, to modify the method of Appu to include of Adler because it will enhance apparatus efficiency.
The motivation for doing so would be [“provides systems and methods to improve access efficiency for random and/or "bursty accesses"” (Column 4, lines 10-12 by Adler)].
Appu does not appear to explicitly disclose transferring compressed data from a flash memory …. to an address within a controller memory buffer; transferring the compressed data ….. by initiating a direct memory access (DMA) transaction by the decompressor to transfer the compressed data from the address of the controller memory buffer directly to the decompressor device.
However, Gopal discloses transferring compressed data from a flash memory …. to an address within a controller memory buffer; transferring the compressed data [(Paragraphs 0049, 0070, 0077, 0084 and 0103; FIGs. 1 and 10) where Gopal teaches where write compression and/or decompression output to the local memory 148, and a second descriptor moves data from the local memory 148 to the destination address, for example, in LLC of core(s) (e.g., LLC as cache 212 in FIG. 2) for decompression or DRAM (e.g., Double Data Rate Synchronous Dynamic Random-Access Memory (DDR SDRAM))) for compression. Thus, in certain embodiments, the compressor and/or decompressor circuits would (e.g., only) be blocked when the local memory 148 is full. For example, where the OS could throw away compression results that are too big (e.g., without using any bandwidth to write the data to DRAM) by sending a second descriptor to drop a job's data from the local memory 148. In certain embodiments, there is an operation to allocate/free memory regions in this device memory, but freeing of buffers can also implicitly happen with certain operations that read out the results to correspond to the claimed limitation] ….. by initiating a direct memory access (DMA) transaction by the decompressor to transfer the compressed data from the address of the controller memory buffer directly to the decompressor device [(Paragraphs 0049, 0070, 0077, 0092 and 0103; FIGs. 1 and 10) where Gopal teaches where the engine will start reading the source data from the source address (e.g., in compressed data 116) specified in the descriptor, and the DMA circuit 122 will send a stream of input data into the decompressor circuit 124; FIG. 5 illustrates an example format of a descriptor 500 including a source address according to embodiments of the disclosure. In certain embodiments, operation code 502 (e.g., JOB1) is a value that indicates an (e.g., decompression or compression) operation where a first descriptor 500 (of a pair of descriptors) identifies the source address but does not have a destination address specified (e.g., destination field 504 is ignored or not present), and instead of the DMA circuit 122 taking the output stream from the decompressor circuit 124 and writing it out to memory 108 (e.g., as uncompressed data 114) in response to this descriptor 500, the accelerator circuit (e.g., decompressor circuit 124) that is decompressing that data is to instead store it internally (e.g., within buffer 306 as shown in FIG. 3). In the second mode (e.g., as indicated by a second descriptor 302 having its destination address specified and corresponding to the first descriptor which did not have its destination address specified), the DMA circuit 122 will then output the stream from the internal storage (e.g., buffer 306 as shown in FIG. 3) of decompressor circuit 124 and write it out to memory 108 (e.g., as uncompressed data 114) in response to the second descriptor (Paragraphs 0065-0067); where FIG. 10 is a flow diagram illustrating operations 1000 of a method of decompression according to embodiments of the disclosure. Some or all of the operations 1000 (or other processes described herein, or variations, and/or combinations thereof) are performed under the control of a computer system (e.g., an accelerator thereof). The operations 1000 include, at block 1002, sending, by a hardware processor core of a system, a first descriptor to an accelerator circuit coupled to the hardware processor core and having a decompressor circuit and a direct memory access circuit. The operations 1000 further include, at block 1004, in response to receiving the first descriptor, decompressing compressed data from the direct memory access circuit into decompressed data by the decompressor circuit and storing the decompressed data in a buffer in the accelerator circuit. The operations 1000 include, at block 1006, sending, by the hardware processor core of the system, a second descriptor to the accelerator circuit separately from the first descriptor. The operations 1000 include, at block 1008, in response to receiving the second descriptor, writing the decompressed data from the buffer to memory external to the accelerator circuit by the direct memory access circuit to correspond to the claimed limitation].
Appu and Gopal are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Appu and Gopal before him or her, to modify the method of Appu to include of Gopal because it will enhance latency.
The motivation for doing so would be [“allow the implementation of the lowest latency decompression solution possible” (Paragraph 0049 by Gopal)].
Appu further discloses transferring the compressed data from the controller memory buffer to a decompressor device [(Paragraphs 0035 and 0188-0195; FIGs. 1 and 14 and related text) wherein Appu teaches where the memory device 120 can be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as process memory; FIG. 14 depicts a block diagram of a memory and reorder buffer (ROB) system. ROB system 1400 receives compressed data from memory 1450, stores the data, and provides data in-order to decompressor 1420. In some examples, in response to a read request, compressed data are sent from memory 1450 in multiple segments or entries and the compressed data are stored in data buffer 1410 prior to being sent or copied in-order to decompressor 1420, where Appu further teaches a lossy or lossless decompression unit (e.g., decompressor 1420) can launch read requests to memory 1450. A read request can cause a read of one or more entries from memory 1450 for storage to data buffer 1410. Data buffer 1410 can be implemented using a dynamic random access memory (DRAM) or other RAM. Data can be received from memory 1450 in a compressed format. Compressed data segments or entries from memory 1450 can be received at data buffer 1410 out-of-order but decompressor 1420 decodes data in-order. For example, if a data request is for 256 bytes of data that are compressed to 128 bytes but merely 64 bytes are transferred or copied using a memory interface to data buffer 1410 in a clock cycle, then two 64 byte segments are transferred to data buffer 1410 over two clock cycles. ROB system 1400 ensures that allocation order is maintained such that ROB system 1400 copies data to decompressor 1420 in the order of allocation so that decompressor 1420 can decode data in order. Data read from memory 1450 may need to be reordered because data is provided from memory 1450 out-of-order (even if data is read from the same page) to correspond to the claimed limitation]; decompressing the compressed data by the decompressor device to produce uncompressed data [(Paragraphs 0035 and 0188-0195; FIGs. 1 and 14 and related text) wherein Appu teaches where the memory device 120 can be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as process memory; FIG. 14 depicts a block diagram of a memory and reorder buffer (ROB) system. ROB system 1400 receives compressed data from memory 1450, stores the data, and provides data in-order to decompressor 1420. In some examples, in response to a read request, compressed data are sent from memory 1450 in multiple segments or entries and the compressed data are stored in data buffer 1410 prior to being sent or copied in-order to decompressor 1420, where Appu further teaches a lossy or lossless decompression unit (e.g., decompressor 1420) can launch read requests to memory 1450. A read request can cause a read of one or more entries from memory 1450 for storage to data buffer 1410. Data buffer 1410 can be implemented using a dynamic random access memory (DRAM) or other RAM. Data can be received from memory 1450 in a compressed format. Compressed data segments or entries from memory 1450 can be received at data buffer 1410 out-of-order but decompressor 1420 decodes data in-order. For example, if a data request is for 256 bytes of data that are compressed to 128 bytes but merely 64 bytes are transferred or copied using a memory interface to data buffer 1410 in a clock cycle, then two 64 byte segments are transferred to data buffer 1410 over two clock cycles. ROB system 1400 ensures that allocation order is maintained such that ROB system 1400 copies data to decompressor 1420 in the order of allocation so that decompressor 1420 can decode data in order. Data read from memory 1450 may need to be reordered because data is provided from memory 1450 out-of-order (even if data is read from the same page) to correspond to the claimed limitation]; storing the uncompressed data in a main memory of a CPU [(Paragraphs 0191-0199 and 0226; FIGs. 1 and 14 and related text) wherein Appu teaches where Decompressor 1420 can receive control information and entries from data buffer using an interface such as a bus or other interconnect. Decompressor 1420 can use buffer 1414 to store one or more entries. Buffer 1414 can be 256B in size (or other sizes) and be implemented as part of a memory or cache. Decompressor 1420 can start decompression when all entry data is available in-order or when decompressor 1420 receives a head of line data entry in a sequence of one or more data entries. Decompressor 1420 can use a cache (e.g., level-1, level-2, level-3, or last level cache) (not depicted) to store data from data buffer 1410. Decompressor 1420 can perform any type of lossy or lossless decompression scheme including decompression of any of graphics interchange format (GIF), joint photographic experts group (JPEG), Quicktime, or portable network graphic (PNG) to correspond to the claimed limitation]; and transferring the uncompressed data to from the main memory to a requestor of the data [(Paragraphs 0191-0199 and 0226; FIGs. 1 and 14 and related text) wherein Appu teaches where Decompressor 1420 can receive control information and entries from data buffer using an interface such as a bus or other interconnect. Decompressor 1420 can use buffer 1414 to store one or more entries. Buffer 1414 can be 256B in size (or other sizes) and be implemented as part of a memory or cache. Decompressor 1420 can start decompression when all entry data is available in-order or when decompressor 1420 receives a head of line data entry in a sequence of one or more data entries. Decompressor 1420 can use a cache (e.g., level-1, level-2, level-3, or last level cache) (not depicted) to store data from data buffer 1410. Decompressor 1420 can perform any type of lossy or lossless decompression scheme including decompression of any of graphics interchange format (GIF), joint photographic experts group (JPEG), Quicktime, or portable network graphic (PNG) to correspond to the claimed limitation].
Appu does not appear to explicitly disclose transferring the uncompressed data from the main memory to a requestor of the data.
However, Kato discloses transferring the uncompressed data from the main memory to a requestor of the data [(Paragraphs 0012, 0018 and 0203; FIGs. 1 and 12) where Kato teaches where the compressed blocks #0 and #2 are decompressed during DMA transfer, and the decompressed data is stored in the main RAM 25. On the other hand, the non-compressed block #1 is transferred as it is, and the raw data is stored in the main RAM 25. As has been discussed above, it is possible to DMA transfer compressed and non-compressed blocks together in response to one DMA transfer request to correspond to the claimed limitation].
Appu and Kato are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Appu and Kato before him or her, to modify the method of Appu to include of Kato because it will enhance apparatus efficiency.
The motivation for doing so would be [“effectively access an external memory. In addition, it is another object of the present invention to provide a multiprocessor and the related arts in which it is possible to simplify the circuit configuration for accessing an external memory and thereby reduce the cost. Furthermore, it is a further object of the present invention to provide a multiprocessor and the related arts in which it is possible to prevent wasting the bus bandwidth of the internal memory while controlling the processor cores” (Paragraphs 0008-0010 by Kato)].
Therefore, it would have been obvious to combine Appu and Gopal to obtain the invention as specified in the instant claim.
As for independent claims 7 and 13, the applicant is directed to the rejections to claim 1 set forth above, as they are rejected based on the same rationale.
Claims 4, 10 and 16 are rejected under 35 U.S.C. 103(a) as being disclosed by Appu, Adler, Gopal and Kato, as applied to claims 1, 7 and 13, and further in view of Nelogal et al. (US PGPUB 2017/0132169 hereinafter referred to as Nelogal).
As per dependent claim 4, Appu /Kato discloses the method of claim 1.
Appu /Kato does not appear to explicitly disclose performing a CRC check on the uncompressed data stored in the main memory prior to the uncompressed data being transferred to the requestor of the data.
However, Nelogal discloses performing a CRC check on the uncompressed data stored in the main memory prior to the uncompressed data being transferred to the requestor of the data [(Paragraph 0067; FIGs. 1 and 4) where the decompression engine 402 determines if the decompression was valid (block 716). For example, after decompression of the packet 104, the decompression engine 402 checks the cyclic redundancy check (CRC) which detects errors that occur during retrieval of the packet. The decompression engine 402 may not decompress the packet successfully due too much data being lost, unrecognizable compression technique used, etc. If the decompression engine 402 determines the packet 104 is not validly decompressed, then it will notify the example destination modifier 404 to send a NACK (block 726) to inform the example source modifier 214 (FIG. 2) to select the next compression type or send the new packet 201 as uncompressed. If the packet 104 is successfully decompressed, the example destination modifier 404 will send an ACK (block 718). For example, the destination modifier 404 may be notified by the decompression engine 402 that decompression was completed and inform the source modifier 214 to correspond to the claimed limitation].
Appu /Kato and Nolan are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Appu /Kato and Nolan before him or her, to modify the apparatus of Ambikapathy /Jeong to include the CRC checking of Nolan because it will enhance accuracy.
The motivation for doing so would be [“improve the efficiency of using a computing device by increasing network bandwidth” (Paragraph 0089 by Nolan)].
Therefore, it would have been obvious to combine Appu /Kato and Nolan to obtain the invention as specified in the instant claim.
As for claims 10 and 16, the applicant is directed to the rejections to claim 8 set forth above, as they are rejected based on the same rationale.
Conclusion
THIS ACTION IS MADE FINAL. 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMED M GEBRILohamed Gebril whose telephone number is (571)270-1857 and email address is mohamed.gebril @uspto.gov. The examiner can normally be reached on Monday-Friday 9-5 ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jared Rutz can be reached on 571-272-5535. The fax phone number for the organization where this application or proceeding is assigned is 571-270-2857.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHAMED M GEBRIL/Primary Examiner, Art Unit 2135
Prosecution Insights