Prosecution Insights
Last updated: July 17, 2026
Application No. 18/324,200

SYSTEMS AND METHODS FOR ON-DEMAND NETWORK CONTROLS

Non-Final OA §102§103
Filed
May 26, 2023
Examiner
CHOI, WON JUN
Art Unit
2411
Tech Center
2400 — Computer Networks
Assignee
Verizon Communications Inc.
OA Round
3 (Non-Final)
69%
Grant Probability
Favorable
3-4
OA Rounds
6m
Est. Remaining
81%
With Interview

Examiner Intelligence

Grants 69% — above average
69%
Career Allowance Rate
25 granted / 36 resolved
+11.4% vs TC avg
Moderate +12% lift
Without
With
+11.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 7m
Avg Prosecution
30 currently pending
Career history
80
Total Applications
across all art units

Statute-Specific Performance

§101
0.4%
-39.6% vs TC avg
§103
89.3%
+49.3% vs TC avg
§102
8.2%
-31.8% vs TC avg
§112
1.4%
-38.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 36 resolved cases

Office Action

§102 §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 . Response to Amendment This communication is considered fully responsive to the amendment filed on 10/06/2025. Claims 1, 3, 6, and 11-18 have been amended. Objection to claim 12 is withdrawn since it has been amended accordingly. Response to Arguments Applicant’s arguments with respect to claims 1-20 filed on 10/06/2025 have been considered but are moot because the applicant’s arguments were drawn to newly added features to independent claims, which have been addressed in the instant office action with previously identified prior art by mapping the relevant teachings for more clarification thereof that read on said added feature are moot. Claim Rejections - 35 USC § 102 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1-3, 5-8, 11-13, 18, and 19 are rejected under 35 U.S.C. 102(a)(1) as anticipated by U.S. Patent Application Publication NO. 2020/0275304 to Zhao et al (hereinafter “Zhao”). Examiner’s note: in what follows, references are drawn to Zhao unless otherwise mentioned. With respect to independent claims 1, 11, and 18: Regarding Claim 1, Zhao teaches A method, comprising: receiving, by a network device and via an external interface, a service request, from an application in a data network, for a bearer associated with an external application (Fig. 4 and para [0067]: As shown, a server 320 (interpreted as “a data network”) may be coupled to the network, e.g., to the core network or EPC 100 (interpreted as “a network device”). The server 320 may be configured to provide (send and/or receive) data (or content) through the network 100 …) (para [0081]: For example, current 3GPP standards may provide for a “bearer resource allocation request message” which may be transmitted from an application operator (e.g., application server 320) to a core network entity (e.g., an MME 322 and/or a policy and charging rules function (PCRF)). Such a request may be made over an Rx interface (interpreted as “via an external interface, a service request, from an application in a data network, for a bearer associated with an external application”). Current standards may allow a non-carrier server (e.g., app server 320) to connect to PCRF through the Rx interface)(Fig. 7 and para [0107]: …, the app server 320 may transmit a request for enhanced QoS over the Rx interface.; performing, by the network device, authentication and authorization for the service request (para [0093]: Based on the request (and the included information), the PGW/PCEF (interpreted as “the network device”) may check with a PCRF to determine whether or not to grant the request.); generating, by the network device, a network configuration request for a core network, based on information in the service request (para [0093]: Based on granting the request, the PGW/PCEF may transmit a confirmation to the UE and may begin to set up the dedicated bearer (interpreted as “generating … a network configuration request for a core network”) (para [0116]: The PGW 716/SGW 717 may also send a “create bearer request” to the MME 322 to create a dedicated bearer, e.g., based on granting the request (805).); and sending, by the network device and in response to receiving the service request, the network configuration request to an exposure function in the core network (para [0163]: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending, … , the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320. The dedicated bearer may be a dedicated end-to-end pipeline from the UE 106 to the app server 320, e.g., including any component connections (e.g., UE 106 to base station 102, base station 102 to gateway 716, gateway 716 to any intermediate network elements, intermediate network elements to app server 320, etc.) Each component connection of the dedicated end-to-end pipeline may be configured so that the entire end-to-end pipeline provides the desired QoS.). Regarding claim 11, it is a network device claim corresponding to the method claim 1, except the limitations “one or more network devices (FIG. 1; eNodeB 102, Evolved Packet Core (EPC) 100, and App Server 320), comprising: one or more processors” (FIG. 5 and para [0075]: FIG. 5 is an example block diagram of a base station 102. The base station 102 may be an eNodeB, a gNB, or an access point, among various possibilities … As shown, the base station 102 may include a processing element, such as processor(s) 504 which may execute program instructions for the base station 102..) and is therefore rejected for the similar reasons set forth in the rejection of claim 1. Regarding claim 18, it is a non-transitory computer-readable medium claim corresponding to the method claim 1, except the limitations “non-transitory computer-readable medium” (FIG. 5 and para [0079]: The processing element, such as processor(s) 504, of the base station 102 may be configured to implement part or all of the methods described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium)) and is therefore rejected for the similar reasons set forth in the rejection of claim 1. With respect to dependent claims: Regarding Claim 2, Zhao teaches The method of claim 1, wherein the service request includes: (FIGs. 9-14 and para [0111]: For example, the request may include any or all of: a requested quality of service (QOS) level for a flow (para [0113]: Flow information, including treatment and differentiated services code point (DSCP) values, e.g., to indicate QoS requirements of the application traffic (interpreted as “a requested quality of service (QOS) level for a flow”), an application identifier (para [0112]: Application information, such as Application ID (interpreted as “an application identifier”), Name, Vendor, e.g., to identify the app and/or traffic of the app.), an application port (FIG. 12 and para [0138]: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“source port” in FIG. 12 is interpreted as “application port”) a user equipment (UE) port (FIG. 12 and para [0138]: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“Destination port” in FIG. 12 is interpreted as “user equipment (UE) port”), and a callback uniform resource locator (URL) (FIG. 12 and para [0138]: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“Destination IP address” in FIG. 12 is interpreted as “callback uniform resource locator (URL)”). Regarding Claim 3, Zhao teaches The method of claim 1, wherein the network device serves as an application function that interfaces with the data network and that interfaces with the exposure function in the core network (para [0065]: It will be appreciated that the core network may operate according to 5G and/or LTE, e.g., among various possible wireless standards. As shown, the EPC 100 may include a mobility management entity (MME) 322, a home subscriber server (HSS) 324, and a serving gateway (SGW) 326. The EPC 100 may also include various other devices known to those skilled in the art.)(para [0163]: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320(interpreted as “interfaces with the data network and that interfaces with the exposure function in the core network”)). Examiner’s note: The core network (EPC 100) of Zhao is interpreted as “the network device serves as an application function”. See para [0023] of the Specification of the instant application “For example, core devices 135 may include 5G network functions, such … an application function (AF)” ); wherein receiving the service request includes receiving the service request via an Internet Protocol (IP) interface (para [0111]: The request may be transmitted over user datagram protocol (UDP) port 3455 (The UDP is interpreted as “Internet Protocol (IP) interface”), among various possibilities. The request may be or include an RSVP Resv message with a 3GPP QoS object. The request message may include information for the QoS request and policy control.); and wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request via a non-IP interface (para [0140]: FIG. 14 illustrates a service quality IE, according to some embodiments. The service quality IE may carry an indication of the service quality measured or requested by the UE. An operation field of the IE may specify whether the indicated QoS characteristics are requested by the UE (e.g., for a dedicated bearer) or measured by the UE (e.g., for a specific bearer and/or in general). For example, the UE may use a service quality IE (e.g., of the request type) to specify QoS characteristics requested for a dedicated bearer associated with an app 710 (interpreted as “differentiated quality of service (QOS) flow request”)) (para [0163]: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending, … , the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320.). Regarding Claim 5, Zhao teaches The method of claim 1, wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request to a service capability exposure function (SCEF) for a 4G network (para [0140]: FIG. 14 illustrates a service quality IE, according to some embodiments. The service quality IE may carry an indication of the service quality measured or requested by the UE. An operation field of the IE may specify whether the indicated QoS characteristics are requested by the UE (e.g., for a dedicated bearer) or measured by the UE (e.g., for a specific bearer and/or in general). For example, the UE may use a service quality IE (e.g., of the request type) to specify QoS characteristics requested for a dedicated bearer associated with an app 710 (interpreted as “differentiated quality of service (QOS) flow request”)) (para [0163]: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending, … , the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320.). Regarding Claim 6, Zhao teaches The method of claim 1, wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request to a network exposure function (NEF) for a 5G network (para [0140]: FIG. 14 illustrates a service quality IE, according to some embodiments. The service quality IE may carry an indication of the service quality measured or requested by the UE. An operation field of the IE may specify whether the indicated QoS characteristics are requested by the UE (e.g., for a dedicated bearer) or measured by the UE (e.g., for a specific bearer and/or in general). For example, the UE may use a service quality IE (e.g., of the request type) to specify QoS characteristics requested for a dedicated bearer associated with an app 710 (interpreted as “differentiated quality of service (QOS) flow request”)) (para [0163]: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending the differentiated quality of service (QOS) flow request to the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320.) (para [0171]: It is noted that FIG. 19 merely illustrates relationships among certain example UE-side and networked or external entities and should not be construed to narrow the scope or spirit of the subject matter described herein, and that various other embodiments of such systems and methods are possible. For example, 5G core network standards may allow an application server (e.g., 320) to connect to a user plane function (UPF) 1910 and/or network exposure function (NEF) 1920 and to send request for a specified QoS with a UE.). Regarding Claim 7, Zhao teaches The method of claim 1, wherein the service request includes one of: a request to create a quality of service (QOS) session (para [0093]: Based on granting the request, the PGW/PCEF may transmit a confirmation to the UE and may begin to set up the dedicated bearer (interpreted as “generating … a network configuration request for a core network”) (para [0116]: The PGW 716/SGW 717 may also send a “create bearer request” to the MME 322 to create a dedicated bearer, e.g., based on granting the request (805).), a request to update an existing QoS session, or a request to delete a QoS session. Regarding Claim 8, Zhao teaches The method of claim 1, wherein the service request identifies a type of differentiated quality of service (QOS) for the bearer (para [0008]: The UE may transmit a request to the network for a dedicated bearer or enhanced QoS flow for the application traffic. The UE may indicate requested QoS configuration parameters and other parameters for the bearer/flow.)(para [0009]: The UE may use an extended Resource ReSerVation Protocol (RSVP) to communicate about the request and associated parameters with the network.)(para [0150]: The new RSVP object may be referred to as “3GPP QoS Object”. The format may follow RFC 2205. The 3GPP QoS object may have class=239, c-type=1 and a list of Information Elements. The format of information element (IE) may be as illustrated in FIG. 9, according to some embodiments. Thus, the IE may specify the length of the IE, and the type of the IE.). See FIGs 9-14 of Zhao. Regarding Claim 12, Zhao teaches The one or more network devices of claim 11, wherein the one or more network devices serve as an application function that interfaces with the data network and the exposure function in the core network (para [0065]: It will be appreciated that the core network may operate according to 5G and/or LTE, e.g., among various possible wireless standards. As shown, the EPC 100 may include a mobility management entity (MME) 322, a home subscriber server (HSS) 324, and a serving gateway (SGW) 326. The EPC 100 may also include various other devices known to those skilled in the art.)(para [0163]: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320(interpreted as “interfaces with the data network and the exposure function in the core network”)). Examiner’s note: The core network (EPC 100) of Zhao is interpreted as “the one or more network devices serve as an application functi”. See para [0023] of the Specification of the instant application “For example, core devices 135 may include 5G network functions, such … an application function (AF)” ); and wherein, when receiving the service request, the one or more processor are further configured to: receive the service request via a dedicated application programming interface (API) using Internet Protocol (para [0085]: The request may be received via an application programming interface (API), e.g., a QoS API. A QoS API may provide an interface for applications executing on the UE to request enhanced QoS for communications with an application server (e.g., the application server 320) (para [0111]: The request may be transmitted over user datagram protocol (UDP) port 3455 (The UDP is interpreted as “Internet Protocol (IP) interface”),...). Regarding Claim 13, Zhao teaches The one or more network devices of claim 12, wherein the one or more processor are further configured to: send, using the dedicated API, a subscription identifier and quality of service (QOS) status for a flow associated with the service request (para [0008]: The UE may transmit a request to the network for a dedicated bearer or enhanced QoS flow for the application traffic. The UE may indicate requested QoS configuration parameters and other parameters for the bearer/flow.)(para [0009]: The UE may use an extended Resource ReSerVation Protocol (RSVP) to communicate about the request and associated parameters with the network.)(para [0092]: The Resv message may include a “3GPP QoS Object” as further described below. The object may include application profile and QoS information (interpreted as “a subscription identifier and quality of service (QOS) status”), e.g., which may be necessary for the PGW/PCEF to grant the request and/or to implement the dedicated bearer for the application.). Regarding Claim 19, Zhao teaches The non-transitory computer-readable medium of claim 18, further comprising one or more instructions for: receiving the service request via a dedicated API using Internet Protocol (para [0085]: The request may be received via an application programming interface (API), e.g., a QoS API. A QoS API may provide an interface for applications executing on the UE to request enhanced QoS for communications with an application server (e.g., the application server 320) (para [0111]: The request may be transmitted over user datagram protocol (UDP) port 3455 (The UDP is interpreted as “Internet Protocol”),...); and send, to an external network function and using the dedicated API, a subscription identifier and quality of service (QOS) status for a flow associated with the service request (para [0008]: The UE may transmit a request to the network for a dedicated bearer or enhanced QoS flow for the application traffic. The UE may indicate requested QoS configuration parameters and other parameters for the bearer/flow.)(para [0009]: The UE may use an extended Resource ReSerVation Protocol (RSVP) to communicate about the request and associated parameters with the network.)(para [0092]: The Resv message may include a “3GPP QoS Object” as further described below. The object may include application profile and QoS information (interpreted as “a subscription identifier and quality of service (QOS) status”), e.g., which may be necessary for the PGW/PCEF to grant the request and/or to implement the dedicated bearer for the application.). Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 4, 14, 15 and 16 rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of 3GPP Technical Specification 23.501 V16.16.0 (uploaded date: March 31, 2023) (hereinafter “3GPP TS 23.501”). Examiner’s note: in what follows, references are drawn to Zhao unless otherwise mentioned. Regarding Claim 4, Zhao teaches The method of claim 1, wherein sending the network configuration request includes sending the network configuration request to the exposure function (para [0163]: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending, … , the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320.) via one of a T8 interface or an N33 interface. It is noted that while disclosing the claimed feature “sending the network configuration request to the exposure function” (see para [0163] of Zhao), Zhao does not specifically teach about the T8 interface or N33 interface. It, however, had been known in the art before the effective date of the instant application as shown by 3GPP TS 23.501, page 238, as follows; … For external exposure of services related to specific UE(s), the SCEF+NEF resides in the HPLMN. Depending on operator agreements, the SCEF+NEF in the HPLMN may have interface(s) with NF(s)(“Network Function(s)”) in the VPLMN.). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Zhao's method by using a T8 interface or an N33 interface defined in 3GPP Technical Specification 23.501 in order to have sent the network configuration request to the exposure function via the one of a T8 interface or an N33 interface (see page 238 of 3GPP TS 23.501 V16.16.0). Regarding Claim 14, Claim 14, has similar limitation as of Claim(s) 4, therefore it is rejected under the same reasons as Claim(s) 4. Regarding Claim 15, Claim 15, has similar limitation as of Claim(s) 4, therefore it is rejected under the same reasons as Claim(s) 4. Regarding Claim 16, Zhao teaches The one or more network device of claim 11, wherein the service request includes: (FIGs. 9-14 and para [0111]: For example, the request may include any or all of: a requested quality of service (QOS) level for a service flow (para [0113]: Flow information, including treatment and differentiated services code point (DSCP) values, e.g., to indicate QoS requirements of the application traffic (interpreted as “a requested quality of service (QOS) level for a flow”), an application identifier (para [0112]: Application information, such as Application ID (interpreted as “an application identifier”), Name, Vendor, e.g., to identify the app and/or traffic of the app.), an application IP address (FIG. 12 and para [0138]: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“source IP address” in FIG. 12 is interpreted as “an application IP address”) a user equipment (UE) IP address (FIG. 12 and para [0138]: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“Destination IP address” in FIG. 12 is interpreted as “a user equipment (UE) IP address”), and a duration for terminating the requested service. Zhao does not explicitly teach a duration for terminating the requested service. It, however, had been known in the art before the effective date of the instant application as shown by 3GPP TS 23.501, as follows. In page 119, Table 5.6.7-1 of 3GPP TS 23.501: discloses “Information element contained in AF request”. In Table 5.6.7-1, 3GPP TS 23.501 discloses the information of “Temporal Validity Condition : Time interval(s) or duration(s)”. In page 121, 3GPP TS 23.501 discloses that “Temporal validity condition. This is provided in the form of time interval(s) or duration(s) during which the AF request is to be applied.” Claim(s) 9 and 20 rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of U.S. Patent Application Publication No. 2023/0108693 to Cao et al (hereinafter “Cao”). Regarding Claim 9, Zhao teaches The method of claim 1, further comprising: Zhao does not explicitly disclose sending, in response to receiving the service request, a subscriber profile identifier (SPID) update to a network function in the core network. In analogous art, Cao teaches the claimed feature “sending, in response to receiving the service request, a subscriber profile identifier (SPID) update to a network function in the core network.” (Para [0127] of Cao: The QoS parameter request may further include the service requirement information of the user (interpreted as “in response to receiving the service request”) and a radio network resource of the second network element in addition to the second QoS parameter, or may further include the service requirement information of the user, the attribute information of the user, and a radio network resource of the second network element in addition to the second QoS parameter. In this case, the attribute information of the user may include at least one of the following information: the identifier of the UE, a QFI, the user priority, a subscriber profile identifier (subscriber profile identifier, SPID), and an indication indicating that a terminal device of the user has a high access priority (high priority access). The high priority access may be sent by the UE to the AN network element when the UE initially accesses a network. The SPID may be sent by the AMF of the core network to the AN network element (interpreted as “a network function in the core network”) when the UE registers with the network, and indicates information about a preferential RAT or frequency for the UE.)(para [0130] of Cao: If the foregoing case is caused, the first radio access controller may determine the new first QoS parameter, namely, an updated QoS parameter (an updated QoS profile), by using an artificial intelligence method with reference to information such as the user priority, the SPID, the high priority access, the media type, the bandwidth requirement, and the available radio network resource.) Zhao and Cao are both considered to be analogous to the claimed invention because they are in the same field of network communication. Therefore, it would have been obvious to someone to have modified Zhao's method to incorporate the teaching of Cao and dynamically managed QoS of the AN network element. Doing so would possible to effectively use the radio network resource and maximize efficiency (see para [0143] of Cao). Regarding Claim 20, Zhao teaches The non-transitory computer-readable medium of claim 18, further comprising one or more instructions for: Cao teaches dynamically updating, based on sending the network configuration request, a subscriber profile identifier (SPID) in the core network (Para [0127] of Cao: The QoS parameter request may further include the service requirement information of the user and a radio network resource of the second network element in addition to the second QoS parameter, or may further include the service requirement information of the user (interpreted as “in response to receiving the service request”), the attribute information of the user, and a radio network resource of the second network element in addition to the second QoS parameter. In this case, the attribute information of the user may include at least one of the following information: the identifier of the UE, a QFI, the user priority, a subscriber profile identifier (subscriber profile identifier, SPID), and an indication indicating that a terminal device of the user has a high access priority (high priority access). The high priority access may be sent by the UE to the AN network element when the UE initially accesses a network. The SPID may be sent by the AMF of the core network to the AN network element when the UE registers with the network, and indicates information about a preferential RAT or frequency for the UE.)(para [0130] of Cao: the first radio access controller may determine the new first QoS parameter, namely, an updated QoS parameter (an updated QoS profile), by using an artificial intelligence method with reference to information such as the user priority, the SPID, the high priority access, the media type, the bandwidth requirement, and the available radio network resource.). Claim(s) 10 rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of U.S. Patent Application Publication No. 2015/0271827 to Hamalainen et al (hereinafter “Hamalainen”). Examiner’s note: in what follows, references are drawn to Zhao unless otherwise mentioned. Regarding Claim 10, Zhao teaches The method of claim 1, further comprising Zhao does not explicitly teach initiating dynamic provisioning of radio access technology (RAT) frequency selection priority (RFSP) values in response to the service request. Zhao discusses that, in para [0067], various connections that make up the end-to-end bearer 350 may each include specific QoS characteristics. For some of the connections, the QoS characteristics may be indicated by QoS class indicator (QCI). For example, a connection (or bearer) between the UE 106 and the base station 102 may be configured with a first QCI.(Examiner’s note: The first QCI is associated with claimed feature “radio access technology (RAT) frequency selection priority (RFSP) values”. See para [0013] of the Specification of the instant application: The RFSP values are closely associated with QoS class identifier (QCI) values for end-to-end QoS support across the network.). It is noted that while disclosing the QoS class indicator (QCI), Zhao does not specifically teach about the initiating dynamic provisioning of radio access technology (RAT) frequency selection priority (RFSP) values in response to the service request. It, however, had been known in the art before the effective date of the instant application as shown by Hamalainen, as follows; initiating dynamic provisioning of radio access technology (RAT) frequency selection priority (RFSP) values in response to the service request. (para [0091] of Hamalainen: A RRM (“Radio Resource Management”) function that is implemented in the base station may utilize the provided parameters for example QoS parameters or RFSP Index. RRM (Radio Resource Management)(para [0121] of Hamalainen: The HSS may provide a number of subscriber parameters (which may be modified by the CEMO) to base station through MME like QCI (QoS parameters) or RFSP index.)(para [0121] of Hamalainen: When a need to changing a priority for a user is detected, a new RFSP Index value is provisioned to user profile in HSS.) Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Zhao's method by using the features of Hamalainen in order to have individually controlled based on the RRM (see para [0070-0071] of Hamalainen). Claim(s) 17 rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of Cao and further in view of Hamalainen. Regarding Claim 17, Zhao teaches The one or more network devices of claim 11, wherein the one or more processors are further configured to: Cao teaches send, in response to receiving the service request, a subscriber profile identifier (SPID) update to a network function in the core network (Para [0127] of Cao: The QoS parameter request may further include the service requirement information of the user (interpreted as “in response to receiving the service request”) and a radio network resource of the second network element in addition to the second QoS parameter, or may further include the service requirement information of the user, the attribute information of the user, and a radio network resource of the second network element in addition to the second QoS parameter. In this case, the attribute information of the user may include at least one of the following information: the identifier of the UE, a QFI, the user priority, a subscriber profile identifier (subscriber profile identifier, SPID), and an indication indicating that a terminal device of the user has a high access priority (high priority access). The high priority access may be sent by the UE to the AN network element when the UE initially accesses a network. The SPID may be sent by the AMF of the core network to the AN network element (interpreted as “a network function in the core network”) when the UE registers with the network, and indicates information about a preferential RAT or frequency for the UE.)(para [0130] of Cao: If the foregoing case is caused, the first radio access controller may determine the new first QoS parameter, namely, an updated QoS parameter (an updated QoS profile), by using an artificial intelligence method with reference to information such as the user priority, the SPID, the high priority access, the media type, the bandwidth requirement, and the available radio network resource.); and Hamalainen teaches initiate dynamic provisioning of radio access technology (RAT) frequency selection priority (RFSP) values in response to the service request . (para [0091] of Hamalainen: A RRM (“Radio Resource Management”) function that is implemented in the base station may utilize the provided parameters for example QoS parameters or RFSP Index. RRM (Radio Resource Management)(para [0121] of Hamalainen: The HSS may provide a number of subscriber parameters (which may be modified by the CEMO) to base station through MME like QCI (QoS parameters) or RFSP index.)(para [0121] of Hamalainen: When a need to changing a priority for a user is detected, a new RFSP Index value is provisioned to user profile in HSS.). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the combination of Zhao and Cao by using the features of Hamalainen in order to have individually controlled based on the RRM (see para [0070-0071] of Hamalainen). Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00. 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, Derrick W Ferris can be reached at 571-272-3123. 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. /WON JUN CHOI/Examiner, Art Unit 2411 /DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Read full office action

Prosecution Timeline

May 26, 2023
Application Filed
Jul 22, 2025
Non-Final Rejection mailed — §102, §103
Oct 06, 2025
Response Filed
Dec 17, 2025
Final Rejection mailed — §102, §103
Feb 02, 2026
Response after Non-Final Action
Mar 02, 2026
Request for Continued Examination
Mar 11, 2026
Response after Non-Final Action
Jul 16, 2026
Non-Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12671604
BUS CONTROLLED LIGHTING SYSTEM
4y 1m to grant Granted Jun 30, 2026
Patent 12592798
Communication Method and Communications Apparatus
3y 11m to grant Granted Mar 31, 2026
Patent 12574333
Multi Radio Media Access Control for Ultra-Low and Bounded Delay
4y 3m to grant Granted Mar 10, 2026
Patent 12568537
WIRELESS UPLINK COMMUNICATION SYSTEM
3y 8m to grant Granted Mar 03, 2026
Patent 12550166
Scrambling of Physical Broadcast Channel (PBCH)
3y 8m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
69%
Grant Probability
81%
With Interview (+11.7%)
3y 7m (~6m remaining)
Median Time to Grant
High
PTA Risk
Based on 36 resolved cases by this examiner. Grant probability derived from career allowance 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