DETAILED ACTION
In response to communications filed 04/29/2026.
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 .
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 Gundavelli et al. (US 2024/0007395 A1) hereinafter “Starsinic” and “Gundavelli” respectively.
Regarding Claim 1, Starsinic teaches A method comprising:
receiving, by one or more routing devices (Starsinic: paragraph 0016 & Fig. 1, one or more routers or gateway devices) in a local area network (LAN) (Starsinic: paragraph 0016 & Fig. 1, access network; see also paragraphs 0057-0058 & Fig. 6A, wireless network WLAN implementation, gateway devices in wireless LAN), 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 (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) in a provider network (Starsinic: paragraph 0057, communication network further comprising the Internet);
identifying, by the one or more 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 one or more routing device (Starsinic: paragraph 0035 & Fig. 4, said one or more routers), one or more sources of delay-tolerant traffic in the LAN (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 one or more routing devices and based on the routing policy (Starsinic: paragraph 0035 & Fig. 1, said one or more routers), instructions via the LAN, for the one or more sources (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).
Starsinic fails to explicitly receiving, by one or more routing devices in a local area network (LAN) for a customer premises and from a provider network used by the LAN. However, Gundavelli from an analogous art teaches a wireless LAN controller receiving a Route Selection Policy (URSP) from a network controller of a cloud network for a user device connected to an enterprise network to send and receive data over multiple radio access technologies (Gundavelli: paragraphs 0033-0035, 0050, 0060 & Fig. 4A). Gundavelli further teaches the URSP may be determined based on parameters and specifications provided by a network operator and according to enterprise policies (Gundavelli: paragraph 0071) therefore similarly teaching a provider network used by the enterprise or wireless LAN.
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 to include receiving QoS policies or a Route Selection Policy (URSP) from a controller of the provider network as taught by Gundavelli so as to obtain routing policies based on conditions directly from the provider network.
Regarding Claim 2, Starsinic-Gundavelli teaches the respective claim(s) as presented above and further teaches wherein the one or more routing device include a fixed wireless access (FWA) device for the LAN (Starsinic: paragraph 0016 & Fig. 1, said one or more routers in the access network). Examiner recites same reasoning to combine Starsinic-Gundavelli as presented in rejected claim 1 above to teach a router in a customer premises network.
Regarding Claim 3, Starsinic-Gundavelli teaches the respective claim(s) as presented above and further teaches receiving, by the one or more routing devices 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-Gundavelli 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-Gundavelli 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-Gundavelli 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-Gundavelli teaches the respective claim(s) as presented above and further teaches wherein the one or more routing devices include 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-Gundavelli teaches the respective claim(s) as presented above and further teaches wherein the one or more source of delay-tolerant traffic include 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-Gundavelli 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 (Gundavelli: paragraph 0050, machine learning to classify application requirements). Examiner recites same reasoning to combine Starsinic-Gundavelli as presented in rejected claim 1.
Regarding Claim 11, Starsinic teaches A system (Starsinic: paragraph 0016, system), comprising:
one or more routing devices (Starsinic: paragraph 0016 & Fig. 1, one or more routers or gateway devices) in a local area network (LAN) (Starsinic: paragraph 0016 & Fig. 1, access network; see also paragraphs 0057-0058 & Fig. 6A, wireless network WLAN implementation, gateway devices in wireless LAN), 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 LAN (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 LAN (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 LAN (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).
Starsinic fails to explicitly receiving, by one or more routing devices in a local area network (LAN) for a customer premises and from a provider network used by the LAN. However, Gundavelli from an analogous art teaches a wireless LAN controller receiving a Route Selection Policy (URSP) from a network controller of a cloud network for a user device connected to an enterprise network to send and receive data over multiple radio access technologies (Gundavelli: paragraphs 0033-0035, 0050, 0060 & Fig. 4A). Gundavelli further teaches the URSP may be determined based on parameters and specifications provided by a network operator and according to enterprise policies (Gundavelli: paragraph 0071) therefore similarly teaching a provider network used by the enterprise or wireless LAN.
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 to include receiving QoS policies or a Route Selection Policy (URSP) from a controller of the provider network as taught by Gundavelli so as to obtain routing policies based on conditions directly from the provider network.
Regarding Claim 12, Starsinic-Gundavelli teaches the respective claim(s) as presented above and further teaches wherein the one or more routing devices include a fixed wireless access (FWA) device for the LAN (Starsinic: paragraph 0016 & Fig. 1, said one or more routers in the access network).
Regarding Claim 13, Starsinic-Gundavelli teaches the respective claim(s) as presented above and further teaches send, via a broadcast signal over the LAN, 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; see also paragraphs 0022, 0036 & 0039, marking (label) to indicate how the packet should be handled or processed).
Regarding Claim 14, Starsinic-Gundavelli 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-Gundavelli 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-Gundavelli teaches the respective claim(s) as presented above and further teaches wherein the source of delay-tolerant traffic includes a client device connected (Starsinic: paragraph 0035 & Fig. 1, said end user devices), via a wireless connection, to the one or more 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 or gateway devices) in a local area network (LAN) ((Starsinic: paragraph 0016 & Fig. 1, access network; see also paragraphs 0057-0058 & Fig. 6A, wireless network WLAN implementation, gateway devices in wireless LAN), 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 LAN (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 LAN (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 LAN (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 LAN (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).
Starsinic fails to explicitly receiving, by one or more routing devices in a local area network (LAN) for a customer premises and from a provider network used by the LAN. However, Gundavelli from an analogous art teaches a wireless LAN controller receiving a Route Selection Policy (URSP) from a network controller of a cloud network for a user device connected to an enterprise network to send and receive data over multiple radio access technologies (Gundavelli: paragraphs 0033-0035, 0050, 0060 & Fig. 4A). Gundavelli further teaches the URSP may be determined based on parameters and specifications provided by a network operator and according to enterprise policies (Gundavelli: paragraph 0071) therefore similarly teaching a provider network used by the enterprise or wireless LAN.
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 to include receiving QoS policies or a Route Selection Policy (URSP) from a controller of the provider network as taught by Gundavelli so as to obtain routing policies based on conditions directly from the provider network.
Regarding Claim 19, Starsinic-Gundavelli teaches the respective claim(s) as presented above and further teaches sending, via a broadcast signal over the LAN, 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-Gundavelli 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-Gundavelli in view of Magyar et al. (US 2013/0133041 A1) hereinafter “Magyar.”
Regarding Claim 5, Starsinic-Gundavelli teaches the respective claim(s) as presented above however fails to explicitly teach obtaining, by the one or more routing devices, 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-Gundavelli 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-Gundavelli teaches the respective claim(s) as presented above and further teaches a client device including an 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-Gundavelli 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-Gundavelli 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:
a) Starsinic-Gundavelli alone or in combination fails to teach receiving a control plane signaling indicating network congestion conditions from a base station (remarks, page 4).
b) Starsinic-Gundavelli alone or in combination fails to teach sending a network identifier for a traffic category to be paused via a broadcast signal over the LAN (remarks, page 4).
Examiner's response:
Applicant's arguments filed 04/29/2026 have been fully considered but they are not persuasive.
Regarding argument a), Starsinic teaches the communication network may comprise multiple access networks including a fixed Ethernet network and cellular wireless network (Starsinic: paragraph 0057 & Fig. 6A). As previously presented, Starsinic teaches routers may further be implemented as eNodeBs (Starsinic: paragraph 0020). Since Starsinic teaches a router may determine a condition situation in a cellular network (Starsinic: paragraphs 0038, 0041 & Fig. 4) and further teaches a plurality of routers in communication with at least one eNodeB of a cellular network in at least one embodiment, Starsinic similarly teaches receiving conditions from the base station of the provider network in communication with the routers of the cpe.
Regarding argument b), as previously presented Starsinic teaches sending delay tolerance parameters to determine which flows need to be terminated, reduced, delayed, or disallowed (Starsinic: paragraph 0043). Starsinic further teaches devices may mark data plane packets (specific label packet marking) with an indication of what kind of QoS treatment is required by each of the devices in which the marking (label) may indicate how the packet should be handled or processed (Starsinic: paragraphs 0022, 0036 & 0039). Examiner notes since the label is indicative of the determined route, Starsinic similarly teaches sending or including an identifier to indicate which packets and/or flows of traffic are paused based on the QoS requirements.
All other 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
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 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 (571) 272-3988. 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
Prosecution Insights