DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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, 4-5, 9, 12-13, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Price et al. (US PGPUB 2021/0406035; hereinafter “Price”) in view of Ai et al. (US PGPUB 2025/0156213; hereinafter “Ai”), Gangar et al. (US PGPUB 2024/0411574; hereinafter “Gangar”) and Luthra et al. (US PGPUB 2024/0250875; hereinafter “Luthra”).
Claim 1:
Price teaches a computer-implemented method, comprising:
collecting information from a storage cluster associated with pod deletion candidacy ([0039] “the cycling manager 106 communicates with the orchestration system 104 to collect information about active compute resources and their configuration and communicates with the resource provider 102 to instruct the resource provider to create new compute resources or delete outdated compute resources.” [0051] “Typically, the API server 216 can query the agent 208 running on the nodes 202 in the node group 204 to retrieve information about the nodes including information about the pods running on the node, the state/condition of the pods, the available resources on the node: the CPU, memory, and the maximum number of pods 212 that can be scheduled onto the node 202 at any given time.”);
marking a node associated with the selected pod as not schedulable ([0075] “before terminating nodes, the cycling manager 106 may mark the outdated nodes as ‘unschedulable’. To this end, the cycling manager 106 requests the master node 206 to update the properties of the outdated nodes to indicate that these nodes are unschedulable. This prevents the orchestration system 104 from assigning any new jobs to the marked nodes”);
draining the node of application workloads ([0019] “replacing… ten old compute resources in a cluster typically involves… draining the work load off the old compute resource.” [0055] “The node group object includes…a method for deleting pods—draining or waiting. In the draining method, the orchestration system 104 evicts the pods in a node (allowing them to gracefully terminate the current tasks they are performing).”);
deleting the selected pod ([0143] “When the cycling module 114 requests the master node 206 to delete the remaining pods on the node, the master node 206 records the intended grace period (typically a default period of 30s) before the pod is allowed to be forcefully killed… Once the grace period has expired, a KILL signal is sent to those processes, and the pod is then deleted from the API server.”); and
recreating the selected pod with a new configuration ([0049] “If that configuration template is updated, in some cases, the master node 206 creates new DaemonSet pods on existing nodes once the outdated DaemonSet pods are manually deleted. In such cases, any newly created nodes however will be created based on the updated DaemonSet configuration template.”).
With further regard to Claim 1, Price does not teach the following, however, Ai teaches:
selecting a pod for deletion based on pod priorities determined using the collected information ([0017] “the container management system may determine a candidate second node based on the life cycle of the at least one node and the life cycle of the container set on the at least one node, then determine at least one candidate deletion order… and predict a benefit of deleting the container sets from the second nodes according to the candidate deletion order. The benefit may be determined based on resource utilization on the cluster. Then, the container management system determines a target deletion order.” [0080] “Scale-out means adding a pod or adding a node. Scale-in means deleting (removing) a pod or deleting a node.” [0095] “in a scale-in process, the container management system may further dynamically adjust a scale-in order, and increase priorities of the pods.” [0139] “a deletion order (also referred to as a position in a scale-in order or a scale-in priority) is adjusted.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price with the pod deletion selection based on priority as taught by Ai “so that the pods can be preferentially deleted or released” (Ai [0095]) and since “This improves resource utilization, and reduces service costs” (Ai [0018]).
With further regard to Claim 1, Price in view of Ai does not teach the following, however, Gangar teaches:
updating the recreated pod with updated storage software ([0046] “the pods m-x may be updated on nodes 5-8, and since nodes 5-8 are non-cordoned nodes, the computing system may recycle pods m-x in favor of replacing them with nodes m′-x′ with the updated software release on node 5-8.” [0053] “During the update, updated first set of pods are associated with updated software relative to the replaced first set of pods.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price in view of Ai with the updating of software as taught by Gangar as this “supports efficient downscaling and updating of computing clusters” (Gangar [0049]).
With further regard to Claim 1, Price in view of Ai and Gangar does not teach the following, however, Luthra teaches:
marking the node as schedulable ([0052] “After maintenance on a node is complete, an uncordon command may allow scheduling of the node again.” [0062] “The loop 456 includes performing operation 458 in which the IMS 432 simultaneously or sequentially uncordons each O-Cloud node included in the request(s). The loop 456 further includes operation 460 in which IMS 432 marks each O-Cloud node, which has been uncordoned via operation 458, schedulable for one or more new workload deployments. In some embodiments, operation 458 toggles a flag, which results in an O-Cloud node being indicated as being uncordoned.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price in view of Ai and Gangar with the marking of a node as scheduable as taught by Luthra in order to “provide for an ability to quickly and efficiently uncordon O-Cloud nodes such that the O-Cloud nodes may resume NF deployments” (Luthra [0063]).
Claim 4:
Price in view of Ai, Gangar and Luthra teaches the method of Claim 1. Price further teaches wherein the updated storage software is selected from the group consisting of: an image update and a configuration update ([0032] “In order to scale-up or scale-down either automatically or based on external instructions, the resource requesting system 110 provides a launch configuration to the resource provider 102. This launch configuration includes the hardware and resource configuration that is used to create new compute resources for scaling up a compute group. Typically, a compute group is associated with one launch configuration at a time. To change the launch configuration for a compute group a new launch configuration is created and then, the compute group is updated to use the new launch configuration.”).
Claim 5:
Price in view of Ai, Gangar and Luthra teaches the method of Claim 1. Price further teaches wherein the updating includes an orchestration framework update that is based on updating an external component ([0073] “Typically, when a configuration change occurs in one system it takes a finite amount of time for that change to settle in the system. For example, if a node is added in a Kubernetes cluster, it takes finite amount of time for that node addition event to be detected and for the orchestration system to communicate this change to the resource provider and for the resource provider to update its system to reflect this.” [0088] “If a launch configuration or configuration template is updated and a number of compute resources/nodes are added to a node group in quick succession… the cycling manager 106 has to wait for the duration of the watch timer before these changes can be detected. Second, any changes made to the underlying resources by the resource provider 102 may take a finite amount of time to be reflected in the orchestration system 104 and consequently for the orchestration system to update the node group based on those changes. Further, the resource provider and/or orchestration system may be configured to perform some follow up actions when a resource is added to the node group (e.g., deleting another node, updating its scheduling queue, etc.) which may again take a finite amount of time to be percolated to the other systems in the environment 100.”).
Claims 9 and 12-13:
With regard to Claims 9 and 12-13, these claims are equivalent in scope to Claims 1 and 4-5 rejected above, merely having a different independent claim type, and as such Claims 9 and 12-13 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 4-5.
With further regard to Claim 9, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Price reference also anticipates these additional elements of Claim 9, for example, Price teaches:
A computer program product, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions readable and/or executable by a computer ([0154] “the methods disclosed herein are performed by computer system 700 in response to processor 704 executing one or more sequences of one or more instructions contained in main memory 706. Such instructions may be read into main memory 706 from another storage medium, such as storage device 710. Execution of the sequences of instructions contained in main memory 706 causes processor 704 to perform the process steps described herein.”).
Claims 17 and 20:
With regard to Claims 17 and 20, these claims are equivalent in scope to Claims 1 and 4 rejected above, merely having a different independent claim type, and as such Claims 17 and 20 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 4.
With further regard to Claim 17, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Price reference also anticipates these additional elements of Claim 17, for example, Price teaches a system, comprising:
a processor (Fig. 7: Processor 704); and
logic integrated with the processor, executable by the processor, or integrated with and executable by the processor, the logic being configured to perform operations ([0154] “the methods disclosed herein are performed by computer system 700 in response to processor 704 executing one or more sequences of one or more instructions contained in main memory 706. Such instructions may be read into main memory 706 from another storage medium, such as storage device 710. Execution of the sequences of instructions contained in main memory 706 causes processor 704 to perform the process steps described herein.”).
Claims 2-3, 10-11 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Price in view of Ai, Gangar and Luthra as applied to Claims 1, 9 and 17 above, and further in view of Lu (US PGPUB 2015/0149989; hereinafter “Lu”).
Claim 2:
Price in view of Ai, Gangar and Luthra teaches all the limitations of claim 1 as described above. Price in view of Ai, Gangar and Luthra does not teach the following, however, Lu teaches comprising:
inserting the information in a priority queue structure for determining the pod priorities ([0035] “when determining that the configuration file is a newer version, second resident module 16 can further acquire multiple parameters of the node n according to the identification information stored in the second database 18, and then calculate and obtain an update priority value according to the parameters,” wherein parameters associated with ‘nodes’ in Lu are applicable to the ‘pods’ as taught by Price in view of Ai, Gangar and Luthra. [0037] “the second resident module… determines whether the update priority values of all of nodes recorded in the update hash table are larger than an update threshold, and sorts and records the nodes, whose update priority value larger than the update threshold, into an update queue table.”),
wherein the pod priorities are based on a count of checks registered with the priority queue structure ([0035] “The parameters include, for example, a severity of the update package data of all pieces of the firmware of the node n, a quantity of the firmware required to be updated in the node n, the time and network bandwidth for updating the firmware, and a pool load of the node n.” [0036] “For example, while the severity is the highest, the update priority value is 90; while the severity is middle, the update priority value is 60; and while the severity is minimum, the update priority value is 0. In an embodiment, the larger the quantity of the firmware required to be updated is, the larger the update priority value is. For example, whenever the firmware of one physical machine is updated, the update priority value will be added with 10. In an embodiment, the longer the time for updating the firmware is, the less the update priority value is. For example, while the time for updating the firmware is very long, the update priority value is 0. In an embodiment, the wider the bandwidth for updating the firmware is, the less the update priority value is. For example, while the bandwidth for updating the firmware arrives at its maximum, the update priority value is 0. In an embodiment, the larger the pool load of the node n is, the less the update priority value is. For example, while the pool load of the node n arrives at its maximum, the update priority value is 0.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price in view of Ai, Gangar and Luthra with the priority queue as taught by Lu thereby reducing administrator burden by being “capable of automatically updating firmware of servers” (Lu [0003]).
Claim 3:
Price in view of Ai, Gangar, Luthra and Lu teaches all the limitations of claim 2 as described above. Price in view of Ai, Gangar and Luthra does not teach the following, however, Lu teaches comprising:
wherein the checks are static and dynamic ([0035] “The parameters include, for example, a severity of the update package data of all pieces of the firmware of the node n, a quantity of the firmware required to be updated in the node n, the time and network bandwidth for updating the firmware, and a pool load of the node n,” wherein these parameters include static values, i.e. “a severity of the update package data,” and dynamic values, i.e. “network bandwidth for updating”. [0038] “the second resident module 16 can periodically adds a preset value to the update priority values of all of the nodes recorded in the update hash table. For example, the second resident module 16 adds 1 to the update priority values of all of the nodes recorded in the update hash table once every 30 minutes. Therefore, the nodes recorded in the update hash table can be protected from missing the installing of the update package data because the update priority value is too small,” wherein the adding of a “preset value to the update priority values of all of the nodes” indicates a type of dynamic “check”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price in view of Ai, Gangar and Luthra with the priority queue parameters as taught by Lu thereby reducing administrator burden by being “capable of automatically updating firmware of servers” (Lu [0003]).
Claims 10-11 and 18-19:
With regard to Claims 10-11 and 18-19, these claims are equivalent in scope to Claims 2-3 rejected above, merely having a different independent claim type, and as such Claims 10-11 and 18-19 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 2-3.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Price in view of Ai, Gangar and Luthra as applied to Claims 5 and 13 above, and further in view of Jensen et al. (US PGPUB 2023/0318995; hereinafter “Jensen”).
Claim 6:
Price in view of Ai, Gangar and Luthra teaches all the limitations of claim 5 as described above. Price in view of Ai, Gangar and Luthra does not teach the following, however, Jensen teaches:
wherein the updating of the external component is based on registering a webhook to intercept the draining ([0012] “The monitoring may be accomplished, for example, using webhooks that notify the server whenever predefined key performance indicators are met.” [0014] “The server receives an indication of a selectable element (e.g., corresponding to an action) that was selected from the one or more selectable elements. The server causes performance of the action associated with the selectable element that was selected… After the selected action is performed, the server may receive a confirmation that the action was performed and verify whether the action resolved the condition.” [0089] “At 806, the server receives an indication of a selection of an action… the action may be, for example, at least one of draining a node impacted by the condition”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price in view of Ai, Gangar and Luthra with the use of a webhook as taught by Jensen since “Techniques for managing notifications associated with conditions… may be desirable” (Jensen [0011]).
Claim 14:
With regard to Claim 14, this claim is equivalent in scope to Claim 6 rejected above, merely having a different independent claim type, and as such Claim 14 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 6.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Price in view of Ai, Gangar, Luthra and Jensen as applied to Claims 6 and 14 above, and further in view of Doshi et al. (US PGPUB 2025/0315315; hereinafter “Doshi”).
Claim 7:
Price in view of Ai, Gangar, Luthra and Jensen teaches all the limitations of claim 6 as described above. Price in view of Ai, Gangar, Luthra and Jensen does not teach the following, however, Doshi teaches comprising:
establishing a disruption budget for the selected pod to prevent deletion of the selected pod by an external drain, wherein the disruption budget allows the selected pod to self-delete ([0050] “Some systems implement a pod disruption budget (PDB) that establishes a minimum application availability. In many cases, the PDB minimum availability is set to one, meaning that at least one copy of the application must remain alive at all times.” [0053] “Applications 1 and 2 thereby comply with their PDB minimum availability requirements while multiple compute nodes are upgraded in parallel. The batch upgrades BU1 and BU2 ensure that each of Application 1, Application 2, and Application 3 can comply with their respective PDB minimum availability requirements. Notably, Application 3 requires that two compute nodes be available at all times, and therefore, only two of the four compute nodes for Application 3 may be upgraded in parallel.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price in view of Ai, Gangar, Luthra and Jensen with the use of a disruption budget as taught by Doshi in order “to minimize the total time required to upgrade a platform while ensuring that all applications deployed on the platform remain live and do not experience downtime due to the upgrade process” (Doshi [0016]).
Claim 15:
With regard to Claim 15, this claim is equivalent in scope to Claim 7 rejected above, merely having a different independent claim type, and as such Claim 15 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 7.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Price in view of Ai, Gangar, Luthra and Jensen as applied to Claims 6 and 14 above, and further in view of Kuperman et al. (US PGPUB 2025/0284550; hereinafter “Kuperman”).
Claim 8:
Price in view of Ai, Gangar, Luthra and Jensen teaches all the limitations of claim 6 as described above. Price in view of Ai, Gangar, Luthra and Jensen does not teach the following, however, Kuperman teaches comprising:
establishing a webhook for the selected pod to prevent deletion of the selected pod by an external drain, wherein the webhook allows the selected pod to self-delete ([0037] “Mutate pod request 363 is a request to mutate a pod from its default configuration… Mutate pod request 363 may be performed using an admission webhook. Admission webhooks are HTTP callbacks that receive admission requests and do something with them. Admission webhooks may be… mutating admission webhooks. Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults. After all object modifications are complete, and after the incoming object is validated by the API server, validating admission webhooks are invoked and can reject requests to enforce custom policies,” wherein ‘deleting’ is a type of “mutating”. [0038] “when placeholder nodes are to be deleted or when operations are to be scaled down, pod pinner 310 may issue a delete node request 364 to Kubernetes control plane 320.” [0039] “Because binding pods to a node is an immutable action, autoscaler 130 clears the state be deleting the node, deleting the pod, and then creates a placeholder node anew and recreates the pods to be assigned to that placeholder node (e.g., using a mutate pod request 363 with a webhook to monitor for recreation of the pod and responsive assignment to the placeholder node).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Price in view of Ai, Gangar, Luthra and Jensen with the use of a webhook as taught by Kuperman in order “to enforce custom defaults” (Kuperman [0037]).
Claim 16:
With regard to Claim 16, this claim is equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Vattkuti (US Patent 11,204,758) discloses a method and system for determining a patching sequence for applying software patches to correct a plurality of issues on a cloud system that comprises a plurality of pods.
Garg (“Upgrade in Kubernetes Clusters - State of Practice and Analysis from Availability Perspective,” 2022) discusses an “Auto-Metric collector” tool for automating the process of event collection and metric calculation as it relates to Kubernetes cluster upgrading, including discussion regarding identifying upgrade process failure and taking remediation measures.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard 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, Bradley Teets can be reached at (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOANNE G MACASIANO/Examiner, Art Unit 2197
Prosecution Insights