DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is responsive to a response filed on November 13th, 2025.
Response to Amendment
The amendments filed on November 13th, 2025 have been entered.
Claims 1, 12-13, 17, and 19 have been amended.
Claim 20 has been canceled.
Claim 21 has been added.
The previously raised 35 U.S.C. 112(b) rejection is withdrawn for claim 19 in light of the amendment.
Response to Arguments
Applicant’s arguments, filed on November 13th, 2025 have been considered but are moot in view of the new grounds of rejection. However, claims 12-16 were found to be patentably distinct from the prior art of record.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3 and 6-11 are rejected under 35 U.S.C. 103 as being unpatentable over Baheri et al. (Pub. No. US 2020/0099568), hereinafter Baheri; in view of Lakshmikanthan et al. (Pub. No. US 2016/0277291), hereinafter Lakshmikanthan.
Claim 1. Baheri discloses [a] network device comprising:
a first input-output interface configured as a maintenance end point (MEP) interface; a second input-output interface configured as a peer interface for the MEP interface (See Parag. [0008]; a network element includes one or more interfaces connected to a network; a switch configured to switch packets between the one or more interfaces; and a controller communicatively coupled to the one or more interfaces and the switch, wherein, responsive to receiving an Operations, Administration, and Maintenance (OAM) Protocol Data Unit (PDU) with a destination Media Access Control (MAC) address equal to an interface address of the one or more interfaces, a Maintenance End Point (MEP) is automatically created based on the received OAM PDU and attributes contained in a header of the OAM PDU, the network device is a slave/reactive network device and the MEP is with a master/active network device. See also Parag. [0051]);
a packet processor coupled to the first and second input-output interfaces and configured to handle a continuity check message (CCM) protocol data unit (PDU) for the MEP interface (See Parag. [0010]; a processing device executing a Virtual Network Function (VNF) includes a network interface and a processor communicatively coupled to one another; and memory storing instructions that, when executed, cause the processor to receive an Operations, Administration, and Maintenance (OAM) Protocol Data Unit (PDU). See Parag. [0008]; a switch configured to switch packets between the one or more interfaces … The received OAM PDU can be a unicast CCM message.); and
control circuitry coupled to the packet processor and configured to perform bridging for the CCM PDU (See Parag. [0009]; The MEP can be one of a DOWN MEP if a received interface the OAM PDU is received on is the same as the interface address; and a UP MEP if the received interface is different from the interface address and an address associated with the OADM PDU is learned. See Parag. [0032]; A UP MEP receives CCMs or PDUs from a switch's bridging function and sends CCMs or PDUs towards the bridging function).
Baheri doesn’t explicitly disclose control circuitry coupled to the packet processor and configured to perform control plane bridging for the CCM PDU, wherein the packet processor is configured to implement a data plane of the network device, wherein the control circuitry is configured to implement a control plane of the network device distinct from the data plane, and wherein the control plane bridging for the CCM PDU is performed in the control plane of the network device.
However, Lakshmikanthan discloses control circuitry coupled to the packet processor and configured to perform control plane bridging, wherein the packet processor is configured to implement a data plane of the network device, wherein the control circuitry is configured to implement a control plane of the network device distinct from the data plane, and wherein the control plane bridging is performed in the control plane of the network device (See Parag. [0008]; a control plane device is configured to implement a control plane of a software defined networking (SDN) network including a plurality of network devices implementing the method for enabling shortest path bridging in a network that is scalable to support sixteen million virtual local area network (VLAN) identifiers using multiprotocol label swapping (MPLS) encapsulation. See Parag. [0078]; FIG. 6D illustrates that a centralized approach 674 (also known as software defined networking (SDN)) that decouples the system that makes decisions about where traffic is sent from the underlying systems that forwards traffic to the selected destination ... The centralized control plane 676 has a south bound interface 682 with a data plane 680 (sometime referred to the infrastructure layer, network forwarding plane, or forwarding plane (which should not be confused with a ND forwarding plane)) that includes the NEs 670A-H (sometimes referred to as switches, forwarding elements, data plane elements, or nodes). See Parag. [0090]; The centralized control plane 776 transmits relevant messages to the data plane 680 ... The data plane 680 processes these messages and programs the appropriate flow information and corresponding actions in the forwarding tables (sometime referred to as flow tables) of the appropriate NE/VNEs, and then the NEs/VNEs map incoming packets to flows represented in the forwarding tables and forward packets based on the matches in the forwarding tables. See Parag. [0054]; The routing information base 505A can be implemented as match action tables that are utilized for forwarding protocol data units PDUs (i.e. packets)).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the control circuitry coupled to the packet processor and configured to perform bridging for the CCM PDU, taught by Baheri, such that the packet processor is configured to implement a data plane of the network device, wherein the control circuitry is configured to implement a control plane of the network device distinct from the data plane, and wherein the control plane bridging is performed in the control plane of the network device, as taught by Lakshmikanthan. This would be convenient to enable scalable implementation of shortest path bridging without hardware changes to network device using media access control (MAC) in multi-protocol label switching encapsulation (Lakshmikanthan, Parag. [0001]).
Claim 2. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 1,
Baheri further discloses wherein the control circuitry is configured to associate an up MEP with the first input-output interface to configure the first input-output interface as the MEP interface (See Parag. [0006]; creating a UP MEP if the received interface is different from the interface address and learning an address associated with the OADM PDU. See Parag. [0031]; if the interface the received PDU is received on is not the same as the destined interface, a UP MEP is created, and the egress port learned).
Claim 3. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 2,
Baheri further discloses wherein the CCM PDU is received at the second input-output interface, wherein the packet processor comprises an ingress pipeline for the second input-output interface, and wherein the ingress pipeline is configured to process the CCM PDU by trapping the CCM PDU and sending the CCM PDU to the control circuitry (See Parag. [0010]; a processing device executing a Virtual Network Function (VNF) includes a network interface and a processor communicatively coupled to one another; and memory storing instructions that, when executed, cause the processor to receive an Operations, Administration, and Maintenance (OAM) Protocol Data Unit (PDU). See Parag. [0051]; vOAM VNF 150 creates a “logical interface” for the vOAM TAP interface, and that logical interface provides an indirect mapping with the physical ports. Any frame received on a physical port would be analogous to a frame received on a logical interface for the vOAM VNF 150. The vOAM VNF 150 uses these logical interfaces for their configurations (MEP creation, etc.) and they help to identify the ingress / egress interfaces for the OAM frame IO (Input/Output). See also Parag. [0048]).
Claim 6. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 2,
Baheri further discloses wherein the control circuitry is configured to perform connectivity fault management at least in part by generating the CCM PDU at the up MEP (See Parag. [0023]; CFM relies on well-defined messages (OAM PDUs) exchanged between the network elements, specifically and in particular each End Point (MEP) that provides origination and termination of the service transport path(s) for a MEG or MA. The network elements 12, 14 are defined as a MEP …).
Claim 7. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 6,
Baheri further discloses wherein the packet processor comprises an egress pipeline for the second input-output interface and wherein the control circuitry is configured to send the CCM PDU to the egress pipeline after performing control plane bridging for the CCM PDU (See Parag. [0032]; A UP MEP receives CCMs or PDUs from a switch's bridging function and sends CCMs or PDUs towards the bridging function. See Parag. [0051]; The vOAM VNF 150 uses these logical interfaces for their configurations (MEP creation, etc.) and they help to identify the ingress / egress interfaces for the OAM frame IO (Input/Output)).
Claim 8. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 7,
Baheri further discloses wherein the egress pipeline is configured to provide the CCM PDU to the second input-output interface for egress (See Parag. [0032]; A UP MEP receives CCMs or PDUs from a switch's bridging function and sends CCMs or PDUs towards the bridging function. See Parag. [0051]; The vOAM VNF 150 uses these logical interfaces for their configurations (MEP creation, etc.) and they help to identify the ingress / egress interfaces for the OAM frame IO (Input/Output)).
Claim 9. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 1,
Baheri doesn’t explicitly disclose wherein the control circuitry is configured to store virtual local area network (VLAN) or tunnel information and wherein the control circuitry is configured to perform control plane bridging for the CCM PDU based on the VLAN or tunnel information.
However, Lakshmikanthan discloses wherein the control circuitry is configured to store virtual local area network (VLAN) or tunnel information and wherein the control circuitry is configured to perform control plane bridging for the CCM PDU based on the VLAN or tunnel information (See Parag. [0008]; a control plane device is configured to implement a control plane of a software defined networking (SDN) network including a plurality of network devices implementing the method for enabling shortest path bridging in a network that is scalable to support sixteen million virtual local area network (VLAN) identifiers using multiprotocol label swapping (MPLS) encapsulation.).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the control circuitry coupled to the packet processor and configured to perform bridging for the CCM PDU, taught by Baheri, to store virtual local area network (VLAN) or tunnel information and wherein the control circuitry is configured to perform control plane bridging for the CCM PDU based on the VLAN or tunnel information, as taught by Lakshmikanthan. This would be convenient to enable scalable implementation of shortest path bridging without hardware changes to network device using media access control (MAC) in multi-protocol label switching encapsulation (Lakshmikanthan, Parag. [0001]).
Claim 10. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 1,
Baheri doesn’t explicitly disclose wherein the packet processor lacks an Ethernet Operations, Administration, and Maintenance (OAM) processor.
However, Lakshmikanthan discloses wherein the packet processor lacks an Ethernet Operations, Administration, and Maintenance (OAM) processor (See Parag. [0008]; The control plane device includes a non-transitory computer-readable medium having stored therein a shortest path bridging label mode (SPBL) module. See Parag. [0029]; Using SPBL the backbone switches/routers will encapsulate customer side Ethernet frames in a multi-protocol label stack (MPLS) label stack for transport across the provider backbone network which is an internet protocol/MPLS network. This isolation follows the SPBM system and allows greater scalability).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the control circuitry coupled to the packet processor and configured to perform bridging for the CCM PDU, taught by Baheri, such that the packet processor lacks an Ethernet Operations, Administration, and Maintenance (OAM) processor, as taught by Lakshmikanthan. This would be convenient to enable scalable implementation of shortest path bridging without hardware changes to network device using media access control (MAC) in multi-protocol label switching encapsulation (Lakshmikanthan, Parag. [0001]).
Claim 11. Baheri in view of Lakshmikanthan discloses [t]he network device defined in claim 1,
Baheri further discloses wherein the packet processor does not support packet trapping on an egress pipeline for the first input-output interface or does not support packet injection on an ingress pipeline for the first input-output interface (See Parag. [0010]; a processing device executing a Virtual Network Function (VNF) includes a network interface and a processor communicatively coupled to one another; and memory storing instructions that, when executed, cause the processor to receive an Operations, Administration, and Maintenance (OAM) Protocol Data Unit (PDU). See Parag. [0048]; The vOAM VNF 150 is deployed as a standalone VM or container and not configured to be a part any service flow. The NOS 120 is configured to classify frames using the frame classification process 160 based on any segment in a frame (like Ether-type, OpCode, etc.). The frame classification process 160 can be a standard packet filter that can be applied in the ingress pipeline of the packet processor of the NOS 120. This helps in classification of the OAM frames 164 at the NOS 120 itself rather than at the vOAM VNF 150 thereby reducing the load at the vOAM VNF 150).
Claims 17 is rejected under 35 U.S.C. 103 as being unpatentable over Baheri et al. (Pub. No. US 2020/0099568), hereinafter Baheri; in view of Meilik et al. (Pub. No. US 2014/0092751), hereinafter Meilik.
Claim 17. Baheri discloses [a] network device comprising:
a first network interface; a second network interface (See Parag. [0008]; a network element includes one or more interfaces connected to a network; a switch configured to switch packets between the one or more interfaces ... See also Parag. [0051]);
data plane processing circuitry comprising an egress pipeline for the second network interface and an ingress pipeline for the first network interface (See Parag. [0010]; a processing device executing a Virtual Network Function (VNF) includes a network interface and a processor communicatively coupled to one another ... See Parag. [0008]; a network element includes one or more interfaces connected to a network; a switch configured to switch packets between the one or more interfaces; and a controller communicatively coupled to the one or more interfaces and the switch, wherein, responsive to receiving an Operations, Administration, and Maintenance (OAM) Protocol Data Unit (PDU) with a destination Media Access Control (MAC) address equal to an interface address of the one or more interfaces, a Maintenance End Point (MEP) is automatically created based on the received OAM PDU and attributes contained in a header of the OAM PDU, the network device is a slave/reactive network device and the MEP is with a master/active network device. See Parag. [0051]; The vOAM VNF 150 uses these logical interfaces for their configurations (MEP creation, etc.) and they help to identify the ingress / egress interfaces for the OAM frame IO (Input/Output)).
control circuitry configured to implement an up maintenance end point (MEP) on the first network interface and configured to generate a continuity check message (CCM) protocol data unit (PDU) originating from the up MEP (See Parag. [0006]; creating a UP MEP if the received interface is different from the interface address and learning an address associated with the OADM PDU. See Parag. [0032]; A UP MEP receives CCMs or PDUs from a switch's bridging function and sends CCMs or PDUs towards the bridging function).
Baheri doesn’t explicitly disclose the control circuitry configured to inject the CCM PDU into the egress pipeline for the second network interface such that the CCM PDU bypasses the ingress pipeline for the first network interface on which the UP MEP is implemented.
However, Meilik discloses inject the CCM PDU into the egress pipeline for the second network interface such that the CCM PDU bypasses the ingress pipeline for the first network interface on which the UP MEP is implemented, wherein the CCM PDU is egressed from the second network interface and is destined for a remote MEP (See Parag. [0015-0016]; Embodiments are directed to improving conventional OAM operations by ensuring OAM packets, such as, for example, Ethernet OAM packets exchanged between MEP down entities (e.g. MEPs protecting a network between two network devices) in a MA, are forwarded using the latest reachability information ... transmitting an OAM packet from a source network device to a destination network device are disclosed. They include generating an OAM protocol data unit (PDU) at the source network device, injecting the OAM PDU in an ingress packet processing pipeline, determining an egress interface of the source network device through which to transmit the OAM PDU to the destination network device, encapsulating the OAM PDU in one or more protocol headers in an egress packet processing pipeline, and transmitting the encapsulated OAM PDU from the egress interface as the OAM packet. The injected OAM PDU is associated with an indication to bypass at least a portion of ingress packet processing. See Parag. [0046]; Network device 500 may include a bypass packet processing block 522. In an exemplary embodiment, upon encountering an indication (e.g. such as a special header in the packet) to bypass further packet processing, a packet in the ingress packet processing pipeline 542 can be processed in bypass packet processing block 522. Bypass packet processing block 522 may either completely bypass any ingress packet processing. In another embodiment, bypass packet processing block may access the forwarding table based upon the pointer to an entry of the forwarding table that is included in the special header of the packet. The packet then enters into egress packet processing. In an exemplary embodiment, an ingress packet from the OAM shim layer 546 or early in the processing of the network layer 548 may enter bypass processing 522. In the same embodiment, after accessing the forwarding table using the pointer included in the special header, the packet is entered into the egress processing pipeline 552 at the OAM shim layer 556 or later stages of egress network layer processing 558. Therefore, one or more layers of ingress and/or egress are bypassed for packets with the mentioned indication).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the control circuitry, taught by Baheri, to include inject the CCM PDU into the egress pipeline for the second network interface such that the CCM PDU bypasses the ingress pipeline for the first network interface on which the UP MEP is implemented, wherein the CCM PDU is egressed from the second network interface and is destined for a remote MEP, as taught by Meilik. This would be convenient to improving conventional OAM operations by ensuring OAM packets, such as, for example, Ethernet OAM packets exchanged between MEP down entities (e.g. MEPs protecting a network between two network devices) in a MA, are forwarded using the latest reachability information (Meilik, Parag. [0015]).
Claims 18-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Baheri et al. (Pub. No. US 2020/0099568), hereinafter Baheri; in view of Meilik et al. (Pub. No. US 2014/0092751), hereinafter Meilik; and further in view of Lakshmikanthan et al. (Pub. No. US 2016/0277291), hereinafter Lakshmikanthan.
Claim 18. Baheri in view of Meilik discloses [t]he network device defined in claim 17,
Baheri in view of Meilik doesn’t explicitly disclose wherein the control circuitry is configured to store VLAN mapping information or tunnel information that identifies the second network interface based on traffic header information and wherein the control circuitry is configured to perform control plane bridging, based on the stored information, to identify the second network interface serving as a peer interface to the up MEP.
However, Lakshmikanthan discloses wherein the control circuitry is configured to store VLAN mapping information or tunnel information that identifies the second network interface based on traffic header information and wherein the control circuitry is configured to perform control plane bridging, based on the stored information, to identify the second network interface serving as a peer interface to the up MEP (See Parag. [0008]; a control plane device is configured to implement a control plane of a software defined networking (SDN) network including a plurality of network devices implementing the method for enabling shortest path bridging in a network that is scalable to support sixteen million virtual local area network (VLAN) identifiers using multiprotocol label swapping (MPLS) encapsulation.).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the control circuitry coupled to the packet processor and configured to perform bridging for the CCM PDU, taught by Baheri in view of Meilik, store VLAN mapping information or tunnel information that identifies the second network interface based on traffic header information and wherein the control circuitry is configured to perform control plane bridging, based on the stored information, to identify the second network interface serving as a peer interface to the up MEP, as taught by Lakshmikanthan. This would be convenient to enable scalable implementation of shortest path bridging without hardware changes to network device using media access control (MAC) in multi-protocol label switching encapsulation (Lakshmikanthan, Parag. [0001]).
Claim 19. Baheri in view of Meilik and Lakshmikanthan discloses [t]he network device defined in claim 18,
Baheri further discloses wherein the control circuitry is configured to inject the CCM PDU into the egress pipeline for the second network device after performing control plane bridging based on the stored information (See Parag. [0010]; a processing device executing a Virtual Network Function (VNF) includes a network interface and a processor communicatively coupled to one another; and memory storing instructions that, when executed, cause the processor to receive an Operations, Administration, and Maintenance (OAM) Protocol Data Unit (PDU). See Parag. [0032]; A UP MEP receives CCMs or PDUs from a switch's bridging function and sends CCMs or PDUs towards the bridging function. See Parag. [0048]; The vOAM VNF 150 is deployed as a standalone VM or container and not configured to be a part any service flow. The NOS 120 is configured to classify frames using the frame classification process 160 based on any segment in a frame (like Ether-type, OpCode, etc.). The frame classification process 160 can be a standard packet filter that can be applied in the ingress pipeline of the packet processor of the NOS 120. This helps in classification of the OAM frames 164 at the NOS 120 itself rather than at the vOAM VNF 150 thereby reducing the load at the vOAM VNF 150).
Claim 21. Baheri in view of Meilik and Lakshmikanthan discloses [t]he network device defined in claim 18,
Baheri in view of Meilik doesn’t explicitly disclose wherein the data plane processing circuitry is configured to implement a data plane of the network device, wherein the control circuitry is configured to implement a control plane of the network device distinct from the data plane, and wherein the control circuitry is configured to perform control plane bridging for the CCM PDU prior to the CCM PDU being injected into the egress pipeline for the second network interface.
However, Lakshmikanthan discloses wherein the data plane processing circuitry is configured to implement a data plane of the network device, wherein the control circuitry is configured to implement a control plane of the network device distinct from the data plane, and wherein the control circuitry is configured to perform control plane bridging for the CCM PDU prior to the CCM PDU being injected into the egress pipeline for the second network interface (See Parag. [0008]; a control plane device is configured to implement a control plane of a software defined networking (SDN) network including a plurality of network devices implementing the method for enabling shortest path bridging in a network that is scalable to support sixteen million virtual local area network (VLAN) identifiers using multiprotocol label swapping (MPLS) encapsulation. See Parag. [0078]; FIG. 6D illustrates that a centralized approach 674 (also known as software defined networking (SDN)) that decouples the system that makes decisions about where traffic is sent from the underlying systems that forwards traffic to the selected destination ... The centralized control plane 676 has a south bound interface 682 with a data plane 680 (sometime referred to the infrastructure layer, network forwarding plane, or forwarding plane (which should not be confused with a ND forwarding plane)) that includes the NEs 670A-H (sometimes referred to as switches, forwarding elements, data plane elements, or nodes). See Parag. [0090]; The centralized control plane 776 transmits relevant messages to the data plane 680 ... The data plane 680 processes these messages and programs the appropriate flow information and corresponding actions in the forwarding tables (sometime referred to as flow tables) of the appropriate NE/VNEs, and then the NEs/VNEs map incoming packets to flows represented in the forwarding tables and forward packets based on the matches in the forwarding tables. See Parag. [0054]; The routing information base 505A can be implemented as match action tables that are utilized for forwarding protocol data units PDUs (i.e. packets)).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the control circuitry coupled to the packet processor and configured to perform bridging for the CCM PDU, taught by Baheri, such that wherein the data plane processing circuitry is configured to implement a data plane of the network device, wherein the control circuitry is configured to implement a control plane of the network device distinct from the data plane, and wherein the control circuitry is configured to perform control plane bridging for the CCM PDU prior to the CCM PDU being injected into the egress pipeline for the second network interface, as taught by Lakshmikanthan. This would be convenient to enable scalable implementation of shortest path bridging without hardware changes to network device using media access control (MAC) in multi-protocol label switching encapsulation (Lakshmikanthan, Parag. [0001]).
Allowable Subject Matter
Claim 4 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is the reason for objecting to claim 4:
With regards to claim 4, Baheri et al. (Pub. No. US 2020/0099568) in view of Lakshmikanthan et al. (Pub. No. US 2016/0277291) fails to fairly teach or suggest “wherein the ingress pipeline is configured to process the CCM PDU by dropping the CCM PDU based on identifying the up MEP as being in a maintenance domain identified in the CCM PDU and being in a same virtual local area network (VLAN) as the second input-output interface.”
In addition, no other prior art of records teaches or suggests the instant claim as a whole.
Claim 5 is objected to because it depends on claim 4.
In interpreting the currently amended claims, in light of the specification, the Examiner finds claims 12-16 to be patentably distinct from the prior art of record.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kamisetty et al. (Pub. No. US 2022/0191061) – Related art in the area related to supporting Spanning Tree Protocol (STP) in networks that use Ethernet Virtual Private Network (EVPN) All-Active (A-A) multihoming, (Abstract; Systems and methods are provided herein for supporting Spanning Tree Protocol (STP) in networks that use Ethernet Virtual Private Network (EVPN) All-Active (A-A) multihoming. This may be accomplished by a network administrator defining a super root group comprising a plurality of network devices, wherein each network device provides A-A multihoming to a multihomed device. All network devices in the super root group use a common bridge ID when generating BPDU messages for STP. All network devices in the super root group will send BPDU messages comprising the common bridge ID to the multihomed device. Because the BPDU messages comprise a common bridge ID, the multihomed device treats the network devices in the super root group as a single local bridge, thus STP is enabled without causing STP flapping.).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/Abdelbasst Talioua/Examiner, Art Unit 2445