DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
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 3/4/2026 have been entered. The claims 1, 9 and 16 have been amended. The claims 1-20 are pending in the current application.
Response to Arguments
Applicant's arguments filed 3/4/2026 have been fully considered but they are not persuasive.
In Remarks, applicant made general allegation that Sparks does not teach the new claim limitation: wherein the second version of the image is generated subsequent to generation of the augmented image digest, and the augmented image digest comprises a placeholder descriptor corresponding to the second architecture. The examiner cannot concur.
Sparks teaches the new claim limitation: wherein the second version of the image is generated subsequent to generation of the augmented image digest, and the augmented image digest comprises a placeholder descriptor corresponding to the second architecture.
In a non-limiting example, Sparks teaches that the augmented image digest contains image manifest 200 and image index 200 (that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118) and the expanded image metadata 214 for the different versions of a container image 118 and is generated subsequent to the creation of the different versions of the container image 118 that can run on different platforms.
Sparks teaches at Paragraph [0075] Certain embodiments of this disclosure define particular container metadata 120, which may be represented as expanded metadata 214. Expanded metadata 214 may include one or more fields that describe the containerized application represented by container image 118 and/or the runtime environment and/or the interface between a container generated from container image 118 and a host (e.g., a compute node of computing environment 106 on which the container instance 144 generated from container image 118 is run). For example, certain embodiments define particular fields of container metadata 120 (expanded metadata 214) to include information that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment. To the extent container image 118 follows the OCI standards specification, certain embodiments expand the few metadata fields defined by the OCI standards specification to include additional fields that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
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 disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7 and 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sparks et al. US-PGPUB No.2025/0238253 (hereinafter Sparks) in view of
Shah et al. US-PGPUB No. 2024/0211231 (hereinafter Shah);
Osadchyy et al. US-PGPUB No. 2024/0345902 (hereinafter Osadchyy);
Suarez et al. US-PGPUB No. 2017/0177877 (hereinafter Suarez);
Carvalho et al. US-PGPUB No. 2018/0365006 (hereinafter Carvalho).
Re Claim 1:
Sparks teaches a method, comprising:
receiving, from an image registry in response to a client request from a client, an image digest identifying a first version of an image for a first architecture (
Sparks teaches at Paragraph [0109] A container registry (e.g., storage device 112 of FIG. 1) may store a container image (e.g., container image 118a) for a containerized application.
Applicant’s specification discloses at Paragraph 0019 that the image digest may be any file, message, document, binary object, and/or the like that identifies and/or describes resources for retrieving a container image from a registry. For instance, the image digest may be a data object, such as, for example, a markup language object, contained in the body of a message and/or as a data file, such as, for example, an HTTP message. In various implementations, an image digest may include information about a specific version of an image and/or may include information about multiple versions of an image. For example, the image digest may be an image manifest that describes content for a specific image version, such as configurations, data object identifiers and/or locations, embedded content, and/or the like. For instance, the image digest may be formatted as an image manifest as defined by a container-related standard promulgated by the Open Containers Initiative (OCI). As another example, the image digest may be an image index that includes a list identifying one or more versions of an image. For example, the image digest may include a list of image manifests for specific image versions. For instance, the image digest may be formatted as an image index as defined by an OCI standard. In further examples, the image digest may include information identifying resources for one or more specific image versions and information identifying a list of image manifests for other versions of the image.
Sparks teaches at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration. The OCI image manifest specification describes labels and annotations as schema elements in the OCI image specification. Labels typically are set in the OCI image configuration, while annotations can be supported in multiple files, though annotations typically are provided in the image index or manifest.
Sparks teaches at Paragraph 0041 that interface 114 of container-provider system 102 may receive requests for container metadata 120 and/or container images 118 from computing environment 106 and/or transmit container metadata 120 and/or container images 118 to those requests. Sparks teaches at Paragraph 0051 that container engine operations may include accepting user requests, including command line options, pulling container images (e.g., container images 118), and running the container. Sparks teaches at Paragraph 0054 that interface 126 of compute node 1 may transmit metadata requests 130 and/or container image requests 134 to container-provider system 102 and/or receive responses 132 that include container metadata 120 and/or responses 136 that include container images 118 from container-provider system 102.
Sparks teaches at Paragraph 0028 that container-provider system 102 is configured to receive via network 104 from computing environment 106 requests for container metadata for containerized applications and requests for container images for containerized applications, and to communicate, in response to those requests container metadata and container images to computing environment 106 via network 104. The container metadata for a containerized application includes certain information that may be useful to computing environment 106 to evaluate whether to download the container image for the containerized application and/or whether and/or how to deploy the containerized application within computing environment 106.
Sparks teaches at Paragraph 0016 that in instance of the container image is generated when the image is started using a “run” command and images may be stored in a container image registry and at Paragraph 0063 that container management engine 128 may access the container metadata 120 associated with the containerized application by obtaining the container metadata 120 from an image manifest of the container image 118 and at Paragraph 0076 that expanded metadata 214 may include OS features, MPI variant, and architecture (Arch).
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform);
generating an augmented image digest, the augmented image digest identifying the first version of the image and a second version of the image for a second architecture (
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform
Applicant’s specification discloses at Paragraph 0019 that the image digest may be any file, message, document, binary object, and/or the like that identifies and/or describes resources for retrieving a container image from a registry. For instance, the image digest may be a data object, such as, for example, a markup language object, contained in the body of a message and/or as a data file, such as, for example, an HTTP message. In various implementations, an image digest may include information about a specific version of an image and/or may include information about multiple versions of an image. For example, the image digest may be an image manifest that describes content for a specific image version, such as configurations, data object identifiers and/or locations, embedded content, and/or the like. For instance, the image digest may be formatted as an image manifest as defined by a container-related standard promulgated by the Open Containers Initiative (OCI). As another example, the image digest may be an image index that includes a list identifying one or more versions of an image. For example, the image digest may include a list of image manifests for specific image versions. For instance, the image digest may be formatted as an image index as defined by an OCI standard. In further examples, the image digest may include information identifying resources for one or more specific image versions and information identifying a list of image manifests for other versions of the image.
Sparks teaches at Paragraph 0020 that annotations typically are provided in the image index or manifest and at Paragraph 0022 that this metadata may be inserted into the container image as labels, annotations, or both, and may be implemented as key-value pairs. As particular examples, the expanded metadata for a containerized application may include one or more of the following: operating system (OS) application binary interface (ABI); OS features; message passing interface (MPI) ABI standard - - - MPI variant; MPI process management interface (PMI); workload management (WLM)/orchestration; graphics processing unit (GPU) details; central processing unit (CPU) details (including, e.g., microarchitecture (uArch)); network details; and device drivers.
Sparks teaches at Paragraph 0071 that container image 118 includes an image manifest 200, an image index 202 (image digest), one or more filesystem layers 204, and an image configuration 206.
Sparks teaches at Paragraph [0075] Certain embodiments of this disclosure define particular container metadata 120, which may be represented as expanded metadata 214. Expanded metadata 214 may include one or more fields that describe the containerized application represented by container image 118 and/or the runtime environment and/or the interface between a container generated from container image 118 and a host (e.g., a compute node of computing environment 106 on which the container instance 144 generated from container image 118 is run). For example, certain embodiments define particular fields of container metadata 120 (expanded metadata 214) to include information that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment. To the extent container image 118 follows the OCI standards specification, certain embodiments expand the few metadata fields defined by the OCI standards specification to include additional fields that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform);
Wherein the second version of the image is generated subsequent to generation of the augmented image digest, and the augmented image digest comprises a placeholder descriptor corresponding to the second architecture (
Sparks teaches that the augmented image digest contains image manifest 200 and image index 200 (that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118) and the expanded image metadata 214 for the different versions of a container image 118 and is generated subsequent to the creation of the different versions of the container image 118 that can run on different platforms.
Sparks teaches at Paragraph [0075] Certain embodiments of this disclosure define particular container metadata 120, which may be represented as expanded metadata 214. Expanded metadata 214 may include one or more fields that describe the containerized application represented by container image 118 and/or the runtime environment and/or the interface between a container generated from container image 118 and a host (e.g., a compute node of computing environment 106 on which the container instance 144 generated from container image 118 is run). For example, certain embodiments define particular fields of container metadata 120 (expanded metadata 214) to include information that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment. To the extent container image 118 follows the OCI standards specification, certain embodiments expand the few metadata fields defined by the OCI standards specification to include additional fields that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform);
providing the augmented image digest to the client in a response to the client request (
Sparks teaches at Paragraph 0071 that container image 118 includes an image manifest 200, an image index 202 (image digest), one or more filesystem layers 204, and an image configuration 206.
Sparks teaches at Paragraph [0075] Certain embodiments of this disclosure define particular container metadata 120, which may be represented as expanded metadata 214. Expanded metadata 214 may include one or more fields that describe the containerized application represented by container image 118 and/or the runtime environment and/or the interface between a container generated from container image 118 and a host (e.g., a compute node of computing environment 106 on which the container instance 144 generated from container image 118 is run). For example, certain embodiments define particular fields of container metadata 120 (expanded metadata 214) to include information that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment. To the extent container image 118 follows the OCI standards specification, certain embodiments expand the few metadata fields defined by the OCI standards specification to include additional fields that may be useful for container management engine 128 to determine whether a containerized application implemented by a container instance 144 generated from a particular container image 118 is suitable to run in a particular computing environment (e.g., computing environment 106) and/or how to deploy the containerized application within the particular computing environment.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Sparks teaches at Paragraph 0051 that container engine operations may include accepting user requests, including command line options, pulling container images (e.g., container images 118), and running the container. Sparks teaches at Paragraph 0054 that interface 126 of compute node 1 may transmit metadata requests 130 and/or container image requests 134 to container-provider system 102 and/or receive responses 132 that include container metadata 120 and/or responses 136 that include container images 118 from container-provider system 102.
Sparks teaches at Paragraph [0093] If container management engine 128 determines at step 504 to deploy the first containerized application in the computing environment (e.g., computing environment 106), then at step 506, in response to determining to deploy the first containerized application in the computing environment, container management engine 128 may download the first container image (e.g., container image 118a) for the first containerized application and at Paragraph 0094 deploying, according to the first container image, the first containerized application in the computing environment for execution includes deploying a container instance of the container image of the first containerized application to a computing node of the computing environment for execution and at Paragraph 0097 that deploying, according to the first container image, the first containerized application in the computing environment for execution includes deploying a container instance of the container image of the first containerized application to a computing node of the computing environment for execution).
Shah/Osadchyy teaches a method, comprising:
receiving, from an image registry in response to a client request from a client, an image digest identifying a first version of an image for a first architecture (
Osadchyy teaches at Paragraph 0048 that in response to receiving the notification from container scheduler 206, container runtime 214 sends pull request 220 for original container image 222, which corresponds to container 216, to multi-architecture registry proxy 210. Multi-architecture registry proxy 210 then pulls original container image 222 from container registry 208. However, it should be noted that original container image 222 is built for original processor architecture (OPA) 224 (e.g., x86 processor architecture), which is different from target processor architecture 218 (e.g., s390x processor architecture).
Osadchyy teaches at Paragraph 0050 that container runtime 214 can modify pull request 220 for original container image 222 to include information, such as, for example, a modified manifest list identifying target layers of target container image 226 for target processor architecture 218.
Shah teaches at Paragraph 0043 that a user may submit a request to deploy an instance of the container image 230 within a runtime environment of a host platform and the host platform may launch/deploy a new instance of the container and pull image layers from the container image 230 into an image build generated from the container image 230 and the user may request which optional features they are interested in and select only those features for inclusion in the final image build that is used to deploy the container and the application. Shah teaches at Paragraph 0045 that a request with an identifier for a “latest” version of the application corresponding to the container may be interpreted by the container engine as only the “required” layers of the container image without any of the optional layers.
Shah teaches at Paragraph 0046 that to request the first image layer 231, the user may submit a request to a container registry of the container engine (e.g., via a user interface, API, etc.) which identifies the tag A (e.g., tag id=A). Likewise, to request the second image layer 232, the user may submit a request to the container registry which identifies the tag B (e.g., tag id=B). The registry may compile the build file to identify which tags correspond to which image layers. Next, the registry may exclude any optional image layers which are not requested with the tag identifier and only pull the required image layers and any optional image layers that are identified by the tag identifier.
Shah teaches at Paragraph [0047] The image layers of the container image 230 may include various features. For example, one of the first image layers within the container image may contain an operating system such as a Ubuntu operating system of a virtual machine);
generating an augmented image digest, the augmented image digest identifying the first version of the image and a second version of the image for a second architecture (
Osadchyy teaches at Paragraph 0053 that mapping operations 300 involve original container image 302 and target container image 304. However, it should also be noted that source layer 306, source layer 308, source layer 310, source layer 312, source layer 314, source layer 316, and source layer 318 are each built for a specific processor architecture (e.g., x86 processor architecture) and target layer 320, target layer 322, target layer 324, target layer 326, target layer 328, target layer 330, and target layer 332 are each built and optimized for a different specific processor architecture (e.g., s390x processor architecture).
Osadchyy teaches at Paragraph 0048 that in response to receiving the notification from container scheduler 206, container runtime 214 sends pull request 220 for original container image 222, which corresponds to container 216, to multi-architecture registry proxy 210. Multi-architecture registry proxy 210 then pulls original container image 222 from container registry 208. However, it should be noted that original container image 222 is built for original processor architecture (OPA) 224 (e.g., x86 processor architecture), which is different from target processor architecture 218 (e.g., s390x processor architecture).
Osadchyy teaches at Paragraph 0050 that container runtime 214 can modify pull request 220 for original container image 222 to include information, such as, for example, a modified manifest list identifying target layers of target container image 226 for target processor architecture 218.
Osadchyy teaches at Paragraph [0051] The Open Containers Initiative defines a container image as a manifest with a configuration and plurality of layers for a specific processor architecture and operating system combination. As used herein, an original container image defines a container image that a program developer builds and publishes for a particular processor architecture. Multi-architecture registry proxy 210 of illustrative embodiments examines each respective layer of original container image 222. Multi-architecture registry proxy 210 initially considers each respective layer as a layer built for original processor architecture 224. Then, multi-architecture registry proxy 210 retrieves information, such as layer-to-layer mappings, application type, computational resource ratios, and the like, from mapping table 228 and generates respective target layers of target container image 226 for target processor architecture 218. Container image layers include, for example, application configuration data, application initial data, application, its associated dependencies, runtime, libraries, base operating system, and optional operating system packages. Multi-architecture registry proxy 210 performs mapping operations that include transfer, substitute, and convert. Multi-architecture registry proxy 210 utilizes emulator 230 to perform the conversion mapping operation by, for example, wrapping a binary of the application with an emulation (i.e., instructions) for target processor architecture 218. Emulator 230 can represent a plurality of different emulators for a plurality of different processor architectures. In addition, multi-architecture registry proxy 210 determines the type of the application, processor architecture affinity, and computational resource ratios by analyzing the information contained in mapping table 228.
[0071] The process begins when a multi-architecture registry proxy of the computer receives a request to pull an original source container image stored in a container registry from a container runtime of a target host computer node via a network (step 702). The original source container image corresponds to a container, which is associated with an application, that is scheduled to run on the target host computer node.
[0072] In response to receiving the request in step 702, the multi-architecture registry proxy determines that the original source container image built for a first type of processor architecture is incompatible with a second type of processor architecture corresponding to the target host computer node (step 704). The first type of processor architecture is different from the second type of processor architecture based on a determined degree of architectural dissimilarity between the first type of processor architecture and the second type of processor architecture.
[0073] In response to determining that the original source container image built for the first type of processor architecture is incompatible with the second type of processor architecture corresponding to the target host computer node in step 704, the multi-architecture registry proxy performs dynamic mapping of respective source image layers of the original source container image built for the first type of processor architecture to corresponding target image layers for the second type of processor architecture that is different from the first type of processor architecture (step 706). The dynamically mapping of the respective source image layers of the original source container image built for the first type of processor architecture to the corresponding target image layers of the target container image optimized for the second type of processor architecture includes at least one of: the multi-architecture registry proxy transferring a first set of image layers of the original source container image that contain cross-platform interpretive application data (e.g., application initial data, application configuration data, cross-platform interpretive application, and associated cross-platform interpretive application libraries) to the target container image; the multi-architecture registry proxy substituting a second set of image layers of the original container image that contain cross-platform interpretive runtime data associated with the first type of processor architecture with corresponding image layers that contain interpretive runtime data compatible with the second type of processor architecture; or the multi-architecture registry proxy converting a third set of image layers of the original container image that contain first binary application data (e.g., a binary of the application and a binary of its associated application libraries) to corresponding image layers that contain second binary application data that are compatible with the second type of processor architecture.
Shah teaches at Paragraph 0045 that a request with an identifier for a “latest” version of the application corresponding to the container may be interpreted by the container engine as only the “required” layers of the container image without any of the optional layers. Thus, the container engine may deploy only the necessary layers while excluding all optional layers. Any of these final configurations may be pulled (i.e., downloaded and stored in a container) during deployment of an image build generated from the container image 230 based on tags that are embedded within the build file of the container image 230.
Shah teaches at Paragraph 0049 that the registry may transfer the tag identifier to a container engine which may push the final image to the container in the runtime environment.
Shah teaches at Paragraph 0071 that the container engine 426 may run multiple instances of the container image 430 within a runtime environment 428 thereof. For example, the container engine 426 may include a service (e.g., a daemon) that is responsible for pulling content from the container image 430 to generate a final container image, and then deploying the final container image within the runtime environment 428.
Shah teaches at Paragraph 0072 that based on a manifest, a registry may know that TAG A requires the optional image layer 432 and it will only pull the required image layers and the optional image layer 432 and the manifest may be stored with the container image 430 and the original image and the manifest file will be downloaded by deployment.
Shah teaches at FIG. 2 and Paragraph 0042 that FIG. 2 illustrates an example of a multi-variant container image 230 and at Paragraph 0043 that different variations of image layers may be pulled from the container image 230 and added to a container in a runtime environment.
Shah teaches at FIGS. 4A-4D that the Build File 400 includes the operating system specification “ubuntu”.
Shah teaches at Paragraph [0072] In response to a request for an image build from the container image 430, the host platform 420 may generate the container image 430 including all of the layers therein. That is the, host platform may start with the entire container image 430 built therein. Next, the build file 400 may be compiled to identify which optional layers of the container image 430 are to be included in the final image build. In particular, the compiling may identify a tag identifier corresponding to which optional layers to include. For example, based on a manifest, a registry may know that TAG A requires the optional image layer 432 and it will only pull the required image layers and the optional image layer 432. The manifest may be stored with the container image 430. When the build file is compiled, the host platform can create a manifest with all kinds of different tag options. For example, TAG A, TAG C, TAG E, etc. may be defined in a custom build file. Then, the different image layers may be assigned different tags. The original image and the manifest file which will be download by deployment.
Shah teaches at Paragraph 0076 that the container engine 426 may run multiple instances of the container image 430 within a runtime environment 428 thereof.
Shah teaches at Paragraph 0080 that the pulling may include pulling only required image layers to the container in the runtime environment in response to a predefined tag identifier being included in the request. In some embodiments, the pulling may include pulling one or more optional image layers from the container image to the instance of the container in response to a predefined tag identifier being included in the request.); and
providing the augmented image digest to the client in a response to the client request (
Osadchyy teaches at Paragraph 0058 that the multi-architecture registry proxy substitutes source layer 406 and source layer 408 of original container image 402 with target layer 418 and target layer 420 corresponding to a base operating system and operating system packages of target container image 404 that are optimized for the target processor architecture (e.g., s390x processor architecture). Osadchyy teaches at Paragraph 0060 that the multi-architecture registry proxy places converted source layer 412 of the binary of the application with its emulation wrapper and converted source layer 410 of binary libraries with their emulation wrappers in corresponding target layer 424 and target layer 422 of target container image 404 optimized for the target processor architecture (e.g., s390x processor architecture).
[0071] The process begins when a multi-architecture registry proxy of the computer receives a request to pull an original source container image stored in a container registry from a container runtime of a target host computer node via a network (step 702). The original source container image corresponds to a container, which is associated with an application, that is scheduled to run on the target host computer node.
[0072] In response to receiving the request in step 702, the multi-architecture registry proxy determines that the original source container image built for a first type of processor architecture is incompatible with a second type of processor architecture corresponding to the target host computer node (step 704). The first type of processor architecture is different from the second type of processor architecture based on a determined degree of architectural dissimilarity between the first type of processor architecture and the second type of processor architecture.
[0073] In response to determining that the original source container image built for the first type of processor architecture is incompatible with the second type of processor architecture corresponding to the target host computer node in step 704, the multi-architecture registry proxy performs dynamic mapping of respective source image layers of the original source container image built for the first type of processor architecture to corresponding target image layers for the second type of processor architecture that is different from the first type of processor architecture (step 706). The dynamically mapping of the respective source image layers of the original source container image built for the first type of processor architecture to the corresponding target image layers of the target container image optimized for the second type of processor architecture includes at least one of: the multi-architecture registry proxy transferring a first set of image layers of the original source container image that contain cross-platform interpretive application data (e.g., application initial data, application configuration data, cross-platform interpretive application, and associated cross-platform interpretive application libraries) to the target container image; the multi-architecture registry proxy substituting a second set of image layers of the original container image that contain cross-platform interpretive runtime data associated with the first type of processor architecture with corresponding image layers that contain interpretive runtime data compatible with the second type of processor architecture; or the multi-architecture registry proxy converting a third set of image layers of the original container image that contain first binary application data (e.g., a binary of the application and a binary of its associated application libraries) to corresponding image layers that contain second binary application data that are compatible with the second type of processor architecture.
Shah teaches at Paragraph 0080 that the pulling may include pulling only required image layers to the container in the runtime environment in response to a predefined tag identifier being included in the request. In some embodiments, the pulling may include pulling one or more optional image layers from the container image to the instance of the container in response to a predefined tag identifier being included in the request).
It would have been obvious to one of the ordinary skill in the art before the filing date of the instant application to have incorporated the additional features of Osadchyy/Shah of pulling the required image layers to build instances of the container images for the different types of architectures in a runtime environment into the container provider system of Sparks to have provided a second version of the container image adapted to a second architecture. One of the ordinary skill in the art would have been motivated to have provided the combination of an original image manifest and a modified image manifest as an augmented image manifest identifying target layers of target container image for target processor architecture (Osadchyy Paragraph 0050).
Sparks in view of Suarez/Carvalho teaches receiving from an image registry in response to a client request from a client, an image digest identifying a first version of an image for a first architecture (
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0027 that one or more base layers of the container image 152 may comprise the operating system used to execute other software applications.
Suarez teaches at Paragraph 0046 that 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, such as the container registry 202 of FIG. 2, three times (images 346A-346B) over three time periods. 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.
Suarez teaches at Paragraph 0112 that the process 1400 includes a series of operations wherein a request is received to launch the container image, the manifest for the requested container image is located, the layers comprising the container image are located based on the manifest, the container image is downloaded to a container instance, in the container image is launched in a software container of the container instance.
Suarez teaches at Paragraph 0127 that the process 1600 detects an event requiring obtaining a software image from a repository and one example of such an event may be receiving a request by a customer through an API of a container registry front-end service directing the agent to obtain and launch the specified container image and the automated build service communicates to the system performing the process 1600 that the new version should be automatically deployed to replace the current version running in the container instance of the system.
Suarez teaches at Paragraph 0057 that it may be that a publicly available layer of a particular version of an operating system has a known Secure Shell (SSH) vulnerability, and the publicly available layer has a content-addressable identifier of “df9cb78ee4b0,” the security sweep 454 may search the manifests in the repository for content-addressable identifiers of layers matching “df9cb78ee4b0.” Whether a security vulnerability exists may be determined by a vendor of software (e.g., a vendor providing the particular publicly available layer of the previous example), determined by the computing resource service provider hosting the container registry/repositories, or determined by the customer of the computing resource service provider associated with the particular repository being swept.
Suarez teaches at Paragraph [0058] In the latter case, in some implementations a container registry front-end service, such as the container registry front-end service 214 of FIG. 2, provides an application programming interface that the customer can call and through which the customer can specify a content-addressable identifier for the layer that the customer wishes to have swept from his/her repository by the security sweep 454. In this latter case, the reasons for performing the sweep may be at the discretion of the customer and may not necessarily be for security vulnerability purposes; e.g., the customer may simply decide that certain applications should be updated or no longer need to be included in the container image. As noted in the present disclosure, in some embodiments the manifests/metadata is searched using a registry metadata service, such as the registry metadata service 222 of FIG. 2
Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 and another image manifest from the cluster of nodes 118 to generate a manifest list). The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download);
Generating an augmented image digest, the augmented image digest identifying the first version of the image and the second version of the image for a second architecture (
Carvalho teaches at Paragraph 0018 that every node in the cluster of nodes 112 has computer architecture A and Paragraph 0019 that every node in the cluster of nodes 118 has computer architecture B. Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 (having architecture A) and another image manifest from the cluster of nodes 118 (having architecture B) to generate a manifest list. The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0021 that the system may also obtain or generate a manifest that contains metadata about the set of container image layers and at Paragraph 0033 that metadata stored by the registry metadata service 22 may include a historical record of changes in the repository and version tracking information and manifests for container images stored in the storage service 290 and at Paragraph 0044 that The registry metadata service 222 may store container image manifests, tag information, and revision history of container images in the storage service 290.
Suarez teaches at Paragraph 0033 that the registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries. Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest.
Suarez teaches at FIG. 3 that generating the augmented image manifest 350B and 350A identifying the first version of the image v1 and the second version of the image v2.
Suarez teaches at [0047] that, 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. The manifest may be stored as a separate file, or in a database in a separate field from the container image. In this manner, the manifest specifies which layers are associated with the container image, and thus, when a new container image is uploaded, it can be determined from the manifest which layers of the image may or may not already be stored in the registry 302. The manifest may be a file written in any suitable format, such as using JSON.
Suarez teaches at Paragraph 0048 that the second version 346B (image v2) is stored with the updated layers and a manifest 350B indicating the locations of the layers of the version of the container image 352 at the second time.
Suarez teaches at Paragraph 0056 that if a particular layer of the container image of an underlying Ubuntu operating system has a security vulnerability, the security sweep may discover from the manifest 350B that the content-addressable identifier of layer 2 listed in the manifest 350B matches the content-addressable identifier provided to the security sweep associated with the insecure layer and may flag layer 2 as un-referenceable and may prevent layer 2 from being used);
Providing the augmented image digest to the client in a response to the client request (
Carvalho teaches at Paragraph 0018 that every node in the cluster of nodes 112 has computer architecture A and Paragraph 0019 that every node in the cluster of nodes 118 has computer architecture B. Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 (having architecture A) and another image manifest from the cluster of nodes 118 (having architecture B) to generate a manifest list. The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0033 that the registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries. Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest.
Suarez teaches at Paragraph [0113] In 1402, the system receives a request (e.g., through the container registry front-end service 114 of FIG. 1) to launch a specified container image. As described in the present disclosure the request may be received from any of a variety of entities, such as from a computing device being operated by the customer associated with the repository.
Suarez teaches at Paragraph [0114] In 1404, a manifest for the specified container image may be obtained. In some embodiments, this manifest is obtained from a registry metadata storage service, such as the registry metadata service 222 of FIG. 2. Based on the metadata in the manifest, in 1406, the layers comprising the container image may be located; that is, because only layers that have been updated may be uploaded with a most recent version of the container image.
Suarez teaches at Paragraph 0056 that if a particular layer of the container image of an underlying Ubuntu operating system has a security vulnerability, the security sweep may discover from the manifest 350B that the content-addressable identifier of layer 2 listed in the manifest 350B matches the content-addressable identifier provided to the security sweep associated with the insecure layer and may flag layer 2 as un-referenceable and may prevent layer 2 from being used).
It would have been obvious to one of the ordinary skill in the art before the filing date of the instant application to have recognized from the teaching of Sparks that different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform to have recognized that Suarez’s different versions of the container images 346A-346B are created to run on different platforms wherein Suarez teaches that the container images v1 and v2 may be associated with different operating systems by modifying the one or more base images of the container image with the different operating systems including Red Hat Linux, Microsoft Windows, Apple OS X, etc. and the one or more base image layers can be modified as shown at FIG. 3 to be associated with different operating systems. One of the ordinary skill in the art would have provided an augmented image manifest for the different versions of the container image designed for the different operating systems by modifying the one or more base image layers tied to the different operating systems.
It would have been obvious to one of the ordinary skill in the art before the filing date of the instant application to have recognized from the teaching of Carvalho that the manifest list identifying a first version of the container image for the architecture A and the second version of the container image for the architecture B to have recognized that Suarez’s different versions of the container images 346A-346B are created to run on different platforms wherein Suarez teaches that the container images v1 and v2 may be associated with different operating systems by modifying the one or more base images of the container image with the different operating systems including Red Hat Linux, Microsoft Windows, Apple OS X, etc. and the one or more base image layers can be modified as shown at FIG. 3 of Suarez to be associated with different operating systems. One of the ordinary skill in the art would have provided an augmented image manifest for the different versions of the container image designed for the different operating systems by modifying the one or more base image layers tied to the different operating systems.
Re Claim 2:
The claim 2 encompasses the same scope of invention as that of the claim 1 except additional claim limitation of receiving, from the client in response to the augmented image digest, a request for the second version of the image; in response to the request for the second version of the image, providing a request for the first version of the image to the image registry; and receiving, from the image registry, a first image manifest for the first version of the image.
The Sparks and Suarez/Carvalho combination further teaches the claim limitation of receiving, from the client in response to the augmented image digest, a request for the second version of the image; in response to the request for the second version of the image, providing a request for the first version of the image to the image registry; and receiving, from the image registry, a first image manifest for the first version of the image (
Carvalho teaches at Paragraph 0018 that every node in the cluster of nodes 112 has computer architecture A and Paragraph 0019 that every node in the cluster of nodes 118 has computer architecture B. Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 (having architecture A) and another image manifest from the cluster of nodes 118 (having architecture B) to generate a manifest list. The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0033 that the registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries. Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest.
Applicant’s specification discloses at Paragraph 0019 that the image digest may be any file, message, document, binary object, and/or the like that identifies and/or describes resources for retrieving a container image from a registry. For instance, the image digest may be a data object, such as, for example, a markup language object, contained in the body of a message and/or as a data file, such as, for example, an HTTP message. In various implementations, an image digest may include information about a specific version of an image and/or may include information about multiple versions of an image. For example, the image digest may be an image manifest that describes content for a specific image version, such as configurations, data object identifiers and/or locations, embedded content, and/or the like. For instance, the image digest may be formatted as an image manifest as defined by a container-related standard promulgated by the Open Containers Initiative (OCI). As another example, the image digest may be an image index that includes a list identifying one or more versions of an image. For example, the image digest may include a list of image manifests for specific image versions. For instance, the image digest may be formatted as an image index as defined by an OCI standard. In further examples, the image digest may include information identifying resources for one or more specific image versions and information identifying a list of image manifests for other versions of the image.
Sparks teaches at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration. The OCI image manifest specification describes labels and annotations as schema elements in the OCI image specification. Labels typically are set in the OCI image configuration, while annotations can be supported in multiple files, though annotations typically are provided in the image index or manifest and at Paragraph 0063 that container management engine 128 may access the container metadata 120 associated with the containerized application by obtaining the container metadata 120 from an image manifest of the container image 118.
Sparks teaches at Paragraph 0037 that container metadata 120 may be specified using annotations, labels, or both. Annotations and labels are standard schema elements defined by the OCI standard. Entries in container metadata 120 may be stored as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. For example, annotations and labels may be formatted as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. Thus, in certain embodiments, container metadata 120 may be stored as OCI-compliant labels, OCI-compliant annotations, or both OCI-compliant labels and OCI-compliant annotations.
Sparks teaches at Paragraph 0051 that container engine operations may include accepting user requests, including command line options, pulling container images (e.g., container images 118), and running the container. Sparks teaches at Paragraph 0054 that interface 126 of compute node 1 may transmit metadata requests 130 and/or container image requests 134 to container-provider system 102 and/or receive responses 132 that include container metadata 120 and/or responses 136 that include container images 118 from container-provider system 102.
Sparks teaches at Paragraph [0109] A container registry (e.g., storage device 112 of FIG. 1) may store a container image (e.g., container image 118a) for a containerized application.
Sparks teaches at Paragraph [0040] Container metadata 120 for a container image 118 may be specified in an image manifest portion of the container image 118.
Sparks teaches at Paragraph 0041 that interface 114 of container-provider system 102 may receive requests for container metadata 120 and/or container images 118 from computing environment 106 and/or transmit container metadata 120 and/or container images 118 to those requests.
Sparks teaches at Paragraph 0071 that container image 118 includes an image manifest 200, an image index 202, one or more filesystem layers 204, and an image configuration 206 and at Paragraph 0072 that image manifest 200 includes filesystem layer information 208, image configuration information 210, and container metadata 120. Filesystem layer information 208 may include references to filesystem layers 204.
Sparks teaches at Paragraph [0078] Filesystem layers 204 may include one or more filesystem layers, shown as Layer 1, Layer 2, Layer 3, through Layer Y as an example. The first filesystem layer (e.g., Layer 1) may be considered a base layer that represents an initial state of the file system. Each additional layer may represent changes to the container image 118, such as to the filesystem, over time. The underlying filesystem may include the source code for the containerized application and other suitable information for creating a container from the container image 118 to implement the containerized application at runtime (e.g., in computing environment 106 of FIG. 1).
The claimed first version of the image is mapped to the second version 118b of the container image and the claimed second version of the image is mapped to the first version 118a of the container image.
Sparks teaches receiving, from the client in response to the augmented image digest (different versions of the container image 118), a request for the second version of the image (request for the first version 118a); in response to the request for the second version of the image, providing a request for the first version of the image to the image registry (a second version 118b of the container image); and receiving, from the image registry, a first image manifest for the first version of the image (receiving the second container metadata 120b describing the first image manifest describing the version of the image).
Sparks teaches at Paragraph [0089] In certain embodiments, the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph [0096] Returning to step 504, if container management engine 128 determines at step 504 not to deploy the first containerized application in the computing environment (e.g., computing environment 106), then at step 510, in response to determining not to deploy the first containerized application in the computing environment, container management engine 128 may determine not to download the first container image (e.g., container image 118a). At step 512, container management engine 128 may return an indication that the download of first container image (e.g., container image 118a) is rejected.
Sparks teaches at Paragraph [0097] Computing environment 106 (e.g., container management engine 128) may repeat method 500 one or more times, if desired, to obtain a different, or potentially even the same, containerized application. For example, container management engine 128 may access second container metadata (e.g., container metadata 120b of FIG. 1) associated with a second containerized application. The second container metadata may be stored in a second container registry (e.g., storage device 112 of FIG. 1 or another suitable storage device) as part of a second container image (e.g., container image 118b of FIG. 1) for the second containerized application. The second containerized application may be a containerized application that can be generated from the second container image (e.g., container image 118b). Container management engine 128 may determine, prior to downloading the second container image (e.g., container image 118b), according to the second container metadata (e.g., container metadata 120b), and according to the computing environment characteristics (e.g., computing environment characteristics 140), whether to deploy the second containerized application in the computing environment. If container management engine 128 determines to deploy the second containerized application in the computing environment, then container management engine 128 may download the second container image, e.g., container image 118b).
Re Claim 3:
The claim 3 encompasses the same scope of invention as that of the claim 2 except additional claim limitation of generating a second image manifest for the second version of the image based, at least in part, on the first image manifest and an architectural feature of the second architecture; and providing the second image manifest to the client.
The Sparks and Suarez/Carvalho combination further teaches the claim limitation of generating a second image manifest for the second version of the image based, at least in part, on the first image manifest and an architectural feature of the second architecture; and providing the second image manifest to the client (
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0033 that the registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries. Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest.
Sparks teaches at FIG. 2 that container metadata 120 includes basic metadata 212 and expanded metadata 214 and at FIG. 4 and Paragraph 0086 that image manifest 400 includes container metadata 402 and platform information.
Sparks teaches at Paragraph 0077 that, these different implementations of container image 118 could correspond to different platforms (e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform) or other attributes (e.g., operating systems). This may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Accordingly, the second image manifest for the second version of the container image for platform 2 is generated based on the first image manifest for the first version of the container image for platform 1 as the first image manifest and the second image manifest share the common container metadata 402.
Sparks teaches at Paragraph 0051 that container engine operations may include accepting user requests, including command line options, pulling container images (e.g., container images 118), and running the container. Sparks teaches at Paragraph 0054 that interface 126 of compute node 1 may transmit metadata requests 130 and/or container image requests 134 to container-provider system 102 and/or receive responses 132 that include container metadata 120 and/or responses 136 that include container images 118 from container-provider system 102.
Sparks teaches at Paragraph [0109] A container registry (e.g., storage device 112 of FIG. 1) may store a container image (e.g., container image 118a) for a containerized application.
Sparks teaches at Paragraph [0096] Returning to step 504, if container management engine 128 determines at step 504 not to deploy the first containerized application in the computing environment (e.g., computing environment 106), then at step 510, in response to determining not to deploy the first containerized application in the computing environment, container management engine 128 may determine not to download the first container image (e.g., container image 118a). At step 512, container management engine 128 may return an indication that the download of first container image (e.g., container image 118a) is rejected.
Sparks teaches at Paragraph [0097] Computing environment 106 (e.g., container management engine 128) may repeat method 500 one or more times, if desired, to obtain a different, or potentially even the same, containerized application. For example, container management engine 128 may access second container metadata (e.g., container metadata 120b of FIG. 1) associated with a second containerized application. The second container metadata may be stored in a second container registry (e.g., storage device 112 of FIG. 1 or another suitable storage device) as part of a second container image (e.g., container image 118b of FIG. 1) for the second containerized application. The second containerized application may be a containerized application that can be generated from the second container image (e.g., container image 118b). Container management engine 128 may determine, prior to downloading the second container image (e.g., container image 118b), according to the second container metadata (e.g., container metadata 120b), and according to the computing environment characteristics (e.g., computing environment characteristics 140), whether to deploy the second containerized application in the computing environment. If container management engine 128 determines to deploy the second containerized application in the computing environment, then container management engine 128 may download the second container image, e.g., container image 118b.
Carvalho teaches at Paragraph 0018 that every node in the cluster of nodes 112 has computer architecture A and Paragraph 0019 that every node in the cluster of nodes 118 has computer architecture B. Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 (having architecture A) and another image manifest from the cluster of nodes 118 (having architecture B) to generate a manifest list. The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download.
).
Re Claim 4:
The claim 4 encompasses the same scope of invention as that of the claim 3 except additional claim limitation that the first image manifest identifies a sequence of file system layer descriptors; and generating the second image manifest comprises appending an additional file system layer descriptor to the sequence or modifying an entry of the sequence to support the architectural feature.
The Sparks and Suarez/Carvalho combination further teaches the claim limitation that the first image manifest identifies a sequence of file system layer descriptors; and generating the second image manifest comprises appending an additional file system layer descriptor to the sequence or modifying an entry of the sequence to support the architectural feature (
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0048 that the second version 346B (image v2) is stored with the updated layers and a manifest 350B indicating the locations of the layers of the version of the container image 352 at the second time.
Suarez teaches at Paragraph 0033 that the registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries. Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest.
Sparks teaches at Paragraph [0078] Filesystem layers 204 may include one or more filesystem layers, shown as Layer 1, Layer 2, Layer 3, through Layer Y as an example. The first filesystem layer (e.g., Layer 1) may be considered a base layer that represents an initial state of the file system. Each additional layer may represent changes to the container image 118, such as to the filesystem, over time. The underlying filesystem may include the source code for the containerized application and other suitable information for creating a container from the container image 118 to implement the containerized application at runtime (e.g., in computing environment 106 of FIG. 1).
Sparks teaches at Paragraph 0016 that a computer system downloads an OCI container image and then unpacks that container image into a container runtime filesystem bundle and a container image may be changed, and those changes may be saved in layers forming another image. Thus, an image may be a set of layers and at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration.
Sparks teaches at Paragraph [0034] Storage device 112 stores container images 118, shown to include container images 118a, 118b, through 118n. In general, a container image 118 may be one or more files that can be used by an appropriate engine to generate an instance of a container for running a containerized application. For example, among other contents, a container image 118 may include executable code that can be used by an appropriate engine to generate an instance of a container for running a containerized application.
Sparks teaches at Paragraph 0111 that logic 116 may obtain the container metadata (e.g., container metadata 120a) from an image manifest (e.g., image manifest 400 of FIG. 4) of the container image (e.g., container image 118a). In certain embodiments, the container metadata (e.g., container metadata 120a) includes information regarding the containerized application, information regarding a runtime environment for running the containerized application, and information regarding an interface between the containerized application and a computing node for running the containerized application. In certain embodiments, entries of the container metadata (e.g., container metadata 120a) may be implemented as a key-value field format, such as described above with reference to metadata format 300 and example metadata entry 306 of FIGS. 3A-3B.
Applicant’s specification discloses at Paragraph 0019 that the image digest may be any file, message, document, binary object, and/or the like that identifies and/or describes resources for retrieving a container image from a registry. For instance, the image digest may be a data object, such as, for example, a markup language object, contained in the body of a message and/or as a data file, such as, for example, an HTTP message. In various implementations, an image digest may include information about a specific version of an image and/or may include information about multiple versions of an image. For example, the image digest may be an image manifest that describes content for a specific image version, such as configurations, data object identifiers and/or locations, embedded content, and/or the like. For instance, the image digest may be formatted as an image manifest as defined by a container-related standard promulgated by the Open Containers Initiative (OCI). As another example, the image digest may be an image index that includes a list identifying one or more versions of an image. For example, the image digest may include a list of image manifests for specific image versions. For instance, the image digest may be formatted as an image index as defined by an OCI standard. In further examples, the image digest may include information identifying resources for one or more specific image versions and information identifying a list of image manifests for other versions of the image.
Sparks teaches at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration. The OCI image manifest specification describes labels and annotations as schema elements in the OCI image specification. Labels typically are set in the OCI image configuration, while annotations can be supported in multiple files, though annotations typically are provided in the image index or manifest and at Paragraph 0063 that container management engine 128 may access the container metadata 120 associated with the containerized application by obtaining the container metadata 120 from an image manifest of the container image 118.
Sparks teaches at Paragraph 0037 that container metadata 120 may be specified using annotations, labels, or both. Annotations and labels are standard schema elements defined by the OCI standard. Entries in container metadata 120 may be stored as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. For example, annotations and labels may be formatted as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. Thus, in certain embodiments, container metadata 120 may be stored as OCI-compliant labels, OCI-compliant annotations, or both OCI-compliant labels and OCI-compliant annotations.
Sparks teaches at Paragraph 0051 that container engine operations may include accepting user requests, including command line options, pulling container images (e.g., container images 118), and running the container. Sparks teaches at Paragraph 0054 that interface 126 of compute node 1 may transmit metadata requests 130 and/or container image requests 134 to container-provider system 102 and/or receive responses 132 that include container metadata 120 and/or responses 136 that include container images 118 from container-provider system 102.
Sparks teaches at Paragraph [0109] A container registry (e.g., storage device 112 of FIG. 1) may store a container image (e.g., container image 118a) for a containerized application.
Sparks teaches at Paragraph [0040] Container metadata 120 for a container image 118 may be specified in an image manifest portion of the container image 118.
Sparks teaches at Paragraph 0041 that interface 114 of container-provider system 102 may receive requests for container metadata 120 and/or container images 118 from computing environment 106 and/or transmit container metadata 120 and/or container images 118 to those requests.
Sparks teaches at Paragraph 0071 that container image 118 includes an image manifest 200, an image index 202, one or more filesystem layers 204, and an image configuration 206 and at Paragraph 0072 that image manifest 200 includes filesystem layer information 208, image configuration information 210, and container metadata 120. Filesystem layer information 208 may include references to filesystem layers 204.
Sparks teaches at Paragraph [0078] Filesystem layers 204 may include one or more filesystem layers, shown as Layer 1, Layer 2, Layer 3, through Layer Y as an example. The first filesystem layer (e.g., Layer 1) may be considered a base layer that represents an initial state of the file system. Each additional layer may represent changes to the container image 118, such as to the filesystem, over time. The underlying filesystem may include the source code for the containerized application and other suitable information for creating a container from the container image 118 to implement the containerized application at runtime (e.g., in computing environment 106 of FIG. 1).
The claimed first version of the image is mapped to the second version 118b of the container image and the claimed second version of the image is mapped to the first version 118a of the container image.
Sparks teaches receiving, from the client in response to the augmented image digest (different versions of the container image 118), a request for the second version of the image (request for the first version 118a); in response to the request for the second version of the image, providing a request for the first version of the image to the image registry (a second version 118b of the container image); and receiving, from the image registry, a first image manifest for the first version of the image (receiving the second container metadata 120b describing the first image manifest describing the version of the image).
Sparks teaches at Paragraph [0089] In certain embodiments, the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph [0096] Returning to step 504, if container management engine 128 determines at step 504 not to deploy the first containerized application in the computing environment (e.g., computing environment 106), then at step 510, in response to determining not to deploy the first containerized application in the computing environment, container management engine 128 may determine not to download the first container image (e.g., container image 118a). At step 512, container management engine 128 may return an indication that the download of first container image (e.g., container image 118a) is rejected.
Sparks teaches at Paragraph [0097] Computing environment 106 (e.g., container management engine 128) may repeat method 500 one or more times, if desired, to obtain a different, or potentially even the same, containerized application. For example, container management engine 128 may access second container metadata (e.g., container metadata 120b of FIG. 1) associated with a second containerized application. The second container metadata may be stored in a second container registry (e.g., storage device 112 of FIG. 1 or another suitable storage device) as part of a second container image (e.g., container image 118b of FIG. 1) for the second containerized application. The second containerized application may be a containerized application that can be generated from the second container image (e.g., container image 118b). Container management engine 128 may determine, prior to downloading the second container image (e.g., container image 118b), according to the second container metadata (e.g., container metadata 120b), and according to the computing environment characteristics (e.g., computing environment characteristics 140), whether to deploy the second containerized application in the computing environment. If container management engine 128 determines to deploy the second containerized application in the computing environment, then container management engine 128 may download the second container image, e.g., container image 118b.
Carvalho teaches at Paragraph 0018 that every node in the cluster of nodes 112 has computer architecture A and Paragraph 0019 that every node in the cluster of nodes 118 has computer architecture B. Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 (having architecture A) and another image manifest from the cluster of nodes 118 (having architecture B) to generate a manifest list. The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download).
Re Claim 5:
The claim 5 encompasses the same scope of invention as that of the claim 2 except additional claim limitation that, responsive to the request for the second version of the image;
providing the first image manifest to the client; and providing a request for a second image manifest for the second version of the image to an address associated with the image registry.
The Sparks and Suarez/Carvalho combination teaches the claim limitation that responsive to the request for the second version of the image; providing the first image manifest to the client; and providing a request for a second image manifest for the second version of the image to an address associated with the image registry (
Carvalho teaches at Paragraph 0018 that every node in the cluster of nodes 112 has computer architecture A and Paragraph 0019 that every node in the cluster of nodes 118 has computer architecture B. Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 (having architecture A) and another image manifest from the cluster of nodes 118 (having architecture B) to generate a manifest list. The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0048 that the second version 346B (image v2) is stored with the updated layers and a manifest 350B indicating the locations of the layers of the version of the container image 352 at the second time.
Suarez teaches at Paragraph 0033 that the registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries. Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest.
Sparks teaches responsive to the request for the first version 118a of the container image, providing the second container metadata 120b to the client and providing a request for the first container metadata 120a to an address associated with the image registry as shown at Paragraph 0089 and Paragraph 0097 of the specification.
Sparks teaches at Paragraph 0089 that the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph 0101 that container management engine 128 may access first container metadata (e.g., container metadata 120a) associated with the first containerized application. The first container metadata (e.g., container metadata 120a) may be stored as part of the first container image (e.g., container image 118a) for the first containerized application. In certain embodiments, container management engine 128 may access the first container metadata (e.g., container metadata 120a) associated with the first containerized application by obtaining the first container metadata (e.g., container metadata 120a) from an image manifest (e.g., image manifest 400 of FIG. 4) of the first container image (e.g., container image 118a).
Sparks teaches at Paragraph 0016 that a computer system downloads an OCI container image and then unpacks that container image into a container runtime filesystem bundle and a container image may be changed, and those changes may be saved in layers forming another image. Thus, an image may be a set of layers and at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration.
Sparks teaches at Paragraph [0034] Storage device 112 stores container images 118, shown to include container images 118a, 118b, through 118n. In general, a container image 118 may be one or more files that can be used by an appropriate engine to generate an instance of a container for running a containerized application. For example, among other contents, a container image 118 may include executable code that can be used by an appropriate engine to generate an instance of a container for running a containerized application.
Sparks teaches at Paragraph 0111 that logic 116 may obtain the container metadata (e.g., container metadata 120a) from an image manifest (e.g., image manifest 400 of FIG. 4) of the container image (e.g., container image 118a). In certain embodiments, the container metadata (e.g., container metadata 120a) includes information regarding the containerized application, information regarding a runtime environment for running the containerized application, and information regarding an interface between the containerized application and a computing node for running the containerized application. In certain embodiments, entries of the container metadata (e.g., container metadata 120a) may be implemented as a key-value field format, such as described above with reference to metadata format 300 and example metadata entry 306 of FIGS. 3A-3B.
Applicant’s specification discloses at Paragraph 0019 that the image digest may be any file, message, document, binary object, and/or the like that identifies and/or describes resources for retrieving a container image from a registry. For instance, the image digest may be a data object, such as, for example, a markup language object, contained in the body of a message and/or as a data file, such as, for example, an HTTP message. In various implementations, an image digest may include information about a specific version of an image and/or may include information about multiple versions of an image. For example, the image digest may be an image manifest that describes content for a specific image version, such as configurations, data object identifiers and/or locations, embedded content, and/or the like. For instance, the image digest may be formatted as an image manifest as defined by a container-related standard promulgated by the Open Containers Initiative (OCI). As another example, the image digest may be an image index that includes a list identifying one or more versions of an image. For example, the image digest may include a list of image manifests for specific image versions. For instance, the image digest may be formatted as an image index as defined by an OCI standard. In further examples, the image digest may include information identifying resources for one or more specific image versions and information identifying a list of image manifests for other versions of the image.
Sparks teaches at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration. The OCI image manifest specification describes labels and annotations as schema elements in the OCI image specification. Labels typically are set in the OCI image configuration, while annotations can be supported in multiple files, though annotations typically are provided in the image index or manifest and at Paragraph 0063 that container management engine 128 may access the container metadata 120 associated with the containerized application by obtaining the container metadata 120 from an image manifest of the container image 118.
Sparks teaches at Paragraph 0037 that container metadata 120 may be specified using annotations, labels, or both. Annotations and labels are standard schema elements defined by the OCI standard. Entries in container metadata 120 may be stored as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. For example, annotations and labels may be formatted as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. Thus, in certain embodiments, container metadata 120 may be stored as OCI-compliant labels, OCI-compliant annotations, or both OCI-compliant labels and OCI-compliant annotations.
Sparks teaches at Paragraph 0051 that container engine operations may include accepting user requests, including command line options, pulling container images (e.g., container images 118), and running the container. Sparks teaches at Paragraph 0054 that interface 126 of compute node 1 may transmit metadata requests 130 and/or container image requests 134 to container-provider system 102 and/or receive responses 132 that include container metadata 120 and/or responses 136 that include container images 118 from container-provider system 102.
Sparks teaches at Paragraph [0109] A container registry (e.g., storage device 112 of FIG. 1) may store a container image (e.g., container image 118a) for a containerized application.
Sparks teaches at Paragraph [0040] Container metadata 120 for a container image 118 may be specified in an image manifest portion of the container image 118.
Sparks teaches at Paragraph 0041 that interface 114 of container-provider system 102 may receive requests for container metadata 120 and/or container images 118 from computing environment 106 and/or transmit container metadata 120 and/or container images 118 to those requests.
Sparks teaches at Paragraph 0071 that container image 118 includes an image manifest 200, an image index 202, one or more filesystem layers 204, and an image configuration 206 and at Paragraph 0072 that image manifest 200 includes filesystem layer information 208, image configuration information 210, and container metadata 120. Filesystem layer information 208 may include references to filesystem layers 204.
Sparks teaches at Paragraph [0078] Filesystem layers 204 may include one or more filesystem layers, shown as Layer 1, Layer 2, Layer 3, through Layer Y as an example. The first filesystem layer (e.g., Layer 1) may be considered a base layer that represents an initial state of the file system. Each additional layer may represent changes to the container image 118, such as to the filesystem, over time. The underlying filesystem may include the source code for the containerized application and other suitable information for creating a container from the container image 118 to implement the containerized application at runtime (e.g., in computing environment 106 of FIG. 1).
The claimed first version of the image is mapped to the second version 118b of the container image and the claimed second version of the image is mapped to the first version 118a of the container image.
Sparks teaches receiving, from the client in response to the augmented image digest (different versions of the container image 118), a request for the second version of the image (request for the first version 118a); in response to the request for the second version of the image, providing a request for the first version of the image to the image registry (a second version 118b of the container image); and receiving, from the image registry, a first image manifest for the first version of the image (receiving the second container metadata 120b describing the first image manifest describing the version of the image).
Sparks teaches at Paragraph [0089] In certain embodiments, the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph 0089 that the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph [0096] Returning to step 504, if container management engine 128 determines at step 504 not to deploy the first containerized application in the computing environment (e.g., computing environment 106), then at step 510, in response to determining not to deploy the first containerized application in the computing environment, container management engine 128 may determine not to download the first container image (e.g., container image 118a). At step 512, container management engine 128 may return an indication that the download of first container image (e.g., container image 118a) is rejected.
Sparks teaches at Paragraph [0097] Computing environment 106 (e.g., container management engine 128) may repeat method 500 one or more times, if desired, to obtain a different, or potentially even the same, containerized application. For example, container management engine 128 may access second container metadata (e.g., container metadata 120b of FIG. 1) associated with a second containerized application. The second container metadata may be stored in a second container registry (e.g., storage device 112 of FIG. 1 or another suitable storage device) as part of a second container image (e.g., container image 118b of FIG. 1) for the second containerized application. The second containerized application may be a containerized application that can be generated from the second container image (e.g., container image 118b). Container management engine 128 may determine, prior to downloading the second container image (e.g., container image 118b), according to the second container metadata (e.g., container metadata 120b), and according to the computing environment characteristics (e.g., computing environment characteristics 140), whether to deploy the second containerized application in the computing environment. If container management engine 128 determines to deploy the second containerized application in the computing environment, then container management engine 128 may download the second container image, e.g., container image 118b).
Re Claim 6:
The claim 6 encompasses the same scope of invention as that of the claim 3 except additional claim limitation that, responsive to the request for the second version of the image: instantiating the first version of the image based on the first image manifest to provide an instance of the first version of the image; modifying the instance of the first version of the image based, at least in part, on the second architecture; and
generating the second version of the image and the second image manifest based, at least in part, on the modified instance of the first version of the image.
The Sparks and Suarez/Carvalho combination teaches the claim limitation that responsive to the request for the second version of the image to provide an instance of the first version of the image; instantiating the first version of the image based on the first image manifest: modifying the instance of the first version of the image based, at least in part, on the second architecture; and generating the second version of the image and the second image manifest based, at least in part, on the modified instance of the first version of the image (
Carvalho teaches at Paragraph 0018 that every node in the cluster of nodes 112 has computer architecture A and Paragraph 0019 that every node in the cluster of nodes 118 has computer architecture B. Carvalho teaches at Paragraph 0013 that the client device 102 can transmit the build request 104 and at Paragraph 0014 that the build request 104 may specify a particular computer architecture and at Paragraph 0021 that the clusters of nodes 112 and 118 can also create image manifests having metadata related to the container images and the orchestration cluster 106 can make the image manifests available to the client device 102 and combine an image manifest from the cluster of nodes 112 (having architecture A) and another image manifest from the cluster of nodes 118 (having architecture B) to generate a manifest list. The client device 102 can use the manifest list to determine which version of the container image is compatible with the client device 102 and select that version of the container image to download.
Sparks teaches at Paragraph 0077 that image index 202 may be a higher-level manifest that points to a list of manifests and descriptors and these manifests may provide different implementations of container image 118 and different implementations of container image 118 could correspond to different platforms, e.g., a first implementation of container image 118 for an ARM-based platform and a second implementation of container image 118 for an AMD-based platform and this may facilitate creation and management of multi-architecture container images for which different versions of a container image 118 are created for a same containerized application so that the containerized application can run on different platforms using the applicable container image for that platform.
Suarez teaches at Paragraph 0033 that the registry metadata service may be queried for the metadata rather than the container registry itself, in order to quickly and efficiently determine which layers/images can be cleaned up during garbage collection without burdening the container registry with metadata queries. Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest.
Sparks teaches responsive to the request for the first version 118a of the container image, instantiating the second version of the container image based on the second image manifest 120b and modifying the instance of the second version 118b of the container image based at least in part on the first architecture and generating the first version 118a of the container image and the first image manifest 120a based on the modified instance of the second version 118b of the container image.
Sparks teaches at Paragraph 0089 that the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph 0101 that container management engine 128 may access first container metadata (e.g., container metadata 120a) associated with the first containerized application. The first container metadata (e.g., container metadata 120a) may be stored as part of the first container image (e.g., container image 118a) for the first containerized application. In certain embodiments, container management engine 128 may access the first container metadata (e.g., container metadata 120a) associated with the first containerized application by obtaining the first container metadata (e.g., container metadata 120a) from an image manifest (e.g., image manifest 400 of FIG. 4) of the first container image (e.g., container image 118a).
Sparks teaches at Paragraph 0016 that a computer system downloads an OCI container image and then unpacks that container image into a container runtime filesystem bundle and a container image may be changed, and those changes may be saved in layers forming another image. Thus, an image may be a set of layers and at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration.
Sparks teaches at Paragraph [0034] Storage device 112 stores container images 118, shown to include container images 118a, 118b, through 118n. In general, a container image 118 may be one or more files that can be used by an appropriate engine to generate an instance of a container for running a containerized application. For example, among other contents, a container image 118 may include executable code that can be used by an appropriate engine to generate an instance of a container for running a containerized application.
Sparks teaches at Paragraph 0111 that logic 116 may obtain the container metadata (e.g., container metadata 120a) from an image manifest (e.g., image manifest 400 of FIG. 4) of the container image (e.g., container image 118a). In certain embodiments, the container metadata (e.g., container metadata 120a) includes information regarding the containerized application, information regarding a runtime environment for running the containerized application, and information regarding an interface between the containerized application and a computing node for running the containerized application. In certain embodiments, entries of the container metadata (e.g., container metadata 120a) may be implemented as a key-value field format, such as described above with reference to metadata format 300 and example metadata entry 306 of FIGS. 3A-3B.
Applicant’s specification discloses at Paragraph 0019 that the image digest may be any file, message, document, binary object, and/or the like that identifies and/or describes resources for retrieving a container image from a registry. For instance, the image digest may be a data object, such as, for example, a markup language object, contained in the body of a message and/or as a data file, such as, for example, an HTTP message. In various implementations, an image digest may include information about a specific version of an image and/or may include information about multiple versions of an image. For example, the image digest may be an image manifest that describes content for a specific image version, such as configurations, data object identifiers and/or locations, embedded content, and/or the like. For instance, the image digest may be formatted as an image manifest as defined by a container-related standard promulgated by the Open Containers Initiative (OCI). As another example, the image digest may be an image index that includes a list identifying one or more versions of an image. For example, the image digest may include a list of image manifests for specific image versions. For instance, the image digest may be formatted as an image index as defined by an OCI standard. In further examples, the image digest may include information identifying resources for one or more specific image versions and information identifying a list of image manifests for other versions of the image.
Sparks teaches at Paragraph [0020] that an OCI-compliant image includes a manifest, a set of filesystem layers, and a configuration. The OCI image manifest specification describes labels and annotations as schema elements in the OCI image specification. Labels typically are set in the OCI image configuration, while annotations can be supported in multiple files, though annotations typically are provided in the image index or manifest and at Paragraph 0063 that container management engine 128 may access the container metadata 120 associated with the containerized application by obtaining the container metadata 120 from an image manifest of the container image 118.
Sparks teaches at Paragraph 0037 that container metadata 120 may be specified using annotations, labels, or both. Annotations and labels are standard schema elements defined by the OCI standard. Entries in container metadata 120 may be stored as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. For example, annotations and labels may be formatted as key-value pairs that define a particular field/parameter for a container that may be generated from the container image 118 or other suitable information. Thus, in certain embodiments, container metadata 120 may be stored as OCI-compliant labels, OCI-compliant annotations, or both OCI-compliant labels and OCI-compliant annotations.
Sparks teaches at Paragraph 0051 that container engine operations may include accepting user requests, including command line options, pulling container images (e.g., container images 118), and running the container. Sparks teaches at Paragraph 0054 that interface 126 of compute node 1 may transmit metadata requests 130 and/or container image requests 134 to container-provider system 102 and/or receive responses 132 that include container metadata 120 and/or responses 136 that include container images 118 from container-provider system 102.
Sparks teaches at Paragraph [0109] A container registry (e.g., storage device 112 of FIG. 1) may store a container image (e.g., container image 118a) for a containerized application.
Sparks teaches at Paragraph [0040] Container metadata 120 for a container image 118 may be specified in an image manifest portion of the container image 118.
Sparks teaches at Paragraph 0041 that interface 114 of container-provider system 102 may receive requests for container metadata 120 and/or container images 118 from computing environment 106 and/or transmit container metadata 120 and/or container images 118 to those requests.
Sparks teaches at Paragraph 0071 that container image 118 includes an image manifest 200, an image index 202, one or more filesystem layers 204, and an image configuration 206 and at Paragraph 0072 that image manifest 200 includes filesystem layer information 208, image configuration information 210, and container metadata 120. Filesystem layer information 208 may include references to filesystem layers 204.
Sparks teaches at Paragraph [0078] Filesystem layers 204 may include one or more filesystem layers, shown as Layer 1, Layer 2, Layer 3, through Layer Y as an example. The first filesystem layer (e.g., Layer 1) may be considered a base layer that represents an initial state of the file system. Each additional layer may represent changes to the container image 118, such as to the filesystem, over time. The underlying filesystem may include the source code for the containerized application and other suitable information for creating a container from the container image 118 to implement the containerized application at runtime (e.g., in computing environment 106 of FIG. 1).
The claimed first version of the image is mapped to the second version 118b of the container image and the claimed second version of the image is mapped to the first version 118a of the container image.
Sparks teaches receiving, from the client in response to the augmented image digest (different versions of the container image 118), a request for the second version of the image (request for the first version 118a); in response to the request for the second version of the image, providing a request for the first version of the image to the image registry (a second version 118b of the container image); and receiving, from the image registry, a first image manifest for the first version of the image (receiving the second container metadata 120b describing the first image manifest describing the version of the image).
Sparks teaches at Paragraph [0089] In certain embodiments, the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph 0089 that the container management engine 128 accesses the first container metadata (e.g., container metadata 118a), in part, by transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata (e.g., container metadata 118a) associated with a first containerized application and receiving the first container metadata in response to the first request (e.g., as response 132 of FIG. 1). The first container metadata (e.g., container metadata 118a) may be stored in a first container registry (e.g., storage device 112 as part of a container image (e.g., container image 118a) for the first containerized application. Container management engine 128 may generate the request (e.g., metadata request 130) using a command line interface, such as via SKOPEO, or another suitable container image registry. In certain embodiments, the first container metadata (e.g., container metadata 118a) may be stored as an OCI-compliant labels, an OCI-compliant annotation, or possibly both.
Sparks teaches at Paragraph [0096] Returning to step 504, if container management engine 128 determines at step 504 not to deploy the first containerized application in the computing environment (e.g., computing environment 106), then at step 510, in response to determining not to deploy the first containerized application in the computing environment, container management engine 128 may determine not to download the first container image (e.g., container image 118a). At step 512, container management engine 128 may return an indication that the download of first container image (e.g., container image 118a) is rejected.
Sparks teaches at Paragraph [0097] Computing environment 106 (e.g., container management engine 128) may repeat method 500 one or more times, if desired, to obtain a different, or potentially even the same, containerized application. For example, container management engine 128 may access second container metadata (e.g., container metadata 120b of FIG. 1) associated with a second containerized application. The second container metadata may be stored in a second container registry (e.g., storage device 112 of FIG. 1 or another suitable storage device) as part of a second container image (e.g., container image 118b of FIG. 1) for the second containerized application. The second containerized application may be a containerized application that can be generated from the second container image (e.g., container image 118b). Container management engine 128 may determine, prior to downloading the second container image (e.g., container image 118b), according to the second container metadata (e.g., container metadata 120b), and according to the computing environment characteristics (e.g., computing environment characteristics 140), whether to deploy the second containerized application in the computing environment. If container management engine 128 determines to deploy the second containerized application in the computing environment, then container management engine 128 may download the second container image, e.g., container image 118b).
Re Claim 7:
The claim 7 encompasses the same scope of invention as that of the claim 6 except additional claim limitation that receiving telemetry data regarding the second version of the image from the client in response to instantiation of the second version of the image.
Osadchyy further teaches the claim limitation that receiving telemetry data regarding the second version of the image from the client in response to instantiation of the second version of the image (
Osadchyy teaches at Paragraph 0075 that the container scheduler queries computational resource ratios from the multi-architecture registry proxy when deploying a container. The container scheduler then utilizes the computational resource ratios queried from the multi-architecture registry proxy to determine a best fit target host computer node based on needed and available computational resources. In an alternative illustrative embodiment, the container scheduler stores the computational resource ratios in a database. In other words, the multi-architecture registry proxy does not store the computational resource ratios. The container scheduler utilizes the database to look up the computational resource ratios when determining which host computer node to schedule the container on. In another alternative illustrative embodiment, the container runtime queries the computational resource ratios from the multi-architecture registry proxy to update available resources on its host computer node after pulling the container image and running an instance of the container.).
Re Claim 9:
The claim 9 recites a device, comprising:
One or more processors to:
receive, from an image registry in response to a client request from a client, an image digest identifying a first version of an image for a first architecture;
generate an augmented image digest, the augmented image digest identifying the first version of the image and a second version of the image for a second architecture, wherein the second version of the image is generated subsequent to generation of the augmented image digest, and the augmented image digest comprises a placeholder descriptor corresponding to the second architecture; and
provide the augmented image digest to the client in a response to the client request.
The claim 9 is in parallel with the claim 1 in the form of an apparatus claim. The claim 9 is subject to the same rationale of rejection as the claim 1.
Moreover, Sparks further teaches a device, comprising:
One or more processors [perform the method steps of the claim 1] (Sparks teaches at Paragraph 0129-134 that the computing device 1100 include one or more computer processors 1102 to perform various operations described herein).
Re Claim 10:
The claim 10 encompasses the same scope of invention as that of the claim 9 except additional claim limitation that the one or more processors are further to: receive, from the client in response to the augmented image digest, a request for the second version of the image; in response to the request for the second version of the image, provide a request for the first version of the image to the image registry; and receive, from the image registry, a first image manifest for the first version of the image.
The claim 10 is in parallel with the claim 2 in the form of an apparatus claim. The claim 10 is subject to the same rationale of rejection as the claim 2.
Re Claim 11:
The claim 11 encompasses the same scope of invention as that of the claim 10 except additional claim limitation that the one or more processors are further to: generate a second image manifest for the second version of the image based, at least in part, on the first image manifest and an architectural feature of the second architecture; and provide the second image manifest to the client.
The claim 11 is in parallel with the claim 3 in the form of an apparatus claim. The claim 11 is subject to the same rationale of rejection as the claim 3.
Re Claim 12:
The claim 12 encompasses the same scope of invention as that of the claim 11 except additional claim limitation that the first image manifest identifies a sequence of file system layer descriptors; and the one or more processors are further to append an additional file system layer descriptor to the sequence or modify an entry of the sequence to support the architectural feature to generate the second image manifest.
The claim 12 is in parallel with the claim 4 in the form of an apparatus claim. The claim 12 is subject to the same rationale of rejection as the claim 4.
Re Claim 13:
The claim 13 encompasses the same scope of invention as that of the claim 10 except additional claim limitation that the one or more processors are further to, responsive to the request for the second version of the image: provide the first image manifest to the client; and
provide a request for a second image manifest for the second version of the image to an address associated with the image registry.
The claim 13 is in parallel with the claim 5 in the form of an apparatus claim. The claim 13 is subject to the same rationale of rejection as the claim 5.
Re Claim 14:
The claim 14 encompasses the same scope of invention as that of the claim 11 except additional claim limitation that the one or more processors are further to, responsive to the request for the second version of the image to provide an instance of the first version of the image; instantiate the first version of the image based on the first image manifest; modify the instance of the first version of the image based, at least in part, on the second architecture; and generate the second version of the image and the second image manifest based, at least in part, on the modified instance of the first version of the image.
The claim 14 is in parallel with the claim 6 in the form of an apparatus claim. The claim 14 is subject to the same rationale of rejection as the claim 6.
Re Claim 15:
The claim 15 encompasses the same scope of invention as that of the claim 14 except additional claim limitation that the one or more processors are further to receive telemetry data regarding the second version of the image from the client in response to instantiation of the second version of the image.
The claim 15 is in parallel with the claim 7 in the form of an apparatus claim. The claim 15 is subject to the same rationale of rejection as the claim 7.
Re Claim 16:
The claim 16 recites an article comprising:
a non-transitory storage medium comprising computer-readable instructions stored thereon and executable by a computing device to:
receive, from an image registry in response to a client request from a client, an image digest identifying a first version of an image for a first architecture;
generate an augmented image digest, the augmented image digest identifying the first version of the image and a second version of the image for a second architecture, wherein the second version of the image is generated subsequent to generation of the augmented image digest, and the augmented image digest comprises a placeholder descriptor corresponding to the second architecture; and
provide the augmented image digest to the client in a response to the client request.
The claim 16 is in parallel with the claim 1 in the form of an article of manufacture. The claim 16 is subject to the same rationale of rejection as the claim 1.
Moreover, Sparks further teaches an article comprising:
a non-transitory storage medium comprising computer-readable instructions stored thereon and executable by a computing device to [perform the method steps of the claim 1] (Sparks teaches at Paragraph 0129-134 that computer processor(s) 1102 may be an integrated circuit for processing instructions. For example, computer processor(s) may be one or more cores or micro-cores of a processor. Processor 1102 may be a general-purpose processor configured to execute program code included in software executing on computing device 1100. A computer-readable medium may have stored thereon code and/or machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statement and the computing device 1100 include one or more computer processors 1102 to perform various operations described herein).
Re Claim 17:
The claim 17 encompasses the same scope of invention as that of the claim 16 except additional claim limitation that the instructions are further executable by the computing device to: receive, from the client in response to the augmented image digest, a request for the second version of the image; in response to the request for the second version of the image, provide a request for the first version of the image to the image registry; and receive, from the image registry, a first image manifest for the first version of the image.
The claim 17 is in parallel with the claim 2 in the form of an article of manufacture. The claim 17 is subject to the same rationale of rejection as the claim 2.
Re Claim 18:
The claim 18 encompasses the same scope of invention as that of the claim 17 except additional claim limitation that the instructions are further executable by the computing device to: generate a second image manifest for the second version of the image based, at least in part, on the first image manifest and an architectural feature of the second architecture; and provide the second image manifest to the client.
The claim 18 is in parallel with the claim 3 in the form of an article of manufacture. The claim 18 is subject to the same rationale of rejection as the claim 3.
Re Claim 19:
The claim 19 encompasses the same scope of invention as that of the claim 18 except additional claim limitation that the first image manifest identifies a sequence of file system layer descriptors; and the instructions are further executable by the computing device to append an additional file system layer descriptor to the sequence or modify an entry of the sequence to support the architectural feature to generate the second image manifest.
The claim 19 is in parallel with the claim 4 in the form of an article of manufacture. The claim 19 is subject to the same rationale of rejection as the claim 4.
Re Claim 20:
The claim 20 encompasses the same scope of invention as that of the claim 17 except additional claim limitation that the instructions are further executable by the computing device to, responsive to the request for the second version of the image: provide the first image manifest to the client; and provide a request for a second image manifest for the second version of the image to an address associated with the image registry.
The claim 20 is in parallel with the claim 5 in the form of an article of manufacture. The claim 20 is subject to the same rationale of rejection as the claim 5.
Claims 8 is rejected under 35 U.S.C. 103 as being unpatentable over Sparks et al. US-PGPUB No. 2025/0238253 (hereinafter Sparks) in view of Shah et al. US-PGPUB No. 2024/0211231 (hereinafter Shah); Osadchyy et al. US-PGPUB No. 2024/0345902 (hereinafter Osadchyy); Suarez et al. US-PGPUB No. 2017/0177877 (hereinafter Suarez); Carvalho et al. US-PGPUB No. 2018/0365006 (hereinafter Carvalho);
Featonby et al. US-Patent No. 11,573,816 (hereinafter Featonby).
Re Claim 8:
The claim 8 encompasses the same scope of invention as that of the claim 6 except additional claim limitation of caching the second version of the image; and responsive to a subsequent request for the second version of the image, providing the cached second version of the image.
However, Featonby et al. US-Patent No. 11,573,816 (hereinafter Featonby) further teaches the claim limitation of caching the second version of the image; and responsive to a subsequent request for the second version of the image, providing the cached second version of the image (Featonby teaches at column 11, lines 1-50 that the user computing device 102 calls an API provided by the container service 140 to request to add a compute instance 148 to a cluster and the container service 140 adds the instance to the cluster….upon receiving the cluster manifest, the container agent 150 processes the content of the cluster manifest and sends a request to the container registry service 130 to prefetch the container images identified by the cluster manifest and the container registry service 130 transmits the requested container images which are stored in a cache 152 of the instance on which the container agent 150 is running. After the container images have been pre-fetched into the cache 152, the user computing device 102 calls another API to request to execute a task in the cluster, where the task includes the container images pre-fetched into the cache 152 and the container agent 150 accesses the container image whose execution is requested).
It would have been obvious to one of the ordinary skill in the art before the filing date of the instant application to have incorporated Featonby’s cache for storing the pre-fetched versions of the container images into the container image provider system of Sparks to have provided cache for storing the container images for execution at the user computing device. One of the ordinary skill in the art would have been motivated to have reduced the launch time with the task execution request.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIN CHENG WANG whose telephone number is (571)272-7665. The examiner can normally be reached Mon-Fri 8:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, King Poon can be reached at 571-270-0728. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JIN CHENG WANG/Primary Examiner, Art Unit 2617