DETAILED ACTION
1. This Office Action is taken in response to Applicants’ Amendments and Remarks filed on 5/26/2026 regarding application 18/999,689 filed on 12/23/2024.
Claims 1-20 are pending for consideration.
2. Response to Remarks
Applicants’ amendments and remarks have been fully and carefully considered, with the Examiner’s response set forth below.
(1) Applicant contends that, regarding claim 1, Leung fails to teach the limitation “identifying a class size based on the size of the compressed data.” The Examiner disagrees.
First, the limitation merely recites “a class size,” and is otherwise completely silent on the scope and definition of the term “class size.” As such, the term “class size” must be given the broadest, reasonable interpretation according to the guidelines set forth by the MPEP. Thus, within the context of the limitations recited in claim 1 and as far as claim 1 is concerned, “any size of memory area that is able to accommodate the size of the compressed data” qualifies as a “class size.”
Second, figure 1 of Leung shows that the bounce buffer (126) comprises a plurality of units with size of 1K bytes. Further, Leung teaches accommodating and storing the compressed data using these 1KB unites as a basis [Bounce buffer 126 can be allocated in memory 120 as a pool of multiple subregions. For example, a subregion can be 1 KB in size, and multiple subregions can be allocated to DMA circuitry 102 to store data before and after compression of data ... (¶ 0019); ... Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction ... Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data ... (¶ 0009)].
Therefore, Leung clearly teaches “identifying a class size based on the size of the compressed data” as recited in claim 1.
(2) Applicant also contends that, regarding claim 1, Leung fails to teach the limitation “identifying an unused memory pointer for a first memory slab based on the class size, wherein the first memory slab is pre-allocated,” because “Leung relies on post-compression dynamic deallocation rather than a pre-allocated memory slab architecture, it does not anticipate the present claims” (see pages 6-7 of Applicant’s Remarks). The Examiner disagrees.
First, the limitation merely recites “a first memory slab is pre-allocated,” and “store the compressed data in the first memory slab.” The limitation does not recite anything as to what may happen to the memory space after the compressed data is stored in the first memory slab. Thus, any operations performed to the memory space afterwards would be acceptable, including deallocation of unused memory space.
Second, Leung specification teaches that the bounce buffer includes a plurality of per-allocated 1K Bytes units which are used to accommodate an stored the compressed data [as shown in figure 1, where the bounce buffer (126) comprises a plurality of units with size of 1K bytes; Bounce buffer 126 can be allocated in memory 120 as a pool of multiple subregions. For example, a subregion can be 1 KB in size, and multiple subregions can be allocated to DMA circuitry 102 to store data before and after compression of data ... (¶ 0019); ... Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction ... Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data ... (¶ 0009); ... At 202, a DMA circuitry could request and receive, from an operating system (OS), allocation of multiple pointers to a subset of a bounce buffer. For example, 4 pointers to different 1 KB (or 512B or other sizes) regions can be allocated. In some examples, an NVMe command (nCMD) is allocated 4 KB in a bounce buffer. However, other sizes of bounce buffer can be allocated. At 202, DMA engine can transfer data from a host to a staging buffer prior to storage in the allocated bounce buffer (¶ 0030); At 304, the compressed data can be stored into a bounce buffer. In some examples, a network protocol engine that processes received commands could request allocation of a bounce buffer. An operating system (OS) can allocate the bounce buffer as multiple subregions ... (¶ 0034)].
Third, regarding the “deallocation” that Applicant cited, it is noted that Leung teaches the deallocation may occur only if the allocated regions in the bounce buffer is unused after storing the compressed data, hence is totally irrelevant to the fact the the bounce buffer is allocated before storing the compressed data [... where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions ... (¶ 0019)].
Therefore, Leung clearly teaches that the memory space of the bounce buffer is allocated before storing the compressed data, hence pre-allocated.
(2) In response to the amendments and remarks, an updated claim analysis has been made with additional, new reference(s). Refer to the corresponding sections of the following Office Action for details.
3. Examiner’s Note
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
(2) Examiner has cited particular columns/paragraph and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
4. Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Leung et al. (US Patent Application Publication 2024/0329873, hereinafter Leung).
As to claim 1, Leung teaches A method performed by a memory footprint compression system of a computing device for writing compressed data to memory [computer device as shown in figures 1,4, and 6; Examples described herein relate to a device that includes: a host interface; and circuitry to: based on allocation of a region in a buffer, wherein the buffer is associated with Non-volatile Memory Express over Fabrics (NVMe-oF) transactions: based on a first size of compressed data to be stored in the buffer, deallocate a portion of the region in the buffer and store the compressed data of the first size into a second portion of the region in the buffer and based on a second size of the compressed data to be stored in the buffer, utilize the allocated region in the buffer to store the compressed data of the second size (abstract)], comprising:
receiving a size of compressed data stored in at least one output buffer [For example, one or more of compressors/decompressors 114 can perform lossless or lossy compression of data stored in staging buffer 124 prior to storage in bounce buffer 126 … One or more of compressors/decompressors 114 can store compressed data into staging buffer 124 and then copy compressed data from staging buffer 124 into bounce buffer 126 until full and then block further copies to bounce buffer 126. Map 128 can indicate a storage location in bounce buffer 126, size of the data, and compression technology applied. Based on a read of data from bounce buffer 126, one or more of compressors/decompressors 114 can retrieve compressed data and decompress the compressed data based on map 128 (¶ 0016-0017)];
identifying a class size based on the size of the compressed data [the limitation merely recites “a class size,” and is otherwise completely silent on the scope and definition of the term “class size.” As such, the term “class size” must be given the broadest, reasonable interpretation according to the guidelines set forth by the MPEP. Thus, within the context of the limitations recited in claim 1 and as far as claim 1 is concerned, “any size of memory area that is able to accommodate the size of the compressed data” qualifies as a “class size.” For example, the corresponding “class size” may be the “size of an allocated region used to accommodate and store the compressed data” –
Various examples provide for allocation of a region in a bounce buffer at least for data to be written as part of an NVMe-oF write transaction or data to be read as part of an NVMe-oF read transaction. Prior to storage of the data into the bounce buffer, the data can be compressed using one or more compression technologies. Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction. The bounce buffer can be allocated using multiple pointers, where a pointer refers to a subregion (e.g., a strict subset of the bounce buffer). Deallocation of the portion of the region can include identifying a pointer to a strict subset of the bounce buffer for reallocation to another write or read transaction. Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data. Some examples can allocate a size of a bounce buffer for transactions that utilize one or more of: a network interface device, an accelerator, or a storage controller (¶ 0009); Bounce buffer 126 can be allocated in memory 120 as a pool of multiple subregions. For example, a subregion can be 1 KB in size, and multiple subregions can be allocated to DMA circuitry 102 to store data before and after compression of data. However, other sizes of subregions can be used. Based on compression of data, a size of data stored in bounce buffer 126 may shrink and based on configuration 122, where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions … For example, bounce buffer 126 can include four 1 KiB subregions. Where a first data of size 4 KiB is compressed by 10× to 0.4 KiB and stored in only one 1 KiB subregion, the three unused 1 KiB sub regions can be freed for other transactions. Where a second data is compressed to 3.5 KiB, all four subregions are used to store the 3.5 KiB compressed data and no sub-region can be freed in this case (¶ 0019-0020)];
identifying an unused memory pointer for a first memory slab based on the class size, wherein the first memory slab is pre-allocated [the corresponding “first memory slab” is, for example, “the bounce buffer” -- Various examples provide for allocation of a region in a bounce buffer at least for data to be written as part of an NVMe-oF write transaction or data to be read as part of an NVMe-oF read transaction. Prior to storage of the data into the bounce buffer, the data can be compressed using one or more compression technologies. Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction. The bounce buffer can be allocated using multiple pointers, where a pointer refers to a subregion (e.g., a strict subset of the bounce buffer). Deallocation of the portion of the region can include identifying a pointer to a strict subset of the bounce buffer for reallocation to another write or read transaction. Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data. Some examples can allocate a size of a bounce buffer for transactions that utilize one or more of: a network interface device, an accelerator, or a storage controller (¶ 0009); Bounce buffer 126 can be allocated in memory 120 as a pool of multiple subregions. For example, a subregion can be 1 KB in size, and multiple subregions can be allocated to DMA circuitry 102 to store data before and after compression of data. However, other sizes of subregions can be used. Based on compression of data, a size of data stored in bounce buffer 126 may shrink and based on configuration 122, where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions. For example, data can include an NVMe-oF command and/or data received in a packet or to be transmitted in a packet. Accordingly, a number of transactions that can utilize bounce buffer 126 can potentially increase where subregions of bounce buffer 126 are deallocated and available for use. A bit map or data may be used to identify subregions available for allocation. For example, bounce buffer 126 can include four 1 KiB subregions. Where a first data of size 4 KiB is compressed by 10× to 0.4 KiB and stored in only one 1 KiB subregion, the three unused 1 KiB sub regions can be freed for other transactions. Where a second data is compressed to 3.5 KiB, all four subregions are used to store the 3.5 KiB compressed data and no sub-region can be freed in this case (¶ 0019-0020)];
identifying a memory address to write the compressed data to, based on the unused memory pointer [the corresponding “memory address” is the “storage location of the bounce buffer” -- … The bounce buffer can be allocated using multiple pointers, where a pointer refers to a subregion (e.g., a strict subset of the bounce buffer). Deallocation of the portion of the region can include identifying a pointer to a strict subset of the bounce buffer for reallocation to another write or read transaction … (¶ 0009); One or more of compressors/decompressors 114 can store compressed data into staging buffer 124 and then copy compressed data from staging buffer 124 into bounce buffer 126 until full and then block further copies to bounce buffer 126. Map 128 can indicate a storage location in bounce buffer 126, size of the data, and compression technology applied. Based on a read of data from bounce buffer 126, one or more of compressors/decompressors 114 can retrieve compressed data and decompress the compressed data based on map 128 (¶ 0017)]; and
sending the memory address to a direct memory access module [DMA circuit, figure 1, 102; FIG. 2 depicts an example write operation. The write operation can include an NVMe-oF write operation. The write operation can be performed by a network interface device, an accelerator, or a storage controller. At 202, a DMA circuitry could request and receive, from an operating system (OS), allocation of multiple pointers to a subset of a bounce buffer. For example, 4 pointers to different 1 KB (or 512B or other sizes) regions can be allocated. In some examples, an NVMe command (nCMD) is allocated 4 KB in a bounce buffer. However, other sizes of bounce buffer can be allocated. At 202, DMA engine can transfer data from a host to a staging buffer prior to storage in the allocated bounce buffer (¶ 0030)].
As to claim 2, Leung teaches The method of claim 1, further comprising: writing the compressed data to the memory address from the direct memory access module [Bounce buffer 126 can be allocated in memory 120 as a pool of multiple subregions. For example, a subregion can be 1 KB in size, and multiple subregions can be allocated to DMA circuitry 102 to store data before and after compression of data. However, other sizes of subregions can be used. Based on compression of data, a size of data stored in bounce buffer 126 may shrink and based on configuration 122, where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions … (¶ 0019-0020); FIG. 2 depicts an example write operation. The write operation can include an NVMe-oF write operation. The write operation can be performed by a network interface device, an accelerator, or a storage controller. At 202, a DMA circuitry could request and receive, from an operating system (OS), allocation of multiple pointers to a subset of a bounce buffer. For example, 4 pointers to different 1 KB (or 512B or other sizes) regions can be allocated. In some examples, an NVMe command (nCMD) is allocated 4 KB in a bounce buffer. However, other sizes of bounce buffer can be allocated. At 202, DMA engine can transfer data from a host to a staging buffer prior to storage in the allocated bounce buffer (¶ 0030)].
As to claim 3, Leung teaches The method of claim 1, further comprising: pre-allocating one or more memory slabs for one or more of a plurality of class sizes, including the class size and the first memory slab; and sending first memory pointers for the first memory slab for each of the plurality of class sizes to a memory allocator module [Examples described herein relate to a device that includes: a host interface; and circuitry to: based on allocation of a region in a buffer, wherein the buffer is associated with Non-volatile Memory Express over Fabrics (NVMe-oF) transactions: based on a first size of compressed data to be stored in the buffer, deallocate a portion of the region in the buffer and store the compressed data of the first size into a second portion of the region in the buffer and based on a second size of the compressed data to be stored in the buffer, utilize the allocated region in the buffer to store the compressed data of the second size (abstract); Various examples provide for allocation of a region in a bounce buffer at least for data to be written as part of an NVMe-oF write transaction or data to be read as part of an NVMe-oF read transaction. Prior to storage of the data into the bounce buffer, the data can be compressed using one or more compression technologies. Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction. The bounce buffer can be allocated using multiple pointers, where a pointer refers to a subregion (e.g., a strict subset of the bounce buffer). Deallocation of the portion of the region can include identifying a pointer to a strict subset of the bounce buffer for reallocation to another write or read transaction. Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data. Some examples can allocate a size of a bounce buffer for transactions that utilize one or more of: a network interface device, an accelerator, or a storage controller (¶ 0009); … Based on compression of data, a size of data stored in bounce buffer 126 may shrink and based on configuration 122, where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions … (¶ 0019); … a DMA circuitry could request and receive, from an operating system (OS), allocation of multiple pointers to a subset of a bounce buffer. For example, 4 pointers to different 1 KB (or 512B or other sizes) regions can be allocated … (¶ 0030); … At 304, compressed data can be stored in the bounce buffer and unused subregion(s) of the bounce buffer, which do not store compressed data, pointers to the unused subregions can be deallocated (¶ 0034); … receiving allocation of a first group of multiple pointers to multiple regions of a buffer; and based on compression of the first data, deallocating at least one of the first group of multiple pointers based on a size of the compressed first data; and in response to receipt of a read command associated with a second data received in at least one packet by the network interface: receiving allocation of a second group of multiple pointers to multiple regions of the buffer; and based on compression of the second data, deallocating at least one of the second group of multiple pointers based on a size of the compressed second data (¶ 0095)].
As to claim 4, Leung teaches The method of claim 3, wherein the pre-allocating comprises: allocating contiguous regions for each class size [For example, bounce buffer 126 can include four 1 KiB subregions. Where a first data of size 4 KiB is compressed by 10× to 0.4 KiB and stored in only one 1 KiB subregion, the three unused 1 KiB sub regions can be freed for other transactions. Where a second data is compressed to 3.5 KiB, all four subregions are used to store the 3.5 KiB compressed data and no sub-region can be freed in this case (¶ 0020)].
As to claim 5, Leung teaches The method of claim 3, further comprising: pre-allocating a second memory slab for one or more of the plurality of class sizes; and sending second memory pointers for the second memory slab for one or more of the plurality of class sizes to the memory allocator module [Examples described herein relate to a device that includes: a host interface; and circuitry to: based on allocation of a region in a buffer, wherein the buffer is associated with Non-volatile Memory Express over Fabrics (NVMe-oF) transactions: based on a first size of compressed data to be stored in the buffer, deallocate a portion of the region in the buffer and store the compressed data of the first size into a second portion of the region in the buffer and based on a second size of the compressed data to be stored in the buffer, utilize the allocated region in the buffer to store the compressed data of the second size (abstract); Various examples provide for allocation of a region in a bounce buffer at least for data to be written as part of an NVMe-oF write transaction or data to be read as part of an NVMe-oF read transaction. Prior to storage of the data into the bounce buffer, the data can be compressed using one or more compression technologies. Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction. The bounce buffer can be allocated using multiple pointers, where a pointer refers to a subregion (e.g., a strict subset of the bounce buffer). Deallocation of the portion of the region can include identifying a pointer to a strict subset of the bounce buffer for reallocation to another write or read transaction. Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data. Some examples can allocate a size of a bounce buffer for transactions that utilize one or more of: a network interface device, an accelerator, or a storage controller (¶ 0009); … Based on compression of data, a size of data stored in bounce buffer 126 may shrink and based on configuration 122, where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions … (¶ 0019); … a DMA circuitry could request and receive, from an operating system (OS), allocation of multiple pointers to a subset of a bounce buffer. For example, 4 pointers to different 1 KB (or 512B or other sizes) regions can be allocated … (¶ 0030); … At 304, compressed data can be stored in the bounce buffer and unused subregion(s) of the bounce buffer, which do not store compressed data, pointers to the unused subregions can be deallocated (¶ 0034); … receiving allocation of a first group of multiple pointers to multiple regions of a buffer; and based on compression of the first data, deallocating at least one of the first group of multiple pointers based on a size of the compressed first data; and in response to receipt of a read command associated with a second data received in at least one packet by the network interface: receiving allocation of a second group of multiple pointers to multiple regions of the buffer; and based on compression of the second data, deallocating at least one of the second group of multiple pointers based on a size of the compressed second data (¶ 0095)].
As to claim 6, Leung teaches The method of claim 5, wherein the unused memory pointer for the first memory slab for the class size was identified in response to identifying that there is no unused memory pointer for the second memory slab for the class size [Examples described herein relate to a device that includes: a host interface; and circuitry to: based on allocation of a region in a buffer, wherein the buffer is associated with Non-volatile Memory Express over Fabrics (NVMe-oF) transactions: based on a first size of compressed data to be stored in the buffer, deallocate a portion of the region in the buffer and store the compressed data of the first size into a second portion of the region in the buffer and based on a second size of the compressed data to be stored in the buffer, utilize the allocated region in the buffer to store the compressed data of the second size (abstract); Various examples provide for allocation of a region in a bounce buffer at least for data to be written as part of an NVMe-oF write transaction or data to be read as part of an NVMe-oF read transaction. Prior to storage of the data into the bounce buffer, the data can be compressed using one or more compression technologies. Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction. The bounce buffer can be allocated using multiple pointers, where a pointer refers to a subregion (e.g., a strict subset of the bounce buffer). Deallocation of the portion of the region can include identifying a pointer to a strict subset of the bounce buffer for reallocation to another write or read transaction. Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data. Some examples can allocate a size of a bounce buffer for transactions that utilize one or more of: a network interface device, an accelerator, or a storage controller (¶ 0009); … Based on compression of data, a size of data stored in bounce buffer 126 may shrink and based on configuration 122, where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions … (¶ 0019); … a DMA circuitry could request and receive, from an operating system (OS), allocation of multiple pointers to a subset of a bounce buffer. For example, 4 pointers to different 1 KB (or 512B or other sizes) regions can be allocated … (¶ 0030); … At 304, compressed data can be stored in the bounce buffer and unused subregion(s) of the bounce buffer, which do not store compressed data, pointers to the unused subregions can be deallocated (¶ 0034); … receiving allocation of a first group of multiple pointers to multiple regions of a buffer; and based on compression of the first data, deallocating at least one of the first group of multiple pointers based on a size of the compressed first data; and in response to receipt of a read command associated with a second data received in at least one packet by the network interface: receiving allocation of a second group of multiple pointers to multiple regions of the buffer; and based on compression of the second data, deallocating at least one of the second group of multiple pointers based on a size of the compressed second data (¶ 0095)].
As to claim 7, Leung teaches The method of claim 1, further comprising: generating the compressed data using a compression algorithm [At 204, one or more compression engines can apply different lossless or lossy compression algorithms in parallel. Compressed data can be selected based on compressed data with a highest compression ratio or which reduced data in size by a largest amount … (¶ 0031)]; and writing the compressed data to the at least one output buffer [For example, one or more of compressors/decompressors 114 can perform lossless or lossy compression of data stored in staging buffer 124 prior to storage in bounce buffer 126 … (¶ 0016-0017)].
As to claim 8, Leung teaches The method of claim 1, further comprising: writing the compressed data from the at least one output buffer to a memory in response to determining: the size of compressed data exceeds a size of the at least one output buffer, a slab of a right size class cannot be obtained within a designated time, there is no allocated memory pointer for the size of the compressed data, or based on the class size, there is no unused memory pointer [Examples described herein relate to a device that includes: a host interface; and circuitry to: based on allocation of a region in a buffer, wherein the buffer is associated with Non-volatile Memory Express over Fabrics (NVMe-oF) transactions: based on a first size of compressed data to be stored in the buffer, deallocate a portion of the region in the buffer and store the compressed data of the first size into a second portion of the region in the buffer and based on a second size of the compressed data to be stored in the buffer, utilize the allocated region in the buffer to store the compressed data of the second size (abstract); Various examples provide for allocation of a region in a bounce buffer at least for data to be written as part of an NVMe-oF write transaction or data to be read as part of an NVMe-oF read transaction. Prior to storage of the data into the bounce buffer, the data can be compressed using one or more compression technologies. Based on a size of the compressed data being less than that of the allocated region, a portion of the region in the bounce buffer can be deallocated and made available for use by another write or read transaction. The bounce buffer can be allocated using multiple pointers, where a pointer refers to a subregion (e.g., a strict subset of the bounce buffer). Deallocation of the portion of the region can include identifying a pointer to a strict subset of the bounce buffer for reallocation to another write or read transaction. Based on a size of the compressed data being approximately a size of the allocated region, or such that no subregion of the bounce buffer would not store compressed data, the allocated region in the buffer can be used to store the compressed data. Based on a size of the compressed data being greater than a size of the allocated region, the allocated region in the buffer can be increased and the increased size allocated region can be used to store the compressed data. Some examples can allocate a size of a bounce buffer for transactions that utilize one or more of: a network interface device, an accelerator, or a storage controller (¶ 0009); … Based on compression of data, a size of data stored in bounce buffer 126 may shrink and based on configuration 122, where a size of the compressed data is less than allocated region in bounce buffer 126 and at least one subregion is not used to store the compressed data, packet processors 104 can deallocate at least one subregion in bounce buffer 126 so that pointer(s) to such at least one subregion can be available for use for data of other transactions … (¶ 0019); … a DMA circuitry could request and receive, from an operating system (OS), allocation of multiple pointers to a subset of a bounce buffer. For example, 4 pointers to different 1 KB (or 512B or other sizes) regions can be allocated … (¶ 0030); … At 304, compressed data can be stored in the bounce buffer and unused subregion(s) of the bounce buffer, which do not store compressed data, pointers to the unused subregions can be deallocated (¶ 0034); … receiving allocation of a first group of multiple pointers to multiple regions of a buffer; and based on compression of the first data, deallocating at least one of the first group of multiple pointers based on a size of the compressed first data; and in response to receipt of a read command associated with a second data received in at least one packet by the network interface: receiving allocation of a second group of multiple pointers to multiple regions of the buffer; and based on compression of the second data, deallocating at least one of the second group of multiple pointers based on a size of the compressed second data (¶ 0095)].
As to claim 9, Leung teaches The method of claim 1, further comprising sending memory slab status data to a slab allocator module [… Accordingly, a number of transactions that can utilize bounce buffer 126 can potentially increase where subregions of bounce buffer 126 are deallocated and available for use. A bit map or data may be used to identify subregions available for allocation (¶ 0019); … After determination of the size of compressed data, unused subregion(s) in the bounce buffer can be made available and deallocated and returned to a free pool. A bit map can be updated to identify unused subregions in bounce buffer (¶ 0031)].
As to claim 10, Leung teaches The method of claim 9, wherein the memory slab status data is configured to indicate to the slab allocator module a use status of the memory slab for the class size [… Accordingly, a number of transactions that can utilize bounce buffer 126 can potentially increase where subregions of bounce buffer 126 are deallocated and available for use. A bit map or data may be used to identify subregions available for allocation (¶ 0019); … After determination of the size of compressed data, unused subregion(s) in the bounce buffer can be made available and deallocated and returned to a free pool. A bit map can be updated to identify unused subregions in bounce buffer (¶ 0031)].
As to claim 11, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details.
In addition, regarding claim 11, Leung teaches one or more memories [memory subsystem, figure 6, 620]; and one or more processors [processors, figure 6, 610] communicatively coupled to the one or more memories [as shown in figure 6, the processors (610) and are connected to the memories (620) via an interface unit (612)].
As to claim 12, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 13, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to “As to claim 3” presented earlier in this Office Action for details.
As to claim 14, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to “As to claim 4” presented earlier in this Office Action for details.
As to claim 15, it recites substantially the same limitations as in claim 5, and is rejected for the same reasons set forth in the analysis of claim 5. Refer to “As to claim 1” presented earlier in this Office Action for details.
As to claim 16, it recites substantially the same limitations as in claim 6, and is rejected for the same reasons set forth in the analysis of claim 6. Refer to “As to claim 6” presented earlier in this Office Action for details.
As to claim 17, it recites substantially the same limitations as in claim 7, and is rejected for the same reasons set forth in the analysis of claim 7. Refer to “As to claim 7” presented earlier in this Office Action for details.
As to claim 18, it recites substantially the same limitations as in claim 8, and is rejected for the same reasons set forth in the analysis of claim 8. Refer to “As to claim 8” presented earlier in this Office Action for details.
As to claim 19, it recites substantially the same limitations as in claim 9, and is rejected for the same reasons set forth in the analysis of claim 9. Refer to “As to claim 9” presented earlier in this Office Action for details.
As to claim 20, it recites substantially the same limitations as in claim 10, and is rejected for the same reasons set forth in the analysis of claim 10. Refer to “As to claim 10” presented earlier in this Office Action for details.
Conclusion
5. Claims 1-20 are rejected as explained above.
6. 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.
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHENG JEN TSAI whose telephone number is 571-272-4244. The examiner can normally be reached on Monday-Friday, 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached on 571-272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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).
/SHENG JEN TSAI/Primary Examiner, Art Unit 2139
Prosecution Insights