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 .
This Office Action is in response to the Amendment filed on 05/27/2026.
In the instant Amendment: Claims 1, 2, 6, and 7 have been amended, claims 3-5 have been cancelled. Claims 1, 2, 6, 7 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Claim objection has been withdrawn.
Applicants' arguments in the instant Amendment, filed on 05/27/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, 2, 6, and 7. See Remarks at 2-3.
The examiner respectfully disagrees because these arguments are not persuasive.
Applicant argues that McKay and Suarez fail to disclose the amended claims because (1) “the cited references do not teach or suggest the claimed two-layer cryptographic architecture in which a first dedicated layer stores the manifest, a second dedicated layer stores a digital signature of a digest of the manifest, and verification is performed through decryption and digest comparison specifically against the manifest stored in the first layer, followed by integrity verification using layer digests associated with the manifests,” (2) “[i]mportantly, the amended claims now require a specific structural and cryptographic relationship between the first and second layers of the signed container image. The second layer is not merely a generic signature associated with a deployment resource, but rather a digital signature of a digest of the manifest comprised in the first layer,” and (3) “[f]urther, the amended claims now recite that the first and second layers each contain a single file.” See Remarks at 3 (emphasis added).
In contrast to Applicant’s assertions, Suarez et al. teaches a container image comprising a plurality of software layers, each layer can correspond to manifest related to metadata for such layer(s), and a hash-based digest for verifying authenticity of such layers:
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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format.
Specifically, FIG. 3 depicts a container image 352 comprising a series of six layers (labeled as subscripts 1, 2, 3, 4, 5, and 6) that has been uploaded to a registry 302… 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.
In some examples, a “manifest” may refer to metadata about the container image as well as metadata about the set of layers that the container image is comprised of.
As described in the present disclosure, each container image 1212 may be made up of a set of files and a manifest known as layers 1214…the system may analyze the indicated container image to determine a set of layers, which may be a subset of image files of the container image.
See Suarez ¶¶ [0033], [0046]-[0047], [0105], [0109] (emphasis added).
Here, Suarez teaches that a container image comprising a plurality of layers, each software layer can be associated with a manifest—a set of meta-data about the container image/software layer(s). A manifest can include a verifiable hash-based digest generated for the one or more layers. Finally, each manifest and/or a software layer may correspond to a software file.
Furthermore, McKay ¶¶ [0062], [0069] generally teaches about generating a digital signature with a digest encrypted with a private key. Digital signature verification can be accomplished with a corresponding public key and comparison of hashed digest.
Thus, the combination with McKay in view of Suarez teaches generating a digital signature from a hashed digest corresponding to one or more software layers and/or manifest of a container image. Furthermore, the digital signature and the manifest/digest can be stored at different container image layers that are also stored at different files. During verification, the digital signature and manifest/digest can be retrieved from each corresponding layer/files, the digital signature can be decrypted with a public key, and a comparison is made between the decrypted digital signature and the hashed manifest/digest.
Accordingly, applicant’s argument, especially the assertion that McKay in view of Suarez lacks “a specific structural and cryptographic relationship between the first and second layers of the signed container image, [t]he second layer is not merely a generic signature associated with a deployment resource, but rather a digital signature of a digest of the manifest comprised in the first layer,” 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, 2, 6, 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 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.);
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.);
verifying 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.)
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; digest of the manifest comprised in the second layer of the signed container image; for each layer of the manifest comprised in the first layer of the signed container image; wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file.
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.);
the digest of the manifest comprised in the second layer of the signed container image (Suarez [0033], [0110]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. 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.);
for each layer of the manifest comprised in the first layer of the signed container image (Suarez [0033], [0110]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. 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.).
wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file (Suarez [0033],[0105], [0109]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. As described in the present disclosure, each container image 1212 may be made up of a set of files and a manifest known as layers 1214…the system may analyze the indicated container image to determine a set of layers, which may be a subset of image files 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 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; digest of the manifest comprised in the second layer of the signed container image; for each layer of the manifest comprised in the first layer of the signed container image; wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file. 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.);
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.);
verifying 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.).
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; digest of the manifest comprised in the second layer of the signed container image; for each layer of the manifest comprised in the first layer of the signed container image; wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file.
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);
the digest of the manifest comprised in the second layer of the signed container image (Suarez [0033], [0110]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. 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.);
for each layer of the manifest comprised in the first layer of the signed container image (Suarez [0033], [0110]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. 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.).
wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file (Suarez [0033],[0105], [0109]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. As described in the present disclosure, each container image 1212 may be made up of a set of files and a manifest known as layers 1214…the system may analyze the indicated container image to determine a set of layers, which may be a subset of image files 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; digest of the manifest comprised in the second layer of the signed container image; for each layer of the manifest comprised in the first layer of the signed container image; wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file. 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 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.);
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.);
verifying 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
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.);
the digest of the manifest comprised in the second layer of the signed container image (Suarez [0033], [0110]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. 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.);
for each layer of the manifest comprised in the first layer of the signed container image (Suarez [0033], [0110]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. 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.).
wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file (Suarez [0033],[0105], [0109]. 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 and a checksum for verifying the integrity of the content of the layer. In some examples, a “container image” may be a virtual file system comprising a collection of data objects that make up the software application. The manifest may be a file written in any suitable format. As described in the present disclosure, each container image 1212 may be made up of a set of files and a manifest known as layers 1214…the system may analyze the indicated container image to determine a set of layers, which may be a subset of image files 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 first/second layer; digest of the manifest comprised in the second layer of the signed container image; for each layer of the manifest comprised in the first layer of the signed container image; wherein verifying the [signature] comprises verifying that the first and second layers of the signed container image each contain a single file. 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
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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
