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 .
This communication is in response to the amendment filed on 04/07/2026.
Claims 1-20 are pending and are rejected. Claims 1, 10, and 15 have been amended.
Response to Arguments
Applicant’s arguments with respect to claims 1, 10, 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
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jacob et al. (US 9596167 B1), hereafter Jacob in view of Furuno (US 20030031192 A1), hereafter Furuno and further in view of Mirsky et al. (US 20160036695 A1), hereafter Mirsky.
Regarding claim 1, Jacob teaches a method in a network device, the method comprising:
receiving a local Multiprotocol Label Switching (MPLS) label and a neighbor MPLS label (col. 2, lines 64-67, monitor traffic for a VRF using a Multiprotocol Label Switching (MPLS) label of labeled packets forwarded according to the VRF and in some instances using an MPLS label of labeled packets received at a router), wherein the local MPLS label is associated with a given interface on the network device, wherein the neighbor MPLS label is associated with a remote device (col. 6, lines 49-51, fig. 1, each of PEs 16 for each of the tunnels 22 endpoints may be configured with a particular MPLS label that identifies received packets for the IP service in the data plane. Examiner note: The PE 16A that configured with a particular MPLS label corresponds to the local MPLS and the PE 16C/B that configured with the other MPLS labels correspond to the neighbor MPLS label);
in response to receiving a first packet on the given interface of the network device, the network device:
generating a tunneled packet by encapsulating the first packet and the neighbor MPLS label (col. 6,lines 28-32, PEs 16 receive such IP traffic on attachment circuits 20 and encapsulate the traffic for transport by tunnels 22 to remote PEs 16; col. 6, lines 55-58, PE 16A may be further configured with MPLS label “200” that, when attached to packets received from PE 16B, identifies the packets as tunnel 22A packets associated with VRF 26A); and
transmitting the tunneled packet to the remote device to be processed by the remote device including the remote device transmitting a return packet (col. 6, lines 30-32, PEs 16 receive such IP traffic on attachment circuits 20 and encapsulate the traffic for transport by tunnels 22 to remote PEs 16); and
in response to receiving the return packet from the remote device (col. 9, lines 7-11, in turn, the respective destination VRF 26B or 26C encapsulate the LMR message as the payload of another (e.g., “return”) measurement packet that the respective VRF 26B or 26C transmits back to VRF 26A), the network device:
decapsulating the return packet to recover a second packet and an MPLS label encapsulated in the return packet (col. 10, lines 57-60, upon receiving a return measurement packet that includes an encapsulated LMR payload, the MM 27A decapsulates the LMR payload, and analyzes the Rxfcf value included in the LMR payload);
Jacob does not explicitly teach
transmitting the recovered second packet on the given interface in response to the determination;
determining that the MPLS label encapsulated in the return packet is equal to the local MPLS label;
Furuno teaches
transmitting the recovered second packet on the given interface in response to a determination that the recovered MPLS label is equal to the local MPLS label ([0092] when, e.g., a destination network "A" is detected as the destination network, reads a local label (source label) corresponding to the destination network "A" (recovered MPLS label is equal to the local MPLS label) and a piece of identifying information of an output I/F from the label learning table 6; [0093] Subsequently, the routing engine 10 (e.g., the label generation module 11 of the routing engine 10) attaches (pads; inserts) the local label to the IP packet and sends the labeled packet to the WAN-I/F 9 identified by the identifying information. The labeled packet is thus sent to the WAN-I/F 9 and forwarded from this WAN/-I/F 9).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob disclosure, the verification of the receive MPLS to route the packet to an appropriate destination/source, as taught by Furuno. One would be motivated to do so to enhance and increase an efficiency of services of MPLS utilized as a backbone technology for IP-VPN (Internet Protocol-Virtual Private Network) services.
Jacob and Furuno do not explicitly teach
determining that the MPLS label encapsulated in the return packet is equal to the local MPLS label.
Mirsky teaches
determining that the MPLS label encapsulated in the return packet is equal to the local MPLS label ([0043] If the value is not empty, then a check can be made whether the My Discriminator from the received MPLS packet matches the local My Discriminator value associated with the BFD session).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob and Furuno disclosure, a comparison label of the return packet to the local label, as taught by Mirsky. One would be motivated to do so to establishing bidirectional forwarding detection for bootstrapping a BFD for an MPLS LSP without requiring the use of LSP Ping.
Regarding claim 2, Jacob, Furuno, and Mirsky teach the method of claim 1, wherein Jacob further teaches the network device is deployed in a network that does not include an MPLS network (col. 5-col. 6, line 1-3, CEs 18 may each represent, in certain instances, one or more of a switch, a hub, a bridge device, or any other network device capable of accessing the IP service).
Regarding claim 3, Jacob, Furuno, and Mirsky teach the method of claim 1, wherein Jacob further the tunneled packet is transmitted to the remote device without using MPLS protocol (col. , 5, lines 17-22, each of customer networks 14 may operate according to a wide variety of network protocols, such as any of the 802.3X family of network protocols related to the Ethernet protocol, any of the 802. IX family of wireless networking protocols, an Internet Protocol (IP) protocol, and a Transmission Control Protocol (TCP)).
Regarding claim 4, Jacob, Furuno, and Mirsky teach the method of claim 1, Furuno further teaches receiving the local and neighbor MPLS labels from a user ([0075] The WAN-I/F 14 controls a function of receiving the labeled packet from the user communication device).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob disclosure, labels are received from the user, as taught by Furuno. One would be motivated to do so to enhance and increase an efficiency of services of MPLS utilized as a backbone technology for IP-VPN (Internet Protocol-Virtual Private Network) services.
Regarding claim 5, Jacob, Furuno, and Mirsky teach the method of claim 4, wherein Jacob further teaches the user is a human user or an automated process running on a network management system (col. 2, lines 17-21, an administrator or other entity may configure service monitoring between endpoints that cooperatively offer an IP service, such as a layer 3 virtual private network (L3VPN) or IP-VPN, to interconnect customer networks coupled to the endpoints).
Regarding claim 6, Jacob, Furuno, and Mirsky teach the method of claim 1, wherein Jacob further teaches the local and neighbor MPLS labels are generated by the network device (col. 7, lines 56-57, PEs 16 advertise and install labeled routes for destination prefixes in customer networks).
Regarding claim 7, Jacob, Furuno, and Mirsky teach the method of claim 1, Mirsky further teaches wherein the local and neighbor MPLS labels have the same value ([0043] As the BFD packets are received back from the passive node at the active node via the MPLS network, each of the My Discriminators and Your Discriminators are accessed. If the My Discriminator does match, then the standard BFD process can immediately proceed).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob and Furuno disclosure, a comparison label values of the return packet to the local label, as taught by Mirsky. One would be motivated to do so to establishing bidirectional forwarding detection for bootstrapping a BFD for an MPLS LSP without requiring the use of LSP Ping.
Regarding claim 8, Jacob, Furuno, and Mirsky teach the method of claim 1, wherein Jacob further teaches
the remote device processes the tunneled packet based on the neighbor MPLS label contained in the tunneled packet (col. 22, lines 22-24, PE 16A identifies return flow measurement packet as a response to flow measurement packet based on the value of inner label 164 and the L4/L3 header).
Regarding claim 9, Jacob, Furuno, and Mirsky teach the method of claim 1, wherein Jacob further teaches a first host is connected to the network device and a second host is connected to the remote device, wherein the first packet and the return packet are part of a communication between the first host and the second host (col. 7, lines 40-45, multicast source device 15 (“multicast source 15”) of customer network 14A is a multicast traffic source that makes use of an IP-MVPN configured in IP network 12 including PEs 16 to efficiently deliver multicast traffic to multicast destinations located in at least one of customer networks 14B and 14C).
Regarding claim 10, Jacob teaches a network device comprising:
a plurality of interfaces (col. 8, lines 55-56, CE 18-facing interfaces for VRFs 26);
one or more computer processors (col. 14, lines 59-60, one or more processors); and
a computer-readable storage device comprising instructions for controlling the one or more computer processors to:
receive a packet (ingress packet) on an interface (ingress interface) of the network device (col. 2, lines 64-67, monitor traffic for a VRF using a Multiprotocol Label Switching (MPLS) label of labeled packets forwarded according to the VRF and in some instances using an MPLS label of labeled packets received at a router);
identify a pseudowire associated with the ingress interface (col. 6, lines 52-54, PE 16A may be configured to attach pseudowire label "100" to specify tunnel 22A packets, associated with VRF 26B, to PE 16B);
generate a tunneled packet comprising the ingress packet and a first user- selected MPLS label (col. 6,lines 28-32, PEs 16 receive such IP traffic on attachment circuits 20 and encapsulate the traffic for transport by tunnels 22 to remote PEs 16; col. 6, lines 55-58, PE 16A may be further configured with MPLS label “200” that, when attached to packets received from PE 16B, identifies the packets as tunnel 22A packets associated with VRF 26A);
transmit the tunneled packet to a remote device associated with the pseudowire (col. 6, lines 30-32, PEs 16 receive such IP traffic on attachment circuits 20 and encapsulate the traffic for transport by tunnels 22 to remote PEs 16);
receive a return packet from the remote device (col. 9, lines 7-11, in turn, the respective destination VRF 26B or 26C encapsulate the LMR message as the payload of another (e.g., “return”) measurement packet that the respective VRF 26B or 26C transmits back to VRF 26A);
identify an interface (egress interface) using a second user-selected MPLS label contained in the return packet (col. 10, lines 57-60, upon receiving a return measurement packet that includes an encapsulated LMR payload, the MM 27A decapsulates the LMR payload, and analyzes the Rxfcf value included in the LMR payload);
Jacob does not explicitly teach
transmit at least a portion of the return packet on the identified egress interface based on the comparison.
Furuno teaches
transmit at least a portion of the return packet on the identified egress interface based on the comparison ([0092] when, e.g., a destination network "A" is detected as the destination network, reads a local label (source label) corresponding to the destination network "A" and a piece of identifying information of an output I/F from the label learning table 6).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob disclosure, the verification of the receive MPLS to route the packet to an appropriate destination/source, as taught by Furuno. One would be motivated to do so to enhance and increase an efficiency of services of MPLS utilized as a backbone technology for IP-VPN (Internet Protocol-Virtual Private Network) services.
Jacob and Furuno do not explicitly teach
compare the second user-selected MPLS label contained in the return packet to the first user-selected MPLS label.
Mirsky teaches
compare the second user-selected MPLS label contained in the return packet to the first user-selected MPLS label ([0043] If the value is not empty, then a check can be made whether the My Discriminator from the received MPLS packet matches the local My Discriminator value associated with the BFD session; [0085] Forwarding table entries include both a specific set of match criteria (a set of values or wildcards, or an indication of what portions of a packet should be compared to a particular value/values/wildcards).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob and Furuno disclosure, a comparison label of the return packet to the local label, as taught by Mirsky. One would be motivated to do so to establishing bidirectional forwarding detection for bootstrapping a BFD for an MPLS LSP without requiring the use of LSP Ping.
Regarding claim 11, Jacob, Furuno, and Mirsky teach the network device of claim 10, wherein Furuno further teaches the computer-readable storage device further comprises instructions for controlling the one or more computer processors to receive first and second user-selected MPLS labels from a user ([0075] The WAN-I/F 14 controls a function of receiving the labeled packet from the user communication device).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob disclosure, labels are received from the user, as taught by Furuno. One would be motivated to do so to enhance and increase an efficiency of services of MPLS utilized as a backbone technology for IP-VPN (Internet Protocol-Virtual Private Network) services.
Regarding claim 12, Jacob, Furuno, and Mirsky teach the network device of claim 10, wherein Jacob further teaches the ingress interface is patched to the pseudowire (col. 6, lines 52-54, PE 16A may be configured to attach pseudowire label "100" to specify tunnel 22A packets, associated with VRF 26B, to PE 16B).
Regarding claim 13, Jacob, Furuno, and Mirsky teach the network device of claim 10, wherein the ingress interface and the egress interface are the same interface (col. 6, lines 64-67, Service endpoints that receive IP traffic from attachment circuits are ingress service endpoints, while service endpoints that output IP traffic to attachment circuits 20 are egress service endpoints).
Regarding claim 14, Jacob, Furuno, and Mirsky teach the network device of claim 10, Jacob does not teach wherein the first and second user-selected MPLS labels are the same ([0043] As the BFD packets are received back from the passive node at the active node via the MPLS network, each of the My Discriminators and Your Discriminators are accessed. If the My Discriminator does match, then the standard BFD process can immediately proceed).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob and Furuno disclosure, a comparison label values of the return packet to the local label, as taught by Mirsky. One would be motivated to do so to establishing bidirectional forwarding detection for bootstrapping a BFD for an MPLS LSP without requiring the use of LSP Ping.
Regarding claim 15, Jacob teaches a method in a network management system to manage sending packets on a pseudowire, the method comprising the network management system:
receiving a local MPLS label and a neighbor MPLS label from a user, wherein the local MPLS label is associated with a given interface on a first network device, wherein the neighbor MPLS label is associated with a second network device (col. 2, lines 64-67, monitor traffic for a VRF using a Multiprotocol Label Switching (MPLS) label of labeled packets forwarded according to the VRF and in some instances using an MPLS label of labeled packets received at a router), and
communicating the local and neighbor MPLS labels to the first network device to be stored in the first network device (col. 6, lines 49-51, fig. 1, each of PEs 16 for each of the tunnels 22 endpoints may be configured with a particular MPLS label that identifies received packets for the IP service in the data plane.),
wherein in response to the first network device receiving a first packet on the given interface of the first network device, the first network device:
adds the neighbor MPLS label to the first packet; encapsulates the first packet with the added neighbor MPLS label in a tunneling protocol to produce an outgoing packet (col. 6,lines 28-32, PEs 16 receive such IP traffic on attachment circuits 20 and encapsulate the traffic for transport by tunnels 22 to remote PEs 16; col. 6, lines 55-58, PE 16A may be further configured with MPLS label “200” that, when attached to packets received from PE 16B, identifies the packets as tunnel 22A packets associated with VRF 26A);
Jacob does not explicitly teach
transmits the outgoing packet to the second network device.
Furuno teaches
transmits the outgoing packet to the second network device ([0092] when, e.g., a destination network "A" is detected as the destination network, reads a local label (source label) corresponding to the destination network "A" and a piece of identifying information of an output I/F from the label learning table 6).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob disclosure, the verification of the receive MPLS to route the packet to an appropriate destination/source, as taught by Furuno. One would be motivated to do so to enhance and increase an efficiency of services of MPLS utilized as a backbone technology for IP-VPN (Internet Protocol-Virtual Private Network) services.
Regarding claim 16, Jacob and Furuno teach the method of claim 15, wherein a packet from the second network device is transmitted by the second network device in response to the second network device receiving the outgoing packet from the first network device, wherein in response to the first network device receiving the packet from the second network device, the first network device:
decapsulates the incoming packet to obtain a second packet and an MPLS label, wherein the MPLS label is equal to the local MPLS label (col. 10, lines 57-60, upon receiving a return measurement packet that includes an encapsulated LMR payload, the MM 27A decapsulates the LMR payload, and analyzes the Rxfcf value included in the LMR payload); and
Jacob does not explicitly teach
in response to the MPLS label equaling the local MPLS label, transmits the second packet on the given interface associated with the local MPLS label.
in response to the MPLS label equaling the local MPLS label, transmits the second packet on the given interface associated with the local MPLS label ([0092] when, e.g., a destination network "A" is detected as the destination network, reads a local label (source label) corresponding to the destination network "A" and a piece of identifying information of an output I/F from the label learning table 6).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob disclosure, the verification of the receive MPLS to route the packet to an appropriate destination/source, as taught by Furuno. One would be motivated to do so to enhance and increase an efficiency of services of MPLS utilized as a backbone technology for IP-VPN (Internet Protocol-Virtual Private Network) services.
Regarding claim 17, Jacob, Furuno, and Mirsky teach the method of claim 15, Jacob does not teach wherein the local and neighbor MPLS labels are the same label ([0043] As the BFD packets are received back from the passive node at the active node via the MPLS network, each of the My Discriminators and Your Discriminators are accessed. If the My Discriminator does match, then the standard BFD process can immediately proceed).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob and Furuno disclosure, a comparison label values of the return packet to the local label, as taught by Mirsky. One would be motivated to do so to establishing bidirectional forwarding detection for bootstrapping a BFD for an MPLS LSP without requiring the use of LSP Ping.
Regarding claim 18, Jacob and Furuno teach the method of claim 15, wherein Jacob further teaches the user is a human user or an automated process running on the network management system (col. 2, lines 17-21, an administrator or other entity may configure service monitoring between endpoints that cooperatively offer an IP service, such as a layer 3 virtual private network (L3VPN) or IP-VPN, to interconnect customer networks coupled to the endpoints).
Regarding claim 19, Jacob and Furuno teach the method of claim 15, Jacob further teaches the network management system storing the local MPLS label of the first network device as a neighbor MPLS label in the second network device and storing the neighbor MPLS label of the first network device as a local MPLS label in the second network device, wherein in response to the second network device receiving the outgoing packet from the first network device, the second network device:
adds its neighbor MPLS label to the second packet (col. 10, lines 34-37, To generate a return measurement packet, any of MMs 27B and 27C may encapsulate an LMR payload using a source IP (SIP) address of the interface that faces the respective CE 14B or 14C attached to the VRF 26B or 26C);
encapsulates the second packet with the added neighbor MPLS label in a
tunneling protocol to produce an outgoing packet (col. 10, lines 37-42, to encapsulate the LMR payload, MMs 27B and 27C add a field for a destination IP (DIP) address, which reflects the source IP address from which the most recent measurement packet (with the corresponding LMM payload) was received);
Jacob does not explicitly teach
transmits the outgoing packet to the first network device.
Furuno teaches
transmits the outgoing packet to the first network device based on a comparison ([0092] when, e.g., a destination network "A" is detected as the destination network, reads a local label (source label) corresponding to the destination network "A" and a piece of identifying information of an output I/F from the label learning table 6).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob disclosure, the verification of the receive MPLS to route the packet to an appropriate destination/source, as taught by Furuno. One would be motivated to do so to enhance and increase an efficiency of services of MPLS utilized as a backbone technology for IP-VPN (Internet Protocol-Virtual Private Network) services.
Jacob and Furuno do not explicitly teach
a comparison of the local MPLS label to a MPLS label returned from the second network device.
Mirsky teaches
a comparison of the local MPLS label to a MPLS label returned from the second network device ([0043] If the value is not empty, then a check can be made whether the My Discriminator from the received MPLS packet matches the local My Discriminator value associated with the BFD session; [0085] Forwarding table entries include both a specific set of match criteria (a set of values or wildcards, or an indication of what portions of a packet should be compared to a particular value/values/wildcards).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jacob and Furuno disclosure, a comparison label of the return packet to the local label, as taught by Mirsky. One would be motivated to do so to establishing bidirectional forwarding detection for bootstrapping a BFD for an MPLS LSP without requiring the use of LSP Ping.
Regarding claim 20, Jacob, Furuno, and Mirsky teach the method of claim 15, wherein Jacob further teaches the network does not use MPLS (col. 5-col. 6, line 1-3, CEs 18 may each represent, in certain instances, one or more of a switch, a hub, a bridge device, or any other network device capable of accessing the IP service).
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 ANH NGUYEN whose telephone number is (571)270-0657. The examiner can normally be reached M-F.
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, Umar Cheema can be reached at 5712703037. 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.
/ANH NGUYEN/ Primary Examiner, Art Unit 2458
Prosecution Insights