Prosecution Insights
Last updated: October 02, 2026
Application No. 18/991,772

CONGESTION PROCESSING METHOD AND APPARATUS AND COMMUNICATION DEVICE

Non-Final OA §102§103§112
Filed
Dec 23, 2024
Priority
Jun 22, 2022 — CN 202210716554.6 +1 more
Examiner
TODD, GREGORY G
Art Unit
2451
Tech Center
2400 — Computer Networks
Assignee
Vivo Mobile Communication Co., Ltd.
OA Round
1 (Non-Final)
39%
Grant Probability
At Risk
1-2
OA Rounds
2y 9m
Est. Remaining
36%
With Interview

Examiner Intelligence

Grants only 39% of cases
39%
Career Allowance Rate
176 granted / 456 resolved
-19.4% vs TC avg
Minimal -3% lift
Without
With
+-2.7%
Interview Lift
resolved cases with interview
Typical timeline
4y 6m
Avg Prosecution
33 currently pending
Career history
499
Total Applications
across all art units

Statute-Specific Performance

§101
9.5%
-30.5% vs TC avg
§103
39.4%
-0.6% vs TC avg
§102
21.5%
-18.5% vs TC avg
§112
21.2%
-18.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 456 resolved cases

Office Action

§102 §103 §112
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 is a first office action in response to application filed, with the above serial number, on 23 December 2024 in which claims 1-20 are presented for examination. Claims 1-20 are therefore pending in the application. It is noted that the claims of the application are replete with alternative limitations and nested alternative limitations of alternative limitations, often making it hard to follow what is intended to claim as the invention. Examiner recommends positively reciting the limitations while limiting the use of alternative limitations. The broadest reasonable interpretation is given during examination and thus when a limitation has numerous alternatives the prior art need only disclose one in order to anticipate the claim. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 7, 10, 13 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The claim recites “third information”, “third operation”, etc. These are recited without corresponding first and/or second components in the claim set, rendering the claims indefinite as to whether, for example, a first information and second information are claimed or not as they suggest. Claim 10 similarly recites an “eight condition”, etc. without corresponding seven other conditions being claimed. Claim 13 similarly obtains a ‘third requirement’ and it is not clear if there are a first and second requirement claimed. 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)(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. Claim(s) 1-15, 17-20 is/are rejected under 35 U.S.C. 102a1 as being anticipated by Zhu (hereinafter “Zhu”, 2012/0307634). As per Claim 1, Zhu discloses a congestion processing method, comprising: obtaining, by a first communication device, first information; wherein the first information comprises at least one of the following: a first requirement, first capability information of a terminal, first intention information of the terminal, or operation information of the terminal; and performing, by the first communication device, a first operation based on the first information, wherein the first operation comprises at least one of the following: determining to accept the first requirement or reject the first requirement; performing an operation corresponding to a congestion mark, or skipping performing or rejecting to perform an operation corresponding to a congestion mark; sending a second requirement to the terminal, wherein the second requirement is used to require the terminal to perform the operation corresponding to the congestion mark; sending a first query to the terminal, wherein the first query is used to query the terminal whether to allow to perform the operation corresponding to the congestion mark; sending a second query to the terminal, wherein the second query is used to query the terminal whether the operation corresponding to the congestion mark is being performed; or sending at least one of the following to a second communication device: the first information or first capability information of the first communication device; wherein the first capability information indicates one of the following: supporting the operation and/or a function corresponding to the congestion mark; and not supporting the operation and/or the function corresponding to the congestion mark; the first intention information of the terminal indicates one of the following: allowing, by the terminal and/or a user, to perform the operation corresponding to the congestion mark; and not allowing, by the terminal and/or the user, to perform the operation corresponding to the congestion mark; the operation information of the terminal indicates one of the following: the terminal is performing the operation corresponding to the congestion mark; and the terminal has not performed the operation corresponding to the congestion mark, wherein the first requirement is used to require to perform the operation corresponding to congestion mark (at least paragraph 54-57, 136; UE 1 negotiates the local link congestion notification capability with the eNodeB; the eNodeB adds a congestion identifier into an extension field of an RTCP packet header. As a radio access network control entity, the eNodeB adds a local congestion identifier into the RTCP packet header of the original RTCP packet after receiving an RTCP packet sent by a UE ; in the end-to-end congestion notification mechanism, when congestion of the local link is detected between the UE 1 and the eNodeB, the congestion identifier also needs to be added in the RTCP packet). As per Claim 2. The method according to claim 1, wherein the performing an operation corresponding to a congestion mark comprises at least one of the following: setting a first congestion mark for a data packet when a congestion mark condition is met; setting, based on the received first congestion mark, a second congestion mark for feedback; performing a congestion response operation based on the received first congestion mark or the second congestion mark; or recognizing mark information related to a congestion mark in a first protocol layer; and/or the performing an operation corresponding to a congestion mark comprises at least one of the following: performing, on a downlink, the operation corresponding to the congestion mark, and performing, on an uplink, the operation corresponding to the congestion mark; or recognizing mark information related to a congestion mark in a first protocol layer; and/or the performing, on a downlink, the operation corresponding to the congestion mark comprises at least one of the following: setting a first congestion mark for a downlink data packet when a downlink direction meets a congestion mark condition; setting, based on the received first congestion mark, a second congestion mark for an uplink data packet for feedback; or recognizing mark information related to a congestion mark in a first protocol layer; and/or the performing, on an uplink, the operation corresponding to the congestion mark comprises at least one of the following: setting a first congestion mark for an uplink data packet when an uplink direction meets a congestion mark condition; setting a first congestion mark for a downlink data packet when the uplink direction meets the congestion mark condition; sending a corresponding congestion mark or a corresponding congestion status to the terminal when the uplink direction meets the congestion mark or the congestion condition; or performing a congestion response operation on the uplink based on the received first congestion mark or a second congestion mark; wherein the first protocol layer comprises at least one of the following: a physical layer, a medium access control MAC layer, a radio link control RLC layer, a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, a general packet radio service tunneling protocol for the user plane GTP-U layer, an Internet protocol IP layer, or a transmission control protocol TCP layer (at least paragraph 54-57, 136; when the eNodeB detects that the local link is congested, taking RTCP as an example, which is not limited to the case of RTCP, the eNodeB adds a congestion identifier into an extension field of an RTCP packet header). As per Claim 3. The method according to claim 2, wherein the performing, on a downlink by the first communication device, the operation corresponding to the congestion mark comprises at least one of the following: setting the first congestion mark for the downlink data packet when the downlink direction meets the congestion mark condition; or recognizing the mark information related to the congestion mark in the first protocol layer; and/or the performing, on a downlink by the terminal, the operation corresponding to the congestion mark comprises at least one of the following: setting, based on the received first congestion mark, the second congestion mark for the uplink data packet for feedback; or recognizing the mark information related to the congestion mark in the first protocol layer; and/or the performing, on an uplink by the first communication device, the operation corresponding to the congestion mark comprises at least one of the following: setting the first congestion mark for the uplink data packet when the uplink direction meets the congestion mark condition; sending the congestion mark or the congestion status to the terminal when the uplink direction meets the congestion mark or the congestion condition; or recognizing the mark information related to the congestion mark in the first protocol layer; and/or performing, on the uplink by the terminal, the operation corresponding to the congestion mark comprises at least one of the following: setting the first congestion mark for the uplink data packet when the uplink direction meets the congestion mark condition; performing the congestion response operation on the uplink based on the received first congestion mark or the second congestion mark; or recognizing the mark information related to the congestion mark in the first protocol layer; and/or the requiring, by the first requirement, to perform the operation corresponding to the congestion mark comprises at least one of the following: requiring to perform, on the uplink, the operation corresponding to the congestion mark; or requiring to perform, on the downlink, the operation corresponding to the congestion mark; and/or the first requirement or the requiring, by the first requirement, to perform, on the downlink, the operation corresponding to the congestion mark comprises at least one of the following: requiring to set the first congestion mark for the downlink data packet when that the congestion mark condition is met; requiring to set, based on the received first congestion mark, the second congestion mark for feedback; or requiring to recognize the mark information related to the congestion mark in the first protocol layer; and/or requiring, by the second requirement, the terminal to perform the operation corresponding to the congestion mark comprises at least one of the following: requiring the terminal to perform, on the uplink, the operation corresponding to the congestion mark; or requiring the terminal to perform, on the downlink, the operation corresponding to the congestion mark; and/or the second requirement or the requiring, by the second requirement, the terminal to perform, on the downlink, the operation corresponding to the congestion mark comprises at least one of the following: requiring the terminal to set, based on the received first congestion mark, the second congestion mark for the uplink data packet for feedback; or requiring to recognize the mark information related to the congestion mark in the first protocol layer (at least paragraph 54-57, 136-137; when a end-to-end congestion notification solution is already set up, if the downlink between the eNodeB and the UE 1 is congested, the eNodeB adds a downlink local link congestion indication into an IP packet header of a downlink RTP packet. A congestion indication which is received by the UE 1 and is provided by another node in the network is the same as the congestion indication provided by the local radio access control entity). As per Claim 4.The method according to claim 1, wherein the first operation comprises at least one of the following: when a first condition is met, performing the operation corresponding to the congestion mark, and determining to accept the first requirement; wherein the first condition comprises at least one of the following: the terminal supports the operation and/or the function corresponding to the congestion mark; the terminal and/or the user allows to perform the operation corresponding to the congestion mark; the terminal is performing the operation corresponding to the congestion mark; the terminal accepts the second requirement; the terminal accepts that the operation corresponding to the congestion mark is being performed; the first communication device supports the operation and/or the function corresponding to the congestion mark; a resource of the first communication device can meet the first requirement; or the first communication device has received the first requirement, when a second condition is met, skipping performing or rejecting to perform the operation corresponding to the congestion mark; wherein the second condition comprises at least one of the following: the terminal does not support the operation and/or the function corresponding to the congestion mark; the terminal and/or the user does not allow to perform the operation corresponding to the congestion mark; the terminal rejects the second requirement; the terminal has not performed the operation corresponding to the congestion mark; the first communication device has not received the first requirement; the first communication device has received the first requirement, but a resource of the first communication device cannot meet the first requirement; or the first communication device does not support the operation and/or the function corresponding to the congestion mark, when a third condition is met, rejecting the first requirement; wherein the third condition comprises at least one of the following: the terminal does not support the operation and/or the function corresponding to the congestion mark; the terminal and/or the user does not allow to perform the operation corresponding to the congestion mark; the terminal rejects the second requirement; the terminal has not performed the operation corresponding to the congestion mark; the first communication device does not support the operation and/or the function corresponding to the congestion mark; the first communication device has received the first requirement; or a resource of the first communication device cannot meet the first requirement, when a fourth condition is met, sending the second requirement to the terminal; wherein the fourth condition comprises at least one of the following: the terminal supports the operation and/or the function corresponding to the congestion mark; the terminal allows to perform the operation corresponding to the congestion mark; the terminal has not performed the operation corresponding to the congestion mark; the first communication device supports the operation and/or the function corresponding to the congestion mark; the first communication device has received the first requirement; or a resource of the first communication device can meet the first requirement, when a fifth condition is met, sending the first query to the terminal; wherein the fifth condition comprises at least one of the following: the terminal supports the operation and/or the function corresponding to the congestion mark; the first communication device cannot determine whether the terminal allows to perform the operation corresponding to the congestion mark; the first communication device supports the operation and/or the function corresponding to the congestion mark; the first communication device has received the first requirement; or a resource of the first communication device can meet the first requirement, or when a sixth condition is met, sending the second query to the terminal; wherein the sixth condition comprises at least one of the following: the terminal supports the operation and/or the function corresponding to the congestion mark; the first communication device cannot determine whether the terminal is performing the operation corresponding to the congestion mark; the first communication device supports the operation and/or the function corresponding to the congestion mark; the first communication device has received the first requirement; or a resource of the first communication device can meet the first requirement (at least paragraph 54-57, 136; UE 1 negotiates the local link congestion notification capability with the eNodeB; the eNodeB adds a congestion identifier into an extension field of an RTCP packet header. As a radio access network control entity, the eNodeB adds a local congestion identifier into the RTCP packet header of the original RTCP packet after receiving an RTCP packet sent by a UE ; in the end-to-end congestion notification mechanism, when congestion of the local link is detected between the UE 1 and the eNodeB, the congestion identifier also needs to be added in the RTCP packet). As per Claim 5. The method according to claim 4, wherein the performing, by the first communication device, the operation corresponding to the congestion mark comprises: performing, on a downlink by the first communication device, the operation corresponding to the congestion mark; and/or the skipping, by the first communication device, performing or rejecting to perform the operation corresponding to the congestion mark comprises: skipping, by the first communication device, performing, on a downlink, or rejecting to perform, on a downlink, the operation corresponding to the congestion mark; and/or the first requirement or a first requirement in an Nth condition comprises: requiring to perform, on a downlink, the operation corresponding to the congestion mark; and/or the second requirement or a second requirement in an Nth condition comprises: requiring to perform, on a downlink, the operation corresponding to the congestion mark; and/or the first query comprises: querying the terminal whether to allow to perform, on a downlink, the operation corresponding to the congestion mark; and/or the second query comprises: querying whether the terminal is performing, on a downlink, the operation corresponding to the congestion mark; and/or the supporting, by the terminal, the operation and/or the function corresponding to the congestion mark in an Nth condition comprises: supporting, by the terminal, performing, on a downlink, the operation and/or the function corresponding to the congestion mark; and/or the allowing, by the terminal and/or the user, to perform the operation corresponding to the congestion mark in an Nth condition comprises: allowing, by the terminal and/or the user, to perform, on a downlink, the operation corresponding to the congestion mark; and/or that the terminal is performing the operation corresponding to the congestion mark in an Nth condition comprises: the terminal is performing, on a downlink, the operation corresponding to the congestion mark; and/or the not supporting, by the terminal, the operation and/or the function corresponding to the congestion mark in an Nth condition comprises: not supporting, by the terminal, performing, on a downlink, the operation and/or the function corresponding to the congestion mark; and/or the not allowing, by the terminal and/or the user, to perform the operation corresponding to the congestion mark in an Nth condition comprises: not allowing, by the terminal and/or the user, to perform, on a downlink, the operation corresponding to the congestion mark; and/or that the terminal has not performed the operation corresponding to the congestion mark in an Nth condition comprises: the terminal has not performed, on a downlink, the operation corresponding to the congestion mark, wherein the Nth condition comprises at least one of the following: the first condition, the second condition, the third condition, the fourth condition, the fifth condition, or the sixth condition (at least paragraph 54-57, 136-137; when a end-to-end congestion notification solution is already set up, if the downlink between the eNodeB and the UE 1 is congested, the eNodeB adds a downlink local link congestion indication into an IP packet header of a downlink RTP packet. A congestion indication which is received by the UE 1 and is provided by another node in the network is the same as the congestion indication provided by the local radio access control entity). As per Claim 6. The method according to claim 1, wherein the performing an operation corresponding to a congestion mark comprises: performing, on the downlink, the operation corresponding to the congestion mark; and/or the operation corresponding to the congestion mark comprises an operation corresponding to a downlink congestion mark (at least paragraph 54-57, 136-137; when a end-to-end congestion notification solution is already set up, if the downlink between the eNodeB and the UE 1 is congested, the eNodeB adds a downlink local link congestion indication into an IP packet header of a downlink RTP packet. A congestion indication which is received by the UE 1 and is provided by another node in the network is the same as the congestion indication provided by the local radio access control entity).. Claims 7-12 do not, in substance, add or define any additional limitations over claims 1-6 and therefore are rejected for similar reasons, supra. As per Claim 13, Zhu discloses a congestion processing method, comprising: obtaining, by a third communication device, a third requirement, wherein the third requirement is used to require to perform an operation corresponding to a congestion mark; and sending, by the third communication device, the third requirement to a second communication device (at least paragraph 54-57, 136; UE 1 negotiates the local link congestion notification capability with the eNodeB; the eNodeB adds a congestion identifier into an extension field of an RTCP packet header. As a radio access network control entity, the eNodeB adds a local congestion identifier into the RTCP packet header of the original RTCP packet after receiving an RTCP packet sent by a UE ; in the end-to-end congestion notification mechanism, when congestion of the local link is detected between the UE 1 and the eNodeB, the congestion identifier also needs to be added in the RTCP packet). As per Claim 15. The method according to claim 14, wherein the requiring, by the third requirement, to perform the operation corresponding to the congestion mark comprises at least one of the following: requiring to perform, on the uplink, the operation corresponding to the congestion mark; or requiring to perform, on a downlink, the operation corresponding to the congestion mark; and/or the third requirement or the requiring, by the third requirement, to perform, on the downlink, the operation corresponding to the congestion mark comprises at least one of the following: requiring to set the first congestion mark for the downlink data packet when the congestion mark condition is met; requiring to set, based on the received first congestion mark, the second congestion mark for feedback and set, based on the received first congestion mark, the second congestion mark for the uplink data packet for feedback; or requiring to recognize the mark information related to the congestion mark in the first protocol layer (at least paragraph 54-57, 136-137; when a end-to-end congestion notification solution is already set up, if the downlink between the eNodeB and the UE 1 is congested, the eNodeB adds a downlink local link congestion indication into an IP packet header of a downlink RTP packet. A congestion indication which is received by the UE 1 and is provided by another node in the network is the same as the congestion indication provided by the local radio access control entity; when congestion of the local link is detected between the UE 1 and the eNodeB, the congestion identifier also needs to be added in the RTCP packet). As per Claim 17. The method according to claim 13, wherein the method further comprises: after the step of sending the third requirement to the second communication device, receiving a third response sent by the second communication device; wherein the third response comprises at least one of the following: accepting the third requirement or rejecting the third requirement; or a failure cause or a rejection cause (at least paragraph 54-57, 136-137; when congestion of the local link is detected between the UE 1 and the eNodeB, the congestion identifier also needs to be added in the RTCP packet. After receiving the RTCP packet that has the congestion identifier, the UE 1 performs the congestion control on the traffic in the uplink direction from the UE 1 to the eNodeB by adjusting its own sending rate. In this case, the UE 1 does not need to know whether a congestion indication is initiated by the local congestion notification mechanism or the end-to-end congestion notification mechanism, because both mechanisms have the same purpose of making the UE adjust the rate). As per Claim 18. A communication device, comprising a processor and a memory that stores a program or an instruction executable on the processor, wherein when the program or the instruction is executed by the processor, the steps of the congestion processing method according to claim 1 (at least paragraph 52-57; eg eNodeB or local terminal). As per Claim 19. A communication device, comprising a processor and a memory that stores a program or an instruction executable on the processor, wherein when the program or the instruction is executed by the processor, the steps of the congestion processing method according to claim 7 (at least paragraph 52-57; eg eNodeB or local terminal). As per Claim 20. A communication device, comprising a processor and a memory that stores a program or an instruction executable on the processor, wherein when the program or the instruction is executed by the processor, the steps of the congestion processing method according to claim 13 (at least paragraph 52-57; eg eNodeB or local terminal). 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) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu in view of Ding et al (hereinafter “Ding”, 2020/0344638). Zhu fails to disclose wherein the obtained third requirement is granularity requirement information of a second object; and the sent third requirement is granularity requirement information of a third object; wherein the second object comprises a service data flow; and the third object comprises at least one of the following: a service data flow or a QoS policy. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Ding. Ding discloses in an analogous art, quality of service can be guaranteed in a granularity of a quality of service (QoS) flow, wherein each QoS flow is bound to a corresponding policy and charging control (PCC) rule, quality of service of a data service transmitted by using the QoS flow is determined based on QoS parameters in the PCC rule to which the QoS flow is bound, and a session management function network element binds the PCC rule to the QoS flow (at least paragraph 3-5). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Ding’s guarantee of QoS in granularity of QoS flow with Zhu as Ding teaches so that an accuracy rate of determining a quality of service QoS flow corresponding to a PCC rule can be increased, thereby improving network quality of service of a data service (par. 4) and ensure that PCC rules including same standardized QoS parameter indication information but different non-standardized QoS parameters are bound to different QoS flows, thereby increasing an accuracy rate of determining the quality of service QoS flow corresponding to the PCC rule, and improving user experience (par. 8). Conclusion The prior art made of record and not relied upon considered pertinent to applicant's disclosure is indicated in PTO form 892. Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY G TODD whose telephone number is (303)297-4763. The examiner can normally be reached 8:30-5 MST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Nicholas Taylor can be reached on (571)272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /GREGORY TODD/ Primary Examiner, Art Unit 2443
Read full office action

Prosecution Timeline

Dec 23, 2024
Application Filed
Sep 18, 2026
Non-Final Rejection mailed — §102, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12732432
Large Network Simulation
3y 7m to grant Granted Sep 08, 2026
Patent 12707004
SYSTEM FOR BRIDGING, MANAGING, AND PRESENTING SMARTPHONE & OTHER DATA FILES WITH TELEPHONY INTERACTIONS
4y 2m to grant Granted Aug 11, 2026
Patent 12707286
SYSTEM AND METHOD FOR O-CLOUD NODE RECONFIGURATION IN A TELECOMMUNICATIONS SYSTEM
3y 7m to grant Granted Aug 11, 2026
Patent 12695667
NETWORK CONTROL APPARATUS AND METHOD FOR POPULATING LOGICAL DATAPATH SETS
2y 3m to grant Granted Jul 28, 2026
Patent 12641006
Dynamic Expansion And Contraction Of Edge Clusters For Managing Access To Cloud-Based Applications
5y 0m to grant Granted May 26, 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
39%
Grant Probability
36%
With Interview (-2.7%)
4y 6m (~2y 9m remaining)
Median Time to Grant
Low
PTA Risk
Based on 456 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