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 .
DETAILED ACTION
This communication is responsive to Amendment filed 5/21/2026.
In Amendment, no claims are cancelled and no claims are added. Thus, claims 1-20 are pending in this application.
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-5, 8 and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Potturu (US 2021/0004387) in view of Jain (US 2023/0244392) in further of Jiang (US 20240103896).
As per claim 1, Potturu discloses a method for managing resources of a distributed system, the method comprising:
obtaining container operation metrics for pods hosted by the distributed system (Paragraph 21 “one or more usage metrics based on the data characterizing the message queue 118. The usage metrics may include any metrics that indicate the usage of the message queue 118, and may include some or all of the data characterizing the message queue 118, metrics derived from that data, or any combination thereof. The usage metrics may be based on a current size of the message queue 118, a previous size of the message queue 118, a rate of change of the size of the message queue 118, and the like.),
for a pod of the pods, performing a workload analysis of containers of the pod obtain container level metrics for the pod (Paragraph 11 “To account for increased or decreased usage, a pod may be “horizontally scaled” by creating additional replicas of the pod or reducing the number of replicas. When implemented as a control loop, this technique is referred to as “horizontal pod autoscaling.”)
making a determination regarding whether to perform pod level of container level scaling based on the container level metrics for the pod (Paragraph 17 “The Kubernetes node 104 may include one or more pod replicas 112. Each pod replica may implement one or more containers. Each container may implement an application. Each pod may be associated with an owner, for example such as a customer of the pod system.);
in a first instance of the determination where container level scaling for the pod is to be performed:
updating container membership in the pod based on the pod definition to obtain an updated pod (Paragraph 23 “The custom metrics server 126 may respond to such queries by providing stored usage metrics. The HPA 108 may employ the usage metrics to horizontally scale the pod replicas 112 in the pod system.); and
providing computer implemented services using the updated pod (Paragraph 23).
Potturu does not expressly disclose but Jain discloses
determining, from a pod definition, dependencies among the containers (Paragraph 5 “The container orchestration platform can deploy containers on nodes (e.g., a virtual machine, physical hardware, etc.) that have allocated compute resources (e.g., processor, memory, etc.) for executing applications hosted within containers. Applications (or processes) hosted within multiple containers may interact with one another and cooperate together. For example, a storage application within a container may access a deduplication application and a compression application within other containers in order deduplicate and/or compress data managed by the storage application. Container orchestration platforms often offer the ability to support these cooperating applications (or processes) as a grouping (e.g., in Kubernetes this is referred to as a pod). This grouping (e.g., a pod) can supports multiple containers and forms a cohesive unit of service for the applications (or services) hosted within the containers. Containers that are part of a pod may be co-located and scheduled on a same node, such as the same physical hardware or virtual machine. This allows the containers to share resources and dependencies, communicate with one another, and/or coordinate their lifecycles of how and when the containers are terminated.”);
making a determination regarding whether to perform pod level of container level scaling based on the dependencies among the containers (Paragraph 25 “Accordingly, as provided herein, a traditional vertical pod autoscaler (e.g., resource scaling functionality) is modified with the ability to interpret custom objects that are not natively supported by the container orchestration platform. The traditional vertical pod autoscaler is an autoscaling tool that helps size pods for optimal CPU and memory resources required by the pods.” That is, the disclosed autoscaler determines which memory resources (ie, claimed dependencies) are required by the containers and makes determinations on how to scale the pods accordingly.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Potturu to include the teachings of Jain because it provides for the purpose of efficiently balancing workloads between containers by ensuring that dependencies needed in a certain container are taken into account when deciding how to scale. In this way, the combination benefits from the increased granularity which affords a higher level of efficiency.
Potturu does not expressly disclose but Jiang discloses the containers comprising an underutilized container and and over utilized container (Paragraph 66 ““Consumption predictors,” as used herein, refer to the metrics that are used to predict utilization of the resources for the components of node 204 of DBaaS cluster 202 identified as being a potential bottleneck. For example, such consumption predictors include CPU utilization, memory utilization, disk utilization, input/output utilization, timeline of called components of node 204 of DBaaS cluster 202 identified as being a potential bottleneck, a traffic generation model and the relationship of components of node 204 of DBaaS cluster 202 identified as being a potential bottleneck.”);
updating a pod definition for the pod to increase a number of instances of the overutilized container (Paragraph 31 “In some embodiments of the present disclosure, the present disclosure comprises a computer-implemented method, system and computer program product for scaling a resource of a Database as a Service (DBaaS) cluster in a cloud platform. In one embodiment of the present disclosure, user service requests from a service cluster to be processed by the DBaaS cluster are received. A “service cluster,” as used herein, refers to a cluster of nodes for receiving and forwarding service requests to the DBaaS cluster. A “DBaaS cluster,” as used herein, refers to a cluster of nodes for handling such service requests. For example, an ingress gateway of the service cluster may receive and forward such requests to a sidecar which invokes a DBaaS service to handle such a service request. The DBaaS cluster and the service cluster each consists of a set of worker machines, called nodes, that run containerized applications (containerized applications package an application with its dependencies and necessary services). Each of the nodes may include one or more pods containing a group of one or more containers. A “container,” as used herein, refers to a standard unit of software that packages up code and all its dependencies so that the application runs quickly and reliably from one computing environment to another. A first set of tracing data from the user service requests is generated by a service mesh facilitating service-to-service communication between the service cluster and the DBaaS cluster. A second set of tracing data is generated by the DBaaS cluster from handling the user service requests. Such tracing data (both first and second sets) illustrates how the service components of a node of a DBaaS cluster operate, execute and perform in handling service requests. A dependency tree is then generated to discover application relationships to identify potential bottlenecks in nodes of the DBaaS cluster based on the first and second sets of tracing data. A “dependency tree,” as used herein, refers to a graph illustrating the relationship between the services, such as the service pairs handling a particular type of request (e.g., create request, indexing, replication). One or more pods of a node of the DBaaS cluster are then scaled (scaled up or down) based on the dependency tree, which is used in part, to predict the utilization of the resources of the components of the DBaaS node identified as being a potential bottleneck. When the predicted utilization of the resources is above or below a threshold level, a scale operation is executed to scale the pod(s) of the DBaaS node identified as being a potential bottleneck. In this manner, system bottlenecks at the DBaaS are addressed by identifying potential bottlenecks involving nodes of the DBaaS cluster and intelligently scaling the pod(s) in a node of the DBaaS cluster identified as being a potential bottleneck prior to the bottleneck actually occurring.”);
determining that the underutilized container is independent on an operation of the overutilized container (Paragraph 30 “Consumption predictors (e.g., memory utilization, timeline of called components of the node of the DBaaS cluster, traffic generation model, etc.) for the components of the node of the DBaaS cluster identified as being a potential bottleneck may be analyzed so that the utilization of the resources for such components is determined. The predicted utilization of the resources for the components of the DBaaS node identified as being a potential bottleneck is determined based on the determined utilization of the resources of the components of the DBaaS node identified as being a potential bottleneck and a timeline of called components of the DBaaS cluster. A scale operation may then be executed to scale one or more pods in the node of the DBaaS cluster identified as being a potential bottleneck in response to the predicted utilization of the resources being above or below a threshold level. A more detailed description of these and other features will be provided below.”);
updating the pod definition for the pod to decrease a number of instances of the underutilized container (Paragraph 61 “In one embodiment, DBaaS component analyzer 219 accesses the data structure to determine whether a potential bottleneck has been identified in dependency tree 300 using table 400. In one embodiment, DBaaS component analyzer 219 utilizes a software tool for analyzing the data structure to determine whether a potential bottleneck has been identified in dependency tree 300 using the information found in tracing data 216, such as, but not limited to, IBM® Cognos®, Microsoft® Power BI, Sisense®, Thoughtspot, etc.” Paragraphs 66-67 ““Consumption predictors,” as used herein, refer to the metrics that are used to predict utilization of the resources for the components of node 204 of DBaaS cluster 202 identified as being a potential bottleneck. For example, such consumption predictors include CPU utilization, memory utilization, disk utilization, input/output utilization, timeline of called components of node 204 of DBaaS cluster 202 identified as being a potential bottleneck, a traffic generation model and the relationship of components of node 204 of DBaaS cluster 202 identified as being a potential bottleneck. [0067] In one embodiment, metrics analyzer 221 analyzes the consumption predictors, such as CPU utilization, memory utilization, disk utilization, and input/output utilization, using various software tools, including, but not limited to, Paessler® PRTG, AIDA64 Extreme, Wise System Monitor, Rainmeter, SolarWind® Network Performance Monitor, etc. Based on such an analysis, the utilization of the resources for the components of node 204 of DBaaS cluster 202 identified as being a potential bottleneck is obtained.”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Potturu to include the teachings of Jiang because it allows for the number of instances of a container to be optimized based the utilization rates of the containers.
As per claim 2, Potturu further discloses wherein in a first instance of the updating of the pod definition where a container level metric of the container level metrics fell below a first workload threshold for a container of the containers:
the pod definition is updated to specify at least one additional instance of the container (Paragraph 23).
As per claim 3, Potturu further discloses wherein in a second instance of the updating of the pod definition where the container level metric of the container level metrics fell below a second workload threshold for the container:
the pod definition is updated to specify at least one less instance of the container (Paragraph 23).
As per claim 4, Potturu further discloses wherein updating the container membership comprises instantiating the at least one additional instance of the container or terminating operation of an instance of the container (Paragraph 12).
As per claim 5, Potturu further discloses
wherein making the determination comprises:
comparing a first workload of a first container of the containers to a workload threshold to obtain a first comparison result (Paragraph 32); and
comparing a second workload of a second container of the containers to the workload threshold to obtain a second comparison result (Paragraph 32).
As per claim 8, Potturu further discloses further comprising:
for a container of the containers, performing a performance analysis of the container to obtain a container performance rating (Paragraph 31-33 “threshold”);
making a second determination regarding whether to the container performance rating indicates that the container is undesirable; (Paragraph 31-33 “threshold”);
in a first instance of the second determination where the container is undesirable:
updating a pod definition for the pod to replace the container (Paragraph 31-33 “threshold”);
updating the updated pod to replace the container using the pod definition to obtain a second updated pod (Paragraph 34) and
providing the computer implemented services using the second updated pod (Paragraph 34).
As per claims 11-15, they are medium claims having similar limitations as cited in claims 1-5 and are rejected under the same rationale.
As per claims 16-20, they are system claims having similar limitations as cited in claims 1-5 and are rejected under the same rationale.
Claims 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Potturu in view of Jain in further view of Jiang in further view of Krishna (US 2020/0257512).
As per claim 6, Potturu does not expressly disclose but Krishna discloses wherein making the determination further comprises:
in a first instance where the first comparison result indicates that the workload threshold is exceeded and the second comparison result indicates that the workload threshold is not exceeded:
concluding that container level scaling is to be performed (Paragraph 9-10).
Therefore it would have been obvious to one of ordinary skill in the art at the time of filing to modify the method of Potturu to include the teachings of Krishna because it provides for the purpose of efficiently balancing workloads between containers. In this way, the combination benefits by being able to scale up or scale down the number of containers based on the workload.
As per claim 7, Potturu further discloses wherein making the determination further comprises:
in a first instance where the first comparison result indicates that the workload threshold is exceeded and the second comparison result indicates that the workload threshold is exceeded:
concluding that pod level scaling is to be performed (Paragraphs 13-14).
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Potturu in view of Jain in further view of Jiang in further view of Stopel (US 2017/0098072).
As per claim 9, Potturu does not expressly disclose but Stopel discloses wherein the second determination is based, at least in part, on a security state for the container (Paragraph 17 “detecting vulnerabilities in software containers at runtime. The method comprises monitoring events triggered as a result of changes to an application layer of a software container; based on the monitored events, determining if at least one file has been changed; upon determination that at least one file has been changed, scanning the at least one file to detect at least one type of vulnerability; and upon determination of at least one type of known vulnerability, generating a detection event.”).
Therefore it would have been obvious to one of ordinary skill in the art at the time of filing to modify the method of Potturu to include the teachings of Stopel because it ensures the security of a container. In this way, the combination benefits by making sure that containers do not contain malicious code.
As per claim 10, Potturu does not expressly disclose but Stopel discloses wherein the second determination is based, at least in part, on an operating state for the container, the operating state being based on software component versions of the container (Paragraph 60).
Response to Arguments
Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY A MUDRICK whose telephone number is (571)270-3374. The examiner can normally be reached 9am-5pm Central Time.
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, Pierre Vital can be reached at (571)272-4215. 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.
/TIMOTHY A MUDRICK/Primary Examiner, Art Unit 2198 6/02/2026
Prosecution Insights