Prosecution Insights
Last updated: August 17, 2026
Application No. 18/898,010

COMMUNICATION METHOD AND APPARATUS

Non-Final OA §103
Filed
Sep 26, 2024
Priority
Mar 28, 2022 — CN 202210311737.X +1 more
Examiner
WANG, YAOTANG
Art Unit
Tech Center
Assignee
Huawei Technologies Co., Ltd.
OA Round
1 (Non-Final)
80%
Grant Probability
Favorable
1-2
OA Rounds
9m
Est. Remaining
96%
With Interview

Examiner Intelligence

Grants 80% — above average
80%
Career Allowance Rate
384 granted / 482 resolved
+19.7% vs TC avg
Strong +16% interview lift
Without
With
+16.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
28 currently pending
Career history
504
Total Applications
across all art units

Statute-Specific Performance

§101
5.4%
-34.6% vs TC avg
§103
71.0%
+31.0% vs TC avg
§102
11.5%
-28.5% vs TC avg
§112
5.9%
-34.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 482 resolved cases

Office Action

§103
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The instant First Office Action on the merits is in response to claims filed on 9/26/2024. Claims 1-20 are pending. Claims 1, 12 and 19 are the base independent claims. Information Disclosure Statement The information disclosure statement (IDS) submitted was filed before the mailing of a first Office action on the merits. The submission is in compliance with the provisions of 37 CFR 1.97(b). Accordingly, the information disclosure statement is being considered by the examiner. Priority Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, or 365(c) is acknowledged. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copies of papers required under 35 U.S.C. 119(a)-(d) have been filed. 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over LI et al (CN 112423340A, published on 2/26/2021; citation is based on its English publication, US 2022/0174546) in view of MARCO et al (WO 2020/063722 / “GB 2577531”). Regarding claim 12, LI discloses a communication method, comprising: receiving, by a user plane function, a first data packet from an access network device (fig. 9 & par 228-230; in one embodiment, UPF receives a packet from RAN), wherein a tunneling protocol-user plane (GTP-U) header of the first data packet comprises first congestion information (par 228-229; when the RAN detects that a first service flow is congested…where the packet includes the QFI and the congestion information; also see par 155-156, par 194, par 205); and sending, by the user plane function, second congestion information to a server based on the first congestion information (par 230; UPF receives the packet from the RAN through the dedicated tunnel, determines that the first service flow is congested, and reports the congestion information to the AF). Although the reference discloses user plane information is reported quickly so that to adjust a policy, packet transmission rate, or the like based on the user plane information, the reference does not explicitly disclose: wherein the second congestion information comprises information for adjusting a rate for sending a first data flow (emphasis added). However it is obvious in view of MARCO, because MARCO discloses: wherein the second congestion information comprises information for adjusting a rate for sending a first data flow (page 7, par [78], marking at least one of the plurality of protocol data units with a discard instruction; also see page 10, par [107]-[108]). In view of the above, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of communication protocol configured for the electronic system of MARCO with the electronic system of LI. One is motivated as such to introduce the congestion information at the adaptation layer or GTP-U (MARCO, parge 9, par [97]). Regarding claim 1, LI discloses a communication method, comprising: performing, by an access network device, congestion detection on a first data flow (par 138-139; e.g. The notification information may be specifically a service flow identifier (QoS flow identifier, QFI), and is used to indicate that a QoS requirement of a service flow corresponding to the QFI cannot be met or is met again); and sending, by the access network device, a first data packet to a user plane function based on a congestion detection result (fig. 9 & par 228-230; in one embodiment, RAN sends a packet to UPF), wherein a tunneling protocol-user plane (GTP-U) header of the first data packet comprises congestion information (par 166; if a packet header of the generated uplink packet includes a QFI, it indicates that the RAN detects that a QoS feature of the QFI meets the reporting condition. If the packet header does not include a QFI or a QFI is empty or a special symbol, it indicates that congestion occurs in the RAN). The reference does not explicitly teach the alternative form as below: or (examining note: since the claim shows a limitation in an alternative form, the prior art may teach either or both limitations, and this notice applies to subsequent occurrences of claim limitations that are in the alternative form), sending, by the access network device, a second data packet to user equipment (UE) based on a congestion detection result, wherein a service data adaptation protocol (SDAP) layer of the second data packet comprises congestion information, wherein the congestion information comprises information for adjusting a rate for sending the first data flow. However, it is taught by MARCO, because MARCO discloses: sending, by the access network device, a second data packet to user equipment (UE) based on a congestion detection result (page 7, [78]-[79]; e.g. sending the plurality of protocol data units including the at least one marked protocol data unit to a second node of the network… As will be appreciated the UE is itself a node of the network), wherein a service data adaptation protocol (SDAP) layer of the second data packet comprises congestion information (page 6, par [61]; e.g. accessing the quality of service flow identification of each of the plurality of protocol data units comprises reading the quality of service flow identification (QFI) from a service data adaptation protocol (SDAP) layer header of each of the plurality of protocol data units), wherein the congestion information comprises information for adjusting a rate for sending the first data flow (page 7, par [78], marking at least one of the plurality of protocol data units with a discard instruction; also see page 10, par [107]-[108]). In view of the above, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of communication protocol configured for the electronic system of MARCO with the electronic system of LI. One is motivated as such to introduce the congestion information at the adaptation layer or GTP-U (MARCO, parge 9, par [97]). Regarding claim 19, LI discloses a communication apparatus, comprising: at least one processor; and one or more memories (par 280; processor and memory) coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the communication apparatus to perform operations comprising: performing congestion detection on a first data flow (par 138-139; e.g. The notification information may be specifically a service flow identifier (QoS flow identifier, QFI), and is used to indicate that a QoS requirement of a service flow corresponding to the QFI cannot be met or is met again); and sending a first data packet to a user plane function based on a congestion detection result (fig. 9 & par 228-230; in one embodiment, RAN sends a packet to UPF), wherein a tunneling protocol-user plane (GTP-U) header of the first data packet comprises congestion information (par 166; if a packet header of the generated uplink packet includes a QFI, it indicates that the RAN detects that a QoS feature of the QFI meets the reporting condition. If the packet header does not include a QFI or a QFI is empty or a special symbol, it indicates that congestion occurs in the RAN). The reference does not explicitly teach the alternative form as below: or (examining note: since the claim shows a limitation in an alternative form, the prior art may teach either or both limitations, and this notice applies to subsequent occurrences of claim limitations that are in the alternative form), sending a second data packet to user equipment (UE) based on a congestion detection result, wherein a service data adaptation protocol (SDAP) layer of the second data packet comprises congestion information, wherein the congestion information comprises information for adjusting a rate for sending the first data flow. However, it is taught by MARCO, because MARCO discloses: sending a second data packet to user equipment (UE) based on a congestion detection result (page 7, [78]-[79]; e.g. sending the plurality of protocol data units including the at least one marked protocol data unit to a second node of the network… As will be appreciated the UE is itself a node of the network), wherein a service data adaptation protocol (SDAP) layer of the second data packet comprises congestion information (page 6, par [61]; e.g. accessing the quality of service flow identification of each of the plurality of protocol data units comprises reading the quality of service flow identification (QFI) from a service data adaptation protocol (SDAP) layer header of each of the plurality of protocol data units), wherein the congestion information comprises information for adjusting a rate for sending the first data flow (page 7, par [78], marking at least one of the plurality of protocol data units with a discard instruction; also see page 10, par [107]-[108]). In view of the above, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of communication protocol configured for the electronic system of MARCO with the electronic system of LI. One is motivated as such to introduce the congestion information at the adaptation layer or GTP-U (MARCO, parge 9, par [97]). Regarding claim 2, LI discloses: receiving, by the access network device, a data flow identifier of the first data flow (par 157; e.g. the RAN generates an uplink packet, where the packet includes a QFI. The QFI is used to identify the QoS flow). Regarding claim 3, LI discloses: wherein the performing, by an access network device, congestion detection on a first data flow comprises: performing, by the access network device, congestion detection on the first data flow based on the data flow identifier (par 157; e.g. the packet further includes delay or packet loss rate information). Regarding claim 4, MARCO discloses: receiving, by the access network device, a congestion identifier (page 10, par [110]; e.g. queue size and/or queue delay). Regarding claim 5, LI discloses: wherein the performing, by an access network device, congestion detection on a first data flow comprises: performing, by the access network device, congestion detection on the first data flow based on at least one of a data flow identifier of the first data flow or the congestion identifier (par 138-139; e.g. The notification information may be specifically a service flow identifier (QoS flow identifier, QFI), and is used to indicate that a QoS requirement of a service flow corresponding to the QFI cannot be met or is met again). Regarding claim 6, MARCO discloses: wherein the congestion information comprises first congestion information and second congestion information, the first congestion information is congestion information between the access network device and the user plane function, and the second congestion information is congestion information between the access network device and the UE (page 4, par [50]; an IAB network, the bottleneck might be the access link (assuming bad UE radio conditions) but also any other backhaul link). Regarding claim 7, LI discloses: wherein the sending, by the access network device, a first data packet to a user plane function based on a congestion detection result, or the sending, by the access network device, a second data packet to user equipment (UE) based on a congestion detection result comprises: determining, by the access network device, that the congestion detection result meets a first condition; and sending, by the access network device, the first data packet to the user plane function, or sending, by the access network device, the second data packet to the UE (par 138-139; e.g. The notification information may be specifically a service flow identifier (QoS flow identifier, QFI), and is used to indicate that a QoS requirement of a service flow corresponding to the QFI cannot be met or is met again). Regarding claim 8, LI discloses: wherein the receiving, by the access network device, a data flow identifier of the first data flow comprises: receiving, by the access network device, the first data packet from the user plane function, wherein the first data packet comprises the data flow identifier; or receiving, by the access network device, congestion detection information from a session management function (SMF) network element, wherein the congestion detection information comprises the data flow identifier (fig. 9, par 184; e.g. the SMF sends the correspondence between the QFI and the dedicated QFI to the UPF by using an N4 session modification message). Regarding claim 9, LI discloses: wherein the congestion detection information further comprises at least one of a queue delay, congestion reporting time, a packet loss rate, a buffer size, a periodicity, a congestion level, or a rate reduction proportion (par 157; e.g. the packet further includes delay or packet loss rate information). Regarding claim 10, LI discloses: wherein the first data flow is a quality of service (QoS) flow that is in a protocol data unit (PDU) session and that is bound to a congestion detection policy and charging control (PCC) rule (par 129-130; e.g. quality of service ( quality of service, QoS) policy and a slice selection policy… forwarding and charging). Regarding claim 11, LI discloses: wherein the first data packet or the second data packet is a data packet that transmits data of the first data flow, or the first data packet or the second data packet is a monitoring data packet (par 166; e.g. when congestion is detected by the RAN, the RAN may generate an uplink packet, and transmit the generated uplink packet through the dedicated N3 tunnel). Regarding claim 13, LI disclose: wherein the sending, by the user plane function, second congestion information to a server comprises: sending, by the user plane function, a second data packet to the server, wherein the second data packet comprises the second congestion information (par 230; UPF receives the packet from the RAN through the dedicated tunnel, determines that the first service flow is congested, and reports the congestion information to the AF). Regarding claim 14, MARCO discloses: wherein the sending, by the user plane function, second congestion information to a server comprises: sending, by the user plane function, the second congestion information to the server via user equipment (UE) (page 5, par [53], possibly, this congestion notification will have to be conveyed back from the UE across the congested IAB network and back to the TCP sender in the UE). Regarding claim 15, LI discloses: wherein the sending, by the user plane function, the second congestion information to the server via user equipment (UE) comprises: sending, by the user plane function, a downlink data packet to the UE, wherein the downlink data packet comprises the second congestion information (par 162; e.g. a downlink packet generated by the UPF includes user plane information. The user plane information includes at least one of the following: notification information, congestion information). Regarding claim 16, LI discloses: wherein the sending, by the user plane function, second congestion information to a server comprises: sending, by the user plane function, the second congestion information to the server via a session management function or a network exposure function (par 176; e.g. may interact with the PCF by using a NEF. The PCF generates a new policy rule based on the application function request and sends a session policy update message to the SMF). Regarding claim 17, LI discloses: wherein the sending, by the user plane function, second congestion information to a server comprises: determining, by the user plane function, that the first congestion information meets a first condition, or determining, by the user plane function based on the first congestion information, that a congestion detection result meets a first condition (par 138-139; e.g. The notification information may be specifically a service flow identifier (QoS flow identifier, QFI), and is used to indicate that a QoS requirement of a service flow corresponding to the QFI cannot be met or is met again); and sending, by the user plane function, the second congestion information to the server (par 230; UPF receives the packet from the RAN through the dedicated tunnel, determines that the first service flow is congested, and reports the congestion information to the AF). Regarding claim 18, LI discloses: wherein the first data packet is a data packet that transmits data and that is of the first data flow or a monitoring data packet (par 166; e.g. when congestion is detected by the RAN, the RAN may generate an uplink packet, and transmit the generated uplink packet through the dedicated N3 tunnel). Regarding claim 20, LI discloses: receiving a data flow identifier of the first data flow (par 157; e.g. the RAN generates an uplink packet, where the packet includes a QFI. The QFI is used to identify the QoS flow). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to YAOTANG WANG whose telephone number is (571)272-4023. The examiner can normally be reached 10:00-18:00 ET (M, W, TH & alternate F). 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, HADI ARMOUCHE can be reached at 571-270-3618. 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. /YAOTANG WANG/SCE/Primary Examiner, Art Unit 2409
Read full office action

Prosecution Timeline

Sep 26, 2024
Application Filed
Jul 28, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12706701
HARQ FEEDBACK METHOD AND DEVICE, AND STORAGE MEDIUM
3y 1m to grant Granted Aug 11, 2026
Patent 12706698
ACKNOWLEDGEMENT FEEDBACK FOR POSITIONING IN RADIO RESOURCE CONTROL INACTIVE STATE
2y 9m to grant Granted Aug 11, 2026
Patent 12695694
RELIABLE OUT-OF-ORDER TRANSPORT PROTOCOL WITH FAST RETRANSMISSION OF PACKETS
3y 1m to grant Granted Jul 28, 2026
Patent 12696057
COMMUNICATION METHOD AND APPARATUS, AND RELATED DEVICE
2y 9m to grant Granted Jul 28, 2026
Patent 12696270
ADAPTATIONS TO STATUS PROTOCOL DATA UNITS
2y 9m to grant Granted Jul 28, 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

1-2
Expected OA Rounds
80%
Grant Probability
96%
With Interview (+16.3%)
2y 8m (~9m remaining)
Median Time to Grant
Low
PTA Risk
Based on 482 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