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 Objections
Claim 2 and 20 are objected to because of the following informalities: Claims 2 and 20 state the abbreviation “RL-GLB”. While it is assumed to stand for “Global Load Balancer”, the first instance of the term should be spelled out for clarity. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1, 3, 10-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 11,930,073 by Duan et al. (Duan) in view of US 2023/0305892 by Mathew et al. (Mathew).
With respect to claim 1, Duan teaches a method of directing network traffic to distribute client service requests among a set of service backends of a service network (Col. 4 lines 12-58, Fig. 2 – requests/queries are distributed to a hierarchy of backend databases using a load balancer that guarantees user-specified service level objectives), comprising:
regularly obtaining respective capacity and performance information for each of the service backends and providing the information to a trained reinforcement-learning (RL) model that integrates learned request-distribution and reward information for the service network; (Col. 7 lines 43-52, Col. 10 lines 33-67, Col. 11 lines 23-55, Col. 12 lines 22-49, Col. 13 lines 25-42 – to optimally select a backend database, a trained reinforcement learning (RL) model of a load balancer obtains capacity and performance information for corresponding backends, such as latency, storage size, speed, etc. The trained RL load balancer maximizes the notion of a cumulative reward, such as a reward corresponding to a user-specific service level indicator, through repeated interactions with the environment. The RL load balancer is continuously trained and updated.)
operating the RL model to regularly update recommendation values for directing the client service requests to the respective service backends, and regularly providing updated recommendation values to a traffic director to influence traffic-directing thereby; and by the traffic director, directing network traffic at least partly based on the regularly provided updated recommendation values. (Col. 11 lines 23-55, Col. 12 lines 22-49, Col. 13 lines 5 Col. 14 line 19 – RL load balancer continuously updates preferences (recommendation value) for directing client service requests. For example, an initial preference may be updated to a different backend database according to performance or based on service level objectives. A final selection may be made based on updated preference)
Duan does not explicitly state that the service requests are being distributed to a set of clusters. Mathew teaches database systems may make use of a distributed environment including load balancing to different service clusters. (Paragraph 64, 93-96 global level is utilized to receive requests and distribute it to regional computing clusters). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have the backend databases of Duan be part of clusters as in Mathew. One would be motivated to have this beause it would be beneficial to apply the advantages of Duan’s database RL load balancing to other database management environments such as those using clustering systems.
With respect to claim 3, Duan as modified teaches the method of claim 1, and further teaches wherein the reward information reflects a degree of meeting a service level agreement (SLA), including latency and errors, and cost objectives. (Col. 4 lines 20-33, Col. 7 lines 4-19, Col.11 lines 23-55 – load balancer trained in accordance with rewards corresponding with any user specified service level indicator e.g., quality, availability, responsibilities, latency, throughput).
With respect to claim 10, Duan as modified teaches the method of claim 1, wherein the capacity and performance information are one or more of service metrics, application metrics, service cluster metrics, latency, cluster/service resource utilization, policies, data gravity, client/cluster geolocation info, governance, performance, custom policies, custom configuration. (Col. 4 lines 12-58 , Col. 7 lines 4-19, Col.11 lines 23-55 – information can include at least size, speed, queries per second, quality, availability, responsibilities, latency, throughput)
With respect to claim 11, Duan as modified teaches the method of claim 10, wherein the capacity and performance information are ingested via one or more mechanisms selected from open telemetry, Prometheus, and Kubernetes state monitoring (KSM). (Col. 4 lines 12-58 , Col. 7 lines 4-19, Col.11 lines 23-55 – the collection of information- including size, speed, queries per second, quality, availability, responsibilities, latency, throughput- is not limited to any specific mechanism and thus would include in scope any commonly known mechanisms such as open telemetry, Prometheus, and Kubernetes state monitoring (KSM) see also Mathew paragraph 125 )
With respect to claim 12, Duan as modified teaches the method of claim 10, wherein the capacity and performance information are received from one or more third-party monitoring platforms as well as directly from the service clusters. (Mathew Paragraphs 121-125 – metrics can be provided by components of the application service itself or by third party providers)
With respect to claim 13, Duan as modified teaches the method of claim 1, wherein the service clusters provide resources for executing respective workloads of types selected from CPU, database, HPC and GPU workloads, and the service requests are requests for deployment of the workloads on the service clusters. (Duan Col. 4 lines 32-58 – database workloads, Mathew Paragraph 78, 102 – workloads and configurable to the type of loads)
With respect to claim 14, Duan as modified teaches the method of claim 1, wherein the service clusters are deployed across multiple regions, zones, and/or edge locations of a single cloud provider. (Duan Col. 15 lines 33-53, Col. 19 lines 11-26 public/private cloud, remote servers; Mathew Fig. 4b region a and b)
With respect to claim 15, Duan as modified teaches the method of claim 1, wherein the service clusters are deployed across multiple distinct cloud providers. (Duan Col. 19 lines 11-26 – hybrid cloud composed of multiple cloud types, Mathew paragraph 37)
With respect to claim 16, Duan as modified teaches the method of claim 1, wherein the service clusters are deployed across multiple clouds and hybrid clouds including one or more of data centers, on-premises data centers, enterprise data centers/sites, edge clouds, edge data centers. (Duan Col. 15 lines 33-53, Col. 19 lines 11-26 – hybrid cloud composed of multiple cloud types)
With respect to claim 17, Duan as modified teaches the method of claim 1, wherein the RL model is deployed on a smart global load balancing (GLB) platform deployed in one or more cloud environments or one or more data centers. (Mathew Fig. 4b, Paragraph 95 global load balancer 445)
Claims 19 is similar in scope to claim 1 and is rejected based on the same rationale.
Claim(s) 4, 5 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duan and Mathew as applied to claim 1 above, and further in view of US 2011/0271005 by Bharrat et al. (Bharrat).
With respect to claim 4, Duan and Mathew teach the method of claim 1, but do no explicitly disclose wherein the traffic director is a Domain Name System (DNS) server and the recommendation values are weight values reflecting respective current capacities of the service clusters for accepting service requests, the DNS server using the weight values to select among candidate service clusters for a given service when responding to a resolution requests for the given service, the selection being reflected in DNS responses that cause the service clients to direct the service requests to the selected service clusters accordingly.
Bharrat teaches a traffic director can be a DNS server that uses weight values reflecting respective current capacities of the service clusters for accepting service request the DNS server using the weight values to select among candidate service clusters for a given service when responding to a resolution requests for the given service, the selection being reflected in DNS responses that cause the service clients to direct the service requests to the selected service clusters accordingly (Paragraph 8-9, 14, 21, 40-41 servers can communicate capacity metrics to a DNS server, DNS server can use the servers' current capacity, combining priority and weight values, when selecting servers to handle client requests).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have the traffic director of Duan as modified be a DNS server as taught by Bharrat. One would be motivated to have this as the server and DNS interactions of Bharrat provide advantages of load balancing based directly on communications of the server as well as providing the capability of persistent sessions when providing a service.
With respect to claim 5, Duan as modified teaches the method of claim 4, wherein the weight values are calculated by respective dynamic traffic controllers (DTCs) of the service clusters which each monitor load of a service against configured resource constraints and dynamically adjusts the application weight according to how close an application is to reaching its maximum capacity. (Based on the same logic of claim 4, Bharrat further teaches in paragraph 40-41 servers can directly communicate their available load or capacity (e.g., as priority 322 and weight 324 values) to the DNS server)
With respect to claim 9, Duan as modified teaches the method of claim 4, and further teaches wherein a given service is advertised from multiple service clusters, enabling the DNS server to load balance among the service clusters, and wherein (1) an association of a weight with a respective name/address mapping guides the DNS server to balance a distribution of its responses to favor one service cluster over another for one or more of the service requests, and (2) dynamically updating the weight based on service cluster loading allows the DNS server to steer more or less traffic to a given service cluster. (Based on the same logic of claim 4, Bharrat further teaches in paragraph 40-42 – DNS servers uses identity table to map servers to weights, distribution for a service can be made, for example, a smaller portion of requests going to a smaller server while a larger portion goes to a larger capacity server)
Allowable Subject Matter
Claims 2, 6-8, 18 and 20 are objected to as being dependent upon a rejected base claim (Note the minor informality with claims 2 and 20 as well), but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID R LAZARO whose telephone number is (571)272-3986. The examiner can normally be reached M-F 8-4:30.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
/DAVID R LAZARO/Primary Examiner, Art Unit 2455