DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 02/18/2026 have been fully considered but they are not persuasive.
Applicant’s arguments (Summary of pages 8-11, Examiner’s emphasis – bold)
…Applicant argued that the combination of EAD and MENG does not teach or suggest "the direct connect gateway is bypassed during the routing," as recited in amended claim 1 because the combination introduces a change in the basic principle under which system described in EAD reference was designed to operate with respect to elements mapped to, for example, "the default route," "the direct connect gateway," and "the cloud computing system," as recited in amended claim 1,
Response:
Examiner respectfully disagrees.
In particular, EAD discloses techniques for establishing a network-link between a first virtual network in a first cloud environment and a second virtual network in a second cloud environment. Customer traffic isolation is achieved by establishing unique tunnels for each customer Virtual Private Cloud (VPC)-customer VCN connection. The unique tunnels provide direct path to each of the customer sites. Similarly, Meng discloses tunnels 110A – 110C, that are used to provide direct paths to each spoke serving customer sites a 114A – 114D. Meng discloses the use of dynamic tunnel managers 120, 121 to implement dynamic tunnel negotiation based on network conditions. At stage F, upon completion of the dynamic tunnel negotiation, a dynamic tunnel 116 is established between the spoke 105 and the spoke 106. The dynamic tunnel 116 is a VPN tunnel which facilitates secure transmission of data over the public network 112 and may leverage encryption. Once the dynamic tunnel 116 has been established, the spoke dynamic tunnel managers 120, 121 redirect data flow between the spoke 105 and the spoke 106 through the dynamic tunnel 116 such that data no longer flows through the hub 104, thus, bypassing the hub connecting tunnels 110B and 110C during the routing as required by amended claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-4,6-7,9, 10-12, 14-15, 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ead et al. (US 2024/0129371 A1), in view of Meng et al. (US 2021/0036887 A1).
Regarding claim 1, Ead discloses a method (Ead [0013], a method directed to creating a network-link between a first virtual network in a first cloud environment and a second virtual network in a second cloud environment in a multi-cloud infrastructure), comprising:
indicating, by a routing device (fig. 1,VNIC/fig.8A, Transit Gateway (TGW) 807) to a direct connect gateway (fig.1 -VNC VR/Gateway -105/fig. 8A – Direct connect Gateway 808 ) in a cloud computing system (fig. 8A, 805), a default route (fig.1, Default Route to VR/fig. 8A, Connect Attach 1) (Ead, figs. 1&8A, [0079-0080;0189-0191] fig. 1 discloses default for each compute instance in Subnet-1, including compute instances C1 and C2, having 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. In a corresponding manner, fig. 8A discloses Transit Gateway (TGW) 807 indicating a default route such as Connect Attach 1 and Connect Attach 2 to a Direct Connect Gateway 808, where Connect Attach 1 and Connect Attach 2 are used as default routes for routing packets directed to Customer 1 VCN (831) and Customer 2 VCN (832), respectively, in a region of a second cloud environment 805),
wherein the default route (forwarding/routing tables includes information of a default route of fig. 1 and Connect Attach ½ of fig. 8A) is propagated (Publishing forwarding/routing tables) to a virtual network function (VNF) (NVDs executes virtualization network functions, e.g. VNICs, VRs, gateways) running in the cloud computing system (a region of a second cloud environment 805); (fig. 8A, [0073;0189] Network Virtualization Devices are disclosed to execute Network functions (e.g. VNICs, VRs, gateways and a VCN Distribution Service publishes the configuration information which includes default route information stored by the VCN Control Plane, or portions thereof, to the NVDs (VNICs, VRs, gateways). That is, information about the default route is propagated to the VNFs. The distributed information may be used to update information (e.g., forwarding tables, routing tables, etc.) stored and used by the NVDs (VNF) to forward packets to and from the compute instances in the VCN),
creating, by the routing device (transmit gateway 807), a generic routing encapsulation (GRE) tunnel between the VNF (NVDs – VNICs, VRs, gateways) the routing device (transit gateway 807) based on the default route (attachment 1/tunnel 1), wherein the GRE tunnel permits a direct peering between the VNF (fig. 1 -VNICs to VCN VR) (Ead, fig. 8A, [0190 – 0191] the transit gateway 807 achieves customer traffic isolation by establishing unique tunnels for each customer VPC-customer VCN connection, where each VPC include VNFs such as VNICs, VRs and gateways). The transit gateway establishes the different tunnels based on a generic routing encapsulation (GRE) protocol. Specifically, the transit gateway establishes a first tunnel (corresponding to customer 1 VPC 801 in the second cloud environment 805 that desires to establish a connection with customer 1 VCN 831 in the first cloud environment 835) that is transmitted over the direct connect attachment (from the transit gateway 807 to the direct connect gateway 808 and referred to as connection attachment 1) as tunnel 1) and
a private network (fig. 6, Cloud Env B 640) outside of the cloud computing system (fig. 6, Cloud Env A 610) (Ead [0152], a link 670 created between cloud A 610 and cloud B 640, and a link 672 created between cloud A 610 and cloud C 660. Via link 670, a customer of cloud B 640 can access or use one or more services 614 provided by cloud A 610. Likewise, via link 672, a customer of cloud C 660 can access or use one or more services 614 provided by cloud A 610); and
performing, by the routing device (figs. 1&8A - VNIC/Transit gateway 807), a routing between the VNF (figs. 1,6 & 8A) and the private network (Cloud Env B 640) using the GRE tunnel (Tunnel – 670) (Ead, figs. 1,6 & 8A, each compute instance in Subnet-1, including compute instances C1 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 (VNF) for Subnet-1 (private cloud). Similarly, in fig. 8A, the transit gateway 807 performing packet routing transversing Direct Connect gateway 808 (VNF) through a tunnel (Connect Attach 1) to Customer 1 VPC).
EAD did not explicitly disclose wherein the direct connect gateway is bypassed during the routing.
Meng discloses wherein the gateway (hub 104 – fig. 1) in the cloud computing system is bypassed (Bypassing hub 104) during the routing (Meng [0026] At stage F, upon completion of the dynamic tunnel negotiation, a dynamic tunnel 116 is established between the spoke 105 and the spoke 106. The dynamic tunnel 116 is a VPN tunnel which facilitates secure transmission of data over the public network 112 and may leverage encryption. Once the dynamic tunnel 116 has been established, the spoke dynamic tunnel managers 120, 121 redirect data flow between the spoke 105 and the spoke 106 through the dynamic tunnel 116 such that data no longer flows through hub 104).
One of ordinary skill in the art would have been motivated to combine Ead and Meng because these teachings are from the same field of endeavor with respect to disclosing techniques related to the establishment of tunnels between multiple cloud networks.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Meng into the invention of Ead. The motivation would have been to dynamically terminate a tunnel after a period of inactivity to reduce overhead caused by consistent maintenance of dynamic tunnels with low use, Meng, [Abstract].
Regarding claim 2, Ead and Meng disclose the method of claim 1, further comprising:
adding, by the routing device (Spoke dynamic tunnel manager 120), a route to a list (routing tables) of advertised routes using a data routing protocol (BGP) (Meng, figs. 1-4, [0015;0018-0019] a method for dynamic establishment and termination of spoke-to-spoke VPN tunnels in a hub-and-spoke network based on information provided through a BGP push configuration. A Routing engine of the spokes 103, 105 may install a static route to reach the spoke 106 to an entry in a respective routing table maintained for the spokes 103, 105. The entry may indicate the static route, the VIP address of the spoke 106, and an outgoing tunnel interface (e.g., an interface for transmission of outgoing network traffic via a VPN tunnel). Adding the static route to the routing tables of the spokes 103, 105 allows the spokes 103, 105 to install routes advertised by the spoke 106 and resolve the next hop for the routes to the spoke 106 using BGP),
wherein the route is added to the list based on an availability of the VNF (Meng [0014;0018;0048] Adding a static route to the routing tables of the spokes 103, 105 allows the spokes 103, 105 to install routes advertised by the spoke 106 and resolve the next hop for the routes to the spoke 106 using BGP. Also, a dynamic route/tunnel may be established and added to routing tables based on the available of a desired virtual network function such as a firewall, a server, a cloud service, at the end of the tunnel).
The motivation to combine is similar to that of claim 1
Regarding claim 3, Ead and Meng discloses the method of claim 1, further comprising:
removing (termination of established tunnels), by the routing device (Spoke dynamic tunnel manager 120), a route from a list (routing tables) of advertised routes using a dynamic border gateway protocol (BGP) (Meng, [0031;0050;0054], fig. 5 depicts a flowchart of operations for termination of dynamically established VPN tunnels between spokes that was established based on configuration information provide through BGP),
wherein the route is removed (Termination of dynamically created tunnels) from the list (routing tables) based on an unavailability (inactive of spoke-to-spoke VPN tunnels connected network/cloud service) of the VNF (Meng, [0013;0054] Termination of VPN tunnels between spokes also occurs dynamically. By monitoring traffic exchanged between two spokes, VPN tunnels can be terminated after observing a period of tunnel inactivity. Dynamic teardown of tunnels based on inactivity timeout reduces overhead caused by consistent maintenance of VPN tunnels between spokes which exchange data infrequently. If the dynamic tunnel is an IPsec tunnel, the dynamic tunnel may be terminated when the IPsec/firewall function becomes unavailable at the end of the tunnel).
The motivation to combine is similar to that of claim 1.
Regarding claim 4, Ead and Meng disclose the method of claim 1, wherein the infrastructure includes one or more of: a virtual private gateway, a direct connect gateway, or an Internet gateway (Ead, figs. 1&7-8A, [0089-0092] discloses a cloud services provider infrastructure (CSPI) ich includes an Internet Gateway (IGW) 120, Service Gateway (SGW) 126, Private Access Gateway (PAGW) 130. In figs. 7- 8, the infrastructure includes a Transit Gateway 807 and a Direct Connect Gateway 808).
The motivation to combine is similar to that of claim 1.
Regarding claim 6, Ead and Meng disclose the method of claim 1, wherein the VNF is associated with a firewall, a session border controller, a software-defined wide area network (SD-WAN), routing, a secure gateway, or a virtual private network (VPN) concentrator (Ead [0124] A Network Virtualization Device (NVD) is disclosed to implement or perform network virtualization functions. These functions are performed by software/firmware executed by the NVD and include without limitation: packet encapsulation and de-capsulation functions; functions for creating a VCN network; functions for implementing network policies such as VCN security list (firewall) functionality; functions that facilitate the routing and forwarding of packets to and from compute instances in a VCN).
The motivation to combine is similar to that of claim 1.
Regarding claim 7, Ead and Meng disclose the method of claim 1, wherein the private network is a multi-protocol label switching (MPLS) network (Ead [0046] discloses a cloud services provider infrastructure or CSPI that can be used by customers to build their own customizable networks and deploy customer resources. The CSPI includes a private network is a multi-protocol label switching (MPLS) network).
The motivation to combine is similar to that of claim 1
Regarding claim 9, Ead discloses a device (Gateway 807 and 808), comprising: one or more processors (Ead [0016] discloses a computing device comprising: one or more processors; and a memory including instructions that, when executed with the one or more processors, cause the computing device to, at least) configured to:
The rest of the limitations of claim 9 are rejected with rational similar to that of claim 1.
Regarding claim(s) 10-12, the claims is/are rejected with rational similar to that of claim(s) 2-4, respectively.
Regarding claim(s) 14 and 15, the claims is/are rejected with rational similar to that of claim(s) 6 and 7, respectively.
Regarding claim(s) 17, Ead discloses a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to (Ead [0015] discloses one or more computer readable non-transitory media storing computer-executable instructions that, when executed by one or more processors, cause:
The rest of the limitations of claim 17 are rejected with rational similar to that of claim 1.
Regarding claim(s) 18 and 19, the claims is/are rejected with rational similar to that of claim(s) 2 and 4, respectively.
Claim(s) 5, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ead et al. (US 2024/0129371 A1), in view of Meng et al. (US 2021/0036887 A1), further in view of Manzardo (US 2004/0177137 A1).
Regarding claim 5, Ead and Meng disclose the method of claim 1, further comprising: advertising a plurality of routes to the VNF via the GRE tunnel (Ead [0190] the transit gateway 807 achieves customer traffic isolation by establishing unique tunnels for each customer VPC-customer VCN connection. Tunnel information is published to and used by the transit gateway to establish the different tunnels based on a generic routing encapsulation (GRE) protocol).
Manzardo discloses wherein a quantity associated with the plurality of routes is greater than a routing limit associated with the direct connect gateway based on only the default route being apparent to the cloud computing system (Manzardo [0139; 0142-0143] discloses the ability to define a maximum number of gateway channels allowed/supported. If it is determined that the number of access request is larger than the gateway channels possible on the access point, the method 180 moves to the step 196 where the flag originally cleared in the step 186 is not set. The number of users assumed for the access point is then decreased during the step 198 and the method proceeds back to the step 190).
One of ordinary skill in the art would have been motivated to combine Ead, Meng and Manzardo because these teachings are from the same field of endeavor with respect to disclosing techniques related to the establishment of links between networks.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Meng into the invention of Ead and Meng. The motivation would have been to determine the number of access points needed for the location within a network, Manzardo, [Abstract].
Regarding claim(s) 13, the claims is/are rejected with rational similar to that of claim(s) 5.
Regarding claim(s) 20, the claims is/are rejected with rational similar to that of claim(s) 5.
Claim(s) 8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ead et al. (US 2024/0129371 A1), in view of Meng et al. (US 2021/0036887 A1), further in view of Ballantyne et al. (US 2008/0144627 A1).
Regarding claim 8, Ead and Meng disclose the method of claim 7, but did not explicitly disclose wherein the routing device is a private Internet Protocol MPLS provider edge (PE) router.
Ballantyne discloses wherein the routing device is a private Internet Protocol MPLS provider edge (PE) router (Ballantyne [0019;0025;0058] [0058] Referring now to FIG. 4, in step 302, as in FIG. 3, operation of a network management station (NMS) is initiated. In step 304, a communication tunnel is established using generic routing encapsulation (GRE) or a similar encapsulation protocol. In various embodiments: the tunnel is established between the NMS and a particular router in a managed network or monitored network (step 304); the tunnel is established to a provider edge router of an MPLS network (step 401A); multiple tunnels are established to a provider edge router, in which each tunnel is associated with a different customer or VPN (step 401B); and the tunnel is established to a router that is multiple physical hops away (step 401C).
One of ordinary skill in the art would have been motivated to combine Ead, Meng and Ballantyne because these teachings are from the same field of endeavor with respect to disclosing techniques related to the establishment of tunnels between multiple cloud networks.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Ballantyne into the invention of Ead and Meng. The motivation would have been to maintain a database of routes and determine whether the synchronized route database is missing one or more particular routes, and to generate a notification message when the synchronized route database is missing the one or more particular routes, Ballantyne, [Abstract].
Regarding claim(s) 16, the claims is/are rejected with rational similar to that of claim(s) 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following publications show the state of the art related to the establishment and termination of tunnels between multiple cloud networks.
Perng et al. (US 2022/0279046 A1)
Tubaltsev et al. (US 2015/0263946 A1)
Wang US 2023/0123614 A1)
ZHAO (US 2024/0048484 A1)
Shetye et al. (US 2024/0129185 A1)
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from 9:00 am – 5:00 pm.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/D.F.D/ Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights