DETAILED ACTION
Claims 1-20 are presented for examination.
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 .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 9, 15, and 18-19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Akers et al. (US PG Pub No. 2018/0316769 A1).
Regarding claim 9, Akers teaches a service access method, applicable to a multi-cluster load balancing node in a multi-cluster service system comprising at least one service VPC responsible for providing a target service (Fig 1, wherein IVN 110A implementing service Svc1 with implementation fleet 120; [0003], an IVN may also be referred to as a virtual private cloud) and at least one client VPC which can access the target service (Fig 1, Svc1 consuming IVNs 110B-110D contain consumer sets 125A-125C), the method comprising:
generating in advance an information mapping relationship among second service information which the target service has in each client VPC (Fig 2; [0025], wherein a respective private address for Svc1 is provided for each service-consuming IVN; [0040]; Fig 2, private addresses 250A, 250B and 250C each belong to the address range of a different service-consuming IVN and are assigned to the virtual network interfaces 277 of load balancer 256), first service information which the target service has in each service VPC (Figs 2-3; [0039-41], wherein virtual network interfaces 277 attaches to load balancer 256, established at the service-implementing IVN in response to the registration request and assigned a private address), and information of a service instance in each service VPC which can provide the target service ([0037], wherein the registration request indicates the set of resource to which service requests should be directed using load balancing); and
load-balancing, based on the information mapping relationship, an access request for the target service from any client VPC onto a target service instance in the at least one service VPC, to enable the target service instance to provide the target service for a service instance corresponding to the access request ([0037], [0041], wherein load balancer 256 receives service requests arriving at private address 250 and distributes them among compute instances according to a selected load balancing algorithm, such as random, round-robin, or selection based on lowest estimated workload; [0026], the response is returned to the requesting compute instances in the consuming IVN).
Regarding claim 15, Akers teaches an information configuration method, applicable to a multi-cluster service management and control node in a multi-cluster service system comprising at least one service VPC responsible for providing a target service and at least one client VPC which can access the target service (Fig 1, wherein IVN 110A implementing service Svc1 with implementation fleet 120; [0003], an IVN may also be referred to as a virtual private cloud), the method comprising:
acquiring and delivering second service information which the target service has in each client VPC (Figs 3-4; [0047], wherein in response to EnablePrivateConnectivity request 409 identifying the service and the consumer’s IVN, the control plane identifies a private IP address accessible from within the consumer IVN and assigns it to a virtual network interface associated with the service’s load balancer), first service information which the target service has in each service VPC ([0041], wherein in response to the RegisterServiceForPrivateAccess request 305, the control plane establishes the load balancer and assigns one or more virtual network interfaces to it), and information of a service instance in each service VPC which can provide the target service (Fig 3; [0041] wherein request 305 indicates the set of resources to which service request should be directed using load balancing) to a multi-cluster load balancing node, to be used by the multi-cluster load balancing node to locally generate an information mapping relationship (Fig 2; [0040-41], wherein the control plane configures load balancer 256 with the private addresses 250 on its virtual network interfaces 277 and with its backend compute instances);
wherein the information mapping relationship is used for load balancing an access request for the target service from any client VPC onto a target service instance in the at least one service VPC (Fig 2; [0037], wherein load balancer 256 distributes request received at private addresses 250 among the back-end compute instances).
Regarding claims 18-19, they are the device and medium claims of claim 9 above. Therefore, they are rejected for the same reasons as claim 9 above.
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.
Claim(s) 1, 6-7 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Akers et al. (US PG Pub No. 2018/0316769 A1) in view of Pahwa et al. (US PG Pub No. 2020/0314173 A1).
Regarding claim 1, Akers teaches a multi-cluster service system, comprising:
a plurality of service clusters for providing services externally and distributed in a plurality of VPCs (Fig1, wherein a service implementation fleet 120 of compute instances 112A-112B in IVN 110A provides Svc1 to other IVNs, compute instances 112K-112U are distributed in IVNs 110B-11D; Fig 6, wherein a privately accessible service may also be implemented at several different IVNs located in respective availability containers, each with its own private endpoint);
wherein the plurality of VPCs comprise at least one service VPC responsible for providing a target service and at least one client VPC which can access the target service (Fig 1, service complementing IVN 110A, Svc1 consuming IVNs 110B-110D), and the target service having first service information in each service VPC and second service information in each client VPC ([0040]; Fig 2 private address 250A-250C, each from the address range of a respective consuming IVN, and the virtual network interfaces 277 of load balancer 256 in the service-implementing IVN);
a multi-cluster load balancing node for generating in advance an information mapping relationship among second service informationbalancing algorithm, such as random, round-robin, or selection based on lowest estimated workload; [0026], the response return to the requesting compute instances in the consuming IVN).
Akers does not teach the service implementation fleets as service clusters (e.g. container orchestration clusters), or a single load balancing node that distributes requests across service instances belonging to a plurality of such clusters.
Pahwa teaches a multi-cluster container orchestration system in which a software application is hosted across a set of destination clusters 120a-120n, each cluster comprising pods 122 executing the application and each associated with geographical region 121a-121n (Fig 1; [0029-30]). Pahwa’s multi-cluster load balancer 130 load balances application requests across the destination clusters (Fig 1; Fig 5, 502-506). For each destination cluster, a derived service 220 creates a network endpoint group (NEG) 230 whose endpoints 231 each carry the IP address 242 and port 244 of a respective pod and these NEGs serve as the backends of the load balancer ([0038]; Figs 2 and 3B). The NEG endpoints function the “information of a service instance … which can provide the target service”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to load balance requests across service instances of a plurality of service implementation fleets. One would be motivated by the desire to utilize a load balancer targeting multiple clusters to provide a single point of management and configuration to keep services available if a cluster goes offline as taught by Pahwa ([0028]).
Regarding claim 6, Akers teaches a multi-cluster service management and control node for acquiring and delivering the second service information which the target service has in each client VPC, the first service information which the target service has in each service VPC, and the information of the service instance in each service VPC which can provide the target service to the multiple-cluster load balancing node, to be used by the multiple-cluster load balancing node to locally generate the information mapping relationship (Figs 3-4; [0041], wherein the set of resources are named for load balancing; [0041] wherein a private address from the consumer IVN’s range to be assigned to a virtual network interface of the load balancer).
Regarding claim 7, Akers and Pahwa teach a cluster management and control node, and a VPC network management and control node; wherein the multi-cluster service management and control node is further used for:
automatically discovering, in a case where the target service is a containerized service, based on a service exposure mechanism, a target service exposed externally by the at least one service VPC (Pahwa Fig 2; [0035-36], wherein multi-cluster controller 200 selects from cluster registry 125 and by label matching criteria 213, the clusters hosting the multi-cluster service 210, and automatically instantiates and manages derived services 220 in each), and at least one client VPC which needs to access the target service, configuring the second service information which the target service has in each client VPC (Akers [0054] wherein metrics analyzer 571 automatically detects compute instances in another IVN sending requests to a registered service; [0049], the control plane assigns a private address for the service accessible from that IVN), and acquiring, by the cluster management and control node, the first service information which the target service has in each service VPC, and the information of the service instance in each service VPC which can provide the target service (Pahwa [0038], wherein derived services 220 and NEG controllers 232 produce, per cluster, the endpoints 231 with pod IP addresses 242 and ports 244 used by the load balancer); and
deploying, according to the second service information which the target service has in each client VPC, by the VPC network management and control node, in each client VPC, an endpoint corresponding to the target service (Aker [0047], wherein the control plane assigns the private address from the consuming IVN’s range to a virtual network interface associated with the service and records it in the consumer IVN’s networking metadata).
Regarding claim 16-17, it is the method claim of claim 7 above. Therefore, it is rejected for the same reasons as claim 7 above.
Claim(s) 2-4, 10-13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Akers et al. (US PG Pub No. 2018/0316769 A1) in view of Pahwa et al. (US PG Pub No. 2020/0314173 A1), further in view of Mittal et al. (US PG Pub No. 2020/0099656 A1).
Regarding claim 2, Akers teaches wherein a first virtual network interface card device is deployed in each service VPC as a traffic access point of a target service, the first virtual network interface card device has a first private network IP address (Fig 2, wherein one or more virtual network interfaces are attached to load balancer 256, each with an assigned private IP address and packets addressed to that IP address are received by the load balancer compute instances).
Akers does not teach first service information which the target service has in the service VPC comprises the first private network IP address and a port number of the target service.
Mittal teaches mapping a service executing in a service provider’s virtual network 102 into a service consumer’s virtual network 104 ([0029]). A subnet is created in the provider’s virtual network as the provider-side endpoint of a private channel and the internal load balancer has a customer IP address visible only within the provider’s virtual network ([0030-31]; Fig 1; Fig 3, 302-304). Service requests carry a destination port of the service that the load balancer maps to a port of the selected virtual machine ([0033]; Fig 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to identify the service by the address plus its port. One would be motivated by the desire to allow for provider virtual machine to see traffic as originating within their own virtual network so that the platform can serve many consumers that use the same or overlapping address space as taught by Mittal ([0026]).
Regarding claim 3, Mittal teaches wherein a second virtual network interface card device bound to the target service is deployed in each client VPC as a traffic routing point of the target service, the second virtual network interface card device has a second private network IP address, and second service information which the target service has in the client VPC comprises the second private network IP address and a port number or mapped port number of the target service (Figs 1-2; Fig 4, 402-406, wherein a subnet is created in the consumer’s virtual network and consumer virtual machine 120 addresses service requests on the service port and the address is replaced with the load balancer’s routable address so that the traffic is routed to the load balancer).
Regarding claim 4, Akers and Mittal teach wherein the multi-cluster load balancing node is specifically used for: receiving an access request sent by any service instance in any client VPC through access to a second virtual network interface card device in the client VPC, wherein the access request comprises identification information of the any client VPC and a second private network IP address (Akers Fig 2, wherein requests from each consuming IVN reach load balancer addressed to that IVN’s private address 250A-C; Mittal [0038], wherein consumer virtual machine 120 sends the request to consumer-side address 192.168.2.4 and the host node embeds a general routing encapsulation key that uniquely identifies the consumer’s virtual network);
determining, according to the identification information of the any client VPC and the second private network IP address, in conjunction with the information mapping relationship, the target service instance and a target private network IP address, wherein the target private network IP address is a first private network IP address which the target service has in a service VPC where the target service instance is located (Mittal Fig 4, 408-414, [0041-42], wherein internal load balancer 106 selects virtual machine 130 among multiple virtual machines, and NAT table 128 maps the request to provide-side subnet 116 address 10.1.1.3 which is the same provider virtual network as the selected machine); and
sending, according to an IP address of the target service instance and the target private network IP address, the access request to the target service instance, to enable the target service instance to provide the target service for a service instance corresponding to the access request (Mittal Fig 4, 416, wherein the translated packed is communicated to virtual machine using its IP address, [0056], with the provider-side subnet address as the source).
Regarding claim 10, it is the method claim of claim 4 above. Therefore, it is rejected for the same reasons as claim 4 above.
Regarding claim 11, Akers and Mittal teach converting a source IP address and a destination IP address of the access request into the target private network IP address and the IP address of the target service instance, respectively (Mittal [0031], wherein the source IP address of the request is converted into the provider-side address and the destination IP address is converted into the IP address of the selected virtual machine); and
sending, via the first virtual network interface card device in the service VPC where the target service instance is located, the access request after address conversion to the target service instance, to enable the target service instance to provide the target service for the service instance corresponding to the access request (Akers [0039] wherein outbound packets from a load balancer compute instance carry the address of the attached virtual network interface as their source and are transmitted via the interface card to which it is attached).
Regarding claim 12, Pahwa teaches wherein the at least one service VPC comprises a plurality of service VPCs distributed in different regions (Abstract), and determining the target service instance according to the identification information of the any client VPC and the second private network IP address, in conjunction with the information mapping relationship, comprises:
acquiring, according to the identification information of the any client VPC and the second private network IP address in conjunction with the information mapping relationship, the plurality of service VPCs and information of a service instance therein which can provide the target service ([0038], wherein the destination clusters and their endpoints are identified for a requester service corresponding to acquiring the plurality of service VPCs and their service instance information );
determining, according to regions where the plurality of service VPCs are located and/or the number of service instances contained which can provide the target service, load balancing weights corresponding to the plurality of service VPCs ([0045], wherein each request is routed based on geographical regions of the clusters); and
determining, according to the load balancing weights corresponding to the plurality of service VPCs, the target service instance from service instances in the plurality of service VPCs which can provide the target service ([0052], wherein each cluster is assigned a percentage of total traffic and routes requests randomly according to those percentages while accounting for each cluster’s capacity).
Regarding claim 13, Pahwa teaches wherein determining, according to the regions where the plurality of service VPCs are located, the load balancing weights corresponding to the plurality of service VPCs, comprises: determining, according to a location relationship between regions where the plurality of service VPCs are located and a region where the multi-cluster load balancing node is located, the load balancing weights corresponding to the plurality of service VPCs; wherein a load balancing weight of a service VPC located in a same region as the multi-cluster load balancing node is greater than a load balancing weight of a service VPC located in a different region from the multi-cluster load balancing node ([0046]; [0048]; [0050]).
Regarding claim 20, Akers teaches a multi-cluster service management and control node for acquiring and delivering the second service information which the target service has in each client VPC, the first service information which the target service has in each service VPC, and the information of the service instance in each service VPC which can provide the target service to the multiple-cluster load balancing node, to be used by the multiple-cluster load balancing node to locally generate the information mapping relationship (Figs 3-4; [0041], wherein the set of resources are named for load balancing; [0041] wherein a private address from the consumer IVN’s range to be assigned to a virtual network interface of the load balancer).
.
Claim(s) 5 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Akers et al. (US PG Pub No. 2018/0316769 A1) in view of Pahwa et al. (US PG Pub No. 2020/0314173 A1), further in view of Liu (US PG Pub No. 2022/0337545 A1).
Regarding claim 5, Akers does not teach wherein the multi-cluster load balancing node is located in a system VPC and is further used for: deploying, in the system VPC, a third virtual network interface card device bound to the target service, wherein the third virtual network interface card has a third private network IP address, and third service information which the target service has in the system VPC comprises the third private network IP address and a port number of the target service; and establishing, through the third service information which the target service has in the system VPC, an information mapping relationship among the second service information which the target service has in each client VPC, the first service information which the target service has in each service VPC, and the information of the service instance in each service VPC which can provide the target service.
Liu teaches a first VPC 330 and a second VPC 340 with overlapping private address segments that communicate through a third VPC 350 whose private address segment differs from both (Figs 3A-3B; [0086]). Liu further teaches control platform 316 allocates private network address to gateway 1 and gateway 2 and each gateway holds an address belonging to the third VPC for external communications ([0090]; [0108]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to places Aker’s load balancing node in a separate system VPC, to assign that node a virtual network interface with a third private IP address per target service. One would be motivated by the desire to allow VPCs with overlapping private addresses to communicate by routing through an intermediate VPC with distinct address segments as taught by Liu ([0004]).
Regarding claim 8, Akers does not teach wherein the multi-cluster service management and control node is further used for: receiving, in a case where the target service is a virtual machine-based service, service configuration information submitted by a user, wherein the service configuration information comprises information of at least one service VPC where the target service is located, the first service information which the target service has in each service VPC, the information of the service instance in each service VPC which can provide the target service, and information of each client VPC which needs to access the target service, and the second service information which the target service has in each client VPC; and deploying, according to the second service information which the target service has in each client VPC, by the VPC network management and control node, in each client VPC, an endpoint corresponding to the target service.
Liu teaches a control platform presenting configuration pages on which a user enters, for each gateway, the VPC in which it is located, the VPC to which it connects, and its private networking address (Figs 5A and 5D). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to allow users to enter first and second service information directly. One would be motivated by the desire to allow for user control over address planning.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Akers et al. (US PG Pub No. 2018/0316769 A1) in view of Liu (US PG Pub No. 2022/0337545 A1).
Regarding claim 14, Akers does not teach wherein generating in advance the information mapping relationship among the second service information which the target service has in each client VPC, the first service information which the target service has in each service VPC, and the information of the service instance in each service VPC which can provide the target service, comprises: deploying, in a system VPC where the multi-cluster load balancing node is located, a third virtual network interface card device bound to the target service, wherein the third virtual network interface card has a third private network IP address, and third service information which the target service has in the system VPC comprises the third private network IP address and a port number of the target service; and establishing, through the third service information which the target service has in the system VPC, an information mapping relationship among the second service information which the target service has in each client VPC, the first service information which the target service has in each service VPC, and the information of the service instance in each service VPC which can provide the target service.
Liu teaches a first VPC 330 and a second VPC 340 with overlapping private address segments that communicate through a third VPC 350 whose private address segment differs from both (Figs 3A-3B; [0086]). Liu further teaches control platform 316 allocates private network address to gateway 1 and gateway 2 and each gateway holds an address belonging to the third VPC for external communications ([0090]; [0108]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to places Aker’s load balancing node in a separate system VPC, to assign that node a virtual network interface with a third private IP address per target service. One would be motivated by the desire to allow VPCs with overlapping private addresses to communicate by routing through an intermediate VPC with distinct address segments as taught by Liu ([0004]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC C WAI whose telephone number is (571)270-1012. The examiner can normally be reached Monday - Friday 9-5.
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, Aimee Li can be reached at (571) 272-4169. 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.
/Eric C Wai/Primary Examiner, Art Unit 2195
