Prosecution Insights
Last updated: July 17, 2026
Application No. 18/757,889

Managing Container Images

Non-Final OA §103
Filed
Jun 28, 2024
Examiner
TRAN, JOSHUA VAN
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-55.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
7 currently pending
Career history
12
Total Applications
across all art units

Statute-Specific Performance

§103
100.0%
+60.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 0 resolved cases

Office Action

§103
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 . Examiner’s Notes Regarding claim 13, the claim recites: “A computer program product for managing container images, the computer program product comprising a set of computer-readable storage media having program instructions collectively stored therein…”. The claim does not specify the computer-readable storage media as being non-transitory computer-readable storage media. However, paragraph [0032] of the specification excludes freely propagating electromagnetic waves. Therefore, a 101 rejection based on CRM is not warranted. Claim Rejections - 35 USC § 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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1, 3, 4, 9, 11, 12, 13, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Huo et al. (US20230325080, Huo hereinafter) in view of Gugick et al. (US8260750, Gugick hereinafter). Regarding claim 1, Huo discloses: A computer-implemented method for managing container images (see Huo, paragraph [0005], “Embodiments of the present disclosure relate to a computer-implemented method, an associated computer system and computer program products for building or modifying image files for containers…”), the computer-implemented method comprising: determining, by a computer, (see Huo, paragraph [0082], “…files depicted with a “C” indicates a file or directory that has changed from the file in the previous layer.”); determining, by the computer, whether (see Huo, paragraph [0100], “If during step 917, the hash value of the original file in the lower layer is not the same as the hash value of the updated file, the method 900 may proceed to step 921. During step 921, PPM 510 may further examine whether the difference between the hash values exceeds a default differ value, or a threshold value set by a user or administrator of the container system.…”); responsive to the computer determining that (see Huo, paragraph [0100], “…if in step 921 the difference between the hash values does not exceed a default differ value or threshold value, the method 900 may proceed to step 923…”), (see Huo, paragraph [0026], “…the read-write layer is added as a new top layer of a new image”), (see Huo, paragraph [0102], “…In step 943, the daemon 509 runs a commit operation creating a new image 520 from the changes to the container 523, as represented in the read-write layer to be added as a new layer on top of the existing layers within new image 520…”), (see Huo, paragraph [0097], “…During step 901, a daemon 509 may receive from a client 503 a request to build a container image using an existing image or modify an existing container image. In response to the request, in step 903, daemon 509 may pull the base image or existing image specified by the client's request from registry 515 or image repository 517 thereof to local storage 511 of a host node 501…”); and copying, by the computer, the set of changed files in the new increment file layer of the upgraded container image (see Huo, paragraph [0083], “…newly added files present in the top layer 650 can be copied up to the container layer 601…”), (see Huo, paragraph [0102], “…In step 943, the daemon 509 runs a commit operation creating a new image 520 from the changes to the container 523, as represented in the read-write layer to be added as a new layer on top of the existing layers within new image 520…”). Huo does not appear to distinctly disclose: However, Gugick discloses: determining, by a computer, a number of a set of changed files included in a plurality of upgraded files in response to identifying the set of changed files (see Gugick, Abstract, “…One approach… is for the escalation module 122 to access the data store 102 to determine a quantity of storage units changed since the last backup (partial or full). Storage units can include space on disk reserved for a file or application, such as one or more blocks, a page of blocks, a group of collection of blocks, a row or column in a database, a table in a database, or the like.…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the determination of a number of a set of changed files as taught by Gugick, for the result of providing a measure to determine the size of the upgrade. Regarding claim 3, Huo discloses: performing, by the computer, a comparison of a first hash of a plurality of original files in the original file layer of the original container image and a second hash of the plurality of upgraded files corresponding to the upgraded container image (see Huo, paragraph [0099], “…In step 915, PPM 510 may compare hash values of the original files from the lower layer of the pulled image 519 with the hash value of the updated file from the top layer of the pulled image 519. In step 917, based on the comparison of hash values by PPM 510, a determination is made whether or not the hash values are the same…”), (see Huo, paragraph [0084], “The filtered group 604 of files being processed during the pre-commit stage by PPM 510 may undergo a hash value comparison step 609…”); and identifying, by the computer, the set of changed files included in the plurality of upgraded files based on the comparison of the first hash of the plurality of original files in the original file layer of the original container image and the second hash of the plurality of upgraded files corresponding to the upgraded container image (see Huo, paragraph [0099]). Regarding claim 4, Huo discloses: generating, by the computer, a first hash of a plurality of original files in the original file layer of the original container image (please note that hash values must first be generated to be compared, see Huo, paragraph [0084], “…During the hash value comparison step 609… PPM 510 may, for each file or directory identified within the read-only layer as being changed from an original file… compare hash values of the updated file being copied up to the container layer 601 with the original file from the lower layer 709 of the image…”); and generating, by the computer, a second hash of the plurality of upgraded files corresponding to the upgraded container image (please note that hash values must first be generated to be compared, see Huo, paragraph [0099], “…In step 915, PPM 510 may compare hash values of the original files from the lower layer of the pulled image 519 with the hash value of the updated file from the top layer of the pulled image 519…”). Regarding claim 9, Huo discloses: A computer system for managing container images, the computer system comprising: a communication fabric; a set of computer-readable storage media connected to the communication fabric, wherein the set of computer-readable storage media collectively stores program instructions; and a set of processors connected to the communication fabric (see Huo, paragraph [0042], “Computing system 100 may include communications fabric 112, which can provide for electronic communications among one or more processor(s) 103, memory 105, persistent storage 106, cache 107, communications unit 111, and one or more input/output (I/O) interface(s) 115…”), wherein the set of processors executes the program instructions to: determine (see Huo, paragraph [0082], “…files depicted with a “C” indicates a file or directory that has changed from the file in the previous layer.”); determine whether (see Huo, paragraph [0100], “If during step 917, the hash value of the original file in the lower layer is not the same as the hash value of the updated file, the method 900 may proceed to step 921. During step 921, PPM 510 may further examine whether the difference between the hash values exceeds a default differ value, or a threshold value set by a user or administrator of the container system.…”); generate a new increment file layer that is in addition to an original file layer of a plurality of original layers in an upgraded container image of an original container image in response to determining that (see Huo, paragraph [0100], “…if in step 921 the difference between the hash values does not exceed a default differ value or threshold value, the method 900 may proceed to step 923…”), (see Huo, paragraph [0026], “…the read-write layer is added as a new top layer of a new image”), (see Huo, paragraph [0102], “…In step 943, the daemon 509 runs a commit operation creating a new image 520 from the changes to the container 523, as represented in the read-write layer to be added as a new layer on top of the existing layers within new image 520…”), (see Huo, paragraph [0097], “…During step 901, a daemon 509 may receive from a client 503 a request to build a container image using an existing image or modify an existing container image. In response to the request, in step 903, daemon 509 may pull the base image or existing image specified by the client's request from registry 515 or image repository 517 thereof to local storage 511 of a host node 501…”); and copy the set of changed files in the new increment file layer of the upgraded container image (see Huo, paragraph [0083], “…newly added files present in the top layer 650 can be copied up to the container layer 601…”), (see Huo, paragraph [0102], “…In step 943, the daemon 509 runs a commit operation creating a new image 520 from the changes to the container 523, as represented in the read-write layer to be added as a new layer on top of the existing layers within new image 520…”). Huo does not appear to distinctly disclose: However, Gugick discloses: determine a number of a set of changed files included in a plurality of upgraded files in response to identifying the set of changed files (see Gugick, Abstract, “…One approach… is for the escalation module 122 to access the data store 102 to determine a quantity of storage units changed since the last backup (partial or full). Storage units can include space on disk reserved for a file or application, such as one or more blocks, a page of blocks, a group of collection of blocks, a row or column in a database, a table in a database, or the like.…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the determination of a number of a set of changed files as taught by Gugick, for the result of providing a measure to determine the size of the upgrade. Regarding claim 11, Huo discloses: perform a comparison of a first hash of a plurality of original files in the original file layer of the original container image and a second hash of the plurality of upgraded files corresponding to the upgraded container image (see Huo, paragraph [0099], “…In step 915, PPM 510 may compare hash values of the original files from the lower layer of the pulled image 519 with the hash value of the updated file from the top layer of the pulled image 519. In step 917, based on the comparison of hash values by PPM 510, a determination is made whether or not the hash values are the same…”), (see Huo, paragraph [0084], “The filtered group 604 of files being processed during the pre-commit stage by PPM 510 may undergo a hash value comparison step 609…”); and identify the set of changed files included in the plurality of upgraded files based on the comparison of the first hash of the plurality of original files in the original file layer of the original container image and the second hash of the plurality of upgraded files corresponding to the upgraded container image (see Huo, paragraph [0099]). Regarding claim 12, Huo discloses: generate a first hash of a plurality of original files in the original file layer of the original container image (please note that hash values must first be generated to be compared, see Huo, paragraph [0084], “…During the hash value comparison step 609… PPM 510 may, for each file or directory identified within the read-only layer as being changed from an original file… compare hash values of the updated file being copied up to the container layer 601 with the original file from the lower layer 709 of the image…”); and generate a second hash of the plurality of upgraded files corresponding to the upgraded container image (please note that hash values must first be generated to be compared, see Huo, paragraph [0099], “…In step 915, PPM 510 may compare hash values of the original files from the lower layer of the pulled image 519 with the hash value of the updated file from the top layer of the pulled image 519…”). Regarding claim 13, Huo discloses: A computer program product for managing container images, the computer program product comprising a set of computer-readable storage media having program instructions collectively stored therein (see Huo, paragraph [0032], “…A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing…”), the program instructions executable by a computer to cause the computer to: determine (see Huo, paragraph [0082], “…files depicted with a “C” indicates a file or directory that has changed from the file in the previous layer.”); determine whether (see Huo, paragraph [0100], “If during step 917, the hash value of the original file in the lower layer is not the same as the hash value of the updated file, the method 900 may proceed to step 921. During step 921, PPM 510 may further examine whether the difference between the hash values exceeds a default differ value, or a threshold value set by a user or administrator of the container system.…”); generate a new increment file layer that is in addition to an original file layer of a plurality of original layers in an upgraded container image of an original container image in response to determining that (see Huo, paragraph [0100], “…if in step 921 the difference between the hash values does not exceed a default differ value or threshold value, the method 900 may proceed to step 923…”), (see Huo, paragraph [0026], “…the read-write layer is added as a new top layer of a new image”), (see Huo, paragraph [0102], “…In step 943, the daemon 509 runs a commit operation creating a new image 520 from the changes to the container 523, as represented in the read-write layer to be added as a new layer on top of the existing layers within new image 520…”), (see Huo, paragraph [0097], “…During step 901, a daemon 509 may receive from a client 503 a request to build a container image using an existing image or modify an existing container image. In response to the request, in step 903, daemon 509 may pull the base image or existing image specified by the client's request from registry 515 or image repository 517 thereof to local storage 511 of a host node 501…”); and copy the set of changed files in the new increment file layer of the upgraded container image (see Huo, paragraph [0083], “…newly added files present in the top layer 650 can be copied up to the container layer 601…”), (see Huo, paragraph [0102], “…In step 943, the daemon 509 runs a commit operation creating a new image 520 from the changes to the container 523, as represented in the read-write layer to be added as a new layer on top of the existing layers within new image 520…”). Huo does not appear to distinctly disclose: However, Gugick discloses: determine a number of a set of changed files included in a plurality of upgraded files in response to identifying the set of changed files (see Gugick, Abstract, “…One approach… is for the escalation module 122 to access the data store 102 to determine a quantity of storage units changed since the last backup (partial or full). Storage units can include space on disk reserved for a file or application, such as one or more blocks, a page of blocks, a group of collection of blocks, a row or column in a database, a table in a database, or the like.…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the determination of a number of a set of changed files as taught by Gugick, for the result of providing a measure to determine the size of the upgrade. Regarding claim 15, Huo discloses: perform a comparison of a first hash of a plurality of original files in the original file layer of the original container image and a second hash of the plurality of upgraded files corresponding to the upgraded container image (see Huo, paragraph [0099], “…In step 915, PPM 510 may compare hash values of the original files from the lower layer of the pulled image 519 with the hash value of the updated file from the top layer of the pulled image 519. In step 917, based on the comparison of hash values by PPM 510, a determination is made whether or not the hash values are the same…”), (see Huo, paragraph [0084], “The filtered group 604 of files being processed during the pre-commit stage by PPM 510 may undergo a hash value comparison step 609…”); and identify the set of changed files included in the plurality of upgraded files based on the comparison of the first hash of the plurality of original files in the original file layer of the original container image and the second hash of the plurality of upgraded files corresponding to the upgraded container image (see Huo, paragraph [0099]). Regarding claim 16, Huo discloses: generate a first hash of a plurality of original files in the original file layer of the original container image (please note that hash values must first be generated to be compared, see Huo, paragraph [0084], “…During the hash value comparison step 609… PPM 510 may, for each file or directory identified within the read-only layer as being changed from an original file… compare hash values of the updated file being copied up to the container layer 601 with the original file from the lower layer 709 of the image…”); and generate a second hash of the plurality of upgraded files corresponding to the upgraded container image (please note that hash values must first be generated to be compared, see Huo, paragraph [0099], “…In step 915, PPM 510 may compare hash values of the original files from the lower layer of the pulled image 519 with the hash value of the updated file from the top layer of the pulled image 519…”). Claims 2, 10, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Huo and Gugick as applied to claim 1, 9, and 13 above, and further in view of McPherson et al. (US10169209, McPherson hereinafter). Regarding claim 2, Huo does not appear to distinctly disclose: responsive to the computer determining that the number of the set of changed files included in the plurality of upgraded files is greater than the defined file change threshold level, generating, by the computer, a new anchor file layer that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image; and copying, by the computer, the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image. However, Gugick discloses: responsive to the computer determining that the number of the set of changed files included in the plurality of upgraded files is greater than the defined file change threshold level (see Gugick, col 5 lines 44-47, “…a user can supply an escalation parameter that triggers a full backup at block 208 if the data change amount exceeds a threshold…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include a trigger condition as taught by Gugick, for the result of applying the appropriate layer in the appropriate situation. Huo as modified does not appear to distinctly disclose: generating, by the computer, a new anchor file layer that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image and copying, by the computer, the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image. However, McPherson discloses: generating, by the computer, a new anchor file layer (operating system layer 412b) that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image (see McPherson, col 11 lines 1-7, “…Image engine 140 may determine that the update may be packaged in a new, updated version of operating system layer 412a, for example operating system layer 412b, and thereby replace operating system layer 412a with operating system layer 412b in container image 410, resulting in container image 420…”), (see McPherson, col 9 lines 4-5, “…the first layer is replaced with a third layer, where the third layer is an updated version of the first layer”); and copying, by the computer, the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image (the full updated layer inherently includes changed files and original files, see Mcpherson, col 11 lines 2-7, “…the update may be packaged in a new, updated version of operating system layer 412a, for example operating system layer 412b, and thereby replace operating system layer 412a with operating system layer 412b in container image 410, resulting in container image 420…”), (see McPherson, col 11 lines 18-20, “…a container image file may contain the full contents of each layer that is included in the container image…”), (see McPherson, col 8 lines 58-60, “…a system or container may determine which copy of the content to use in a specific situation or by a specific layer or application…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the generation of a new layer that replaces the original file layer and copying both the changed files and original files into the new layer as taught by McPherson, for the result of capturing the upgrade as a single self-contained consolidated layer. Regarding claim 10, Huo does not appear to distinctly disclose: generate a new anchor file layer that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image in response to determining that the number of the set of changed files included in the plurality of upgraded files is greater than the defined file change threshold level; and copy the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image. However, Gugick discloses: (see Gugick, col 5 lines 44-47, “…a user can supply an escalation parameter that triggers a full backup at block 208 if the data change amount exceeds a threshold…”); It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include a trigger condition as taught by Gugick, for the result of applying the appropriate layer in the appropriate situation. Huo as modified does not appear to distinctly disclose: generate a new anchor file layer that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image copy the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image. However, McPherson discloses: generate a new anchor file layer (operating system layer 412b) that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image (see McPherson, col 11 lines 1-7, “…Image engine 140 may determine that the update may be packaged in a new, updated version of operating system layer 412a, for example operating system layer 412b, and thereby replace operating system layer 412a with operating system layer 412b in container image 410, resulting in container image 420…”), (see McPherson, col 9 lines 4-5, “…the first layer is replaced with a third layer, where the third layer is an updated version of the first layer”); and copy the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image (the full updated layer inherently includes changed files and original files, see Mcpherson, col 11 lines 2-7, “…the update may be packaged in a new, updated version of operating system layer 412a, for example operating system layer 412b, and thereby replace operating system layer 412a with operating system layer 412b in container image 410, resulting in container image 420…”), (see McPherson, col 11 lines 18-20, “…a container image file may contain the full contents of each layer that is included in the container image…”), (see McPherson, col 8 lines 58-60, “…a system or container may determine which copy of the content to use in a specific situation or by a specific layer or application…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the generation of a new layer that replaces the original file layer and copying both the changed files and original files into the new layer as taught by McPherson, for the result of capturing the upgrade as a single self-contained consolidated layer. Regarding claim 14, Huo does not appear to distinctly disclose: generate a new anchor file layer that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image in response to determining that the number of the set of changed files included in the plurality of upgraded files is greater than the defined file change threshold level; and copy the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image. However, Gugick discloses: (see Gugick, col 5 lines 44-47, “…a user can supply an escalation parameter that triggers a full backup at block 208 if the data change amount exceeds a threshold…”); It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include a trigger condition as taught by Gugick, for the result of applying the appropriate layer in the appropriate situation. Huo as modified does not appear to distinctly disclose: generate a new anchor file layer that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image copy the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image. However, McPherson discloses: generate a new anchor file layer (operating system layer 412b) that replaces the original file layer of the plurality of original layers in the upgraded container image of the original container image (see McPherson, col 11 lines 1-7, “…Image engine 140 may determine that the update may be packaged in a new, updated version of operating system layer 412a, for example operating system layer 412b, and thereby replace operating system layer 412a with operating system layer 412b in container image 410, resulting in container image 420…”), (see McPherson, col 9 lines 4-5, “…the first layer is replaced with a third layer, where the third layer is an updated version of the first layer”); and copy the set of changed files and a plurality of original files in the new anchor file layer of the upgraded container image (the full updated layer inherently includes changed files and original files, see Mcpherson, col 11 lines 2-7, “…the update may be packaged in a new, updated version of operating system layer 412a, for example operating system layer 412b, and thereby replace operating system layer 412a with operating system layer 412b in container image 410, resulting in container image 420…”), (see McPherson, col 11 lines 18-20, “…a container image file may contain the full contents of each layer that is included in the container image…”), (see McPherson, col 8 lines 58-60, “…a system or container may determine which copy of the content to use in a specific situation or by a specific layer or application…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the generation of a new layer that replaces the original file layer and copying both the changed files and original files into the new layer as taught by McPherson, for the result of capturing the upgrade as a single self-contained consolidated layer. Claims 5, 8, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Huo and Gugick as applied to claims 1 and 13 above, and further in view of Suarez et al. (US20170177860, Suarez hereinafter). Regarding claim 5, Huo as modified does not appear to distinctly disclose: stopping, by the computer, a microservice in response to receiving an input to upgrade the original container image to a new version of the original container image; determining, by the computer, an identifier corresponding to the new version of the original container image; performing, by the computer, a search of a remote image registry to locate the identifier corresponding to the new version of the original container image; and determining, by the computer, whether the identifier corresponding to the new version of the original container image is associated with the new increment file layer that contains the set of changed files based on the search of the remote image registry. However, Suarez discloses: stopping, by the computer, a microservice (currently running version of the software) in response to receiving an input to upgrade the original container image to a new version of the original container image (see Suarez, paragraph [0127], “…the new version should be automatically deployed to replace the current version running in the container instance of the system.”), (see Suarez, paragraph [0128], “…the agent may stop any currently running version of the software of the container image…”); determining, by the computer, an identifier corresponding to the new version of the original container image (see Suarez, paragraph [0033], “…A manifest may comprise metadata such as an identity of the container image that corresponds to the manifest, and, for each layer listed in the manifest, a content-addressable identifier that uniquely corresponds to a respective layer…”), (see Suarez, paragraph [0127]); performing, by the computer, a search of a remote image registry (container registry) to locate the identifier corresponding to the new version of the original container image (see Suarez, paragraph [0034], “…the container registry front-end service 214 may query the registry metadata service 222 for the location of a data object in the storage service 290, and, as a result of receiving the location, may retrieve the data object corresponding to the location from the storage service 290.”), (see Suarez, paragraph [0114], “In 1404, a manifest for the specified container image may be obtained. In some embodiments, this manifest is obtained from a registry metadata storage service, such as the registry metadata service 222 of FIG. 2…”), (see Suarez, paragraph [0033]), (see Suarez, paragraph [0127]); and determining, by the computer, whether the identifier corresponding to the new version of the original container image is associated with the new increment file layer that contains the set of changed files based on the search of the remote image registry (see Suarez, paragraph [0036], “…Each time the container image is updated, a new container image layer may be created. Each container image layer may only contain data objects that have changed since the previous version of the container image. Accordingly, a layer may include a manifest that links to data objects within previous layers that have not changed…”), (see Suarez, paragraph [0033]). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include stopping the running microservice on an instruction to upgrade, determining the new version’s identifier, searching a remote registry for the identifier, and determining which layers the version comprises as taught by Suarez, for the result of allowing a host to obtain a specific new version on demand. Regarding claim 8, Huo discloses: generating, by the computer, a container to run the microservice based on the new version of the original container image (the new container must first be generated to be deployed, see Huo, paragraph [0102], “…the daemon 509 deploys a new container 524 running the new image 520.”), (see Huo, paragraph [0041], “…a computing system 100 may take many different forms, including bare metal computer systems, and virtualized computer systems, including systems with container-oriented architecture, and microservice-oriented architecture…”); and running, by the computer, the microservice using the container that was generated based on the new version of the original container image (see Huo, paragraph [0102]), (see Huo, paragraph [0041]). Regarding claim 17, Huo as modified does not appear to distinctly disclose: stop a microservice in response to receiving an input to upgrade the original container image to a new version of the original container image; determine an identifier corresponding to the new version of the original container image; perform a search of a remote image registry to locate the identifier corresponding to the new version of the original container image; and determine whether the identifier corresponding to the new version of the original container image is associated with the new increment file layer that contains the set of changed files based on the search of the remote image registry. However, Suarez discloses: stop a microservice (currently running version of the software) in response to receiving an input to upgrade the original container image to a new version of the original container image (see Suarez, paragraph [0127], “…the new version should be automatically deployed to replace the current version running in the container instance of the system.”), (see Suarez, paragraph [0128], “…the agent may stop any currently running version of the software of the container image…”); determine an identifier corresponding to the new version of the original container image (see Suarez, paragraph [0033], “…A manifest may comprise metadata such as an identity of the container image that corresponds to the manifest, and, for each layer listed in the manifest, a content-addressable identifier that uniquely corresponds to a respective layer…”), (see Suarez, paragraph [0127]); perform a search of a remote image registry (container registry) to locate the identifier corresponding to the new version of the original container image (see Suarez, paragraph [0034], “…the container registry front-end service 214 may query the registry metadata service 222 for the location of a data object in the storage service 290, and, as a result of receiving the location, may retrieve the data object corresponding to the location from the storage service 290.”), (see Suarez, paragraph [0114], “In 1404, a manifest for the specified container image may be obtained. In some embodiments, this manifest is obtained from a registry metadata storage service, such as the registry metadata service 222 of FIG. 2…”), (see Suarez, paragraph [0033]), (see Suarez, paragraph [0127]); and determine whether the identifier corresponding to the new version of the original container image is associated with the new increment file layer that contains the set of changed files based on the search of the remote image registry (see Suarez, paragraph [0036], “…Each time the container image is updated, a new container image layer may be created. Each container image layer may only contain data objects that have changed since the previous version of the container image. Accordingly, a layer may include a manifest that links to data objects within previous layers that have not changed…”), (see Suarez, paragraph [0033]). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include stopping the running microservice on an instruction to upgrade, determining the new version’s identifier, searching a remote registry for the identifier, and determining which layers the version comprises as taught by Suarez, for the result of allowing a host to obtain a specific new version on demand. Regarding claim 20, Huo discloses: generate a container to run the microservice based on the new version of the original container image (the new container must first be generated to be deployed, see Huo, paragraph [0102], “…the daemon 509 deploys a new container 524 running the new image 520.”), (see Huo, paragraph [0041], “…a computing system 100 may take many different forms, including bare metal computer systems, and virtualized computer systems, including systems with container-oriented architecture, and microservice-oriented architecture…”); and run the microservice using the container that was generated based on the new version of the original container image (see Huo, paragraph [0102]), (see Huo, paragraph [0041]). Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Huo, Gugick, and Suarez as applied to claims 5 and 17 above, and further in view of Cheng et al. (US20200218529, Cheng hereinafter). Regarding claim 6, Huo does not appear to distinctly disclose: responsive to the computer determining that the identifier corresponding to the new version of the original container image is associated with the new increment file layer that contains the set of changed files based on the search of the remote image registry, retrieving, by the computer, only the new increment file layer that contains the set of changed files from the remote image registry using the identifier; and adding, by the computer, the new increment file layer containing the set of changed files retrieved from the remote image registry to the plurality of original layers that includes the original file layer to form the new version of the original container image. However, Suarez discloses: responsive to the computer determining that the identifier corresponding to the new version of the original container image is associated with the new increment file layer that contains the set of changed files based on the search of the remote image registry, retrieving, by the computer, (see Suarez, paragraph [0114], “…the layers comprising the container image may be located; that is, because only layers that have been updated may be uploaded with a most recent version of the container image, not all layers comprising the container image may be located together… the manifest may include a content-addressable identifier associated with the other layers, and the location of the other layers may be located using the content-addressable identifier.”), (see Suarez, paragraph [0036], “… Each time the container image is updated, a new container image layer may be created. Each container image layer may only contain data objects that have changed since the previous version of the container image…”); and (see Suarez, paragraph [0114]), (see Suarez, paragraph [0036]), (see Suarez, paragraph [0114], “In 1404, a manifest for the specified container image may be obtained. In some embodiments, this manifest is obtained from a registry metadata storage service, such as the registry metadata service 222 of FIG. 2…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the retrieval of a new incremental file layer that contains the changed files from the remote registry using an identifier as taught by Suarez, for the result of obtaining the new version of the layer. Huo as modified does not appear to distinctly disclose: adding, by the computer, However, Cheng discloses: retrieving, by the computer, only the new increment file layer that contains the set of changed files (see Cheng, paragraph [0014], “…When a container image is upgraded, only an incremental part of the container needs to be downloaded. This reduces a download time and network bandwidth, reduces disk space on a device for storing the container image…”), (see Cheng, paragraph [0040], “Operation 401: Receive an incremental image file of the container, where the incremental image file includes a newly-added file, a modified file, and information about a deleted file…”); and adding, by the computer, the new increment file layer containing the set of changed files retrieved (see Cheng, paragraph [0040], “Operation 401: Receive an incremental image file of the container, where the incremental image file includes a newly-added file, a modified file, and information about a deleted file…”), (see Cheng, paragraph [0007], “…using the incremental image file as a file at a new first sublayer to form the first sublayer of the updated image layer, and using a file at an m.sup.th sublayer of the original image layer as a file at a new (m+1).sup.th sublayer to form the (m+1).sup.th sublayer of the updated image layer, where 1≤m≤n.”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the retrieval of only a new incremental file layer that contains the changed files as taught by Cheng, for the result of obtaining the new version of the layer. Regarding claim 18, Huo does not appear to distinctly disclose: retrieve only the new increment file layer that contains the set of changed files from the remote image registry using the identifier in response to determining that the identifier corresponding to the new version of the original container image is associated with the new increment file layer that contains the set of changed files based on the search of the remote image registry; and add the new increment file layer containing the set of changed files retrieved from the remote image registry to the plurality of original layers that includes the original file layer to form the new version of the original container image. However, Suarez discloses: retrieve (see Suarez, paragraph [0114], “…the layers comprising the container image may be located; that is, because only layers that have been updated may be uploaded with a most recent version of the container image, not all layers comprising the container image may be located together… the manifest may include a content-addressable identifier associated with the other layers, and the location of the other layers may be located using the content-addressable identifier.”), (see Suarez, paragraph [0036], “… Each time the container image is updated, a new container image layer may be created. Each container image layer may only contain data objects that have changed since the previous version of the container image…”); and (see Suarez, paragraph [0114]), (see Suarez, paragraph [0036]), (see Suarez, paragraph [0114], “In 1404, a manifest for the specified container image may be obtained. In some embodiments, this manifest is obtained from a registry metadata storage service, such as the registry metadata service 222 of FIG. 2…”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the retrieval of a new incremental file layer that contains the changed files from the remote registry using an identifier as taught by Suarez, for the result of obtaining the new version of the layer. Huo as modified does not appear to distinctly disclose: add However, Cheng discloses: retrieve only the new increment file layer that contains the set of changed files (see Cheng, paragraph [0014], “…When a container image is upgraded, only an incremental part of the container needs to be downloaded. This reduces a download time and network bandwidth, reduces disk space on a device for storing the container image…”), (see Cheng, paragraph [0040], “Operation 401: Receive an incremental image file of the container, where the incremental image file includes a newly-added file, a modified file, and information about a deleted file…”); and add the new increment file layer containing the set of changed files retrieved (see Cheng, paragraph [0040], “Operation 401: Receive an incremental image file of the container, where the incremental image file includes a newly-added file, a modified file, and information about a deleted file…”), (see Cheng, paragraph [0007], “…using the incremental image file as a file at a new first sublayer to form the first sublayer of the updated image layer, and using a file at an m.sup.th sublayer of the original image layer as a file at a new (m+1).sup.th sublayer to form the (m+1).sup.th sublayer of the updated image layer, where 1≤m≤n.”). It would have been obvious to one of ordinary skill in the art before the effecting filing date of the claimed invention to have modified a method for managing container images as taught by Huo, to include the retrieval of only a new incremental file layer that contains the changed files as taught by Cheng, for the result of obtaining the new version of the layer. Allowable Subject Matter Claims 7 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joshua Tran whose telephone number is (571)272-5460. The examiner can normally be reached on M-F 9-5. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /JOSHUA TRAN/ Examiner, Art Unit 2192 /S. Sough/SPE, Art Unit 2192
Read full office action

Prosecution Timeline

Jun 28, 2024
Application Filed
Jun 22, 2026
Non-Final Rejection mailed — §103
Jul 08, 2026
Response Filed
Jul 08, 2026
Applicant Interview (Telephonic)
Jul 08, 2026
Examiner Interview Summary

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month