DETAILED ACTION
In response to communication filed on 8/13/2026.
Claims 1-4,8-11,13-17,38-41, and 43 are pending.
Claims 1-4,8-11,13-17,38-41, and 43 are rejected.
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 Amendments
This communication is in response to Applicant’s reply filed under 3 CFR 1.111 on 8/13/2026. Claims 18,38 and 43 were amended, claims 6 and 42 were canceled, and claims 1-4,8-11,13-17,38-41, and 43 remain pending.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1,4,16,38,41, and 43 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sayenko et al. (US Pub. 2020/0374745)(S1 hereafter).
Regarding claims 1,38 and 43, S1 teaches a first network node (i.e. base station comprising a gNB)[paragraph 0024][refer Fig. 11][paragraph 0120] comprising a memory [refer Fig. 11; 1140] for storing computer instructions [paragraph 0124] and a processor (i.e. controller) in communication with the memory [refer Fig. 11; 1150], when the processor executes the computer instructions, the processor is configured [paragraph 0125] to cause the first network node to:
determine that a Data Radio Bearer (DRB)(i.e. a bearer) associated with a Protocol Data Unit (PDU) session of a wireless device (i.e. UE) is Explicit Congestion Notification (ECN) enabled (the network apparatus determines that a congestion control notification (ECN) is supported if the ECN field has a value of 01 or 10 for an IP header (i.e. PDU session))[paragraph 0053], via one of the following manners:
in response to all Quality of Service (QoS) flows in the DRB being ECN enabled, determining that the DRB is ECN enabled [paragraph 0059],
determine that a congestion occurs in the DRB (network apparatus may configure a counter for each UE, each bearer, or each IP flow (or QoS flow), may calculate the number of packets transmitted and received for each UE, each bearer, or each IP flow, and may detect data per UE, bearer, or IP flow that incurs congestion based on the counter values)[paragraph 0059]; and
transmit a first message to at least one of: a second network node, or the wireless device, the first message comprising congestion information of the congestion in the DRB (the network apparatus may calculate the number of packets transmitted and received for each UE, detects the cause of congestion by UE, bearer, or IP flow, selects data packets corresponding thereto (i.e. the claimed first message), and sets an ECN field to 11)[paragraph 0059].
Regarding claims 4 and 41, S1 teaches the congestion information is used by the second network node or the wireless device for congestion control on the DRB (i.e. bearer)[paragraph 0059], and the congestion information comprises an indication of a direction of the congestion in the DRB, the direction comprising an uplink direction, and a downlink direction (the network apparatus may configure a counter for each UE, each bearer, or each IP flow (or QoS flow), and calculates the number of packets transmitted and received (i.e. direction of congestion) for each UE, each bearer, or each IP flow, and detects data per UE, bearer, or IP flow that incurs congestion based on the counter values)[paragraph 0059].
Regarding claim 16, S1 teaches determining that the congestion occurs in the DRB comprises: receiving a fourth message from the wireless device, the fourth message indicating that the congestion occurs in the DRB (the network apparatus may configure a counter for each UE, each bearer, or each IP flow (or QoS flow), and calculates the number of packets transmitted and received (i.e. receiving message from UE) for each UE, each bearer, or each IP flow, and detects data per UE, bearer, or IP flow that incurs congestion based on the counter values)[paragraph 0059].
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 2,3,8-10,13,15,17,39 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Sayenko et al. (US Pub. 2020/0374745)(S1 hereafter) in view of Xu et al. (US Pub. 2024/0236765)(X1 hereafter).
Regarding claims 2 and 39, S1 doesn’t expressly disclose that the first network node comprises a Distributed Unit (DU) of a gNodeB (gNB) and the second network node comprises a Central Unit (CU) of the gNB.
X1 discloses that an access node, which comprises of a gNB [paragraph 0088], can comprise of one or more central units (CU) and one or more distributed nodes (DU) [paragraph 0096], in which a DU can indicate that an uplink/downlink packet of a service is congested, and sending the information to a CU through a tunnel corresponding to a data radio bearer [paragraph 0044].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of distributed and central units within a gNB to send congestion information accordingly as taught by X1. One would be motivated to do so to provide an improvement to data packet transmission security [refer X1; paragraph 0038].
Regarding claims 3 and 40, S1 doesn’t expressly disclose the first network node hosts a Radio Link Control (RLC) entity of a base station and the second network node hosts a Packet Data Convergence Protocol (PDCP) entity of the base station.
X1 discloses that an access node, which comprises of a gNB [paragraph 0088], can comprise of one or more central units (CU) and one or more distributed nodes (DU) [paragraph 0096], in which a DU can indicate that an uplink/downlink packet of a service is congested, and sending the information to a CU through a tunnel corresponding to a data radio bearer [paragraph 0044], the DU comprising of an RLC layer and the CU comprising of a PDCP layer [refer Fig. 2b][paragraph 0097].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of distributed and central units within a gNB to send congestion information accordingly as taught by X1. One would be motivated to do so to provide an improvement to data packet transmission security [refer X1; paragraph 0038].
Regarding claim 8, S1 fails to disclose receiving a third message from the second network node, the third message being indicative of all the QoS flows in the DRB are ECN enabled.
X1 discloses that an access node, which comprises of a gNB [paragraph 0088], can comprise of one or more central units (CU) and one or more distributed nodes (DU) [paragraph 0096], in which a DU can indicate that an uplink/downlink packet of a service is congested, and sending the information to a CU through a tunnel corresponding to a data radio bearer (i.e. sending message to second network node)[paragraph 0044], an access network device can generate information that includes transmission direction information and a QoS flow used to transmit data for a service [paragraph 0117], an ECN is indicated within an IP header of a sent packet to indicate uplink and downlink transmission congestion based upon the value [paragraph 0114].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of distributed and central units within a gNB to send congestion information as taught by X1. One would be motivated to do so to provide an improvement to data packet transmission security [refer X1; paragraph 0038].
Regarding claim 9, S1 fails to disclose the first message comprises an NR-U packet; and transmitting the first message comprises transmitting the first message to the second network node via an NR-U tunnel associated with the DRB.
X1 discloses that an access node, which comprises of a gNB [paragraph 0088], can comprise of one or more central units (CU) and one or more distributed nodes (DU) [paragraph 0096], in which a DU can indicate that an uplink/downlink packet of a service is congested, and sending the information to a CU through a tunnel corresponding to a data radio bearer [paragraph 0044], data packet PDU session between an access network device and terminal comprises GPRS tunneling protocol user plane packets (i.e. NR-U packet and tunnel)[paragraph 0148].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of distributed and central units within a gNB to send congestion information using a tunnel accordingly as taught by X1. One would be motivated to do so to provide an improvement to data packet transmission security [refer X1; paragraph 0038].
Regarding claim 10, S1 doesn’t expressly disclose transmitting the first message comprises transmitting the first message to the second network node via at least one of: an assistance information data PDU.
X1 discloses that an access node, which comprises of a gNB [paragraph 0088], can comprise of one or more central units (CU) and one or more distributed nodes (DU) [paragraph 0096], in which a DU can indicate that an uplink/downlink packet of a service is congested, and sending the information to a CU through a tunnel corresponding to a data radio bearer [paragraph 0044], a DU can send assistance information to a CU [paragraph 0171].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of distributed and central units within a gNB to send congestion information accordingly as taught by X1. One would be motivated to do so to provide an improvement to data packet transmission security [refer X1; paragraph 0038].
Regarding claim 13, S1 fails to disclose a reception of the first message on the second network node triggers the second network node to:
determine a direction of the congestion in the DRB, the direction comprising an uplink direction and a downlink direction; and for each QoS flow mapped to the DRB, and based on the direction of the congestion in the DRB, set an ECN field in an Internet Protocol (IP) header of an IP packet associated with the each QoS flow to indicate that a congestion occurs in the each QoS flow,
the IP packet is encapsulated in a user plane packet; the user plane packet comprises one of an uplink user plane packet and a downlink user plane packet; and
a direction of the user plane packet being indicated by the direction of the congestion in the DRB.
X1 discloses that an access node, which comprises of a gNB [paragraph 0088], can comprise of one or more central units (CU) and one or more distributed nodes (DU) [paragraph 0096], in which a DU can indicate that an uplink/downlink packet of a service is congested, and sending the information to a CU through a tunnel corresponding to a data radio bearer (i.e. sending message to second network node)[paragraph 0044], an access network device can generate information that includes transmission direction information and a QoS flow used to transmit data for a service [paragraph 0117], an ECN is indicated within an IP header of a sent packet to indicate uplink and downlink transmission congestion based upon the value [paragraph 0114]. X1 further notes that data packet PDU session between an access network device and terminal comprises GPRS tunneling protocol user plane packets (i.e. IP packets encapsulated in a user plane packet)[paragraph 0148].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of distributed and central units within a gNB to send congestion information and using user plane packet transmission accordingly as taught by X1. One would be motivated to do so to provide an improvement to data packet transmission security [refer X1; paragraph 0038].
Regarding claim 15, S1 teaches a reception of the first message on the wireless device triggers the wireless device to: determine a direction of the congestion in the DRB, the direction comprising an uplink direction and a downlink direction (the network apparatus may configure a counter for each UE, each bearer, or each IP flow (or QoS flow), and calculates the number of packets transmitted and received (i.e. direction of congestion) for each UE, each bearer, or each IP flow, and detects data per UE, bearer, or IP flow that incurs congestion based on the counter values)[paragraph 0059]; and
for each QoS flow mapped to the DRB, and based on the direction of the congestion in the DRB, set an ECN field in an IP header of an IP packet associated with the each QoS flow to indicate that a congestion occurs in the each QoS flow (the network apparatus may configure a counter for each UE, each bearer, or each IP flow (or QoS flow), and calculates the number of packets transmitted and received (i.e. direction of congestion) for each UE, each bearer, or each IP flow, and detects data per UE, bearer, or IP flow that incurs congestion based on the counter values)[paragraph 0059], a direction of the packet is indicated by the direction of the congestion in the DRB (the number of packets transmitted and received (i.e. direction of congestion) for each UE, each bearer, or each IP flow, and detects data per UE, bearer, or IP flow that incurs congestion based on the counter values)[paragraph 0059].
However, S1 fails to explicitly disclose the IP packet is encapsulated in a user plane packet; the user plane packet comprises one of an uplink user plane packet and a downlink user plane packet; and
a direction of the user plane packet being indicated by the direction of the congestion in the DRB.
X1 discloses the indication that an uplink/downlink packet of a service is congested, and sending the information through a tunnel corresponding to a data radio bearer (i.e. sending message to second network node)[paragraph 0044], an access network device can generate information that includes transmission direction information and a QoS flow used to transmit data for a service [paragraph 0117], an ECN is indicated within an IP header of a sent packet to indicate uplink and downlink transmission congestion based upon the value [paragraph 0114]. X1 further notes that data packet PDU session between an access network device and terminal comprises GPRS tunneling protocol user plane packets (i.e. IP packets encapsulated in a user plane packet)[paragraph 0148].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of user plane packet transmissions accordingly as taught by X1. One would be motivated to do so to use of a known technique in the field of endeavor to yield predictable results.
Regarding claim 17, S1 doesn’t expressly disclose the fourth message comprises a MAC CE message; and the MAC CE message comprises at least one of: a first indicator indicating that the congestion occurs in the DRB; or a second indicator indicating a direction of the congestion in the DRB.
X1 discloses that an access node, which comprises of a gNB [paragraph 0088], can comprise of one or more central units (CU) and one or more distributed nodes (DU) [paragraph 0096], in which a DU can indicate that an uplink/downlink packet of a service is congested, and sending the information to a CU through a tunnel corresponding to a data radio bearer [paragraph 0044], a control message can comprise of a MAC CE message can include congestion information (i.e. ECN)[paragraph 0181].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate handling congestion information using a MAC CE data packet as taught by X1. One would be motivated to do so to use of a known technique in the field of endeavor to yield predictable results.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over S1 in view of Centonza et al. (US Pub. 2022/0174515)(C1 hereafter).
Regarding claim 11, S1 doesn’t expressly disclose first message comprises a control plane message, the control plane message comprising a GNB-DU STATUS INDICATION message; and the congestion information comprising at least one of: a list of wireless devices, the wireless device being a member of the list of wireless devices.
C1 discloses the use of a gNB-DU status indication that contains a list of cells affected by an overload condition (i.e. congestion)[paragraph 0050], each cell within a DU’s coverage comprises of UEs (i.e. wireless devices) and are used to determine resources for network access UE related traffic [paragraph 0018].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of a gNB-DU status indication messaging that includes identification of a cells that have an overloaded condition as taught by C1. One would be motivated to do so to provide identification of any severity, such as load level, of an issue within a DU [refer C1; paragraph 0020].
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over S1 in view of Tesanovic et al. (US Pub. 2023/0284083)(T1 hereafter).
Regarding claim 14, S1 doesn’t expressly disclose the first message comprises a Medium Access Control - Control Element (MAC CE) message; and the MAC CE message comprises at least one of:
a list of DRBs under congestion condition, the DRB being a member of the list of DRB.
T1 discloses that a control PDU (i.e. MAC-CE) used for reporting [paragraph 0136], which is done based on different groupings [paragraph 0137], one such grouping is done by radio bearers per bearer ID in order for a receiving node to know if a specific bearer is getting congested [paragraph 0148].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of S1 for a gNB [refer S1; Fig. 1; 110] that handles congestion indications [refer S1; paragraph 0059] to incorporate the use of a control PDU for reporting that would comprise of a grouping (i.e. list) of bearers for congestion identification as taught by T1. One would be motivated to do so to indicate congestion in a network [refer T1; paragraph 0148].
Response to Arguments
Applicant's arguments filed 8/13/2026 have been fully considered but they are not persuasive.
Regarding claims 1,4,16,38,41, and 43, applicant argues that the applied reference, Sayenko et al. (US Pub. 2020/0374745)(S1 hereafter), does not teach the claim limitation, namely, “determining that a DRB associated with a PDU session of a wireless device is ECN enabled via…in response to all QoS flows in the DRB being ECN enabled, determining that the DRB is ECN enabled.” Refer pages 8-11 of Applicant’s arguments.
In response to the above-mentioned argument, examiner respectively disagrees.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., determining that a DRB is ECN enabled by aggregating the ECN enablement status of all QoS flows mapped to that DRB) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Given the broadest reasonable interpretation, as required by MPEP 2111, to determine that an ECN is enabled in response to all QoS flows in a DRB being ECN enabled can be viewed with regards to the disclosure of S1 since S1notes configuring a counter for each UE, each bearer, or each IP flow (or QoS flow)(i.e. the claimed all QoS flows in a DRB since S1 notes that IP flow is equated to QoS flow), may calculate the number of packets transmitted and received for each UE, each bearer, or each IP flow, and may detect data per UE, bearer, or IP flow that incurs congestion based on the counter values. Therefore, the network apparatus detects the cause of congestion by UE, bearer, or IP flow, selects data packets corresponding thereto, and sets an ECN field [S1; paragraph 0059]. Accordingly, this can be viewed as determining that ECN being enabled is based upon the IP flows (or QoS flows) having an ECN counter, which constitutes as providing a determination that ECN is enabled.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN C KAVLESKI whose telephone number is (571)270-3619. The examiner can normally be reached M-F 6:30am-3pm.
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, Charles C Jiang can be reached on 571-270-7191. 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.
Ryan Kavleski
/R.C.K./
Examiner, Art Unit 2412
/CHARLES C JIANG/Supervisory Patent Examiner, Art Unit 2412
Prosecution Insights