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 .
This action is responsive to the application filed August 29, 2024.
Claims 1-20 are pending and are presenting for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below 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 that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
Specification
The specification is objected to for information provided on page 1, paragraph 1, where the current status of the Cross Reference to Related Applications should be updated. See MPEP 608.01[R-5] and 37 CFR 1.78.
Claim Objections
6. Claim 7 is objected to because of the following informalities:
As to claim 7, line 2, recites to include the following limitation “the second set of packages” should be changed to, for example, --the set of packages -- instead. Appropriate correction is required.
Double Patenting
7. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
8. Claims 1-20 are rejected on the ground of nonstatutory anticipated-double patenting as being unpatentable over claims 1-3, 5-10, 12-17, and 19-20 of U.S. Patent No. 12093673 B2.
The claims of the current application and the claims of the reference patent are compared in the following table below:
Current Application
U.S. Patent No. 12093673 B2
1. A method comprising:
receiving, at a virtual image server, an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages; and
generating, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer.
2. The method of claim 1, further comprising: retrieving, using the image manifest, binary content associated with the corresponding image file for each of the set of packages from an image registry, wherein the image registry stores the binary content associated with the corresponding image file for each of the set of packages inside a specific isolated directory that the corresponding image file owns, and wherein the container image is built using the binary content associated with the corresponding image file for each of the set of packages.
3. The method of claim 1, wherein the image manifest references an identifier of the corresponding image file for each of the set of packages.
4. The method of claim 1, further comprising:
providing the image manifest to a container host; and
building, by the container host, the container image based on the image manifest.
5. The method of claim 3, wherein the
identifier of the corresponding image file of each of the set of packages comprises a hash.
6. The method of claim 1, wherein the image manifest does not reference the corresponding image file for each of the set of packages in an order.
7. The method of claim 2, wherein retrieving the binary content associated with the corresponding image file for each of the second set of packages comprises: redirecting the binary content associated with the corresponding image file for each of the set of packages through the virtual image server to the container host.
8. A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device to:
receive, at a virtual image server, an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages; and
generate, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer.
9. The system of claim 8, wherein the processing device is further to: retrieve, using the image manifest, binary content associated with the corresponding image file for each of the set of packages from an image registry, wherein the image registry stores the binary content associated with the corresponding image file for each of the set of packages inside a specific isolated directory that the corresponding image file owns, and wherein the container image is built using the binary content associated with the corresponding image file for each of the set of packages.
10. The system of claim 8, wherein the image manifest references an identifier of the corresponding image file for each of the set of packages.
11. The system of claim 8, wherein the processing device is further to:
provide the image manifest to a container host; and
build, by the container host, the container image based on the image manifest.
12. The system of claim 10, wherein the identifier of the corresponding image file of each of the set of packages comprises a hash.
13. The system of claim 8, wherein the image manifest does not reference the corresponding image file for each of the set of packages in an order.
14. The system of claim 9, wherein to retrieve the binary content associated with the corresponding image file for each of the set of packages, the processing device is to: redirect the binary content associated with the corresponding image file for each of the set of packages through the virtual image server to the container host.
15. A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device to:
receive, at a virtual image server, an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages; and
generate, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer.
16. The non-transitory computer-readable medium of claim 15, wherein the processing device is further to: retrieve, using the image manifest, binary content associated with the corresponding image file for each of the set of packages from an image registry, wherein the image registry stores the binary content associated with the corresponding image file for each of the set of packages inside a specific isolated directory that the corresponding image file owns, and wherein the container image is built using the binary content associated with the corresponding image file for each of the set of packages.
17. The non-transitory computer-readable medium of claim 15, wherein the image manifest references an identifier of the corresponding image file for each of the set of packages.
18. The non-transitory computer-readable medium of claim 15, wherein the processing device is further to:
provide the image manifest to a container host; and
build, by the container host, a container image based on the image manifest.
19. The non-transitory computer-readable medium of claim 17, wherein the identifier of the corresponding image file of each of the set of packages comprises a hash.
20. The non-transitory computer-readable medium of claim 15, wherein the image manifest does not reference the corresponding image file for each of the set of packages in an order.
1. A method comprising:
receiving, at a virtual image server, an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages;
For each of the set of packages, retrieving, by the virtual image server, the corresponding image file from an image registry;
generating, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer;
providing the image manifest to a container host; and
building, by the container host, the container image based on the image manifest.
2. The method of claim 1, further comprising: retrieving, using the image manifest, binary content associated with the corresponding image file for each of the set of packages from the image registry, wherein the image registry stores the binary content associated with the corresponding image file for each of the set of packages inside a specific isolated directory that the corresponding image file owns, and wherein the container image is built using the binary content associated with the corresponding image file for each of the set of packages.
3. The method of claim 1, wherein the image manifest references an identifier of the corresponding image file for each of the set of packages.
1. A method comprising: receiving, at a virtual image… layer;
providing the image manifest to a container host; and
building, by the container host, the container image based on the image manifest.
5. The method of claim 3, wherein the identifier of the corresponding image file of each of the set of packages comprises a hash.
6. The method of claim 1, wherein the image manifest does not reference the corresponding image file for each of the set of packages in an order.
7. The method of claim 2, wherein retrieving the binary content associated with the corresponding image file for each of the set of packages comprises: redirecting the binary content associated with the
corresponding image file for each of the set of packages through the virtual image server to the container host.
8. A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device to:
receive, at a virtual image server, an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages;
for each of the set of packages, retrieve, by the virtual image server, the corresponding image file from an image registry;
generate, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer;
provide the image manifest to a container host; and
build, by the container host, a container image based on the image manifest.
9. The system of claim 8, wherein the processing device is further to: retrieve, using the image manifest, binary content associated with the corresponding image file for each of the set of packages from the image registry, wherein the image registry stores the binary content associated with the corresponding image file for each of the set of packages inside a specific isolated directory that the corresponding image file owns, and wherein the container image is built using the binary content associated with the corresponding image file for each of the set of packages.
10. The system of claim 8, wherein the image manifest references an identifier of the corresponding image file for each of the set of packages.
8. A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device to:
receive, … image layer;
provide the image manifest to a container host; and
build, by the container host, a container image based on the image manifest.
12. The system of claim 10, wherein the identifier of the corresponding image file of each of the set of packages comprises a hash.
13. The system of claim 8, wherein the image manifest does not reference the corresponding image file for each of the second set of packages in an order.
14. The system of claim 9, wherein to retrieve the binary content associated with the corresponding image file for each of the set of packages, the processing device is to: redirect the binary content associated with the corresponding image file for each of the set of packages through the virtual image server to the container host.
15. A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device to:
receive, at a virtual image server, an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages;
for each of the set of packages, retrieve, by the virtual image server, the corresponding image file from an image registry;
generate, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer;
provide the image manifest to a container host; and
build, by the container host, a container image based on the image manifest.
16. The non-transitory computer-readable medium of claim 15, wherein the processing device is further to: retrieve, using the image manifest, binary content associated with the corresponding image file for each of the set of packages from the image registry, wherein the image registry stores the binary content associated with the corresponding image file for each of the set of packages inside a specific isolated directory that the corresponding image file owns, and wherein the container image is built using the binary content associated with the corresponding image file for each of the set of packages.
17. The non-transitory computer-readable medium of claim 15, wherein the image manifest references an identifier of the corresponding image file for each of the set of packages.
15. A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device to: receive… image layer;
provide the image manifest to a container host; and
build, by the container host, a container image based on the image manifest.
19. The non-transitory computer-readable medium of claim 17, wherein the identifier of the corresponding image file of each of the set of packages comprises a hash.
20. The non-transitory computer-readable medium of claim 15, wherein the image manifest does not reference the corresponding image file for each of the set of packages in an order.
Based on the comparison table above, which highlight the differences by underlining words indicates that, the conflicting claims 1-20 of current examined application and claims 1-3, 5-10, 12-17, and 19-20 of US patent No. `673 are not identical, but they are not patentably distinct from each other and as such are unpatentable for anticipated-type double patenting.
Thus, claims 1-20 of the current examined application are unpatentable over claims 1-3, 5-10, 12-17, and 19-20 of the U.S. Patent Application No. ‘673 and as such are unpatentable for anticipated-type double patenting.
Claim Rejections - 35 USC § 101
9. 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.
10. Claims 1, 3-6, 8, 10-13, 15, and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent Claims 1, 8, and 15 recites:
A method comprising:
[a] receiving, at a virtual image server, an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages; and
[b] generating, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer.
Step 2A – prong 1:
The claims 1, 8, and 15 recite the limitation of:
[b] generating an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer.
These limitations of step [b] as draft, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Step 2A – Prong 2:
Under Prong 2, this judicial exception is not integrated into a practical application. The claims recite the following additional elements: “A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device”, “A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device”, “at a virtual image server”, and “by the virtual image server” merely recite instructions to implement an abstract idea on a generic computer, or merely use a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. See MPEP 2106.05(f).
Furthermore, the additional limitation of step [a] “receiving an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering and displaying data. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(g).
Step 2B:
Under Step 2B, 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 additional elements of “A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device”, “A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device”, “at a virtual image server”, and “by the virtual image server” amount to no more than mere instructions, or generic computer/computer components to carry out the exception, for the limitations and for the limitation of step [a] “receiving an image definition file specifying a set of packages to build a container image, wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages” , the courts have identified mere data gathering, transmitting, and displaying are well-understood, routine and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding to per claims 3, 10, and 17, the limitation of “wherein the image manifest references an identifier of the corresponding image file for each of the set of packages” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to per claims 4, 11, and 18, the limitation of “further comprising: building the container image based on the image manifest” recites mental process. The additional element “by the container host” and “wherein the processing device is further to” merely recite instructions to implement an abstract idea on a generic computer, or merely use a generic computer or computer components as a tool to perform the abstract idea. Lastly, the additional element of “providing the image manifest to a container host” which is nothing more than insignificant extra solution activity which is not a practical application under prong 2. Under step 2B, the courts have identified mere data gathering, transmitting, and displaying are well-understood, routine and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding to per claims 5, 12, and 19, the limitation of “wherein the identifier of the corresponding image file of each of the set of packages comprises a hash” which is further define data (identifier) that is nothing more than insignificant extra solution activity which is not a practical application under prong 2. Under step 2B, the courts have identified mere data gathering and displaying are well-understood, routine and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding to per claims 6, 13, and 20, the limitation of “wherein the image manifest does not reference the corresponding image file for each of the set of packages in an order” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Claim Rejections - 35 USC § 103
11. 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.
12. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Novy (US 20210255840 A1) in view of Tarasov et al. (US 20220147378 A1, hereinafter Tarasov).
As per claims 1, 8, and 15, Novy discloses a method comprising:
receiving, at a virtual image server, an image definition file specifying a set of packages to build a container image(e.g., metadata contain specify packages for the container engine to pull – see at least 0043, Figs. 1-2, and associated text), wherein the virtual image server comprises a mapping of the image definition file to an image file corresponding to each of the set of packages-- (E.g., the container engine 222 may determine one or more packages and pull the image files corresponding to the required one or more packages from an appropriate repository within registry server 130, upon metadata – see at least 0043, Fig. 1-2, and associated text).
It is to note that Novy does not explicitly disclose, but Tarasov, in an analogous art, discloses generating, by the virtual image server, an image manifest using the corresponding image file for each of the set of packages, wherein the image manifest references the corresponding image file for each of the set of packages as a separate image layer – (E.g., the manifest includes metadata describing the plurality of files, the manifest may include a list of file names (e.g., content identifiers), ownership and/or permissions data associated with those files, etc. In another example, the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where the plurality of files are stored, etc.). In yet another example, the manifest may store a plurality of file stubs that each include a pointer to a location where the file is stored – see at least 0068-0073);
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated building the container image by utilizing a manifest of Tarasov’s teaching into Novy’s teaching for further optimizing node performance via using less bandwidth in generation the container image as seen in Tarasov (e.g., 0073 and 0082).
Further regarding to claim 8, Novy discloses a system (e.g., computing device 120 – see at least 0020) comprising: a memory; and a processing device operatively coupled to the memory, the processing device to implement method steps as of claim 1 above.
Further regarding to claim 15, Novy discloses a non-transitory computer-readable medium – see at least 0071, having instructions stored thereon which, when executed by a processing device, cause the processing device to implement method steps as of claim 1 above.
As per claims 2, 9, and 16, Novy discloses further comprising:
retrieving, binary content associated with the corresponding image file for each of the set of packages from the image registry, wherein the image registry stores the binary content associated with the corresponding image file for each of the set of packages inside a specific isolated directory that the corresponding image file owns, and wherein the container image is built using the binary content associated with the corresponding image file for each of the set of packages— (e.g., downloading the image file for set of the package in which the package can be in binary --see Novy, at least 0023, 0024, 0028, 0038, 0043-0044,0047-0048), but does not explicitly discloses; however, Tarasov, in an analogous art, discloses retrieving, using the image manifest for content file of the container image– (E.g., using manifest to retrieve data file from the content store for the container image – see Tarasov, at least 0080-0082).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Tarasov’s teaching into Novy’s teaching for further optimizing node performance via using less bandwidth in generation the container image as seen in Tarasov (e.g., 0073 and 0082).
As per claims 3, 10, and 17, modified Novy with Tarasov discloses wherein the image manifest references an identifier of the corresponding image file for each of the set of packages – (incorporated Tarasov’s teaching (E.g., the manifest includes metadata describing the plurality of files, the manifest may include a list of file names (e.g., content identifiers), ownership and/or permissions data associated with those files, etc. In another example, the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where the plurality of files are stored, etc.). In yet another example, the manifest may store a plurality of file stubs that each include a pointer to a location where the file is stored – see Tarasov, at least 0068-0073, into Novy’s teaching for further optimizing node performance via using less bandwidth in generation the container image as seen in Tarasov (e.g., 0073 and 0082)).
As per claims 4, 11, and 18, it is to note that Novy does not explicitly disclose, but Tarasov, in an analogous art, discloses further comprising: providing the image manifest to a container host; and building, by the container host, the container image based on the image manifest – (E.g., retrieving the manifest for the container of a node , in which the manifest include metadata needed to mount the file system, as well as pointers to additional file data for the container image – see at least 0072-0073, Fig. 4, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated building the container image by utilizing a manifest of Tarasov’s teaching into Novy’s teaching for further optimizing node performance via using less bandwidth in generation the container image as seen in Tarasov (e.g., 0073 and 0082).
As per claims 5, 12, and 19, modified Novy with Tarasov discloses, wherein the identifier of the corresponding image file of each of the set of packages comprises a hash --( e.g., incorporated Tarasov’s teaching (E.g., the manifest includes metadata describing the plurality of files, the manifest may include a list of file names (e.g., content identifiers), ownership and/or permissions data associated with those files, etc. In another example, the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where the plurality of files are stored, etc.). In yet another example, the manifest may store a plurality of file stubs that each include a pointer to a location where the file is stored – see Tarasov, at least 0068-0073, into Novy’s teaching for further optimizing node performance via using less bandwidth in generation the container image as seen in Tarasov (e.g., 0073 and 0082)).
As per claims 6, 13, and 20, modified Novy with Tarasov discloses, wherein the image manifest does not reference the corresponding image file for each of the set of packages in an order -- (e.g., incorporated Tarasov’s teaching (E.g., the manifest includes metadata describing the plurality of files, the manifest may include a list of file names (e.g., content identifiers), ownership and/or permissions data associated with those files, etc. In another example, the manifest may include content-based addresses for the files (e.g., file hashes, pointers to locations where the plurality of files are stored, etc.). In yet another example, the manifest may store a plurality of file stubs that each include a pointer to a location where the file is stored – see Tarasov, at least 0068-0073, into Novy’s teaching for further optimizing node performance via using less bandwidth in generation the container image as seen in Tarasov (e.g., 0073 and 0082)).
As per claims 7 and 14, modified Novy with Tarasov discloses, wherein retrieving the binary content associated with the corresponding image file for each of the second set of packages comprises: redirecting the binary content associated with the corresponding image file for each of the second set of packages through the virtual image server to the container host – ( e.g., incorporating the retrieving the manifest for the container of a node , in which the manifest include metadata needed to mount the file system, as well as pointers to additional file data for the container image – see Tarasov, at least 0072-0073, Fig. 4, and associated text, into container engine of Novy’s teaching for further optimizing node performance via using less bandwidth in generation the container image as seen in Tarasov (e.g., 0073 and 0082)).
Conclusion
13. The prior art made of record and not relied upon (cited on 892 form) is considered pertinent to application disclosure.
Waterman et al. (US-20240095006-A1) disclosed assembling executable image files for execution as software containers.
Rupprecht et al. (US-11762850-B2) disclosed creating and deploying container images.
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARINA LEE whose telephone number is (571)270-1648. The examiner can normally be reached Monday to Friday (8 am to 4: 30 pm ET).
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, Hyung S. Sough can be reached on (571)-272-6799. 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.
/MARINA LEE/Primary Examiner, Art Unit 2192
Prosecution Insights