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 .
Notice for all Patent Application as subject to AIA
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 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.
RESPONSE TO AMENDMENT
Amended claims 44-63 are pending and remain for further examination.
The old rejection maintained
Applicant’s amendments and arguments with respect to claims 44-63 filed on July 02, 2025 have been fully considered but they are not deemed to be persuasive for the claims 44-63. The rejection is respectfully maintained as set forth in the last Office Action mailed on April 09, 2025.
Claim Rejections - 35 USC § 103
The text of those sections of title AIA 35 U.S.C. 103 code not included in this action can be found in a prior Office Action.
Claims 44-46, 48, 50-53, and 55-57 are rejected under AIA 35 U.S.C. 103 as being un-patentable over Alexander et al (U.S. Patent No. 6,189,111 B1) in view of Matthews et al (U.S. Patent No. 10,601,779 B1).
As to claim 44, Alexander et al teach a method of providing N+1 redundancy for a cluster of network nodes (figure 1, column 3 lines 37-43, column 9 lines 27-32, reference teaches that N+1 redundancy is used for a cluster includes N+1 nodes), the method comprising: determining, by a standby node, that a primary node in a cluster has failed (figure 1, column 5 lines 35-53, column 6 lines 5-12, reference teaches that diagnostic system or node itself or another/redundant/preselected node detects the failure of an active node); retrieving, by a standby node, session data for user sessions associated with the failed primary node; restoring user sessions of the failed primary node at the standby node; and switching from a standby mode to an active mode (figure 1, column 6 lines 19-37, figure 2, column 7 lines 26-38, column 8 lines 15-24, reference teaches that recipient/non-failed node retrieves memory object (session information) associated with the failed node and recovers the memory object at the recipient node and the recipient node initiates operation to perform the memory object of the failed node).
However, Alexander et al do not teach that configuring the standby node to use an Internet Protocol (IP) address of the failed primary node; and retrieving, from a low latency database for the cluster, session data for user sessions associated with the failed primary node.
Matthews et al teach that determining that a primary node in a cluster has failed (figure 1, column 5 lines 32-39, figure 6, column 10 lines 8-16, identify fail node); a standby node to use an Internet Protocol (IP) address of the failed primary node (figure 1, column 5 line 62 to column 6 line 6, figure 8, column 11 lines 30-38, move an IP address assigned to the failed node to a second/alternative node); receiving, from low latency database for the cluster, session data for user sessions associated with the failed primary node by a standby node, data from a storage shared between the primary node and the standby node (column 5 line 18-49, figure 3C, column 8 lines 28-41, figure 8, column 11 lines 39-49, second/alternative node retrieves session data for user sessions associated with the failed node from session database); and restoring the user session at the standby node (figures 3B-3C, column 8 lines 17-27 & 42-45, restoring the user session at the second/alternative node).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Matthews et al as stated above with the method of Alexander et al for restoring the user sessions at the standby node by using an IP address in response to detect the failure of the primary node because it would have improved the system utilization and the system efficiency, and also reduced processing delay by recovering the session information from the failover primary node and restoring the user session at the standby node.
However, Alexander et al also do not teach that releasing, after a last one of the user sessions ends at the standby node or upon expiration of a standby timer, the IP address of the failed primary node and switching from the active mode to the standby mode.
Matthews et al teach that releasing the IP address of the failed primary node and switching from the active mode to the standby mode after a last one of the user sessions ends at the standby node (figure 2, column 7 lines 1-8, figure 6, column 10 lines 31-47, figure 7, column 11 lines 3-23, figure 8, column 11 lines 24-49, reference teaches that VPN appliance/node reassigns an IP address associated with the VPN appliance/node to another node (releasing the IP address) and shuts down / removes the VPN appliance/node as a candidate for new session (switching active mode to standby mode) after the VPN appliance/node being taken out of service to close (VPN appliance/node can be rapidly added or removed from the VPN services, and receiving and releasing the IP address of the failed appliance/node)).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Matthews et al stated above with the method of Alexander et al for switching from an active mode to a standby mode because it would have improved the system utilization by making the node available for future failure of the node.
As to claim 45, Alexander et al teach that determining that a primary node in a cluster has failed comprises: sending a periodic keepalive message to one or more primary nodes in the cluster, and determining a node failure when the failed primary node fails to respond to a keepalive message (column 5 lines 35-53, column 6 lines 19-32, determining a node in a cluster is failed by periodically receiving “I’m Alive” message from the node).
As to claim 46, Matthews et al teach that configuring the standby node to use an IP address of the failed primary node comprises configuring a network interface to use the IP address of the failed primary node (figures 1-2, column 5 line 57 to column 6 line 13, column 7 lines 9-20, VPN service configuring an interface to use the IP address).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Matthews et al as stated above with the method of Alexander et al for configuring a network interface to use the IP address of the failed primary node because it would have improved the system utilization and the system efficiency by configuring an interface to use the failed node IP address.
As to claim 48, Matthews et al teach that setting a standby identity key in the database to an identity of the failed primary node (figure 2, column 7 lines 9-20, identifying status of node in the session database).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Matthews et al as stated above with the method of Alexander et al for identifying status of node in the session database because it would have improved the system utilization and the system efficiency by identifying status of the failed node.
As to claims 51-53 and 55-57, they are also rejected for the same reasons set forth to rejecting claims 44-46 and 48-50 above, since claims 51-53 and 55-57 are merely an apparatus for the method of operations defined in the claims 44-46 and 48-50, and claims 51-53 and 55-57 do not teach or define any new limitations than above rejected claims 44-46 and 48-50.
Claims 47 and 54 are rejected under AIA 35 U.S.C. 103 as being un-patentable over Alexander et al (U.S. Patent No. 6,189,111 B1) in view of Matthews et al (U.S. Patent No. 10,601,779 B1), as applied to claim 44 and 51 above, and further in view of Miklos (U.S. Patent Application Publication No. 2014/0059192 A1).
As to claim 47, neither Alexander et al nor Matthews et al explicitly teaches that announcing a binding between the IP address and a Medium Access Control (MAC) address of the standby node.
Miklos teaches that configuring the standby node to use an IP address of the failed primary node comprises announcing a binding between the IP address and a Medium Access Control (MAC) address of the standby node (pars. 0021-0022 & 0026-0027, figure 5, figure 5, pars. 0116 & 0118-0119, new LGW using an IP address of the terminal used by an old LGW and binding the IP address to the MAC address of the new LGW).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Miklos stated above with the method of Alexander et al for binding between the IP address and a Medium Access Control (MAC) address because it would have improved the system utilization and the system efficiency by using MAC address of the host standby node.
As to claim 54, it is also rejected for the same reasons set forth to rejecting claim 47 above, since claim 54 is merely an apparatus for the method of operations defined in the claim 47, and claim 54 does not teach or define any new limitations than above rejected claim 47.
Claims 58-63 are rejected under AIA 35 U.S.C. 103 as being un-patentable over Ghosh et al (U.S. Patent Application Publication No. 2011/0071981 A1) in view of Doverspike et al (U.S. Patent Application Publication No. 2004/0107382 A1).
As to claim 58, Ghosh et al teach a method of failure recovery by a primary node in a cluster (see figures 3-4, pars. 0137-0138, reference teaches about failure recovery of a node in a cluster), the method comprising: following a restart by the primary node, determining that the primary node (recovery node) is configure as a new active node or a new standby node in the cluster (figure 4, pars. 0144-0145, figure 6, pars. 0160-0162, reference teaches that after restarting the failed node using as an active node or a standby node).
However, Ghosh et al do not teach that after restarting the primary node , determining that an IP address of the primary node being used by a standby node , obtaining a new IP address or waiting for the IP address of the primary node to be released by the standby node.
Doverspike et al teach that configuring a standby node to use an Internet Protocol (IP) address of the failed primary node (figure 4, pars. 0031-0032, reference teaches that a new interface node configures to uses an IP address of the failed interface node); the primary node restarting and determining whether an IP address of the primary node is being used by a standby node in the cluster, and obtaining IP address from the standby node (figure 4, pars. 0033-0034, reference teaches that failure of an original interface node has been repaired and the original interface node obtaining IP address from the new interface node); the primary node restarting and determining whether an IP address of the primary node is being used by a standby node in the cluster, and waiting for the IP address to be released by the standby node (figure 6, pars. 0041-0042, reference teaches that failure of an original interface node has been repaired and the original interface node define as a spare interface node (standby or waiting)); and also teaches that the primary node restarting and obtaining a new IP address (figure 7, par. 0047, reference teaches that activating an interface node and obtaining a new IP address for the activated interface node), which are functionally equivalent to the claimed limitations.
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Doverspike et al as stated above with the method of Ghosh et al Alexander et al for waiting for the IP address to be released by the standby node or obtaining a new IP address because it would have improved the system utilization and the system efficiency, and also reduced processing delay by obtaining a new IP address.
As to claim 59, Ghosh et al teach that getting a standby identity from a database serving the cluster of network nodes; and comparing the standby identity to an identity of the primary node (figure 4, pars. 0142-0145, reference teaches that after restarting the failed node, access recovery information from shared storage to reconstruct, and using as a new standby/spare node).
As to claim 60, Doverspike et al teach that reconfiguring a network interface of the primary node with the new IP address and returning to an active mode (figure 4, pars. 0033-0034, reference teaches that failure of an original interface node has been repaired and the original interface node obtaining IP address from the new interface node and returning to an active node; and figure 7, par. 0047, reference teaches that activating an interface node and obtaining a new IP address for the activated interface node).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Doverspike et al as stated above with the method of Ghosh et al Alexander et al for waiting for the IP address to be released by the standby node or obtaining a new IP address because it would have improved the system utilization and the system efficiency, and also reduced processing delay by obtaining a new IP address.
As to claims 61-63, they are also rejected for the same reasons set forth to rejecting claims 58-60 above, since claims 61-63 are merely an apparatus for the method of operations defined in the claims 58-60, and claims 61-63 do not teach or define any new limitations than above rejected claims 58-60.
Response to Arguments
Applicant’s amendments and arguments with respect to claims 44-63 filed on July 02, 2025 have been fully considered but they are not deemed to be persuasive for the claims 44-63.
In the remarks, the applicant argues that:
Argument: Neither Alexander nor Matthews disclose “releasing, after a last one of the user sessions ends at the standby node or upon expiration of a standby timer, the IP address of the failed primary node and switching from the active mode to the standby mode,” as required in claim 44 and 51.
Response: Matthews et al teach that releasing the IP address of the failed primary node and switching from the active mode to the standby mode after a last one of the user sessions ends at the standby node (figure 2, column 7 lines 1-8, figure 6, column 10 lines 31-47, figure 7, column 11 lines 3-23, figure 8, column 11 lines 24-49, reference teaches that VPN appliance/node reassigns an IP address associated with the VPN appliance/node to another node (releasing the IP address) and shuts down / removes the VPN appliance/node as a candidate for new session (switching active mode to standby mode) after the VPN appliance/node being taken out of service to close (VPN appliance/node can be rapidly added or removed from the VPN services, and receiving and releasing the IP address of the failed appliance/node)), which implies the claimed invention; therefore, the applicant’s arguments are moot and the combination of Alexander and Matthews teaches the claimed invention.
Argument: Neither Ghosh nor Doverspike disclose “upon determining that the IP address is being used by a standby node, obtaining a new IP address or waiting for the IP address to be released by the standby node,” as recited in the clams.
Response: Doverspike et al teach that configuring a standby node to use an Internet Protocol (IP) address of the failed primary node (figure 4, pars. 0031-0032, reference teaches that a new interface node configures to uses an IP address of the failed interface node); the primary node restarting and determining whether an IP address of the primary node is being used by a standby node in the cluster, and obtaining IP address from the standby node (figure 4, pars. 0033-0034, reference teaches that failure of an original interface node has been repaired and the original interface node obtaining IP address from the new interface node); the primary node restarting and determining whether an IP address of the primary node is being used by a standby node in the cluster, and waiting for the IP address to be released by the standby node (figure 6, pars. 0041-0042, reference teaches that failure of an original interface node has been repaired and the original interface node define as a spare interface node (standby or waiting)); and also teaches that the primary node restarting and obtaining a new IP address (figure 7, par. 0047, reference teaches that activating an interface node and obtaining a new IP address for the activated interface node), which implies the claimed invention; therefore, the applicant’s arguments are moot and the combination of Ghosh and Doverspike teaches the claimed invention.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Content Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Bharat Barot whose telephone number is (571)272-3979. The examiner can normally be reached on 7:00AM-3:30PM.
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, Kamal B Divecha can be reached on (571)272-5863. The fax phone number for the organization where this application or proceeding is assigned is (571)273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BHARAT BAROT/Primary Examiner, Art Unit 2453October 02, 2025
Prosecution Insights