DETAILED ACTION
This office action is a response to an amendment filed on 12/18/2025.
Response to Amendment
The Amendment filed on 12/18/2026 has been entered.
Claims 1-14 are pending
Claims 1, 6, 10 and 12 are amended
Claims 15-20 are withdrawn
Claims 1-14 remain rejected.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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-6 and 11, are rejected under 35 U.S.C. 103 as being unpatentable over Khasnabish et al. (US 20220103985 A1), hereinafter referenced as Khasnabish, in view of Grewal et al. (US 20240031908 A1), hereinafter referenced as Grewal, and further in view of Krishan et al. (US 20210204200 A1), hereinafter referenced as Krishan.
Regarding claim 1, Khasnabish teaches a hybrid cloud cellular network (Para. [0017]-Khasnabish discloses network device may be implemented according to various computing architectures, such as centralized, distributed, cloud (e.g., elastic, public, private, hybrid, etc.), edge, fog, and/or another type of computing architecture, and may be incorporated into various types of network architectures (e.g., software defined network (SDN), virtual network, logical network, network slice, overlay or underlay networks, etc.). Para. [0009]-Khasnabish discloses broadband cellular networks (e.g., Fifth Generation (5G) New Radio networks) is the use of Multi-access Edge Compute (MEC) platforms (also referred to herein as Mobile Edge Compute platforms)), comprising:
a plurality of base stations, each base station of the plurality of base stations comprising: a radio unit (RU); a router; and a distributed unit (DU) (Para. [0022]-Khasnabish discloses access device 107 may include a next generation Node B (gNB), an evolved Node B (eNB), an evolved Long Term Evolution (eLTE) eNB, a radio network controller (RNC), a remote radio head (RRH), a baseband unit (BBU), a radio unit (RU), a CU, a DU {Distributed Unit} ... transport service (e.g., routing and forwarding), such as a router. Para. [0039]-Khasnabish discloses MEC platform 115 may receive inputs (e.g., continuously or frequently per configuration) from base stations (e.g., access devices 107). Para. [0021]-Khasnabish discloses Access network 105 may include ... centralized unit (CU) and distributed unit (DU)); and
a cellular network cluster comprising a plurality of network functions (Para. [0009]-Khasnabish discloses broadband cellular networks (e.g., Fifth Generation (5G) New Radio networks) is the use of Multi-access Edge Compute (MEC) platforms (also referred to herein as Mobile Edge Compute platforms). Para. [0013]-Khasnabish discloses virtual network functions executed on the MEC cluster),
the cellular network cluster is implemented on a cloud computing platform (Para. [0009]-Khasnabish discloses powerful computing resources may be available via a cloud computing network … broadband cellular networks (e.g., Fifth Generation (5G) New Radio networks) is the use of Multi-access Edge Compute (MEC) platforms (also referred to herein as Mobile Edge Compute platforms). Para. [0013]-Khasnabish discloses virtual network functions executed on the MEC cluster) and
communicates with a plurality of DUs of the plurality of base stations (Figs. 2-3, Para. [0044]-Khasnabish discloses access network 105 support separation of control and user planes (such as in 5G networks), a control and user plane separation (CUPS) gateway can be strategically placed near the edge (e.g., MEC platform 115) in order to support both in-band (same channel) and out-of-band (separated, as in CUPS) signaling. Para. [0021]-Khasnabish discloses Access network 105 may include ... centralized unit (CU) and distributed unit (DU). Para. [0039]-Khasnabish discloses MEC platform 115 may receive inputs (e.g., continuously or frequently per configuration) from base stations (e.g., access devices 107)),
the cellular network cluster comprising: a virtual router, implemented on the cloud computing platform, configured to: receive a data packet from the cellular network cluster (Figs. 1-2, Para. [0045]-Khasnabish discloses UPF 330 performs packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling. UPF 220 may act as a router and a gateway between core network 120 and an external data network 125 and may forward session data between data network 125 and access network 105, or between MEC platforms 115 and access network 105. Fig. 3, Para. [0041]-Khasnabish logical components {corresponding to virtual component} for implementing an edge slice proxy (ESP) service structure 300. The edge slice proxy may generally facilitate extending features and functionality of network slicing to the MEC platforms 115 ... ESP service structure 300 may include an edge network exposure function 305, ..., a user plane function (UPF) 330).
Khasnabish fails to teach route the data packet to a second virtual router of a plurality of virtual routers implemented on the cloud computing platform, wherein: the virtual router and the second virtual router are configured to function as an overlay on the cloud computing platform's underlying native routing architecture; the virtual router and the second virtual router are located within different cloud computing regions of the cloud computing platform.
However, Grewal teaches route the data packet to a second virtual router of a plurality of virtual routers implemented on the cloud computing platform (Figs. 1-4, Para. [0080]-Grewal discloses Virtualized cell site router 20A includes a virtual router forwarding plane (vRouter) 206A configured with VRFs 212A-212K (collectively, “VRFs 212”) for respective network slices implemented with respective L3VPNs, which vCSR 20A and routers 204A-204B implement using tunnels 231A-231K connecting VRFs 212 to VRFs 210A-210K on routers 204A-204B. Fig. 13, Para. [0213]-Grewal discloses all pod connectivity is implemented using virtual routers ... Network controller 1324 may implement the network solution in the computing infrastructure by, e.g., configuring the one or more virtual network and virtual network interfaces in the virtual routers. Para. [0068]-Grewal discloses vCSRs 20 may operate as provider edge (PE) routers for networks transporting layer 3 packets among DUs 22, CUs 13, and mobile core network 7. Para. [0097]-Grewal discloses (vRouter 206A alone) may provide fast path data packet handling by vRouter 206A as well as full control plane routing functionality for virtualized cell site router 20A. Para. [0181-0184]-Grewal discloses Virtual router 206A implements one or more virtual routing and forwarding instances (VRFs) 222A-222B for respective virtual networks for which virtual router 206A operates as respective tunnel endpoints ... If the destination is another virtual network endpoint executing on computing device 800, virtual router 206A routes the packet to the appropriate one of virtual network interfaces 212, 213. (See also Figs. 7-8, Para. [0009-0012, 0160, 0173])),
the virtual router and the second virtual router are configured to function as an overlay on the cloud computing platform's underlying native routing architecture (Para. [0169]-Grewal discloses virtual routers implement each virtual network using an overlay network. Fig. 4, Para. [0107]-Grewal discloses having learned the routes, whether by routing protocols or from SDN controller 70, cRPD 324 can selectively program … overlay routes to vRouter 206A (via vRouter agent 314). Para. [0149]-Grewal discloses the system supports VRF functionality where overlay and underlay routes remain separated in different VRFs. (See also Para. [0219-0230]));
the virtual router and the second virtual router are located within different cloud computing regions of the cloud computing platform (Figs. 1-2, Para. [0081]-Grewal discloses each of the VRFs 212A-212K has a corresponding virtual network interface to DU 22A. Each of the virtual network interfaces of DU 22A may thus be mapped into a different L3VPN in vCSR 20A {virtual Cell Site Router} ... vCSR 20A is introduced as a cloud-native router into the data path to, e.g., support the F1 interfaces to CUs 213A-213K that may be executing in edge or regional data center sites. Para. [0061]-Grewal discloses CUs 13 are shown in FIG. 1 as located at a regional data center, typically within 40 km of the supported DUs 22).
Khasnabish and Grewal are considered to be analogous to the claimed invention because they are in the same field of communication network, dealing with virtualized computing infrastructure and, more specifically, to a containerized router.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish to incorporate the teachings of Grewal on cloud networks, with a motivation for virtual routers to virtual router communication, and guarantee improved network management, (Grewal, Para. [0008]).
Khasnabish fails to teach the virtual router is configured to analyze a label of the data packet; and the virtual router prioritizes routing of the data packet on the cloud computing platform to the second virtual router based on the label of the data packet.
However, Krishan teaches the virtual router is configured to analyze a label of the data packet (Para. [0080]-Krishan discloses the DSCP value {corresponding to label} assigned to the service by NRF 100 can be used to mark packets transmitted over the connection. Intermediate switches and routers will use the DSCP value to identify the service class of received packets and provide the appropriate quality of service. Para. [0006]-Krishan discloses core network service may include resources of a virtualized NRF); and
the virtual router prioritizes routing of the data packet on the cloud computing platform to the second virtual router based on the label of the data packet (Para. [0045]-Krishan discloses it is important for consumer NFs to be able to ensure that transport priority is set for 5G messages so that the messages can be handled accordingly by intermediate network nodes before the messages reach the producer NF. Para. [0080]-Krishan discloses Intermediate switches and routers will use the DSCP value {corresponding to label} to identify the service class of received packets and provide the appropriate quality of service).
Khasnabish and Krishan are both considered to be analogous to the claimed invention because they are in the same field of communication network, dealing with methods, systems, and computer readable media for enabling 5G networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal to incorporate the teachings of Krishan on packet labelling, with a motivation packet routes prioritization, and guarantee transport quality of service in 5G networks, (Krishan, Para. [0009]).
Regarding claim 2, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 1.
Khasnabish fails to teach the virtual router comprises a prioritization engine, configured to: analyze the received data packet; and prioritize the data packet based on the label of the data packet, wherein prioritizing the data packet comprises delivering the data packet ahead of a second data packet having a lesser priority.
However, Krishan teaches the virtual router comprises a prioritization engine, configured to: analyze the received data packet (Para. [0080]-Krishan discloses Intermediate switches and routers will use the DSCP value {corresponding to label} to identify the service class of received packets and provide the appropriate quality of service); and
prioritize the data packet based on the label of the data packet (Para. [0045]-Krishan discloses it is important for consumer NFs to be able to ensure that transport priority is set for 5G messages so that the messages can be handled accordingly by intermediate network nodes before the messages reach the producer NF. Para. [0080]-Krishan discloses Intermediate switches and routers will use the DSCP value {corresponding to label} to identify the service class of received packets and provide the appropriate quality of service),
prioritizing the data packet comprises delivering the data packet ahead of a second data packet having a lesser priority (Para. [0006]-Krishan discloses the priority information may also be used for routing and proxies. A server may also use the priority information to process higher priority requests before lower priority requests).
Krishan is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with methods, systems, and computer readable media for enabling 5G networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal to incorporate the teachings of Krishan on packet prioritization, with a motivation to transmit prioritized packet first, and guarantee transport quality of service in 5G networks, (Krishan, Para. [0009]).
Regarding claim 3, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 2.
Khasnabish fails to teach the assigned priority is based on the data packet comprising data for a wireless 911 call.
However, Krishan teaches the assigned priority is based on the data packet comprising data for a wireless 911 call (Para. [0047]-Krishan discloses to provide transport quality of service for 5G network traffic. One particular application for such transport quality of service is network slicing. Network slicing is used in 5G networks to provide service based on the target functionality. Examples of such functionality include ultra-reliable low latency communications, massive IoT, and emergency services {corresponding to wireless 911 calls/texts}. Para. [0045]-Krishan discloses it is important for consumer NFs to be able to ensure that transport priority is set for 5G messages).
Krishan is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with methods, systems, and computer readable media for enabling 5G networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal to incorporate the teachings of Krishan on packet prioritization, with a motivation to prioritize wireless 911 calls, and guarantee transport quality of service in 5G networks, (Krishan, Para. [0009]).
Regarding claim 4, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 1.
Khasnabish fails to teach the virtual router comprises a routing table that defines where data packets are to be routed based on a characteristic of the data packets.
However, Grewal teaches the virtual router comprises a routing table that defines where data packets are to be routed based on a characteristic of the data packets (Para. [0181]-Grewal discloses Para. [0181]-Grewal discloses each VRF 222 stores forwarding information for the corresponding virtual network and identifies where data packets are to be forwarded … Each of VRFs 222 may include a network forwarding table storing routing and forwarding information for the virtual network).
Grewal is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with virtualized computing infrastructure and, more specifically, to a containerized router.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Krishan to incorporate the teachings of Grewal on virtual routers, with a motivation for the routers to have routing tables, and guarantee improved network management, (Grewal, Para. [0008]).
Regarding claim 5, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 1.
Khasnabish fails to teach the virtual router is configured to use multiprotocol label switching (MPLS) to route the data packet.
However, Grewal teaches the virtual router is configured to use multiprotocol label switching (MPLS) to route the data packet (Para. [0016]-Grewal discloses Multi-Protocol Label Switching (MPLS) routes may be programmed on the virtual router).
Grewal is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with virtualized computing infrastructure and, more specifically, to a containerized router.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Krishan to incorporate the teachings of Grewal on virtual routers, with a motivation for the routers to use MPLS to route data packet, and guarantee improved network management, (Grewal, Para. [0008]).
Regarding claim 6, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 5.
Khasnabish fails to teach the virtual router is further configured to use generic routing encapsulation between the virtual router and the second virtual router located in a second cellular network cluster on the cloud computing platform.
However, Grewal teaches the virtual router is further configured to use generic routing encapsulation between the virtual router and the second virtual router located in a second cellular network cluster on the cloud computing platform (Fig. 2, Para. [0180]-Grewal discloses example tunneling protocols that may be used include IP over Generic Route Encapsulation (GRE), VxLAN, Multiprotocol Label Switching (MPLS) over GRE. Para. [0110]-Grewal discloses vRouter agent 314 provides a generic interface 340 .... This generic interface 340 may be implemented by any controller, routing protocol process, or other agent because it relies on gRPC).
Grewal is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with virtualized computing infrastructure and, more specifically, to a containerized router.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Krishan to incorporate the teachings of Grewal on virtual routers, with a motivation for the routers to use generic routing encapsulation, and guarantee improved network management, (Grewal, Para. [0008]).
Regarding claim 11, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 2.
Khasnabish further teachs the hybrid cloud cellular network is a 5G New Radio (NR) radio access technology (RAT) cellular network (Para. [0031]-Khasnabish discloses End device 130 may support one or multiple RATs (e.g., 4G, 5G, and/or future generation RAT) and various portions of the radio spectrum (e.g., multiple frequency bands, multiple carrier frequencies, licensed, unlicensed, mm wave, above mm wave, etc.), various levels and variations of network slicing, DC service, and/or other types of connectivity services. Para. [0017]-Khasnabish discloses network device may be implemented according to various computing architectures, such as centralized, distributed, cloud (e.g., elastic, public, private, hybrid, etc.)).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Khasnabish et al. (US 20220103985 A1), hereinafter referenced as Khasnabish, in view of Grewal et al. (US 20240031908 A1), hereinafter referenced as Grewal, in view of Krishan et al. (US 20210204200 A1), hereinafter referenced as Krishan, and further in view of Shevade et al. (US 20220311744 A1), hereinafter referenced as Shevade.
Regarding claim 7, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 1.
Khasnabish further teaches the virtual router is implemented as code that is loaded by a cellular network operator onto the cloud computing platform (Para. [0045]-Khasnabish discloses UPF 330 performs packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling. UPF 220 may act as a router and a gateway between core network 120 and an external data network 125 and may forward session data between data network 125 and access network 105, or between MEC platforms 115 and access network 105. Core network 120 may include multiple UPFs 330 disposed at various geographic locations. Para. [0017]-Khasnabish discloses computing architectures, such as centralized, distributed, cloud (e.g., elastic, public. Fig. 3, Para. [0041]-Khasnabish logical components {corresponding to virtual component} for implementing an edge slice proxy (ESP) service structure 300 ... user plane function (UPF) 330).
Khasnabish fails to teach the code being mapped to a user account of the cellular network operator with the cloud computing platform.
However, Shevade teaches the code being mapped to a user account of the cellular network operator with the cloud computing platform (Fig. 4, Para. [0121]-Shevade discloses to create the subnet in the network slice 470 from a customer account associated with the virtual private cloud network 107. Para. [0101]-Shevade discloses the cellular topology 442 includes an arrangement of a plurality of cells for a customer that takes into account reuse of frequency spectrum where possible given the location of the cells. Para. [0082]-Shevade discloses Customers can connect to an AZ of the cloud provider network 203 via a publicly accessible network (e.g., the Internet, a cellular communication network)).
Shevade is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with extending cloud-based virtual private networks to radio-based networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal and Krishan to incorporate the teachings of Shevade on virtual routers, with a motivation to implement the routers as a code on the platform for users, and guarantee higher throughput, (Shevade, Para. [0001]).
Claims 8-9 is rejected under 35 U.S.C. 103 as being unpatentable over Khasnabish et al. (US 20220103985 A1), hereinafter referenced as Khasnabish, in view of Grewal et al. (US 20240031908 A1), hereinafter referenced as Grewal, in view of Krishan et al. (US 20210204200 A1), hereinafter referenced as Krishan, and further in view of LOHMAR et al. (US 20210274266 A1), hereinafter referenced as Lohmar.
Regarding claim 8, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 1.
Khasnabish fails to teach the cellular network cluster is a logical national data center (NDC) of the hybrid cloud cellular network.
However, Lohmar teaches the cellular network cluster is a logical national data center (NDC) of the hybrid cloud cellular network (Para. [0136]-Lohmar discloses network architecture ... may be virtualized as set forth above and architected in a cloud-computing environment comprising a shared pool of configurable virtual resources ..., as well as platforms and infrastructure of NDCs {National Data Centers}, RDCs {Regional Data Ceters}. Para. [0047]-Lohmar discloses wireless communication network (e.g., a cellular network, a proprietary data communication network, a corporate-wide wireless network, etc.)).
Lohmar is considered to be analogous to the claimed invention because it is in the same field of communication networks, dealing with network architecture, system, devices and methods for facilitating low latency media ingestion and distribution using reliable multicast over one or more fixed networks, wireless networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal and Krishan to incorporate the teachings of Lohmar on cellular network cluster, with a motivation for logical NDC, and guarantee reducing the overall end-to-end delay so that the media as viewed by the end consumer is as close as possible in time to reality, (Lohmar, Para. [0005]).
Regarding claim 9, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 1.
Khasnabish fails to teach the cellular network cluster is a logical regional data center (RDC) of the hybrid cloud cellular network.
However, Lohmar teaches the cellular network cluster is a logical regional data center (RDC) of the hybrid cloud cellular network (Para. [0136]-Lohmar discloses network architecture ... may be virtualized as set forth above and architected in a cloud-computing environment comprising a shared pool of configurable virtual resources ..., as well as platforms and infrastructure of NDCs {National Data Centers}, RDCs {Regional Data Ceters}. Para. [0047]-Lohmar discloses wireless communication network (e.g., a cellular network, a proprietary data communication network, a corporate-wide wireless network, etc.)).
Lohmar is considered to be analogous to the claimed invention because it is in the same field of communication networks, dealing with network architecture, system, devices and methods for facilitating low latency media ingestion and distribution using reliable multicast over one or more fixed networks, wireless networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal and Krishan to incorporate the teachings of Lohmar on cellular network cluster, with a motivation for logical RDC, and guarantee reducing the overall end-to-end delay so that the media as viewed by the end consumer is as close as possible in time to reality, (Lohmar, Para. [0005]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Khasnabish et al. (US 20220103985 A1), hereinafter referenced as Khasnabish, in view of Grewal et al. (US 20240031908 A1), hereinafter referenced as Grewal, in view of Krishan et al. (US 20210204200 A1), hereinafter referenced as Krishan, and further in view of Hu et al. (US 20210044567 A1), hereinafter referenced as Hu.
Regarding claim 10, Khasnabish in view of Grewal and Krishan teaches the hybrid cloud cellular network of claim 1.
Khasnabish further teaches a second cellular network cluster comprising a second plurality of network functions, wherein the second cellular network cluster is implemented on the cloud computing platform, the second cellular network cluster comprising: the second virtual router (Para. [0045]-Khasnabish discloses UPF 330 performs packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling. UPF 220 may act as a router and a gateway between core network 120 and an external data network 125 and may forward session data between data network 125 and access network 105, or between MEC platforms 115 and access network 105. Core network 120 may include multiple UPFs 330 disposed at various geographic locations. Para. [0017]-Khasnabish discloses computing architectures, such as centralized, distributed, cloud (e.g., elastic, public. Fig. 3, Para. [0041]-Khasnabish logical components {corresponding to virtual component} for implementing an edge slice proxy (ESP) service structure 300 ... user plane function (UPF) 330),
the second virtual router is configured to: receive the data packet from the virtual router via the cloud computing platform (Para. [0017]-Khasnabish discloses network device may be implemented according to various computing architectures, such as centralized, distributed, cloud (e.g., elastic, public, private, hybrid, etc.). Para. [0045]-Khasnabish discloses UPF 330 performs packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling. UPF 220 may act as a router and a gateway between core network 120 and an external data network 125 and may forward session data between data network 125 and access network 105, or between MEC platforms 115 and access network 105. Core network 120 may include multiple UPFs 330 disposed at various geographic locations);
Khasnabish fails to teach reformat the received data packet; and output the reformatted received data packet to the second cellular network cluster.
However, Hu teaches reformat the received data packet (Para. [0116]-Hu discloses the data label agent 202 in the classifier 104 may, in response to receiving the packet from a further data center, determine a further label for the packet, the further label indicating a format of the packet associated with the further data center. The further label may be a data format label 330 in the example of FIG. 3. In some embodiments, the classifier 104 may transmit the packet to the SSC in association with the further label. Para. [0006]-Hu discloses transmitting the packet to the selected security service chain in association with the at least one label, the packet being processed by the ordered set of security functions in the security service chain); and
output the reformatted received data packet to the second cellular network cluster (Para. [0116]-Hu discloses the data label agent 202 in the classifier 104 may, in response to receiving the packet from a further data center, determine a further label for the packet, the further label indicating a format of the packet associated with the further data center. The further label may be a data format label 330 in the example of FIG. 3. In some embodiments, the classifier 104 may transmit the packet to the SSC in association with the further label. Para. [0006]-Hu discloses transmitting the packet to the selected security service chain in association with the at least one label, the packet being processed by the ordered set of security functions in the security service chain).
Hu is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with method, apparatus, and computer readable medium for providing a security service for a data center.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal and Krishan to incorporate the teachings of Hu on data packet, with a motivation to format received data packet, and guarantee security service for a data center, (Hu, Para. [0005]).
Claims 12-14 is rejected under 35 U.S.C. 103 as being unpatentable over Khasnabish et al. (US 20220103985 A1), hereinafter referenced as Khasnabish, in view of Hu et al. (US 20210044567 A1), hereinafter referenced as Hu, and further in view of Grewal et al. (US 20240031908 A1), hereinafter referenced as Grewal.
Regarding claim 12, Khasnabish a method for implementing an overlay network on a public cloud computing platform (Para. [0017]-Khasnabish discloses computing architectures, such as centralized, distributed, cloud (e.g., elastic, public, private, hybrid, etc.), edge, fog, and/or another type of computing architecture, and may be incorporated into various types of network architectures (e.g., software defined network (SDN), virtual network, logical network, network slice, overlay), the method comprising:
creating a plurality of virtual routers executed at different cloud computing regions of the public cloud computing platform (Para. [0045]-Khasnabish discloses UPF 330 performs packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling. UPF 220 may act as a router and a gateway between core network 120 and an external data network 125 and may forward session data between data network 125 and access network 105, or between MEC platforms 115 and access network 105. Core network 120 may include multiple UPFs 330 disposed at various geographic locations. Para. [0017]-Khasnabish discloses computing architectures, such as centralized, distributed, cloud (e.g., elastic, public. Fig. 3, Para. [0041]-Khasnabish logical components {corresponding to virtual component} for implementing an edge slice proxy (ESP) service structure 300 ... user plane function (UPF) 330. Fig. 2, Para. [0033]-Khasnabish discloses Network links 222 may include, for example, mobile broadband links between an ITD 210 and one or more local/regional MEC platforms 115. Similarly, network links 224 may include, for example, mobile broadband links between RBD 215 and one or more local/regional MEC platforms 115);
receiving a data packet by the first virtual router of the plurality of virtual routers (Para. [0045]-Khasnabish discloses UPF 330 performs packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling. UPF 220 may act as a router and a gateway between core network 120 and an external data network 125 and may forward session data between data network 125 and access network 105, or between MEC platforms 115 and access network 105. Core network 120 may include multiple UPFs 330 disposed at various geographic locations);
receiving the formatted data packet by the second virtual router of the plurality of virtual routers located at the different cloud computing region (Para. [0045]-Khasnabish discloses UPF 330 performs packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling. UPF 220 may act as a router and a gateway between core network 120 and an external data network 125 and may forward session data between data network 125 and access network 105, or between MEC platforms 115 and access network 105. Core network 120 may include multiple UPFs 330 disposed at various geographic locations. Fig. 2, Para. [0033]-Khasnabish discloses Network links 222 may include, for example, mobile broadband links between an ITD 210 and one or more local/regional MEC platforms 115. Similarly, network links 224 may include, for example, mobile broadband links between RBD 215 and one or more local/regional MEC platforms 115),
Khasnabish fails to teach the plurality of virtual routers function as an overlay on the public cloud computing platform's underlying native routing architecture; a first virtual router and a second virtual router of the plurality of virtual routers are located within different cloud computing regions of the public cloud computing platform; the first virtual router causes the formatted data packet to be transmitted to the second virtual router.
However, Grewal teaches the plurality of virtual routers function as an overlay on the public cloud computing platform's underlying native routing architecture (Para. [0169]-Grewal discloses virtual routers implement each virtual network using an overlay network. Fig. 4, Para. [0107]-Grewal discloses having learned the routes, whether by routing protocols or from SDN controller 70, cRPD 324 can selectively program … overlay routes to vRouter 206A (via vRouter agent 314). Para. [0149]-Grewal discloses the system supports VRF functionality where overlay and underlay routes remain separated in different VRFs. (See also Para. [0219-0230]));
a first virtual router and a second virtual router of the plurality of virtual routers are located within different cloud computing regions of the public cloud computing platform (Figs. 1-2, Para. [0081]-Grewal discloses each of the VRFs 212A-212K has a corresponding virtual network interface to DU 22A. Each of the virtual network interfaces of DU 22A may thus be mapped into a different L3VPN in vCSR 20A {virtual Cell Site Router} ... vCSR 20A is introduced as a cloud-native router into the data path to, e.g., support the F1 interfaces to CUs 213A-213K that may be executing in edge or regional data center sites. Para. [0061]-Grewal discloses CUs 13 are shown in FIG. 1 as located at a regional data center, typically within 40 km of the supported DUs 22);
the first virtual router causes the formatted data packet to be transmitted to the second virtual router (Figs. 1-4, Para. [0080]-Grewal discloses Virtualized cell site router 20A includes a virtual router forwarding plane (vRouter) 206A configured with VRFs 212A-212K (collectively, “VRFs 212”) for respective network slices implemented with respective L3VPNs, which vCSR 20A and routers 204A-204B implement using tunnels 231A-231K connecting VRFs 212 to VRFs 210A-210K on routers 204A-204B. Fig. 13, Para. [0213]-Grewal discloses all pod connectivity is implemented using virtual routers ... Network controller 1324 may implement the network solution in the computing infrastructure by, e.g., configuring the one or more virtual network and virtual network interfaces in the virtual routers. Para. [0068]-Grewal discloses vCSRs 20 may operate as provider edge (PE) routers for networks transporting layer 3 packets among DUs 22, CUs 13, and mobile core network 7. Para. [0097]-Grewal discloses (vRouter 206A alone) may provide fast path data packet handling by vRouter 206A as well as full control plane routing functionality for virtualized cell site router 20A. Para. [0181-0184]-Grewal discloses Virtual router 206A implements one or more virtual routing and forwarding instances (VRFs) 222A-222B for respective virtual networks for which virtual router 206A operates as respective tunnel endpoints ... If the destination is another virtual network endpoint executing on computing device 800, virtual router 206A routes the packet to the appropriate one of virtual network interfaces 212, 213. (See also Figs. 7-8, Para. [0009-0012, 0160, 0173])).
Khasnabish and Grewal are considered to be analogous to the claimed invention because they are in the same field of communication network, dealing with virtualized computing infrastructure and, more specifically, to a containerized router.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish to incorporate the teachings of Grewal on cloud networks, with a motivation for virtual routers to virtual router communication, and guarantee improved network management, (Grewal, Para. [0008]).
Khasnabish fails to teach formatting the received data packet for transmission to a different cloud computing region of the public cloud computing platform by applying a label that defines a path to a network function (NF) at the different cloud computing region; … reformatting the received formatted data packet by the second virtual router for use by the NF executed at the different cloud computing region of the public cloud computing platform.
However, Hu teaches formatting the received data packet for transmission to a different cloud computing region of the public cloud computing platform by applying a label that defines a path to a network function (NF) at the different cloud computing region (Para. [0116]-Hu discloses the data label agent 202 in the classifier 104 may, in response to receiving the packet from a further data center, determine a further label for the packet, the further label indicating a format of the packet associated with the further data center. The further label may be a data format label 330 in the example of FIG. 3. In some embodiments, the classifier 104 may transmit the packet to the SSC in association with the further label. Para. [0006]-Hu discloses transmitting the packet to the selected security service chain in association with the at least one label, the packet being processed by the ordered set of security functions in the security service chain. Figs. 1 and 4, Para. [0030]-Hu discloses data center 101 can provide security protection for data stored into or obtained from the storage system 130. The storage system 130 may include one or more physical storage devices to store the data, which may be distributed geographically in the same location or different locations (in the case of cloud based storage). Para. [0037]-Hu discloses Data Service Providers (DSPs) of data centers offer data services (such as cloud based data service) to vertical market through collecting diversity data from various data resources (such as healthcare, public safety, real estate, transportation, and utilities));
reformatting the received formatted data packet by the second virtual router for use by the NF executed at the different cloud computing region of the public cloud computing platform (Para. [0116]-Hu discloses the data label agent 202 in the classifier 104 may, in response to receiving the packet from a further data center, determine a further label for the packet, the further label indicating a format of the packet associated with the further data center. The further label may be a data format label 330 in the example of FIG. 3. In some embodiments, the classifier 104 may transmit the packet to the SSC in association with the further label. Para. [0006]-Hu discloses transmitting the packet to the selected security service chain in association with the at least one label, the packet being processed by the ordered set of security functions in the security service chain. Para. [0037]-Hu discloses Data Service Providers (DSPs) of data centers offer data services (such as cloud based data service) to vertical market through collecting diversity data from various data resources (such as healthcare, public safety, real estate, transportation, and utilities)).
Hu is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with method, apparatus, and computer readable medium for providing a security service for a data center.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Grewal to incorporate the teachings of Hu on data packet, with a motivation to format received data packet, and guarantee security service for a data center, (Hu, Para. [0005]).
Regarding claim 13, Khasnabish in view of Hu and Grewal teaches the method of claim 12.
Khasnabish further teaches the overlay network functions as part of a 5G New Radio (NR) cellular network that is partially implemented on the public cloud computing platform (Para. [0031]-Khasnabish discloses End device 130 may support one or multiple RATs (e.g., 4G, 5G, and/or future generation RAT) and various portions of the radio spectrum (e.g., multiple frequency bands, multiple carrier frequencies, licensed, unlicensed, mm wave, above mm wave, etc.), various levels and variations of network slicing, DC service, and/or other types of connectivity services. Para. [0017]-Khasnabish discloses network device may be implemented according to various computing architectures, such as centralized, distributed, cloud (e.g., elastic, public, private, hybrid, etc.)).
Regarding claim 14, Khasnabish in view of Hu and Grewal teaches the method of claim 12.
Khasnabish fails to teach each virtual router of the plurality of virtual routers uses generic routing encapsulation (GRE) to create GRE tunnels with other virtual routers of the plurality of virtual routers.
However, Grewal teaches each virtual router of the plurality of virtual routers uses generic routing encapsulation (GRE) to create GRE tunnels with other virtual routers of the plurality of virtual routers (Fig. 2, Para. [0180]-Grewal discloses example tunneling protocols that may be used include IP over Generic Route Encapsulation (GRE), VxLAN, Multiprotocol Label Switching (MPLS) over GRE. Para. [0110]-Grewal discloses vRouter agent 314 provides a generic interface 340 .... This generic interface 340 may be implemented by any controller, routing protocol process, or other agent because it relies on gRPC).
Grewal is considered to be analogous to the claimed invention because it is in the same field of communication network, dealing with virtualized computing infrastructure and, more specifically, to a containerized router.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Khasnabish in view of Hu to incorporate the teachings of Grewal on virtual routers, with a motivation for the routers to use generic routing encapsulation, and guarantee improved network management, (Grewal, Para. [0008]).
Response to Arguments
Applicant's Arguments/Remarks, filed on 12/18/2025, with respect to the 35 USC § 103 rejection of claims 1-14 have been fully considered. Applicant’s arguments are not persuasive.
In the remarks, on page 7, Lines [9-13], Applicant argues that, “as amended, these claim recitations require that the two virtual routers function on top of a cloud computing platform 's underlying native routing architecture. Further, the routing performed between the two virtual routers is performed between separate cloud computing regions of the same cloud computing platform. The art, regardless of how combined, fails to show such an arrangement.”
However, Grewal teaches the virtual router and the second virtual router are configured to function as an overlay on the cloud computing platform's underlying native routing architecture (Para. [0169]-Grewal discloses virtual routers implement each virtual network using an overlay network. Fig. 4, Para. [0107]-Grewal discloses having learned the routes, whether by routing protocols or from SDN controller 70, cRPD 324 can selectively program … overlay routes to vRouter 206A (via vRouter agent 314). Para. [0149]-Grewal discloses the system supports VRF functionality where overlay and underlay routes remain separated in different VRFs. (See also Para. [0219-0230])); the virtual router and the second virtual router are located within different cloud computing regions of the cloud computing platform (Figs. 1-2, Para. [0081]-Grewal discloses each of the VRFs 212A-212K has a corresponding virtual network interface to DU 22A. Each of the virtual network interfaces of DU 22A may thus be mapped into a different L3VPN in vCSR 20A {virtual Cell Site Router} ... vCSR 20A is introduced as a cloud-native router into the data path to, e.g., support the F1 interfaces to CUs 213A-213K that may be executing in edge or regional data center sites. Para. [0061]-Grewal discloses CUs 13 are shown in FIG. 1 as located at a regional data center, typically within 40 km of the supported DUs 22).
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 OLADIRAN GIDEON OLALEYE whose telephone number is (571)272-5377. The examiner can normally be reached Monday - Friday: 07:30am - 05:30pm to.
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 SPE, NICHOLAS A. JENSEN can be reached on (571) 270-5443. 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.
/OO/
Examiner, Art Unit 2472
/NICHOLAS A JENSEN/Supervisory Patent Examiner, Art Unit 2472