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 is in response to an amendment/response/communication filed 8/14/2024.
No claims have been cancelled.
No claims have been added.
Claims(s) 1-20 is/are currently pending.
Information Disclosure Statement
The information disclosure statement(s) (IDS(s)) submitted on 12/29/2023, 1/25/2024 and 8/14/2024 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner.
Drawings
The drawings were received on 11/28/2023. These drawings are accepted.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claim 4 is objected to because of the following informalities: claim 4, line 2, notes “no-prem” which is considered as a misspelling. The Examiner suggests changing to “on-premises”, or something similar. Appropriate correction is required.
Claim 4 is objected to because of the following informalities: claim 4, line 3, notes “no-prem” which is considered as a misspelling. The Examiner suggests changing to “on-premises”, or something similar. Appropriate correction is required.
Claim 11 is objected to because of the following informalities: claim 11, line 2, notes “no-prem” which is considered as a misspelling. The Examiner suggests changing to “on-premises”, or something similar. Appropriate correction is required.
Claim 11 is objected to because of the following informalities: claim 11, line 3, notes “no-prem” which is considered as a misspelling. The Examiner suggests changing to “on-premises”, or something similar. Appropriate correction is required.
Claim 18 is objected to because of the following informalities: claim 18, line 3, notes “no-prem” which is considered as a misspelling. The Examiner suggests changing to “on-premises”, or something similar. Appropriate correction is required.
Claim 18 is objected to because of the following informalities: claim 18, line 4, notes “no-prem” which is considered as a misspelling. The Examiner suggests changing to “on-premises”, or something similar. Appropriate correction is required.
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.
Claim(s) 1, 3, 5, 8, 10, 12, 15, 17 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday et al. US 20220038554 in view of Zhao et al. US 20200382345.
As to claim 1:
Merwaday et al. discloses:
A method for deploying network functions into target cloud
computing environments in a cellular telecommunication network using an overlay network, the method comprising:
deploying, by a mobile network operator, a first cloud native function in a
first public cloud;
(“FIG. 21 shows example edge cloud deployments including Multi-Access Support including an OpeNESS LTE Edge Cloud Deployment model support 2101 and an OpenNESS 5G SA Edge Cloud Deployment Model support 2102. OpenNESS supports multiple deployment options on an 5G Stand alone and LTE cellular network, as shown in FIG. 21. In these examples, OpenNESS may be deployed on 5G, LTE or IP (wireless or wireline) networks. The networking abstraction provided by the Edge Node Dataplane, network policy configuration and the Core Network Configuration Agent (CNCA) abstracts the protocol, access technology and access technology configuration differences such that edge applications see standard IP traffic as though they are deployed in the cloud.”; Merwaday et al.; 0276)
(“OpenNESS is intended for customers/users such as operators to conduct lab/field trials of edge compute in network edge and On-Premises Edge, ISVs, or OSVs to develop edge compute infrastructure solutions that take advantage of the COTS Architecture, and/or application developers who intend to develop applications for the edge, port the applications from public cloud to edge to take advantage of being closer to user.”; Merwaday et al.; 0235)
(“…By running multiple cloud connector instances from different cloud service providers on the same Edge Node, a multi-cloud experience can be easily implemented. OpenNESS supports this by providing the ability to deploy public cloud IOT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu OpenEdge on edge compute platform. The existing IOT gateways can be migrated to OpenNESS as is or enhanced to call EAA APIs using extensions like Lambda functions.”; Merwaday et al.; 0329)
(where
“LTE cellular” maps to “cellular telecommunication network”,
“operators” maps to “by mobile network operator”,
“public cloud”/”Amazon AWS” maps to “first public cloud”,
“IOT gateways” maps to “first cloud native function”
“deploy” maps to “deploying”
deploying, by the mobile network operator, a second cloud native function
in a second public cloud;
(where
“multi-cloud”/”public cloud”/Baidu OpenEdge” maps to “second public cloud”
“IOT gateways” maps to “second cloud native function”
providing a connected virtual private cloud;
(“…Access technologies” in the context of OpenNESS refers to various types of traffic that OpenNESS solution can be handled. They include 5G, LTE (GTP/IP), Wireline (IP), WiFi (IP), and/or the like. “Multi-cloud” and/or “multi-cloud environments” in the context of OpenNESS refers to support in OpenNESS to host multiple Public or Private cloud application on the same node or in the OpenNESS compute cluster. These cloud applications can come from (e.g., Amazon AWS Greengrass, Baidu cloud, etc.).”; Merwaday et al.; 0232)
(“…The edge aggregation nodes 1340 and other systems of the edge cloud 1110 are connected to a cloud or data center 1360, which uses a backhaul network 1350 to fulfill higher-latency requests from a cloud/data center for websites, applications, database servers, etc….”; Merwaday et al.; 0163)
(“…The MEC apps 1726 can be configured to provide services 1730, which can include processing network communications traffic of different types associated with one or more wireless connections (e.g., connections to one or more RANs or core network functions) and/or some other services such as those discussed herein….”; Merwaday et al.; 0191)
(“…Edge nodes may also provide orchestration of multiple applications through isolated user-space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs)…”; Merwaday et al.; 0141)
(where
“Private cloud”/”application”/”connected…applications”/ ”apps…connections”/”applications…virtual machines” maps to “providing a connected virtual private cloud”, where “connected” maps to “connected”, “private cloud” maps to “private cloud”, “virtual machines” maps to “virtual”
…overlay network…
(“OpenNESS supports network overlay and dataplane using OVN/OVS. This is the recommended dataplane when incoming and outgoing flows are based on pure IP. This is implemented using kube-ovn. In this mode, the OVN/OVS can support IP based Five tuple based flow filtering and forwarding, and/or the same Interface used for Inter-App, management, Internet and Dataplane interface.”; Merwaday et al.; 0288)
(where
“network overly” maps to “…overlay network…”
…
transmitting data traffic between the first cloud native function and the
second cloud native function using the overlay network.
(“The OVN/OVS-DPDK is the secondary dataplane that is supported in native mode is OVN/OVS-DPDK. In some implementations, the OVN/OVS-DPDK is the primary dataplane supported. For non-S1u deployments this should be the dataplane of choice. OVN manages the IP addresses allocated to the applications. In this mode both north-south and east-west traffic is supported by OVS-DPDK. vEth pair is used as interface for container and vitrio for VMs.”; Merwaday et al.; 0260)
(“The MME 524 implements mobility management functions to track a current location of UEs 117 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc. The S1-MME interface communicatively couples the MME 524 with the CP entities 232 of the NANs 230, and the S1-MME interface communicatively couples the MME 524 with the edge-services 211b in the edge orchestrator 210 (see e.g., FIGS. 2 and 3)”; Merwaday et al.; 0049)
(“The SGW 526 terminates an S1 interface toward the Radio Access Network (RAN) and routes data packets between the RAN and the EPC 522. The SGW 526 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility.”; Merwaday et al.; 0050)
(“The SGSN 528 tracks a location of UEs 117 and performs security functions and access control. The SGSN 528 also performs inter-EPC node signaling for mobility between different RAT networks; PDN and SGW selection as specified by MME 524”; Merwaday et al.; 0051)
(“…edge node 140 handovers…”; Merwaday et al.; 0067)
(where
“dataplane” maps to “data traffic”,
“east-west traffic” maps to “between”
performing “handovers, gateway selection”/”inter-RAN node handovers”/”inter-3GPP mobility”/”edge noted 140 handovers”/”mobility between different networks”/”PDN and SGW slection”, is considered as requiring “transmitting data traffic between the first cloud native function and the
second cloud native function”
“network overlay and dataplane using OVN/OVS” maps to “using the overlay network”
Merwaday et al. teaches a multi-cloud system with a plurality of public cloud vendors for a cellular communication network where communication between the public clouds is performed via an overlay, where the public clouds include IOT gateways, where handover, selection and mobility are performed.
Merwaday et al. as described above does not explicitly teach:
deploying one or more virtual routers within the connected virtual private
cloud;
connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …; and
However, Zhao et al. further teaches a VRA/VPC/overlay/public clouds capability which includes:
deploying one or more virtual routers within the connected virtual private
cloud;
connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …; and
(“A first aspect relates to a computer-implemented method for performing VPC routing across multiple public cloud environments. The method creates a first virtual routing agent (VRA) for a first VPC of a first public cloud. The method sends a registration request to a VRA controller, wherein the registration request comprises a data structure that includes communication parameters of the first VRA. The method receives the communication parameters of other VRAs for other VPCs located in other public cloud environments from the VRA controller. The method uses the communication parameters of the other VRAs for overlay routing of data packets from the first VPC of the first public cloud to other VPCs of other public clouds via the other VRAs of the other VPCs. Because the VRAs in each cloud has the communication parameters of the other VRAs, an overlay network can be constructed that connects VPCs in different cloud data centers. In certain embodiments, the overlay network is managed by a network operator or a cloud blocker. In certain embodiments, the complexity of public cloud infrastructure may be transparent to the customer. Advantages of the first aspect include eliminating or reducing a customer's cost, complicated configuration, and dependence on a cloud provider's virtual gateway and infrastructure services (like Elastic Compute Cloud (EC2) of Amazon Web Services (AWS)) for VPC routing.”; Zhao et al.; 0004)
(where
“VRAs”/FIG. 2 maps to “deploying one or more virtual routers”, “VPC” maps to “virtual private cloud”,
“creates a first virtual routing agent (VRA) for a first VPC of a first public cloud” maps to “within the connected virtual private cloud”
FIG. 2 illustrates “connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …”
Zhao et al. teaches communication between public clouds using an overlay where the overlay uses VRAs for a VPC.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the VRA/VPC/overlay/public clouds capability of Zhao et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the VRA/VPC/overlay/public clouds capability as taught by the processing/communications of Zhao et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved functionality (Zhao et al.; 0056) are achieved.
As to claim 3:
Merwaday et al. discloses:
wherein the first public cloud and the second public cloud are operated by different cloud computing cloud service providers.
(“…By running multiple cloud connector instances from different cloud service providers on the same Edge Node, a multi-cloud experience can be easily implemented. OpenNESS supports this by providing the ability to deploy public cloud IOT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu OpenEdge on edge compute platform. The existing IOT gateways can be migrated to OpenNESS as is or enhanced to call EAA APIs using extensions like Lambda functions.”; Merwaday et al.; 0329)
As to claim 5:
Merwaday et al. discloses:
wherein the first cloud native function and the second cloud native function form part of a single network stack that is distributed between the first public cloud and the second public cloud.
(“FIG. 19 also shows an example OpenNESS Architecture 1902 according to various embodiments. The OpenNESS reference edge stack combines the cloud-native and NFV infrastructure optimizations for Virtual machine and Container cloud on COTS Architecture (e.g., CPU, Memory, IO, and Acceleration) from various open-source projects with essential amount of Edge compute specific APIs and network abstraction on to provide a unique and one-stop-shop development solution for edge compute.”; Merwaday et al.; 0239)
As to claim 8:
Merwaday et al. discloses:
A system for deploying network functions into target cloud computing environments in a cellular telecommunication network using an overlay network, the system comprising:
at least one memory that stores computer executable instructions; and
at least one processor that executes the computer executable instructions
to cause actions to be performed, the actions including:
deploying, by a mobile network operator, a first cloud native function in a
first public cloud;
(“FIG. 21 shows example edge cloud deployments including Multi-Access Support including an OpeNESS LTE Edge Cloud Deployment model support 2101 and an OpenNESS 5G SA Edge Cloud Deployment Model support 2102. OpenNESS supports multiple deployment options on an 5G Stand alone and LTE cellular network, as shown in FIG. 21. In these examples, OpenNESS may be deployed on 5G, LTE or IP (wireless or wireline) networks. The networking abstraction provided by the Edge Node Dataplane, network policy configuration and the Core Network Configuration Agent (CNCA) abstracts the protocol, access technology and access technology configuration differences such that edge applications see standard IP traffic as though they are deployed in the cloud.”; Merwaday et al.; 0276)
(“OpenNESS is intended for customers/users such as operators to conduct lab/field trials of edge compute in network edge and On-Premises Edge, ISVs, or OSVs to develop edge compute infrastructure solutions that take advantage of the COTS Architecture, and/or application developers who intend to develop applications for the edge, port the applications from public cloud to edge to take advantage of being closer to user.”; Merwaday et al.; 0235)
(“…By running multiple cloud connector instances from different cloud service providers on the same Edge Node, a multi-cloud experience can be easily implemented. OpenNESS supports this by providing the ability to deploy public cloud IOT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu OpenEdge on edge compute platform. The existing IOT gateways can be migrated to OpenNESS as is or enhanced to call EAA APIs using extensions like Lambda functions.”; Merwaday et al.; 0329)
(where
“LTE cellular” maps to “cellular telecommunication network”,
“operators” maps to “by mobile network operator”,
“public cloud”/”Amazon AWS” maps to “first public cloud”,
“IOT gateways” maps to “first cloud native function”
“deploy” maps to “deploying”
deploying, by the mobile network operator, a second cloud native function
in a second public cloud;
(where
“multi-cloud”/”public cloud”/Baidu OpenEdge” maps to “second public cloud”
“IOT gateways” maps to “second cloud native function”
providing a connected virtual private cloud;
(“…Access technologies” in the context of OpenNESS refers to various types of traffic that OpenNESS solution can be handled. They include 5G, LTE (GTP/IP), Wireline (IP), WiFi (IP), and/or the like. “Multi-cloud” and/or “multi-cloud environments” in the context of OpenNESS refers to support in OpenNESS to host multiple Public or Private cloud application on the same node or in the OpenNESS compute cluster. These cloud applications can come from (e.g., Amazon AWS Greengrass, Baidu cloud, etc.).”; Merwaday et al.; 0232)
(“…The edge aggregation nodes 1340 and other systems of the edge cloud 1110 are connected to a cloud or data center 1360, which uses a backhaul network 1350 to fulfill higher-latency requests from a cloud/data center for websites, applications, database servers, etc….”; Merwaday et al.; 0163)
(“…The MEC apps 1726 can be configured to provide services 1730, which can include processing network communications traffic of different types associated with one or more wireless connections (e.g., connections to one or more RANs or core network functions) and/or some other services such as those discussed herein….”; Merwaday et al.; 0191)
(“…Edge nodes may also provide orchestration of multiple applications through isolated user-space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs)…”; Merwaday et al.; 0141)
(where
“Private cloud”/”application”/”connected…applications”/ ”apps…connections”/”applications…virtual machines” maps to “providing a connected virtual private cloud”, where “connected” maps to “connected”, “private cloud” maps to “private cloud”, “virtual machines” maps to “virtual”
…overlay network…
(“OpenNESS supports network overlay and dataplane using OVN/OVS. This is the recommended dataplane when incoming and outgoing flows are based on pure IP. This is implemented using kube-ovn. In this mode, the OVN/OVS can support IP based Five tuple based flow filtering and forwarding, and/or the same Interface used for Inter-App, management, Internet and Dataplane interface.”; Merwaday et al.; 0288)
(where
“network overly” maps to “…overlay network…”
…
transmitting data traffic between the first cloud native function and the
second cloud native function using the overlay network.
(“The OVN/OVS-DPDK is the secondary dataplane that is supported in native mode is OVN/OVS-DPDK. In some implementations, the OVN/OVS-DPDK is the primary dataplane supported. For non-S1u deployments this should be the dataplane of choice. OVN manages the IP addresses allocated to the applications. In this mode both north-south and east-west traffic is supported by OVS-DPDK. vEth pair is used as interface for container and vitrio for VMs.”; Merwaday et al.; 0260)
(“The MME 524 implements mobility management functions to track a current location of UEs 117 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc. The S1-MME interface communicatively couples the MME 524 with the CP entities 232 of the NANs 230, and the S1-MME interface communicatively couples the MME 524 with the edge-services 211b in the edge orchestrator 210 (see e.g., FIGS. 2 and 3)”; Merwaday et al.; 0049)
(“The SGW 526 terminates an S1 interface toward the Radio Access Network (RAN) and routes data packets between the RAN and the EPC 522. The SGW 526 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility.”; Merwaday et al.; 0050)
(“The SGSN 528 tracks a location of UEs 117 and performs security functions and access control. The SGSN 528 also performs inter-EPC node signaling for mobility between different RAT networks; PDN and SGW selection as specified by MME 524”; Merwaday et al.; 0051)
(“…edge node 140 handovers…”; Merwaday et al.; 0067)
(where
“dataplane” maps to “data traffic”,
“east-west traffic” maps to “between”
performing “handovers, gateway selection”/”inter-RAN node handovers”/”inter-3GPP mobility”/”edge noted 140 handovers”/”mobility between different networks”/”PDN and SGW slection”, is considered as requiring “transmitting data traffic between the first cloud native function and the
second cloud native function”
“network overlay and dataplane using OVN/OVS” maps to “using the overlay network”
Merwaday et al. teaches a multi-cloud system with a plurality of public cloud vendors for a cellular communication network where communication between the public clouds is performed via an overlay, where the public clouds include IOT gateways, where handover, selection and mobility are performed.
Merwaday et al. as described above does not explicitly teach:
deploying one or more virtual routers within the connected virtual private
cloud;
connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …; and
However, Zhao et al. further teaches a VRA/VPC/overlay/public clouds capability which includes:
deploying one or more virtual routers within the connected virtual private
cloud;
connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …; and
(“A first aspect relates to a computer-implemented method for performing VPC routing across multiple public cloud environments. The method creates a first virtual routing agent (VRA) for a first VPC of a first public cloud. The method sends a registration request to a VRA controller, wherein the registration request comprises a data structure that includes communication parameters of the first VRA. The method receives the communication parameters of other VRAs for other VPCs located in other public cloud environments from the VRA controller. The method uses the communication parameters of the other VRAs for overlay routing of data packets from the first VPC of the first public cloud to other VPCs of other public clouds via the other VRAs of the other VPCs. Because the VRAs in each cloud has the communication parameters of the other VRAs, an overlay network can be constructed that connects VPCs in different cloud data centers. In certain embodiments, the overlay network is managed by a network operator or a cloud blocker. In certain embodiments, the complexity of public cloud infrastructure may be transparent to the customer. Advantages of the first aspect include eliminating or reducing a customer's cost, complicated configuration, and dependence on a cloud provider's virtual gateway and infrastructure services (like Elastic Compute Cloud (EC2) of Amazon Web Services (AWS)) for VPC routing.”; Zhao et al.; 0004)
(where
“VRAs”/FIG. 2 maps to “deploying one or more virtual routers”, “VPC” maps to “virtual private cloud”,
“creates a first virtual routing agent (VRA) for a first VPC of a first public cloud” maps to “within the connected virtual private cloud”
FIG. 2 illustrates “connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …”
Zhao et al. teaches communication between public clouds using an overlay where the overlay uses VRAs for a VPC.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the VRA/VPC/overlay/public clouds capability of Zhao et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the VRA/VPC/overlay/public clouds capability as taught by the processing/communications of Zhao et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved functionality (Zhao et al.; 0056) are achieved.
As to claim 10:
Merwaday et al. discloses:
wherein the first public cloud and the second public cloud are operated by different cloud computing cloud service providers.
(“…By running multiple cloud connector instances from different cloud service providers on the same Edge Node, a multi-cloud experience can be easily implemented. OpenNESS supports this by providing the ability to deploy public cloud IOT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu OpenEdge on edge compute platform. The existing IOT gateways can be migrated to OpenNESS as is or enhanced to call EAA APIs using extensions like Lambda functions.”; Merwaday et al.; 0329)
As to claim 12:
Merwaday et al. discloses:
wherein the first cloud native function and the second cloud native function form part of a single network stack that is distributed between the first public cloud and the second public cloud.
(“FIG. 19 also shows an example OpenNESS Architecture 1902 according to various embodiments. The OpenNESS reference edge stack combines the cloud-native and NFV infrastructure optimizations for Virtual machine and Container cloud on COTS Architecture (e.g., CPU, Memory, IO, and Acceleration) from various open-source projects with essential amount of Edge compute specific APIs and network abstraction on to provide a unique and one-stop-shop development solution for edge compute.”; Merwaday et al.; 0239)
As to claim 15:
Merwaday et al. discloses:
A non-transitory computer-readable storage medium having
computer-executable instructions stored thereon that, when executed by at least one processor, cause the at least one processor to cause actions to be performed, the actions including:
deploying, by a mobile network operator, a first cloud native function in a
first public cloud;
(“FIG. 21 shows example edge cloud deployments including Multi-Access Support including an OpeNESS LTE Edge Cloud Deployment model support 2101 and an OpenNESS 5G SA Edge Cloud Deployment Model support 2102. OpenNESS supports multiple deployment options on an 5G Stand alone and LTE cellular network, as shown in FIG. 21. In these examples, OpenNESS may be deployed on 5G, LTE or IP (wireless or wireline) networks. The networking abstraction provided by the Edge Node Dataplane, network policy configuration and the Core Network Configuration Agent (CNCA) abstracts the protocol, access technology and access technology configuration differences such that edge applications see standard IP traffic as though they are deployed in the cloud.”; Merwaday et al.; 0276)
(“OpenNESS is intended for customers/users such as operators to conduct lab/field trials of edge compute in network edge and On-Premises Edge, ISVs, or OSVs to develop edge compute infrastructure solutions that take advantage of the COTS Architecture, and/or application developers who intend to develop applications for the edge, port the applications from public cloud to edge to take advantage of being closer to user.”; Merwaday et al.; 0235)
(“…By running multiple cloud connector instances from different cloud service providers on the same Edge Node, a multi-cloud experience can be easily implemented. OpenNESS supports this by providing the ability to deploy public cloud IOT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu OpenEdge on edge compute platform. The existing IOT gateways can be migrated to OpenNESS as is or enhanced to call EAA APIs using extensions like Lambda functions.”; Merwaday et al.; 0329)
(where
“LTE cellular” maps to “cellular telecommunication network”,
“operators” maps to “by mobile network operator”,
“public cloud”/”Amazon AWS” maps to “first public cloud”,
“IOT gateways” maps to “first cloud native function”
“deploy” maps to “deploying”
deploying, by the mobile network operator, a second cloud native function
in a second public cloud;
(where
“multi-cloud”/”public cloud”/Baidu OpenEdge” maps to “second public cloud”
“IOT gateways” maps to “second cloud native function”
providing a connected virtual private cloud;
(“…Access technologies” in the context of OpenNESS refers to various types of traffic that OpenNESS solution can be handled. They include 5G, LTE (GTP/IP), Wireline (IP), WiFi (IP), and/or the like. “Multi-cloud” and/or “multi-cloud environments” in the context of OpenNESS refers to support in OpenNESS to host multiple Public or Private cloud application on the same node or in the OpenNESS compute cluster. These cloud applications can come from (e.g., Amazon AWS Greengrass, Baidu cloud, etc.).”; Merwaday et al.; 0232)
(“…The edge aggregation nodes 1340 and other systems of the edge cloud 1110 are connected to a cloud or data center 1360, which uses a backhaul network 1350 to fulfill higher-latency requests from a cloud/data center for websites, applications, database servers, etc….”; Merwaday et al.; 0163)
(“…The MEC apps 1726 can be configured to provide services 1730, which can include processing network communications traffic of different types associated with one or more wireless connections (e.g., connections to one or more RANs or core network functions) and/or some other services such as those discussed herein….”; Merwaday et al.; 0191)
(“…Edge nodes may also provide orchestration of multiple applications through isolated user-space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs)…”; Merwaday et al.; 0141)
(where
“Private cloud”/”application”/”connected…applications”/ ”apps…connections”/”applications…virtual machines” maps to “providing a connected virtual private cloud”, where “connected” maps to “connected”, “private cloud” maps to “private cloud”, “virtual machines” maps to “virtual”
…overlay network…
(“OpenNESS supports network overlay and dataplane using OVN/OVS. This is the recommended dataplane when incoming and outgoing flows are based on pure IP. This is implemented using kube-ovn. In this mode, the OVN/OVS can support IP based Five tuple based flow filtering and forwarding, and/or the same Interface used for Inter-App, management, Internet and Dataplane interface.”; Merwaday et al.; 0288)
(where
“network overly” maps to “…overlay network…”
…
transmitting data traffic between the first cloud native function and the
second cloud native function using the overlay network.
(“The OVN/OVS-DPDK is the secondary dataplane that is supported in native mode is OVN/OVS-DPDK. In some implementations, the OVN/OVS-DPDK is the primary dataplane supported. For non-S1u deployments this should be the dataplane of choice. OVN manages the IP addresses allocated to the applications. In this mode both north-south and east-west traffic is supported by OVS-DPDK. vEth pair is used as interface for container and vitrio for VMs.”; Merwaday et al.; 0260)
(“The MME 524 implements mobility management functions to track a current location of UEs 117 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc. The S1-MME interface communicatively couples the MME 524 with the CP entities 232 of the NANs 230, and the S1-MME interface communicatively couples the MME 524 with the edge-services 211b in the edge orchestrator 210 (see e.g., FIGS. 2 and 3)”; Merwaday et al.; 0049)
(“The SGW 526 terminates an S1 interface toward the Radio Access Network (RAN) and routes data packets between the RAN and the EPC 522. The SGW 526 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility.”; Merwaday et al.; 0050)
(“The SGSN 528 tracks a location of UEs 117 and performs security functions and access control. The SGSN 528 also performs inter-EPC node signaling for mobility between different RAT networks; PDN and SGW selection as specified by MME 524”; Merwaday et al.; 0051)
(“…edge node 140 handovers…”; Merwaday et al.; 0067)
(where
“dataplane” maps to “data traffic”,
“east-west traffic” maps to “between”
performing “handovers, gateway selection”/”inter-RAN node handovers”/”inter-3GPP mobility”/”edge noted 140 handovers”/”mobility between different networks”/”PDN and SGW slection”, is considered as requiring “transmitting data traffic between the first cloud native function and the
second cloud native function”
“network overlay and dataplane using OVN/OVS” maps to “using the overlay network”
Merwaday et al. teaches a multi-cloud system with a plurality of public cloud vendors for a cellular communication network where communication between the public clouds is performed via an overlay, where the public clouds include IOT gateways, where handover, selection and mobility are performed.
Merwaday et al. as described above does not explicitly teach:
deploying one or more virtual routers within the connected virtual private
cloud;
connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …; and
However, Zhao et al. further teaches a VRA/VPC/overlay/public clouds capability which includes:
deploying one or more virtual routers within the connected virtual private
cloud;
connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …; and
(“A first aspect relates to a computer-implemented method for performing VPC routing across multiple public cloud environments. The method creates a first virtual routing agent (VRA) for a first VPC of a first public cloud. The method sends a registration request to a VRA controller, wherein the registration request comprises a data structure that includes communication parameters of the first VRA. The method receives the communication parameters of other VRAs for other VPCs located in other public cloud environments from the VRA controller. The method uses the communication parameters of the other VRAs for overlay routing of data packets from the first VPC of the first public cloud to other VPCs of other public clouds via the other VRAs of the other VPCs. Because the VRAs in each cloud has the communication parameters of the other VRAs, an overlay network can be constructed that connects VPCs in different cloud data centers. In certain embodiments, the overlay network is managed by a network operator or a cloud blocker. In certain embodiments, the complexity of public cloud infrastructure may be transparent to the customer. Advantages of the first aspect include eliminating or reducing a customer's cost, complicated configuration, and dependence on a cloud provider's virtual gateway and infrastructure services (like Elastic Compute Cloud (EC2) of Amazon Web Services (AWS)) for VPC routing.”; Zhao et al.; 0004)
(where
“VRAs”/FIG. 2 maps to “deploying one or more virtual routers”, “VPC” maps to “virtual private cloud”,
“creates a first virtual routing agent (VRA) for a first VPC of a first public cloud” maps to “within the connected virtual private cloud”
FIG. 2 illustrates “connecting the first public cloud and the second public cloud to the connected virtual private cloud using the one or more virtual routers in the connected virtual private cloud to form the …”
Zhao et al. teaches communication between public clouds using an overlay where the overlay uses VRAs for a VPC.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the VRA/VPC/overlay/public clouds capability of Zhao et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the VRA/VPC/overlay/public clouds capability as taught by the processing/communications of Zhao et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved functionality (Zhao et al.; 0056) are achieved.
As to claim 17:
Merwaday et al. discloses:
wherein the first public cloud and the second public cloud are operated by different cloud computing cloud service providers.
(“…By running multiple cloud connector instances from different cloud service providers on the same Edge Node, a multi-cloud experience can be easily implemented. OpenNESS supports this by providing the ability to deploy public cloud IOT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu OpenEdge on edge compute platform. The existing IOT gateways can be migrated to OpenNESS as is or enhanced to call EAA APIs using extensions like Lambda functions.”; Merwaday et al.; 0329)
As to claim 19:
Merwaday et al. discloses:
wherein the first cloud native function and the second cloud native function form part of a single network stack that is distributed between the first public cloud and the second public cloud.
(“FIG. 19 also shows an example OpenNESS Architecture 1902 according to various embodiments. The OpenNESS reference edge stack combines the cloud-native and NFV infrastructure optimizations for Virtual machine and Container cloud on COTS Architecture (e.g., CPU, Memory, IO, and Acceleration) from various open-source projects with essential amount of Edge compute specific APIs and network abstraction on to provide a unique and one-stop-shop development solution for edge compute.”; Merwaday et al.; 0239)
Claim(s) 2, 9 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday et al. US 20220038554 in view of Zhao et al. US 20200382345 and in further view of Dunbar et al. US 20200412608 (U.S. Patent Application Publications citation #3, listed on IDS dated 2023-12-29).
As to claim 2:
Merwaday et al. as described above does not explicitly teach:
wherein the overlay network is connected to physical infrastructure of the first public cloud and the second public cloud via a colocation data center.
However, Dubar et al. further teaches a VPC/one public cloud data center/physical/overlay capability which includes:
wherein the overlay network is connected to physical infrastructure of the first public cloud and the second public cloud via a colocation data center.
(“According to a first aspect of the present disclosure, a method of operating a network device to stitch an existing virtual private network (VPN) with one or more virtual private clouds (VPCs) in one or more public cloud data centers (DCs) includes communicating over the existing VPN between a plurality of first network devices; configuring a virtual routing application in a first VPC in a first public DC; and configuring one or more virtual routing application in the existing VPN. The method also includes establishing a plurality of paths between the first network devices in the existing VPN and one or more second networking devices in the first VPC, the plurality of paths including one or more physical connections and one or more virtual connections over non-secure networks. Additionally, a virtual routing application controller is configured in the existing VPN for controlling the virtual routing application in the first VPC and the one or more virtual routing applications in the existing VPN, whereby the virtual routing application controller routes the plurality of first network devices in the existing VPN to access applications instantiated in the first VPC through the paths between the first network devices and the first VPC.”; Dunbar et al.; 0007)
(“The following presents techniques to integrate, or “stitch”, existing virtual private networks (VPNs), such as MPLS (multiprotocol label switching) VPNs, with Virtual Private Clouds (VPCs) in third party Data Centers (a.k.a. Cloud DCs). Embodiments of a stitching architecture are realized by configuring a virtual routing application (VRA) in a VPC that belongs to a public cloud, such as in an Amazon Web Services (AWS) data center. For the VPCs in a public cloud that do not have a VRA, traffic from those VPCs can be default routed to the VPCs with a VRA. In some embodiments, the VRA can be hosted in a virtual machine (VM), a container. In other embodiments, the VRA can also be a software component residing in a virtual router (vRouter) or virtual switch (vSwitch). Each virtual overlay network can have a logically centralized VRA controller, which communicates with all VRAs for overlay network management and control.”; Dunbar et al.; 0034)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the VPC/one public cloud data center/physical/overlay capability of Dunbar et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the VPC/one public cloud data center/physical/overlay capability as taught by the processing/communications of Dunbar et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved VRA (Dunbar et al.; Abstract) are achieved.
As to claim 9:
Merwaday et al. as described above does not explicitly teach:
wherein the overlay network is connected to physical infrastructure of the first public cloud and the second public cloud via a colocation data center.
However, Dubar et al. further teaches a VPC/one public cloud data center/physical/overlay capability which includes:
wherein the overlay network is connected to physical infrastructure of the first public cloud and the second public cloud via a colocation data center.
(“According to a first aspect of the present disclosure, a method of operating a network device to stitch an existing virtual private network (VPN) with one or more virtual private clouds (VPCs) in one or more public cloud data centers (DCs) includes communicating over the existing VPN between a plurality of first network devices; configuring a virtual routing application in a first VPC in a first public DC; and configuring one or more virtual routing application in the existing VPN. The method also includes establishing a plurality of paths between the first network devices in the existing VPN and one or more second networking devices in the first VPC, the plurality of paths including one or more physical connections and one or more virtual connections over non-secure networks. Additionally, a virtual routing application controller is configured in the existing VPN for controlling the virtual routing application in the first VPC and the one or more virtual routing applications in the existing VPN, whereby the virtual routing application controller routes the plurality of first network devices in the existing VPN to access applications instantiated in the first VPC through the paths between the first network devices and the first VPC.”; Dunbar et al.; 0007)
(“The following presents techniques to integrate, or “stitch”, existing virtual private networks (VPNs), such as MPLS (multiprotocol label switching) VPNs, with Virtual Private Clouds (VPCs) in third party Data Centers (a.k.a. Cloud DCs). Embodiments of a stitching architecture are realized by configuring a virtual routing application (VRA) in a VPC that belongs to a public cloud, such as in an Amazon Web Services (AWS) data center. For the VPCs in a public cloud that do not have a VRA, traffic from those VPCs can be default routed to the VPCs with a VRA. In some embodiments, the VRA can be hosted in a virtual machine (VM), a container. In other embodiments, the VRA can also be a software component residing in a virtual router (vRouter) or virtual switch (vSwitch). Each virtual overlay network can have a logically centralized VRA controller, which communicates with all VRAs for overlay network management and control.”; Dunbar et al.; 0034)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the VPC/one public cloud data center/physical/overlay capability of Dunbar et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the VPC/one public cloud data center/physical/overlay capability as taught by the processing/communications of Dunbar et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved VRA (Dunbar et al.; Abstract) are achieved.
As to claim 16:
Merwaday et al. as described above does not explicitly teach:
wherein the overlay network is connected to physical infrastructure of the first public cloud and the second public cloud via a colocation data center.
However, Dubar et al. further teaches a VPC/one public cloud data center/physical/overlay capability which includes:
wherein the overlay network is connected to physical infrastructure of the first public cloud and the second public cloud via a colocation data center.
(“According to a first aspect of the present disclosure, a method of operating a network device to stitch an existing virtual private network (VPN) with one or more virtual private clouds (VPCs) in one or more public cloud data centers (DCs) includes communicating over the existing VPN between a plurality of first network devices; configuring a virtual routing application in a first VPC in a first public DC; and configuring one or more virtual routing application in the existing VPN. The method also includes establishing a plurality of paths between the first network devices in the existing VPN and one or more second networking devices in the first VPC, the plurality of paths including one or more physical connections and one or more virtual connections over non-secure networks. Additionally, a virtual routing application controller is configured in the existing VPN for controlling the virtual routing application in the first VPC and the one or more virtual routing applications in the existing VPN, whereby the virtual routing application controller routes the plurality of first network devices in the existing VPN to access applications instantiated in the first VPC through the paths between the first network devices and the first VPC.”; Dunbar et al.; 0007)
(“The following presents techniques to integrate, or “stitch”, existing virtual private networks (VPNs), such as MPLS (multiprotocol label switching) VPNs, with Virtual Private Clouds (VPCs) in third party Data Centers (a.k.a. Cloud DCs). Embodiments of a stitching architecture are realized by configuring a virtual routing application (VRA) in a VPC that belongs to a public cloud, such as in an Amazon Web Services (AWS) data center. For the VPCs in a public cloud that do not have a VRA, traffic from those VPCs can be default routed to the VPCs with a VRA. In some embodiments, the VRA can be hosted in a virtual machine (VM), a container. In other embodiments, the VRA can also be a software component residing in a virtual router (vRouter) or virtual switch (vSwitch). Each virtual overlay network can have a logically centralized VRA controller, which communicates with all VRAs for overlay network management and control.”; Dunbar et al.; 0034)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the VPC/one public cloud data center/physical/overlay capability of Dunbar et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the VPC/one public cloud data center/physical/overlay capability as taught by the processing/communications of Dunbar et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved VRA (Dunbar et al.; Abstract) are achieved.
Claim(s) 4, 11 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday et al. US 20220038554 in view of Zhao et al. US 20200382345 and in further view of Potyrag et al. US 11733901.
As to claim 4:
Merwaday et al. discloses:
on-prem environment
(“The edge cloud 1110 may span multiple network layers, such as an edge devices layer a1210 having gateways, on-premise servers,”; Merwaday et al.; 0153)
transmitting data traffic between
(“The OVN/OVS-DPDK is the secondary dataplane that is supported in native mode is OVN/OVS-DPDK. In some implementations, the OVN/OVS-DPDK is the primary dataplane supported. For non-S1u deployments this should be the dataplane of choice. OVN manages the IP addresses allocated to the applications. In this mode both north-south and east-west traffic is supported by OVS-DPDK. vEth pair is used as interface for container and vitrio for VMs.”; Merwaday et al.; 0260)
Merwaday et al. as described above does not explicitly teach:
deploying a third cloud native function in an on-prem environment;
connecting the on-prem environment to the first public cloud and the second public cloud via the overlay network; and
… the first cloud native function, the second cloud native function, and the third cloud native function using the overlay network.
However, Potyrag et al. further teaches an on-premises cloud/model/VPC capability which includes:
deploying a third cloud native function in an on-prem environment;
connecting the on-prem environment to the first public cloud and the second public cloud via the overlay network; and
… the first cloud native function, the second cloud native function, and the third cloud native function using the overlay network.
(“Readers will appreciate that the embodiments described herein may be useful for a variety of use cases. For example, embodiments may be useful for AI use cases in which on-premises hardware is used for scaled ML inference. In such an example, models may be trained and developed in the public cloud, then the model may be deployed the model on one or more on-premises cloud infrastructures to deliver higher performance that using the public cloud for deployment. In fact, multiple edge locations may have custom, regional models deployed, but developers may still run centralized training and retraining of models. Likewise, by deploying the models an edge, data may be ingested from edge locations (e.g., a company's location) thereby avoiding unreliable and expensive connections that would be required for moving all edge data to the public cloud.”; Potyrag et al.; col. 59, lines 8-23)
(“The storage systems described above may also be part of a multi-cloud environment in which multiple cloud computing and storage services are deployed in a single heterogeneous architecture. In order to facilitate the operation of such a multi-cloud environment, DevOps tools may be deployed to enable orchestration across clouds. Likewise, continuous development and continuous integration tools may be deployed to standardize processes around continuous integration and delivery, new feature rollout and provisioning cloud workloads. By standardizing these processes, a multi-cloud strategy may be implemented that enables the utilization of the best provider for each workload.”; Potyrag et al.; col. 49, lines 15-26)
(“For further explanation, FIG. 4D sets forth a diagram of a multi-site deployment in which on-premises cloud infrastructures 402a, 402b are paired with storage systems 412a, 412b in accordance with some embodiments of the present disclosure. In the example depicted in FIG. 4D, each of the on-premises cloud infrastructures 402a, 402b support a VPC 414a, 414b that includes resources provisioned for one or more users or applications. Data communications between resources in the VPCs 414a, 414b may be carried out using a WAN 422 or through transit gateways (‘TGW’) 424 that includes a network transit hub that can be used to interconnect virtual private clouds (VPCs) and on-premises networks.”; Potyrag et al.; col. 55, lines 28-40)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the on-premises cloud/modelVPC capability of Potyrag et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the on-premises cloud/model/VPC capability as taught by the processing/communications of Potyrag et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved performance (Potyrag et al.; col. 45, lines 20-22) are achieved.
As to claim 11:
Merwaday et al. discloses:
on-prem environment
(“The edge cloud 1110 may span multiple network layers, such as an edge devices layer a1210 having gateways, on-premise servers,”; Merwaday et al.; 0153)
transmitting data traffic between
(“The OVN/OVS-DPDK is the secondary dataplane that is supported in native mode is OVN/OVS-DPDK. In some implementations, the OVN/OVS-DPDK is the primary dataplane supported. For non-S1u deployments this should be the dataplane of choice. OVN manages the IP addresses allocated to the applications. In this mode both north-south and east-west traffic is supported by OVS-DPDK. vEth pair is used as interface for container and vitrio for VMs.”; Merwaday et al.; 0260)
Merwaday et al. as described above does not explicitly teach:
deploying a third cloud native function in an on-prem environment;
connecting the on-prem environment to the first public cloud and the second public cloud via the overlay network; and
… the first cloud native function, the second cloud native function, and the third cloud native function using the overlay network.
However, Potyrag et al. further teaches an on-premises cloud/model/VPC capability which includes:
deploying a third cloud native function in an on-prem environment;
connecting the on-prem environment to the first public cloud and the second public cloud via the overlay network; and
… the first cloud native function, the second cloud native function, and the third cloud native function using the overlay network.
(“Readers will appreciate that the embodiments described herein may be useful for a variety of use cases. For example, embodiments may be useful for AI use cases in which on-premises hardware is used for scaled ML inference. In such an example, models may be trained and developed in the public cloud, then the model may be deployed the model on one or more on-premises cloud infrastructures to deliver higher performance that using the public cloud for deployment. In fact, multiple edge locations may have custom, regional models deployed, but developers may still run centralized training and retraining of models. Likewise, by deploying the models an edge, data may be ingested from edge locations (e.g., a company's location) thereby avoiding unreliable and expensive connections that would be required for moving all edge data to the public cloud.”; Potyrag et al.; col. 59, lines 8-23)
(“The storage systems described above may also be part of a multi-cloud environment in which multiple cloud computing and storage services are deployed in a single heterogeneous architecture. In order to facilitate the operation of such a multi-cloud environment, DevOps tools may be deployed to enable orchestration across clouds. Likewise, continuous development and continuous integration tools may be deployed to standardize processes around continuous integration and delivery, new feature rollout and provisioning cloud workloads. By standardizing these processes, a multi-cloud strategy may be implemented that enables the utilization of the best provider for each workload.”; Potyrag et al.; col. 49, lines 15-26)
(“For further explanation, FIG. 4D sets forth a diagram of a multi-site deployment in which on-premises cloud infrastructures 402a, 402b are paired with storage systems 412a, 412b in accordance with some embodiments of the present disclosure. In the example depicted in FIG. 4D, each of the on-premises cloud infrastructures 402a, 402b support a VPC 414a, 414b that includes resources provisioned for one or more users or applications. Data communications between resources in the VPCs 414a, 414b may be carried out using a WAN 422 or through transit gateways (‘TGW’) 424 that includes a network transit hub that can be used to interconnect virtual private clouds (VPCs) and on-premises networks.”; Potyrag et al.; col. 55, lines 28-40)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the on-premises cloud/modelVPC capability of Potyrag et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the on-premises cloud/model/VPC capability as taught by the processing/communications of Potyrag et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved performance (Potyrag et al.; col. 45, lines 20-22) are achieved.
As to claim 18:
Merwaday et al. discloses:
on-prem environment
(“The edge cloud 1110 may span multiple network layers, such as an edge devices layer a1210 having gateways, on-premise servers,”; Merwaday et al.; 0153)
transmitting data traffic between
(“The OVN/OVS-DPDK is the secondary dataplane that is supported in native mode is OVN/OVS-DPDK. In some implementations, the OVN/OVS-DPDK is the primary dataplane supported. For non-S1u deployments this should be the dataplane of choice. OVN manages the IP addresses allocated to the applications. In this mode both north-south and east-west traffic is supported by OVS-DPDK. vEth pair is used as interface for container and vitrio for VMs.”; Merwaday et al.; 0260)
Merwaday et al. as described above does not explicitly teach:
deploying a third cloud native function in an on-prem environment;
connecting the on-prem environment to the first public cloud and the second public cloud via the overlay network; and
… the first cloud native function, the second cloud native function, and the third cloud native function using the overlay network.
However, Potyrag et al. further teaches an on-premises cloud/model/VPC capability which includes:
deploying a third cloud native function in an on-prem environment;
connecting the on-prem environment to the first public cloud and the second public cloud via the overlay network; and
… the first cloud native function, the second cloud native function, and the third cloud native function using the overlay network.
(“Readers will appreciate that the embodiments described herein may be useful for a variety of use cases. For example, embodiments may be useful for AI use cases in which on-premises hardware is used for scaled ML inference. In such an example, models may be trained and developed in the public cloud, then the model may be deployed the model on one or more on-premises cloud infrastructures to deliver higher performance that using the public cloud for deployment. In fact, multiple edge locations may have custom, regional models deployed, but developers may still run centralized training and retraining of models. Likewise, by deploying the models an edge, data may be ingested from edge locations (e.g., a company's location) thereby avoiding unreliable and expensive connections that would be required for moving all edge data to the public cloud.”; Potyrag et al.; col. 59, lines 8-23)
(“The storage systems described above may also be part of a multi-cloud environment in which multiple cloud computing and storage services are deployed in a single heterogeneous architecture. In order to facilitate the operation of such a multi-cloud environment, DevOps tools may be deployed to enable orchestration across clouds. Likewise, continuous development and continuous integration tools may be deployed to standardize processes around continuous integration and delivery, new feature rollout and provisioning cloud workloads. By standardizing these processes, a multi-cloud strategy may be implemented that enables the utilization of the best provider for each workload.”; Potyrag et al.; col. 49, lines 15-26)
(“For further explanation, FIG. 4D sets forth a diagram of a multi-site deployment in which on-premises cloud infrastructures 402a, 402b are paired with storage systems 412a, 412b in accordance with some embodiments of the present disclosure. In the example depicted in FIG. 4D, each of the on-premises cloud infrastructures 402a, 402b support a VPC 414a, 414b that includes resources provisioned for one or more users or applications. Data communications between resources in the VPCs 414a, 414b may be carried out using a WAN 422 or through transit gateways (‘TGW’) 424 that includes a network transit hub that can be used to interconnect virtual private clouds (VPCs) and on-premises networks.”; Potyrag et al.; col. 55, lines 28-40)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the on-premises cloud/modelVPC capability of Potyrag et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the on-premises cloud/model/VPC capability as taught by the processing/communications of Potyrag et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved performance (Potyrag et al.; col. 45, lines 20-22) are achieved.
Claim(s) 6, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday et al. US 20220038554 in view of Zhao et al. US 20200382345 and in further view of Nadella et al. US 20170181210.
As to claim 6:
Merwaday et al. as described above does not explicitly teach:
further comprising causing the first public cloud and the second public cloud to appear to be on a single network due to connections with the overlay network.
However, Nadella et al. further teaches an appear as single network/overly capability which includes:
further comprising causing the first public cloud and the second public cloud to appear to be on a single network due to connections with the overlay network.
(“FIG. 6 is a diagram that depicts a high level view of a cloud WAN overlay network 600 created, across one or more cloud computing networks 105, as a result of the provisioning of FIGS. 4 and 5. As shown, cloud WAN overlay network 600 connects customer cloud resources in each of cloud computing networks 105-1 through 105-n, data center(s) 115, and branch site(s) 120 via encrypted tunnels such that data can be exchanged between cloud computing networks, between data center(s) 115 and one or more of the cloud computing networks 105, or between branch site(s) 120 and one or more of the cloud computing networks 105, as if the data crosses a single network. Cloud WAN overlay network 600, thus, enables customer 140 to execute apps, and store and process data between multiple cloud computing networks, or between a data center(s) 115 and/or a branch site(s) 120, across multiple intervening networks (e.g., public network 130 and private IP network 135) that effectively “appear” as a single wide area network due to establishment of cloud WAN overlay network 600.”; Nadella et al.; 0034)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the appear as single network/overly capability of Nadella et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the appear as single network/overly capability as taught by the processing/communications of Nadella et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved overlay network (Nadella et al.; Abstract) are achieved.
As to claim 13:
Merwaday et al. as described above does not explicitly teach:
further comprising causing the first public cloud and the second public cloud to appear to be on a single network due to connections with the overlay network.
However, Nadella et al. further teaches an appear as single network/overly capability which includes:
further comprising causing the first public cloud and the second public cloud to appear to be on a single network due to connections with the overlay network.
(“FIG. 6 is a diagram that depicts a high level view of a cloud WAN overlay network 600 created, across one or more cloud computing networks 105, as a result of the provisioning of FIGS. 4 and 5. As shown, cloud WAN overlay network 600 connects customer cloud resources in each of cloud computing networks 105-1 through 105-n, data center(s) 115, and branch site(s) 120 via encrypted tunnels such that data can be exchanged between cloud computing networks, between data center(s) 115 and one or more of the cloud computing networks 105, or between branch site(s) 120 and one or more of the cloud computing networks 105, as if the data crosses a single network. Cloud WAN overlay network 600, thus, enables customer 140 to execute apps, and store and process data between multiple cloud computing networks, or between a data center(s) 115 and/or a branch site(s) 120, across multiple intervening networks (e.g., public network 130 and private IP network 135) that effectively “appear” as a single wide area network due to establishment of cloud WAN overlay network 600.”; Nadella et al.; 0034)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the appear as single network/overly capability of Nadella et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the appear as single network/overly capability as taught by the processing/communications of Nadella et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved overlay network (Nadella et al.; Abstract) are achieved.
As to claim 20:
Merwaday et al. as described above does not explicitly teach:
further comprising causing the first public cloud and the second public cloud to appear to be on a single network due to connections with the overlay network.
However, Nadella et al. further teaches an appear as single network/overly capability which includes:
further comprising causing the first public cloud and the second public cloud to appear to be on a single network due to connections with the overlay network.
(“FIG. 6 is a diagram that depicts a high level view of a cloud WAN overlay network 600 created, across one or more cloud computing networks 105, as a result of the provisioning of FIGS. 4 and 5. As shown, cloud WAN overlay network 600 connects customer cloud resources in each of cloud computing networks 105-1 through 105-n, data center(s) 115, and branch site(s) 120 via encrypted tunnels such that data can be exchanged between cloud computing networks, between data center(s) 115 and one or more of the cloud computing networks 105, or between branch site(s) 120 and one or more of the cloud computing networks 105, as if the data crosses a single network. Cloud WAN overlay network 600, thus, enables customer 140 to execute apps, and store and process data between multiple cloud computing networks, or between a data center(s) 115 and/or a branch site(s) 120, across multiple intervening networks (e.g., public network 130 and private IP network 135) that effectively “appear” as a single wide area network due to establishment of cloud WAN overlay network 600.”; Nadella et al.; 0034)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the appear as single network/overly capability of Nadella et al. into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the appear as single network/overly capability as taught by the processing/communications of Nadella et al., the benefits of improved QoE (Merwaday et al.; 0223) with improved overlay network (Nadella et al.; Abstract) are achieved.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday et al. US 20220038554 in view of Zhao et al. US 20200382345 and in further view of Luft US 20160197834.
As to claim 7:
Merwaday et al. as described above does not explicitly teach:
wherein the first cloud native function is deployed to the first public cloud based on performance characteristics of the first public cloud relative to the first cloud native function.
However, Luft further teaches an arbitrage/demand capability which includes:
wherein the first cloud native function is deployed to the first public cloud based on performance characteristics of the first public cloud relative to the first cloud native function.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the arbitrage/demand capability of Luft into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the arbitrage/demand capability as taught by the processing/communications of Luft, the benefits of improved QoE (Merwaday et al.; 0223) with improved scheduling (Luft; Abstract) are achieved.
As to claim 14:
Merwaday et al. as described above does not explicitly teach:
wherein the first cloud native function is deployed to the first public cloud based on performance characteristics of the first public cloud relative to the first cloud native function.
However, Luft further teaches an arbitrage/demand capability which includes:
wherein the first cloud native function is deployed to the first public cloud based on performance characteristics of the first public cloud relative to the first cloud native function.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the arbitrage/demand capability of Luft into Merwaday et al. By modifying the processing/communications of Merwaday et al. to include the arbitrage/demand capability as taught by the processing/communications of Luft, the benefits of improved QoE (Merwaday et al.; 0223) with improved scheduling (Luft; Abstract) are achieved.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 10965737 – teaches a cloud provider network associated with telecommunications (see FIG. 8).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL K PHILLIPS whose telephone number is (571)272-1037. The examiner can normally be reached M-F 8am-10am, 1pm-5pm.
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, Ricky Ngo can be reached on 571-272-3139. 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.
MICHAEL K. PHILLIPS
Examiner
Art Unit 2464
/MICHAEL K PHILLIPS/Examiner, Art Unit 2464