Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination
2. 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 01/26/2026 has been entered.
DETAILED ACTION
3. This Office Action is in response to the filing with the office dated 01/26/2026.
Claims 1, 4, 8, 10, 15, 17 and 19 have been amended. Claims 7, and 14 have been cancelled. Claims 1, 8 and 15 are independent claims. Claims 1-6, 8-13 and 15-20 are pending in this office action.
Priority
4. Applicant’s claim for the benefit of parent Application No. 17/533,361filed on 11/23/2021 is acknowledged by the examiner.
Response to amendment/arguments
5. Applicant’s arguments with respect to the rejection of claims under 35 U.S.C. § 101 as the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more, have been fully considered. However, Examiner respectfully disagrees with the applicant’s argument. See response to arguments section. The rejection has been maintained.
6. Applicant’s arguments with respect to the rejection of claims under 35 U.S.C. § 102 (a)(i) and 103(a) have been fully considered but are moot in view of the new grounds of rejection.
Response to 101 Arguments
7. Applicant’s arguments on page 9 regarding 101 rejection states “Applicant submits that the recitations of amended independent claim 1 are integrated into a practical application and are, therefore, patent-eligible”.
Examiner respectfully disagrees as the amended claims are directed to an abstract idea categorized under mental processes. Courts consider a mental process if it “can be performed in the human mind, or by a human using a pen and paper. The limitation “wherein storing the container image at the container registry comprises updating metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file”. These limitations, at the high level of generality as drafted, would encompass a user to receive files that are to be stored at the container registry/ repository, and identify the duplicate files and upload only the non-duplicate files and reference/ point to the duplicate files from the previous image by updating the metadata which are essentially steps of generating and manipulating and storing data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
8. Claims 1-6, 8-13 and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Determining whether claims are statutory under 35 U.S.C. 101 involves a two-step analysis. Step 1 requires a determination of whether the claims are directed to the statutory categories of invention. Step 2 requires a determination of whether the claims are directed to a judicial exception without significantly more. Step 2 is divided into two prongs, with the first prong having a part 1 and part 2. See MPEP 2106; See 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG).
Pursuant to Step 1, claims 8-13 recite a system which are directed to the statutory category of a machine. Claims 15-20 recite a non-transitory computer readable storage medium, which are directed to a manufacture.
Regarding claims 1, 8 and 15 Pursuant to Step 2A, part 1, claims are analyzed to determine whether they are directed to an abstract idea. Under the 2019 PEG, claims are deemed to be directed to an abstract idea if they fall within one of the enumerated categories of (a) mathematical concepts, (b) certain methods of organizing human activity, and (c) mental processes. Here, claim 1 are directed to an abstract idea categorized under mental processes. Courts consider a mental process if it “can be performed in the human mind, or by a human using a pen and paper.” MPEP 2016(a)(2)(III). Courts also consider a mental process as one that can be performed in the human mind and is merely using a computer as a tool to perform the concept. MPEP 2016(a)(2)(III)(C)(3). Claim 1 recites a mental process because the recited steps recite actions of generating SQL query based on natural language query. but is recited at a high level of generality that merely used computers as a tool to perform the processes. See MPEP 2106(a)(2)(III). For example, claim 1 recites limitations of “receiving, from a client device, a container image…..” and “storing the container image at the container registry….”, “updating metadata ….”. These limitations, at the high level of generality as drafted, would encompass a user to receive files and deduplicate the files and then store them in data store are essentially steps of generating and manipulating data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Pursuant to Step 2A, part 2, claims are analyzed to determine whether the recited abstract idea is integrated into a practical application. In this case, as explained above, claim 1 merely recite a mental process. These limitations describe receiving plurality of files and deduplicate them and store them in a data store. While claim 1 recites additional components in the form of processors, a memory, and system, these components are recited at a high level of generality, which do not add meaningful limits on the recited abstract idea to integrate it into a practical application by providing an improvement to the functioning of a computer or technology, implementing the abstract idea with a particular machine or manufacture that is integral to the claim, effecting a transformation or reduction of a particular article to a different state or thing, nor applying the abstract idea in some meaningful way beyond linking its use to computer technology. See 2019 PEG. Neither of these additional limitations recite sufficient limitations to adequately convey the asserted improvement of the claimed invention. Accordingly, even in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the recitation of generic computing components is still mere instructions to apply the exception under MPEP 2106.05(f) and does not provide significantly more. Considering the additional elements in combination and the claim as a whole does not change the analysis, and does not amount to significantly more. Thus the claims are abstract.
Regarding claim 2 recite “determining that at least one file of the plurality of files is the duplicate….”. These limitations, at the high level of generality as drafted, would encompass a user to look at the files and determine if they are duplicate files is essentially steps of generating and manipulating data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Regarding claims 3, 9, 16 recite “rebuilding the container image to include each of the plurality of files of the container image in view of the previously stored container image file”. These limitations, at the high level of generality as drafted, would encompass a user to look at the files and determine if they are duplicate files based on the previously store data is essentially steps of generating and manipulating data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Regarding claims 4, 10 17 recite “adding the reference in metadata of the container image to the previously stored container image file in place of the at least one file of the plurality of files not stored with the container image at the container registry”. These limitations, at the high level of generality as drafted, would encompass a user to look at the files and determine if they are duplicate files based on the previously store data add a reference to the stored data is essentially steps of generating and manipulating data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Regarding claims 5, 11 and 18 recite “wherein determining that at least one file of the plurality of files is the duplicate of a previously stored container image file comprises: determining if a checksum of one or more previously stored container image files at the container registry matches a checksum of one of the plurality of files of the container image”. These limitations, at the high level of generality as drafted, would encompass a user to look at the files and determine if they are duplicate files using the checksum values of the files is essentially steps of generating and manipulating data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Regarding claims 6, 12 and 19 recite “wherein each file of the plurality of files is in a searchable compressed format”. These limitations, at the high level of generality as drafted, would encompass a user to search for the files based on the plurality of files that are in a searchable compressed format is essentially steps of generating and manipulating data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Regarding claims 13 and 20 recite “storing the files …and updating the metadata…”. These limitations, at the high level of generality as drafted, would encompass a user to store the files and update the metadata is essentially steps of generating and manipulating data at a high level of generality, which can be performed by a person using a computer as a tool. which is mentally performable as an evaluation or judgement. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Claim Rejections - 35 U.S.C. § 103
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 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.
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.
9. Claims 1-6, 8-13 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over LI; GUANG CHENG (US 20210141760 A1) in view of Scrivano; Giuseppe (US 20190251190 A1) and in further view of Suarez; Anthony Joseph (US 20170177860 A1).
Regarding independent claim 1, LI; GUANG CHENG (US 20210141760 A1) teaches, a method comprising: receiving, from a client device, a container image with a duplicate file removed from the container image, wherein the container image comprises a plurality of files (Fig. 3, Paragraphs [0030]- [0032] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. In an example, image manager 122 queries file index 136 for a file identifier and checksum of each file to determine whether there is an entry in file index 136 with the same file identifier and checksum. For example, if the metadata and checksums indicate that the container image contains the file “/usr/lib64/libc-2.17.20” with the checksum “a188418f0f8cd2a1fcfa21856a986044”, then image manager 122 may determine that this file is already present in data store 130, as shown in file index 400 of FIG. 4. As such, image manager 122 determines that this file does not need to be stored for the container image, and updates a file list for the container image to indicate the location of the existing version of the file in data store 130. Also see Paragraph [0016]);
storing, by a processing device and at the container registry, the container image including the reference to the previously stored container image file at the container registry (Paragraphs [0016], [0017] discloses, storing the container image including the reference to the previously stored container image file).
LI et al fails to explicitly teach, in an individually compressed and searchable format, and wherein the plurality of files are appended together in the individually compressed and searchable format, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate fil.
Scrivano; Giuseppe (US 20190251190 A1) teaches, wherein the plurality of files in an individually compressed and searchable format, (Paragraph [0029] The one or more files 108 may be in any format, including archived or compressed or archived and compressed formats. For example, the one or more files 108 may be of type .gz, .bz, .tar, .zip, .rar, etc.) [0030] The first file 110 includes a checksum 112a, which is a unique text string that may be used to identify a file. For example, MD5 (Message Digest 5) and SHA (Secure Hash Algorithm) may be used to generate a checksum or a hash value, which may be used to verify files (i.e., search for files and determine if they are duplicate or not). Also see Paragraph [0056], [0057] In response to a checksum match, a link may be created to the particular file corresponding to the matching checksum. As shown in FIG. 3, the checksum “18anxha482hjk” matches with the file path “/var/lib/containers/storage/ostree/os-svcs/18anxha482hjk.” (i.e., the checksum is a searchable compressed format without using the full file path ) The file path indicates that the matching file is located in or associated with repository 312 for operating system services. Like repository 316, the repository 312 for operating system services may also include one or more layers 314 in an expanded state. As shown, the layer 314 includes four files, a first file “41s32dfw1979,” a second file “b473605rx7084,” a third file “18anxha482hjk,” and a fourth file “ct9aeg6fd3sfe.” Here, the checksum of the third file in layer 314 is identical to the checksum “18anxha482hjk” of the extracted file “svc3.exe.” Thus, if an image in a repository such as an Applications repository 316 requires access to the file with checksum “18anxha482hjk,” a link pointing to the location or repository where the file may be located may be created in the image requiring access to the file, such that the file may be accessed via the link);
and wherein the plurality of files are appended together in the individually compressed and searchable format; wherein the plurality of files of the container image are stored in the individually compressed and searchable format. (Paragraph [0015] In more detail, a container image layer may be extracted to a data storage location of a data storage device such as a storage file path of a network data storage device or a local data storage device. For example, if a first container image layer is “layer1.gz,” then the extracting may include decompressing and/or dearchiving “layer1.gz” into its respective files (i.e., plurality of files are appended together in a layer which is compressed and searchable layer) (i.e., the plurality of files are appended/ added/ included in a layer).Also see Paragraph [0027], [0048]-[0051]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of LI et al by providing in an individually compressed and searchable format, and wherein the plurality of files is appended together in the individually compressed and searchable format, as taught by Scrivano et al (Fig. 3 Paragraphs [0030], [0056]) .
One of the ordinary skill in the art would have been motivated to make this modification, so to reduce costs, to make container image storage more efficient. For example, container image storage may be made more efficient if multiple container images which require access to a file in common could all be made to use the same, single file, instead of duplicating the file in each image or each image layer. Another way to more efficiently store image files would be to ensure that duplicate files are not created—or if they are, that they are removed-when different layers in the same image are built using the same file. Particularly for container images, the same file can be present in multiple layers and stored separately on the file system (Fig. 3 Paragraph [0013]).
LI et al and Scrivano et al fails to explicitly teach, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, at the container registry, the container image including the reference to the previously stored container image file at the container registry, and wherein to store the container image at the container registry, the processing device is to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file.
Suarez; Anthony Joseph (US 20170177860 A1) teaches, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, at the container registry, the container image including the reference to the previously stored container image file at the container registry (Fig 3 and related paragraphs discloses, container image includes a reference to a previously stored container image file at a container registry (Examiner interprets container image file as container image at a time. Examiner interprets container registry as repository, see [0046]. Examiner interprets files in container image as layers in the image at a time));
and wherein to store the container image at the container registry, the processing device is to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file (Fig. 3 and related paragraphs discloses, that layers 12 and 22 may be found with the second version 346B and that layers 31-61 may be found with the initial version 346A). (i.e., when the container image is updated, only the changed files/ layers are stored and layers/ files 31-61 are duplicate files and the metadata indicates, those files needs to be accessed from initial version). Also see [0034]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of LI et al by providing wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, at the container registry, the container image including the reference to the previously stored container image file at the container registry, and wherein to store the container image at the container registry, the processing device is to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file, as taught by Suarez et al (Fig. 3 and related paragraphs).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, container registry storage is optimized and bandwidth needed for uploading container images may be reduced. The registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries as taught by Suarez et al (Paragraphs [0027], [0053]).
Regarding dependent claim 2, LI et al, Scrivano and Suarez et al teach, the method of claim 1.
Scrivano et al further teaches, further comprising: determining that at least one file of the plurality of files is the duplicate file by comparing an identifier of each of the plurality of files of the container image in the individually compressed and searchable format in a first list of files to a plurality of previously stored container image files, wherein each of the plurality of previously stored container image files is stored in the individually compressed and searchable format (Fig. 3, Paragraphs [0047]-[0051] discloses, determining that at least one file of the plurality of files is the duplicate of a previously stored container image file by comparing the identifier (Examiner interprets identifier as a layer) in the individually compressed and searchable format)).
LI et al further teaches, further comprising: determining that at least one file of the plurality of files is the duplicate file by comparing an identifier of each of the plurality of files of the container image in the individually compressed and searchable format in a first list of files to a plurality of previously stored container image files (Fig. 3, Paragraphs [0030]- [0032] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. In an example, image manager 122 queries file index 136 for a file identifier and checksum of each file to determine whether there is an entry in file index 136 with the same file identifier and checksum. For example, if the metadata and checksums indicate that the container image contains the file “/usr/lib64/libc-2.17.20” with the checksum “a188418f0f8cd2a1fcfa21856a986044”, then image manager 122 may determine that this file is already present in data store 130, as shown in file index 400 of FIG. 4. As such, image manager 122 determines that this file does not need to be stored for the container image, and updates a file list for the container image to indicate the location of the existing version of the file in data store 130. Also see Paragraph [0016]).
and providing, to the client device, a second list of files comprising the reference to the previously stored container image file(Fig. 4. 5 Paragraphs [0030]-[0034] discloses, providing updated list of files comprising the references to the previously stored image file. Also see Paragraph [0017]).
Regarding dependent claim 3, LI et al, Scrivano and Suarez et al teach, the method of claim 2.
LI et al further teaches, (Paragraph [0016] discloses, determining plurality of files is the duplicate file by comparing the checksums).
Regarding dependent claim 4, LI et al, Scrivano and Suarez et al teach, the method of claim 1.
LI et al further teaches, further comprising: adding wherein the reference is included in metadata of the container image to the previously stored container image file in place of the at least one file of the plurality of files not stored with the container image at the container registry duplicate file in the metadata of the container image (Paragraph [0031] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. Also see Paragraphs [0016], [0017]).
Regarding dependent claim 5, LI et al, Scrivano and Suarez et al teach, the method of claim 1.
LI et al further teaches, wherein determining that at least one file of the plurality of files is the duplicate of a previously stored container image file (Paragraph [0016] The image server then determines whether any files in the container image are duplicates of files already stored in a repository managed by the image server) further comprises comprising: rebuilding the container image to include each of the plurality of files of the container image in view of the previously stored container image file determining if a checksum of one or more previously stored container image files at the container registry matches a checksum of one of the plurality of files of the container image (Paragraph [0016] The image server then determines whether any files in the container image are duplicates of files already stored in a repository managed by the image server. In an example, the image server compares file identifiers and checksums received from the client device with file identifiers and checksums of files in the repository in order to identify matching files. Also see [0018]).
Regarding dependent claim 6, LI et al, Scrivano and Suarez et al teach, the method of claim 1.
LI et al further teaches, wherein receiving the container image corresponds to a push request (Paragraph [0021] discloses, receiving and storing container image corresponds to push and pull request).
Regarding independent claim 8, LI; GUANG CHENG (US 20210141760 A1) teaches, a system comprising: a memory; and a processing device, operatively coupled to the memory (Fig. 7 [0050] System 700 includes a central processing unit (CPU) 702, one or more I/O device interfaces 704 (that may provide connections for various I/O devices 704, such as keyboards, displays, mouse devices, and the like) to the system 700, network interface 706 (e.g., a physical network interface card), memory 708, storage 710, and an interconnect 712)), to: receive, from a client device, a container image with a duplicate file removed from the container image (Fig. 3, Paragraphs [0030]- [0032] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. In an example, image manager 122 queries file index 136 for a file identifier and checksum of each file to determine whether there is an entry in file index 136 with the same file identifier and checksum. For example, if the metadata and checksums indicate that the container image contains the file “/usr/lib64/libc-2.17.20” with the checksum “a188418f0f8cd2a1fcfa21856a986044”, then image manager 122 may determine that this file is already present in data store 130, as shown in file index 400 of FIG. 4. As such, image manager 122 determines that this file does not need to be stored for the container image, and updates a file list for the container image to indicate the location of the existing version of the file in data store 130. Also see Paragraph [0016]);
store, at the container registry, the container image including the reference to the previously stored container image file at the container registry (Paragraphs [0016], [0017] discloses, storing the container image including the reference to the previously stored container image file).
LI et al fails to explicitly teach, wherein the container image comprises a plurality of files in an individually compressed and searchable format, and wherein the plurality of files are appended together in the individually compressed and searchable format, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; wherein the plurality of files of the container image are stored in the individually compressed and searchable format.
Scrivano; Giuseppe (US 20190251190 A1) teaches, wherein the container image comprises a plurality of files in an individually compressed and searchable format (Paragraph [0029] The one or more files 108 may be in any format, including archived or compressed or archived and compressed formats. For example, the one or more files 108 may be of type .gz, .bz, .tar, .zip, .rar, etc.) [0030] The first file 110 includes a checksum 112a, which is a unique text string that may be used to identify a file. For example, MD5 (Message Digest 5) and SHA (Secure Hash Algorithm) may be used to generate a checksum or a hash value, which may be used to verify files (i.e., search for files and determine if they are duplicate or not). Also see Paragraph [0056], [0057] In response to a checksum match, a link may be created to the particular file corresponding to the matching checksum. As shown in FIG. 3, the checksum “18anxha482hjk” matches with the file path “/var/lib/containers/storage/ostree/os-svcs/18anxha482hjk.” (i.e., the checksum is a searchable compressed format without using the full file path ) The file path indicates that the matching file is located in or associated with repository 312 for operating system services. Like repository 316, the repository 312 for operating system services may also include one or more layers 314 in an expanded state. As shown, the layer 314 includes four files, a first file “41s32dfw1979,” a second file “b473605rx7084,” a third file “18anxha482hjk,” and a fourth file “ct9aeg6fd3sfe.” Here, the checksum of the third file in layer 314 is identical to the checksum “18anxha482hjk” of the extracted file “svc3.exe.” Thus, if an image in a repository such as an Applications repository 316 requires access to the file with checksum “18anxha482hjk,” a link pointing to the location or repository where the file may be located may be created in the image requiring access to the file, such that the file may be accessed via the link);
and wherein the plurality of files are appended together in the individually compressed and searchable format; wherein the plurality of files of the container image are stored in the individually compressed and searchable format (Paragraph [0015] In more detail, a container image layer may be extracted to a data storage location of a data storage device such as a storage file path of a network data storage device or a local data storage device. For example, if a first container image layer is “layer1.gz,” then the extracting may include decompressing and/or dearchiving “layer1.gz” into its respective files (i.e., plurality of files are appended together in a layer which is compressed and searchable layer) (i.e., the plurality of files are appended/ added/ included in a layer).Also see Paragraph [0027], [0048]-[0051]);
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of LI et al by providing in an individually compressed and searchable format, and wherein the plurality of files is appended together in the individually compressed and searchable format, as taught by Scrivano et al (Fig. 3 Paragraphs [0030], [0056]) .
One of the ordinary skill in the art would have been motivated to make this modification, so to reduce costs, to make container image storage more efficient. For example, container image storage may be made more efficient if multiple container images which require access to a file in common could all be made to use the same, single file, instead of duplicating the file in each image or each image layer. Another way to more efficiently store image files would be to ensure that duplicate files are not created—or if they are, that they are removed-when different layers in the same image are built using the same file. Particularly for container images, the same file can be present in multiple layers and stored separately on the file system (Fig. 3 Paragraph [0013]).
LI et al and Scrivano et al fails to explicitly teach, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, at the container registry, the container image including the reference to the previously stored container image file at the container registry; and wherein to store the container image at the container registry, the processing device is to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file.
Suarez; Anthony Joseph (US 20170177860 A1) teaches, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, at the container registry, the container image including the reference to the previously stored container image file at the container registry (Fig 3 and related paragraphs discloses, container image includes a reference to a previously stored container image file at a container registry (Examiner interprets container image file as container image at a time. Examiner interprets container registry as repository, see [0046]. Examiner interprets files in container image as layers in the image at a time));
and wherein to store the container image at the container registry, the processing device is to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file (Fig. 3 and related paragraphs discloses, that layers 12 and 22 may be found with the second version 346B and that layers 31-61 may be found with the initial version 346A). (i.e., when the container image is updated, only the changed files/ layers are stored and layers/ files 31-61 are duplicate files and the metadata indicates, those files needs to be accessed from initial version). Also see [0034]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of LI et al by providing wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, at the container registry, the container image including the reference to the previously stored container image file at the container registry, and wherein to store the container image at the container registry, the processing device is to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file, as taught by Suarez et al (Fig. 3 and related paragraphs).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, container registry storage is optimized and bandwidth needed for uploading container images may be reduced. The registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries as taught by Suarez et al (Paragraphs [0027], [0053]).
Regarding dependent claim 9, LI et al, Scrivano and Suarez et al teach, the system of claim 8.
LI et al further teaches, wherein the processing device is further to: rebuild the container image to include each of the plurality of files of the container image in view of the previously stored container image file (Paragraph [0034] Image manager 122 then sends the image to image client 142. Image client 142 may then build and execute the container based on the image. Also see Paragraph [0018] When the image server receives a request from a client device to pull the container image (i.e., a pull request), it uses the file list for the container image to retrieve all of the files in the container image from their respective locations in the repository (i.e., retrieving previously stored container image file, including the reference files) and then generates the container image with all of the files (i.e., building the container image will all the files)).
Regarding dependent claim 10, LI et al, Scrivano and Suarez et al teach, the system of claim 8.
LI et al further teaches, wherein the reference is included in metadata of the container image in place of the duplicate file in the metadata of the container image (Paragraph [0031] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. Also see Paragraphs [0016], [0017]).
Regarding dependent claim 11, LI et al, Scrivano and Suarez et al teach, the system of claim 10.
LI et al further teaches, wherein the reference to the previously stored container image file in the metadata comprises a checksum of the previously stored container image file (Paragraph [0031] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. Also see Paragraphs [0016], [0017]).
Regarding dependent claim 12, LI et al, Scrivano and Suarez et al teach, the system of claim 8.
LI et al further teaches, wherein the processing device is further
PNG
media_image1.png
14
20
media_image1.png
Greyscale
determine that at least one file of the plurality of files is the duplicate file, and wherein to determine that the at least one file of the plurality of files is the duplicate file, the processing device is to: determine if a first checksum of one or more previously stored container image files at the container registry matches a second checksum of one of the plurality of files of the container image (Paragraph [0016] The image server then determines whether any files in the container image are duplicates of files already stored in a repository managed by the image server. In an example, the image server compares file identifiers and checksums received from the client device with file identifiers and checksums of files in the repository in order to identify matching files. Also see [0018]).
Regarding dependent claim 13, LI et al, Scrivano and Suarez et al teach, the system of claim 8.
Scrivano et al further teaches, wherein each file of the plurality of files is in a searchable compressed format to receive the container image (Paragraph [0012] layer may be comprised of one or more files, and the files may be archived and compressed. To use the files, the files may need to first be extracted, which may involve dearchiving and/or decompressing the files). [0029] The one or more files 108 may be in any format, including archived or compressed or archived and compressed formats. For example, the one or more files 108 may be of type .gz, .bz, .tar, .zip, .rar, etc.). [0030] The first file 110 includes a checksum 112a, which is a unique text string that may be used to identify a file. For example, MD5 (Message Digest 5) and SHA (Secure Hash Algorithm) may be used to generate a checksum or a hash value, which may be used to verify files (i.e., search for files and determine if they are duplicate or not). Also see Paragraph [0056] In response to a checksum match, a link may be created to the particular file corresponding to the matching checksum. As shown in FIG. 3, the checksum “18anxha482hjk” matches with the file path “/var/lib/containers/storage/ostree/os-svcs/18anxha482hjk.” (i.e., the checksum is a searchable compressed format without using the full file path) The file path indicates that the matching file is located in or associated with repository 312 for operating system services. Like repository 316, the repository 312 for operating system services may also include one or more layers 314 in an expanded state. As shown, the layer 314 includes four files, a first file “41s32dfw1979,” a second file “b473605rx7084,” a third file “18anxha482hjk,” and a fourth file “ct9aeg6fd3sfe.” Here, the checksum of the third file in layer 314 is identical to the checksum “18anxha482hjk” of the extracted file “svc3.exe.” Thus, if an image in a repository such as an Applications repository 316 requires access to the file with checksum “18anxha482hjk,” a link pointing to the location or repository where the file may be located may be created in the image requiring access to the file, such that the file may be accessed via the link).
LI et al further teaches, the processing device is to receive the container image in a push request (Paragraph [0021] discloses, receiving and storing container image corresponds to push and pull request).
Regarding independent claim 15, LI; GUANG CHENG (US 20210141760 A1) teaches, a non-transitory computer readable storage medium including instructions stored therein, that when executed by a processing device, cause the processing device Paragraph [0051] CPU 702 may receive and execute instructions stored in memory 708. Similarly, the CPU 702 may receive and store data related to applications in memory 708. The interconnect 712 transmits programming instructions and application data, among the CPU 702, I/O device interface 704, network interface 706, memory 708, and storage 710) to: receive, from a client device, a container image with a duplicate file removed from the container image (Fig. 3, Paragraphs [0030]- [0032] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. In an example, image manager 122 queries file index 136 for a file identifier and checksum of each file to determine whether there is an entry in file index 136 with the same file identifier and checksum. For example, if the metadata and checksums indicate that the container image contains the file “/usr/lib64/libc-2.17.20” with the checksum “a188418f0f8cd2a1fcfa21856a986044”, then image manager 122 may determine that this file is already present in data store 130, as shown in file index 400 of FIG. 4. As such, image manager 122 determines that this file does not need to be stored for the container image, and updates a file list for the container image to indicate the location of the existing version of the file in data store 130. Also see Paragraph [0016]);
and store, by the processing device and at the container registry, the container image including the reference to the previously stored container image file at the container registry (Paragraphs [0016], [0017] discloses, storing the container image including the reference to the previously stored container image file).
LI et al fails to explicitly teach, wherein the container image comprises a plurality of files in an individually compressed and searchable format, and wherein the plurality of files are appended together in the individually compressed and searchable format, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; wherein the plurality of files of the container image are stored in the individually compressed and searchable format.
Scrivano; Giuseppe (US 20190251190 A1) teaches, wherein the container image comprises a plurality of files in an individually compressed and searchable format (Paragraph [0029] The one or more files 108 may be in any format, including archived or compressed or archived and compressed formats. For example, the one or more files 108 may be of type .gz, .bz, .tar, .zip, .rar, etc.) [0030] The first file 110 includes a checksum 112a, which is a unique text string that may be used to identify a file. For example, MD5 (Message Digest 5) and SHA (Secure Hash Algorithm) may be used to generate a checksum or a hash value, which may be used to verify files (i.e., search for files and determine if they are duplicate or not). Also see Paragraph [0056], [0057] In response to a checksum match, a link may be created to the particular file corresponding to the matching checksum. As shown in FIG. 3, the checksum “18anxha482hjk” matches with the file path “/var/lib/containers/storage/ostree/os-svcs/18anxha482hjk.” (i.e., the checksum is a searchable compressed format without using the full file path ) The file path indicates that the matching file is located in or associated with repository 312 for operating system services. Like repository 316, the repository 312 for operating system services may also include one or more layers 314 in an expanded state. As shown, the layer 314 includes four files, a first file “41s32dfw1979,” a second file “b473605rx7084,” a third file “18anxha482hjk,” and a fourth file “ct9aeg6fd3sfe.” Here, the checksum of the third file in layer 314 is identical to the checksum “18anxha482hjk” of the extracted file “svc3.exe.” Thus, if an image in a repository such as an Applications repository 316 requires access to the file with checksum “18anxha482hjk,” a link pointing to the location or repository where the file may be located may be created in the image requiring access to the file, such that the file may be accessed via the link);
and wherein the plurality of files are appended together in the individually compressed and searchable format; wherein the plurality of files of the container image are stored in the individually compressed and searchable format (Paragraph [0015] In more detail, a container image layer may be extracted to a data storage location of a data storage device such as a storage file path of a network data storage device or a local data storage device. For example, if a first container image layer is “layer1.gz,” then the extracting may include decompressing and/or dearchiving “layer1.gz” into its respective files (i.e., plurality of files are appended together in a layer which is compressed and searchable layer) (i.e., the plurality of files are appended/ added/ included in a layer).Also see Paragraph [0027], [0048]-[0051]);
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of LI et al by providing in an individually compressed and searchable format, and wherein the plurality of files is appended together in the individually compressed and searchable format, as taught by Scrivano et al (Fig. 3 Paragraphs [0030], [0056]) .
One of the ordinary skill in the art would have been motivated to make this modification, so to reduce costs, to make container image storage more efficient. For example, container image storage may be made more efficient if multiple container images which require access to a file in common could all be made to use the same, single file, instead of duplicating the file in each image or each image layer. Another way to more efficiently store image files would be to ensure that duplicate files are not created—or if they are, that they are removed-when different layers in the same image are built using the same file. Particularly for container images, the same file can be present in multiple layers and stored separately on the file system (Fig. 3 Paragraph [0013]).
LI et al and Scrivano et al fails to explicitly teach, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file.
LI et al and Scrivano et al fails to explicitly teach, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, by the processing device and at the container registry, the container image including the reference to the previously stored container image file at the container registry, wherein the plurality of files of the container image are stored in the individually compressed and searchable format, and wherein to store the container image, the instructions, when executed by the processing device, cause the processing device to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file.
Suarez; Anthony Joseph (US 20170177860 A1) teaches, wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, by the processing device and at the container registry, the container image including the reference to the previously stored container image file at the container registry (Fig 3 and related paragraphs discloses, container image includes a reference to a previously stored container image file at a container registry (Examiner interprets container image file as container image at a time. Examiner interprets container registry as repository, see [0046]. Examiner interprets files in container image as layers in the image at a time));
and wherein to store the container image, the instructions, when executed by the processing device, cause the processing device to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file (Fig. 3 and related paragraphs discloses, that layers 12 and 22 may be found with the second version 346B and that layers 31-61 may be found with the initial version 346A). (i.e., when the container image is updated, only the changed files/ layers are stored and layers/ files 31-61 are duplicate files and the metadata indicates, those files needs to be accessed from initial version). Also see [0034]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of LI et al by providing wherein the container image includes a reference to a previously stored container image file at a container registry, and wherein the previously stored container image file corresponds to the duplicate file; and store, at the container registry, the container image including the reference to the previously stored container image file at the container registry, and wherein to store the container image at the container registry, the processing device is to update metadata of the container image to indicate an offset of the duplicate file removed from the container image and to indicate the reference to the previously stored container image file, as taught by Suarez et al (Fig. 3 and related paragraphs).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, container registry storage is optimized and bandwidth needed for uploading container images may be reduced. The registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries as taught by Suarez et al (Paragraphs [0027], [0053]).
Regarding dependent claim 16, LI et al, Scrivano and Suarez et al teach, the non-transitory computer readable storage medium of claim 15.
LI et al further teaches, wherein the instructions, when executed by the processing device, further cause the processing device further to: rebuild the container image to include each of the plurality of files of the container image in view of the previously stored container image file (Paragraph [0034] Image manager 122 then sends the image to image client 142. Image client 142 may then build and execute the container based on the image. Also see Paragraph [0018] When the image server receives a request from a client device to pull the container image (i.e., a pull request), it uses the file list for the container image to retrieve all of the files in the container image from their respective locations in the repository (i.e., retrieving previously stored container image file, including the reference files) and then generates the container image with all of the files (i.e., building the container image with all the files)).
Regarding dependent claim 17, LI et al, Scrivano and Suarez et al teach, the non-transitory computer readable storage medium of claim 15.
LI et al further teaches, wherein the reference is included in metadata of the container image in place of the duplicate file in the metadata of the container image (Paragraph [0031] In an example, image client 142 performs an image push 152 in which image client 142 first computes a checksum for each file in a container image and sends metadata indicating the files that are present in the container image along with the checksum for each file to image manager 122. Image manager 122 then uses the metadata and checksums to determine if any files in the container image are duplicates of files already present in image files 132 in data store 130. Also see Paragraphs [0016], [0017]).
Regarding dependent claim 18, LI et al, Scrivano and Suarez et al teach, the non-transitory computer readable storage medium of claim 17.
LI et al further teaches, wherein the reference to the previously stored container image file in the metadata comprises a checksum of the previously stored container image file (Paragraph [0016] The image server then determines whether any files in the container image are duplicates of files already stored in a repository managed by the image server. In an example, the image server compares file identifiers and checksums received from the client device with file identifiers and checksums of files in the repository in order to identify matching files).
Regarding dependent claim 19, LI et al, Scrivano and Suarez et al teach, the non-transitory computer readable storage medium of claim 15.
LI et al further teaches, wherein the instructions, when executed by the processing device, further cause the processing device to: determine that at least one file of the plurality of files is the duplicate (Paragraph [0016] The image server then determines whether any files in the container image are duplicates of files already stored in a repository managed by the image server).
Regarding dependent claim 20, LI et al, Scrivano and Suarez et al teach, the non-transitory computer readable storage medium of claim 19.
LI et al further teaches, wherein (Paragraph [0021] discloses, receiving and storing container image corresponds to push and pull request).
Closest Prior art
10. The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure.
Tarasov; Vasily (US 20220147378 A1) teaches, A computer-implemented method according to one embodiment includes receiving a request to create a container; retrieving a manifest for a container image of the container; and mounting a file system for the container, utilizing the manifest (Abstract).
11. Examiner has pointed out particular references contained in the prior arts of record in the body of this action for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and Figures may apply as well. It is respectfully requested from the applicant, in preparing the response, to consider fully the entire references as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior arts or disclosed by the examiner. It is noted that any citation to specific pages, columns, figures, or lines in the prior art references any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331-33, 216 USPQ 1038-39 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968))).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN RAJAPUTRA whose telephone number is (571) 272-4669. The examiner can normally be reached between 8:00 AM - 5: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, Tony Mahmoudi (571) 272-4078 can be reached. 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. R./
Examiner, Art Unit 2163
/ALEX GOFMAN/Primary Examiner, Art Unit 2163