DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This Office Action is sent in response to Applicant’s Communication received 3/29/2024 for application number 18/622,779. The Office hereby acknowledges receipt of the following and placed of record in file: Specification, Drawings, Abstract, Oath/Declaration, claims.
3. Claims 1 – 20 are presented for examination.
Claim Rejections - 35 USC § 103
4. 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.
5. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
7. Claims are rejected under 35 U.S.C. 103 as being unpatentable over Beveridge (U.S. Publication 2024/0419470) (Beveridge hereinafter) in view of Kolesov et al. (U.S. Patent 10,348,893) (Kolesov hereinafter).
8. As per claim 1, Beveridge teaches a computer-implemented method performed by an orchestration component, the method comprising: monitoring for creation of a pair pool object [“the containerized workload may include an operator (not shown) configured to perform one or more functions of container control plane 160. For example, a Kubernetes operator is an application-specific controller that extends the functionality of the Kubernetes API to create, configure, and/or manage instances of complex products on behalf of a Kubernetes user. More specifically, a Kubernetes operator uses custom controllers to monitor and track custom Kubernetes objects, referred to as custom resource definition (CRD) objects, to help ensure that the actual state of the cluster and the desired state of cluster are always in-sync within the cluster (e.g., via continuous monitoring of the CRD objects). Whenever the state of the cluster is different from what has been defined, a Kubernetes operator acts to reconcile the current state of the cluster. Accordingly, in certain aspects, scaling agent 180 is configured to communicate with the operator instead of container control plane 160 to change a number of VMs 104 instantiated on hosts 102 and/or a number of pods and/or containers 130 of one or more containerized workloads running on the VMs 104. ¶ 0030; Kubernetes operator mapped to orchestration component; pods mapped to pair pool objects];
in response to detecting the creation of a pair pool object,
creating a plurality of pair objects [“scaling agent 180 is configured to monitor a utilization of resources of one or more hosts 102 of a computer system, and based on the utilization, scale a number (quantity) of containerized workloads running on the one or more hosts 102,” ¶ 0042];
using a pair operator, detecting creation of the pair objects [“Control plane 160 includes components such as an application programming interface (API) server 162, a cluster store (etcd) 166, a controller 164, and a scheduler 168. Control plane 160's components make global decisions about Kubernetes cluster 150 (e.g., scheduling), as well as detect and respond to cluster events (e.g., starting up a new pod 140 when a workload deployment's replicas field is unsatisfied),” ¶ 0035].
Beveridge does not explicitly disclose but Kolesov discloses in response to detecting the creation of one of the pair objects, instantiating a pair of stateful redundant telephony-grade nodes [“A method for providing redundant Session Initiation Protocol (SIP) call center performance, comprising steps of: instantiating a first SIP server pair comprising a first and a second SIP server, the second SIP server taking a role of backup to the first SIP server; instantiating a second SIP server pair hosted in a geographic location remote from the first SIP server pair, the second SIP server pair comprising a third and a fourth SIP server, the fourth SIP server taking a role of backup to the third SIP server, wherein the second SIP server pair is redundant to the first SIP server pair and operates concurrently with the first SIP server pair; concurrently registering a SIP communication device of a particular agent with both the first and second SIP server pairs; transmitting, by an agent application, data to log-in the particular agent to the first SIP server pair, without logging-in the particular agent to the second SIP server pair; routing, by the first SIP server pair, a telephony call to the SIP communication device of the particular agent logged-in to the first SIP server pair,” Cl. 5; SIP server pairs mapped to nodes].
It would have been obvious to one of ordinary skill in the art, having the teachings of Beveridge and Kolesov available before the effective filing date of the claimed invention, to modify the capability of workload auto-scaling as disclosed by Beveridge to include the capability of maintaining high-availability nodes as taught by Kolesov, thereby providing a mechanism to enhance system efficiency by supporting system resource redundancy.
9. As per claim 2, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein the orchestration component is a custom Kubernetes operator [“the containerized workload may include an operator (not shown) configured to perform one or more functions of container control plane 160. For example, a Kubernetes operator is an application-specific controller that extends the functionality of the Kubernetes API to create, configure, and/or manage instances of complex products on behalf of a Kubernetes user. More specifically, a Kubernetes operator uses custom controllers to monitor and track custom Kubernetes objects, referred to as custom resource definition (CRD) objects, to help ensure that the actual state of the cluster and the desired state of cluster are always in-sync within the cluster (e.g., via continuous monitoring of the CRD objects). Whenever the state of the cluster is different from what has been defined, a Kubernetes operator acts to reconcile the current state of the cluster. Accordingly, in certain aspects, scaling agent 180 is configured to communicate with the operator instead of container control plane 160 to change a number of VMs 104 instantiated on hosts 102 and/or a number of pods and/or containers 130 of one or more containerized workloads running on the VMs 104. ¶ 0030; Kubernetes operator mapped to orchestration component; pods mapped to pair pool objects].
10. As per claim 3, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein the pair pool object specifies a number of pair objects to be created [“Whenever the state of the cluster is different from what has been defined, a Kubernetes operator acts to reconcile the current state of the cluster. Accordingly, in certain aspects, scaling agent 180 is configured to communicate with the operator instead of container control plane 160 to change a number of VMs 104 instantiated on hosts 102 and/or a number of pods and/or containers 130 of one or more containerized workloads running on the VMs 104,” ¶ 0030].
11. As per claim 4, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein the pair operator is responsible for creating two containers for each pair object, each container representing a node within the pair [“Kubelet 170 on each host 102 is an agent that helps to ensure that one or more pods 140 run on each host 102 according to a defined state for the pods 140, such as defined in a configuration file. Each pod 140 may include one or more containers 130,” ¶ 0034; pods mapped to pair objects].
12. As per claim 5, Beveridge and Kolesov teach the method of claim 1. Kolesov further teaches wherein each pair object represents a highly available pair of stateful redundant telephony-grade nodes within the orchestration component [“A method for providing redundant Session Initiation Protocol (SIP) call center performance, comprising steps of: instantiating a first SIP server pair comprising a first and a second SIP server, the second SIP server taking a role of backup to the first SIP server; instantiating a second SIP server pair hosted in a geographic location remote from the first SIP server pair, the second SIP server pair comprising a third and a fourth SIP server, the fourth SIP server taking a role of backup to the third SIP server, wherein the second SIP server pair is redundant to the first SIP server pair and operates concurrently with the first SIP server pair; concurrently registering a SIP communication device of a particular agent with both the first and second SIP server pairs; transmitting, by an agent application, data to log-in the particular agent to the first SIP server pair, without logging-in the particular agent to the second SIP server pair; routing, by the first SIP server pair, a telephony call to the SIP communication device of the particular agent logged-in to the first SIP server pair,” Cl. 5; SIP server pairs mapped to nodes].
It would have been obvious to one of ordinary skill in the art, having the teachings of Beveridge and Kolesov available before the effective filing date of the claimed invention, to modify the capability of workload auto-scaling as disclosed by Beveridge to include the capability of maintaining high-availability nodes as taught by Kolesov, thereby providing a mechanism to enhance system efficiency by supporting system resource redundancy.
13. As per claim 6, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein the detection of pair pool objects by the orchestration component is performed using closed loop automation [“Controller 164 is a control plane 160 component that runs and manages controller processes in Kubernetes cluster 150. As described above, control plane 160 may have (e.g., four) control loops called controller processes, which watch the state of Kubernetes cluster 150 and try to modify the current state of Kubernetes cluster 150 to match an intended state of Kubernetes cluster 150,” ¶ 0038; controller processors mapped to closed loop automation].
14. As per claim 7, Beveridge and Kolesov teach the method of claim 6. Beveridge further teaches wherein closed loop automation comprises continuous monitoring by the orchestration component for objects of relevant types [“Controller 164 is a control plane 160 component that runs and manages controller processes in Kubernetes cluster 150. As described above, control plane 160 may have (e.g., four) control loops called controller processes, which watch the state of Kubernetes cluster 150 and try to modify the current state of Kubernetes cluster 150 to match an intended state of Kubernetes cluster 150,” ¶ 0038; watching the state of the cluster suggests continuous monitoring].
15. As per claim 8, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein the pair pool object includes configuration data specifying a container image to be used for the telephony-grade nodes [“Kubelet 170 on each host 102 is an agent that helps to ensure that one or more pods 140 run on each host 102 according to a defined state for the pods 140, such as defined in a configuration file. Each pod 140 may include one or more containers 130,” ¶ 0034].
16. As per claim 9, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein each telephony-grade node is instantiated within its own dedicated group of containers [“Kubelet 170 on each host 102 is an agent that helps to ensure that one or more pods 140 run on each host 102 according to a defined state for the pods 140, such as defined in a configuration file. Each pod 140 may include one or more containers 130,” ¶ 0034; suggesting the containers are dedicated/exclusive to pods].
17. As per claim 10, Beveridge and Kolesov teach the method of claim 9. Beveridge further teaches wherein the dedicated group of containers is contained within one or more Kubernetes pods [“Whenever the state of the cluster is different from what has been defined, a Kubernetes operator acts to reconcile the current state of the cluster. Accordingly, in certain aspects, scaling agent 180 is configured to communicate with the operator instead of container control plane 160 to change a number of VMs 104 instantiated on hosts 102 and/or a number of pods and/or containers 130 of one or more containerized workloads running on the VMs 104,” ¶ 0030].
18. As per claim 11, Beveridge and Kolesov teach the method of claim 10. Beveridge further teaches wherein the dedicated group of containers are configured with resource limits [“when the resource limit is reached such that additional resources on the one or more hosts 102 are not available for use by VMs 104, the VMs 104 may be configured to use resources according to the share level allocated to the pools,” ¶ 0079].
19. As per claim 13, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches dynamically scaling a number of pairs in the pair pool according to real-time workload metrics [“scaling agent 180 runs as a service or function within a cluster management mechanism integrated with virtualization manager 178, such as VMware's Dynamic Resource Manager (DRS) which also performs hypervisor cluster balancing functions. Scaling agent 180 is configured to determine utilization of resources of computer system 100, and based on the determined utilization, scale a number of VMs 104 running on hosts 102 of computing system 100 and/or scale a number of pods and/or containers 130 running on the VMs 104,” ¶ 0026; dynamic management based on utilization of resources suggests scaling according to real-time metrics].
20. As per claim 14, Beveridge and Kolesov teach the method of claim 13. Beveridge further teaches wherein the real-time workload metrics comprise one or more of: central processing unit (CPU) utilization, memory usage, or network throughput of the telephony-grade nodes [“Another example trigger includes a change in utilization of one or more resource types, such as CPU core and/or memory utilization. For example, if the utilization of one or more resource types changes by a threshold amount (e.g., 15%) since a previous utilization, scaling agent 180 determines to change a number of VMs 104 running on the hosts 102. In certain embodiments, scaling agent 180 determines to change the maximum allowed number of VMs 104 that can run on the hosts 102 (e.g., by changing the pod quota for one or more namespaces) in response to the change in utilization of one or more resource types. In some embodiments, such as where utilization fluctuations of the one or more resource types are estimated to be short in duration, a quota for the one or more resource types (e.g., a CPU quota, memory allocation quota, etc.) may be changed for the one or more namespaces instead of changing the number of VMs 104 running on the hosts 102 or the maximum allowed number of VMs 104 that can run on the hosts 102,” ¶ 0054].
21. As per claim 15, Beveridge and Kolesov teach the method of claim 14. Beveridge further teaches wherein capacity scaling is achieved by managing multiple pairs of telephony-grade nodes [“scaling agent 180 is configured to scale up or down (increase or decrease) VMs having different configurations (also referred to as different VM types). For example, there may be multiple node clusters for a containerized workload, such as a first group of VMs 104 and a second group of VMs 104, and the VMs 104 in the different groups may have different configurations,” ¶ 0065].
22. As per claim 16, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein orchestration component is operable to perform one or more of the following operations: creation, deletion, scaling, and/or failover of the telephony-grade nodes [“scaling agent 180 is configured to scale up or down (increase or decrease) VMs having different configurations (also referred to as different VM types). For example, there may be multiple node clusters for a containerized workload, such as a first group of VMs 104 and a second group of VMs 104, and the VMs 104 in the different groups may have different configurations,” ¶ 0065].
23. As per claim 17, Beveridge and Kolesov teach the method of claim 1. Beveridge further teaches wherein the method is implemented within a cloud-native environment supporting multi-cloud or hybrid cloud deployment [“modern applications can be deployed in one or more data centers, such as in a multi-cloud or hybrid cloud fashion. For example, an application may be deployed in a single cloud or across multiple clouds and thus consume both cloud services executing in a public cloud and local services executing in a private data center (e.g., a private cloud). Within the public cloud or private data center, modern applications can be deployed onto one or more virtual machines (VMs), containers, application services, and/or the like,” ¶ 0001].
24. As per claim 19, it is a system claim having similar limitations as cited in claim 1. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 1 above.
25. As per claim 20, it is a device claim having similar limitations as cited in claim 1. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claim 1 above.
26. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Beveridge and Kolesov in further view of Smith et al. (U.S. Publication 2002/0059734) (Smith hereinafter).
27. As per claim 12, Beveridge and Kolesov teach the method of claim 1. Beveridge and Kolesov do not explicitly disclose but Smith discloses wherein upon failure of one of the pair of stateful redundant telephony-grade nodes, the other node automatically assumes a role of the failed node [“system 100 may include a primary appliance node 170 and a not shown, redundant appliance node having a construction that is identical to node 170. The redundant appliance node may utilize conventional failure detection and/or fault tolerance techniques to determine if primary node 170 is no longer operating as expected. If the redundant appliance node determines that the primary node 170 is no longer operating as expected, the redundant appliance node may utilize conventional failover techniques to assume the operations that were previously performed in system 100 by primary node 170,” ¶ 0048].
It would have been obvious to one of ordinary skill in the art, having the teachings of Beveridge, Kolesov and Smith available before the effective filing date of the claimed invention, to modify the capability of workload auto-scaling as disclosed by Beveridge and Kolesov to include the capability of managing node failover scenarios as taught by Smith, thereby providing a mechanism to enhance system efficiency by supporting system resource redundancy utilization.
28. Claim 18 is are rejected under 35 U.S.C. 103 as being unpatentable over Beveridge and Kolesov in further view of Arunachalam et al. (U.S. Publication 2020/0007628) (Arunachalam hereinafter).
29. As per claim 18, Beveridge and Kolesov teach the method of claim 1. Beveridge and Kolesov do not explicitly disclose but Arunachalam discloses wherein the telephony-grade nodes support IPv4/IPv6 dual-stack operation [“The 5G NR network is a heterogeneous network comprising multiple radio resources to fulfil a requirement of the higher data rates and an ultra-low latency. multi-connectivity (MC) feature is another emerging technology for the 5G NR network, where the MC feature enables the UE (100) to aggregate multiple radio resources from different radio access technologies (RATs) such as a Wi-Fi network 400, the 4G-LTE network and the 5G NR network. Further, the MC feature enables the UE 100 to connect simultaneously to different RATs. The UE 100 is equipped with multiple network interfaces (e.g. Wi-Fi network interface, cellular network interface) and support dual stack networks (i.e. IPv4/IPv6),” ¶ 0041].
It would have been obvious to one of ordinary skill in the art, having the teachings of Beveridge, Kolesov and Arunachalam available before the effective filing date of the claimed invention, to modify the capability of workload auto-scaling as disclosed by Beveridge and Kolesov to include the capability of managing connections with content servers as taught by Arunachalam, thereby providing a mechanism to enhance system efficiency by supporting system resource redundancy via the use of standard protocols.
Conclusion
30. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C WOOD whose telephone number is (571)272-5285. The examiner can normally be reached Monday - Friday, 8:00 am - 4:30 pm.
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, Chat C Do can be reached at 571-272-3721. 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.
/WILLIAM C WOOD/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights