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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a scheduling module configured to in claim 13
a communication module configured to in claim 13
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim 13 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 limitation(s) “a scheduling module configured to initialize a pool of a plurality of containers …” and “a communication module configured to receive a request to deploy or scale the user application” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not provide any structure for performing the claimed functions. There is no disclosure of any particular structure, either explicitly or inherently, to perform the initializing and receiving of the scheduling and communication modules respectively. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 13 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. As described above, the disclosure does not provide structure to perform the claimed functions of initializing a pool of a plurality of containers and receiving a request to deploy or scale the user application of the scheduling and communication modules respectively. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 4, 7, 9-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Demystifying Fission - Pool Manager | Fission” (hereinafter referred to as Fission) in view of US 12443424 B1 (hereinafter referred to as Featonby) further in view of “In-place Update of Pod Resources” (hereinafter referred to as Kubernetes).
As per claim 1 – teaches a method for deploying or scaling a user application in a container execution system comprising a plurality of nodes, the method comprising:
PNG
media_image1.png
77
953
media_image1.png
Greyscale
initializing a pool of a plurality of containers running on one or more of the nodes (Pool Manager- It keeps a constant check on environment CRD changes and proactively creates generic pools for environments – [“PoolSize”]), each of the plurality of containers of the pool having compute resources specified at a first lower level (To give you greater control over resource usages for all functions in the same environment, you can also set CPU and memory flags. The below snippet limits the min/max cpu to 100 m/200 m, and min/max memory to 128Mi/256Mi respectively. (The CPU limit is in miliCPU);
– [“PoolSize”]; The –mincpu and –minmemory values define the lower level of compute resources each container will use when in an idle (not actively running a user application) state).
Fission does not teach the following limitations of the claim. However, Featonby, in an analogous art, teaches them as can be seen in the in-line citations below:
receiving a request for deploying or scaling up the user application; determining one or more scaling parameters based on the received request (The routine 200 begins at block 202, at which the container service 140 receives a request to execute a user code on a compute instance provided by the cloud provider network 120. The request may include or indicate one or more of: (i) a user code to be executed by the container service 140, (ii) a capacity configuration requested for executing the user code, (iii) whether the user code is to be executed using compute capacity assigned to the user of the user code or on-demand/serverless compute capacity provided by the cloud network provider 120, (iv) configuration parameters to be used to execute the user code (e.g., arguments to be inputted to the user code, network settings to be configured, etc.), (v) location of the user code, and the like – [54]; A capacity configuration requested for executing the user code corresponds to “scaling parameters”); selecting one of the nodes, the selected node having sufficient additional compute resources for running another instance of the user application; selecting one of the containers of the pool running on the selected node; scaling up the selected container without restarting the container (taught in further reference), by increasing the compute resources specified for the selected container to a second higher level to generate a second scaled-up container, wherein the scaling is based on the one or more scaling parameters; and running the user application in the newly scaled-up container on the selected node (At block 204, the container service 140 determines whether there is a compute instance in an existing pool that can be used to execute the user code. If the container service 140 determines that there is a compute instance that can be used, the routine 200 proceeds to block 206, where the container service 140 executes the user code on a pre-warmed compute instance from the existing pool – [55]; The container service determining a compute instance capable of running the user code corresponds to the process of selecting a container of the pool that has additional compute resources to run the user application. Executing the user code on a pre-warmed compute instance corresponds to “increasing the compute resources … scaling is based on one or more scaling parameters”).
Therefore, all of the elements of claim 1 addressed insofar are taught by either Fission or Featonby. The only difference is the combination of the minimal compute resource container pool of Fission with the process of determining a container of the pool to execute the user application on. It would have been obvious to one of ordinary skill in the art to simply apply the process of choosing a container with sufficient resources from the pool to run the user application on to the system governing the minimal compute resource container pool to yield the predictable result of a containerization system that initializes minimal resource container that can be used to perform user applications.
The combination of Fission and Featonby does not teach the last limitation claim 1. However, Kubernetes, in an analogous art, teaches them as can be seen in the in-line citations below:
scaling up the selected container without restarting the container (This proposal aims at allowing Pod resource requests & limits to be updated in-place, without a need to restart the Pod or its Containers – [“Summary”]; In-place requests & limits updates correspond to “without restarting the container”).
Therefore, all of the elements of claim 1 are taught by either Featonby, Fission, or Kubernetes. The only difference between the prior art and the claimed invention is the addition of the in-place scaling functionality to the combination or Fission and Featonby. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine these ideas because of the motivation mentioned in the Kubernetes reference: “Currently, changing resource allocation requires the Pod to be recreated since the PodSpec's Container Resources is immutable.
While many stateless workloads are designed to withstand such a disruption, some are more sensitive, especially when using low number of Pod replicas. Moreover, for stateful or batch workloads, Pod restart is a serious disruption, resulting in lower availability or higher cost of running. Allowing Resources to be changed without recreating the Pod or restarting the Containers addresses this issue directly.” (Kubernetes, “Motivation”).
Claim(s) 2-3, 5-6, 8, and 13-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fission in view of Featonby further in view of Kubernetes further in view of US 11137924 B2 (hereinafter referred to as Sterin).
As per claim 2 – The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. It does not teach the limitations of claim 2. However, Sterin, in an analogous art, teaches them as can be seen in the in-line citations below:
mounting a container filesystem of a shared filesystem to each of the plurality of containers of the pool (Embodiments presented herein provide a scalable and highly available distributed file storage system that permits containerized applications running in distinct container hosts, such as virtual machines (VMs), to simultaneously read/write to the same storage volume, such as the same block device – [col 2; lines 37-42]; A file storage system that allows for multiple containers running on separate host VMS to utilize a shared storage volume teaches the essential concept of mounting a shared storage volume to containers).
Therefore, all of the elements of claim 2 are addressed by either the aforementioned combination of Fission, Andrianov, Kubernetes or Sterin. The only difference is the combination of the shared container storage system of Sterin with the minimal resource container pool system of Fission, Andrianov and Kubernetes. It would have been obvious to one of ordinary skill in the art to apply the technique of mounting a shared storage volume to each of the containers of the pool because of the explicitly mentioned benefit of the shared volumes providing a “scalable and highly available distributed file storage system that permits containerized applications running on distinct container hosts, such as virtual machines (VMs), to simultaneously read/write to the same storage volume, such as the same block device” in Sterin.
As per claim 3 - The combination of Fission, Featonby, Kubernetes, and Sterin teach the method of claim 2. Fission additionally teaches:
wherein the filesystems mounted to each of the plurality of containers of the pool do not contain program code for the user application (Pool Manager- It keeps a constant check on environment CRD changes and proactively creates generic pools for environments. When a request comes in, the Pool Manager with the help of fetcher loads the function in one of these pods – [“PoolSize”]; Creating generic pools means creating containers that aren’t specialized for any application/function until they are needed to fulfill requests).
As per claim 4 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. Featonby additionally teaches:
wherein the request for deploying or scaling up the user application includes data comprising program code for the user application and associated data for running the user application in one of the containers (The request may include or indicate one or more of: (i) a user code to be executed by the container service … configuration parameters to be used to execute the user code (e.g., arguments to be inputted to the user code, network settings to be configured, etc.) – [col 15; lines 12-21] configuration parameters correspond to “associated data for running the user application”).
As per claim 5 - The combination of Fission, Featonby and Kubernetes teach the method of claim 1. Sterin additionally teaches:
running a first scaled-up container on a node of the container execution system before the request is received, wherein a first container filesystem containing program code for the user application and associated data for running the user application is mounted to the first scaled-up container; and mounting the first container filesystem to the newly scaled-up container (See Fig. 5; The process of mounting an already mounted filesystem to other containers teaches “mounting the first container filesystem to the newly scaled-up container”).
As per claim 6 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. Sterin additionally teaches:
further comprising: running a first scaled-up container on a node of the container execution system before the request is received, wherein a first container filesystem containing program code for the user application and associated data for running the user application is mounted to the first scaled-up container; and mounting the first container filesystem to each container of the pool before the request is received (See Fig. 5; The process of mounting an already mounted filesystem to other containers teaches “mounting the first container filesystem to each container of the pool before the request is received”).
As per claim 7 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. Fission additionally teaches:
wherein the containers of the pool are generated from a single base container image (Pool Manager- It keeps a constant check on environment CRD changes and proactively creates generic pools for environments – [section “PoolSize”]; The containers of the generic pools are generic themselves, which corresponds to “single base container image”).
As per claim 8 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. Sterin additionally teaches:
wherein the pool of containers comprises a dedicated pool of containers wherein each container of the dedicated pool is mounted to a corresponding container filesystem of a shared filesystem (See Fig. 5; The process of mounting an already mounted filesystem to other containers teaches mounting containers of a dedicated pool to a scaled-up filesystem), and a general pool of containers wherein each container of the general pool is not mounted to a filesystem
As per claim 9 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. Fission additionally teaches:
PNG
media_image1.png
77
953
media_image1.png
Greyscale
wherein the compute resources specified for the containers of the pool are less than the compute resources needed to run the user application (
– [section “PoolSize”]; --mincpu/men defines a lower level of resources not sufficient for running applications/workloads. –maxcpu/mem defines a higher level of compute resource that a container can flexibly scale to in order to run user applications/workloads).
As per claim 10 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. Fission additionally teaches:
wherein the containers of the pool do not include the user application (Pool Manager- It keeps a constant check on environment CRD changes and proactively creates generic pools for environments. When a request comes in, the Pool Manager with the help of fetcher loads the function in one of these pods – [section “PoolSize”]; Containers of the generic pools are not specialized for any application/workload and, therefore, do not store any instructions for running the user application).
As per claim 11 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. Featonby additionally teaches:
wherein the containers of the pool omit at least a portion of the runtime environment required for running the user application (The request may include or indicate one or more of: (i) a user code to be executed by the container service … configuration parameters to be used to execute the user code (e.g., arguments to be inputted to the user code, network settings to be configured, etc.) – [col 15; lines 12-21]; The request for running the user code containing configuration parameters, which correspond to “runtime environment”, proves that the containers of the pool lacked a “runtime environment required for running the user application”)
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fission in view of Featonby further in view of Kubernetes further in view of US 20190163536 A1 (hereinafter referred to as Parees).
As per claim 12 - The combination of Fission, Featonby, and Kubernetes teach the method of claim 1. However, it does not teach the limitations of claim 12. Parees, in an analogous art, teaches them as can be seen in the in-line citations below.
wherein the scaling parameters are based on one or more of the user application size, minimum compute resources for a container running the user application, maximum compute resources for a container running the user application minimum replica counts for containers running the user application, and/or maximum replica counts for containers running the user application (As an example, if using a Java virtual machine application 32, if the resource usage metrics 40 indicate that heap memory usage+non-heap memory usage was consistently above 90% of the memory available to the first container 22-1, then an optimized container resource constraint value 24-2 may increase the amount of memory for the second container 22-2 by 20%. If the resource usage metrics 40 indicate that the CPU utilization is consistently >90%, an optimized container resource constraint value 24-2 may increase the available processing power of the container 22-2 by 25% - [0035]; scaling up a new container based on CPU/memory usage metrics corresponds to the Applicant’s “scaling parameters”).
Therefore, all of the elements of claim 12 are addressed by the combination of Fission, Featonby, and Kubernetes or Parees. The only difference is the combination between the claimed invention and the prior art is the utilization of the specific scaling parameters taught in Parees with the overall minimal compute resource pool taught through the combination of Fission, Featonby, and Kubernetes. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the these teachings to yield the predictable result of a minimal compute resource pool allocation system that allocates resources based on well-known metrics that define how much compute resources a computer application needs.
As per claim 13 – Featonby teaches a system for deploying or scaling a user application, the system comprising:
a container execution system comprising a plurality of nodes each node configured to run one or more user applications in one or more containers (FIG. 1 depicts an example computing environment 100 including a cloud provider network 120 in which the disclosed container service can be implemented. A cloud provider network (sometimes referred to as a cloud provider system or simply a “cloud”) refers to a large pool of network-accessible computing resources (such as compute, storage, and networking resources, applications, and services), which may be virtualized (e.g., virtual machines) or bare-metal (e.g., bare-metal instances or physical machines). The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands – [col 3; lines 54-63]; The cloud computing environment providing computing resources to users corresponds to “configured to run one or more user applications in one or more containers”).
and a container orchestration system comprising: a scheduling module configured to initialize a pool of a plurality of containers running on one or more of the nodes of the container execution system (The container service 140 provides a generational pool manager 142, a warm pool 143, and an active pool 146 – [col 4; lines 29-30]; The container service providing a warm pool and an active pool corresponds to “initializing a pool … container execution system”).
a communication module configured to receive a request to deploy or scale the user application (When a code execution request is received, the generational pool manager 142 may select an appropriate compute instance from the warm pool 143 – [col. 4; lines 52-54]; This demonstrates the functionality of receiving a request to run user applications).
and a vertical scaling module configured to, in response to receiving the request, select one of the nodes and one of the containers of the pool running on the selected node (At block 204, the container service 140 determines whether there is a compute instance in an existing pool that can be used to execute the user code – [col. 15; lines 22-24]; This demonstrates the functionality of selected a container of the pool able to run the user application).
and to scale up the selected container without restarting the container by increasing the compute resources specified for the selected container to a second higher level to generate a scaled-up container, wherein the scaling is based on one or more scaling parameters based on the request; and wherein the selected node is configured to run the user application in the scaled-up container (At block 204, the container service 140 determines whether there is a compute instance in an existing pool that can be used to execute the user code. If the container service 140 determines that there is a compute instance that can be used, the routine 200 proceeds to block 206, where the container service 140 executes the user code on a pre-warmed compute instance from the existing pool – [55]; The container service determining a compute instance capable of running the user code corresponds to the process of selecting a container of the pool that has additional compute resources to run the user application. Executing the user code on a pre-warmed compute instance corresponds to “increasing the compute resources … scaling is based on one or more scaling parameters”).
Featonby does not teach the following limitations of claim 13. However, Sterin, in an analogous art teaches them as can be seen in the in-line citations below:
a shared filesystem comprising one or more container filesystems for storing program code for the user application, and associated data for running the user application in one of the containers (Embodiments presented herein provide a scalable and highly available distributed file storage system that permits containerized applications running in distinct container hosts, such as virtual machines (VMs), to simultaneously read/write to the same storage volume, such as the same block device – [col 2; lines 37-42]; A file storage system that allows for multiple containers running on separate host VMS to utilize a shared storage volume teaches the essential concept of mounting a shared storage volume to containers).
The combination of Featonby and Sterin does not teach the following limitations. However, Fission, in an analogous art, teaches them as can be seen in the in-line citations below:
PNG
media_image1.png
77
953
media_image1.png
Greyscale
each container of the pool having compute resources specified at a first lower level (To give you greater control over resource usages for all functions in the same environment, you can also set CPU and memory flags. The below snippet limits the min/max cpu to 100 m/200 m, and min/max memory to 128Mi/256Mi respectively. (The CPU limit is in miliCPU) – [section “PoolSize”]; The –mincpu and –minmemory values define the lower level of compute resources each container will use when in an idle (not actively running a user application) state).
The combination of Featonby, Fission, and Sterin does not teach the last limitation claim 1. However, Kubernetes, in an analogous art, teaches them as can be seen in the in-line citations below:
scaling up the selected container without restarting the container (This proposal aims at allowing Pod resource requests & limits to be updated in-place, without a need to restart the Pod or its Containers – [“Summary”]; In-place requests & limits updates correspond to “without restarting the container”).
As per claim 14 – The combination of Featonby, Sterin, Fission, and Kubernetes teach the system of claim 13. Fission additionally teaches:
further comprising: wherein the container filesystems mounted to the containers of the pool do not contain program code for the user application (Pool Manager- It keeps a constant check on environment CRD changes and proactively creates generic pools for environments. When a request comes in, the Pool Manager with the help of fetcher loads the function in one of these pods – [section “PoolSize”]; Creating generic pools means creating containers that aren’t specialized for any application/function until they are needed to fulfill requests).
As per claim 15 – The combination of Featonby, Sterin, Fission, and Kubernetes teach the system of claim 13. Sterin additionally teaches:
further comprising: wherein a single container filesystem is mounted to the containers of the pool, wherein the container filesystem contains program code for the user application (See Fig. 5; The process of mounting an already mounted filesystem to other containers teaches “mounting the first container filesystem to each container of the pool before the request is received”).
As per claim 16 – The combination of Featonby, Sterin, Fission, and Kubernetes teach the system of claim 13. Fission additionally teaches:
wherein the scheduling module is configured to generate the plurality of containers of the pool from a single base container image (Pool Manager- It keeps a constant check on environment CRD changes and proactively creates generic pools for environments – [section “PoolSize”]; The containers of the generic pools are generic themselves, which corresponds to “single base container image”).
As per claim 17 – The combination of Featonby, Sterin, Fission, and Kubernetes teach the system of claim 13. Fission additionally teaches:
PNG
media_image1.png
77
953
media_image1.png
Greyscale
wherein the compute resources specified for the containers of the pool are less than the compute resources needed to run the user application (
– [section “PoolSize”]; --mincpu/men defines a lower level of resources not sufficient for running applications/workloads. –maxcpu/mem defines a higher level of compute resource that a container can flexibly scale to in order to run user applications/workloads).
As per claim 18 – The combination of Featonby, Sterin, Fission, and Kubernetes teach the system of claim 13. Fission additionally teaches:
wherein the containers of the pool do not include the user application (Pool Manager- It keeps a constant check on environment CRD changes and proactively creates generic pools for environments. When a request comes in, the Pool Manager with the help of fetcher loads the function in one of these pods – [section “PoolSize”]; Creating generic pools means creating containers that aren’t specialized for any application/function until they are needed to fulfill requests).
As per claim 19 – The combination of Featonby, Sterin, Fission, and Kubernetes teach the system of claim 13. Featonby additionally teaches:
wherein the containers of the pool omit at least a portion of the runtime environment required for running the user application (The request may include or indicate one or more of: (i) a user code to be executed by the container service … configuration parameters to be used to execute the user code (e.g., arguments to be inputted to the user code, network settings to be configured, etc.) – [col 15; lines 12-21]; The request for running the user code containing configuration parameters, which correspond to “runtime environment”, proves that the containers of the pool lacked a “runtime environment required for running the user application”)
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fission in view of Featonby further in view of Kubernetes further in view of Sterin further in view of Parees.
As per claim 20 - The combination of Featonby, Sterin, Fission, and Kubernetes teach the system of claim 13. Parees additionally teaches:
wherein the scaling parameters are based on one or more of the user application size, minimum compute resources for a container running the user application, maximum compute resources for a container running the user application minimum replica counts for containers running the user application, and/or maximum replica counts for containers running the user application (As an example, if using a Java virtual machine application 32, if the resource usage metrics 40 indicate that heap memory usage+non-heap memory usage was consistently above 90% of the memory available to the first container 22-1, then an optimized container resource constraint value 24-2 may increase the amount of memory for the second container 22-2 by 20%. If the resource usage metrics 40 indicate that the CPU utilization is consistently >90%, an optimized container resource constraint value 24-2 may increase the available processing power of the container 22-2 by 25% - [0035]; scaling up a new container based on CPU/memory usage metrics corresponds to the Applicant’s “scaling parameters”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Morano (US 20250272013 A1) discusses temporary storage volumes that can be mounted to one or more containers of a pod.
Aithal (US 11573814 B1) teaches sharing image layers between containers.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH MAXEN LANE whose telephone number is (571)272-8027. The examiner can normally be reached M-F from 7:30 A.M. - 5 P.M..
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, April Y. Blair can be reached at (571) 270-1014. 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.
/JOSEPH MAXEN LANE/Examiner, Art Unit 2196
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights