Prosecution Insights
Last updated: October 27, 2026
Application No. 18/613,921

INFORMATION CONTROL METHOD AND APPARATUS, NETWORK FUNCTION, AND READABLE STORAGE MEDIUM

Final Rejection §102§103
Filed
Mar 22, 2024
Priority
Sep 28, 2021 — CN 202111143205.1 +1 more
Examiner
OH, ANDREW CHUNG SUK
Art Unit
2466
Tech Center
2400 — Computer Networks
Assignee
Vivo Mobile Communication Co., Ltd.
OA Round
2 (Final)
70%
Grant Probability
Favorable
3-4
OA Rounds
11m
Est. Remaining
84%
With Interview

Examiner Intelligence

Grants 70% — above average
70%
Career Allowance Rate
398 granted / 568 resolved
+12.1% vs TC avg
Moderate +14% lift
Without
With
+14.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
20 currently pending
Career history
603
Total Applications
across all art units

Statute-Specific Performance

§101
5.2%
-34.8% vs TC avg
§103
59.9%
+19.9% vs TC avg
§102
14.5%
-25.5% vs TC avg
§112
11.3%
-28.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 568 resolved cases

Office Action

§102 §103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Arguments Section 112(b) Applicant’s arguments, filed 08/26/2026, with respect to section 112(b) have been fully considered and are persuasive. The section 112(b) rejection of claims 1, 3-8, 10-16, 18-20 has been withdrawn. Section 102 / 103 Applicant's arguments filed 08/26/2026 have been fully considered but they are not persuasive. On p.15, the applicant argues that claim 1 states RAN sends interaction assistance information to the core network and not RAN capabilities. Therefore, Ronneke teaches RAN capabilities that are not used for interaction between the first core network function and the second core network function. The examiner respectfully disagrees. Ronneke at [0167] expressly teaches that the NG-RAN node transmits its 5MBS capability information to the AMF/core network node indicating whether the RAN supports 5MBS. Ronneke teaches that the RAN capability indication helps determine whether individual delivery is needed and if it is selected, the AMF interacts with the SMF. [0205-216] details what happens if the RAN supports or does not support 5MBS and how it affects the AMF. [0216] teaches that the AMF/core network node selects the PDU session to be used for 5MBS data delivery and contacts the SMF node. The claims remain unpatentable. Claim Rejections - 35 USC § 102 The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. Independent Claims Claim(s) 1, 8, 16, 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Ronneke (US-20230309189). As to claim 1, 8, 16, 20: Ronneke teaches an information control method, comprising: sending, by a radio access network (RAN) node, interaction assistance information to a first core network function ([0006-8, 0167] it is also possible to allow the NG-RAN node 10 to transmit its 5MBS capability information as part of the NGAP message which is used to forward the NAS message to the AMF/core network node), wherein the interaction assistance information is used to assist the first core network function in invoking information related to multicast and broadcast service management OR session management to a second core network function ([0098-101] If a RAN supports 5MBS, the AMF, or other core network node triggers the 5GC Shared MBS traffic delivery method), wherein the interaction assistance information meets at least one of following: comprising information that is required to be sent to the second core network function ([0216] AMF/core network node 16, 38 sends a PDU Session Update SMContext to SMF node 18 a, with the IP multicast address and source IP address of the 5MBS session); the information that is required to be sent to the second core network function is absent ([0204] if step S192 and S194 are not executed (e.g., AMF/core network node 16, 38 does already have a 5MBS session context), a DisableIndividualDelivery parameter or flag may be present in the 5MBS session context in AMF/core network node 16, 38 if it was earlier provided by the AF node 26); comprising first indication information. wherein the first indication information is used to indicate that it is required to interact with the second core network function ([0152] DisableIndividualDelivery parameter may indicate whether the AF node 26 expects the 5G System (5GS) to enable the 5MBS individual delivery method); OR the first indication information is used to indicate that it is optional OR not interacting with the second core network function, OR to indicate that it is conditional or not interacting with the second core network function; comprising transmission type indication information, wherein the transmission type indication information is used to indicate at least one of following: a transmission type is unicast, OR the transmission type is multicast ([0152] DisableIndividualDelivery); comprising first shared tunnel information ([0014-35] N6 tunnel info); OR first shared tunnel information is absent. Dependent Claims Claim(s) 3, 10, 18 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Ronneke (US-20230309189). As to claim 3, 10, 18: Ronette teaches the method according to claim 1, wherein the interaction assistance information meets at least one of following: in a case that the interaction assistance information comprises information that is required to be sent to the second core network function, the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function; in a case that the interaction assistance information does not comprise the information that is required to be sent to the second core network function, the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function; in a case that the transmission type indication information comprised in the interaction assistance information indicates that the transmission type is unicast [0006-8, 99-101, 167] it is also possible to allow the NG-RAN node 10 to transmit its 5MBS capability information as part of the NGAP message which is used to forward the NAS message to the AMF/core network node), the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function ([0188, 189] The PDU Session selection may involve interaction between AMF/core network node 16. 38 and SMF 18a); or in a case that the transmission type indication information comprised in the interaction assistance information indicates that the transmission type is multicast [0006-8, 98-101, 167] it is also possible to allow the NG-RAN node 10 to transmit its 5MBS capability information as part of the NGAP message which is used to forward the NAS message to the AMF/core network node), the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function ([0098-101]). 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 following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 4, 5, 6, 7, 11, 12, 13, 14, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ronneke (US-20230309189) in view of 3GPP TR 23.757 v17.0.0 (2021-03) Study on architectural enhancements for 5G multi-cast-broadcast service. As to claim 4, 11: Ronneke teaches the method according to claim 1. Ronneke may not explicitly teach wherein the first shared tunnel information comprises at least one of following: a transmission address; or, wherein the first shared tunnel information comprises at least one of a transmission address or a tunnel identifier, and comprises at least one of following: a multicast and broadcast service (MBS) session identifier; MBS quality of service flow information; MBS service area information; or an MBS area session identifier. However, 3GPP teaches wherein the first shared tunnel information comprises at least one of following: a transmission address (p.28 4. MB-SMF sets up the N6 resources for the MB Session in the MB-UPF and the N3 resources for transport multicast tunnelling using the LL MC address allocated for the TMGI.); or a tunnel identifier (p.43 If the RAN node is configured to use a unicast transport for multicast distribution sessions, it allocates a downlink tunnel ID (an IP address and a GTP-U TEID) for the reception of the multicast distribution session and indicates the downlink tunnel information in the request); or, wherein the first shared tunnel information comprises at least one of a transmission address or a tunnel identifier, and comprises at least one of following: a multicast and broadcast service (MBS) session identifier (p.62 RAN to AMF: N2 message ([MB-SMF ID], N2 MB Info (TMGIs))); MBS quality of service flow information; MBS service area information; or an MBS area session identifier. Thus, it would have been obvious to one of ordinary skill in the art to implement MB sessions, taught by 3GPP, into the communication system, taught by Ronneke, in order to implement a well-known feature of a pre-defined protocol and enable multicast or broadcast. In addition, it would have been obvious to combine 3GPP and Ronneke in a known manner to obtain predictable results as the combination would not change the essence, quiddity, or functionality of the prior art references. As to claim 5, 12: Ronneke teaches the method according to claim 4. Ronneke may not explicitly teach wherein when the interaction assistance information comprises first shared tunnel information, the interaction assistance information meets at least one of following: in a case that the first shared tunnel information comprises a transmission address, and the transmission address is a multicast address, the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function; in a case that the first shared tunnel information comprises a transmission address, and the transmission address is a unicast address or not a multicast address, the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function; in a case that the first shared tunnel information comprises a tunnel identifier, the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function; or in a case that the first shared tunnel information does not comprise the tunnel identifier, the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function. However, 3GPP teaches wherein when the interaction assistance information comprises first shared tunnel information, the interaction assistance information meets at least one of following: in a case that the first shared tunnel information comprises a transmission address, and the transmission address is a multicast address, the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function (p.43 For multicast transport of the multicast distribution, it indicates in the downlink tunnel information the transport multicast address for the multicast session, The SMF determines that the shared tunnel is used for multicast packet transferring and the interaction with UPF is not needed); in a case that the first shared tunnel information comprises a transmission address, and the transmission address is a unicast address or not a multicast address, the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function; in a case that the first shared tunnel information comprises a tunnel identifier, the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function; or in a case that the first shared tunnel information does not comprise the tunnel identifier, the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function. Thus, it would have been obvious to one of ordinary skill in the art to implement MB sessions, taught by 3GPP, into the communication system, taught by Ronneke, in order to implement a well-known feature of a pre-defined protocol and enable multicast or broadcast. In addition, it would have been obvious to combine 3GPP and Ronneke in a known manner to obtain predictable results as the combination would not change the essence, quiddity, or functionality of the prior art references. As to claim 6: Ronneke teaches the method according to claim 1. Ronneke may not explicitly teach wherein the sending interaction assistance information to a first core network function comprises: sending, by the RAN node, the interaction assistance information to the first core network function based on second shared tunnel information; wherein the interaction assistance information meets at least one of following: when a first condition is met, the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function; or when a second condition is met, the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function, wherein the first condition comprises at least one of following: the second shared tunnel information comprises a tunnel identifier; or the second shared tunnel information comprises a transmission address, and the transmission address is a multicast address, wherein the second condition comprises at least one of following: the second shared tunnel information is unknown; or the second shared tunnel information comprises a transmission address, and the transmission address is a unicast address or not a multicast address. However, 3GPP teaches wherein the sending interaction assistance information to a first core network function comprises: sending, by the RAN node, the interaction assistance information to the first core network function based on second shared tunnel information (p.43 RAN nodes selects the AMF to reach MB-SMF and signals a request towards AMF [MB-SMF ID, Multicast context/group ID]); wherein the interaction assistance information meets at least one of following: when a first condition is met, the interaction assistance information is used to indicate any one of following: the first core network function optionally interacts with or does not interact with the second core network function, and the first core network function conditionally interacts with or does not interact with the second core network function (p.43 The SMF determines that the shared tunnel is used for multicast packet transferring and the interaction with UPF is not needed); or when a second condition is met, the interaction assistance information is used to indicate that the first core network function is required to interact with the second core network function (p.43 If RAN supports MBS, and if no user plane for multicast group distribution is established towards the RAN node, steps 14 to 18 are executed. RAN nodes selects the AMF to reach MB-SMF and signals a request towards AMF [MB-SMF ID, Multicast context/group ID].), wherein the first condition comprises at least one of following: the second shared tunnel information comprises a tunnel identifier (p.40 An UPF, based on configuration received from SMF, identifies a packet as belonging to a Multicast flow, in which case it delivers it to one or multiple RAN nodes via a shared tunnel identified by a shared TEID associated with the Multicast session context to which the Multicast flow belongs to); or the second shared tunnel information comprises a transmission address, and the transmission address is a multicast address (p.43 MB-SMF sends a multicast distribution session response to AMF. For multicast transport of the multicast distribution, it indicates in the downlink tunnel information the transport multicast address for the multicast session.), wherein the second condition comprises at least one of following: the second shared tunnel information is unknown; or the second shared tunnel information comprises a transmission address, and the transmission address is a unicast address or not a multicast address (p.164 f the RAN node is configured to use a unicast transport for multicast distribution sessions, it allocates a downlink tunnel ID (an IP address and a GTP-U TEID) for the reception of the multicast distribution session and indicates the downlink tunnel information in the request). Thus, it would have been obvious to one of ordinary skill in the art to implement MB sessions, taught by 3GPP, into the communication system, taught by Ronneke, in order to implement a well-known feature of a pre-defined protocol and enable multicast or broadcast. In addition, it would have been obvious to combine 3GPP and Ronneke in a known manner to obtain predictable results as the combination would not change the essence, quiddity, or functionality of the prior art references. As to claim 7, 19: Ronneke teaches the method according to claim 1. Ronneke may not explicitly teach wherein the sending interaction assistance information to a first core network function comprises: sending, by the RAN node, the interaction assistance information to the first core network function through any one of following: a shared tunnel establishment request, and a shared tunnel release request. However, 3GPP teaches wherein the sending interaction assistance information to a first core network function comprises: sending, by the RAN node, the interaction assistance information to the first core network function through any one of following: a shared tunnel establishment request (p.43 RAN nodes selects the AMF to reach MB-SMF and signals a request towards AMF [MB-SMF ID, Multicast context/group ID]), and a shared tunnel release request (p.51 RAN node selects the AMF to reach MB-SMF and signals a request for the Multicast user plane distribution release towards that AMF [MB-SMF ID, Multicast context/group ID, downlink tunnel information]). Thus, it would have been obvious to one of ordinary skill in the art to implement MB sessions, taught by 3GPP, into the communication system, taught by Ronneke, in order to implement a well-known feature of a pre-defined protocol and enable multicast or broadcast. In addition, it would have been obvious to combine 3GPP and Ronneke in a known manner to obtain predictable results as the combination would not change the As to claim 13: Ronneke teaches the method according to claim 8, wherein when the interaction assistance information indicates that the first core network function optionally interacts with or does not interact with the second core network function (p.43 The SMF determines that the shared tunnel is used for multicast packet transferring and the interaction with UPF is not needed), or indicates that the first core network function conditionally interacts with or does not interact with the second core network function (p.43 If RAN supports MBS, and if no user plane for multicast group distribution is established towards the RAN node, steps 14 to 18 are executed), the method further comprises at least one of following: when the RAN node is a first RAN node or a last RAN node when serving a multicast and broadcast service or a session, the first core network function invokes information related to multicast and broadcast service management or session management to the second core network function (p.40 The user plane between the ingress node and the RAN node only needs to be added when the first users served by the RAN node joins the multicast group; p.43 RAN nodes selects the AMF to reach MB-SMF and signals a request towards AMF [MB-SMF ID, Multicast context/group ID). As to claim 14: Ronneke teaches the method according to claim 8. Ronneke may not explicitly each wherein the invoking, based on the interaction assistance information, information related to multicast and broadcast service management or session management to a second core network function, comprises at least one of following: the first core network function invokes information related to multicast and broadcast service management or session management to the second core network function when the interaction assistance information meets at least one of following: comprising information that is required to be sent to the second core network function; comprised first indication information indicates that the first core network function is required to interact with the second core network function; comprised transmission type indication information indicates that the transmission type is unicast; or comprising shared tunnel information; or the first core network function invokes information related to multicast and broadcast service management or session management to the second core network function, when the interaction assistance information meets at least one of following: the information that is required to be sent to the second core network function is absent; comprised first indication information indicates optionally interacting with or not interacting with the second core network function; comprised first indication information indicates conditionally interacting with or not interacting with the second core network function; comprised transmission type indication information indicates that the transmission type is multicast; or shared tunnel information is absent. However, 3GPP teaches wherein the invoking, based on the interaction assistance information, information related to multicast and broadcast service management or session management to a second core network function, comprises at least one of following: the first core network function invokes information related to multicast and broadcast service management or session management to the second core network function when the interaction assistance information (p.43 RAN nodes selects the AMF to reach MB-SMF and signals a request towards AMF [MB-SMF ID, Multicast context/group ID].) meets at least one of following: comprising information that is required to be sent to the second core network function; comprised first indication information indicates that the first core network function is required to interact with the second core network function (p.43 If RAN supports MBS, and if no user plane for multicast group distribution is established towards the RAN node, steps 14 to 18 are executed); comprised transmission type indication information indicates that the transmission type is unicast (p.43 If the RAN node is configured to use a unicast transport for multicast distribution sessions, it allocates a downlink tunnel ID (an IP address and a GTP-U TEID) for the reception of the multicast distribution session and indicates the downlink tunnel information in the request); or comprising shared tunnel information (p.43 If the RAN node is configured to use a unicast transport for multicast distribution sessions, it allocates a downlink tunnel ID (an IP address and a GTP-U TEID)); or the first core network function invokes information related to multicast and broadcast service management or session management to the second core network function, when the interaction assistance information meets at least one of following: the information that is required to be sent to the second core network function is absent; comprised first indication information indicates optionally interacting with or not interacting with the second core network function; comprised first indication information indicates conditionally interacting with or not interacting with the second core network function; comprised transmission type indication information indicates that the transmission type is multicast; or shared tunnel information is absent. Thus, it would have been obvious to one of ordinary skill in the art to implement MB sessions, taught by 3GPP, into the communication system, taught by Ronneke, in order to implement a well-known feature of a pre-defined protocol and enable multicast or broadcast. In addition, it would have been obvious to combine 3GPP and Ronneke in a known manner to obtain predictable results as the combination would not change the essence, quiddity, or functionality of the prior art references. Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ronneke (US-20230309189) in view of 3GPP TR 23.247 v17.0.0 (2021-09) Architectural Enhancements for 5G Multicast-Broadcast Services; Ling (WO-2022229883-A1). As to claim 15: Ronneke teaches the method according to claim 8. Ronneke may not explicitly teach wherein the method further comprises: invoking, by the first core network function … when serving a multicast and broadcast service or a session, information related to multicast and broadcast service management or session management to the second core network function; wherein the invoking, based on whether the RAN node is a first RAN node or a last RAN node when serving a multicast and broadcast service or a session, information related to multicast and broadcast service management or session management to the second core network function: when the RAN node is a first RAN node or a last RAN node when serving a multicast and broadcast service, the first core network function invokes information related to multicast and broadcast service management or session management to the second core network function. However, 3GPP TR 23.247 teaches wherein the method further comprises: invoking, by the first core network function (section 7.2.2.4 The AMF invokes Nmbsmf_MBSSession_ReceptionEnd request (MBS Session ID, N2 SM information) to the MB-SMF corresponding to the MB-SMF ID stored in the AMF for the MBS Session ID.) … when serving a multicast and broadcast service or a session (section 7.2.2.4 The MB-SMF responses to the AMF. If there's no RAN node controlled by the AMF serving the multicast session, the MB-SMF also removes the AMF ID from the context of the multicast session; A RAN node decides to release shared delivery for an MBS session, e.g. because it no longer serves at least one UE within the MBS session. For location dependent services, the NG-RAN node may release shared delivery for the location dependent contents of an MBS session if it no longer serves at least one UE assigned to an MBS session ID and area session ID.), information related to multicast and broadcast service management or session management to the second core network function (section 7.2.2.4 The AMF invokes Nmbsmf_MBSSession_ReceptionEnd request (MBS Session ID, N2 SM information) to the MB-SMF corresponding to the MB-SMF ID stored in the AMF for the MBS Session ID); wherein the invoking, based on whether the RAN node is a first RAN node or a last RAN node when serving a multicast and broadcast service or a session, information related to multicast and broadcast service management or session management to the second core network function: when the RAN node is a first RAN node or a last RAN node when serving a multicast and broadcast service , the first core network function invokes information related to multicast and broadcast service management or session management to the second core network function (section 7.2.2.4 The NG-RAN node sends N2 MBS Session release request (MBS Session ID, [unicast GTP TEID], [Area Session ID]) to the AMF. For location dependent services, the NG-RAN node also provides the Area Session ID. The RAN node includes the unicast GTP TEID if unicast transport is used for the shared delivery. The AMF invokes Nmbsmf_MBSSession_ReceptionEnd request (MBS Session ID, N2 SM information) to the MB-SMF corresponding to the MB-SMF ID stored in the AMF for the MBS Session ID.). Thus, it would have been obvious to one of ordinary skill in the art to implement shared delivery when needed and releasing resources when not needed, taught by 3GPP, into the communication system, taught by Ronneke, in order to implement a well-known feature of a pre-defined protocol and improve multicast management efficiency. In addition, it would have been obvious to combine Ronneke and 3GPP in a known manner to obtain predictable results as the combination would not change the essence, quiddity, or functionality of the prior art references. Ronneke may not explicitly teach based on whether the RAN node is a first RAN node or a last RAN node. However, Ling teaches based on whether the RAN node is a first RAN node or a last RAN node ([0099] 3. For multicast transport, the AMF will send the Multicast distribution release request to the MB-SMF with the AMF ID, only when there are no NG-RANs serving the MBS session). Thus, it would have been obvious to one of ordinary skill in the art to implement determine whether RAN node is first or last serving the MBS session, taught by Ling, into the communication system, taught by Ronneke, in order to implement a well-known feature of a pre-defined protocol and improve signaling efficiency. In addition, it would have been obvious to combine Ling and Ronneke in a known manner to obtain predictable results as the combination would not change the essence, quiddity, or functionality of the prior art references. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW CHUNG SUK OH whose telephone number is (571)270-5273. The examiner can normally be reached M-F 12p-8p. 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, Faruk Hamza can be reached at 5712727969. 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. /ANDREW C OH/ Primary Examiner, Art Unit 2466
Read full office action

Prosecution Timeline

Mar 22, 2024
Application Filed
May 28, 2026
Non-Final Rejection mailed — §102, §103
Aug 26, 2026
Response Filed
Oct 14, 2026
Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12757069
SWITCHING MECHANISM FOR DYNAMIC MULTICAST OPTIMIZATION
2y 9m to grant Granted Oct 06, 2026
Patent 12757200
WIRELESS COMMUNICATION METHOD, USER EQUIPMENT, AND BASE STATION
2y 5m to grant Granted Oct 06, 2026
Patent 12727044
METHOD FOR TRANSMITTING CONTROL SIGNALING IN RELAY NETWORK, CONFIGURATION METHOD AND DEVICE
2y 2m to grant Granted Sep 01, 2026
Patent 12713501
METHOD AND DEVICE FOR GROUP-BASED SENSING IN WIRELESS LAN SYSTEM
2y 8m to grant Granted Aug 18, 2026
Patent 12706711
SOUNDING REFERENCE SIGNAL REPETITION CONFIGURATION
3y 4m to grant Granted Aug 11, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

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

Prosecution Projections

3-4
Expected OA Rounds
70%
Grant Probability
84%
With Interview (+14.4%)
3y 6m (~11m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 568 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