Prosecution Insights
Last updated: April 19, 2026
Application No. 18/588,818

Patch Panels Using Static MPLS Pseudowire Tunnels

Non-Final OA §103
Filed
Feb 27, 2024
Examiner
NGUYEN, ANH
Art Unit
2458
Tech Center
2400 — Computer Networks
Assignee
Arista Networks, Inc.
OA Round
1 (Non-Final)
79%
Grant Probability
Favorable
1-2
OA Rounds
2y 9m
To Grant
99%
With Interview

Examiner Intelligence

Grants 79% — above average
79%
Career Allow Rate
282 granted / 359 resolved
+20.6% vs TC avg
Strong +25% interview lift
Without
With
+24.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
23 currently pending
Career history
382
Total Applications
across all art units

Statute-Specific Performance

§101
12.8%
-27.2% vs TC avg
§103
58.6%
+18.6% vs TC avg
§102
9.0%
-31.0% vs TC avg
§112
12.1%
-27.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 359 resolved cases

Office Action

§103
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 application filed on 02/27/2024. Claims 1-20 are pending and are rejected. Information Disclosure Statement The information disclosure statement (IDS) submitted on 2/27/24 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Objections Claims 9 and 10-18 are objected to because of the following informalities: Claim 9 should be renumbered as Claim 10. Claims 10-18 should be renumbered as Claims 12-20. Appropriate correction is required. For the purpose of examination, Claims 9 and 10-18 have been renumbered as Claims 10 and 12-10, respectively. 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-6, 8-13, 15-16, and 18-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. 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 a determination that the recovered MPLS label 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). 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 2, Jacob and Furuno 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 and Furuno 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 and Furuno 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 and Furuno 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 and Furuno 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 8, Jacob and Furuno 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 and Furuno 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. Furuno teaches transmit at least a portion of the return packet on the identified egress interface ([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 11, Jacob and Furuno 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 and Furuno 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 and Furuno 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 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 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 ([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 20, Jacob and Furuno 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). Claims 7, 14, and 17 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 Pandey and further in view of Wang (US 20230031179 A1). Regarding claim 7, Jacob and Furuno teach the method of claim 1, Jacob does not teach wherein the local and neighbor MPLS labels have the same value. Wang teaches wherein the local and neighbor MPLS labels have the same value ([0176] the ILM table entries of the SR-MPLS tunnel and the virtual circuit with the same label value should reside in different label spaces). 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, two labels have the same values, as taught by Wang. One would be motivated to do so to distinguish context information about the destination of the two packets and forward the data packets to the corresponding device. Regarding claim 14, Jacob and Furuno teach the network device of claim 10, Jacob does not teach wherein the first and second user-selected MPLS labels are the same. Wang teaches wherein the first and second user-selected MPLS labels are the same ([0176] the ILM table entries of the SR-MPLS tunnel and the virtual circuit with the same label value should reside in different label spaces). 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, two labels have the same values, as taught by Wang. One would be motivated to do so to distinguish context information about the destination of the two packets and forward the data packets to the corresponding device. Regarding claim 17, Jacob and Furuno teach the method of claim 15, Jacob does not teach wherein the local and neighbor MPLS labels are the same label. Wang teaches wherein the local and neighbor MPLS labels are the same label ([0176] the ILM table entries of the SR-MPLS tunnel and the virtual circuit with the same label value should reside in different label spaces). 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, two labels have the same values, as taught by Wang. One would be motivated to do so to distinguish context information about the destination of the two packets and forward the data packets to the corresponding device. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Zhao (US 20140056300 A1) and Pandey (US 20250219936 A1). 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
Read full office action

Prosecution Timeline

Feb 27, 2024
Application Filed
Dec 19, 2025
Non-Final Rejection — §103
Mar 21, 2026
Interview Requested
Apr 01, 2026
Applicant Interview (Telephonic)
Apr 01, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602480
DATA MANAGEMENT APPARATUS AND DATA MANAGEMENT METHOD
2y 5m to grant Granted Apr 14, 2026
Patent 12603908
SYSTEM FOR DETECTING ANOMALOUS NETWORK PATTERNS BASED ON ANALYZING NETWORK TRAFFIC DATA AND METHOD THEREOF
2y 5m to grant Granted Apr 14, 2026
Patent 12587558
SYSTEM AND METHOD OF ARTIFICIAL INTELLIGENCE ASSISTED CYBER THREAT IDENTIFICATION VIA WEBSERVER LOGS
2y 5m to grant Granted Mar 24, 2026
Patent 12578895
USING NETWORK DEVICE REPLICATION IN DISTRIBUTED STORAGE CLUSTERS
2y 5m to grant Granted Mar 17, 2026
Patent 12581310
PAIRING OF USER DEVICE WITH REMOTE SYSTEM
2y 5m to grant Granted Mar 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
79%
Grant Probability
99%
With Interview (+24.9%)
2y 9m
Median Time to Grant
Low
PTA Risk
Based on 359 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month