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 .
Terminal Disclaimer
The terminal disclaimer filed on 08/06/2026 which ties the present application to U.S. Patent No. 11,682,055 have been accepted.
Response to Amendment
Applicant’s “Amendment” filed on 07/30/2026 has been considered.
Claims 21, 23, 25, 29, 31,33, 35, 37, and 39 are amended. Claims 21-40 remain pending in this application and an action on the merits follow.
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 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 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2013/0136133 to Alkhatib et al., in view of U.S. Patent Application Publication No. 2013/0166705 to Flavel et al.
With regard to claims 21, 29, and 35, Alkhatib discloses a system, comprising:
a networking device of a provider network located at a facility (Fig. 3, paragraph 57, As used herein, the phrase "physical network" is not meant to be limiting, but may encompass tangible mechanisms and equipment (e.g., fiber lines, circuit boxes, switches, antennas, IP routers, and the like), as well as intangible communications and carrier waves, that facilitate communication between endpoints at geographically remote locations.);
one or more computing devices of the provider network configured to implement a virtual private cloud (VPC) within the provider network (Fig. 2, paragraphs 36-37, For instance, the cloud computing platform 200 may be a public cloud, a private cloud, or a dedicated cloud. The cloud computing platform 200 may include one or more data centers (e.g., data center 225) that comprise nodes (e.g., nodes 211 and 212) for hosting service applications and other software.); and
one or more computing devices of the provider network configured to: instantiate a virtual interface that enables connectivity between the VPC implemented within the provider network and an endpoint external to the provider network, wherein the endpoint external to the provider network is connected to the provider network via the networking device located at the facility (Fig. 3, paragraphs 40, 46, 58, and 60, In another aspect, the endpoints 201, 202, and 230 communicate externally through a physical network topology to resources of a remote network (e.g., resource 375 of the enterprise private network 325 of FIG. 3). If the endpoint (e.g., endpoints 201 and 202) is hosted on a virtual machine (e.g., virtual machines 270 and 275), the driver (e.g., driver 223) is implemented within the network stack, hides all existing adaptors, and presents a single virtualized interface of the network. In this embodiment, the driver 223 may represent an independent VM switch or may be incorporated within an existing VM switch (e.g., VM switch 222). The VM switch 222, in embodiments, is provided to offer isolated connectivity between endpoints internal to and external of the data center 225, as more fully discussed with reference to FIG. 3. Generally, the enterprise private network 325 includes resources, such as resource 375 that are managed by a customer of the cloud computing platform 200. Typically, the resources 355 and 375, and the data center 225 include, or are linked to, some form of a computing unit (e.g., central processing unit, microprocessor, etc.) to support operations of the endpoint(s) and/or component(s) running thereon. Examiner notes that the resources 355 and 375 can be considered as “the endpoint external to the provider network is connected to the provider network via the networking device located at the facility”. Examiner notes that a single virtualized interface of the network of the endpoint hosted on a virtual private cloud platform offers isolated connectivity between endpoints internal to and external of the data center, wherein endpoints enteral of the data center are the resources 355 and 375, which is considered as “instantiate a virtual interface that enables connectivity between the VPC implemented within the provider network and an endpoint external to the provider network”.).
However, Alkhatib does not disclose a networking device of a provider network located at a co-location facility.
However, Flavel teaches a networking device of a provider network located at a co-location facility (A virtual private cloud (VPC) may include one or more virtual data centers (VDCs) that each defines a logical grouping of virtual machines, local load balancers, firewalls and other network resource elements at a single location. Multiple virtual data centers may be supported within the same actual data center at a location., paragraph 21).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Alkhatib to include, a networking device of a provider network located at a co-location facility, as taught in Flavel, in order to customize virtual private cloud computing networks (Flavel, paragraph 3).
With regard to claims 22, 30, and 36, Alkhatib discloses the networking device of the provider network is connected to a networking device external to the provider network via a dedicated interconnect, and the network device external to the provider network provides network routing to the endpoint external to the provider network (paragraph 36, For instance, the cloud computing platform 200 may be a public cloud, a private cloud, or a dedicated cloud.).
With regard to claims 23, 31, and 37, the combination of references discloses the one or more computing devices of the provider network are further configured to: coordinate performance of one or more border gateway protocol (BGP) sessions between a virtual router included in the VPC and the network device external to the provider network; and route traffic between the VPC and the endpoint external to the provider network, via the networking device at the co-location facility, using addressing information exchanged in the one or more border gateway protocol sessions (Alkhatib, abstract, paragraphs 61-62, Generally, the overlay 330 represents a layer of virtual IP addresses, instead of physical IP addresses, that virtually represents the endpoints of the service application and connects the virtual representations. In other embodiments, the overlay 330 is a virtual network built on top of the physical network 380 that includes the resources allocated to the customer controlling the service application. In operation, the overlay 330 maintains one or more logical associations of the interconnected end points A 211, B 385, C 212, and D 345 and may enforce the access control/security associated with the end points A 211, B 385, C 212, and D 345 in order to achieve physical network reachability (e.g., using a physical transport). The driver may then solicit the directory service 220 to perform a lookup procedure by sending a request comprising indicia of a source IP address that points to the subject endpoint, and a destination IP address, as depicted at block 402. Flavel, paragraph 21, ).
With regard to claims 24, 32, and 38, Alkhatib discloses the networking device of the provider network is connected to a networking device external to the provider network via a network intermediary that has established a dedicated interconnect with the networking device of the provider network, the dedicated interconnect of the network intermediary is partitioned, wherein at least one partition is allocated for providing connectivity to the network device external to the provider network, and the network device external to the provider network provides network routing to the endpoint external to the provider network (paragraph 7, Generally, the drivers support selecting a most appropriate format and pathway of a communication between endpoints that are allocated to the service application, while virtually partitioning the allocated network adapters from other resources in a data center. ).
With regard to claims 25, 33, and 39, the combination of references discloses the one or more computing devices of the provider network are further configured to: receive a virtual local area network (VLAN) instruction for routing traffic between the VPC and the endpoint external to the provider network; and route traffic between the VPC and the endpoint external to the provider network, via the networking device at the co-location facility, in accordance with the VLAN instruction (Alkhatib, paragraphs 9 and 40, The driver may further package the source and destination IP addresses within a request for routing information, and convey the request to the directory service, either internally or externally. By way of example, the channels may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). Flavel, paragraph 21).
With regard to claims 26 and 40, Alkhatib discloses the VLAN instruction further specifies a subnet address range for a virtual local area network external to the provider network that is attached to the VPC via the connection provided by the network intermediary (paragraph 22, Generally, the directory service maintains a mapping between virtual internet protocol (IP) addresses and location-dependent addresses of a physical network.).
With regard to claims 27 and 34, Alkhatib discloses one or more computing devices configured to implement a connectivity coordinator configured to: receive a request, submitted by a customer of the provider network, to instantiate the virtual interface to be used to enable access between the VPC and an external network of the customer, external to the provider network; configure the access between the VPC and the external network of the customer (paragraph 43, In one instance, the architecture of the data center 225 allows a management system (e.g., fabric controller 232) or administrators of the cloud computing platform 200 to instantiate new endpoints or reallocate present endpoints to support a service application.).
With regard to claim 28, Alkhatib substantially discloses the claimed invention, however, Alkhatib does not disclose determine an Internet Protocol (IP) address range to be assigned, at least in part, on an address range of a subnet of the VPC, wherein one or more IP addresses within the IP address range to be assigned are private IP addresses.
However, Flavel teaches determine an Internet Protocol (IP) address range to be assigned, at least in part, on an address range of a subnet of the VPC, wherein one or more IP addresses within the IP address range to be assigned are private IP addresses (An example of a virtual private network created using the process shown in FIG. 4 involves an intra-virtual data center customer subnet behind a firewall. In this example, firewall support for network address translation (NAT) is selected so that a pre-determined set of public internet protocol addresses setup to be routed to the firewall can be directed to the intra-virtual data center customer subnet. The firewall may take an internet protocol address from the pre-determined public address space such as 12.0.0.10 and translate this to the private internet protocol address, paragraph 68).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Alkhatib to include, determine an Internet Protocol (IP) address range to be assigned, at least in part, on an address range of a subnet of the VPC, wherein one or more IP addresses within the IP address range to be assigned are private IP addresses, as taught in Flavel, in order to customize virtual private cloud computing networks (Flavel, paragraph 3).
Response to Arguments
Applicants' arguments filed on 07/30/2026 have been fully considered but they are not fully persuasive especially in light of the previously references applied in the rejections.
Applicants remark that “the combination of references does not disclose a networking device of a provider network located at a co-location facility”.
Examiner directs Applicants' attention to the office action above.
Conclusion
Please refer to form 892 for cited references.
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 extension fee 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 from the examiner should be directed to Ariel Yu whose telephone number is 571-270-3312. The examiner can normally be reached on Monday-Friday 9:00am-5:00pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Obeid Fahd A can be reached on 571-270-3324. 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.
/ARIEL J YU/Primary Examiner, Art Unit 3627
Prosecution Insights