Detailed Action
This action is in response to the application filed on 11/25/2024. Claims 1-10 are
pending and have been fully examined.
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 .
Status of the Claims
Claims 1-10 are rejected under 35 U.S.C. 103
Claims 5-7 are rejected under 35 U.S.C 112b
Claims 1-2 are objected
Status of the Claims
Claim 1 is objected to because of the following informalities: “wherein the load sharing and backup include inter-cluster load sharing and backup, and load sharing and backup in the cluster according to health states of the server nodes in the cluster and the cluster.” should read “wherein the load sharing and backup include inter-cluster load sharing and backup, and load sharing and backup in the cluster according to health states of the server nodes in the health cluster and the unhealthy cluster.
Claim 2 is objected to because of the following informalities: “wherein the preset minimum survival number threshold equals the total number of server nodes in the cluster multiplied by the minimum survival ratio, or is set according to a service requirement.” should read “wherein the preset minimum survival number threshold equals the total number of server nodes in the cluster multiplied by the minimum survival ratio, or is set according to a service requirement.”
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 5 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 5 recites the limitation “the cluster load backup mode.” There is insufficient antecedent basis for this limitation in the claim. Claim 1 recites load sharing and backup on cluster groups according to a weight and a priority. Claim 1 does not recite “the cluster load backup mode.”
Further claim 5 has grammatical errors and words are missing, appropriate correction is required.
Claims 6-7 are further rejected for dependency on claim 5.
Examiners Note: For purposes of examination the cluster load backup mode will be interpreted as backup on traffic of the unhealthy cluster.
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-3 and 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Bhalerao et al. (U.S. Patent No. 9,148,479 B1), hereinafter referred to as Bhalerao, in view of Karuppannan et al. (U.S. Publication No. 2023/0224361 A1), hereinafter referred to as Karuppannan.
Regarding Claim 1, Bhalerao teaches:
A cluster-based load sharing and backup method, comprising: (Col. 6, lines 51-65; regarding, “Computer cluster 208 generally represents a group of two or more nodes (such as nodes 202(1)-(N)) capable of communicating with one another to collectively perform one or more tasks, such as collectively providing high availability of at least one application and/or collectively executing at least one application… Examples of computer cluster 208 include, without limitation, high-availability clusters, load-balancing clusters, Beowolf clusters, high-performance computing clusters, or any other suitable computer clusters.”);
periodically monitoring a cluster, and determining a health cluster group and an unhealthy cluster group according to a health condition of the cluster; (Col. 9, lines 63-67; regarding, “cluster engine 106 may prompt the operating system kernel drivers to asynchronously monitor the healthiness of cluster agents 210(1)-(N) in order to determine whether nodes 202(1)-(N) are healthy enough to execute the application.”; Fig. 5, Col. 11, lines 62-65, Col. 12, lines 1-8; regarding, “cluster information 122 may include various information used to coordinate and/or operate computer cluster 208, such as… each healthy backup agent… and each unhealthy backup agent...”);
performing load sharing and backup on a traffic of the unhealthy cluster group to the health cluster group (Col. 11, lines 50-54; regarding, “if node 202(1) was executing the application at the point in time that cluster agent 210(1) stalled or started malfunctioning, cluster engine 106 may direct the application to fail over from node 202(1) to node 202(N).”);
wherein the load sharing and backup include inter-cluster load sharing and backup, and load sharing and backup in the cluster according to health states of the server nodes in the cluster and the cluster. (Col. 10, lines 8-15; regarding, “operating system kernel drivers may determine whether cluster agents 210(1)-(N) appear healthy or unhealthy based at least in part on an operating status associated with each of cluster agents 210(1)-(N). This operating status may indicate whether cluster agents 210(1)-(N) are currently running or currently stalled or malfunctioning.”; Col. 11, lines 46-57; regarding, “in response to receiving the notification indicating that node 202(1) is not healthy enough to execute the application, cluster engine 106 may prevent the node 202(1) from continuing to execute the application. For example, if node 202(1) was executing the application at the point in time that cluster agent 210(1) stalled or started malfunctioning, cluster engine 106 may direct the application to fail over from node 202(1) to node 202(N). In other words, cluster engine 106 may direct node 202(1) to stop executing the application and then select node 202(N) to start executing the application.”).
Bhalerao fails to explicitly disclose but Karuppannan teaches:
performing load sharing and backup on a traffic of the unhealthy cluster group to the health cluster group according to a weight and a priority of the cluster; ([0017]; regarding, “determination that the first pool in the first cluster is associated with an unhealthy status, the first load balancer may identify a second pool implementing the service in the second cluster”; [0058]; regarding, “pools are assigned with different priority levels. In this case, block 415 may involve assigning local pool 531/541 is assigned with a first priority level (e.g., 10) that is higher than a second priority level (e.g., 8) assigned to remote pool 532/542. This way, local pool 531/541 is configured to take precedence or priority to handle traffic when its status=HEALTHY. However, when there is a failure that causes a state transition from HEALTHY to UNHEALTHY, traffic may be steered (i.e., proxied) from local pool 531/541 in first cluster 101 towards remote pool 532/542 in second cluster 102.”);
and receiving and parsing a client request to obtain an execution task, and determining a target cluster and a target server node from the health cluster group; ([0028]; regarding, “VMs 231-235 may interact with any suitable computer system 270 supporting a load balancer (e.g., LLB1 120 or LLB2 130 in FIG. 1)”; [0070]; regarding, “In one example, LLB1 120 may forward the request from client device 140 to LLB2 130, which then parses the request and forwards it to POOL2 of backend server(s) 134… LLB1 120 has awareness of the health status of the payment service implemented by POOL2, and a path associated with POOL2 in second cluster 102.”);
and sending the execution task to the target server node in the target cluster for execution, and returning an execution result; ([0068]; regarding, “LLB1 120 in first cluster 101 may receive a request from client device... The request may be a HTTP(S) request to access URL2=“https://eu.ecommerce.com/payment” specifying path=“payment.” In response, LLB1 120 may identify local POOL1 of first backend server(s) 124 implementing the service and determine its health status. If POOL1 is associated with status=HEALTHY, LLB1 120 may steer the request towards local POOL1 for processing”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine Bhalerao with the teachings of Karuppannan. Doing so could reduce service downtime, improve application performance and enhance user experience (Karuppannan, [0017]).
Regarding Claim 2, Bhalerao in view of Karuppannan teach the method of claim 1 as referenced above. Bhalerao in view of Karuppannan further teaches:
wherein periodically monitoring the cluster, and determining the health cluster group and the unhealthy cluster group according to the health condition of the cluster comprises:
initializing the weights and priorities of the server nodes in the cluster and the cluster, and dividing the clusters into two groups according to a number of survival numbers of the server nodes in the cluster and a preset minimum survival number threshold, which are respectively a health cluster group and an unhealthy cluster group; (Fig. 1, [0017]; regarding, “determination that the first pool in the first cluster is associated with an unhealthy status, the first load balancer may identify a second pool implementing the service in the second cluster (e.g., payment service 132 in FIG. 1). The second pool may be associated with a healthy status”; [0058]; regarding, “pools are assigned with different priority levels. In this case, block 415 may involve assigning local pool 531/541 is assigned with a first priority level (e.g., 10) that is higher than a second priority level (e.g., 8) assigned to remote pool 532/542. This way, local pool 531/541 is configured to take precedence or priority to handle traffic when its status=HEALTHY. However, when there is a failure that causes a state transition from HEALTHY to UNHEALTHY, traffic may be steered (i.e., proxied) from local pool 531/541 in first cluster 101 towards remote pool 532/542 in second cluster 102.”);
wherein the preset minimum survival number threshold is set according to a total number of server nodes in the cluster and a minimum survival ratio, wherein the preset minimum survival number threshold equals the total number of server nodes in the cluster multiplied by the minimum survival ratio, or is set according to a service requirement. ([0038]; regarding, “there is a requirement where the minimum number of services up and running equals to the number of services… in each cluster 101/102. In this case, since only one service is HEALTHY in each cluster 101/102, the application may be considered to be down in both clusters 101-102. This causes GLB 110 to avoid steering traffic to both LLB1 120 and LLB2 130, rendering the application to be inaccessible.”).
Regarding Claim 3, Bhalerao in view of Karuppannan teach the method of claim 2 as referenced above. Bhalerao in view of Karuppannan further teaches:
wherein the dividing the cluster into two groups according to the number of survival of the server nodes in the cluster and the preset minimum survival number threshold comprises:
1) periodically counting a number of server nodes in the cluster, and comparing with the preset minimum survival number threshold to mark the health status of the cluster; (Fig. 1, [0062]; regarding, “GSLB service health monitoring may be performed to monitor the health of services and associated backend server(s) in each cluster 101/102. In practice, health monitoring may be performed using health monitor(s) configured on the control plane and/or data plane. In this case, LLB 120/130 may obtain information specifying the health status of services in each cluster 101/102 from the health monitor(s)”; [0063]; regarding, “Using control-plane-based health monitoring, LLB 120/130 (or a controller) may perform periodic health checks to determine the health status of local services in their local cluster 101/102. LLB1 120 and LLB2 130 may also query each other to determine the health status of remote services in respective clusters 101-102.”; ([0038]; regarding, “there is a requirement where the minimum number of services up and running equals to the number of services… in each cluster 101/102.”);
and if the number of the server nodes is greater than or equal to the preset minimum survival number threshold, marking the cluster as a health cluster, and dividing the health cluster into the health cluster group; (Fig. 3, [0043]; regarding, “LLB1 120 may identify a first pool…in first cluster 101... At 330 (no) and 340, in response to determination that the first pool in first cluster 101 is associated with status=HEALTHY, LLB1 120 may allow client device 140 to access the service implemented by the first pool in first cluster 101.”);
and if the number of the server nodes is less than the preset minimum survival number threshold, marking the cluster as an unhealthy cluster, dividing the unhealthy cluster into the unhealthy cluster group, and performing load sharing and backup on the unhealthy cluster. ([0044]; regarding, “Otherwise, at 330 (yes) and 350… in response to determination that the first pool in first cluster 101 is associated with status=UNHEALTHY, LLB1 120 may identify a second pool implementing the service in second cluster 102. The second pool is associated with a healthy status and includes second backend server(s) 134 selectable by a LLB2 130 to process the request.”).
Regarding Claim 8, Bhalerao in view of Karuppannan teach the method of claim 1 as referenced above. Bhalerao in view of Karuppannan further teaches:
wherein the receiving and parsing the client request to obtain the execution task, and determining the target cluster and the target server node from the health cluster group comprises:
accepting the client request, and parsing the client request to obtain the execution plan; ([0070]; regarding, “In one example, LLB1 120 may forward the request from client device 140 to LLB2 130, which then parses the request…”);
and determining a target cluster from the health cluster group according to the weight and priority of the health cluster; ([0028]; regarding, “VMs 231-235 may interact with any suitable computer system 270 supporting a load balancer (e.g., LLB1 120 or LLB2 130 in FIG. 1)”; [0070]; regarding, “In one example, LLB1 120 may forward the request from client device 140 to LLB2 130, which then parses the request and forwards it to POOL2 of backend server(s) 134… LLB1 120 has awareness of the health status of the payment service implemented by POOL2, and a path associated with POOL2 in second cluster 102.”);
and determining the target server node from the target cluster according to the weights and priorities of the server nodes. ([0017]; regarding, “determination that the first pool in the first cluster is associated with an unhealthy status, the first load balancer may identify a second pool implementing the service in the second cluster”; [0058]; regarding, “pools are assigned with different priority levels. In this case, block 415 may involve assigning local pool 531/541 is assigned with a first priority level (e.g., 10) that is higher than a second priority level (e.g., 8) assigned to remote pool 532/542. This way, local pool 531/541 is configured to take precedence or priority to handle traffic when its status=HEALTHY. However, when there is a failure that causes a state transition from HEALTHY to UNHEALTHY, traffic may be steered (i.e., proxied) from local pool 531/541 in first cluster 101 towards remote pool 532/542 in second cluster 102.”);
Regarding Claim 9, Bhalerao in view of Karuppannan teach the method of claim 1 as referenced above. Bhalerao in view of Karuppannan further teaches:
wherein the sending the execution task to the target server node in the target cluster for execution, and returning an execution result comprises:
sending the execution task to the target cluster, and allocating, by a master server node in the target cluster, the execution task to the target server node in a balanced manner; (Karuppannan, [0028]; regarding, “VMs 231-235 may interact with any suitable computer system 270 supporting a load balancer (e.g., LLB1 120 or LLB2 130 in FIG. 1)”; [0070]; regarding, “In one example, LLB1 120 may forward the request from client device 140 to LLB2 130, which then parses the request and forwards it to POOL2 of backend server(s) 134… LLB1 120 has awareness of the health status of the payment service implemented by POOL2, and a path associated with POOL2 in second cluster 102.”; [0071]; regarding, “LLB2 130 may allow client device 140 operated by end user 141 to access service=payment by selecting particular backend server 134 in POOL2 to process the request. At 670, 680 and 690 in FIG. 6, a response from that particular backend server 134 is then forwarded towards LLB1 120”);
and processing, by the target server node, a result to a master server node in the target cluster after the execution task is completed; ([0068]; regarding, “LLB1 120 in first cluster 101 may receive a request from client device... The request may be a HTTP(S) request to access URL2=“https://eu.ecommerce.com/payment” specifying path=“payment.” In response, LLB1 120 may identify local POOL1 of first backend server(s) 124 implementing the service and determine its health status. If POOL1 is associated with status=HEALTHY, LLB1 120 may steer the request towards local POOL1 for processing”);
and obtaining, by the master server node in the target cluster, an execution result according to the processing result, and returning the execution result to the client. ([0071]; regarding, “LLB2 130 may allow client device 140 operated by end user 141 to access service=payment by selecting particular backend server 134 in POOL2 to process the request. At 670, 680 and 690 in FIG. 6, a response from that particular backend server 134 is then forwarded towards LLB1 120, which in turn forwards it towards client device 140.”).
Regarding Claim 10, Bhalerao in view of Karuppannan teach the method of claim 1 as referenced above. Bhalerao in view of Karuppannan further teaches:
An apparatus for implementing the cluster-based load sharing and backup method according to claim 1, wherein the apparatus comprises a health detection module, a sharing backup module, an execution determination module, and a return module; (Karuppannan, [0052]; regarding, “GSLB service configuration may be performed for a global application that is deployed in multiple clusters 101-102… the GSLB service may provide a number of functions, such as (1) defining, synchronizing, and maintaining GSLB configuration; (2) monitoring the health of configuration components; (3) optimizing application service for clients by providing GSLB DNS responses to FQDN requests; (4) processing global application requests; or any combination thereof.”; [0099]; regarding, “The units in the examples described can be combined into one module or further divided into a plurality of sub-units.”);
wherein the health detection module is configured to periodically monitor a cluster, and determine a health cluster group and an unhealthy cluster group according to the health condition of the cluster; (Bhalerao, Col. 9, lines 63-67; regarding, “cluster engine 106 may prompt the operating system kernel drivers to asynchronously monitor the healthiness of cluster agents 210(1)-(N) in order to determine whether nodes 202(1)-(N) are healthy enough to execute the application.”; Fig. 5, Col. 11, lines 62-65, Col. 12, lines 1-8; regarding, “cluster information 122 may include various information used to coordinate and/or operate computer cluster 208, such as… each healthy backup agent… and each unhealthy backup agent...”);
and the sharing backup module is configured to perform load sharing and backup on the traffic of the unhealthy cluster group to the health cluster group according to the weight and priority of the cluster; (Karuppannan, [0017]; regarding, “determination that the first pool in the first cluster is associated with an unhealthy status, the first load balancer may identify a second pool implementing the service in the second cluster”; [0058]; regarding, “pools are assigned with different priority levels. In this case, block 415 may involve assigning local pool 531/541 is assigned with a first priority level (e.g., 10) that is higher than a second priority level (e.g., 8) assigned to remote pool 532/542. This way, local pool 531/541 is configured to take precedence or priority to handle traffic when its status=HEALTHY. However, when there is a failure that causes a state transition from HEALTHY to UNHEALTHY, traffic may be steered (i.e., proxied) from local pool 531/541 in first cluster 101 towards remote pool 532/542 in second cluster 102.”);
Claims 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Bhalerao et al. (U.S. Patent No. 9,148,479 B1), hereinafter referred to as Bhalerao, in view of Karuppannan et al. (U.S. Publication No. 2023/0224361 A1), hereinafter referred to as Karuppannan, in further view of Spear et al (U.S. Publication No. 2013/0007505 A1), hereinafter referred to as Spear.
Regarding Claim 5, Bhalerao in view of Karuppannan teach the method of claim 1 as referenced above. Bhalerao in view of Karuppannan fail to explicitly disclose but Spear teaches:
wherein the step of sharing and backing up the inter-cluster load comprises:
selecting a load sharing target cluster from the health cluster group according to the cluster load backup mode between the clusters, and performing load sharing and backup on the traffic of the unhealthy cluster to the load sharing target cluster; ([0011]; regarding, “extensions to this load balancer failover technique can provide for a cluster-based approach in which two (or more) clusters can be configured as a primary cluster and a secondary cluster, and on a failure to the primary cluster, the secondary cluster can be activated.”);
and wherein, the cluster load backup mode between the clusters includes three types: a multi-master mode, a multi-standby mode, a master mode and a multi-master mode, respectively; ([0035]; regarding, “the multiple servers behind the load balancer can be identified and in addition, given services to have traffic sent to, such as web, email, database or so forth. Based on this identification of various servers to be primary and secondary, a failover rule may be generated (block 230)… the failover rule can include multiple entries, each of which identifies the given service, and the servers that are able to handle the service… for each service an entry may be provided that includes an identification field for the service, a primary field to identify a primary server configured to handle the service, and a secondary field to identify a secondary server capable of handling the service… although three such fields are identified, understand the scope of the present invention is not limited in this regard and in some implementations, multiple primary servers and multiple secondary servers can be present and can be identified in the fields discussed. In addition, other fields may also be present in a given embodiment. In addition to the failover rule, a service rule may be generated (block 240). This rule can be populated with entries that identify each service and the corresponding server on which it is currently executing.”);
wherein, when the cluster load backup mode between the clusters is multi-master: multi-standby mode, the health cluster group is composed of a plurality of main clusters and a plurality of standby clusters, after the main cluster is marked as an unhealthy cluster, the standby cluster is selected as a load sharing target cluster, all execution tasks carried by the main cluster are migrated to the standby cluster, and the standby cluster carries and responds to a client request borne by the main cluster; ([0011]; regarding, “extensions to this load balancer failover technique can provide for a cluster-based approach in which two (or more) clusters can be configured”; [0035]; regarding, “multiple primary servers and multiple secondary servers can be present”; [0028]; regarding, “when the service fails on the primary server, load balancer 130 may begin sending requests for the failing service to the secondary server.”)
wherein the cluster load backup mode between the clusters is the main mode, the health cluster group is composed of at least two master clusters, and after the master cluster is marked as an unhealthy cluster, all execution tasks carried by the master cluster are balanced and migrated to other master clusters, and the master clusters balance bearers and respond to client requests borne by the master cluster; (Fig. 1, [0011]; regarding, “extensions to this load balancer failover technique can provide for a cluster-based approach in which two (or more) clusters can be configured”; [0035]; regarding, “multiple primary servers and multiple secondary servers can be present”; [0024]; regarding, “…when a particular service executing on one of servers 150 fails…load balancer itself can automatically disable the sending of traffic to a failed server 150 for a given service, in order to provide for a seamless switching over of the failing service from one server to another.”);
wherein the cluster load backup mode between the clusters is multi-master: one standby mode, wherein the health cluster group is composed of a plurality of main clusters and a standby cluster, after the main cluster is marked as an unhealthy cluster, the standby cluster is selected as a load sharing target cluster, all execution tasks carried by the main cluster are migrated to the standby cluster, and the standby cluster carries and responds to a client request borne by the main cluster. ([0011]; regarding, “extensions to this load balancer failover technique can provide for a cluster-based approach in which two (or more) clusters can be configured”; [0035]; regarding, “multiple primary servers and multiple secondary servers can be present”; [0028]; regarding, “when the service fails on the primary server, load balancer 130 may begin sending requests for the failing service to the secondary server.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine Bhalerao and Karuppannan with the teachings of Spear. Doing so could increase availability and reduce downtime (Spear, [0024]).
Regarding Claim 6, Bhalerao in view of Karuppannan in further view of Spear teach the method of claim 5 as referenced above. Bhalerao in view of Karuppannan in further view of Spear teaches:
wherein the step of inter-cluster load sharing and backup further comprises:
after the cluster is restored to the health cluster by the unhealthy cluster, the cluster is marked as a health cluster, and all execution tasks of the load sharing target cluster bearer and sharing and the client request are migrated back to the cluster. (Spear, [0031]; regarding, “Upon the primary server's return after repair, the load balancer can change both primary instances to replicate from the first port of the passive server. After replication such that the primary server has a data configuration that is coherent with the secondary server, both instances on the primary server can be stopped, and the first server is again configured to be the primary. Thus on the primary server, its first port is configured again as the master and its second port configured as a slave.”).
Regarding Claim 7, Bhalerao in view of Karuppannan in further view of Spear teach the method of claim 5 as referenced above. Bhalerao in view of Karuppannan in further view of Spear teaches:
wherein the step of load sharing and backup in the cluster is as follows:
determining a load sharing target server node according to the weights of the server nodes survival in the load sharing target cluster and the priorities; (Karuppannan, [0017]; regarding, “determination that the first pool in the first cluster is associated with an unhealthy status, the first load balancer may identify a second pool implementing the service in the second cluster”; [0058]; regarding, “pools are assigned with different priority levels. In this case, block 415 may involve assigning local pool 531/541 is assigned with a first priority level (e.g., 10) that is higher than a second priority level (e.g., 8) assigned to remote pool 532/542. This way, local pool 531/541 is configured to take precedence or priority to handle traffic when its status=HEALTHY. However, when there is a failure that causes a state transition from HEALTHY to UNHEALTHY, traffic may be steered (i.e., proxied) from local pool 531/541 in first cluster 101 towards remote pool 532/542 in second cluster 102.”);
and allocating the execution task and the client request balance of the load sharing target cluster bearer and the sharing to the load sharing target server node. (Karuppannan, [0068]; regarding, “LLB1 120 in first cluster 101 may receive a request from client device... The request may be a HTTP(S) request to access URL2=“https://eu.ecommerce.com/payment” specifying path=“payment.” In response, LLB1 120 may identify local POOL1 of first backend server(s) 124 implementing the service and determine its health status. If POOL1 is associated with status=HEALTHY, LLB1 120 may steer the request towards local POOL1 for processing”).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Bhalerao et al. (U.S. Patent No. 9,148,479 B1), hereinafter referred to as Bhalerao, in view of Karuppannan et al. (U.S. Publication No. 2023/0224361 A1), hereinafter referred to as Karuppannan, in further view of Yevmenkin et al (U.S. Publication No. 2020/0366730 A1), hereinafter referred to as Yevmenkin.
Regarding Claim 4, Bhalerao in view of Karuppannan teach the method of claim 3 as referenced above. Bhalerao in view of Karuppannan further teaches:
wherein the step of periodically counting the survival quantity of the server nodes in the cluster and comparing the survival quantity with the preset minimum survival number threshold, marking the health status of the cluster further includes counting the survival server nodes in the cluster by:
1) periodically sending a survival state monitoring broadcast notification to all server nodes in each cluster, and returning node monitoring information; (Col. 12, lines 33-35; regarding, “cluster engine 106 may identify a polling mechanism (such as a heartbeat mechanism) installed on at least one of nodes 202(1)-(N)… the polling mechanism may be configured to poll the operating system kernel for evidence of any type or form of system failure”);
and 2) determining and marking a survival state of the server node according to the node monitoring information; (Col. 12, lines 53-58; regarding, “After cluster engine 106 has configured the polling mechanism to check for the unhealthy condition, the polling mechanism may check for the unhealthy condition and determine, based at least in part on the check, whether the node is experiencing the unhealthy condition.”);
and 3) counting the number of server nodes in each cluster; ([0038]; regarding, “there is a requirement where the minimum number of services up and running equals to the number of services (e.g., min_hm_up=2) in each cluster 101/102.”);
wherein, the node monitoring information includes…and a survival state; (Col. 12, lines 53-58; regarding, “After cluster engine 106 has configured the polling mechanism to check for the unhealthy condition, the polling mechanism may check for the unhealthy condition and determine, based at least in part on the check, whether the node is experiencing the unhealthy condition.”);
wherein the survival state includes two fields, which are survival and non-storage, and are determined according to whether the server node works normally, and if the server node works normally, the survival state of the server node is marked as storage, and if the server node does not work normally, the survival state of the server node is marked as non-survival. (Col. 10, lines 8-14; regarding, “operating system kernel drivers may determine whether cluster agents 210(1)-(N) appear healthy or unhealthy based at least in part on an operating status associated with each of cluster agents 210(1)-(N). This operating status may indicate whether cluster agents 210(1)-(N) are currently running or currently stalled or malfunctioning.”).
Bhalerao in view of Karuppannan fail to explicitly disclose but Yevmenkin teaches:
wherein, the node monitoring information includes three fields, the three fields being a server number, a port number, and a survival state; (Table-US-00003, [0048-0055]).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine Bhalerao and Karuppannan with the teachings of Yevmenkin. Doing so could allow the system to duplicate incoming (client-to-cluster) traffic to all servers in the cluster and let each server decide if it is to deal with particular part of the incoming traffic, thereby reducing the cost (Yevmenkin, [0076]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATHEW GUSTAFSON whose telephone number is (571)272-5273. The examiner can normally be reached Monday-Friday 8:00-4:00.
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, Bryce Bonzo can be reached at (571) 272-3655. 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.
/M.D.G./Examiner, Art Unit 2113
/BRYCE P BONZO/Supervisory Patent Examiner, Art Unit 2113