Prosecution Insights
Last updated: April 19, 2026
Application No. 17/869,749

DYNAMIC TETHERING MECHANISM FOR POWER SAVING

Non-Final OA §102§103
Filed
Jul 20, 2022
Examiner
NGUYEN, CHUONG M
Art Unit
2411
Tech Center
2400 — Computer Networks
Assignee
MediaTek Inc.
OA Round
4 (Non-Final)
72%
Grant Probability
Favorable
4-5
OA Rounds
3y 2m
To Grant
92%
With Interview

Examiner Intelligence

Grants 72% — above average
72%
Career Allow Rate
330 granted / 457 resolved
+14.2% vs TC avg
Strong +19% interview lift
Without
With
+19.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
61 currently pending
Career history
518
Total Applications
across all art units

Statute-Specific Performance

§101
2.6%
-37.4% vs TC avg
§103
65.0%
+25.0% vs TC avg
§102
9.2%
-30.8% vs TC avg
§112
15.7%
-24.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 457 resolved cases

Office Action

§102 §103
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 a. Claims 1-20 in the present application, filed on or after March 16, 2013, are being examined under the first inventor to file provisions of the AIA . - claim 9 is canceled b. This is a second non final action on the merits based on Applicant’s claims submitted on 12/23/2025. Response to Arguments Regarding independent claims 1 and 13 previously rejected under 35 U.S.C. § 102(a)(2), Applicant's arguments, see “However, British Telecom teaches that a tether request receiver in a tether provider receives a request from an external tether requestor. It does not teach the tethering device (i.e., the tether provider) receiving cellular information of its own internal cellular network. Therefore, British Telecom does not explicitly teach the claimed limitation: "receive cellular information of a cellular network of the tethering device" and “Therefore, British Telecom does not explicitly teach the claimed limitation: "the power manager dynamically determines a second tethering mode with different supported speed or bandwidth according to the updated cellular information".” on pages 7-8, filed on 12/23/2025, with respect to British Telecom Foreign Patent EP3343962 (hereinafter “British Telecom”), have been fully considered and are persuasive. Therefore, the previous rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Wang et al. US Pub 2024/0064776 (hereinafter “Wang”), in combination with previously applied reference British Telecom. See section Claim Rejections - 35 USC § 103 below for complete details. 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 of this title, 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. 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 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. Claims 1-8 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over British Telecom Foreign Patent EP3343962 (hereinafter “British Telecom”), and in view of Wang et al. US Pub 2024/0064776 (hereinafter “Wang”). Regarding claim 1 British Telecom discloses a controller (“Figure 4 shows the components of an auto tether controller 35, 55 in the first embodiment.” [0048]) of a tethering device (“Figure 3 shows an example of the data path between the third mobile device 21 (a tether client) and the first mobile device 3 (a tether provider) when the tether link has been established as shown in Figure 2.” [0036]), comprising: a power manager (i.e. “tether setup manager 97” in Fig. 4 and furthermore determining which tethering interface would be best for a tethering power requirement “If tether clients are available at both the WiFi and Bluetooth interfaces, WiFi will only be selected if the mobile device is charging from a power source or if it is not charging but has sufficient battery power, for example 60%. Otherwise Bluetooth is selected. This is because WiFi can provide a faster data speeds although it can use more power than Bluetooth.” [0101]); and a tethering manager (i.e. “mode selector 83” in Fig. 4; “a mode selector 83 which determines from the inputs whether to enable the auto tether function and which mode to use” [0049]), configured to use the first tethering mode to configure at least one interface of the tethering device, wherein the at least one interface (e.g. “USB 41, 59, Bluetooth 43 61, WiFi 45, 63 and cellular 37, 57 interfaces” [0053]) of the tethering device is used to communicate with an electronic device (“the device is connected to a base station” [0047]), and the electronic device shares the cellular network of the tethering device via the at least one interface (“The mode selector 83, tether requestor function 85 and the tether provider function 91 are linked to a local interface controller and routing table 99 for controlling the data paths during the tether operations. The local interface controller and routing table 75 connects the auto tether controller to the OS 33, 53, and network interfaces of the mobile device such as USB 41, 59, Bluetooth 43 61, WiFi 45, 63 and cellular 37, 57 interfaces of the mobile device.” [0053]); British Telecom does not specifically teach a power manager configured to receive cellular information of a cellular network of the tethering device, and determine a first tethering mode from a plurality of tethering modes according to the cellular information; wherein if the cellular information of the tethering device is updated so that a supported bandwidth is changed, the power manager dynamically determines a second tethering mode with different supported speed or bandwidth according to the updated cellular information, and the tethering manager uses the second tethering mode to configure the at least one interface of the tethering device. In an analogous art, Wang discloses a power manager (i.e. “host UE device 102”) configured to receive cellular information of a cellular network (e.g. “cellular network 100” in Fig. 1) of the tethering device (“the host UE device 102 determines one or more network slices 118 for a client UE device 104 responsive to the client UE device 104 establishing a tethered connection (downstream link) 114 with the host UE device 102, or upon receiving a request from the client UE device 104 to access the cellular network 100.” [0053]), and determine a first tethering mode from a plurality of tethering modes according to the cellular information (“For example, after analyzing a selection policy 126 for the third network slice 118-3, the host UE device 102 determines that context information 124 such as device type, tethered connection type, tethered connection frequency, and data type (i.e. plurality of tethering modes) are needed to determine if the third network slice 118-3 can be selected for the client UE device 104. The host UE device 102 then communicates with the client UE device 104 to obtain this context information 124. However, in at least some embodiments, this and other context information 124 is already provided to the host UE device 102 as part of establishing the tethered connection 114. As such, the context 124 of the client UE device 104 can be automatically provided to host UE device 102 by the client UE device 104, and/or the host UE device 102 can query the client UE device 104 for context information 124.” [0053]); wherein if the cellular information of the tethering device is updated so that a supported bandwidth is changed (“As data and bandwidth allotments have increased for end-users, tethering has become a more viable and useful option for accessing the Internet through cellular networks.” [0026]), the power manager (i.e. “host UE device 102”) dynamically determines a second tethering mode with different supported speed or bandwidth according to the updated cellular information (“The method 600 is initiated in response to the host UE device 102 determining that a tethering mode should be enabled.” [0077]), and the tethering manager uses the second tethering mode (“In response to this determination, the host UE device 102 enables the tethering mode at block 602. The host UE device 102, at block 604, attaches to the cellular network 100. The host UE device 102, at block 606, determines if the cellular network 100 is a 5G NR Standalone (SA) network. If the result of this determination is negative (e.g., the cellular network 100 is an LTE network or a 5G NR Non-Standalone (NSA) network), the host UE device 102, at block 608, uses a default upstream link 116-1 and default network slice 118-1 for all tethered client UE devices 104. The host UE device 102 continues with this configuration until a determination is made at block 610 that tethering is no longer enabled. When a determination is made that tethering is no longer enabled, the process then ends at block 612.” [0077]) to configure the at least one interface of the tethering device (“For example, a wired connection between the host UE device 102 and a client UE device 104 can be made using a Universal Serial Bus (USB) connection, an Ethernet connection, and so on. A wireless connection can be made using, for example, Wi-Fi (that is, one or more of the IEEE 802.11 wireless standards), Bluetooth®, Zigbee®, Near-field Communication (NFC), and so on.” [0035]). Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify British Telecom’s method for automatic mobile device, to include Wang’s network communication tethering mechanism, in order to determine when to switch tethering communication protocol (Wang [0001]). Thus, a person of ordinary skill would have appreciated the ability to incorporate Wang’s network communication tethering mechanism into British Telecom’s method for automatic mobile device since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Regarding claim 2 British Telecom, as modified by Wang, previously discloses the controller of claim 1, Wang further discloses wherein the cellular information comprises a radio access technology (RAT) currently used by the tethering device (“However, it should be understood that the present disclosure is not limited to networks employing a 5G NR RAT configuration, but rather the techniques described herein can be applied to any combination of different RATs employed at the UE devices and the RANs. It should also be understood that the present disclosure is not limited to any specific network configurations or architectures described herein for implementing network slicing (or equivalent technology) with tethered connections, but instead, techniques described herein can be applied to any configuration of RANs where a host UE device can establish multiple concurrent upstream links to implement different network slices for tethered client UE devices.” [0031]), a band currently used by the tethering device, and/or a real network speed of the tethering device (“the following techniques are described in an example context in which one or more UE devices and Radio Access Networks (RANs) implement one or more radio access technologies (RATs) including at least a Fifth Generation (5G) New Radio (NR) standard (e.g., Third Generation Partnership Project (3GPP) Release 15, 3GPP Release 16, etc.) (hereinafter, “5G NR” or “5G NR standard”).” [0031]). Regarding claim 3 British Telecom, as modified by Wang, previously discloses the controller of claim 1, British Telecom further discloses wherein the interface of the tethering device is a Wi-Fi interface (“Tethering is a process whereby a mobile device can connect to, and use another nearby device's cellular data link where its own connection to the cellular network is not available via a short range local device communication path. Additionally, tethering can be used for other classes of user entity such as tablets and laptop computers which do not have cellular network interfaces but can tether using WiFi™, USB or Bluetooth™.” [0008]), the power manager refers to the cellular information to select the first tethering mode from the plurality of tethering modes (“the tether setup manager updates the local interface controller and routing table 99 with a set of rules” [0112] and furthermore “The mode selector 83, tether requestor function 85 and the tether provider function 91 are linked to a local interface controller and routing table 99 for controlling the data paths during the tether operations. The local interface controller and routing table 75 connects the auto tether controller to the OS 33, 53, and network interfaces of the mobile device such as USB 41, 59, Bluetooth 43 61, WiFi 45, 63 and cellular 37, 57 interfaces of the mobile device.” [0053]). Wang further discloses wherein the plurality of tethering modes comprise different combinations of antenna modes (“By way of example, the antennas 302 and the RF front end 304 operate in sub-gigahertz bands, sub-6 GHz bands, and/or above 6 GHz bands defined by the 3GPP LTE, 3GPP 5G NR, or other communication standards.” [0064-0065]), bandwidths, and/or bands for the Wi-Fi interface (“For example, the selection criteria 228 may indicate specific parameters or attributes (e.g., latency, bandwidth, services, SLAs, etc.) of a network slice 118 to be selected for a given client UE device 104.” [0050]). Regarding claim 4 British Telecom, as modified by Wang, previously discloses the controller of claim 1, British Telecom further discloses wherein the interface of the tethering device is an Universal Serial Bus (USB) interface (“USB 41, 59” in Fig. 3; [0053]), the power manager refers to the cellular information to select the first tethering mode from the plurality of tethering modes (“the tether setup manager updates the local interface controller and routing table 99 with a set of rules” [0112] and furthermore “The mode selector 83, tether requestor function 85 and the tether provider function 91 are linked to a local interface controller and routing table 99 for controlling the data paths during the tether operations. The local interface controller and routing table 75 connects the auto tether controller to the OS 33, 53, and network interfaces of the mobile device such as USB 41, 59, Bluetooth 43 61, WiFi 45, 63 and cellular 37, 57 interfaces of the mobile device.” [0053]). Wang further discloses wherein the interface of the tethering device is an Universal Serial Bus (USB) interface (“The tethered connection 114 (also referred to as a downstream link 114) can be established using wired or wireless technologies. For example, a wired connection between the host UE device 102 and a client UE device 104 can be made using a Universal Serial Bus (USB) connection, an Ethernet connection, and so on.” [0035]), and wherein the plurality of tethering modes comprise different combinations of connection types, speed modes, and/or transfer queue parameters for the USB interface (“For example, selection criteria 228 can include tethered connection parameters such as link type (e.g., wired or wireless, USB, Wi-Fi, Bluetooth®, etc.), link frequency, channel, and so on; client UE device type; media access control (MAC) address; source Internet Protocol (IP) address of the data associated with the client UE device 104; the destination IP address of the data associated with the client UE device 104; the communication port associated with the data of the client UE device 104; the applications and/or services on the client UE device 104 requesting data; the mobility status (e.g., in a vehicle, stationary, on a pedestrian, traveling above or below a speed threshold, etc.) of the client UE device 104; a combination thereof; and so on.” [0051]). Regarding claim 5 British Telecom, as modified by Wang, previously discloses the controller of claim 1, British Telecom further discloses the power manager refers to the cellular information to select the first tethering mode from the plurality of tethering modes (“the tether setup manager updates the local interface controller and routing table 99 with a set of rules” [0112] and furthermore “The mode selector 83, tether requestor function 85 and the tether provider function 91 are linked to a local interface controller and routing table 99 for controlling the data paths during the tether operations. The local interface controller and routing table 75 connects the auto tether controller to the OS 33, 53, and network interfaces of the mobile device such as USB 41, 59, Bluetooth 43 61, WiFi 45, 63 and cellular 37, 57 interfaces of the mobile device.” [0053]). Wang further discloses wherein the interface of the tethering device is an Ethernet interface (“The tethered connection 114 (also referred to as a downstream link 114) can be established using wired or wireless technologies. For example, a wired connection between the host UE device 102 and a client UE device 104 can be made using a Universal Serial Bus (USB) connection, an Ethernet connection, and so on.” [0035]), and wherein the plurality of tethering modes comprise different combinations of cable types, low power mode settings, and/or transfer queue parameters for the Ethernet interface (“For example, the selection criteria 228 may indicate specific parameters or attributes (e.g., latency, bandwidth, services, SLAs, etc.) of a network slice 118 to be selected for a given client UE device 104.” [0050]). Regarding claim 6 British Telecom, as modified by Wang, previously discloses the controller of claim 1, British Telecom further discloses wherein the power manager determines the first tethering mode whose corresponding bandwidth of the interface is lower than or closest to a cellular bandwidth of the tethering device from a plurality of tethering modes (“Permission Parameters/thresholds relating to whether tethering is allowed to be provided: Cellular status ∘ Cellular reception strength, e.g. - do not offer tethering if the backhaul link is below 5Mbps ∘ Remaining data allowance, e.g. do not provide tethering is there is less than 500Mb allowance remaining. Other parameters can be defined relating to the operation of the tether provider in offering and providing tethering.” [0057-0058]). Regarding claim 7 British Telecom, as modified by Wang, previously discloses the controller of claim 1, British Telecom further discloses wherein the power manager receives the cellular information and usage information of the tethering device, and determines the first tethering mode according to the cellular information and the usage information (“Other parameters can be defined relating to the operation of the tether provider in offering and providing tethering. Performance Parameters related to the tethering service when allowed: A data cap/limit value for how much data from the user's data subscription plan is allowed to be used for tethering Data rate cap on bandwidth offered Rules for a tether request when the user has fully used their data allowance Tether interface priority-default is USB, WiFi, Bluetooth.” [0058-0059]) Regarding claim 8 British Telecom, as modified by Wang, previously discloses the controller of claim 7, British Telecom further discloses wherein the usage information comprises network usage statistics indicating the flow of signal transmission/reception (“In this embodiment, the definable parameters include: Permission Parameters/thresholds relating to whether tethering is allowed to be provided: Time ∘ Times when tethering is automatically allowed ∘ Times when tethering is automatically rejected ∘ Times where the user of the tether provider device must manually accept or reject the session Device status ∘ Battery life considerations, e.g. do not offer tethering if the battery level is below 20% ∘ Processing load, e.g. do not offer tethering if the processing load is above 80%.” [0057]). Regarding claim 10 British Telecom, as modified by Wang, previously discloses the controller of claim 1, British Telecom further discloses wherein the power manager determines the second tethering mode (“Performance Parameters related to the tethering service when allowed: Tether interface priority-default is USB, WiFi, Bluetooth” [0059]) whose corresponding bandwidth of the interface is lower than or closest to a cellular bandwidth of the tethering device from a plurality of tethering modes (“Permission Parameters/thresholds relating to whether tethering is allowed to be provided: Cellular status ∘ Cellular reception strength, e.g. - do not offer tethering if the backhaul link is below 5Mbps Other parameters can be defined relating to the operation of the tether provider in offering and providing tethering.” [0057-0058]). Regarding claim 11 British Telecom, as modified by Wang, previously discloses the controller of claim 1, British Telecom further discloses wherein if the cellular information of the tethering device is updated, the power manager dynamically determines the second tethering mode according to the updated cellular information and usage information of the tethering device (“the mobile devices involved in tethering are modified so that the tethering interaction can be carried out without user intervention. This enables a data connection to be made available in a more seamless manner and furthermore the created link is formed with knowledge of the type of data connection and likely usage cases during the tether session.” [0025] and furthermore “Different types of application have different levels of bandwidth consumption and this is determined and included in the request. For example, if the device was inactive at the time of connectivity loss, then the request will indicate low expected usage. If there was an active web browsing, then request would indicate medium expected usage and if the user was in a video call or streaming media, then high activity would be indicated.” [0094]). Regarding claim 12 British Telecom, as modified by Wang, previously discloses the controller of claim 1, Wang further discloses wherein the usage information comprises network usage statistics indicating the flow of signal transmission/reception (“can request to release its current network slice(s) 118 and/or activate a new network slice(s) 118” [0062]), and the power manager determines if a connection between the tethering device and the electronic device is able to be interrupted (“proceeds to deactivate the second network slice 118-2”) according to the usage information, for the determination of the second tethering device (“A client UE device 104, in at least some embodiments, can request to release its current network slice(s) 118 and/or activate a new network slice(s) 118. For example, the second client UE device 104-2 can send a request to the host UE device 102 using the tethered connection 114-2 to release the second network slice 118-2 activated for the second client UE device 104-2. The host UE device 102 then proceeds to deactivate the second network slice 118-2 and, in at least some embodiments, the associated upstream link 116-2. If the second client UE device 104-2 has requested a new network slice 118, the host UE device 102 activates the new network slice 118 for the second client UE device 104-2 according to the network slice selection techniques described above and establishes a new upstream link 116 if needed.” [0062]). Regarding claim 13 A control method of a tethering device, comprising: receiving cellular information of a cellular network of the tethering device, and determining a first tethering mode from a plurality of tethering modes according to the cellular information; and using the first tethering mode to configure at least one interface of the tethering device, wherein the at least one interface of the tethering device is used to communicate with an electronic device, and the electronic device shares the cellular network of the tethering device via the at least one interface; if the cellular information of the tethering device is updated so that a supported bandwidth is changed, dynamically determining a second tethering mode with different supported speed or bandwidth according to the updated cellular information, and using the second tethering mode to configure the at least one interface of the tethering device. The scope and subject matter of method claim 13 is drawn to the method of using the corresponding apparatus claimed in claim 1. Therefore method claim 13 corresponds to apparatus claim 1 and is rejected for the same reasons of anticipation as used in claim 1 rejection above. Regarding claim 14 The control method of claim 13, wherein the cellular information comprises a radio access technology (RAT) currently used by the tethering device, a band currently used by the tethering device, and/or a real network speed of the tethering device. The scope and subject matter of method claim 14 is drawn to the method of using the corresponding apparatus claimed in claim 2. Therefore method claim 14 corresponds to apparatus claim 2 and is rejected for the same reasons of obviousness as used in claim 2 rejection above. Regarding claim 15 The control method of claim 13, wherein the interface of the tethering device is a Wi-Fi interface, and the step of receiving the cellular information of a cellular network of the tethering device, and determining the first tethering mode from a plurality of tethering modes according to the cellular information comprises: referring to the cellular information to select the first tethering mode from the plurality of tethering modes, wherein the plurality of tethering modes comprise different combinations of antenna modes, bandwidths, and/or bands for the Wi-Fi interface. The scope and subject matter of method claim 15 is drawn to the method of using the corresponding apparatus claimed in claim 3. Therefore method claim 15 corresponds to apparatus claim 3 and is rejected for the same reasons of obviousness as used in claim 3 rejection above. Regarding claim 16 The control method of claim 13, wherein the interface of the tethering device is an Universal Serial Bus (USB) interface, and the step of receiving the cellular information of a cellular network of the tethering device, and determining the first tethering mode from a plurality of tethering modes according to the cellular information comprises: referring to the cellular information to select the first tethering mode from the plurality of tethering modes, wherein the plurality of tethering modes comprise different combinations of connection types, speed modes, and/or transfer queue parameters for the USB interface. The scope and subject matter of method claim 16 is drawn to the method of using the corresponding apparatus claimed in claim 4. Therefore method claim 16 corresponds to apparatus claim 4 and is rejected for the same reasons of obviousness as used in claim 4 rejection above. Regarding claim 17 The control method of claim 13, wherein the interface of the tethering device is an Ethernet interface, and the step of receiving the cellular information of a cellular network of the tethering device, and determining the first tethering mode from a plurality of tethering modes according to the cellular information comprises: referring to the cellular information to select the first tethering mode from the plurality of tethering modes, wherein the plurality of tethering modes comprise different combinations of cable types, low power mode settings, and/or transfer queue parameters for the Ethernet interface. The scope and subject matter of method claim 17 is drawn to the method of using the corresponding apparatus claimed in claim 5. Therefore method claim 17 corresponds to apparatus claim 5 and is rejected for the same reasons of obviousness as used in claim 5 rejection above. Regarding claim 18 The control method of claim 13, wherein the step of receiving the cellular information of a cellular network of the tethering device, and determining the first tethering mode from a plurality of tethering modes according to the cellular information comprises: determining the first tethering mode whose corresponding bandwidth of the interface is lower than or closest to a cellular bandwidth of the tethering device from the plurality of tethering modes. The scope and subject matter of method claim 18 is drawn to the method of using the corresponding apparatus claimed in claim 6. Therefore method claim 18 corresponds to apparatus claim 6 and is rejected for the same reasons of obviousness as used in claim 6 rejection above. Regarding claim 19 The control method of claim 13, wherein the step of receiving the cellular information of a cellular network of the tethering device, and determining the first tethering mode from a plurality of tethering modes according to the cellular information comprises: receiving the cellular information and usage information of the tethering device, and determining the first tethering mode according to the cellular information and the usage information. The scope and subject matter of method claim 19 is drawn to the method of using the corresponding apparatus claimed in claim 7. Therefore method claim 19 corresponds to apparatus claim 7 and is rejected for the same reasons of obviousness as used in claim 7 rejection above. Regarding claim 20 The control method of claim 19, wherein the usage information comprises network usage statistics indicating the flow of signal transmission/reception. The scope and subject matter of method claim 20 is drawn to the method of using the corresponding apparatus claimed in claim 8. Therefore method claim 20 corresponds to apparatus claim 8 and is rejected for the same reasons of obviousness as used in claim 8 rejection above. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHUONG M NGUYEN whose telephone number is (571)272-8184. The examiner can normally be reached M-F 10:00am - 6:30pm. 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, Derrick Ferris can be reached at 571-272-3123. 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. /CHUONG M NGUYEN/Primary Examiner, Art Unit 2411
Read full office action

Prosecution Timeline

Jul 20, 2022
Application Filed
Dec 16, 2024
Non-Final Rejection — §102, §103
Feb 26, 2025
Response Filed
Mar 24, 2025
Final Rejection — §102, §103
Jun 05, 2025
Interview Requested
Jun 11, 2025
Examiner Interview Summary
Jun 11, 2025
Applicant Interview (Telephonic)
Jun 27, 2025
Request for Continued Examination
Jul 03, 2025
Response after Non-Final Action
Oct 06, 2025
Non-Final Rejection — §102, §103
Dec 23, 2025
Response Filed
Feb 10, 2026
Non-Final Rejection — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598653
METHOD FOR NODE USED FOR WIRELESS COMMUNICATION AND APPARATUS
2y 5m to grant Granted Apr 07, 2026
Patent 12587820
FREQUENCY RANGE 2 (FR2) NON-STANDALONE SIDELINK DISCOVERY
2y 5m to grant Granted Mar 24, 2026
Patent 12587920
DETECTING PHYSICAL CELL IDENTIFIER (PCI) CONFUSION DURING SECONDARY NODE (SN) CHANGE PROCEDURE IN WIRELESS NETWORKS
2y 5m to grant Granted Mar 24, 2026
Patent 12581480
USER EQUIPMENTS, BASE STATIONS AND METHODS FOR UPLINK TRANSMISSION IN INTERRUPTED TRANSMISSION INDICATION
2y 5m to grant Granted Mar 17, 2026
Patent 12538248
Expiry of Time Alignment Timer
2y 5m to grant Granted Jan 27, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

4-5
Expected OA Rounds
72%
Grant Probability
92%
With Interview (+19.3%)
3y 2m
Median Time to Grant
High
PTA Risk
Based on 457 resolved cases by this examiner. Grant probability derived from career allow 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