DETAILED ACTION
Claim Status
Applicant’s amendment overcomes the 112(b) rejection to claim 10.
Claim Rejections - 35 USC § 103
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 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-2, 4-5, 7-10, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Madrele (MACSEC AS SERVICE FOR BGP MPLS LAYER 3 VPN (L3VPN) CLIENTS) in view of Baheri (US 20220360605 A1).
Regarding claim 1, Madrele teaches a method performed in a provider edge, PE, node of a label-switched network, comprising: (Page 1)
agreeing on a set of Media Access Control security, MACsec, policies with an adjacent provider (P) node of the network; (Page 9 Figure 3. Page 4: the end provider edge assigns the vpnv4 label. Fully meshed PE’s will advertise this NLRI to another PE’s and macsec/mka service end point are automatically discovered via BGP. Each pair of PEs in a macsec/mka service point must be able to establish (and tear down) pseudowires to each other, i.e., exchange (and withdraw) of macsec/mka NLRI upon service enable and disable.)
agreeing on an association between MACsec labels and MACsec policies with the adjacent P node, and (Page 3 – Page 4: This BGP peer can assign the “macsec label” as an end destination. Upon receipt of the macsec frame, this label can be used to decrypt the macsec frames because this is the end point, and as in the case of vpnv4, the end provider edge assigns the vpnv4 label, and thus the macsec end point is known. Page 4 image 1. Page 4 Label assignment/packet processing, items 1-5.)
obtaining a set of user information rules, each user information rule being associated with a MACsec policy. (Page 3: MAC address is used for MACsec service end point discovery. The PE will generate the new label for MACsec, hence, packets will not be sent as multicast packets but labeled packets will be used, and based on the label, the packet will be delivered to MACsec end point. Page 5 image 1 and Page 6 image 1: Labeled packet while carrying the macsec. Page 6: 1. Encrypt the packets including the VPN label. 2. Encrypt the packets excluding the vpn label. Page 4 Label assignment/packet processing, items 1-5.)
Madrele does not explicitly disclose wherein each MACsec label of the MACsec labels is agreed on with the adjacent P node on a per-link basis between the PE node and the adjacent P node.
However, Baheri teaches wherein each MACsec label of the MACsec labels is agreed on with the adjacent P node on a per-link basis between the PE node and the adjacent P node. ([0038]: utilizing a field known as a MACsec Key Agreement (MKA), which may be part of the SecTAG 18 (e.g., MACsec label) shown in FIGS. 1A and 1B. The MKA may be part of a security protocol and may be configured to run on configured flows (e.g., VLAN, MPLS, etc.) between the two edge devices.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madrele to include above limitations. One would have been motivated to do so because it is an well-known technique in the art that utilizing a field known as a MACsec Key Agreement (MKA), which may be part of the SecTAG or EtherType shown in FIGS. 1A and 1B. The MKA may be part of a security protocol and may be configured to run on configured flows (e.g., VLAN, MPLS, etc.) between the two edge devices Node A and User Device3/Node X. G.8032 and SR are configured to protect traffic and MKA Protocol Data Units (PDUs) in the network. As taught by Baheri, [0038].
Same rationales apply to claims 4 (method), 7 (method), and 16 (label-switched network) because they are substantially similar to claim 1 (method).
Regarding claim 2, Madrele and Baheri teach the method according to claim 1.
Madrele teaches receiving a user packet from a customer edge, CE, device; (Page 9 Figure 3: vrf based packet forwarding for data packet with macsec as encryption service.)
extracting user side information from the user packet, and matching the user side information against the set of user information rules to identify a particular MACsec policy using the association between user information rules and MACsec policies; (Page 9 Figure 3. Page 2: Parsing the RT and RD. BGP is configured for address-family “macsec”. Via RD and RT export import the vrf membership and the BGP next-hop of the macsec peer needed for the particular vrf are known. This BGP peer can assign the “macsec label” as an end destination.)
identifying a particular MACsec label associated with the particular MACsec policy using the association between MACsec labels and MACsec policies agreed on with the adjacent P node; (Page 2 – Page 3: This BGP peer can assign the “macsec label” as an end destination. Upon receipt of the macsec frame, this label can be used to decrypt the macsec frames because this is the end point, and as in the case of vpnv4, the end provider edge assigns the vpnv4 label, and thus the macsec end point is known. For sending the MKA packets, a different label will be used but as MKA packets go multicast, those are replicated to all the peers participating in the macsec operation. Fully meshed PE’s will advertise this NLRI to another PE’s and macsec/mka service end point are automatically discovered via BGP.)
modifying the user packet by inserting the particular MACsec label into the user packet, and (Page 4 Label assignment/packet processing, items 1-5. Page 5 image 1 and Page 6 image 1: Labeled packet while carrying the macsec.)
applying the particular MACsec policy to the modified user packet and sending the modified user packet to the adjacent P node. (Page 4 Label assignment/packet processing, items 1-5. Page 6: 1. Encrypt the packets including the VPN label. 2. Encrypt the packets excluding the vpn label.)
Same rationales apply to claim 17 (label-switched network) because it is substantially similar to claim 2 (method).
Regarding claim 5, Madrele and Baheri teach the method according to claim 1.
Madrele teaches receiving and processing a packet from the adjacent P node or PE node, the packet including a particular MACsec label; (Page 9 Figure 3: data packet forwarded between PE1-asr9k, P, PE2-asr9k and PE3-asr9k.)
identifying a particular MACsec policy associated with the particular MACsec label using the association between MACsec labels and MACsec policies agreed on with the adjacent P node or PE node, and (Page 9 Figure 3: PE2-asr9k and PE3-asr9k identifying MACsec policy associated with M1 LABEL LM1.)
identifying a second particular MACsec label associated with the particular MACsec policy using the association between MACsec labels and MACsec policies agreed on with said another adjacent P node or PE node, inserting the second particular MACsec label into the packet, applying the particular MACsec policy to the packet and sending the packet to said another adjacent P node or PE node. (Page 9 Figure 3: PE2-asr9k insert LABEL LM2, send packet to PE3-asr9k. PE3-asr9k insert LABEL LM3, send packet to PE2-asr9k.)
Regarding claim 8, Madrele and Baheri teach the method according to claim 7.
Madrele teaches in one of the first and second PE nodes:
receiving a user packet from a customer edge, CE, device; (Page 9 Figure 3: vrf based packet forwarding for data packet with macsec as encryption service.)
extracting user side information from the user packet, and matching the user side information against the set of user information rules to identify a particular MACsec policy using the association between user information rules and MACsec policies; (Page 9 Figure 3. Page 2: Parsing the RT and RD. BGP is configured for address-family “macsec”. Via RD and RT export import the vrf membership and the BGP next-hop of the macsec peer needed for the particular vrf are known. This BGP peer can assign the “macsec label” as an end destination.)
identifying a particular MACsec label associated with the particular MACsec policy using the association between MACsec labels and MACsec policies agreed on with the adjacent P node; (Page 2 – Page 3: This BGP peer can assign the “macsec label” as an end destination. Upon receipt of the macsec frame, this label can be used to decrypt the macsec frames because this is the end point, and as in the case of vpnv4, the end provider edge assigns the vpnv4 label, and thus the macsec end point is known. For sending the MKA packets, a different label will be used but as MKA packets go multicast, those are replicated to all the peers participating in the macsec operation. Fully meshed PE’s will advertise this NLRI to another PE’s and macsec/mka service end point are automatically discovered via BGP.)
modifying the user packet by inserting the particular MACsec label into the user packet, and (Page 4 Label assignment/packet processing, items 1-5. Page 5 image 1 and Page 6 image 1: Labeled packet while carrying the macsec.)
applying the particular MACsec policy to the modified user packet and sending the modified user packet to the adjacent P node. (Page 4 Label assignment/packet processing, items 1-5. Page 6: 1. Encrypt the packets including the VPN label. 2. Encrypt the packets excluding the vpn label.)
in the at least one P node:
receiving and processing a packet from the adjacent P node or PE node, the packet including a particular MACsec label; (Page 9 Figure 3: data packet forwarded between PE1-asr9k, P, PE2-asr9k and PE3-asr9k.)
identifying a particular MACsec policy associated with the particular MACsec label using the association between MACsec labels and MACsec policies agreed on with the adjacent P node or PE node, and (Page 9 Figure 3: PE2-asr9k and PE3-asr9k identifying MACsec policy associated with M1 LABEL LM1.)
identifying a second particular MACsec label associated with the particular MACsec policy using the association between MACsec labels and MACsec policies agreed on with said another adjacent P node or PE node, inserting the second particular MACsec label into the packet, applying the particular MACsec policy to the packet and sending the packet to said another adjacent P node or PE node. (Page 9 Figure 3: PE2-asr9k insert LABEL LM2, send packet to PE3-asr9k. PE3-asr9k insert LABEL LM3, send packet to PE2-asr9k.)
in said other one of the first and second PE nodes:
receiving and processing the packet from the at least one P node or from another P node of the label-switched network, and sending the packet to a second CE device adjacent to said other one of the first and second PE nodes. (Page 9 Figure 3: data packet forwarded between CE1, PE1-asr9k, P, PE2-asr9k, PE3-asr9k, CE2 and CE3.)
Regarding claim 9, Madrele and Baheri teach the method according to claim 7.
Madrele teaches the label-switched network implementing Multi-Protocol Label Switching, MPLS. (Page 1: MACSec is provided as a service for Layer 3 Virtual Private Network (L3 VPN) clients over Layer 2 VPN l2vpn/ Virtual Private LAN Service (VPLS) using services ports, such as in Cisco IOS XR.)
Regarding claim 10, Madrele and Baheri teach the method according to claim 7.
Madrele teaches used to establish an end-to-end MACsec path between the first and second CE devices in a Level 3 virtual private network, L3VPN. (Page 1: To provide the MACSec as service for L3 VPN clients over a normal MPLS VPNv4 network, the Border Gateway Protocol (BGP) can be extended for MACSec. The solution is proposed over MPLS L3 VPN. Page 9 Figure 3: MACsec Path between CE1, CE2 and CE3.)
Claim(s) 3 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Madrele (MACSEC AS SERVICE FOR BGP MPLS LAYER 3 VPN (L3VPN) CLIENTS) in view of Baheri (US 20220360605 A1), and in view of Chopra (US 20130091349 A1).
Regarding claim 3, Madrele and Baheri teach the method according to claim 1.
Madrele does not explicitly disclose wherein modifying the user packet further comprises inserting, into the user packet, also a MACsec label identifier, MLI, identifying the particular MACsec label.
However, Chopra teaches wherein modifying the user packet further comprises inserting, into the user packet, also a MACsec label identifier, MLI, identifying the particular MACsec label. (Fig. 2: MPLS Label(s), SecTag. [0021]: The MACSEC PHY component 70 receives the packet 80 and generates a new packet 90 by parsing down past the DA/SA fields 81 and 82 and the VLAN tag(s) field 83 with variable/configurable masks to insert MACSEC Security Tag (SecTag) information in field 92, secure data in field 94 and an Integrity Check Value (ICV) in field 96 after the VLAN tag(s) field 83 before the FCS field 85. [0025]: The MPLS packet 120 comprises fields for the MPLS DA 121, MPLS SA 122, MPLS Label(s) 123, optional control word 124, followed by the MACSEC DA 125, MACSEC SA 126, SecTag 127, SecureData 128, ICV 129 and FCS 130.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madrele to include above limitations. One would have been motivated to do so because both Madrele and Chopra belong to the same company Cisco Technology Inc.
Same rationales apply to claims 6 (method) because it is substantially similar to claim 3 (method).
Response to Arguments
Applicant's arguments, see pages 8-10, filed 03/06/2026, with respect to the rejection(s) of claims 1-10 and 16-17 under 35 U.S.C. § 102 and 35 U.S.C. § 103 have been fully considered but are moot in view of new ground(s) of rejection.
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 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 ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455