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 .
DETAILED ACTION
This non-final office action is responsive to the U.S. patent application no. 19/111.763 filed on March 13, 2025.
Claim 1-21 have been cancelled.
Claims 22-41 are pending.
Claims 22-41 are rejected.
Priority
The application claims priority under 35 U.S.C. 365(a) to the international application no. PCT/CN2022122844 filed on September 22, 2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on March 13, 2025 and July 26, 2025 are compliant with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement filings have been considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 22, 30, 32 and 39 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 22, 23, 24, of co-pending Application No. 19/111,299 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other as shown below.
Application No. 19/111,673
Reference application no. 19/111,299
22. A method comprising:
detecting a congestion event associated with a traffic flow in a first queue;
generating, in a second queue, a packet with a congestion experienced (CE) indication and an identifier associated with the first queue; and
outputting the packet for transmission.
30. The method of claim 22, wherein the packet is a packet data convergence protocol (PDCP) control protocol data unit (PDU) and the method further comprises: providing, within a PDU type field of the PDCP control PDU, an indication that the packet has: a format for congestion feedback with no sequence number; a format for congestion feedback with 12-bit sequence number; or a format for congestion feedback with 18-bit sequence number.
21. A method comprising:
detecting a congestion event associated with a traffic flow;
generating a radio link control (RLC) protocol data unit (PDU) with a congestion experienced (CE) indication; and
(22. The method of claim 21, wherein the RLC PDU is an RLC control PDU and the method further comprises: placing the RLC control PDU in a queue, wherein the RLC control PDU is prioritized for transmission ahead of other PDUs of the queue.)
outputting the RLC PDU for transmission to a device.
23. The method of claim 21, wherein the RLC PDU is an RLC control PDU that comprises: no sequence number and one octet; an 18-bit sequence number; a 12-bit sequence number; a 6-bit sequence number in a first of two octets of the RLC control PDU; a 6-bit sequence number in a second of two octets of the RLC control PDU; or a six-bit sequence number distributed in first and second octets of two octets of the RLC control PDU.
24. The method of claim 21, wherein the RLC PDU is an RLC control PDU that comprises a field to indicate the RLC control PDU has no sequence number, an 18-bit sequence number, a 12-bit sequence number, or a 6-bit sequence number.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 22-41 are rejected under 35 U.S.C. 102(a)(2) as being unpatentable over Ostberg et al. (U.S. 2025/0150402).
Regarding claim 22, Ostberg disclosed a method comprising:
detecting a congestion event associated with a traffic flow in a first queue (Ostberg disclosed in Fig. 12, step 1202 and [0107] that “the first network node receives from the second network node packets for an uplink user plane flow over the uplink connection between the wireless device and the radio network. Data radio bearers (DRBs) may be used to control and/or organize the UL user plane flow.” Said “UL user plane flow” anticipates the “traffic flow in a first queue” in the claim. Ostberg then disclosed in Fig. 12, 1204 and [0108] that “the first network node obtains an indication of a proportion of packets within the uplink user plan flow that are to be marked with a congestion indicator.” Said “congestion indicator” represents a detection of a congestion);
generating, in a second queue, a packet with a congestion experienced (CE) indication and an identifier associated with the first queue (Ostberg disclosed in Fig. 12, step 1206 and [0109] that “the first network node marks the proportion of the packets with the congestion indicator (e.g. an LAS indicator, such as an ECN field” Ostberg further disclosed in [0108] that “the packets received from the second network node may be RLC PDUs. The packets to be marked with a congestion indicator may be PDCP PDUs or IP packets”); and
outputting the packet for transmission (Ostberg disclosed in Fig. 12, step 1208 and [0111] that “the first network node transmits the packets for the uplink user plane flow, including the portion of packets marked with the congestion indicator, towards a core network of the radio network. For example, the packets may be transmitted over a backhaul network to the core network” which means that the packets will be transmitted via the backhaul network’s outgoing buffer).
Regarding claim 32, Ostberg disclosed one or more non-transitory, computer-readable media having instructions that, when executed, cause processor circuitry to:
place a plurality of packets of a traffic flow in a first queue (Ostberg disclosed in Fig. 12, step 1202 and [0107] that “the first network node receives from the second network node packets for an uplink user plane flow over the uplink connection between the wireless device and the radio network. Data radio bearers (DRBs) may be used to control and/or organize the UL user plane flow.” Said “UL user plane flow” anticipates the “plurality of packets of a traffic flow” in the claim.);
place a first packet in a second queue (Ostberg disclosed in [0097] that “the node hosting PDCP may decide to apply ECN marking to some/all of the UL IP packets in egress for the corresponding DRB traffic” which involves putting the UL IP packets in an egress buffer/queue.);
detect, in the first packet, a congestion experienced (CE) indication and an identifier associated with the first queue (Ostberg then disclosed in Fig. 12, 1204 and [0108] that “the first network node obtains an indication of a proportion of packets within the uplink user plan flow that are to be marked with a congestion indicator.”); and
provide, from a first layer to a second layer above the first layer, a congestion indication corresponding to one or more packets of the plurality of packets based on detecting the CE indication in the first packet (Ostberg disclosed in [0014-0016] that the User Plane protocol that is used over F1-U, Xn-U and X2-U may use PDU type 1, i.e. Downlink Data Delivery Status to allow a node hosting lower layers such as RLC to convey information that could help the node hosting PDCP to better manage a radio bearer’s configuration.).
Regarding claims 23 and 33, Ostberg disclosed the subject matter of claims 22 and 32, respectively. Ostberg further disclosed wherein the first queue is for a first data radio bearer (DRB) or quality of service (QoS) flow (Ostberg disclosed in [0107] that “Data Radio Bearer (DRBs) may be used to control and/or organize the UL user plan flow” and in [0108] that “the packets received from the second network node may be RLC PDUs”) and the second queue is for a second DRB or QoS flow that is dedicated to congestion feedback or includes both congestion feedback and non-congestion related data (Ostberg disclosed in [0107] that “Data Radio Bearer (DRBs) may be used to control and/or organize the UL user plan flow” and in [0108] that “the packets to be marked with a congestion indicator may be PDCP PDUs or IP packets”).
Regarding claim 24, Ostberg disclosed the method of claim 22.
Ostberg further disclosed wherein the method further comprises: determining a lowest sequence number (SN) in the first queue at a time in which the congestion event is detected; and generating the packet with an indication of the lowest SN (Ostberg, [0021] and table 1 disclosed an example of a Data Delivery Status Frame that contains an indication of “Start of lost NR-U sequence number range” that corresponds to a lowest sequence number in the UL user plane flow).
Regarding claims 25 and 34, Ostberg disclosed the subject matter of claims 22 and 32, respectively. Ostberg further disclosed wherein the CE indication is a CE-set indication to indicate the traffic flow is experiencing congestion or a CE-clear indication to indicate the traffic flow is not experiencing congestion (Ostberg, [0090], “the node hosting PDCP (e.g. the gNB-CU-UP) may rely on information contained in PDU Type 1 and/or PDU Type 2 to deduce whether ECN marking should be set or not in the UL IP Packets in egress.” Meaning that the ECN marking is used to indicate whether the UL use plane flow experiences a congestion or not).
Regarding claim 26, Ostberg disclosed the method of claim 25.
Ostberg further disclosed wherein the packet is a first packet, the congestion event is a first congestion event associated with a first threshold of the first queue, the CE indication is a first CE indication that is a CE-set indication to indicate the traffic flow is experiencing congestion (Ostberg, [0009], “ L4S enables real-time critical data applications to adapt their rate to the weakest link, providing minimal latency impact due to queue build up. The state-of-the-art L4S is typically triggered by thresholds in the transport node input queue and may be used to signal a congested situation”) and
the method further comprises:
detecting a second congestion event associated with a second threshold of the first queue (Ostberg disclosed in [0073] that “Reception of Assistance Information with a different L4S Marking Probability value than previously received, may be used by the CU-UP to change the ECN marking accordingly.”);
generating, in the second queue, a second packet with a CE-clear indication to indicate the traffic flow is not experiencing congestion (Ostberg further disclosed in [0073] that “The lack of L4S Marking Probability in a subsequent Assistance Information may be interpreted by the CU-UP as an indication that the L4S Marking Probability is no longer applicable and ECN marking should therefore no longer be included in the IP header.” In other words, not including ECN marking in the IP header is an indication that the congestion is cleared.); and
outputting the second packet for transmission (Ostberg disclosed in Fig. 12, step 1208 and [0111] that “the first network node transmits the packets for the uplink user plane flow, including the portion of packets marked with the congestion indicator, towards a core network of the radio network. For example, the packets may be transmitted over a backhaul network to the core network”).
Regarding claim 27, Ostberg disclosed the method of claim 22.
Ostberg further disclosed wherein the first queue and the second queue are for: packet data convergence protocol (PDCP) service data units (SDUs); PDCP protocol data units (PDUs); service data adaptation protocol (SDAP) SDUs; or SDAP PDUs (Ostberg, Fig. 3 and [0012, 0013], “PDCP PDU”, “SDAP”).
Regarding claim 28, Ostberg disclosed the method of claim 22.
Ostberg further disclosed wherein the packet is a first packet and the method further comprises: generating, in the second queue, a second packet with a CE indication and an identifier associated with a third queue (Ostberg, [0117], “In a yet further embodiment, a first congestion indicator may be added to the PDUs signaled from the second network node to the first network node. The first congestion marker (which may be provided, e.g., in a GTP-U Extension Header for UL GTP-U PDUs) may be provided with each uplink PDU that contains an IP packet that is determined by the congestion control algorithm (in the second network node) to carry a second congestion indicator (e.g., in the ECN field of that IP packet).”).
Regarding claim 29, Ostberg disclosed the method of claim 22.
Ostberg further disclosed further comprising: receiving, in radio resource control (RRC) signaling, configuration information to configure the second queue for congestion feedback and associate the second queue with the first queue (Ostberg disclosed in [0098-0100] that “the node hosting the lower layers (e.g. the gNB-DU) may host functionalities aimed at influencing how the ECN marking should be applied by the node hosting PDCP (e.g. the gNB-CU)” and the functionalities hosted by the node hosting the lower layers include setting, adapting or configuring parameters including Radio Resource Status).
Regarding claims 30 and 39, Ostberg disclosed the subject matter of claims 22 and 32, respectively. Ostberg further disclosed wherein the packet is a packet data convergence protocol (PDCP) control protocol data unit (PDU) (Ostberg, [0013, 0108], “PDCP PDU”) and
the method further comprises:
providing, within a PDU type field of the PDCP control PDU, an indication that the packet has: a format for congestion feedback with no sequence number; a format for congestion feedback with 12-bit sequence number; or a format for congestion feedback with 18-bit sequence number (Ostberg disclosed in [0064] that “ in case A the CDA and PMark functions are hosted in the DU (or secondary network node). In one embodiment of the disclosure, the information providing the marking probability can be added to the 3GPP TS 34.425 Assistance Information PDU” and then in [0066] a detailed description of the Assistance Information PDU that includes fields for communicating congestion feedback).
Regarding claims 31 and 38, Ostberg disclosed the subject matter of claims 22 and 32, respectively. Ostberg further disclosed wherein the packet is a packet data convergence protocol (PDCP) data protocol data unit (PDU) (Ostberg, [0013, 0108], “PDCP PDU”) and the method further comprises:
providing, within the PDCP data PDU, a sequence number associated with the first queue, a sequence number associated with the second queue, or sequence numbers associated with both the first queue and the second queue (Ostberg disclosed in [0014-0016] that the User Plane protocol that is used over F1-U, Xn-U and X2-U may use PDU type 1, i.e. Downlink Data Delivery Status to allow a node hosting lower layers such as RLC to convey information that could help the node hosting PDCP to better manage a radio bearer’s configuration. Ostberg then disclosed in [0019-0021] the PDU Type 1 provides sequence number related information such as “Highest Transmitted NR PDCP Sequence Number”, “Delivered NR PDCP Sequence Number Range” etc.).
Regarding claim 35, Ostberg disclosed the one or more non-transitory, computer-readable media of claim 32.
Ostberg further disclosed wherein the one or more packets are packet data convergence protocol (PDCP) service data units (SDUs) or service data adaptation protocol (SDAP) SDUs (Ostberg, Fig. 3 and [0012, 0013], “PDCP PDU”, “SDAP”) and
to process the one or more packets the processor circuitry is to: generate an IP packet having a header with a CE bit and at least one packet of the one or more packets (Ostberg, [0073], “Based on the L4S Marking Probability information received in the Assistance Information, the CU-UP determines when to start to include ECN marking in the IP header in accordance with the received L4S Marking Probability value”).
Regarding claim 36, Ostberg disclosed the one or more non-transitory, computer-readable media of claim 32.
Ostberg further disclosed wherein the second queue is associated with a data radio bearer and the processor circuitry is associated with a base station centralized unit (Ostberg disclosed in Fig. 12, step 1208 and [0111] that “the first network node transmits the packets for the uplink user plane flow, including the portion of packets marked with the congestion indicator, towards a core network of the radio network. And in [0098] that “a congestion marker, referred to herein as L4S Congestion Notification, may be added to the PDUs signaled from the gNB-DU to the gNB-CU or in general signaled from the node hosting lower layers to the node hosting PDCP”).
Regarding claim 37, Ostberg disclosed the one or more non-transitory, computer-readable media of claim 32.
Ostberg further disclosed wherein the second queue is associated with a quality-of-service flow (Ostberg, [0024], “get a good Quality of Experience”) and the processor circuitry is associated with a user plane function (UPF) in a core network (Ostberg, [0030], “marking the proportion of packets with the congestion indicator and transmitting packets for the uplink user plane flow towards a core network of the radio network”).
Regarding claim 39, Ostberg disclosed the one or more non-transitory, computer-readable media of claim 32.
Ostberg further disclosed wherein the first packet comprises a packet data convergence protocol (PDCP) control protocol data unit (PDU) and the instructions, when executed, further cause the processor circuitry to:
decode a PDU type field of the PDCP control PDU to obtain an indication that the first packet has: a format for congestion feedback with no sequence number; a format for congestion feedback with a 12-bit sequence number; or a format for congestion feedback with an 18-bit sequence number.
Regarding claim 40, Ostberg disclosed an apparatus comprising: processor circuitry to: generate radio resource control (RRC) message to include configuration information to configure a first queue of a user equipment for congestion feedback for data transmitted through a second queue of the user equipment (Ostberg disclosed in [0107], “the first network node receives from the second network node packets for an uplink user plane flow of the uplink connection between the wireless device and the radio network” and in [0108] that “the packets received from the second network node may be RLC PDU.” Ostberg further disclosed in [0015-0016] that RLC PDU Type 1 and PDU Type 2 has been defined to enable a node hosting lower layers such as RLC to convey link status information to a node hosting the upper layer PDCP. The “second network node” or the “wireless device” disclosed by Ostberg here anticipates the “apparatus” in the claim); and
output the RRC message for transmission to a user equipment (Ostberg, Fig. 3, [0105-0106] and Fig. 12); and
interface circuitry coupled with the processor circuitry to enable communication (Ostberg, Figs. 3, 14, 15).
Regarding claim 41, Ostberg disclosed the apparatus of claim 40.
Ostberg further disclosed wherein the first queue is for a first data radio bearer or QoS flow, the second queue is for a second DRB or QoS flow, and the configuration information is further to configure the first DRB or QoS flow for congestion feedback for a plurality of DRBs or QoS flows, including the second DRB or QoS flow (Ostberg, [0108], “the packets received from the second network node may be RLC PDUs. The packets to be marked with a congestion indicator may be PDCP PDUs or IP packets”).
Related Prior Art
Ma et al. (US 2016/0219088) is directed to methods and systems for a quality-of-experience based queue management for routers for real-time video applications.
Oyman et al. (2022/0046478) is directed to systems, apparatuses, methods, and computer-readable media for negotiating Radio Access Network (RAN)-level capabilities toward improving end-to-end quality of Internet Protocol Multimedia Subsystem (IMS) communication sessions, such as Voice over Long-Term Evolution (VoLTE) calls. Disclosed embodiments include Session Description Protocol-based mechanisms to signal the RAN-level capabilities.
Nguyen et al. (US 2017/0019803) is directed to a system and method for optimizing downlink throughput.
Talebi Fard et al. (US 2025/0274810) disclosed a system in which a first network node receives, from a second network node, a first message comprising a configuration parameter for reporting of user plane congestion associated with a network slice to a target node, wherein the configuration parameter comprises an identifier of the network slice. The first network node sends, to a user plane function (UPF), a second message comprising the configuration parameter.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIRLEY X ZHANG whose telephone number is (571)270-5012. The examiner can normally be reached 8:30am - 5:00pm.
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, Joon H Hwang can be reached at 571-272-4036. 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.
/SHIRLEY X ZHANG/Primary Examiner, Art Unit 2447
Prosecution Insights