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 Amendment
This communication is considered fully responsive to the amendment filed on 02/13/2025.
Claim 1 has been amended. Claims 11-16 were previously canceled.
Claims 1-10 are pending in this application.
Response to Arguments
Applicant’s arguments with respect to claims 1-10 filed on 02/13/2026 have been considered but are moot because the arguments related solely to newly added limitations addressed in the instant Office Action with newly identified prior art, thus rendering applicant’s arguments moot.
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.
Claim 1 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 1 recites the limitation "the real network address" in lines 18-19. There is insufficient antecedent basis for this limitation in the claim.
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.
Claims 1-7 are rejected under 35 U.S.C. 103 as being unpatentable over Brar et al. (U.S. Patent Application Publication No. 20220263791, hereinafter “Brar”) in view of Thunga et al. (US Patent No. 11,252,126 B1, hereinafter “Thunga”), and further in view of Raszuk et al. (U.S. Patent Application Publication No. 20060233181, hereinafter “Raszuk”).
Regarding claim 1, Brar teaches A cloud platform overlaying infrastructure (para [0037]; There are various different types or models of cloud services including Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS), and others.)(Fig. 13 and para [0199]; FIG. 13 is a block diagram 1300 illustrating another example pattern of an IaaS architecture.) of one or more public cloud networks, the cloud platform comprising:
a first virtual cloud network (FIG. 13 and para [0199]; a virtual cloud network (VCN) 1306); and
a controller communicatively coupled to the first virtual cloud network (FIG. 13, Control Plane VCN 1316 and para [0200]; The VCN 1306 can include a local peering gateway (LPG) 1310 (e.g. the LPG 1210 of FIG. 12) that can be communicatively coupled to a secure shell (SSH) VCN 1312 (e.g. the SSH VCN 1212 of FIG. 12) via an LPG 1210 contained in the SSH VCN 1312. The SSH VCN 1312 can include an SSH subnet 1314 (e.g. the SSH subnet 1214 of FIG. 12), and the SSH VCN 1312 can be communicatively coupled to a control plane VCN 1316 (interpreted as “a controller”) (e.g. the control plane VCN 1216 of FIG. 12) via an LPG 1310 contained in the control plane VCN 1316.),
a plurality of spoke gateways (para [0121]; The control plane functions include functions used for configuring a network (e.g., setting up routes and route tables, configuring VNICs, etc.) that controls how data is to be forwarded. In certain embodiments, a VCN Control Plane is provided that computes all the overlay-to-substrate mappings centrally and publishes them to the NVDs and to the virtual network edge devices such as various gateways such as the DRG, the SGW, the IGW, etc.(interpreted as “a plurality of spoke gateways”, see para [0001] of the Specification of the instant application; “edge (spoke) gateways”))(FIG. 13 and para [0200]; The VCN 1306 can include a local peering gateway (LPG) 1310 (e.g. the LPG 1210 of FIG. 12) that can be communicatively coupled to a secure shell (SSH) VCN 1312 (e.g. the SSH VCN 1212 of FIG. 12) via an LPG 1210 contained in the SSH VCN 1312. The SSH VCN 1312 can include an SSH subnet 1314 (e.g. the SSH subnet 1214 of FIG. 12), and the SSH VCN 1312 can be communicatively coupled to a control plane VCN 1316 (e.g. the control plane VCN 1216 of FIG. 12) via an LPG 1310 contained in the control plane VCN 1316. The control plane VCN 1316 can be contained in a service tenancy 1319 (e.g. the service tenancy 1219 of FIG. 12), and the data plane VCN 1318 (e.g. the data plane VCN 1218 of FIG. 12) can be contained in a customer tenancy 1321 that may be owned or operated by users, or customers, of the system.)(The a local peering gateways (LPG) 1310, Internet Gateway 1334, and Service Gateway 1336 are interpreted as “a plurality of spoke gateways”);
(The missing/crossed out limitation will be discussed in view of Thunga) that interacts with the plurality of spoke gateways (FIG. 13 and para [0201]; The control plane VCN 1316 can include the service gateway 1336 and the NAT gateway 1338 .(interpreted as “a network traffic filtering system”)) and the controller, the network traffic filtering system configured to:
(i) determine, whether a network address overlapping condition exists for an incoming message by conducting analytics on a first subnet IP address of border gateway protocol (BGP) advertisement (Para [0005]; A private network is a network that assigns IP addresses to devices in that network from a private IP address space. … With the increase in private networks, it is possible that one private network communicating with another private network may have wholly, or partially overlapping address spaces (interpreted as “whether a network address overlapping condition exists for an incoming message”). In other words, one or several IP address conflicts may exist between the private networks.) (Para [0006]; These address conflicts can be handled by Network Address Translation (“NAT”) (interpreted as “a first mapped network address translation (NAT)”), which is a method of remapping one IP address space to another.) (para [0170]: At block 1012, routes are advertised. In some embodiments, these routes can be advertised by the gateway 600, and these routes can be based, at least in part, on the translation database 702 (interpreted as “a first mapped network address translation (NAT)”), and specifically on the outbound translation database 706. In some embodiments, the advertising of these routes can be performed according to a protocol including route advertising capability, such as, for example, Border Gateway Protocol (“BGP”) (interpreted as “border gateway protocol (BGP) advertisement”), Routing Information Protocol (“RIP”), Babel, or the like.) (para [0173]: At block 1018, an inbound data packet is received at gateway 600. ..Alternatively, in some embodiments, the network packet can be received from another cloud-based virtual private network such as network 902 via gateway 600-B.) (para [0174]: At block 1020 one or several addresses of the inbound network packet are translated according to the mapping information in the translation database 702, and specifically according to the mapping information in the inbound translation database 704. In some embodiments, this can include identifying and translating a destination IP address of the network packet. (interpreted as “conducting analytics on a first subnet IP address of border gateway protocol (BGP) advertisement”) In some embodiments, this can further include identifying and translating a source IP address of the network packet. This translation can, for example, include translation of the source address from the source IP address space to a modified source IP address space and/or translation of the destination IP address from a modified destination IP address space to the destination IP address space of the network connected to the gateway 600 via the network port 602-F.), the analytics comprising determining whether the first subnet IP address coincides with a Classless-InterDomain Routing (CIDR) representation of the first subnet IP address within a first mapped network address translation (NAT) (para [0005]: A private network is a network that assigns IP addresses to devices in that network from a private IP address space. … With the increase in private networks, it is possible that one private network communicating with another private network may have wholly, or partially overlapping address spaces) (Para [0006]; These address conflicts can be handled by Network Address Translation (“NAT”), which is a method of remapping one IP address space to another.) (para [0057]: when a VCN is created, it is associated with a private overlay Classless Inter-Domain Routing (CIDR) address space, which is a range of private overlay IP addresses that are assigned to the VCN (e.g., 10.0/16). A VCN includes associated subnets (interpreted as “the analytics comprising determining whether the first subnet IP address coincides with a Classless-InterDomain Routing (CIDR) representation of the first subnet IP address within a first mapped network address translation (NAT)” in view of paragraphs [0005-0006, 0057, 173-0174]).) ; and
(ii) responsive to a determination that a network address overlapping condition exists, routing, by a spoke gateway of the plurality of spoke gateways, a data message that includes a virtual network address as an identifier for a first tenant resource in lieu of the real network address (para [0173]: At block 1018, an inbound data packet is received at gateway 600. ...) (para [0174]: At block 1020 one or several addresses of the inbound network packet are translated according to the mapping information in the translation database 702, and specifically according to the mapping information in the inbound translation database 704. In some embodiments, this can include identifying and translating a destination IP address of the network packet. (interpreted as “a determination that a network address overlapping condition exists”)) (para 0175): At block 1022, the network packet is delivered. In some embodiments, the network packet is delivered by the gateway 600 according to the routing table 606 (interpreted as “routing, by a spoke gateway of the plurality of spoke gateways, a data message that includes a virtual network address as an identifier for a first tenant resource”). In some embodiments, the network packet can be delivered based at least in part on the translated destination address (interpreted as “an identifier for a first tenant resource”) and the routing table 606.) (The missing/crossed out limitation will be discussed in view of Raszuk).
As noted above, Brar does not specifically teach about the “a network traffic filtering system implemented as a separate cloud component”.
It, however, had been known in the art before the effective date of the instant application as shown by Thunga as follows;
Thunga teaches the “a plurality of spoke gateways” (FIG. 1A and Col. 4, lines 25-29: Hub and Spoke Arrangement of VPCs. FIG. 1A is a network diagram that includes four virtual private clouds 101A-101D (VPCs A through D) (interpreted as “a plurality of spoke gateways”) interconnected indirectly to one another via each of their attachments to the same virtual hub, illustrated as transit gateway 106 (interpreted as “a controller”)); and a network traffic filtering system implemented as a separate cloud component that interacts with the plurality of spoke gateways and the controller (FIG. 1A and Col. 4, lines 42-50: The administrator may have further selected to have each of VPCs 101A-101D (VPCs A through D) access the Internet or other public network via VPC 101B (VPC B), and thus added a public network gateway 112 to VPC 101B. The public network gateway 112 (interpreted as “a network traffic filtering system implemented as a separate cloud component”) may be or include a network address translation (NAT) gateway that enables instances in one or more private subnets to connect to the Internet or other services, but prevents the Internet or other outside network from initiating a connection with those instances).
FIG. 1A of Thunga is reproduced herein below.
PNG
media_image1.png
540
734
media_image1.png
Greyscale
(FIG. 1A of Thunga)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Brar's method by using the plurality of Spoke VPCs discussed in Thunga in order to conduct the method of Brar by system for domain name system (DNS) resolutions in a network environment that includes multiple virtual private clouds (VPCs) attached indirectly to each other via a transit gateway that serves as a hub in a hub and spoke model.
Regarding the limitation ““routing …a data message … along with Autonomous system (AS) path data and next hop addressing data,” while Brar explicitly disclosing, in para [0077], “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,” the combination of Brar and Thunga do not explicitly teach the “routing …a data message … along with Autonomous system (AS) path data and next hop addressing data.”
It, however, had been known in the art at the time of instant application as shown by Raszuk. Raszuk teaches that ‘AS_PATH’ and ‘NEXT_HOP’ are fundamental attributes used in BGP-based routing to identify and manage paths to a destination (see para [0008-0018] of Raszuk: Under the BGP-4 standard described in RFC1771, which was published by the Internet Engineering Task Force (IETF) in March 1995 and which defines the mechanism for exchanging IPv4 routes, a BGP UPDATE message includes a message header, and some or all of the following fields: (4) Path Attributes—the attributes of the routes advertised in the BGP UPDATE message including, but not limited to, the NEXT_HOP attribute, the ORIGIN attribute, and the AS_PATH attribute (interpreted as “along with Autonomous system (AS) path data”);…).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the combination of Brar and Thunga to incorporate the AS_PATH and NEXT_HOP attributes as taught by Raszuk into the gateway routing system of the combination of Brar and Thunga. The motivation for this combination would be to provide a standardized and reliable method for path identification and loop prevention in a multi-tenant or multi-cloud environment, as Brar already utilizes gateways and BGP-like protocol concepts (see para [0170] of Brar) to bridge disparate networks.
Regarding claim 2, Brar, Thunga, and Raszuk teach The cloud platform of claim 1, Brar further teaches wherein the network traffic filtering system is configured to prevent data messages associated with the network address from being routed from the first virtual cloud network by precluding propagation of the content, including the network address, from the first virtual cloud network. (Paragraph [0173]; At block 1018, an inbound data packet is received at gateway 600. The inbound network packet, also referred to herein as an inbound data packet, can be received from a network connected to the gateway 600 via one of ports 602-A through 602-E…)(Para [0174]; At block 1020 one or several addresses of the inbound network packet are translated according to the mapping information in the translation database 702, and specifically according to the mapping information in the inbound translation database 704. In some embodiments, this can include identifying and translating a destination IP address of the network packet.) (Para [0175]; … the network packet can be delivered based at least in part on the translated destination address and the routing table 606.)
Regarding claim 3, Brar and Thunga teach The cloud platform of claim 1, Brar further teaches wherein the first tenant resource is associated with a first on-premises network and the second tenant resource is associated with a second on- premises network different than the first on-premises network. (Para [0085]; Resources in on-premises networks (interpreted as “first and second on-premises networks”) that are connected to a VCN with FastConnect or VPN Connect can also use the service gateway configured for that VCN.)
Regarding claim 4, Brar, Thunga, and Raszuk teach The cloud platform of claim 1, Brar further teaches wherein the incoming message corresponds to a control plane message and the data messages being prevented from being routed over the cloud platform by at least altering the network address when the network address is overlapping a subnetwork address. (Para [0175]; … the network packet can be delivered based at least in part on the translated destination address and the routing table 606.) (Para [0121]; … The data plane functions include functions for the actual routing/forwarding of a packet (Examiner’s note: the received network packet) based upon configuration set up using control plane.
Regarding claim 5, Brar, Thunga, and Raszuk teach The cloud platform of claim 4, Brar further teaches wherein the control plane message corresponds to a Border Gateway Protocol (BGP) advertisement in which the network address is an advertised network address. (Para [0170]; … the advertising of these routes can be performed according to a protocol including route advertising capability, such as, for example, Border Gateway Protocol (“BGP”), Routing Information Protocol (“RIP”), Babel, or the like.)
Regarding claim 6, Brar, Thunga, and Raszuk teach The cloud platform of claim 5, Brar further teaches wherein the controller is configured to determine that the Border Gateway Protocol (BGP) advertisement is associated with a network address overlapping condition by at least determining whether the advertised network address is located within a mapped network address translation (NAT) (claim 1 of Brar; … generating a Network Address Translation (“NAT”) function in the gateway, the NAT function configured to advertise routes and translate addresses of received network packets; advertising routes based on the translation information;….) (Para [0171]; …these received advertisements can identifying routes according to the private IP addresses of that network. These private IP addresses can be translated by the NAT function 604 based on information contained in the translation database 702, and specifically based on information contained in the inbound translation database 704.), the mapped NAT comprises address translations for one or more network addresses identified to have overlapping network addresses with a subnetwork address associated with a component of the cloud platform or a component of the previously registered tenant resource. (claim 1 of Brar; … populating a unified routing table in the gateway based on the plurality of first IP addresses in the private address space and on translated route advertisements; receive an inbound network packet at the gateway; translating an inbound address of the inbound network packet with the NAT function…)
Regarding claim 7, Brar, Thunga, and Raszuk teach The cloud platform of claim 4, Brar further teaches wherein the network traffic filtering system is configured to program a data store associated with each of a plurality of components deployed within the first virtual cloud network to route the data messages identifying the first tenant resource supplying the incoming message with a virtual network address in lieu of the network address. (Para [0065]; Route tables, security rules, and DHCP options may be configured for a VCN. Route tables are virtual route tables for the VCN and include rules to route traffic from subnets within the VCN to destinations outside the VCN by way of gateways or specially configured instances. A VCN's route tables can be customized to control how packets are forwarded/routed to and from the VCN…)
Claims 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Brar in view of Thunga, in view of Raszuk, and further in view of “AWS Solution – Transit VPC” by Jeff Barr | on 11 AUG 2016 | in Amazon VPC, AWS Marketplace (https://aws.amazon.com/blogs/aws/aws-solution-transit-vpc/)(hereinafter “Barr”).
Regarding claim 8, Brar, Thunga, and Raszuk teach the cloud platform of claim 4, wherein the first virtual cloud network corresponds to a first virtual private cloud network that overlays networking infrastructure of a first public cloud network and the cloud platform further comprising:
It is noted that while disclosing the cloud platform of claim 4, wherein the first virtual cloud network corresponds to a first virtual private cloud network that overlays networking infrastructure of a first public cloud network, a combination of Brar, Thunga, and Raszuk does not specifically teach about “a transit virtual private cloud network coupled to the first virtual private cloud network, the transit virtual private cloud network allowing a transmission of data messages from the first virtual private cloud network to a second virtual private cloud network deployed to overlay a different region of the first public cloud network.” It, however, had been known in the art before the effective date of the instant application as shown by Barr as follows (See Barr, page 1 and Figure in page 1 ; The new Transit VPC Solution shows you how to implement a very useful networking construct that we call a transit VPC. You can use this to connect multiple Virtual Private Clouds (VPCs) that might be geographically disparate and/or running in separate AWS accounts, to a common VPC that serves as a global network transit center. This network topology simplifies network management and minimizes the number of connections that you need to set up and manage. Even better, it is implemented virtually and does not require any physical network gear or a physical presence in a colocation transit hub. Here’s what this looks like)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the combination of Brar, Thunga, and Raszuk by using the features of Barr in order to have more effective method such that "The new Transit VPC Solution shows you how to implement a very useful networking construct that we call a transit VPC. You can use this to connect multiple Virtual Private Clouds (VPCs) that might be geographically disparate and/or running in separate AWS accounts, to a common VPC that serves as a global network transit center." [Barr; lines 8-10 in page 1].
Regarding claim 9, Brar, Thunga, and Raszuk teach the cloud platform of claim 4, wherein the first virtual cloud network corresponds to a first virtual private cloud network overlaying networking infrastructure of a first public cloud network and the cloud platform further comprising:
It is noted that while disclosing the cloud platform of claim 4, wherein the first virtual cloud network corresponds to a first virtual private cloud network overlaying networking infrastructure of a first public cloud network, a combination of Brar, Thunga, and Raszuk does not specifically teach about “a transit virtual private cloud network coupled to the first virtual private cloud network, the transit virtual private cloud network allowing a transmission of data messages from the first virtual private cloud network to a second virtual private cloud network deployed to overlay networking infrastructure of a second public cloud network different than the first public cloud network.” It, however, had been known in the art before the effective date of the instant application as shown by Barr as [AltContent: rect]follows (See Barr, page 1 and Figure in page 1 ; The new Transit VPC Solution shows you how to implement a very useful networking construct that we call a transit VPC. You can use this to connect multiple Virtual Private Clouds (VPCs) that might be geographically disparate and/or running in separate AWS accounts, to a common VPC that serves as a global network transit center. This network topology simplifies network management and minimizes the number of connections that you need to set up and manage. Even better, it is implemented virtually and does not require any physical network gear or a physical presence in a colocation transit hub. Here’s what this looks like). The Figure in page 1 of Barr is reproduced herein below.
PNG
media_image2.png
399
496
media_image2.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the combination of Brar, Thunga, and Raszuk by using the features of Barr in order to have more effective method such that "The new Transit VPC Solution shows you how to implement a very useful networking construct that we call a transit VPC. You can use this to connect multiple Virtual Private Clouds (VPCs) that might be geographically disparate and/or running in separate AWS accounts, to a common VPC that serves as a global network transit center." [Barr; lines 8-10 in page 1]. The benefit of such incorporation enables that the network traffic filtering system of the controller may transmit data messages between VPCs via a common transit VPC as a global network transit center.
Regarding claim 10, Brar, Thunga, Raszuk and Barr teach the cloud platform of claim 9, Brar further teaches wherein the first public cloud network is provided and managed by a first cloud provider and the second public cloud network is provided and managed by a second cloud provider. (Para [0100]; …, Providers can represent a service as a private endpoint in multiple VCNs of one or more customers...).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00.
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, Derrick W Ferris can be reached at 571-272-3123. 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.
/WON JUN CHOI/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights