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 .
Status of Claims
Claims 1-8, 10, 13-23 are pending. Claims 1, 3, 8, 14, 16, and 22 have been amended as per Applicants' request.
Papers Submitted
It is hereby acknowledged that the following papers have been received and placed of record in the file:
Amended Claims as filed on December 08, 2025
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.
Claim(s) 1, 10, and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over O’Hare et al. (US 2019/0303454) (hereinafter Ohare) (published October 03, 2019) in view of KAWAGUCHI (US 2013/0054894) (hereinafter Kawaguchi) (published February 28, 2013).
Regarding Claim 1 and 14, taking claim 1 as exemplary, Ohare discloses a block storage device for data compression and comprising: an interface; and a processor coupled to the interface and configured to:
“FIG. 1 is a schematic illustration showing a storage device 30 that includes a plurality of host adapters (HA) 32-34, a plurality of disk adapters (DA) 36-38 and a plurality of disk drives 42-44” (Ohare [0019])
“Systems, methods, and computer program products disclosed herein could be executed on architecture similar to that depicted in FIGS. 1 and 2. For example, method steps could be performed by processors either communicatively coupled to storage device 30 or internal, to storage device 30” (Ohare [0025])
store a data block after the data block has been compressed as a single block using large block compression when the data block cannot be de-duplicated and the data block is to be written to a block storage area of the block storage device, wherein the large block compression is applied to data blocks that are at least 128 kilobytes (kB) and are written to or read from the block storage area;
“In the system depicted in FIG. 3, it is possible for a user to set a deduplication threshold value based on data size. If for example, a user wanted to prevent duplicative write operations on a block-by-block basis, i.e., at a 128 K aligned deduplication value, all data chunks pictured in FIG. 3 would be written to storage device 130 even though duplicate values of data chunks A-L exist in storage blocks 131-133 as compared with storage blocks 134-137” (Ohare [0032] blocks 111-117 cannot be deduplicated and written to the storage array as blocks 131-137)
“Our solution provides the ability for large block (128 K) deduplication, but with an offsetting ability which provides nearly the same deduplication abilities as small block deduplication, but at a fraction of the metadata costs. In some embodiments, deduplication can be performed on 128 K blocks. The solution also permits large block compression and IO such that the data reduction ratio (“DRR”) reaches optimal levels, and large block performance does not suffer from severe fragmentation” (Ohare [0008] compression would be performed on the 128 K blocks of 111-117 as part of the storage to array 230)
write, for all sub-blocks of the data block, a similarity hash to a similarity hash table after storing the data block using the large block compression; and
“Hash table 150, which could be stored in memory 46, contains a series of fingerprints/hashes, which correspond to each 32 KB data block A-L, on a one-to-one basis. For example, the hash value for data chunk A is represented by A in blocks 151 and 154 of hash table 150. Hash table 150 similarly employs pointers 141-147 to show the physical location of the actual data corresponding to each hash value. In exemplary embodiments, hash values A-L could each be 32B hashes used to uniquely identify the pattern found in its respective data chunk” (Ohare [0031] the data chunk are sub-blocks and the similarity hash is on a chunk by chunk basis)
But does not explicitly state in a first operating phase and store, in a second operating phase after the large block compression of the first operating phase and based on the similarity hash, the sub-blocks for further reduction in size in a first disk space using similarity-de-duplication and further compression when the first disk space is less than a second disk space, wherein the first disk space is storage space that is required for storing the data block based on the similarity de-duplication, and wherein the second disk space is storage space that is required for storing the data block based on its present format.
However Ohare does disclose storing the sub-blocks using similarity-de-duplication.
“FIG. 6 depicts a system employing 32 K aligned deduplication for data blocks 610. In this system, data blocks 611-613 are physical written in data storage 630. Pointers 621a-621m are stored in a virtual table of pointers and allow hosts to physically locate the data in data blocks 611-613. In the 32 K aligned deduplication system of FIG. 6, when it comes time to determine if un written data block 614 should be written to physical storage 630, this determination will be made on a 32 KB granularity basis, meaning each data chunk will be individually evaluated to determine if it has already been written to physical storage 630” (Ohare [0050] the sub blocks of data 610 is written to 630 using similarity deduplication)
Kawaguchi and Ohare discloses in a first operating phase and
“In the second embodiment, a storage subsystem stores and distributes data to plural deduplication storage devices. The deduplication storage device mounts the storage subsystem to store data. The storage subsystem also has deduplication function (but the page size is larger than the deduplication storage device), so deduplicated data by deduplication storage devices can be deduplicated again by the storage subsystem. To optimize the possibility of deduplication, the deduplication storage derives sort the data with reconciliation” (Kawaguchi [0068] the first operating phase is when the data is being written to the storage before the data is deduplicated again)
“In the system depicted in FIG. 3, it is possible for a user to set a deduplication threshold value based on data size. If for example, a user wanted to prevent duplicative write operations on a block-by-block basis, i.e., at a 128 K aligned deduplication value, all data chunks pictured in FIG. 3 would be written to storage device 130 even though duplicate values of data chunks A-L exist in storage blocks 131-133 as compared with storage blocks 134-137” (Ohare [0034] writing the data in 128k aligned blocks and the hash values (see fig. 3) would be the first operating stage when the storage subsystem stores the data)
store, in a second operating phase after the large block compression of the first operating phase and based on the similarity hash, the sub-blocks for further reduction in size in a first disk space using similarity-de-duplication and further compression when the first disk space is less than a second disk space, wherein the first disk space is storage space that is required for storing the data block based on the similarity de-duplication, and wherein the second disk space is storage space that is required for storing the data block based on its present format.
“In the second embodiment, a storage subsystem stores and distributes data to plural deduplication storage devices. The deduplication storage device mounts the storage subsystem to store data. The storage subsystem also has deduplication function (but the page size is larger than the deduplication storage device), so deduplicated data by deduplication storage devices can be deduplicated again by the storage subsystem. To optimize the possibility of deduplication, the deduplication storage derives sort the data with reconciliation” (Kawaguchi [0068] the second operating phase is when the storage subsystem deduplicates the data again)
“FIG. 6 depicts a system employing 32 K aligned deduplication for data blocks 610. In this system, data blocks 611-613 are physical written in data storage 630. Pointers 621a-621m are stored in a virtual table of pointers and allow hosts to physically locate the data in data blocks 611-613. In the 32 K aligned deduplication system of FIG. 6, when it comes time to determine if un written data block 614 should be written to physical storage 630, this determination will be made on a 32 KB granularity basis, meaning each data chunk will be individually evaluated to determine if it has already been written to physical storage 630” (Ohare [0050] the data can be deduplicated again as disclosed in Kawaguchi and the deduplication would be done by employing 32k alignment of the sub blocks)
By integrating the disclosures of Ohare and Kawaguchi, a system can be implemented that performs data deduplication multiple times using different methodologies. Kawaguchi specifies that a storage subsystem can include a deduplication function and that data which has already been deduplicated can undergo the process again.
In the first operating phase, which occurs while the data is being stored, the subsystem's deduplication function executes the steps described in Fig.3 and paragraphs [0031] and [0032] of Ohare. During this initial stage, the data is processed and stored in its current format on array drives 130 (second disk space).
A second operating phase follows where the data is subjected to deduplication again. For this phase, the system employs the 32k-aligned deduplication method detailed in Fig. 6 and paragraph [0050] of Ohare. This secondary process utilizes the storage space on array drives 630 (first disk space), which are specifically illustrated to hold data managed through similarity deduplication. This approach is distinct from the initial storage format used during the first phase.
Determining the most efficient storage strategy involves basic mathematical reasoning by a person of ordinary skill in the art. This individual can evaluate the storage space required for the 32k-aligned deduplication method against the space consumed by the current storage format. Because it is straightforward to identify which option uses less physical space, the system can easily select the most optimized storage configuration.
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the multiple times of deduplicating of data in Kawaguchi with the memory system in Ohare. The motivation for doing so would be improve the optimization of the space when storing data as disclosed in Kawaguchi. “To optimize the possibility of deduplication, the deduplication storage derives sort the data with reconciliation” (Kawaguchi [0068])
Regarding Claim 10, Kawaguchi and Ohare further discloses wherein the data block that is stored in the block storage device can be further reduced in size using the similarity de-duplication based on the similarity hash.
“In the second embodiment, a storage subsystem stores and distributes data to plural deduplication storage devices. The deduplication storage device mounts the storage subsystem to store data. The storage subsystem also has deduplication function (but the page size is larger than the deduplication storage device), so deduplicated data by deduplication storage devices can be deduplicated again by the storage subsystem. To optimize the possibility of deduplication, the deduplication storage derives sort the data with reconciliation” (Kawaguchi [0068])
“In the 32 K aligned deduplication system of FIG. 6, when it comes time to determine if un written data block 614 should be written to physical storage 630, this determination will be made on a 32 KB granularity basis, meaning each data chunk will be individually evaluated to determine if it has already been written to physical storage 630. In unwritten data block 614, data chunk “$” will be recorded in physical storage at the location indicated by pointer 321m. Data chunk “A,” however, will not be recorded because the deduplication system will determine that data chunk “A” has already been stored in physical storage 630. As a result, pointer 622a will be recorded in a virtual table of pointers showing the connection between unwritten data chunk “A” and its location in physical storage 630. Similarly, for data chunks “B” through “L,” this 32 K aligned deduplication system store pointers 622b-6221 to record the correlation between unwritten data chunks “B” through “L” in data blocks 614-617 and their respective locations within physical storage 630” (Ohare [0050] the determination if the size can be reduced would be comparison of data in array drives 130 and 630 of Fig. 3 and Fig. 6, for blocks 614-617 it is determine that the size can be reduced and therefore deduplicated based on the hash in the second pass)
Claims 2, 15, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ohare (published October 03, 2019) and Kawaguchi (published February 28, 2013) in view of Lakey et al. (US 2012/0110258) (hereinafter Lakey) (published May 03, 2012).
Regarding Claims 2 and 15, the combination of Ohare and Kawaguchi disclosed the device of claim 1 and method of claim 14, and Ohare further discloses wherein the block storage area comprises data blocks that are written to or read from the block storage area.
“In this example, the storage array allocation is 128 KB. That is, storage array blocks 131-137 each contain 128 KB of storage space. The letters A-L each represent a unique 32 KB chunk of data, four 32 KB data chunks per 128 KB data block 131-137. Those of skill in the art will recognize that the storage array allocation size as well as the data chunk size could vary in alternate embodiments without deviating from the teachings disclosed herein. In embodiments, storage array allocation sizes could range from 4 K up to 1024 K (1 MB), likely in a power of 2, while data chunk sizes could fall within the same range” (Ohare [0027])
But does not explicitly state wherein the block storage area comprises data blocks that have an average size larger than a predefined threshold and wherein the predefined threshold is at least 128 KB.
Lakey and Ohare discloses wherein the block storage area comprises data blocks that have an average size larger than a predefined threshold and wherein the predefined threshold is at least 128 KB.
“If the determination block 406 determines that the size of the data block to be written as per the write command is above a threshold, control is transferred to the block 404, which marks the data related to the write command as non-cacheable data” (Lakey [0035])
“If the determination operation 314 determines that the data is not cacheable, control is again transferred to the writing operation 312, which writes the data to the storage media 116” (Lakey [0029])
“Operation 708 continuously calculates and updates various block-size statistics such as, the average block-size for write commands to the storage device, various percentile values of the block-size for write commands, etc.” (Lakey [0045])
“In this example, the storage array allocation is 128 KB. That is, storage array blocks 131-137 each contain 128 KB of storage space. The letters A-L each represent a unique 32 KB chunk of data, four 32 KB data chunks per 128 KB data block 131-137. Those of skill in the art will recognize that the storage array allocation size as well as the data chunk size could vary in alternate embodiments without deviating from the teachings disclosed herein. In embodiments, storage array allocation sizes could range from 4 K up to 1024 K (1 MB), likely in a power of 2, while data chunk sizes could fall within the same range” (Ohare [0027])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the determination of whether the data is cacheable based on size in Lakey with the system in the combination of Ohare and Kawaguchi. The motivation for doing so would be for more better caching efficiency. When cache blocks if the block size is too large it would cause a huge displacement on the useful data stored in the cache thereby lower efficiency so it would be more efficient to just directly store blocks larger than a certain size directly to the storage.
Regarding Claim 16, Lakey further discloses wherein the average size is based on a write statistic.
“Operation 708 continuously calculates and updates various block-size statistics such as, the average block-size for write commands to the storage device, various percentile values of the block-size for write commands, etc.” (Lakey [0045])
Claim 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ohare (published October 03, 2019), Kawaguchi (published February 28, 2013), and Lakey (published May 03, 2012) in view of MARUYAMA (US 2014/0258647) (hereinafter Maruyama) (published September 11, 2014).
Regarding Claim 3, the combination of Ohare, Kawaguchi, and Lakey disclosed the device of claim 2, but does not explicitly state wherein the average size is based on a read statistic.
Maruyama discloses wherein the average size is based on a read statistic.
“The average data amount is an average amount of data read in response to a read request, and is, for example, an average block size (r.sub.R) to be described later” (Maruyama [0034])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to substitute the write statistics as the average block size in the combination of Ohare, Kawaguchi, and Lakey to be the read statistics disclosed in Maruyama to obtain the predictable results of using the right metrics to compare against the threshold. The motivation for doing so would be to be more accurate, when comparing the average size to the threshold, write statistics should be used when its for data written to the block storage area and read statistics should be used when it is for data read from the block storage area.
Claims 4-8 and 17-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ohare (published October 03, 2019) and Kawaguchi (published February 28, 2013) in view of ARMANGAU et al. (US 2020/0042220) (hereinafter Armangau) (published February 06, 2020).
Regarding Claims 4 and 17, the combination of Ohare and Kawaguchi disclosed the device of claim 1 and method of claim 14, but does not explicitly state wherein an operation of the data block that can be de-duplicated is based on an in-line phase.
Armangau discloses wherein an operation of the data block that can be de-duplicated is based on an in-line phase.
“Described below is a technique for use in managing inline data de-duplication in storage systems, which technique may be used to provide, among other things, receiving a request to write data at a logical address of a file in a file system of a storage system, determining whether the data can be de-duplicated to matching data residing on the storage system in a compressed format, and based on the determination, using a block mapping pointer associated with the matching data to de-duplicate the data, where the block mapping pointer includes a block mapping of a set of compressed data extents and information regarding location of the matching data within the set of compressed data extents” (Armangau [0021])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the in-line deduplication of Armangau with the system in the combination of Ohare and Kawaguchi. The motivation for doing so would be to provide more storage space as disclosed by Armangau. “In at least some implementations in accordance with the current technique described herein, the use of managing inline data de-duplication in storage systems technique can provide one or more of the following advantages: providing inline de-duplication to an existing inline compression process, re-using existing inline compression block mapping instead of adding a new de-duplication block mapping object, and providing more storage space to map data blocks by using less space for block mapping objects” (Armangau [0026])
Regarding Claims 5 and 18, the combination of Ohare and Kawaguchi disclosed the device of claim 1 and method of claim 14, but does not explicitly state wherein the processor is further configured to de-duplicate and compress the data block to obtain a resulting data block.
Armangau discloses wherein the processor is further configured to de-duplicate and compress the data block to obtain a resulting data block.
“Data storage systems typically employ data compression and de-duplication techniques to store data more efficiently. In a conventional data storage system, a data stream including a plurality of data segments is received, and a data segment identifier (ID) (e.g., hash value) is generated for each received data segment. The data segment ID is compared with other data segment IDs in an ID index (or ID dictionary or index table). The data segment IDs in the ID dictionary correspond to unique (or de-duplicated) data segments within a de-duplication domain previously stored by the data storage system … If the data segment ID of the received data segment does not match any of the data segment IDs in the ID dictionary, then the received data segment is compressed for storage on the data storage system” (Armangau [0009] the resulting data block is the compressed received data segment after deduplication)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the deduplication and compression of Armangau with the system in the combination of Ohare and Kawaguchi. The motivation for doing so would be to provide more storage space as disclosed by Armangau. “In at least some implementations in accordance with the current technique described herein, the use of managing inline data de-duplication in storage systems technique can provide one or more of the following advantages: providing inline de-duplication to an existing inline compression process, re-using existing inline compression block mapping instead of adding a new de-duplication block mapping object, and providing more storage space to map data blocks by using less space for block mapping objects” (Armangau [0026])
Regarding Claims 6 and 19, Ohare and Kawaguchi further discloses wherein the processor is further configured to compare a first size resulting from de-duplication and compression of the data block with a second size resulting from the large block compression of the data block.
“In the system depicted in FIG. 3, it is possible for a user to set a deduplication threshold value based on data size. If for example, a user wanted to prevent duplicative write operations on a block-by-block basis, i.e., at a 128 K aligned deduplication value, all data chunks pictured in FIG. 3 would be written to storage device 130 even though duplicate values of data chunks A-L exist in storage blocks 131-133 as compared with storage blocks 134-137” (Ohare [0032] see paragraph [0008] large block compression is applied for 128k blocks, array drives 130 shows the size from large block compression)
“FIG. 6 depicts a system employing 32 K aligned deduplication for data blocks 610. In this system, data blocks 611-613 are physical written in data storage 630. Pointers 621a-621m are stored in a virtual table of pointers and allow hosts to physically locate the data in data blocks 611-613. In the 32 K aligned deduplication system of FIG. 6, when it comes time to determine if un written data block 614 should be written to physical storage 630, this determination will be made on a 32 KB granularity basis, meaning each data chunk will be individually evaluated to determine if it has already been written to physical storage 630” (Ohare [0050] see paragraph [0006] for compression of different blocks sizes as examples, 32k aligned deduplication using the hash and compression for the blocks, array drives 630 shows the size required from deduplication)
“In the second embodiment, a storage subsystem stores and distributes data to plural deduplication storage devices. The deduplication storage device mounts the storage subsystem to store data. The storage subsystem also has deduplication function (but the page size is larger than the deduplication storage device), so deduplicated data by deduplication storage devices can be deduplicated again by the storage subsystem. To optimize the possibility of deduplication, the deduplication storage derives sort the data with reconciliation” (Kawaguchi [0068] the storage size for data of the two deduplication method would be compared to see which one is more optimized for the storage)
Regarding Claims 7 and 20, Ohare further discloses wherein the processor is further configured to store the data block using the large block compression in response to the first size being larger than or equal to the second size.
“The systems and methods herein would look to hash table 250 to determine if a hash for data chunk “$” could be found. Once no hash for “$” was found, the entire data block 214 would be written to physical data storage 230 at data block 234” (Ohare [0044] when the resulting size of the data block is the same it would be obvious to choose the method that requires less labor, in this case just (large block) compression rather than deduplication and compression)
Regarding Claim 8, Ohare further discloses wherein the processor is further configured to: de-duplicate a first part of the sub-blocks of the data block and compress a second part of the sub-blocks to obtain the resulting data block; and store the resulting data block to de-duplicate and compress the data block.
“In unwritten data block 614, data chunk “$” will be recorded in physical storage at the location indicated by pointer 321m. Data chunk “A,” however, will not be recorded because the deduplication system will determine that data chunk “A” has already been stored in physical storage 630. As a result, pointer 622a will be recorded in a virtual table of pointers showing the connection between unwritten data chunk “A” and its location in physical storage 630” (Ohare [0050] subblock/data chunks A, B, and C are deduplicated from block 614 and the stored data block only includes $)
Regarding Claim 21, Kawaguchi and Ohare further discloses reducing a size of the data block that is stored in the block storage device using similarity de-duplication based on the similarity hash.
“In the second embodiment, a storage subsystem stores and distributes data to plural deduplication storage devices. The deduplication storage device mounts the storage subsystem to store data. The storage subsystem also has deduplication function (but the page size is larger than the deduplication storage device), so deduplicated data by deduplication storage devices can be deduplicated again by the storage subsystem. To optimize the possibility of deduplication, the deduplication storage derives sort the data with reconciliation” (Kawaguchi [0068])
“In unwritten data block 614, data chunk “$” will be recorded in physical storage at the location indicated by pointer 321m. Data chunk “A,” however, will not be recorded because the deduplication system will determine that data chunk “A” has already been stored in physical storage 630. As a result, pointer 622a will be recorded in a virtual table of pointers showing the connection between unwritten data chunk “A” and its location in physical storage 630” (Ohare [0050] subblock/data chunks A, B, and C are deduplicated from block 614 and the stored data block only includes $ which reduces the size of the data block)
Regarding Claim 22, Kawaguchi and Ohare further discloses further comprising: de-duplicating a first part of the sub-blocks of the data block and compress a second part of the sub-blocks to obtain the resulting data block; and storing the resulting data block to de-duplicate and compress the data block.
“Block level storage arrays typically perform compression and deduplication at 4 K, 8 K, 16 K, and 128 K blocks. In these increments, the smaller blocks receive better deduplication, while the larger blocks receive better compression” (Ohare [0006] block sizes provide are just an example and can also be done with 32k blocks)
“In unwritten data block 614, data chunk “$” will be recorded in physical storage at the location indicated by pointer 321m. Data chunk “A,” however, will not be recorded because the deduplication system will determine that data chunk “A” has already been stored in physical storage 630. As a result, pointer 622a will be recorded in a virtual table of pointers showing the connection between unwritten data chunk “A” and its location in physical storage 630” (Ohare [0050] subblock/data chunks A, B, and C are deduplicated from block 614 and the data block including only $ would be compressed and stored which reduces the size of the data block)
Regarding Claim 23, Kawaguchi and Ohare further discloses wherein the data block that is stored in the block storage device can be further reduced in size using the similarity de-duplication based on the similarity hash.
“In the second embodiment, a storage subsystem stores and distributes data to plural deduplication storage devices. The deduplication storage device mounts the storage subsystem to store data. The storage subsystem also has deduplication function (but the page size is larger than the deduplication storage device), so deduplicated data by deduplication storage devices can be deduplicated again by the storage subsystem. To optimize the possibility of deduplication, the deduplication storage derives sort the data with reconciliation” (Kawaguchi [0068])
“In unwritten data block 614, data chunk “$” will be recorded in physical storage at the location indicated by pointer 321m. Data chunk “A,” however, will not be recorded because the deduplication system will determine that data chunk “A” has already been stored in physical storage 630. As a result, pointer 622a will be recorded in a virtual table of pointers showing the connection between unwritten data chunk “A” and its location in physical storage 630” (Ohare [0050] subblock/data chunks A, B, and C are deduplicated from block 614 and the stored data block only includes $ which reduces the size of the data block)
Claim 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ohare (published October 03, 2019) and Kawaguchi (published February 28, 2013) in view of Kozlovsky et al. (US 2017/0083581) (hereinafter Kozlovsky) (published March 23, 2017).
Regarding Claim 13, the combination Ohare and Kawaguchi disclosed the device of claim 10, but does not explicitly state wherein an operation that the data block stored in the block storage device can be further reduced in size using the similarity de-duplication is based on an offline phase.
Kozlovsky and Ohare discloses wherein an operation that the data block stored in the block storage device can be further reduced in size using the similarity de-duplication is based on an offline phase.
“There might be different options for the schedule and the presence of the deduplication in the I/O path. For example, the restore algorithm may be implemented using an inline deduplication option (where incoming data stream is deduplicated), an online deduplication option (where data is subject to deduplication once the data arrives to storage), or an offline deduplication option (where deduplication is performed according to some schedule)” (Kozlovsky [0026])
“In unwritten data block 614, data chunk “$” will be recorded in physical storage at the location indicated by pointer 321m. Data chunk “A,” however, will not be recorded because the deduplication system will determine that data chunk “A” has already been stored in physical storage 630. As a result, pointer 622a will be recorded in a virtual table of pointers showing the connection between unwritten data chunk “A” and its location in physical storage 630” (Ohare [0050] subblock/data chunks A, B, and C are deduplicated from block 614 and the stored data block only includes $ which reduces the size of the data block)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine offline deduplication option in Kozlovsky with the system in the combination Ohare and Kawaguchi. The motivation for doing so would be to improve performance. Offline deduplication would provide better performance and lower resource usage as it does not require extra overhead when processing data and also allows for scheduling flexibility as it is not required when the data arrives and can be performed during off-peak times.
Response to Arguments
Claim Rejections - 35 U.S.C. § 112
Applicant’s arguments, see page 7 of remarks, filed December 08, 2025, with respect to claims 1-8, 10, and 13-23 have been fully considered and are persuasive. The 35 U.S.C. § 112 rejection of claims 1-8, 10, and 13-23 has been withdrawn.
Claim Rejections - 35 U.S.C. § 103
Applicant's arguments filed December 08, 2025 have been fully considered but they are not persuasive.
Applicant Argues:
a) (page 9 bottom) In rejecting independent claim 1, the Examiner asserts that O 'hare writes data in 128 kilobyte aligned blocks in a first operating state in a storage subsystem but admits that O'hare does not disclose a first operating phase nor does he disclose de-duplication. See Office Action, p. 5. Instead, the Examiner asserts that Kawaguchi's paragraph 68 discloses a first operating phase and also discloses a deduplication function. See id., p. 5 and 6. While Kawaguchi states that deduplication is possible, Kawaguchi does not store, in a second operating phase after the large block compression of the first operating phase and based on the similarity hash, all the sub-blocks for further reduction in size in a first disk space using similarity de-duplication and further compression when the first disk space is less than a second disk space:
With respect to (a), applicant appears to misinterpret the rejection. Ohare does disclose de-duplication as referenced in the rejection, what Ohare does not disclose is the first operating phase, and the performing of deduplication in different operating phases. While Kawaguchi discloses the performing of deduplication, it does not disclose the details of what is performed during deduplication, the details of the similarity deduplication is disclosed by Ohare in at least Fig. 6 and paragraph [0050].
b) (page 10 bottom) The Examiner alleges that Kawaguchi deduplicates data in a second operating phase, while O'hare is cited for disclosing aligned duplicating data of 32 kilobyte data blocks using pointers. See id., p. 6. However, nowhere does Kawaguchi disclose duplicating data and compressing the data in a second operating phase. Further, Kawaguchi does not disclose storing the sub-blocks of the data block using similarity de-duplication and further compressing after large block compression in a first operating phase. While O'hare is cited for a hash table and using pointers, the combination of O'hare and Kawaguchi does not disclose using large block compression when the data block cannot be de-duplicated and that the data block is to be written to a block storage area of the block storage device nor do they contemplate any mechanism for deduplication and further compression after large block compression in a first operating phase, besides merely stating that deduplication is possible. Further, Kawaguchi does not store, in a second operating phase after the large block compression of the first operating phase and based on the similarity hash, all the sub-blocks for further reduction in size in a first disk space using similarity de-duplication and further compression when the first disk space is less than a second disk space.
With respect to (b), the cited portion of Kawaguchi (paragraph [0068]) explicitly states “The storage subsystem also has deduplication function (but the page size is larger than the deduplication storage device), so deduplicated data by deduplication storage devices can be deduplicated again by the storage subsystem”. The explicitly mentioning of the data being deduplicated again means that there is at least two different instances at which the data is deduplicated. The first instance of deduplication would be when it is first deduplicated and is interpreted to be the first operating phase, the second instance of deduplication would be when it is deduplicated again and is interpreted to be the second operating phase. Ohare discloses the two different types of deduplication and it would be obvious to one of ordinary skill in the art to use the different types of deduplication during the two instances of deduplication and to choose the storage method of the deduplication method that uses less storage.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
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 SIDNEY LI whose telephone number is (571)270-5967. The examiner can normally be reached Monday to Friday 10:00 AM to 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Arpan P Savla can be reached at (571) 272-1077. 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.
/S.L./Examiner, Art Unit 2137
/Arpan P. Savla/Supervisory Patent Examiner, Art Unit 2137
Prosecution Insights