Prosecution Insights
Last updated: October 23, 2026
Application No. 18/377,642

GLOBAL BANDWIDTH-AWARE ADAPTIVE ROUTING

Final Rejection §103
Filed
Oct 06, 2023
Priority
Aug 25, 2023 — IN 202311057144
Examiner
FOLLANSBEE, JOHN A
Art Unit
2458
Tech Center
2400 — Computer Networks
Assignee
Mellanox Technologies Ltd.
OA Round
4 (Final)
12%
Grant Probability
At Risk
5-6
OA Rounds
10m
Est. Remaining
15%
With Interview

Examiner Intelligence

Grants only 12% of cases
12%
Career Allowance Rate
5 granted / 42 resolved
-46.1% vs TC avg
Minimal +3% lift
Without
With
+3.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 10m
Avg Prosecution
12 currently pending
Career history
69
Total Applications
across all art units

Statute-Specific Performance

§101
7.7%
-32.3% vs TC avg
§103
45.8%
+5.8% vs TC avg
§102
22.2%
-17.8% vs TC avg
§112
18.2%
-21.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 42 resolved cases

Office Action

§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 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), filed on 9/26/2025 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 9/26/2025 has been entered. Claims 1-20 are pending. Response to Arguments 2. Applicant's arguments been fully considered but they are not persuasive. The applicant argues the following issues. (A) Rejection under 35 U.S.C. 102 and 103 Issue 1: The applicant argues that the cited references do not show “at least one switch to determine an event associated with a change in network bandwidth between a local host and a remote host located downstream of the local host and the at least one switch, and to provide, response to the change in network bandwidth, routing protocols for the network communication, the routing protocols to be used to modify one or more non-binary weight values of an adaptive routing algorithm in the at least one switch for selection of one or more different routes for the network communication between the local host and the remote host” as recited in claim 1. Examiner respectfully disagrees, Abys discloses a system for global bandwidth-aware adaptive routing in a network communication, comprising: at least one switch to determine an event associated with a change in network bandwidth between a local host and a remote host located downstream of the local host and the at least one switch (e.g., figures 2A-2C and figure 6 step 640, next hop or subsequent next hop is the remote host), and to provide, responsive to the change in network bandwidth (e.g. col. 12, “determine that they are congested … queuing delays … lost packets”), routing protocols for the network communication, the routing protocols to be used to modify one or more weights of an adaptive routing algorithm in the at least one switch for selection of at least one or more different routes for the network communication between the local host and the remote host (col. 12, last paragraph, “In some implementations, a virtual switch monitors or measures link congestion and dynamically routes packets around congested links. For example, based on such congestion monitoring, the ToR switch may determine that links through the IGHN are congested and, as a result, select as the next hop a destination in the fat tree. In some implementations, network congestion may be monitored directly by a virtual switch, for example, by detecting queuing delays or lost data packets (e.g., unacknowledged TCP requests) over certain links. In some other implementations, host servers and ToR switches in the IGHN can instead explicitly communicate their relative congestion levels, for example, using control messages. In some implementations, congestion is detected using the Explicit Congestion Notification (ECN) protocol”, wherein the congestion event is an event of changed available bandwidth, and changing next hop is modifying one or more weights of an adaptive routing algorithm for selection of a different route, in that changing to the selected next hop is equivalent to modifying a weight of the selected next hop to 1 and to modifying a weight of the previous and non-selected next hop to zero. It is to be noted that the claimed does not require a specific type of weight in the algorithm to be modified therefore Examiner interprets as any type of weight. See col. 12, “the ToR switch implements a hypercube routing protocol. For example, C. Glass and L. Ni "The Tum Model for Adaptive Routing" (1994) describes several routing protocols for a direct hypercube. These protocols can be used with an indirect generalized hypercube network topology, treating each server group as a virtual switch”. See also Figure 6 and col. 11. It is to be noted that the claimed “local” and “remote” is not limited to any specific reference entity therefore Examiner interprets as local/remote to any reference entity, alternatively, see col. 11-col. 12 and Figure 6). However, Abys does not expressly disclose that the weights are non-binary weight values. McDonald discloses weights being non-binary weight values ([0023], “The adaptive weight for each of the non-minimal candidate routes can be calculated by combining the actual congestion in the minimal candidate routes and the actual congestion in the non-minimal candidate routes in different ways. In some other examples the routing engine may also assign an adaptive weight to each minimal candidate route as a function of the congestion in the respective minimal candidate route and the hop count of the minimal candidate route.” And [0030]-[0031]). Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Abys with McDonald. The suggestion/motivation would have been to provide adaptive routing based on actual congestion weight (McDonough, [0023]). Claim Rejections - 35 USC § 103 3. 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. 4. 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. 5. 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. 6. Claims 1-2, 4-9, 11-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over by Abys e al (US 9705798) in view of McDonald (US 2019/0104054). As to claim 1, Abys discloses a system for global bandwidth-aware adaptive routing in a network communication, comprising: at least one switch to determine an event associated with a change in network bandwidth between a local host and a remote host located downstream of the local host and the at least one switch (e.g., figures 2A-2C and figure 6 step 640, next hop or subsequent next hop is the remote host), and to provide, responsive to the change in network bandwidth (e.g. col. 12, “determine that they are congested … queuing delays … lost packets”), routing protocols for the network communication, the routing protocols to be used to modify one or more weights of an adaptive routing algorithm in the at least one switch for selection of at least one or more different routes for the network communication between the local host and the remote host (col. 12, last paragraph, “In some implementations, a virtual switch monitors or measures link congestion and dynamically routes packets around congested links. For example, based on such congestion monitoring, the ToR switch may determine that links through the IGHN are congested and, as a result, select as the next hop a destination in the fat tree. In some implementations, network congestion may be monitored directly by a virtual switch, for example, by detecting queuing delays or lost data packets (e.g., unacknowledged TCP requests) over certain links. In some other implementations, host servers and ToR switches in the IGHN can instead explicitly communicate their relative congestion levels, for example, using control messages. In some implementations, congestion is detected using the Explicit Congestion Notification (ECN) protocol”, wherein the congestion event is an event of changed available bandwidth, and changing next hop is modifying one or more weights of an adaptive routing algorithm for selection of a different route, in that changing to the selected next hop is equivalent to modifying a weight of the selected next hop to 1 and to modifying a weight of the previous and non-selected next hop to zero. It is to be noted that the claimed does not require a specific type of weight in the algorithm to be modified therefore Examiner interprets as any type of weight. See col. 12, “the ToR switch implements a hypercube routing protocol. For example, C. Glass and L. Ni "The Tum Model for Adaptive Routing" (1994) describes several routing protocols for a direct hypercube. These protocols can be used with an indirect generalized hypercube network topology, treating each server group as a virtual switch”. See also Figure 6 and col. 11. It is to be noted that the claimed “local” and “remote” is not limited to any specific reference entity therefore Examiner interprets as local/remote to any reference entity, alternatively, see col. 11-col. 12 and Figure 6). However, Abys does not expressly disclose that the weights are non-binary weight values. McDonald discloses weights being non-binary weight values ([0023], “The adaptive weight for each of the non-minimal candidate routes can be calculated by combining the actual congestion in the minimal candidate routes and the actual congestion in the non-minimal candidate routes in different ways. In some other examples the routing engine may also assign an adaptive weight to each minimal candidate route as a function of the congestion in the respective minimal candidate route and the hop count of the minimal candidate route.” And [0030]-[0031]). Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Abys with McDonald. The suggestion/motivation would have been to provide adaptive routing based on actual congestion weight (McDonough, [0023]). As to claim 8, see similar rejection to claim 1. As to claim 15, see similar rejection to claim 1. As to claim 2, Abys-McDonald discloses the system of claim 1, wherein the event is failed or congested link in the different routes between the local host and the remote host, the failed or congested link to cause the change in the network bandwidth between the local host and the remote host (Abys, see citation in rejection to claim 1, events indicating that links are congested). As to claim 9, see similar rejection to claim 2. As to claim 16, see similar rejection to claim 2. As to claim 4, Abys discloses the claimed invention substantially as discussed in claim 1, including a modification feature to be used to perform the modification of the adaptive routing algorithm using weighting values (see citation in rejection, wherein the weight of 1 is used for the new next hop and weight of 0 is used for the old next hop), but does not expressly disclose a conversion feature to convert the event to the weighting values. McDonald discloses a concept of converting congestion event into weighting values ([0023]). Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Abys with McDonald. The suggestion/motivation would have been to provide adaptive routing based on actual congestion weight (McDonough, [0023]). As to claim 11, see similar rejection to claim 4. As to claim 18, see similar rejection to claim 4. As to claim 5, Abys-McDonald discloses the system of claim 1, wherein the modification to the adaptive routing algorithm comprises a weight change to a plurality of next-hops providing the different routes for the network communication between the local host and the remote host, wherein the weight change removes at least one of the plurality of next-hops (see citation in rejection to claim 5, Abys, wherein change next hop indicates replacing/removing the previous next hop). As to claim 12, see similar rejection to claim 5. As to claim 6, Abys-McDonald discloses the system of claim 1, wherein the at least one switch comprises an interface to receive instructions to enable the determination of the event associated with the change in network bandwidth and to enable a determination of the routing protocols for the network communication (see citation in rejection to claim 1, Abys, wherein the interface that receives a notification of congestion event is equivalent to an interface to receive instructions to enable subsequent steps such as the determination of the event associated with the change in network bandwidth and to enable a determination of the routing protocols for the network communication. It is to be noted that the claimed limitation is “enable”). As to claim 13, see similar rejection to claim 6. As to claim 19, see similar rejection to claim 6. As to claim 7, Abys-McDonald discloses the system of claim 1, wherein the at least one switch is within a predetermined hop distance from the remote host (Abys, col. 11-col. 12; Figure 6, one hop distance from the destination), the at least one switch further to: receive the event in a communication associated with the remote host; and remove at least one of a plurality of next-hops to the remote host, as part of the routing protocols, based in part on the communication to provide the modification of the adaptive routing algorithm in the at least one switch (see citation in rejection to claim 1, wherein changing next hop in responsive to the event is equivalent to remove the previous next hop from the route). As to claim 14, see similar rejection to claim 7 As to claim 20, see similar rejection to claim 7. 7. Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Abys-McDonald, as applied to claim 1 above, and further in view of KiuChi (US 6882653). As to claim 3, Abys-McDonald discloses the claimed invention substantially as discussed in claim 1, including protocols enabling communication of the event between the at least one switch and other switches in the network communication, but does not expressly disclose a Border Gateway Protocol (BGP). KiuChi discloses a concept to use BGP protocol to communicate events (col. 1, last paragraph to col. 2, paragraph 1. It is to be noted that the claimed limitation merely requires “enabling”). Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Abys-McDonald with KiuChi. The suggestion/motivation of the combination would have been to notifying a fault or congestion of traffic and instructing alternative routing (Riuchi, col. 1 last paragraph to col. 2, paragraph 2). As to claim 10, see similar rejection to claim 3. As to claim 17, see similar rejection to claim 3. 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 John Follansbee whose telephone number is 571-272-3964. The examiner can normally be reached on 9-6. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /JOHN A FOLLANSBEE/ Supervisory Patent Examiner, Art Unit 2444
Read full office action

