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 .
This Office Action is in response to claims filed 03/07/2024.
Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1-2, 12, and 20 declare “a service level agreement violation” multiple times. It is unclear if these are referring to the same or different instances of “a service level agreement violation”.
For the purposes of compact prosecution, Examiner will interpret additional instances of “a service level agreement violation” as the same “a service level agreement violation” initially declared in independent Claims.
Claim 2 recites “a violation threshold”. It is unclear whether this is same or different instance of “a violation threshold” as the one declared in Claim 1.
For the purposes of compact prosecution, Examiner will interpret “a violation threshold” as referring to the same “a violation threshold” in Claim 1.
Claim 4 and 15 recite “a node”. It is unclear whether this is same or different instance of “a node” as the one declared in Claims 1 and 12.
For the purposes of compact prosecution, Examiner will interpret “a node” as referring to the same “a node” in Claims 1 and 12.
Claim 5 and 16 recite “a determination”. It is unclear whether this is same or different instance of “a determination” as the one declared in Claims 4 and 15.
For the purposes of compact prosecution, Examiner will interpret “a determination” as referring to the same “a determination” in Claims 4 and 15.
Claim 10 recites “the carbon emission categories” and “the categories”. There is insufficient antecedent basis for this limitation in the claim.
For the purposes of compact prosecution, Examiner will interpret “the carbon emission categories” and “the categories” as referring to “emission categories” earlier in Claim 10.
Claim 20 recites “a request” and “the request”. It is unclear whether this is same or different instance of “a request” as the one declared earlier in Claim 20. Subsequently, it is unclear which “a request” that “the request” is referring to.
For the purposes of compact prosecution, Examiner will interpret all additional instances of “a request” and “the request” as referring to the “a request” first declared in Claim 20.
Claims 3, 6-9, 11, 13-14, 17-19 are all rejected based on their dependency to the aforementioned rejected Claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-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.
Step 1:
Claims 1-11 are directed to method and falls within the statutory category of a process; Claims 12-19 are directed to system and falls within the statutory category of a machines; Claim 20 is directed to a computer program product and falls within the statutory category of article of manufacture. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1, 12 and 20: The limitations of “determining/determine [, by the processor set,] whether a first pod on a node meeting a carbon intensity threshold is available to process the request without a service level agreement violation over a violation threshold”, “assigning/assign [, by the processor set,] the request to the first pod on the node meeting the carbon intensity threshold in response to the first pod being available and a service level agreement violation over the violation threshold being absent;” and “assigning/assign [, by the processor set,] the request to a second pod that does not result in a service level agreement violation over the violation threshold in response to a service level agreement violation being present for assigning the request to the first pod”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally evaluate whether a resource is capable of completing a task based on threshold requirements. Furthermore, someone can choose to or choose not to assign a flag of failure based on threshold requirements.
Therefore, yes, Claims 1, 12 and 20 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
Claims 1, 8 and 15: The judicial exceptions are not integrated into practical applications. In particular, the claims recite the following additional elements – “receiving/receive [, by a processor set,] the/a request for processing by the multi-cluster system;”, reciting insignificant extra-solution data gathering activity, MPEP § 2106.05(g). Furthermore, “a processor set;” and “a set of one or more computer-readable storage media;” and “program instructions, collectively stored in the set of one or more storage media, for causing a processor set to perform the following computer operations:”, is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)).
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that the Claims 1, 12 and 20 not only recite a judicial exception but that the claims are directed to a judicial exception as a judicial exception has not been integrated into a practical application.
Step 2B:
Claims 1, 12 and 20: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components, field of use/technological environment, and insignificant extra-solution activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra-solution activity is Well-Understood, Routine, and Conventional. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network”. See MPEP § 2106.05(d)(II).
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1, 12 and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 2 and 13: “increasing/increase the carbon intensity threshold in response to the first pod on the node meeting the carbon intensity threshold being unavailable to process the request without a service level agreement violation that is under a violation threshold to form an adjusted carbon intensity threshold”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally adjust thresholds depending on whether or not certain requirements are being met. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 2 and 13 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 2 and 13 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 3 and 14: “assigning/ assign [, by the processor set,] the request to a cluster in the multi-cluster system using global load balancing that takes into account carbon emissions by the cluster in the multi-cluster system”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally assign resources to complete a request by considering the waste produced by that resource. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 3 and 14 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 3 and 14 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 4 and 15: “determining/determine [, by the processor set,] whether a selected pod in the multi-cluster system is usable to load balance requests considering a tradeoff between service level agreement violations in processing requests and carbon emissions from a node on which the selected pod is running; and evicting/evict [, by the processor set,] the selected pod in response to a determination that the selected pod is not usable to load balance requests” , as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally evaluate whether a resource is worth continue using to stop using it. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 4 and 15 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 4 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 5 and 16: “evicting/evict [, by the processor set,] the selected pod at a time based on a progress of a number of workloads being processed by the pod in response to a determination that the selected pod is not usable to load balance requests, wherein the selected pod becomes an evicted pod”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally evaluate whether a resource is worth continue using to stop using it. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 5 and 16 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 5 and 16 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 6 and 17: “determining/ determine [, by the processor set,] carbon emissions for an impacted node exceeds a threshold limit in response to an incoming request; and determining/determine [, by the processor set,] whether an impacted pod on the impacted node is a usable pod for load balancing based on service level violations in processing requests and carbon emissions from the impacted node”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally evaluate whether a resource is exceeding certain thresholds and whether the resource is usable with regards to those thresholds. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 6 and 17 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 6 and 17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 7 and 18: “performing/perform [, by the processor set,] load balancing to assign requests to clusters in the multi-cluster system with usable pods in the multi-cluster system”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally balance allocation of tasks to a plurality of resources. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 7 and 18 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 7 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 8 and 19: “changing/change [, by the processor set,] a number of pods available to process requests that takes into account reducing carbon emissions in response to changes in workloads”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally evaluate how many resources must be utilized to reduce resource waste. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 8 and 19 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 8 and 19 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 10: “assigning, by the processor set, emission categories to nodes in the multi-cluster system based on carbon emissions from the nodes, wherein each carbon emission category in the carbon emission categories has a range of carbon emissions for the nodes; and assigning, by the processor set, weights to pods on the nodes using the categories, wherein the pods in nodes with a first carbon emission category is assigned a higher weight than the pods in the nodes with a second carbon emission category that is higher than the first carbon emission category, wherein requests are assigned to the pods using the weights”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally assign weights and categories to resources based on the amount and type of waste they produce. With regard to integration into practical application and whether additional elements amount to significantly more, Claim 10 fails both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 11; “assigning, by the processor set, carbon emission categories to nodes in the multi cluster system based on carbon emissions from the nodes, wherein each carbon emission category in the carbon emission categories has a range of carbon emissions for the nodes; and assigning, by the processor set, requests to pods in the nodes on a round robin basis, wherein the pods in the nodes with lower carbon emission ratings are assigned requests more often than the pods in the nodes with a higher carbon emissions ratings”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally assign weights and categories to resources based on the amount and type of waste they produce. With regard to integration into practical application and whether additional elements amount to significantly more, Claim 11 fails both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 11 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 6-9, 12, 14, and 1720 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ekins et al. (US 20210373973 A1) (hereinafter Ekins), in view of Asveren et al. (US 20220094743 A1) (hereinafter Asveren).
Regarding Claim 1, Ekins teaches:
A computer implemented method for assigning a request in a multi-cluster system, the computer implemented method comprising: receiving, by a processor set, the request for processing by the multi-cluster system;
“Processing device 104 (or controller 101) represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like”, (Ekins: ¶51), “Readers will appreciate that in some embodiments, executing (1708) the workload (1716) on the target execution environment (1712a) may be carried out by issuing a request to the target execution environment (1712a) to execute a particular workload (1716)”, (Ekins: ¶324), “In some embodiments, executing (1708) the workload (1716) is performed automatically in response to selecting (1706) the target execution environment (1712a). In other embodiments, executing (1708) the workload (1716) is performed automatically in response to a request or confirmation from a user or other entity to execute (1708) the workload (1716) on the selected target execution environment (1712a)”, (Ekins: ¶325), “FIG. 17 also includes selecting (1706), based on each carbon emission cost (1704) for the plurality of execution environments (1712a, 1712b, 1712n), a target execution environment (1712a)”, (Ekins: ¶322, Fig 17), “FIG. 17 also includes executing (1708) the workload (1016) on the target execution environment (1712a)”, (Ekins: ¶323, Fig 17), “calculating, for each execution environment of a plurality of execution environments, a carbon emission cost associated with a workload; selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Claim 11), “Storage clusters 161, in various embodiments as disclosed herein, can be contrasted with storage arrays in general. The storage nodes 150 are part of a collection that creates the storage cluster 161. “, (Ekins: ¶113), “the container storage may be provided by the cluster directly through its shared-nothing storage model, with those containers providing the images that form the execution environment for parts of an application or service”, (Ekins : ¶213). Examiner notes: the plurality of execution environment is being interpreted as the multi-cluster system.
determining, by the processor set, whether on a node meeting a carbon intensity threshold is available to process the request without a service level agreement violation over a violation threshold;
“FIG. 17, each of the execution environments (1712a, 1712b, 1712n) may be embodied as a collection of computer hardware resources and computer software resources that are capable of supporting the execution of a particular workload (1716)”, (Ekins: ¶317, Fig 17), “the carbon emission cost (1704) may include an emission intensity calculated as an amount of carbon by weight (e.g., in grams) emitted per unit of energy”, (Ekins: ¶316), “the carbon emission cost (1704) may include a projected emission intensity”, (Ekins: ¶317), “the target execution environment (1712a) is selected (1706) as having a lowest carbon emission cost while satisfying one or more thresholds as will be described in more retail below”, (Ekins: ¶322), “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335).
While Ekins does not explicitly teach the use of pods, it does teach carrying out processing in a container in “Executing (1014) the workload (1016) on the target execution environment (1012a) may be carried out, for example, by deploying source code associated with the workload within a container in the target execution environment…”, (Ekins: ¶289). Using a container to carry out processing is similar to using pods because a pod can be a containerized environment specifically in the context of Kubernetes pods which Ekins mentions in “Such software applications can be deployed in a variety of ways, including container-based deployment models” … “containerized applications may be managed using Docker Swarm, Kubernetes, and others”, (Ekins: ¶202).
assigning, by the processor set, the request to the first pod on the node meeting the carbon intensity threshold in response to the first pod being available and a service level agreement violation over the violation threshold being absent;
“The target execution environment (1712a) is selected (1706) as having a lowest carbon emission cost while satisfying one or more thresholds”, (Ekins: ¶322), “by deploying source code associated with the workload (1716) within a container in the target execution environment (1712a)…”, (Ekins: ¶323), “executing (1708) the workload (1716) on the target execution environment (1712a) and issuing a request to the target execution environment (1712a) to execute the workload (1716) can be viewed as being synonymous”, (Ekins: ¶324), “executing (1708) the workload (1716) is performed automatically in response to selecting (1706) the target execution environment (1712a)”, (Ekins: ¶325), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
and assigning, by the processor set, the request to a second pod that does not result in a service level agreement violation over the violation threshold in response to a service level agreement violation being present for assigning the request to the first pod.
“execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716). Those execution environments whose predicted or historic availability falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)”, (Ekins: ¶336), “selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Claim 11).
Further regarding Claim 1, Ekins fails to teach:
a first pod … the first pod … the first pod … a second pod … the first pod
However, Asveren teaches: “In various embodiments, the entities of the system are implemented as PODs or native applications on nodes. In various embodiments, the system is a Kubernetes system with the nodes of the system being Kubernetes nodes and the SBC workers being PODs implemented on the nodes”, (Asveren: ¶24), “In various embodiments the cluster is implemented on a Kubernetes system, e.g., located in the cloud, with the compute nodes being Kubernetes nodes…”, (Asveren: ¶44), “the autoscaler 291 also add PODs or applications to nodes of the cluster 230 or remove or delete PODs or applications from nodes of the cluster 230” … “the orchestrator 292 manages the first cluster of SBCs and the SLB 1 including the addition and deletion of nodes and applications, e.g., SBC applications and SLB applications, instantiated and/or implemented on the nodes”, (Asveren: ¶54).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a first pod … the first pod … the first pod … a second pod … the first pod of Asveren with the methods and systems of Ekins resulting in a system that can manage Kubernetes clusters with pods. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the ability of the application to scale horizontally, the ability of the application to scale automatically, using proactive and reactive actions, the ability of the application to handle node and transient failures without degrading”, (Asveren: ¶4).
Regarding Claim 3, Ekins teaches:
assigning, by the processor set, the request to a cluster in the multi-cluster system using global load balancing that takes into account carbon emissions by the cluster in the multi-cluster system.
“Workload placement based on carbon emissions, including g: calculating, for each execution environment of a plurality of execution environments, a carbon emission cost associated with a workload;”, (Ekins: Abstract), “FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “elasticity implements a unique scale-out technique that balances work evenly across all resources regardless of client access pattern, and maximizes concurrency by eliminating much of the need for inter-blade coordination that typically occurs with conventional distributed locking”, (Ekins: ¶119), “rebalancing algorithms attempt to store the copies of all entities within an authority in the same layout and on the same set of machines”, (Ekins: ¶105), “Latency-sensitive client requests may be persisted in replicated NVRAM, and then later NAND, while background rebalancing operations are persisted directly to NAND”, (Ekins: ¶109).
Regarding Claim 6, Ekins teaches:
determining, by the processor set, carbon emissions for an impacted node exceeds a threshold limit in response to an incoming request;
“The carbon emission cost (1704) for a particular execution environment (1712a, 1712b, 1712n) is a quantitative expression of an amount of carbon emitted is association with the use of the particular execution environment (1712a, 1712b, 1712n)”, (Ekins: ¶316), “may be expressed as a particular amount of carbon by weight estimated to be emitted through use of the particular execution environment (1712a, 1712b, 1712n)”, (Ekins: ¶318), “Selecting (1902) the target execution environment (1712a) based on one or more thresholds (1904) may include calculating one or more values for each execution environment (1712a, 1712b, 1712n) and selecting (1902) the target execution environment (1712a) responsive to the values for that target execution environment (1712a) falling above or below a particular threshold (1904) corresponding to the value” … “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)”, (Ekins: ¶335).
and determining, by the processor set, whether an impacted pod on the impacted node is a usable pod for load balancing based on service level violations in processing requests and carbon emissions from the impacted node.
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336), “Such software applications can be deployed in a variety of ways, including container-based deployment models” … “containerized applications may be managed using Docker Swarm, Kubernetes, and others”, (Ekins: ¶202). Examiner notes: Ekins teaches determining whether the impacted workload/containerized application is usable for placement because it excludes environments that fail an SLA-related availability threshold.
Regarding Claim 7, Ekins teaches:
performing, by the processor set, load balancing to assign requests to clusters in the multi-cluster system with usable pods in the multi-cluster system.
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
Regarding Claim 8, Ekins teaches:
changing, by the processor set, a number of pods available to process requests that takes into account reducing carbon emissions in response to changes in workloads.
“FIG. 17 includes calculating (1702), for each execution environment (1712a, 1712b, 1712n) of a plurality of execution environments (1712a, 1712b, 1712n), a carbon emission cost (1704) associated with a workload (1716)”, (Ekins: ¶315), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336), “Accordingly, in some embodiments, one or more devices in the target execution environment (1712a) not required for executing the workload (1716) may be deactivated to reduce the overall carbon output caused by executing the workload (1716) on the target execution environment (1712a)”, (Ekins: ¶341).
Regarding Claim 9, Ekins teaches:
changing, by the processor set, resources allocated to a number of individual pods that takes into account reducing carbon emissions in response to changes in workloads.
“Accordingly, in some embodiments, one or more devices in the target execution environment (1712a) not required for executing the workload (1716) may be deactivated to reduce the overall carbon output caused by executing the workload (1716) on the target execution environment (1712a)”, (Ekins: ¶341), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
Regarding Claim 12, Ekins teaches:
A computer system comprising: a processor set; a set of one or more computer-readable storage media; and program instructions, collectively stored in the set of one or more storage media,
“Storage array controller 101 may include one or more processing devices 104 and random access memory (‘RAM’) 111. Processing device 104 (or controller 101) represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like”, (Ekins: ¶51), “any computing device that includes discrete components such as a processing device, central processing unit, computer memory, or various adapters” … “The persistent storage resource 170A-B main include any number of storage drives 171A-F (also referred to as “storage devices” herein) and any number of non-volatile Random Access Memory (‘NVRAM’) devices (not shown)”, (Ekins: ¶41).
for causing the processor set to perform the following computer operations: receive a request for processing by a multi-cluster system;
“executing (1708) the workload (1716) on the target execution environment (1712a) may be carried out by issuing a request to the target execution environment (1712a) to execute a particular workload (1716)”, (Ekins: ¶324), “In some embodiments, executing (1708) the workload (1716) is performed automatically in response to selecting (1706) the target execution environment (1712a). In other embodiments, executing (1708) the workload (1716) is performed automatically in response to a request or confirmation from a user or other entity to execute (1708) the workload (1716) on the selected target execution environment (1712a)”, (Ekins: ¶325), “FIG. 17 also includes selecting (1706), based on each carbon emission cost (1704) for the plurality of execution environments (1712a, 1712b, 1712n), a target execution environment (1712a)”, (Ekins: ¶322, Fig 17), “FIG. 17 also includes executing (1708) the workload (1016) on the target execution environment (1712a)”, (Ekins: ¶323, Fig 17), “calculating, for each execution environment of a plurality of execution Page 14 environments, a carbon emission cost associated with a workload; selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Claim 11), “Storage clusters 161, in various embodiments as disclosed herein, can be contrasted with storage arrays in general. The storage nodes 150 are part of a collection that creates the storage cluster 161. “, (Ekins: ¶113), “the container storage may be provided by the cluster directly through its shared-nothing storage model, with those containers providing the images that form the execution environment for parts of an application or service”, (Ekins : ¶213). Examiner notes: the plurality of execution environment is being interpreted as the multi-cluster system.
determine whether a first pod on a node meeting a carbon intensity threshold is available to process the request without a service level agreement violation over a violation threshold;
“FIG. 17, each of the execution environments (1712a, 1712b, 1712n) may be embodied as a collection of computer hardware resources and computer software resources that are capable of supporting the execution of a particular workload (1716)”, (Ekins: ¶317, Fig 17), “the carbon emission cost (1704) may include an emission intensity calculated as an amount of carbon by weight (e.g., in grams) emitted per unit of energy”, (Ekins: ¶316), “the carbon emission cost (1704) may include a projected emission intensity”, (Ekins: ¶317), “the target execution environment (1712a) is selected (1706) as having a lowest carbon emission cost while satisfying one or more thresholds as will be described in more retail below”, (Ekins: ¶322), “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335).
While Ekins does not explicitly teach the use of pods, it does teach carrying out processing in a container in “Executing (1014) the workload (1016) on the target execution environment (1012a) may be carried out, for example, by deploying source code associated with the workload within a container in the target execution environment…”, (Ekins: ¶289). Using a container to carry out processing is similar to using pods because a pod can be a containerized environment specifically in the context of Kubernetes pods which Ekins mentions in “Such software applications can be deployed in a variety of ways, including container-based deployment models” … “containerized applications may be managed using Docker Swarm, Kubernetes, and others”, (Ekins: ¶202).
assign the request to the first pod on the node meeting the carbon intensity threshold in response to the first pod being available and a service level agreement violation over the violation threshold being absent;
“The target execution environment (1712a) is selected (1706) as having a lowest carbon emission cost while satisfying one or more thresholds”, (Ekins: ¶322), “by deploying source code associated with the workload (1716) within a container in the target execution environment (1712a)…”, (Ekins: ¶323), “executing (1708) the workload (1716) on the target execution environment (1712a) and issuing a request to the target execution environment (1712a) to execute the workload (1716) can be viewed as being synonymous”, (Ekins: ¶324), “executing (1708) the workload (1716) is performed automatically in response to selecting (1706) the target execution environment (1712a)”, (Ekins: ¶325), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
and assign the request to a second pod that does not result in a service level agreement violation over the violation threshold in response to a service level agreement violation being present for assigning the request to the first pod.
“execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716). Those execution environments whose predicted or historic availability falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)”, (Ekins: ¶336), “selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Claim 11).
Further regarding Claim 12, Ekins fails to teach:
a first pod … the first pod … the first pod … a second pod … the first pod
However, Asveren teaches: “In various embodiments, the entities of the system are implemented as PODs or native applications on nodes. In various embodiments, the system is a Kubernetes system with the nodes of the system being Kubernetes nodes and the SBC workers being PODs implemented on the nodes”, (Asveren: ¶24), “In various embodiments the cluster is implemented on a Kubernetes system, e.g., located in the cloud, with the compute nodes being Kubernetes nodes…”, (Asveren: ¶44), “the autoscaler 291 also add PODs or applications to nodes of the cluster 230 or remove or delete PODs or applications from nodes of the cluster 230” … “the orchestrator 292 manages the first cluster of SBCs and the SLB 1 including the addition and deletion of nodes and applications, e.g., SBC applications and SLB applications, instantiated and/or implemented on the nodes”, (Asveren: ¶54).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a first pod … the first pod … the first pod … a second pod … the first pod of Asveren with the methods and systems of Ekins resulting in a system that can manage Kubernetes clusters with pods. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the ability of the application to scale horizontally, the ability of the application to scale automatically, using proactive and reactive actions, the ability of the application to handle node and transient failures without degrading”, (Asveren: ¶4).
Regarding Claim 14, Ekins teaches:
assign the request to a cluster in the multi-cluster system using global load balancing that takes into account carbon emissions by the cluster in the multi-cluster system.
“Workload placement based on carbon emissions, including g: calculating, for each execution environment of a plurality of execution environments, a carbon emission cost associated with a workload;”, (Ekins: Abstract), “FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “elasticity implements a unique scale-out technique that balances work evenly across all resources regardless of client access pattern, and maximizes concurrency by eliminating much of the need for inter-blade coordination that typically occurs with conventional distributed locking”, (Ekins: ¶119), “rebalancing algorithms attempt to store the copies of all entities within an authority in the same layout and on the same set of machines”, (Ekins: ¶105), “Latency-sensitive client requests may be persisted in replicated NVRAM, and then later NAND, while background rebalancing operations are persisted directly to NAND”, (Ekins: ¶109).
Regarding Claim 17, Ekins teaches:
determine whether carbon emissions for an impacted node exceeds a threshold limit in response to an incoming request;
“The carbon emission cost (1704) for a particular execution environment (1712a, 1712b, 1712n) is a quantitative expression of an amount of carbon emitted is association with the use of the particular execution environment (1712a, 1712b, 1712n)”, (Ekins: ¶316), “may be expressed as a particular amount of carbon by weight estimated to be emitted through use of the particular execution environment (1712a, 1712b, 1712n)”, (Ekins: ¶318), “Selecting (1902) the target execution environment (1712a) based on one or more thresholds (1904) may include calculating one or more values for each execution environment (1712a, 1712b, 1712n) and selecting (1902) the target execution environment (1712a) responsive to the values for that target execution environment (1712a) falling above or below a particular threshold (1904) corresponding to the value” … “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)”, (Ekins: ¶335).
and determine whether an impacted pod on the impacted node is a usable pod for load balancing based on service level violations in processing requests and carbon emissions from the impacted node.
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336), “Such software applications can be deployed in a variety of ways, including container-based deployment models” … “containerized applications may be managed using Docker Swarm, Kubernetes, and others”, (Ekins: ¶202). Examiner notes: Ekins teaches determining whether the impacted workload/containerized application is usable for placement because it excludes environments that fail an SLA related availability threshold.
Regarding Claim 18, Ekins teaches:
perform multi-cluster load balancing to assign requests to clusters in the multi cluster system with usable pods in the multi-cluster system.
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
Regarding Claim 19, Ekins teaches:
change a number of pods available to process requests that takes into account reducing carbon emissions in response to changes in workloads.
“FIG. 17 includes calculating (1702), for each execution environment (1712a, 1712b, 1712n) of a plurality of execution environments (1712a, 1712b, 1712n), a carbon emission cost (1704) associated with a workload (1716)”, (Ekins: ¶315), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336), “Accordingly, in some embodiments, one or more devices in the target execution environment (1712a) not required for executing the workload (1716) may be deactivated to reduce the overall carbon output caused by executing the workload (1716) on the target execution environment (1712a)”, (Ekins: ¶341).
Regarding Claim 20, Ekins teaches:
A computer program product for assigning a request in a multi-cluster system, the computer program product comprising: a set of one or more computer-readable storage media; program instructions, collectively stored in the set of one or more storage media,
“Storage array controller 101 may include one or more processing devices 104 and random access memory (‘RAM’) 111. Processing device 104 (or controller 101) represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like”, (Ekins: ¶51), “any computing device that includes discrete components such as a processing device, central processing unit, computer memory, or various adapters” … “The persistent storage resource 170A-B main include any number of storage drives 171A-F (also referred to as “storage devices” herein) and any number of non-volatile Random Access Memory (‘NVRAM’) devices (not shown)”, (Ekins: ¶41).
for causing a processor set to perform the following computer operations: receive a request for processing by the multi-cluster system;
“executing (1708) the workload (1716) on the target execution environment (1712a) may be carried out by issuing a request to the target execution environment (1712a) to execute a particular workload (1716)”, (Ekins: ¶324), “In some embodiments, executing (1708) the workload (1716) is performed automatically in response to selecting (1706) the target execution environment (1712a). In other embodiments, executing (1708) the workload (1716) is performed automatically in response to a request or confirmation from a user or other entity to execute (1708) the workload (1716) on the selected target execution environment (1712a)”, (Ekins: ¶325), “FIG. 17 also includes selecting (1706), based on each carbon emission cost (1704) for the plurality of execution environments (1712a, 1712b, 1712n), a target execution environment (1712a)”, (Ekins: ¶322, Fig 17), “FIG. 17 also includes executing (1708) the workload (1016) on the target execution environment (1712a)”, (Ekins: ¶323, Fig 17), “calculating, for each execution environment of a plurality of execution Page 14 environments, a carbon emission cost associated with a workload; selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Claim 11), “Storage clusters 161, in various embodiments as disclosed herein, can be contrasted with storage arrays in general. The storage nodes 150 are part of a collection that creates the storage cluster 161. “, (Ekins: ¶113), “the container storage may be provided by the cluster directly through its shared-nothing storage model, with those containers providing the images that form the execution environment for parts of an application or service”, (Ekins : ¶213). Examiner notes: the plurality of execution environment is being interpreted as the multi-cluster system.
determine whether a first pod on a node meeting a carbon intensity threshold is available to process the request without a service level agreement violation over a violation threshold;
“FIG. 17, each of the execution environments (1712a, 1712b, 1712n) may be embodied as a collection of computer hardware resources and computer software resources that are capable of supporting the execution of a particular workload (1716)”, (Ekins: ¶317, Fig 17), “the carbon emission cost (1704) may include an emission intensity calculated as an amount of carbon by weight (e.g., in grams) emitted per unit of energy”, (Ekins: ¶316), “the carbon emission cost (1704) may include a projected emission intensity”, (Ekins: ¶317), “the target execution environment (1712a) is selected (1706) as having a lowest carbon emission cost while satisfying one or more thresholds as will be described in more retail below”, (Ekins: ¶322), “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335).
While Ekins does not explicitly teach the use of pods, it does teach carrying out processing in a container in “Executing (1014) the workload (1016) on the target execution environment (1012a) may be carried out, for example, by deploying source code associated with the workload within a container in the target execution environment…”, (Ekins: ¶289). Using a container to carry out processing is similar to using pods because a pod can be a containerized environment specifically in the context of Kubernetes pods which Ekins mentions in “Such software applications can be deployed in a variety of ways, including container-based deployment models” … “containerized applications may be managed using Docker Swarm, Kubernetes, and others”, (Ekins: ¶202).
assign the request to the first pod on the node meeting the carbon intensity threshold in response to the first pod being available and a service level agreement violation over the violation threshold being absent;
“The target execution environment (1712a) is selected (1706) as having a lowest carbon emission cost while satisfying one or more thresholds”, (Ekins: ¶322), “by deploying source code associated with the workload (1716) within a container in the target execution environment (1712a)…”, (Ekins: ¶323), “executing (1708) the workload (1716) on the target execution environment (1712a) and issuing a request to the target execution environment (1712a) to execute the workload (1716) can be viewed as being synonymous”, (Ekins: ¶324), “executing (1708) the workload (1716) is performed automatically in response to selecting (1706) the target execution environment (1712a)”, (Ekins: ¶325), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
and assign the request to a second pod that does not result in a service level agreement violation over the violation threshold in response to a service level agreement violation being present for assigning the request to the first pod.
“execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716). Those execution environments whose predicted or historic availability falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)”, (Ekins: ¶336), “selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Claim 11).
Further regarding Claim 20, Ekins fails to teach:
a first pod … the first pod … the first pod … a second pod … the first pod
However, Asveren teaches: “In various embodiments, the entities of the system are implemented as PODs or native applications on nodes. In various embodiments, the system is a Kubernetes system with the nodes of the system being Kubernetes nodes and the SBC workers being PODs implemented on the nodes”, (Asveren: ¶24), “In various embodiments the cluster is implemented on a Kubernetes system, e.g., located in the cloud, with the compute nodes being Kubernetes nodes…”, (Asveren: ¶44), “the autoscaler 291 also add PODs or applications to nodes of the cluster 230 or remove or delete PODs or applications from nodes of the cluster 230” … “the orchestrator 292 manages the first cluster of SBCs and the SLB 1 including the addition and deletion of nodes and applications, e.g., SBC applications and SLB applications, instantiated and/or implemented on the nodes”, (Asveren: ¶54).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a first pod … the first pod … the first pod … a second pod … the first pod of Asveren with the methods and systems of Ekins resulting in a system that can manage Kubernetes clusters with pods. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the ability of the application to scale horizontally, the ability of the application to scale automatically, using proactive and reactive actions, the ability of the application to handle node and transient failures without degrading”, (Asveren: ¶4).
Claims 2 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ekins in view of Asveren, in further view of Dong et al. (US 20170228257 A1) (hereinafter Dong)
Regarding Claim 2, Ekins teaches:
increasing the carbon intensity threshold in response to the first pod on the node meeting the carbon intensity threshold being unavailable to process the request without a service level agreement violation that is under a violation threshold to form an adjusted carbon intensity threshold.
“execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
Further regarding Claim 2, Ekins and Asveren fails to teach:
increasing the carbon intensity threshold
However, Dong teaches: “dynamically adjusting the resource utilization threshold based on at least one parameter. The at least one parameter may comprise” … “carbon footprint (e.g., energy and/or space usages)”, (Dong: ¶10), “Threshold adjustment determining engine 122 may determine an adjustment value to be added to a first threshold value based on a function of the usage charges. The function of the usage charges may define a relationship between the usage charges and the adjustment value”, (Dong: ¶20).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine increasing the carbon intensity threshold of Dong with the methods and systems of Ekins and Asveren resulting in a system that can adjust threshold values to meet requirements. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Such fixed thresholds used for monitoring the utilization rate fail to accommodate dynamically changing circumstances, causing false alarm signals and a waste of computing resources”, (Dong: ¶1), “the lower threshold for the resource utilization rate may be scheduled to be adjusted higher (e.g., 10% to 20% utilization rate) to save more resources”, (Dong: ¶22).
Regarding Claim 13, teaches:
increase the carbon intensity threshold in response to the first pod on the node meeting the carbon intensity threshold being unavailable to process the request without a service level agreement threshold violation to form an adjusted carbon intensity threshold.
“execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336). 25.
Further regarding Claim 13, Ekins and Asveren fails to teach:
increase the carbon intensity threshold
However, Dong teaches: “dynamically adjusting the resource utilization threshold based on at least one parameter. The at least one parameter may comprise” … “carbon footprint (e.g., energy and/or space usages)”, (Dong: ¶10), “Threshold adjustment determining engine 122 may determine an adjustment value to be added to a first threshold value based on a function of the usage charges. The function of the usage charges may define a relationship between the usage charges and the adjustment value”, (Dong: ¶20).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine increase the carbon intensity threshold of Dong with the methods and systems of Ekins and Asveren resulting in a system that can adjust threshold values to meet requirements. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Such fixed thresholds used for monitoring the utilization rate fail to accommodate dynamically changing circumstances, causing false alarm signals and a waste of computing resources”, (Dong: ¶1), “the lower threshold for the resource utilization rate may be scheduled to be adjusted higher (e.g., 10% to 20% utilization rate) to save more resources”, (Dong: ¶22).
Claims 4-5 and 15-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ekins in view of Asveren, in further view of Jain et al. (US 20210081243 A1) (hereinafter Jain).
Regarding Claim 4, Ekins teaches:
determining, by the processor set, whether a selected pod in the multi-cluster system is usable to load balance requests considering a tradeoff between service level agreement violations in processing requests and carbon emissions from a node on which the selected pod is running;
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336), “FIG. 17 includes calculating (1702), for each execution environment (1712a, 1712b, 1712n) of a plurality of execution environments (1712a, 1712b, 1712n), a carbon emission cost (1704) associated with a workload (1716)”, (Ekins: ¶315). Examiner notes: the calculation of carbon cost is being interpreted as the consideration of a tradeoff as each cost is asses and the cheapest one is selected.
and evicting, by the processor set, the selected pod in response to a determination that the selected pod is not usable to load balance requests.
“execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335).
Further regarding Claim 4, Ekins and Asveren fails to teach:
and evicting, by the processor set, the selected pod in response to a determination that the selected pod is not usable to load balance requests
However, Jain teaches: “the termination dispatcher 114 is configured to evict each pod associated with the detached instance 202 prior to terminating the detached instance 202” … “gracefully evicting the pod prevents the work associated with the pod to be rescheduled by the scheduler 116” … “gracefully evicting a pod by the termination dispatcher 114 includes the termination dispatcher 114 starting a predetermined grace period and allowing the containers of the pod to run to completion and perform cleanup functions during the predetermined grace period”, (Jain: ¶51), “In one example, the termination dispatcher 114 is configured to evict a pod associated with the detached instance 202 if the pod is non-deferring”, (Jain: ¶52), “the autoscaler 110 is configured to not continue to the next eligible instance to scale-down, until all pods have been evicted off the prior instance and no unscheduled pods are assigned to the instance group”, (Jain: ¶71).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine evicting, by the processor set, the selected pod in response to a determination that the selected pod is not usable to load balance requests of Jain with the methods and systems of Ekins and Asveren resulting in a system that can remove pods based on load balance requests. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improvements, including, for example, increased efficiency and speed, in standing up a computing platform multiple times for an increased number of customers” … “other benefits include improved utilization of resources allocated to instances across the computing platform, and increased security and enhanced resiliency of the operating platform”, (Jain: ¶27).
Regarding Claim 5, Ekins teaches:
evicting, by the processor set, the selected pod at a time based on a progress of a number of workloads being processed by the pod in response to a determination that the selected pod is not usable to load balance requests, wherein the selected pod becomes an evicted pod.
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
Further regarding Claim 5, Ekins and Asveren fails to teach:
evicting, by the processor set, the selected pod at a time based on a progress of a number of workloads being processed by the pod in response to a determination that the selected pod is not usable to load balance requests, wherein the selected pod becomes an evicted pod.
However, Jain teaches: “the termination dispatcher 114 is configured to evict each pod associated with the detached instance 202 prior to terminating the detached instance 202” … “gracefully evicting the pod prevents the work associated with the pod to be rescheduled by the scheduler 116” … “gracefully evicting a pod by the termination dispatcher 114 includes the termination dispatcher 114 starting a predetermined grace period and allowing the containers of the pod to run to completion and perform cleanup functions during the predetermined grace period”, (Jain: ¶51), “In one example, the termination dispatcher 114 is configured to evict a pod associated with the detached instance 202 if the pod is non-deferring”, (Jain: ¶52), “the autoscaler 110 is configured to not continue to the next eligible instance to scale-down, until all pods have been evicted off the prior instance and no unscheduled pods are assigned to the instance group”, (Jain: ¶71).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine evicting, by the processor set, the selected pod at a time based on a progress of a number of workloads being processed by the pod in response to a determination that the selected pod is not usable to load balance requests, wherein the selected pod becomes an evicted pod of Jain with the methods and systems of Ekins and Asveren resulting in a system that can remove pods during a designated period of time based on load balance requests. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improvements, including, for example, increased efficiency and speed, in standing up a computing platform multiple times for an increased number of customers” … “other benefits include improved utilization of resources allocated to instances across the computing platform, and increased security and enhanced resiliency of the operating platform”, (Jain: ¶27).
Regarding Claim 15, Ekins teaches:
determine whether a selected pod in the multi-cluster system is usable to load balance requests considering a tradeoff between service level violations in processing requests and carbon emissions from a node on which the selected pod is running;
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336), “FIG. 17 includes calculating (1702), for each execution environment (1712a, 1712b, 1712n) of a plurality of execution environments (1712a, 1712b, 1712n), a carbon emission cost (1704) associated with a workload (1716)”, (Ekins: ¶315). Examiner notes: the calculation of carbon cost is being interpreted as the consideration of a tradeoff as each cost is asses and the cheapest one is selected.
and evict the selected pod in response to a determination that the selected pod is not usable to load balance requests.
“execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335).
Further regarding Claim 15, Ekins and Asveren fails to teach:
and evict the selected pod in response to a determination that the selected pod is not usable to load balance requests.
However, Jain teaches: “the termination dispatcher 114 is configured to evict each pod associated with the detached instance 202 prior to terminating the detached instance 202” … “gracefully evicting the pod prevents the work associated with the pod to be rescheduled by the scheduler 116” … “gracefully evicting a pod by the termination dispatcher 114 includes the termination dispatcher 114 starting a predetermined grace period and allowing the containers of the pod to run to completion and perform cleanup functions during the predetermined grace period”, (Jain: ¶51), “In one example, the termination dispatcher 114 is configured to evict a pod associated with the detached instance 202 if the pod is non-deferring”, (Jain: ¶52), “the autoscaler 110 is configured to not continue to the next eligible instance to scale-down, until all pods have been evicted off the prior instance and no unscheduled pods are assigned to the instance group”, (Jain: ¶71).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine evicting the selected pod in response to a determination that the selected pod is not usable to load balance requests of Jain with the methods and systems of Ekins and Asveren resulting in a system that can remove pods based on load balance requests. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improvements, including, for example, increased efficiency and speed, in standing up a computing platform multiple times for an increased number of customers” … “other benefits include improved utilization of resources allocated to instances across the computing platform, and increased security and enhanced resiliency of the operating platform”, (Jain: ¶27).
Regarding Claim 16, Ekins teaches:
evict the selected pod at a time based on a progress of a number of workloads being processed by the pod in response to a determination that the selected pod is not usable to load balance requests, wherein the selected pod becomes an evicted pod.
“FIG. 2A is a perspective view of a storage cluster 161, with multiple storage nodes 150 and internal solid-state memory coupled to each storage node to provide network attached storage or storage area network” … “reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby” … “the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load”, (Ekins: ¶91, Fig 2A), “execution environments (1712a, 1712b, 1712n) whose values fall above or below the corresponding threshold (1904) are filtered or excluded from candidacy for selection (1902) as the target execution environment (1712a)” … “execution environments (1712a, 1712b, 1712n) whose predicted availability falls below a threshold (1904) may be excluded from candidacy” … “The one or more thresholds (1904) may also include predefined thresholds (1904) corresponding to particular service level agreements”, (Ekins: ¶335), “The user is subject to a service level agreement guaranteeing a particular level of availability during execution of the workload (1716)” … “falls below an availability threshold (1904) are excluded from candidacy as a target execution environment (1712a)” … “target execution environment may be selected (1902) as the execution environment (1712a, 1712b, 1712n) having a lowest carbon emission cost (1704) and having an availability meeting or exceeding the availability threshold (1904)”, (Ekins: ¶336).
Further regarding Claim 16, Ekins and Asveren fail to teach:
evict the selected pod at a time based on a progress of a number of workloads being processed by the pod in response to a determination that the selected pod is not usable to load balance requests, wherein the selected pod becomes an evicted pod.
However, Jain teaches: “the termination dispatcher 114 is configured to evict each pod associated with the detached instance 202 prior to terminating the detached instance 202” … “gracefully evicting the pod prevents the work associated with the pod to be rescheduled by the scheduler 116” … “gracefully evicting a pod by the termination dispatcher 114 includes the termination dispatcher 114 starting a predetermined grace period and allowing the containers of the pod to run to completion and perform cleanup functions during the predetermined grace period”, (Jain: ¶51), “In one example, the termination dispatcher 114 is configured to evict a pod associated with the detached instance 202 if the pod is non-deferring”, (Jain: ¶52), “the autoscaler 110 is configured to not continue to the next eligible instance to scale-down, until all pods have been evicted off the prior instance and no unscheduled pods are assigned to the instance group”, (Jain: ¶71).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine evicting, by the processor set, the selected pod at a time based on a progress of a number of workloads being processed by the pod in response to a determination that the selected pod is not usable to load balance requests, wherein the selected pod becomes an evicted pod of Jain with the methods and systems of Ekins and Asveren resulting in a system that can remove pods during a designated period of time based on load balance requests. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improvements, including, for example, increased efficiency and speed, in standing up a computing platform multiple times for an increased number of customers” … “other benefits include improved utilization of resources allocated to instances across the computing platform, and increased security and enhanced resiliency of the operating platform”, (Jain: ¶27).
Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ekins in view of Asveren, in further view of Chamberlin et al. (US 20230251701 A1) (hereinafter Chamberlin).
Regarding Claim 10, Ekins teaches:
assigning, by the processor set, emission categories to nodes in the multi-cluster system based on carbon emissions from the nodes,
“Workload placement based on carbon emissions, including: calculating, for each execution environment of a plurality of execution environments, a carbon emission cost associated with a workload; selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Abstract).
and assigning, by the processor set, weights to pods on the nodes using the categories,
“a fitness score (2004) based on the carbon emission cost (1704). For example, the fitness score (2004) for a given execution environment (1712a, 1712b, 1712n) may be calculated based on the carbon emission cost (1704) for the given execution environment (1712a, 1712b, 1712n) and one or more other values” … “the fitness score (2004) may be calculated (2002) using a weighted function applied to the carbon emission cost (1704) and the one or more other values”, (Ekins: ¶338), “the performance load on the storage system (408) may be calculated according to some formula that takes as inputs the weighted or unweighted combination of such factors…”, (Ekins: ¶244), “, the performance load on the storage systems (406, 408) in the fleet (906) may be calculated according to some formula that takes as inputs the weighted or unweighted combination of such factors”, (Ekins: ¶273). Examiner notes: execution environments are given weighted factors that determine carbon emission cost.
wherein the pods in nodes with a first carbon emission category is assigned a higher weight than the pods in the nodes with a second carbon emission category that is higher than the first carbon emission category, wherein requests are assigned to the pods using the weights.
“the fitness score (2004) may be calculated (2002) using a weighted function applied to the carbon emission cost (1704) and the one or more other values”, (Ekins: ¶338), “the target execution environment (1712a) based on the fitness score (2004). For example, the target execution environment (1712a) may be selected (2006) as having a highest fitness score (2004). As another example, the target execution environment (1712a) may be selected (2006) as having a highest fitness score (2004) and satisfying one or more thresholds as described above. Thus, while the target execution environment (1712a) may be selected (2006) with the carbon emission cost (1704) as a factor in selection, the target execution environment (1712a) may or may not have the lowest carbon emission cost (1704) due to the other factors used in calculating the fitness scores (2004)”, (Ekins: ¶339). Examiner notes: based on a weighted function applied to emission costs of execution environments, a fitness score can either be the highest or the lowest. Fitness score is being loosely tied to emission category but a more explicit teaching is provided by Chamberlin.
Further regarding Claim 10, Ekins and Asveren fails to teach:
assigning, by the processor set, emission categories to nodes in the multi-cluster system based on carbon emissions from the nodes, wherein each carbon emission category in the carbon emission categories has a range of carbon emissions for the nodes; and assigning, by the processor set, weights to pods on the nodes using the categories, wherein the pods in nodes with a first carbon emission category is assigned a higher weight than the pods in the nodes with a second carbon emission category that is higher than the first carbon emission category, wherein requests are assigned to the pods using the weights.
However, Chamberlin teaches: “sustainability information within a given region may be normalized to be within a predetermined range (e.g., from 0-1; from 0-100; or characterized as bad, average, or good)” … “Using carbon intensity as an example, the actual carbon intensity range of the first region (e.g., from an actual minimum carbon intensity to an actual maximum carbon intensity) may be below the actual carbon intensity range of the second region, such that even the actual minimum carbon intensity of the second region is greater than the actual maximum carbon intensity for the first region”, (Chamberlin: ¶23), “the sustainability information may be normalized according to one or more predetermined ranges, for example from 0-1 or 0-100, or from bad, average, to good” … “the sustainability information may be normalized according to one or more descriptive statistics associated with the sustainability information overall (e.g., such that an energy characteristic for a given region has the same statistic as another region)”, (Chamberlin: ¶60), “the sustainability information provided by data provider 106 may relate to any of a variety of energy characteristics of one or more energy grids, such as carbon intensity”, (Chamberlin: ¶42), “a carbon intensity has improved or diminished (e.g., according to a cached sustainability forecast, an update to a sustainability forecast, or based on substantially real-time sustainability information)”, (Chamberlin: ¶53). Examiner notes: sustainability information (bad, average, good) is being interpreted as the emission categories.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine assigning, by the processor set, emission categories to nodes in the multi-cluster system based on carbon emissions from the nodes, wherein each carbon emission category in the carbon emission categories has a range of carbon emissions for the nodes; and assigning, by the processor set, weights to pods on the nodes using the categories, wherein the pods in nodes with a first carbon emission category is assigned a higher weight than the pods in the nodes with a second carbon emission category that is higher than the first carbon emission category, wherein requests are assigned to the pods using the weights of Chamberlin with the methods and systems of Ekins and Asveren resulting in a system that can categories types of emissions based on the type, source, and quantity of emission. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “sustainability forecast to manage various device functionality, such that functionality may be performed during one or more times that are identified to have a comparatively lower environmental impact, thereby deferring device energy consumption during a time forecasted to have a higher environmental impact”, (Chamberlin: Abstract).
Claim 11 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ekins in view of Asveren and Chamberlin, in further view of Ellappan et al. (US 20230300187 A1) (hereinafter Ellappan).
Regarding Claim 11, Ekins teaches:
assigning, by the processor set, carbon emission categories to nodes in the multi cluster system based on carbon emissions from the nodes,
“Workload placement based on carbon emissions, including: calculating, for each execution environment of a plurality of execution environments, a carbon emission cost associated with a workload; selecting, based on each carbon emission cost for the plurality of execution environments, a target execution environment; and executing the workload on the target execution environment”, (Ekins: Abstract).
wherein the pods in the nodes with lower carbon emission ratings are assigned requests more often than the pods in the nodes with a higher carbon emissions ratings.
“the fitness score (2004) may be calculated (2002) using a weighted function applied to the carbon emission cost (1704) and the one or more other values”, (Ekins: ¶338), “the target execution environment (1712a) based on the fitness score (2004). For example, the target execution environment (1712a) may be selected (2006) as having a highest fitness score (2004). As another example, the target execution environment (1712a) may be selected (2006) as having a highest fitness score (2004) and satisfying one or more thresholds as described above. Thus, while the target execution environment (1712a) may be selected (2006) with the carbon emission cost (1704) as a factor in selection, the target execution environment (1712a) may or may not have the lowest carbon emission cost (1704) due to the other factors used in calculating the fitness scores (2004)”, (Ekins: ¶339), “Consider an example where a user is deploying a workload (1716) for execution on an execution environment (1712a, 1712b, 1712n) based on carbon emission costs (1704)”, (Ekins: ¶336). Examiner notes: based on a weighted function applied to emission costs of execution environments, a fitness score can either be the highest or the lowest. Fitness score is being loosely tied to emission category but a more explicit teaching is provided by Chamberlin.
Further regarding Claim 11, Ekins and Asveren fails to teach:
assigning, by the processor set, carbon emission categories to nodes in the multi cluster system based on carbon emissions from the nodes, wherein each carbon emission category in the carbon emission categories has a range of carbon emissions for the nodes;
However, Chamberlin teaches: “sustainability information within a given region may be normalized to be within a predetermined range (e.g., from 0-1; from 0-100; or characterized as bad, average, or good)” … “Using carbon intensity as an example, the actual carbon intensity range of the first region (e.g., from an actual minimum carbon intensity to an actual maximum carbon intensity) may be below the actual carbon intensity range of the second region, such that even the actual minimum carbon intensity of the second region is greater than the actual maximum carbon intensity for the first region”, (Chamberlin: ¶23), “the sustainability information may be normalized according to one or more predetermined ranges, for example from 0-1 or 0-100, or from bad, average, to good” … “the sustainability information may be normalized according to one or more descriptive statistics associated with the sustainability information overall (e.g., such that an energy characteristic for a given region has the same statistic as another region)”, (Chamberlin: ¶60), “the sustainability information provided by data provider 106 may relate to any of a variety of energy characteristics of one or more energy grids, such as carbon intensity”, (Chamberlin: ¶42), “a carbon intensity has improved or diminished (e.g., according to a cached sustainability forecast, an update to a sustainability forecast, or based on substantially real-time sustainability information)”, (Chamberlin: ¶53). Examiner notes: sustainability information (bad, average, good) is being interpreted as the emission categories.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine assigning, by the processor set, carbon emission categories to nodes in the multi cluster system based on carbon emissions from the nodes, wherein each carbon emission category in the carbon emission categories has a range of carbon emissions for the nodes of Chamberlin with the methods and systems of Ekins and Asveren resulting in a system that can categories types of emissions based on the type, source, and quantity of emission. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “sustainability forecast to manage various device functionality, such that functionality may be performed during one or more times that are identified to have a comparatively lower environmental impact, thereby deferring device energy consumption during a time forecasted to have a higher environmental impact”, (Chamberlin: Abstract).
Further regarding Claim 11, Ekins and Asveren in view of Chamberlin fails to teach:
and assigning, by the processor set, requests to pods in the nodes on a round robin basis,
However, Ellappan teaches: “Master cloud environment 102 may receive the request via API server 120 and activate one or more network functions to execute the request”, (Ellappan: ¶22), “Nodes 122 (illustrated as first node 122A, second node 122B, third node 122C, and fourth node 122D) are virtual or physical machines, depending on the cluster, that can run a workload task. One or more containers 126 may be placed into pods 124 that run on nodes 122. Each node 122 may run one or more pods 124”, (Ellappan: ¶25), “The kube-proxy 132 can manage services defined on each node 122 and can forward one or more messages using various protocols, including Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Stream Control Transmission Protocol (SCTP), or may implement round robin TCP, UDP, and SCTP forwarding across a set of backend devices”, (Ellappan: ¶28).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine assigning, by the processor set, requests to pods in the nodes on a round robin basis of Ellappan with the methods and systems of Ekins, Asveren, and Chamberlin resulting in a system that can use round robin to distribute requests to pods. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The discovery and mapping micro-service can map the environment without prior knowledge (e.g., without a template or manual interaction) by initializing itself and tracking any resource changes”, (Ellappan: ¶14), “the discovery and mapping micro-service rules may be evaluated again and NF resource inventory may be updated at ETCD server 108. This may help to avoid running costly periodic resource reconciliation processing”, (Ellappan: ¶47).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIHAB ALAM whose telephone number is (571)272-8705. The examiner can normally be reached Mon - Fri 7:30am-5pm.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/S.A./Examiner, Art Unit 2197
/GREGORY A KESSLER/Primary Examiner, Art Unit 2197
Prosecution Insights