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 .
Information Disclosure Statement
The IDS filed 4/25/2025, 9/10/2025, 1/5/2026 and 6/29/2026 have been considered.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “infrastructure modules,” “service modules,” “control and management modules,” in claims 1-20.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitations “infrastructure modules,” “service modules,” “control and management modules,” in claims 1-20 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim 15 recites in part: “…wherein the first group of modules are organized and interconnected in a same manner as the second group of modules.” It is unclear as to what is considered “same manner.”
Claim 17 recites in part: “…one or more BASs having a same structure.” It is unclear as to what is intended by “same structure.”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 1 recites a system comprising one or more infrastructure modules, control and management modules and one or more gateways. Claim 2 specifically recites wherein some or all of the infrastructure modules, the service modules, the control and management modules, and the one or more gateways are implemented using virtualized resources. Therefore, the system as claimed, is not necessarily. Instead, one can reasonably interpret it as software, per se, which is not statutory.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-12, and 15-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thyagarajan (US 20190079804, as cited in the IDS filed 4/25/2025), in view of Hanahan et al. (US 11218424, hereinafter referred to as “Hanahan,” as cited in the IDS filed 1/5/2026).
Regarding claim 1, Thyagarajan teaches a system comprising:
one or more infrastructure modules each providing a respective infrastructure resource as service ([0036] System Environment. With reference to FIG. 1, there is shown an exemplary cloud-based network topology. On the bottom layer of the topology, there is the hardware 15 that supports the SDN network functionality. There is shown Infrastructure as a Service (IasS) 12, a form of cloud computing that provides virtualized computing resources over the Internet. In an exemplary IaaS model, a telecommunications service provider may host and/or operate hardware, software, servers, storage and other infrastructure components on behalf of its vendors, including hosting and managing vendors' applications and handle tasks including system maintenance, backup and resiliency planning. IaaS platforms offer highly scalable resources that can be adjusted on-demand. This makes IaaS well-suited for workloads that are temporary, experimental or that may change unexpectedly or change over time.);
one or more service modules each providing a respective functionality as service and utilizing at least one of the infrastructure resources as service ([0041] NFPaaS 11 may include components that provide Data Base as a Service (DBaaS), Load Balancing as a Service (LBaaS), DNS as a Service (DNSaaS), Network Time Protocol as a Service (NTPaaS), port monitoring as a service such as TAPaaS, network analytics and tools, and other types of functionality.);
one or more control and management modules each providing a respective management or control resource as service, at least one of the control and management modules providing said respective management or control resource as service to at least one of the infrastructure modules or the service modules ([0161] As described herein, a telecommunications system wherein management and control utilizing a software designed network (SDN) and an internet protocol are based, at least in part, on user equipment, may provide a wireless management and control framework that enables common wireless management and control, such as mobility management, radio resource management, QoS, load balancing, etc., across many wireless technologies, e.g. LTE, Wi-Fi, and future 5G access technologies; decoupling the mobility control from data planes to let them evolve and scale independently; reducing network state maintained in the network based on user equipment types to reduce network cost and allow massive scale; shortening cycle time and improving network upgradability; flexibility in creating end-to-end services based on types of user equipment and applications, thus improve customer experience; or improving user equipment power efficiency and battery life—especially for simple Machine-to-Machine (M2M) and Internet of Things (IoT) sensors/devices—through enhanced wireless management.).
However, Thyagaraja does not explicitly teach one or more gateways providing a secured connection with, and facilitating interaction between, some or all of the infrastructure modules, the service modules and the control and management modules.
Hanahan teaches one or more gateways providing a secured connection with, and facilitating interaction between, some or all of the infrastructure modules, the service modules and the control and management modules (col. 29, line 50 to col. 30, line 2: System 710 may each include a virtual router and one or more virtual ports over a physical cross-connect 709 by which a virtual connection 707 between an NSP network offering connectivity to an enterprise customer and a virtual router in the data center is established. The NSP network may offer WAN connectivity. Via the cloud exchange, the virtual router may route traffic to/from one or more virtualized performance hub servers, the Internet, and one or more other cloud service provider networks 713 offering Infrastructure, Software, Platform, Data Storage, or other offering as-a-Service. At least in some examples, no colocation is required for a customer to obtain NFV services (e.g., firewall, load balancer, packet inspection) using a virtual performance hub. A system may include a virtual router, virtual ports for connecting a virtual circuit (or “interconnection”) 707 over an NSP/ECX cross connect between an NSP and the virtual router. The system may offer connectivity for a performance hub/NFV services, a WAN connection, and Internet Service connection (ISP/Internet Connect) 712, and third-party cloud services (IaaS/SaaS).).
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to incorporate the secure gateway architecture of Hanahan into the teaching of in order to improve security, scalability, interoperability, and policy enforcement among distributed cloud services. Such modification merely applies a known gateway architecture to a known distributed cloud framework for its predictable benefits.
Regarding claim 2, Thyagarajan teaches the system of claim 1, wherein some or all of the infrastructure modules, the service modules, the control and management modules, and the one or more gateways are implemented using virtualized resources provided by a plurality of clouds (abstract - A system for providing network function as a service includes a combination of virtual network resources hosted on physical network resources, wherein the virtual network resources are communicatively chained to provide a dynamically configurable set of processing resources and a configurable controller in communication with the combination of virtual network resources, wherein the controller includes a scheduler and load balancer. The controller is configured to receive a request to provide network function as a service functionality, retrieve policies associated with the request, schedule the virtual network resources to be assigned in response to the request, instantiate the virtual network resources and balance the virtual network resources across one or more physical resources.).
Regarding claim 3, Thyagarajan does not explicitly teach the system of claim 2, wherein the one or more gateways include a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting control and management functions of: the infrastructure modules, the service modules and the control and management modules residing in a same one of the clouds.
Hanahan teaches wherein the one or more gateways include a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting control and management functions of: the infrastructure modules, the service modules and the control and management modules residing in a same one of the clouds (col. 10, lines 39-62: wherein the one or more gateways include a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting control and management functions of: the infrastructure modules, the service modules and the control and management modules residing in a same one of the clouds.). The motivation to combine is the same as claim 1.
Regarding claim 4, Thyagarajan does not teach the system of claim 3, wherein the C/M plane interface GW or TW-GW is configured to control access to one or more of the infrastructure modules, the service modules and the control and management modules, by one or more other of infrastructure modules, the service modules and the control and management modules or by another device.
Hanahan teaches wherein the C/M plane interface GW or TW-GW is configured to control access to one or more of the infrastructure modules, the service modules and the control and management modules, by one or more other of infrastructure modules, the service modules and the control and management modules or by another device (col. 10, lines 39-62: wherein the one or more gateways include a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting control and management functions of: the infrastructure modules, the service modules and the control and management modules residing in a same one of the clouds.). The motivation to combine is the same as claim 1.
Regarding claim 5, Thyagarajan teaches the system of claim 3, wherein said some or all of the infrastructure modules, the service modules and the control and management modules are implemented using virtualized resources in the plurality of clouds (abstract - A system for providing network function as a service includes a combination of virtual network resources hosted on physical network resources, wherein the virtual network resources are communicatively chained to provide a dynamically configurable set of processing resources and a configurable controller in communication with the combination of virtual network resources, wherein the controller includes a scheduler and load balancer. The controller is configured to receive a request to provide network function as a service functionality, retrieve policies associated with the request, schedule the virtual network resources to be assigned in response to the request, instantiate the virtual network resources and balance the virtual network resources across one or more physical resources.).
However, Thyagarajan does not teach the system further comprising, in each one of the plurality of clouds, a different respective one of the C/M plane interface gateways (GWs) or trustworthy gateways (TW-GWs), wherein different respective ones of the C/M plane interface gateways (GWs) or trustworthy gateways (TW-GWs) are coupled together for interconnecting different ones of the infrastructure modules, the service modules and the control and management modules residing in different ones of the clouds.
Hanahan teaches the system further comprising, in each one of the plurality of clouds, a different respective one of the C/M plane interface gateways (GWs) or trustworthy gateways (TW-GWs), wherein different respective ones of the C/M plane interface gateways (GWs) or trustworthy gateways (TW-GWs) are coupled together for interconnecting different ones of the infrastructure modules, the service modules and the control and management modules residing in different ones of the clouds (col. 10, lines 39-62: wherein the one or more gateways include a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting control and management functions of: the infrastructure modules, the service modules and the control and management modules residing in a same one of the clouds.). The motivation to combine is the same as claim 1.
Regarding claim 6, Thyagarajan does not teach the system of claim 3, wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is configured to operate as a signal message forwarding function in order to facilitate an interface between one or more pairs of modules, each pair of modules selected from the one or more infrastructure modules, the one or more service modules, and the one or more control and management modules, the interface being a direct logical interface.
Hanahan teaches wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is configured to operate as a signal message forwarding function in order to facilitate an interface between one or more pairs of modules, each pair of modules selected from the one or more infrastructure modules, the one or more service modules, and the one or more control and management modules, the interface being a direct logical interface (col. 29, line 50 to col. 30, line 2: System 710 may each include a virtual router and one or more virtual ports over a physical cross-connect 709 by which a virtual connection 707 between an NSP network offering connectivity to an enterprise customer and a virtual router in the data center is established. The NSP network may offer WAN connectivity. Via the cloud exchange, the virtual router may route traffic to/from one or more virtualized performance hub servers, the Internet, and one or more other cloud service provider networks 713 offering Infrastructure, Software, Platform, Data Storage, or other offering as-a-Service. At least in some examples, no colocation is required for a customer to obtain NFV services (e.g., firewall, load balancer, packet inspection) using a virtual performance hub. A system may include a virtual router, virtual ports for connecting a virtual circuit (or “interconnection”) 707 over an NSP/ECX cross connect between an NSP and the virtual router. The system may offer connectivity for a performance hub/NFV services, a WAN connection, and Internet Service connection (ISP/Internet Connect) 712, and third-party cloud services (IaaS/SaaS).). The motivation to combine is the same as claim 1.
Regarding claim 7, Thyagarajan does not teach the system of claim 3, wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is configured to operate as a signal message translator in order to facilitate an interface between one or more pairs of modules, each pair of modules selected from the one or more infrastructure modules, the one or more service modules, and the one or more control and management modules, the signal message translator changing content of messages being forwarded between said one or more pairs of modules.
Hanahan teaches wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is configured to operate as a signal message translator in order to facilitate an interface between one or more pairs of modules, each pair of modules selected from the one or more infrastructure modules, the one or more service modules, and the one or more control and management modules, the signal message translator changing content of messages being forwarded between said one or more pairs of modules (col. 24, lines 11-24: A cloud exchange point 303 NAT device(s) that applies NAT service 519 performs NAT (or NAPT), which may also or alternatively include carrier-grade NAT (“CG-NAT” or “CGN”), to translate the cloud exchange point 303 addresses and CSP routes and/or to translate the cloud exchange point 303 addresses and customer routes. The cloud exchange point 303 NAT device(s) that applies NAT service 519 (also referred to herein as “NAT service 519 device”) may include one or more dedicated NAT appliances, one or more virtual machines executing on real server(s) and configured to apply NAT using network function virtualization (NFV), one or more service cards configured to apply the NAT service 519 and inserted in one or more of PEs 302, 304, or other device(s) inbox or out-of-box.). The motivation to combine is the same as claim 1.
Regarding claim 8, Thyagarajan does not teach the system of claim 3, wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is further configured to communicatively couple some of all of the infrastructure modules, the service modules and the control and management modules to a C/M plane connection, the C/M plane connection operative for control plane messaging between client devices, servers, and some or all of the infrastructure modules, the service modules and the control and management modules.
Hanahan teaches wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is further configured to communicatively couple some of all of the infrastructure modules, the service modules and the control and management modules to a C/M plane connection, the C/M plane connection operative for control plane messaging between client devices, servers, and some or all of the infrastructure modules, the service modules and the control and management modules (col. 24, lines 11-24: PE routers may couple to one another according to a peer model without use of overlay networks. That is, PEs 310 and PEs 312 may not peer directly with one another to exchange routes, but rather indirectly exchange routes via IP/MPLS fabric 301. In the example of FIG. 3B, cloud exchange point 303 is configured to implement multiple layer 3 virtual circuits 330A-330C (collectively, “virtual circuits 330”) to interconnect customer network 308 and cloud service provider networks 322 with end-to-end IP paths. Each of cloud service providers 320 and customers 308 may be an endpoint for multiple virtual circuits 330, with multiple virtual circuits 330 traversing one or more attachment circuits between a PE/PE or PE/CE pair for the IP/MPLS fabric 301 and the CSP/customer. A virtual circuit 330 represents a layer 3 path through IP/MPLS fabric 301 between an attachment circuit connecting a customer network to the fabric 301 and an attachment circuit connecting a cloud service provider network to the fabric 301. Each virtual circuit 330 may include at least one tunnel (e.g., an LSP and/or Generic Route Encapsulation (GRE) tunnel) having endpoints at PEs 302, 304. PEs 302, 304 may establish a full mesh of tunnels interconnecting one another.). The motivation to combine is the same as claim 1.
Regarding claim 9, Thyagarajan does not teach the system of claim 3, wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is configured to: receive a request for a first module of the infrastructure modules, the service modules and the control and management modules to use a specified service; determine a second module of the infrastructure modules, the service modules and the control and management modules, the second module providing the specified service and the first module being authorized to receive the specified service from the second module; and forward the request to the second module.
Hanahan teaches wherein the C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) is configured to: receive a request for a first module of the infrastructure modules, the service modules and the control and management modules to use a specified service; determine a second module of the infrastructure modules, the service modules and the control and management modules, the second module providing the specified service and the first module being authorized to receive the specified service from the second module; and forward the request to the second module (abstract - In general, techniques are described for network connectivity for non-colocated customers of a cloud exchange. A programmable network platform for the cloud exchange comprises processing circuitry configured to: configure a virtual network device in the data center to run a network service for a customer; receive, from the customer, a request for a remote port and network information for a network service provider connectivity service for the customer; assign, in response to receiving the request for the remote port, a remote port of the cloud exchange to the customer; and configure, in response to receiving the request for the remote port using the network information, the cloud exchange to connect the network service provider connectivity service to the virtual network device via the remote port of the cloud exchange.). The motivation to combine is the same as claim 1.
Regarding claim 10, Thyagarajan does not teach the system of claim 1, further comprising a data plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting data processing functions of some or all of the service modules to a data plane connection, the data plane connection operative for data transmission between client devices, servers, and some or all of the infrastructure modules, the service modules and the control and management modules.
Hanahan teaches a data plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting data processing functions of some or all of the service modules to a data plane connection, the data plane connection operative for data transmission between client devices, servers, and some or all of the infrastructure modules, the service modules and the control and management modules (col. 10, lines 39-62: wherein the one or more gateways include a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting control and management functions of: the infrastructure modules, the service modules and the control and management modules residing in a same one of the clouds.). The motivation to combine is the same as claim 1.
Regarding claim 11, Thyagarajan does not teach the system of claim 10, wherein the data plane interface GW or TW-GW is configured to control access to one or more of the infrastructure modules, the service modules and the control and management modules, by one or more other of infrastructure modules, the service modules and the control and management modules or by another device.
Hanahan teaches wherein the data plane interface GW or TW-GW is configured to control access to one or more of the infrastructure modules, the service modules and the control and management modules, by one or more other of infrastructure modules, the service modules and the control and management modules or by another device (col. 7, lines 26-47: As examples of the above, customer 108C is illustrated as having contracted with a cloud exchange provider for cloud exchange 100 to directly access layer 3 cloud services via cloud exchange points 128C. In this way, customer 108C receives redundant layer 3 connectivity to cloud service provider 110A, for instance. Customer 108C, in contrast, is illustrated as having contracted with the cloud exchange provider for cloud exchange 100 to directly access layer 3 cloud services via cloud exchange point 128C and also to have contracted with NSP 106B to access layer 3 cloud services via a transit network of the NSP 106B. Customer 108B is illustrated as having contracted with multiple NSPs 106A, 106B to have redundant cloud access to cloud exchange points 128A, 128B via respective transit networks of the NSPs 106A, 106B. The contracts described above are instantiated in network infrastructure of the cloud exchange points 128 by L3 peering configurations within switching devices of NSPs 106 and cloud exchange points 128 and L3 connections, e.g., layer 3 virtual circuits, established within cloud exchange points 128 to interconnect cloud service provider 110 networks to NSPs 106 networks and customer 108 networks, all having at least one port offering connectivity within one or more of the cloud exchange points 128.).
Regarding claim 12, Thyagarajan does not teach the system of claim 10, wherein said some or all of the service modules are implemented in a plurality of clouds, the system further comprising, in each one of the plurality of clouds, a different respective one of the data plane interface gateways (GWs) or trustworthy gateways (TW-GWs), wherein different respective ones of the data plane interface gateways (GWs) or trustworthy gateways (TW-GWs) are coupled together for interconnecting different ones of the service modules residing in different ones of the clouds.
Hanahan teaches wherein said some or all of the service modules are implemented in a plurality of clouds, the system further comprising, in each one of the plurality of clouds, a different respective one of the data plane interface gateways (GWs) or trustworthy gateways (TW-GWs), wherein different respective ones of the data plane interface gateways (GWs) or trustworthy gateways (TW-GWs) are coupled together for interconnecting different ones of the service modules residing in different ones of the clouds (col. 24, lines 11-24: PE routers may couple to one another according to a peer model without use of overlay networks. That is, PEs 310 and PEs 312 may not peer directly with one another to exchange routes, but rather indirectly exchange routes via IP/MPLS fabric 301. In the example of FIG. 3B, cloud exchange point 303 is configured to implement multiple layer 3 virtual circuits 330A-330C (collectively, “virtual circuits 330”) to interconnect customer network 308 and cloud service provider networks 322 with end-to-end IP paths. Each of cloud service providers 320 and customers 308 may be an endpoint for multiple virtual circuits 330, with multiple virtual circuits 330 traversing one or more attachment circuits between a PE/PE or PE/CE pair for the IP/MPLS fabric 301 and the CSP/customer. A virtual circuit 330 represents a layer 3 path through IP/MPLS fabric 301 between an attachment circuit connecting a customer network to the fabric 301 and an attachment circuit connecting a cloud service provider network to the fabric 301. Each virtual circuit 330 may include at least one tunnel (e.g., an LSP and/or Generic Route Encapsulation (GRE) tunnel) having endpoints at PEs 302, 304. PEs 302, 304 may establish a full mesh of tunnels interconnecting one another.). The motivation to combine is the same as claim 1.
Regarding claim 15, Thyagarajan teaches the system of claim 1, wherein the infrastructure modules, the service modules and the control and management modules comprise a first group of modules implemented using virtualized resources provided by a first cloud and a second group of modules implemented using virtualized resources provided by a second cloud, and wherein the first group of modules are organized and interconnected in a same manner as the second group of modules ([0036] System Environment. With reference to FIG. 1, there is shown an exemplary cloud-based network topology. On the bottom layer of the topology, there is the hardware 15 that supports the SDN network functionality. There is shown Infrastructure as a Service (IasS) 12, a form of cloud computing that provides virtualized computing resources over the Internet. In an exemplary IaaS model, a telecommunications service provider may host and/or operate hardware, software, servers, storage and other infrastructure components on behalf of its vendors, including hosting and managing vendors' applications and handle tasks including system maintenance, backup and resiliency planning. IaaS platforms offer highly scalable resources that can be adjusted on-demand. This makes IaaS well-suited for workloads that are temporary, experimental or that may change unexpectedly or change over time.).
Regarding claim 16, Thyagarajan does not teach the system of claim 1, further comprising: a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting, via dedicated and secured connections, the infrastructure modules, the service modules and the control and management modules residing in a same one of a plurality of clouds; a data plane interface GW or TW-GW configured as another intermediary for interconnecting, via further dedicated and secured connections, some or all of the service modules to a data plane connection, the data plane connection operative for data transmission between client devices, servers, and some or all of the infrastructure modules, the service modules and the control and management modules, wherein the infrastructure modules, the service modules and the control and management modules, the C/M plane interface GW or TW-GW, and the data plane interface GW or TW-GW collectively form some or all of a basic architecture structure (BAS).
Hanahan teaches a C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) configured as an intermediary for interconnecting, via dedicated and secured connections, the infrastructure modules, the service modules and the control and management modules residing in a same one of a plurality of clouds; a data plane interface GW or TW-GW configured as another intermediary for interconnecting, via further dedicated and secured connections, some or all of the service modules to a data plane connection, the data plane connection operative for data transmission between client devices, servers, and some or all of the infrastructure modules, the service modules and the control and management modules, wherein the infrastructure modules, the service modules and the control and management modules, the C/M plane interface GW or TW-GW, and the data plane interface GW or TW-GW collectively form some or all of a basic architecture structure (BAS) (col. 8, line 52 to col. 9, line 15: Hardware and/or software components for NFVI 102 implement network management and resource orchestration systems of which at least one, in general, performs at least one technique described herein. In one example, the network management and resource orchestration systems form an architecture having at least three functional blocks of which one example functional block, an orchestration system, is responsible for onboarding of new network services (NS) and virtual network function (VNF) packages; NS lifecycle management; global and local resource management; and validation and authorization of network functions virtualization infrastructure (NFVI) resource requests. In some examples, network service orchestrator 112 in programmable network platform 120 is an example of the orchestration system while, in other examples, the orchestration system instructs (e.g., by way of function call) network service orchestrator 112 to dynamically allocate resources (e.g., compute) resources. Network service orchestrator 112 distributes physical resources, such as processing cores in one or more computing devices of NFVI 102, for executing VNFs. Other functional blocks (e.g., management blocks) oversee lifecycle management of VNF instances; fill the coordination and adaptation role for configuration and event reporting between NFV infrastructure (NFVI) and Element/Network Management Systems, and control and manage the NFVI compute, storage, and network resources. While shown separately as part of programmable network platform 120, these management blocks may reside in NFVI 102 and cooperate with the orchestration system when deploying VNFs.). The motivation to combine is the same as claim 1.
Regarding claim 17, Thyagarajan does not teach the system of claim 16, further comprising one or more additional BASs having a same structure as the BAS, the BAS and the additional BASs being interconnected. Hanahan teaches one or more additional BASs having a same structure as the BAS, the BAS and the additional BASs being interconnected (col. 8, line 52 to col. 9, line 15: Hardware and/or software components for NFVI 102 implement network management and resource orchestration systems of which at least one, in general, performs at least one technique described herein. In one example, the network management and resource orchestration systems form an architecture having at least three functional blocks of which one example functional block, an orchestration system, is responsible for onboarding of new network services (NS) and virtual network function (VNF) packages; NS lifecycle management; global and local resource management; and validation and authorization of network functions virtualization infrastructure (NFVI) resource requests. In some examples, network service orchestrator 112 in programmable network platform 120 is an example of the orchestration system while, in other examples, the orchestration system instructs (e.g., by way of function call) network service orchestrator 112 to dynamically allocate resources (e.g., compute) resources. Network service orchestrator 112 distributes physical resources, such as processing cores in one or more computing devices of NFVI 102, for executing VNFs. Other functional blocks (e.g., management blocks) oversee lifecycle management of VNF instances; fill the coordination and adaptation role for configuration and event reporting between NFV infrastructure (NFVI) and Element/Network Management Systems, and control and manage the NFVI compute, storage, and network resources. While shown separately as part of programmable network platform 120, these management blocks may reside in NFVI 102 and cooperate with the orchestration system when deploying VNFs.). The motivation to combine is the same as claim 1.
Regarding claim 18, Thyagarajan does not teach the system of claim 16, further comprising: another C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) forming part of another BAS and connected to the C/M plane interface GW or TW-GW of the BAS; and another data plane interface GW or TW-GW forming part of said other BAS and connected to the data plane interface GW or TW-GW of the BAS.
Hanahan teaches another C/M plane interface gateway (GW) or trustworthy gateway (TW-GW) forming part of another BAS and connected to the C/M plane interface GW or TW-GW of the BAS; and another data plane interface GW or TW-GW forming part of said other BAS and connected to the data plane interface GW or TW-GW of the BAS (col. 8, line 52 to col. 9, line 15: Hardware and/or software components for NFVI 102 implement network management and resource orchestration systems of which at least one, in general, performs at least one technique described herein. In one example, the network management and resource orchestration systems form an architecture having at least three functional blocks of which one example functional block, an orchestration system, is responsible for onboarding of new network services (NS) and virtual network function (VNF) packages; NS lifecycle management; global and local resource management; and validation and authorization of network functions virtualization infrastructure (NFVI) resource requests. In some examples, network service orchestrator 112 in programmable network platform 120 is an example of the orchestration system while, in other examples, the orchestration system instructs (e.g., by way of function call) network service orchestrator 112 to dynamically allocate resources (e.g., compute) resources. Network service orchestrator 112 distributes physical resources, such as processing cores in one or more computing devices of NFVI 102, for executing VNFs. Other functional blocks (e.g., management blocks) oversee lifecycle management of VNF instances; fill the coordination and adaptation role for configuration and event reporting between NFV infrastructure (NFVI) and Element/Network Management Systems, and control and manage the NFVI compute, storage, and network resources. While shown separately as part of programmable network platform 120, these management blocks may reside in NFVI 102 and cooperate with the orchestration system when deploying VNFs.). The motivation to combine is the same as claim 1.
Regarding claim 19, Thyagarajan teaches the system of claim 1, wherein the system serves at least one device which is configured to include: one or more further infrastructure modules each providing a respective infrastructure resource as service; one or more further service modules each providing a respective functionality as service and utilizing at least one of the infrastructure resources as service; and one or more further control and management modules each providing a respective further management or control resource as service, at least one of the further control and management modules providing said respective further management or control resource as service to at least one of the further infrastructure modules or the further service modules ([0036] System Environment. With reference to FIG. 1, there is shown an exemplary cloud-based network topology. On the bottom layer of the topology, there is the hardware 15 that supports the SDN network functionality. There is shown Infrastructure as a Service (IasS) 12, a form of cloud computing that provides virtualized computing resources over the Internet. In an exemplary IaaS model, a telecommunications service provider may host and/or operate hardware, software, servers, storage and other infrastructure components on behalf of its vendors, including hosting and managing vendors' applications and handle tasks including system maintenance, backup and resiliency planning. IaaS platforms offer highly scalable resources that can be adjusted on-demand. This makes IaaS well-suited for workloads that are temporary, experimental or that may change unexpectedly or change over time.).
Claim 20 is similar to claim 1, but in method form. it is rejected under the same rationale.
Allowable Subject Matter
Claims 13 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, AND the claims be amended or persuasively argued to overcome the rejections under 35 USC 112 as set forth above.
Regarding claim 13, the prior art of record does not teach the system of claim 12, wherein one or more of the different respective ones of the data plane interface gateways (GWs) or trustworthy gateways (TW-GWs) are operative to provide a 6G data plane interconnecting one or more of the service modules with one or more client devices, said interconnecting using the data plane connection.
Claim 14 depends on claim 13, therefore is objected to for its dependency.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
1. Tsai et al, US 20180239647 - a network functions virtualization infrastructure being managed in a decentralized fashion.
2. Zhang et al., US 10505798 - providing customized virtual networks based on SONAC.
3. Taleb et al., "Anything as a Service" for 5G Mobile Systems," - Anything as a Service" (ANYaaS), which allows a network operator to create and orchestrate 5G services on demand and in a dynamic way.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
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, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458
Prosecution Insights