Prosecution Insights
Last updated: April 19, 2026
Application No. 18/051,152

SYSTEMS AND METHODS FOR INTELLIGENT MULTIPLEXING IN A WIRELESS ACCESS ROUTER

Non-Final OA §103
Filed
Oct 31, 2022
Examiner
ANSARI, NAJEEBUDDIN
Art Unit
2463
Tech Center
2400 — Computer Networks
Assignee
Verizon Patent and Licensing Inc.
OA Round
3 (Non-Final)
63%
Grant Probability
Moderate
3-4
OA Rounds
4y 4m
To Grant
99%
With Interview

Examiner Intelligence

Grants 63% of resolved cases
63%
Career Allow Rate
289 granted / 458 resolved
+5.1% vs TC avg
Strong +59% interview lift
Without
With
+58.8%
Interview Lift
resolved cases with interview
Typical timeline
4y 4m
Avg Prosecution
38 currently pending
Career history
496
Total Applications
across all art units

Statute-Specific Performance

§101
6.0%
-34.0% vs TC avg
§103
54.8%
+14.8% vs TC avg
§102
20.4%
-19.6% vs TC avg
§112
13.5%
-26.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 458 resolved cases

Office Action

§103
DETAILED ACTION In response to communications filed 11/14/2025. Claims 1-20 are pending for examination. 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 . Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/14/2025 has been entered. 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 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. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1-4, 6-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Starsinic et al. (US 2015/0029854 A1) in view of Lin et al. (US 2022/0167373 A1) hereinafter “Starsinic” and “Lin” respectively. Regarding Claim 1, Starsinic teaches A method comprising: receiving, by a routing device (Starsinic: paragraph 0016 & Fig. 1, one or more routers) in a network (Starsinic: paragraph 0016 & Fig. 1, access network in proximity to end point devices), a routing policy (Starsinic: paragraph 0035 & Fig. 4, router receiving QoS configuration message including QoS policies and/or new QoS rule), wherein the routing policy includes criteria (Starsinic: paragraph 0035 & Table 3, delay tolerance parameter) for applying delays to delay-tolerant traffic when congestion conditions are present in a provider network used by the network (Starsinic: paragraphs 0035 & 0043 and Table 3, access network can use the delay tolerance parameter during periods of congestion to determine which flows need to be terminated, reduced, delayed, or disallowed); identifying, by the routing device and after receiving the routing policy, (Starsinic: paragraph 0035 & Fig. 4, said one or more routers receiving QoS configuration including delay tolerance parameter), an indication of network congestion conditions in the provider network (Starsinic: paragraphs 0038, 0041 & Fig. 4, router may determine a congestion situation in the network); identifying, by the routing device (Starsinic: paragraph 0035 & Fig. 4, said one or more routers), one or more source of delay-tolerant traffic in the network (Starsinic: paragraph 0043, use the delay tolerance parameter to determine which flows need to be terminated, reduced, delayed, or disallowed in the access network during periods of congestion); and sending, by the routing device and based on the routing policy (Starsinic: paragraph 0035 & Fig. 1, said one or more routers), instructions via the network (Starsinic: paragraph 0038 & Fig. 4, sending a resource reservation adjustment from the access network) to pause data transmission of the delay-tolerant traffic after identifying the indication of network congestion conditions (Starsinic: paragraph 0043, when congestion is first detected, resources that are reserved for flows with a high delay tolerance can be reduced, completely terminated, delayed, or told to back-off which may further be based on the flow's delay tolerance). Although Starsinic teaches the one or more routers in the access network is in proximity to the end point devices, Starsinic fails to explicitly teach the one or more routers is specifically located in a customer premises network. However, Lin from an analogous art similarly teaches a wireless-communication device implemented as a central wireless router within range of a plurality of user devices for delay-aware bandwidth scheduling (Lin: paragraph 0031 & Fig. 1). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to modify the router of Starsinic as a central wireless router in a customer premise as taught by Lin to centralize management of traffic for multiple clients or users for further traffic configuration. Regarding Claim 2, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches wherein the routing device includes a fixed wireless access (FWA) device for the customer premises network (Starsinic: paragraph 0016 & Fig. 1, said one or more routers in the access network). Examiner recites same reasoning to combine Starsinic-Lin as presented in rejected claim 1 above to teach a router in a customer premises network. Regarding Claim 3, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches receiving, from a base station (Starsinic: paragraph 0020, router implemented as eNodeB), a control plane signal indicating network congestion conditions (Narula: paragraphs 0038, 0041 & Fig. 4, router may determine a congestion situation in the network). Regarding Claim 4, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches monitoring an uplink queue for congestion (Starsinic: paragraph 0052, uplink bandwidth at a given time to manage resources). Regarding Claim 6, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches receiving, via a registration process, a traffic category for the source (Starsinic: paragraph 0018, provision QoS rules on a per flow basis, thus categorizing a type of traffic). Regarding Claim 7, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches dynamically detecting a kind of traffic associated with an application based on one or more of a traffic pattern and a request/response history (Starsinic: paragraph 0017, detects that a rule needs to be applied to reserve resources for the traffic flow). Regarding Claim 8, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches wherein the routing device includes a fixed wireless access (FWA) router (Starsinic: paragraph 0016 & Fig. 1, said one or more routers in the access network), and wherein the source of the delay-tolerant traffic includes a client device connected to the FWA router (Starsinic: paragraph 0016 & Fig. 1, said end point devices). Regarding Claim 9, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches wherein the source of delay-tolerant traffic includes one of a client device or an application executed on the client device (Starsinic: paragraph 0035 & Fig. 1, said end user devices). Regarding Claim 10, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches deriving, by another device in a core network (Starsinic: paragraph 0041 & Fig. 1, Internet or cloud network), a machine-learning model to generate the routing policy for a base station (Lin: paragraph 0050, machine learning to classify application requirements). Examiner recites same reasoning to combine Starsinic-Lin as presented in rejected claim 1. Regarding Claim 11, Starsinic teaches A system (Starsinic: paragraph 0016, system), comprising: a routing device (Starsinic: paragraph 0016 & Fig. 1, one or more routers) in a network (Starsinic: paragraph 0016 & Fig. 1, access network in proximity to end point devices), the routing device configured to: receive, from a core network (Starsinic: paragraph 0057, core network), a routing policy (Starsinic: paragraph 0035 & Fig. 4, router receiving QoS configuration message including QoS policies and/or new QoS rule), wherein the routing policy includes criteria (Starsinic: paragraph 0035 & Table 3, delay tolerance parameter) for applying delays to delay-tolerant traffic when congestion conditions are present in a provider network used by the network (Starsinic: paragraphs 0035 & 0043 and Table 3, access network can use the delay tolerance parameter during periods of congestion to determine which flows need to be terminated, reduced, delayed, or disallowed); identify, after receiving the routing policy, an indication of network congestion conditions in the provider network (Starsinic: paragraph 0043 & Fig. 3, detect system state change that causes a redetermination of a latency sensitivity for first data; see also paragraph 0049, condition of links (i.e. noisy) at various times); identify a source of delay-tolerant traffic in the network (Starsinic: paragraphs 0035-0037 & 0049, determine whether data is delay-sensitive or normal data from a plurality of end user devices); and send, based on the routing policy, instructions via the network (Starsinic: paragraph 0038 & Fig. 4, sending a resource reservation adjustment from the access network) to pause data transmission of the delay-tolerant traffic after identifying the indication of network congestion conditions (Starsinic: paragraph 0043, when congestion is first detected, resources that are reserved for flows with a high delay tolerance can be reduced, completely terminated, delayed, or told to back-off which may further be based on the flow's delay tolerance). Although Starsinic teaches the one or more routers in the access network is in proximity to the end point devices, Starsinic fails to explicitly teach the one or more routers is specifically located in a customer premises network. However, Lin from an analogous art similarly teaches a wireless-communication device implemented as a central wireless router within range of a plurality of user devices for delay-aware bandwidth scheduling (Lin: paragraph 0031 & Fig. 1). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to modify the router of Starsinic as a central wireless router in a customer premise as taught by Lin to centralize management of traffic for multiple clients or users for further traffic configuration. Regarding Claim 12, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches wherein the routing device includes a fixed wireless access (FWA) device for the customer premises network (Starsinic: paragraph 0016 & Fig. 1, said one or more routers in the access network). Regarding Claim 13, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches send, via a broadcast signal over the customer premises network, a network identifier for a traffic category to be paused (Starsinic: paragraph 0043, sending delay tolerance parameters to determine which flows need to be terminated, reduced, delayed, or disallowed). Regarding Claim 14, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches receive, from a base station (Starsinic: paragraph 0020, router implemented as eNodeB), a control plane signal indicating network congestion conditions (Narula: paragraphs 0038, 0041 & Fig. 4, router may determine a congestion situation in the network). Regarding Claim 15, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches dynamically detect a kind of traffic associated with an application based one or more of a traffic pattern and a request/response history (Starsinic: paragraph 0017, detects that a rule needs to be applied to reserve resources for the traffic flow). Regarding Claim 16, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches wherein the delay-tolerant traffic source includes a client device connected (Starsinic: paragraph 0035 & Fig. 1, said end user devices), via a wireless connection, to the routing device (Starsinic: paragraphs 0057-0058, WLAN). Regarding Claim 18, Starsinic teaches A non-transitory computer-readable storage medium (Starsinic: paragraph 0008, computer-readable medium) containing instructions, executable by at least one processor (Starsinic: paragraph 0008, instructions executed on processor) of a routing device (Starsinic: paragraph 0035 & Fig. 1, access point), for: receiving, by the routing device (Starsinic: paragraph 0016 & Fig. 1, one or more routers) in a network (Starsinic: paragraph 0016 & Fig. 1, access network in proximity to end point devices, thus teaching the one or more routers are in a network), a routing policy (Starsinic: paragraph 0035 & Fig. 4, router receiving QoS configuration message including QoS policies and/or new QoS rule), wherein the routing policy includes criteria (Starsinic: paragraph 0035 & Table 3, delay tolerance parameter) for applying delays to delay-tolerant traffic when congestion conditions are present in a provider network used by the network (Starsinic: paragraphs 0035 & 0043 and Table 3, access network can use the delay tolerance parameter during periods of congestion to determine which flows need to be terminated, reduced, delayed, or disallowed); identifying, by the routing device and after receiving the routing policy, (Starsinic: paragraph 0035 & Fig. 4, said one or more routers receiving QoS configuration including delay tolerance parameter), an indication of network congestion conditions in the provider network for the network (Starsinic: paragraphs 0038, 0041 & Fig. 4, router may determine a congestion situation in the network); identifying, by the routing device (Starsinic: paragraph 0035 & Fig. 4, said one or more routers), one or more source of delay-tolerant traffic in the network (Starsinic: paragraph 0043, use the delay tolerance parameter to determine which flows need to be terminated, reduced, delayed, or disallowed in the access network during periods of congestion); and sending, by the routing device and based on the routing policy (Starsinic: paragraph 0035 & Fig. 1, said one or more routers), instructions via the network (Starsinic: paragraph 0038 & Fig. 4, sending a resource reservation adjustment from the access network) to pause data transmission of the delay-tolerant traffic after identifying the indication of network congestion conditions (Starsinic: paragraph 0043, when congestion is first detected, resources that are reserved for flows with a high delay tolerance can be reduced, completely terminated, delayed, or told to back-off which may further be based on the flow's delay tolerance). Although Starsinic teaches the one or more routers in the access network is in proximity to the end point devices, Starsinic fails to explicitly teach the one or more routers is specifically located in a customer premises network. However, Lin from an analogous art similarly teaches a wireless-communication device implemented as a central wireless router within range of a plurality of user devices for delay-aware bandwidth scheduling (Lin: paragraph 0031 & Fig. 1). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to modify the router of Starsinic as a central wireless router in a customer premise as taught by Lin to centralize management of traffic for multiple clients or users for further traffic configuration. Regarding Claim 19, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches sending, via a broadcast signal over the customer premises network, a network identifier for a traffic category to be paused (Starsinic: paragraph 0043, sending delay tolerance parameters to determine which flows need to be terminated, reduced, delayed, or disallowed). Regarding Claim 20, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches receiving, from a host application (Starsinic: paragraph 0058, M2M application), a signal indicating network congestion conditions (Starsinic: paragraphs 0038, 0041 & Fig. 4, determine a congestion situation in the network). Claims 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Starsinic-Lin in view of Magyar et al. (US 2013/0133041 A1) hereinafter “Magyar.” Regarding Claim 5, Starsinic-Lin teaches the respective claim(s) as presented above however fails to explicitly teach obtaining, by the routing device, subscriber input via a client device connected to the routing device, for delaying the data transmissions. However, Magyar from an analogous art determines when network conditions are suitable for sending delay tolerant data traffic (Magyar: paragraphs 0026 & 0054) and further teaches a subscriber may mark traffic as delay tolerant (Magyar: paragraph 0052). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to modify Starsinic-Lin to include subscriber input for delaying transmissions as suggested in Magyar so as to further delay data transmissions based on client preferences. Regarding Claim 17, Starsinic-Lin teaches the respective claim(s) as presented above and further teaches a client device including application (Starsinic: paragraph 0035 & Fig. 1, said end user devices and application) configured to: receive instructions from the routing device to delay data transmissions (Starsinic: paragraph 0038 & Fig. 4, apply the QoS rules and to determine how long the QoS rules should be applied). Starsinic-Lin fails to explicitly teach obtain subscriber consent for delaying the data transmissions. However, Magyar from an analogous art determines when network conditions are suitable for sending delay tolerant data traffic (Magyar: paragraphs 0026 & 0054) and further teaches a subscriber may mark traffic as delay tolerant thus indicating or consenting for delaying transmissions (Magyar: paragraph 0052). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to modify Starsinic-Lin to include subscriber input for delaying transmissions as suggested in Magyar so as to further delay data transmissions based on client preferences. Response to Arguments Applicant’s arguments with respect to amended claims 1, 11 and 18 have been considered but are moot in view of the new ground(s) of rejection. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAJEEB ANSARI whose telephone number is (571)270-5446. The examiner can normally be reached Monday-Friday 10am to 2pm. 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, ASAD NAWAZ can be reached at 469-295-9193. 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. /NAJEEB ANSARI/Examiner, Art Unit 2463 /ASAD M NAWAZ/Supervisory Patent Examiner, Art Unit 2463
Read full office action

Prosecution Timeline

Oct 31, 2022
Application Filed
Mar 15, 2025
Non-Final Rejection — §103
Jun 03, 2025
Response Filed
Sep 06, 2025
Final Rejection — §103
Oct 30, 2025
Response after Non-Final Action
Nov 14, 2025
Request for Continued Examination
Nov 23, 2025
Response after Non-Final Action
Feb 07, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12592870
COMMUNICATION METHOD AND RELATED DEVICE
2y 5m to grant Granted Mar 31, 2026
Patent 12587899
OVERLOAD STATUS DATA TRANSMISSION TO DISTRIBUTED UNIT ENABLING OVERLOAD ACTION AT DISTRIBUTED UNIT
2y 5m to grant Granted Mar 24, 2026
Patent 12549450
SYSTEMS AND METHODS FOR CONVERGED BASEBAND AND AI OPERATIONS
2y 5m to grant Granted Feb 10, 2026
Patent 12538146
MICROSERVICES FOR CENTRALIZED UNIT USER PLANE (CU-UP) AND CENTRALIZED UNIT CONTROL PLANE (CU-CP) STANDBY PODS IN A CLOUD-NATIVE FIFTH GENERATION (5G) WIRELESS TELECOMMUNICATION NETWORK
2y 5m to grant Granted Jan 27, 2026
Patent 12526685
GENERATING LONG-TERM NETWORK CHANGES FROM SLA VIOLATIONS
2y 5m to grant Granted Jan 13, 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

3-4
Expected OA Rounds
63%
Grant Probability
99%
With Interview (+58.8%)
4y 4m
Median Time to Grant
High
PTA Risk
Based on 458 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