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 2/03/2026.
In Amendment, no claims are cancelled and no claims are added. Thus, claims 1-20 are pending in this application. This Office Action is made final.
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).
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 a pod definition for the pod (Paragraph 15 “The Kubernetes master 102 may include a controller manager 106 and a horizontal pod autoscaler (HPA) 108. The controller manager 106 and the HPA 108 may implement one or more of the functions described herein. The HPA 108 may be configured using a configuration file. The configuration file may be implemented, for example, as a yaml file. The configuration file may specify a maximum number of pod replicas, a minimum number of pod replicas, and the like.);
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.
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 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 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
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 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 2/24/2026