CTNF 18/951,444 CTNF 90960 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 correspondence is in response to the application number 18/951444 filed on November 18, 2024. Claims 1 – 20 are pending. Authorization for Internet Communications The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03): “Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.” Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439 . Information Disclosure Statement 06-52 The information disclosure statement (IDS) submitted on February 11, 2025 was filed on or after the mailing date of the application on November 18, 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Double Patenting Analysis The applicant has filed application 18/791002 which are co-pending with the instant application and names the assignee in common, and is directed to similar subject matter as the instant application. At this time of examination, the instant application appears to claim only subject matter directed to an invention that is independent and distinct from that claimed in the co-pending application. Therein, no non-statutory Double Patenting rejections have been applied. The applicant is required to maintain a clear line of demarcation between the applications during prosecution, as the Double Patenting analysis can be revisited if the claims of the instant application and the co-pending application converge to claiming the same subject matter. The applicant may wish to proactively file a terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) to overcome possible future Double Patenting rejections 35 USC § 101 Analysis – Judicial Exception 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception. . The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement in the field of core networking, and particularly one involving both a central core network system and one or more compact core systems. The claimed invention comprises three embodiments directed to a custom compact core system which only includes the necessary network functions and databases for a pre-defined purpose or use case defined by an owner of a compact core system. A first embodiment is a method implemented in a communication network by a compact core system for managing communications between the compact core system and an external system is disclosed. The method comprises receiving, by a compact access and mobility management function (AMF) at the compact core system, a session establishment request from a device to initiate a data session with an external system, authenticating, by the compact AMF, the device using a local unified data management (UDM) at the compact core system, and forwarding, by the compact AMF, the session establishment request to a compact session management function (SMF) at the compact core system. The method further comprises evaluating, by the compact SMF, one or more routing policies associated with the device and provisioned at the compact core system to determine whether the data session is permitted, and to determine parameters for the data session when the data session is permitted, wherein the one or more routing policies indicate whether the data session with the external system is permitted, and obtaining, by the compact SMF, one or more policy rules associated with the device and provisioned at the compact core system, in which the one or more policy rules define at least one of an allocation or management of network resources for forwarding data packets for the data session. The method further comprises configuring, by the compact SMF, a user plane function (UPF) at the compact core system to establish the data session based on the one or more routing policies and one or more policy rules, establishing, by the compact SMF using a network slice selection function (NSSF) at the compact core system, a network slice for forwarding the data packets associated with the data session, and forwarding, by the UPF over the network slice, the data packets associated with the data session between the device and the external system. A second embodiment is a method implemented in a communication network between a compact core system and a central core network system for configuring and updating the compact core system is disclosed. The method comprises establishing, using a user plane function (UPF) at the compact core system, a connection between a compact access and mobility management function (AMF) at the compact core system and a central AMF at the central core network system over a network slice, and obtaining, by the central AMF, a routing policy associated with a plurality of different devices that are registered with the compact core system, in which the routing policy indicates whether data from a first device is permitted to be transmitted to the central core network system, and when the data from the first device is permitted to be transmitted to the central core network system, the routing policy comprises one or more rules for transmitting the data between the first device and the central core network system. The method further comprises transmitting, by the central AMF, the routing policy to the compact AMF over the network slice using the UPF, storing, by the compact AMF, the routing policy in a data store of the compact core system to configure the compact core system according to the routing policy, obtaining, by the central AMF, an update to the routing policy based on at least one of a request from an owner of the compact core system, a current network condition, or an update to a policy rule associated with the routing policy, transmitting, by the central AMF, the update to the routing policy to the compact AMF over the network slice using the UPF, and updating, by the compact AMF, the routing policy by re-configuring the compact core system according to the update to the routing policy. A third embodiment is a compact core system that comprises one or more memories, one or more processors, a compact access and mobility management function (AMF), and a compact session management function (SMF). The one or more memories comprise a first data store configured to maintain a plurality of routing policies associated with a plurality of different devices that are registered with the compact core system, wherein each of the routing policies indicates rules for transmitting data to one or more other systems, and a second data store configured to maintain a plurality of policy rules associated with the different devices that are registered with the compact core system, wherein the policy rules are based on a subscription of the different devices and define at least one of an allocation or management of network resources for transmitting data between a first device and a central core network system. The compact AMF comprises instructions stored in the one or more memories, which when executed by the one or more processors, cause the compact AMF to be configured to establish a secure connection with a central AMF at a central core network system over a network slice using a user plane function (UPF) at the compact core system. The compact SMF comprises instructions stored in the one or more memories, which when executed by the one or more processors, cause the compact SMF to be configured to establish a data session with the first device that is registered with the compact core system. The compact AMF is further configured to obtain the data either from the first device or based on the first device, and transmit the data to the central AMF over the network slice using the UPF based on a routing policy of the routing policies indicating that the data is permitted to be transmitted and stored at the central core network system. The ordered steps of the claim language impose meaningful limits on the scope of the claims, and provides a useful improvement to the compact core by producing a more resource effective and lightweight compact core system. Therein the claimed invention is statutory under 35 USC 101. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-21-aia AIA Claim s 1 – 6, 8 – 10, and 14 - 20 are rejected under 35 U.S.C. 103 as being un-patentable over Li et al. (U.S. 2023/0337121 A1; herein referred to as LI) in view of Chun et al. (U.S. 2025/0184942 A1; herein referred to as Chun) . In regard to claim 1, Li teaches A method implemented in a communication network by a compact core system for managing communications between the compact core system and an external system (see Fig. 1 ¶ [0014] “ . . . an enterprise may manage its own Radio Access Network (RAN) of base stations and/or a core network to manage the RAN and provide connectivity between the RAN and other networks. The enterprise may lease devices, network infrastructure, cloud center resources, and/or software components from a provider of communication services to implement a private RAN and/or a private core network for UE devices used by the employees and/or customers associated with the enterprise. An administrator may configure the private RAN and/or private core network for a set of network slices . . .” ) , wherein the method comprises: receiving, by a compact access and mobility management function (AMF) at the compact core system, a session establishment request from a device to initiate a data session with an external system (see Fig. 2 ¶ ¶ [0032-0034] “ . . . FIG. 2 illustrates a system 200 that includes exemplary components of private core network 150 in the context of environment 100 according to an implementation described herein. As shown in FIG. 2, system 200 may include UE device 110, gNodeB 210, private core network 150, and PDN 160. gNodeB 210 (corresponding to base station 120) may include devices (e.g., base stations) and components that enable UE device 110 to connect to private core network 150 via private RAN 130 using 5G NR RAT. For example, gNodeB 210 may service one or more cells, with each cell being served by a wireless transceiver with an antenna array configured for mm-wave wireless communication. gNodeB 210 may communicate with AMF 220 using an N2 interface 212 and communicate with UPF 230 using an N3 interface 214. In some implementations, gNodeB 210 may receive one or more network slicing rules that assign applications to network slices and apply the one or more network slicing rules to communication sessions. Core network 150 may include an Access and Mobility Function (AMF) 220, , a User Plane Function (UPF) 230, a Session Management Function (SMF) 240, an Application Function (AF) 250, a Unified Data Management (UDM) 252, a Policy Control Function (PCF) 254, a Charging Function (CHF) 256, a Network Repository Function (NRF) 258, a Network Exposure Function (NEF) 260, a Network Slice Selection Function (NSSF) 262, an Authentication Server Function (AUSF) 264, a 5G Equipment Identity Register (EIR) 266, a Network Data Analytics Function (NWDAF) 268, a Short Message Service Function (SMSF) 270, a Security Edge Protection Proxy (SEPP) 272, and a Non-3GPP Inter-Working Function (N3IWF) 274. . . . “) ; authenticating, by the compact AMF (see ¶ [0036] “ . . . AMF 220 may perform registration management, connection management, reachability management, mobility management, lawful intercepts, Short Message Service (SMS) transport between UE device 110 and SMSF 270, session management messages transport between UE device 110 and SMF 240, access authentication and authorization, location services management, functionality to support non-3GPP access networks, and/or other types of management processes. AMF 220 may be accessible by other function nodes via an Namf interface 222. . . .”) , the device using a local unified data management (UDM) at the compact core system (see ¶ [0040] “ . . . UDM 252 may maintain subscription information for UE devices 110, manage subscriptions, generate authentication credentials, handle user identification, perform access authorization based on subscription data, perform network function registration management, maintain service and/or session continuity by maintaining assignment of SMF 240 for ongoing sessions, support SMS delivery, support lawful intercept functionality, and/or perform other processes associated with managing user data. UDM 252 may be accessible via a Nudm interface 253. . . . “) . ; forwarding, by the compact AMF, the session establishment request to a compact session management function (SMF) at the compact core system (see ¶ [0038] “ . . . SMF 240 may perform session establishment, session modification, and/or session release, perform IP address allocation and management, . . .”) ; evaluating, by the compact SMF, one or more routing policies associated with the device and provisioned at the compact core system to determine whether the data session is permitted (see ¶ [0038] “ . . . SMF may receive one or more network slicing rules that assign applications to network slices and may configure UPF 230 to implement the one or more network slicing rules. . . .:) , and to determine parameters for the data session when the data session is permitted (see ¶ [0019] “ . . . detecting that a communication session in a private cellular wireless network is associated with an application may include determining that the data units associated with the communication session satisfy a data unit parameter criterion. For example, application data units may be encrypted and deep packet/frame inspection may not be able to determine an application ID by analyzing the content of a data unit payload. However, a data unit pattern may be used to determine that data units are associated with an application or to identify a particular application. The data unit parameter criterion may include, for example, a pattern of one uplink data unit to multiple downlink data units, a payload (which is associated with uplink data units) that is greater than an uplink payload threshold, a cumulative payload (which is associated with downlink data units) is greater than a downlink payload threshold, and/or another type of data unit parameter criterion indicative of data units associated with an application . . .”) , wherein the one or more routing policies indicate whether the data session with the external system is permitted (see ¶ [0039] “ . . . AF 250 may provide services associated with a particular application, such as, for example, an application for influencing traffic routing, an application for accessing NEF 260, an application for interacting with a policy framework for policy control, and/or other types of applications. AF 250 may be accessible via an Naf interface 251, also referred to as an NG5 interface. In some implementations, AF 250 may correspond to, or interface with orchestration device 170 and/or application server 180. . . .”) ; obtaining, by the compact SMF, one or more policy rules associated with the device and provisioned at the compact core system (see ¶ [0041] “ . . . PCF 254 may support policies to control network behavior, provide policy rules to control plane functions (e.g., to SMF 240), access subscription information relevant to policy decisions, perform policy decisions, and/or perform other types of processes associated with policy enforcement. . . .”) , wherein the one or more policy rules define at least one of an allocation or management of network resources (e.g. slicing rules) for forwarding data packets for the data session (see ¶ [0041] “ . . . NEF 260 may expose capabilities and events to other NFs, including 3.sup.rd party NFs, AFs, edge computing NFs, and/or other types of NFs. Furthermore, NEF 260 may secure provisioning of information from external applications to private core network 150, translate information between private core network 150 and devices/networks external to private core network 150, support a Packet Flow Description (PFD) function, and/or perform other types of network exposure functions. NEF 260 may be accessible via Nnef interface 261. In some implementations, orchestration device 170 may interact with SMF 240 and/or gNodeB 210 via NEF 260 by, for example, providing one or more slicing rules to SMF 240 and/or gNodeB 210 via NEF 260. . . . “). ; configuring, by the compact SMF, a user plane function (UPF) at the compact core system to establish the data session based on the one or more routing policies and one or more policy rules (see ¶¶ [0016-0017] “ . . . to systems and methods for automatic application-level network slicing over private cellular networks. The systems and methods may include a rule engine that automatically detects an application associated with a communication session and assigns the communication session to a network slice based on a slicing rule associated with the application. A network device, such as a Fourth Generation (4G) eNodeB, a 4G Packet Data Network Gateway (PGW), a 5G gNodeB, a 5G Session Management Function, a 5G User Plane Function, and/or another type of network device in a RAN or core network, may be configured to receive, from an orchestration device, a network slicing rule that assigns a particular application to a particular network slice and stores the network slicing rule in a database associated with a traffic classifier. The network slicing rule may, for example, assign applications of different types to different network slices and/or assign different applications of the same type to different network slices. The network device may be further configured to detect that a communication session in a private cellular wireless network is associated with an application, determine that data units associated with the communication session match the network slicing rule, classify the communication session to a network slice based on the network slicing rule, and assign the data units associated with the communication session to the network slice. A data unit may correspond to a segment, a packet, or a frame. Assigning the data units to the network slice may include assigning the data units to a particular CoS, assigning the data units to a logical network associated with the network device, transferring or routing the data units to a particular device in the private core network or another network associated with the private core network, and/or performing another type of action to assign the data units to the network slice. For example, in a 4G core network, network slicing may not be implemented and may be emulated by assigning a particular CoS, such as a QCI, to the communication session based on the detected application . . .” see Fig. 5 ¶¶ [0067-0068] “ . . . FIG. 5 is a diagram illustrating exemplary components of a device 500 that may be included in private core network 150 or private RAN 130, such as, for example, gNodeB 210, UPF 230, SMF 240, eNodeB 310, SGW 330, PGW 340, and/or another component of private RAN 130 or private core network 150. The components of system 500 may be implemented, for example, via processor 420 executing instructions from memory 430. Alternatively, some or all of the components of system 500 may be implemented via hard-wired circuitry. As shown in FIG. 5, device 500 may include an orchestrator device interface 510, a rule engine 520, an application database (DB) 530, a slicing rules DB 540, a traffic classifier 550, interfaces 560-A and 560-B, a data unit probe 570, and a traffic director 580. Orchestrator device interface 510 may be configured to communicate with orchestrator device 170. For example, orchestrator device interface 510 may be configured to receive a set of network slicing rules, and/or information relating to applications, from orchestrator device 170. Rule engine 520 may be configured to receive the information from orchestrator device interface 510 and store the information in application DB 530 and/or slicing rules DB 540.) ; establishing, by the compact SMF using a network slice selection function (NSSF) at the compact core system, a network slice for forwarding the data packets associated with the data session (see ¶ [0044] “ . . . NSSF 262 may select a set of network slice instances to serve a particular UE device 110, determine network slice selection assistance information (NSSAI) or a Single-NSSAI (S-NSSA), determine a particular AMF 220 to serve a particular UE device 110, and/or perform other types of processing associated with network slice selection or management. NSSF 262 may be accessible via Nnssf interface 263. In some implementations, SMF 240 and/or gNodeB 210 may provide network slice selection information, which may be determined based on a detected application, for a communication session, and a query to NSSF 262. NSSF 262 may select a network slice for the communication session based on the received information provided in the query . . .”) ; and forwarding, by the UPF over the network slice, the data packets associated with the data session between the device and the external system (see Fig. 8, ¶ [0087] “ . . . FIG. 8 illustrates an exemplary signal flow 800 according to an implementation described herein. As shown in FIG. 8, signal flow 800 may include orchestration device 170 providing a set of network slicing rules in private core network 150 and/or private RAN 130 to SMF 240 via NEF 260 (signals 810 and 812). At a later time, UE device 110 may perform a Protocol Data Unit (PDU) session establishment procedure with SMF 240 and UPF 230 via gNodeB 210 (block 820) to communicate with application server 180. UE device 110 may begin to exchange data traffic with application server 180 via gNodeB 210 and UPF 230 using the established communication session (signals 830, 832, and 834). . . .”) Li fails to explicitly teach , However Chun teaches to determine whether the data session is permitted (see Chun ¶ [0062] “ . . . The AMF 312 may receive, from UE 301, non-access stratum (NAS) messages transmitted in accordance with NAS protocol. NAS messages relate to communications between UE 301 and the core network. Although NAS messages may be relayed to AMF 312 via AN 302, they may be described as communications via the N1 interface. NAS messages may facilitate UE registration and mobility management, for example, by authenticating, identifying, configuring, and/or managing a connection of UE 301. NAS messages may support session management procedures for maintaining user plane connectivity and quality of service (QOS) of a session between UE 301 and DN 309. If the NAS message involves session management, AMF 312 may send the NAS message to SMF 314. NAS messages may be used to transport messages between UE 301 and other components of the core network (e.g., core network components other than AMF 312 and SMF 314). The AMF 312 may act on a particular NAS message itself, or alternatively, forward the NAS message to an appropriate core network function (e.g., SMF 314, etc.) . . .”). It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for assigning device sessions in a wireless network to a particular network slice based on routing policies determined by rules in the private core, as taught by Chun, into a method and system for managing private core networks that determine session authority and service authorization, using network slicing rules as controlled by the private core, as taught by Li. Such incorporation provides network slice assignments based on multiple polices and network requirements of the session. In regard to claim 2, the combination of Li and Chun teaches wherein a policy rule of the one or more policy rules indicates that the data packets associated with the data session are to be forwarded over the network slice that meets predefined quality of service (QoS) parameters (see Li Fig. 6B ¶¶ [0080-0081] “ . . . FIG. 6B illustrates exemplary components of slicing rules DB 540 according to an implementation described herein. As shown in FIG. 6B, slicing rules DB 540 may include application records 650. Each application record 650 may store network slicing information relating to a particular application. Application record 650 may include an application ID field 660, an application type field 670, and a network slice field 680. Application ID field 660 may store an ID associated with an application. Application type field 670 may store information identifying an application type associated with the application. Network slice field 680 may store network slice information and/or CoS information to which the application has been assigned. For example, network slice field 680 may store a network slice ID (e.g., S-NSSAI, etc.), an ID associated with a logical network, device, and/or path in private RAN 130 and/or private core network 150, a CoS ID associated with a particular CoS guaranteed by private RAN 130 and/or private core network 150, a priority value managed by private RAN 130 and/or private core network 150, and/or other types of information that may be used by private RAN 130 and/or private core network 150 to select a network slice or provide a particular CoS. . . . “) In regard to claim 3, the combination of Li and Chun teaches wherein after evaluating the one or more routing policies and obtaining the one or more policy rules (see Li ¶ [0041] as described for the rejection of claim 1 and is incorporated herein) , the method further comprises updating a session context to indicate at least one of addresses of the device and external system, quality of service (QoS) parameters for the data session, service flow descriptions for the data session, the one or more routing policies, or the one or more policy rules (see Chen ¶¶ [0061-0063] “ . . . he AMF 312 depicted in FIG. 3 may control UE access to the core network. The UE 301 may register with the network via AMF 312. It may be necessary for UE 301 to register prior to establishing a PDU session. The AMF 312 may manage a registration area of UE 301, enabling the network to track the physical location of UE 301 within the network. For a UE in connected mode, AMF 312 may manage UE mobility, for example, handovers from one AN or portion thereof to another. For a UE in idle mode, AMF 312 may perform registration updates and/or page the UE to transition the UE to connected mode. The AMF 312 may receive, from UE 301, non-access stratum (NAS) messages transmitted in accordance with NAS protocol. NAS messages relate to communications between UE 301 and the core network. Although NAS messages may be relayed to AMF 312 via AN 302, they may be described as communications via the N1 interface. NAS messages may facilitate UE registration and mobility management, for example, by authenticating, identifying, configuring, and/or managing a connection of UE 301. NAS messages may support session management procedures for maintaining user plane connectivity and quality of service (QOS) of a session between UE 301 and DN 309. If the NAS message involves session management, AMF 312 may send the NAS message to SMF 314. NAS messages may be used to transport messages between UE 301 and other components of the core network (e.g., core network components other than AMF 312 and SMF 314). The AMF 312 may act on a particular NAS message itself, or alternatively, forward the NAS message to an appropriate core network function (e.g., SMF 314, etc.). The SMF 314 depicted in FIG. 3 may establish, modify, and/or release a PDU session based on messaging received UE 301. The SMF 314 may allocate, manage, and/or assign an IP address to UE 301, for example, upon establishment of a PDU session. There may be multiple SMFs in the network, each of which may be associated with a respective group of wireless devices, base stations, and/or UPFs. A UE with multiple PDU sessions may be associated with a different SMF for each PDU session. As noted above, SMF 314 may select one or more UPFs to handle a PDU session and may control the handling of the PDU session by the selected UPF by providing rules for packet handling (PDR, FAR, QER, etc.). Rules relating to QoS and/or charging for a particular PDU session may be obtained from PCF 320 and provided to UPF 305. . . .”). The motivation to combine Chen with Li is described for the rejection of claim 1 and is incorporated herein. Additionally, Chen provides specific settings and parameters for the session being processed into the private core. In regard to claim 4, the combination of Li and Chen teaches wherein configuring the UPF at the compact core system based on the one or more routing policies and one or more policy rules (see LI Fig. 5 ¶¶ [0067-0068] as described for the rejection of claim 1 and is incorporated herein) comprises at least one of assigning quality of service (QoS) parameters to the UPF, defining routes or next hop destinations for the data packets, or enforcing handling conditions based on the one or more policy rules (see Li ¶¶ [0073-0074] “ . . . interfaces 560 may interface with other devices. For example, for uplink traffic, interface 560-A may receive data units originating from UE device 110 or a previous hop uplink device along the communication path from UE device 110, and interface 560-B may provide the uplink data units to a next hop destination along the communication path to the destination address. Similarly, for downlink traffic, interface 560-B may receive data units from a source device (e.g., application server 180) or a previous hop downlink device along the communication path from the source device and interface 560-A may provide the downlink data units to a next hop destination along the communication path to the destination address. Data unit probe 570 may mirror data units from the data flow and provide the mirrored data units to traffic classifier 550 for classification. Data unit probe 570 may be configured to mirror data units only from communication sessions that have not yet been classified. Traffic director 580 may correspond to a kernel module on the data plane that marks data flows with a classification determined by traffic classifier 550 and/or routes data flows to a different destination based on the classification. For example, traffic director 580 may assign any downlink packets (e.g., from a LAN associated with private core network 150 to private RAN 130) in flow i with QCI 6 based on the above example of the classification <flow: i, AppType: video, QCI: 6>. Thus, traffic director 580 may assign a CoS class to a communication session based on the classification. As another example, traffic director 580 may route the data units for the communication session to a different logical device associated with a particular network slice and/or to a different physical device. For example, traffic director 580 may assign a network slice ID to the communication session and/or direct NSSF 262 to transfer the communication session to the assigned network slice. As another example, a slicing rule may direct data traffic associated with a particular application to MEC device 145 and the communication session may be transferred from a session between UE device 110 and application server 180 to a session between UE device 110 and MEC device 145. . . .”). In regard to claim 5, the combination of Li and Chen teaches wherein establishing the network slice (see Li ¶ [0044] as described for the rejection of claim 1 and is incorporated herein) comprises configuring, by the compact SMF, the UPF with quality of service (QoS) parameters and traffic policies defined for the network slice (see Chen ¶¶ [0286-0289] “ . . . , a first network node (e.g., a MME, a SMF+PGW-C, and/or the like) of the first network system may receive the first message. In response to the first message, the first network node may send a second message to the UE. For example, the second message may indicate at least one of one or more established EPS contexts, one or more default EPS bearers, one or more EPS bearers, and/or or more PDN connections. For example, based on that the UE indicates that the UE supports the feature of the alternative slice (e.g., a feature of a network slice replacement), the first network node may further include into the second message, at least one of an information of an alternative slice, an information associated with the alternative slice and/or the alternative network slice management information. For example, based on the requested (established, allowed) EPS context (of the one or more EPS contexts), based on the requested (established, allowed) EPS bearer (of the one or more EPS bearers), and/or based on the requested (established, allowed) PDN connection (of the one or more PDN connections), the first network system (or the first network node) may determine a network slice (e.g., slice A) associated with at least one of the EPS context, the EPS bearer, and/or the PDN connection. Based on the determined network slice (e.g., slice A), the first network system may determine an alternative network slice (e.g., slice B) for the determined network slice (e.g., slice A). For example, based on the determined alternative network slice (alternative slice), the first network system may determine the alternative slice management information associated with the alternative slice. For example, the second message may comprise at least one of an identifier of the EPS bearer (or the PDN connection, the EPS context), an identifier associated with the network slice (e.g., slice A), and/or an identifier associated with the alternative network slice (e.g., slice B). For example, the second message may be at least one of a Attach accept message, a Service accept messages, a Tracking area update accept message, a Downlink NAS transport message, a Downlink generic NAS transport message, a Activate dedicated EPS bearer context request message, a Activate dedicated EPS bearer context accept message, a Activate default EPS bearer context accept message, a bearer resource allocation accept message, a bearer resource modification accept message, a ESM information accept message, a Modify EPS bearer context accept message, a PDN connectivity accept message, a ESM data transport message and/or the like. For example, the second message may comprise at least one of A EPS attach type: This may indicate a type of requested attach. For example, this may indicate EPS attach, EPS/IMSI attach, EPS emergency attach, and/or the like. A EPS bearer identity: This may indicate an identifier of the EPS bearer. The EPS bearer may uniquely identify traffic flows that receive a common QoS treatment between the UE and a PDN GW (e.g., UPF+PGW-U). For example, the EPS bearer is the level of granularity for bearer level QoS control in the first network system (e.g., EPS, EPC). A EPS QOS: This may indicate QoS parameters for the EPS bearer (associated with the PDN connection, and/or the EPS context). For example, for the EPS bearer, this may indicate a QCI (QOS Class Identifier), a maximum bit rate for uplink, a maximum bit rate for a downlink, and/or the like . . . “). The motivation to combine Chen with Li is described for the rejection of claim 1 and is incorporated herein. Additionally, Chen provides SMF configurations based on particular performance requirements for the session. In regard to claim 6, the combination of Li and Chen teaches wherein the local UDM maintains only subscriber profiles associated with one or more devices that are registered with a central core network system and permitted to use services provided by the compact core system (e.g. slice differentiators for subscribers) (see Chen ¶ [0100] “ . . . The S-NSSAI may further include a slice differentiator (SD) to distinguish between different tenants of a particular slice and/or service type. For example, a tenant may be a customer (e.g., vehicle manufacture, service provider, etc.) of a network operator that obtains (for example, purchases) guaranteed network resources and/or specific policies for handling its subscribers. The network operator may configure different slices and/or slice types, and use the SD to determine which tenant is associated with a particular slice. . . .”). The motivation to combine Chen with Li is described for the rejection of claim 1 and is incorporated herein. Additionally Chen maintains knowledge of what subscribers are matched to a particular network slice. In regard to claim 8, Li teaches A method implemented in a communication network between a compact core system and a central core network system for configuring and updating the compact core system (see Fig. 1 ¶ [0014] “ . . . an enterprise may manage its own Radio Access Network (RAN) of base stations and/or a core network to manage the RAN and provide connectivity between the RAN and other networks. The enterprise may lease devices, network infrastructure, cloud center resources, and/or software components from a provider of communication services to implement a private RAN and/or a private core network for UE devices used by the employees and/or customers associated with the enterprise. An administrator may configure the private RAN and/or private core network for a set of network slices . . .” ) , wherein the method comprises: establishing, using a user plane function (UPF) at the compact core system, a connection between a compact access and mobility management function (AMF) at the compact core system and a central AMF at the central core network system over a network slice (see ¶¶ [0033-0034] “ . . gNodeB 210 (corresponding to base station 120) may include devices (e.g., base stations) and components that enable UE device 110 to connect to private core network 150 via private RAN 130 using 5G NR RAT. For example, gNodeB 210 may service one or more cells, with each cell being served by a wireless transceiver with an antenna array configured for mm-wave wireless communication. gNodeB 210 may communicate with AMF 220 using an N2 interface 212 and communicate with UPF 230 using an N3 interface 214. In some implementations, gNodeB 210 may receive one or more network slicing rules that assign applications to network slices and apply the one or more network slicing rules to communication sessions. Core network 150 may include an Access and Mobility Function (AMF) 220, a User Plane Function (UPF) 230, a Session Management Function (SMF) 240, an Application Function (AF) 250, a Unified Data Management (UDM) 252, a Policy Control Function (PCF) 254, a Charging Function (CHF) 256, a Network Repository Function (NRF) 258, a Network Exposure Function (NEF) 260, a Network Slice Selection Function (NSSF) 262, an Authentication Server Function (AUSF) 264, a 5G Equipment Identity Register (EIR) 266, a Network Data Analytics Function (NWDAF) 268, a Short Message Service Function (SMSF) 270, a Security Edge Protection Proxy (SEPP) 272, and a Non-3GPP Inter-Working Function (N3IWF) 274. . . .”). ; obtaining, by the central AMF, a routing policy associated with a plurality of different devices that are registered with the compact core system (see ¶ [0038] “ . . . SMF may receive one or more network slicing rules that assign applications to network slices and may configure UPF 230 to implement the one or more network slicing rules. . . .:) , wherein the routing policy indicates whether data from a first device is permitted to be transmitted to the central core network system (see ¶ [0039] “ . . . AF 250 may provide services associated with a particular application, such as, for example, an application for influencing traffic routing, an application for accessing NEF 260, an application for interacting with a policy framework for policy control, and/or other types of applications. AF 250 may be accessible via an Naf interface 251, also referred to as an NG5 interface. In some implementations, AF 250 may correspond to, or interface with orchestration device 170 and/or application server 180. . . .”) , wherein when the data from the first device is permitted to be transmitted to the central core network system, the routing policy comprises one or more rules for transmitting the data between the first device and the central core network system (see ¶ [0041] “ . . . PCF 254 may support policies to control network behavior, provide policy rules to control plane functions (e.g., to SMF 240), access subscription information relevant to policy decisions, perform policy decisions, and/or perform other types of processes associated with policy enforcement. NEF 260 may expose capabilities and events to other NFs, including 3.sup.rd party NFs, AFs, edge computing NFs, and/or other types of NFs. Furthermore, NEF 260 may secure provisioning of information from external applications to private core network 150, translate information between private core network 150 and devices/networks external to private core network 150, support a Packet Flow Description (PFD) function, and/or perform other types of network exposure functions. NEF 260 may be accessible via Nnef interface 261. In some implementations, orchestration device 170 may interact with SMF 240 and/or gNodeB 210 via NEF 260 by, for example, providing one or more slicing rules to SMF 240 and/or gNodeB 210 via NEF 260. . . . “) ; transmitting, by the central AMF, the routing policy to the compact AMF over the network slice using the UPF (see Fig. 2, ¶ [0037] “ . . . UPF 230 may maintain an anchor point for intra/inter-RAT mobility, maintain an external Packet Data Unit (PDU) point of interconnect to a particular data network (e.g., PDN 160), perform packet routing and forwarding, perform the user plane part of policy rule enforcement, perform packet inspection, perform lawful intercept, perform traffic usage reporting, perform QoS handling in the user plane, perform uplink traffic verification, perform transport level packet marking, perform downlink packet buffering, forward an “end marker” to a RAN node (e.g., gNodeB 210), and/or perform other types of user plane processes. UPF 230 may communicate with SMF 240 using an N4 interface 232 and connect to PDN 160 using an N6 interface 234. . . .”) ; storing, by the compact AMF, the routing policy in a data store of the compact core system to configure the compact core system according to the routing policy (see ¶ [0016] “ . . . systems and methods for automatic application-level network slicing over private cellular networks. The systems and methods may include a rule engine that automatically detects an application associated with a communication session and assigns the communication session to a network slice based on a slicing rule associated with the application. A network device, such as a Fourth Generation (4G) eNodeB, a 4G Packet Data Network Gateway (PGW), a 5G gNodeB, a 5G Session Management Function, a 5G User Plane Function, and/or another type of network device in a RAN or core network, may be configured to receive, from an orchestration device, a network slicing rule that assigns a particular application to a particular network slice and stores the network slicing rule in a database associated with a traffic classifier. The network slicing rule may, for example, assign applications of different types to different network slices and/or assign different applications of the same type to different network slices. . . .”). ; Li fails to explicitly teach, However Chum teaches obtaining, by the central AMF, an update to the routing policy based on at least one of a request from an owner of the compact core system, a current network condition, or an update to a policy rule associated with the routing policy (see Chun ¶¶ [0096-0097] “ . . . Each network slice may be tailored to network services having different sets of characteristics. For example, slice A may correspond to enhanced mobile broadband (eMBB) service. Mobile broadband may refer to internet access by mobile users, commonly associated with smartphones. Slice B may correspond to ultra-reliable low-latency communication (URLLC), which focuses on reliability and speed. Relative to eMBB, URLLC may improve the feasibility of use cases such as autonomous driving and telesurgery. Slice C may correspond to massive machine type communication (mMTC), which focuses on low-power services delivered to a large number of users. For example, slice C may be optimized for a dense network of battery-powered sensors that provide small amounts of data at regular intervals. Many mMTC use cases would be prohibitively expensive if they operated using an eMBB or URLLC network. If the service requirements for one of the UEs 601 changes, then the network slice serving that UE can be updated to provide better service. Moreover, the set of network characteristics corresponding to eMBB, URLLC, and mMTC may be varied, such that differentiated species of eMBB, URLLC, and mMTC are provided. Alternatively, network operators may provide entirely new services in response to, for example, customer demand . . . “) ; transmitting, by the central AMF, the update to the routing policy to the compact AMF over the network slice using the UPF (see Chun ¶ [0060] “ . . . The UPF 305 may serve as a gateway for user plane traffic between AN 302 and DN 308. The UE 301 may connect to UPF 305 via a Uu interface and an N3 interface (also described as NG-U interface). The UPF 305 may connect to DN 308 via an N6 interface. The UPF 305 may connect to one or more other UPFs (not shown) via an N9 interface. The UE 301 may be configured to receive services through a protocol data unit (PDU) session, which is a logical connection between UE 301 and DN 308. The UPF 305 (or a plurality of UPFs if desired) may be selected by SMF 314 to handle a particular PDU session between UE 301 and DN 308. The SMF 314 may control the functions of UPF 305 with respect to the PDU session. The SMF 314 may connect to UPF 305 via an N4 interface. The UPF 305 may handle any number of PDU sessions associated with any number of UEs (via any number of ANs). For purposes of handling the one or more PDU sessions, UPF 305 may be controlled by any number of SMFs via any number of corresponding N4 interfaces. . . .”) ; and updating, by the compact AMF, the routing policy by re-configuring the compact core system according to the update to the routing policy (see Chun ¶ [0062] “ . . . The AMF 312 may receive, from UE 301, non-access stratum (NAS) messages transmitted in accordance with NAS protocol. NAS messages relate to communications between UE 301 and the core network. Although NAS messages may be relayed to AMF 312 via AN 302, they may be described as communications via the N1 interface. NAS messages may facilitate UE registration and mobility management, for example, by authenticating, identifying, configuring, and/or managing a connection of UE 301. NAS messages may support session management procedures for maintaining user plane connectivity and quality of service (QOS) of a session between UE 301 and DN 309. If the NAS message involves session management, AMF 312 may send the NAS message to SMF 314. NAS messages may be used to transport messages between UE 301 and other components of the core network (e.g., core network components other than AMF 312 and SMF 314). The AMF 312 may act on a particular NAS message itself, or alternatively, forward the NAS message to an appropriate core network function (e.g., SMF 314, etc.) . . .”). The motivation to combine Chun with Li is described for the rejection of claim 1 and is incorporated herein. In regard to claim 9, the combination of Li and Chun teaches wherein the routing policy indicates that data of a first type that is received from the first device registered with the compact core system is to be transmitted to the central core network system over a first predefined network slice having a first set of quality of service (QoS) parameters (see LI Fig. 6B ¶¶ [0080-0081] “ . . . FIG. 6B illustrates exemplary components of slicing rules DB 540 according to an implementation described herein. As shown in FIG. 6B, slicing rules DB 540 may include application records 650. Each application record 650 may store network slicing information relating to a particular application. Application record 650 may include an application ID field 660, an application type field 670, and a network slice field 680. Application ID field 660 may store an ID associated with an application. Application type field 670 may store information identifying an application type associated with the application. Network slice field 680 may store network slice information and/or CoS information to which the application has been assigned. For example, network slice field 680 may store a network slice ID (e.g., S-NSSAI, etc.), an ID associated with a logical network, device, and/or path in private RAN 130 and/or private core network 150, a CoS ID associated with a particular CoS guaranteed by private RAN 130 and/or private core network 150, a priority value managed by private RAN 130 and/or private core network 150, and/or other types of information that may be used by private RAN 130 and/or private core network 150 to select a network slice or provide a particular CoS. . . . “) In regard to claim 10, the combination of Li and Chun wherein an update to the routing policy indicates a second predefined network slice with a second set of QoS parameters (see Chun ¶ [0223] “ . . . the network may determine whether to use an alternative slice for a network slice. For example, the network node (e.g., AMF, SMF, PCF, NSSF, and/or the like) of the network may monitor network resources available for the network slice, may check whether there is a congestion for the network slice, and/or may check whether QoS requirement is met for the network slice. For example, based on that there is shortage of network resource for the slice A, based on that there is a congestion for the slice A, and/or based on that QoS requirement is not met for the slice A, the network node may determine to use an alternative slice (e.g., slice B, slice B1, slice B2, and/or the like) for the slice A. . . .”) , and wherein updating the routing policy comprises storing an updated routing policy in the data store (see Chun ¶ [0222] “ . . . the UE may receive the first slice service response message. The UE may store the information included in the first slice service response message in the storage. For example, the storage may be a memory of the UE. . . .”) , wherein the updated routing policy indicates that the data of the first type that is received from the first device is to be transmitted to the central core network system over the second predefined network slice (see Chun ¶ [0224] “ . . . based on the determination to use the alternative slice for the slice A, the network node may send a slice service update message to the UE. For example, the slice service update message may be at least one of the registration accept message, the registration reject message, the PDU session establishment accept message, the PDU session establishment reject message, the service accept message, the service reject message, the UE configuration update message, the PDU session modification command/request message and/or the like. For example, the slice service update message may comprise at least one of the list of (updated) allowed network slices (e.g., allowed network slices, allowed slices), the list of (updated) rejected network slices (e.g., rejected network slices, rejected slices), the list of (updated) alternative network slices (e.g., alternative network slices, alternative slices), the list of configured network slices (e.g., configured network slices, configured slices), and/or alternative slice management information (e.g., alt slice mgmt info). In one example, the first slice service response message may be the slice service update message . . .”) The motivation to combine Chun with Li is described for the rejection of claim 1 and is incorporated herein. Additionally, Chun provides for update routing polices using alternative slices being used by the private core. In regard to claim 14, Li teaches A compact core system (see Fig. 1 ¶ [0014] “ . . . an enterprise may manage its own Radio Access Network (RAN) of base stations and/or a core network to manage the RAN and provide connectivity between the RAN and other networks. The enterprise may lease devices, network infrastructure, cloud center resources, and/or software components from a provider of communication services to implement a private RAN and/or a private core network for UE devices used by the employees and/or customers associated with the enterprise. An administrator may configure the private RAN and/or private core network for a set of network slices . . .” ) , comprising: one or more memories comprising: a first data store configured to maintain a plurality of routing policies associated with a plurality of different devices that are registered with the compact core system, wherein each of the routing policies indicates rules for transmitting data to one or more other systems (see Fig. 5 ¶¶ [0067-0069] “ . . As shown in FIG. 5, device 500 may include an orchestrator device interface 510, a rule engine 520, an application database (DB) 530, a slicing rules DB 540, a traffic classifier 550, interfaces 560-A and 560-B, a data unit probe 570, and a traffic director 580. Orchestrator device interface 510 may be configured to communicate with orchestrator device 170. For example, orchestrator device interface 510 may be configured to receive a set of network slicing rules, and/or information relating to applications, from orchestrator device 170. Rule engine 520 may be configured to receive the information from orchestrator device interface 510 and store the information in application DB 530 and/or slicing rules DB 540. Application DB 530 may store information relating to particular applications. Exemplary information that may be stored in application DB 530 is described below with reference to FIG. 6A. Slicing rules DB 540 may store information relating to one or more slicing rules associated with private core network 150. Exemplary information that may be stored in slicing rules DB 540 is described below with reference to FIG. 6B. . . .”). ; and a second data store configured to maintain a plurality of policy rules associated with the different devices that are registered with the compact core system, wherein the policy rules are based on a subscription of the different devices and define at least one of an allocation or management of network resources for transmitting data between a first device and a central core network system (see Li ¶ [0070] “ . . . rule engine 520 may include a data unit pattern analysis module that identifies and/or analyzes data unit patterns for particular applications and stores identified data unit patterns in application DB 530. For example, the data unit pattern analysis module may include a machine learning model trained to identify a data unit pattern for an application. The machine learning model may output, for example, a ratio of uplink data units to downlink data units for an application; a minimum, average, and/or maximum payload size for uplink data units and/or downlink data units associated with the application; a payload size variation for data units associated with the application; a minimum, average, and/or maximum throughput values associated with the application; and/or other types of data unit patterns for the application. The data unit patterns may be determined when data units can be unambiguously identified as being associated with the application (e.g., when the application traffic is not encrypted, when the application is assigned a particular VLAN ID, IP address and port, device group ID, etc.) and then may be used to identify the application when other techniques to identify the application are not available. . . . “) ; one or more processors (see Li ¶ [0059] “ . . . Processor 420 may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor 420 may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic. . . . “) . ; a compact access and mobility management function (AMF) comprising instructions stored in the one or more memories, which when executed by the one or more processors, cause the compact AMF to be configured to establish a secure connection with a central AMF at a central core network system over a network slice using a user plane function (UPF) at the compact core system (see Li ¶ ¶ [0033-0034] “ . . . gNodeB 210 (corresponding to base station 120) may include devices (e.g., base stations) and components that enable UE device 110 to connect to private core network 150 via private RAN 130 using 5G NR RAT. For example, gNodeB 210 may service one or more cells, with each cell being served by a wireless transceiver with an antenna array configured for mm-wave wireless communication. gNodeB 210 may communicate with AMF 220 using an N2 interface 212 and communicate with UPF 230 using an N3 interface 214. In some implementations, gNodeB 210 may receive one or more network slicing rules that assign applications to network slices and apply the one or more network slicing rules to communication sessions. Core network 150 may include an Access and Mobility Function (AMF) 220, a User Plane Function (UPF) 230, a Session Management Function (SMF) 240, an Application Function (AF) 250, a Unified Data Management (UDM) 252, a Policy Control Function (PCF) 254, a Charging Function (CHF) 256, a Network Repository Function (NRF) 258, a Network Exposure Function (NEF) 260, a Network Slice Selection Function (NSSF) 262, an Authentication Server Function (AUSF) 264, a 5G Equipment Identity Register (EIR) 266, a Network Data Analytics Function (NWDAF) 268, a Short Message Service Function (SMSF) 270, a Security Edge Protection Proxy (SEPP) 272, and a Non-3GPP Inter-Working Function (N3IWF) 274. . . .”). ; and a compact session management function (SMF) comprising instructions stored in the one or more memories, which when executed by the one or more processors, cause the compact SMF to be configured to establish a data session with the first device that is registered with the compact core system (see Li ¶ ¶ [0037-0038] “ . . . UPF 230 may maintain an anchor point for intra/inter-RAT mobility, maintain an external Packet Data Unit (PDU) point of interconnect to a particular data network (e.g., PDN 160), perform packet routing and forwarding, perform the user plane part of policy rule enforcement, perform packet inspection, perform lawful intercept, perform traffic usage reporting, perform QoS handling in the user plane, perform uplink traffic verification, perform transport level packet marking, perform downlink packet buffering, forward an “end marker” to a RAN node (e.g., gNodeB 210), and/or perform other types of user plane processes. UPF 230 may communicate with SMF 240 using an N4 interface 232 and connect to PDN 160 using an N6 interface 234. SMF 240 may perform session establishment, session modification, and/or session release, perform IP address allocation and management, perform Dynamic Host Configuration Protocol (DHCP) functions, perform selection and control of UPF 230, configure traffic steering at UPF 230 to guide the traffic to the correct destinations, terminate interfaces toward PCF 254, perform lawful intercepts, charge data collection, support charging interfaces, control and coordinate of charging data collection, terminate session management parts of Non-Access Stratum (NAS) messages, perform downlink data notification, manage roaming functionality, and/or perform other types of control plane processes for managing user plane data. SMF 240 may be accessible via an Nsmf interface 242. SMF may receive one or more network slicing rules that assign applications to network slices and may configure UPF 230 to implement the one or more network slicing rules. . . .”) ; Li fails to explicitly teach, However Chun teaches wherein the compact AMF is further configured to: obtain the data either from the first device or based on the first device (see Chun ¶ [0060] “ . . . The UPF 305 may serve as a gateway for user plane traffic between AN 302 and DN 308. The UE 301 may connect to UPF 305 via a Uu interface and an N3 interface (also described as NG-U interface). The UPF 305 may connect to DN 308 via an N6 interface. The UPF 305 may connect to one or more other UPFs (not shown) via an N9 interface. The UE 301 may be configured to receive services through a protocol data unit (PDU) session, which is a logical connection between UE 301 and DN 308. The UPF 305 (or a plurality of UPFs if desired) may be selected by SMF 314 to handle a particular PDU session between UE 301 and DN 308. The SMF 314 may control the functions of UPF 305 with respect to the PDU session. The SMF 314 may connect to UPF 305 via an N4 interface. The UPF 305 may handle any number of PDU sessions associated with any number of UEs (via any number of ANs). For purposes of handling the one or more PDU sessions, UPF 305 may be controlled by any number of SMFs via any number of corresponding N4 interfaces. . . .”) ; and transmit the data to the central AMF over the network slice using the UPF, based on a routing policy of the routing policies indicating that the data is permitted to be transmitted and stored at the central core network system (see Chun ¶ [0062] “ . . . The AMF 312 may receive, from UE 301, non-access stratum (NAS) messages transmitted in accordance with NAS protocol. NAS messages relate to communications between UE 301 and the core network. Although NAS messages may be relayed to AMF 312 via AN 302, they may be described as communications via the N1 interface. NAS messages may facilitate UE registration and mobility management, for example, by authenticating, identifying, configuring, and/or managing a connection of UE 301. NAS messages may support session management procedures for maintaining user plane connectivity and quality of service (QOS) of a session between UE 301 and DN 309. If the NAS message involves session management, AMF 312 may send the NAS message to SMF 314. NAS messages may be used to transport messages between UE 301 and other components of the core network (e.g., core network components other than AMF 312 and SMF 314). The AMF 312 may act on a particular NAS message itself, or alternatively, forward the NAS message to an appropriate core network function (e.g., SMF 314, etc.) . . .”). The motivation to combine Chun with Li is described for the rejection of claim 1 and is incorporated herein. In regard to claim 15, the combination of Li and Chun teaches wherein the network slice may be a dedicated network slice for communications between the compact core system and the central core network system (see Chun ¶ [0096] “ . . . Each network slice may be tailored to network services having different sets of characteristics. For example, slice A may correspond to enhanced mobile broadband (eMBB) service. Mobile broadband may refer to internet access by mobile users, commonly associated with smartphones. Slice B may correspond to ultra-reliable low-latency communication (URLLC), which focuses on reliability and speed. Relative to eMBB, URLLC may improve the feasibility of use cases such as autonomous driving and telesurgery. Slice C may correspond to massive machine type communication (mMTC), which focuses on low-power services delivered to a large number of users. For example, slice C may be optimized for a dense network of battery-powered sensors that provide small amounts of data at regular intervals. Many mMTC use cases would be prohibitively expensive if they operated using an eMBB or URLLC network. . . .”) , and wherein the network slice employs at least one of encryption protocols, authentication mechanisms, access controls, or auditing (see Chun ¶¶ [0097-0099] “ . . . If the service requirements for one of the UEs 601 changes, then the network slice serving that UE can be updated to provide better service. Moreover, the set of network characteristics corresponding to eMBB, URLLC, and mMTC may be varied, such that differentiated species of eMBB, URLLC, and mMTC are provided. Alternatively, network operators may provide entirely new services in response to, for example, customer demand. In FIG. 6, each of the UEs 601 has its own network slice. However, it will be understood that a single slice may serve any number of UEs and a single UE may operate using any number of slices. Moreover, in the example network architecture 600B, the AN 602, UPF 605 and SMF 614 are separated into three separate slices, whereas the AMF 612 is unsliced. However, it will be understood that a network operator may deploy any architecture that selectively utilizes any mix of sliced and unsliced network elements, with different network elements divided into different numbers of slices. Although FIG. 6 only depicts three core network functions, it will be understood that other core network functions may be sliced as well. A PLMN that supports multiple network slices may maintain a separate network repository function (NFR) for each slice, enabling other NFs to discover network services associated with that slice. Network slice selection may be controlled by an AMF, or alternatively, by a separate network slice selection function (NSSF). For example, a network operator may define and implement distinct network slice instances (NSIs). Each NSI may be associated with single network slice selection assistance information (S-NSSAI). The S-NSSAI may include a particular slice/service type (SST) indicator (indicating eMBB, URLLC, mMTC, etc.). as an example, a particular tracking area may be associated with one or more configured S-NSSAIs. UEs may identify one or more requested and/or subscribed S-NSSAIs (e.g., during registration). The network may indicate to the UE one or more allowed and/or rejected S-NSSAIs. . . .”). The motivation to combine Chun with Li is described for the rejection of claim 1 and is incorporated herein. Additionally, Chun assigns specific rules and protocols to the assigned network slice. In regard to claim 16, the combination of Li and Chun teaches wherein when the data is obtained from the first device, the data comprises content generated at the first device and received at the compact core system for forwarding to the central core network system (see Li Fig. 8, ¶ [0087] “ . . . FIG. 8 illustrates an exemplary signal flow 800 according to an implementation described herein. As shown in FIG. 8, signal flow 800 may include orchestration device 170 providing a set of network slicing rules in private core network 150 and/or private RAN 130 to SMF 240 via NEF 260 (signals 810 and 812). At a later time, UE device 110 may perform a Protocol Data Unit (PDU) session establishment procedure with SMF 240 and UPF 230 via gNodeB 210 (block 820) to communicate with application server 180. UE device 110 may begin to exchange data traffic with application server 180 via gNodeB 210 and UPF 230 using the established communication session (signals 830, 832, and 834). . . .”) In regard to claim 17, the combination of Li and Chun teaches wherein when the data is based on the first device, the data comprises usage data indicating an amount of data used by the first device during one or more data sessions during a predefined period of time (see Chun ¶ [0070] “ . . . The CHF 380 may control billing-related tasks associated with UE 301. For example, UPF 305 may report traffic usage associated with UE 301 to SMF 314. The SMF 314 may collect usage data from UPF 305 and one or more other UPFs. The usage data may indicate how much data is exchanged, what DN the data is exchanged with, a network slice associated with the data, or any other information that may influence billing. The SMF 314 may share the collected usage data with the CHF. The CHF may use the collected usage data to perform billing-related tasks associated with UE 301. The CHF may, depending on the billing status of UE 301, instruct SMF 314 to limit or influence access of UE 301 and/or to provide billing-related notifications to UE 301. . . . “). The motivation to combine Chun with Li is described for the rejection of claim 1 and is incorporated herein. Additionally Chun provides a way for measuring the usage of data exchange., In regard to claim 18, the combination of Li and Chun teaches wherein the data session is established over a second network slice that meets quality of service (QoS) parameters associated with the first device (see Chun Fig. 17 ¶ [0199] “ . . . FIG. 17 illustrates an example embodiment of using an alternative slice. For example, the alternative slice may be a slice that can be alternatively used for a network slice. For example, the alternative slice (e.g., slice B) for the network slice (e.g., slice A) may be assigned and/or provided to a UE with an indication that the alternative slice (e.g., slice B) is used as alternative to the network slice (e.g., slice A). For example, at T=t1, the UE may depart the second area and move to the first area. The network may indicate to the UE that the slice B is the alternative slice for the slice A. When the UE arrives at the first area, the UE may determine to establish a PDU session for the slice A. Based on that alternative slice is available for the existing/previous slice, and/or by using the information that the slice B is the alternative slice for the slice A, the UE may send a request for the PDU session. The request may indicate the slice A and the alternative slice (slice B) for the slice A. Based on the request, the network may determine that the request is associated with the slice A, that the request is associated with the slice B, and/or that the alternative slice for the slice A is the slice B. Based on the determination, the network may adjust network resource usage. For example, based on that the slice B is the alternative for the slice A, to fulfill the QoS requirement of the UE, the network may consider status of network resources of the slice A and/or status of network resource of the slice B. For example, if resources for the slice A is available, the network may serve the request of the UE via using the slice A. For example, if resources for the slice A is not available, the network may serve the request of the UE via using the alternative slice (e.g., slice B). Using alternative slice information in addition to the network slice information may assist a network in optimizing network resource allocation to server the UE. . . “). The motivation to combine Chun with Li is described for the rejection of claim 1 and is incorporated herein. Additionally, Chun describes network slices assigned based on a required QOS. In regard to claim 19, the combination of Li and Chun teaches wherein the first device is registered with the compact core system when the first device is authenticated with the compact core system or when the first device has established another data session with a second device or external system using the compact core system (see Chun ¶ [0061] “ . . . The AMF 312 depicted in FIG. 3 may control UE access to the core network. The UE 301 may register with the network via AMF 312. It may be necessary for UE 301 to register prior to establishing a PDU session. The AMF 312 may manage a registration area of UE 301, enabling the network to track the physical location of UE 301 within the network. For a UE in connected mode, AMF 312 may manage UE mobility, for example, handovers from one AN or portion thereof to another. For a UE in idle mode, AMF 312 may perform registration updates and/or page the UE to transition the UE to connected mode. . . .”; “ . . . The VSEPP 590 and the HSEPP 591 communicate via an N32 interface for defined purposes while concealing information about each PLMN from the other. The SEPPs may apply roaming policies based on communications via the N32 interface. The PCF 520 and PCF 521 may communicate via the SEPPs to exchange policy-related signaling. The NRF 530 and NRF 531 may communicate via the SEPPs to enable service discovery of NFs in the respective PLMNs. The VPLMN and HPLMN may independently maintain NEF 540 and NEF 541. The NSSF 570 and NSSF 571 may communicate via the SEPPs to coordinate slice selection for UE 501. The HPLMN may handle all authentication and subscription related signaling. For example, when the UE 501 registers or requests service via the VPLMN, the VPLMN may authenticate UE 501 and/or obtain subscription data of UE 501 by accessing, via the SEPPs, the UDM 551 and AUSF 561 of the HPLMN. . . .”) The motivation to combine Chun with Li is described for the rejection of claim 1 and is described herein. Additionally, Chun registers devices on the core. In regard to claim 20, the combination of Li and Chun teaches wherein the compact AMF is further configured to store the data in a third data store of the compact core system (see Li Fig. 6B ¶ ¶ [0080-0082] “ . . . FIG. 6B illustrates exemplary components of slicing rules DB 540 according to an implementation described herein. As shown in FIG. 6B, slicing rules DB 540 may include application records 650. Each application record 650 may store network slicing information relating to a particular application. Application record 650 may include an application ID field 660, an application type field 670, and a network slice field 680. Application ID field 660 may store an ID associated with an application. Application type field 670 may store information identifying an application type associated with the application. Network slice field 680 may store network slice information and/or CoS information to which the application has been assigned. For example, network slice field 680 may store a network slice ID (e.g., S-NSSAI, etc.), an ID associated with a logical network, device, and/or path in private RAN 130 and/or private core network 150, a CoS ID associated with a particular CoS guaranteed by private RAN 130 and/or private core network 150, a priority value managed by private RAN 130 and/or private core network 150, and/or other types of information that may be used by private RAN 130 and/or private core network 150 to select a network slice or provide a particular CoS. Although FIG. 6B shows exemplary components of slicing rules DB 540, in other implementations, slicing rules DB 540 may include fewer components, different components, additional components, or differently arranged components than depicted in FIG. 6B. . . “) . 07-21-aia AIA Claim 7 i s re jected under 35 U.S.C. 103 as being un-patentable over Li et al. (U.S. 2023/0337121 A1; herein referred to as LI) in view of Chun et al. (U.S. 2025/0184942 A1; herein referred to as Chun) as applied to claims 1 – 6, 8 – 10, and 14 - 20 in further view of Akkipeddi et al. (U.S. 2025/0097821 A1; herein referred to as Akkipeddi). In regard to claim 7, the combination of Li and Chun fails to expclitly teach, However Akkipeddi teaches further comprising maintaining, at the compact core system, a forwarding table that maps permitted destination addresses to a next-hop interface or destination within a local network (see Akkipeddi ¶¶ [0287-0289] “ . . . CNI 312 and/or routing stack programs the same routes into DPDK vRouter 206A and kernel 380 forwarding table, although with different next-hop interfaces. Routing stack could detect DPDK vRouter 206A being out of service (a TCP connection is used between routing stack and DPDK vRouter 206A) and update the next-hop information and bring up the core facing (physical) interface state accordingly. Similarly, when the DPDK vRouter 206A is restored, routing stack could detect the availability and restore the routes and interface state such that application POD traffic starts going via the DPDK vRouter 206A. By ensuring that the core facing interface(s) previously managed by vRouter 206A is/are assigned the same interface name and IP addresses, it would result in minimal disruption to the control-plane routing protocol state. . . .”) , wherein forwarding, by the UPF over the network slice, the data packets associated with the data session between the device and the external system comprises forwarding the data packets to the next-hop interface (see Akkipeddi Fig. 2, ¶¶ [0077-0079] “ . . . FIG. 2 is a block diagram illustrating an example implementation of a part of the mobile network system of FIG. 1 in further detail, in accordance with techniques of this disclosure. System 200 includes CUs 213A-213K, each of which may represent any of CUs 13. In this example, multiple network slices (e.g., 5G network slices) are implemented using L3VPNs and tunnels 231A-231K to connect DU 22A to different CUs 213A-213K for respective network slices. One of the primary technical challenges facing service providers today is the ability to deliver a wide array of network performance characteristics that future services will demand. To name a few, bandwidth, latency, packet loss, security, and reliability will greatly vary from one service to the other. Emerging applications such as remote operation of robots, massive Internet-of-Things (IOT), and self-driving cars require connectivity, but with vastly different characteristics. The combination of architecture flexibility, software programmability, and needs of different business segments (medical, factories, military, public safety, etc.) and applications have led to the creation of the concept of network slicing. A network slice provides a way to completely segment the mobile network to support a particular type of service or business or even to host service providers (multi-tenancy) who do not own a physical network. Furthermore, each slice can be optimized according to capacity, coverage, connectivity, security and performance characteristics. Since the slices can be isolated from each other, as if they are physically separated both in the control and user planes, the user experience of the network slice will be the same as if it was a separate network. A network slice can span all domains of the network including software applications (both memory and processing) running on network nodes, specific configurations of the core transport network, access network configurations as well as the end devices. The network slicing enables multiple operators to share a mobile network securely but by separating their own users from others, and different applications of a user to use different network slices that provide widely different performance characteristics. 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. Each of tunnels 231A-231K may represent a SR-MPLSoIPv6 or other type of tunnel mentioned above. Each of routers 204A-204K may be a gateway router for a data center having one or more servers to execute any one or more of CUs 213A-213K. The data center may include a data center fabric to switch mobile data traffic between the router and the CU. In some cases, the one or more servers of the data center may also execute a UPF for the mobile network, in which case the data center fabric may also switch mobile data traffic between the CU and the UPF . . .”) based on the forwarding table (see ¶ [0122] “ . . . The vRouter forwarding plane is existing systems may operate as a loadable kernel module in Linux and is responsible for the following functions: [0123] It enables encapsulating packets to be sent to the overlay network and decapsulating packets to be received from the overlay network. [0124] It assigns packets to a routing instance: Packets received from the overlay network are assigned to a routing instance based on the MPLS label or Virtual Network Identifier (VNI). Virtual interfaces to local virtual machines are bound to routing instances. [0125] It does a lookup of the destination address in the forwarding information base (FIB)—also known as forwarding table—and forwards the packet to the correct destination. The routes can be Layer 3 IP prefixes or Layer 2 MAC addresses. [0126] A forwarding policy can be applied using a flow table: It matches packets against the flow table and applies the flow actions. [0127] It punts the packets for which no flow rule is found (that is, the first packet of every flow) to the vRouter agent, which then installs a rule in the flow table. [0128] It punts certain packets such as DHCP, ARP, MDNS to the vRouter agent for proxying to an SDN controller . . .”). It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for a control plane implementation to provide policies for containized routers and construct forwarding tables to route session data through a core network, as taught by Akkipeddi, into a method and system for managing private core networks that determine session authority and service authorization, using network slicing rules as controlled by the private core, where the device session in a wireless network is assigned to a particular network slice based on routing policies determined by rules in the private core, as taught by the combination of Li and Chun. Such incorporation provides a knowledge of flow control in the private core . 07-21-aia AIA Claim s 11 – 12 are rejected under 35 U.S.C. 103 as being un-patentable over Li et al. (U.S. 2023/0337121 A1; herein referred to as LI) in view of Chun et al. (U.S. 2025/0184942 A1; herein referred to as Chun) as applied to claims 1 – 6, 8 – 10, and 14 - 20 in further view of Lei et al. (U.S. 2025/0063348 A1; herein referred to as Lei) . In regard to claim 11, the combination of Li and Chen fails to explicitly teach, However Lei teaches wherein the routing policy indicates that data received from the first device registered with the compact core system is to be encrypted according to a first encryption algorithm using a predefined encryption key prior to transmission (see Lei ¶ [0015] “ . . . the terminal device includes mobile equipment ME and a universal subscriber identity module USIM, and a mapping relationship is preconfigured in the USIM. That a terminal device obtains identification information of a first decryption network element in a local network includes: The ME obtains the identification information of the first decryption network element in the local network. That the terminal device obtains, based on the identification information and a mapping relationship, a first encryption key corresponding to the first decryption network element includes: The ME sends the identification information to the USIM. The USIM determines, based on the identification information and the mapping relationship, the first encryption key corresponding to the first decryption network element. That the terminal device encrypts the user identity information by using the first encryption key, to obtain the hidden user identity includes: The USIM encrypts the user identity information by using the first encryption key, to obtain the hidden user identity, and sends the hidden user identity to the ME. The ME receives the hidden user identity from the USIM. That the terminal device sends a registration request to the local network through an access network device includes: The ME sends the registration request to the local network through the access network device. . . .”). It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for encryption key management for devices registering in a core network, as taught by Lei, into a method and system for managing private core networks that determine session authority and service authorization, using network slicing rules as controlled by the private core, where the device session in a wireless network is assigned to a particular network slice based on routing policies determined by rules in the private core, as taught by the combination of Li and Chun. Such incorporation provides secure authorization for devices sending traffic through the core. In regard to claim 12, the combination of Li, Chen and Lei teaches wherein an update to the routing policy indicates that the data received from the first device is to be encrypted according to a second encryption algorithm using a second predefined encryption key prior to transmission (see Lei ¶ [0058] “ . . . The first decryption network element is a network element in a first local network. The second decryption network element in the macro network determines a first encryption key based on the identification information of the first decryption network element and the mapping relationship. The mapping relationship records at least one decryption network element and an encryption key corresponding to each of the at least one decryption network element, and the at least one decryption network element includes the first decryption network element. The second decryption network element in the macro network sends the first encryption key to a terminal device. The first encryption key corresponds to the first decryption network element. . . .”) , and wherein updating the routing policy comprises storing an updated first routing policy in the data store (see Lei ¶ [0066] “ . . . when storing the preconfigured information, the second decryption network element in the macro network can also autonomously determine the identification information of the first decryption network element based on the information about a first access network device. . . .”) , wherein the updated first routing policy indicates that the data received from the first device is to be encrypted according to a second encryption algorithm using a second predefined encryption key prior to transmission (see Lei ¶ [0065] “ . . . that a second decryption network element in a macro network obtains identification information of a first decryption network element includes: The second decryption network element in the macro network obtains the identification information of the first decryption network element from preconfigured information based on local network subscription information of the terminal device and information about a first access network device. The preconfigured information includes identification information of a decryption network element corresponding to each of at least one local network, the at least one local network includes the first local network, and the first access network device is configured to provide a communication service for the terminal device. . . .”). The motivation to combine Lei with the combination of Li and Chun is described for the rejection of claim 11 and is incorporated herein. Additionally, Lei enables encryption over different network slices . 07-21-aia AIA Claim 13 is rejected under 35 U.S.C. 103 as being un-patentable over Li et al. (U.S. 2023/0337121 A1; herein referred to as LI) in view of Chun et al. (U.S. 2025/0184942 A1; herein referred to as Chun) as applied to claims 1 – 6, 8 – 10, and 14 - 20 in further view of Guim Bernat et al. (U.S. 2025/0112825 A1; herein referred to as Guim) . In regard to claim 13, the combination of Li and Chun fails to teach, However Guim teaches wherein the routing policy indicates that raw data received from devices registered with the compact core system is prohibited from being forwarded to an external system, but an encrypted version of the raw data is permitted to be forwarded to the external system (see Guim ¶¶ [0820-0822] “ . . . One aspect that SAE may use to improve correlation or classification is to correlate different characteristics inherent to the resources being utilized by the workload itself. Different CPU and platform resources may have different levels of isolation or security characteristics which may be used by SAE in order to improve the classification or data filtering. Classification may include using: [0821] 1. Platform security and multi-tenant cryptography, which may include features such as secure enclaves or memory encryption that may completely remove potential conflicts. In other examples, the SAE has to validate which of these features are actually utilized by the particular workload in order to certify that the system is conflict free (or conflict limited). [0822] 2. Resource isolation may change the conflict of interest mapping. In resource isolation, different resources or platform features may change perspective of a particular SLA. For example, SAE may check whether resources are hardware partitioned per tenant or whether they are not going to be shared across multiple tenants. . . .”). It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system to offer orchestration and management for applications and coordinated service instances among many types of storage and compute resources using a core network, as taught by Guim, into a method and system for managing private core networks that determine session authority and service authorization, using network slicing rules as controlled by the private core, where the device session in a wireless network is assigned to a particular network slice based on routing policies determined by rules in the private core, as taught by the combination of Li and Chun. Such incorporation enabled the system to filter certain sessions based on security or authentication. Conclusion There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri.. 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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /JAMES N FIORILLO/ Primary Examiner, Art Unit 2444 Application/Control Number: 18/951,444 Page 2 Art Unit: 2444 Application/Control Number: 18/951,444 Page 3 Art Unit: 2444 Application/Control Number: 18/951,444 Page 4 Art Unit: 2444 Application/Control Number: 18/951,444 Page 5 Art Unit: 2444 Application/Control Number: 18/951,444 Page 6 Art Unit: 2444 Application/Control Number: 18/951,444 Page 7 Art Unit: 2444 Application/Control Number: 18/951,444 Page 8 Art Unit: 2444 Application/Control Number: 18/951,444 Page 9 Art Unit: 2444 Application/Control Number: 18/951,444 Page 10 Art Unit: 2444 Application/Control Number: 18/951,444 Page 11 Art Unit: 2444 Application/Control Number: 18/951,444 Page 12 Art Unit: 2444 Application/Control Number: 18/951,444 Page 13 Art Unit: 2444 Application/Control Number: 18/951,444 Page 14 Art Unit: 2444 Application/Control Number: 18/951,444 Page 15 Art Unit: 2444 Application/Control Number: 18/951,444 Page 16 Art Unit: 2444 Application/Control Number: 18/951,444 Page 17 Art Unit: 2444 Application/Control Number: 18/951,444 Page 18 Art Unit: 2444 Application/Control Number: 18/951,444 Page 19 Art Unit: 2444 Application/Control Number: 18/951,444 Page 20 Art Unit: 2444 Application/Control Number: 18/951,444 Page 21 Art Unit: 2444 Application/Control Number: 18/951,444 Page 22 Art Unit: 2444 Application/Control Number: 18/951,444 Page 23 Art Unit: 2444 Application/Control Number: 18/951,444 Page 24 Art Unit: 2444 Application/Control Number: 18/951,444 Page 25 Art Unit: 2444 Application/Control Number: 18/951,444 Page 26 Art Unit: 2444 Application/Control Number: 18/951,444 Page 27 Art Unit: 2444 Application/Control Number: 18/951,444 Page 28 Art Unit: 2444 Application/Control Number: 18/951,444 Page 29 Art Unit: 2444 Application/Control Number: 18/951,444 Page 30 Art Unit: 2444 Application/Control Number: 18/951,444 Page 31 Art Unit: 2444 Application/Control Number: 18/951,444 Page 32 Art Unit: 2444 Application/Control Number: 18/951,444 Page 33 Art Unit: 2444 Application/Control Number: 18/951,444 Page 34 Art Unit: 2444 Application/Control Number: 18/951,444 Page 35 Art Unit: 2444 Application/Control Number: 18/951,444 Page 36 Art Unit: 2444 Application/Control Number: 18/951,444 Page 37 Art Unit: 2444 Application/Control Number: 18/951,444 Page 38 Art Unit: 2444 Application/Control Number: 18/951,444 Page 39 Art Unit: 2444 Application/Control Number: 18/951,444 Page 40 Art Unit: 2444 Application/Control Number: 18/951,444 Page 41 Art Unit: 2444 Application/Control Number: 18/951,444 Page 42 Art Unit: 2444 Application/Control Number: 18/951,444 Page 43 Art Unit: 2444
Prosecution Insights