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 .
DETAILED ACTION
This Office Action is in response to the amendment filed 05/04/2026.
Claims 1-20 are pending in this application.
Claims 1, 9 and 16 are independent claims.
Claims 1, 9 and 16 are currently amended.
This Office Action is made final.
Claim Rejections - 35 USC § 103
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1,2,9,10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further of Draznin (US 2023/0379221 A1).
As per claim 1, Mukherjee teaches A device, comprising:
a processing system including a processor; (Mukherjee Fig 6 Block 514 (Processors))
a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations, the operations comprising:
based on the determination, generating a first virtual machine image (Mukherjee [col 7, lines 13-15] Artifacts are a set of entities that are needed to bring up a VNF, such as a VM image is used to instantiate the VM and [col 9, lines 9-11] Operations 254-266 involve instantiating the VNF in the cloud computing infrastructure 110 once the POD has been installed and image downloaded and [col 24, lines 19-39] In one form, a method is provided that is performed by an orchestration entity configured to instantiate one or more virtual network functions in a cloud computing infrastructure that includes compute resources and storage resources. The method includes: obtaining a virtual network function descriptor file that describes parameters of a virtual network function to be instantiated in the cloud computing infrastructure, and a network services descriptor file that defines networking parameters to be supported in the cloud computing infrastructure, wherein the virtual network function descriptor file includes vendor-specific enhanced resource information associated with one or more configurations of the compute resources and/or storage resources [VNF is made based on resources needed] ; creating, based on the virtual network function descriptor file and the network services descriptor file, artifacts that are referenced when instantiating the virtual network function, the artifacts including an aggregation of servers corresponding to a virtual network capacity, virtual machine images, and network configurations; and instantiating the virtual network function on a Point of Delivery (POD) in the cloud computing infrastructure, based on the artifacts.),
providing the first virtual machine image to equipment of a public cloud provider. (Mukherjee [col 7, lines 12-20] Artifacts are a set of entities that are needed to bring up a VNF, such as a VM image is used to instantiate the VM. The artifact creation relates to what was done on the physical POD building step. The image has to be known to that instance of the cloud control software 118, such as Openstack. For example, in Openstack, a set of “networks” is aligned with the VM and that is defined/included in the artifacts and [col 17, lines 47-51] At 430, the orchestration entity instantiates the VNF on the POD in the cloud computing infrastructure [equipment of public cloud provider], based on the artifacts.)
Mukherjee does not teach wherein the first virtual machine image includes a session border controller (SBC) and the at least one message network function.
However, Parikh teaches wherein the first virtual machine image includes a session border controller (SBC) and the at least one message network function (Parikh Fig 2 Block 212 (v-sbc) and Block 214 (V-CSCF) [message network function] and [0014] FIG. 2 is a block diagram illustrating aspects of hardware resources and virtual network functions in a cloud computing system [consistent with Mukhreje], according to an illustrative embodiment. [0038] In the illustrated example, the VNFs 106 include one or more virtual session border controllers (“V-SBCs”) 212 and one or more virtual call session control functions (“V-CSCFs”) 214…);
The examiner believes this interpretation of message network function is consistent with what is provided in the specification ([0041] One or more voice or message network functions may be received at 210D. Example voice and/or message network functions include, but are not limited to, include a short message service center (SMSC), a short message server function (SMSF), a message center (MC), a call session control function (CSCF), and associated proxies, and the like.)
The examiner will assume that CSCF can handle both voice as well as messages (and thus covers both claim 1 and 9). This is consistent with what is available in literature of communication devices. For example https://www.mobius-software.com/documentation/Mobius+TAS/Call+Session+Control+Function+%28CSCF%29
mentions “CSCF acts as a proxy for signaling messages between the end-user devices and the core network”.
Parikh also mentions messaging using CSCF in several places (see for example [0042] An I-CSCF can forward SIP message requests and responses to the S-CSCF. An I-CSCF can encrypt SIP messages or portions thereof. It should be understood that an I-CSCF of the V-CSCFs 214 can perform additional operations known to those skilled in the art, and as such, the operations described above should not be construed as being limiting in any way.).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Parikh with the system of Mukherjee to use a session border controller. One having ordinary skill in the art would have been motivated to use Parikh into the system of Mukherjee for the purpose of handling capacity constraints within a virtual zone (Parikh paragraph 08).
Examiner believes Mukherjee teaches determining demand (i.e. determining resource requirement for the VNF as shown above based on vendor specific resource requirements. The cited paragraph in the specification (paragraph 30) states [0030] In some embodiments, enterprise 210A may benefit from moving one or more network functions to public cloud 180. For example, enterprise 210A may move one or more network functions 224A to equipment of the public cloud to provide elastic scaling up and down of these network functions as needed based on demand. Demand may fluctuate based on many factors (e.g., seasonal variations, time-of-day variations, demand fluctuations resulting from events such as concerts, etc.) and elastic scaling in the cloud allows current demand to be quickly met without additional real-time overhead being placed on enterprise 210A.
This teaches resource elasticity and does not mention how this is tied to image formation (things like VNF descriptor etc).
The art of Draznin is introduced below to further emphasize resource determination as being a natural part of instantiating a VNF.
Draznin teaches determining a demand for at least one message network function resulting in a determination (Draznin 0073] Block 1515 includes maintaining a database storing a catalog of VNFs from a plurality of third-party vendors, in which the catalog exposes a UI to the one or more customers configured to enable browsing of VNF descriptive information and selection of VNFs for deployment. Block 1520 includes registering the plurality of third-party vendors with the network functions delivery system, in which the plurality of third-party vendors provides a plurality of VNFs for listing in the catalog, and in which the VNFs are packaged for the network functions delivery system where each VNF package comprises a software image to run a VNF, a VNF descriptor defining metadata to onboard the VNF package to the network functions delivery system, specified NFVI resource requirements, and artifacts for managing VNFs when deployed, and wherein the plurality of third-party vendors provides the VNF descriptive information for inclusion in the catalog. Block 1525 includes, in response to customer selection of a VNF for deployment, comparing the specified NFVI resource requirements with currently available resources on the NFVI based on the monitoring).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Draznin with the system of Mukhreje and Parikh to determine resource demand for the VNF. One having ordinary skill in the art would have been motivated to use Draznin into the system of Mukhreje and Parikh and for implementing a VNF deployment data model (Draznin paragraph 03)
As per claim 2, Mukherjee teaches wherein the operations further comprise providing the equipment of the public cloud provider with instructions to dynamically instantiate virtual machines using the first virtual machine image. (Mukherjee [col 7, lines 13-15] Artifacts are a set of entities that are needed to bring up a VNF, such as a VM image is used to instantiate the VM).
As to claims 9 and 16, they are rejected based on the same reason as claim 1.
As to claim 10, it is rejected based on the same reason as claim 2.
Claims 3,8,11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Lindholm (US 2018/0063688 A1).
As per claim 3, Mukherjee and Parikh and Draznin do not teach wherein the SBC and the at least one message network function are configured to communicate within an instantiated virtual machine without an IPsec tunnel.
However, Lindholm teaches wherein the SBC and the at least one message network function are configured to communicate within an instantiated virtual machine without an IPsec tunnel. (Lindholm [0059] In order for this method to work, the UE must accept the 200 OK response without receiving the 410 response which would normally precede it when registering with the IMS. Also, the UE should accept the 200OK response without requiring authentication of the P-CSCF or that an IPSec secure association is set up, as both of these procedures require data that is held in the HPLMN. Given that this procedure is only to be used in an emergency, it is anticipated that the lack of security is acceptable in this case).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Lindholm with the system of Mukhreje and Parikh and Draznin to communicate within an instantiated virtual machine without an IPsec tunnel. One having ordinary skill in the art would have been motivated to use Lindholm into the system of Mukhreje and Parikh and Draznin for the purpose of enabling emergency calls handling for roaming UEs on the network. (Lindholm paragraph 01)
As per claim 8, Mukherjee and Parikh and Draznin do not teach wherein the first virtual machine image further includes a voice network function configured to communicate with the SBC without an IPsec tunnel.
However, Lindholm teaches wherein the first virtual machine image further includes a voice network function configured to communicate with the SBC without an IPsec tunnel. (Lindholm [0059] In order for this method to work, the UE must accept the 200 OK response without receiving the 410 response which would normally precede it when registering with the IMS. Also, the UE should accept the 200OK response without requiring authentication of the P-CSCF or that an IPSec secure association is set up, as both of these procedures require data that is held in the HPLMN. Given that this procedure is only to be used in an emergency, it is anticipated that the lack of security is acceptable in this case).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Lindholm with the system of Mukhreje and Parikh and Draznin to communicate with the SBC without an IPsec tunnel. One having ordinary skill in the art would have been motivated to use Lindholm into the system of Mukhreje and Parikh and Draznin for the purpose of enabling emergency calls handling for roaming UEs on the network. (Lindholm paragraph 01)
As to claims 11 and 20, they are rejected based on the same reason as claim 8.
Claim 4, 12 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Lindholm (US 2018/0063688 A1) and Knuth (US 2022/0094790 A1).
As per claim 4, Mukherjee and Parikh and Draznin and Lindholm do not teach wherein the operations further comprise establishing a first IPsec tunnel between an enterprise gateway and the SBC in the instantiated virtual machine.
However, Knuth teaches wherein the operations further comprise establishing a first IPsec tunnel between an enterprise gateway and the SBC in the instantiated virtual machine. (Knuth [0060] The method may also include transmitting a secure channel confirmation from the content delivery device to the enterprise device confirming the communication channel was established. In one example, the secure channel confirmation is a 200 OK session initiation protocol (SIP) message. The call content data includes one or more of an image file, an audio file, a video file, a location map, and a web link. The communication channel is a IPsec channel and is established between the mobile device and a session border control (SBC) entity and a public branch exchange (PBX) operated within an enterprise network hosting the enterprise device)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Knuth with the system of Mukhreje and Parikh and Draznin and Lindholm to establish a first IPsec tunnel. One having ordinary skill in the art would have been motivated to use Knuth into the system of Mukhreje and Parikh and Draznin and Lindholm for the purpose of confirmation, confirming and routing the call to the mobile device via the communication channel. (Knuth paragraph 03)
As to claims 12 and 17, they are rejected based on the same reason as claim 4.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Lindholm (US 2018/0063688 A1) and Knuth (US 2022/0094790 A1) and Qiu (US 2022/0078091 A1).
As per claim 5, Mukherjee and Parikh and Draznin and Lindholm and Knuth do not teach wherein the operations further comprise communicating through the first IPsec tunnel with the at least one message network function in the instantiated virtual machine,
However, Qui teaches wherein the operations further comprise communicating through the first IPsec tunnel with the at least one message network function in the instantiated virtual machine. (Qiu [0033] shows ipsec [0073] a short message service center (SMSC), an automatic location function server (ALPS), a gateway mobile location center (GMLC), a serving gateway (S-GW) 430, a packet data network (PDN) gateway, an RAN, a serving mobile location center (SMLC), [0092] A virtual network functions (VNFs) 902 may be able to support a limited number of sessions. Each VNF 902 may have a VNF type that indicates its functionality or role. For example, FIG. 9A illustrates a gateway VNF 902a and a policy and charging rules function (PCRF) VNF 902b. Additionally or alternatively, VNFs 902 may include other types of VNFs. Each VNF 902 may use one or more virtual machines (VMs) 904 to operate. Each VM 904 may have a VM type that indicates its functionality or role. For example, FIG. 9A illustrates a management control module (MCM) VM 904a, an advanced services module (ASM) VM 904b, and a device enrollment program module (DEP) VM 904c. Additionally or alternatively, VMs 904 may include other types of VMs. Each VM 904 may consume various network resources from a hardware platform 906, such as a resource 908, a virtual central processing unit (vCPU) 908a, memory 908b, or a network interface card (NIC) 908c. Additionally or alternatively, hardware platform 906 may include other types of resources 908.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Qiu with the system of Mukhreje and Parikh and Draznin and Lindholm and Knuth to communicate through the first IPsec tunnel. One having ordinary skill in the art would have been motivated to use Qiu into the system of Mukhreje and Parikh and Draznin and Lindholm and Knuth for the purpose of maintaining fault resilience in a network. (Qiu paragraph 04)
Claims 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Li (US 2025/0393089 A1)
As per claim 6, Mukherjee and Parikh and Draznin do not teach wherein the at least one message network function includes a 5G short message server function (SMSF).
However, Li teaches wherein the at least one message network function includes a 5G short message server function (SMSF). (Li [0092] The AMF 144 allows other functions of the 5GC 140 to communicate with the UE 102 and the RAN 104 and to subscribe to notifications about mobility events w.r.t the UE 102. The AMF 144 includes the following functionality, some or all which may be supported in a single instance of an AMF 144: termination of RAN CP interface (N2); termination of NAS (N1), NAS ciphering and integrity protection; registration management; connection management; reachability management; mobility management; lawful intercept (for AMF events and interface to LI System); provide transport for session management (SM) messages between UE 102 and SMF 146; transparent proxy for routing SM messages; access authentication; access authorization; provide transport for short message service (SMS) messages between UE 102 and SMS function (SMSF); security anchor functionality (SEAF) as specified in 3GPP TS 33.501 (“[TS33501]”); location services management for regulatory services; provide transport for location services messages between the UE 102 and location management function (LMF) and between the RAN 104 and the LMF; EPS Bearer ID allocation for interworking with EPS; UE mobility event notification; S-NSSAIs per TA mapping notification; support for Control Plane CIoT 5GS optimization; support for User Plane CIoT 5GS optimization; support for restriction of use of enhanced coverage; provisioning of external parameters (expected UE behavior parameters or Network Configuration parameters); support for Network Slice-Specific Authentication and Authorization; support for charging; controlling the 5G access stratum-based time distribution based on UE's subscription data; and/or controlling the gNB's time synchronization status reporting and subscription. In addition to the aforementioned functionalities of the AMF 144, the AMF 144 may include policy related functionalities as described in clause 6.2.8 of [0209] The term “network function” or “NF” at least in some examples refers to a functional block within a network infrastructure that has one or more external interfaces and a defined functional behavior. The term “Application Function” or “AF” at least in some examples refers to an element or entity that interacts with a 3GPP core network in order to provide services. Additionally or alternatively, the term “Application Function” or “AF” at least in some examples refers to an edge compute node or ECT framework from the perspective of a 5G core network. The term “virtualized network function” or “VNF” at least in some examples refers to an implementation of an NF that can be deployed on a Network Function Virtualization Infrastructure (NFVI). The term “Network Functions Virtualization Infrastructure Manager” or “NFVI” at least in some examples refers to a totality of all hardware and software components that build up the environment in which VNFs are deployed).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Li with the system of Mukhreje and Parikh and Draznin to use a short message server function. One having ordinary skill in the art would have been motivated to use Li into the system of Mukhreje and Parikh and Draznin for the purpose of ease of communicating with edge computing and data centers (Li paragraph 02).
As to claim 19, it is rejected based on the same reason as claim 6.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Bendi (US 2020/0036668 A1).
As per claim 7, Mukherjee and Parikh and Draznin do not teach wherein the at least one message network function includes a short message service center (SMSC).
However, Bendi teaches wherein the at least one message network function includes a short message service center (SMSC). (Bendi [0042] Server device 430 includes one or more devices capable of storing, processing, and/or routing information associated with a message. For example, server device 430 may include a server (e.g., in a data center or a cloud computing environment), a data center (e.g., a multi-server micro data center), a workstation computer, a virtual machine (VM) provided in a cloud computing environment, a short message service center (SMSC), a multimedia messaging service center (MMSC), a simple mail transfer protocol (SMTP) gateway, or a similar type of device. In some implementations, server device 430 may include a communication interface that allows server device 430 to receive information from and/or transmit information to other devices in environment 400. In some implementations, server device 430 may receive a request for classification information from messaging gateway device 420, and may provide a response message, which includes the classification information, to messaging gateway device 420, as described elsewhere herein. [0043] Inter-carrier server device 440 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with a message. For example, inter-carrier server device 440 may include a server (e.g., in a data center or a cloud computing environment), a data center (e.g., a multi-server micro data center, a virtual machine (VM) provided in a cloud computing environment, an SMSC, an MMSC, an SMTP gateway, or a similar type of device. In some implementations, inter-carrier server device 440 may receive a message from messaging gateway device 420, as described elsewhere herein).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Bendi with the system of Mukhreje and Parikh and Draznin to use a short message service center. One having ordinary skill in the art would have been motivated to use Bendi into the system of Mukhreje and Parikh and Draznin for the purpose of avoiding delays in communication (Bendi paragraph 10).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Lindholm (US 2018/0063688 A1) and Knuth (US 2022/0094790 A1) and Burdin (US 2023/0344727 A1)
As per claim 13, Mukherjee and Parikh and Draznin and Lindholm and Knuth wherein the operations further comprise communicating through the first IPsec tunnel with the SBC in the instantiated virtual machine.
However, Burdin teaches wherein the operations further comprise communicating through the first IPsec tunnel with the SBC in the instantiated virtual machine. (Burdin [0014] As described above, conventional systems cannot identify and allocate VNFs to execute the necessary functions on incoming data in a given network. For example, VNFs are often implemented in telecommunication networks, such as 5G networks. Additionally, VNFs execute network functions including but not limited to: Switching: BNG, CG-NAT, routers; Tunneling gateway elements: IPSec/SSL VPN gateways, web-proxies; Traffic analysis: deep packet inspection devices, QoE measurement; Signaling: SBCs, IMS; Application-level optimization: CDNs, load Balancers, application filters; Home routers and set-top boxes; Mobile network nodes: HLR/HSS, MME, SGSN, GGSN/PDN-GW, RNC; Network-wide functions: AAA servers policy control, charging platforms; and Security functions: firewalls, intrusion detection systems, virus scanners, spam protection. Multiple functions may need to be executed on a single data packet before it is routed to its respective destination. However, conventional routers do not implement VNFs. As such, conventional systems cannot identify the appropriate VNFs to execute the functions in the desired order. [0030] As indicated above, VNFs 1-n may be software implementations of network functions. The network functions may include but are not limited to: Switching: BNG, CG-NAT, routers; Tunneling gateway elements: IPSec/SSL VPN gateways, web-proxies; Traffic analysis: deep packet inspection devices, QoE measurement, QoS measurement; Signaling: SBCs, IMS; Application-level optimization: CDNs, load Balancers, application filters; Home routers and set-top boxes; Mobile network nodes: HLR/HSS, MME, SGSN, GGSN/PDN-GW, RNC; Network-wide functions: AAA servers policy control, charging platforms; and Security functions: firewalls, intrusion detection/prevention systems, virus scanners, spam protection. In this regard, the software implementations of network functions may be executed on attributes such as the security policies of originating network node 110 or intended destination, size of the data packet, the urgency of the data packet, type of data in the data packet, etc).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Burdin with the system of Mukhreje and Parikh and Draznin and Lindholm and Knuth to communicate through the first IPsec tunnel. One having ordinary skill in the art would have been motivated to use Burdin into the system of Mukhreje and Parikh and Draznin and Lindholm and Knuth for the purpose of instantiating virtual network functions (VNFs) in a network infrastructure device.(Burdin paragraph 13)
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Krasilnikov (US 12,432,606 B1)
As per claim 14, Mukherjee and Parikh and Draznin do not teach wherein the at least one voice network function includes a user plane function (UPF).
However, Krasilnikov teaches wherein the at least one voice network function includes a user plane function (UPF). (Krasilnikov [col 6, lines 58-67 and col 7, lines 1-3] The network functions of the core network can include a User Plane Function (UPF), Access and Mobility Management Function (AMF), and Session Management Function (SMF), described in more detail below. For data traffic destined for locations outside of the communication network 100, network functions typically include a firewall through which traffic can enter or leave the communication network 100 to external networks such as the Internet or a cloud provider network. Note that in some embodiments, the communication network 100 can include facilities to permit traffic to enter or leave from sites further downstream from the core network (e.g., at an aggregation site or radio-based network 103)).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Krasilnikov with the system of Mukhreje and Parikh and Draznin to use a user plane function. One having ordinary skill in the art would have been motivated to use Krasilnikov into the system of Mukhreje and Parikh and Draznin for the purpose of using a distributed unit management service for automatically deploying, configuring, and managing DUs in radio-based networks. (Krasilnikov col 2, lines 18-20)
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Butler (US 2023/0291661 A1)
As per claim 16, Mukherjee and Parikh and Draznin do not teach wherein the at least one voice network function includes a control plane function (CPF).
However, Butler teaches wherein the at least one voice network function includes a control plane function (CPF). (Butler [0027] The interfaces N1 through N15 define communications and/or protocols between each NF as described in relevant standards. The UPF 216 is part of the user plane and the AMF 210, SMF 214, PCF 212, AUSF 206, and UDM 208 are part of the control plane. Collectively, the network functions that make up the control plane (referred to herein as “control plane functions”) perform the signalling that establishes and maintains access to services in the telecommunications network, such as voice, text, or data services).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Butler with the system of Mukhreje and Parikh and Draznin to use a control plane function. One having ordinary skill in the art would have been motivated to use Butler into the system of Mukhreje and Parikh and Draznin for the purpose of reducing latency in communicating with a control plane (Butler paragraph 02).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Mukherjee (US 11,687,355 B1) in view of Parikh (US 2016/0057208 A1) in further view of Draznin (US 2023/0379221 A1) and Tomasso (US 2022/0217126 A1)
As per claim 18, Mukherjee and Parikh and Draznin do not teach establishing, by the processing system, a second IPsec tunnel between the enterprise gateway and a second SBC in a second virtual machine instantiated by the equipment of the public cloud provider based on the virtual machine image.
However, Tomasso teaches establishing, by the processing system, a second IPsec tunnel between the enterprise gateway and a second SBC in a second virtual machine instantiated by the equipment of the public cloud provider based on the virtual machine image. (Tomasso [claim1] A device comprising: a processor configured to run a first virtual machine, wherein the first virtual machine is configured to establish a first IP security (IPSEC) Virtual Private Network (VPN) and receive data, apply a first encryption to the data thereby generating one-layer encrypted data, and send the one-layer encrypted data to a first set of ports; and the processor is further configured to run a second virtual machine, wherein the second virtual machine is configured to establish a second IPSEC VPN and receive the one-layer encrypted data at the first set of ports, apply a second encryption to the one-layer encrypted data thereby generating two-layer encrypted data, and send the two-layer encrypted data to a second set of ports).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Tomasso with the system of Mukhreje and Parikh and Draznin to establish a tunnel based on a virtual machine image. One having ordinary skill in the art would have been motivated to use Tomasso into the system of Mukhreje and Parikh and Draznin for the purpose of improving the functionality of a networking device (Tomasso paragraph 02).
Response to Arguments
Applicant's arguments filed on 05/04/2026 have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claims 1, 9 and 16 have been considered but are moot because the arguments do not apply because of the introduction of new art by Draznin.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor April Blair, can be reached on (571)270-1014. 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.
/MEHRAN KAMRAN/Primary Examiner, Art Unit 2196
Prosecution Insights