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 .
Claims 1-20 are presented for examination.
The claims and only the claims form the metes and bounds of the invention. “Office personnel are to give claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in the specification but not recited in the claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969)” (MPEP p 2100-8, c 2, I 45-48; p 2100-9, c 1, l 1-4). The Examiner has full latitude to interpret each claim in the broadest reasonable sense. The Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 02 January 2026 has been entered.
Response to Arguments
Applicant’s remarks/amendment was filed on 02 January 2026.
Applicant’s arguments have been considered but they are not persuasive. However, the Examiner welcomes any suggestion(s) Applicant may have on moving prosecution forward. The Examiner’s contact information is in the Conclusion of this office action.
Applicant argues:
It is clear from the above reproduced paragraph of the originally-filed application that the "header" is “associated with the first data content version". A person of skill in the art of data management would readily appreciate that the "header" is therefore separate from the "first data content version [that] includes the chunk compression group," and therefore the application at least implicitly discloses "the header does not include the data from the object and the data from the one or more other objects." Independent claim 1 (as an example) also provides for "identifying, by the data platform, a chunk compression grouping [i.e., group] storing the selected data chunk including the data from the object and one or more data chunks including data from one or more other objects, wherein the chunk compression grouping includes the
selected data chunk compressed together with the one or more data chunks." Put another way, because the specification describes that the header is separate from the first data content version that includes the chunk compression group, and the claim 1 defines the chunk compression group [i.e., grouping] as "storing the selected data chunk including the data from the object and one or more data chunks including data from one or more other objects," this at least implicitly supports the amendments to the independent claims.
In response, the Examiner submits:
The independent claims recite “wherein the header does not include the data from the object and the data from the one or more other objects”.
Azzarella teaches a header that indicates a chunk compression grouping is provided (Azzarello: at least ¶0025; “the header 234 includes a signature; a compression type; a checksum; and compression mapping information. Among other uses, the FCF program 10 uses header 234 to identify whether a file is compressed”), wherein the header does not include data from the object and the data from the one or more other objects (Azzarello: at least ¶0025; “the header 234 includes a signature; a compression type; a checksum; and compression mapping information. Among other uses, the FCF program 10 uses header 234 to identify whether a file is compressed”).
Azzarello’s header does not include data from the object plus the data from the one or more other objects.
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.
Claims 1, 3, 9-10, 12, 18-19 are rejected under U.S.C 103 as being unpatentable over US PGPUB 2007/0208893 by Azzarello et al. (“Azzarello”) in view of USPGPUB 2022/0374395 by Scrivano et al. (“Scrivano”).
As to Claim 1, Azzarello teaches a method, comprising: determining, by a data platform implemented by a computing system, to send a selected data chunk including data from an object to a destination system (Azzarello: at least ¶0038; “file system then returns the compressed data (chunks 2 and 3)” and “decompresses the data, truncates any extra data that was not requested and then returns the data as requested”; ¶0040 further discloses “operation 410 where a read request is received” and ¶0042 further discloses “operation 460 where the data is returned”);
identifying, by the data platform, a chunk compression grouping storing the selected data chunk including data from the object and one or more data chunks including data from one or more other objects (Azzarello: at least ¶¶0037-0038; “chunk 1 in the original uncompressed file 310 was reduced in size by 24 k; chunk 2 was reduced in size by 3 k; chunk 3 was reduced in size by 4 k; and chunk 4 was reduced in size by 23 k” and “compressed data (chunks 2 and 3) of compressed file 312”; ¶0037 also discloses “when uncompressed file 310 is compressed to become compressed file 312 a header 320 is added to the file and each chunk (1-4) within uncompressed file 310 is compressed and stored after header 320”; note: header as one or more other objects); and
based at least in part on one or more metrics associated with the chunk compression grouping (Azzarello: at least ¶0032; “determines if the file in a compressed state meets a minimum compression threshold”), executing, by the data platform, a machine learning model to determine a data content version from a plurality of data content versions, wherein the plurality of data content versions include at least a data content version generated based on the chunk compression grouping to provide to the destination system (Azzarello: at least ¶0032; “if the file does not meet the minimum compression threshold then the file is stored as an uncompressed file”; ¶0029 further discloses “determine whether to compress the file before it written to the FAT volume”; note: data chunks meeting the minimum compression threshold would be compressed; file compressed as one content version and file uncompressed as another content version), wherein the generated data content version includes the chunk compression grouping (Azzarello: at least ¶¶0037-0038; “chunk 1 in the original uncompressed file 310 was reduced in size by 24 k; chunk 2 was reduced in size by 3 k; chunk 3 was reduced in size by 4 k; and chunk 4 was reduced in size by 23 k” and “compressed data (chunks 2 and 3) of compressed file 312”; ¶0037 also discloses “when uncompressed file 310 is compressed to become compressed file 312 a header 320 is added to the file and each chunk (1-4) within uncompressed file 310 is compressed and stored after header 320”) and a header that indicates a chunk compression grouping is provided (Azzarello: at least ¶0025; “the header 234 includes a signature; a compression type; a checksum; and compression mapping information. Among other uses, the FCF program 10 uses header 234 to identify whether a file is compressed”), wherein the header does not include data from the object and the data from the one or more other objects (Azzarello: at least ¶0025; “the header 234 includes a signature; a compression type; a checksum; and compression mapping information. Among other uses, the FCF program 10 uses header 234 to identify whether a file is compressed”; note: Azzarello’s header does not include data from the object plus the one or more other objects).
Azzarello does not explicitly disclose, but Scrivano discloses wherein the chunk compression grouping includes the selected data chunk compressed together with the one or more data chunks (Scrivano: at least ¶0030; “the portions of data between each compression start point of the set of merged compression start points (CSPs) 260 are compressed to create a compressed archive file 262”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Scrivano’s feature of wherein the chunk compression grouping includes the selected data chunk compressed together with the one or more data chunks (Scrivano: at least ¶0030) with Azzarello’s method.
The suggestion/motivation for doing so would have been to utilize “… a multi-function algorithm to segment and compress” data that may lower “system execution latency, excessive storage and memory access, and provide improved performance of the computer system” (Scrivano: at least ¶0017).
Claim 10 (a computer system claim) corresponds in scope to claim 1, and is similarly rejected.
Claim 19 (a non-transitory computer-readable storage media claim) corresponds in scope to claim 1, and is similarly rejected.
As to Claim 3, Azzarello and Scrivano teach the method of claim 1, further comprising sending, by the data platform, the data content version that includes the chunk compression grouping to the destination system (Azzarello: at least ¶0029; “determine whether to compress the file before it written to the FAT volume”; ¶0042 also discloses “operation 430 where the requested data is retrieved from the uncompressed file” and ¶0043 discloses “requested data is located and retrieved from the compressed file”).
Claim 12 (a computer system claim) corresponds in scope to claim 3, and is similarly rejected.
As to Claim 9, Azzarello and Scrivano teach the method of claim 1, further comprising receiving, by the data platform, a request to perform a data management operation with respect to the object (Azzarello: at least ¶0038; “file system then returns the compressed data (chunks 2 and 3)” and “decompresses the data, truncates any extra data that was not requested and then returns the data as requested”; ¶0040 further discloses “operation 410 where a read request is received” and ¶0042 further discloses “operation 460 where the data is returned”), wherein determining to send the selected data chunk including the data from the object to the destination system is responsive to receiving the request to perform the data management operation (Azzarello: at least ¶0019; “for example, FCF program 10 is configured to individually intercept calls to the FAT file system, perform the compression and decompression tasks, and return the data to/from the volume”; ¶0030 further discloses “moving a file across volumes involves copying the file to the new volume and then deleting the file on the original volume”; note: compress/decompress tasks and returning data as example of data management operation; copying and deleting as example of management operations).
Claim 18 (a computer system claim) corresponds in scope to claim 9, and is similarly rejected.
Claims 2, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2007/0208893 by Azzarello et al. (“Azzarello”) in view of USPGPUB 2022/0374395 by Scrivano et al. (“Scrivano”), and further in view of US PGPUB 2012/0158647 by Yadappanavar et al. (“Yadappanavar”).
As to Claim 2, Azzarello and Scrivano teach the method of claim 1, further comprising: decompressing, by the data platform, the chunk compression grouping to generate a decompressed chunk compression grouping (Azzarello: at least ¶0038; “file system then returns the compressed data (chunks 2 and 3) of compressed file 312. The FCF program intercepts the returned data, decompresses the data”; ¶0044 also discloses “moving to operation 450, the retrieved data is decompressed using the specified compression algorithm”).
Azzarello and Scrivano do not explicitly disclose, but Yadappanavar discloses extracting, by the data platform, the selected data chunk from the decompressed chunk compression grouping (Yadappanavar: at least ¶0049; “extracts a portion of the decompressed data associated with the read request from the decompressed data. At step 708, the extracted data is transmitted to the client, and the read request is serviced”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Yadappanavar’s feature of extracting, by the data platform, the selected data chunk from the decompressed chunk compression grouping (Yadappanavar: at least ¶0049) with the method disclosed by Azzarello and Scrivano.
The suggestion/motivation for doing so would have been to perform “IO operations on files that include blocks and sub-blocks that are compressed” (Yadappanavar: at least ¶0046) upon request by a network client (Yadappanavar: at least ¶0046; “extracted data is transmitted to the client, and the read request is serviced”).
Claim 11 (a computer system claim) corresponds in scope to claim 2, and is similarly rejected.
Claim 20 (a non-transitory computer-readable storage media claim) corresponds in scope to claim 2, and is similarly rejected.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2007/0208893 by Azzarello et al. (“Azzarello”) in view of USPGPUB 2022/0374395 by Scrivano et al. (“Scrivano”), and further in view of US PGPUB 2015/0193342 by Ohara et al. (“Ohara”).
As to Claim 4, Azzarello and Scrivano teach the method of claim 1.
Azzarello and Scrivano do not explicitly disclose, but Ohara discloses wherein the one or more metrics correspond to one or more of: a compression ratio associated with the chunk compression grouping, a load on the computing system, a load on the destination system, or available network bandwidth (Ohara: at least ¶0116; “data compression processing in the background is performed in order … when the uncompressed data amount in the uncompression chunks exceeds a predetermined storage capacity, when the operation time of the storage system 1 reaches a predetermined period, or when any similar trigger event occurs”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ohara’s feature of wherein the one or more metrics correspond to one or more of: a compression ratio associated with the chunk compression grouping, a load on the computing system, a load on the destination system, or available network bandwidth (Ohara: at least ¶0116) with the method disclosed by Azzarello and Scrivano.
The suggestion/motivation for doing so would have been to “efficiently utilize” a storage apparatus “by increasing the available storage capacity of the storage apparatus” (Ohara: at least ¶0116).
Claim 13 (a computer system claim) corresponds in scope to claim 4, and is similarly rejected.
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2007/0208893 by Azzarello et al. (“Azzarello”) in view of USPGPUB 2022/0374395 by Scrivano et al. (“Scrivano”), and further in view of US PGPUB 2012/0158647 by Yadappanavar et al. (“Yadappanavar”), and further in view of US PGPUB 2013/0275396 by Condict et al. (“Condict”).
As to Claim 5, Azzarello and Scrivano teach the method of claim 1, wherein the data content version that includes the chunk compression grouping storing the selected data chunk and the one or more data chunks including the data from the one or more other objects is a first data content version (Azzarello: at least ¶¶0037-0038; “chunk 1 in the original uncompressed file 310 was reduced in size by 24 k; chunk 2 was reduced in size by 3 k; chunk 3 was reduced in size by 4 k; and chunk 4 was reduced in size by 23 k” and “compressed data (chunks 2 and 3) of compressed file 312”; ¶0037 also discloses “when uncompressed file 310 is compressed to become compressed file 312 a header 320 is added to the file and each chunk (1-4) within uncompressed file 310 is compressed and stored after header 320”; note: header as one or more other objects), and the plurality of data content versions includes: a third data content version that includes an uncompressed version of the selected data chunk that is generated by decompressing, by the computing system, the chunk compression grouping (Azzarello: at least ¶¶0043-0044; “When the file is compressed, the process flows to operation 440 where the requested data is located and retrieved from the compressed file” and “moving to operation 450, the retrieved data is decompressed using the specified compression algorithm”).
Azzarello and Scrivano do not explicitly disclose, but Yadappanavar discloses said third data content version that includes an uncompressed version of the selected data generated by extracting, by the computing system, the selected data chunk from the decompressed chunk compression grouping (Yadappanavar: at least ¶0049; “extracts a portion of the decompressed data associated with the read request from the decompressed data. At step 708, the extracted data is transmitted to the client, and the read request is serviced”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Yadappanavar’s feature of said third data content version that includes an uncompressed version of the selected data generated by extracting, by the computing system, the selected data chunk from the decompressed chunk compression grouping (Yadappanavar: at least ¶0049) with method disclosed by Azzarello and Scrivano.
The suggestion/motivation for doing so would have been to perform “IO operations on files that include blocks and sub-blocks that are compressed” (Yadappanavar: at least ¶0046) upon request by a network client (Yadappanavar: at least ¶0046; “extracted data is transmitted to the client, and the read request is serviced”).
Azzarello, Scrivano and Yadappanavar do not explicitly disclose, but Condict discloses a second data content version that includes a compressed version of the selected data chunk that is generated by decompressing, by the computing system, the chunk compression grouping, extracting, by the computing system, the selected data chunk from the decompressed chunk compression grouping, and compressing, by the computing system, the selected data chunk (Condict: at least ¶0005; “Compression processes can be compared using metrics, with the most common comparison made using a compression ratio (CR)”; ¶0056 further discloses “If the compression process used before the submission of the data to the selection system 200 is less effective than an option available to the selection system 200, the data is decompressed, and recompressed using the compression process selected with the aforementioned methodology”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Condict’s feature of a second data content version that includes a compressed version of the selected data chunk that is generated by decompressing, by the computing system, the chunk compression grouping, extracting, by the computing system, the selected data chunk from the decompressed chunk compression grouping, and compressing, by the computing system, the selected data chunk (Condict: at least ¶¶0005, 0056) with the method disclosed by Azzarello, Scrivano and Yadappanavar.
The suggestion/motivation for doing so would have been to “improve space saving from data compression by providing a plurality of compression processes, and optionally, one or more parameters for controlling operation of the compression processes and selecting from the plurality of compression processes and the parameters to satisfy resource limits, such as CPU usage and memory usage” (Condict: at least Abstract, ¶0029).
Claim 14 (a computer system claim) corresponds in scope to claim 5, and is similarly rejected.
Claims 6-8 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2007/0208893 by Azzarello et al. (“Azzarello”) in view of USPGPUB 2022/0374395 by Scrivano et al. (“Scrivano”), and further in view of US PGPUB 2012/0158647 by Yadappanavar et al. (“Yadappanavar”), and further in view of US PGPUB 2013/0275396 by Condict et al. (“Condict”), and further in view of US PGPUB 2003/0164975 by Aoyagj et al. (“Aoyagj”).
As to Claim 6, Azzarello, Scrivano, Yadappanavar and Condict teach the method of claim 5.
Azzarello, Scrivano, Yadappanavar and Condict do not explicitly disclose, but Aoyagj discloses wherein the machine learning module determines the data content version is the first data content version when the one or more metrics indicate a compression ratio associated with the selected data chunk is greater than a compression ratio threshold and a load on the computing system less than a threshold load (Aoyagj: at least ¶0189; “outputting the image data having the updated header information if the data amount of the image data is equal to or smaller than a predetermined value” but “recompressing the image data stored in the storage means at a second compression ratio higher than the first compression ratio if the data amount of the image data is equal to or larger than the predetermined value”; note: recompression at second ratio would not occur if storage load smaller than predetermined value).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Aoyagj’s feature wherein the machine learning module determines the data content version is the first data content version when the one or more metrics indicate a compression ratio associated with the selected data chunk is greater than a compression ratio threshold and a load on the computing system less than a threshold load (Aoyagj: at least ¶0189) with the method disclosed by Azzarello, Scrivano, Yadappanavar and Condict.
The suggestion/motivation for doing so would have been to allow for “compressing image data in real time into a data amount within the storage capacity of a memory” (Aoyagj: at least ¶0013).
Claim 15 (a computer system claim) corresponds in scope to claim 6, and is similarly rejected.
As to Claim 7, Azzarello, Scrivano, Yadappanavar, Condict and Aoyagj teach the method of claim 6, wherein the machine learning module determines the data content version is the second data content version when the one or more metrics indicate the compression ratio associated with the selected data chunk is greater than the compression ratio threshold and the load on the computing system greater than the threshold load (Aoyagj: at least ¶0189; “recompressing the image data stored in the storage means at a second compression ratio higher than the first compression ratio if the data amount of the image data is equal to or larger than the predetermined value”).
Claim 16 (a computer system claim) corresponds in scope to claim 7, and is similarly rejected.
As to Claim 8, Azzarello, Scrivano, Yadappanavar, Condict and Aoyagj teach the method of claim 7, wherein the machine learning module determines the data content version is the second data content version when the one or more metrics indicate the compression ratio associated with the selected data chunk is less than a compression ratio threshold (Condict: at least ¶0005; “Compression processes can be compared using metrics, with the most common comparison made using a compression ratio (CR)”; ¶0056 further discloses “If the compression process used before the submission of the data to the selection system 200 is less effective than an option available to the selection system 200, the data is decompressed, and recompressed using the compression process selected with the aforementioned methodology”; claim 16 further discloses “… recompresses the objects using a compression process in the lookup table and having a higher compression ratio”).
Claim 17 (a computer system claim) corresponds in scope to claim 8, and is similarly rejected.
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Huen Wong whose telephone number is (571) 270-3426. The examiner can normally be reached on Monday - Friday (10:00AM EST - 6:00PM EST). If attempts to reach the examiner by telephone are unsuccessful, the Examiner's supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300 for regular communications and after final communications.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.W/Examiner, AU 2168
08 January 2026
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168