DETAILED ACTION
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 under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/06/2026, for application 18/294,678 has been entered.
This Office Action is in response to the Amendment filed on 03/06/2026. In the instant amendment: Claims 1-3 have been amended. Claims 1-7 have been examined and are pending.
Objection
Claims 1, 3 are objected to because of the following informalities:
Regarding claim 1, claim 1 recites “receiving, by the pipeline server, the base container image.” (Emphasis added.) When a term first appears, “a/an” should be used. Whenever referring back to such a previously mentioned term, article “the” should be used. The claim language should be amended to “receiving, by a pipeline server, the base container image.”
Regarding claim 3, claim 3’ status is listed as “Previously Presented.” However, applicant amended punctuation of the claim language. Claim 3 should be listed as “Currently Amended” instead. Correction is requested.
Response to Arguments
Claim rejection under 35 U.S.C. 112(b) is withdrawn because of the current amendment.
Applicants' arguments in the instant Amendment, filed on 03/06/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant Argues: McKay in view of Suarez fails to disclose the amended claims 1 and 2. See Remarks at 2-3 (emphasis added).
The examiner respectfully disagrees because these arguments are not persuasive.
Applicant argues that McKay and Suarez fail to disclose the amended claims because these references teach a “fundamentally different type of ‘layers’.” Id. at 2. Applicant further explained that McKay fails to disclose “adding container image layers to a base container image, These layers form part of the image’s layered filesystem structure, such as the layered structure used in container image formats.” Id at 3.
In contrast to applicant’s reasoning, Suarez discloses:
In response to receiving the first request, the system may determine a set of container image layers that comprise the container image specified by the first request. The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image. Individual container image layers may comprise a set of files of the container image.
A series of layers may begin with a base image/layer for the underlying operating system (e.g., Ubuntu, Fedora, etc.). For example, layers 1-3 of the container image 352 may comprise layers of the underlying operating system. Layers 4-6, likewise, may comprise layers of one or more software applications (e.g., WordPress, Apache HTTP Server, etc.) to be installed to the underlying operating system. Each layer may have an associated content-addressable identifier, which may be generated by calculating a checksum (e.g., MDS, SHA1, SHA256, SHA512, etc.) for the layer.
See Suarez ¶¶ [0021], [0046] (emphasis added).
Here, Suarez discloses adding a series of layers to a virtual container image as a part of the file system structure, and adding a checksum or hash as a content-addressable identifier to each of these container image layers. Furthermore, McKay explains that “signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature.” See McKay ¶ [0062] (emphasis added). Thus, McKay in view of Suarez discloses adding layers to a virtual container image, and generating checksum and/or digital signatures to be appended to such container image layers. Accordingly, applicant’s assertion that McKay in view of Suarez fails to disclose the concept of “layers” is unpersuasive.
In conclusion, applicant’s argument is unpersuasive and the rejection of amended claims 1 is maintained. Rejection of claims 2, 6 and 7, which recite similar matters, is similarly maintained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically discloses as set forth in section 102 of this title, 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-7 are rejected under 35 U.S.C. 103 as being unpatentable over McKay et al. (“McKay,” US 20220019418, filed July 20, 2020) in view of Suarez et al. (“Suarez,” US 20170177877, published June 22, 2017).
Regarding claim 1, McKay discloses
A method for generating a signed container image from a base container image [comprising a plurality of container image layers], the method comprising (McKay FIGs 3, 5, [0043], [0056], [0062], [0073]. Referring now to FIG. 3, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 2) is shown. Software 460 may be a repository that may be written and read by deployment program 430 and signature function 440 and may be accessible to verification function 450. The software content may include, for example, virtual machine and container images. In general, software 460 may include any combination of content and configuration data capable of being deployed to node(s) 480. Software 460 may be, for example, a database. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest can be encrypted, forming a digital signature. Admission policy 700 depicts five sections that include signature requirements. More particularly, “spec.replicas,” “spec.template.metadata.*”, “spec.template.spec.containers.image.”),
receiving, by the pipeline server, the base container image (McKay [0034], [0056], [0060]-[0061. In cloud computing node 10 there is a computer system/server 12, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Software 460 may be a repository that may be written and read by deployment program 430 and signature function 440 and may be accessible to verification function 450. Software 460 may include, for example, software and deployment resources, such as configuration files (e.g., YAML, Ansible® Playbooks) and associated metadata. The software content may include, for example, virtual machine and container images. Examples of such configuration files are shown in FIGS. 8 and 9. A configuration file may be, for example, a YAML file. In step 510, signature function 440 receives a selection of one or more sections of the deployment resource to sign. In some instances, the signing user may select all of the sections, or specify that the entire file is to be signed.);
generating, by the pipeline server, the signed container image by cryptographically signing at least one of the plurality of container image layers (McKay FIGs 3, 5, [0043], [0056], [0062], [0073]. Referring now to FIG. 3, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 2) is shown. Software 460 may be a repository that may be written and read by deployment program 430 and signature function 440 and may be accessible to verification function 450. Software 460 may include, for example, software and deployment resources, such as configuration files (e.g., YAML, Ansible® Playbooks) and associated metadata. The software content may include, for example, virtual machine and container images. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature. Admission policy 700 depicts five sections that include signature requirements. More particularly, “spec.replicas,” “spec.template.metadata.*”, “spec.template.spec.containers.image,” …);
wherein the container hosting environment includes a master node acting as orchestrator and a plurality of the worker nodes running the container instantiating the signed container image [after pulling the signed container image from the image registry] (McKay [0052]-[0053], [0058], [0070]. In one embodiment, server 420 and node(s) 480 are part of a Kubernetes® environment, where server 420 represents a master node and node(s) 480 represent one or more worker nodes. In such an embodiment, verification function 450 may be a part of an application programming interface (API) server within the master node. Deployment program 430 executes on server 420. Deployment program 430 may be a dedicated deployment program, a function integrated within another program, such as an orchestration or software deployment program, or any other program or function that can communicate with nodes 480 and provide a user interface for interacting with deployment resources and creating/enforcing cryptographic signatures of deployment resources. In other embodiments, deployment program 430 may reside on other devices, provided that deployment program 430 can communicate with software 460, admission policy 470, and node(s) 480. Deployment program 430 may include signature function 440 and verification function 450. Software 490 may be, for example, a container, virtual machine, application, or any other software capable of being deployed. If verification function 450 determines that all necessary signatures are present and verified (decision 630, yes branch), verification function 450 permits deployment of the software to node(s) 480 (step 640) in accordance with the configuration and deployment parameters, resulting in software 490 operating on associated node(s) 480.),
generating, by the pipeline server, a signed container image [by adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer] comprising a digital signature of a digest of the manifest generated using a private key of the image provider (McKay FIG. 3, [0034], [0043], [0047], [0056], [0061]-[0062]. In cloud computing node 10 there is a computer system/server 12, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Referring now to FIG. 3, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 2) is shown [hardware/software layer, virtualization layer, management layer, and workloads layer]. Workloads layer 90 provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and mobile desktop 96. Software 460 may be a repository that may be written and read by deployment program 430 and signature function 440 and may be accessible to verification function 450. The software content may include, for example, virtual machine and container images. In general, software 460 may include any combination of content and configuration data capable of being deployed to node(s) 480. Software 460 may be, for example, a database. In step 510, signature function 440 receives a selection of one or more sections of the deployment resource to sign. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature.).
McKay does not explicitly disclose:
a base container image comprising a plurality of container image layers, for pushing the signed container image to an image registry of a container hosting environment, pulling the signed container image from the image registry; adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer; pushing, by the pipeline server, the signed container image to the image registry.
However, in an analogous art, Suarez discloses a method, comprising the step of:
a base container image comprising a plurality of container image layers (Suarez [0021]. In response to receiving the first request, the system may determine a set of container image layers that comprise the container image specified by the first request. The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image. Individual container image layers may comprise a set of files of the container image.),
for pushing the signed container image to an image registry of a container hosting environment (Suarez [0088], [0090]. The security token 974 may include a signature of the security token application programming interface 976 and/or the instance service interface 912 certifying the authenticity of the security token 974. As shown in the example 900, the software developer pushes the layers (including the manifest) of the container image 952 and the security token 974 in application programming interface requests to the container registry front-end service 914.),
pulling the signed container image from the image registry (Suarez [0128]. In 1604, the system may obtain a valid authentication token by making a call to a container registry front-end service, such as the container registry front-end service 114 of FIG. 1, such as in the manner described in conjunction with FIG. 9, in order to allow the system to act on behalf of the customer. The authentication token may be valid until it expires. In 1606, having obtained the authentication token, the system may make a request through a container engine, such as the container engine 208 of FIG. 2, to obtain the specified version of the container image);
adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer (Suarez [0021], [0110]. In response to receiving the first request, the system may determine a set of container image layers that comprise the container image specified by the first request. The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image. Individual container image layers may comprise a set of files of the container image. In 1306, a manifest may be generated for the subset of layers representing the container image being uploaded. As noted, the manifest can be comprised of metadata about the container image as well as metadata about the set of layers of which the container image is comprised.);
pushing, by the pipeline server, the signed container image to the image registry (Suarez [0090], [0093]. As shown in the example 900, the software developer pushes the layers (including the manifest) of the container image 952 and the security token 974 in application programming interface requests to the container registry front-end service 914. The content delivery network 1080 may be a distributed system of servers deployed in multiple geographic regions in around the world, communicating with each other via a network, such as the Internet.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine Suarez and McKay to include the step of: for pushing the signed container image to an image registry of a container hosting environment, pulling the signed container image from the image registry; the first layer comprising a manifest of the base container image; pushing the signed container image to the image registry. One would have been motivated to provide users with a means for signing and retrieving signed virtual/container images from designated registries. (See Suarez [0090].)
Regarding claim 2, McKay discloses a method, comprising:
A method [for securely pulling, to a worker node of a container hosting environment from an image registry],
a signed container image generated from a base container image [comprising a plurality of container image layers, by adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer] comprising a digital signature of a digest of the manifest generated using a private key of an image provider (McKay FIG. 3 (virtualization layer, management layer, workloads layer), [0043], [0047], [0056], [0061]-[0062]. Referring now to FIG. 3, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 2) is shown [hardware/software layer, virtualization layer, management layer, and workloads layer]. Workloads layer 90 provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and mobile desktop 96. Software 460 may be a repository that may be written and read by deployment program 430 and signature function 440 and may be accessible to verification function 450. The software content may include, for example, virtual machine and container images. In general, software 460 may include any combination of content and configuration data capable of being deployed to node(s) 480. Software 460 may be, for example, a database. In step 510, signature function 440 receives a selection of one or more sections of the deployment resource to sign. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature.), comprising:
verifying, by an image signature verification node, the signature of the digest of [the manifest comprised in the second layer] of the signed container image; verifying, by the image signature verification node, the integrity of the signed container image based on [the manifest comprised in the first layer] of the signed container image (McKay [0062], [0069]. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature. In decision 630, verification function 450 determines whether signatures are present and verified in the intercepted deployment resources. Verification function 450 compares the signatures present in the configuration file or other deployment resource and determines whether the required signatures are present. In addition, verification function 450 utilizes hash algorithms and/or public keys associated with each of the signatures to identify whether the signatures are valid. Verification of the signatures is accomplished by applying a hash function to the data and decrypting the signature using the signer's public key. If the resulting hashes are equal, the signature can be confirmed as valid.),
when verification of the signature and the integrity is successful, notifying, by the image signature verification node, a master node such that it allows the worker node to pull the signed container image (McKay [0052],[0070]. In one embodiment, server 420 and node(s) 480 are part of a Kubernetes® environment, where server 420 represents a master node and node(s) 480 represent one or more worker nodes. In such an embodiment, verification function 450 may be a part of an application programming interface (API) server within the master node. If verification function 450 determines that all necessary signatures are present and verified (decision 630, yes branch), verification function 450 permits deployment of the software to node(s) 480 (step 640) in accordance with the configuration and deployment parameters, resulting in software 490 operating on associated node(s) 480.),
wherein the container hosting environment includes a master node acting as orchestrator and a plurality of worker nodes running a container instantiating the signed container image [after pulling the signed container image from the image registry] (McKay [0052]-[0053], [0058], [0070]. In one embodiment, server 420 and node(s) 480 are part of a Kubernetes® environment, where server 420 represents a master node and node(s) 480 represent one or more worker nodes. In such an embodiment, verification function 450 may be a part of an application programming interface (API) server within the master node. Deployment program 430 executes on server 420. Deployment program 430 may be a dedicated deployment program, a function integrated within another program, such as an orchestration or software deployment program, or any other program or function that can communicate with nodes 480 and provide a user interface for interacting with deployment resources and creating/enforcing cryptographic signatures of deployment resources. In other embodiments, deployment program 430 may reside on other devices, provided that deployment program 430 can communicate with software 460, admission policy 470, and node(s) 480. Deployment program 430 may include signature function 440 and verification function 450. Software 490 may be, for example, a container, virtual machine, application, or any other software capable of being deployed. If verification function 450 determines that all necessary signatures are present and verified (decision 630, yes branch), verification function 450 permits deployment of the software to node(s) 480 (step 640) in accordance with the configuration and deployment parameters, resulting in software 490 operating on associated node(s) 480.).
McKay does not explicitly disclose:
for securely pulling, to a worker node of a container hosting environment from an image registry; a base container image comprising a plurality of container image layers, by adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer; pushed to the image registry of the container hosting environment; after pulling the signed container image from the image registry.
However, in an analogous art, Suarez discloses a method comprising the step of:
for securely pulling, to a worker node of a container hosting environment from an image registry (Suarez [0090], [0128]. As shown in the example 900, the software developer pushes the layers (including the manifest) of the container image 952 and the security token 974 in application programming interface requests to the container registry front-end service 914. In 1604, the system may obtain a valid authentication token by making a call to a container registry front-end service, such as the container registry front-end service 114 of FIG. 1, such as in the manner described in conjunction with FIG. 9, in order to allow the system to act on behalf of the customer. The authentication token may be valid until it expires. In 1606, having obtained the authentication token, the system may make a request through a container engine, such as the container engine 208 of FIG. 2, to obtain the specified version of the container image, the request including the authentication token. In 1608, as a result of the request being fulfilled and the system obtaining the specified version of the container image.);
a base container image comprising a plurality of container image layers, by adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer (Suarez [0021], [0110]. In response to receiving the first request, the system may determine a set of container image layers that comprise the container image specified by the first request. The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image. Individual container image layers may comprise a set of files of the container image. In 1306, a manifest may be generated for the subset of layers representing the container image being uploaded. As noted, the manifest can be comprised of metadata about the container image as well as metadata about the set of layers of which the container image is comprised.),
pushed to the image registry of the container hosting environment (Suarez [0088], [0090]. The security token 974 may include a signature of the security token application programming interface 976 and/or the instance service interface 912 certifying the authenticity of the security token 974. As shown in the example 900, the software developer pushes the layers (including the manifest) of the container image 952 and the security token 974 in application programming interface requests to the container registry front-end service 914.),
after pulling the signed container image from the image registry (Suarez [0128]. In 1604, the system may obtain a valid authentication token by making a call to a container registry front-end service, such as the container registry front-end service 114 of FIG. 1, such as in the manner described in conjunction with FIG. 9, in order to allow the system to act on behalf of the customer. The authentication token may be valid until it expires. In 1606, having obtained the authentication token, the system may make a request through a container engine, such as the container engine 208 of FIG. 2, to obtain the specified version of the container image).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine Suarez and McKay to include the step of: for securely pulling, to a worker node of a container hosting environment from an image registry; the first layer comprising a manifest of the base container image; pushed to the image registry of the container hosting environment comprising a pipeline server of the image provider; after pulling the signed container image from the image registry; the manifest in the first/second layer. One would have been motivated to provide users with a means for signing and retrieving signed virtual/container images from designated registries. (See Suarez [0090].)
Regarding claim 3, McKay and Suarez disclose the method of claim 2.
McKay further discloses
wherein verifying the signature comprises: obtaining a decrypted digest by decrypting the signature [of the digest of the manifest comprised in the second layer of the signed container image] using a public key corresponding to the secret key of the image provider; computing a digest of the manifest comprised in the first layer of the signed container image; and comparing the decrypted digest with the computed digest (McKay [0062], [0069]. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature. In decision 630, verification function 450 determines whether signatures are present and verified in the intercepted deployment resources. Verification function 450 compares the signatures present in the configuration file or other deployment resource and determines whether the required signatures are present. In addition, verification function 450 utilizes hash algorithms and/or public keys associated with each of the signatures to identify whether the signatures are valid. Verification of the signatures is accomplished by applying a hash function to the data and decrypting the signature using the signer's public key. If the resulting hashes are equal, the signature can be confirmed as valid.).
Suarez further discloses the digest of the manifest comprised in the second layer of the signed container image (Suarez [0110]. In 1306, a manifest may be generated for the subset of layers representing the container image being uploaded. As noted, the manifest can be comprised of metadata about the container image as well as metadata about the set of layers of which the container image is comprised.).
The motivation is the same as that of claim 2 above.
Regarding claim 4, McKay and Suarez disclose the method of claim 3.
McKay further discloses wherein verifying (S4) the integrity of the signed container image comprises: comparing, [for each layer of the manifest comprised in the first layer of the signed container image], a digest associated to the layer in the manifest with a digest associated to a corresponding layer in a manifest of the signed container image (McKay [0062], [0069]. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature. In decision 630, verification function 450 determines whether signatures are present and verified in the intercepted deployment resources. Verification function 450 compares the signatures present in the configuration file or other deployment resource and determines whether the required signatures are present. In addition, verification function 450 utilizes hash algorithms and/or public keys associated with each of the signatures to identify whether the signatures are valid. Verification of the signatures is accomplished by applying a hash function to the data and decrypting the signature using the signer's public key. If the resulting hashes are equal, the signature can be confirmed as valid.).
Suarez further discloses for each layer of the manifest comprised in the first layer of the signed container image (Suarez [0110]. In 1306, a manifest may be generated for the subset of layers representing the container image being uploaded. As noted, the manifest can be comprised of metadata about the container image as well as metadata about the set of layers of which the container image is comprised.).
The motivation is the same as that of claim 3 above.
Regarding claim 5, McKay and Suarez disclose the method of claim 4, McKay further discloses wherein verifying (S3) the signature comprises verifying that the first and second layers of the signed container image each contain a single file (McKay [0043], [0062], [0069]. Referring now to FIG. 3, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 2) is shown. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature. In decision 630, verification function 450 determines whether signatures are present and verified in the intercepted deployment resources. Verification function 450 compares the signatures present in the configuration file or other deployment resource and determines whether the required signatures are present. In addition, verification function 450 utilizes hash algorithms and/or public keys associated with each of the signatures to identify whether the signatures are valid. Verification of the signatures is accomplished by applying a hash function to the data and decrypting the signature using the signer's public key. If the resulting hashes are equal, the signature can be confirmed as valid.).
Regarding claim 6, McKay discloses
A computer program product stored on a non-transitory computer-readable storage medium directly loadable into the memory of at least one computer, comprising software code instructions for performing the steps of below when the product is run on the at least one computer (McKay [0080]. The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.):
generating a signed container image from a base container image comprising [a plurality of container image layers by adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer] comprising a digital signature of a digest of the manifest generated using a private key of the image provider (McKay FIG. 3 (virtualization layer, management layer, workloads layer), [0043], [0047], [0056], [0061]-[0062]. Referring now to FIG. 3, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 2) is shown [hardware/software layer, virtualization layer, management layer, and workloads layer]. Workloads layer 90 provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and mobile desktop 96. Software 460 may be a repository that may be written and read by deployment program 430 and signature function 440 and may be accessible to verification function 450. The software content may include, for example, virtual machine and container images. In general, software 460 may include any combination of content and configuration data capable of being deployed to node(s) 480. Software 460 may be, for example, a database. In step 510, signature function 440 receives a selection of one or more sections of the deployment resource to sign. In step 520, signature function 440 encrypts the selected sections as one or more digests and/or encrypted messages. In some embodiments, a one-way hash function is utilized to create a message digest for each of the selected sections. A message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature.); and
verifying the signature of the digest of the manifest comprised in the second layer of the signed container image; verifying the integrity of the signed container image based on the manifest comprised in the first layer of the signed container image (McKay [0062], [0069]. A message digest can be encrypted, forming a digital signature. As such, in other embodiments, the created message digest(s) are encrypted with a private key to create a digital signature. In decision 630, verification function 450 determines whether signatures are present and verified in the intercepted deployment resources. Verification function 450 compares the signatures present in the configuration file or other deployment resource and determines whether the required signatures are present. In addition, verification function 450 utilizes hash algorithms and/or public keys associated with each of the signatures to identify whether the signatures are valid. Verification of the signatures is accomplished by applying a hash function to the data and decrypting the signature using the signer's public key. If the resulting hashes are equal, the signature can be confirmed as valid.), and
notifying a master node such that it allows the worker node to pull the signed container image when verification of the signature and the integrity is successful (McKay [0052],[0070]. In one embodiment, server 420 and node(s) 480 are part of a Kubernetes® environment, where server 420 represents a master node and node(s) 480 represent one or more worker nodes. In such an embodiment, verification function 450 may be a part of an application programming interface (API) server within the master node. If verification function 450 determines that all necessary signatures are present and verified (decision 630, yes branch), verification function 450 permits deployment of the software to node(s) 480 (step 640) in accordance with the configuration and deployment parameters, resulting in software 490 operating on associated node(s) 480.).
Suarez further discloses
container image layers by adding a first layer and a second layer to the base container image, the first layer comprising a manifest of the base container image and the second layer (Suarez [0021], [0110]. In response to receiving the first request, the system may determine a set of container image layers that comprise the container image specified by the first request. The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image. Individual container image layers may comprise a set of files of the container image. In 1306, a manifest may be generated for the subset of layers representing the container image being uploaded. As noted, the manifest can be comprised of metadata about the container image as well as metadata about the set of layers of which the container image is comprised.);
pushing the signed container image to the image registry of a container hosting environment (Suarez [0088], [0090]. The security token 974 may include a signature of the security token application programming interface 976 and/or the instance service interface 912 certifying the authenticity of the security token 974. As shown in the example 900, the software developer pushes the layers (including the manifest) of the container image 952 and the security token 974 in application programming interface requests to the container registry front-end service 914.);
pulling, by a worker node of the container hosting environment, from the image registry, a signed container image (Suarez [0128]. In 1604, the system may obtain a valid authentication token by making a call to a container registry front-end service, such as the container registry front-end service 114 of FIG. 1, such as in the manner described in conjunction with FIG. 9, in order to allow the system to act on behalf of the customer. The authentication token may be valid until it expires. In 1606, having obtained the authentication token, the system may make a request through a container engine, such as the container engine 208 of FIG. 2, to obtain the specified version of the container image.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine Suarez and McKay to include the step of: for securely pulling, to a worker node of a container hosting environment from an image registry, a signed container image generated and pushed to the image registry according to claim 1 (see claim 1 above); the manifest in the the first/second layer. One would have been motivated to provide users with a means for signing and retrieving signed virtual/container images from designated registries. (See Suarez [0090].)
Regarding claim 7, claim 7 is directed to a image signature verification node corresponding to the computer program product of claim 6. Claim 7 is similar to claim 6 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Luu Pham can be reached on 571 270 5002. 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.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights