Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Information Disclosure Statement
The information disclosure statement filed 12/19/2024 fails to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. It has been placed in the application file, but the information referred to therein has not been considered.
Specifically, a copy and translation of foreign patent document CN 106227579 A cited in the information disclosure sheet has not been provided, and thus has not been considered.
Claim Objections
Claims 3, 12 and 19 are objected to because of the following informalities:
In claim 3, lines 5-6, it is unclear whether “a minimum number of image layers” is the same as or distinct from the minimum number of image layers previously recited in claim 3, line 2. If they are the same, claim 3, lines 5-6 should be amended to recite “[[a]] the minimum number of image layers”. If they are distinct, a modifier should be added to distinguish them.
In claim 12, lines 5-6, it is unclear whether “a minimum number of image layers” is the same as or distinct from the minimum number of image layers previously recited in claim 12, line 2. If they are the same, claim 12, lines 5-6 should be amended to recite “[[a]] the minimum number of image layers”. If they are distinct, a modifier should be added to distinguish them.
In claim 19, lines 5-6, it is unclear whether “a minimum number of image layers” is the same as or distinct from the minimum number of image layers previously recited in claim 19, line 2. If they are the same, claim 19, lines 5-6 should be amended to recite “[[a]] the minimum number of image layers”. If they are distinct, a modifier should be added to distinguish them.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-3, 5, 11-12, and 18-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation "the container" in line 3. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the container image”.
Claim 3 recites the limitation "the container" in line 4. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the container image”. If this interpretation is correct, “the container” recited in claim 3, line 7, should be similarly amended.
Claim 5 recites the limitation "the layer substitution data" in lines 2-3. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the layer substitution relationship data”.
Claim 5 recites the limitation "the container" in line 2. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the container image”. If this interpretation is correct, “the container” recited in claim 5, line 4, should be similarly amended.
Claim 11 recites the limitation "the container" in line 3. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the container image”.
Claim 12 recites the limitation "the container" in line 4. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the container image”. If this interpretation is correct, “the container” recited in claim 12, line 7, should be similarly amended.
Claim 18 recites the limitation "the container" in line 3. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the container image”.
Claim 19 recites the limitation "the container" in line 4. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to “the container image”. If this interpretation is correct, “the container” recited in claim 19, line 7, should be similarly amended.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8 and 10-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claim 1 is directed to A computer-implemented method comprising: a series of steps, and is therefore directed to a process, which is one of the four statutory categories.
Step 2A, Prong One:
Claim 1 recites the limitations:
generating layer substitution relationship data for one or more image layers of a container image of a container-based computing environment, the layer substitution relationship data specifying one or more layer substitution relationships between different image layers of the container image; and
identifying an image layer subset that omits one or more superseded image layers of the container image, the identifying being based, at least in part, on the generated layer substitution relationship data for the one or more image layers of the container image;
all of which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Accordingly, claim 1 recites a judicial exception (i.e., an abstract idea).
Step 2A, Prong Two:
The additional elements recited by claim 1 include:
(i) A computer-implemented method comprising:
(ii) based on a download request that specifies a target image layer of the container image
(iii) establishing a container image layer deployment based on the identified image layer subset to facilitate container processing within the container-based computing environment.
Regarding the additional element (i), the limitation recited amounts to mere instructions to implement the limitations which can be performed in the human mind, i.e., the judicial exception, on a computer, which is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2106.05(f).
Regarding the additional element (ii), the limitation recited amounts to insignificant extra-solution activity of necessary data gathering, as it is merely gathering the target image layer of the container image used in “identifying an image layer subset” (which is a mental process as identified above) from a download request. Insignificant extra-solution activity is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2106.05(g).
Regarding the additional element (iii), the limitation recited amounts to mere instructions to apply the exception on a computer, as it is merely reciting deploying the identified image layer subset (the result of the recited mental process) in a computing environment, i.e., making the identified image layer subset useable for execution on a computer, which is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2106.05(f). Alternatively, this limitation could be considered insignificant extra-solution activity of mere data outputting/insignificant application of the recited judicial exception, which is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2106.05(g).
Furthermore, the combination of additional elements results in mere instructions to apply the exception and insignificant extra-solution activity of mere data gathering. This combination of additional elements fails to integrate the judicial exception into a practical application. See MPEP 2106.04(d).
Step 2B:
Regarding the additional element (i), the limitation is reciting a generic computer performs the steps which can be performed in the human mind, which is mere instructions to apply the exception. The courts have found adding mere instructions to apply the exception is not enough to amount to significantly more than the recited judicial exception. See MPEP 2106.05(a) and 2016.05(f).
Regarding the additional element (ii), the limitation recited is insignificant extra-solution activity which amounts to necessary data gathering. Further, the additional element (ii) is considered receiving data over a network, which has been identified by the courts as well-understood, routine, and conventional activity. See MPEP 2106.05(d). The courts have found adding insignificant extra-solution activity and well-understood routine, and conventional activity is not enough to amount to significantly more than the recited judicial exception. See MPEP 2106.05(a) and 2106.05(g).
Regarding the additional element (iii), the limitation is reciting, with a high-level of generality, mere instructions for implementing (“establishing a container image layer deployment […] to facilitate container processing”) the result of the recited mental process (“based on the identified image layer subset”) on a computer (“within the container-based computing environment”). The courts have found adding mere instructions to apply the exception is not enough to amount to significantly more than the recited judicial exception. See MPEP 2106.05(a) and 2016.05(f). As identified previously, this additional element can alternatively be considered insignificant extra-solution activity, as is it merely reciting, with a high level of generality, implementing the output/result of the mental process on a generic computer, with no restrictions on how the result is achieved and no description of the mechanism for achieving the result. Further, this step of insignificant extra-solution activity comprises the well-understood, routine, and conventional activities of storing data and transmitting data over a network (e.g., installing software, and sending the software to the host node where it is to be made available), which are not enough to amount to significantly more than the recited judicial exceptions. See MPEP 2106.05(a), 2106.05(d), and 2106.05(g).
The combination of these additional elements amounts to a method comprising steps which can be performed mentally implemented by a generic computer, and comprising steps of insignificant extra-solution activity and well-understood, routine, and conventional activity.
Therefore, the additional elements, when considered individually and in combination, fail to add an inventive concept to the claim.
Consequently claim 1 as a whole does not amount to significantly more than the recited judicial exceptions and the claim is not eligible.
Claim 2 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1, including the judicial exception “identifying an image layer subset”. Claim 2 recites the limitation wherein the image layer subset contains a superseding image layer to the target image layer, the one or more superseded image layers of the container omitted from the image layer subset including the target image layer. Since a person would still be able to identify the image layer subset specified in the limitation recited by claim 2 in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, the limitation of claim 2 is still reciting a mental process.
Claim 2 does not recite any additional elements beyond those recited in claim 1. Accordingly, for the same reasons presented with respect to claim 1, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 2 is not eligible.
Claim 3 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Further, claim 3 recites generating a streamlined minimum dependency graph identifying a minimum number of image layers for the container image layer deployment based on the target image layer specified in the download request and a substitution relationship between at least two image layers of the container, the identifying the image layer subset comprising generating the image layer subset from a minimum number of image layers for the container image layer deployment and the substitution relationship between the at least two image layers of the container which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 3 does not recite any additional elements beyond those recited in claim 1. Accordingly, for the same reasons presented with respect to claim 1, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 3 is not eligible.
Claim 4 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1, including the judicial exception “generating layer substitution relationship data”. Claim 4 recites the limitation wherein the generated layer substitution relationship data comprises a layer substitution list in metadata of a superseding image layer to the target image layer, the layer substitution list identifying the target image layer as being replaced by the superseding image layer. Since a person would still be able to generate the layer substitution relationship data specified in the limitation recited by claim 4 in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, the limitation of claim 4 is still reciting a mental process.
Claim 4 does not recite any additional elements beyond those recited in claim 1. Accordingly, for the same reasons presented with respect to claim 1, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 4 is not eligible.
Claim 5 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Further, claim 5 recites wherein generating the layer substitution data comprises generating and retaining, for multiple image layers of the container, a respective layer substitution list in associated metadata of each image layer of the multiple image layers of the container which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 5 does not recite any additional elements beyond those recited in claim 1. Accordingly, for the same reasons presented with respect to claim 1, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 3 is not eligible
For clarity of the record, the Examiner would like to note the limitation “and retaining” could be considered insignificant extra-solution activity of mere data gathering and outputting, which is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2016.05(g). Further, this step of insignificant extra-solution activity would also be considered well-understood, routine, and conventional activity of storing data, which is not enough to amount to significantly more than the recited judicial exception. See MPEP 2106.05(a), 2106.05(d) and 2106.05(g). Even when considered in combination with the additional elements of claim 1, the additional elements do not amount to significantly more than the recited judicial exceptions and do not provide an inventive concept. Thus, claim 5 is not eligible.
Claim 6 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Further, claim 6 recites wherein the generating comprises generating […] a layer substitution list based on analysis of one or more file substitution relationships between layers of the container image, the superseding image layer superseding, at least in part, the target image layer which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 6 recites the additional element during a committing of a superseding image layer to the container image in a container repository of the container-based computing environment which is generally linking to a particular technological environment. This additional element of generally linking to a particular technological environment is not indicative of integration into a practical application, nor is it enough to amount to significantly more than the recited judicial exception. See MPEP 2106.04(d), 2106.05(a) and 2106.05(h). Even when considered in combination with the additional elements of claim 1, the additional elements do not amount to significantly more than the recited judicial exceptions and do not provide an inventive concept. Thus, claim 6 is not eligible.
Claim 7 is dependent on claim 6, and therefore inherits the same judicial exceptions recited in claims 1 and 6. Further, claim 7 recites using […] at least the layer substitution list of the superseding image layer together with a relation ID list in building, based on the target image layer specified in the download request, a streamlined minimum dependency graph identifying a minimum number of image layers for the container image layer deployment which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 7 recites the additional element based on the download request which, for the same reasons presented with respect to claim 1, amounts to insignificant extra-solution activity of mere data gathering, and is not indicative of integration into a practical application. Further, it amount to the well-understood, routine, and conventional activity of receiving data over a network, which is not enough to amount to significantly more than the recited judicial exception. See MPEP 2106.04(d), 2106.05(a), 2106.05(d), and 2106.05(g). Even when considered in combination with the additional elements of claims 1 and 6, the additional elements do not amount to significantly more than the recited judicial exceptions and do not provide an inventive concept. Thus, claim 7 is not eligible.
Claim 8 is dependent on claim 7, and therefore inherits the same judicial exceptions recited in claims 1 and 6-7. The additional element recited in claims 1, 6 and 7 were not indicative of integration into a practical application nor did they amount to significantly more than the recited judicial exception as they recited mere instructions to apply the exception, steps of insignificant extra-solution activity and generally linking to a particular technological environment.
Claim 8 recites the additional element wherein the establishing includes using the streamlined minimum dependency graph in establishing the container image layer deployment pursuant to the download request, which amounts to mere instructions to apply the exception on a computer, which is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2106.05(f). Alternatively, this limitation could be considered insignificant extra-solution (specifically post-solution) activity of mere data outputting/insignificant application of the recited judicial exception, which is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2106.05(g). Further, neither mere instructions to apply the exception nor insignificant extra-solution activity amount to significantly more than the recited judicial exception. See MPEP 2106.05(a), 2106.05(f) and 2106.05(g). Even when considered in combination with the additional elements of claims 1 and 6-7, the additional elements do not amount to significantly more than the recited judicial exceptions and do not provide an inventive concept. Thus, claim 8 is not eligible.
Claim 10 recites A computer program product for facilitating processing within a computing environment, the computer program product comprising: a set of one or more computer readable storage media; and program instructions, collectively stored in the set of one or more storage media, for causing at least one processor set to perform computer operations comprising: the steps of the method of claim 1. Thus, for similar reasons presented with respect to claim 1, claim 10 is rejected because the claimed invention is directed to an abstract idea without significantly more.
For clarity of the record, regarding the claimed “computer program product” of claims 10-16, the Examiner would like to point to paragraph [0028] of the Specification of the instant application, which expressly excludes “transitory signals per se” from being included with the broadest reasonable interpretation of the computer program product. Accordingly, claims 10-16 fall within the four statutory categories, and is specifically considered an article of manufacture.
Further, the additional element recited above amounts to mere instructions to apply the exception on a generic computer, which is neither indicative of integration into a practical application nor amounts to significantly more than the recited judicial exception. See MPEP 2106.04(d) and MPEP 2106.05(f).
Claims 11-16 recite substantially the same limitations as those recited in claims 2-4 and 6-8, respectively, applied to the computer program product of claim 10. Thus, for the same reasons presented with respect to claims 2-4 and 6-8, claims 11-16 are directed to an abstract idea without significantly more and are not eligible.
Claim 17 recites A computer system comprising: at least one processor set; a set of one or more computer-readable storage media; and program instructions, collectively stored in the set of one or more storage media, for causing the at least one processor set to perform computer operations comprising: the steps of the method of claim 1. Thus, for similar reasons presented with respect to claim 1, claim 17 is rejected because the claimed invention is directed to an abstract idea without significantly more.
For clarity of the record, the additional element recited above amounts to mere instructions to apply the exception on a generic computer, which is neither indicative of integration into a practical application nor amounts to significantly more than the recited judicial exception. See MPEP 2106.04(d) and MPEP 2106.05(f).
Claims 18-20 recite substantially the same limitations as those recited in claims 2-3 and 6, respectively, applied to the computer system of claim 17. Thus, for the same reasons presented with respect to claims 2-3 and 6, claims 18-20 are directed to an abstract idea without significantly more and are not eligible.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 4-6, 10-11, 13-14, 17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rupprecht et al. (U.S. Pub. No. 2021/0096894), hereinafter Rupprecht, in view of Chibon et al. (U.S. Pub. No. 2025/0199839), hereinafter Chibon.
Regarding claim 1, Rupprecht teaches A computer-implemented method (FIG. 2; [0004] – “Embodiments of the present invention disclose a computer-implemented method, a computer program product, and a system for optimizing container images through automatic layer suggestions.”) comprising:
generating layer substitution relationship data for one or more image layers of a container image of a container-based computing environment ([0002] and [0011] – discusses a container-based computing environment, where containers include a plurality of layers), the layer substitution relationship data specifying one or more layer substitution relationships between different image layers of the container image ([0004] – “system for optimizing container images through automatic layer suggestions. The computer-implemented method includes one or more computer processers identifying one or more layers contained within an image. The one or more computer processors compare each identified layer with one or more layers contained in an image repository. […] The one or more computer processors determine a potential substitute layer utilizing a respective calculated layer overlap score.”; [0025] – “Program 150 compares image layers to layers in the registry (step 204). Responsive to program 150 detecting a pushed or modified image, program 150 identifies one or more sets of layers contained within a container image (e.g., pushed image).”; [0026] – “Program 150 calculates layer overlap (step 206). Program 150 compares each layer in the set of identified layers, as detailed in step 204, to each layer contained in each image in a repository or image registry (e.g., registry 122).”; [0029] – “Program 150, then, presents, displays, or prompts a user with one or more layer suggestions (e.g., potential layer substitutions, opportunities for increased layer shareability, etc.). In an embodiment, the layer suggestion contains information regarding the suggested layer substitute, the effect the substitute will have on other layers, details regarding expected container/host performance, and possible layer ramifications such as security considerations and potential broken file dependencies. In an embodiment, program 150 notifies or prompts the user for a response (e.g., layer selection). In other embodiments, program 150 presents a maintained list of all layer suggestions along with associated information.”);
[…], identifying an image layer subset that omits one or more superseded image layers of the container image, the identifying being based, at least in part, on the generated layer substitution relationship data for the one or more image layers of the container image ([0004] – “substitute one or more identified layers with the determined substitute layer. The one or more computer restructure one or more layers of the image based on the substituted layer.”; [0019] – “registry 122 contains one or more stored images that are decomposed into sets of individual layers that comprise each image”; [0032] – “then program 150 substitutes the layer (step 210)”; [0033] – “Program 150 utilizes the selected layer (e.g., highest ranked layer (i.e., highest layer overlap score)), as detailed in step 206, as a substitute layer (e.g., read-only shared layer). In an embodiment, program 150 replaces the file structure associated with a shared layer with links (e.g., layer links, container links, symbolic links, etc.) to shared layers and file structures. […] program 150 rearranges, automatically, one or more layers to maximize layer reusability. In an embodiment, program 150 may modify, replace, swap, or delete any subordinate (e.g., previous, below, etc.) layer in an image.”; [0035]-[0036] – “Program 150 utilizes decision 212 as a recursive function allowing program 150 to run recursively until all layers exceeding the layer overlap threshold are processed. […] Responsive to program 150 determining that there is no leftover file or layer (e.g., each file in the set of layers is associated with a shared layer (e.g., substitute layer)), program 150 pushes the image into the registry, as detailed below in step 214.”); and
establishing a container image layer deployment based on the identified image layer subset to facilitate container processing within the container-based computing environment ([0037] – “Program 150 pushes the image into the registry (step 214). Program 150 pushes, transmits, or stores the resulting image (e.g., optimized, modified, restructured, etc.), detailed in the above steps, into registry 122 or one or more image repositories. In an embodiment, program 150, automatically, deploys the modified image to another host or cluster of hosts”; [0011] – “Containers are prevalent in information technology and development operations deployments, servers, and systems. Containers allow for the rapid creation, modification, suspension, and deletion of one or more applications in a virtualized environment.”; [0002] – “programs running inside of a container can only see the contents of the container and devices assigned to the container.”).
Rupprecht fails to expressly teach identifying the image layer subset based on a download request that specifies a target image layer of the container image.
However, Chibon teaches identifying an image layer subset based on a download request that specifies a target image layer of the container image ([0016]-[0017] – “The environment 100 includes a layer state machine (LSM) system 104, one or more client devices 102, and an available image layers storage 108 that are each communicably coupled together via a communication network 120. […] The communication network 120 may be a public network (e.g., the internet)”; [0025] – LSM system 104 may be a server, client device may be a laptop or mobile device; [0033] – “The LSM agent 109 may be configured to receive a request (e.g., container modification request) from the client device 102”; [0035] – “The request may be to replace a first image layer (e.g., A1) of the one or more image layers with a different image layer (e.g., A2) […] The LSM agent 109 defines, in the container image file, the modified version of the container image (e.g., container image 112b) by replacing the first image layer (e.g., A1) with the different image layer (e.g., A2) and the second image layer (e.g., B1) with the available image layer (e.g., B2).”; FIG. 2C and [0059] – “The processing device 202c is configured to receive, from a client device 203c, a request 230 to modify a container image 212c that includes a base layer 210c-1 and one or more image layers (e.g., 201c-2, 201c-3). […]. The processing device 202c is configured to generate, based on the state machine 211c, a container image file 240c that defines a modified version of the container image 212b.” As shown in FIG. 2C, the modified container image file 240c is transferred via the network as detailed in [0016]-[0017], i.e., downloaded, from the LSM system 204c to the client device 202c in response to the request to modify the container image.).
Rupprecht and Chibon are considered to be analogous art to the claimed invention because they are in the same field of managing container image layers of a container-based computing environment. Therefore, it would have been obvious to one of ordinary skill in the art that identifying image layer subset that omits one or more superseded image layers of the container image as taught by Rupprecht may be based on a download request that specifies a target image layer as taught by Chibon. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
Regarding claim 2, the combination of Rupprecht in view of Chibon teaches The computer-implemented method of claim 1. Chibon further teaches wherein the image layer subset contains a superseding image layer to the target image layer, the one or more superseded image layers of the container omitted from the image layer subset including the target image layer ([0035] – “The request may be to replace a first image layer (e.g., A1) of the one or more image layers with a different image layer (e.g., A2) […] The LSM agent 109 defines, in the container image file, the modified version of the container image (e.g., container image 112b) by replacing the first image layer (e.g., A1) with the different image layer (e.g., A2) and the second image layer (e.g., B1) with the available image layer (e.g., B2).” The modified version of the container image (containing the identified image layer subset) replaces the first image layer (e.g., A1) (the “target image layer”) with the different image layer (e.g., A2) (the “superseding image layer to the target layer”).).
It would have been obvious to one of ordinary skill in the art that identifying the image layer subset that omits one or more superseded image layers of the container image as taught by Rupprecht may be based on a download request that specifies a target image layer (e.g., a target image layer to be replaced with a superseding image layer in the container image) as taught by Chibon. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced (i.e., “superseded”) in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
Regarding claim 4, the combination of Rupprecht in view of Chibon teaches The computer-implemented method of claim 1. Rupprecht further teaches wherein the generated layer substitution relationship data comprises a layer substitution list in metadata of a superseding image layer to [another] image layer, the layer substitution list identifying [another] image layer as being replaced by the superseding image layer ([0019] – “registry 122 contains one or more stored images that are decomposed into sets of individual layers that comprise each image. In this embodiment, each decomposed layer is associated with a metadata entry contained in layer metadata store 124.”; [0020] – “Layer metadata store 124 contains a plurality of sets of metadata for each container or image created, pushed, shared, and modified by program 150. In an embodiment, the contained metadata includes, but is not limited to, layer IDs, hashes, related layers […] Layer metadata store 124 maintains entries for each image, container, layer, software application, or program that program 150 detects, compares, decomposes, encounters, scans, identifies, or retrieves.”; [0029] – “layer suggestions (e.g., potential layer substitutions, […] program 150 presents a maintained list of all layer suggestions along with associated information […] program 150 presents a maintained list of all identified layers, including previously skipped or modified layers.”; [0037] – “Program 150 updates layer metadata store 124 with metadata generated from the operations detailed above. In an embodiment, program 150 stores the hashes generated from calculating layer intersection and creating substitute layers. In an embodiment, the updated metadata includes, but is not limited to, related layers”. A metadata entry, including related layers, is maintained for each layer used by program 150, thus including the substitute layer which replaces (“supersedes”) another layer in the container image (as described in [0029], [0032]-[0033]). The metadata/list of substitutions including related layers, is maintained even for previously identified/modified/substituted layers.).
Rupprecht does not, however Chibon further teaches a superseding image layer to the target image layer and metadata identifying the target image layer as being replaced by the superseding image layer ([0035]-[0036] and [0059] – a client sends a request to replace a first image layer (“target layer”) with a different image layer (e.g., replace a first database layer with an alternative database layer), and the LSM system defines the modified version of the container image in a container image file with the different image layer replacing the first image layer; [0012] – “The container spec file (e.g., container image file) can be decorated with annotations (e.g., tags, labels) in the form of Boolean algebra that shows available alternative […] This shows where layers might need an AND operator or can have an OR operator”).
It would have been obvious to one of ordinary skill in the art that the generated relationship substitution data comprising a layer substitution list in metadata for each image layer which indicates related layer (e.g., substitution relationships) as taught by Rupprecht would apply for the superseding image layer to the target image layer as taught by Chibon when identifying the image layer subset that omits one or more superseded image layers of the container image as taught by Rupprecht is modified to be based on a download request that specifies a target image layer (e.g., a target image layer to be replaced with a superseding image layer in the container image) as taught by Chibon with respect to claim 1. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced (i.e., “superseded”) in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
Regarding claim 5, the combination of Rupprecht in view of Chibon teaches The computer-implemented method of claim 1. Rupprecht further teaches wherein generating the layer substitution data comprises generating and retaining, for multiple image layers of the container, a respective layer substitution list in associated metadata of each image layer of the multiple image layers of the container ([0019] – “registry 122 contains one or more stored images that are decomposed into sets of individual layers that comprise each image. In this embodiment, each decomposed layer is associated with a metadata entry contained in layer metadata store 124.”; [0020] – “Layer metadata store 124 contains a plurality of sets of metadata for each container or image created, pushed, shared, and modified by program 150. In an embodiment, the contained metadata includes, but is not limited to, layer IDs, hashes, related layers […] Layer metadata store 124 maintains entries for each image, container, layer, software application, or program that program 150 detects, compares, decomposes, encounters, scans, identifies, or retrieves.”; [0029] – “layer suggestions (e.g., potential layer substitutions, […] program 150 presents a maintained list of all layer suggestions along with associated information […] program 150 presents a maintained list of all identified layers, including previously skipped or modified layers.”; [0037] – “Program 150 updates layer metadata store 124 with metadata generated from the operations detailed above. In an embodiment, program 150 stores the hashes generated from calculating layer intersection and creating substitute layers. In an embodiment, the updated metadata includes, but is not limited to, related layers”).
Regarding claim 6, the combination of Rupprecht in view of Chibon teaches The computer-implemented method of claim 1. Rupprecht further teaches wherein the generating comprises generating, during a committing of […] image layer to the container image in a container repository of the container-based computing environment, a layer substitution list based on analysis of one or more file substitution relationships between layers of the container image (FIG. 2; [0024] – “Program 150 detects a new image (step 202). Program 150 monitors registry 122 or is notified by registry 122 when a user pushes an image or when a user modifies an image stored within registry 122. […] program 150 monitors application (e.g., application 112) activity to determine a network request (e.g., image push or image modification). In an embodiment, program 150 identifies a pushed image and pauses, delays, or halts the push (e.g., image storage) until one or more layer optimizations have completed”; [0025] – “Program 150 compares image layers to layers in the registry (step 204). Responsive to program 150 detecting a pushed or modified image, program 150 identifies one or more sets of layers contained within a container image (e.g., pushed image). Each layer contains one or more sets of files/folders”; [0026] – “Program 150 calculates layer overlap (step 206). Program 150 compares each layer in the set of identified layers, as detailed in step 204, to each layer contained in each image in a repository or image registry (e.g., registry 122). In an embodiment, program 150 calculates a layer overlap score (e.g., value, rank, etc.) for each identified or decomposed layer in the detected container image based on the similarity (i.e., layer intersection) of said layer to another layer. In this embodiment, similarity can be calculated by the percentage of like files present in both layers”; [0028] – “Program 150 utilizes the filesystems of a plurality of layers to calculate and determine a layer overlap score for each pair of layers. In an embodiment, program 150 creates a plurality of decisions trees (e.g., a tree for each set of layers), where each tree splits when a layer is created, added, or modified”; [0029] – “Program 150, then, presents, displays, or prompts a user with one or more layer suggestions (e.g., potential layer substitutions, opportunities for increased layer shareability, etc.). In an embodiment, the layer suggestion contains information regarding the suggested layer substitute, the effect the substitute will have on other layers, details regarding expected container/host performance, and possible layer ramifications such as security considerations and potential broken file dependencies. In an embodiment, program 150 notifies or prompts the user for a response (e.g., layer selection). In other embodiments, program 150 presents a maintained list of all layer suggestions along with associated information.”).
Rupprecht does not, however Chibon teaches committing a superseding image layer to a container image, the superseding image layer superseding, at least in part, the target image layer ([0020] – “One or more developers create each of the image layers 101 using a computing device and store (e.g., upload) the image layers 101 in the available image layer storage 108 via the communication network 120.”; [0024] – “LSM agent 109 may retrieve a container image 112 and one or more image layers 101 from the available image layers storage 108 and add the one or more image layers on top of the layers of the container image 112”; [0035]-[0036] and [0059] – a client sends a request to replace, i.e., “supersede”, a first image layer (“target layer”) with a different image layer (e.g., replace a first database layer with an alternative database layer) in a container image, and the LSM system defines the modified version of the container image in a container image file with the different image layer replacing the first image layer).
It would have been obvious to one of ordinary skill in the art that the generating the relationship substitution data would comprise generating a layer substitution list during committing of image layers to container images (e.g., modifications to container images in the registry) as taught by Rupprecht would apply for the superseding image layer to the target image layer as taught by Chibon when identifying the image layer subset that omits one or more superseded image layers of the container image as taught by Rupprecht is modified to be based on a download request that specifies a target image layer (e.g., a target image layer to be replaced with a superseding image layer in the container image) as taught by Chibon with respect to claim 1. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced (i.e., “superseded”) in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
Regarding claim 10, Rupprecht teaches A computer program product for facilitating processing within a computing environment, the computer program product comprising:
a set of one or more computer readable storage media; and
program instructions, collectively stored in the set of one or more storage media, for causing at least one processor set to perform computer operations ([0050] – “The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”) comprising: the method of claim 1. Accordingly, claim 1 is rejected as being unpatentable over Rupprecht in view of Chibon for the same reasons presented with respect to claim 1.
Claim 11 recites substantially the same additional limitations as claim 2. Accordingly, claim 11 is rejected as being unpatentable over Rupprecht in view of Chibon for the same reasons presented with respect to claim 2.
Claim 13 recites substantially the same additional limitations as claim 4. Accordingly, claim 13 is rejected as being unpatentable over Rupprecht in view of Chibon for the same reasons presented with respect to claim 4.
Claim 14 recites substantially the same additional limitations as claim 6. Accordingly, claim 14 is rejected as being unpatentable over Rupprecht in view of Chibon for the same reasons presented with respect to claim 6.
Regarding claim 17, Rupprecht teaches A computer system ([0041] – “FIG. 5 depicts a block diagram of components of computing device 110 and server computer 120”) comprising:
at least one processor set ([0044] – processor(s) 501);
a set of one or more computer-readable storage media ([0043] – memory 502 and persistent storage 505); and
program instructions, collectively stored in the set of one or more storage media, for causing the at least one processor set to perform computer operations [0044] – “Program 150 may be stored in persistent storage 505 and in memory 502 for execution by one or more of the respective computer processor(s) 501”) comprising: the method of claim 1. Accordingly, claim 1 is rejected as being unpatentable over Rupprecht in view of Chibon for the same reasons presented with respect to claim 1.
Claim 18 recites substantially the same additional limitations as claim 2. Accordingly, claim 18 is rejected as being unpatentable over Rupprecht in view of Chibon for the same reasons presented with respect to claim 2.
Claim 20 recites substantially the same additional limitations as claim 6. Accordingly, claim 20 is rejected as being unpatentable over Rupprecht in view of Chibon for the same reasons presented with respect to claim 6.
Claims 3, 7-8, 12, 15-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rupprecht in view of Chibon as applied to claims 1, 10, 14 and 17 above, and further in view of Jayachandran et al. (U.S. Pub. No. 2017/0068676), hereinafter Jayachandran, and Prasad et al. (U.S. Pub. No. 2021/0103450), hereinafter Prasad.
Regarding claim 3, the combination of Rupprecht in view of Chibon teaches The computer-implemented method of claim 1. Rupprecht further teaches determining image layers for the container image layer deployment based on […] the container image deployment based on a substitution relationship between at least two image layers of the container, the identifying the image layer subset comprising generating the image layer subset from […] image layers for the container image layer deployment and the substitution relationship between the at least two image layers of the container ([0004] – “system for optimizing container images through automatic layer suggestions. The computer-implemented method includes one or more computer processers identifying one or more layers contained within an image. The one or more computer processors compare each identified layer with one or more layers contained in an image repository. […] The one or more computer processors determine a potential substitute layer utilizing a respective calculated layer overlap score. […] substitute one or more identified layers with the determined substitute layer. The one or more computer restructure one or more layers of the image based on the substituted layer.”; [0029] – “Program 150, then, presents, displays, or prompts a user with one or more layer suggestions (e.g., potential layer substitutions, opportunities for increased layer shareability, etc.). In an embodiment, the layer suggestion contains information regarding the suggested layer substitute, the effect the substitute will have on other layers, details regarding expected container/host performance, and possible layer ramifications such as security considerations and potential broken file dependencies. In an embodiment, program 150 notifies or prompts the user for a response (e.g., layer selection). In other embodiments, program 150 presents a maintained list of all layer suggestions along with associated information.”); [0033] – “Program 150 utilizes the selected layer (e.g., highest ranked layer (i.e., highest layer overlap score)), as detailed in step 206, as a substitute layer (e.g., read-only shared layer). In an embodiment, program 150 replaces the file structure associated with a shared layer with links (e.g., layer links, container links, symbolic links, etc.) to shared layers and file structures. […] program 150 rearranges, automatically, one or more layers to maximize layer reusability. In an embodiment, program 150 may modify, replace, swap, or delete any subordinate (e.g., previous, below, etc.) layer in an image.”; [0037] – “Program 150 pushes the image into the registry (step 214). Program 150 pushes, transmits, or stores the resulting image (e.g., optimized, modified, restructured, etc.), detailed in the above steps, into registry 122 or one or more image repositories. In an embodiment, program 150, automatically, deploys the modified image to another host or cluster of hosts”).
Chibon further teaches determining image layers for the container image layer deployment based on the target image layer specified in the download request and a substitution relationship between at least two image layers of the container ([0033]-[0034] – “The LSM agent 109 may be configured to receive a request (e.g., container modification request) from the client device 102, where the request is to modify a container image 112 that includes a base layer (e.g., 101a-1) and one or more image layers (e.g., 101a-2, 101a-3). […] The LSM agent 109 may be configured to generate, based on the state machine 111, a container image file that defines a modified version of the container image. For example, the request may be to modify container image 112a (currently running) to tum it into and/or replace it with container image 112b. The LSM agent 109 may be configured to send (e.g., transmit), to the client device 102, the container image file to be used by the client device 102 […] the sending of the container image file causing the CCM agent 105 of the client device 102 to either stop (e.g., tear down) the container image 112a that is currently running and then execute the container image 112b”; [0035] – the modified version of the container image (e.g., container image 112b) may omit a first image layer (e.g., layer A1) and replace (“substitute”) it with a different image layer (e.g. layer A2) according to the request from the client device; [0042] – “a plurality of optional images layers of the plurality
of modified versions of the container image are defined using Boolean logic (e.g., AND, OR, NOT).”).
It would have been obvious to one of ordinary skill in the art that identifying the image layer subset that omits one or more superseded image layers of the container image, wherein the deployment is based on the identified image layer subset, as taught by Rupprecht may be based on a download request that specifies a target image layer, such that the deployment is based on the target image layer specified in the request, as taught by Chibon. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced (i.e., “superseded”) in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
The combination of Rupprecht in view of Chibon fails to expressly teach generating a streamlined minimum dependency graph identifying a minimum number of image layers for the container image layer deployment, and the identifying the image layer subset comprising generating the image layer subset from a minimum number of image layers for the container image layer deployment.
However, Jayachandran teaches generating a streamlined […] dependency graph identifying a […] number of image layers for the container image based on a target image layer and a substitution relationship between at least two image layers ([0014] – “optimizing the number of layers of images (such as, for example, Docker™ images) by retaining selected software components and removing unwanted components. […] A dependency graph (for example, a directed acyclic graph) can be generated between software components across layers in the image”; [0026] – “The user can then select the specific layers that he or she wants to retain. The system then removes the links to the unwanted layers and overlays the selected layers to create a new (leaner) coherent file system image. Further, in at least one embodiment of the invention, a dependency graph between the layers of an image can be used to ensure that none of the selected layers bear a dependency on one or more of the removed layers, thereby ensuring that the software components selected will perform as expected in the newly created (leaner) image. In one or more embodiments of the invention, a user can remove one or more layers of an image and, in its/their place, insert one or more other layers to create a new coherent file system image.”; [0037] – “dependency analyzer 206 identifies any dependencies between software components and generates a dependency graph between layers in the given image.”; [0040]-[0041] – “Referring again to FIG. 2, the image compactor 208 uses the generated dependency graph to identify one or more layers that need to be retained for the selected software components as well as one or more layers that can be removed. The image compactor 208 additionally creates the final image from the selected layers. In at least one embodiment of the invention, the image compactor 208 selects all layers that contain application components selected by the user, as well as all lower layers on which such layers depend using the dependency graph generated by the dependency analyzer 206. The output final image contains a sub-set of layers representing only the required layers for the selected application component. The sub-set of layers can be loaded as an image. In another embodiment of the invention, the image compactor 208 can remove one or more layers from an image, and in its/their place, insert one or more new layers.” Selecting only the required layers using the dependency graph is implicitly determining/identifying (i.e., generating) a “streamlined” dependency graph containing only the required layers.), and the identifying the image layer subset comprising generating the image layer subset from a […] number of image layers for the container image layer deployment ([0014] – “optimizing the number of layers of images (such as, for example, Docker™ images) by retaining selected software components and removing unwanted components. […] A dependency graph (for example, a directed acyclic graph) can be generated between software components across layers in the image”; [0040]-[0041] – “Referring again to FIG. 2, the image compactor 208 uses the generated dependency graph to identify one or more layers that need to be retained for the selected software components as well as one or more layers that can be removed. The image compactor 208 additionally creates the final image from the selected layers. In at least one embodiment of the invention, the image compactor 208 selects all layers that contain application components selected by the user, as well as all lower layers on which such layers depend using the dependency graph generated by the dependency analyzer 206. The output final image contains a sub-set of layers representing only the required layers for the selected application component. The sub-set of layers can be loaded as an image. In another embodiment of the invention, the image compactor 208 can remove one or more layers from an image, and in its/their place, insert one or more new layers.”).
Jayachandran is considered to be analogous art to the claimed invention because it is in the same field of managing container image layers of a container-based computing environment. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Rupprecht in view of Chibon to include generating a streamlined dependency graph indicating a number of layers in the container image taught by Jayachandran based on the target image layer taught by Chibon and the substitution relationship taught by Rupprecht, such that identifying the image layer subset is based on the number of layers indicated by the streamlined dependency graph as taught by Jayachandran. Using a dependency graph according to the methods of Jayachandran would provide the benefit of allowing a user to create a leaner container image with an optimal number of layers comprising only required layers needed for a user’s desired functionality and removing any layers that are not required by the user, while ensuring the container will function as expected (Jayachandran: [0014], [0017] and [0026]).
The combination of Rupprecht in view of Chibon and Jayachandran does not expressly teach the streamlined dependency graph as a streamlined minimum dependency graph indicating a minimum number of image layers and generating the image layer subset from a minimum number of image layers.
However, Prasad teaches a dependency graph indicating a minimum number of image layers for a container image and generating an image layer subset for the container imager from the minimum number of image layers ([0031] – “generating a container image assembly file with add-on library vulnerabilities removed and with container image size minimized (i.e., number of layers of the container image are reduced to a minimum number)”; [0033] – “Container image assembly manager 218 generates container image assembly file 224 based on the information contained within knowledge base 220 and library dependency graph 222. […] container image assembly manager 218 may deploy the generated container image”; [0046] – “Considering a base container image and add-on libraries as activities (e.g., a sequence of library dependencies), illustrative embodiments generate the library dependency graph […] each path in the library dependency graph is a valid sequence of library dependencies.”; [0051] – “illustrative embodiments compute a total size of the container image and identify a base container image variant with a minimum or smallest size (i.e., smallest number of layers).”; [0052] – “When preparing the initial container image assembly file, illustrative embodiments utilize the selected base image variant with minimum size and the generated list of libraries needed as add-ons. Further, based on information in the knowledge base, illustrative embodiments assign a sequence number to each add-on library in the list. Furthermore, illustrative embodiments generate the container image assembly file by adding one layer for each add-on library in the list to the container image.”; [0066]-[0069] – “Container image optimizer 324 utilizes application definition reader 334 to read application definitions 314 to find out which add-on libraries are needed by respective applications. These add-on libraries are leaf nodes in data structures of the library dependency graphs generated by library dependency graph builder 322 during graph training […] Container image optimizer 324 utilizes predictor 336, based on information in knowledge base 326, to: retrieve add-on libraries identified in a respective application definition and to predict an optimum path (i.e., set of container image assembly file lines) to install those add-on libraries […] Container image optimizer 324 utilizes optimizer 340, based on information in knowledge base 326, to: generate multiple container image assembly files using different base container images and a set of needed add-on libraries; compare build time and size of the different container images; and output an optimal set of instructions needed in a respective container image assembly file. Knowledge base 326 is a persistent storage for trained library dependency graphs and various derived features of those graphs.”).
Prasad is considered to be analogous art to the claimed invention because it is in the same field of managing container image layers of a container-based computing environment. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Rupprecht in view of Chibon and Jayachandran such that the streamlined dependency graph indicates a minimum number of image layers and that the image layer subset is generated based on a minimum number of image layers as taught by Prasad. Minimizing the number of layers in a container image reduces the time it takes to bring up the container image for running, i.e., reduces the time to deploy the container image (Prasad: [0075]).
Regarding claim 7, the combination of Rupprecht in view of Chibon teaches The computer-implemented method of claim 6. Rupprecht further teaches using […] at least the layer substitution list of the superseding image layer together with a relation ID list in […] identifying a […] number of image layers for the container image layer deployment ([0020] – “Layer metadata store 124 contains a plurality of sets of metadata for each container or image created, pushed, shared, and modified by program 150. In an embodiment, the contained metadata includes, but is not limited to, layer IDs, hashes, related layers, software, containers, file structures, filenames, folder names, parent folders, subfolders […] Layer metadata store 124 maintains entries for each image, container, layer, software application, or program that program 150 detects, compares, decomposes, encounters, scans, identifies, or retrieves.”; [0029] – “Program 150, then, presents, displays, or prompts a user with one or more layer suggestions (e.g., potential layer substitutions, opportunities for increased layer shareability, etc.). In an embodiment, the layer suggestion contains information regarding the suggested layer substitute, the effect the substitute will have on other layers, details regarding expected container/host performance, and possible layer ramifications such as security considerations and potential broken file dependencies. In an embodiment, program 150 notifies or prompts the user for a response (e.g., layer selection). In other embodiments, program 150 presents a maintained list of all layer suggestions along with associated information.”; [0033] – “Program 150 utilizes the selected layer (e.g., highest ranked layer (i.e., highest layer overlap score)), as detailed in step 206, as a substitute layer […] The substitute layer contains a file structure (e.g., sets of files and folders) corresponding with a file structure of an existing shared layer in registry 122. Program 150 removes all related (e.g., not associated with a substitute layer) folders and files associated with said file structure and adds/moves (e.g., including removing said files from the substitute layer) all missed files and layers to a leftover layer […] Mistakenly removing necessary files in a leftover layer may create problems if said files are referenced by lower layers (e.g., files referenced by many programs, functions, and applications). Program 150 performs extra checks and tests to ensure that all files exist in the final restructured image. In an embodiment, program 150 utilizes test cases to verify that all required files exist and, in tum, ensure container functionality. Responsive to the creation of a substitute layer and a leftover layer, program 150 rearranges, automatically, one or more layers to maximize layer reusability. In an embodiment, program 150 may modify, replace, swap, or delete any subordinate (e.g., previous, below, etc.) layer in an image. For example, program 150 swaps two layers to maximize layer reusability and shareability. In this example, program 150 runs a plurality of file structure and functionality tests to verify that no references or dependencies were severed”; [0037] – “Program 150 pushes the image into the registry (step 214). Program 150 pushes, transmits, or stores the resulting image ( e.g., optimized, modified, restructured, etc.), detailed in the above steps, into registry 122 or one or more image repositories. In an embodiment, program 150, automatically, deploys the modified image to another host or cluster of hosts. […] Program 150 updates layer metadata store 124 with metadata generated from the operations detailed above. […] updated metadata includes, but is not limited to, related layers, software, containers, filenames, folder names, parent folders, subfolders”. Rearranging the container image layers, i.e., after a layer substitution based on a list of suggested substitutions (“layer substitution list”), comprises ensuring dependencies, such as related folders and files (e.g., related layers, parent folders and subfolders/files specified in metadata for the layer – the “relation ID list”) are present in the rearranged container image layers.).
Chibon further teaches using, based on the download request, at least the layer substitution of the superseding image layer in, based on the target image layer specified in the download request, identifying image layers for the container image layer deployment ([0033]-[0034] – “The LSM agent 109 may be configured to receive a request (e.g., container modification request) from the client device 102, where the request is to modify a container image 112 that includes a base layer (e.g., 101a-1) and one or more image layers (e.g., 101a-2, 101a-3). […] The LSM agent 109 may be configured to generate, based on the state machine 111, a container image file that defines a modified version of the container image. For example, the request may be to modify container image 112a (currently running) to tum it into and/or replace it with container image 112b. The LSM agent 109 may be configured to send (e.g., transmit), to the client device 102, the container image file to be used by the client device 102 […] the sending of the container image file causing the CCM agent 105 of the client device 102 to either stop (e.g., tear down) the container image 112a that is currently running and then execute the container image 112b”; [0035] – the modified version of the container image (e.g., container image 112b) may omit a first image layer (e.g., layer A1) and replace (“substitute” or supersede) it with a different image layer (e.g. layer A2) according to the request from the client device; [0042] – “a plurality of optional images layers of the plurality of modified versions of the container image are defined using Boolean logic (e.g., AND, OR, NOT).”).
It would have been obvious to one of ordinary skill in the art that identifying the image layer subset that omits one or more superseded image layers of the container image, wherein the deployment is based on the identified image layer subset, as taught by Rupprecht may be based on a download request that specifies a target image layer and superseding image layer to the target image layer, such that the deployment is based on the target image layer specified in the request, as taught by Chibon. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced (i.e., “superseded”) in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
The combination of Rupprecht in view of Chibon fails to expressly teach using a layer substitution of the superseding image layer together with a relation ID list in building, based on the target image layer, a streamlined minimum dependency graph identifying a minimum number of image layers.
However, Jayachandran teaches using a layer substitution of a superseding image layer together with a relation ID list in building, based on the target image layer, a streamlined […] dependency graph identifying a number of image layers ([0014] – “optimizing the number of layers of images (such as, for example, Docker™ images) by retaining selected software components and removing unwanted components. […] A dependency graph (for example, a directed acyclic graph) can be generated between software components across layers in the image”; [0026] – “The user can then select the specific layers that he or she wants to retain. The system then removes the links to the unwanted layers and overlays the selected layers to create a new (leaner) coherent file system image. Further, in at least one embodiment of the invention, a dependency graph between the layers of an image can be used to ensure that none of the selected layers bear a dependency on one or more of the removed layers, thereby ensuring that the software components selected will perform as expected in the newly created (leaner) image. In one or more embodiments of the invention, a user can remove one or more layers of an image and, in its/their place, insert one or more other layers to create a new coherent file system image.”; [0037] – “dependency analyzer 206 identifies any dependencies between software components and generates a dependency graph between layers in the given image. Given a set of selected software components, the dependency analyzer 206 identifies the layers of files on which the components depend. […] a combination of techniques can be implemented to build such a dependency graph.”. The dependencies between software components/layers are analogous to a “relation ID list”, as they identify the relationships between layers/software components within the layers. [0040]-[0041] – “Referring again to FIG. 2, the image compactor 208 uses the generated dependency graph to identify one or more layers that need to be retained for the selected software components as well as one or more layers that can be removed. The image compactor 208 additionally creates the final image from the selected layers. In at least one embodiment of the invention, the image compactor 208 selects all layers that contain application components selected by the user, as well as all lower layers on which such layers depend using the dependency graph generated by the dependency analyzer 206. The output final image contains a sub-set of layers representing only the required layers for the selected application component. The sub-set of layers can be loaded as an image. In another embodiment of the invention, the image compactor 208 can remove one or more layers from an image, and in its/their place, insert one or more new layers.” Selecting only the required layers using the dependency graph is implicitly determining/identifying (i.e., generating) a “streamlined” dependency graph containing only the required layers.).
Jayachandran is considered to be analogous art to the claimed invention because it is in the same field of managing container image layers of a container-based computing environment. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Rupprecht in view of Chibon to include building a streamlined dependency graph indicating a number of layers in the container image taught by Jayachandran based on the target image layer taught by Chibon and the layer substitution list and relation ID list taught by Rupprecht, such that identifying the image layers is based on the number of layers indicated by the streamlined dependency graph as taught by Jayachandran. Using a dependency graph according to the methods of Jayachandran would provide the benefit of allowing a user to create a leaner container image with an optimal number of layers comprising only required layers needed for a user’s desired functionality and removing any layers that are not required by the user, while ensuring the container will function as expected (Jayachandran: [0014], [0017] and [0026]).
The combination of Rupprecht in view of Chibon and Jayachandran fails to expressly teach the streamlined dependency graph as a streamlined minimum dependency graph indicating a minimum number of image layers.
However, Prasad teaches a dependency graph indicating a minimum number of image layers for a container image for the container image layer deployment ([0031] – “generating a container image assembly file with add-on library vulnerabilities removed and with container image size minimized (i.e., number of layers of the container image are reduced to a minimum number)”; [0033] – “Container image assembly manager 218 generates container image assembly file 224 based on the information contained within knowledge base 220 and library dependency graph 222. […] container image assembly manager 218 may deploy the generated container image”; [0046] – “Considering a base container image and add-on libraries as activities (e.g., a sequence of library dependencies), illustrative embodiments generate the library dependency graph […] each path in the library dependency graph is a valid sequence of library dependencies.”; [0051] – “illustrative embodiments compute a total size of the container image and identify a base container image variant with a minimum or smallest size (i.e., smallest number of layers).”; [0052] – “When preparing the initial container image assembly file, illustrative embodiments utilize the selected base image variant with minimum size and the generated list of libraries needed as add-ons. Further, based on information in the knowledge base, illustrative embodiments assign a sequence number to each add-on library in the list. Furthermore, illustrative embodiments generate the container image assembly file by adding one layer for each add-on library in the list to the container image.”; [0066]-[0069] – “Container image optimizer 324 utilizes application definition reader 334 to read application definitions 314 to find out which add-on libraries are needed by respective applications. These add-on libraries are leaf nodes in data structures of the library dependency graphs generated by library dependency graph builder 322 during graph training […] Container image optimizer 324 utilizes predictor 336, based on information in knowledge base 326, to: retrieve add-on libraries identified in a respective application definition and to predict an optimum path (i.e., set of container image assembly file lines) to install those add-on libraries […] Container image optimizer 324 utilizes optimizer 340, based on information in knowledge base 326, to: generate multiple container image assembly files using different base container images and a set of needed add-on libraries; compare build time and size of the different container images; and output an optimal set of instructions needed in a respective container image assembly file. Knowledge base 326 is a persistent storage for trained library dependency graphs and various derived features of those graphs.”).
Prasad is considered to be analogous art to the claimed invention because it is in the same field of managing container image layers of a container-based computing environment. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Rupprecht in view of Chibon and Jayachandran such that the streamlined dependency graph indicates a minimum number of image layers for the container image layer deployment as taught by Prasad. Minimizing the number of layers in a container image reduces the time it takes to bring up the container image for running, i.e., reduces the time to deploy the container image (Prasad: [0075]).
Regarding claim 8, the combination of Rupprecht in view of Chibon, Jayachandran and Prasad teaches The computer-implemented method of claim 7. Chibon further teaches wherein the establishing includes […] establishing the container image layer deployment pursuant to the download request ([0033]-[0034] – “The LSM agent 109 may be configured to receive a request (e.g., container modification request) from the client device 102, where the request is to modify a container image 112 that includes a base layer (e.g., 101a-1) and one or more image layers (e.g., 101a-2, 101a-3). […] The LSM agent 109 may be configured to generate, based on the state machine 111, a container image file that defines a modified version of the container image. For example, the request may be to modify container image 112a (currently running) to tum it into and/or replace it with container image 112b. The LSM agent 109 may be configured to send (e.g., transmit), to the client device 102, the container image file to be used by the client device 102 […] the sending of the container image file causing the CCM agent 105 of the client device 102 to either stop (e.g., tear down) the container image 112a that is currently running and then execute the container image 112b”; [0035] – the modified version of the container image (e.g., container image 112b) may omit a first image layer (e.g., layer A1) and replace it with a different image layer (e.g. layer A2) according to the request from the client device).
It would have been obvious to one of ordinary skill in the art that identifying the image layer subset that omits one or more superseded image layers of the container image, wherein the deployment is based on the identified image layer subset, as taught by Rupprecht may be based on a download request that specifies a target image layer, such that the deployment is pursuant to the request, as taught by Chibon. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced (i.e., “superseded”) in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
Prasad further teaches using the streamlined minimum dependency graph in establishing the container image layer deployment ([0031] – “generating a container image assembly file with add-on library vulnerabilities removed and with container image size minimized (i.e., number of layers of the container image are reduced to a minimum number)”; [0033] – “Container image assembly manager 218 generates container image assembly file 224 based on the information contained within knowledge base 220 and library dependency graph 222. […] container image assembly manager 218 may deploy the generated container image”; [0046] – “Considering a base container image and add-on libraries as activities (e.g., a sequence of library dependencies), illustrative embodiments generate the library dependency graph […] each path in the library dependency graph is a valid sequence of library dependencies.”; [0051] – “illustrative embodiments compute a total size of the container image and identify a base container image variant with a minimum or smallest size (i.e., smallest number of layers).”; [0052] – “When preparing the initial container image assembly file, illustrative embodiments utilize the selected base image variant with minimum size and the generated list of libraries needed as add-ons. Further, based on information in the knowledge base, illustrative embodiments assign a sequence number to each add-on library in the list. Furthermore, illustrative embodiments generate the container image assembly file by adding one layer for each add-on library in the list to the container image.”; [0066]-[0069] – “Container image optimizer 324 utilizes application definition reader 334 to read application definitions 314 to find out which add-on libraries are needed by respective applications. These add-on libraries are leaf nodes in data structures of the library dependency graphs generated by library dependency graph builder 322 during graph training […] Container image optimizer 324 utilizes predictor 336, based on information in knowledge base 326, to: retrieve add-on libraries identified in a respective application definition and to predict an optimum path (i.e., set of container image assembly file lines) to install those add-on libraries […] Container image optimizer 324 utilizes optimizer 340, based on information in knowledge base 326, to: generate multiple container image assembly files using different base container images and a set of needed add-on libraries; compare build time and size of the different container images; and output an optimal set of instructions needed in a respective container image assembly file. Knowledge base 326 is a persistent storage for trained library dependency graphs and various derived features of those graphs.”).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Rupprecht in view of Chibon and Jayachandran such that the streamlined dependency graph indicates a minimum number of image layers and is used in establishing the container image layer deployment as taught by Prasad. Minimizing the number of layers in a container image reduces the time it takes to bring up the container image for running, i.e., reduces the time to deploy the container image (Prasad: [0075]).
Claim 12 recites substantially the same additional limitations as claim 3. Accordingly, claim 12 is rejected as being unpatentable over Rupprecht in view of Chibon as applied to claim 10, and further in view of Jayachandran and Prasad for the same reasons presented with respect to claim 3.
Claim 15-16 recite substantially the same additional limitations as claims 7-8. Accordingly, claims 15-16 are rejected as being unpatentable over Rupprecht in view of Chibon as applied to claim 14, and further in view of Jayachandran and Prasad for the same reasons presented with respect to claims 7-8.
Claim 19 recites substantially the same additional limitations as claim 3. Accordingly, claim 19 is rejected as being unpatentable over Rupprecht in view of Chibon as applied to claim 17, and further in view of Jayachandran and Prasad for the same reasons presented with respect to claim 3.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Rupprecht in view of Chibon as applied to claim 1 above, and further in view of Prasad.
Regarding claim 9, the combination of Rupprecht in view of Chibon teaches The computer-implemented method of claim 1. Rupprecht further teaches wherein establishing the container image layer deployment results in deployment of [...] layers of the container image ([0037] – “Program 150 pushes the image into the registry (step 214). Program 150 pushes, transmits, or stores the resulting image (e.g., optimized, modified, restructured, etc.), detailed in the above steps, into registry 122 or one or more image repositories. In an embodiment, program 150, automatically, deploys the modified image to another host or cluster of hosts”; [0011] – “Containers are prevalent in information technology and development operations deployments, servers, and systems. Containers allow for the rapid creation, modification, suspension, and deletion of one or more applications in a virtualized environment. Traditionally, containers contain a plurality of layers that can be shared with other containers in an attempt to reduce storage utilization in image registries, on container hosts, and deployment servers”; [0019 ] –“registry 122 contains one or more stored images that are decomposed into sets of individual layers that comprise each image”) […].
Chibon further teaches deployment of layers of the container image pursuant to the download request ([0033]-[0034] – “The LSM agent 109 may be configured to receive a request (e.g., container modification request) from the client device 102, where the request is to modify a container image 112 that includes a base layer (e.g., 101a-1) and one or more image layers (e.g., 101a-2, 101a-3). […] The LSM agent 109 may be configured to generate, based on the state machine 111, a container image file that defines a modified version of the container image. For example, the request may be to modify container image 112a (currently running) to tum it into and/or replace it with container image 112b. The LSM agent 109 may be configured to send (e.g., transmit), to the client device 102, the container image file to be used by the client device 102 […] the sending of the container image file causing the CCM agent 105 of the client device 102 to either stop (e.g., tear down) the container image 112a that is currently running and then execute the container image 112b”; [0035] – the modified version of the container image (e.g., container image 112b) may omit a first image layer (e.g., layer A1) and replace it with a different image layer (e.g. layer A2) according to the request from the client device).
It would have been obvious to one of ordinary skill in the art that identifying the image layer subset that omits one or more superseded image layers of the container image, wherein the deployment is based on the identified image layer subset, as taught by Rupprecht may be based on a download request that specifies a target image layer, such that the deployment is pursuant to the request, as taught by Chibon. Incorporating the teachings of Chibon, which allows a user to send a request specifying a container image layer to be replaced (i.e., “superseded”) in a container image to be downloaded and executed, would facilitate a user of the container flexibly swapping out functionality as needed and to better fit the environment in which the container is to execute (Chibon: [0010]).
The combination of Rupprecht in view of Chibon fails to expressly teach deployment of a reduced count of layers of the container image.
However, Prasad teaches deployment of a reduced count of layers of the container image ([0031] – “generating a container image assembly file with add-on library vulnerabilities removed and with container image size minimized (i.e., number of layers of the container image are reduced to a minimum number)”; [0033] – “Container image assembly manager 218 generates container image assembly file 224 based on the information contained within knowledge base 220 and library dependency graph 222. […] container image assembly manager 218 may deploy the generated container image to a set of one or more host nodes in a production environment for running.”; [0051] – “illustrative embodiments compute a total size of the container image and identify a base container image variant with a minimum or smallest size (i.e., smallest number of layers).”; [0052] – “When preparing the initial container image assembly file, illustrative embodiments utilize the selected base image variant with minimum size and the generated list of libraries needed as add-ons. Further, based on information in the knowledge base, illustrative embodiments assign a sequence number to each add-on library in the list. Furthermore, illustrative embodiments generate the container image assembly file by adding one layer for each add-on library in the list to the container image.”; [0053] – “When optimizing layers of the container image, […] illustrative embodiments recommend replacements for vulnerable container images by providing alternate paths for installation of application add-on libraries with vulnerabilities removed. Illustrative embodiments also merge multiple sequential layers of the initial container image assembly file based on rules”; [0075] – “The computer optimizes the container image assembly file by providing alternate paths for installation of the add-on libraries with the vulnerabilities removed (step 508). The computer further optimizes the container image assembly file by merging multiple sequential layers of the container image assembly file based on predefined rules for reducing a number of layers in the container image assembly file (step 510). The predefined rules include file affinity in sequential layers according to information in the knowledge base, size of a layer after merging layers not exceeding a predefined layer size, and any user-defined rules. It should be noted that reducing the number of layers reduces the time it takes to bring up the container image for running.”).
Prasad is considered to be analogous art to the claimed invention because it is in the same field of managing container image layers of a container-based computing environment. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Rupprecht in view of Chibon such establishing the container image deployment results in deployment of a reduced count of image layers as taught by Prasad. Reducing the number of layers in a container image reduces the time it takes to bring up the container image for running, i.e., reduces the time to deploy the container image (Prasad: [0075]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Griffin et al. (U.S. Pub. No. 2023/0418594) teaches a system for dynamically switching layers of a container image for adapting performance to a particular computing environment, where the layers are tagged with metadata indicating their role and rules for executing the layer, where the rules include one or more optional layers, where the optional layers may take the place of one or more of the layers of a container image to generate a particular version of the container image (see Fig. 1, Abstract, [0013], [0024], and [0027]). In response to a client request, the system generates a container image that includes one or more unique layers and determines the optional layers for each layers based on the metadata tags, and transmits a version of the container image to the client device (see [0031]-[0034]).
Mathews et al. (U.S. Pub. No. 2022/0229647) teaches generating a dependency tree by identifying which dependencies (e.g., portions of code included in layers) are needed for an application to run (see [0057]). It further teaches containerization platforms may impose limits on the number of layers that can be formed or used in an image, and to address these constraints the number of layers may be reduced by combining sub-dependencies that are unique to a node in a dependency tree with their dominating node into a single layer (see [0055], [0086], and [0091]).
Zhao et al. (U.S. Patent No. 10,534,671) teaches a method for managing container images in which an image layer of a container image, structured as a chain or tree of layers, is identified for compaction and the data of the identified layer is merged with data of another image layer of the container image (see Abstract, Col. 3, lines 39-61, and Col. 5, lines 49-59). It further teaches image layers, because of their dependencies, form a tree structure, and a layer being compacted is removed from the tree (see Col. 6, lines 1-10). Compacting the image layers reduces the number of layers in the container image, which reduces wasted storage space and improves performance of a deployment (Col. 4, lines 13-20 and Col. 5, lines 14-21).
Featonby et al. (U.S. Patent No. 11,892,418) teaches a system which identifies and removes unused files and/or layers from a container image (e.g., removes layers that were previously relied upon but are no longer used or replace layers that are currently used with layers that have superior performance) to reduce the size of the container image and thus improve startup latency, reduce storage costs, and reduce security vulnerabilities due to layers that are not properly maintained (see Abstract and Col. 2, lines 46-57).
BenHanokh et al. (U.S. Patent No. 11,983,525) teaches generating an updated container image in which a layer of the container image is replaced with a different layer in order to reduce the size of the container image (see Abstract, Col. 2, lines 35-60).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
