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 .
DETAILED ACTION
The instant application having Application No. 18/896,762 is presented for examination by the examiner. Claims 1, 8 and 15 are amended. Claims 1-20 have been examined.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 8 and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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, 2, 8 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 2024/0283737 A1), in view of Shen (US 20220045933 A1).
Regarding Claim 1
Huang discloses:
A network device comprising: one or more processing units; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processing units, cause the one or more processing units to: discover, by route advertising, an IP tunnel gateway (Huang ¶65, 81, 100: teach discovering, by route advertising, an IP tunnel gateway by explicitly disclosing that a first network device advertises an IP Prefix route including a gateway (GW) IP address and an MPLS label, and that upon receiving the advertised route, a second network device identifies a tunnel (Tunnel1) as the outbound interface for packet forwarding based on the advertised routing information.); update discovered IP tunnel in a routing table based on the route advertising of the IP tunnel gateway (Huang ¶81, 91–93, 100: teach discovering, by route advertising, an IP tunnel gateway and updating an advertised IP tunnel in a routing table by explicitly disclosing that a first network device advertises an IP Prefix route including a GW IP address and an MPLS label, and that upon receiving the advertised route, a second network device saves the advertised route fields into an IP-VRF routing table and identifies and records a tunnel (Tunnel1) as an outbound interface for packet forwarding.).
Huang does not explicitly teach forwarding the routing table update to either (A) a peer tunnel gateway outside an access-controlled network domain, or (B) a central policy store of the access-controlled network domain. On the other hand, Shen teaches that border routers advertise Transport Endpoint SIDs (TESIDs) to a controller device (128) using BGP-LS, where the controller device manages the routing domain and receives routing state updates from border routers within the domain (Shen ¶¶0035, 0054). The controller device 128 within domain 114A constitutes a central policy store of the access-controlled network domain, and the BGP-LS advertisement of the routing table update to that controller directly reads on forwarding the routing table update to a central policy store of the access-controlled network domain. Shen further teaches that border routers forward TESID advertisements via BGP to other border routers across domain boundaries (¶0040) which reads on forwarding the routing table update to a peer tunnel gateway outside the access-controlled network domain.
It would have been obvious to one of ordinary skill in the art to incorporate the routing table update forwarding mechanism of Shen into the tunnel gateway system of Huang in order to propagate tunnel routing state to either a centralized controller or peer gateway for network wide consistency and policy enforcement. Forwarding routing updates to a central policy store or peer gateway is a well-known and predictable design pattern in BGP tunnel routing systems, as evidenced by Shen's explicit disclosure of both mechanisms. The combination yields predictable results and involves no more than the application of known techniques to a known system.
Regarding Claim 2
Huang discloses:
The network device of claim 1, wherein the instructions further cause the one or more processing units to register a network interface based on the routing table update (Huang ¶0091–0092: teach registering a network interface based on a routing table update by explicitly disclosing that, after receiving an advertised IP Prefix route, a network device updates an IP-VRF routing table and stores an identified outbound interface (e.g., Tunnel1 or an IRB interface) in the routing entry for subsequent packet forwarding.).
Regarding Claim 8
Claim 8 is directed to a method corresponding to the computer-executable instruction in claim 1. Claim 8 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 9
Claim 9 is directed to a method corresponding to the computer-executable instruction in claim 2. Claim 9 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Claims 3-7 and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 2024/0283737 A1), in view of Shen (US 20220045933 A1) as applied to claims 1-2 and 8-9 above, and in further view of Lee (US 2023/0319111 A1).
Regarding Claim 3
Huang and Shen combined teach a network device that discovers an IP tunnel gateway by route advertising, updates a routing table based on that advertisement, and forwards the routing table update to either a central policy store or peer gateway across domain boundaries. However, Huang and Shen are silent in explicitly teaching configuring a cryptographic engine of the network device to bring up a key exchange session according to a key exchange protocol. Lee teaches configuring a cryptographic engine to establish a key exchange session using a key exchange protocol, such as Internet Key Exchange (IKE), to negotiate security associations for an IPsec tunnel (¶33, 36, 37). Lee explicitly discloses that when an IPsec tunnel is required, a cryptographic engine negotiates keys and establishes security associations prior to encrypted communications.
It would have been obvious to configure the network device of Huang and Shen to include the cryptographic key exchange mechanism of Lee in order to secure the advertised IP tunnel, as securing tunnel communications via key exchange was a well-known and predictable improvement for tunnel-based routing systems. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Regarding Claim 4
Huang and Shen combined teach a network device that discovers an IP tunnel gateway by route advertising, updates a routing table based on that advertisement, and forwards the routing table update to either a central policy store or peer gateway across domain boundaries. However, Huang and Shen is silent in explicitly teaching updating the advertised IP tunnel in the routing table to identify a key exchange session. Lee teaches that, after a key exchange session is established, tunnel routing information is updated by writing security association information, including a remote gateway address and IPsec tunnel key, into an IPsec routing table for handling subsequent packets of the session (¶37, 47).
It would have been obvious to update the advertised IP tunnel of Huang and Shen to identify the key exchange session as taught by Lee in order to ensure that routing entries correctly reference secured tunnel sessions. Associating routing entries with established security associations is a predictable and routine design choice. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Regarding Claim 5
Huang and Shen combined teach a network device that discovers an IP tunnel gateway by route advertising, updates a routing table based on that advertisement, and forwards the routing table update to either a central policy store or peer gateway across domain boundaries. However, Huang and Shen are silent in explicitly teaching updating a forwarding table based on an updated advertised IP tunnel that identifies a key exchange session. Lee teaches updating forwarding behavior based on established IPsec tunnel parameters by explicitly disclosing that, after security associations are negotiated, a load balancing engine updates an IPsec routing table and session table that are used to forward subsequent packets for the session over the IPsec tunnel (¶35, 37, 43).
It would have been obvious to one of ordinary skill in the art to update forwarding tables or forwarding behavior in Huang and Shen based on the secured tunnel information of Lee so that packets are forwarded using the correct IPsec tunnel and associated security parameters. This modification yields predictable and secure packet forwarding behavior. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Regarding Claim 6
Huang and Shen combined teach a network device that discovers an IP tunnel gateway by route advertising, updates a routing table based on that advertisement, and forwards the routing table update to either a central policy store or peer gateway across domain boundaries. However, Huang and Shen are silent in explicitly teaching encapsulating path information of an outbound packet according to a tunneling protocol based on an updated forwarding table. Lee teaches encapsulating path information of outbound packets according to a tunneling protocol by explicitly disclosing that, after an IPsec tunnel is established, outbound packets are processed for IPsec transmission and new headers containing information necessary for IPsec routing are attached to the packets prior to encryption (¶39).
It would have been obvious to one of ordinary skill in the art to apply the packet encapsulation techniques of Lee to the updated forwarding behavior of Huang and Shen so that outbound packets are encapsulated in accordance with the established IP tunnel and associated forwarding information. This combination yields predictable and secure packet transmission over a tunnel. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Regarding Claim 7
Huang and Shen combined teach a network device that discovers an IP tunnel gateway by route advertising, updates a routing table based on that advertisement, and forwards the routing table update to either a central policy store or peer gateway across domain boundaries. Huang and Shen are silent in explicitly teaching configuring a cryptographic engine to encrypt encapsulated path information of an outbound packet. Lee teaches configuring a cryptographic engine to encrypt encapsulated path information by explicitly disclosing that an IPsec encrypts packet contents and header fields, including newly attached headers containing information necessary for IPsec routing, from cleartext into ciphertext (¶39).
It would have been obvious to apply the encryption techniques of Lee to the encapsulated packets forwarded according to Huang and Shen so that routing and path information within the IP tunnel is securely encrypted. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Regarding Claim 10
Claim 10 is directed to a method corresponding to the computer-executable instruction in claim 3. Claim 10 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 11
Claim 11 is directed to a method corresponding to the computer-executable instruction in claim 4. Claim 11 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 12
Claim 12 is directed to a method corresponding to the computer-executable instruction in claim 5. Claim 12 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 13
Claim 13 is directed to a method corresponding to the computer-executable instruction in claim 6. Claim 13 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 14
Claim 14 is directed to a method corresponding to the computer-executable instruction in claim 7. Claim 14 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Claims 15-16 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 2024/0283737 A1), in view of Alharbi (US 2021/0084010 A1) and in further view of Shen (US 20220045933 A1).
Regarding Claim 15
Huang Teaches:
A network device configured as an IP tunnel gateway, comprising: one or more processing units; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processing units, cause the one or more processing units to:
advertise the IP tunnel gateway by route advertising (Huang ¶65, 81, 100: teach discovering, by route advertising, an IP tunnel gateway by explicitly disclosing that a first network device advertises an IP Prefix route including a gateway (GW) IP address and an MPLS label, and that upon receiving the advertised route, a second network device identifies a tunnel (Tunnel1) as the outbound interface for packet forwarding based on the advertised routing information.);
Huang teaches advertising an IP tunnel gateway via route advertising and updating routing tables based on advertised tunnel information (¶65, 81, 100), but is silent in explicitly teaching updating advertised IP tunnels or ceasing route advertisement based on a key exchange session being brought down at a cryptographic engine. Alharbi teaches managing IPsec tunnels using IKE security associations and modifying or stopping routing exchange in response to security-related events, including cryptographic key lifecycle changes and policy updates (¶47–49, 73–74).
It would have been obvious to update or withdraw advertised IP tunnel routes in Huang based on the cryptographic session teardown taught by Alharbi, because continuing to advertise a tunnel without a valid security association would be insecure and nonfunctional. Ceasing route advertisement in response to tunnel teardown yields predictable and expected results in secure network routing systems.
Huang and Alharbi are silent in explicitly teaching forwarding the routing table update to either (A) a peer tunnel gateway outside an access-controlled network domain, or (B) a central policy store of the access-controlled network domain. On the other hand, Shen teaches that border routers advertise Transport Endpoint SIDs (TESIDs) to a controller device (128) using BGP-LS, where the controller device manages the routing domain and receives routing state updates from border routers within the domain (Shen ¶¶0035, 0054). The controller device 128 within domain 114A constitutes a central policy store of the access-controlled network domain, and the BGP-LS advertisement of the routing table update to that controller directly reads on forwarding the routing table update to a central policy store of the access-controlled network domain. Shen further teaches that border routers forward TESID advertisements via BGP to other border routers across domain boundaries (¶0040) which reads on forwarding the routing table update to a peer tunnel gateway outside the access-controlled network domain.
It would have been obvious to one of ordinary skill in the art to incorporate the routing table update forwarding mechanism of Shen into the tunnel gateway system of Huang and Alharbi in order to propagate tunnel routing state to either a centralized controller or peer gateway for network wide consistency and policy enforcement. Forwarding routing updates to a central policy store or peer gateway is a well-known and predictable design pattern in BGP tunnel routing systems, as evidenced by Shen's explicit disclosure of both mechanisms. The combination yields predictable results and involves no more than the application of known techniques to a known system.
Regarding Claim 16
Huang Teaches:
The network device of claim 15, wherein the route advertising is configured by a locally stored network policy implemented according to Border Gateway Protocol ("BGP") (Huang ¶45, 56–57, 64: teaches route advertising configured by a locally stored network policy implemented according to BGP by explicitly disclosing that network devices establish BGP peer relationships, advertise EVPN IP Prefix routes carrying route targets (ERTs), and locally retain or import advertised routes into IP-VRF routing tables only when the carried ERT matches a locally configured import route target (IRT), thereby enforcing locally stored BGP routing policy.).
Regarding Claim 18
Huang Teaches:
The network device of claim 15, wherein the route advertising is configured by a network policy applied over network devices reachable over a range of IP addresses, identified by a common IP prefix (Huang ¶65, 84, 0091: teach route advertising configured by a network policy applied over network devices reachable over a range of IP addresses identified by a common IP prefix by explicitly disclosing advertising IP Prefix routes that define a subnet IP range, installing routing entries keyed on the IP Prefix, and forwarding packets whose destination IP addresses fall within the advertised subnet.).
Regarding Claim 19
Huang Teaches:
The network device of claim 15, wherein the route advertising is configured by a network policy applied over network devices reachable over a common VRF (virtual routing and forwarding") virtually defined by a routing table (Huang ¶45, 91: teach route advertising configured by a network policy applied over network devices reachable over a common VRF by explicitly disclosing that only policy-matched routes are retained and stored in a corresponding IP-VRF routing table for packet forwarding.).
Claims 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 2024/0283737 A1), in view of Alharbi (US 2021/0084010 A1), in view of Shen (US 20220045933 A1), as applied to claim 15, and in further view of Vairavakkalai (US 2024/0267257 A1).
Regarding Claim 17
Huang, Alharbi and Shen are silent in explicitly teaching that the route advertising is configured by network policy stored at a central policy store of an access-controlled network domain.
Vairavakkalai teaches route advertising configured by centrally defined network policy implemented according to BGP by explicitly disclosing a service layer that defines mapping communities and import policies used to control how service routes and transport routes are imported and resolved across network devices via BGP (¶107, 117). Vairavakkalai further teaches that BGP import policies match routing attributes, such as communities or colors, to enforce policy-based routing behavior across an access-controlled network domain.
It would have been obvious to configure the BGP-based route advertising of Huang, Alharbi and Shen using the centrally defined BGP import and mapping policies of Vairavakkalai in order to centrally control tunnel route advertisement and routing behavior across an access controlled network domain. Centralized policy definition with distributed enforcement via BGP is a well-known and predictable design choice in large-scale networks. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Regarding Claim 20
Huang, Alharbi and Shen are silent in explicitly teaching that the route advertising is configured by a network policy applied over network devices reachable over a common BGP community defined by a BGP color tag.
Vairavakkalai teaches route advertising configured by network policy applied over network devices reachable over a common BGP community defined by a color tag by explicitly disclosing the use of mapping communities, route-targets, and color attributes to classify transport routes and service routes, and by applying BGP import policies that match on color or route-target values to control how routes are imported and resolved across network devices (¶94, 96, 107, 117). Vairavakkalai further teaches that color attributes encoded in BGP routing information are used to group network devices and routes for policy-based forwarding over selected tunnels.
It would have been obvious to the routing table of Huang, Alharbi and Shen using with the teaching of Vairavakkalai in order to propagate tunnel routing state to a centralized controller gateway for network wide consists. The claim would be obvious in the art and can combine methods known before the effective filling date which produces predictable results.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431
Prosecution Insights