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
Applicant’s submission filed 6/1/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 6/1/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 responsive to receipt of a second client request from the client device subsequent to generation of the augmented image digest, generating the second version of the image and providing the second version of the image to the client. The examiner cannot concur.
Sparks teaches at Paragraph 0016 that Docker is one tool for creating and managing containerized application. With Docker, container images are created with a “build” command, and an instance of the container image—a container—is generated when the image is started using a “run” command. Images may be stored in a container image registry (e.g., a Docker registry, such as registry.hub.docker.com). Multiple containers may be generated from the container image. In Sparks, the container images 118a-118b are created with build command with Docker subsequent to the generation of the augmented image digest (expanded image manifest or modified image manifest). Even if the container images are subsequently stored after generation, the container images 118a-118b are still created after the generation of the augmented image digest contained in the container image 118. Moreover, the second containerized application (an instance of the container image 118b) is generated subsequent to the generation of the augmented image digest associated with the container image 118 (see Paragraph 0034).
Applicant argued against Osadchyy that this translation occurs within the scope of a single client request. The examiner cannot concur.
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 the multi-architecture registry proxy 210 utilizes the target layers to generate target container image 226. Accordingly, the container image 226 is generated for the target processor architecture subsequent to generation of the modified manifest list.
Osadchyy teaches at Paragraph 0050 that container runtime 214 can modify pull request 220 (second pull request) 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.
Applicant argued against Shah with argument that Shah operates on preexisting image layers and does not describe generating a new architecture-specific image in response to a client request. The examiner cannot concur.
Shah teaches at Paragraph 0075 that the request may include a different tag identifier (TAG D). In response, the host platform compiles the build file 440 to identify the TAG D and forward the tag D to the container engine 426 and the container engine 425 creates the final image build which includes required image layers from the container image 430 and the optional image layers 432, 434 and 436.
In other words, Sparks implicitly teaches the claim limitation:
Responsive to receipt of a second client request from the client device subsequent to generation of the augmented image digest, generating the second version of the image; and
Providing the second version of the image to the client device (
In Sparks, an instance of a container for running a containerized application is generated responsive to receipt of a second client request. For example, an instance of the container image 118b for the second containerized application is generated responsive to the second client request. Even if the container image 118b is generated prior to the receipt of a second client request, the second containerized application is generated responsive to the receipt of a second client request and thus an instance of the container image 118b for the second containerized application is generated responsive to the second client request.
Sparks implicitly teaches a second client request. Sparks teaches at FIG. 5 and Paragraph 0097 that computing environment 106 may repeat method 500 one or more times to access second container metadata 120b associated with a second containerized application. This means the request at Block 502 of FIG. 5 and Paragraph 0088-0089 is repeated for a second client request for the second container image 118b and at Paragraph 0107 that container management engine 128 may download a second container image (e.g., container image 118b of FIG. 1) for a second containerized application. Additionally, the container images 118a-118b are built subsequent to the generation of the augmented image digest associated with the container image 118).
Shah/Osadchvy teaches the claim limitation Responsive to receipt of a second client request from the client device subsequent to generation of the augmented image digest, generating the second version of the image; and
Providing the second version of the image to the client device
Osadchyy teaches at Paragraph 0050 that the multi-architecture registry proxy 210 utilizes the target layers to generate target container image 226. Accordingly, the container image 226 is generated for the target processor architecture subsequent to generation of the modified manifest list responsive to the modified pull request (a second pull request).
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 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.
Shah teaches at Paragraph 0075 that the request may include a different tag identifier (TAG D). In response, the host platform compiles the build file 440 to identify the TAG D and forward the tag D to the container engine 426 and the container engine 425 creates the final image build which includes required image layers from the container image 430 and the optional image layers 432, 434 and 436.
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.
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);
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).
In Remarks, applicant alleged that all platform-specific versions are pre-built and stored before the image index is assembled. However, the claim limitation requires responsive to receipt of a second client request from the client device subsequent to generation of the augmented image digest. Applicant’s claim limitation is ambiguous and not clear. In other words, the second client request is provided from the client device subsequent to generation of the augmented image digest.
Sparks teaches at Paragraph 0016 that Docker is one tool for creating and managing containerized application. With Docker, container images are created with a “build” command, and an instance of the container image—a container—is generated when the image is started using a “run” command. Images may be stored in a container image registry (e.g., a Docker registry, such as registry.hub.docker.com). Multiple containers may be generated from the container image. Each container is an instance of the container image and runs a program. Starting the container image creates a running container of this container image.
Sparks teaches at Paragraph 0034 that a container image 118 may be one or more files that can be used to generate an instance of a container for running a containerized application.
Sparks teaches at Paragraph 0075 that a container is generated from container image 118 and a host on which the container instance 144 generated from container image is run. Accordingly, the container instance is generated subsequent to the generation of the augmented image digest such as the expanded metadata 214 and at Paragraph 0094 deploying a container instance of the container image of the first containerized application to a computing node.
Even if the second version of the image were recited to be generated subsequent to generation of the augmented image digest, Sparks teaches an instance of a container for running a second containerized application is generated subsequent to the generation of the augmented image digest. Sparks teaches the generation of an instance of a container for running a second containerized application by the provider subsequent to generation of the augmented image digest. For example, Sparks teaches at Paragraph 0034 a container image 118 may be one or more files that can be used an appropriate engine to generate an instance of a container for running a (second) containerized application and multiple containers may be generated from a container image 118. Sparks teaches at Paragraph 0088 that the first containerized application may be a containerized application that can be generated from the first container image 118a and thus an instance of a container is generated for running the first containerized application.
Sparks teaches at Paragraph 0097 that the second containerized application may be a containerized application that can be generated from the second container image 118b and thus an instance of a container for running the second containerized application is generated upon the second client request.
An instance of second container image corresponding container image 118b is generated (as opposed to the pre-stored container image 118b in the host device) corresponding to the second containerized application.
Sparks further teaches an instance of a container is generated at runtime. Sparks teaches at [0068] One or more of compute nodes 1-M may include a container runtime 142. Container runtime 142 may be a software component that facilitates running an instance of a container (e.g., the containerized application) on the compute node. For example, for a containerized application that has been deployed to a particular compute node of compute nodes 1-M, the container runtime 142 on the particular compute node may generate a container from container image 118 to run the containerized application. Example container runtimes may include CONTAINER RUNTIME INTERFACE (CRI), CONTAINERD, CRI-O, RUNC, GVISOR, KATA, and others.
Moreover, the container images are generated as opposed to be pre-built in the host device. Sparks teaches at Paragraph 0016 container images are created with a build command and multiple containers may be generated from the container image and at Paragraph 0035 that example frameworks for building container images 118 include DOCKER and PODMAN.
Sparks teaches the generation of second containerized application represented by the second container image 118b in the computing environment 106 (as opposed to applicant’s reference to the container image 118 in the container provider system 102) responsive to a second client request. Sparks teaches at FIG. 5 and Paragraph 0097 that computing environment 106 may repeat method 500 one or more times to access second container metadata 120b associated with a second containerized application. This means the request at Block 502 of FIG. 5 and Paragraph 0088-0089 is repeated for a second client request for the second container image 118b and at Paragraph 0107 that container management engine 128 may download a second container image (e.g., container image 118b of FIG. 1) for a second containerized application.
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 prior 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);
Re Claim 1:
Sparks teaches a method, comprising:
receiving, from an image registry in response to a first client request from a client device, an image digest identifying a first version of an image for a first architecture (
Sparks teaches at FIG. 5 Block 502 and Paragraph 0089 transmitting a first request (e.g., metadata request 130 of FIG. 1) for the first container metadata associated with a first containerized application and at Paragraph 0093 that container management engine 128 may download the first container image (e.g., container image 118a) for the first containerized application.
Sparks teaches at Paragraph 0113 that logic 116 may receive from the computing system a request (container image request 134 of FIG. 1) for the container image 118a and in response logic 116 may communicate to the computing system the container image.
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 0071 that the container image 118 includes an image manifest 200, an image index 202. Sparks teaches at Paragraph 0113 that logic 116 may receive from the computing system a request (container image request 134 of FIG. 1) for the container image 118a and in response logic 116 may communicate to the computing system the container image. Thus, by communicating the container image 118 including an image manifest 200 and an image index 202 to a client device (computing system), the image manifest 200 and image index 202 (augmented image digest) is communicated to the client device.
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 [0077] Image index 202 may be a higher-level manifest that points to a list of manifests and descriptors. These manifests may provide different implementations of container image 118. For example, 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.
Sparks teaches at Paragraph 0086 that container metadata 402 may include container metadata 120 including basic metadata 212 and expanded metadata 124.
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.
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 device in a response to the first client request (
Sparks teaches at Paragraph 0071 that the container image 118 includes an image manifest 200, an image index 202. Sparks teaches at Paragraph 0113 that logic 116 may receive from the computing system a request (container image request 134 of FIG. 1) for the container image 118a and in response logic 116 may communicate to the computing system the container image. Thus, by communicating the container image 118 including an image manifest 200 and an image index 202 to a client device (computing system), the image manifest 200 and image index 202 (augmented image digest) is communicated to the client device.
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 [0077] Image index 202 may be a higher-level manifest that points to a list of manifests and descriptors. These manifests may provide different implementations of container image 118. For example, 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.
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).
Sparks at least implicitly teaches the claim limitation:
Responsive to receipt of a second client request from the client device subsequent to generation of the augmented image digest, generating the second version of the image; and
Providing the second version of the image to the client device (
Sparks teaches that an instance of the container image of the second containerized application is generated and subsequently deployed to the computing environment.
Sparks implicitly teaches a second client request. Sparks teaches at FIG. 5 and Paragraph 0097 that computing environment 106 may repeat method 500 one or more times to access second container metadata 120b associated with a second containerized application. This means the request at Block 502 of FIG. 5 and Paragraph 0088-0089 is repeated for a second client request for the second container image 118b and at Paragraph 0107 that container management engine 128 may download a second container image (e.g., container image 118b of FIG. 1) for a second containerized application).
Shah/Osadchvy teaches the claim limitation Responsive to receipt of a second client request from the client device subsequent to generation of the augmented image digest, generating the second version of the image; and
Providing the second version of the image to the client device
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 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.
Shah teaches at Paragraph 0075 that the request may include a different tag identifier (TAG D). In response, the host platform compiles the build file 440 to identify the TAG D and forward the tag D to the container engine 426 and the container engine 425 creates the final image build which includes required image layers from the container image 430 and the optional image layers 432, 434 and 436.
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.
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);
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).
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 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 (
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 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.
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).
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 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.
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).
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 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 (
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 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 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 (
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 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 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 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);
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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights