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 Rejections - 35 USC § 102
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 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) 1 - 12, and 16 - 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Linden, U.S. Patent Publication No. 2010/0162383.
Linden teaches:
1. (Currently Amended) A method performed by a first network node, wherein the first network node is a standby member in a cluster, and the cluster further comprises an active member (cluster devices include active and standby devices, [0028]);
the method comprises:
determining a failure of the active member, based at least on a reception of an incoming traffic to the cluster (a cluster device operating in standby mode may become active in response to a failure, [0028]);
taking over the incoming traffic (when activated, the device may implement the tasks and services that were formerly provided by the failed over device, [0028]); and
refreshing a sequence number associated with the incoming traffic (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]).
2. (Currently Amended) The method according to claim 1, further comprising:
synchronizing with a second network node, wherein the second network node is the active member in the cluster (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]).
3. (Currently Amended) The method according to claim 2, further comprising:
receiving a configuration for information synchronization from the second network node (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]);
wherein synchronizing with the second network node comprises:
receiving information according to the configuration from the second network (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]);
wherein a transmission of the information is initiated by the second network node, to synchronize the first network node (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]).
4. (Currently Amended) The method according to claim 3, wherein the information comprises at least one of:
a security association, SA, Up/Down state (phase one and phase two security associations (P1SA, P2SA), [0051]);
a security parameters index, SPI;
an encryption/decryption key (session keys, [0051]); and/or
an algorithm.
5. (Currently Amended) The method according to claim 1, wherein refreshing a sequence number associated to the incoming traffic comprises:
triggering a procedure for SA rekeying (IPSec module requests key updates for a rekey operation, [0191]).
6. (Currently Amended) The method according to claim 5, wherein the procedure for SA rekeying is triggered for a child SA with traffic (IPSec modules work with IKE for P2SA sequence number and rekey operations, [0194]); or
wherein the procedure for SA rekeying is triggered for every child SA.
7. (Currently Amended) The method according to claim 1, wherein the cluster is a hot standby cluster for internet key exchange protocol version 2/ internet protocol security, IKEv2/IPsec, traffic (IPSec modules, [0194]);
wherein the traffic is an IPsec traffic (communication links between IPSec modules, [0194], which implies IPSec traffic); and
wherein the method further comprises:
informing an internet protocol security, IPsec, stack to exchange IKEv2/IPsec protocol messages to take over a control plane (IKE maintains IPSec data, the cluster master utilizes said data for activating/deactivating devices for load balancing, [0195]).
8. (Currently Amended) A method performed by a second network node, wherein the second network node is an active member in a cluster, and the cluster further comprises a standby member (cluster devices include active and standby devices, [0028]);
the method comprises:
transmitting a configuration for information synchronization to a first network node (a cluster device operating in standby mode may become active in response to a failure, [0028]); and
transmitting information according to the configuration to the first network node, wherein the first network node is a standby member in the cluster (a cluster device operating in standby mode may become active in response to a failure, [0028]).
9. (Currently Amended) The method according to claim 8, wherein the information comprises at least one of:
a security association, SA, Up/Down state (phase one and phase two security associations (P1SA, P2SA), [0051]);
a security parameters index, SPI;
an encryption/decryption key (session keys, [0051]); and/or
an algorithm.
10. (Currently Amended) The method according to claim 8, wherein the cluster is a hot standby cluster for internet key exchange protocol version 2/ internet protocol security, IKEv2/IPsec, traffic (IPSec modules, [0194]).
11. (Currently Amended) An apparatus for a first network node, wherein the first network node is a standby member in a cluster, and the cluster further comprises an active member (cluster devices include active and standby devices, [0028]):
wherein the apparatus for the first network node comprises:
a processor; and
a memory, the memory containing instructions executable by the processor, whereby the apparatus for the first network node is operative for:
determining a failure of the active member, based at least on a reception of an incoming traffic to the cluster (a cluster device operating in standby mode may become active in response to a failure, [0028]);
taking over the incoming traffic (a cluster device operating in standby mode may become active in response to a failure, [0028]); and
refreshing a sequence number associated with the incoming traffic (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]).
12. (Currently Amended) The apparatus according to claim 11, wherein the apparatus is further operative to perform operations comprising:
synchronize with a second network node, wherein the second network node is the active member in the cluster (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]).
16. (New) The apparatus according to claim 12, wherein the apparatus is further operative to perform operations comprising:
receive a configuration for information synchronization from the second network node (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]);
wherein synchronize with the second network node comprises:
receive information according to the configuration from the second network (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]);
wherein a transmission of the information is initiated by the second network node, to synchronize the first network node (the flow run-time synchronization data includes the data to transition a flow from one cluster device to another device and includes the security association sequence information number, [0092]).
17. (New) The apparatus according to The apparatus according to wherein the information comprises at least one of:
a security association, SA, Up/Down state (phase one and phase two security associations (P1SA, P2SA), [0051]);
a security parameters index, SPI;
an encryption/decryption key (session keys, [0051]); and/or
an algorithm.
18. (New) The apparatus according to claim 11, wherein refresh a sequence number associated to the incoming traffic comprises:
trigger a procedure for SA rekeying (IPSec module requests key updates for a rekey operation, [0191]).
19. (New) The apparatus according to claim 18, wherein the procedure for SA rekeying is triggered for a child SA with traffic (IPSec modules work with IKE for P2SA sequence number and rekey operations, [0194]); or
wherein the procedure for SA rekeying is triggered for every child SA.
20. (New) The apparatus according to claim 11, wherein the cluster is a hot standby cluster for internet key exchange protocol version 2/ internet protocol security, IKEv2/IPsec, traffic (IPSec modules, [0194]);
wherein the traffic is an IPsec traffic (communication links between IPSec modules, [0194], which implies IPSec traffic); and
wherein the apparatus is further operative to perform operations comprising:
inform an internet protocol security, IPsec, stack to exchange IKEv2/IPsec protocol messages to take over a control plane (IKE maintains IPSec data, the cluster master utilizes said data for activating/deactivating devices for load balancing, [0195]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER G SOLINSKY whose telephone number is (571)270-7216. The examiner can normally be reached M - Th, 6:30 A - 5:00 P.
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, Asad Nawaz can be reached at 571-272-3988. 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.
PETER G. SOLINSKY
Examiner
Art Unit 2463
/Peter G Solinsky/Primary Examiner, Art Unit 2463
