DETAILED ACTION
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 .
Response to Amendment
This office action is in response to amendment/reconsideration filed on 2/10/2026, the amendment/reconsideration has been considered. No amendments have been made to claims. Claims 1-20 are pending for examination as cited below.
Response to Arguments
Applicant's arguments filed on 2/10/2026 have been fully considered but they are not persuasive. In remarks applicant argues in substance that:
1. Overview
Applicant argues that neither “Vemu” nor “Alister” teaches or suggests “generating a nonce corresponding to each of a plurality of policies.” Applicant asserts that “Vemu” merely references IKE/IKEv2 generally and that neither reference discusses nonces in relation to policies.
The arguments are not persuasive. When the references are properly considered, Vemu expressly teaches once generation in IKEv2, and Alister teaches distributing security policies, associating them with security groups, and generating/exchanging keying material per policy group. When combined, the references render obvious generating a nonce (i.e., random value used in key derivation) for each policy group.
2. Vemu teaches nonce generation in IKEv2
Applicant acknowledges that IKEv2 uses nonces but argues that Vemu does not link nonce to policies. This is incorrect.
(a) Vemu explicitly incorporates IKEv2 negotiation, which requires nonce generation
Vemu states:
Vemu [0003], “negotiation is typically carried out using IKE or IKEv2 in accordance with security policy defined in a policy database (PD) held in the server.”
IKEv2 mandatorily generates nonces for each SA negotiation. Because Vemu ties IKEv2 negotiation directly to the security policy defined in the PD, the nonce generation is inherently tied to the policy being negotiated.
(b) Incorporation of protocol includes its required operations
IKEv2 requires:
A unique nonce for each SA negotiation
SA negotiation is performed per policy selector (source/destination, protocol, ports)
Thus, nonce generation is performed per policy, because each policy triggers a separate SA negotiation. Applicant’s argument that Vemu “does not teach any relationship between nonces an each of a plurality of policies” is therefore inconsistent with the explicit disclosure that IKEv2 negotiation is performed in accordance with the security policy.
3. Alister teaches per-policy (per-security-group) keying and random value generation
Applicant asserts that Alister does not teach nonces or random values tied to polices. This is incorrect:
(a) Alister repeatedly describes:
Alister fig.3, steps 322-326, “KGDP 14-A replies with key KA1…KGDP 14-B
replies with key KB.”
These keys are generated per security group )SG1, SG2), which are the polices in Alister’s architecture
(b) Alister defines polices as security groups
Alister [0006], “policy 12…defines the traffic to be secured by source and destination IP address, pot and/or protocol.”
Alister [0094], “Host 10-A-1 is assigned to SG1…Host 10-A-2 is assigned to SG2.”
Thus, each SG corresponds to a policy, and each policy results in generation of keying material.
(c ) Key generation in Alister necessarily uses random values (nonces)
Alister describes:
Alister [0076]-[0077], “Key generation…creates keys to secure a given tunnel…as in IKE this is done in coordination with a single peer as each side agrees on outbound and inbound keys.”
4. Combined teachings render the claim obvious
(a) Vemu provides:
IKEv2 negotiation tied to security policies (Vemu, [0003])
IKEv2 inherently generates nonces per SA/policy
(b) Alister provides:
Explicit per-policy (per-security-group) key generation (Alister, fig.3, [0094])
Distribution of keying material per policy
Use of IKE-style generation (Alister, [0076]-[0077])
(c) The combination yields the claimed feature
A person of skilled in the art would understand that:
Each policy (SG1, SG2 etc.) in Alister requires key generation.
IKEv2 key generation (as used in both references) requires nonces
Therefore, each policy requires its own nonce.
This is exactly the claimed “generating a nonce corresponding to each of a plurality of policies.”
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-7, 9-15 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vemulapalli et al. (Pub. No.: US 2016/0105401 A1), hereinafter “Vemu” in view of McAlister et al. (Pub. No.: US 2011/0013776 A1), hereinafter “Alister”.
As to claim 1. Vemu discloses the invention substantially including, a method of establishing one or more secure data channels between network devices (Vemu, Abstract), comprising:
by a management system (Vemu, fig.1, element-106, [0021] i.e. VPN server),
(i) configuring a first network device and a second network device to enable generation of a base key pair and exchanging the base key pair between the first network device and the second network device (Vemu, [0003], SAs are negotiated between peer nodes (or security gateways for example) using a mechanism known as “Internet Key Exchange” (IKE or IKEv2), and are allocated an identification known as a “Security Parameter Index” (SPI).);
(ii) generating a nonce corresponding to each of a plurality of policies (Vemu, [0003], Negotiation is typically carried out using IKE or IKEv2 in accordance with security policy defined in a Policy Database (PD) held in the server.).
Vemu however is silent to disclose explicitly, (iii) distributing each of the plurality of policies and the corresponding nonces to the first network device and the second network device.
Alister discloses a similar concept in the same field of endeavor including, (iii) distributing each of the plurality of policies and the corresponding nonces to the first network device and the second network device (Alister, [0036], The present invention is a method for securing message traffic in a data network by distributing security policies. A security policy is identified to a first key generation and distribution point (KGDP) located at a first location. The security policy is a policy to be applied to a network connection, and include at least an identification of a first security group and a network device that is assigned to the first security group at the first location.).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art to incorporate the teachings of “Alister” into those of “Vemu” to provide a technique for securing message traffic in a data network using a protocol such as IPsec, and more particularly various methods for distributing security policies among peer entities in a network while minimizing the passing and storage of detailed policy or key information except at the lowest levels of a hierarchy.
As to claim 2. The combined system of Vemu and Alister discloses the invention as in parent claim above including, wherein the method further comprises receiving, from a user, information that defines one or more of the plurality of policies required to secure data traffic conveyed between the first network device and the second network device (Vemu, [0003], The appropriate SA is identified to the receiving node by including the corresponding SPI in the ESP header. Details of the existing SAs and the respective SPIs are maintained in a Security Association Database (SAD) that is associated with each IPSec node.).
As to claim 3. The combined system of Vemu and Alister discloses the invention as in parent claim above including, wherein the first network device is a first endpoint device and the second network device is a second endpoint device (Vemu, [0003], the organization may specify end-points (e.g., user terminals) to which IP packets may be sent, or from which they may be received, the particular security levels to be used for encrypting packets, etc.).
As to claim 4. The combined system of Vemu and Alister discloses the invention as in parent claim above including, wherein the method further comprises generating, by the management system, a unique key per policy of the plurality of policies (Alister, [0011-0012], additionally this is a known concept in using IKE and IKEv2)).
As to claim 5. The combined system of Vemu and Alister discloses the invention as in parent claim above including, wherein the method further comprises distributing, by the management system, the unique key per policy of the plurality of policies to the first network device and the second network device (Alister, [0036], The security policy is a policy to be applied to a network connection, and include at least an identification of a first security group and a network device that is assigned to the first security group at the first location. Also, PEP concept describes the same concept.).
As to claim 6. The combined system of Vemu and Alister discloses the invention as in parent claim above including, wherein the method further comprises receiving, from a user, information that defines to which network device each of the plurality of policies should be applied (Vemu, [0003], the organization may specify end-points (e.g., user terminals) to which IP packets may be sent, or from which they may be received, the particular security levels to be used for encrypting packets, etc. Further, the idea of segmenting the policy for a specific zone is already known.).
As to claim 7. The combined system of Vemu and Alister discloses the invention as in parent claim above including, wherein the method further comprises configuring the first network device and the second network device to enable Internet Key Exchange, version 2 (IKEv2) protocol (Vemu, [0003], SAs are negotiated between peer nodes (or security gateways for example) using a mechanism known as “Internet Key Exchange” (IKE or IKEv2), and are allocated an identification known as a “Security Parameter Index” (SPI). The appropriate SA is identified to the receiving node by including the corresponding SPI in the ESP header.).
Claims 10-15 are rejected for same rationale as applied to claims 2-7 above.
Claims 19-20 are rejected for same rationale as applied to claims 11, 12 and 14 above.
Claim(s) 8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vemulapalli et al. (Pub. No.: US 2016/0105401 A1), hereinafter “Vemu” in view of McAlister et al. (Pub. No.: US 2011/0013776 A1), hereinafter “Alister” and further in view of Sakai et al. (Pub. No.: US 2004/0093524 A1), hereinafter “Sak”.
As to claim 8. The combined system of Vemu and Alister discloses the invention as in parent claim above. Vemu and Alister however are silent to disclose explicitly, wherein the method further comprises using a random number generator to generate the nonce corresponding to each of the plurality of policies.
Sak discloses a similar concept the same field of endeavor including, wherein the method further comprises using a random number generator to generate the nonce corresponding to each of the plurality of policies (Sak, [0094], The SA parameter is generated by the request processing section 15 based upon contents of a distribution policy, an SPI notified by a setting request message, and random numbers obtained from the random number generator 18.).
Therefore, before the effective filing date of the instant application it would have been obvious to incorporate the teachings of “Sak” into those of “Vemu and Alister” to provide an IPsec setting server apparatus capable of preventing inconsistency of setting among communicating apparatuses. An IPsec processing section subjects a data communication packet received from an interface section to IPsec processing. An SPD is referred to from the IPsec processing section and records policies for applying the IPsec. An SAD is referred to from the IPsec processing section and records an SA necessary for subjecting an individual kind of communication to the IPsec processing. A request processing section receives a setting request message from the IPsec processing apparatus and returns a distribution message.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1 of U.S. Patent No. 12113779 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because, see the table below:
Instant application: 18/816,442 U.S. Patent No.: 12113779 B2
1. A method of establishing one or more secure data channels between network devices, comprising: by a management system, (i) configuring a first network device and a second network device to enable generation of a base key pair and exchanging the base key pair between the first network device and the second network device; (ii) generating a nonce corresponding to each of a plurality of policies; and (iii) distributing each of the plurality of policies and the corresponding nonces to the first network device and the second network device.
1. A method of establishing one or more secure data channels between network devices, comprising: generating and exchanging a base key pair between a first network device and a second network device; for each of a plurality of policies, providing a nonce corresponding to the each of the plurality of policies to the first network device and the second network device; at the first network device and the second network device, generating, for the each of the plurality of policies, a session key that is a function of the base key pair and the nonce corresponding to the each of the plurality of policies; at the first network device, determining that a first data packet matches a rule associated with a first policy of the plurality of policies, encrypting the data with a first session key that corresponds to the first policy to produce a first encrypted data packet, and conveying the first encrypted data packet to the second network device; and at the second network device, determining that the first encrypted data packet matches the rule associated with the first policy, and decrypting the first encrypted data packet with the first session key to produce the first data packet.
Claims 9 and 15 carries the similar limitation but in different statutory class, are rejected for same rationale as applied to claim 1 above. The dependent claims 2-8, 10-14 and 16-20 carries the deficiencies from the base claims.
The instant claims merely broaden the scope of the conflicting claims. It is well settled that broadening the scope of claims would have been obvious to one of ordinary skill in the art in view of the narrower issued claims. In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982) and In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see the attached PTO-892.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAUQIR HUSSAIN whose telephone number is (571)270-1247. The examiner can normally be reached M-F 7:00 - 8:00 with IFP.
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, Brian J Gillis can be reached at 571 272-7952. 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.
/Tauqir Hussain/Primary Examiner, Art Unit 2446
Prosecution Insights