DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This action is in response to the following communication: Non-provisional Application No. 18/657,497 filed on 05/07/2024.
3. Claims 1-20 are pending.
Claims 1, 15 and 19 are independent claims.
Claim Interpretation
4. It is noted that claims 1 and 19 recites intended use language.
Claim 1: “instructions that, when executed…”.
Claim 19. “instructions that, when executed…”.
Appropriate corrections are required.
Claim Objections
5: Claims 16 and 18 are objected to because of the following informalities:
Claim 16, line 1, recites “the method of claim 14”, however claim 14 doesn’t recite a “method”. Therefore this claim will be treated as being dependent on claim 15.
Claim 18, line 1, recites “the method of claim 14”, however claim 14 doesn’t recite a “method”. Therefore this claim will be treated as being dependent on claim 15.
Claim Rejections - 35 USC § 101
6. 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.
7. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Regarding claims 1, 15 and 19, the limitations “determining a first side effect,” “associating the delta layer”, and “associating the delta storage” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Claims 1, 15 and 19: Under Prong 2 Step 2A, the judicial exception is not integrated into a practical application. The additional elements “a processor”, “a memory”, “a device”, and “storage” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. The additional element “receiving an update”, “performing a first sequence“, “recording the first sequence“, “recording the first side effect“, “performing a second sequence“, “recording the side effect”, “applying a sequence of operations”, “recording the sequence of operations”, “recording the side effect” and “recording the second sequence“ do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering data. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f) and (g), respectively.
Claims 1, 15 and 19: Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional elements “a processor”, “a memory”, “a device”, and “storage” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, and the additional element “receiving an update”, “performing a first sequence“, “recording the first sequence“, “recording the first side effect“, “performing a second sequence“, “recording the side effect”, “applying a sequence of operations”, “recording the sequence of operations”, “recording the side effect” and “ recording the second sequence“ is merely gathering data which the courts have identified as well-understood, routine conventional activity. See for example Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, MPEP 2106.05(d). Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Claims 1, 15 and 19 recite further additional elements “a processor”, “a memory”, “a device”, and “storage”. These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Therefore, the additional elements recited in claims 1, 15 and 19 do not integrate the judicial exception into a practical application under prong 2, nor amount to significantly more under step 2B.,
Regarding claims 3, the limitations recited in these claims merely describe the “determining the first side effect”, “determining layers” and “determining side effects”, in each of claims 1, 15 and 19 thus, are likewise analyzed under Prong 1 as mental process.
Regarding claims 4-11 and 16-18, the additional elements of “data structure stores: information about the base layer”, “directed acyclic graph comprising nodes”, “delta layer is represented by an edge”, “delta layer represents a dependency”, “delta storage is represented by an edge”, “delta layer comprises a hierarchy”, “executing the first set of operations”, “storage includes user inputs”, “delta storage includes the side effect”, “receiving a restart command”, “performing the first sequence”, and “performing the second sequence” is analyzed under Prong 2 as mere data gathering which does not integrate the judicial exception into a practical application, or amounts to significantly more under Step 2B for the reasons provided in the rejection of claims 1, 15 and 19.
Regarding claims 12-14 and 20, the limitation “determining a second side effect”, “associating the second delta storage”, “associating the second delta layer”, “associating the third delta layer with the base layer”, “determining a parent layer”, “associating the merged layer”, and “review relationship between layers” recites additional mental process under Prong 1. The additional element “receiving a second update”, “applying the second update”, “recording the second sequence”, “recording the second side effect”, “receiving a third update”, “applying the third update”, “recording the third sequence”, “receiving a command” , “merging the parent layer”, “receive a restart command ”, and “perform operations” is analyzed under Prong 2 as mere data gathering which does not integrate the judicial exception into a practical application, or amounts to significantly more under Step 2B for the reasons provided in the rejection of claims 1, 15 and 19.
Claim Rejections - 35 USC § 102
8. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
9. Claims 1, 3, 10-13, 15 and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Abrams, US 2018/0088926.
In regards to claim 1, Abrams teaches:
A device comprising: a processor; and memory comprising computer executable instructions that, when executed, perform operations comprising: receiving an update to a base layer of the device, wherein the base layer is associated with a persisted storage of a container stored by the device and content of the persisted storage is used as input to the base layer (p. 1, [0003]), see “a request for an updated version of a container image may be received from a client device, the request comprising an identification of a previous version of the container image. A delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
performing a first sequence of operations to apply the update to the base layer; determining a first side effect of the update on the content of the persisted storage (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
recording the first sequence of operations as a delta layer for the base layer (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
recording the first side effect as a delta storage for the persisted storage; associating the delta layer and the persisted storage with the base layer; and associating the delta storage with the persisted storage, such that the content of the persisted storage is used as input to the delta layer (Fig. 9), see “904 compute delta between previous version and updated version of container image, 902 build Updated version of Container Image, 908 Transmit patch to container registry”, (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image” and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer. For example, a binary patch utility such as xdelta3 may be used. The flowchart may then proceed to block 906 to create a patch based on the computed delta. The flowchart may then proceed to block 908 to transmit the patch to a container registry”.
In regards to claim 3, Abrams teaches:
determining the first side effect of the update on the content of the persisted storage comprises (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
determining layers of the content in the persisted storage; and determining side effects of the layers of the content in the persisted storage (p. 4, [0040]), see “in some embodiments, layer deltas may be used to facilitate management and updates of container images. For example, deltas may be calculated between image layers for different versions of the same container image (e.g., using a binary delta calculation), and a patch may then be created based on the delta calculations”.
In regards to claim 10, Abrams teaches:
the delta layer comprises a hierarchy of sequentially applied delta layers (p. 10, [00]), see [0089]), see “in some embodiments, however, the flowchart may restart and/or certain blocks may be repeated. For example, in some embodiments, the flowchart may restart at block 702 in order to continue receiving and processing requests for updated container images” and (Fig. 7), see “702 receive request for updated version of a container image, 704 compute a delta between layers of the previous version of the container image, 706 create patch based on delta”.
In regards to claim 11, Abrams teaches:
executing the first set of operations recorded as the delta layer using the content of the persisted storage as input (Fig. 9), see “904 compute delta between previous version and updated version of container image, 902 build Updated version of Container Image, 908 Transmit patch to container registry”.
In regards to claim 12, Abrams teaches:
receiving a second update to the base layer of the device, wherein the second update includes a second sequence of operations; applying the second update to the base layer by performing the second sequence of operations; determining a second side effect of the update for the base layer and the delta layer; recording the second sequence of operations as a second delta layer of the base layer and the delta layer; recording the second side effect as a second delta storage; associating the second delta storage to the delta storage; and associating the second delta layer to the delta layer (p. 4, [0037]), see thus, in theory, only new layers must be transferred and stored when upgrading to a newer version of an image. In practice, however, there are two problems with transferring only new layers. First, images can become large when many layers are added (e.g., when multiple layers change the same file, that file may be duplicated in each of those layers), so often they are “squashed” into one single layer. For example, when an image includes multiple layers with different versions of the same file, the file must be duplicated for each layer. If a large file in an image is updated 20 times, the image may include separate layers for each update, and thus may contain 20 copies of the file. While the layers may be squashed into a single layer to save space, the squashed image loses the efficiencies of having multiple layers, requiring the entire new image to be transferred to developers using the image) and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer) (emphasis added).
In regards to claim 13, Abrams teaches:
receiving a third update to the base layer; applying the third update to the base layer by performing a third sequence of operations; recording the third sequence of operations as a third delta layer, wherein the third sequence of operations does not have a side effect on the content of the persisted storage; and associating the third delta layer with the base layer (p. 4, [0037]), see “thus, in theory, only new layers must be transferred and stored when upgrading to a newer version of an image. In practice, however, there are two problems with transferring only new layers. First, images can become large when many layers are added (e.g., when multiple layers change the same file, that file may be duplicated in each of those layers), so often they are “squashed” into one single layer. For example, when an image includes multiple layers with different versions of the same file, the file must be duplicated for each layer. If a large file in an image is updated 20 times, the image may include separate layers for each update, and thus may contain 20 copies of the file. While the layers may be squashed into a single layer to save space, the squashed image loses the efficiencies of having multiple layers, requiring the entire new image to be transferred to developers using the image” and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer” (emphasis added).
In regards to claim 15, Abrams teaches:
A computer-implemented method comprising: receiving an update to a base layer of a device, wherein the base layer is associated with a persisted storage of a container stored by the device and content of the persisted storage is used as input to the base layer (p. 1, [0003]), see “a request for an updated version of a container image may be received from a client device, the request comprising an identification of a previous version of the container image. A delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
the base layer includes a first sequence of operations and the persisted storage is a read-only storage (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
performing a second sequence of operations to apply the update to the base layer (p. 4, [0037]), see thus, in theory, only new layers must be transferred and stored when upgrading to a newer version of an image. In practice, however, there are two problems with transferring only new layers. First, images can become large when many layers are added (e.g., when multiple layers change the same file, that file may be duplicated in each of those layers), so often they are “squashed” into one single layer. For example, when an image includes multiple layers with different versions of the same file, the file must be duplicated for each layer. If a large file in an image is updated 20 times, the image may include separate layers for each update, and thus may contain 20 copies of the file. While the layers may be squashed into a single layer to save space, the squashed image loses the efficiencies of having multiple layers, requiring the entire new image to be transferred to developers using the image) and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer) (emphasis added).
determining a side effect of the update on the content of the persisted storage (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
recording the side effect as a delta storage for the persisted storage, the delta storage is a read-write storage; associating the delta layer and the persisted storage with the base layer (Fig. 9), see “904 compute delta between previous version and updated version of container image, 902 build Updated version of Container Image, 908 Transmit patch to container registry”, (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image” and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer. For example, a binary patch utility such as xdelta3 may be used. The flowchart may then proceed to block 906 to create a patch based on the computed delta. The flowchart may then proceed to block 908 to transmit the patch to a container registry” (emphasis added).
recording the second sequence of operations as a delta layer for the base layer (p. 4, [0037]), see thus, in theory, only new layers must be transferred and stored when upgrading to a newer version of an image. In practice, however, there are two problems with transferring only new layers. First, images can become large when many layers are added (e.g., when multiple layers change the same file, that file may be duplicated in each of those layers), so often they are “squashed” into one single layer. For example, when an image includes multiple layers with different versions of the same file, the file must be duplicated for each layer. If a large file in an image is updated 20 times, the image may include separate layers for each update, and thus may contain 20 copies of the file. While the layers may be squashed into a single layer to save space, the squashed image loses the efficiencies of having multiple layers, requiring the entire new image to be transferred to developers using the image) and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer) (emphasis added).
associating the delta storage with the persisted storage, such that the content of the persisted storage is used as input to the delta layer (Fig. 9), see “904 compute delta between previous version and updated version of container image, 902 build Updated version of Container Image, 908 Transmit patch to container registry”, (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image” and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer. For example, a binary patch utility such as xdelta3 may be used. The flowchart may then proceed to block 906 to create a patch based on the computed delta. The flowchart may then proceed to block 908 to transmit the patch to a container registry”.
In regards to claim 18, Abrams teaches:
receiving a restart command for the container; performing the first sequence of operations included in the base layer using content in the persisted storage (p. 10, [00]), see [0089]), see “in some embodiments, however, the flowchart may restart and/or certain blocks may be repeated. For example, in some embodiments, the flowchart may restart at block 702 in order to continue receiving and processing requests for updated container images” and (Fig. 7), see “702 receive request for updated version of a container image, 704 compute a delta between layers of the previous version of the container image, 706 create patch based on delta”.
performing the second sequence of operations included in the delta layer using content in the delta storage (p. 4, [0037]), see thus, in theory, only new layers must be transferred and stored when upgrading to a newer version of an image. In practice, however, there are two problems with transferring only new layers. First, images can become large when many layers are added (e.g., when multiple layers change the same file, that file may be duplicated in each of those layers), so often they are “squashed” into one single layer. For example, when an image includes multiple layers with different versions of the same file, the file must be duplicated for each layer. If a large file in an image is updated 20 times, the image may include separate layers for each update, and thus may contain 20 copies of the file. While the layers may be squashed into a single layer to save space, the squashed image loses the efficiencies of having multiple layers, requiring the entire new image to be transferred to developers using the image) and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer) (emphasis added).
Claim Rejections - 35 USC § 103
10. 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
11. Claims 2 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Abrams in view of Huang et al., U.S. Patent No. 10,303,657 (hereinafter Huang).
In regards to claims 1, the rejections above are incorporated respectively.
In regards to claim 2, Abrams doesn't explicitly teach:
receiving a rollback command for the update; removing an association between the delta storage and the persisted storage; and removing an association between the delta layer and the base layer.
However, Huang teaches such use: (column 8, lines 33-39), see “in this way, a state of the second layer can be restored. As described above, the content of the second part of the data archive contains the difference caused by the third layer. Therefore, the difference may overwrite the files or folders in the target fold and the state of the second layer may be restored to its original state in the image generating process”.
Abrams and Huang are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams and Huang before him or her, to modify the system of Abrams to include the teachings of Huang, as a system for docker layer deduplication, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to eliminate layer duplication, as suggested by Huang (column 5, lines 5-11, column 10, lines 43-54).
In regards to claim 4, Abrams doesn't explicitly teach:
a data structure stores: information about the base layer, the delta layer, the persisted storage, and the delta storage; and relationship information between at least two of the base layer, the delta layer, the persisted storage, and the delta storage.
However, Huang teaches such use: (Fig. 3), see “240 Existing Image, 241 A, 241 B, 250 new Image, 244 C, 243 B), (column 5, lines 5-11), see “as described above, each of the instructions stored in the configuration file 230 may create a layer in the image 250… duplicated layers will be introduced during the image generating phase because the layers within the image are overlays in a single inheritance tree”, (column 4, lines 60-67), see “in execution of each of the instructions, an intermediate container may be created so that the instruction is run inside the intermediate container. In this way, the intermediate container may contain all changes that need to be made to the underlying layers. Then a copy of the intermediate container is committed to an
image” and (column 5, lines 13-25), see “as shown in FIG. 3, the existing image 240 includes Layer A 241 and Layer B 242, where Layer A 241 is assumed to be created prior to Layer B 242. The instructions stored in the configuration file 230 indicate that the layers to be created in sequence in the image 250 are Layer A, Layer C and Layer B. Due to the single-inheritance layering model, the image 250 will share Layer A 241 with the existing image 240, but a new copy of Layer B will be created in the image 250. That is because the base layer of Layer B 243 in the image 250 is Layer C 244, which is different from the base layer of Layer B 242 in the existing image 240. As a result, two copies of Layer B will be created, which may cause a waste of disk space”.
Abrams and Huang are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams and Huang before him or her, to modify the system of Abrams to include the teachings of Huang, as a system for docker layer deduplication, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to eliminate layer duplication, as suggested by Huang (column 5, lines 5-11, column 10, lines 43-54).
12. Claims 5-9 are rejected under 35 U.S.C. 103 as being unpatentable over Abrams in view of Huang in view of Lo et al., U.S. Patent No. 5,857,207 (hereinafter Lo).
In regards to claims 1 and 4 the rejections above are incorporated accordingly.
In regards to claim 5, Abrams and Huang, in particular Abrams doesn't explicitly teach:
the data structure is a directed acyclic graph comprising nodes representing the base layer, the delta layer, the persisted storage, and the delta storage.
However, Lo teaches such use: (Abstract), see “elements can also be Compound Types, which nestably refer to another list of Properties. Blops are stored in Containers, which map to the physical medium on which the data is stored. Containers associate respective Container Handlers which are specific to the Container's physical medium. Related Blops in a Container are organized into Pools of Blops. Each Container contains one or more Pools, each Pool having a unique name within the Container. A Pool contains multiple versions of a Blop. Versions of different Blops are grouped together in Layers in a Pool and each Layer contains at most one version of a Blop. Layers are related to each other as an acyclic digraph, where each Layer is above one or more Base Layers” and (column 6, lines 36-42), see “the data structure can also include Pools which are referred to herein as Delta Pools, which allow several Pools to behave as if they were a single Pool. In a Delta Pool, the Bottom Layer is actually derived from a Layer in a Base Pool. Thus the Layers in the Delta Pool appear as a continuation of the Layers in the Base Pool. FIG. 4 symbolically illustrates an example of how the Layers in a Delta Pool and its Base Pool might be related” (emphasis added).
Abrams, Huang and Lo are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams, Huang and Lo before him or her, to modify the system of Abrams and Lo, in particular Abrams, to include the teachings of Lo, as a system for storage management, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to provide greater flexibility in the support of optimistic concurrency in the maintenance of data, as suggested by Lo (column 6, lines 36-42, column 74, lines 43-56).
In regards to claim 6, Abrams and Huang, in particular Abrams doesn't explicitly teach:
a relationship between the base layer and the delta layer is represented by an edge connecting a node of the base layer to a node of the delta layer.
However, Lo teaches such use: (Fig. 4), see arrow from “402 Base Pool, 404 Delta Pool”.
Abrams, Huang and Lo are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams, Huang and Lo before him or her, to modify the system of Abrams and Lo, in particular Abrams, to include the teachings of Lo, as a system for storage management, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to provide greater flexibility in the support of optimistic concurrency in the maintenance of data, as suggested by Lo (column 6, lines 36-42, column 74, lines 43-56).
In regards to claim 7, Abrams and Huang, in particular Abrams doesn't explicitly teach:
a direction of the edge connecting the node of the base layer to the node of the delta layer represents a dependency between the base layer and the delta layer.
However, Lo teaches such use: (Fig. 4), see arrow from “402 Base Pool, 404 Delta Pool” and (column 6, lines 37-43), see “in a Delta Pool, the Bottom Layer is actually derived from a Layer in a Base Pool. Thus the Layers in the Delta Pool appear as a continuation of the Layers in the Base Pool. FIG. 4 symbolically illustrates an example of how the Layers in a Delta Pool and its Base Pool might be related” (emphasis added).
Abrams, Huang and Lo are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams, Huang and Lo before him or her, to modify the system of Abrams and Lo, in particular Abrams, to include the teachings of Lo, as a system for storage management, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to provide greater flexibility in the support of optimistic concurrency in the maintenance of data, as suggested by Lo (column 6, lines 36-42, column 74, lines 43-56).
In regards to claim 8, Abrams and Huang, in particular Abrams doesn't explicitly teach:
a relationship between the persisted storage and the delta storage is represented by an edge connecting a node of the persisted storage to a node of the delta storage.
However, Lo teaches such use: (Fig. 4), see arrow from “402 Base Pool, 404 Delta Pool” and (column 6, lines 37-43), see “in a Delta Pool, the Bottom Layer is actually derived from a Layer in a Base Pool. Thus the Layers in the Delta Pool appear as a continuation of the Layers in the Base Pool. FIG. 4 symbolically illustrates an example of how the Layers in a Delta Pool and its Base Pool might be related” (emphasis added).
Abrams, Huang and Lo are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams, Huang and Lo before him or her, to modify the system of Abrams and Lo, in particular Abrams, to include the teachings of Lo, as a system for storage management, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to provide greater flexibility in the support of optimistic concurrency in the maintenance of data, as suggested by Lo (column 6, lines 36-42, column 74, lines 43-56).
In regards to claim 9, Abrams and Huang, in particular Abrams doesn't explicitly teach:
a direction of the edge connecting the node of the persisted storage to the node of the delta storage represents a dependency between the persisted storage and the delta storage.
However, Lo teaches such use: (Fig. 4), see arrow from “402 Base Pool, 404 Delta Pool” and (column 6, lines 37-43), see “in a Delta Pool, the Bottom Layer is actually derived from a Layer in a Base Pool. Thus the Layers in the Delta Pool appear as a continuation of the Layers in the Base Pool. FIG. 4 symbolically illustrates an example of how the Layers in a Delta Pool and its Base Pool might be related” (emphasis added).
Abrams, Huang and Lo are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams, Huang and Lo before him or her, to modify the system of Abrams and Lo, in particular Abrams, to include the teachings of Lo, as a system for storage management, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to provide greater flexibility in the support of optimistic concurrency in the maintenance of data, as suggested by Lo (column 6, lines 36-42, column 74, lines 43-56).
13. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Abrams in view of Liu et al., U.S. 2023/0098841 (hereinafter Liu).
In regards to claims 1, the rejections above are incorporated respectively.
In regards to claim 14, Abrams doesn't explicitly teach:
receiving a command to merge layers of the device; determining a parent layer of the device that is not associated with a storage of the container; merging the parent layer with a dependent layer to form a merged layer, wherein the dependent layer is associated with a dependent storage that includes a side effect of the persisted storage; and associating the merged layer with the storage associated with the dependent layer.
However, Liu teaches such use: (Fig. 1), see “File system 104, Platform-Independent later 120, Base Layer 116), ((p. 40, [0039]), see “layer management module 110 may share multiple platform-independent layers and platform-dependent layers onto a container image”, (p. 5, [0036]), see “layer management module 110 operates to generate an initial layer of file system 104. The initial layer may be a platform-dependent base layer. Layer management module 110 also operates to assign files associated with the initial layer with a group identification as a same group in file registry 114 for a plurality of platforms 106. Layer management module 110 operates to generate a new layer based on base layer 116 into file system 104. Layer management module 110 operates to mark a new layer as being platform-independent in file registry 114 in response that the new layer is platform-independent” and (p. 3, [0020]), see “an image may also include, or be associated with, meta-data describing the image itself, or describing components (e.g., layers) of the image. For example, an image may include a header describing a layer within the image, such as the name of the layer and the location of that layer within the image. Meta-data for an image may indicate the relationships of the layers within the image, such as which layer precedes another layer, from the bottom to the top of a hierarchical stack of layers within the image”.
Abrams and Liu are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams and Liu before him or her, to modify the system of Abrams to include the teachings of Liu, as a system for classifying a file system, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to classify and store multiple layers of a file system as platform-dependent and platform-independent layers.as suggested by Liu (p. 5, [0036]), p. 9, [0086]).
14. Claims 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Abrams in view of Thomason et al., U.S. Patent No. 10,140,159 (hereinafter Thomason).
In regards to claims 1, the rejections above are incorporated respectively.
In regards to claim 16, Abrams doesn't explicitly teach:
the persisted storage includes user inputs to the container.
However, Thomason teaches such use: (Abstract), see “determining a base state of a particular container, wherein the base state is represented by a base image. The method further includes determining a target state of the particular container, wherein the target state is represented by a deployment of the particular container. In addition, the method includes determining a set of commands to transition from the base state to the target state. Further, the method includes generating a manifest for the target state of the particular container, the manifest comprising the determined set of commands to reach the target state”, (column 10, last para.), see “at block 306, the manifest generator 149 determines a set of commands to transition the particular container from the base state to the target state. In an example, as part of the block 306, the manifest generator 149 can determine user commands that were previously executed in relation to the base state in order to reach the target state” and (column 6, first para.), see “FIG. 3, the manifest generator 149 can determine commands to transition a container from a base state to a target state. The manifest generator 149 can generate a manifest that includes the determined commands as part of the manifest. In that way, when the container is deployed using the generated manifest, the container can be deployed in its target state. An example will be described in relation to FIG. 3”.
Abrams and Thomason are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams and Thomason before him or her, to modify the system of Abrams to include the teachings of Thomason, as a system for dynamic creation of container manifests, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to allocate finite hardware resources among multiple users, as suggested by Thomason (column 10, last para, column 13, lines 20-33).
In regards to claim 17, Abrams doesn't explicitly teach:
the delta storage includes the side effect to maintain the user inputs in the persisted storage.
However, Thomason teaches such use: (Abstract), see “determining a base state of a particular container, wherein the base state is represented by a base image. The method further includes determining a target state of the particular container, wherein the target state is represented by a deployment of the particular container. In addition, the method includes determining a set of commands to transition from the base state to the target state. Further, the method includes generating a manifest for the target state of the particular container, the manifest comprising the determined set of commands to reach the target state”, (column 10, last para.), see “at block 306, the manifest generator 149 determines a set of commands to transition the particular container from the base state to the target state. In an example, as part of the block 306, the manifest generator 149 can determine user commands that were previously executed in relation to the base state in order to reach the target state” and (column 6, first para.), see “FIG. 3, the manifest generator 149 can determine commands to transition a container from a base state to a target state. The manifest generator 149 can generate a manifest that includes the determined commands as part of the manifest. In that way, when the container is deployed using the generated manifest, the container can be deployed in its target state. An example will be described in relation to FIG. 3”.
Abrams and Thomason are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams and Thomason before him or her, to modify the system of Abrams to include the teachings of Thomason, as a system for dynamic creation of container manifests, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to allocate finite hardware resources among multiple users, as suggested by Thomason (column 10, last para, column 13, lines 20-33).
15. Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Abrams in view of Lo et al., U.S. Patent No. 5,857,207 (hereinafter Lo).
In regards to claim 19, Abrams teaches:
A system comprising: a processor; and memory comprising computer executable instructions that, when executed, perform operations comprising: receiving an update to a base layer of a device, wherein the base layer is associated with a persisted storage of a container stored by the device and content of the persisted storage is used as input to the base layer (p. 1, [0003]), see “a request for an updated version of a container image may be received from a client device, the request comprising an identification of a previous version of the container image. A delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
applying a sequence of operations to the base layer to update the base layer (p. 4, [0037]), see thus, in theory, only new layers must be transferred and stored when upgrading to a newer version of an image. In practice, however, there are two problems with transferring only new layers. First, images can become large when many layers are added (e.g., when multiple layers change the same file, that file may be duplicated in each of those layers), so often they are “squashed” into one single layer. For example, when an image includes multiple layers with different versions of the same file, the file must be duplicated for each layer. If a large file in an image is updated 20 times, the image may include separate layers for each update, and thus may contain 20 copies of the file. While the layers may be squashed into a single layer to save space, the squashed image loses the efficiencies of having multiple layers, requiring the entire new image to be transferred to developers using the image) and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer) (emphasis added).
determining a side effect of the update on the content of the persisted storage (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
recording the sequence of operations as a delta layer of the base layer in a graph (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image”.
recording the side effect as a delta storage of the persisted storage in the graph (Fig. 9), see “904 compute delta between previous version and updated version of container image, 902 build Updated version of Container Image, 908 Transmit patch to container registry”, (p. 1, [0003]), see “a delta may be determined between container layers of the previous version of the container image and the updated version of the container image” and (p. 11, [0096]), see “the flowchart may begin at block 902 by building an updated version of a container image. The flowchart may then proceed to block 904 to compute a delta between layers of the previous version of the container image and the updated version of the container image. In some embodiments, for example, a binary delta or binary difference calculation may be used to calculate the difference between each layer. For example, a binary patch utility such as xdelta3 may be used. The flowchart may then proceed to block 906 to create a patch based on the computed delta. The flowchart may then proceed to block 908 to transmit the patch to a container registry”.
Abrams doesn't explicitly teach:
the delta layer and the base layer are first set of nodes in the graph and the first set of nodes are connected by a first edge.
However, Lo teaches such use: (Abstract), see “elements can also be Compound Types, which nestably refer to another list of Properties. Blops are stored in Containers, which map to the physical medium on which the data is stored. Containers associate respective Container Handlers which are specific to the Container's physical medium. Related Blops in a Container are organized into Pools of Blops. Each Container contains one or more Pools, each Pool having a unique name within the Container. A Pool contains multiple versions of a Blop. Versions of different Blops are grouped together in Layers in a Pool and each Layer contains at most one version of a Blop. Layers are related to each other as an acyclic digraph, where each Layer is above one or more Base Layers” and (column 6, lines 36-42), see “the data structure can also include Pools which are referred to herein as Delta Pools, which allow several Pools to behave as if they were a single Pool. In a Delta Pool, the Bottom Layer is actually derived from a Layer in a Base Pool. Thus the Layers in the Delta Pool appear as a continuation of the Layers in the Base Pool. FIG. 4 symbolically illustrates an example of how the Layers in a Delta Pool and its Base Pool might be related” (emphasis added).
the delta storage and the persisted storage are second set of nodes in the graph and the second set of nodes are connected by a second edge.
However, Lo teaches such use: (Fig. 5), see arrows from 506 Base Pool L1, 504 Separable Pool 502, Base Pool L3, L1, 508 Separable Pool L2).
Abrams and Lo are analogous art because they are from the same field of endeavor, software updating.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Abrams and Lo before him or her, to modify the system of Abrams to include the teachings of Lo, as a system for storage management, and accordingly it would enhance the system of Abrams, which is focused on container image management, because that would provide Abrams with the ability to provide greater flexibility in the support of optimistic concurrency in the maintenance of data, as suggested by Lo (column 6, lines 36-42, column 74, lines 43-56).
In regards to claim 20, Abrams teaches:
receive a restart command for the container; review relationship between layers in the graph to determine a hierarchy of layers; and perform operations included in each layer of the hierarchy of layers in a sequential manner using content of storage associated with the each layer (p. 10, [00]), see [0089]), see “in some embodiments, however, the flowchart may restart and/or certain blocks may be repeated. For example, in some embodiments, the flowchart may restart at block 702 in order to continue receiving and processing requests for updated container images” and (Fig. 7), see “702 receive request for updated version of a container image, 704 compute a delta between layers of the previous version of the container image, 706 create patch based on delta”.
Conclusion
16. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Application Publications
Sekar 12282758 teaches containerization systems and methods that The method includes deploying an initial container image associated with a startup script, a pre-service script and post-service script. This deployment Further, the method includes executing the startup script associated with the initial container image, and the executing including copying configuration information for the initial container image into a volume and generating a marker file for the initial container image. The containerization systems and methods The method also includes deploying a main container image associated with a startup script.
Picco 12288053 teaches providing an enhanced codebase in a computing environment, by one or more processors, is depicted. One or more container specification files may be automatically created and updated with one or more changes to a codebase.
17. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Evral Bodden whose telephone number is 571-272-3455. The examiner can normally be reached on Monday to Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Cha Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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) Form at https://www.uspto.gov/patents/uspto-automatedinterview-request-air-form.
If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EVRAL E BODDEN/ Primary Examiner, Art Unit 2193
Prosecution Insights