DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
1. Claims 1, 4, and 6-7 are currently amended.
2. Claims 9-14 are newly added.
3. Claims 1-14 are pending.
4. Claims 1-14 are rejected.
Response to Arguments
5. Regarding 35 U.S.C. 101 Rejections:
Applicant’s amendments and arguments to claims 1, 6, and 7 have been considered and are not persuasive. The rejections under 35 U.S.C. 101 are maintained. Additionally, applicant’s arguments are rejected under a new ground of rejection necessitated by the amendment. The full rejection can be found in the 35 U.S.C. 101 Rejections section below.
6. Regarding Prior Art Rejections:
Applicant’s amendments and arguments to claims 1, 6, and 7 have been considered and are not persuasive. The rejections under 35 U.S.C. 103 are maintained. Additionally, applicant’s arguments are rejected under a new ground of rejection necessitated by the amendment.
Applicant argues in remarks:
Amended claim 1 recites a load distribution apparatus comprising a schedule mechanism that deploys container to node in container base, and a scale mechanism that acquires resource data from the container base, wherein the scale mechanism acquires external data about container to be deployed on the container base, calculates available resources of the container base by determining, for each node, a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes, determines resource of the container base based on the resource data and the external data using a first threshold value defining minimum remaining available resources and a second threshold value defining allowable available resources, deletes node of the container base if it is determined that the resource is excessive, and adds node of the container base if it is determined that shortage of the resource, thereby dynamically optimizing physical hardware resource allocation in the container base to reduce operational costs while maintaining service availability. The Examiner has alleged that Anand anticipates the amended claims by teaching cross- cluster capacity scaling where clusters broadcast capacity requirements and coordinate node deallocation and reallocation based on mapping of node requirements and availability. However, Applicant respectfully submits that the examiner's rejection fails to recognize that the amended claims recite specific technical calculations and threshold-based determinations that are not disclosed by Anand. Applicant respectfully disagrees with the rejection and submits that the amended claims are patentable over Anand because the specific technical calculations recited in the amended claims are not disclosed or suggested by Anand's cross-cluster capacity scaling approach. Anand does not disclose the specific calculation process recited in amended claim 1 where the scale mechanism "calculates available resources of the container base by determining, for each node, a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes." Anand's system focuses on cross-cluster capacity sharing where "a specific cluster (Cluster A) has extra capacity and at the same time another specific cluster (Cluster B) requires more capacity." Anand et al., paragraph [0064]. This describes reallocation of existing nodes between clusters based on current capacity states, not the claimed calculation of available resources by determining differences between node resources and maximum values for each node and summing across nodes. Anand's supply and demand component analyzes existing resources differently than the claimed calculation process. While Anand teaches a "supply/demand component 243 for applying supply and demand algorithms that may be used to understand the availability of resources and their individual longevity before deprovisioning nodes to provide supply and to understand the resource requirements and other constraints required by the workload providing the demand," Anand et al., paragraph [0050], this component analyzes availability and requirements of existing resources for cross-cluster sharing purposes. Anand does not disclose the specific mathematical calculation recited in the amended claims where differences are calculated for each node between node resources and maximum values, then summed across all nodes. The threshold-based determination process recited in amended claim 1 is not disclosed by Anand. The limitation "determines resource of the container base based on the resource data and the external data using a first threshold value defining minimum remaining available resources and a second threshold value defining allowable available resources" as recited by claim 1 as amended requires specific threshold values for automated resource management decisions. Anand's capacity allocation component operates through "mapping capacity availability and requirement requests" Anand et al., paragraph [0046], but does not disclose the claimed dual-threshold system with first and second threshold values defining minimum remaining and allowable available resources. Amended claims 6 and 7 recite corresponding technical calculation and threshold-based determination limitations that distinguish over Anand's cross-cluster capacity sharing approach for the same reasons as amended claim 1. Claims 4, 5, and 8 incorporate these distinguishing limitations through their dependency relationships with the amended independent claims. Applicant respectfully submits that the amended claims are allowable over Anand and requests withdrawal of the rejection under 35 U.S.C. § 102(a)(1).
Additionally, applicant continues to argue that:
Claims 2 and 3 depend from claim 1 and incorporate the technical limitations added to claim 1 as amended through their dependency relationship. The specific calculation process where the scale mechanism "calculates available resources of the container base by determining, for each node, a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes" as recited by claim 1 as amended is not disclosed or suggested by Anand, Atkinson, or Srikanta. The threshold-based determination process using "a first threshold value defining minimum remaining available resources and a second threshold value defining allowable available resources" as recited by claim 1 as amended similarly is not disclosed or suggested by the cited references. The examiner's obviousness analysis fails to address how the cited references would teach or suggest these specific technical limitations that distinguish the amended claims. The Examiner's motivation to combine the references does not overcome the technical differences introduced by the amendments to claim 1. While Atkinson teaches that "pipelines may be placed in containers that are portable to different CI/CD tools," this teaching relates to container portability rather than the claimed resource calculation and threshold-based determination processes. Similarly, while Srikanta teaches "administrative operations, such as system configuration and management," this general teaching does not suggest the specific mathematical calculations and dual-threshold system recited in the amended claims. Applicant respectfully submits that claims 2 and 3 are allowable over the cited combinations and requests withdrawal of the rejections under 35 U.S.C. § 103.
With the newly amended claims, the overall scope of the claim does not read the same way it did before. Therefore, new art and combination thereof was introduced to better suit the new scope of the claims.
Anand does not teach of the newly added mathematical equations, however, in analogous art, Singh teaches of calculating available resources of the container base by determining, ([0047] In the illustrated example of FIG. 3, the example deployment monitor 302 monitors deployment environments (e.g., dependent environment 112 of FIG. 1) and determines whether to initiate a scaling operation and to what extent. For example, the deployment monitor 302 may monitor infrastructure resource consumption levels and requirements (e.g., workload) of the deployed application 108 in the deployment environment 112. In some examples, the deployment monitor 302 may compare resource utilization by the application 108 workload to utilization ranges. For example, the deployment monitor 302 may initiate a scale-in operation when resource utilization by the workload is in a first range (e.g., less than 25% utilization), may initiate a scale-out operation when resource utilization by the workload is in a second range (e.g., greater than 75% utilization), and may perform no scaling operation when resource utilization by the workload is in a third range (e.g., greater than or equal to 25% utilization and less than or equal to 75% utilization). In some examples, the deployment monitor 302 may compare the workload to one or more thresholds and scale the number of virtual machines (e.g., sub-nodes) executing the workload accordingly (e.g., increase or decrease the cluster size of a node); [0048] For example, when the deployment monitor 302 of the illustrated example determines that the resource utilization by the workload satisfies a first threshold, the example deployment monitor 302 initiates a scale-out operation to add (e.g., provision) one or more virtual machines to the deployment environment. For example, the example deployment monitor 302 may initiate a first scale-out operation to provision one additional virtual machine 114 when resource utilization by the workload exceeds 75% of available resources, the example deployment monitor 302 may initiate a second scale-out operation to provision a second virtual machine 114 when resource utilization by the workload exceeds 85% of available resources, etc; Examiner’s Note: The deployment monitor calculates available resources.),
Singh fails to explicitly teach that the calculation is done by calculating a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes.
However, in analogous art, Neuse teaches a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes ([0090] As for the VMs deployed on the host, each VM raw consumption is the raw consumption of CPU resources by a VM excluding guest OS overhead and represented in portable units. The VM raw consumption is the resource consumption that is moved to or from a host during a placement process. VMM efficiency is inherent to the host and is recomputed during placement moves. VM guest OS overhead is unique to each VM and represents the effect of Guest OS scalability on a VM. In practice it is estimated as a function of the virtual processor states for the VM and empirical scalability characteristics of the VM Guest OS. The raw VM consumptions are compensated for VM Guest OS to determine a total CM consumption where the raw VM consumptions for a set of VMs, VM through VM.sub.N, deployed on the host and their estimated Guest OS overhead consumptions are all summed together as a total VM consumption 96, QVM; of the available capacity on the host. CPU capacity headroom 95 is total VM consumption 96 subtracted from available capacity 94. For the objective function, CPU capacity headroom 95 is normalized by available resource capacity 94 to a scale of 0 (zero) to 1 (one); (CA-QVM)/CA, is a metric for establishing a placement score; [0108] At step 107, a threshold score is determined. From FIG. 7, a placement score is related to a difference (headroom) between capacity and consumption. The input to step 107 is the target configuration including a target set of hosts with associated host capacities and a target set of VMs with associated VM resource consumptions. The placement score is generally and preferably computed as the minimum normalized headroom in a cloud computing environment across all resources, all time intervals, all hosts and all clusters. If the optimal placement and an achievable score were known, then the threshold score could be computed from the achievable score. However, it is not practical to find the optimal placement. Instead, an ideal score is calculated from an aggregate "headroom" as MIN(1-Qtot/Ctot) where Ctot is the total available capacity of the target set of hosts and Qtot is the total VM resource consumption over the target set of virtual machines for each resource in a set of resources The aggregate value (1-Qtot/Ctot) is the normalized difference between Ctot and Qtot, normalized by dividing the difference between the total available capacity and the total VM resource consumption by the total available capacity. The minimum is taken over the set of hosts and the set of resources and the defined set of time intervals. The threshold score is taken as a pre-configured fraction of the ideal score.),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh with the teachings of Neuse where determining available resources includes calculating a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes. Similarly to Singh, Neuse teaches of reconfiguring a computing environment by measuring resource utilization (Abstract). It would make sense that in order to calculate the available resources, one would need to find the difference between node resources and average actual usage amounts. Therefore, together, Singh and Neuse teach of calculating available resources, comparing resource usage to a first and second threshold, and add/delete nodes accordingly.
Additionally, claims 2-5 and 9-14 depend from and further limit amended claim 1 and are therefore also rejected under 35 U.S.C 103.
The full rejection can be found in the 35 U.S.C. 103 rejection section below.
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.
The claim(s), as amended, contain the following language that is unclear:
As per amended claim 1, line 1 recites “maximum of total container request values”. It is unclear what these values refer to. For examination purposes, examiner interprets the limitation as the maximum number of total containers able to be deployed onto the container base.
Claims 2-5 and 9-14 are dependent on claim 1 and fail to cure the deficiencies set forth above for claim 1. Therefore, they are rejected under the same rationale above.
Regarding claim 6, it is a method claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 7, it is a method claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 8, it is a program causing a processor to execute the load distribution according to claim 7. Therefore, it is rejected under the same rationale above.
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.
7. Claims 1-14 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.
8. Step 1:
Claims 1-5 and 9-14 are directed to a load distribution apparatus and fall within the statutory category of articles of manufacture; Claims 6-7 are directed to a load distribution system and fall within the statutory category of machines; and Claim 8 is directed to a program and falls within the statutory category of machines. 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.
9. Step 2A Prong 1:
Claims 1, 6, and 7: The limitations of “a schedule mechanism that deploys container to node in container base, and a scale mechanism that acquires resource data from the container base, wherein the scale mechanism acquires external data about container to be deployed on the container base, calculates available resources of the container base by determining, for each node, a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes, determines resource of the container base based on the resource data and the external data using a first threshold value defining minimum remaining available resources and a second threshold value defining allowable available resources, deletes node of the container base if it is determined that the resource is excessive, and adds node of the container base if it is determined that shortage of the resource, thereby dynamically optimizing physical hardware resource allocation in the container base to reduce operational costs while maintaining service availability’, 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 think and observe, judge and evaluate that a schedule mechanism deploys a container to a node in a container base. More specifically, the newly added limitation of “calculates available resources of the container base by determining, for each node, a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes, determines resource of the container base based on the resource data and the external data using a first threshold value defining minimum remaining available resources and a second threshold value defining allowable available resource”, recite a mathematical concept. The claim requires “average actual usage amounts, and sums the differences,” which are mathematical calculations.
Therefore, Yes, claim 1 recites 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.
10. Step 2A Prong 2:
Claims 1, 6, and 7: The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional elements – “A load distribution apparatus, comprising:”; “A load distribution system, comprising: a container base includes multiple nodes that store container; and a load distribution apparatus connected to the container base and deploys container to node of the container base, wherein the load distribution apparatus includes a processor and a storage unit”; and “A load distribution method using a load distribution apparatus that includes a processor and a storage unit and deploys data to node of container base”, which is merely recitations of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Additionally, the claims recite “a schedule mechanism that deploys container to node in container base”, which merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application. Moreover, “a scale mechanism that acquires resource data from the container base, wherein the scale mechanism acquires external data about container to be deployed on the container base”, merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g). The courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Lastly, “deletes node of the container base if it is determined that the resource is excessive, and adds node of the container base if it is determined that shortage of the resource, thereby dynamically optimizing physical hardware resource allocation in the container base to reduce operational costs while maintaining service availability” is merely applying the judicial exception or abstract idea. Therefore, this additional element does not integrate the judicial exception into a practical application under.
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 claim 1 not only recites a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application.
11. Step 2B:
Claims 1, 6, and 7: 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 and field of use/technological environment which do not amount to significantly more than the abstract idea.
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, 6, and 7 do not recite patent eligible subject matter under 35 U.S.C. § 101.
12. With regard to claim 2, it recites additional abstract idea recitations of “wherein as the external data, the scale mechanism acquires data about container to be deployed from CI/CD pipeline in development environment”, 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 think about and observe, judge and evaluate that the container is deployed from CI/CD pipeline in a development environment. Additionally, defining the development environment is no more than generic computing components and field of use/technological environment which do not amount to significantly more than the abstract idea. Moreover, acquiring data about the container merely recites insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g). The courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Further, claim 2 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 2 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
13. With regard to claim 3, it recites additional abstract idea recitations of “wherein the data includes container identification data, container use, processing priority, container request resource, and affinity rule”, 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 think about and observe, judge and evaluate that the data includes container identification data, container use, processing priority, container request resource, and affinity rule. Moreover, this recites insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g). The courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Further, claim 3 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 3 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 3 does not recite patent eligible subject matter under 35 U.S.C. § 101.
14. With regard to claim 4, it recites additional abstract idea recitations of “wherein the scale mechanism performs scale determining of the container base, based on supply and demand forecast of resource in a production environment and data of resource of the container base, and prepares resource according to the supply and demand forecast,” 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 think about and observe, judge and evaluate that the scaling mechanism performs scale determining of the container base, based on the supply and demand forecast of resource in the production environment and data of resource of the container base, and prepares resource according to the supply and demand forecast. Moreover, this is merely applying the judicial exception or abstract idea. Therefore, this additional element does not integrate the judicial exception into a practical application. Further, claim 4 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 4 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
15. With regard to claim 5, it recites additional abstract idea recitations of “wherein the schedule mechanism determines whether the container can be deployed on the container base based on a container deploy request, when determining that the container can deploy, deploys the container on the container base, when determining that the container cannot deploy, determines whether container can be deployed to external resource, and deploys the container to the external resource if it is determined that the container can be deployed to the external resource,” 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 think about and observe, judge and evaluate that the container can deploy on the container base and deploys. Additionally, a person can think and observe, judge and evaluate that the container cannot be deployed on the container base and deploys the container to an external resource. Moreover, this is merely applying the judicial exception or abstract idea. Therefore, this additional element does not integrate the judicial exception into a practical application. Further, claim 5 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 5 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 5 does not recite patent eligible subject matter under 35 U.S.C. § 101.
16. With regard to claim 8, it recites additional abstract idea recitations of “A program causing a processor to execute the load distribution method according to claim 7.” A program that causes a processer to execute is no more than generic computing components and field of use/technological environment which do not amount to significantly more than the abstract idea. Further, claim 8 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 8 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 8 does not recite patent eligible subject matter under 35 U.S.C. § 101.
17. With regard to claim 9, it recites additional abstract idea recitations of “wherein the scale mechanism calculates the available resources (A) by, for each node, calculating a difference between node resources and a maximum of total container request values or average actual usage amounts, and summing the differences across all nodes, and wherein the scale mechanism further calculates a tendency (AA) of the available resources by subtracting a previous value of (A) from a current value of (A)” 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 think about and observe, judge and evaluate the calculation of available resources by calculating a difference between not resources and usage amounts and summing the differences across all nodes. Additionally, this recites a mathematical concept. The claim requires “average actual usage amounts, and sums the differences,” which are mathematical calculations. Further, claim 9 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 9 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 9 does not recite patent eligible subject matter under 35 U.S.C. § 101.
18. With regard to claim 10, it recites additional abstract idea recitations of “wherein when adding a node, the scale mechanism selects a node group by calculating surplus resources for each node group using formula Xcn = Ac + MIN(AAc, 0) + Cn - Bc for CPU and Xmn = Am + MIN(AAm, 0) + Mn - Bm for memory, where Ac and Am are available resources for CPU and memory respectively, AAc and AAm are tendencies of available resources, Cn and Mn are CPU amount and memory amount of one node in the node group, and Bc and Bm are CPU and memory request values based on the external data, and selects the node group that minimizes ((Xcn -Hc)/Cn + (Xmn - Hm)/Mn) x Yn, where He and Hm are threshold values for CPU and memory, and Yn is node cost”, 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 think about and observe, judge and evaluate the calculation of surplus resources by using a formula that takes in available resources and tendencies of resources as inputs. Additionally, this recites a mathematical concept. The claim requires “average actual usage amounts, and sums the differences,” which are mathematical calculations. Further, claim 10 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 10 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
19. With regard to claim 11, it recites additional abstract idea recitations of “wherein the scale mechanism excludes node groups that cannot satisfy deployment requirements based on affinity rules specified in the external data before determining whether to add or delete nodes”, 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 think about and observe, judge and evaluate that nodes are excluded if they do not satisfy certain rules. Additionally, this is merely applying the judicial exception or abstract idea. Therefore, this additional element does not integrate the judicial exception into a practical application. Further, claim 11 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 11 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 11 does not recite patent eligible subject matter under 35 U.S.C. § 101.
20. With regard to claim 12, it recites additional abstract idea recitations of “wherein the scale mechanism monitors actual resource usage of deployed containers on the container base over time, compares the actual resource usage against the total container request values to identify resource consumption patterns, and automatically adjusts node allocation by adding nodes when the actual resource usage exceeds a predetermined utilization threshold and deleting nodes when the actual resource usage falls below a predetermined minimum threshold, thereby dynamically optimizing the physical hardware resource allocation in the container base to reduce the operational costs while maintaining the service availability”, 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 think about and observe, judge and evaluate the comparison of actual resource usage and the total container request. This is a mere comparison. Moreover, “automatically adjusts node allocation by adding nodes when the actual resource usage exceeds a predetermined utilization threshold and deleting nodes when the actual resource usage falls below a predetermined minimum threshold, thereby dynamically optimizing the physical hardware resource allocation in the container base to reduce the operational costs while maintaining the service availability” is merely applying the judicial exception or abstract idea. Therefore, this additional element does not integrate the judicial exception into a practical application. Further, claim 12 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 12 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 12 does not recite patent eligible subject matter under 35 U.S.C. § 101.
21. With regard to claim 13, it recites additional abstract idea recitations of “wherein the schedule mechanism receives a container deployment request specifying resource requirements and affinity rules, queries the container base to determine available physical nodes that satisfy the affinity rules, calculates whether sufficient CPU and memory resources exist on the available physical nodes to accommodate the container, and when insufficient resources are available on the container base, transmits a notification to the scale mechanism to trigger addition of a physical node to the container base before deploying the container, thereby preventing deployment failures and service interruptions”, 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. Specifically, “wherein the schedule mechanism receives a container deployment request specifying resource requirements and affinity rules, queries the container base to determine available physical nodes that satisfy the affinity rules” merely recites insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g). The courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Moreover, “calculates whether sufficient CPU and memory resources exist on the available physical nodes to accommodate the container, and when insufficient resources are available on the container base, transmits a notification to the scale mechanism to trigger addition of a physical node to the container base before deploying the container, thereby preventing deployment failures and service interruptions” is merely applying the judicial exception or abstract idea. Therefore, this additional element does not integrate the judicial exception into a practical application. Further, claim 13 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 13 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 13 does not recite patent eligible subject matter under 35 U.S.C. § 101.
22. With regard to claim 14, it recites additional abstract idea recitations of “wherein the scale mechanism acquires node group data from the container base including CPU amount per node, memory amount per node, current node count, minimum node count, maximum node count, and node cost for each node group, excludes node groups that fail to satisfy affinity rules specified in the external data, calculates surplus resource costs for remaining node groups based on formula ((Xcn - Hc)/Cn + (Xmn - Hm)/Mn) x Yn where Xcn and Xmn represent surplus CPU andmemory resources respectively, He and Hm represent threshold values, Cn and Mn represent CPU and memory amounts per node, and Yn represents node cost, and selects the node group with lowest surplus resource cost for node addition, thereby minimizing infrastructure costs while ensuring adequate resources for container deployment”, 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. Specifically, “wherein the scale mechanism acquires node group data from the container base including CPU amount per node, memory amount per node, current node count, minimum node count, maximum node count, and node cost for each node group, excludes node groups that fail to satisfy affinity rules specified in the external data” merely recites insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g). The courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Moreover, “calculates surplus resource costs for remaining node groups based on formula ((Xcn - Hc)/Cn + (Xmn - Hm)/Mn) x Yn where Xcn and Xmn represent surplus CPU andmemory resources respectively, He and Hm represent threshold values, Cn and Mn represent CPU and memory amounts per node, and Yn represents node cost” recites a mathematical concept. Lastly, “selects the node group with lowest surplus resource cost for node addition, thereby minimizing infrastructure costs while ensuring adequate resources for container deployment” is merely applying the judicial exception or abstract idea. Therefore, this additional element does not integrate the judicial exception into a practical application. Further, claim 14 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 14 also fails both Step 2A prong 2, 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 than the abstract idea. Therefore, Claim 14 does not recite patent eligible subject matter under 35 U.S.C. § 101.
23. Therefore, Claims 1-14 do 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.
24. Claims 1, 3-4, 6-10, and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. US 20150381711 A1 in view of Neuse et al. US 20140019966 A1, and in further view of Wang et al. US 20200241903 A1.
25. With regard to claim 1, Singh teaches:
A load distribution apparatus, comprising:
a schedule mechanism that deploys container to node in container base ([0013] Deploying a multi-tiered application in a cloud computing environment may involve a cloud computing platform provider (e.g., VMware) providing a deployment environment to provision virtual computing resources (e.g., virtual machines (VMs)) in which an enterprise (e.g., an organization, an agency, a corporation, etc.) can deploy its application; [0050] The deployment monitor 302 of the illustrated example may initiate a scaling operation according to a schedule; Examiner’s Note: Application = container, node = node, and cloud computing environment = container base.), and
a scale mechanism that acquires resource data from the container base, wherein the scale mechanism acquires external data about container to be deployed on the container base ([0020] In the illustrated example of FIG. 1, the example topology generator 118 generates an example application blueprint 126 specifying a logical topology of the application 108, which is to be deployed. The example blueprint 126 maps the structure of the application 108 as a collection of nodes. Application components may be added to each node to specify which application components are executing on the node. For example, the topology generator 118 may generate a blueprint 126 (e.g., a topology map) for an online store application specifying a web application executing on an application server (e.g., an Apache Tomcat application server) that uses a data store as a database (e.g., a MongoDB). The example web application may be implemented by a Java web application archive (e.g., a “WAR” file) comprising dynamic web pages, static web pages, Java servlets, Java classes, and/or other properties, configuration information and/or resource files included in the Java web application. In the illustrated example, the blueprint 126 is an abstract representation of the structure of the application 108 including virtual machines and their corresponding application components, operating systems, dependencies and/or configurations. In some examples, the blueprint 126 standardizes the structure of an application for repeated deployments in multiple and/or diverse deployment environments. The application 108 may alternatively describe the entire online store application, including application server components and database components, rather than just the web application itself; Examiner’s Note: Paragraph [002] talks about external data; [0021] In the illustrated example of FIG. 1, the topology generator 118 retrieves virtual computing resources from an example catalog 120 to assemble the blueprint 126. For example, the catalog 120 may list virtual computing resources (e.g., virtual machines, networking resources, storage resources, etc.) that may be provisioned from the cloud computing platform provider 110 and corresponding application components (e.g., software services, scripts, code components, application-specific packages, etc.) that may be installed on the provisioned virtual computing resources. The example catalog 120 of the illustrated example is pre-populated with available virtual computing resources and/or application components; Examiner’s Note: Paragraph [0021] talks about resource data from the container base.),
calculates available resources of the container base by determining, for each node, a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes ([0047] In the illustrated example of FIG. 3, the example deployment monitor 302 monitors deployment environments (e.g., dependent environment 112 of FIG. 1) and determines whether to initiate a scaling operation and to what extent. For example, the deployment monitor 302 may monitor infrastructure resource consumption levels and requirements (e.g., workload) of the deployed application 108 in the deployment environment 112. In some examples, the deployment monitor 302 may compare resource utilization by the application 108 workload to utilization ranges. For example, the deployment monitor 302 may initiate a scale-in operation when resource utilization by the workload is in a first range (e.g., less than 25% utilization), may initiate a scale-out operation when resource utilization by the workload is in a second range (e.g., greater than 75% utilization), and may perform no scaling operation when resource utilization by the workload is in a third range (e.g., greater than or equal to 25% utilization and less than or equal to 75% utilization). In some examples, the deployment monitor 302 may compare the workload to one or more thresholds and scale the number of virtual machines (e.g., sub-nodes) executing the workload accordingly (e.g., increase or decrease the cluster size of a node); [0048] For example, when the deployment monitor 302 of the illustrated example determines that the resource utilization by the workload satisfies a first threshold, the example deployment monitor 302 initiates a scale-out operation to add (e.g., provision) one or more virtual machines to the deployment environment. For example, the example deployment monitor 302 may initiate a first scale-out operation to provision one additional virtual machine 114 when resource utilization by the workload exceeds 75% of available resources, the example deployment monitor 302 may initiate a second scale-out operation to provision a second virtual machine 114 when resource utilization by the workload exceeds 85% of available resources, etc; Examiner’s Note: The deployment monitor calculates available resources.),
determines resource of the container base based on the resource data and the external data using a first threshold value defining minimum remaining available resources and a second threshold value defining allowable available resources ([0047] In the illustrated example of FIG. 3, the example deployment monitor 302 monitors deployment environments (e.g., dependent environment 112 of FIG. 1) and determines whether to initiate a scaling operation and to what extent. For example, the deployment monitor 302 may monitor infrastructure resource consumption levels and requirements (e.g., workload) of the deployed application 108 in the deployment environment 112. In some examples, the deployment monitor 302 may compare resource utilization by the application 108 workload to utilization ranges. For example, the deployment monitor 302 may initiate a scale-in operation when resource utilization by the workload is in a first range (e.g., less than 25% utilization), may initiate a scale-out operation when resource utilization by the workload is in a second range (e.g., greater than 75% utilization), and may perform no scaling operation when resource utilization by the workload is in a third range (e.g., greater than or equal to 25% utilization and less than or equal to 75% utilization). In some examples, the deployment monitor 302 may compare the workload to one or more thresholds and scale the number of virtual machines (e.g., sub-nodes) executing the workload accordingly (e.g., increase or decrease the cluster size of a node); [0069] It, at block 408, the deployment monitor 302 determines that the deployed application 108 workload does not satisfy the “high” utilization criterion and/or threshold, then, at block 412, the deployment monitor 302 determines whether the resource utilization for the deployed application 108 is “low.” For example, the deployment monitor 302 may compare the deployed application 108 workload to a “low” utilization criterion and/or threshold such as utilization values less than 25% utilization of available resources. If, at block 412, the deployment monitor 302 determines that the deployed application 108 workload satisfies the “low” utilization criterion and/or threshold, then, at block 414, the deployment monitor 302 initiates a scale-in operation. For example, the deployment monitor 302 may alert the example scale-in handler 304 to decrease a cluster node size by two virtual machines. Control then proceeds to block 416 to determine whether to continue monitoring deployment of the application 108 in the deployment environment 112; Examiner’s Note: The low utilization criterion and/or threshold corresponds to the first threshold, and the high utilization criterion and/or threshold corresponds to the second threshold.),
deletes node of the container base if it is determined that the resource is excessive, and adds node of the container base if it is determined that shortage of the resource, thereby dynamically optimizing physical hardware resource allocation in the container base to reduce operational costs while maintaining service availability ([0013] In situations, when workloads decrease, the enterprise may be paying for idle or underutilized virtual computing resources to which workloads are no longer assigned. In contrast, when workloads increase, the enterprise performance may decrease as a result of providing slower services to customers as the virtual computing resources are overloaded; [0014] To more efficiently use resources in a virtual computing environment, examples disclosed herein enable scaling in and scaling out processes. For example, resources (e.g., virtual machines, networking resources, storage resources, etc.) may be allocated (e.g., scaled-out) for use by a virtual computing node when workloads increase at the computing node. In addition, resources can be freed (e.g., scaled-in) from the computing node when workloads decrease at that computing node. In this manner, resources are not inefficiently sitting idle at a virtual computing node when, for example, the node has no need for those resources. Also, the virtual computing node is allocated additional resources when needed to, for example, address increased workloads; [0069] It, at block 408, the deployment monitor 302 determines that the deployed application 108 workload does not satisfy the “high” utilization criterion and/or threshold, then, at block 412, the deployment monitor 302 determines whether the resource utilization for the deployed application 108 is “low.” For example, the deployment monitor 302 may compare the deployed application 108 workload to a “low” utilization criterion and/or threshold such as utilization values less than 25% utilization of available resources. If, at block 412, the deployment monitor 302 determines that the deployed application 108 workload satisfies the “low” utilization criterion and/or threshold, then, at block 414, the deployment monitor 302 initiates a scale-in operation. For example, the deployment monitor 302 may alert the example scale-in handler 304 to decrease a cluster node size by two virtual machines. Control then proceeds to block 416 to determine whether to continue monitoring deployment of the application 108 in the deployment environment 112.).
While Singh teaches available resources, which reasonably teaches the resources that are able to be used, it does not teach calculating available resources using a difference.
However, in analogous art, Neuse teaches:
a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes ([0090] As for the VMs deployed on the host, each VM raw consumption is the raw consumption of CPU resources by a VM excluding guest OS overhead and represented in portable units. The VM raw consumption is the resource consumption that is moved to or from a host during a placement process. VMM efficiency is inherent to the host and is recomputed during placement moves. VM guest OS overhead is unique to each VM and represents the effect of Guest OS scalability on a VM. In practice it is estimated as a function of the virtual processor states for the VM and empirical scalability characteristics of the VM Guest OS. The raw VM consumptions are compensated for VM Guest OS to determine a total CM consumption where the raw VM consumptions for a set of VMs, VM through VM.sub.N, deployed on the host and their estimated Guest OS overhead consumptions are all summed together as a total VM consumption 96, QVM; of the available capacity on the host. CPU capacity headroom 95 is total VM consumption 96 subtracted from available capacity 94. For the objective function, CPU capacity headroom 95 is normalized by available resource capacity 94 to a scale of 0 (zero) to 1 (one); (CA-QVM)/CA, is a metric for establishing a placement score; [0108] At step 107, a threshold score is determined. From FIG. 7, a placement score is related to a difference (headroom) between capacity and consumption. The input to step 107 is the target configuration including a target set of hosts with associated host capacities and a target set of VMs with associated VM resource consumptions. The placement score is generally and preferably computed as the minimum normalized headroom in a cloud computing environment across all resources, all time intervals, all hosts and all clusters. If the optimal placement and an achievable score were known, then the threshold score could be computed from the achievable score. However, it is not practical to find the optimal placement. Instead, an ideal score is calculated from an aggregate "headroom" as MIN(1-Qtot/Ctot) where Ctot is the total available capacity of the target set of hosts and Qtot is the total VM resource consumption over the target set of virtual machines for each resource in a set of resources The aggregate value (1-Qtot/Ctot) is the normalized difference between Ctot and Qtot, normalized by dividing the difference between the total available capacity and the total VM resource consumption by the total available capacity. The minimum is taken over the set of hosts and the set of resources and the defined set of time intervals. The threshold score is taken as a pre-configured fraction of the ideal score.),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh with the teachings of Neuse where determining available resources includes calculating a difference between node resources and a maximum of total container request values or average actual usage amounts, and sums the differences across the nodes. Similarly to Singh, Neuse teaches of reconfiguring a computing environment by measuring resource utilization (Abstract). It would make sense that in order to calculate the available resources, one would need to find the difference between node resources and average actual usage amounts. Therefore, together, Singh and Neuse teach of calculating available resources, comparing resource usage to a first and second threshold, and add/delete nodes accordingly.
Additionally, although Singh and Neuse teach calculating available resources, comparing resource usage to a first and second threshold, and add/delete nodes accordingly, both fail to explicitly teach the idea of containers. Singh teaches the idea of deploying an application in a cloud computing environment.
However, in analogous art, Wang teaches:
[0026] OS virtualization is also referred to herein as container virtualization. As used herein, OS virtualization refers to a system in which processes are isolated in an OS. In a typical OS virtualization system, a host OS is installed on the server hardware. Alternatively, the host OS can be installed in a VM of a full virtualization environment or a paravirtualization environment. The host OS of an OS virtualization system is configured (e.g., utilizing a customized kernel, etc.) to provide isolation and resource management for processes that execute within the host OS (e.g., applications that execute on the host OS, etc.). The isolation of the processes is known as a container. Thus, a process executes within a container that isolates the process from other processes executing on the host OS. Thus, OS virtualization provides isolation and resource management capabilities without the resource overhead utilized by a full virtualization environment or a paravirtualization environment. Example OS virtualization environments include Linux Containers LXC and LXD, the DOCKER™ container platform, the OPENVZ™ container platform, etc. Example container orchestration managers include Kubernetes® K8S™ that coordinate and schedule the deployment and execution of containers associated with a distributed application (e.g., a containerized application). As used herein, the term “containerized application” refers to one or more isolated applications or services executing on a single host that have access to the same OS kernel. As used herein, the term “application containerization” refers to an OS-level virtualization method used to deploy and run distributed applications without launching an entire VM for each one of the distributed applications.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh and Neuse with the teachings of Wang that applications and containers refer to the same thing. Therefore, Singh, Neuse, and Wang teach calculating available resources, comparing resource usage to a first and second threshold, and add/delete nodes accordingly in order to deploy a container to a node in a container base.
26. With regard to claim 3, Singh further teaches:
wherein the data includes container identification data, container use, processing priority, container request resource, and affinity rule ([0020] In the illustrated example of FIG. 1, the example topology generator 118 generates an example application blueprint 126 specifying a logical topology of the application 108, which is to be deployed. The example blueprint 126 maps the structure of the application 108 as a collection of nodes. Application components may be added to each node to specify which application components are executing on the node. For example, the topology generator 118 may generate a blueprint 126 (e.g., a topology map) for an online store application specifying a web application executing on an application server (e.g., an Apache Tomcat application server) that uses a data store as a database (e.g., a MongoDB). The example web application may be implemented by a Java web application archive (e.g., a “WAR” file) comprising dynamic web pages, static web pages, Java servlets, Java classes, and/or other properties, configuration information and/or resource files included in the Java web application. In the illustrated example, the blueprint 126 is an abstract representation of the structure of the application 108 including virtual machines and their corresponding application components, operating systems, dependencies and/or configurations. In some examples, the blueprint 126 standardizes the structure of an application for repeated deployments in multiple and/or diverse deployment environments. The application 108 may alternatively describe the entire online store application, including application server components and database components, rather than just the web application itself; [0021] In the illustrated example of FIG. 1, the topology generator 118 retrieves virtual computing resources from an example catalog 120 to assemble the blueprint 126. For example, the catalog 120 may list virtual computing resources (e.g., virtual machines, networking resources, storage resources, etc.) that may be provisioned from the cloud computing platform provider 110 and corresponding application components (e.g., software services, scripts, code components, application-specific packages, etc.) that may be installed on the provisioned virtual computing resources. The example catalog 120 of the illustrated example is pre-populated with available virtual computing resources and/or application components. In some examples, an administrator 106 (e.g., an information technology (IT) administrator, a system administrator, etc.) customizes the catalog 120 by adding and/or modifying the available virtual computing resources and/or application components listed in the catalog 120. For example, the administrator 106 may enter specifications, configurations, properties, custom tasks, etc. about each entry in the catalog 120. The example blueprint 126 of the illustrated example includes an installation order for the application components during deployment. For example, the blueprint 126 may define dependencies between one or more of the application components. For example, the developer 104 may specify a dependency from an Apache service (e.g., a load balancer) to an application code package such as a web application. In some such examples, the dependency may be that the load balancer may not be configured until installation of the web application is complete.).
27. With regard to claim 4, Singh further teaches:
wherein the scale mechanism performs scale determining of the container base, based on [[the]] supply and demand forecast of resource in [[the]] production environment and data of resource of the container base, and prepares resource according to the supply and demand forecast ([0047] In the illustrated example of FIG. 3, the example deployment monitor 302 monitors deployment environments (e.g., dependent environment 112 of FIG. 1) and determines whether to initiate a scaling operation and to what extent. For example, the deployment monitor 302 may monitor infrastructure resource consumption levels and requirements (e.g., workload) of the deployed application 108 in the deployment environment 112. In some examples, the deployment monitor 302 may compare resource utilization by the application 108 workload to utilization ranges. For example, the deployment monitor 302 may initiate a scale-in operation when resource utilization by the workload is in a first range (e.g., less than 25% utilization), may initiate a scale-out operation when resource utilization by the workload is in a second range (e.g., greater than 75% utilization), and may perform no scaling operation when resource utilization by the workload is in a third range (e.g., greater than or equal to 25% utilization and less than or equal to 75% utilization). In some examples, the deployment monitor 302 may compare the workload to one or more thresholds and scale the number of virtual machines (e.g., sub-nodes) executing the workload accordingly (e.g., increase or decrease the cluster size of a node); [0069] It, at block 408, the deployment monitor 302 determines that the deployed application 108 workload does not satisfy the “high” utilization criterion and/or threshold, then, at block 412, the deployment monitor 302 determines whether the resource utilization for the deployed application 108 is “low.” For example, the deployment monitor 302 may compare the deployed application 108 workload to a “low” utilization criterion and/or threshold such as utilization values less than 25% utilization of available resources. If, at block 412, the deployment monitor 302 determines that the deployed application 108 workload satisfies the “low” utilization criterion and/or threshold, then, at block 414, the deployment monitor 302 initiates a scale-in operation. For example, the deployment monitor 302 may alert the example scale-in handler 304 to decrease a cluster node size by two virtual machines. Control then proceeds to block 416 to determine whether to continue monitoring deployment of the application 108 in the deployment environment 112; Examiner’s Note: The deployment manager adjusts the nodes based on resource utilization. For example, if resources are not being used as much, a scale-in operation is called. This reflects supply and demand because the size of the nodes is dynamically adjusted based on if more/less nodes are needed.).
28. Regarding claim 6, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
29. Regarding claim 7, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
30. With regard to claim 8, Singh further teaches:
A program causing a processor to execute the load distribution method according to claim 7 ([0065] Flowcharts representative of example machine readable instructions for implementing the scaling handler 130 of FIGS. 1 and/or 3 are shown in FIGS. 4-6. In this example, the machine readable instructions comprise a program for execution by a processor such as the processor 912 shown in the example processor platform 900 discussed below in connection with FIG. 9.).
31. With regard to claim 9, Neuse further teaches:
wherein the scale mechanism calculates the available resources (A) by, for each node, calculating a difference between node resources and a maximum of total container request values or average actual usage amounts, and summing the differences across all nodes, and wherein the scale mechanism further calculates a tendency (AA) of the available resources by subtracting a previous value of (A) from a current value of (A) ([0090] As for the VMs deployed on the host, each VM raw consumption is the raw consumption of CPU resources by a VM excluding guest OS overhead and represented in portable units. The VM raw consumption is the resource consumption that is moved to or from a host during a placement process. VMM efficiency is inherent to the host and is recomputed during placement moves. VM guest OS overhead is unique to each VM and represents the effect of Guest OS scalability on a VM. In practice it is estimated as a function of the virtual processor states for the VM and empirical scalability characteristics of the VM Guest OS. The raw VM consumptions are compensated for VM Guest OS to determine a total CM consumption where the raw VM consumptions for a set of VMs, VM through VM.sub.N, deployed on the host and their estimated Guest OS overhead consumptions are all summed together as a total VM consumption 96, QVM; of the available capacity on the host. CPU capacity headroom 95 is total VM consumption 96 subtracted from available capacity 94. For the objective function, CPU capacity headroom 95 is normalized by available resource capacity 94 to a scale of 0 (zero) to 1 (one); (CA-QVM)/CA, is a metric for establishing a placement score; [0108] At step 107, a threshold score is determined. From FIG. 7, a placement score is related to a difference (headroom) between capacity and consumption. The input to step 107 is the target configuration including a target set of hosts with associated host capacities and a target set of VMs with associated VM resource consumptions. The placement score is generally and preferably computed as the minimum normalized headroom in a cloud computing environment across all resources, all time intervals, all hosts and all clusters. If the optimal placement and an achievable score were known, then the threshold score could be computed from the achievable score. However, it is not practical to find the optimal placement. Instead, an ideal score is calculated from an aggregate "headroom" as MIN(1-Qtot/Ctot) where Ctot is the total available capacity of the target set of hosts and Qtot is the total VM resource consumption over the target set of virtual machines for each resource in a set of resources The aggregate value (1-Qtot/Ctot) is the normalized difference between Ctot and Qtot, normalized by dividing the difference between the total available capacity and the total VM resource consumption by the total available capacity. The minimum is taken over the set of hosts and the set of resources and the defined set of time intervals. The threshold score is taken as a pre-configured fraction of the ideal score; [0119] At step 128, the method determines the resource capacities comprising: raw capacity, ideal capacity, host effective capacity and available capacity in portable units for a resource R and host H. Step 128 is accomplished by mapping the total VM consumption for host H and the given machine configuration into a resource capacity C.sub.A(H,R) for the given resource by looking up the given machine configuration and the total VM consumption in the pre-computed host capacity lookup table from step 105. In other embodiments, a functional mapping is performed as described in step 105. The determination of resource capacity is done only for source virtual and physical machines whose configurations have changed during the long-term past; Examiner’s Note: The determination of resource capacity for configurations have changed during the long-term past represent a tendency.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh with the teachings of Neuse wherein the scale mechanism calculates the available resources (A) by, for each node, calculating a difference between node resources and a maximum of total container request values or average actual usage amounts, and summing the differences across all nodes, and wherein the scale mechanism further calculates a tendency (AA) of the available resources by subtracting a previous value of (A) from a current value of (A). By calculating the tendency of resources, the system can solve the problem of size, complexity, and rate of change of resource consumption inhibiting VM assignment to hosts (Abstract). Taking into account the tendency of resources helps dynamically assign VMs to proper hosts that have adequate resources to execute them.
32. With regard to claim 10, Neuse further teaches:
wherein when adding a node, the scale mechanism selects a node group by calculating surplus resources for each node group using formula Xcn = Ac + MIN(AAc, 0) + Cn - Bc for CPU and Xmn = Am + MIN(AAm, 0) + Mn - Bm for memory, where Ac and Am are available resources for CPU and memory respectively, AAc and AAm are tendencies of available resources, Cn and Mn are CPU amount and memory amount of one node in the node group, and Bc and Bm are CPU and memory request values based on the external data, and selects the node group that minimizes ((Xcn -Hc)/Cn + (Xmn - Hm)/Mn) x Yn, where He and Hm are threshold values for CPU and memory, and Yn is node cost ([0061] A physical server in the set of physical servers 6 comprises a set of resources 6r, including but not limited to CPU, memory, network interface and operating system resources; [0149] In an embodiment for handling excess capacity, a user specifies a minimum capacity M.sub.Spare to be available as spare host capacity and a threshold host capacity to remove, M.sub.Remove in units of host capacity C.sub.host(R). A number of hosts to remove NHostsRemove is computed at step 388 and compared to M.sub.Remove. If NhostsRemove is greater than M.sub.Remove, then step 392 is performed and NhostRemove host servers are removed from the target set of hosts.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh with the teachings of Neuse wherein when adding a node, the scale mechanism selects a node group by calculating surplus resources for each node group using formula Xcn = Ac + MIN(AAc, 0) + Cn - Bc for CPU and Xmn = Am + MIN(AAm, 0) + Mn - Bm for memory, where Ac and Am are available resources for CPU and memory respectively, AAc and AAm are tendencies of available resources, Cn and Mn are CPU amount and memory amount of one node in the node group, and Bc and Bm are CPU and memory request values based on the external data, and selects the node group that minimizes ((Xcn -Hc)/Cn + (Xmn - Hm)/Mn) x Yn, where He and Hm are threshold values for CPU and memory, and Yn is node cost. By calculating surplus resources, the system can solve the problem of size, complexity, and rate of change of resource consumption inhibiting VM assignment to hosts (Abstract). Taking into account the surplus of resources helps dynamically assign VMs to proper hosts, and ensure that the system is not inefficiently allocating unused resources.
33. With regard to claim 12, Singh further teaches:
wherein the scale mechanism monitors actual resource usage of deployed containers on the container base over time, compares the actual resource usage against the total container request values to identify resource consumption patterns, and automatically adjusts node allocation by adding nodes when the actual resource usage exceeds a predetermined utilization threshold and deleting nodes when the actual resource usage falls below a predetermined minimum threshold, thereby dynamically optimizing the physical hardware resource allocation in the container base to reduce the operational costs while maintaining the service availability ([0013] In situations, when workloads decrease, the enterprise may be paying for idle or underutilized virtual computing resources to which workloads are no longer assigned. In contrast, when workloads increase, the enterprise performance may decrease as a result of providing slower services to customers as the virtual computing resources are overloaded; [0014] To more efficiently use resources in a virtual computing environment, examples disclosed herein enable scaling in and scaling out processes. For example, resources (e.g., virtual machines, networking resources, storage resources, etc.) may be allocated (e.g., scaled-out) for use by a virtual computing node when workloads increase at the computing node; [0067] The example program of FIG. 4 determines whether to scale an application 108 (FIGS. 1 and/or 3) deployed in a deployment environment 112 (FIGS. 1 and/or 3). The example program of FIG. 4 begins at block 402 when the example deployment monitor 302 (FIG. 3) determines whether a scaling operation is scheduled to be performed. For example, the deployment monitor 302 may compare the current date and/or time to scheduled periods defined for a scale-out operation (e.g., during work hours) and/or a scale-in operation (e.g., over the weekend). If, at block 402, the deployment monitor 302 determines that a scaling operation is scheduled to be performed, then, at block 404, the deployment monitor 302 initiates the corresponding scaling operation. For example, the deployment monitor 302 may send a message to the example scale-in handler 304 (FIG. 3) to schedule a scale-in operation for 5:00 pm on Fridays, and may send a message to the example scale-out handler 320 (FIG. 3) to initiate a scale-out operation for 8:00 am on Mondays. Control then proceeds to block 416 to determine whether to continue monitoring deployment of the application 108 in the deployment environment 112.).
34. With regard to claim 13, Singh further teaches:
wherein the schedule mechanism receives a container deployment request specifying resource requirements and affinity rules, queries the container base to determine available physical nodes that satisfy the affinity rules, calculates whether sufficient CPU and memory resources exist on the available physical nodes to accommodate the container, and when insufficient resources are available on the container base, transmits a notification to the scale mechanism to trigger addition of a physical node to the container base before deploying the container, thereby preventing deployment failures and service interruptions ([0013] When the application is deployed, workloads (e.g., schedules/collections of one or more processes or tasks) assigned to virtual computing resources may change over time. In situations, when workloads decrease, the enterprise may be paying for idle or underutilized virtual computing resources to which workloads are no longer assigned. In contrast, when workloads increase, the enterprise performance may decrease as a result of providing slower services to customers as the virtual computing resources are overloaded; [0014] To more efficiently use resources in a virtual computing environment, examples disclosed herein enable scaling in and scaling out processes. For example, resources (e.g., virtual machines, networking resources, storage resources, etc.) may be allocated (e.g., scaled-out) for use by a virtual computing node when workloads increase at the computing node. In addition, resources can be freed (e.g., scaled-in) from the computing node when workloads decrease at that computing node. In this manner, resources are not inefficiently sitting idle at a virtual computing node when, for example, the node has no need for those resources. Also, the virtual computing node is allocated additional resources when needed to, for example, address increased workloads; [0021] In the illustrated example of FIG. 1, the topology generator 118 retrieves virtual computing resources from an example catalog 120 to assemble the blueprint 126. For example, the catalog 120 may list virtual computing resources (e.g., virtual machines, networking resources, storage resources, etc.) that may be provisioned from the cloud computing platform provider 110 and corresponding application components (e.g., software services, scripts, code components, application-specific packages, etc.) that may be installed on the provisioned virtual computing resources. The example catalog 120 of the illustrated example is pre-populated with available virtual computing resources and/or application components. In some examples, an administrator 106 (e.g., an information technology (IT) administrator, a system administrator, etc.) customizes the catalog 120 by adding and/or modifying the available virtual computing resources and/or application components listed in the catalog 120. For example, the administrator 106 may enter specifications, configurations, properties, custom tasks, etc. about each entry in the catalog 120. The example blueprint 126 of the illustrated example includes an installation order for the application components during deployment. For example, the blueprint 126 may define dependencies between one or more of the application components. For example, the developer 104 may specify a dependency from an Apache service (e.g., a load balancer) to an application code package such as a web application. In some such examples, the dependency may be that the load balancer may not be configured until installation of the web application is complete; [0022] In the illustrated example of FIG. 1, the deployment plan generator 122 generates an example deployment plan 128 based on the blueprint 126. The example deployment plan 128 includes deployment settings (e.g., state information such as virtual computing resource cluster sizes, processing resources, memory, networking resources, etc.) and an execution plan identifying tasks having an order in which virtual computing resources are provisioned and application components are installed, configured, and started. The example deployment plan 128 of the illustrated example is a process-oriented view of the blueprint 126. For example, the administrator 106 may follow discrete steps included in the deployment plan 128 to deploy the application 108. In some examples, different deployment plans 128 may be generated from a single blueprint 126 to test prototypes (e.g., new application versions), to scale (e.g., scale-out or scale-in) deployments, and/or to deploy the application 108 to different deployment environments (e.g., testing environments, staging environments, production environments, etc.); [0069] It, at block 408, the deployment monitor 302 determines that the deployed application 108 workload does not satisfy the “high” utilization criterion and/or threshold, then, at block 412, the deployment monitor 302 determines whether the resource utilization for the deployed application 108 is “low.” For example, the deployment monitor 302 may compare the deployed application 108 workload to a “low” utilization criterion and/or threshold such as utilization values less than 25% utilization of available resources. If, at block 412, the deployment monitor 302 determines that the deployed application 108 workload satisfies the “low” utilization criterion and/or threshold, then, at block 414, the deployment monitor 302 initiates a scale-in operation. For example, the deployment monitor 302 may alert the example scale-in handler 304 to decrease a cluster node size by two virtual machines. Control then proceeds to block 416 to determine whether to continue monitoring deployment of the application 108 in the deployment environment 112.).
35. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. US 20150381711 A1; Neuse et al. US 20140019966 A1; and Wang et al. US 20200241903 A1, as applied in claim 1, in further view of Atkinson et al. US 10120670 B1.
36. With regard to claim 2, Singh, Neuse, and Wang teach the load distribution apparatus according to claim 1 but fail to explicitly teach wherein as the external data, the scale mechanism acquires data about container to be deployed from CI/CD pipeline in development environment.
However, in analogous art, Atkinson teaches:
wherein as the external data, the scale mechanism acquires data about container to be deployed from CI/CD pipeline in development environment (Col. 4, lines 9-16, Systems and methods described herein may enable creation, testing, and/or deployment of generic pipelines, providing the ability to easily switch between CI/CD tools. Pipelines may be placed in containers that are portable to different CI/CD tools. The pipelines themselves may include generic scripts that can operate on a variety of different applications and may include generic and/or specific code that makes the pipeline functionality work; Examiner’s Note: Containers are deployed from CI/CD pipeline.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh, Neuse, and Wang with the teachings of Atkinson wherein as the external data, the scale mechanism acquires data about container to be deployed from CI/CD pipeline in development environment. This allows the container 110 to include everything required for execution of the pipeline (e.g., all source code). That is, when container 110 is distributed to a CI/CD platform environment, and the environment executes a command to run the program inside container 110, container 110 may be able to provide the pipeline functionality regardless of the environment in which it is deployed, as discussed in Atkinson (Col. 8, lines 26-32). Therefore, allowing for deployment of the container in a variety of environments.
37. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. US 20150381711 A1; Neuse et al. US 20140019966 A1; and Wang et al. US 20200241903 A1, as applied in claim 1, in further view of Chou et al. US 9577916 B1.
38. With regard to claim 5, Singh, Neuse, and Wang teach the load distribution apparatus according to claim 1 but fail to explicitly teach wherein the schedule mechanism determines whether the container can be deployed on the container base based on a container deploy request.
However, in analogous art, Chou teaches:
wherein the schedule mechanism determines whether the container can be deployed on the container base based on a container deploy request (Col. 7, lines 22-43, Specifically, the user-defined gateway functions program 108A, 108B (FIG. 1) may register the user-defined plugin containers 204a, 204b, and 204c on the gateway 206, and may also register user-defined routing policies associated with the user-defined plugin containers 204a, 204b, and 204c on the gateway 206 to enable the gateway 206 to recognize the user-defined plugin containers 204a, 204b, and 204c and to route incoming transactions 214 to the user-defined plugin containers 204a, 204b, and 204c. Also, using the plugin controller 208, the user-defined gateway functions program 108A, 108B (FIG. 1) may register external computing resources, such as virtual machines (not shown), to the gateway 206 to enable the gateway to externally run the user-defined plugin containers 204a, 204b, and 204c on the external computing resources. Furthermore, using the plugin controller 208, the user-defined gateway functions program 108A, 108B (FIG. 1) may activate the user-defined routing policies by implementing the user-defined routing policies for the user-defined plugin containers 204a, 204b, and 204c to route incoming transactions 214 to the user-defined plugin containers 204a, 204b, and 204c; Col. 9, lines 26-38, Then, at 310, the user-defined gateway functions program 108A, 108B (FIG. 1) may receive transactions 214 (FIG. 2) via the gateway 206 (FIG. 2). Specifically, and as previously described in FIG. 2, the user-defined gateway functions program 108A, 108B (FIG. 1) may receive transactions 214 (FIG. 2) via routing nodes 210 (FIG. 2) that are associated with a router 212 (FIG. 2) on the gateway 206 (FIG. 2). For example, the user-defined gateway functions program 108A, 108B (FIG. 1) may receive transactions 214 (FIG. 2), such as http requests, via routing nodes 210 (FIG. 2) on a router 212 (FIG. 2) that is associated with a gateway 206 (FIG. 2), such as an http proxy gateway, to control the amount of http requests received by the gateway 206 (FIG. 2); Col. 10, lines 16-23, Therefore, using the rate-limiting plugin container, the user-defined gateway functions program 108A, 108B (FIG. 1) may process the received http requests 214 (FIG. 2) and determine whether the number of http requests 214 (FIG. 2) has exceeded the user-defined threshold before presenting the http requests 214 (FIG. 2) to backend devices, such as a server 112 (FIG. 1).),
when determining that the container can deploy, deploys the container on the container base (Col. 7, lines 44-48, Then, using the plugin controller 208, the user-defined gateway functions program 108A, 108B (FIG. 1) may deploy the user-defined plugin containers 204a, 204b, and 204c locally on the gateway 206 and/or externally on the registered external computing resources; Examiner’s Note: Containers can be deployed locally on the gateway, which is analogous with the container base.),
when determining that the container cannot deploy, determines whether container can be deployed to external resource, and deploys the container to the external resource if it is determined that the container can be deployed to the external resource (Col. 7, lines 48-52, For example, the user-defined gateway functions program 108A, 108B (FIG. 1) may deploy the user-defined plugin containers 204a and 204b on the gateway 206, and also deploy the user-defined plugin container 204c on an external computing resource.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh, Neuse, and Wang with the teachings of Chou wherein the schedule mechanism determines whether the container can be deployed on the container base based on a container deploy request, when determining that the container can deploy, deploys the container on the container base, when determining that the container cannot deploy, determines whether container can be deployed to external resource, and deploys the container to the external resource if it is determined that the container can be deployed to the external resource. Chou teaches of deploying containers on a gateway or on an external computing resource (Col. 7, lines 48-52). This allows for optimal resource usage and maximizes resource availability; therefore, ensuring scalability.
39. Claims 11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. US 20150381711 A1; Neuse et al. US 20140019966 A1; and Wang et al. US 20200241903 A1, as applied in claim 1, in further view of Sehgal et al. US 20220350656 A1.
40. With regard to claim 11, Singh, Neuse, and Wang teach the load distribution apparatus according to claim 1 but fail to explicitly teach wherein the scale mechanism excludes node groups that cannot satisfy deployment requirements based on affinity rules specified in the external data before determining whether to add or delete nodes.
However, in analogous art, Sehgal teaches:
wherein the scale mechanism excludes node groups that cannot satisfy deployment requirements based on affinity rules specified in the external data before determining whether to add or delete nodes ([0027] The set of rules 216B may further specify that if the amount of time that has elapsed since the preceding attempt is less than or equal to the threshold amount of time, the scheduler service 217 may not attempt to schedule the pod on a node 131 that was the subject of the preceding attempt to schedule the pod 220. Stated differently, the scheduler service 217 may attempt to schedule the pod 220 based on the default security policy (e.g., using the default predicates) and the resource requirements of the pod 220 but may exclude the node 131 that was the subject of the preceding attempt to schedule the pod 220 from consideration; [0037] At block 510, if the amount of time that has elapsed since the preceding attempt is less than or equal to the threshold amount of time, then at block 515 the scheduler service 217 may exclude a node 131 that was the subject of the preceding attempt to schedule the pod 220 from scheduling consideration. At block 520, the scheduler service 217 may attempt to schedule the pod 220 based on the default security policy (e.g., using the default predicates) and the resource requirements of the pod 220 but may exclude the node 131 that was the subject of the preceding attempt to schedule the pod 220 from consideration.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh, Neuse, and Wang with the teachings of Sehgal wherein the scale mechanism excludes node groups that cannot satisfy deployment requirements based on affinity rules specified in the external data before determining whether to add or delete nodes. Similarly to Singh, Neuse, and Wang, Sehgal teaches of scheduling containers onto a node. Moreover, Sehgal teaches of excluding nodes that do not satisfy a set of rules. By excluding nodes that do not satisfy a set of rules, the scaling mechanism can prevent scheduling on incompatible nodes and ensuring that only nodes capable of supporting the workload are used.
41. With regard to claim 14, Singh teaches:
wherein the scale mechanism acquires node group data from the container base including CPU amount per node, memory amount per node, current node count, minimum node count, maximum node count, and node cost for each node group, excludes node groups that fail to satisfy affinity rules specified in the external data, calculates surplus resource costs for remaining node groups based on formula ((Xcn - Hc)/Cn + (Xmn - Hm)/Mn) x Yn where Xcn and Xmn represent surplus CPU and memory resources respectively, He and Hm represent threshold values, Cn and Mn represent CPU and memory amounts per node, and Yn represents node cost, and selects the node group with lowest surplus resource cost for node addition, thereby minimizing infrastructure costs while ensuring adequate resources for container deployment ([0013] When the application is deployed, workloads (e.g., schedules/collections of one or more processes or tasks) assigned to virtual computing resources may change over time. In situations, when workloads decrease, the enterprise may be paying for idle or underutilized virtual computing resources to which workloads are no longer assigned. In contrast, when workloads increase, the enterprise performance may decrease as a result of providing slower services to customers as the virtual computing resources are overloaded; [0014] To more efficiently use resources in a virtual computing environment, examples disclosed herein enable scaling in and scaling out processes. For example, resources (e.g., virtual machines, networking resources, storage resources, etc.) may be allocated (e.g., scaled-out) for use by a virtual computing node when workloads increase at the computing node. In addition, resources can be freed (e.g., scaled-in) from the computing node when workloads decrease at that computing node. In this manner, resources are not inefficiently sitting idle at a virtual computing node when, for example, the node has no need for those resources. Also, the virtual computing node is allocated additional resources when needed to, for example, address increased workloads; [0020] In the illustrated example of FIG. 1, the example topology generator 118 generates an example application blueprint 126 specifying a logical topology of the application 108, which is to be deployed. The example blueprint 126 maps the structure of the application 108 as a collection of nodes. Application components may be added to each node to specify which application components are executing on the node. For example, the topology generator 118 may generate a blueprint 126 (e.g., a topology map) for an online store application specifying a web application executing on an application server (e.g., an Apache Tomcat application server) that uses a data store as a database (e.g., a MongoDB). The example web application may be implemented by a Java web application archive (e.g., a “WAR” file) comprising dynamic web pages, static web pages, Java servlets, Java classes, and/or other properties, configuration information and/or resource files included in the Java web application. In the illustrated example, the blueprint 126 is an abstract representation of the structure of the application 108 including virtual machines and their corresponding application components, operating systems, dependencies and/or configurations. In some examples, the blueprint 126 standardizes the structure of an application for repeated deployments in multiple and/or diverse deployment environments. The application 108 may alternatively describe the entire online store application, including application server components and database components, rather than just the web application itself; [0021] In the illustrated example of FIG. 1, the topology generator 118 retrieves virtual computing resources from an example catalog 120 to assemble the blueprint 126. For example, the catalog 120 may list virtual computing resources (e.g., virtual machines, networking resources, storage resources, etc.) that may be provisioned from the cloud computing platform provider 110 and corresponding application components (e.g., software services, scripts, code components, application-specific packages, etc.) that may be installed on the provisioned virtual computing resources. The example catalog 120 of the illustrated example is pre-populated with available virtual computing resources and/or application components; [0047] In the illustrated example of FIG. 3, the example deployment monitor 302 monitors deployment environments (e.g., dependent environment 112 of FIG. 1) and determines whether to initiate a scaling operation and to what extent. For example, the deployment monitor 302 may monitor infrastructure resource consumption levels and requirements (e.g., workload) of the deployed application 108 in the deployment environment 112. In some examples, the deployment monitor 302 may compare resource utilization by the application 108 workload to utilization ranges. For example, the deployment monitor 302 may initiate a scale-in operation when resource utilization by the workload is in a first range (e.g., less than 25% utilization), may initiate a scale-out operation when resource utilization by the workload is in a second range (e.g., greater than 75% utilization), and may perform no scaling operation when resource utilization by the workload is in a third range (e.g., greater than or equal to 25% utilization and less than or equal to 75% utilization). In some examples, the deployment monitor 302 may compare the workload to one or more thresholds and scale the number of virtual machines (e.g., sub-nodes) executing the workload accordingly (e.g., increase or decrease the cluster size of a node); [0048] For example, when the deployment monitor 302 of the illustrated example determines that the resource utilization by the workload satisfies a first threshold, the example deployment monitor 302 initiates a scale-out operation to add (e.g., provision) one or more virtual machines to the deployment environment. For example, the example deployment monitor 302 may initiate a first scale-out operation to provision one additional virtual machine 114 when resource utilization by the workload exceeds 75% of available resources, the example deployment monitor 302 may initiate a second scale-out operation to provision a second virtual machine 114 when resource utilization by the workload exceeds 85% of available resources, etc; [0049] When the deployment monitor 302 of the illustrated example determines that resource utilization by the workload satisfies a second threshold, the example deployment monitor 302 initiates a scale-in operation to remove (e.g., de-provision) one or more virtual machines from the deployment environment. For example, the deployment monitor 302 may initiate a first scale-in operation to de-provision a first virtual machine 114 when resource utilization by the workload is less than 25% of available resources, the deployment monitor 302 may initiate a second scale-in operation to de-provision a second virtual machine 114 when resource utilization by the workload is less than 15% of available resources, etc. In some examples, the utilization records and/or the resource utilization thresholds are stored in a data structure such as a lookup table. In some examples, the utilization records and/or the resource utilization thresholds may be changed by the developer 104, the administrator 106 and/or any other person.).
Singh, however, fails to explicitly teach excluding node groups that fail to satisfy affinity rules specified in the external data.
However, in analogous art, Sehgal teaches:
excluding node groups that fail to satisfy affinity rules specified in the external data ([0027] The set of rules 216B may further specify that if the amount of time that has elapsed since the preceding attempt is less than or equal to the threshold amount of time, the scheduler service 217 may not attempt to schedule the pod on a node 131 that was the subject of the preceding attempt to schedule the pod 220. Stated differently, the scheduler service 217 may attempt to schedule the pod 220 based on the default security policy (e.g., using the default predicates) and the resource requirements of the pod 220 but may exclude the node 131 that was the subject of the preceding attempt to schedule the pod 220 from consideration; [0037] At block 510, if the amount of time that has elapsed since the preceding attempt is less than or equal to the threshold amount of time, then at block 515 the scheduler service 217 may exclude a node 131 that was the subject of the preceding attempt to schedule the pod 220 from scheduling consideration. At block 520, the scheduler service 217 may attempt to schedule the pod 220 based on the default security policy (e.g., using the default predicates) and the resource requirements of the pod 220 but may exclude the node 131 that was the subject of the preceding attempt to schedule the pod 220 from consideration.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singh with the teachings of Sehgal to exclude node groups that fail to satisfy affinity rules specified in the external data. Similarly to Singh, Neuse, and Wang, Sehgal teaches of scheduling containers onto a node. Moreover, Sehgal teaches of excluding nodes that do not satisfy a set of rules. By excluding nodes that do not satisfy a set of rules, the scaling mechanism can prevent scheduling on incompatible nodes and ensuring that only nodes capable of supporting the workload are used.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AN-AN N NGUYEN whose telephone number is (571)272-6147. The examiner can normally be reached Monday-Friday 8:00-5:00 ET.
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, AIMEE LI can be reached at (571) 272-4169. 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.
/AN-AN NGOC NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195