DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-4, 8-11, and 15-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Yehuda et al. (U.S. Patent No. 10,956,346) in view of Aizman et al. (Pub. No. US 2012/0017043).
Claim 1:
Ben-Yehuda et al. disclose a memory system, comprising:
one or more memory components configurable as one or more logical memory devices [fig. 1; column 13, lines 52-56; column 19, lines 16-20 – “The in-line hardware accelerator is coupled to one or more SSD units 15 and to accelerator memory. The connection to the network and the SSD units may be via a switch such as an PCIe switch (not shown).” … “Block or K/V data stored in the system belongs to a logical volume. Each logical volume has configuration attributes (e.g. compression enabled/disabled), size and protocol (e.g. Block or K/V). Logical volumes can be created, deleted and modified using the management interface.”],
wherein the one or more logical memory devices are to be configured with lossy compression enabled or lossy compression disabled [column 19, lines 16-20; column 43, lines 61-65; column 50, lines 63 – column 51, line 8 – Compression can be enabled or disabled and the algorithm can be lossy or lossless. (“Block or K/V data stored in the system belongs to a logical volume. Each logical volume has configuration attributes (e.g. compression enabled/disabled), size and protocol (e.g. Block or K/V). Logical volumes can be created, deleted and modified using the management interface.” … “Another example is for the storage system may use different data resiliency or compression algorithms for data and for metadata, since it may be acceptable to lose data partly or entirely, but it may not be acceptable to lose any metadata.” … “A concrete example may be a Co-Processor the implements a lossy compression algorithm like JPEG. On the Ingress, the original data has to be written to media, read back from media through the CPU to the co-processor, compressed by the co-processor compression engines and the written back through the CPU back to media. In this sequence, the original data is copied between the CPU and the Storage twice before the compressed data gets copied again. These round trips through the CPU waste bandwidth on the CPU, add latency and as a result, slows down the system overall.—See FIG. 22. The CPU is connected to the DRAM, co-processor and SSD units—and the co-processor must use the resources of the CPU to access the SSD unit.”)]; and a controller configured to:
receive, from a host device, a command to write data to a memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”];
compress the data to obtain compressed data, responsive to the memory location corresponding to a logical memory device, of the one or more logical memory devices, that is configured with lossy compression enabled [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”]; and
cause the compressed data to be written to the memory location [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”].
However, Ben-Yehuda et al. do not specifically disclose,
the memory components are volatile memory,
In the same field of endeavor, Aizman et al. disclose,
the memory components are volatile memory [par. 0088 – “A RAM Disk (also referred to as RAM drive or ramdisk) is a block of random access memory (RAM) that is utilized to emulate a disk drive. The corresponding computer software is often implemented as a RAM Disk block level driver. A RAM Disk will provide a superior I/O performance at the price of not providing for data persistency. Capacity of RAM disks is also limited by the size of RAM and generally is expected to be orders of magnitude smaller than the capacity of stable storage.”],
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Ben-Yehuda et al. to include a ramdisk, as taught by Aizman et al., in order to improve performance by providing a high-speed memory.
Claim 2 (as applied to claim 1 above):
Ben-Yehuda et al. disclose,
wherein the controller is configured to compress the data using a lossy compression operation using a lossy compression and decompression engine of the controller [column 1, lines 53-59 – “The in-line hardware accelerator may include at least one acceleration engines out of a compression engine, a decompression engine, an encryption engine, a decryption engine, a compaction engine, a de-duplication engine, a data movement engine, a replication engine, a peer-to-peer engine, a scatter-gather engine, a virtual MMU engine, or an erasure coding engine.”].
Claim 3 (as applied to claim 1 above):
Ben-Yehuda et al. disclose, wherein the controller is further configured to:
receive an additional command to write additional data to an additional memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”]; and
cause the additional data to be written to the additional memory location without using a lossy compression operation, responsive to the additional memory location corresponding to an additional logical memory device, of the one or more logical memory devices, that is configured with lossy compression disabled [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – Data is stored uncompressed when compression is not enabled. (“Since user data may be stored in various formats (e.g., raw, compressed, encrypted) the metadata also stores for each piece of user data the format it is stored in.” … “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”)].
Claim 4 (as applied to claim 1 above):
Ben-Yehuda et al. disclose, wherein the controller is further configured to:
receive an additional command to read from the memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”];
decompress the compressed data using a decompression operation to obtain decompressed data [column 23, lines 24-29 – “Compression/decompression acceleration refers to compressing data while being written to SSD and decompress while being read from SSD. Data compression is a critical acceleration function as it increases the effective user capacity, increases SSD endurance and improves overall system performance.”]; and
output the decompressed data [column 23, lines 24-29 – “Compression/decompression acceleration refers to compressing data while being written to SSD and decompress while being read from SSD. Data compression is a critical acceleration function as it increases the effective user capacity, increases SSD endurance and improves overall system performance.”].
Claim 8:
Ben-Yehuda et al. disclose a system, comprising:
one or more host devices [column 42, lines 1-3 – “The storage system may use a network protocol such as TCP/IP to expose services to its hosts.”]; and
a memory pool, comprising:
a non-compression memory system [figs. 1-4 – memories exclusive of SSD units]; and
a compression memory system, comprising:
one or more memory components configurable as one or more logical memory devices [fig. 1; column 13, lines 52-56; column 19, lines 16-20 – “The in-line hardware accelerator is coupled to one or more SSD units 15 and to accelerator memory. The connection to the network and the SSD units may be via a switch such as an PCIe switch (not shown).” … “Block or K/V data stored in the system belongs to a logical volume. Each logical volume has configuration attributes (e.g. compression enabled/disabled), size and protocol (e.g. Block or K/V). Logical volumes can be created, deleted and modified using the management interface.”],
wherein the one or more logical memory devices are to be configured with lossy compression enabled or lossy compression disabled [column 19, lines 16-20; column 43, lines 61-65; column 50, lines 63 – column 51, line 8 – Compression can be enabled or disabled and the algorithm can be lossy or lossless. (“Block or K/V data stored in the system belongs to a logical volume. Each logical volume has configuration attributes (e.g. compression enabled/disabled), size and protocol (e.g. Block or K/V). Logical volumes can be created, deleted and modified using the management interface.” … “Another example is for the storage system may use different data resiliency or compression algorithms for data and for metadata, since it may be acceptable to lose data partly or entirely, but it may not be acceptable to lose any metadata.” … “A concrete example may be a Co-Processor the implements a lossy compression algorithm like JPEG. On the Ingress, the original data has to be written to media, read back from media through the CPU to the co-processor, compressed by the co-processor compression engines and the written back through the CPU back to media. In this sequence, the original data is copied between the CPU and the Storage twice before the compressed data gets copied again. These round trips through the CPU waste bandwidth on the CPU, add latency and as a result, slows down the system overall.—See FIG. 22. The CPU is connected to the DRAM, co-processor and SSD units—and the co-processor must use the resources of the CPU to access the SSD unit.”)]; and
a controller configured to:
receive, from a host device, a command to write data to a memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”];
compress the data using a lossy compression operation to obtain compressed data, responsive to the memory location corresponding to a logical memory device, of the one or more logical memory devices, that is configured with lossy compression enabled [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”]; and
write the compressed data to the memory location [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”].
However, Ben-Yehuda et al. do not specifically disclose,
the memory components are volatile memory,
In the same field of endeavor, Aizman et al. disclose,
the memory components are volatile memory [par. 0088 – “A RAM Disk (also referred to as RAM drive or ramdisk) is a block of random access memory (RAM) that is utilized to emulate a disk drive. The corresponding computer software is often implemented as a RAM Disk block level driver. A RAM Disk will provide a superior I/O performance at the price of not providing for data persistency. Capacity of RAM disks is also limited by the size of RAM and generally is expected to be orders of magnitude smaller than the capacity of stable storage.”],
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Ben-Yehuda et al. to include a ramdisk, as taught by Aizman et al., in order to improve performance by providing a high-speed memory.
Claim 9 (as applied to claim 8 above):
Ben-Yehuda et al. disclose,
wherein the one or more logical memory devices comprise multiple logical memory devices [fig. 1; column 13, lines 52-56; column 19, lines 16-20 – “Block or K/V data stored in the system belongs to a logical volume. Each logical volume has configuration attributes (e.g. compression enabled/disabled), size and protocol (e.g. Block or K/V). Logical volumes can be created, deleted and modified using the management interface.”].
Claim 10 (as applied to claim 8 above):
Ben-Yehuda et al. disclose, wherein the controller is further configured to:
receive an additional command to write additional data to an additional memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”]; and
cause the additional data to be written to the additional memory location without using the lossy compression operation, responsive to the additional memory location corresponding to an additional logical memory device, of the one or more logical memory devices, that is configured with lossy compression disabled [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – Data is stored uncompressed when compression is not enabled. (“Since user data may be stored in various formats (e.g., raw, compressed, encrypted) the metadata also stores for each piece of user data the format it is stored in.” … “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”)].
Claim 11 (as applied to claim 8 above):
Ben-Yehuda et al. disclose, wherein the controller is further configured to:
receive an additional command to read from the memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”];
decompress the compressed data using a decompression operation to obtain decompressed data [column 23, lines 24-29 – “Compression/decompression acceleration refers to compressing data while being written to SSD and decompress while being read from SSD. Data compression is a critical acceleration function as it increases the effective user capacity, increases SSD endurance and improves overall system performance.”]; and
output the decompressed data [column 23, lines 24-29 – “Compression/decompression acceleration refers to compressing data while being written to SSD and decompress while being read from SSD. Data compression is a critical acceleration function as it increases the effective user capacity, increases SSD endurance and improves overall system performance.”].
Claim 15:
Ben-Yehuda et al. disclose a method, comprising:
receiving, by a controller of a memory system, and from a host device, a command to write data to a memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”];
compressing, by the controller, the data using a lossy compression operation to obtain compressed data [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”]; and
causing, by the controller, the compressed data to be written to the memory location [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”].
However, Ben-Yehuda et al. do not specifically disclose,
the memory components are volatile memory,
In the same field of endeavor, Aizman et al. disclose,
the memory components are volatile memory [par. 0088 – “A RAM Disk (also referred to as RAM drive or ramdisk) is a block of random access memory (RAM) that is utilized to emulate a disk drive. The corresponding computer software is often implemented as a RAM Disk block level driver. A RAM Disk will provide a superior I/O performance at the price of not providing for data persistency. Capacity of RAM disks is also limited by the size of RAM and generally is expected to be orders of magnitude smaller than the capacity of stable storage.”],
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Ben-Yehuda et al. to include a ramdisk, as taught by Aizman et al., in order to improve performance by providing a high-speed memory.
Claim 16 (as applied to claim 15 above):
Ben-Yehuda et al. disclose,
wherein the memory system comprises one or more volatile memory components configured as one or more logical memory devices [fig. 1; column 13, lines 52-56; column 19, lines 16-20 – As discussed above, Aizman et al. disclose a ramdisk. (“The in-line hardware accelerator is coupled to one or more SSD units 15 and to accelerator memory. The connection to the network and the SSD units may be via a switch such as an PCIe switch (not shown).” … “Block or K/V data stored in the system belongs to a logical volume. Each logical volume has configuration attributes (e.g. compression enabled/disabled), size and protocol (e.g. Block or K/V). Logical volumes can be created, deleted and modified using the management interface.”)].
Claim 17 (as applied to claim 16 above):
Ben-Yehuda et al. disclose,
wherein the data is compressed and responsive to the memory location corresponding to a logical memory device, of the one or more logical memory devices, that is configured with lossy compression enabled [column 19, lines 16-20; column 43, lines 61-65; column 50, lines 63 – column 51, line 8 – Compression can be enabled or disabled and the algorithm can be lossy or lossless. (“Block or K/V data stored in the system belongs to a logical volume. Each logical volume has configuration attributes (e.g. compression enabled/disabled), size and protocol (e.g. Block or K/V). Logical volumes can be created, deleted and modified using the management interface.” … “Another example is for the storage system may use different data resiliency or compression algorithms for data and for metadata, since it may be acceptable to lose data partly or entirely, but it may not be acceptable to lose any metadata.” … “A concrete example may be a Co-Processor the implements a lossy compression algorithm like JPEG. On the Ingress, the original data has to be written to media, read back from media through the CPU to the co-processor, compressed by the co-processor compression engines and the written back through the CPU back to media. In this sequence, the original data is copied between the CPU and the Storage twice before the compressed data gets copied again. These round trips through the CPU waste bandwidth on the CPU, add latency and as a result, slows down the system overall.—See FIG. 22. The CPU is connected to the DRAM, co-processor and SSD units—and the co-processor must use the resources of the CPU to access the SSD unit.”)].
Claim 18 (as applied to claim 16 above):
Ben-Yehuda et al. disclose the method, further comprising:
receiving an additional command to write additional data to an additional memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”]; and
causing the additional data to be written to the additional memory location without using the lossy compression operation, responsive to the additional memory location corresponding to an additional logical memory device, of the one or more logical memory devices, that is configured with lossy compression disabled [column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – Data is stored uncompressed when compression is not enabled. (“Since user data may be stored in various formats (e.g., raw, compressed, encrypted) the metadata also stores for each piece of user data the format it is stored in.” … “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”)].
Claim 19 (as applied to claim 16 above):
Ben-Yehuda et al. disclose,
wherein the one or more logical memory devices comprise multiple logical memory devices mapped to multiple logical ports [column 42, lines 1-23 – “[column 21, lines 15-17; column 23, lines 24-29; column 23, line 63 – column 24, line 2; column 25, lines 37-49 – Data is stored uncompressed when compression is not enabled. (“Since user data may be stored in various formats (e.g., raw, compressed, encrypted) the metadata also stores for each piece of user data the format it is stored in.” … “When compression is enabled for a given volume, every block or K/V object belonging to that volume is compressed individually. The data arrives to the front-ends uncompressed, but during the write-flow, the global FTL instructs the accelerator to compress the accelerator object (user-data). If the accelerator object size after compression is smaller than the original size, accelerator keeps the compressed data in the processing memory address space. Otherwise accelerator keeps the original data.”)]”].
Claim 20 (as applied to claim 15 above):
Ben-Yehuda et al. disclose the method, further comprising:
receiving an additional command to read from the memory location [column 15, lines 12-20 – “The frontends (FEs) are optimized for network access and for specific protocol/application implementations. The frontends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network. They handle the request inside the frontend if possible (e.g., if the data to be read is already cached by the frontend) and communicate with the backend if the data needs to be read from or written to storage.”];
decompressing the compressed data using a decompression operation to obtain decompressed data [column 23, lines 24-29 – “Compression/decompression acceleration refers to compressing data while being written to SSD and decompress while being read from SSD. Data compression is a critical acceleration function as it increases the effective user capacity, increases SSD endurance and improves overall system performance.”]; and
outputting the decompressed data [column 23, lines 24-29 – “Compression/decompression acceleration refers to compressing data while being written to SSD and decompress while being read from SSD. Data compression is a critical acceleration function as it increases the effective user capacity, increases SSD endurance and improves overall system performance.”].
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Yehuda et al. (U.S. Patent No. 10,956,346) in view of Aizman et al. (Pub. No. US 2012/0017043) as applied to claim 1 above, and further in view of Colgrove (U.S. Patent No. 11,163,448).
Claim 5 (as applied to claim 1 above):
Ben-Yehuda et al. and Aizman et al. disclose all the limitations above but do not specifically disclose, wherein the controller is further configured to:
determine an updated virtual memory capacity of the one or more logical memory devices resulting from the compressed data being written to the memory location; and
output an indication of the updated virtual memory capacity.
In the same field of endeavor, Colgrove discloses,
determine an updated virtual memory capacity of the one or more logical memory devices resulting from the compressed data being written to the memory location [column 9, line 20 – column 10, line 6 – “Consider the example described above where the storage device (308) is initially characterized by a first storage capacity of 80 GB, the computing device (304) issues a request that the storage device (308) store a database that includes 25 GB of data, the storage device (308) is able to apply compression algorithms and deduplication algorithms that reduce (310) the database to a size of 10 GB, and the storage device (308) designates the entire amount of the storage capacity saved by reducing the data as additional capacity. In such an example, the storage device (308) would export (314) an updated storage capacity (316) of 95 GB to the computing device (304) in the absence of the storage device (308) holding a predetermined amount of storage capacity in reserve. In an embodiment where the storage device (308) does hold a predetermined amount of storage capacity in reserve, however, the storage device (308) would export (314) an updated storage capacity (316) that is reduced by predetermined amount of storage capacity in reserve. If the predetermined amount of storage capacity to be held in reserve was 10 GB, for example, the storage device (308) would export (314) an updated storage capacity (316) of 85 GB to the computing device (304). In the example method depicted in FIG. 5, determining (312) an updated storage capacity (316) for the storage device (308) can alternatively include determining (504) the updated storage capacity (316) for the storage device (308) in dependence upon an anticipated reduction level. The anticipated reduction level can represent the extent to which future commitments of data to the storage device are expected to be reduced. The anticipated reduction level may be determined, for example, based on the average rate at which all data currently stored on the storage device (308) has been reduced (310).”]; and
output an indication of the updated virtual memory capacity [column 9, line 20 – column 10, line 6 – “Consider the example described above where the storage device (308) is initially characterized by a first storage capacity of 80 GB, the computing device (304) issues a request that the storage device (308) store a database that includes 25 GB of data, the storage device (308) is able to apply compression algorithms and deduplication algorithms that reduce (310) the database to a size of 10 GB, and the storage device (308) designates the entire amount of the storage capacity saved by reducing the data as additional capacity. In such an example, the storage device (308) would export (314) an updated storage capacity (316) of 95 GB to the computing device (304) in the absence of the storage device (308) holding a predetermined amount of storage capacity in reserve. In an embodiment where the storage device (308) does hold a predetermined amount of storage capacity in reserve, however, the storage device (308) would export (314) an updated storage capacity (316) that is reduced by predetermined amount of storage capacity in reserve. If the predetermined amount of storage capacity to be held in reserve was 10 GB, for example, the storage device (308) would export (314) an updated storage capacity (316) of 85 GB to the computing device (304). In the example method depicted in FIG. 5, determining (312) an updated storage capacity (316) for the storage device (308) can alternatively include determining (504) the updated storage capacity (316) for the storage device (308) in dependence upon an anticipated reduction level. The anticipated reduction level can represent the extent to which future commitments of data to the storage device are expected to be reduced. The anticipated reduction level may be determined, for example, based on the average rate at which all data currently stored on the storage device (308) has been reduced (310).”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Ben-Yehuda et al. and Aizman et al. to include exporting an updated storage capacity, as taught by Colgrove, in order to improve efficiency by facilitating more effective use of storage.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Yehuda et al. (U.S. Patent No. 10,956,346) and Aizman et al. (Pub. No. US 2012/0017043) as applied to claim 1 above, and further in view of Williams (Pub. No. US 2003/0072493).
Claim 6 (as applied to claim 1 above):
Ben-Yehuda et al. and Aizman et al. disclose all the limitations above but do not specifically disclose,
wherein the data is associated with a flag indicating that the data is approximable.
In the same field of endeavor, Williams discloses,
wherein the data is associated with a flag indicating that the data is approximable [par. 0062 – “The compression process may be directed to operate in a lossy way--by the setting a predetermined flag, for example. The flag may even direct the degree of lossiness. At the cost of reducing the resolution of the signature data, the compression of the signature is better. Where space is a concern, lossy compression may be desirable.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Ben-Yehuda et al. and Aizman et al. to include a flag, as taught by Williams, in order to improve performance by providing a means for quickly identifying the type of compression associated with data.
Claim(s) 12-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Yehuda et al. (U.S. Patent No. 10,956,346) in view of Aizman et al. (Pub. No. US 2012/0017043) as applied to claim 8 above, and further in view of Peffers et al. (Pub. No. US 2018/0164864).
Claim 12 (as applied to claim 8 above):
Ben-Yehuda et al. and Aizman et al. disclose all the limitations above but do not specifically disclose, wherein the controller is further configured to:
determine an error value for the compressed data, wherein the controller is configured to cause the compressed data to be written to the memory location responsive to the error value satisfying a threshold.
In the same field of endeavor, Peffers et al. disclose,
determine an error value for the compressed data, wherein the controller is configured to cause the compressed data to be written to the memory location responsive to the error value satisfying a threshold [par. 0035 – “In some embodiments, compression/decompression and similar functions that are routinely verified with the inverse function to ensure that there are no errors can also be adapted to trigger a training of the target circuit. Since the decompress function is performed as a matter of course on newly compressed data to ensure data is not lost, the compress function itself can tolerate errors because they will be detected when the data is decompressed and compared to the input data. When this occurs, the data can be re-compressed and re-verified, and at a certain threshold rate of errors, can trigger training or in-situ characterization to occur again.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Ben-Yehuda et al. and Aizman et al. to include checking the compressed data for errors, as taught by Peffers et al., in order to improve data integrity.
Claim 13 (as applied to claim 12 above):
Peffers et al. disclose, wherein the controller, to determine the error value, is configured to:
decompress the compressed data to obtain decompressed data [par. 0035 – “Since the decompress function is performed as a matter of course on newly compressed data to ensure data is not lost, the compress function itself can tolerate errors because they will be detected when the data is decompressed and compared to the input data.”]; and
compare the decompressed data to the data, wherein the error value is in accordance with a difference between the decompressed data and the data [par. 0035 – “Since the decompress function is performed as a matter of course on newly compressed data to ensure data is not lost, the compress function itself can tolerate errors because they will be detected when the data is decompressed and compared to the input data.”].
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Yehuda et al. (U.S. Patent No. 10,956,346) in view of Aizman et al. (Pub. No. US 2012/0017043) as applied to claim 8 above, and further in view of Li et al. (Pub. No. US 2023/0050808).
Claim 14 (as applied to claim 8 above):
Ben-Yehuda et al. and Aizman et al. disclose all the limitations above but do not specifically disclose,
wherein the compression memory system is a Type 3 Compute Express Link (CXL) device.
In the same field of endeavor, Li et al. disclose,
wherein the compression memory system is a Type 3 Compute Express Link (CXL) device [par. 0088 – “In some embodiments, a CXL Type-3 device with storage implemented with DRAM, PMEM, low latency NAND, and/or the like in accordance with example embodiments of the disclosure may use parallel device internal resources to achieve required high bandwidth and/or memory access inputs and/or outputs (IOs). Depending on the implementation details, higher system level performance and/or service level agreement (SLA) operations may be achieved by improving or optimizing accelerator concurrent data accesses with device internal parallel resources. Some systems and/or methods in accordance with example embodiments of the disclosure may be applied, for example, to DLRM workloads which may be used in platforms for social media, ecommerce, and/or the like.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Ben-Yehuda et al. and Aizman et al. to include a Type 3 CXL device, as taught by Li et al., in order to improve performance by providing a seamless extension of the host’s main memory.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-6 and 8-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 LARRY T MACKALL whose telephone number is (571)270-1172. The examiner can normally be reached Monday - Friday, 9am-5pm.
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, Reginald G Bragdon can be reached at (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 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.
LARRY T. MACKALL
Primary Examiner
Art Unit 2131
3 April 2026
/LARRY T MACKALL/Primary Examiner, Art Unit 2139
Prosecution Insights