Prosecution Timeline

Show 7 earlier events
Jul 30, 2025
Examiner Interview Summary
Sep 26, 2025
Request for Continued Examination
Oct 07, 2025
Response after Non-Final Action
Dec 31, 2025
Non-Final Rejection mailed — §103
Feb 09, 2026
Examiner Interview Summary
Feb 09, 2026
Applicant Interview (Telephonic)
Jun 01, 2026
Response Filed
Oct 09, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12757113
ADAPTIVE SYNCHRONIZATION MANAGEMENT SYSTEM FOR ENHANCING WIRELESS NETWORK PERFORMANCE
3y 6m to grant Granted Oct 06, 2026
Patent 12757152
ASSISTANCE DATA UPDATE BASED ON POSITIONING REFERENCE SIGNALS AND SYNCHRONIZATION SIGNAL BLOCK SIGNALS
2y 11m to grant Granted Oct 06, 2026
Patent 12745071
METHODS AND APPARATUSES FOR NETWORK FUNCTION DISCOVERY
2y 4m to grant Granted Sep 22, 2026
Patent 12706839
System and Method for Minimizing Data Packet Loss During Traffic Migration to a Software Defined Networking (SDN) Appliance
2y 3m to grant Granted Aug 11, 2026
Patent 12696136
APPLICATION LAYER CONTROL PLANE
2y 8m to grant Granted Jul 28, 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

5-6
Expected OA Rounds
12%
Grant Probability
15%
With Interview (+3.2%)
3y 10m (~10m remaining)
Median Time to Grant
High
PTA Risk
Based on 42 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