DETAILED ACTION
This Action is in response to Application Number 19208995 received on 5/15/2025.
Claims 1-20 are presented for examination.
The effective filing date for this application is 8/10/2022.
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3 and 7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites the limitation, “wherein the cloud security service includes a policy-based forwarding rule to guarantee a symmetric return for Internet bound traffic”. The scope of the limitation is found indefinite, as it is not clear what the requirements are of the rule “to guarantee a symmetric return for Internet bound traffic”, since the limitation amounts to a limitation of intended result of the rule without any specific details to achieve such. For examination purposes, the claim will be interpreted as wherein the cloud security service includes a policy-based forwarding rule for traffic.
Claim 7 recites the limitation, “the overlapping IP address spaces are separated and become routable using the at least four virtual routers”, which is found indefinite as it is not clear by the scope of the claim as to what is meant by “separating” overlapping IP address spaces, and it is not clear by the scope of the claim as to what is meant by address spaces “becoming routable.“
For examination purposes, the limitation will be interpreted as the address spaces may be utilized.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-4, 7-10, 12-15, 18-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Qian et al. (US 20220321470).
Regarding claim 1, Qian disclosed a system, comprising:
a processor (Qian, Fig. 31, [0212]-[0213], Computing device 9000, including one or more processors 9010) configured to:
generate at least four virtual routers for a cloud security service, wherein the at least four virtual routers include a first virtual router, a second virtual router, a third virtual router, and a fourth virtual router (Qian, [0055]-[0056], and Fig. 1, Qian disclosed a system environment in which scalable virtual routers may be implemented for traffic flowing between isolated networks; Fig. 1 shows system 100 comprises an instance 102 of a scalable virtual router (VR), set up using the resources of a multi-layer packet processing service (PPS). VR instance 102 may be used to enable connectivity among a plurality of isolated networks 140A—140D. The control plane may be responsible for configuring VR instances and associated routing/forwarding metadata 108… while the data plane resources may be used to generate and implement actions to route packets originating at (and directed to) the isolated networks 140. Multiple VR instances may be set up. Paragraph [0056] provides examples of isolated networks for 140A-D, such as “isolated network 140A may comprise a set of resources at a data center or premise external to the provider network's own data centers”; [0056] also provides examples as to how the isolated networks may be connected to the provider network, such as “using VPN tunnels” or “physical links”; Fig. 23, 2301, “Establish…a set of virtual routers (VRs)…for traffic flowing between isolated networks (Ins); Qian does not limit the number of virtual routers for the cloud security service);
route cloud security service packets using the first virtual router and the third virtual router (Qian, [0061] and Figure 2 in which Qian disclosed Application categories utilizing virtual routers, which may include various cloud security services; In [0061], “a virtual router similar to the virtual router instance 102 of FIG. 1 may be configured to implement (e.g., with the help of auxiliary task offloading resources) any desired type of packet processing or transformations; [0062], “the VR may act as intermediary or channel between the private address spaces of two or more different IVNs, in effect setting up scalable and scalable cross-IVN channels 206. In at least some embodiments, auxiliary tasks may not be needed for cross-IVN channels. For scalable VPN connectivity 208, auxiliary tasks such as BGP processing, encryption and the like may be needed in the depicted embodiment, and such auxiliary tasks may be implemented using offloading resources associated with a VR”; Additionally, in [0056], isolated network 140A may be specifically set up for a set of resources at a data center external to the provider network’s own data centers; See also [0133] Protocol P1 stack instance 1552, configured in multi-tenant mode, is used for auxiliary tasks associated with traffic handled by a virtual router VR1 set up for a client C1 of a packet processing service, as well as for auxiliary tasks associated with traffic handled by a virtual router VR4 for a different client C4; Qian does not limit the number of virtual routers that may be utilized, and therefore includes instances where two virtual routers are utilized to route cloud security packets); and
route enterprise subscriber packets using the second virtual router (Qian, [0068], “a virtual router 327 has been assigned for processing traffic between client traffic source endpoints 364 and client traffic destination endpoints 372 for one or more PPS clients 310”; See also [0055], in which a virtual router may be set up for multi-tenant mode to handle application data of several different clients; See also [0133] Protocol P1 stack instance 1552, configured in multi-tenant mode, is used for auxiliary tasks associated with traffic handled by a virtual router VR1 set up for a client C1 of a packet processing service, as well as for auxiliary tasks associated with traffic handled by a virtual router VR4 for a different client C4; Qian does not limit the number of virtual routers that may be utilized, and therefore includes instances where two virtual routers are utilized to route subscriber); and
a memory coupled to the processor and configured to provide the processor with instructions (Qian, [0212], “memory”).
Claim 12 recites a method with limitations that are substantially similar to the limitations of claim 1. As shown above, Qian disclosed such limitations, and therefore claim 12 is rejected under the same rationale applied above.
Claim 18 is directed to a computer program product embodied in a non-transitory computer readable medium with limitations that are substantially similar to the limitations of claim 1. Qian disclosed such a medium (Qian, [0217], “a computer-accessible medium may include non-transitory storage media or memory media”). Claim 18 is therefore rejected under the same rationale applied above.
Regarding claims 2 and 13, Qian disclosed the system/method of claims 1 and 12, wherein: the first virtual router includes a first routing table; the second virtual router includes a second routing table; the third virtual router includes a third routing table; and
the fourth virtual router includes a fourth routing table (Qian, [0113], Fig. 11, VR instance 1102 includes Routing/forwarding metadata 1108, which includes one or more route tables populated according to the configuration settings; Therefore each VR instance configured in Qian includes a routing table; As noted above, Qian does not limit the number of VRs and therefore includes the four claimed virtual routers).
Regarding claims 3, 14, and 19, Qian disclosed the system/method/medium of claims 1, 12, and 18, wherein the cloud security service includes a policy-based forwarding rule to guarantee a symmetric return for Internet bound traffic (Qian, [0058], Qian disclosed the routing/forwarding metadata to include policy-based routing rules 110 and used for directing at least a subset of outbound packets from the isolated network; [0066] and [0069], Qian further disclosed policy-based routing rules used for making packet processing decisions and [0107] efficiently implementing routing/forwarding actions based on client-supplied rules; [0108], “In some embodiments, the PPS control plane may generate and specify one or more policy-based routing rules, which when implemented at the exception-path layer cause packets requiring the auxiliary tasks to be transmitted from the VR forwarding plane to the ATOS, and cause response packets containing the results of the auxiliary tasks to be sent back to the forwarding plane nodes. See also [0199] and [0210]).
Regarding claims 4, 15, and 20, Qian disclosed the system/method/medium of claims 1, 12, and 18, wherein a cloud security service provider and an enterprise subscriber have an overlapping IP address spaces ([0065], Qian disclosed address substitution techniques when an overlap exists between the private address ranges of two or more isolated networks, and a VR may be employed as the intermediary responsible for such substitutions; [0080], Qian disclosed the addresses amounting to IP addresses, and the teachings of Qian able to modify the header values of packets in scenarios in which overlapping private address ranges happen to be used at source and destination isolated networks; Per mappings above, VRs configured by Qian include both VRs for cloud security service provider and VRs for enterprise subscriber; See also [0133] and Figure 15, disclosing two protocol stacks operating independently of one another, and as a result, overlapping address ranges can be easily managed).
Regarding claim 7, Qian disclosed the system of claim 4, wherein the overlapping IP address spaces are separated and become routable using the at least four virtual routers; the first virtual router includes a first routing table; the second virtual router includes a second routing table; the third virtual router includes a third routing table; and
the fourth virtual router includes a fourth routing table (Qian, [0065], Qian disclosed address substitution techniques when an overlap exists between the private address ranges of two or more isolated networks, and a VR may be employed as the intermediary responsible for such substitutions; [0080], Qian disclosed the addresses amounting to IP addresses, and the teachings of Qian able to modify the header values of packets in scenarios in which overlapping private address ranges happen to be used at source and destination isolated networks; See [0133] and Figure 15, disclosing two protocol stacks operating independently of one another, and as a result, overlapping address ranges can be easily managed by VRs at both; [0113], Fig. 11, VR instance 1102 includes Routing/forwarding metadata 1108, which includes one or more route tables populated according to the configuration settings; Therefore each VR instance configured in Qian includes a routing table; As noted above, Qian does not limit the number of VRs and therefore includes the four claimed virtual routers each with routing tables).
Regarding claim 8, Qian disclosed the system of claim 1, wherein the first virtual router and third virtual router are dedicated for a cloud security service provider IP address space (Qian, [0061] and Figure 2 in which Qian disclosed Application categories utilizing virtual routers, which may include various cloud security services; In [0061], “a virtual router similar to the virtual router instance 102 of FIG. 1 may be configured to implement (e.g., with the help of auxiliary task offloading resources) any desired type of packet processing or transformations; [0062], “the VR may act as intermediary or channel between the private address spaces of two or more different IVNs, in effect setting up scalable and scalable cross-IVN channels 206. In at least some embodiments, auxiliary tasks may not be needed for cross-IVN channels. For scalable VPN connectivity 208, auxiliary tasks such as BGP processing, encryption and the like may be needed in the depicted embodiment, and such auxiliary tasks may be implemented using offloading resources associated with a VR”; Additionally, in [0056], isolated network 140A may be specifically set up for a set of resources at a data center external to the provider network’s own data centers; See also [0133] Protocol P1 stack instance 1552, configured in multi-tenant mode, is used for auxiliary tasks associated with traffic handled by a virtual router VR1 set up for a client C1 of a packet processing service, as well as for auxiliary tasks associated with traffic handled by a virtual router VR4 for a different client C4.; As such multiple VRs may be dedicated for a cloud security service provider IP address space);
the first virtual router has a first routing table (Qian, [0113], Fig. 11, VR instance 1102 includes Routing/forwarding metadata 1108, which includes one or more route tables populated according to the configuration settings; Therefore each VR instance configured in Qian includes a routing table);
the third virtual router has a third routing table (Qian, [0113], Fig. 11, VR instance 1102 includes Routing/forwarding metadata 1108, which includes one or more route tables populated according to the configuration settings; Therefore each VR instance configured in Qian includes a routing table);
the second virtual router and the fourth virtual router are dedicated for an enterprise subscriber IP address space (Qian, [0068], “a virtual router 327 has been assigned for processing traffic between client traffic source endpoints 364 and client traffic destination endpoints 372 for one or more PPS clients 310”; See also [0055], in which a virtual router may be set up for multi-tenant mode to handle application data of several different clients; [0062], “the VR may act as intermediary or channel between the private address spaces of two or more different IVNs, in effect setting up scalable and scalable cross-IVN channels 206. In at least some embodiments, auxiliary tasks may not be needed for cross-IVN channels. For scalable VPN connectivity 208, auxiliary tasks such as BGP processing, encryption and the like may be needed in the depicted embodiment, and such auxiliary tasks may be implemented using offloading resources associated with a VR”; See also [0133] Protocol P1 stack instance 1552, configured in multi-tenant mode, is used for auxiliary tasks associated with traffic handled by a virtual router VR1 set up for a client C1 of a packet processing service, as well as for auxiliary tasks associated with traffic handled by a virtual router VR4 for a different client C4; As noted above, Qian does not limit the number of VRs and therefore includes the embodiments in which multiple virtual routers may be dedicated to an enterprise subscriber IP address space); and
the second virtual router has a second routing table (Qian, [0113], Fig. 11, VR instance 1102 includes Routing/forwarding metadata 1108, which includes one or more route tables populated according to the configuration settings; Therefore each VR instance configured in Qian includes a routing table); and
the fourth virtual router has a fourth routing table (Qian, [0113], Fig. 11, VR instance 1102 includes Routing/forwarding metadata 1108, which includes one or more route tables populated according to the configuration settings; Therefore each VR instance configured in Qian includes a routing table).
Regarding claim 9, Qian disclosed the system of claim 1, wherein traffic originating from a client associated with an enterprise subscriber destined for a data center associated with the enterprise subscriber is routed using a routing table lookup via customer routing tables associated with the second virtual router and the fourth virtual router (Qian, [0068], “a virtual router 327 has been assigned for processing traffic between client traffic source endpoints 364 and client traffic destination endpoints 372 for one or more PPS clients 310”; See also [0055], in which a virtual router may be set up for multi-tenant mode to handle application data of several different clients; [0062], “the VR may act as intermediary or channel between the private address spaces of two or more different IVNs, in effect setting up scalable and scalable cross-IVN channels 206. In at least some embodiments, auxiliary tasks may not be needed for cross-IVN channels. For scalable VPN connectivity 208, auxiliary tasks such as BGP processing, encryption and the like may be needed in the depicted embodiment, and such auxiliary tasks may be implemented using offloading resources associated with a VR”; See also [0133] Protocol P1 stack instance 1552, configured in multi-tenant mode, is used for auxiliary tasks associated with traffic handled by a virtual router VR1 set up for a client C1 of a packet processing service, as well as for auxiliary tasks associated with traffic handled by a virtual router VR4 for a different client C4; See [0042] and [0057]-[0058] disclosing VR handling packets, utilizing the route table to select next hop to transmit a packet; As noted above, Qian allows for multiple VR instances to be utilized in routing client traffic).
Regarding claim 10, Qian disclosed the system of claim 1, wherein traffic originating from a client associated with an enterprise subscriber destined for an Internet site is routed using a chained routing table lookup ([0001][0058], “In at least some embodiments, entries with destinations within a particular isolated network such as 140C may be propagated to one or more route tables 109 that are associated with other isolated networks such as 140A or 140B, enabling, for example, traffic to flow along paths 155A and 155B from those other isolated networks to 140C”; [0060] transfer between isolated networks includes the use of IP Protocol; See also [0176] “Wide Area Networking Service Using VRs with Dynamic Routing Enabled”).
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.
Claim(s) 5-6, 11, 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Qian et al. (US 20220321470) in view of Souhrada et al. (US 20210067486).
Regarding claims 5 and 16, Qian disclosed the system/method of claims 4 and 15, but did not explicitly disclose wherein the overlapping IP address spaces include RFC 6598 IP addresses.
In an analogous art, Souhrada disclosed wherein the overlapping IP address spaces include RFC 6598 IP addresses (Souhrada, [0065], “Service providers preferably have a dedicated environment for multiple customers with overlapping addresses from the same environment.”, “In some systems, the cloud network on which the management platform resides uses Request for Comment 1918 (RFC1918) addressing (or some other addressing standard), and each customer potentially also uses their own RFC1918 addressing (or some other addressing standard).”).
One of ordinary skill in the art would have been motivated to combine the teachings of Qian and Souhrada, as both teachings provide for virtual network implementation, and as such they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the teachings of Souhrada within the teachings of Qian in order to allow for the utilization of specific protocol addresses even in instances of overlapping address spaces without conflict with the customer’s network (Souhrada, [0017]).
Regarding claims 6 and 17, Qian disclosed the system of claims 4 and 15, but did not explicitly disclose wherein the overlapping IP address spaces include RFC 1918 IP 20 addresses.
In an analogous art, Souhrada disclosed wherein the overlapping IP address spaces include RFC 1918 IP 20 addresses (Souhrada, [0065], “Service providers preferably have a dedicated environment for multiple customers with overlapping addresses from the same environment“; “In some systems, the cloud network on which the management platform resides uses Request for Comment 1918 (RFC1918) addressing (or some other addressing standard), and each customer potentially also uses their own RFC1918 addressing (or some other addressing standard).”).
One of ordinary skill in the art would have been motivated to combine the teachings of Qian and Souhrada, as both teachings provide for virtual network implementation, and as such they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the teachings of Souhrada within the teachings of Qian in order to allow for the utilization of specific protocol addresses even in instances of overlapping address spaces without conflict with the customer’s network (Souhrada, [0017]).
Regarding claim 11, Qian disclosed the system of claim 1, but did not explicitly disclose wherein the cloud security service includes a set of firewalls for security filtering of network traffic to/from a network of an enterprise subscriber.
In an analogous art, Souhrada disclosed the network may include a set of firewalls for security filtering of network traffic to/from a network of an enterprise subscriber ([0022] “firewall”; and [0039] Souhrada disclosed customer has control of select network components such as firewall).
One of ordinary skill in the art would have been motivated to combine the teachings of Souhrada with Qian as Qian explicitly suggests the need for traffic security for traffic flowing through a virtual router (Qian, [0066]), and Souhrada provides an implementation for achieving such security.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the utilization of firewalls, as disclosed by Souhrada within the teachings of Qian, in order to provide the clients of Qian with an extra level of security, thereby increasing customer desirability of use of the system as a whole.
Double Patenting
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 conflicting claims 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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 www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12328256 in view of Qian et al. (US 20220321470).
Claims 1-20 of U.S. Patent No. 12328256 contain every limitation of claims 1-20 of instant application 19208995, except for the limitations reciting the additional two virtual routers (i.e. third and fourth virtual routers), the differences shown in the table below, by example, in bold between claim 1 of the instant application and claim 1 of the US Patent 12328256.
However, the conflicting claims are not patentably distinct from each other because, given the considerable level of skill in the art of networking, one skilled in the art would have found it obvious to apply the limitations of claims 1-20 of US Patent 12328256 to additional virtual routers, as doing do amounts to simply duplicating the number of virtual routers for repeating the same functionality.
Additionally, in an analogous art, Qian disclosed the generation of plural virtual routers for routing such traffic as claimed (Qian, [0055]-[0056], and Fig. 1, Qian disclosed a system environment in which scalable virtual routers may be implemented for traffic flowing between isolated networks; Fig. 1 shows system 100 comprises an instance 102 of a scalable virtual router (VR), set up using the resources of a multi-layer packet processing service (PPS). VR instance 102 may be used to enable connectivity among a plurality of isolated networks 140A—140D. The control plane may be responsible for configuring VR instances and associated routing/forwarding metadata 108… while the data plane resources may be used to generate and implement actions to route packets originating at (and directed to) the isolated networks 140. Multiple VR instances may be set up. Paragraph [0056] provides examples of isolated networks for 140A-D, such as “isolated network 140A may comprise a set of resources at a data center or premise external to the provider network's own data centers”; [0056] also provides examples as to how the isolated networks may be connected to the provider network, such as “using VPN tunnels” or “physical links”; Fig. 23, 2301, “Establish…a set of virtual routers (VRs)…for traffic flowing between isolated networks (Ins); Qian does not limit the number of virtual routers for the cloud security service; [0061] and Figure 2 in which Qian disclosed Application categories utilizing virtual routers, which may include various cloud security services; In [0061], “a virtual router similar to the virtual router instance 102 of FIG. 1 may be configured to implement (e.g., with the help of auxiliary task offloading resources) any desired type of packet processing or transformations; [0062], “the VR may act as intermediary or channel between the private address spaces of two or more different IVNs, in effect setting up scalable and scalable cross-IVN channels 206. In at least some embodiments, auxiliary tasks may not be needed for cross-IVN channels. For scalable VPN connectivity 208, auxiliary tasks such as BGP processing, encryption and the like may be needed in the depicted embodiment, and such auxiliary tasks may be implemented using offloading resources associated with a VR”; Additionally, in [0056], isolated network 140A may be specifically set up for a set of resources at a data center external to the provider network’s own data centers; See also [0133] Protocol P1 stack instance 1552, configured in multi-tenant mode, is used for auxiliary tasks associated with traffic handled by a virtual router VR1 set up for a client C1 of a packet processing service, as well as for auxiliary tasks associated with traffic handled by a virtual router VR4 for a different client C4; Qian does not limit the number of virtual routers that may be utilized, and therefore includes instances where two virtual routers are utilized to route cloud security packets; [0068], “a virtual router 327 has been assigned for processing traffic between client traffic source endpoints 364 and client traffic destination endpoints 372 for one or more PPS clients 310”; See also [0055], in which a virtual router may be set up for multi-tenant mode to handle application data of several different clients; See also [0133] Protocol P1 stack instance 1552, configured in multi-tenant mode, is used for auxiliary tasks associated with traffic handled by a virtual router VR1 set up for a client C1 of a packet processing service, as well as for auxiliary tasks associated with traffic handled by a virtual router VR4 for a different client C4; Qian does not limit the number of virtual routers that may be utilized, and therefore includes instances where two virtual routers are utilized to route subscriber).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate Qian’s teachings for generating multiple virtual routers to use for routing traffic in order to repeat the same functionality across additional virtual routers, thereby increasing scalability.
Instant Application 19208995
US Patent 12328256
1. A system, comprising: a processor configured to:
generate at least four virtual routers for a cloud security service, wherein the at least four virtual routers include a first virtual router, a second virtual router, a third virtual router, and a fourth virtual router;
route cloud security service packets using the first virtual router and the third virtual router; and
route enterprise subscriber packets using the second virtual router and the fourth io virtual router; and a memory coupled to the processor and configured to provide the processor with instructions.
2. The system of claim 1, wherein: the first virtual router includes a first routing table; is the second virtual router includes a second routing table; the third virtual router includes a third routing table; and the fourth virtual router includes a fourth routing table.
3. The system of claim 1, wherein the cloud security service includes a policy-based forwarding rule to guarantee a symmetric return for Internet bound traffic.
4. The system of claim 1, wherein a cloud security service provider and an enterprise subscriber have overlapping IP address spaces.
5. The system of claim 4, wherein the overlapping IP address spaces include RFC 6598 IP addresses.
6. The system of claim 4, wherein the overlapping IP address spaces include RFC 1918 IP 25 addresses.
7. The system of claim 4, wherein: the overlapping IP address spaces are separated and becomes routable using the at least four virtual routers; the first virtual router includes a first routing table; the second virtual router includes a second routing table; the third virtual router includes a third routing table; and the fourth virtual router includes a fourth routing table.
8. The system of claim 1, wherein: the first virtual router and the third virtual router are dedicated for a cloud security service provider IP address space; the first virtual router has a first routing table; the third virtual router has a third routing table; the second virtual router and the fourth virtual router are dedicated for an enterprise io subscriber IP address space; the second virtual router has a second routing table; and the fourth virtual router has a fourth routing table.
9. The system of claim 1, wherein traffic originating from a client associated with an enterprise subscriber destined for a data center associated with the enterprise subscriber is routed is using a routing table lookup via customer routing tables associated with the second virtual router and the fourth virtual router.
10. The system of claim 1, wherein traffic originating from a client associated with an enterprise subscriber destined for an Internet site is routed using a chained routing table lookup.
11. The system of claim 1, wherein the cloud security service includes a set of firewalls for 20 security filtering of network traffic to/from a network of an enterprise subscriber.
12. A method, comprising: generating at least four virtual routers for a cloud security service, wherein the at least four virtual routers include a first virtual router, a second virtual router, a third virtual router, and a fourth virtual router; 25 routing cloud security service packets using the first virtual router and the third virtual router; and routing enterprise subscriber packets using the second virtual router and the fourth virtual router.
13. The method of claim 12, wherein: the first virtual router includes a first routing table; the second virtual router includes a second routing table; the third virtual router includes a third routing table; and the fourth virtual router includes a fourth routing table. 5
14. The method of claim 12, wherein the cloud security service includes a policy-based forwarding rule to guarantee a symmetric return for Internet bound traffic.
15. The method of claim 12, wherein a cloud security service provider and an enterprise subscriber have overlapping IP address spaces.
16. The method of claim 15, wherein the overlapping IP address spaces include RFC 6598 IP io addresses.
17. The method of claim 15, wherein the overlapping IP address spaces include RFC 1918 IP addresses.
18. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: is generating at least four virtual routers for a cloud security service, wherein the at least four virtual routers include a first virtual router, a second virtual router, a third virtual router, and a fourth virtual router; routing cloud security service packets using the first virtual router and the third virtual router; and20 routing enterprise subscriber packets using the second virtual router and the fourth virtual router.
19. The computer program product of claim 18, wherein the cloud security service includes a policy-based forwarding rule to guarantee a symmetric return for Internet bound traffic.
20. The computer program product of claim 18, wherein a cloud security service provider and an enterprise subscriber have overlapping IP address spaces.
1. A system, comprising: a processor configured to:
generate at least two virtual routers for a cloud security service, wherein the at least two virtual routers include a first virtual router and a second virtual router, wherein a first IP address space of a cloud security service provider and a second IP address space of an enterprise subscriber have an overlapping IP address space, the overlapping IP address space corresponding to at least a first portion of the first IP address space being the same as at least a second portion of the second IP address space, the first IP address space being located in a different geographical location from the second IP address space;
route cloud security service packets using the first virtual router; and
route enterprise subscriber packets using the second virtual router, wherein Internet bound traffic originating from the overlapping IP address space of the second IP address space is routed by the first virtual router to the Internet and return traffic coming from the Internet is routed by a symmetric return returning packets via a router interface that the packets were originally received bypassing a routing table lookup; and a memory coupled to the processor and configured to provide the processor with instructions.
2. The system of claim 1, wherein: the first virtual router includes a first routing table; and the second virtual router includes a second routing table.
3. The system of claim 1, wherein the cloud security service includes a policy-based forwarding rule to guarantee the symmetric return for the Internet bound traffic.
[See claim 1 above]
4. The system of claim 1, wherein the overlapping IP address space includes RFC 6598 IP addresses.
5. The system of claim 1, wherein the overlapping IP address space includes RFC 1918 IP addresses.
6. The system of claim 1, wherein the overlapping IP address space becomes routable using the at least two virtual routers, wherein the first virtual router has a first routing table, and wherein the second virtual router has a second routing table.
7. The system of claim 1, wherein: the first virtual router is dedicated for a cloud security service provider IP address space; the first virtual router has a first routing table; the second virtual router is dedicated for an enterprise subscriber IP address space; and the second virtual router has a second routing table.
8. The system of claim 1, wherein traffic originating from a client associated with an enterprise subscriber destined for a data center associated with the enterprise subscriber is routed using a routing table lookup via a customer routing table associated with the second virtual router.
9. The system of claim 1, wherein traffic originating from a client associated with an enterprise subscriber destined for an Internet site is routed using a chained routing table lookup.
10. The system of claim 1, wherein the cloud security service includes a set of firewalls for security filtering of network traffic to/from a network of an enterprise subscriber.
11. A method, comprising: generating at least two virtual routers for a cloud security service, wherein the at least two virtual routers include a first virtual router and a second virtual router, wherein a first IP address space of a cloud security service provider and a second IP address space of an enterprise subscriber have an overlapping IP address space, the overlapping IP address space corresponding to at least a first portion of the first IP address space being the same as at least a second portion of the second IP address space, the first IP address space being located in a different geographical location from the second IP address space; routing cloud security service packets using the first virtual router; and routing enterprise subscriber packets using the second virtual router, wherein Internet bound traffic originating from the overlapping IP address space of the second IP address space is routed by the first virtual router to the Internet and return traffic coming from the Internet is routed by a symmetric return returning packets via a router interface that the packets were originally received bypassing a routing table lookup.
12. The method of claim 11, wherein: the first virtual router includes a first routing table; and the second virtual router includes a second routing table.
13. The method of claim 11, wherein the cloud security service includes a policy-based forwarding rule to guarantee the symmetric return for the Internet bound traffic.
[See claim 11 above]
14. The method of claim 11, wherein the overlapping IP address space includes RFC 6598 IP addresses.
15. The method of claim 11, wherein the overlapping IP address space includes RFC 1918 IP addresses.
16. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: generating at least two virtual routers for a cloud security service, wherein the at least two virtual routers include a first virtual router and a second virtual router, wherein a first IP address space of a cloud security service provider and a second IP address space of an enterprise subscriber have an overlapping IP address space, the overlapping IP address space corresponding to at least a first portion of the first IP address space being the same as at least a second portion of the second IP address space, the first IP address space being located in a different geographical location from the second IP address space; routing cloud security service packets using the first virtual router; and routing enterprise subscriber packets using the second virtual router, wherein Internet bound traffic originating from the overlapping IP address space of the second IP address space is routed by the first virtual router to the Internet and return traffic coming from the Internet is routed by a symmetric return returning packets via a router interface that the packets were originally received bypassing a routing table lookup.
17. The computer program product of claim 14, wherein the cloud security service includes a policy-based forwarding rule to guarantee the symmetric return for the Internet bound traffic.
[See claim 16 above]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kopti (US 20120204219) disclosed service aggregators linked by VRF paths: “The service aggregators 123a and 123b are linked by Virtual Routing and Forwarding (VRF) communication paths (tunnels) 401 and 403 to the routing engine 103. VRF technology permits use of multiple routing tables within routing engine 103, thereby allowing use of identical or overlapping address spaces without conflict. The VRF communication paths (tunnels) 401 and 403 are virtual private networks implemented with routing and forwarding according to a multi-protocol label switching protocol (MPLS). “ (Kopti, [0045]).
Nallamothu et al. (US 20230079209) disclosed “virtual routing and forwarding (VRF) table distinguishes the routes for different VPNs, as well as VPN routes from provider/underlay routes on the PE device. These routes can include overlapping private network address spaces, customer-specific public routes, and provider routes on a PE device useful to the customer. A VRF instance consists of one or more routing tables, a derived forwarding table, the interfaces that use the forwarding table, and the policies and routing protocols that determine what goes into the forwarding table. Because each instance is configured for a particular VPN, each VPN has separate tables, rules, and policies that control its operation. A separate VRF table is created for each VPN that has a connection to a CE device. The VRF table is populated with routes received from directly connected CE devices associated with the VRF instance, and with routes received from other PE routers in the same VPN.” (Nallamothu, [0077]).
Ganapathy et al. (US 20210218598) disclosed techniques for running virtual routers in a cloud network that connect the cloud network to an on-premises network using a network overlay that preserves VRF information in data packets (Ganapathy, Abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JERRY B DENNISON whose telephone number is (571)272-3910. The examiner can normally be reached M-F 8:30-5:50.
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, Hadi Armouche can be reached on 571-270-3618. 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.
/JERRY B DENNISON/Primary Examiner, Art Unit 2419
Prosecution Insights