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 .
This office action is in response to Applicant’s amendment filed September 10, 2026. Claims 1 and 20 have been amended. Claims 1-20 are pending.
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 implemented by one or more networked computing devices of a networked communication system (figure 15), each having at least a processor (figure 15: processor 504), a network interface (figure 15: interface 522), and a memory (figure 15: memory 506 and 508), the 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.
Response to Arguments
Claim Rejections - 35 USC § 112
The rejection is withdrawn in view of Applicant’s amendment to the independent claims.
Claim Rejections - 35 USC § 101
The rejection is withdrawn in view of Applicant’s amendment to the independent claims.
Claim Rejections - 35 USC § 103
Applicant's arguments filed September 10, 2026 have been fully considered but they are not persuasive.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
In this case, Thyagarajan reference is cited to provide the basic architecture of a cloud-based service framework having IaaS/Naas infrastructure resources, NFaaS service functionality, and centralized control/management functionality for provisioning, scheduling, load balancing, monitoring and recovering virtual network functions.
Hanahan reference is cited because it provides a complementary interconnection architecture of a programmable cloud-exchange platform having NFVI resources, VNFs, orchestration/management functionally, service interfaces, ports and virtual circuits that connect network/service resources, including secure/private virtual connections to cloud-service providers. One of ordinary skill in the art implementing the NFaaS architecture of Thyagarajan would have had reason to employ the programmable cloud-exchange/interconnection mechanism of Hanahan to provide controlled and secure connectivity among the infrastructure, network-function services, and external/management resources because Thyagarajan itself contemplates third-party/cloud-hosted functions and dynamically adding access network, while Hanahan provides mechanisms for dynamically provisioning and managing interconnections among cloud and network services.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
For at least these reasons, the rejection is sustained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
