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 action is responsive to an amendment filed on 09/05/2025. Claims 1-2, 5-13 and 15-20 have been amended. Claims 4 and 14 have been canceled. Claims 1-2, 5-13 and 15-20 are pending for examination.
Response to Arguments
Applicant’s arguments, see Applicant Arguments/Remarks, filed on 09/05/2025, with respect to the rejection of the pending claims under 35 U.S.C. §102 have been fully considered.
Applicant argues that Agarwal fails to teach the datacenters in any of these configurations to include local network managers that do not have publicly routable network addresses and that are thus unable to accept connection requests initiated from a public cloud, as required by amended claim 1. Additionally, Agarwal fails to teach such local network managers initiating connections to a publicly routable network address of a connection server, which is also required by amended claim 1.
However, in current rejection, Examiner relies on Alkhatib to teach these amended limitations. See newly crafted rejection, infra.
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-4, 5, 8, 11-13, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0296035 (Agarwal et al.) in view of US 7139828 (Alkhatib et al.).
Regarding Claim 1, Agarwal teaches a method for managing datacenters ([Abstract] A system provisions global logical entities that facilitate the operation of logical networks that span two or more datacenters), the method comprising: at a connection server that handles a plurality of connections between a network management system in a public cloud and datacenters managed by the network management system ([¶¶ 0002-0003], global logical entities facilitate the operation of logical networks that span two or more datacenters. …The traffic of a global logical network may flow between different datacenters as well as locally within a datacenter. The traffic of a local logical network is conducted by local logical switches and routers that are confined to the datacenter, while the traffic of a global logical network is conducted by global logical switches and routers that can span two or more datacenters. [¶ 0005], a global control cluster (GCC) controls the operations of global logical entities across multiple datacenters, while local control clusters (LCCs) control the operations of local logical entities. …a global control cluster controls all logical entities across all participating sites, regardless of whether those logical entities are global logical entities or local logical entities. [¶ 0082], the global control cluster is located in the cloud (e.g., Internet)): receiving (i) a first application programming interface (API) request for a first local network manager located at a first datacenter belonging to a first datacenter group of a first tenant and (ii) a second API request for a second local network manager located at a second datacenter belonging to a second datacenter group of a second tenant ([¶ 0037-0038], global logical entities that, once provisioned, facilitate the operation of logical networks that span two or more datacenters. …the global logical entities operate alongside local logical entities that are for operating logical networks that are local within a datacenter. FIG. 1 illustrates a multi-site environment 100 in which global logical networks span multiple datacenters (multiple physical sites). A datacenter such as the datacenter 101 or 102 provides computing and/or networking resources to tenants or clients. The computing and/or network resources are logically organized into logical networks for different tenants. [¶ 0040] As illustrated, the datacenter 101 provides network nodes 111-124 as computing/networking resources for its tenants, while the datacenter 102 provides network nodes 131-142 as computing computing/networking resources for its tenants. [¶ 0117], Each network manager provides interfaces (e.g., application programming interface or API) for network administrators. [¶ 0130] receives a provisioning request or command from the user or network administrator. [¶ 0149], The network manager accepts provisioning requests for global logical networks); based on a site identifier associated with the first datacenter and included in the first API request, sending the first API request to the first local network manager via a first connection previously initiated by the first local network manager; and based on a site identifier associated with the second datacenter and included in the second API request, sending the second API request to the second local network manager via a second connection previously initiated by the second local network manager ([¶¶ 0006-0007], the global control cluster collects and distributes routing information across the multiple datacenters. …associate the collected routing information with locale identifiers. A locale identifier is for identifying a datacenter. …a locale identifier is for identifying a particular routing path or a forwarding hop as being in a particular datacenter. …the global control cluster uses locale identifiers associated with routing information to determine where the available routing resources are and to plan routing paths. …global control cluster distributes routing information to host machines, the distributed routing information being associated with locale identifiers such that the receiving host machines would be able to determine the locale (i.e., the site or the datacenter) of routing paths or forwarding hops and so to be able to forward packets accordingly. [¶¶ 0094-0095], collected routing information with locale identifiers. A locale identifier is for identifying a datacenter. FIG. 9 illustrates the reporting of information collected by datacenters 901-904 in a multi-site environment 900. …locale identifier is for identifying a particular routing path or a forwarding hop as being in a particular datacenter. a locale identifier is for identifying a set of routing information as being collected at a particular datacenter. …the global control cluster uses locale identifiers associated with routing information to determine where the available routing resources are and to plan routing paths. …the global control cluster distributes routing information to host machines, the distributed routing information being associated with locale identifiers such that the receiving host machines would be able to determine the locale (i.e., the site or the datacenter) of routing paths or forwarding hops and so to be able to forward packets accordingly. Since, as aforementioned, Agarwal teaches different datacenters provide resources for different tenants, therefore it would be realized that global control cluster distributes request to a particular datacenter for a particular tenant based on the locale identifier associated with the datacenter).
Agarwal teaches identifying a particular routing path for a particular datacenter, however, Agarwal does not explicitly teach, Alkhatib teaches the first and second local network managers do not have publicly routable network addresses and are therefore unable to accept connection requests initiated from the public cloud, and the first connection is a persistent connection previously initiated by the first local network manager to a publicly routable network address of the connection server, and the second connection is a persistent connection previously initiated by the second local network manager to the publicly routable network address of the connection server (emphasis added) ([C.5:L.4-22] FIG. 1 shows Agent 30, host A 18, host B 34, and server 38 connected to Internet. Host A registers with Agent 30 and sets up a persistent communication with Agent 30 [i.e., persistent connection previously initiated] so that host A can be accessible by entities outside of private network 10. In one example, host B is a computer with a public IP address. Host B knows the domain name for host A; however, host B does not know an address for host A [i.e., host A does not have publicly routable network address]. According to the present invention, host B requests server 38 to resolve a domain name for host A. Server 38 responds to host B's request by returning the IP address for Agent 30 [i.e., a publicly routable network address of the connection server]. Host B creates a communication for host A and sends that communication to Agent 30. Agent 30 then forwards the communication to host A via the persistent connection between Agent 30 and host A. Host A can reply back to host B via the persistent connection. Note: Since, Alkhatib teaches a mechanism for a persistent outbound connection enabling communication with a private-network node, therefore, it would be an obvious and routine design choice to apply the same procedure to any a second node or datacenter, resulting in a second persistent connection used for a second communication. Thus, a person of ordinary skill in the art would have recognized that a second communication to a second node could be performed using the same registration and persistent-connection procedure taught for the first node).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Alkhatib's teachings of using a persistent connection that initiated previously to communicate with a private node that does not have publicly routable address to the teachings of Agarwal because such incorporation would have an advantageous addition to the system discloses by Agarwal since it would have drastically cut overhead, boosting speed, improving network use, lowering latency, and enabling smoother, faster data exchange for frequent requests like API calls or real-time data.
Regarding Claim 2, Agarwal teaches the method of claim 1, wherein: the connection server is one of a plurality of connection servers operating in the public cloud for the network management system ([¶ 0082], the global control cluster is located in the cloud (e.g., Internet) rather than in any particular datacenter), and a second connection server of the plurality of connection servers handles (i) a third connection initiated by a third local network manager at a third datacenter belonging to the first datacenter group and (ii) a fourth connection initiated by a fourth local network manager at a fourth datacenter belonging to the second datacenter group ([Fig. 1, ¶¶ 0045-0047 ], the global logical network X includes global logical switches (GLSs) X1, X2, and X3 as well as a global logical router (GLR) GLR X4. The GLS X1 (191) is for conducting L2 (data-link layer) traffic between VMs 118-121, the GLS X2 (192) is for conducting L2 traffic between the VMs 139-140, the GLS X3 (193) is for conducting L2 traffic between VMs 122-124 and 141-142, while the GLR X4 (194) is for conducting L3 traffic among LLS X1, X2, and X3. A global logical entity (such as the GLR 194 and the GLS 193) can span multiple datacenters, and the network traffic being handle by those global logical entities can travel from one datacenter to another (i.e., between datacenters A and B). In some embodiments, not all logical entities of a global logical network span multiple datacenters. For example, the global logical switch X2 (192) only has VMs in datacenter B, while the global logical switch X1 (191) only has VMs in datacenter A. different logical networks may belong to different tenants. A tenant with VMs in multiple different datacenters can configure its network to be a global logical network, whose routers and switches can span multiple datacenters. In some embodiments, one tenant may simultaneously own multiple logical networks, whether local or global. In some embodiments, network traffic between the different logical networks are be handled by routers that are mutually accessible to the different logical networks. Since, Agarwal teaches, global control cluster controls the operations of global logical entities across multiple datacenters belongs to different tenants, therefore it would be realized that global control cluster control a third connection and fourth connection initiated by a third local network manager at a third datacenter and fourth local network manager at a forth datacenter).
Regarding Claim 3, Agarwal teaches the method of claim 1 further comprising: receiving a third API request for a third local network manager located at a third datacenter belonging to the first datacenter group ([¶¶ 0037-0038], global logical entities that, once provisioned, facilitate the operation of logical networks that span two or more datacenters. …the global logical entities operate alongside local logical entities that are for operating logical networks that are local within a datacenter. FIG. 1 illustrates a multi-site environment 100 in which global logical networks span multiple datacenters (multiple physical sites). A datacenter such as the datacenter 101 or 102 provides computing and/or networking resources to tenants or clients. The computing and/or network resources are logically organized into logical networks for different tenants. [¶ 0117], Each network manager provides interfaces (e.g., application programming interface or API) for network administrators. [¶ 0130] receives a provisioning request or command from the user or network administrator. [¶ 0149], The network manager accepts provisioning requests for global logical networks); and based on a site identifier associated with the third datacenter and included in the third API request, sending the third API request to the third local network manager via a third connection previously initiated by the third local network manager ([¶¶ 0094-0095], global control cluster collects and distributes routing information across the multiple datacenters. Associate the collected routing information with locale identifiers. A locale identifier is for identifying a datacenter. The information reported to the global control cluster by each datacenter is associated with the datacenter's locale ID. a locale identifier is for identifying a particular routing path or a forwarding hop as being in a particular datacenter. In some embodiments, a locale identifier is for identifying a set of routing information as being collected at a particular datacenter. The global control cluster uses locale identifiers associated with routing information to determine where the available routing resources are and to plan routing paths. The global control cluster distributes routing information to host machines, the distributed routing information being associated with locale identifiers such that the receiving host machines would be able to determine the locale (i.e., the site or the datacenter) of routing paths or forwarding hops and so to be able to forward packets accordingly. As aforementioned, Agarwal teaches routing request from different tenant to particular datacenter based on the locale identifier of that particular datacenter in a multi-tenant, muti-datacenters environment, therefore, it would be appreciated that a third request can be routed to the third datacenter based on the locale identifier of the third datacenter).
Regarding Claim 5, Agarwal teaches the method of claim 1, wherein the first connection is initiated by a connection agent at the first local network manager to the publicly routable network address of the connection server ([Fig. 3, ¶ 0058] The controller agent 340 receives control plane messages from a controller or a cluster of controllers. In some embodiments, these control plane message includes configuration data for configuring the various components of the virtualization software (such as the MPSE 320 and the MPRE 330) and/or the virtual machines. In the example illustrated in FIG. 3, the controller agent 340 receives control plane messages from the controller cluster 360 from the physical network 390 and in turn provides the received configuration data to the MPRE 330 through a control channel without going through the MPSE 320. The controller agent receives control plane messages from the MPSE 320 and forwards configuration data to the router 330 through the MPSE 320. In some embodiments, the controller agent 340 receives control plane data for global logical entities (switches and routers) from a global control cluster and control plane messages for local logical entities from a local control cluster of the datacenter).
Regarding Claim 8, Agarwal teaches The method of claim 1, wherein the public cloud is a first public cloud, the first datacenter is a physical on-premises datacenter of the first tenant and the second datacenter is a virtual datacenter of the second tenant operating in a second public cloud ([¶ 0038] FIG. 1 illustrates a multi-site environment 100 in which global logical networks span multiple datacenters (multiple physical sites). The figure illustrates two datacenters 101 and 102 (datacenter A and datacenter B). A datacenter such as the datacenter 101 or 102 provides computing and/or networking resources to tenants or clients. [¶ 0040], the datacenter 101 provides network nodes 111-124 as computing/networking resources for its tenants, while the datacenter 102 provides network nodes 131-142 as computing computing/networking resources for its tenants. In some embodiments, some of these computing and networking resources are operating on a virtualized platform, wherein virtual machines (VMs) hosted by computing devices (host machines) running virtualization software serve as the computing and network resources).
Regarding Claim 11, Agarwal teaches a non-transitory machine-readable medium storing a connection server program which when executed by at least one processing unit ([Fig. 21, ¶¶ 0151,0160].
The rest of the claim limitations are identical and/or equivalent in scope to claim 1, therefore, Claim 11 is rejected under the same rationale as Claim 1.
Regarding Claims 12-13, 15 and 18, the claim limitations are identical and/or equivalent in scope to claims 2-3, 5 and 8, respectively, therefore, Claims 12-13, 15 and 18 are rejected under the same rationale as claims 2-3, 5 and 8.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal in view of Alkhatib, and further in view of US 12143268 (Garty).
Regarding Claim 6, Agarwal teaches the method of claim 1, wherein …the second API request is initiated by a network administrator for the second datacenter group through a user interface of a second network management service of the network management system in the public cloud ([¶ 0117], Each network manager provides interfaces (e.g., application programming interface or API) for network administrators to enter specifications for logical networks and logical entities. [¶ 0130], receives a provisioning request or command from the user or network administrator for creating global logical entities).
Agarwal in view of Alkhatib do not explicitly teach, Garty teaches the first API request is initiated by a first network management service of the network management system in the public cloud to manage the first datacenter group ([C.1:L.22-28] employ multiple computing resources in cloud-based networks. These computing resources are hosted remotely and are managed by a third party. Usually in the cloud-based networks, the computing resources are associated with one or more projects that may be owned or administered by an organization. [C. 8:L.27-35], provide a cloud-based computing environment that allows the managed network to host software applications, store data, and otherwise utilize remotely-hosted computing resources. The cloud-based computing environment may be provided atop an infrastructure of various computing resources that allow the computing environment to be defined, modified, and otherwise tailored to the needs of the managed network. [C.13:L.7-12], the discovery computing system may be further configured to transmit a first API query to the remote computing system to retrieve organization information associated with the organization that administer the project).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Garty's teachings of receive a an API request from a cloud-based computing environment to the combined teachings of Agarwal and Alkhatib as a predictable alternative to retrieve organization information associated with an organization.
Regarding Claim 16, The claim limitations are identical and/or equivalent in scope to claim 6, therefore Claim 16 is rejected under the same rationale as Claim 6.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal in view of Alkhatib, and further in view of US 2021/0350008 (Sofia et al.).
Regarding Claim 7, Agarwal in view of Alkhatib do not explicitly teach, however, Sofia teaches the method of claim 1 further comprising: receiving a response to the first API request from the first local network manager and providing the response to an initiator of the first API request ([¶ 0003], receiving an outbound payload for output to a requestor as part of a response to a call by the requestor to an application programming interface (API). [¶ 0026], he banking system may then send a response to the requestor via the outgoing API code which will access the policy information which indicates that the customer account number has to be encrypted before sending a response to the requestor, or initiator of the API at the ATM).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Sofia's teachings of receive a response to an API request and provide the response to the initiator to the combined teachings of Agarwal and Alkhatib because such incorporation would have allowed to build a bridge to/from the legacy systems using interfaces such as application programming interfaces (APIs) [Sofia, ¶ 0002].
Regarding Claim 17, The claim limitations are identical and/or equivalent in scope to claim 7, therefore Claim 17 is rejected under the same rationale as Claim 7.
Claims 9-10 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal in view of Alkhatib, and further in view of US 2022/0210487 (Hassler).
Regarding Claim 9, Agarwal in view of do not explicitly teach, however, Hassler teaches the method of claim 1, wherein the first and second connections are Hypertext Transfer Protocol, Version 2 (HTTP/2) connections that use Transmission Control Protocol (TCP) ([¶ 0042] After sending the first data object to the cache server 106, the origin server 102 may determine to send a second data object to the client 108 via the HTTP/2 Server Push method. [¶ 0062], Based on the request for the earlier data object, the origin server may have determined to send additional data objects to the cache server, such as via HTTP/2 server push methods…the cache server may have generated a rule at the TCP layer, associated with the client and the earlier data object, to cause future data objects addressed to the client to be forwarded, at the TCP layer, to a specified port on a downstream network interface of the cache server).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Hassler's HTTP/2 Server Push method to the combined teachings of Agarwal and Alkhatib because such incorporation would have allowed proactively send data to the client which reduces the number of round trips needed to fetch all resources.
Regarding Claim 10, Agarwal in view of Alkhatib do not explicitly teach, however, Hassler teaches the method of claim 9, wherein the HTTP/2 connections enable the connection server to push requests onto the first and second connections ([¶ 0042] After sending the first data object to the cache server 106, the origin server 102 may determine to send a second data object to the client 108 via the HTTP/2 Server Push method. [¶ 0062], Based on the request for the earlier data object, the origin server may have determined to send additional data objects to the cache server, such as via HTTP/2 server push methods…the cache server may have generated a rule at the TCP layer, associated with the client and the earlier data object, to cause future data objects addressed to the client to be forwarded, at the TCP layer, to a specified port on a downstream network interface of the cache server).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Hassler's HTTP/2 Server Push method to the combined teachings of Agarwal and Alkhatib because such incorporation would have allowed proactively send data to the client which reduces the number of round trips needed to fetch all resources.
Regarding Claims 19 and 20, The claim limitations are identical and/or equivalent in scope to claims 9 and 10, therefore, Claims 19 and 20 are rejected under the same rationale as Claims 9 and 10.
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 MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/ Examiner, Art Unit 2457
/ARIO ETIENNE/ Supervisory Patent Examiner, Art Unit 2457