Prosecution Insights
Last updated: April 19, 2026
Application No. 18/020,237

NETWORK SLICING MANAGEMENT METHOD AND SYSTEM, AND COMPUTER READABLE STORAGE MEDIUM

Non-Final OA §103
Filed
Feb 07, 2023
Examiner
BALLOWE, CALEB JAMES
Art Unit
2419
Tech Center
2400 — Computer Networks
Assignee
ZTE CORPORATION
OA Round
3 (Non-Final)
14%
Grant Probability
At Risk
3-4
OA Rounds
3y 1m
To Grant
61%
With Interview

Examiner Intelligence

Grants only 14% of cases
14%
Career Allow Rate
2 granted / 14 resolved
-43.7% vs TC avg
Strong +46% interview lift
Without
With
+46.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
55 currently pending
Career history
69
Total Applications
across all art units

Statute-Specific Performance

§101
4.8%
-35.2% vs TC avg
§103
62.0%
+22.0% vs TC avg
§102
11.3%
-28.7% vs TC avg
§112
21.9%
-18.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 14 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/09/2025 has been entered. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1, 3-4, 7, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bogineni et al. (US 2020/0045586), hereinafter "Bogineni", in view of Xing et al. (US 12,089,124), hereinafter “Xing”, and further in view of Jagannatha et al. (US 2020/0187085), hereinafter "Jagannatha", and further in view of Ding (US 2022/0191765), hereinafter “Ding”. Regarding claim 1, Bogineni teaches: A network slice management method, applied to a slice management server arranged on a user plane of a core network (see Bogineni, Fig. 1A, par. [0027], lines 1-6: in FIG. 1A, and by reference number 110, the base station can send the information that identifies the communications attribute of the application (e.g., the third information) to the UPF component at the core network to determine the set of network slice policies for managing the communications session at the RAN), the method comprising: acquiring a second network slice rule (see Bogineni, Fig. 1A, par. [0027], lines 1-6: in FIG. 1A, and by reference number 110, the base station can send the information that identifies the communications attribute of the application (e.g., the third information) to the UPF component at the core network to determine the set of network slice policies for managing the communications session at the RAN, and see Bogineni, Fig. 1B, par. [0028], lines 2-7: the NSSF component can process the first data indicating the UE preference and/or the second data indicating the communications requirement to determine the set of network slice policies for managing the communications session. In some implementations, the NSSF component can send the network slice policies to the UPF component; in this case, the network slice policies correspond to a second network slice rule), However, Bogineni does not teach: wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment (UE) Route Selection Policy (URSP) rule; acquiring a server address from a network control element of a control plane of the core network; establishing a connection with the UE through the server address; and sending the second network slice rule to the UE, comprising: sending the second network slice rule to the UE according to a first network slice rule matching request sent by the UE, comprising: receiving the first network slice rule matching request sent by the UE, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request; and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule. Xing, in the same field of endeavor, teaches: acquiring a server address from a network control element of a control plane of the core network (see Xing, Fig. 5, col. 25, lines 32-34: S502: The first network element sends a correspondence between the first address and the address information of the first server to the user plane function network element, and see Xing, col. 25, lines 56-64: in S502, the first network element may further send, to the user plane function network element, the location information of the first service provided by the first server, and the second server that provides the first service for the user equipment is determined based on the correspondence between the first address and the address information of the first server and the location information of the first service provided by the first server, and see Xing, col. 31, lines 18-23: S504: The user plane function network element obtains the correspondence between the first address and the address information of the first server. Optionally, in S504, the user plane function network element may further obtain the location information of the first service provided by the first server; in this case, the user plane receives address information of the server (corresponding to a server address) provided by a first network element); establishing a connection with the UE through the server address (see Xing, Fig. 5, col. 32, lines 16-31: in S504, the user plane function network element obtains the correspondence between the first address and the address information of the first server (where optionally, the location information of the first service provided by the first server is further obtained) and then performs recording, to obtain correspondences between first addresses of different services and address information of a plurality of different first servers (where optionally, the location information of the first service provided by the first server is further obtained). If receiving a data packet that is sent by the UE and whose destination address is a first address of a service, the user plane function network element may determine address information of a server that provides the service for the UE, and send the data packet of the service to the corresponding server through an address indicated by the address information, and see col. 34, lines 23-29: S506: The UE sends the data packet of the first service using the first address as the destination address. For example, when the UE performs the first service, the UE may obtain the first address based on the correspondence between the first address and the service identifier of the first service obtained in S505, and then perform S506 to send the data packet of the first service; in this case, the address information is used for communication (i.e. establishing a connection) between the UE and server, corresponding to establishing a connection through the server address); Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of Bogineni with the establishing a connection through a server address acquired from a network element of Xing with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of saving resources and improving security (see Xing, col. 2, lines 26-45). However, the combination of Bogineni in view of Xing does not teach: wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment (UE) Route Selection Policy (URSP) rule; sending the second network slice rule to the UE, comprising: sending the second network slice rule to the UE according to a first network slice rule matching request sent by the UE, comprising: receiving the first network slice rule matching request sent by the UE, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request; and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule. Jagannatha, in the same field of endeavor, teaches: wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE, and see Fig. 4, par. [0052]: Network function devices 415 include one or more devices capable of communicating with UE 405, with base station 410, with data network 420, and/or the like. In some implementations, network function devices 415 can include a user plane function (UPF) device, a session management function (SMF) device, an access and mobility management function (AMF) device, a policy control function (PCF) device, a network slice selection function (NSSF) device; in this case, the network function device (i.e. slice management server) generates updated URSP (corresponding to a new version of the network slice rule)), and the network slice rule is a user equipment (UE) Route Selection Policy (URSP) rule (see Jagannatha, and see par. [0040]: in example network mapping 200, the URSP can include a URSP rule, associated with application 1, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 1. As another example, the URSP can include a URSP rule, associated with application 2, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 2. As another example, the URSP can include a URSP rule, associated with application 3, that includes a first route selection descriptor that specifies network slice 2 and data network 1 are to be used for a data session associated with application 3, and that includes a second route selection descriptor that specifies network slice 1 and data network m are to be used for the data session associated with application 3. In this way, an APH component, included in the UE, can attempt to establish the data session using the first route selection descriptor, and can attempt to establish the data session using the second route selection descriptor if the attempt to establish the data session using the first route selection descriptor is unsuccessful); sending the second network slice rule to the UE (see Jagannatha, Fig. 1A, par. [0023]: in FIG. 1A, and reference number 102, to configure the UE to use a URSP rule associated with one or more applications, one or more network function devices, included in the one or more networks, can transmit a URSP to the UE. For example, a PCF device on the network can generate and maintain the URSP, and can transmit the URSP to the UE via a session management function (SMF) device, a user plane function (UPF) device, a base station, and/or the like), comprising: sending the second network slice rule to the UE according to a first network slice rule matching request sent by the UE (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application), comprising: receiving the first network slice rule matching request sent by the UE (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application), Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the second slice rule of the combination of Bogineni in view of Xing with the USRP and sending the rule based on a received request sent by the UE of Jagannatha with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving efficiency and decreasing latency (see Jagannatha, par. [0013]). However, the combination of Bogineni in view of Xing, and further in view of Jagannatha, does not teach: wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request; and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule. Ding, in the same field of endeavor, teaches: wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE (see Ding, Fig. 6, pars. [0216-0219]: Step 601: The UE sends a registration request to an AME Correspondingly, the AMF may receive the registration request. The registration request may be a registration request corresponding to initial registration of the UE in 5G, or may be a mobility registration request initiated when the UE is handed over from 4G to 5G. In the registration request, the UE carries a PSI list (List of stored PSIs) to notify the PCF of a locally stored user policy list, and further carries a banned PSI or a banned APP ID of the UE. One PSI corresponds to one or more URSPs. Specifically, the registration request carries a UE policy container, where the UE policy container includes the list of stored PSIs, and includes the banned PSI or the banned APP ID. Optionally, the UE policy container further includes an OS ID, and an indication of UE support for ANDSP. The banned PSI refers to a PSI that does not need to be used in PSIs locally stored by the UE. The banned APP ID is an identifier of an application that does not need to be used or is not installed on the UE. The APP ID herein may be in a form of traffic description information, or may be in a form of a URSP rule ID; in this case, the request includes URSP information of the UE for checking a list of information (corresponding to the request being configured for checking a version of a rule)); matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request (see Ding, Fig. 6, pars. [0230-0231]: Step 606: The PCF decides to generate a URSP. Specifically, if the PCF determines that the URSP corresponding to the PSI list sent by the UE is different from the URSP obtained by the PCF from the UDR, the PCF determines that a URSP needs to be regenerated; in this case, comparing URSP corresponds to matching slice rules); and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule (see Ding, Fig. 6, pars. [0230-0238]: Step 606: The PCF decides to generate a URSP. Specifically, if the PCF determines that the URSP corresponding to the PSI list sent by the UE is different from the URSP obtained by the PCF from the UDR, the PCF determines that a URSP needs to be regenerated. Methods in which the PCF regenerates the URSP include but are not limited to the following two methods: Method 1: The PCF determines a URSP corresponding to the banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604), and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Method 2: The PCF obtains a combined banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604) and the banned APP ID obtained from the UDR, determines a URSP corresponding to the combined banned APP ID, and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Step 607: The PCF sends a user policy association establishment response to the AME Correspondingly, the AMF may receive the user policy association establishment response. The user policy association establishment response may carry a trigger event list subscribed by the PCF from the AMF. Step 607 may be performed after step 603 and before step 608. Step 608: The PCF sends the URSP generated in step 606 to the UE in a UE configuration update procedure). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the matching request of the combination of Bogineni in view of Xing, and further in view of Jagannatha, with the request for checking a version, matching, and sending updated rules of Ding with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing signaling overhead (see Ding, par. [0213]). Regarding claim 3, the combination of Bogineni in view of Xing, and further in view of Jagannatha, and further in view of Ding, teaches the method. Bogineni does not teach, but Xing teaches: wherein the network element of the control plane of the core network is a policy control function (PCF) (see Xing, col. 2, lines 48-50: the first network element may be a policy control network element, for example, a PCF in a 5G system). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the establishing a connection of Bogineni with the establishing a connection through a server address acquired from a PCF of Xing with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of saving resources and improving security (see Xing, col. 2, lines 26-45). Regarding claim 4, the combination of Bogineni in view of Xing, and further in view of Jagannatha, and further in view of Ding, teaches the method. Bogineni does not teach, but Xing teaches: wherein the server address is an IP address or a domain name (see Xing, col. 7, lines 13-15: the address information of the first server may include an IP address or a fully qualified domain name (FQDN) address). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the establishing a connection of Bogineni with the establishing a connection through an IP address or domain name acquired from a network element of Xing with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of saving resources and improving security (see Xing, col. 2, lines 26-45). Regarding claim 7, Bogineni teaches: A network slice management method, which is applied to a user equipment (UE) (see Bogineni, par. [0013], lines 1-10: in FIGS. 1A-1C, example implementation 100 can include a user equipment (UE) wirelessly connected to a radio access network (RAN) at a base station, which is connected to a data network via a core network. The UE can run an application that requires communicating with the data network and, therefore, the UE can enter into a communications session with the data network via the RAN and core network. The UE and the core network can communicate application-specific data during the communications session, and see Bogineni, par. [0023], lines 1-9: the request can include information that identifies the UE (e.g., second information), such as information concerning a type of the UE, an operating system running on the UE, hardware components of the UE, the UE's wireless network provider, the UE's wireless network plan, the UE's preferred allocation of radio access resources at the RAN (e.g., a preference concerning the set of network slice policies to apply to the communications session) and/or the like), the method comprising: establishing a connection with a slice management server arranged on a user plane of a core network (see Bogineni, Fig. 1A, par. [0021], lines 1-7: in FIG. 1A, and by reference number 102, the UE can send a request (e.g., first information) to the base station of the RAN to initiate a communications session between the UE and the data network. For example, the UE can run an application that instructs the UE to communicate with an application server that is communicatively connected to the data network, and see Bogineni, par. [0027], lines 2-6: the base station can send the information that identifies the communications attribute of the application (e.g., the third information) to the UPF component at the core network to determine the set of network slice policies for managing the communications session at the RAN; in this case, a communications session (i.e. connection) may be established for communicating with a user plane); However, Bogineni does not teach: establishing a connection through a server address of the slice management server, wherein the server address of the slice management server is acquired by the slice management server from a network element of a control plane of the core network; receiving a second network slice rule sent by the slice management server, wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment Route Selection Policy (URSP) rule; in response to a connection being established with the slice management server arranged on the user plane of the core network, sending a first network slice rule matching request to the slice management server, so that the slice management server sends the second network slice rule to the UE according to the first network slice rule matching request, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule. Xing, in the same field of endeavor, teaches: establishing a connection through a server address of the slice management server (see Xing, Fig. 5, col. 32, lines 16-31: in S504, the user plane function network element obtains the correspondence between the first address and the address information of the first server (where optionally, the location information of the first service provided by the first server is further obtained) and then performs recording, to obtain correspondences between first addresses of different services and address information of a plurality of different first servers (where optionally, the location information of the first service provided by the first server is further obtained). If receiving a data packet that is sent by the UE and whose destination address is a first address of a service, the user plane function network element may determine address information of a server that provides the service for the UE, and send the data packet of the service to the corresponding server through an address indicated by the address information, and see col. 34, lines 23-29: S506: The UE sends the data packet of the first service using the first address as the destination address. For example, when the UE performs the first service, the UE may obtain the first address based on the correspondence between the first address and the service identifier of the first service obtained in S505, and then perform S506 to send the data packet of the first service; in this case, the address information is used for communication (i.e. establishing a connection) between the UE and server, corresponding to establishing a connection through the server address), wherein the server address of the slice management server is acquired by the slice management server from a network element of a control plane of the core network (see Xing, Fig. 5, col. 25, lines 32-34: S502: The first network element sends a correspondence between the first address and the address information of the first server to the user plane function network element, and see Xing, col. 25, lines 56-64: in S502, the first network element may further send, to the user plane function network element, the location information of the first service provided by the first server, and the second server that provides the first service for the user equipment is determined based on the correspondence between the first address and the address information of the first server and the location information of the first service provided by the first server, and see Xing, col. 31, lines 18-23: S504: The user plane function network element obtains the correspondence between the first address and the address information of the first server. Optionally, in S504, the user plane function network element may further obtain the location information of the first service provided by the first server); in this case, the user plane receives address information of the server (corresponding to a server address) provided by a first network element); Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of Bogineni with the establishing a connection through a server address acquired from a network element of Xing with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of saving resources and improving security (see Xing, col. 2, lines 26-45). However, the combination of Bogineni in view of Xing does not teach: receiving a second network slice rule sent by the slice management server, wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment Route Selection Policy (URSP) rule; in response to a connection being established with the slice management server arranged on the user plane of the core network, sending a first network slice rule matching request to the slice management server, so that the slice management server sends the second network slice rule to the UE according to the first network slice rule matching request, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule. Jagannatha, in the same field of endeavor, teaches: receiving a second network slice rule sent by the slice management server (see Jagannatha, Fig. 1A, par. [0023]: in FIG. 1A, and reference number 102, to configure the UE to use a URSP rule associated with one or more applications, one or more network function devices, included in the one or more networks, can transmit a URSP to the UE. For example, a PCF device on the network can generate and maintain the URSP, and can transmit the URSP to the UE via a session management function (SMF) device, a user plane function (UPF) device, a base station, and/or the like), wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE, and see Fig. 4, par. [0052]: Network function devices 415 include one or more devices capable of communicating with UE 405, with base station 410, with data network 420, and/or the like. In some implementations, network function devices 415 can include a user plane function (UPF) device, a session management function (SMF) device, an access and mobility management function (AMF) device, a policy control function (PCF) device, a network slice selection function (NSSF) device; in this case, the network function device (i.e. slice management server) generates updated URSP (corresponding to a new version of the network slice rule)), and the network slice rule is a user equipment Route Selection Policy (URSP) rule (see Jagannatha, Fig. 2, par. [0040]: in example network mapping 200, the URSP can include a URSP rule, associated with application 1, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 1. As another example, the URSP can include a URSP rule, associated with application 2, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 2. As another example, the URSP can include a URSP rule, associated with application 3, that includes a first route selection descriptor that specifies network slice 2 and data network 1 are to be used for a data session associated with application 3, and that includes a second route selection descriptor that specifies network slice 1 and data network m are to be used for the data session associated with application 3. In this way, an APH component, included in the UE, can attempt to establish the data session using the first route selection descriptor, and can attempt to establish the data session using the second route selection descriptor if the attempt to establish the data session using the first route selection descriptor is unsuccessful) in response to a connection being established with the slice management server arranged on the user plane of the core network, sending a first network slice rule matching request to the slice management server (see Jagannatha, Fig. 1A, par. [0023]: in FIG. 1A, and reference number 102, to configure the UE to use a URSP rule associated with one or more applications, one or more network function devices, included in the one or more networks, can transmit a URSP to the UE. For example, a PCF device on the network can generate and maintain the URSP, and can transmit the URSP to the UE via a session management function (SMF) device, a user plane function (UPF) device, a base station, and/or the like. In some implementations, the one or more network function devices can transmit the URSP to the UE based on an event (e.g., based on the UE communicatively connecting to a base station included in the one or more networks, based on the UE installing a new application on the UE, and/or the like), at a particular time interval, based on receiving a request from the UE for the URSP, and/or the like, and see par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application), so that the slice management server sends the second network slice rule to the UE according to the first network slice rule matching request (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application), Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the second slice rule of the combination of Bogineni in view of Xing with the USRP, sending a request, and receiving the rule of Jagannatha with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving efficiency and decreasing latency (see Jagannatha, par. [0013]). However, the combination of Bogineni in view of Xing, and further in view of Jagannatha, does not teach: wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule. Ding, in the same field of endeavor, teaches: wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE (see Ding, Fig. 6, pars. [0216-0219]: Step 601: The UE sends a registration request to an AME Correspondingly, the AMF may receive the registration request. The registration request may be a registration request corresponding to initial registration of the UE in 5G, or may be a mobility registration request initiated when the UE is handed over from 4G to 5G. In the registration request, the UE carries a PSI list (List of stored PSIs) to notify the PCF of a locally stored user policy list, and further carries a banned PSI or a banned APP ID of the UE. One PSI corresponds to one or more URSPs. Specifically, the registration request carries a UE policy container, where the UE policy container includes the list of stored PSIs, and includes the banned PSI or the banned APP ID. Optionally, the UE policy container further includes an OS ID, and an indication of UE support for ANDSP. The banned PSI refers to a PSI that does not need to be used in PSIs locally stored by the UE. The banned APP ID is an identifier of an application that does not need to be used or is not installed on the UE. The APP ID herein may be in a form of traffic description information, or may be in a form of a URSP rule ID; in this case, the request includes URSP information of the UE for checking a list of information (corresponding to the request being configured for checking a version of a rule)); and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule (see Ding, Fig. 6, pars. [0230-0238]: Step 606: The PCF decides to generate a URSP. Specifically, if the PCF determines that the URSP corresponding to the PSI list sent by the UE is different from the URSP obtained by the PCF from the UDR, the PCF determines that a URSP needs to be regenerated. Methods in which the PCF regenerates the URSP include but are not limited to the following two methods: Method 1: The PCF determines a URSP corresponding to the banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604), and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Method 2: The PCF obtains a combined banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604) and the banned APP ID obtained from the UDR, determines a URSP corresponding to the combined banned APP ID, and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Step 607: The PCF sends a user policy association establishment response to the AME Correspondingly, the AMF may receive the user policy association establishment response. The user policy association establishment response may carry a trigger event list subscribed by the PCF from the AMF. Step 607 may be performed after step 603 and before step 608. Step 608: The PCF sends the URSP generated in step 606 to the UE in a UE configuration update procedure, and see par. [0211]: In an example, the UE carries an allowed list (6), PSIs carried by the UE are PSI A (1, 2, 3) and PSI B (4), and the UDR stores PSI A (1, 2, 3) and PSI C (4). The PCF decides that an obtained final URSP policy is (1, 2, 3, 4, 6). In this case, the PCF may update the URSP in the UE in a manner of PSI D (4, 6)+PSI B ( ), or directly update the URSP in the UE in a form of PSI D (1, 2, 3, 4, 6)+PSI A ( )+PSI B ( )). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the matching request of the combination of Bogineni in view of Xing, and further in view of Jagannatha, with the request for checking a version and replacing updated rules of Ding with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing signaling overhead (see Ding, par. [0213]). Regarding claim 12, the combination of Bogineni in view of Xing, and further in view of Jagannatha, and further in view of Ding, teaches the method. Bogineni does not teach, but Xing teaches: wherein the server address is an IP address or a domain name (see Xing, col. 7, lines 13-15: the address information of the first server may include an IP address or a fully qualified domain name (FQDN) address). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the establishing a connection of Bogineni with the establishing a connection through an IP address or domain name acquired from a network element of Xing with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of saving resources and improving security (see Xing, col. 2, lines 26-45). Regarding claim 14, Bogineni teaches: A non-transitory computer-readable storage medium, storing a computer-executable program which, when executed by a computer (see Bogineni, Fig. 4, par. [0065], lines 1-5: Device 400 can perform one or more processes described herein. Device 400 can perform these processes based on processor 420 executing software instructions stored by a non-transitory computer-readable medium, such as memory 430 and/or storage component 440), causes the computer to perform a network slice management method, applied to a slice management server arranged on a user plane of a core network (see Bogineni, Fig. 1A, par. [0027], lines 1-6: in FIG. 1A, and by reference number 110, the base station can send the information that identifies the communications attribute of the application (e.g., the third information) to the UPF component at the core network to determine the set of network slice policies for managing the communications session at the RAN), the method comprising: acquiring a second network slice rule (see Bogineni, Fig. 1A, par. [0027], lines 1-6: in FIG. 1A, and by reference number 110, the base station can send the information that identifies the communications attribute of the application (e.g., the third information) to the UPF component at the core network to determine the set of network slice policies for managing the communications session at the RAN, and see Bogineni, Fig. 1B, par. [0028], lines 2-7: the NSSF component can process the first data indicating the UE preference and/or the second data indicating the communications requirement to determine the set of network slice policies for managing the communications session. In some implementations, the NSSF component can send the network slice policies to the UPF component; in this case, the network slice policies correspond to a second network slice rule); or causes the computer to perform a network slice management method, which is applied to a user equipment(UE) (see Bogineni, par. [0013], lines 1-10: in FIGS. 1A-1C, example implementation 100 can include a user equipment (UE) wirelessly connected to a radio access network (RAN) at a base station, which is connected to a data network via a core network. The UE can run an application that requires communicating with the data network and, therefore, the UE can enter into a communications session with the data network via the RAN and core network. The UE and the core network can communicate application-specific data during the communications session, and see Bogineni, par. [0023], lines 1-9: the request can include information that identifies the UE (e.g., second information), such as information concerning a type of the UE, an operating system running on the UE, hardware components of the UE, the UE's wireless network provider, the UE's wireless network plan, the UE's preferred allocation of radio access resources at the RAN (e.g., a preference concerning the set of network slice policies to apply to the communications session) and/or the like), the method comprising: establishing a connection with a slice management server arranged on a user plane of a core network (see Bogineni, Fig. 1A, par. [0021], lines 1-7: in FIG. 1A, and by reference number 102, the UE can send a request (e.g., first information) to the base station of the RAN to initiate a communications session between the UE and the data network. For example, the UE can run an application that instructs the UE to communicate with an application server that is communicatively connected to the data network, and see Bogineni, par. [0027], lines 2-6: the base station can send the information that identifies the communications attribute of the application (e.g., the third information) to the UPF component at the core network to determine the set of network slice policies for managing the communications session at the RAN; in this case, a communications session (i.e. connection) may be established for communicating with a user plane); However, Bogineni does not teach: wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment (UE) Route Selection Policy (URSP) rule; acquiring a server address from a network control element of a control plane of the core network; establishing a connection with the UE through the server address; and sending the second network slice rule to the UE, comprising: sending the second network slice rule to the UE according to a first network slice rule matching request sent by the UE, comprising: receiving the first network slice rule matching request sent by the UE, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request; and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule; or establishing a connection through a server address of the slice management server, wherein the server address of the slice management server is acquired by the slice management server from a network element of a control plane of the core network; receiving a second network slice rule sent by the slice management server, wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment Route Selection Policy (URSP) rule; in response to a connection being established with the slice management server arranged on the user plane of the core network, sending a first network slice rule matching request to the slice management server, so that the slice management server sends the second network slice rule to the UE according to the first network slice rule matching request, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule. Xing, in the same field of endeavor, teaches: acquiring a server address from a network control element of a control plane of the core network (see Xing, Fig. 5, col. 25, lines 32-34: S502: The first network element sends a correspondence between the first address and the address information of the first server to the user plane function network element, and see Xing, col. 25, lines 56-64: in S502, the first network element may further send, to the user plane function network element, the location information of the first service provided by the first server, and the second server that provides the first service for the user equipment is determined based on the correspondence between the first address and the address information of the first server and the location information of the first service provided by the first server, and see Xing, col. 31, lines 18-23: S504: The user plane function network element obtains the correspondence between the first address and the address information of the first server. Optionally, in S504, the user plane function network element may further obtain the location information of the first service provided by the first server); in this case, the user plane receives address information of the server (corresponding to a server address) provided by a first network element); establishing a connection with the UE through the server address (see Xing, Fig. 5, col. 32, lines 16-31: in S504, the user plane function network element obtains the correspondence between the first address and the address information of the first server (where optionally, the location information of the first service provided by the first server is further obtained) and then performs recording, to obtain correspondences between first addresses of different services and address information of a plurality of different first servers (where optionally, the location information of the first service provided by the first server is further obtained). If receiving a data packet that is sent by the UE and whose destination address is a first address of a service, the user plane function network element may determine address information of a server that provides the service for the UE, and send the data packet of the service to the corresponding server through an address indicated by the address information, and see col. 34, lines 23-29: S506: The UE sends the data packet of the first service using the first address as the destination address. For example, when the UE performs the first service, the UE may obtain the first address based on the correspondence between the first address and the service identifier of the first service obtained in S505, and then perform S506 to send the data packet of the first service; in this case, the address information is used for communication (i.e. establishing a connection) between the UE and server, corresponding to establishing a connection through the server address); or establishing a connection through a server address of the slice management server (see Xing, Fig. 5, col. 32, lines 16-31: in S504, the user plane function network element obtains the correspondence between the first address and the address information of the first server (where optionally, the location information of the first service provided by the first server is further obtained) and then performs recording, to obtain correspondences between first addresses of different services and address information of a plurality of different first servers (where optionally, the location information of the first service provided by the first server is further obtained). If receiving a data packet that is sent by the UE and whose destination address is a first address of a service, the user plane function network element may determine address information of a server that provides the service for the UE, and send the data packet of the service to the corresponding server through an address indicated by the address information, and see col. 34, lines 23-29: S506: The UE sends the data packet of the first service using the first address as the destination address. For example, when the UE performs the first service, the UE may obtain the first address based on the correspondence between the first address and the service identifier of the first service obtained in S505, and then perform S506 to send the data packet of the first service; in this case, the address information is used for communication (i.e. establishing a connection) between the UE and server, corresponding to establishing a connection through the server address), wherein the server address of the slice management server is acquired by the slice management server from a network element of a control plane of the core network (see Xing, Fig. 5, col. 25, lines 32-34: S502: The first network element sends a correspondence between the first address and the address information of the first server to the user plane function network element, and see Xing, col. 25, lines 56-64: in S502, the first network element may further send, to the user plane function network element, the location information of the first service provided by the first server, and the second server that provides the first service for the user equipment is determined based on the correspondence between the first address and the address information of the first server and the location information of the first service provided by the first server, and see Xing, col. 31, lines 18-23: S504: The user plane function network element obtains the correspondence between the first address and the address information of the first server. Optionally, in S504, the user plane function network element may further obtain the location information of the first service provided by the first server); in this case, the user plane receives address information of the server (corresponding to a server address) provided by a first network element); Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the storage medium of Bogineni with the establishing a connection through a server address acquired from a network element of Xing with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of saving resources and improving security (see Xing, col. 2, lines 26-45). However, the combination of Bogineni in view of Xing does not teach: wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment (UE) Route Selection Policy (URSP) rule; sending the second network slice rule to the UE, comprising: sending the second network slice rule to the UE according to a first network slice rule matching request sent by the UE, comprising: receiving the first network slice rule matching request sent by the UE, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request; and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule; or receiving a second network slice rule sent by the slice management server, wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server, and the network slice rule is a user equipment Route Selection Policy (URSP) rule; in response to a connection being established with the slice management server arranged on the user plane of the core network, sending a first network slice rule matching request to the slice management server, so that the slice management server sends the second network slice rule to the UE according to the first network slice rule matching request, wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule. Jagannatha, in the same field of endeavor, teaches: wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE, and see Fig. 4, par. [0052]: Network function devices 415 include one or more devices capable of communicating with UE 405, with base station 410, with data network 420, and/or the like. In some implementations, network function devices 415 can include a user plane function (UPF) device, a session management function (SMF) device, an access and mobility management function (AMF) device, a policy control function (PCF) device, a network slice selection function (NSSF) device; in this case, the network function device (i.e. slice management server) generates updated URSP (corresponding to a new version of the network slice rule)), and the network slice rule is a user equipment (UE) Route Selection Policy (URSP) rule (see Jagannatha, and see par. [0040]: in example network mapping 200, the URSP can include a URSP rule, associated with application 1, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 1. As another example, the URSP can include a URSP rule, associated with application 2, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 2. As another example, the URSP can include a URSP rule, associated with application 3, that includes a first route selection descriptor that specifies network slice 2 and data network 1 are to be used for a data session associated with application 3, and that includes a second route selection descriptor that specifies network slice 1 and data network m are to be used for the data session associated with application 3. In this way, an APH component, included in the UE, can attempt to establish the data session using the first route selection descriptor, and can attempt to establish the data session using the second route selection descriptor if the attempt to establish the data session using the first route selection descriptor is unsuccessful); sending the second network slice rule to the UE (see Jagannatha, Fig. 1A, par. [0023]: in FIG. 1A, and reference number 102, to configure the UE to use a URSP rule associated with one or more applications, one or more network function devices, included in the one or more networks, can transmit a URSP to the UE. For example, a PCF device on the network can generate and maintain the URSP, and can transmit the URSP to the UE via a session management function (SMF) device, a user plane function (UPF) device, a base station, and/or the like), comprising: sending the second network slice rule to the UE according to a first network slice rule matching request sent by the UE (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application), comprising: receiving the first network slice rule matching request sent by the UE (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application); or receiving a second network slice rule sent by the slice management server (see Jagannatha, Fig. 1A, par. [0023]: in FIG. 1A, and reference number 102, to configure the UE to use a URSP rule associated with one or more applications, one or more network function devices, included in the one or more networks, can transmit a URSP to the UE. For example, a PCF device on the network can generate and maintain the URSP, and can transmit the URSP to the UE via a session management function (SMF) device, a user plane function (UPF) device, a base station, and/or the like), wherein the second slice rule refers to a new version of the network slice rule acquired by the slice management server (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE, and see Fig. 4, par. [0052]: Network function devices 415 include one or more devices capable of communicating with UE 405, with base station 410, with data network 420, and/or the like. In some implementations, network function devices 415 can include a user plane function (UPF) device, a session management function (SMF) device, an access and mobility management function (AMF) device, a policy control function (PCF) device, a network slice selection function (NSSF) device; in this case, the network function device (i.e. slice management server) generates updated URSP (corresponding to a new version of the network slice rule)), and the network slice rule is a user equipment Route Selection Policy (URSP) rule (see Jagannatha, Fig. 2, par. [0040]: in example network mapping 200, the URSP can include a URSP rule, associated with application 1, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 1. As another example, the URSP can include a URSP rule, associated with application 2, that specifies that network slice 1 and data network 1 are to be used for a data session associated with application 2. As another example, the URSP can include a URSP rule, associated with application 3, that includes a first route selection descriptor that specifies network slice 2 and data network 1 are to be used for a data session associated with application 3, and that includes a second route selection descriptor that specifies network slice 1 and data network m are to be used for the data session associated with application 3. In this way, an APH component, included in the UE, can attempt to establish the data session using the first route selection descriptor, and can attempt to establish the data session using the second route selection descriptor if the attempt to establish the data session using the first route selection descriptor is unsuccessful) in response to a connection being established with the slice management server arranged on the user plane of the core network, sending a first network slice rule matching request to the slice management server (see Jagannatha, Fig. 1A, par. [0023]: in FIG. 1A, and reference number 102, to configure the UE to use a URSP rule associated with one or more applications, one or more network function devices, included in the one or more networks, can transmit a URSP to the UE. For example, a PCF device on the network can generate and maintain the URSP, and can transmit the URSP to the UE via a session management function (SMF) device, a user plane function (UPF) device, a base station, and/or the like. In some implementations, the one or more network function devices can transmit the URSP to the UE based on an event (e.g., based on the UE communicatively connecting to a base station included in the one or more networks, based on the UE installing a new application on the UE, and/or the like), at a particular time interval, based on receiving a request from the UE for the URSP, and/or the like, and see par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application), so that the slice management server sends the second network slice rule to the UE according to the first network slice rule matching request (see Jagannatha, par. [0033]: the UE can receive an updated URSP from one or more network function devices included in the one or more networks. For example, the one or more network function devices, included in the one or more networks, can generate the updated URSP by updating the information included in the URSP (e.g., by modifying the information included in the URSP, by adding additional information to the URSP, by removing information from the URSP, and/or the like), and can transmit the updated URSP to the UE (e.g., based on generating the updated URSP, based on a periodic schedule for transmitting URSP updates to the UE, based on receiving a request from the UE for the updated URSP, and/or the like). In this way, the URSP can be updated to provide new URSP rules for newly supported applications, can be updated to modify a URSP rule associated with an application), Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the second slice rule of the combination of Bogineni in view of Xing with the USRP and sending or receiving the rule of Jagannatha with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving efficiency and decreasing latency (see Jagannatha, par. [0013]). However, the combination of Bogineni in view of Xing, and further in view of Jagannatha, does not teach: wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request; and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule; or wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE; and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule. Ding, in the same field of endeavor, teaches: wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE (see Ding, Fig. 6, pars. [0216-0219]: Step 601: The UE sends a registration request to an AME Correspondingly, the AMF may receive the registration request. The registration request may be a registration request corresponding to initial registration of the UE in 5G, or may be a mobility registration request initiated when the UE is handed over from 4G to 5G. In the registration request, the UE carries a PSI list (List of stored PSIs) to notify the PCF of a locally stored user policy list, and further carries a banned PSI or a banned APP ID of the UE. One PSI corresponds to one or more URSPs. Specifically, the registration request carries a UE policy container, where the UE policy container includes the list of stored PSIs, and includes the banned PSI or the banned APP ID. Optionally, the UE policy container further includes an OS ID, and an indication of UE support for ANDSP. The banned PSI refers to a PSI that does not need to be used in PSIs locally stored by the UE. The banned APP ID is an identifier of an application that does not need to be used or is not installed on the UE. The APP ID herein may be in a form of traffic description information, or may be in a form of a URSP rule ID; in this case, the request includes URSP information of the UE for checking a list of information (corresponding to the request being configured for checking a version of a rule)); matching the second network slice rule with the first network slice rule built in the UE according to the first network slice rule matching request (see Ding, Fig. 6, pars. [0230-0231]: Step 606: The PCF decides to generate a URSP. Specifically, if the PCF determines that the URSP corresponding to the PSI list sent by the UE is different from the URSP obtained by the PCF from the UDR, the PCF determines that a URSP needs to be regenerated; in this case, comparing URSP corresponds to matching slice rules); and in response to a determination that the first network slice rule does not match the second network slice rule, sending the second network slice rule to the UE for replacing the first network slice rule built in the UE with the second network slice rule (see Ding, Fig. 6, pars. [0230-0238]: Step 606: The PCF decides to generate a URSP. Specifically, if the PCF determines that the URSP corresponding to the PSI list sent by the UE is different from the URSP obtained by the PCF from the UDR, the PCF determines that a URSP needs to be regenerated. Methods in which the PCF regenerates the URSP include but are not limited to the following two methods: Method 1: The PCF determines a URSP corresponding to the banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604), and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Method 2: The PCF obtains a combined banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604) and the banned APP ID obtained from the UDR, determines a URSP corresponding to the combined banned APP ID, and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Step 607: The PCF sends a user policy association establishment response to the AME Correspondingly, the AMF may receive the user policy association establishment response. The user policy association establishment response may carry a trigger event list subscribed by the PCF from the AMF. Step 607 may be performed after step 603 and before step 608. Step 608: The PCF sends the URSP generated in step 606 to the UE in a UE configuration update procedure); or wherein the first network slice rule matching request is configured for checking a version of a first network slice rule built in the UE (see Ding, Fig. 6, pars. [0216-0219]: Step 601: The UE sends a registration request to an AME Correspondingly, the AMF may receive the registration request. The registration request may be a registration request corresponding to initial registration of the UE in 5G, or may be a mobility registration request initiated when the UE is handed over from 4G to 5G. In the registration request, the UE carries a PSI list (List of stored PSIs) to notify the PCF of a locally stored user policy list, and further carries a banned PSI or a banned APP ID of the UE. One PSI corresponds to one or more URSPs. Specifically, the registration request carries a UE policy container, where the UE policy container includes the list of stored PSIs, and includes the banned PSI or the banned APP ID. Optionally, the UE policy container further includes an OS ID, and an indication of UE support for ANDSP. The banned PSI refers to a PSI that does not need to be used in PSIs locally stored by the UE. The banned APP ID is an identifier of an application that does not need to be used or is not installed on the UE. The APP ID herein may be in a form of traffic description information, or may be in a form of a URSP rule ID; in this case, the request includes URSP information of the UE for checking a list of information (corresponding to the request being configured for checking a version of a rule)); and in response to receiving the second network slice rule sent by the slice management server, replacing the first network slice rule built in the UE with the second network slice rule (see Ding, Fig. 6, pars. [0230-0238]: Step 606: The PCF decides to generate a URSP. Specifically, if the PCF determines that the URSP corresponding to the PSI list sent by the UE is different from the URSP obtained by the PCF from the UDR, the PCF determines that a URSP needs to be regenerated. Methods in which the PCF regenerates the URSP include but are not limited to the following two methods: Method 1: The PCF determines a URSP corresponding to the banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604), and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Method 2: The PCF obtains a combined banned APP ID based on the banned APP ID (where the banned APP ID may be carried in step 601 or determined in step 604) and the banned APP ID obtained from the UDR, determines a URSP corresponding to the combined banned APP ID, and then removes the URSP corresponding to the banned APP ID from the URSP obtained from the UDR, to obtain the regenerated URSP. Step 607: The PCF sends a user policy association establishment response to the AME Correspondingly, the AMF may receive the user policy association establishment response. The user policy association establishment response may carry a trigger event list subscribed by the PCF from the AMF. Step 607 may be performed after step 603 and before step 608. Step 608: The PCF sends the URSP generated in step 606 to the UE in a UE configuration update procedure, and see par. [0211]: In an example, the UE carries an allowed list (6), PSIs carried by the UE are PSI A (1, 2, 3) and PSI B (4), and the UDR stores PSI A (1, 2, 3) and PSI C (4). The PCF decides that an obtained final URSP policy is (1, 2, 3, 4, 6). In this case, the PCF may update the URSP in the UE in a manner of PSI D (4, 6)+PSI B ( ), or directly update the URSP in the UE in a form of PSI D (1, 2, 3, 4, 6)+PSI A ( )+PSI B ( )). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the matching request of the combination of Bogineni in view of Xing, and further in view of Jagannatha, with the request for checking a version, matching, sending updated rules, and replacing updated rules of Ding with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing signaling overhead (see Ding, par. [0213]). Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Bogineni in view of Xing, and further in view of Jagannatha, and further in view of Ding, as applied to claims 1, 3-4, 7, 12, and 14 above, and further in view of Liu (US 2023/0247541), hereinafter “Liu”. Regarding claim 10, the combination of Bogineni in view of Xing, and further in view of Jagannatha, and further in view of Ding, teaches the method. The combination of Bogineni in view of Xing does not teach, but Jagannatha teaches: further comprising: saving the second network slice rule (see Jagannatha, par. [0019]: the APH component, included in the UE, is capable of receiving, storing, and/or using a URSP rule, included in a URSP). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the second slice rule of the combination of Bogineni in view of Xing with the saving the rule of Jagannatha with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving efficiency and decreasing latency (see Jagannatha, par. [0013]). However, the combination of Bogineni in view of Xing, and further in view of Jagannatha, and further in view of Ding, does not teach: encrypting the second network slice rule. Liu, in the same field of endeavor, teaches: encrypting the second network slice rule (see Liu, par. [0073], lines 17-26: when the terminal sends a slice registration request to the network operator, it can send the encryption identity to the network operator. Based on the encryption identity, the network operator obtains the application identity corresponding to the encryption identity through decryption or a mapping relationship, etc., thereby activating the slice configuration for the application requested by the terminal, and notifies the terminal that the slice configuration for the application has been activated). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of combination of Bogineni in view of Xing, and further in view of Jagannatha, and further in view of Ding, with the encryption of the slice rule of Liu with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving the security of the service slice activation (see Liu, par. [0186]). Response to Arguments Applicant’s arguments with respect to claims 1, 7, and 14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: De Foy et al. (US 2023/0379985) teaches a network entity running a policy control function (PCF), may send to a wireless receive and transmit unit (WTRU) at least one WTRU route selection policy (URSP) rule associated with, for example, PvD descriptors. Huang-Fu et al. (US 2020/0053622) teaches a method for UE route selection policy (URSP) rule matching. Salkintzis (US 2023/0070259) teaches an apparatus receiving a data packet to be transmitted and determining a matching UE route selection policy (“URSP”) rule for the data packet. Zhu et al. (US 2020/0260330) teaches a method for obtaining, by a first network device, one or more priorities of one or more network slices in a first network slice set for providing a service to an application; and sending, by the first network device, a correspondence between the one or more priorities and the one or more network slices in the first network slice set to a second network device, where a terminal route selection policy on a terminal is updated based on the correspondence. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CALEB J BALLOWE whose telephone number is (571)270-0410. The examiner can normally be reached MON-FRI 7:30-5. 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, Nishant B. Divecha can be reached at (571) 270-3125. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /C.J.B./Examiner, Art Unit 2419 /Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Read full office action

Prosecution Timeline

Feb 07, 2023
Application Filed
Apr 28, 2025
Non-Final Rejection — §103
Jul 31, 2025
Response Filed
Sep 03, 2025
Final Rejection — §103
Dec 09, 2025
Request for Continued Examination
Dec 19, 2025
Response after Non-Final Action
Jan 14, 2026
Non-Final Rejection — §103 (current)

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
14%
Grant Probability
61%
With Interview (+46.4%)
3y 1m
Median Time to Grant
High
PTA Risk
Based on 14 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month