DETAILED ACTION
This action is responsive to amended claims filed on 26 February 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 Arguments
Applicant's arguments filed 26 February 2026 have been fully considered but they are not persuasive.
Applicant argues Brar fails to disclose “bridged gateway” because Brar allegedly discloses only source VNICs/endpoints rather than a bridged gateway. This argument is not persuasive because Brar expressly discloses network virtualization devices (NVDs) executing virtual routers and gateway functions (Brar, fig. 2, [0106]-[0117], [0118]-[0124]). Brar further discloses gateway structures within the virtual network architecture (Brar, see fig. 6). Accordingly, Brar teaches structure corresponding to the claimed bridged gateway, and applicant’s argument is unpersuasive because it focuses on differences in terminology rather than corresponding disclosed structure and functionality.
Applicant argues Brar fails to disclose “a first computing device operable to provide virtual gateway functionality”. This argument is not persuasive because Brar expressly discloses that an NVD implements network virtualization functions including execution of Virtual Routers (VRs) and gateways, and further discloses the NVDs execute VCN VRs corresponding to VCNs (Brar, [0064]-[0105], [0106]-[0117], [0118]-[0124]). Thus, Brar expressly teaches a computing device executing virtual gateway functionality.
Applicant argues Brar fails to disclose “establishment of a Layer-2 tunnel”. This argument is not persuasive because Brar expressly discloses packet encapsulation and decapsulation for customer packets traversing the subtract network (Brar, [0064]-[0105], [0106]-[0117], [0118]-[0124]), insertion of layer-2 headers (Brar, [0064]-[0105], [0106]-[0117], [0118]-[0124]), and L2 VLAN structures (Brar, fig. 6), which reasonably correspond to establishment of Layer-2 virtual communication/tunneling.
Applicant argues Brar fails to disclose a device coupled to a LAN in a premises and fails to disclose message-base initiation. This argument is not persuasive because Brar expressly discloses customer on-premise connectivity through gateway structures (Brar, fig. 6, [0064]-[0105], [0106]-[0117], [0118]-[0124]), and further discloses packet interception, processing, routing determination, and forwarding by the NVD packet-processing pipeline upon receipt of packets (Brar, [0064]-[0105], [0106]-[0117], [0118]-[0124]), thereby teaching message-triggered initiation of virtual gateway processing.
Applicant states Brar fails to disclose claims 1-20. The examiner respectfully disagrees with applicant. As mentioned above for independent claims 1, 10, and 19, while not identical to claims 2-9, 11-18 and 20, the limitations of the dependent claims correspond to the independent claims 1, 10, and 19.
Thus, the examiner maintains 35 U.S.C. 102(a)(2) as being anticipated by Brar et al. (US 20240031282 A1) (hereinafter Bra).
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Brar et al. (US 20240031282 A1) (hereinafter Bra) .
In regards to claims 1 and 10, Bra teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
a memory (Bra, Fig.1, [0090]);
a transceiver operable to be coupled to a local area network (LAN) (Bra, [0036]-[0041]: [0039] In a physical network, a network endpoint (“endpoint”) refers to a computing device or system that is connected to a physical network and communicates back and forth with the network to which it is connected. A network endpoint in the physical network may be connected to a Local Area Network (LAN), a Wide Area Network (WAN), or other type of physical network. Examples of traditional endpoints in a physical network include modems, hubs, bridges, switches, routers, and other networking devices, physical computers (or host machines), and the like. Each physical device in the physical network has a fixed network address that can be used to communicate with the device. This fixed network address can be a Layer-2 address (e.g., a MAC address), a fixed Layer-3 address (e.g., an IP address), and the like. In a virtualized environment or in a virtual network, the endpoints can include various virtual endpoints such as virtual machines that are hosted by components of the physical network (e.g., hosted by physical host machines). These endpoints in the virtual network are addressed by overlay addresses such as overlay Layer-2 addresses (e.g., overlay MAC addresses) and overlay Layer-3 addresses (e.g., overlay IP addresses). Network overlays enable flexibility by allowing network managers to move around the overlay addresses associated with network endpoints using software management (e.g., via software implementing a control plane for the virtual network). Accordingly, unlike in a physical network, in a virtual network, an overlay address (e.g., an overlay IP address) can be moved from one endpoint to another using network management software. Since the virtual network is built on top of a physical network, communications between components in the virtual network involves both the virtual network and the underlying physical network. In order to facilitate such communications, the components of CSPI are configured to learn and store mappings that map overlay addresses in the virtual network to actual physical addresses in the substrate network, and vice versa. These mappings are then used to facilitate the communications. Customer traffic is encapsulated to facilitate routing in the virtual network.); and
a processor device coupled to the memory and the transceiver and being operable to (Bra, Fig. 3, [0101]-[0105], [0106]-[0107]: [0106] Referring back to FIG. 2, an NVD is a physical device or component that performs one or more network and/or storage virtualization functions. An NVD may be any device with one or more processing units (e.g., CPUs, Network Processing Units (NPUs), FPGAs, packet processing pipelines, etc.), memory including cache, and ports. The various virtualization functions may be performed by software/firmware executed by the one or more processing units of the NVD.) :
establishing, by a bridged gateway coupled to a local area network (LAN) in a premises, a layer 2 tunnel with a first computing device coupled to a different network, the first computing device operable to provide a virtual gateway that provides default gateway functionality to computing devices connected to the LAN (Bra, [0039]-[0048]: [0039] In a physical network, a network endpoint (“endpoint”) refers to a computing device or system that is connected to a physical network and communicates back and forth with the network to which it is connected. A network endpoint in the physical network may be connected to a Local Area Network (LAN), a Wide Area Network (WAN), or other type of physical network. Examples of traditional endpoints in a physical network include modems, hubs, bridges, switches, routers, and other networking devices, physical computers (or host machines), and the like. Each physical device in the physical network has a fixed network address that can be used to communicate with the device. This fixed network address can be a Layer-2 address (e.g., a MAC address), a fixed Layer-3 address (e.g., an IP address), and the like. In a virtualized environment or in a virtual network, the endpoints can include various virtual endpoints such as virtual machines that are hosted by components of the physical network (e.g., hosted by physical host machines). These endpoints in the virtual network are addressed by overlay addresses such as overlay Layer-2 addresses (e.g., overlay MAC addresses) and overlay Layer-3 addresses (e.g., overlay IP addresses). Network overlays enable flexibility by allowing network managers to move around the overlay addresses associated with network endpoints using software management (e.g., via software implementing a control plane for the virtual network). Accordingly, unlike in a physical network, in a virtual network, an overlay address (e.g., an overlay IP address) can be moved from one endpoint to another using network management software. Since the virtual network is built on top of a physical network, communications between components in the virtual network involves both the virtual network and the underlying physical network. In order to facilitate such communications, the components of CSPI are configured to learn and store mappings that map overlay addresses in the virtual network to actual physical addresses in the substrate network, and vice versa. These mappings are then used to facilitate the communications. Customer traffic is encapsulated to facilitate routing in the virtual network.);
generating, by the bridged gateway, a first message to be processed by the virtual gateway (Bra, Fig. 12, [0220]-[0235]: [0226] At block 1206, each interface in the VLAN broadcast domain receives and decapsulates an ARP messages. Each of the interfaces in the VLAN broadcast domain that receives the ARP message learns the interface-to-MAC address mapping of the source VNIC of the source CI (e.g., interface identifier of the source interface to MAC address of the source CI) as this message identifies the source CI MAC and IP addresses and the source CI interface identifier. As part of learning the interface-to-MAC address mapping for the source CI, each of the interfaces can update its mapping table (e.g., its L2 forwarding table), and can provide the updated mapping to its associated switch and/or CI. Each recipient interface, except the VSRS, can forward a decapsulated packet to their associated CI. The CI recipient of the forwarded decapsulated packet, and specifically the network interface of that CI, can determine if the target IP address matches the IP address of the CI. If the IP address of the CI associated with that interface does not match the destination CI IP address, then, in some embodiments, the packet is dropped by that CI, and no further action is taken. In the case of the VSRS, the VSRS can determine if the target IP address matches the IP address of the VSRS. If the IP address of the VSRS does not match the target IP address specified in the received packet, then, in some embodiments, the packet is dropped by the VSRS and no further action is taken.); and
sending, by the bridged gateway to the first computing device, the first message to cause the first computing device to initiate the virtual gateway (Bra, Fig. 12, [0220]-[0235]: [0225] At block 1204, the source VNIC, also referred to herein as the source interface, receives the ARP request from the source CI. The source interface identifies all interfaces on the VLAN, and sends the ARP request to all interfaces on the VLAN broadcast domain. As previously mentioned, as the control plane knows all of the interfaces on the VLAN and provides that information to the interfaces with the VLAN, the source interface likewise knows all of the interfaces in the VLAN and is able to send the ARP request to each of the interfaces in the VLAN. To do this, the source interface replicates the ARP request and encapsulates one of the ARP requests for each of the interfaces on the VLAN. Each encapsulated ARP request includes the source CI interface identifier and source CI MAC and IP addresses, the target IP address, and the destination CI interface identifier. The source CI interface replicates an Ethernet broadcast by sending the replicated and encapsulated ARP requests (e.g., ARP messages) as serial unicast, one sent to each interface in the VLAN.).
In regards to claims 2 and 11, Bra teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
wherein the layer 2 tunnel comprises a Generic Routing Encapsulation (GRE) tunnel (Bra, Fig. 13, [0203]-[0205], [0216]-[0217], [0236]-[0241] : [0239] The span port configuration 1324 can indicate, for instance, one or more criteria for copying frames and, possibly, further processing the copied frames. These criteria generally include filtering criteria that can be applied to determine whether a copy needs to be made and processing criteria that indicate the type of processing to apply to the copy. In an example, the customer can specify filtering criteria on any header information including, for instance, source MAC address, destination MAC address, source IP address, destination IP address, and/or protocol. The filtering criteria can additionally or alternatively indicate a source port, a destination port, a source of the traffic (e.g., a compute instance within the L2 VLAN or a source outside of the L2 VLAN), and/or a destination of the traffic (e.g., a compute instance within the L2 VLAN or a source outside of the L2 VLAN). As far as the processing criteria, the customer can specify, among other things, the number of copies to make, any encapsulation to add to a copy (e.g., add generic routing encapsulation (GRE) or virtual extensible LAN (VXLAN) encapsulation to a frame copy). Adding encapsulation can allow a destination to distinguish received copies as being span traffic from other received traffic that is regular or non-span traffic. For the destination, the customer can specify a MAC address, an IP address, a port, a compute instance within the L2 VLAN, a compute instance on another L2 VLAN, a compute instance on a virtual L3 network, a host outside the L2 VLAN (e.g., a host in an on-premise network of the customer), or any other type of destination to receive copies. Although a single destination is described, the customer can specify multiple destinations of the same type or of different types. Further, the customer may specify whether the filtering and processing (e.g., copying and, as applicable, encapsulation) is to be performed on the egress (e.g., at the source port or source L2 VNIC) or ingress (e.g., at the destination port or destination L2 VNIC).).
In regards to claims 3 and 12, Bra teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
wherein the first computing device comprises a broadband network gateway operable to initiate a plurality of virtual gateways, each virtual gateway of the plurality of virtual gateways operable to provide default gateway functionality to corresponding LANs of a plurality of LANs (Bra, Fig. 6, [0030]-[0035], [0161]-[0173]: [0161] With reference now to FIG. 6, a schematic illustration of one embodiment of a computing network is shown. A VCN 602 resides in a CSPI 601. The VCN 602 includes a plurality gateways connecting the VCN 602 to other networks. These gateways include a DRG 604 which can connect the VCN 602 to, for example, an on-premise network such as on-premise data center 606. The gateways can further include a gateway 600, which can include, for example, a LPG for connecting the VCN 602 with another VCN, and/or an IGW and/or NAT gateway for connecting the VCN 602 to the internet. The gateways of the VCN 602 can further include a services gateway 610 which can connect the VCN 602 with a services network 612. The services network 612 can include one or several databases and/or stores including, for example, autonomous database 614 and/or object store 616. The services network can comprise a conceptual network comprising an aggregation of IP ranges, which can be, for example, public IP ranges. In some embodiments, these IP ranges can cover some or all of the public services offered by the CSPI 601 provider. These services can, for example, be accessed through an Internet Gateway or NAT Gateway. In some embodiments, the services network provides a way for the services in the services network to be accessed from the local region through a dedicated gateway for that purpose (a Service Gateway). In some embodiments, the backends of these services can be implemented in, for example, their own private networks. In some embodiments, the services network 612 can include further additional databases.).
In regards to claims 4 and 13, Bra teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
wherein the processor device is further operable to (Bra, Fig. 3, [0101]-[0105], [0106]-[0107]: See above for paragraph [0106].):
receiving, by the bridged gateway, a second message from a second computing device connected to the LAN (Bra, Fig. 12, [0220]-[0235]: See above for paragraph [0226].);
determining, by the bridged gateway, that the second message is a message to be processed by the virtual gateway (Bra, Fig. 12, [0220]-[0235]: [0227] If it is determined that the destination CI IP address specified in the received packet matches the IP address of the CI associated with the recipient interface (destination CI), then, and as indicated in block 1208, the destination CI sends a response, which can be a unicast ARP response to the source interface. This response includes the destination CI MAC address and destination CI IP address, and the source CI IP and MAC addresses. This response is received by the destination interface which encapsulates the unicast ARP response as indicated in block 1210. In some embodiments, this encapsulation can comprise GENEVE encapsulation. The destination interface can forward the encapsulated ARP response via the destination switch to the source interface. This response includes the destination CI MAC and IP addresses and destination CI interface identifier, and the source CI MAC and IP addresses and the source CI interface identifier.);
encapsulating the second message into a layer 3 protocol (Bra, Fig. 10, [0198]-[0208]: [0203] As explained herein above, the VLAN is implemented within a VCN as an overlay L2 network on top of an L3 physical network. An L2 compute instance of the VLAN can send or receive an L2 frame that includes overlay MAC addresses (also referred to as virtual MAC addresses) as source and destination MAC addresses. The L2 frame can also encapsulate a packet that includes overlay IP addresses (also referred to as virtual IP addresses) as source and destination IP addresses. The overlay IP address of the compute instance can, in some embodiments, belong to a CIDR range of the VLAN. The other overlay IP address can belong to the CIDR range (in which case, the L2 frame flows within the VLAN) or outside the CIDR range (in which case, the L2 frame is destined to or received from another network). The L2 frame can also include a VLAN tag that uniquely identifies the VLAN and that can be used to distinguish against multiple L2 VNICs on the same NVD. The L2 frame can be received in an encapsulated packet by the NVD via a tunnel from the host machine of the compute instance, from another NVD, or from the server fleet hosting the VSRS. In these different cases, the encapsulated packet can be an L3 packet sent on the physical network, where the source and destination IP addresses are physical IP addresses. Different types of encapsulation are possible, including GENEVE encapsulation. The NVD can decapsulate the received packet to extract the L2 frame. Similarly, to send an L2 frame, the NVD can encapsulate it in an L3 packet and send it on the physical substrate.); and
sending the second message to the first computing device via the layer 2 tunnel (Bra, Fig. 10, [0198]-[0208]: See above for paragraph [0203].).
In regards to claims 5 and 14, blank teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
wherein the processor device is further to (Bra, Fig. 3, [0101]-[0105], [0106]-[0107]: See above for paragraph [0106].):
receiving, by the bridged gateway via the layer 2 tunnel, a layer 3 packet that includes a layer 2 reply to the second message from the virtual gateway (Bra, Fig. 12, [0220]-[0235]: See above for paragraph [0226].);
extracting, by the bridged gateway, the layer 2 reply (Bra, fig. 10, [0201]-[0209]: [0208] For egress traffic sent from instance 2 1000-B in the VLAN 1000 to an instance in another VLAN, a similar flow as the above egress traffic can exist, except that the VSRS VNIC and VSRS switch are used. In particular, the destination MAC address is not within the L2 broadcast of the VLAN 1000 (it is within the other L2 VLAN). Accordingly, the overlay destination IP address (e.g., IP.A) of the destination instance is used for this egress traffic. For example, L2 VNIC 2 1002-B determines that IP.A is outside of the CIDR range of the VLAN 1000. Accordingly, L2 VNIC 2 1002-B sets a destination MAC address to a default gateway MAC address (e.g., M.DG). Based on M.DG, the L2 switch 2 1004-B sends the egress traffic to the VSRS VNIC (e.g., via a tunnel, with the proper end-to-end encapsulation). The VSRS VNIC forwards the egress traffic to the VSRS switch. In turn, the VSRS switch performs a routing function, where, based on the overlay destination IP address (e.g., IP.A), the VSRS switch of the VLAN 1000 sends the egress traffic to the VSRS switch of the other VLAN (e.g., via the virtual router between these two VLANs, also with the proper end-to-end encapsulation). Next, the VSRS switch of the other VLAN performs a switching function by determining that IP.A is within the CIDR range of this VLAN and performs a look-up of its ARP cache based on IP.A to determine the destination MAC address associated with IP.A. If no match exists in the ARP cache, ARP requests are sent to the different L2 VNICs of the other VLAN to determine the destination MAC address. Otherwise, the VSRS switch sends the egress traffic to the relevant VNIC (e.g., via a tunnel, with the proper encapsulation).); and
sending by the bridged gateway to the second computing device, the layer 2 reply, the layer 2 reply comprising a source MAC address of the virtual gateway (Bra, Fig. 6, [0161]-[0173]: [0164] The VCN 602 can further include additional networks, and specifically can include one or several L2 VLANs (referred to herein as VLANs), which are examples of a virtual L2 network. These one or several VLANs can each comprise a virtual Layer 2 network that is localized in the cloud environment of the VCN 602 and/or that is hosted by the underlying physical network of the CPSI 601. In the embodiment of FIG. 6, the VCN 602 includes a VLAN A 630 and a VLAN B 640. Each VLAN 630, 640 within the VCN 602 can be associated with a contiguous range of overlay IP addresses (e.g., 10.0.0.0/24 and 10.0.1.0/24) that do not overlap with other networks in that VCN, such as other subnets or VLANs in that VCN, and which represent an address space subset within the address space of the VCN. In some embodiments, this IP address space of the VLAN can be isolated from an address space associated with CPSI 601. Each of the VLANs 630, 640 can include one or several compute instances, and specifically, the VLAN A 630 can include, for example, a first compute instance 632-A, and a second compute instance 632-B. In some embodiments the VLAN A 630 can include additional compute instances. The VLAN B 640 can include, for example, a first compute instance 642-A, and a second compute instance 642-B. Each of the compute instances 632-A, 632-B, 642-A, 642-B can have an IP address and a MAC address. These addresses can be assigned or generated in any desired manner. In some embodiments, these addresses can be within a CIDR of the VLAN of the compute instances, and in some embodiments, these addresses can be any addresses. In embodiments in which compute instances of a VLAN communicate with endpoints outside of the VLAN, then one or both of these addresses are from the VLAN CIDR, whereas when all communications are intra-VLAN, then these addresses are not limited to addresses within the VLAN CIDR. In contrast to a network in which addresses are assigned by a control plane, the IP and/or MAC addresses of the compute instances in the VLAN can be assigned by the user/customer of that VLAN, and these IP and/or MAC addresses can then be discovered and/or learned by the compute instances in the VLAN according to the processes for learning discussed below.).
In regards to claims 6 and 15, blank teaches:
A method (see fig)/An apparatus (see fig) comprising:
wherein the processor device is further to (Bra, Fig. 3, [0101]-[0105], [0106]-[0107]: See above for paragraph [0106].):
subsequent to sending the first message to cause the first computing device to initiate the virtual gateway, generating, by the bridged gateway, a second message to be processed by the virtual gateway (Bra, Fig. 10, [0198]-[0208]: See above for paragraph [0203].); and
sending, by the bridged gateway to the first computing device, the second message (Bra, Fig. 12, [0220]-[0235]: See above for paragraph [0226].).
In regards to claims 7 and 16, blank teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
wherein the processor device is further to (Bra, Fig. 3, [0101]-[0105], [0106]-[0107]: See above for paragraph [0106].):
setting, by the bridged gateway, a timer (Bra, fig. 4, [0125]-[0142]:[0129] A feature of a Clos network is that the maximum hop count to reach from one Tier-0 switch to another Tier-0 switch (or from an NVD connected to a Tier-0 switch to another NVD connected to a Tier-0 switch) is fixed. For example, in a 3-Tiered Clos network at most seven hops are needed for a packet to reach from one NVD to another NVD, where the source and target NVDs are connected to the leaf tier of the Clos network. Likewise, in a 4-tiered Clos network, at most nine hops are needed for a packet to reach from one NVD to another NVD, where the source and target NVDs are connected to the leaf tier of the Clos network. Thus, a Clos network architecture maintains consistent latency throughout the network, which is important for communication within and between data centers. A Clos topology scales horizontally and is cost effective. The bandwidth/throughput capacity of the network can be easily increased by adding more switches at the various tiers (e.g., more leaf and spine switches) and by increasing the number of links between the switches at adjacent tiers.);
determining that the timer has expired (Bra, fig. 6, [0146]-[0173]: [0155] (2) Low latency reassignment of MACs and IPs for high-availability and live migration. Many on-premises applications use ARP to reassign IPs and MACs for high availability—when an instance in a cluster or HA pair stops responding, the newly active instance will send a Gratuitous ARP (GARP) to reassign a service IP to its MAC or a Reverse ARP (RARP) to reassign a service MAC to its interface. This is also important when live-migrating an instance on a hypervisor: the new host must send a RARP when the guest has migrated so that guest traffic is sent to the new host. Not only is the assignment done without an API call, but it also needs to be extremely low latency (sub-millisecond). This cannot be accomplished with HTTPS calls to a REST endpoint.) ; and
in response to determining that the timer has expired, sending, by the bridged gateway to the first computing device, the second message (Bra, fig. 6, [0146]-[0173]).
In regards to claims 8 and 17, Bra teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
wherein the default gateway functionality includes a DHCP service and a router function to facilitate communication between a computing device connected to the LAN and a computing device connected to another network (Bra, fig. 6, [0161]-[0173]: [0169] In some embodiments, the VSRS 634, 644 may also host one or several higher level services necessary for networking including, but not limited to: a DHCP relay; a DHCP (hosting); a DHCPv6; a neighbor discovery protocol such as IPv6 Neighbor Discovery Protocol; DNS; a hosting DNSv6; a SLAAC for IPv6; a NTP; a metadata service; and a blockstore mount points. In some embodiments, the VSRS can support one or several Network Address Translation (NAT) functions to translate between network address spaces. In some embodiments, the VSRS can incorporate anti-spoofing, anti-MAC spoofing, ARP-cache poisoning protection for IPv4, IPv6 Route Advertisement (RA) guarding, DHCP guarding, packet filtering using Access Control Lists (ACLs); and/or reverse path forwarding checks. The VSRS can implement functions including, for example, ARP, GARP, Packet Filters (ACLs), DHCP relay, and/or IP routing protocols. The VSRS 634, 644 can, for example, learn MAC addresses, invalidate expired MAC addresses, handle moves of MAC addresses, vet MAC address information, handling flooding of MAC information, handling of storm control, loop prevention, Layer 2 multicast via, for example, protocols such as IGNIP in the cloud, statistic gathering including logs, statistics using SNMP, monitoring, and/or gathering and using statistics for broadcast, total traffic, bits, spanning tree packets, or the like.).
In regards to claims 9 and 18, Bra teaches:
A method (Bra, see fig. 15)/An apparatus (Bra, see fig. 23) comprising:
wherein establishing the layer 2 tunnel and sending the first message to the first computing device is performed during an initialization stage of the bridged gateway and prior to receipt of any messages by the bridged gateway from any computing device connected to the LAN (Bra, fig. 5, [0128]-[0160]: [0128] FIG. 5 depicts a simplified block diagram of a physical network 500 according to certain embodiments. The embodiment depicted in FIG. 5 is structured as a Clos network. A Clos network is a particular type of network topology designed to provide connection redundancy while maintaining high bisection bandwidth and maximum resource utilization. A Clos network is a type of non-blocking, multistage or multi-tiered switching network, where the number of stages or tiers can be two, three, four, five, etc. The embodiment depicted in FIG. 5 is a 3-tiered network comprising tiers 1, 2, and 3. The TOR switches 504 represent Tier-0 switches in the Clos network. One or more NVDs are connected to the TOR switches. Tier-0 switches are also referred to as edge devices of the physical network. The Tier-0 switches are connected to Tier-1 switches, which are also referred to as leaf switches. In the embodiment depicted in FIG. a set of “n” Tier-0 TOR switches are connected to a set of “n” Tier-1 switches and together form a pod. Each Tier-0 switch in a pod is interconnected to all the Tier-1 switches in the pod, but there is no connectivity of switches between pods. In certain implementations, two pods are referred to as a block. Each block is served by or connected to a set of “n” Tier-2 switches (sometimes referred to as spine switches). There can be several blocks in the physical network topology. The Tier-2 switches are in turn connected to “n” Tier-3 switches (sometimes referred to as super-spine switches). Communication of packets over physical network 500 is typically performed using one or more Layer-3 communication protocols. Typically, all the layers of the physical network, except for the TORs layer are n-ways redundant thus allowing for high availability. Policies may be specified for pods and blocks to control the visibility of switches to each other in the physical network so as to enable scaling of the physical network.).
In regards to claim 19, Bra teaches:
A method (Bra, see fig. 15)
establishing, by a computing device coupled to a network, a layer 2 tunnel with a bridged gateway coupled to a local area network (LAN) in a premises, the computing device being operable to provide a virtual gateway that provides default gateway functionality to computing devices connected to the LAN (Bra, Fig. 13, [0236]-[0241]: ;
receiving, by the computing device from the bridged gateway via the layer 2 tunnel a message originating from the bridged gateway for processing by the virtual gateway (Bra, Fig. 12, [0220]-[0235]: See above for paragraph [0226].);
determining, by the computing device, that the virtual gateway has not been initiated (Bra, fig. 19, [0285]-[0297]: [0291] In some examples, the service gateway 1936 of the control plane VCN 1916 or of the data plane VCN 1918 can make application programming interface (API) calls to cloud services 1956 without going through public Internet 1954. The API calls to cloud services 1956 from the service gateway 1936 can be one-way: the service gateway 1936 can make API calls to cloud services 1956, and cloud services 1956 can send requested data to the service gateway 1936. However, cloud services 1956 may not initiate API calls to the service gateway 1936.);
initiating, by the computing device, the virtual gateway (Bra, fig. 2, [0065]-[0090]: [0078] A Network Address Translation (NAT) gateway 128 can be configured for customer's VCN 104 and enables cloud resources in the customer's VCN, which do not have dedicated public overlay IP addresses, access to the Internet and it does so without exposing those resources to direct incoming Internet connections (e.g., L4-L7 connections). This enables a private subnet within a VCN, such as private Subnet-1 in VCN 104, with private access to public endpoints on the Internet. In NAT gateways, connections can be initiated only from the private subnet to the public Internet and not from the Internet to the private subnet.); and
providing, by the computing device to the virtual gateway, the message (Bra, fig. 12, [0219]-[0235]: [0078] A Network Address Translation (NAT) gateway 128 can be configured for customer's VCN 104 and enables cloud resources in the customer's VCN, which do not have dedicated public overlay IP addresses, access to the Internet and it does so without exposing those resources to direct incoming Internet connections (e.g., L4-L7 connections). This enables a private subnet within a VCN, such as private Subnet-1 in VCN 104, with private access to public endpoints on the Internet. In NAT gateways, connections can be initiated only from the private subnet to the public Internet and not from the Internet to the private subnet.).
In regards to claim 20, Bra teaches the method of claim 19:
wherein the message comprises a gratuitous address resolution protocol (ARP) reply message (Bra, fig. 6, [0142]-[0144], [0152]-[0158], [0161]-[0173]: [0165] Each of the VLANs can include a VLAN Switching and Routing Service (VSRS), and specifically, the VLAN A 630 includes a VSRS A 634 and the VLAN B 640 includes a VSRS B 644. Each VSRS 634, 644 participates in Layer 2 switching and local learning within a VLAN and also performs all necessary Layer 3 network functions including ARP, NDP, and routing. VSRS performs ARP (which is a Layer 2 protocol) as the VSRS has to map IPs to MACs.).
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 Francesca Lima Santos whose telephone number is (571)272-6521. The examiner can normally be reached Monday thru Friday 7:30am-5pm, ET.
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.
/FRANCESCA LIMA SANTOS/Examiner, Art Unit 2468
/Thomas R Cairns/Primary Examiner, Art Unit 2468
Prosecution Insights