DETAILED ACTION
This action is responsive to claims filed on 1/8/2026.
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 .
Response to Amendment
Claims 1-13 were pending for examination in previous Office Action mailed 7/29/2025.
Claims 1-13 remain pending for examination with claims 1 and 5 being independent.
Acknowledgement is made of applicant’s amendments to the drawings received on 12/29/2025 in order to overcome objections in prior Office Action. These amendments are acceptable and objections listed in previous Office Action to drawings have been withdrawn.
Acknowledgement is made of applicant’s remarks regarding the specification received on 1/8/2026 in order to overcome objections in prior Office Action. Specification has been reviewed and objections listed in previous Office Action to the specification have been withdrawn.
Response to Arguments
Applicant’s arguments, see Applicant’s remarks pg. 6-14, filed 1/8/2026, with respect to Claims 1 and 5 have been fully considered but are not persuasive.
Applicant’s arguments rely on language solely recited in preamble recitations in claim 1 and 5. When reading the preamble in the context of the entire claim, the recitation of a multiprotocol label switching (MPLS) environment, is not limiting because the body of the claim describes a complete invention and the language recited solely in the preamble does not provide any distinct definition of any of the claimed invention’s limitations. Thus, the preamble of the claim(s) is not considered a limitation and is of no significance to claim construction. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165 (Fed. Cir. 1999). See MPEP § 2111.02.
Further, in response to Applicant’s arguments that in substance the prior art of record does not disclose MPLS or label-based switching mechanism, any virtualization management system sending a configuration request to establish a virtual interface, or the association of a host hardware address with a tunnel identifier as well as exchange of address-resolution requests between source host and destination proxy. Examiner respectfully disagrees.
Here, Chu et al. (US 2017/0250912 A1; hereinafter Chu) in combination with Sivaraj et al. (US 2017/0195220; hereinafter Sivaraj) was relied upon to disclose previously presented independent Claims 1 and 5.
As provided in the previous office action Chu discloses the following:
[0004] Various tunnel endpoints within the overlay network, such as Virtual Tunnel Endpoints (VTEPs), can terminate overlay network packets by encapsulating and de-encapsulating packets through MAC-to-UDP encapsulation. Each tunnel endpoint may be provided with a unique IP/MAC address pair to make the encapsulation and routing encapsulated packets within the overlay network possible. In an overlay network such as a VXLAN network or Network Virtualization using Generic Routing Encapsulation (NVGRE), the associations between host addresses and tunnel endpoints are typically created by a central controller and those mappings are distributed to all the tunnel endpoints in the overlay network.
[0005] In environments such as large-scale data centers, the database storing these mappings can grow very large and consume a large amount of storage resources at individual tunnel endpoints all across the network. Besides the storage requirements, any change in this database would then need to be distributed from the central controller and processed at every tunnel endpoint. Thus, the amount of storage and processing required to maintain a central routing table imposes a significant constraint to the number of hosts an overlay network can support. In addition, this requirement makes it more difficult to implement overlay processing in hardware to improve traffic throughput because of the silicon area limitation. Having one single central server may also mean that there exists a single point of failure, which tends to increase security risks.
[0024] Network segments, such as physical or virtual segments; networks; devices; ports; physical or logical links; and/or traffic in general can be grouped into a bridge or flood domain. A bridge domain or flood domain can represent a broadcast domain, such as an L2 broadcast domain. A bridge domain or flood domain can include a single subnet, but can also include multiple subnets. Moreover, a bridge domain can be associated with a bridge domain interface on a network device, such as a switch. A bridge domain interface can be a logical interface which supports traffic between an L2 bridged network and an L3 routed network. In addition, a bridge domain interface can support internet protocol (IP) termination, VPN termination, address resolution handling, MAC addressing, etc. Both bridge domains and bridge domain interfaces can be identified by a same index or identifier.
[0053] FIG. 4 illustrates an example overlay network 400. Overlay network 400 uses an overlay protocol, such as VXLAN, NVGRE, VO3, or STT, to encapsulate traffic in L2 and/or L3 packets which can cross overlay L3 boundaries in the network. As illustrated in FIG. 4, overlay network 400 can include hosts 406A-D interconnected via network 402.
[0054] Network 402 can include a packet network, such as an IP network, for example. Moreover, network 402 can connect the overlay network 400 with the fabric 312 in FIG. 3. For example, VTEPs 408A-D can connect with the leaf switches 304 in the fabric 312 via network 402.
[0055] Hosts 406A-D include virtual tunnel end points (VTEP) 408A-D, which can be virtual nodes or switches configured to encapsulate and de-encapsulate data traffic according to a specific overlay protocol of the network 400, for the various virtual network identifiers (VNIDs) 410A-I. Each host 406A-D can be a Virtual Ethernet Module (VEM) that is assigned at least one IP address used as the source IP address when the encapsulated MAC frames are sent to other VEMs over the network. Moreover, hosts 406A-D can include servers containing a VTEP functionality, hypervisors, and physical switches, such as L3 switches, configured with a VTEP functionality. For example, hosts 406A and 406B can be physical switches configured to run VTEPs 408A-B. Here, hosts 406A and 406B can be connected to servers 404A-D, which, in some cases, can include virtual workloads through VMs loaded on the servers, for example.
[0056] In some embodiments, network 400 can be a VXLAN network, and VTEPs 408A-D can be VXLAN tunnel end points. However, as one of ordinary skill in the art will readily recognize, network 400 can represent any type of overlay or software-defined network, such as NVGRE, STT, or even overlay technologies yet to be invented.
[0060] VTEPs 408A-D can encapsulate packets directed at the various VNIDs 1-3 in the overlay network 400 according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s). Moreover, when a switch, router, or other network device receives a packet to be transmitted to a recipient in the overlay network 400, it can analyze a routing table, also known as a lookup table or an encapsulation table, to determine where such packet needs to be transmitted so the traffic reaches the appropriate recipient. For example, if VTEP 408A receives a packet from endpoint 404B that is intended for endpoint 404H, VTEP 408A can analyze a routing table that maps the intended endpoint, endpoint 404H, to a specific switch that is configured to handle communications intended for endpoint 404H. VTEP 408A might not initially know, when it receives the packet from endpoint 404B, that such packet should be transmitted to VTEP 408D in order to reach endpoint 404H. Accordingly, by analyzing the routing table, VTEP 408A can lookup endpoint 404H, which is the intended recipient, and determine that the packet should be transmitted to VTEP 408D, as specified in the routing table based on endpoint-to-switch mappings or bindings, so the packet can be transmitted to, and received by, endpoint 404H as expected.
[0077] In this example, host 404B originates a packet that is destined for host 404G (614A) and forwards the packet to tunnel endpoint 408A (614B). In order for tunnel endpoint 408A encapsulate the received packet and to forward the encapsulated packet to its intended recipient, tunnel endpoint 408A may extract the host destination address from the packet and look up the address in its own encapsulation table (not shown). If a match is found for destination host address 55:55:55:55:55:55, tunnel endpoint 408A may use the encapsulation information (i.e., IP address 10.1.1.3) from its encapsulation table to encapsulate and forward the packet. If, however, the host address is not found in the encapsulation table, tunnel endpoint 408A can perform one of three possible operations depending on the operating mode of overlay network 600. The first operation is to consult a central controller (not shown) and populate the appropriate entry in its encapsulation table. The second option is to encapsulate the packet and send the encapsulated packet to a proxy tunnel endpoint (not shown) that may hold the full host database. The final option is to flood overlay network 600 by broadcasting the encapsulated packet to every tunnel endpoint in overlay network 600, as will be discussed in greater detail below.
Sivaraj discloses the following:
[0011] A network device (e.g., a provider edge network device, such as a gateway network device or the like) may be connected to a network, which includes a set of other network devices. The gateway network device may receive route information from another network device (e.g., a provider edge network device, such as a Top of Rack (ToR) switch network device or the like). For example, the ToR switch network device may determine a media access control (MAC) address and a corresponding MAC route (e.g., reachability information, such as network layer reachability information (NLRI)), and may advertise the route information to the gateway network device via a layer 2 (L2) route message to cause the gateway network device to route the network traffic from a first segment of a virtual extensible local area network (VXLAN) to a second segment of the VXLAN. The route information may include information identifying the MAC route. Layer 2 may refer to a layer of the Open Systems Interconnection (OSI) model. The MAC route information may be associated with layer 3 (L3) Internet protocol (IP) address information for the VXLAN. However, the ToR switch network device may lack sufficient computing resources to determine and include IP/MAC binding information in the route information. The IP/MAC binding information, sometimes referred to as MAC-to-IP binding information, may include information that identifies particular IP address information corresponding to particular MAC route information.
[0012] The network device may utilize an address resolution protocol (ARP) message to determine the IP/MAC binding for a received MAC route when network traffic is received at the network. For example, when network traffic is received at the network, the ToR switch network device may advertise a particular MAC route for the network traffic to the gateway network device, and the gateway network device may transmit an ARP message. The gateway network device may receive a response to the ARP message associated with identifying an IP/MAC binding for the MAC route.
[0013] However, when the network includes multiple gateway network devices (e.g., redundant gateway network devices), each gateway network device may be required to transmit an ARP message and receive an ARP response to identify a common IP/MAC binding as a result of the ToR switch network device failing to advertise the IP/MAC binding. Moreover, when the gateway network device is disabled for the network and subsequently enabled for the network, the gateway network device may be routed network traffic associated with a host network device and may, again transmit ARP messages to resolve IP/MAC bindings, although other redundant gateway network devices may have already resolved the IP/MAC bindings and may be available to route the network traffic.
[0014] Implementations, described herein, may utilize a proxy IP/MAC advertisement from a gateway network device to other network devices (e.g., other provider edge network devices, such as ToR switch network devices, other gateway network devices, or the like) of a network to permit routing of network traffic for the network. In this way, a quantity of network traffic associated with transmitting ARP messages and receiving responses to ARP messages may be reduced relative to utilizing the ARP messages to determine IP/MAC binding for each provider edge network device, thereby improving network performance. Moreover, when a network device is removed from or added to the network, a period of time required by the network device to resolve IP/MAC bindings may be reduced relative to utilizing the ARP messages or the network traffic may be directed to a network device that has already received information identifying the IP/MAC binding, thereby reducing a likelihood that network traffic is lost and improving network performance.
Chu describes tunning with unique IP/MAC address pairing for encapsulation and a virtual switching network and mentions a system capable of address resolution protocol. Sivaraj discloses address resolution protocol (ARP) in detail including ARP requests and responses. Further, instant application Lemoine et al. (US 20240039757 A1) also describes ethernet frame encapsulating of an IP packet and a virtual switching network (¶ 23-26; ¶82).
Therefore, the prior art of record still discloses the claimed invention of the independent claims, and the prior art rejection is maintained below.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Chu et al. (US 2017/0250912 A1; hereinafter Chu) and further in view of Sivaraj et al. (US 2017/0195220; hereinafter Sivaraj).
Regarding Claim 1, Chu disclose(s):
A communication method implemented by a multiprotocol label switching virtual source proxy belonging to a computer system implementing a switching virtual local network, said computer system further including a virtualization management system, a first server wherein said source proxy and a host source are connected, a second server wherein a multiprotocol label switching virtual destination proxy and a destination host are connected, said source and destination proxies being connected to the local network and also attached to a communication virtual private network, said method comprising:
running a request received from the virtualization management system to configure, on said private network, a virtual interface for said source host, said request including a request for association of a hardware address of the source host with a tunnel identifier associated with an identifier of said private network, [Chu discloses that in an overlay network such as a VXLAN network or Network Virtualization using Generic Routing Encapsulation (NVGRE), the associations between host addresses and tunnel endpoints are typically created by a central controller and those mappings are distributed to all the tunnel endpoints in the overlay network (¶4-5; ¶76-78). Chu also discloses that hosts include virtual tunnel endpoints (VTEP) which can be virtual nodes or switches configured to encapsulate/decapsulate data traffic for various virtual network identifiers (VNID) where each host can be a Virtual Ethernet Module (VEM) that is assigned at least one IP address used as the source IP address when the encapsulated MAC frames are sent to other VEMs over the network; furthermore each of the overlay tunnels (VTEPs 408A-D) can include one or more VNIDs (¶53-57; Fig. 3-4). Chu further discloses that network segments may be grouped into a bridge domain associated with an interface which supports traffic between layers 2 and 3 and that a bridge domain interface can support IP termination, VPN termination, address resolution handling, MAC addressing, etc. and that bridge domains and bridge domain interfaces may be identified with the same index or identifier (¶24; Fig. 3).]
transmitting, to the destination proxy, a [Chu discloses address resolution handling (¶24) and that VTEPs 408A-D can encapsulate packets directed at the various VNIDs 1-3 in the overlay network 400 according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s) (¶ 60; Fig. 4). Chu also discloses source and destination hosts and host addresses (¶ 80-82) and that one or more spine switches can be configured to host a proxy function that performs a lookup of the endpoint address identifier to locator mapping in a mapping database on behalf of leaf switches and when a packet is received at spine switch 302.sub.i, spine switch 302.sub.i can first check if the destination locator address is a proxy address (¶ 43-44; ¶ 77; Fig. 3).]
transmitting, to the source host, a [Chu discloses address resolution handling (¶24) and that VTEPs 408A-D can encapsulate packets directed at the various VNIDs 1-3 in the overlay network 400 according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s) (¶ 60; Fig. 4). Chu also discloses source and destination hosts and host addresses (¶ 80-82) and that one or more spine switches can be configured to host a proxy function that performs a lookup of the endpoint address identifier to locator mapping in a mapping database on behalf of leaf switches and when a packet is received at spine switch 302.sub.i, spine switch 302.sub.i can first check if the destination locator address is a proxy address (¶ 43-44; ¶ 77; Fig. 3).]
Chu fails to explicitly disclose:
transmitting, to the destination proxy, a request sent by the source host, said requestbeing an address resolution request for an IP address of the destination host, and
transmitting, to the source host, a reply to said resolution request, said reply being sent by the destination host and received from the destination proxy, and also including a hardware address of said destination host.
However Sivaraj, analogous art also teaching address resolution protocol, does disclose:
transmitting, to the destination proxy, a request sent by the source host, said requestbeing an address resolution request for an IP address of the destination host, and [Sivaraj discloses an address resolution protocol (ARP) message to determine the IP/MAC binding for each provider edge network device for a received MAC route with network traffic is received at the network and that IP/MAC binding may include information that identifies particular IP address information corresponding to particular MAC route information and that a proxy IP/MAC advertisement from a gateway network device to other edge network devices, gateway network devices, etc., may be used to permit routing for network traffic for the network (¶11-15; Fig. 1A/B). Furthermore Sivaraj discloses that a network device may include a proxy and that a network device may be associated with a network configuration and may correspond to single/multi-homed host network devices and may also be associated to private networks, virtual local area networks, multi-protocol label switching networks, among others (¶24-26; ¶27-37; ¶47; ¶77-82; Fig. 2-3).]
transmitting, to the source host, a reply to said resolution request, said reply being sent by the destination host and received from the destination proxy, and also including a hardware address of said destination host. [Sivaraj discloses gateway network devices receiving an ARP response for identifying an IP/MAC binding for the MAC route (¶11-15; Fig. 1A/B). Furthermore Sivaraj discloses that a network device may include a proxy and that a network device may be associated with a network configuration and may correspond to single/multi-homed host network devices and may also be associated to private networks, virtual local area networks, multi-protocol label switching networks, among others (¶23-26; ¶27-37; ¶47; Fig. 2-3).]
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the communication system of Chu with that of Sivaraj to explicitly include details on address resolution protocol in order to determine IP/MAC binding, as per Sivaraj (¶11-15), with reasonable expectation of success.
Regarding Claim 2, Chu and Sivaraj disclose(s):
The method of claim 1 further comprising:
receiving, from the source host, an Ethernet frame encapsulating an IP packet sent by the source host toward the destination host, said Ethernet frame including the respective hardware addresses of the source and destination hosts, [Chu discloses that layer 2 data traffic such as MAC Ethernet frames can be encapsulated within layer 3 packets to travel across layer 3 boundaries to reach its destination and that the encapsulated packet can include a source host address for the source host and a source tunnel endpoint address for the second tunnel endpoint (¶ 3; ¶16). Chu also discloses that the proxy function can parse through the packet to the encapsulated, tenant packet to get to the destination locator address of the tenant, perform a lookup of local mapping, and forward the packet to the locator address (¶ 43-44; ¶64-66; Fig. 3-4 and 6B)]
transmitting said Ethernet frame to the destination proxy. [Chu discloses host 404B originating a packet destined for host 404G and forwarding the packet to a tunnel endpoint and further discloses that switches can be configured to host a proxy function (¶ 43-44; ¶77-82; Fig. 6A/B/C). Sivaraj discloses that a network device may include a proxy (¶24-26)]
Regarding Claim 3, Chu and Sivaraj disclose(s):
The method of claim 1, wherein the tunnel identifier is identical to the identifier of the private network. [Chu discloses that network segments (e.g. physical or virtual) such as networks, devices, ports, links, and/or traffic, may be grouped into a bridge domain associated with an interface which supports traffic between layers 2 and 3 and that a bridge domain interface can support IP termination, VPN termination, address resolution handling, MAC addressing, etc. and that bridge domains and bridge domain interfaces may be identified with the same index or identifier (¶24; Fig. 3).]
Regarding Claim 4, Chu and Sivaraj disclose(s):
The method of claim 1, wherein the tunnel identifier is contained in a data table matching the identifier of said private network with said tunnel identifier. [Chu discloses a data table with entries that include MAC addresses, VXLAN IDs (VNIDs), and virtual tunnel end point (VTEP) addresses (¶68-70; Fig. 5-6 and 8)]
Regarding Claim 5, Chu disclose(s):
A communication method implemented by a multiprotocol label switching virtual destination proxy belonging to a computer system implementing a switching virtual local network, said computer system further including a virtualization management system, a first server wherein a multiprotocol label switching virtual source proxy and a source host are connected; a second server wherein said destination proxy and destination host are connected, said source and destination proxies being connected to the local network and also attached to a communication virtual private network, said method comprising:
transmitting, to the destination host, a [Chu discloses address resolution handling (¶24) and that VTEPs 408A-D can encapsulate packets directed at the various VNIDs 1-3 in the overlay network 400 according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s) (¶ 60; Fig. 4). Chu also discloses source and destination hosts and host addresses (¶ 80-82) and that one or more spine switches can be configured to host a proxy function that performs a lookup of the endpoint address identifier to locator mapping in a mapping database on behalf of leaf switches and when a packet is received at spine switch 302.sub.i, spine switch 302.sub.i can first check if the destination locator address is a proxy address (¶ 43-44; ¶ 77-82; Fig. 3).]
transmitting, to the source proxy, a [Chu discloses address resolution handling (¶24) and that VTEPs 408A-D can encapsulate packets directed at the various VNIDs 1-3 in the overlay network 400 according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s) (¶ 60; Fig. 4). Chu also discloses source and destination hosts and host addresses (¶ 80-82) and that one or more spine switches can be configured to host a proxy function that performs a lookup of the endpoint address identifier to locator mapping in a mapping database on behalf of leaf switches and when a packet is received at spine switch 302.sub.i, spine switch 302.sub.i can first check if the destination locator address is a proxy address (¶ 43-44; ¶ 77; Fig. 3).]
Chu fails to explicitly disclose:
transmitting, to the destination host, a request received from the source proxy and sent by the source host, said request being an address resolution request for an IP address of the destination host, and
transmitting, to the source proxy, a reply to said resolution request, said reply being sent by the destination host and including a hardware address of said destination host.
However Sivaraj, analogous art also teaching address resolution protocol, does disclose:
transmitting, to the destination host, a request received from the source proxy and sent by the source host, said request being an address resolution request for an IP address of the destination host, and[Sivaraj discloses an address resolution protocol (ARP) message to determine the IP/MAC binding for each provider edge network device for a received MAC route with network traffic is received at the network and that IP/MAC binding may include information that identifies particular IP address information corresponding to particular MAC route information and that a proxy IP/MAC advertisement from a gateway network device to other edge network devices, gateway network devices, etc., may be used to permit routing for network traffic for the network (¶11-15; Fig. 1A/B). Furthermore Sivaraj discloses that a network device may include a proxy and that a network device may be associated with a network configuration and may correspond to single/multi-homed host network devices and may also be associated to private networks, virtual local area networks, multi-protocol label switching networks, among others (¶24-26; ¶47; Fig. 2).]
transmitting, to the source proxy, a reply to said resolution request, said reply being sent by the destination host and including a hardware address of said destination host. [Sivaraj discloses gateway network devices receiving an ARP response for identifying an IP/MAC binding for the MAC route (¶11-15; Fig. 1A/B). Furthermore Sivaraj discloses that a network device may include a proxy and that a network device may be associated with a network configuration and may correspond to single/multi-homed host network devices and may also be associated to private networks, virtual local area networks, multi-protocol label switching networks, among others (¶24-26; ¶47; Fig. 2).]
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the communication system of Chu with that of Sivaraj to explicitly include details on address resolution protocol in order to determine IP/MAC binding, as per Sivaraj (¶11-15), with reasonable expectation of success.
Regarding Claim 6, Chu and Sivaraj disclose(s):
The method of claim 5, said method further comprising:
receiving, from the source host, an Ethernet frame encapsulating an IP packet, said Ethernet frame including the respective hardware addresses of the source and destination hosts, [Chu discloses that layer 2 data traffic such as MAC Ethernet frames can be encapsulated within layer 3 packets to travel across layer 3 boundaries to reach its destination and that the encapsulated packet can include a source host address for the source host and a source tunnel endpoint address for the second tunnel endpoint (¶ 3; ¶16). Chu also discloses that the proxy function can parse through the packet to the encapsulated, tenant packet to get to the destination locator address of the tenant, perform a lookup of local mapping, and forward the packet to the locator address (¶ 43-44; ¶64-66; Fig. 3-4 and 6B)]
checking a match between, on the one hand, a first identifier, the tunnel identifier inserted between said hardware addresses and the IP packet, and a second identifier contained in a data table matching the hardware address of the destination host with said second identifier, [Chu discloses that host 404B originates a packet that is destined for host 404G (614A) and forwards the packet to tunnel endpoint 408A (614B). In order for tunnel endpoint 408A encapsulate the received packet and to forward the encapsulated packet to its intended recipient, tunnel endpoint 408A may extract the host destination address from the packet and look up the address in its own encapsulation table (not shown). If a match is found for destination host address 55:55:55:55:55:55, tunnel endpoint 408A may use the encapsulation information (i.e., IP address 10.1.1.3) from its encapsulation table to encapsulate and forward the packet and then once a destination IP address is identified, tunnel endpoint 408A may then encapsulate the packet by adding the IP address of tunnel endpoint 408A (i.e., 10.1.1.1) to the encapsulation header in a field such as outer IP source address 520 as shown in FIG. 5. (¶76-79; Fig. 5, 6B, and 7)]
upon a determination that the match check is positive, removing the tunnel identifier from said Ethernet frame and transmitting the Ethernet frame to the destination host. [Chu discloses that next, tunnel endpoint 408D may de-encapsulate the received packet by stripping the encapsulation header. Tunnel endpoint 408D may then forward the resulting de-encapsulated L2 frame to host 404G (614E, 614F) (¶ 79; Fig. 6B).]
Regarding Claim 7, Chu and Sivaraj disclose(s):
The method of claim 4, wherein a data table containing an identifier used by a proxy is a switching table stored by said proxy. [Chu discloses that a network device may include memory to store tables (¶32) and that a spine switch can be configured to host a proxy which can perform a lookup of local mapping database to determine correct locator address of packet (¶43-44; ¶ 60-62; ¶ 68; Fig. 4, 6 and 7-8 ).]
Regarding Claim 8, Chu and Sivaraj disclose(s):
The method of claim 4, wherein a data table containing an identifier used by a proxy is a switching table stored by a virtual Ethernet bridge to which is connected the host contained in the server hosting said proxy. [Chu discloses that a network device may include memory to store tables (¶32) and that a spine switch can be configured to host a proxy which can perform a lookup of local mapping database to determine correct locator address of packet (¶43-44; ¶ 60-62; ¶ 68; Fig.4, 6 and 7-8 ). Chu further discloses that hosts include virtual tunnel endpoints (VTEP) which can be virtual nodes or switches configured to encapsulate/decapsulate data traffic for various virtual network identifiers (VNID) where each host can be a Virtual Ethernet Module (VEM) that is assigned at least one IP address used as the source IP address when the encapsulated MAC frames are sent to other VEMs over the network; furthermore each of the overlay tunnels (VTEPs 408A-D) can include one or more VNIDs (¶53-57; Fig. 3-4) and that network segments may be grouped into a bridge domain associated with an interface which supports traffic between layers 2 and 3 and that a bridge domain interface can support IP termination, VPN termination, address resolution handling, MAC addressing, etc. and that bridge domains and bridge domain interfaces may be identified with the same index or identifier (¶24; Fig. 3). Chu also discloses that the overlay network can host physical devices such as servers (¶ 49-51; ¶55; ¶ 59; Fig. 3-4)]
Regarding Claim 9, Chu and Sivaraj disclose(s):
A non-transitory computer readable medium having stored thereon a computer program including instructions which, when executed by a computer, cause the computer to implement the method of claim 1. [Chu discloses a network device and example system embodiments which include memory, instructions stored thereon, and processors capable of executing instructions stored on memory as well as a system with a chipset, RAM, processor and communication interface to implement the present invention (¶29-40; Fig. 1 and 2A/B)]
Regarding Claim 10, Chu and Sivaraj disclose(s):
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 1. [Chu discloses a network device and example system embodiments which include memory, instructions stored thereon, and processors capable of executing instructions stored on memory as well as a system with a chipset, RAM, processor and communication interface to implement the present invention (¶29-40; Fig. 1 and 2A/B)]
Regarding Claim 11, Chu and Sivaraj disclose(s):
A multiprotocol label switching virtual source proxy including means configured to implement the method of claim 1. [Chu discloses a network device and example system embodiments which include memory, instructions stored thereon, and processors capable of executing instructions stored on memory as well as a system with a chipset, RAM, processor and communication interface to implement the present invention (¶29-40; Fig. 1 and 2A/B). Sivaraj discloses a network device may include a proxy and may be associated with a multiprotocol label switching network (¶23-37; Fig. 2-3)]
Regarding Claim 12, Chu and Sivaraj disclose(s):
A multiprotocol label switching virtual destination proxy including means configured to implement the method of claim 5. [Chu discloses a network device and example system embodiments which include memory, instructions stored thereon, and processors capable of executing instructions stored on memory as well as a system with a chipset, RAM, processor and communication interface to implement the present invention (¶29-40; Fig. 1 and 2A/B). Sivaraj discloses a network device may include a proxy and may be associated with a multiprotocol label switching network (¶23-37; Fig. 2-3)]
Regarding Claim 13, Chu and Sivaraj disclose(s):
A computer system implementing a switching virtual local network, said computer system including a virtualization management system, a first server wherein the virtual proxy of claim 11 and a source host are connected, a second server wherein a destination host and a virtual destination proxy are connected, the virtual destination proxy including means configured to implement a method comprising:
transmitting, to the destination host, a request received from the virtual source proxy and sent by the source host, said request being an address resolution request for an IP address of the destination host, and [Chu discloses address resolution handling (¶24) and that VTEPs 408A-D can encapsulate packets directed at the various VNIDs 1-3 in the overlay network 400 according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s) (¶ 60; Fig. 4). Chu also discloses source and destination hosts and host addresses (¶ 80-82) and that one or more spine switches can be configured to host a proxy function that performs a lookup of the endpoint address identifier to locator mapping in a mapping database on behalf of leaf switches and when a packet is received at spine switch 302.sub.i, spine switch 302.sub.i can first check if the destination locator address is a proxy address (¶ 43-44; ¶ 77-82; Fig. 3). Sivaraj discloses an address resolution protocol (ARP) message to determine the IP/MAC binding for each provider edge network device for a received MAC route with network traffic is received at the network and that IP/MAC binding may include information that identifies particular IP address information corresponding to particular MAC route information and that a proxy IP/MAC advertisement from a gateway network device to other edge network devices, gateway network devices, etc., may be used to permit routing for network traffic for the network (¶11-15; Fig. 1A/B). Furthermore Sivaraj discloses that a network device may include a proxy and that a network device may be associated with a network configuration and may correspond to single/multi-homed host network devices and may also be associated to private networks, virtual local area networks, multi-protocol label switching networks, among others (¶24-26; ¶47; Fig. 2).]
receiving, at the source proxy, a reply to said resolution request, said reply being sent by the destination host and including a hardware address of said destination host, said virtual source and virtual destination proxies being connected to the local network and also attached to a communication virtual private network. [Chu discloses address resolution handling (¶24) and that VTEPs 408A-D can encapsulate packets directed at the various VNIDs 1-3 in the overlay network 400 according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s) (¶ 60; Fig. 4). Chu also discloses source and destination hosts and host addresses (¶ 80-82) and that one or more spine switches can be configured to host a proxy function that performs a lookup of the endpoint address identifier to locator mapping in a mapping database on behalf of leaf switches and when a packet is received at spine switch 302.sub.i, spine switch 302.sub.i can first check if the destination locator address is a proxy address (¶ 43-44; ¶ 77; Fig. 3). Sivaraj discloses gateway network devices receiving an ARP response for identifying an IP/MAC binding for the MAC route (¶11-15; Fig. 1A/B). Furthermore Sivaraj discloses that a network device may include a proxy and that a network device may be associated with a network configuration and may correspond to single/multi-homed host network devices and may also be associated to private networks, virtual local area networks, multi-protocol label switching networks, among others (¶24-26; ¶47; Fig. 2).]
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 Rowan K Fakhro whose telephone number is (703)756-1467. The examiner can normally be reached Monday - Friday 8:00am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Marcus R Smith can be reached at (571) 270-1096. 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.
/RKF/Patent Examiner, Art Unit 2468
/MARCUS SMITH/Supervisory Patent Examiner, Art Unit 2468
Prosecution Insights