CTNF 18/912,076 CTNF 92820 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Information Disclosure Statement The information disclosure statements (IDS), submitted on 2/19/2025 and 4/10/2025, are being considered by the examiner. Double Patenting 08-33 The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg , 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman , 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi , 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum , 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington , 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA/25, or PTO/AIA/26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. Claims 1-20 of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over related claims of the U.S. Patent Application 18,912,251. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are broader than the claims in the US Patent Application 18,912,251. Claims 1-20 of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over related claims of the U.S. Patent Application 18,912,350. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are broader than the claims in the US Patent Application 18,912,350. Claims 1-20 of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over related claims of the U.S. Patent Application 18,912,318. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are broader than the claims in the US Patent Application 18,912,318. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 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 – 07-08-aia AIA (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention. 07-15 AIA Claim 1-20 are rejected under 35 U.S.C. 102( a)(1 ) as being anticipated by Brar (US Patent 12,309,061 B2), (“Brar”) . Regarding claim 1, Brar meets the claim limitations, as follows: A method (one or more methods disclosed herein) [Brar: col. 2, line 8] comprising: in a network environment comprising a plurality of host machines (The cloud services provider infrastructure (CSPI) may comprise interconnected high-performance compute resources including various host machines, memory resources, and network resources that form a physical network, which is also referred to as a substrate network or an underlay network. The resources in CSPI may be spread across one or more data centers that may be geographically spread across one or more geographical regions) [Brar: col. 3, line 64 – col. 4, line line 3; Figs. 5-9] that are communicatively coupled to each other via a network fabric (The host machines are communicatively coupled to different network fabrics via different TOR switches) [Brar: col. 33, line 4-5; Fig. 10] comprising a plurality of switches (The virtual networks are implemented using software virtualization technologies (e.g., hypervisors, functions performed by network virtualization devices (NVDs) (e.g., smartNICs), top-of-rack (TOR) switches, smart TORs that implement one or more functions performed by an NVD, and other mechanisms) to create layers of network abstraction that can be run on top of the physical network.) [Brar: col. 4, line 12-19; Figs. 2-9] , the plurality of switches comprising a plurality of ports ((As shown in FIG. 2, an NVD may comprise multiple physical ports that enable it to be connected to one or more host machines and to one or more TOR switches. A port on an NVD can be classified as a host-facing port (also referred to as a "south port") or a network-facing or TOR facing port (also referred to as a "north port"). A host-facing port of an NVD is a port that is used to connect the NVD to 40 a host machine. Examples of host-facing ports in FIG. 2 include port 236 on NVD 210, and ports 248 and 254 on NVD 212. A network-facing port of an NVD is a port that is used to connect the NVD to a TOR switch. Examples of network-facing ports in FIG. 2 include port 256 on NVD 210, and port 258 on NVD 212. As shown in FIG. 2, NVD 210 is connected to TOR switch 214 using link 228 that extends from port 256 of NVD 210 to the TOR switch 214. Likewise, NVD 212 is connected to TOR switch 216 using link 230 that extends from port 258 ofNVD 212 to the TOR 50 switch 216) [Brar: col. 21, line 34-51; Fig. 2]; (Ports 306 and 308 may be Ethernet ports and the links 320 and 322 between host machine 302 and NVDs 310 and 312 may be Ethernet links. NVD 310 is in turn connected to a first TOR switch 314 and NVD 312 is connected to a second TOR switch 316. The links between NVDs 310 and 312, and TOR switches 314 and 316 may be Ethernet links. TOR switches 314 and 316 represent the Tier-0 switching devices in multi-tiered physical network 318) [Brar: col. 20, line 37-45; Fig. 3] , each host machine in the plurality of host machines comprising one or more GPUs (Each host machine includes a plurality of graphical processing units (GPUs). For example, as shown in FIG. 6, Host machine 1-A 612 includes N GPUs) [Brar: col. 28, line 17-19; Fig. 6] , associating a first subset of ports from the plurality of ports ((Each host machine includes a plurality of graphical processing units (GPUs). For example, as shown in FIG. 6, Host machine 1-A 612 includes N GPUs e.g., GPU 1, 613. Moreover, it is appreciated that the illustration in FIG. 6 (of having each host machine including the same number of GPUs, i.e., N GPUs), is intended to be illustrative and non-limiting i.e., each host machine can include a different number of GPUs. Each rack includes a top of rack (TOR) switch that is communicatively coupled with the GPUs hosted on the host machines. For example, rack 1 610 includes a TOR switch (i.e., TOR 1) 616 that is communicatively coupled to Host 1-A, 612 and Host 1-K, 614, and rack M 620 includes a TOR switch (i.e., TOR M) 626 that is communicatively coupled to Host M-A, 622 and Host M-K, 624. It is appreciated that the TOR switches depicted in FIG. 6 (i.e., TOR 1 616, and TORM 626), each include N ports that are used to communicatively couple the TOR switch to the N GPUs hosted on each host machine included in the rack. The coupling of TOR switches to the GPUs as depicted in FIG. 6 is intended to be illustrative and nonlimiting. For instance, in some embodiments, the TOR switch may have a plurality of ports, each of which corresponds to a GPU on each host machine i.e., a GPU on a host machine may be connected to a unique port of the TOR via a communication link. Moreover, traffic received by a network device (e.g., TOR 1 616) is characterized herein as traffic received on a particular incoming port-link of the network device. For example, when GPU 1 613 of Host 1-A 612 transmits a data packet to TOR 1 616 (using link 617), the data packet is received on port 619 of the TOR 1 switch. TOR 1 616 characterizes this data packet as information received on a first incoming port-link of the TOR. It is appreciated that a similar notion can be applied to all outgoing port-links of the TOR) [Brar: col. 28, line 16-51; Fig. 6]; (A host machine may include one or more network interface cards (NIC) that enable the host machine to be connected to other devices. A NIC on a host machine may provide one or more ports ( or interfaces) that enable the host machine to be communicatively connected to another device. For example, a host machine may be connected to an NVD using one or more ports ( or interfaces) provided on the host machine and on the NVD. A host machine may also be connected to other devices such as another host machine) [Brar: col. 19, line 42-50; Fig. 3] with a first virtual plane (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 )) [Brar: col. 5, line 47-51; Please see the control plane in Figs. 12-15] , the first virtual plane identifying a first collection of resources (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) [Brar: col. 5, line 51-64; Please see the control plane in Figs. 12-15] to be exclusively used for communicating packets from and to host machines associated with the first virtual plane (Each compute instance is associated with a virtual network interface card (VNIC) that enables the compute instance to participate in a subnet of a VCN. A VNIC is a logical representation of physical Network Interface Card (NIC). In general, a VNIC is an interface between an entity ( e.g., a compute instance, a service) and a virtual network. A VNIC exists in a subnet, has one or more associated IP addresses, and associated security rules or policies. A VNIC is equivalent to a Layer-2 port on a switch. A VNIC is attached to a compute instance and to a subnet within a VCN. A VNIC associated with a compute instance enables the compute instance to be a part of a subnet of a VCN and enables the compute instance to communicate (e.g., send and receive packets) with endpoints that are on the same subnet as the compute instance, with endpoints in different subnets in the VCN, or with endpoints outside the VCN. The VNIC associated with a compute instance thus determines how the compute instance connects with endpoints inside and outside the VCN. A VNIC for a compute instance is created and associated with that compute instance when the compute instance is created and added to a subnet within a VCN. For a subnet comprising a set of compute instances, the subnet contains the VNICs corresponding to the set of compute instances, each VNIC attached to a compute instance within the set of computer instances) [Brar: col. 8, line 47 - col. 9, line 4] ; associating a second subset of ports from the plurality of ports (In one embodiment, there is one VCN VR for a VCN where the VCN VR has potentially an unlimited number of ports addressed by IP addresses, with one port for each subnet of the VCN. In this manner, the VCN VR has a different IP address for each subnet in the VCN that the VCN VR is attached to. The VR is also connected to the various gateways configured for a VCN. In certain embodiments, a particular overlay IP address from the overlay IP address range for a subnet is reserved for a port of the VCN VR for that subnet. For example, consider a VCN having two subnets with associated address ranges 10.0/16 and 10.1/16, respectively. For the first subnet within the VCN with address range 10.0/16, an address from this range is reserved for a port of the VCN VR for that subnet. In some instances, the first IP address from the range may be reserved for the VCN VR. For example, for the subnet with overlay IP address range 10.0/16, IP address 10.0.0.1 may be reserved for a port of the VCN VR for that subnet. For the second subnet within the same VCN with address range 10.1/16, the VCN VR may have a port for that second subnet with IP address 10.1.0.1. The VCN VR has a different IP address for each of the subnets in the VCN) [Brar: col. 9, line 59 - col. 10, line 14] with a second virtual plane that is different from the first virtual plane (A customer can set up one or more virtual cloud networks (VCNs) using CSPI resources allocated for the customer. A VCN is a virtual or software defined private network. The customer resources that are deployed in the customer's VCN can include compute instances ( e.g., virtual machines, bare-metal instances) and other resources. These compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. A compute instance deployed on a VCN can communicate with public accessible endpoints ("public endpoints") over a public network such as the Internet, with other instances in the same VCN or other VCNs (e.g., the customer's other VCNs, or VCNs not belonging to the customer), with the customer's on-premise data centers or networks, and with service endpoints, and other types of endpoints.) [Brar: col. 7, line 52-67] ; associating a first host machine and a second host machine from the plurality of host machines to the first virtual plane (The compute instances in a subnet may be hosted by one or more host machines within CSPI 101. A compute instance participates in a subnet via a VNIC associated with the compute instance. For example, as shown in FIG. 1, a compute instance C1 is part of Subnet-1 via a VNIC associated with the compute instance. Likewise, compute instance C2 is part of Subnet-1 via a VNIC associated with C2. In a similar manner, multiple compute instances, which may be virtual machine instances or bare metal instances, may be part of Subnet-1. Via its associated VNIC, each compute instance is assigned a private overlay IP address and a MAC address. For example, in FIG. 1, compute instance Cl has an overlay IP address of 10.0.0.2 and a MAC address of M1, while compute instance C2 has a private overlay IP address of 10.0.0.3 and a MAC address ofM2. Each compute instance in Subnet-I, including compute instances Cl and C2, has a default route to VCN VR 105 using IP address 10.0.0.1, which is the IP address for a port of VCN VR 105 for Subnet-1) [Brar: col. 12, line 5-24] ; and for a packet originating at a first GPU on the first host machine (The VCN CP also sends VCN data mappings to the VCN data plane that is configured to perform packet forwarding and routing functions. In certain embodiments, the VCN CP provides a distribution service that is responsible for providing updates to the VCN data plane. Examples of a VCN Control Plane are also depicted in FIGS. 12, 13, 14, and 15 (see references 1216, 1316, 1416, and 1516) and described below) [Brar: col. 11, line 16-23] and destined for a second GPU on the second host machine (Communications between compute instances on the same subnet are facilitated using VNICs associated with the source compute instance and the destination compute instance. For example, compute instance C1 in Subnet-1 may want to send packets to compute instance C2 in Subnet-1. For a packet originating at a source compute instance and whose destination is another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. Processing performed by the VNIC associated with the source compute instance can include determining destination information for the packet from the packet headers, identifying any policies (e.g., security lists) configured for the VNIC associated with the source compute instance, determining a next hop for the packet, performing any packet encapsulation / decapsulation functions as needed, and then forwarding/routing the packet to the next hop with the goal of facilitating communication of the packet to its intended destination) [Brar: col. 13, line 1-18] , communicating the packet from the first GPU on the first host machine to the second GPU on the second host machine using only ports from the first subset of ports (Communications between compute instances on the same subnet are facilitated using VNICs associated with the source compute instance and the destination compute instance. For example, compute instance C1 in Subnet-1 may want to send packets to compute instance C2 in Subnet-1. For a packet originating at a source compute instance and whose destination is another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. Processing performed by the VNIC associated with the source compute instance can include determining destination information for the packet from the packet headers, identifying any policies (e.g., security lists) configured for the VNIC associated with the source compute instance, determining a next hop for the packet, performing any packet encapsulation / decapsulation functions as needed, and then forwarding/routing the packet to the next hop with the goal of facilitating communication of the packet to its intended destination When the destination compute instance is in the same subnet as the source compute instance, the VNIC associated with the source compute instance is configured to identify the VNIC associated with the destination compute instance and forward the packet to that VNIC for processing. The VNIC associated with the destination compute instance is then executed and forwards the packet to the destination compute instance) [Brar: col. 13, line 1-25]. Regarding claims 2, 11, and 20 , Brar meets the claim limitations as set forth in claims 1, 10, and 19. Brar further meets the claim limitations as follow. wherein the plurality of switches is arranged in a hierarchical structure including a first tier of switches, a second tier of switches, and a third tier of switches (A Clos network is a type of nonblocking, 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.) [Brar: col. 27, line 1-5; Fig. 5] , wherein the plurality of host machines is directly coupled to (FIG. 6 depicts a block diagram of a cloud infrastructure 600 incorporating a CLOS network arrangement, according to certain embodiments. The cloud infrastructure 600 includes a plurality of racks (e.g., rack 1 610 ... rack M, 620). Each rack includes a plurality of host machines (also referred to herein as hosts). For instance, rack 1 610 includes a plurality of hosts (e.g., K host machines) host 1-A, 612 to host 1-K, 614, and rack M includes K host machines i.e., Host M-A, 622 to Host M-K, 624. It is appreciated that the illustration of FIG. 6 (i.e., each rack including the same number of host machines e.g., K host machines) is intended to be illustrative and non-limiting. For instance, rack M, 620 may have a higher or lower number of host machines as 15 compared to the number of host machines included in rack 1, 610) [Brar: col. 28, line 1-16; Fig. 6] switches included in the first tier of switches (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) [Brar: col. 27, line 5-8; Fig. 5] , and wherein the second tier of switches communicatively couples the first tier of switches to the third tier of switches (The Tier-0 switches are connected to Tier-1 switches, which are also referred to as leaf switches. In the embodiment depicted in FIG. 5, 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.) [Brar: col. 27, line 10-18] . Regarding claims 3 and 12 , Brar meets the claim limitations as set forth in claims 2 and 11. Brar further meets the claim limitations as follow. wherein a subset of host machines included in the plurality of host machines are directly coupled to a first switch ((Each host machine includes a plurality of graphical proascessing units (GPUs). For example, as shown in FIG. 6, Host machine 1-A 612 includes N GPUs e.g., GPU 1, 613. Moreover, it is appreciated that the illustration in FIG. 6 (of having each host machine including the same number of GPUs, i.e., N GPUs), is intended to be illustrative and non-limiting i.e., each host machine can include a different number of GPUs. Each rack includes a top of rack (TOR) switch that is communicatively coupled with the GPUs hosted on the host machines. For example, rack 1 610 includes a TOR switch (i.e., TOR 1) 616 that is communicatively coupled to Host 1-A, 612 and Host 1-K, 614, and rack M 620 includes a TOR switch (i.e., TOR M) 626 that is communicatively coupled to Host M-A, 622 and Host M-K, 624. It is appreciated that the TOR switches depicted in FIG. 6 (i.e., TOR 1 616, and TORM 626), each include N ports that are used to communicatively couple the TOR switch to the N GPUs hosted on each host machine included in the rack. The coupling of TOR switches to the GPUs as depicted in FIG. 6 is intended to be illustrative and nonlimiting. For instance, in some embodiments, the TOR switch may have a plurality of ports, each of which corresponds to a GPU on each host machine i.e., a GPU on a host machine may be connected to a unique port of the TOR via a communication link. Moreover, traffic received by a network device (e.g., TOR 1 616) is characterized herein as traffic received on a particular incoming port-link of the network device. For example, when GPU 1 613 of Host 1-A 612 transmits a data packet to TOR 1 616 (using link 617), the data packet is received on port 619 of the TOR 1 switch. TOR 1 616 characterizes this data packet as information received on a first incoming port-link of the TOR. It is appreciated that a similar notion can be applied to all outgoing port-links of the TOR) [Brar: col. 28, line 16-51; Fig. 6] included in the first tier of switches ( 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) [Brar: col. 27, line 5-8; Fig. 5] , each host machine in the subset of host machines being associated to a different virtual plane ( The TOR switches from each rack are communicatively coupled to a plurality of spine switches e.g., spine switch 1, 630 and spine switch P 640. As shown in FIG. 6, TOR 1, 616 is connected to spine switch 1 630 via two links, and to spine switch P 640 via another two links, respectively. Information transmitted from a particular TOR switch to a spine switch is referred to herein as communication conducted via uplinks, whereas information transmitted from a spine switch to a TOR switch is referred to herein as communication conducted via downlinks. According to some embodiments, the TOR switches and the spine switches are connected in a CLOS network arrangement (e.g., a multi-stage switching network), where each TOR switch forms a 'leaf' node in the CLOS network.) [Brar: col. 28, line 52-65; Fig. 6]; ( GPU on a host machine may be connected to a unique port of the TOR via a communication link ) [Brar: col. 28, line 40-42; Fig. 6] . Regarding claims 4 and 13 , Brar meets the claim limitations as set forth in claims 3 and 12. Brar further meets the claim limitations as follow. wherein a number of virtual planes supported by the network fabric corresponds to a number of host machines (The cloud services provider infrastructure (CSPI) may comprise interconnected high-performance compute resources including various host machines, memory resources, and network resources that form a physical network, which is also referred to as a substrate network or an underlay network) [Brar: col. 3, line 64 – col. 4, line 1; Figs. 5-9] included in the subset of host machines (Each compute instance is associated with a virtual network interface card (VNIC) that enables the compute instance to participate in a subnet of a VCN. A VNIC is a logical representation of physical Network Interface Card (NIC). In general, a VNIC is an interface between an entity ( e.g., a compute instance, a service) and a virtual network. A VNIC exists in a subnet, has one or more associated IP addresses, and associated security rules or policies. A VNIC is equivalent to a Layer-2 port on a switch. A VNIC is attached to a compute instance and to a subnet within a VCN. A VNIC associated with a compute instance enables the compute instance to be a part of a subnet of a VCN and enables the compute instance to communicate (e.g., send and receive packets) with endpoints that are on the same subnet as the compute instance, with endpoints in different subnets in the VCN, or with endpoints outside the VCN. The VNIC associated with a compute instance thus determines how the compute instance connects with endpoints inside and outside the VCN. A VNIC for a compute instance is created and associated with that compute instance when the compute instance is created and added to a subnet within a VCN. For a subnet comprising a set of compute instances, the subnet contains the VNICs corresponding to the set of compute instances, each VNIC attached to a compute instance within the set of computer instances) [Brar: col. 8, line 47 - col. 9, line 4] that are directly coupled to the first switch (The host machines are communicatively coupled to different network fabrics via different TOR switches. For instance, host machines 1010 and 1020 are communicatively coupled to a network fabric (referred to herein as a front-end network of the rack 1000) via a TOR switch i.e., TOR 1 switch 1050. The front-end network may correspond to an external network. More specifically, the host machine 1010 is connected to the front-end network, via a network interface card (NIC) 1030 and a network virtualization device (NVD) 1035, which is coupled to the TOR 1 switch 1050. The host machine 1020 is connected to the front-end network via a NIC 1040 and a NVD 1045, which is coupled to the TOR 1 switch 1050. Thus, by some embodiments, the CPUs of each host machine may communicate with the front-end network via the NIC, NVD, and TOR switch. For example, CPUs 1012 of host machine 1010 may communicate with the front-end network via NIC 1030, NVD 1035, and TOR 1 switch 1050) [Brar: col. 33, line 4-21; Fig. 10] included in the first tier of switches (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) [Brar: col. 27, line 5-8; Fig. 5] . Regarding claims 5 and 14 , Brar meets the claim limitations as set forth in claims 1 and 10. Brar further meets the claim limitations as follow. wherein the first collection of resources associated with the first virtual plane include (The cloud services provider infrastructure (CSPI) may comprise interconnected high-performance compute resources including various host machines, memory resources, and network resources that form a physical network, which is also referred to as a substrate network or an underlay network. The resources in CSPI may be spread across one or more data centers that may be geographically spread across one or more geographical regions) [Brar: col. 3, line 64 – col. 4, line line 3; Figs. 5-9]; (A customer can set up one or more virtual cloud networks (VCNs) using CSPI resources allocated for the customer. A VCN is a virtual or software defined private network. The customer resources that are deployed in the customer's VCN can include compute instances ( e.g., virtual machines, bare-metal instances) and other resources. These compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. A compute instance deployed on a VCN can communicate with public accessible endpoints ("public endpoints") over a public network such as the Internet, with other instances in the same VCN or other VCNs (e.g., the customer's other VCNs, or VCNs not belonging to the customer), with the customer's on-premise data centers or networks, and with service endpoints, and other types of endpoints.) [Brar: col. 7, line 52-67]) : (i) a first subset of ports of each switch (As shown in FIG. 2, an NVD may comprise multiple physical ports that enable it to be connected to one or more host machines and to one or more TOR switches. A port on an NVD can be classified as a host-facing port (also referred to as a "south port") or a network-facing or TOR facing port (also referred to as a "north port"). A host-facing port of an NVD is a port that is used to connect the NVD to 40 a host machine. Examples of host-facing ports in FIG. 2 include port 236 on NVD 210, and ports 248 and 254 on NVD 212. A network-facing port of an NVD is a port that is used to connect the NVD to a TOR switch. Examples of network-facing ports in FIG. 2 include port 256 on NVD 210, and port 258 on NVD 212. As shown in FIG. 2, NVD 210 is connected to TOR switch 214 using link 228 that extends from port 256 of NVD 210 to the TOR switch 214. Likewise, NVD 212 is connected to TOR switch 216 using link 230 that extends from port 258 of NVD 212 to the TOR 50 switch 216) [Brar: col. 21, line 34-51; Fig. 2] included in the first tier of 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) [Brar: col. 27, line 7-9; Fig. 5]; Ports 306 and 308 may be Ethernet ports and the links 320 and 322 between host machine 302 and NVDs 310 and 312 may be Ethernet links. NVD 310 is in turn connected to a first TOR switch 314 and NVD 312 is connected to a second TOR switch 316. The links between NVDs 310 and 312, and TOR switches 314 and 316 may be Ethernet links. TOR switches 314 and 316 represent the Tier-0 switching devices in multi-tiered physical network 318) [Brar: col. 20, line 37-45; Figs. 3, 5]) , (ii) a first subset of switches included in the second tier of switches (The Tier-0 switches are connected to Tier-1 switches, which are also referred to as leaf switches. In the embodiment depicted in FIG. 5, 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) [Brar: col. 27, line 10-14; Fig. 5] , and (iii) a first subset of switches included in the third tier of switches (Each block is served by or connected to a set of "n" Tier-2 switches (sometimes referred to as spine switches)) [Brar: col. 27, line 15-16; Fig. 5] . Regarding claims 6 and 15 , Brar meets the claim limitations as set forth in claims 5 and 14. Brar further meets the claim limitations as follow. wherein the second virtual plane identifies a second collection of resources (A customer can set up one or more virtual cloud networks (VCNs) using CSPI resources allocated for the customer. A VCN is a virtual or software defined private network. The customer resources that are deployed in the customer's VCN can include compute instances ( e.g., virtual machines, bare-metal instances) and other resources. These compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. A compute instance deployed on a VCN can communicate with public accessible endpoints ("public endpoints") over a public network such as the Internet, with other instances in the same VCN or other VCNs (e.g., the customer's other VCNs, or VCNs not belonging to the customer), with the customer's on-premise data centers or networks, and with service endpoints, and other types of endpoints.) [Brar: col. 7, line 52-67] to be exclusively used for communicating packets from and to host machines associated with the second virtual plane (Each compute instance is associated with a virtual network interface card (VNIC) that enables the compute instance to participate in a subnet of a VCN. A VNIC is a logical representation of physical Network Interface Card (NIC). In general, a VNIC is an interface between an entity ( e.g., a compute instance, a service) and a virtual network. A VNIC exists in a subnet, has one or more associated IP addresses, and associated security rules or policies. A VNIC is equivalent to a Layer-2 port on a switch. A VNIC is attached to a compute instance and to a subnet within a VCN. A VNIC associated with a compute instance enables the compute instance to be a part of a subnet of a VCN and enables the compute instance to communicate (e.g., send and receive packets) with endpoints that are on the same subnet as the compute instance, with endpoints in different subnets in the VCN, or with endpoints outside the VCN. The VNIC associated with a compute instance thus determines how the compute instance connects with endpoints inside and outside the VCN. A VNIC for a compute instance is created and associated with that compute instance when the compute instance is created and added to a subnet within a VCN. For a subnet comprising a set of compute instances, the subnet contains the VNICs corresponding to the set of compute instances, each VNIC attached to a compute instance within the set of computer instances) [Brar: col. 8, line 47 - col. 9, line 4] , the second collection of resources associated with the second virtual plane include (A customer can set up one or more virtual cloud networks (VCNs) using CSPI resources allocated for the customer. A VCN is a virtual or software defined private network. The customer resources that are deployed in the customer's VCN can include compute instances ( e.g., virtual machines, bare-metal instances) and other resources. These compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. A compute instance deployed on a VCN can communicate with public accessible endpoints ("public endpoints") over a public network such as the Internet, with other instances in the same VCN or other VCNs (e.g., the customer's other VCNs, or VCNs not belonging to the customer), with the customer's on-premise data centers or networks, and with service endpoints, and other types of endpoints.) [Brar: col. 7, line 52-67] : (i) a second subset of ports of each switch (As shown in FIG. 2, an NVD may comprise multiple physical ports that enable it to be connected to one or more host machines and to one or more TOR switches. A port on an NVD can be classified as a host-facing port (also referred to as a "south port") or a network-facing or TOR facing port (also referred to as a "north port"). A host-facing port of an NVD is a port that is used to connect the NVD to 40 a host machine. Examples of host-facing ports in FIG. 2 include port 236 on NVD 210, and ports 248 and 254 on NVD 212. A network-facing port of an NVD is a port that is used to connect the NVD to a TOR switch. Examples of network-facing ports in FIG. 2 include port 256 on NVD 210, and port 258 on NVD 212. As shown in FIG. 2, NVD 210 is connected to TOR switch 214 using link 228 that extends from port 256 of NVD 210 to the TOR switch 214. Likewise, NVD 212 is connected to TOR switch 216 using link 230 that extends from port 258 of NVD 212 to the TOR 50 switch 216) [Brar: col. 21, line 34-51; Fig. 2] included in the first tier of 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) [Brar: col. 27, line 7-9; Fig. 5]; Ports 306 and 308 may be Ethernet ports and the links 320 and 322 between host machine 302 and NVDs 310 and 312 may be Ethernet links. NVD 310 is in turn connected to a first TOR switch 314 and NVD 312 is connected to a second TOR switch 316. The links between NVDs 310 and 312, and TOR switches 314 and 316 may be Ethernet links. TOR switches 314 and 316 represent the Tier-0 switching devices in multi-tiered physical network 318) [Brar: col. 20, line 37-45; Figs. 3, 5]) , (ii) a second subset of switches included in the second tier of switches (The Tier-0 switches are connected to Tier-1 switches, which are also referred to as leaf switches. In the embodiment depicted in FIG. 5, 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) [Brar: col. 27, line 10-14; Fig. 5] , and (iii) a second subset of switches included in the third tier of switches (Each block is served by or connected to a set of "n" Tier-2 switches (sometimes referred to as spine switches)) [Brar: col. 27, line 15-16; Fig. 5] . Regarding claims 7 and 16 , Brar meets the claim limitations as set forth in claims 6 and 15. Brar further meets the claim limitations as follow. wherein the second subset of ports of each switch included in the first tier of switches is different than the first subset of ports of each switch included in the first tier of switches (where the first incoming port-link of the network device is different than the second incoming port-link of the network device, and the first outgoing port-link of the network device is different than the second outgoing port-link of the network device) [Brar: col. 32, line 51-55; Fig. 7] , the second subset of switches included in the second tier of switches is different than the first subset of switches included in the second tier of switches ((The host machines are communicatively coupled to different network fabrics via different TOR switches) [Brar: col. 33, line 4-5; Fig. 10]; (In one embodiment, there is one VCN VR for a VCN where the VCN VR has potentially an unlimited number of ports addressed by IP addresses, with one port for each subnet of the VCN. In this manner, the VCN VR has a different IP address for each subnet in the VCN that the VCN VR is attached to. The VR is also connected to the various gateways configured for a VCN. In certain embodiments, a particular overlay IP address from the overlay IP address range for a subnet is reserved for a port of the VCN VR for that subnet. For example, consider a VCN having two subnets with associated address ranges 10.0/16 and 10.1/16, respectively. For the first subnet within the VCN with address range 10.0/16, an address from this range is reserved for a port of the VCN VR for that subnet. In some instances, the first IP address from the range may be reserved for the VCN VR. For example, for the subnet with overlay IP address range 10.0/16, IP address 10.0.0.1 may be reserved for a port of the VCN VR for that subnet. For the second subnet within the same VCN with address range 10.1/16, the VCN VR may have a port for that second subnet with IP address 10.1.0.1. The VCN VR has a different IP address for each of the subnets in the VCN) [Brar: col. 9, line 59 - col. 10, line 14]; (Turning now to FIG. 9, there is depicted a block diagram of a cloud infrastructure 900 illustrating different types of connections , according to certain embodiments. The infrastructure 900 includes a plurality of racks e.g., rack 1 910, rack D 920, and rack M, 930. Racks 910 and 930 include a plurality of host machines. For instance, rack 1 910 includes a plurality of hosts (e.g., K host machines) Host 1-A, 912 to Host 1-K, 914, and rack M includes K host machines i.e., Host M-A, 932 to Host M-K, 934. Rack D 920 includes one or more host machines 922, each of which include a plurality of CPUs i.e., the host machine 922 is a non-GPU host machine. Each of the racks 910,920, and 930 include a TOR switch i.e., TOR 1, 916, TOR D 926, and TOR M 936 , respectively that are communicatively coupled to the host machines in the respective racks. Further, the TOR switches 916, 926, and 936 are communicatively coupled to a plurality of spine switches i.e., spine switches 940 and 950) [Brar: col. 31, line 49-65; Fig. 9]) , and the second subset of switches included in the third tier of switches is different than the first subset of switches included in the third tier of switches ((The host machines are communicatively coupled to different network fabrics via different TOR switches) [Brar: col. 33, line 4-5; Fig. 10]; (In one embodiment, there is one VCN VR for a VCN where the VCN VR has potentially an unlimited number of ports addressed by IP addresses, with one port for each subnet of the VCN. In this manner, the VCN VR has a different IP address for each subnet in the VCN that the VCN VR is attached to. The VR is also connected to the various gateways configured for a VCN. In certain embodiments, a particular overlay IP address from the overlay IP address range for a subnet is reserved for a port of the VCN VR for that subnet. For example, consider a VCN having two subnets with associated address ranges 10.0/16 and 10.1/16, respectively. For the first subnet within the VCN with address range 10.0/16, an address from this range is reserved for a port of the VCN VR for that subnet. In some instances, the first IP address from the range may be reserved for the VCN VR. For example, for the subnet with overlay IP address range 10.0/16, IP address 10.0.0.1 may be reserved for a port of the VCN VR for that subnet. For the second subnet within the same VCN with address range 10.1/16, the VCN VR may have a port for that second subnet with IP address 10.1.0.1. The VCN VR has a different IP address for each of the subnets in the VCN) [Brar: col. 9, line 59 - col. 10, line 14]; (Turning now to FIG. 9, there is depicted a block diagram of a cloud infrastructure 900 illustrating different types of connections , according to certain embodiments. The infrastructure 900 includes a plurality of racks e.g., rack 1 910, rack D 920, and rack M, 930. Racks 910 and 930 include a plurality of host machines. For instance, rack 1 910 includes a plurality of hosts (e.g., K host machines) Host 1-A, 912 to Host 1-K, 914, and rack M includes K host machines i.e., Host M-A, 932 to Host M-K, 934. Rack D 920 includes one or more host machines 922, each of which include a plurality of CPUs i.e., the host machine 922 is a non-GPU host machine. Each of the racks 910,920, and 930 include a TOR switch i.e., TOR 1, 916, TOR D 926, and TOR M 936 , respectively that are communicatively coupled to the host machines in the respective racks. Further, the TOR switches 916, 926, and 936 are communicatively coupled to a plurality of spine switches i.e., spine switches 940 and 950) [Brar: col. 31, line 49-65; Fig. 9]). Regarding claims 8 and 17 , Brar meets the claim limitations as set forth in claims 1 and 10. Brar further meets the claim limitations as follow. wherein the first GPU on the first host machine associated with the first virtual plane cannot communicate with a third GPU on a third host machine associated with the second virtual plane ((The CSPI may include components in the physical or substrate network and virtualized components (e.g., virtual networks, compute instances, virtual machines, etc.) that are in a virtual network built on top of the physical network components. In certain embodiments, the CSPI is organized and hosted in realms, regions and availability domains. A region is typically a localized geographic area that contains one or more data centers. Regions are generally independent of each other and can be separated by vast distances, for example, across countries or even continents.) [Brar: col. 6, line 9-19]; (In certain embodiments, regions are grouped into realms . A realm is a logical collection of regions. Realms are isolated from each other and do not share any data. Regions in the same realm may communicate with each other, but regions in different realms cannot . A customer's tenancy or account with the CSP exists in a single realm and can be spread across one or more regions that belong to that realm. Typically, when a customer subscribes to an IaaS service, a tenancy or account is created for that customer in the customer-specified region (referred to as the "home" region) within a realm. A customer can extend the customer's tenancy across one or more other regions within the realm. A customer cannot access regions that are not in the realm where the customer's tenancy exists ) [Brar: col. 7, line 3-16] . – Note: Brar discloses an architecture that a customer from one realm cannot access to another realm. Hence a GPU of a host machine associated with a virtual plane in a certain realm cannot access to another GPU of another host machine associated with a different virtual plane in another realm. As a result, Brar disclose the claim limitations). Regarding claims 9 and 18 , Brar meets the claim limitations as set forth in claims 1 and 10. Brar further meets the claim limitations as follow. wherein the first virtual plane includes a plurality of traffic paths, each traffic path originating at a source host machine and terminating at a destination host machine, the source host machine and the destination host machine being assigned to the first virtual plane (As shown in the embodiment depicted in FIG. 1, a Dynamic Routing Gateway (DRG) 122 may be added to or be associated with customer VCN 104 and provides a path for private network traffic communication between customer VCN 104 and another endpoint, where the another endpoint can be the customer's on-premise network 116, a VCN 108 in a different region of CSPI 101, or other remote cloud networks 118 not hosted by CSPI 101) [Brar: col. 14, line 16-23] , and wherein each traffic path utilizes a unique set of resources from the first collection of resources in the network fabric (Various different types of gateways may be configured for 10 a VCN. Examples of gateways that may be configured for a VCN are depicted in FIG. 1 and described below. Examples of gateways associated with a VCN are also depicted in FIGS. 12, 13, 14, and 15 (for example, gateways referenced by reference numbers 1234, 1236, 1238, 1334, 1336, 1338, 1434, 1436, 1438, 1534, 1536, and 1538) and described below. As shown in the embodiment depicted in FIG. 1, a Dynamic Routing Gateway (DRG) 122 may be added to or be associated with customer VCN 104 and provides a path for private network traffic communication between customer VCN 104 and another endpoint, where the another endpoint can be the customer's on-premise network 116, a VCN 108 in a different region of CSPI 101, or other remote cloud networks 118 not hosted by CSPI 101. Customer on-premise network 116 may be a customer network or a customer data center built using the customer's resources. Access to customer on-premise network 116 is generally very restricted. For a customer that has both a customer on-premise network 116 and one or more VCNs 104 deployed or hosted in the cloud by CSPI 101, the customer may want their on-premise network 116 and their cloud-based VCN 104 to be able to communicate with each other. This enables a customer to build an extended hybrid environment encompassing the customer's VCN 104 hosted by CSPI 101 and their on-premises network 116. DRG 122 enables this communication To enable such communications, a communication channel 124 is set up where one endpoint of the channel is in customer on-premise network 116 and the other endpoint is in CSPI 101 and connected to customer VCN 104. Communication channel 124 can be over public communication networks such as the Internet or private communication networks. Various different communication protocols may be used such as IPsec VPN technology over a public communication network such as the Internet, Oracle's Fast-Connect technology that uses a private network instead of a 45 public network, and others. The device or equipment in customer on-premise network 116 that forms one end point for communication channel 124 is referred to as the customer premise equipment (CPE), such as CPE 126 depicted in FIG. 1. On the CSPI 101 side, the endpoint may be a host machine executing DRG 122) [Brar: col. 14, line 9-50] . Regarding claim 10, Brar meets the claim limitations as follows: One or more computer readable non-transitory media storing computer-executable instructions that, when executed by one or more processors, cause (The systems, subsystems, and other components depicted in FIG. 2 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units ( e.g., processors, cores) of the respective systems, using hardware, or combinations thereof. The software may be stored on a non-transitory storage medium ( e.g., on a memory device)) [Brar: col. 26, line 10-16] :in a network environment comprising a plurality of host machines (The cloud services provider infrastructure (CSPI) may comprise interconnected high-performance compute resources including various host machines, memory resources, and network resources that form a physical network, which is also referred to as a substrate network or an underlay network. The resources in CSPI may be spread across one or more data centers that may be geographically spread across one or more geographical regions) [Brar: col. 3, line 64 – col. 4, line line 3; Figs. 5-9] that are communicatively coupled to each other via a network fabric (The host machines are communicatively coupled to different network fabrics via different TOR switches) [Brar: col. 33, line 4-5; Fig. 10] comprising a plurality of switches (The virtual networks are implemented using software virtualization technologies (e.g., hypervisors, functions performed by network virtualization devices (NVDs) (e.g., smartNICs), top-of-rack (TOR) switches, smart TORs that implement one or more functions performed by an NVD, and other mechanisms) to create layers of network abstraction that can be run on top of the physical network.) [Brar: col. 4, line 12-19; Figs. 2-9] , the plurality of switches comprising a plurality of ports ((As shown in FIG. 2, an NVD may comprise multiple physical ports that enable it to be connected to one or more host machines and to one or more TOR switches. A port on an NVD can be classified as a host-facing port (also referred to as a "south port") or a network-facing or TOR facing port (also referred to as a "north port"). A host-facing port of an NVD is a port that is used to connect the NVD to 40 a host machine. Examples of host-facing ports in FIG. 2 include port 236 on NVD 210, and ports 248 and 254 on NVD 212. A network-facing port of an NVD is a port that is used to connect the NVD to a TOR switch. Examples of network-facing ports in FIG. 2 include port 256 on NVD 210, and port 258 on NVD 212. As shown in FIG. 2, NVD 210 is connected to TOR switch 214 using link 228 that extends from port 256 of NVD 210 to the TOR switch 214. Likewise, NVD 212 is connected to TOR switch 216 using link 230 that extends from port 258 ofNVD 212 to the TOR 50 switch 216) [Brar: col. 21, line 34-51; Fig. 2]; (Ports 306 and 308 may be Ethernet ports and the links 320 and 322 between host machine 302 and NVDs 310 and 312 may be Ethernet links. NVD 310 is in turn connected to a first TOR switch 314 and NVD 312 is connected to a second TOR switch 316. The links between NVDs 310 and 312, and TOR switches 314 and 316 may be Ethernet links. TOR switches 314 and 316 represent the Tier-0 switching devices in multi-tiered physical network 318) [Brar: col. 20, line 37-45; Fig. 3] , each host machine in the plurality of host machines comprising one or more GPUs (Each host machine includes a plurality of graphical processing units (GPUs). For example, as shown in FIG. 6, Host machine 1-A 612 includes N GPUs) [Brar: col. 28, line 17-19; Fig. 6] , associating a first subset of ports from the plurality of ports ((Each host machine includes a plurality of graphical processing units (GPUs). For example, as shown in FIG. 6, Host machine 1-A 612 includes N GPUs e.g., GPU 1, 613. Moreover, it is appreciated that the illustration in FIG. 6 (of having each host machine including the same number of GPUs, i.e., N GPUs), is intended to be illustrative and non-limiting i.e., each host machine can include a different number of GPUs. Each rack includes a top of rack (TOR) switch that is communicatively coupled with the GPUs hosted on the host machines. For example, rack 1 610 includes a TOR switch (i.e., TOR 1) 616 that is communicatively coupled to Host 1-A, 612 and Host 1-K, 614, and rack M 620 includes a TOR switch (i.e., TOR M) 626 that is communicatively coupled to Host M-A, 622 and Host M-K, 624. It is appreciated that the TOR switches depicted in FIG. 6 (i.e., TOR 1 616, and TORM 626), each include N ports that are used to communicatively couple the TOR switch to the N GPUs hosted on each host machine included in the rack. The coupling of TOR switches to the GPUs as depicted in FIG. 6 is intended to be illustrative and nonlimiting. For instance, in some embodiments, the TOR switch may have a plurality of ports, each of which corresponds to a GPU on each host machine i.e., a GPU on a host machine may be connected to a unique port of the TOR via a communication link. Moreover, traffic received by a network device (e.g., TOR 1 616) is characterized herein as traffic received on a particular incoming port-link of the network device. For example, when GPU 1 613 of Host 1-A 612 transmits a data packet to TOR 1 616 (using link 617), the data packet is received on port 619 of the TOR 1 switch. TOR 1 616 characterizes this data packet as information received on a first incoming port-link of the TOR. It is appreciated that a similar notion can be applied to all outgoing port-links of the TOR) [Brar: col. 28, line 16-51; Fig. 6]; (A host machine may include one or more network interface cards (NIC) that enable the host machine to be connected to other devices. A NIC on a host machine may provide one or more ports ( or interfaces) that enable the host machine to be communicatively connected to another device. For example, a host machine may be connected to an NVD using one or more ports ( or interfaces) provided on the host machine and on the NVD. A host machine may also be connected to other devices such as another host machine) [Brar: col. 19, line 42-50; Fig. 3] with a first virtual plane (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)) [Brar: col. 5, line 47-51; Please see the control plane in Figs. 12-15] , the first virtual plane identifying a first collection of resources (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) [Brar: col. 5, line 51-64; Please see the control plane in Figs. 12-15] to be exclusively used for communicating packets from and to host machines associated with the first virtual plane (Each compute instance is associated with a virtual network interface card (VNIC) that enables the compute instance to participate in a subnet of a VCN. A VNIC is a logical representation of physical Network Interface Card (NIC). In general, a VNIC is an interface between an entity ( e.g., a compute instance, a service) and a virtual network. A VNIC exists in a subnet, has one or more associated IP addresses, and associated security rules or policies. A VNIC is equivalent to a Layer-2 port on a switch. A VNIC is attached to a compute instance and to a subnet within a VCN. A VNIC associated with a compute instance enables the compute instance to be a part of a subnet of a VCN and enables the compute instance to communicate (e.g., send and receive packets) with endpoints that are on the same subnet as the compute instance, with endpoints in different subnets in the VCN, or with endpoints outside the VCN. The VNIC associated with a compute instance thus determines how the compute instance connects with endpoints inside and outside the VCN. A VNIC for a compute instance is created and associated with that compute instance when the compute instance is created and added to a subnet within a VCN. For a subnet comprising a set of compute instances, the subnet contains the VNICs corresponding to the set of compute instances, each VNIC attached to a compute instance within the set of computer instances) [Brar: col. 8, line 47 - col. 9, line 4] ; associating a second subset of ports from the plurality of ports (In one embodiment, there is one VCN VR for a VCN where the VCN VR has potentially an unlimited number of ports addressed by IP addresses, with one port for each subnet of the VCN. In this manner, the VCN VR has a different IP address for each subnet in the VCN that the VCN VR is attached to. The VR is also connected to the various gateways configured for a VCN. In certain embodiments, a particular overlay IP address from the overlay IP address range for a subnet is reserved for a port of the VCN VR for that subnet. For example, consider a VCN having two subnets with associated address ranges 10.0/16 and 10.1/16, respectively. For the first subnet within the VCN with address range 10.0/16, an address from this range is reserved for a port of the VCN VR for that subnet. In some instances, the first IP address from the range may be reserved for the VCN VR. For example, for the subnet with overlay IP address range 10.0/16, IP address 10.0.0.1 may be reserved for a port of the VCN VR for that subnet. For the second subnet within the same VCN with address range 10.1/16, the VCN VR may have a port for that second subnet with IP address 10.1.0.1. The VCN VR has a different IP address for each of the subnets in the VCN) [Brar: col. 9, line 59 - col. 10, line 14] with a second virtual plane that is different from the first virtual plane (A customer can set up one or more virtual cloud networks (VCNs) using CSPI resources allocated for the customer. A VCN is a virtual or software defined private network. The customer resources that are deployed in the customer's VCN can include compute instances ( e.g., virtual machines, bare-metal instances) and other resources. These compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. A compute instance deployed on a VCN can communicate with public accessible endpoints ("public endpoints") over a public network such as the Internet, with other instances in the same VCN or other VCNs (e.g., the customer's other VCNs, or VCNs not belonging to the customer), with the customer's on-premise data centers or networks, and with service endpoints, and other types of endpoints.) [Brar: col. 7, line 52-67] ; associating a first host machine and a second host machine from the plurality of host machines to the first virtual plane (The compute instances in a subnet may be hosted by one or more host machines within CSPI 101. A compute instance participates in a subnet via a VNIC associated with the compute instance. For example, as shown in FIG. 1, a compute instance C1 is part of Subnet-1 via a VNIC associated with the compute instance. Likewise, compute instance C2 is part of Subnet-1 via a VNIC associated with C2. In a similar manner, multiple compute instances, which may be virtual machine instances or bare metal instances, may be part of Subnet-1. Via its associated VNIC, each compute instance is assigned a private overlay IP address and a MAC address. For example, in FIG. 1, compute instance Cl has an overlay IP address of 10.0.0.2 and a MAC address of M1, while compute instance C2 has a private overlay IP address of 10.0.0.3 and a MAC address ofM2. Each compute instance in Subnet-I, including compute instances Cl and C2, has a default route to VCN VR 105 using IP address 10.0.0.1, which is the IP address for a port of VCN VR 105 for Subnet-1) [Brar: col. 12, line 5-24] ; and for a packet originating at a first GPU on the first host machine (The VCN CP also sends VCN data mappings to the VCN data plane that is configured to perform packet forwarding and routing functions. In certain embodiments, the VCN CP provides a distribution service that is responsible for providing updates to the VCN data plane. Examples of a VCN Control Plane are also depicted in FIGS. 12, 13, 14, and 15 (see references 1216, 1316, 1416, and 1516) and described below) [Brar: col. 11, line 16-23] and destined for a second GPU on the second host machine (Communications between compute instances on the same subnet are facilitated using VNICs associated with the source compute instance and the destination compute instance. For example, compute instance C1 in Subnet-1 may want to send packets to compute instance C2 in Subnet-1. For a packet originating at a source compute instance and whose destination is another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. Processing performed by the VNIC associated with the source compute instance can include determining destination information for the packet from the packet headers, identifying any policies (e.g., security lists) configured for the VNIC associated with the source compute instance, determining a next hop for the packet, performing any packet encapsulation / decapsulation functions as needed, and then forwarding/routing the packet to the next hop with the goal of facilitating communication of the packet to its intended destination) [Brar: col. 13, line 1-18] , communicating the packet from the first GPU on the first host machine to the second GPU on the second host machine using only ports from the first subset of ports (Communications between compute instances on the same subnet are facilitated using VNICs associated with the source compute instance and the destination compute instance. For example, compute instance C1 in Subnet-1 may want to send packets to compute instance C2 in Subnet-1. For a packet originating at a source compute instance and whose destination is another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. Processing performed by the VNIC associated with the source compute instance can include determining destination information for the packet from the packet headers, identifying any policies (e.g., security lists) configured for the VNIC associated with the source compute instance, determining a next hop for the packet, performing any packet encapsulation / decapsulation functions as needed, and then forwarding/routing the packet to the next hop with the goal of facilitating communication of the packet to its intended destination When the destination compute instance is in the same subnet as the source compute instance, the VNIC associated with the source compute instance is configured to identify the VNIC associated with the destination compute instance and forward the packet to that VNIC for processing. The VNIC associated with the destination compute instance is then executed and forwards the packet to the destination compute instance) [Brar: col. 13, line 1-25]. Regarding claim 19, Brar meets the claim limitations as follows: A computing device comprising ( The systems ) [Brar: col. 26, line 10] : one or more processors ( one or more processing units ( e.g., processors, cores) of the respective systems ) [Brar: col. 26, line 12-13] ; and a memory including instructions that, when executed with the one or more processors, cause the computing device to, at least (The systems, subsystems, and other components depicted in FIG. 2 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units ( e.g., processors, cores) of the respective systems, using hardware, or combinations thereof. The software may be stored on a non-transitory storage medium ( e.g., on a memory device)) [Brar: col. 26, line 10-16] :in a network environment comprising a plurality of host machines (The cloud services provider infrastructure (CSPI) may comprise interconnected high-performance compute resources including various host machines, memory resources, and network resources that form a physical network, which is also referred to as a substrate network or an underlay network. The resources in CSPI may be spread across one or more data centers that may be geographically spread across one or more geographical regions) [Brar: col. 3, line 64 – col. 4, line line 3; Figs. 5-9] that are communicatively coupled to each other via a network fabric (The host machines are communicatively coupled to different network fabrics via different TOR switches) [Brar: col. 33, line 4-5; Fig. 10] comprising a plurality of switches (The virtual networks are implemented using software virtualization technologies (e.g., hypervisors, functions performed by network virtualization devices (NVDs) (e.g., smartNICs), top-of-rack (TOR) switches, smart TORs that implement one or more functions performed by an NVD, and other mechanisms) to create layers of network abstraction that can be run on top of the physical network.) [Brar: col. 4, line 12-19; Figs. 2-9] , the plurality of switches comprising a plurality of ports ((As shown in FIG. 2, an NVD may comprise multiple physical ports that enable it to be connected to one or more host machines and to one or more TOR switches. A port on an NVD can be classified as a host-facing port (also referred to as a "south port") or a network-facing or TOR facing port (also referred to as a "north port"). A host-facing port of an NVD is a port that is used to connect the NVD to 40 a host machine. Examples of host-facing ports in FIG. 2 include port 236 on NVD 210, and ports 248 and 254 on NVD 212. A network-facing port of an NVD is a port that is used to connect the NVD to a TOR switch. Examples of network-facing ports in FIG. 2 include port 256 on NVD 210, and port 258 on NVD 212. As shown in FIG. 2, NVD 210 is connected to TOR switch 214 using link 228 that extends from port 256 of NVD 210 to the TOR switch 214. Likewise, NVD 212 is connected to TOR switch 216 using link 230 that extends from port 258 ofNVD 212 to the TOR 50 switch 216) [Brar: col. 21, line 34-51; Fig. 2]; (Ports 306 and 308 may be Ethernet ports and the links 320 and 322 between host machine 302 and NVDs 310 and 312 may be Ethernet links. NVD 310 is in turn connected to a first TOR switch 314 and NVD 312 is connected to a second TOR switch 316. The links between NVDs 310 and 312, and TOR switches 314 and 316 may be Ethernet links. TOR switches 314 and 316 represent the Tier-0 switching devices in multi-tiered physical network 318) [Brar: col. 20, line 37-45; Fig. 3] , each host machine in the plurality of host machines comprising one or more GPUs (Each host machine includes a plurality of graphical processing units (GPUs). For example, as shown in FIG. 6, Host machine 1-A 612 includes N GPUs) [Brar: col. 28, line 17-19; Fig. 6] , associating a first subset of ports from the plurality of ports ((Each host machine includes a plurality of graphical processing units (GPUs). For example, as shown in FIG. 6, Host machine 1-A 612 includes N GPUs e.g., GPU 1, 613. Moreover, it is appreciated that the illustration in FIG. 6 (of having each host machine including the same number of GPUs, i.e., N GPUs), is intended to be illustrative and non-limiting i.e., each host machine can include a different number of GPUs. Each rack includes a top of rack (TOR) switch that is communicatively coupled with the GPUs hosted on the host machines. For example, rack 1 610 includes a TOR switch (i.e., TOR 1) 616 that is communicatively coupled to Host 1-A, 612 and Host 1-K, 614, and rack M 620 includes a TOR switch (i.e., TOR M) 626 that is communicatively coupled to Host M-A, 622 and Host M-K, 624. It is appreciated that the TOR switches depicted in FIG. 6 (i.e., TOR 1 616, and TORM 626), each include N ports that are used to communicatively couple the TOR switch to the N GPUs hosted on each host machine included in the rack. The coupling of TOR switches to the GPUs as depicted in FIG. 6 is intended to be illustrative and nonlimiting. For instance, in some embodiments, the TOR switch may have a plurality of ports, each of which corresponds to a GPU on each host machine i.e., a GPU on a host machine may be connected to a unique port of the TOR via a communication link. Moreover, traffic received by a network device (e.g., TOR 1 616) is characterized herein as traffic received on a particular incoming port-link of the network device. For example, when GPU 1 613 of Host 1-A 612 transmits a data packet to TOR 1 616 (using link 617), the data packet is received on port 619 of the TOR 1 switch. TOR 1 616 characterizes this data packet as information received on a first incoming port-link of the TOR. It is appreciated that a similar notion can be applied to all outgoing port-links of the TOR) [Brar: col. 28, line 16-51; Fig. 6]; (A host machine may include one or more network interface cards (NIC) that enable the host machine to be connected to other devices. A NIC on a host machine may provide one or more ports ( or interfaces) that enable the host machine to be communicatively connected to another device. For example, a host machine may be connected to an NVD using one or more ports ( or interfaces) provided on the host machine and on the NVD. A host machine may also be connected to other devices such as another host machine) [Brar: col. 19, line 42-50; Fig. 3] with a first virtual plane (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)) [Brar: col. 5, line 47-51; Please see the control plane in Figs. 12-15] , the first virtual plane identifying a first collection of resources (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) [Brar: col. 5, line 51-64; Please see the control plane in Figs. 12-15] to be exclusively used for communicating packets from and to host machines associated with the first virtual plane (Each compute instance is associated with a virtual network interface card (VNIC) that enables the compute instance to participate in a subnet of a VCN. A VNIC is a logical representation of physical Network Interface Card (NIC). In general, a VNIC is an interface between an entity ( e.g., a compute instance, a service) and a virtual network. A VNIC exists in a subnet, has one or more associated IP addresses, and associated security rules or policies. A VNIC is equivalent to a Layer-2 port on a switch. A VNIC is attached to a compute instance and to a subnet within a VCN. A VNIC associated with a compute instance enables the compute instance to be a part of a subnet of a VCN and enables the compute instance to communicate (e.g., send and receive packets) with endpoints that are on the same subnet as the compute instance, with endpoints in different subnets in the VCN, or with endpoints outside the VCN. The VNIC associated with a compute instance thus determines how the compute instance connects with endpoints inside and outside the VCN. A VNIC for a compute instance is created and associated with that compute instance when the compute instance is created and added to a subnet within a VCN. For a subnet comprising a set of compute instances, the subnet contains the VNICs corresponding to the set of compute instances, each VNIC attached to a compute instance within the set of computer instances) [Brar: col. 8, line 47 - col. 9, line 4] ; associating a second subset of ports from the plurality of ports (In one embodiment, there is one VCN VR for a VCN where the VCN VR has potentially an unlimited number of ports addressed by IP addresses, with one port for each subnet of the VCN. In this manner, the VCN VR has a different IP address for each subnet in the VCN that the VCN VR is attached to. The VR is also connected to the various gateways configured for a VCN. In certain embodiments, a particular overlay IP address from the overlay IP address range for a subnet is reserved for a port of the VCN VR for that subnet. For example, consider a VCN having two subnets with associated address ranges 10.0/16 and 10.1/16, respectively. For the first subnet within the VCN with address range 10.0/16, an address from this range is reserved for a port of the VCN VR for that subnet. In some instances, the first IP address from the range may be reserved for the VCN VR. For example, for the subnet with overlay IP address range 10.0/16, IP address 10.0.0.1 may be reserved for a port of the VCN VR for that subnet. For the second subnet within the same VCN with address range 10.1/16, the VCN VR may have a port for that second subnet with IP address 10.1.0.1. The VCN VR has a different IP address for each of the subnets in the VCN) [Brar: col. 9, line 59 - col. 10, line 14] with a second virtual plane that is different from the first virtual plane (A customer can set up one or more virtual cloud networks (VCNs) using CSPI resources allocated for the customer. A VCN is a virtual or software defined private network. The customer resources that are deployed in the customer's VCN can include compute instances ( e.g., virtual machines, bare-metal instances) and other resources. These compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. A compute instance deployed on a VCN can communicate with public accessible endpoints ("public endpoints") over a public network such as the Internet, with other instances in the same VCN or other VCNs (e.g., the customer's other VCNs, or VCNs not belonging to the customer), with the customer's on-premise data centers or networks, and with service endpoints, and other types of endpoints.) [Brar: col. 7, line 52-67] ; associating a first host machine and a second host machine from the plurality of host machines to the first virtual plane (The compute instances in a subnet may be hosted by one or more host machines within CSPI 101. A compute instance participates in a subnet via a VNIC associated with the compute instance. For example, as shown in FIG. 1, a compute instance C1 is part of Subnet-1 via a VNIC associated with the compute instance. Likewise, compute instance C2 is part of Subnet-1 via a VNIC associated with C2. In a similar manner, multiple compute instances, which may be virtual machine instances or bare metal instances, may be part of Subnet-1. Via its associated VNIC, each compute instance is assigned a private overlay IP address and a MAC address. For example, in FIG. 1, compute instance Cl has an overlay IP address of 10.0.0.2 and a MAC address of M1, while compute instance C2 has a private overlay IP address of 10.0.0.3 and a MAC address ofM2. Each compute instance in Subnet-I, including compute instances Cl and C2, has a default route to VCN VR 105 using IP address 10.0.0.1, which is the IP address for a port of VCN VR 105 for Subnet-1) [Brar: col. 12, line 5-24] ; and for a packet originating at a first GPU on the first host machine (The VCN CP also sends VCN data mappings to the VCN data plane that is configured to perform packet forwarding and routing functions. In certain embodiments, the VCN CP provides a distribution service that is responsible for providing updates to the VCN data plane. Examples of a VCN Control Plane are also depicted in FIGS. 12, 13, 14, and 15 (see references 1216, 1316, 1416, and 1516) and described below) [Brar: col. 11, line 16-23] and destined for a second GPU on the second host machine (Communications between compute instances on the same subnet are facilitated using VNICs associated with the source compute instance and the destination compute instance. For example, compute instance C1 in Subnet-1 may want to send packets to compute instance C2 in Subnet-1. For a packet originating at a source compute instance and whose destination is another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. Processing performed by the VNIC associated with the source compute instance can include determining destination information for the packet from the packet headers, identifying any policies (e.g., security lists) configured for the VNIC associated with the source compute instance, determining a next hop for the packet, performing any packet encapsulation / decapsulation functions as needed, and then forwarding/routing the packet to the next hop with the goal of facilitating communication of the packet to its intended destination) [Brar: col. 13, line 1-18] , communicating the packet from the first GPU on the first host machine to the second GPU on the second host machine using only ports from the first subset of ports (Communications between compute instances on the same subnet are facilitated using VNICs associated with the source compute instance and the destination compute instance. For example, compute instance C1 in Subnet-1 may want to send packets to compute instance C2 in Subnet-1. For a packet originating at a source compute instance and whose destination is another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. Processing performed by the VNIC associated with the source compute instance can include determining destination information for the packet from the packet headers, identifying any policies (e.g., security lists) configured for the VNIC associated with the source compute instance, determining a next hop for the packet, performing any packet encapsulation / decapsulation functions as needed, and then forwarding/routing the packet to the next hop with the goal of facilitating communication of the packet to its intended destination When the destination compute instance is in the same subnet as the source compute instance, the VNIC associated with the source compute instance is configured to identify the VNIC associated with the destination compute instance and forward the packet to that VNIC for processing. The VNIC associated with the destination compute instance is then executed and forwards the packet to the destination compute instance) [Brar: col. 13, line 1-25]. Reference Notice Additional prior arts, included in the Notice of Reference Cited, made of record and not relied upon is considered pertinent to applicant's disclosure. Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to Philip Dang whose telephone number is (408) 918-7529. The examiner can normally be reached on Monday-Thursday between 8:30 am - 5:00 pm (PST). 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, Sath Perungavoor can be reached on 571-272-7455. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000./Philip P. Dang/Primary Examiner, Art Unit 2488 Application/Control Number: 18/912,076 Page 2 Art Unit: 2488 Application/Control Number: 18/912,076 Page 3 Art Unit: 2488 Application/Control Number: 18/912,076 Page 4 Art Unit: 2488 Application/Control Number: 18/912,076 Page 5 Art Unit: 2488 Application/Control Number: 18/912,076 Page 6 Art Unit: 2488 Application/Control Number: 18/912,076 Page 7 Art Unit: 2488 Application/Control Number: 18/912,076 Page 8 Art Unit: 2488 Application/Control Number: 18/912,076 Page 9 Art Unit: 2488 Application/Control Number: 18/912,076 Page 10 Art Unit: 2488 Application/Control Number: 18/912,076 Page 11 Art Unit: 2488 Application/Control Number: 18/912,076 Page 12 Art Unit: 2488 Application/Control Number: 18/912,076 Page 13 Art Unit: 2488 Application/Control Number: 18/912,076 Page 14 Art Unit: 2488 Application/Control Number: 18/912,076 Page 15 Art Unit: 2488 Application/Control Number: 18/912,076 Page 16 Art Unit: 2488 Application/Control Number: 18/912,076 Page 17 Art Unit: 2488 Application/Control Number: 18/912,076 Page 18 Art Unit: 2488 Application/Control Number: 18/912,076 Page 19 Art Unit: 2488 Application/Control Number: 18/912,076 Page 20 Art Unit: 2488 Application/Control Number: 18/912,076 Page 21 Art Unit: 2488 Application/Control Number: 18/912,076 Page 22 Art Unit: 2488 Application/Control Number: 18/912,076 Page 23 Art Unit: 2488 Application/Control Number: 18/912,076 Page 24 Art Unit: 2488 Application/Control Number: 18/912,076 Page 25 Art Unit: 2488 Application/Control Number: 18/912,076 Page 26 Art Unit: 2488 Application/Control Number: 18/912,076 Page 27 Art Unit: 2488 Application/Control Number: 18/912,076 Page 28 Art Unit: 2488 Application/Control Number: 18/912,076 Page 29 Art Unit: 2488 Application/Control Number: 18/912,076 Page 30 Art Unit: 2488 Application/Control Number: 18/912,076 Page 31 Art Unit: 2488 Application/Control Number: 18/912,076 Page 32 Art Unit: 2488 Application/Control Number: 18/912,076 Page 33 Art Unit: 2488 Application/Control Number: 18/912,076 Page 34 Art Unit: 2488 Application/Control Number: 18/912,076 Page 35 Art Unit: 2488 Application/Control Number: 18/912,076 Page 36 Art Unit: 2488 Application/Control Number: 18/912,076 Page 37 Art Unit: 2488 Application/Control Number: 18/912,076 Page 38 Art Unit: 2488 Application/Control Number: 18/912,076 Page 39 Art Unit: 2488 Application/Control Number: 18/912,076 Page 40 Art Unit: 2488 Application/Control Number: 18/912,076 Page 41 Art Unit: 2488
Prosecution Insights