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 in response to the Applicant Arguments/REMARKS submitted on 01/15/2026.
Claims 1-12 are pending and rejected.
Response to arguments begins on page 31.
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.
The factual inquiries 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-12 are rejected under 35 U.S.C. 103 as being unpatentable by Yang et al (US 8,953,624B2) in view of Rosen & Rekhter EVPN (RFC4364) BGP/MPLS IP Virtual Private Networks (VPNs) (February 2006) (hereinafter “Rosen”) in further view of Sajassi et al EVPN (RFC7432) BGP MPLS-Based Ethernet VPN (February 2015) (hereinafter “Sajassi”).
Regarding claim 1, Yang teaches a communication method implemented by a route reflector belonging to a computer system implementing a virtual local area switching network to which said route reflector is connected, said computer system further including at least one server in which a multiprotocol label switching virtual proxy and a host are connected, said virtual proxy being connected to the local area network as well as attached to a virtual private communication network, said method including, for the host of each server (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, “the techniques described hereinafter involve distributing host route information of virtual machines to routing bridges…to enable communications”[Wingdings font/0xE0]teaches collecting route reachability from hosts and storing associations; “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine2, and his hot information is then distributed to the other routing bridges in the network 100”[Wingdings font/0xE0]host, proxy notification and route advertisement to centralize reflectors and storing mapping information; “The first RBridge adds a forwarding table attribute…indicates whether or not the first RBridge has routing information associated with the virtual machine[Wingdings font/0xE0]parallels verifying existing mappings, and storing only when new), a set of steps of:
saving an identifier of said private network in association with a hardware address of the host (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, focus on host route advertisement/installation and forwarding attributes; it records host route info and next-hop metadata in RBridge tables; host route installation and attributes, it does show storing host route information associated with the virtual machine and forwarding attributes),
receiving, from the virtual proxy connected to said host, a notification including a hop IP address of the host associated with said hardware address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, provides that messages include mobility attributes and nickname/next hop attributes ties to host route messages; the RBridge receives routing messages with mobility/next hope info from egress RBridges and updates forwarding attributes—this maps to receipt of notifications that contain next-hop/-IP style information),
upon a determination that, before receipt of said notification, one or more other IP addresses have been saved in association with one or more hardware addresses of the hosts by the route reflector, verifying a match between said hop IP address and said one or more other IP addresses (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, FIG 4A/B explicit description of checking forwarding/host tables, adding forwarding attributes, and updating next-hop decisions when new routing messages arrive—i.e., comparing received host/route attributes to installed entries and updating the store if different; shows checking table state and updating which supports verify and then save/update behavior),
upon a determination that the verification of the match between said hop IP address and said one or more other IP addresses is negative, or upon a determination that no other IP address has been saved by the route reflector before the receipt of said notification, saving said hop IP address in association with the hardware address of the host (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, FIG 4A/B explicit description of checking forwarding/host tables, adding forwarding attributes, and updating next-hop decisions when new routing messages arrive—i.e., comparing received host/route attributes to installed entries and updating the store if different; shows checking table state and updating which supports verify and then save/update behavior),
receiving, from the host, an advertisement message including any routes accessible via said hop IP address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, discloses receiving routing messages associated with virtual machines and distributing/installing host routes, including storing associated attributes in forwarding tables), and
saving said advertised routes in association with the identifier of said private network, the hardware address of the host and said hop IP address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, discloses receiving routing messages associated with virtual machines and distributing/installing host routes, including storing associated attributes in forwarding tables).
But Yang fails to teach associating route advertisements with VPN identifiers.
However Rosen teaches associating route advertisements with VPN identifiers (Section 4, 4.1, 4.2, 4.3 pg. 12-15, Route Distinguisher/Route Target – teaching associating route advertisements with VPN identifiers (Route Distinguishers/Route Target) so that routes are saved/installed in the correct VRF/instance).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
But Rosen fails to teach service instance identifiers that tie MAC/IP advertisements to a private network.
But Rosen fails to teach service instance identifiers that tie MAC/IP advertisements to a private network.
However, Sajassi teaches service instance identifiers that tie MAC/IP advertisements to a private network (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, teaches service instance identifiers (Ethernet Tags, Route Distinguishers etc.) that tie MAC/IP advertisements to a tenant/private network; thus the specific teaching of a “private network identifier” associated with route/mac entries is in these RFCs), MAC/IP information and next-hop/gateway information (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, Type-2 (MAC/IP advertisement) and NVE procedures explicitly support advertising MAC + IP information and next-hop/gateway information from the VTEP/NVE to other Pes via BGP; these advertisements contain locators/tunnel-identifiers and next-hop information (so a proxy/VTEP sending a “notification” with hop-IP is taught).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen and Sajassi in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Target (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network, while Sajassi teaches the MAC/IP Advertisement route for advertising host MAC and IP bindings along with next-hop and tunnel endpoint information in an Ethernet VPN.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen and Sajassi into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
Regarding claim 2, Yang teaches the method wherein the computer system includes a server in which a virtual destination proxy, and a destination host are connected, as well as a gateway connected to the local area network, said method further comprising (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies) , before the execution of said set of steps, steps of:
receiving, from said gateway, an advertisement message including a tunnel identifier, as well as any routes accessible, by means of said tunnel identifier and in the private network, via an IP address of said gateway (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies), and
saving said advertised routes in association with the identifier of said private network, said tunnel identifier, and said IP address of the gateway (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies),
said set of steps associated with the destination host also including steps of:
transmitting the tunnel identifier to a virtualization management system belonging to the computer system (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies), and
transmitting to said gateway an advertisement message including any routes accessible, by means of said tunnel identifier and in the private network, via said hop IP address (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies).
But Yang and Rosen fails to teach tunnel identifier, tunnel ID and gateway IP.
However, Sajassi teaches tunnel identifier, tunnel ID and gateway IP (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, uses tunnel identifier/VNI concept that ties a tenant instance to a tunnel (VXLAN VNI); EVPN Type-2/Type 5 routes and operational guidance, also describes advertising remote routes and associating them with tunnel/overlay identifiers and gateway Ips; VTEPs advertise per-tenant routes (and can pass VNI/Tunnel ID infor to orchestration/virtualization management).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen and Sajassi in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network, while Sajassi teaches the MAC/IP Advertisement route for advertising host MAC and IP bindings along with next-hop and tunnel endpoint information in an Ethernet VPN.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen and Sajassi into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
Regarding claim 3, Yang teaches the method wherein the computer system includes a server in which a virtual source proxy and a source host are connected, as well as a gateway connected to the local area network, said method further including, before the execution of said set of steps (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies), steps of:
receiving, from said gateway, an advertisement message including a tunnel identifier, as well as any routes accessible, by means of said tunnel identifier and in the private network, via an IP address of said gateway (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies), and
saving said advertised routes in association with the identifier of said private network, said tunnel identifier, and said IP address of the gateway (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies),
said set of steps associated with the source host also including steps of:
transmitting the tunnel identifier to a virtualization management system belonging to the computer system (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies),
transmitting to the source host an advertisement message including any routes accessible, in the private network, via the IP address of the gateway (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies).
Regarding claim 4, Yang teaches the method wherein the computer system includes a first server in which a virtual source proxy and a source host are connected, as well as a second server in which a virtual destination proxy called and a destination host are connected, said source and destination proxies being attached to the same virtual private communication network, said method including an execution of said set of steps for each of the hosts of said servers and, after said set of steps has been executed for the destination host, a step of transmitting to the source host an advertisement message including any routes accessible via the hop IP address of the destination host (col 4 lines 8-67, “TRILL-EVPN…connect TRILL data centers…over MPLS/IP provider networks”[Wingdings font/0xE0]discloses use of overlay tunnels and identifiers analogous to VPN identifiers via tunnel constructs; “Border leaf RBridges…referred to as ‘provider edge devices’ or ‘PEs’”[Wingdings font/0xE0]corresponds to gateway nodes advertising route/tunnel information to edge proxies).
But Yang and Rosen fail to teach after executing steps for destination host, transmit to source host advertisement for routes via destination host hop IP (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, uses tunnel identifier/VNI concept that ties a tenant instance to a tunnel (VXLAN VNI); EVPN Type-2/Type 5 routes and operational guidance, also describes advertising remote routes and associating them with tunnel/overlay identifiers and gateway Ips; VTEPs advertise per-tenant routes (and can pass VNI/Tunnel ID infor to orchestration/virtualization management).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen and Sajassi in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network, while Sajassi teaches the MAC/IP Advertisement route for advertising host MAC and IP bindings along with next-hop and tunnel endpoint information in an Ethernet VPN.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen and Sajassi into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
Regarding claim 5, Yang teaches a communication method implemented by a host belonging to a computer system implementing a virtual local area switching network, said computer system further including a route reflector connected to said local area network, and a server in which a multiprotocol label switching virtual proxy and said host are connected (col 10 lines 3-50, “The routing message is associated with a virtual machine in the network…set by an egress RBridge” [Wingdings font/0xE0] indicates host-originated routing messages conveying reachability, mapping to host notifications; the process of host-driven injection of route information to the network edge parallels your host, proxy, reflector flow), said virtual proxy being connected to the local area network as well attached to a virtual private communication network, said method including steps of:
freely transmitting to the virtual proxy a notification including a hardware address of the host as well as a hop IP address of the host associated with said hardware address,
transmitting to the route reflector an advertisement message including any routes accessible via said hop IP address (col 10 lines 3-50, “The routing message is associated with a virtual machine in the network…set by an egress RBridge” [Wingdings font/0xE0] indicates host-originated routing messages conveying reachability, mapping to host notifications; the process of host-driven injection of route information to the network edge parallels your host, proxy, reflector flow).
But Yang and Rosen fails to teach notification including hardware address of the host as well as a hope IP address of the host.
However, Sajassi teaches notification including hardware address of the host as well as a hope IP address of the host (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, uses tunnel identifier/VNI concept that ties a tenant instance to a tunnel (VXLAN VNI); EVPN Type-2/Type 5 routes and operational guidance, also describes advertising remote routes and associating them with tunnel/overlay identifiers and gateway Ips; VTEPs advertise per-tenant routes (and can pass VNI/Tunnel ID infor to orchestration/virtualization management).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen and Sajassi in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network, while Sajassi teaches the MAC/IP Advertisement route for advertising host MAC and IP bindings along with next-hop and tunnel endpoint information in an Ethernet VPN.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen and Sajassi into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
Regarding claim 6, Yang teaches the method wherein the computer system includes a server in which a virtual source proxy and a source host are connected, as well as a gateway connected to the local area network, said method being implemented by said source host and further including a step of receiving, from the route reflector, an advertisement message including any routes accessible, in the private network, via the IP address of the gateway (col 10 lines 3-50, “The routing message is associated with a virtual machine in the network…set by an egress RBridge” [Wingdings font/0xE0] indicates host-originated routing messages conveying reachability, mapping to host notifications; the process of host-driven injection of route information to the network edge parallels your host, proxy, reflector flow).
But Yang and Rosen fail to teach receiving an advertisement from the route reflector and routing message does not include IP address of the gateway.
However, Sajassi teaches receiving an advertisement from the route reflector and routing message does not include IP address of the gateway (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, uses tunnel identifier/VNI concept that ties a tenant instance to a tunnel (VXLAN VNI); EVPN Type-2/Type 5 routes and operational guidance, also describes advertising remote routes and associating them with tunnel/overlay identifiers and gateway Ips; VTEPs advertise per-tenant routes (and can pass VNI/Tunnel ID infor to orchestration/virtualization management).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen and Sajassi in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network, while Sajassi teaches the MAC/IP Advertisement route for advertising host MAC and IP bindings along with next-hop and tunnel endpoint information in an Ethernet VPN.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen and Sajassi into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
Regarding claim 7, Yang teaches the method wherein the computer system includes a first server in which a virtual source proxy and a source host are connected, as well as a second server in which a virtual destination proxy and a destination host are connected, said source and destination proxies being attached to the same virtual private communication network, said method being implemented by said source host and including a step of receiving, from the route reflector, an advertisement message including any routes accessible via the hop IP address of the destination host (col 10 lines 3-50, “The routing message is associated with a virtual machine in the network…set by an egress RBridge” [Wingdings font/0xE0] indicates host-originated routing messages conveying reachability, mapping to host notifications; the process of host-driven injection of route information to the network edge parallels your host, proxy, reflector flow).
But Yang and Rosen fail to teach receiving an advertisement from the route reflector and routing message does not include IP address of the gateway.
However, Sajassi teaches receiving an advertisement from the route reflector and routing message does not include IP address of the gateway (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, uses tunnel identifier/VNI concept that ties a tenant instance to a tunnel (VXLAN VNI); EVPN Type-2/Type 5 routes and operational guidance, also describes advertising remote routes and associating them with tunnel/overlay identifiers and gateway Ips; VTEPs advertise per-tenant routes (and can pass VNI/Tunnel ID infor to orchestration/virtualization management).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen and Sajassi in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network, while Sajassi teaches the MAC/IP Advertisement route for advertising host MAC and IP bindings along with next-hop and tunnel endpoint information in an Ethernet VPN.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen and Sajassi into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
Regarding claim 8, Yang teaches a non-transitory computer readable storage medium having stored thereon instructions which, when executed by a processor, cause the processor to implement the method of claim 1 (col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods).
Regarding claim 9, Yang teaches a non-transitory computer-readable recording medium having stored thereon instructions which, when executed by a processor, cause the processor to implement the method of claim 5 (col 12 lines 25- 58, col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods) “An apparatus comprising: a plurality of ports, a memory; and a processor…configured to receive a routing message associated with a virtual machine…add a forwarding table attribute…distribute the routing message.” Functions as the route reflector and host-configured device claims).
Regarding claim 10, Yang teaches a route reflector comprising a processor and a memory, the route reflector belonging to a computer system implementing a virtual local area switching network to which said route reflector is connected, said computer system further including at least one server in which a multiprotocol label switching virtual proxy and a host are connected, said virtual proxy being connected to the local area network as well as attached to a virtual private communication network (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, col 12 lines 25- 58, col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods) “An apparatus comprising: a plurality of ports, a memory; and a processor…configured to receive a routing message associated with a virtual machine…add a forwarding table attribute…distribute the routing message.” Functions as the route reflector and host-configured device claims; “the techniques described hereinafter involve distributing host route information of virtual machines to routing bridges…to enable communications”[Wingdings font/0xE0]teaches collecting route reachability from hosts and storing associations; “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine2, and his hot information is then distributed to the other routing bridges in the network 100”[Wingdings font/0xE0]host, proxy notification and route advertisement to centralize reflectors and storing mapping information; “The first RBridge adds a forwarding table attribute…indicates whether or not the first RBridge has routing information associated with the virtual machine[Wingdings font/0xE0]parallels verifying existing mappings, and storing only when new) , said route reflector configured to, for the host of each server:
save an identifier of said private network in association with a hardware address of the host (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, focus on host route advertisement/installation and forwarding attributes; it records host route info and next-hop metadata in RBridge tables; host route installation and attributes, it does show storing host route information associated with the virtual machine and forwarding attributes),
receive, from the virtual proxy connected to said host, a notification including a hop IP address of the host associated with said hardware address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, provides that messages include mobility attributes and nickname/next hop attributes ties to host route messages; the RBridge receives routing messages with mobility/next hope info from egress RBridges and updates forwarding attributes—this maps to receipt of notifications that contain next-hop/-IP style information),
upon a determination that, before receipt of said notification, one or more other IP addresses have been saved in association with one or more hardware addresses of the hosts by the route reflector, verify a match between said hop IP address and said one or more other IP addresses (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, FIG 4A/B explicit description of checking forwarding/host tables, adding forwarding attributes, and updating next-hop decisions when new routing messages arrive—i.e., comparing received host/route attributes to installed entries and updating the store if different; shows checking table state and updating which supports verify and then save/update behavior),
upon a determination that the verification of the match between said hop IP address and said one or more other IP addresses is negative, or upon a determination that no other IP address has been saved by the route reflector before the receipt of said notification, save said hop IP address in association with the hardware address of the host (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, FIG 4A/B explicit description of checking forwarding/host tables, adding forwarding attributes, and updating next-hop decisions when new routing messages arrive—i.e., comparing received host/route attributes to installed entries and updating the store if different; shows checking table state and updating which supports verify and then save/update behavior),
receive, from the host, an advertisement message including any routes accessible via said hop IP address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, discloses receiving routing messages associated with virtual machines and distributing/installing host routes, including storing associated attributes in forwarding tables)), and
save said advertised routes in association with the identifier of said private network, the hardware address of the host, and said hop IP address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, discloses receiving routing messages associated with virtual machines and distributing/installing host routes, including storing associated attributes in forwarding tables).
But Yang fails to teach associating route advertisements with VPN identifiers.
However Rosen teaches associating route advertisements with VPN identifiers (Section 4, 4.1, 4.2, 4.3 pg. 12-15, Route Distinguisher/Route Target – teaching associating route advertisements with VPN identifiers (Route Distinguishers/Route Target) so that routes are saved/installed in the correct VRF/instance).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
But Rosen fails to teach service instance identifiers that tie MAC/IP advertisements to a private network.
However, Sajassi teaches service instance identifiers that tie MAC/IP advertisements to a private network (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, teaches service instance identifiers (Ethernet Tags, Route Distinguishers etc.) that tie MAC/IP advertisements to a tenant/private network; thus the specific teaching of a “private network identifier” associated with route/mac entries is in these RFCs), MAC/IP information and next-hop/gateway information (Section 6, 6.1-6.3 pg. 10-12, Section 7 pg. 13-15, Type-2 (MAC/IP advertisement) and NVE procedures explicitly support advertising MAC + IP information and next-hop/gateway information from the VTEP/NVE to other Pes via BGP; these advertisements contain locators/tunnel-identifiers and next-hop information (so a proxy/VTEP sending a “notification” with hop-IP is taught).
It would have been obvious to a POSITA to modify the route distribution mechanism of Yang with Rosen and BGP/MPLS VPN and control plane teachings of Rosen and Sajassi in order to provide the claimed features of associating a private network identifier, tunnel identifier, and hop-IP with host route advertisements. Yang teaches a route-reflector-like RBridge that receives host route notifications from virtual machines or proxies, compares them with existing entries, and updates forwarding attributes as needed before redistributing the routes. Rosen teaches associating route advertisements with a Route Distinguisher (RD) and Route Targret (RT) to uniquely identify and segregate per-customer VPN routes in a multi-tenant network, while Sajassi teaches the MAC/IP Advertisement route for advertising host MAC and IP bindings along with next-hop and tunnel endpoint information in an Ethernet VPN.
A POSITA, familiar with both a Yang’s RBridge host-route propagation and the BGP/MPLS VPN and EVPN for scalable multi-tenant data center interconnects, would have been motivated to incorporate the RD/RT and MAC/IP advertisement formats of Rosen and Sajassi into Yang’s system to enable interoperable per-VPN host post route distribution, to leverage existing BGP control-plane mechanisms, and to advertise tunnel/gateway identifiers for endpoint reachability. Such a combination would have been predictable use of prior-art elements according to their established functions—Yang’s mechanism for receiving, verifying and installing host route updates, and EVPN/L3VPN’s mechanism for associating those updates with VPN context and tunnel identifiers—yielding the claimed invention with a reasonable expectation of success and without any change to the principles of operation of either reference.
Regarding claim 11, Yang teaches a host comprising a processor and a memory, the host belonging to a computer system implementing a virtual local area switching network, said computer system further including a route reflector connected to said local area network, and a server in which a multiprotocol label switching virtual proxy and said host are connected, said virtual proxy being connected to the local area network as well attached to a virtual private communication network, said host being configured to:
freely transmit to the virtual proxy a notification including a hardware address of the host as well as a hop IP address of the host associated with said hardware address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, col 12 lines 25- 58, col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods) “An apparatus comprising: a plurality of ports, a memory; and a processor…configured to receive a routing message associated with a virtual machine…add a forwarding table attribute…distribute the routing message.” Functions as the route reflector and host-configured device claims; “the techniques described hereinafter involve distributing host route information of virtual machines to routing bridges…to enable communications”[Wingdings font/0xE0]teaches collecting route reachability from hosts and storing associations; “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine2, and his hot information is then distributed to the other routing bridges in the network 100”[Wingdings font/0xE0]host, proxy notification and route advertisement to centralize reflectors and storing mapping information; “The first RBridge adds a forwarding table attribute…indicates whether or not the first RBridge has routing information associated with the virtual machine[Wingdings font/0xE0]parallels verifying existing mappings, and storing only when new),
transmit to the route reflector an advertisement message including any routes accessible via said hop IP address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, col 12 lines 25- 58, col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods) “An apparatus comprising: a plurality of ports, a memory; and a processor…configured to receive a routing message associated with a virtual machine…add a forwarding table attribute…distribute the routing message.” Functions as the route reflector and host-configured device claims; “the techniques described hereinafter involve distributing host route information of virtual machines to routing bridges…to enable communications”[Wingdings font/0xE0]teaches collecting route reachability from hosts and storing associations; “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine2, and his hot information is then distributed to the other routing bridges in the network 100”[Wingdings font/0xE0]host, proxy notification and route advertisement to centralize reflectors and storing mapping information; “The first RBridge adds a forwarding table attribute…indicates whether or not the first RBridge has routing information associated with the virtual machine[Wingdings font/0xE0]parallels verifying existing mappings, and storing only when new).
Regarding claim 12, Yang teaches a computer system including:
the route reflector of claim 10 (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, col 12 lines 25- 58, col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods) “An apparatus comprising: a plurality of ports, a memory; and a processor…configured to receive a routing message associated with a virtual machine…add a forwarding table attribute…distribute the routing message.” Functions as the route reflector and host-configured device claims; “the techniques described hereinafter involve distributing host route information of virtual machines to routing bridges…to enable communications”[Wingdings font/0xE0]teaches collecting route reachability from hosts and storing associations; “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine2, and his hot information is then distributed to the other routing bridges in the network 100”[Wingdings font/0xE0]host, proxy notification and route advertisement to centralize reflectors and storing mapping information; “The first RBridge adds a forwarding table attribute…indicates whether or not the first RBridge has routing information associated with the virtual machine[Wingdings font/0xE0]parallels verifying existing mappings, and storing only when new); and
at least one server comprising: a multiprotocol label switching virtual proxy; and a host connected to the virtual proxy, the host being comprising a processor and a memory, the host being configured to:
freely transmit to the virtual proxy a notification including a hardware address of the host as well as the hop IP address of the host associated with said hardware address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, col 12 lines 25- 58, col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods) “An apparatus comprising: a plurality of ports, a memory; and a processor…configured to receive a routing message associated with a virtual machine…add a forwarding table attribute…distribute the routing message.” Functions as the route reflector and host-configured device claims; “the techniques described hereinafter involve distributing host route information of virtual machines to routing bridges…to enable communications”[Wingdings font/0xE0]teaches collecting route reachability from hosts and storing associations; “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine2, and his hot information is then distributed to the other routing bridges in the network 100”[Wingdings font/0xE0]host, proxy notification and route advertisement to centralize reflectors and storing mapping information; “The first RBridge adds a forwarding table attribute…indicates whether or not the first RBridge has routing information associated with the virtual machine[Wingdings font/0xE0]parallels verifying existing mappings, and storing only when new),
transmitting to the route reflector said advertisement message including any routes accessible via said hop IP address (col 2 lines 28-45, col 4 lines 41-67, col 10 lines 30-50, col 12 lines 25- 58, col 12 lines 25- 58, “a computer readable storage media is provided that is encoded with software comprising computer executable instructions…when the software is executed operable to…receive…add…attribute…forward the routing message.”; embodies non-transitory media storing logic to implement the distribution and mapping methods) “An apparatus comprising: a plurality of ports, a memory; and a processor…configured to receive a routing message associated with a virtual machine…add a forwarding table attribute…distribute the routing message.” Functions as the route reflector and host-configured device claims; “the techniques described hereinafter involve distributing host route information of virtual machines to routing bridges…to enable communications”[Wingdings font/0xE0]teaches collecting route reachability from hosts and storing associations; “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine2, and his hot information is then distributed to the other routing bridges in the network 100”[Wingdings font/0xE0]host, proxy notification and route advertisement to centralize reflectors and storing mapping information; “The first RBridge adds a forwarding table attribute…indicates whether or not the first RBridge has routing information associated with the virtual machine[Wingdings font/0xE0]parallels verifying existing mappings, and storing only when new).
Response to Arguments
First, Applicant’s arguments, see Applicant Arguments/REMARKS, filed 01/15/2026, with respect to 35 USC 112(b) and 35 USC 101 have been fully considered and are persuasive. The rejections of claims 10-12 has been withdrawn.
Second, Applicant's arguments for 35 USC 103 filed 01/15/2026 have been fully considered but they are not persuasive.
Applicant’s arguments have been considered but are not persuasive. Applicant arguments that Yang’s “route reflector” is merely a classic BGP route reflector that only reflects routes among TRILL RBridges, whereas the presently claimed route reflector is a distinct entity that receives notifications from hosts/proxies, verifies IP-addresses associations, and stores VPN-ID/MAC/hop-IP associations. This argument is not persuasive because it rests on an unduly narrow interpretation of “route reflector”.
Under the broadest reasonable interpretation, in light of applicant’s own specification, the claimed “route reflector” is not limited to a conventional passive BGP reflector. Rather, Applicant’s specification expressly describes the route reflector as a computer-based network entity connected to the VLAN local area network and configured to: save the identifier VPN-ID of the private VPN network in association with the hardware address of a host; receive, from a proxy connected to a host, a notification including the host’s hop address associated with the host hardware address; verify…, save…, receive…, and save those advertised routes in association with the VPN identifier, hardware address, and hop address ([0015], [0031], [0035], [0038], [0042], [0045]).
Thus, Applicant’s own disclosure uses “route reflector” to denote an enhanced control-plane route-processing entity, not merely a conventional BGP relay. The specification further states that the route reflector has “the hardware architecture of a computer,” communicates with hosts, proxies, and other system entities through a communication module, and stores the learned data in memory (Applicant Spec [0047]-[0050]). Accordingly, the claim term “route reflector” is reasonably broad enough to encompass a route-distribution/control-plane node performing the recited learning, verification, and storage functions.
Applicant’s argument that Yang’s cited disclosures are operations of RBridges rather than route reflector also is not persuasive. The rejection does not rely on Yang alone to disclose every recited function performed by the exact same named node. Rather, Yang is relied on for teaching the host-route distribution architecture, the use of BGP route reflectors in that architecture, and the route-processing functions that would have suggested the claim arrangement when combined with the additional cited art.
Yang expressly teaches that “data center 1 and data center 2 each has a BGP route reflector,” and that “RR1 and RR2 peer with all the leaf RBridges in their corresponding data centers.” Yang further teaches that “routing information (e.g. host routes of the virtual machines) may be distributed within the network 100 using the BGP protocol via the route reflectors 110(1) and 110(2).” Thus, Yang places the route reflector in the control plane path for distribution of host-route information in the data-center environment. Yang is not limited to merely mentioning a route reflector in passing; rather, it teaches a BGP route-reflector-based architecture for host-route distribution.
Yang also teaches the core-host-route processing relied upon in the rejection. Yang explains that “the host route information of virtual machine 2 may originate from the routing bridge that manages the server hosting virtual machine 2, and this host route information is then distributed to the other routing bridges in the network 100.” Yan further teaches receipt of routing messages associated with a virtual machine, use of mobility and nickname attributes, selective retention or updating of next-hop information, and addition of a forwarding table attribute indicating whether the receiving RBridge already has routing information associated with the virtual machine in its forwarding table. Yang thus teaches receipt of host-related reachability information, evaluation of existing stored routing/forwarding information, and selective dissemination of next-hop-associated routing information.
Applicant contends that Yang lacks the claimed “server in which a multiprotocol label switching virtual proxy and host are connected.” However, this argument does not overcome the rejection because the rejection is based on the combination of Yang with Rosen and Sajassi. Under the broadest reasonable interpretation, Applicant’s own specification describes the proxy functionally as a server-side MPLS-connected intermediary associated with the host and the local area network (Applicant Spec [0024], [0027], [0030]). Yang teaches server hosting virtual machine in a data-center topology, with lead RBridges managing communications for those servers, and further teaches a TRILL-EVPN provider network over MPLS/IP. Rosen and Sajassi supply the well-known MPLS VPN/EVPN control-plane mechanisms that complete the claimed arrangement.
Rosen teaches a BGP/MPLS IP VPN architecture in which customer routes are learned at the edge and distributed using BGP among provider devices attached to the relevant VPN. Rosen staes that “the customer’s edge routes (CE routers) send their routes to the Service Provider’s edge routers (PE routers)” and that “BGP is then used by the Service Provider to exchange the routes of a particular VPN is assigned an MPLS label and that VPN separation is maintained through VPN-specific route identification and distribution mechanisms.
Rosen further teaches that the VPN-IPv4 address family uses a Route Distinguisher (RD), and that Route Targets are used to control route distribution to the proper VPN context. Rosen explains that “a VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4 address,” and that the purpose of the RD is to permit distinct routes to common IPv4 prefixes in different VPNs. These teachings provide the claimed association of routing information with a private-network identifier.
Applicant argues that Rosen’s Route Distinguishers and Route Targets are PE mechanisms, not route-reflector functions. This argument is not persuasive. Rosen expressly teaches use of route reflectors in MPLS/BGP VPN systems and explains that route reflectors may maintain and process VPN route information based on Route Targets. Thus, Rosen shwos that route reflectors in VPN architectures were known to maintain and distribute VPN-associated route state, not merely reflect routes blindly. That teaching directly supports the rejection’s reliance on a route reflector/control plane node that stores and distributes route information in association with VPN-specific identifiers.
Sajassi likewise teaches the missing MAC/IP association aspects. Sajassi teaches that in EVPN, “MAC learning between Pes occurs not in the data plane…but in the control plane,” and that “Pes advertise the MAC addresses learned from the CEs that are connected to them, along with an MPLS label, to other PEs in the control plane using Multiprotocol BGP (MP-BGP).” Sajassi further defines the Type-2 “MAC/IP Advertisement route” as including an RD, an Ethernet Segment Identifier, an Ethernet Tag ID, a MAC Address, an IP Address, and MPLS label information. Thus, Sajassi teaches control-plane advertisement and storage of MAC/IP bindings in an MPLS/BGP EVPN environment.
Applicant contends that Sajassi’s Ethernet Tag ID is not the claimed private-network identifier. This argument is not persuasive under the claim language as broadly but reasonably interpreted. The claim recites “saving an identifier of said private network,” but does not narrowly require any particular format or field. Sajassi teaches that “an Ethernet Tag ID…identifies a particular broadcast domain (e.g. VLAN) in an EVPN instance,” and also teaches that an EVPN instance requires an RD and one or more Route Targets. Rosen likewise teaches VPN-identifying route attributes. Together, Rosen and Sajassi teach use of control-plane identifiers to segregate and associate reachability information with given VPN/EVPN instance, which reasonably meets or at least renders obvious the claimed private-network identifier.
Applicant also argues that the proposed combination would improperly change Yang’s route reflector from a passive RR into an active host-connected control entity. This argument is not persuasive because the combination does not change Yang’s principle of operation. Yang already teaches a BGP route reflector-based host-route distribution architecture in a data-center environment. Rosen and Sajassi merely provide known MPLS VPN/EVPN control-plane refinements—namely, associating route information with VPN identifiers and advertising MAC/IP reachability architecture would have been a predictable use of familiar elements according to their established functions.
Applicant’s argument that none of the references disclose “receiving, from a proxy, a notification containing a hop-IP associated with a hardware address” also is unpersuasive when the references are considered together and in view of Applicant’s own broad disclosure. Applicant’s specification shows that the claimed proxy is a functional intermediary associated with the host and the local network, not a narrowly defined structure (Applicant Spec [0024], [0027], [0030]). Sajassi teaches control-plane learning and advertisement of MAC/IP bindings learned from attached CEs, and Yang teaches server/VM host-route origination and next-hop-based route propagation. The combination would have suggested receipt at the receipt at the route-distribution/control-plane node of host MAC/IP reachability information relayed from the relevant attached intermediary or edge entity.
In conclusion, Applicant’s arguments improperly attack Yang in isolation and apply an unduly narrow interpretation of route reflector.” Yang teaches the data-center and VM host-route distribution architecture using BGP route reflectors and next-hop-aware host-route propagation. Rosen teaches VPN route distribution, VPN-identifying route attributes, and route-reflector participation in MPLS/BGP VPN control-plane operation. Sajassi teaches EVPN control-plane learning and advertisement of MAC/IP bindings together with EVPN-instance-identifying information. Applicant’s own specification confirms that the claimed route reflector is broadly enhanced control-plane computer that stores VPN-associated host MC/IP route information (Applicant Spec [0015], [0031], [0035], [0047]-[0050]).
Accordingly, it would have been obvious to one of ordinary skill in the art to implement Yang’s route-distribution architecture using the known VPN/EVPN identification and MAC/IP advertisement mechanisms of Rosen and Sajassi so that the route reflector/control-plane node stores host reachability in association with the relevant private-network identifier, hardware address, and hop IP address, as claimed. Therefore, Applicant has not shown reversible error in the rejection, and the rejection is maintained.
Conclusion
THIS ACTION IS MADE FINAL. 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 MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 EST.
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, Nishant Divecha can be reached at (571) 270-3125. 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.
/MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights