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 .
This office action is in response to Applicant’s Amendment filed 03/13/2026. Claims 1-20 are pending. Claims 1, 7, 10, and 14-15 have been amended. Any examiner’s note, objection, or rejection not repeated is withdrawn due to Applicant’s amendment.
Priority
Applicant’s claim for priority from application no. 63/260,433 filed 08/19/2021 is acknowledged.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 02/23/2023 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-9, 11, 14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gonzalez et al. (US 20200310881 A1) in view of Bahl et al. (US 20210019194 A1), and further in view of Plouffe et al. (US 20050120160 A1), hereinafter referred to as Gonzalez, Bahl, and Plouffe, respectively.
Regarding Claim 1, Gonzalez discloses A method for capacity optimization ([0019] auto-scaling systems and methods calculate the capacity…required to perform scheduled tasks. Please note that auto-scaling systems calculating required capacity correspond to a method for capacity optimization) in a cluster system ([0018] it was noticed that the auto-scaling feature offered by Kubernetes, a container orchestration system, failed to add enough compute resources; [0019] To address one of more of these issues, embodiments of the present disclosure introduce a new auto-scaling method. Note that Kubernetes is a cluster system, and the reference discloses that their invention for capacity optimization applies to it.), the method comprising: and updating, by the capacity optimizer, the first value of the artificial node-level extended resource based on the first usage amount to maintain the first usage amount between a first lower threshold and a first upper threshold, while the actual value of the node-level built-in resource remains fixed ([0086] If at step 414 a determination is made that the calculated utilization is between the upper and slow scaling threshold values, the scaling manager 106 does nothing. Please note that Applicant’s capacity optimizer corresponds to the scaling manager 106, the upper and slow scaling threshold values correspond to the first upper and first lower threshold values, and doing nothing if the utilization is between the two values corresponds to maintaining the first usage amount between the two. Since it is doing no scaling, this corresponds to the actual value of the node-level built-in resource remaining fixed.), wherein the capacity optimizer is configured to increase the first value of the artificial node-level extended resource if the first usage amount is below the first lower threshold ([0100] If the utilization falls below this lower utilization value, the scaling manager 106 may calculate the number of compute resources required to bring the utilization value to a value higher than the lower threshold. Please note that the lower threshold corresponds to Applicant’s first lower threshold and bringing the utilization value higher than the lower threshold value corresponds to increasing the first value of the node-level extended resource. ), and decrease the first value of the node-level extended resource if the first usage amount is above the first upper threshold ([0100] determining the number of compute resources required to bring the utilization value to a value lower than the upper threshold at steps 312 and 418. Please note that the upper threshold corresponds to Applicant’s first upper threshold and bringing the utilization value lower than the upper threshold value corresponds to decreasing the first value of the node-level extended resource.), or updating, by the capacity optimizer, the second value of the container-level built-in resource to maintain the second usage amount between a second lower threshold and a second upper threshold, while the actual value of the container-level built-in resource remains fixed ([0019] If the utilization is calculated to be within the first and second thresholds, no scale-up or scale-down action is taken.; [0020] This calculation and decision making is performed periodically. Please note that utilization corresponds to Applicant’s usage amount, and not scaling if the utilization value is within the first and second thresholds corresponds to maintaining the usage amount between a second lower and a second upper threshold. Performing this decision making periodically corresponds to Applicant’s updating the value by the capacity optimizer. Since it is doing no scaling, this corresponds to the actual value of the container-level built-in resource remaining fixed.), wherein the capacity optimizer is configured to decrease the second value of the artificial container-level extended resource if the second usage amount is below the second lower threshold ([0019] Alternatively, if the utilization is determined to be below a second threshold, the resources are scaled down Please note that scaling down resources corresponds to decreasing the second value of the container-level extended resource, and the first threshold corresponds to Applicant’s second upper threshold ), and increase the second value of the artificial container-level extended resource if the second usage amount is below the second lower threshold ([0019] If the utilization is determined to be above a first threshold (which can be set to include the buffer capacity), the resources are scaled up Please note that scaling up resources corresponds to increasing the second value of the container-level extended resource, and the first threshold corresponds to Applicant’s second upper threshold ).
Gonzalez does not explicitly disclose advertising, by a capacity optimizer via a Kubernetes application programming interface server, an artificial node-level extended resource and an artificial container-level extended resource; assigning, by the capacity optimizer, a first value to the artificial node-level extended resource and a second value to the artificial container-level extended resource, wherein the first value is set to a value of a node-level built-in resource, and wherein the second value is set to a value of a container-level built-in resource; periodically determining, via a metrics collector, a first usage amount of the node-level built-in resource and a second usage amount of the container-level built-in resource;
However, Bahl discloses advertising, by a capacity optimizer via a Kubernetes application programming interface server ([0042] The API server 204 (e.g., Kubernetes® kube-apiserver) can operate as the front-end to expose the API (e.g., Kubernetes® API) of the container orchestrator 200. Please note that the API server running kube-apiserver corresponds to Applicant’s Kubernetes application programming interface server, and exposing the API corresponds to advertising), an artificial node-level extended resource ([0038] Nodes may be coupled to other [..] networks through one or more interfaces employing any suitable […] wireless connection. Please note nodes coupled to other networks through an interface correspond to Applicant’s node-level extended resource.) and an artificial container-level extended resource ([0042] expose the API (e.g., Kubernetes® API) of the container orchestrator 200. Please note that the exposed Kubernetes API of the container orchestrator 200 corresponds to Applicant’s container-level extended resource); assigning, by the capacity optimizer, a first value to the artificial node-level extended resource and a second value to the artificial container-level extended resource ([0050] the container orchestrator 200 can support labels […] Labels can be key-value pairs used to group together sets of objects, such as pods; [0051] Label selectors can be used to select objects based on their labels. Please note that grouping together sets of objects with a label corresponds to Applicant’s assigning respective first and second values to the node-level extended resource and the container-level extended resource, as it is possible to group the resources together and select them by label to determine the count of each group, corresponding to the value of each resource), wherein the first value is set to an actual value of a node-level built-in resource, and wherein the second value is set to an actual value of a container-level built-in resource (Note that using the labeling system of the previous reference citation, the built-in resources can be labeled with keys identical to the keys of their respective extended resources, resulting in the same counts/values. Since they are virtualized using actual hardware, this corresponds to being set to the actual value of the resource, as virtualized hardware inherently has an associated actual value of hardware being used for its processes.); periodically determining, via a metrics collector, a first usage amount of the node-level built-in resource and a second usage amount of the container-level built-in resource ([0079] The resource metering module 418 can track the inventory of computing resources […] reserved and utilized for deploying the service mesh application, including all computing resources for deploying the application, intermediate components, and the microservice containers 228. Please note that the resource metering module corresponds to Applicant’s metrics collector, and tracking the inventory of all computer resources used for deploying the service mesh application corresponds to Applicant’s determining the respective usage amounts of the first node-level built-in resource and second container-level built-in resource);
Gonzalez and Bahl are both considered to be analogous to the claimed invention because they are in the same field of computer container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez to incorporate the teachings of Bahl to modify the auto-scaling cluster capacity management system to expose the availability of cluster resources via a Kubernetes API, allowing for more efficient resource management as described in Bahl.
Gonzalez-Bahl does not explicitly teach an artificial extended resource.
However, Plouffe teaches an artificial extended resource ([0028] the virtualization layer isolates the OS and their applications from the underlying physical nodes, resources may be managed without changes at the application or operating system interface levels. This is beneficial, for example, as the application or operating system need not be modified to function on multiple nodes (or types of nodes) and therefore, the cost in developing a scalable application is decreased.; [0029] the platform allows physical resources to be abstracted and mapped to virtual resources (e.g., virtual servers (VSs), virtual processors (VPs), virtual I/O devices, etc.). […] The system can have an-infinite number of virtual mainframes.; [0077] To this end, a capability may be provided for changing the amount and allocation of resources, both actual and virtual, to the virtual computing system. More specifically, additional resources (e.g., nodes, network, storage, I/O, etc.) may be allocated (or deallocated) in real time to a frame and these resources may then be used (or not used) by a virtual partition. Similarly, virtualized resources (e.g., virtual processors, virtual I/O, virtual networking, etc.) as well as physical resources may be allocated or deallocated to a virtual server. In this manner, the virtual computing system may be scaled-up/scaled-down as necessary. Please note that scaling the virtual computing system by having virtualized resources representing actual resources that may be scaled corresponds to Applicant’s artificial extended resources. As Applicant states in [0041] of the Specification to “artificially manipulate a Kubernetes container-orchestration system in real-time, such that the orchestration system has data that informs the orchestration system that a workload container has more resources available and allow containers to be allocated to the nodes, despite there being no actual increase in node resources available”, the system disclosed by Plouffe meets the requirements for allowing for artificial extended resources, as the virtualized resources can be managed independently of the actual resources of the underlying physical nodes, thus requiring no changes at the application level.)
Gonzalez-Bahl and Plouffe are both considered to be analogous to the claimed invention because they are in the same field of computer resource management considering utilization. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl to incorporate the teachings of Plouffe to modify the auto-scaling cluster capacity management system exposing the availability of cluster resources via a Kubernetes API to have artificial extended resources at the node and container level, allowing for improved system scalability and adaptability, as described in Plouffe.
Regarding Claim 2, Gonzalez-Bahl-Plouffe as described in Claim 1 discloses from Bahl wherein the node-level built-in resource is a central processing unit resource or a memory resource ([0040] The container orchestrator 200 can comprise one or more clusters or collections of processing, memory […] Each cluster can comprise one or more hosts. In this example, the cluster includes a master 202 and workers 220A and 220B (collectively, 220) (sometimes also referred to as nodes. Please note that the workers 220 correspond to Applicant’s node-level built-in resource, and as a host within the cluster, they comprise processing and memory corresponding to Applicant’s central processing unit or memory resources.)
Regarding Claim 3, Gonzalez-Bahl-Plouffe as described in Claim 1 discloses from Bahl wherein the container-level built-in resource is a central processing unit resource or a memory resource ([0040] The container orchestrator 200 can comprise one or more clusters or collections of processing, memory. Please note that as previously mentioned, the container orchestrator 200’s clusters run by master 202 corresponds to Applicant’s container-level built-in resource, and comprises processing and memory corresponding to Applicant’s central processing unit or memory resources.).
Regarding Claim 5, Gonzalez-Bahl-Plouffe as described in Claim 1 discloses from Gonzalez wherein the first lower threshold is 80 percent, and wherein the first upper threshold is 100 percent ([0067] the utilization is determined as a percentage of the total required capacity divided by the total available capacity.; [0068] At step 308, a determination is made whether the calculated utilization exceeds an upper threshold value or is lower than a lower threshold value. Please note that since the utilization that is used for comparison to the lower and upper threshold values (corresponding to Applicant’s first lower and first upper thresholds) is a percentage, the thresholds are percentages as well, and can be “a percentage” meaning that the values 80 percent and 100 percent fall under its limitations.).
Regarding Claim 6, Gonzalez-Bahl-Plouffe as described in Claim 1 discloses from Bahl wherein the cluster system includes Kubernetes ([0039] the container orchestrator 200 may be based on Kubernetes; [0040] The container orchestrator 200 can comprise one or more clusters. Please note that the container orchestrator 200 comprising one or more clusters being based on Kubernetes corresponds to Applicant’s cluster system including Kubernetes).
Regarding Claim 7, Gonzalez discloses A method for capacity optimization ([0019] auto-scaling systems and methods calculate the capacity…required to perform scheduled tasks. Please note that auto-scaling systems calculating required capacity correspond to a method for capacity optimization) in a Kubernetes cluster system ([0018] it was noticed that the auto-scaling feature offered by Kubernetes, a container orchestration system, failed to add enough compute resources; [0019] To address one of more of these issues, embodiments of the present disclosure introduce a new auto-scaling method. Note that Kubernetes is a cluster system, and the reference discloses that their invention for capacity optimization applies to it.), the method comprising: updating, by the capacity optimizer, the value of the built-in container-level CPU and the value of the built-in container-level memory ([0004] automatically increase/decrease the available compute resources (i.e., processor and/or memory) for containers. Please note that automatically increasing/decreasing available compute resources for containers corresponds to Applicant’s updating values of the built-in container-level CPU and the value of the built-in container-level memory. ); periodically determining, via a metrics collector, a first usage amount of the built-in node-level CPU, a second usage amount of the built-in node-level memory, a third usage amount of the built-in container-level CPU, and a fourth usage amount of the built-in container-level memory; ([0019] calculate the capacity (e.g., processor and memory requirements) required to perform scheduled tasks and the actual capacity (e.g., the available processor and memory) available to determine the utilization; [0020] This calculation and decision making is performed periodically. Please note that the capacity of available processors corresponds to Applicant’s first and third usage amounts, and the capacity of available memory corresponds to the second and fourth usage amounts. Performing this calculation periodically corresponds to Applicant’s determining the values by the metrics collector); automatically and dynamically updating, by the capacity optimizer, the first value, the second value, the third value, the fourth value to maintain the first usage amount, the second usage amount, the third usage amount, and the fourth usage amount between a lower threshold and an upper threshold, while the actual value of the node-level CPU built-in resource, the actual value of the built-in node-level memory, the actual value of the container-level CPU built-in resource, and the actual value of the built-in container-level memory remain fixed. ([0019] If the utilization is determined to be above a first threshold […] the resources are scaled up [...] Alternatively, if the utilization is determined to be below a second threshold, the resources are scaled down […] If the utilization is calculated to be within the first and second thresholds, no scale-up or scale-down action is taken.; [0020] This calculation and decision making is performed periodically. [0086] If at step 414 a determination is made that the calculated utilization is between the upper and slow scaling threshold values, the scaling manager 106 does nothing. Please note that Applicant’s capacity optimizer corresponds to the scaling manager 106, the first and second threshold values correspond to Applicant’s upper and lower threshold values, and scaling up or down to keep utilization between the thresholds corresponds to maintaining the usage amounts between the thresholds. Since it is doing no scaling, this corresponds to the actual values of the node-level and container-level built-in resources and memory remaining fixed.).
Gonzalez does not explicitly disclose advertising, by a capacity optimizer, via a Kubernetes application programming interface, an artificial CPU node-level extended resource, an artificial memory node-level extended resource, an artificial CPU container-level extended resource, and an artificial memory container-level extended resource; assigning, by the capacity optimizer, a first value to the artificial CPU node-level extended resource, wherein the first value is set to an actual value of a built-in node-level CPU; assigning, by the capacity optimizer, a second value to the artificial memory node- level extended resource, wherein the second value is set to an actual value of a built-in node-level memory; assigning, by the capacity optimizer, a third value to the artificial CPU container- level extended resource, wherein the third value is set to an actual value of a built-in container-level CPU; assigning, by the capacity optimizer, a fourth value to the artificial memory container-level extended resource, wherein the fourth value is set to an actual value of a built-in container-level memory
However, Bahl discloses advertising, by a capacity optimizer, via a Kubernetes application programming interface ([0042] expose the API (e.g., Kubernetes® API) of the container orchestrator 200. Please note that the Kubernetes API corresponds to Applicant’s Kubernetes application programming interface, and exposing the API corresponds to advertising), an artificial CPU node-level extended resource (([0038] Nodes may be coupled to other [..] networks through one or more interfaces employing any suitable […] wireless connection; [0040] clusters […] of processing […] the cluster includes […] workers 220A and 220B (collectively, 220) (sometimes also referred to as nodes. Please note that the processing within nodes/workers 220 coupled to other networks through a wireless interface correspond to Applicant’s CPU node-level extended resource), an artificial memory node-level extended resource (([0038] Nodes may be coupled to other [..] networks through one or more interfaces employing any suitable […] wireless connection; [0040] clusters […] of memory […] the cluster includes […] workers 220A and 220B (collectively, 220) (sometimes also referred to as nodes. Please note that the memory within nodes/workers 220 coupled to other networks through a wireless interface correspond to Applicant’s CPU node-level extended resource), an artificial CPU container-level extended resource ([0040] clusters […] of processing; [0042] expose the API (e.g., Kubernetes® API) of the container orchestrator 200. Please note that the processing exposed by the Kubernetes API of the container orchestrator 200 corresponds to Applicant’s CPU container-level extended resource), and an artificial memory container-level extended resource ([0040] clusters […] of memory; [0042] expose the API (e.g., Kubernetes® API) of the container orchestrator 200. Please note that the memory exposed by the Kubernetes API of the container orchestrator 200 corresponds to Applicant’s memory container-level extended resource); assigning, by the capacity optimizer, a first value to the artificial CPU node-level extended resource, wherein the first value is set to an actual value of a built-in node-level CPU; assigning, by the capacity optimizer, a second value to the memory node-level extended resource, wherein the second value is an actual value of a built-in node-level memory; assigning, by the capacity optimizer, a third value to the artificial CPU container-level extended resource, wherein the third value is set to an actual value of a built-in container-level CPU; assigning, by the capacity optimizer, a fourth value to the artificial memory container- level extended resource, wherein the fourth value is set to an actual value of a built-in container-level memory ([0050] the container orchestrator 200 can support labels […] Labels can be key-value pairs used to group together sets of objects, such as pods; [0051] Label selectors can be used to select objects based on their labels.; ([0079] The resource metering module 418 can track the inventory of computing resources […] reserved and utilized for deploying the service mesh application, including all computing resources for deploying the application, intermediate components, and the microservice containers 228. Please note that tracking inventory of computing resources (which includes Applicant’s container and node-level CPU and memory) and then grouping together sets of objects with a label corresponds to Applicant’s assigning respective values to the node-level extended resources and the container-level extended resources, as it is possible to group the resources together after determining usage and select them by label to determine the count of each group, corresponding to the value of each resource. Since they are virtualized using actual hardware, this corresponds to being set to the actual value of the resource, as virtualized hardware inherently has an associated actual value of hardware being used for its processes.);
Gonzalez and Bahl are both considered to be analogous to the claimed invention because they are in the same field of computer container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez to incorporate the teachings of Bahl to modify the auto-scaling cluster capacity management system to expose the availability of cluster resources via a Kubernetes API, allowing for more efficient resource management as described in Bahl.
Gonzalez-Bahl does not explicitly teach an artificial extended resource.
However, Plouffe teaches an artificial extended resource ([0028] the virtualization layer isolates the OS and their applications from the underlying physical nodes, resources may be managed without changes at the application or operating system interface levels. This is beneficial, for example, as the application or operating system need not be modified to function on multiple nodes (or types of nodes) and therefore, the cost in developing a scalable application is decreased.; [0029] the platform allows physical resources to be abstracted and mapped to virtual resources (e.g., virtual servers (VSs), virtual processors (VPs), virtual I/O devices, etc.). […] The system can have an-infinite number of virtual mainframes.; [0077] To this end, a capability may be provided for changing the amount and allocation of resources, both actual and virtual, to the virtual computing system. More specifically, additional resources (e.g., nodes, network, storage, I/O, etc.) may be allocated (or deallocated) in real time to a frame and these resources may then be used (or not used) by a virtual partition. Similarly, virtualized resources (e.g., virtual processors, virtual I/O, virtual networking, etc.) as well as physical resources may be allocated or deallocated to a virtual server. In this manner, the virtual computing system may be scaled-up/scaled-down as necessary. Please note that scaling the virtual computing system by having virtualized resources representing actual resources that may be scaled corresponds to Applicant’s artificial extended resources. As Applicant states in [0041] of the Specification to “artificially manipulate a Kubernetes container-orchestration system in real-time, such that the orchestration system has data that informs the orchestration system that a workload container has more resources available and allow containers to be allocated to the nodes, despite there being no actual increase in node resources available”, the system disclosed by Plouffe meets the requirements for allowing for artificial extended resources, as the virtualized resources can be managed independently of the actual resources of the underlying physical nodes, thus requiring no changes at the application level.)
Gonzalez-Bahl and Plouffe are both considered to be analogous to the claimed invention because they are in the same field of computer resource management considering utilization. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl to incorporate the teachings of Plouffe to modify the auto-scaling cluster capacity management system exposing the availability of cluster resources via a Kubernetes API to have artificial extended respective CPU and memory resources at the node and container levels, allowing for improved system scalability and adaptability, as described in Plouffe.
Regarding Claim 8, Gonzalez-Bahl-Plouffe as described in Claim 7 discloses from Gonzalez wherein updating the third value comprises lowering the third value ([0043] available resources on the node: the CPU; [0046] lower threshold value corresponds to the utilization value for the entire system below which the scaling manager 106 decreases the number of available resources (e.g., decrease the size of the node group 204) Please note the entire system corresponds to Applicant’s container, and decreasing the number of available resources (CPU) for the entire system corresponds to lowering the third value. ), and wherein updating the fourth value comprises lowering the fourth value ([0043] available resources on the node: [...] memory; [0046] lower threshold value corresponds to the utilization value for the entire system below which the scaling manager 106 decreases the number of available resources (e.g., decrease the size of the node group 204) Please note the entire system corresponds to Applicant’s container, and decreasing the number of available resources (memory) for the entire system corresponds to lowering the fourth value. )
Regarding Claim 9, Gonzalez-Bahl-Plouffe as described in Claim 7 discloses from Bahl wherein the capacity optimizer interacts with the Kubernetes cluster system via a Kubernetes application programming interface ([0046] agents 222A and 222B (collectively, 222) (e.g., Kubernetes® kubelet) […] The agents 222 can run on the workers 220 in the cluster […] The agents 222 can oversee communications with the master 202, including downloading […] from the API server 204. Please note that the agents 222 correspond to the Kubernetes cluster system, and communicating with the master 202 including downloading from the API server corresponds to Applicant’s interacting via a Kubernetes application programming interface.).
Regarding Claim 11, Gonzalez-Bahl-Plouffe as described in Claim 7 discloses from Bahl wherein the metrics collector periodically determines the first usage amount of the built-in node-level CPU, the second usage amount of the built-in node-level memory, the third usage amount of the built-in container-level CPU, and the fourth usage amount of the built-in container-level memory every 20 seconds ([0079] The resource metering module 418 can track the inventory of computing resources […] reserved and utilized for deploying the service mesh application, including all computing resources[…] Over time Please note that the resource metering module corresponds to Applicant’s metrics collector, and tracking the inventory of all computer resources used for deploying the service mesh application corresponds to Applicant’s determining the respective usage amounts of the first, second, third, and fourth resources over time, which could include 20 seconds.).
Regarding Claim 14, Gonzalez discloses A computing system for capacity optimization ([0019] auto-scaling systems and methods calculate the capacity…required to perform scheduled tasks. Please note that auto-scaling systems calculating required capacity correspond to a computing system for capacity optimization) of a cluster system ([0018] it was noticed that the auto-scaling feature offered by Kubernetes, a container orchestration system, failed to add enough compute resources; [0019] To address one of more of these issues, embodiments of the present disclosure introduce a new auto-scaling method. Note that Kubernetes is a cluster system, and the reference discloses that their invention for capacity optimization applies to it.), the computing system comprising: one or more processors ([0106] processor 504) and an electronic storage medium configured with specific computer-executable instructions ([0106] Execution of the sequences of instructions contained in main memory 506) that, when executed, cause the one or more processors ([0106] processor 504 executing […] instructions contained in main memory 506.) to at least: and automatically and dynamically update the first value of the artificial node-level extended resource, the second value of the artificial container-level extended resource, or the value of the container-level built-in resource based on the first usage amount and the second usage amount to maintain the first usage amount and the second usage amount between a lower threshold and an upper threshold, while the actual value of the node-level built-in resource and the actual value of the container-level built-in resource remain fixed ([0086] If at step 414 a determination is made that the calculated utilization is between the upper and slow scaling threshold values, the scaling manager 106 does nothing. Please note that Applicant’s capacity optimizer corresponds to the scaling manager 106, the upper and slow scaling threshold values correspond to the lower and upper threshold values, and doing nothing if the utilization is between the two values corresponds to maintaining the usage amounts between the two. Since it is doing no scaling, this corresponds to the actual values of the node-level and container-level built-in resources remaining fixed.), wherein if the first usage amount is below the lower threshold, the first value is increased ([0019] Alternatively, if the utilization is determined to be below a second threshold, the resources are scaled down Please note that the utilization being below a second threshold corresponds to Applicant’s first usage amount being below the lower threshold. Additionally, since it is scaling down the resources once it goes below the threshold, it would be obvious to alternatively scale up the first value once it goes below the threshold, with the threshold serving as a trigger for a change in resource management.), and if the first usage amount is above the upper threshold, the first value is decreased ([0019] If the utilization is determined to be above a first threshold (which can be set to include the buffer capacity), the resources are scaled up Please note that the utilization being above a first threshold corresponds to Applicant’s first usage amount being above the upper threshold. Additionally, since it is scaling up the resources once it goes above the threshold, it would be obvious to alternatively scale down the first value once it goes above the threshold, with the threshold serving as a trigger for a change in resource management.), or updating, by the capacity optimizer, the second value of the container-level built-in resource to maintain the second usage amount between a second lower threshold and a second upper threshold ([0019] If the utilization is calculated to be within the first and second thresholds, no scale-up or scale-down action is taken.; [0020] This calculation and decision making is performed periodically. Please note that utilization corresponds to Applicant’s usage amount, and not scaling if the utilization value is within the first and second thresholds corresponds to maintaining the usage amount between a second lower and a second upper threshold. Performing this decision making periodically corresponds to Applicant’s updating the value by the capacity optimizer.), and wherein if the second usage amount is below the lower threshold, the second value is increased ([0100] If the utilization falls below this lower utilization value, the scaling manager 106 may calculate the number of compute resources required to bring the utilization value to a value higher than the lower threshold. Please note that the lower threshold corresponds to Applicant’s lower threshold and bringing the utilization value higher than the lower threshold value corresponds to increasing the second value if the second usage amount is below the lower threshold.), and if the second usage amount is above the upper threshold, the second value is decreased ([0100] determining the number of compute resources required to bring the utilization value to a value lower than the upper threshold at steps 312 and 418. Please note that the upper threshold corresponds to Applicant’s upper threshold and bringing the utilization value lower than the upper threshold value corresponds to decreasing the second value if the second usage amount is above the upper threshold.).
Gonzalez does not explicitly disclose advertise an artificial node-level extended resource and an artificial container-level extended resource; assign a first value to the artificial node-level extended resource and a second value to the artificial container-level extended resource, wherein the first value is set to an actual value of a node-level built-in resource, and the second value is set to an actual value of a container-level built-in resource; periodically determine a first usage amount of the node-level built-in resource and a second usage amount of the container-level built-in resource;
However, Bahl discloses advertise an artificial node-level extended resource (([0038] Nodes may be coupled to other [..] networks through one or more interfaces employing any suitable […] wireless connection; [0040] the cluster includes […] workers 220A and 220B (collectively, 220) (sometimes also referred to as nodes. Please note that nodes/workers 220 coupled to other networks through a wireless interface correspond to advertising Applicant’s node-level extended resource) and an artificial container-level extended resource ([0042] expose the API (e.g., Kubernetes® API) of the container orchestrator 200. Please note that exposing the API of the container orchestrator 200 corresponds to advertising the container-level extended resource); assign a first value to the artificial node-level extended resource and a second value to the artificial container-level extended resource, wherein the first value is set to an actual value of a node-level built-in resource ([0040] clusters […] of processing, memory […] the cluster includes […] workers 220A and 220B (collectively, 220) (sometimes also referred to as nodes. Please note that the processing and memory resources within nodes/workers 220 correspond to Applicant’s node-level built-in resource. Since they are virtualized using actual hardware, this corresponds to being set to the actual value of the resource, as virtualized hardware inherently has an associated actual value of hardware being used for its processes.), and the second value is a set to an actual value of a container-level built-in resource; ([0040] clusters […] of processing, memory; [0042] expose the API (e.g., Kubernetes® API) of the container orchestrator 200. Please note that the processing and memory resources of the container orchestrator 200 corresponds to Applicant’s container-level built-in resource); periodically determine a first usage amount of the node-level built-in resource and a second usage amount of the container-level built-in resource ([0079] The resource metering module 418 can track the inventory of computing resources […] reserved and utilized for deploying the service mesh application, including all computing resources for deploying the application, intermediate components, and the microservice containers 228. Please note that tracking the inventory of all computer resources used for deploying the service mesh application corresponds to Applicant’s determining the respective usage amounts of the first node-level built-in resource and second container-level built-in resource. Since they are virtualized using actual hardware, this corresponds to being set to the actual value of the resource, as virtualized hardware inherently has an associated actual value of hardware being used for its processes.);
Gonzalez and Bahl are both considered to be analogous to the claimed invention because they are in the same field of computer container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez to incorporate the teachings of Bahl to modify the auto-scaling cluster capacity management system where updating the values comprises lowering the value of the built-in container-level CPU and memory and allowing for dynamic management of available resources, lowering availability as they are used, to expose the availability of cluster resources and determine usage of the built-in resources, allowing for more efficient resource management, as described in Bahl.
Gonzalez-Bahl does not explicitly teach an artificial extended resource.
However, Plouffe teaches an artificial extended resource ([0028] the virtualization layer isolates the OS and their applications from the underlying physical nodes, resources may be managed without changes at the application or operating system interface levels. This is beneficial, for example, as the application or operating system need not be modified to function on multiple nodes (or types of nodes) and therefore, the cost in developing a scalable application is decreased.; [0029] the platform allows physical resources to be abstracted and mapped to virtual resources (e.g., virtual servers (VSs), virtual processors (VPs), virtual I/O devices, etc.). […] The system can have an-infinite number of virtual mainframes.; [0077] To this end, a capability may be provided for changing the amount and allocation of resources, both actual and virtual, to the virtual computing system. More specifically, additional resources (e.g., nodes, network, storage, I/O, etc.) may be allocated (or deallocated) in real time to a frame and these resources may then be used (or not used) by a virtual partition. Similarly, virtualized resources (e.g., virtual processors, virtual I/O, virtual networking, etc.) as well as physical resources may be allocated or deallocated to a virtual server. In this manner, the virtual computing system may be scaled-up/scaled-down as necessary. Please note that scaling the virtual computing system by having virtualized resources representing actual resources that may be scaled corresponds to Applicant’s artificial extended resources. As Applicant states in [0041] of the Specification to “artificially manipulate a Kubernetes container-orchestration system in real-time, such that the orchestration system has data that informs the orchestration system that a workload container has more resources available and allow containers to be allocated to the nodes, despite there being no actual increase in node resources available”, the system disclosed by Plouffe meets the requirements for allowing for artificial extended resources, as the virtualized resources can be managed independently of the actual resources of the underlying physical nodes, thus requiring no changes at the application level.)
Gonzalez-Bahl and Plouffe are both considered to be analogous to the claimed invention because they are in the same field of computer resource management considering utilization. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl to incorporate the teachings of Plouffe to modify the auto-scaling cluster capacity management system exposing the availability of cluster resources via a Kubernetes API to have artificial extended resources at the node and container level, allowing for improved system scalability and adaptability, as described in Plouffe.
Regarding Claim 16, Gonzalez-Bahl-Plouffe as described in Claim 14 discloses from Bahl wherein the node-level built-in resource is CPU or memory ([0040] The container orchestrator 200 can comprise one or more clusters or collections of processing, memory […] Each cluster can comprise one or more hosts. In this example, the cluster includes a master 202 and workers 220A and 220B (collectively, 220) (sometimes also referred to as nodes. Please note that the workers 220 correspond to Applicant’s node-level built-in resource, and as a host within the cluster, they comprise processing and memory corresponding to Applicant’s CPU or memory resources.).
Regarding Claim 17, Gonzalez-Bahl-Plouffe as described in Claim 14 discloses from Bahl wherein the container-level built-in resource is CPU or memory ([0040] The container orchestrator 200 can comprise one or more clusters or collections of processing, memory. Please note that as previously mentioned, the container orchestrator 200’s clusters run by master 202 corresponds to Applicant’s container-level built-in resource, and comprises processing and memory corresponding to Applicant’s CPU or memory resources.).
Regarding Claim 18, Gonzalez-Bahl-Plouffe as described in Claim 14 discloses from Bahl wherein periodically determining the first usage amount and the second usage amount occurs every 20 seconds ([0079] The resource metering module 418 can track the inventory of computing resources […] reserved and utilized for deploying the service mesh application, including all computing resources[…] Over time Please note that the resource metering module corresponds to Applicant’s metrics collector, and tracking the inventory of all computer resources used for deploying the service mesh application corresponds to Applicant’s determining the respective usage amounts of the first and second resources over time, which could include 20 seconds.).
Regarding Claim 19, Gonzalez-Bahl-Plouffe as described in Claim 14 discloses from Gonzalez wherein the lower threshold is 80 percent, and wherein the upper threshold is 100 percent ([0067] the utilization is determined as a percentage of the total required capacity divided by the total available capacity.; [0068] At step 308, a determination is made whether the calculated utilization exceeds an upper threshold value or is lower than a lower threshold value. Please note that since the utilization that is used for comparison to the lower and upper threshold values (corresponding to Applicant’s first lower and first upper thresholds) is a percentage, the thresholds are percentages as well, and can be “a percentage” meaning that the values 80 percent and 100 percent fall under its limitations.).
Regarding Claim 20, Gonzalez-Bahl-Plouffe as described in Claim 14 discloses from Bahl wherein the cluster system comprises Kubernetes ([0039] the container orchestrator 200 may be based on Kubernetes; [0040] The container orchestrator 200 can comprise one or more clusters. Please note that the container orchestrator 200 comprising one or more clusters being based on Kubernetes corresponds to Applicant’s cluster system comprising Kubernetes).
Claims 4, 10, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gonzalez et al. (US 20200310881 A1) in view of Bahl et al. (US 20210019194 A1), further in view of Plouffe et al. (US 20050120160 A1) as applied to Claims 1, 7, and 14 above, and further in view of Mishra et al. (US 20200322226 A1), hereinafter referred to as Gonzalez, Bahl, Plouffe, and Mishra, respectively.
Regarding Claim 4, Gonzalez-Bahl-Plouffe as described in Claim 1 does not explicitly disclose further comprising displaying, on a graphical user interface, the first value, the second value, the actual value of the node-level built-in resource, the actual value of the container-level built-in resource, the first usage amount, and the second usage amount.
However, Mishra discloses further comprising displaying, on a graphical user interface ([0103] an interactive Graphical User Interface (“GUI”) display 1400), the first value, the second value, the first value of the node-level built-in resource, the second value of the container-level built-in resource, the first usage amount, and the second usage amount ([0103] the display 1400 contains graphs showing, over time, a number of application instances 1412, CPU/memory usage of VM and contains 1414, control plane availability 1416, network device flow utilization percentage 1418, etc. Selection of portions of the graphic representation 1410 […] may result in the display of additional information about an element […] selection of a “More Info” icon 1430 may let the user request additional data (e.g., to investigate system performance). Please note that displaying CPU and memory usage corresponds to Applicant’s first and second usage amounts, and displaying additional data about an element, i.e., an application instance 1412, corresponds to displaying the first and second value of the node and container-level built-in resources as part of investigating the system performance. The actual values of these resources could be displayed as well, i.e. as part of the hardware performance of the system.).
Gonzalez-Bahl-Plouffe and Mishra are both considered to be analogous to the claimed invention because they are in the same field of computer resource scaling management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl-Plouffe to incorporate the teachings of Mishra to modify the auto-scaling cluster capacity management system to display usage amounts and the first and second built-in resource values on a GUI, allowing for monitoring of system performance as described in Mishra.
Regarding Claim 10, Gonzalez-Bahl-Plouffe as described in Claim 7 does not explicitly disclose further comprising displaying, on a graphical user interface, the first value, the second value, the third value, the fourth value, the actual value of the built-in node-level CPU, the actual value of the built-in node-level memory, the actual value of the built-in container-level CPU, and the actual value of the built-in container-level memory.
However, Mishra discloses further comprising displaying, on a graphical user interface ([0103] an interactive Graphical User Interface (“GUI”) display 1400), the first value, the second value, the third value, the fourth value, the actual value of the built-in node-level CPU, the actual value of the built-in node-level memory, the actual value of the built-in container-level CPU, and the actual value of the built-in container-level memory ([0103] the display 1400 contains graphs showing, over time, a number of application instances 1412, CPU/memory usage of VM and contains 1414, control plane availability 1416, network device flow utilization percentage 1418, etc. Selection of portions of the graphic representation 1410 […] may result in the display of additional information about an element […] selection of a “More Info” icon 1430 may let the user request additional data (e.g., to investigate system performance). Please note that displaying CPU and memory usage corresponds to Applicant’s values of the built-in container-level and node-level CPU and memory, and displaying additional data about an element, i.e., an application instance 1412, corresponds to displaying the first, second, third, and fourth values as part of investigating the system performance. The actual values of these resources could be displayed as well, i.e. as part of the hardware performance of the system.).
Gonzalez-Bahl-Plouffe and Mishra are both considered to be analogous to the claimed invention because they are in the same field of computer resource scaling management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl-Plouffe to incorporate the teachings of Mishra to modify the auto-scaling cluster capacity management system to display CPU and memory values and the first, second, third, and fourth values on a GUI, allowing for monitoring of system performance as described in Mishra.
Regarding Claim 15, Gonzalez-Bahl-Plouffe as described in Claim 14 does not explicitly disclose further comprising a graphical user interface for displaying the first value, the second value, the actual value of the node-level built-in resource, the actual value of the container-level built-in resource, the first usage amount, and the second usage amount.
However, Mishra discloses further comprising a graphical user interface for displaying ([0103] an interactive Graphical User Interface (“GUI”) display 1400) the first value, the second value, the actual value of the node-level built-in resource, the actual value of the container-level built-in resource, the first usage amount, and the second usage amount ([0103] the display 1400 contains graphs showing, over time, a number of application instances 1412, CPU/memory usage of VM and contains 1414, control plane availability 1416, network device flow utilization percentage 1418, etc. Selection of portions of the graphic representation 1410 […] may result in the display of additional information about an element […] selection of a “More Info” icon 1430 may let the user request additional data (e.g., to investigate system performance). Please note that displaying CPU and memory usage corresponds to Applicant’s first and second usage amounts, and displaying additional data about an element, i.e., an application instance 1412, corresponds to displaying the values of the node and container-level built-in resources as part of investigating the system performance. The actual values of these resources could be displayed as well, i.e. as part of the hardware performance of the system.).
Gonzalez-Bahl-Plouffe and Mishra are both considered to be analogous to the claimed invention because they are in the same field of computer resource scaling management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl-Plouffe to incorporate the teachings of Mishra to modify the auto-scaling cluster capacity management system to display usage amounts and the first and second built-in resource values on a GUI, allowing for monitoring of system performance as described in Mishra.
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Gonzalez et al. (US 20200310881 A1) in view of Bahl et al. (US 20210019194 A1), further in view of Plouffe et al. (US 20050120160 A1) as applied to Claim 7 above, and further in view of Wray et al. (US 20130086273 A1), hereinafter referred to as Gonzalez, Bahl, Plouffe, and Wray, respectively.
Regarding Claim 12, Gonzalez-Bahl-Plouffe as described in Claim 7 does not explicitly disclose further comprising applying a text file, via a cluster administrator, to update the lower threshold and/or the upper threshold.
However, Wray discloses further comprising applying a text file ([0140] read in, from configuration files. Please note that reading in values from configuration files corresponds to Applicant’s applying a text file.), via a cluster administrator ([0140] administrative settings. Please note that administrative settings correspond to Applicant’s cluster administrator), to update the lower threshold and/or the upper threshold ([0140] threshold […] values […] may be read in, from configuration files. Please note that reading in threshold values from configuration files corresponds to Applicant’s applying a text file to update the lower and/or upper threshold).
Gonzalez-Bahl-Plouffe and Wray are both considered to be analogous to the claimed invention because they are in the same field of scaling computing resources. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl-Plouffe to incorporate the teachings of Wray to modify the lower and upper thresholds to be able to be set by a configuration file, allowing for greater user control over the operation of the system as described in Wray.
Regarding Claim 13, Gonzalez-Bahl-Plouffe as described in Claim 7 does not explicitly disclose further comprising applying a text file, via a cluster administrator, to update a frequency of the periodic determination of the first usage amount of the built-in node-level CPU, the second usage amount of the built-in node-level memory, the third usage amount of the built-in container-level CPU, and the fourth usage amount of the built-in container-level memory.
However, Wray discloses further comprising applying a text file ([0140] read in, from configuration files. Please note that reading in values from configuration files corresponds to Applicant’s applying a text file.), via a cluster administrator ([0140] administrative settings. Please note that administrative settings correspond to Applicant’s cluster administrator), to update a frequency of the periodic determination of the first usage amount of the built-in node-level CPU, the second usage amount of the built-in node-level memory, the third usage amount of the built-in container-level CPU, and the fourth usage amount of the built-in container-level memory ([0140] values, such as, swap memory usage utilization, CPU utilization, or the like, may be determined based in part on user preference […] may be read in. Please note that swap memory usage utilization corresponds to Applicant’s second and fourth usage amounts, CPU utilization corresponds to Applicant’s first and third usage amounts, and doing so based on user preference corresponds to updating the frequency of the periodic determination as it would be obvious to one having ordinary skill in the art to alter the frequency of the determination of these values as part of user preference.).
Gonzalez-Bahl-Plouffe and Wray are both considered to be analogous to the claimed invention because they are in the same field of scaling computing resources. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Gonzalez-Bahl-Plouffe to incorporate the teachings of Wray to modify the user preference of frequency of the first, second, third, and fourth usage amount determinations to be able to be set by a configuration file, allowing for greater user control over the operation of the system as described in Wray.
Response to Arguments
Applicant's arguments filed 03/13/2026 have been fully considered but they are not persuasive.
Applicant’s arguments are summarized as follows:
Claims 10 and 15 have been amended sufficiently to overcome the objections.
Regarding the rejection for Independent Claim 1 under 35 U.S.C. 103, Gonzalez-Bahl does not teach the advertised node-level and container-level extended resources being artificial. Additionally, the cited portions of Gonzalez-Bahl do not teach assigning a first value to an artificial node-level extended resource wherein the first value is set to an actual value of a node-level built-in resource and assigning a second value to an artificial container-level extended resource wherein the second value is set to an actual value of a container-level built-in resource. Therefore, the Claim is allowable over the cited art, and the rejections should be withdrawn.
Since amended Claim 1 is patentable over Gonzalez-Bahl, independent Claims 7 and 14 are also patentable, and the additional cited references alone and in combination do not teach or disclose their limitations.
The dependent claims include patentable features and are in condition for allowance.
Regarding A, the amended claims 10 and 15 have been corrected sufficiently to overcome the basis for the objections by now stating actual values; therefore, the objections are withdrawn.
Regarding B, the examiner respectfully disagrees. The Applicant’s arguments are moot, as the rejections of the Claim now relies on a new grounds of rejection, Gonzalez-Bahl-Plouffe, which discloses the limitations stated by the Applicant via the combination of references, as stated above. Therefore, the recited features can be found in the cited combination of references, and independent Claim 1 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. The rejections under 35 U.S.C. 103 are maintained.
Regarding C, the examiner respectfully disagrees. As previously stated, independent Claim 1 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. Therefore, contrary to Applicant’s arguments, because the similar independent Claims 7 and 14 also contain unpatentable limitations and do not add limitations that overcome the rejection, they likewise remain rejected, and the application is not in condition for allowance.
Regarding D, the examiner respectfully disagrees. As previously stated, independent claims 1, 7, and 14 remain rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. Therefore, contrary to Applicant’s arguments, because the dependent claims depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise remain rejected, and the application is not in condition for allowance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Caldato et al. (US 20190102226 A1) discloses usage factors exceeding first/second thresholds, utilizing an API, containers organized in nodes being implemented via Kubernetes, and abstraction between cloud services provided by the cloud infrastructure system and the physical implementation layer used to provision resources for providing the requested services. (see [0011, 0050, 0057, 0183]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARAZ T AKBARI whose telephone number is (571)272-4166. The examiner can normally be reached Monday-Thursday 9:30am-7:30pm 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, April Blair can be reached at (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FARAZ T AKBARI/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights