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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/07/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
Applicant’s amendment filed on 01/07/2026 have been entered. Independent claims 1, 9, and 17 have been amended. Dependent claims 7, 15, and 21 have been amended. No claims have been cancelled. No claims have been added. Claims 1-19, and 21 are still pending in this application.
Response to Arguments
Applicant’s arguments filed on 01/07/2026 on pages 7-9, the applicant argues that Williams teaches a network router, as opposed to a switch for TEPs. However, ¶0154-¶0161 describes a router, described as a “legacy router”, implementing as a switch for one or more TEPs. Which the addition of Gopal with Williams teaches the functionality of the host machine. Thus, the applicant here fails to patentably distinguish the claimed invention of a network router, as opposed to a switch for TEPs from the teachings of Williams. The applicant’s arguments have been fully considered, but are not persuasive.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-13, and 15-21 is/are rejected under 35 U.S.C. 103 as being unpatentable as being unpatentable over Arai (Pub. No.: US 20090154480 A1, hereinafter, “Arai”) in view of Mitra (Pub. No.: US 20030099237 A1, hereinafter, “Mitra”), and further in view of Williams (Pub. No.: US 20200007436 A1, hereinafter, “Williams”), and even further in view of Gopal (Pub. No.: US 20190173920 A1, hereinafter, “Gopal”).
Regarding Claim 1, Claims 9 and Claim 17
Arai teaches
adding by the first TEP (Arai Abstract: adds an ID tag unique to each physical port), a first label to the first packet (Arai Abstract: to the header of a packet received by the physical port); forwarding by the first TEP (Arai Abstract: and sends the packet), the first packet with the first label to a direct-attached virtual network interface card (DAV) associated with the service host (Arai Abstract: adds an ID tag unique to each physical port); modifying, by the DAV, a header of the first packet (Arai ¶0029: a first packet modifying means for modifying a destination address of the packet into the searched server address); and responsive to the modifying, switching, by the DAV, (Arai ¶0029: the packet received from the shared server and modifying the source address into a gateway address, e.g. the modification causes the ID tag to redirect the destination address).
Arai does not explicitly teach:
the first packet to a virtual cloud network (VCN) of the first customer.
However, Mitra teaches:
the first packet to a virtual cloud network (VCN) of the first customer (Mitra ¶0111: A 32-bit tag is attached as a content header to encapsulate the IP packets before pushing the packets into the VCN).
It would be obvious for one skilled in the art, before the effective filing date of the claimed invention, to modify Arai by way of Mitra to include the responsive to the modifying, switching, by the DAV, the first packet to a virtual cloud network (VCN) of the first customer, as taught by Mitra, in ¶111, to combine the well-known technique of multiprotocol label switching with a cloud network to facilitate a more flexible outer network and allow easier maintenance cycles.
Arai in view of Mitra does not teach:
A method comprising: providing a host machine implementing a service host that implements a plurality of tunnel-endpoints (TEPs), a first connection originating at a first customer premise equipment (CPE) in a first on-premises data center of a first customer and terminating at a first TEP of the plurality of TEPs
However, Williams teaches
A method comprising: providing a host machine (Williams Fig. 1: 102, Provider Edge Router) implementing a service host (Williams ¶0019: PE router 102 may determine) that implements a plurality of tunnel-endpoints (TEPs) (Williams ¶0019: PE router 102 may determine a plurality of tunnels over a plurality of routes), a first connection originating at a first customer premise equipment (CPE) in a first on-premises data center of a first customer (Williams Fig. 1: 101, Customer Edge Router) and terminating at a first TEP of the plurality of TEPs (Williams Fig. 1: 103-107, e.g. a PE router; Williams teaches a machine implementing a plurality of routes wherein one side includes a customer edge point, and the other is at a PE router);
It would have been obvious for one skilled in the art, before the effective filing date of the claimed invention, to modify Arai in view of Mitra by way of Williams, to include an element that teaches a machine implementing a plurality of routes wherein one side includes a customer edge point, and the other is at a PE router, as taught by Williams in Fig. 1, Fig. 2, and ¶0019, to improve end-to-end communication by allowing more secure connections using even potentially untrusted networks.
Arai in view of Mitra, further in view of Williams does not explicitly teach
receiving by the first TEP, a first packet over the first connection, wherein a virtual network interface card (VNIC) associated with the service host selects the first TEP from the plurality of TEPs based on a source address included in the first packet;
However, Gopal teaches
receiving by the first TEP (Gopal Fig. 2: 250, e.g. within VM 2201), a first packet over the first connection (Gopal Fig. 2: Connection between 2201 and 214), wherein a virtual network interface card (VNIC) (Gopal Fig. 2: 226, e.g. a DNE controller used by the VNIC, see ¶0043) associated with the service host (Gopal Fig. 2: 210) selects (Gopal ¶0031: selects SPI value for VM) the first TEP (Gopal Fig. 2: 2201) from the plurality of TEPs (Gopal Fig. 2: 2202-220a) based on a source address included in the first packet (Gopal ¶0043: SPI value; Gopal teaches a plurality of VMs containing VNICs connect to a host device that selects a chosen VM machine for a TEP);
It would have been obvious for one skilled in the art, before the effective filing date of the claimed invention, to modify Arai in view of Mitra, further in view of Williams by way of Gopal, to include an element that teaches a plurality of VMs containing VNICs connect to a host device that selects a chosen VM machine for a TEP, as taught by Gopal in Fig. 2 and ¶0043, to optimize deterministic load balancing by processing encapsulated encrypted data packets at a destination tunnel endpoint.
Regarding Claim 2, Claim 10, and Claim 18
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 1. Arai further teaches
modifying, by the DAV, the header of the first packet to include at least the first label (Arai ¶0055: In Step S34, the destination address of the received packet is modified), a slot ID associated with the DAV, and a user datagram protocol (UDP)-header that includes a destination IP address assigned to a gateway to which the first packet is to be forwarded (Arai ¶0050: A packet modifier 543 modifies a destination address of the received packet).
Regarding Claim 3, Claim 11, and Claim 19
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 1. Arai further teaches
providing the host machine implementing the service host, a second connection from a second CPE in a second on-premises data center of a second customer (Arai Fig. 4: S40, SENDING PACKET); receiving by the second TEP, a second packet over the second connection (Arai ¶0055: Step S35, the received packet is transferred to the shared common serve); and adding by the second TEP, a second label to the second packet (Arai Abstract: modifies a destination address of the packet).
Williams teaches
the second connection terminating at a second TEP of the plurality of TEPs (Williams ¶0058: the plurality of routes may include a first route and a second route)
It would be obvious for one skilled in the art, before the effective filing date of the claimed invention, to modify Arai by way of Mitra, and further by Williams to include the plurality of routes may include a first route and a second route, as taught by Williams in ¶0058, to increase support for the latest networking and/or cryptographic algorithms as they further evolve and scalability can incur inconsistent results.
Regarding Claim 4 and Claim 12
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 3. Arai further teaches
forwarding by the second TEP, the second packet with the second label to the DAV associated with the service host (Arai ¶0055: Step S35, the received packet is transferred,); modifying, by the DAV, the header of the second packet (Arai Abstract: modifies a destination address of the packet,); and responsive to the modifying, switching, by the DAV, the second packet to the VCN of the second customer (Mitra ¶0111: A 32-bit tag is attached as a content header to encapsulate the IP packets before pushing the packets into the VCN).
Regarding Claim 5 and Claim 13
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 1. Arai further teaches
wherein the DAV switches the first packet to a first attachment associated with a gateway (Arai ¶0055: transferred to the shared common server from the interface 51 via the transmission buffer), the gateway routing the first packet to the VCN of the first customer via a second attachment (Mitra ¶0111: A 32-bit tag is attached as a content header to encapsulate the IP packets before pushing the packets into the VCN).
Regarding Claim 7 and Claim 15
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 1. Mitra teaches
wherein the VNIC that is programmed to forward packets from the first TEP to the first customer premise equipment via an Internet gateway (Mitra ¶0111: A 32-bit tag is attached as a content header to encapsulate the IP packets before pushing the packets into the VCN,), the VNIC being associated with another slot ID that is different than the slot ID associated with the DAV (Mitra ¶0111: A 32-bit tag is attached as a content header to encapsulate the IP packets before pushing the packets into the VCN).
Regarding Claim 8 and Claim 16
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 5. Arai further teaches
advertising, by the first TEP to the first attachment associated with the gateway, information including at least the first label (Arai Abstract: The GW 2 searches for a server address corresponding to the ID tag attached to the packet received from the switch), a slot ID assigned to the DAV, and a substrate address of the DAV (Arai Abstract: GW 2 attaches an ID tag corresponding to a source address), the advertising being conducted via an out-of-band routing protocol executed between the first TEP and the first attachment associated with the gateway (Arai Abstract: modifies the source address of the packet into a GW address).
Regarding Claim 21
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 1. Williams further teaches
wherein the first packet is routed to the first TEP by the VNIC included in the service host (Williams Fig. 8A: 602), and wherein the direct-attached virtual network interface card (DAV) (Williams Fig. 6: 308) is a smart network interface card (NIC) (Williams Fig. 8A: 608c).
Claim(s) 6 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable as being unpatentable over Arai (Pub. No.: US 20090154480 A1, hereinafter, “Arai”) in view of Mitra (Pub. No.: US 20030099237 A1, hereinafter, “Mitra”), further in view of Williams (Pub. No.: US 20200007436 A1, hereinafter, “Williams”), and further in view of Gopal (Pub. No.: US 20190173920 A1, hereinafter, “Gopal”), and even further in view of Kelly (Pub. No.: US 20170039116 A1, hereinafter, “Kelly”).
Regarding Claim 6 and Claim 14
The combination of Arai, Mitra, Williams, and Gopal teaches the method, machine, and medium as explained above in Claim 5. The combination of Arai, Mitra, Williams, and Gopal does not explicitly teach
wherein the service host resides in a first tenancy, and the gateway resides in a second tenancy, the first tenancy being different than the second tenancy.
However, Kelly teaches:
wherein the service host resides in a first tenancy, and the gateway resides in a second tenancy, the first tenancy being different than the second tenancy (Kelly ¶0079: one or more power loads are configured to host multiple software applications within the same runtime environment, e.g., multitenancy).
It would be obvious for one skilled in the art, before the effective filing date of the claimed invention, to modify Arai, Mitra, Williams, and Gopal with Kelly to include wherein the service host resides in a first tenancy, and the gateway resides in a second tenancy, the first tenancy being different than the second tenancy, as taught by Kelly ¶0079, to enable multitenancy during packet switching to increase the bandwidth capabilities of the host service.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN MICHAEL WHITAKER whose telephone number is (703)756-4763. The examiner can normally be reached Monday - Thursday 7:30am - 4:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Rutkowski can be reached on (571) 270-1215. 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.
/JUSTIN MICHAEL WHITAKER/Examiner, Art Unit 2415
/Sudesh M. Patidar/Primary Examiner, Art Unit 2415