Prosecution Insights
Last updated: July 17, 2026
Application No. 18/625,738

SYSTEMS AND DEVICES FOR NETWORK DATA COLLECTION, TRANSMISSION, AND PROCESSING

Final Rejection §103§112
Filed
Apr 03, 2024
Examiner
MENDAYE, KIDEST H
Art Unit
2457
Tech Center
2400 — Computer Networks
Assignee
Mellanox Technologies Ltd.
OA Round
2 (Final)
81%
Grant Probability
Favorable
3-4
OA Rounds
5m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 81% — above average
81%
Career Allowance Rate
296 granted / 364 resolved
+23.3% vs TC avg
Strong +32% interview lift
Without
With
+31.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
16 currently pending
Career history
387
Total Applications
across all art units

Statute-Specific Performance

§101
1.1%
-38.9% vs TC avg
§103
94.3%
+54.3% vs TC avg
§102
1.6%
-38.4% vs TC avg
§112
0.6%
-39.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 364 resolved cases

Office Action

§103 §112
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 2. Claims 1-22 are pending. Response to argument Applicant amendment/argument filed on 02/26/2026 has been fully considered, but they are moot in view of new ground(s) of rejection. Claim Rejections - 35 USC § 112 3. The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 4. Claims 1 15 and 18 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention. 5. The specification describes para. [0029] “a centralized computing device (e.g., data receiver / configuration transmitter) receives these data packets and determines configuration updates for the networked devices based on these data packets. The configuration updates occur locally by the centralized computing device within a datacenter cluster so as to reduce or otherwise avoid any computational burden on other systems or components (e.g., at the host level or otherwise).” However the specification does not clearly define what constitutes “in the absence of a transmission” nor does it provide a reasonably certain standard for determining whether an external transmission present or absent during generation configuration updates. The description determine updates locally to avoid burden on the components does not expressly prohibit external transmission nor does it clarify whether incidental or routine external communications. Because the claim fails to inform a person of ordinary skill in the art, with reasonable certainty what is meant by “in the absence of a transmission” the scope of the claim is ambiguous. The ambiguity renders the claim indefinite. Appropriate correction is required. Claim Rejections - 35 USC § 103 6. In the event the determination of the status of the application as subject to AlA 35 U.S.C. 102 and 103 (or as subject to pre-AlA 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. 7. 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. 8. Claims 1,5,7-8 14-15, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Labovitz et al. ( US 20250047714 A1) hereinafter Labovitz in view of Zhu et al. (US 20210007011 A1) hereinafter Zhu. Regarding claims, 1 15 and 18, Labovitz a system for network data collection and processing, the system (see figs 1, and 5) comprising: a first networked device comprising at least a processor of a first DPU of the first network device (para. see fig. 1 para. [0031], [0054]); wherein the first networked device is configured to generate one or more first data packets comprising one or more event-driven data entries associated with the first networked device and/or one or more manipulated outputs generated based on manipulations to the event-driven data entries (para. [0077] at step 595, the set of servers 522 receives router configuration information from the routers 521. The router configuration information for a router 521 may include an indication of the vendor of the router 521, an indication of the router model of the router 521, an indication of a set of capabilities supported by the router 521 (e.g., hardware capabilities, an indication of a capacity of the router 521, an indication of status information associated with the router 521 (e.g., a router status of the router 521, one or more component statuses of one or more components of the router.. [0083] …the feedback information received from the routers 521 may include traffic information related to traffic being received at the routers 521 (e.g., packets or packet samples, packet flows or packet flow samples, or the like, as well as various combinations thereof); a centralized computing device comprising at least a processor, wherein the centralized computing device is communicably coupled with the at least one networked device(see Figs. 1 and 10) and configured to: receive the one or more first data packets from the first networked device (para. [0083] the feedback information received from the routers 521 may include traffic information related to traffic being received at the routers 521 (e.g., packets or packet samples, packet flows or packet flow samples, or the like, as well as various combinations thereof), which may be evaluated by the set of servers 522 to determine the efficacy of the router-specific security rules previously provided to the routers 521); determined one or more configuration updates based at least in part on the one or more first data packets (para.[0069],[0081],[0083] the feedback information received from the routers 521 may include traffic information related to traffic being received at the routers 521 (e.g., packets or packet samples, packet flows or packet flow samples, or the like. which may be evaluated by the set of servers 522 to determine the efficacy of the router-specific security rules previously provided to the routers 521 (e.g., based on a determination that one or more of the router-specific security rules for one or more of the routers 521 may be adjusted accordingly and provided to the routers 521 for use by the routers 521 to continue to mitigate the security event), wherein the one or more configuration updates are generated locally by the centralized computing device (para. [0081] the set of servers 522 may generate the router-specific security rules based on modification of the set of security rules to form the router-specific security rules. The set of servers 522 may generate the router-specific security rules based on modification of the set of security rules, based on the router configuration information and/or the router telemetry data, to form the router-specific security rules [0082] The set of servers 522 may generate the router-specific security rules using one or more rule programming languages. The set of servers 522 may generate the router-specific security rules for a router 521 using one or more programming languages that compiles the security rules and outputs router-specific security rules usable by the router 521 as determined from the router configuration information for the router 521. For example, the router-specific security rules may be defined using one or more of NetConf, YANG, CLI, or the like, as well as various combinations thereof. The router-specific security rules may be specified using any other suitable rule specification languages which may be supported by the routers 521. [0086] At block 630, generate, based on compiling of the security rule based on the network device information, a device-specific security rule for the network device, wherein the device-specific security rule is based on a programming language); and transmit the one or more configuration updates to the first networked device (para. [0083] the feedback information received from the routers 521 may include operating parameters of the routers 521 associated with handling of traffic at the routers 521, which may be evaluated by the set of servers 522 to determine the efficacy of the router-specific security rules previously provided to the routers 521, one or more of the router-specific security rules for one or more of the routers 521 may be adjusted accordingly and provided to the routers 521 for use by the routers 521 to continue to mitigate the security event. [0086] At block 640, send the device-specific security rule toward the network device (see also figs. 5-6). Labovitz discloses determine one or more configuration updates based at least in part on the one or more first data packets, wherein the one or more configuration updates are generated by the centralized computing device as recited above. Labovitz may not exactly disclose wherein the one or more configuration updates are generated locally by the centralized computing device in the absence of a transmission by the centralized computing device that is external to the system. However, Zhu discloses the one or more configuration updates are generated locally by the centralized computing device in the absence of a transmission by the centralized computing device that is external to the system (para. [0244] the mapping rule may be a mapping rule locally generated by the RN 2 based on information such as a QoS parameter configuration corresponding to a DRB/QoS flow of the UE and a QoS parameter configuration of a DRB of the RN 2 (see also 112 (b) rejection above)). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz and include the one or more configuration updates are generated locally by the centralized computing device in the absence of a transmission by the centralized computing device that is external to the system using the teaching of Zhu . One would have been motivated to do so in order to provide flow control information feedback to multiple network connected devices. Regarding claims 5 and 20, claim 1 is incorporated. Labovitz further discloses wherein the first networked device is further configured to: receive the one or more configuration updates from the centralized computing device; and modify one or more operations performed by the first networked device based on the one or more configuration updates (para. [0083] the feedback information received from the routers 521 may include traffic information related to traffic being received at the routers 521 (e.g., packets or packet samples, packet flows or packet flow samples, or the like, as well as various combinations thereof), which may be evaluated by the set of servers 522 to determine the efficacy of the router-specific security rules previously provided to the routers 521 (e.g., based on a determination that there is still bad traffic being received at the routers 521 that needs to be dropped, one or more of the router-specific security rules for one or more of the routers 521 may be adjusted accordingly and provided to the routers 521 for use by the routers 521 to continue to mitigate the security event). For example, the feedback information received from the routers 521 may include operating parameters of the routers 521 associated with handling of traffic at the routers 521, which may be evaluated by the set of servers 522 to determine the efficacy of the router-specific security rules previously provided to the routers 521 (e.g., based on a determination that the operating parameters indicate an unexpected or unusual strain on the routers 521, one or more of the router-specific security rules for one or more of the routers 521 may be adjusted accordingly and provided to the routers 521 for use by the routers 521 to continue to mitigate the security event). Regarding claim 7, claim 1 is incorporated. Labovitz further discloses wherein the second networked device is configured to: generate one or more event-driven data entries associated with the second networked device; and generate one or more second data packets comprising the one or more event-driven data entries of the second networked device (para. [0077] [0083] at step 595, the set of servers 522 receives router configuration information from the routers 521. The router configuration information for a router 521 may include an indication of the vendor of the router 521, an indication of the router model of the router 521, an indication of a set of capabilities supported by the router 521 (e.g., hardware capabilities, software capabilities (e.g., programming languages supported) or the like), an indication of a capacity of the router 521, an indication of status information associated with the router 521 (e.g., a router status of the router 521, one or more component statuses of one or more components of the router, or the like, as well as various combinations thereof), or the like, as well as various combinations thereof. It will be appreciated that, although the router configuration information is only depicted as being received from router 521-B, router configuration information may be received from any of the routers 521 in the communication network 520…[0078] At step 596, the set of servers 522 receives router telemetry data from the routers 521. The router telemetry data for a router 521 may include one or more of packet mirroring traffic from the router 521, IPFIX data from the router 521, SNMP traps from the router 521, gRPC data from the router 521, or the like, as well as various combinations thereof. It will be appreciated that, although the router telemetry data is only depicted as being received from router 521-C, router telemetry data may be received from any of the routers 521 in the communication network 520). Regarding claim 8, claim 7 is incorporated. Labovitz further discloses wherein the one or more event-driven data entries generated by the first networked device and the second networked device further comprise time data indicative of a time at which the respective event-driven data entries were generated (para. [0077]-[0078, [0065] the security attack samples are samples of security attacks which have occurred and each security attack sample may include security attack information describing the security attack (e.g., attack type of the attack, date and time of the attack, location of the attack, etc..). Regarding claim 14, claim 7 is incorporated. Labovitz further discloses wherein the first networked device, the second networked device, and the centralized computing device are formed in a common datacenter cluster such that the first data packet generation by the first networked device, the second data packet generation by the second networked device, and the determination of the one or more configuration updates by the centralized computing device occur within the common datacenter cluster. (para. [0026] the communication network 110 may be any type of network, such as a telecommunications service provider network a datacenter network, an enterprise network, a content distribution network (CDN), or the like, as well as various combinations thereof. The network security system 120 is configured to support security for the communication network 110. The external networks 130 may include various types of networks with which the communication network 110 may interact for various purposes, such as telecommunications service provider networks, datacenter networks, enterprise networks, the Internet, or the like, as well as various combinations thereof. It will be appreciated that the communication system 100 may include various other elements which may be arranged in various ways. [0027] The communication network 110 may include any type of network for which security may be provided by the network security system 120. For example, the communication network 110 may include a datacenter network (e.g., including servers communicating via switches (e.g., top-of-rack (ToR) switches), routers, and so forth). For example, the communication network 110 may include an enterprise network. It will be appreciated that the communication network 110 may be implemented in various other ways and may include any communication network(s) for which security may be provided by the network security system 120. [0069] the one or more network devices that are configured in step 497 may be the same one or more network devices 411 as those configured in step 495 and/or may include one or more different network devices 411 than those configured in step 495….(see also para. [0076]-[0077] [0083]). 9. Claims 2 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view of Patel et al. (US 20220021738 A1) hereinafter Patel. Regarding claims 2 and 16, claim 1 is incorporated. Labovitz/Zhu may not explicitly disclose wherein the first networked device further comprises a first data buffer within which the first networked device aggregates event-driven data entries associated with the first networked device. However, Patel discloses wherein the first networked device further comprises a first data buffer within which the first networked device aggregates event-driven data entries associated with the first networked device (para. [0038] the virtual router buffers and aggregates multiple tunneled packets received from the underlying physical network fabric prior to delivery to the appropriate routing instance for the packets). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz/Zhu and include wherein the first networked device further comprises a first data buffer within which the first networked device aggregates event-driven data entries associated with the first networked device using the teaching of Patel. One would have been motivated to do so in order to leverage analytics in a distributed architecture to provide near or seemingly-near real-time and historic monitoring, performance visibility and dynamic optimization to improve orchestration, security, accounting and planning within the computing environment. 10. Claims 3 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view of Ji (US 20240214312 A) hereinafter Ji. Regarding claims 3 and 17, claim 1 is incorporated. Labovitz/Zhu may not explicitly disclose , wherein the one or more first data packets are transmitted by the first networked device to the centralized computing device via one or more Remote Direct Memory Access (RDMA) operations. However, Ji discloses wherein the one or more first data packets are transmitted by the first networked device to the centralized computing device via one or more Remote Direct Memory Access (RDMA) operations (para. [0060] when the first network device is a source server, an application layer in the first network device sends a message to a transport layer in the first network device, where the message includes the RDMA data needing to be sent to the destination server. After obtaining the message sent by the application layer, the first network device generates at least one RDMA packet based on the message, where the at least one RDMA packet includes a same transmission identifier. [0062] When the first network device generates a plurality of RDMA packets based on the message sent by the application layer, the first network device adds a same transmission identifier to the plurality of RDMA packets. RDMA data included in the plurality of RDMA packets generated by the first network device belongs to a same message, and the plurality of RDMA packets need to be transmitted in sequence to ensure that the destination server can receive complete RDMA data in the message. Therefore, the first network device adds a same transmission identifier to the plurality of RDMA packets, to ensure that the plurality of RDMA packets can be transmitted in sequence. For example, the first network device may allocate a transmission identifier to the message, and all the plurality of RDMA packets generated by the first network device based on the message include the transmission identifier corresponding to the message, to ensure that the plurality of RDMA packets corresponding to the message include a same transmission identifier). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz/Zhu and include wherein the one or more first data packets are transmitted by the first networked device to the centralized computing device via one or more Remote Direct Memory Access (RDMA) operations using the teaching of Ji. One would have been motivated to do so in order to improve utilization rate of the network bandwidth. 11. Claims 4, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view Ozen et al. (US 20180262432 A1) hereinafter Ozen Regarding claims 4 and 19, claim 1 is incorporated. Labovitz/Zhu may not explicitly disclose wherein the centralized computing device further comprises a centralized data buffer within which the centralized computing device aggregates at least the one or more first data packets received from the first networked device.. However, Ozen discloses wherein the centralized computing device further comprises a centralized data buffer within which the centralized computing device aggregates at least the one or more first data packets received from the first networked device (para. [0009] receiving packets from a plurality of clients; generating an aggregate packet having a copy of the payload of two or more of the packets received from different ones of the plurality of clients within a common buffer period; and sending the generated aggregate packet to a remote server. [0005] Each packet may traverse a series of routers and other network devices that temporarily store the packets in fixed-size buffers). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz/Zhu and include wherein the centralized computing device further comprises a centralized data buffer within which the centralized computing device aggregates at least the one or more first data packets received from the first networked device using the teaching of Ozen. One would have been motivated to do so in order to reduce congestion within the network. Regarding claim 13, claim 7 is incorporated Labovitz/Zhu may not explicitly the one or more first data packets received from the first networked device; and the one or more second data packets received from the second networked device. However, Ozen discloses the one or more first data packets received from the first networked device; and the one or more second data packets received from the second networked device (para. [0009] receiving packets from a plurality of clients; generating an aggregate packet having a copy of the payload of two or more of the packets received from different ones of the plurality of clients within a common buffer period; and sending the generated aggregate packet to a remote server. [0005] Each packet may traverse a series of routers and other network devices that temporarily store the packets in fixed-size buffers). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz/Zhu and include the one or more first data packets received from the first networked device; and the one or more second data packets received from the second networked device using the teaching of Ozen. One would have been motivated to do so in order to reduce congestion within the network. 12. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view of Petrini et al. (US 20210406214 A1) hereinafter Petrini. Regarding claim 6, claim 1 is incorporated. Labovitz/Zhu may not explicitly disclose , wherein the first networked device comprises a first data processing unit (DPU).. However, Petrini discloses wherein the first networked device comprises a first data processing unit (DPU) (para. [0068] In some embodiments, a switch or switch tile may include an Infrastructure Processing Unit (IPU) or a Data Processing Unit (DPU). Switches may also comprise hardware programmable switches using languages such as but not limited to P4 (Programming Protocol-independent Packet Processors) and NPL (Network Programming Language). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz and include wherein the first networked device comprises a first data processing unit (DPU) using the teaching of Petrini. One would have been motivated to do so in order to improve efficiency and scalability of the underlying application system software. 13. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view of Venkata et al. (US 10534601 B1) hereinafter Venkata Regarding claim 9, claim 8 is incorporated. Labovitz/Zhu may not explicitly disclose wherein the centralized computing device is further configured to perform one or more synchronization operations for the first networked device and the second networked device based on the time data of the event-driven data entries of the first networked device and the second networked device. However, Venkata discloses wherein the centralized computing device is further configured to perform one or more synchronization operations for the first networked device and the second networked device based on the time data of the event-driven data entries of the first networked device and the second networked device (col. 2 lines 30-42, a plurality of compute nodes configured to perform compute functions for a plurality of session instances of a cloud data center to: receive a request to perform an in-services software upgrade (ISSU) of a first packet forwarding component of a virtual router configured to forward traffic flows for the plurality of session instances; spawn a second virtual routing agent for the virtual router; and synchronize flow state information between the second virtual routing agent and a first virtual routing agent of the virtual router). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz/Zhu and include wherein the centralized computing device is further configured to perform one or more synchronization operations for the first networked device and the second networked device based on the time data of the event-driven data entries of the first networked device and the second networked device using the teaching of Venkata. One would have been motivated to do so in order to automatically direct aggregation of tunnel packets to perform aggregation operation. 14. Claim 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view of Jacob et al. (US 12316546 B1) hereinafter Jacob. Regarding claim 10, claim 7 is incorporated. Labovitz/Zhu may not explicitly disclose , wherein the centralized computing device is further configured to: receive the one or more second data packets from the second networked device; and determine the one or more configuration updates based at least in part on the one or more first data packets and the one or more second data packets. However, Jacob discloses wherein the centralized computing device is further configured to: receive the one or more second data packets from the second networked device; and determine the one or more configuration updates based at least in part on the one or more first data packets and the one or more second data packets (col. 5 lines 20-45 and col. 15 lines 14-28), process 500 includes receiving updated telemetry data associated with the plurality of the network devices; determining whether the updated telemetry data satisfies the threshold; and selectively maintaining the modified class of service for the set of network devices based on the updated telemetry data satisfying the threshold, or modifying the class of service configuration to cause the set of network devices to provide the class of service for the set of user devices based on the updated telemetry data failing to satisfy the threshold. In some implementations, modifying the class of service configuration for the set of network devices based on the updated telemetry data satisfying the threshold includes utilizing an OpenConfig protocol or a network configuration protocol to modify the class of service configuration for the set of network devices). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz/Zhu and include wherein the centralized computing device is further configured to: receive the one or more second data packets from the second networked device; and determine the one or more configuration updates based at least in part on the one or more first data packets and the one or more second data packets using the teaching of Jacob . One would have been motivated to do so in order to continuously monitor network events to prevent bandwidth spikes and optimize throughput utilization. Regarding claim 11, claim 10 is incorporated. Labovitz further discloses wherein the centralized computing device is further configured to transmit the one or more configuration to the first networked device and the second networked device (see para. [0076]-[0078] and [0081]-]0083]) Regarding claim 12, claim 10 is incorporated. Labovitz further discloses wherein the second networked device is further configured to: receive the one or more configuration updates from the centralized computing device; and modify one or more operations performed by the second networked device based on the one or more configuration updates (para[0077]… although the router configuration information is only depicted as being received from router 521-B, router configuration information may be received from any of the routers 521 in the communication network 520…[0078] At step 596, the set of servers 522 receives router telemetry data from the routers 521. The router telemetry data for a router 521 may include one or more of packet mirroring traffic from the router 521, IPFIX data from the router 521, SNMP traps from the router 521, gRPC data from the router 521, or the like, as well as various combinations thereof. It will be appreciated that, although the router telemetry data is only depicted as being received from router 521-C, router telemetry data may be received from any of the routers 521 in the communication network 520. [0083] the feedback information received from the routers 521 may include traffic information related to traffic being received at the routers 521 (e.g., packets or packet samples, packet flows or packet flow samples, or the like, as well as various combinations thereof), which may be evaluated by the set of servers 522 to determine the efficacy of the router-specific security rules previously provided to the routers 521 (e.g., based on a determination that there is still bad traffic being received at the routers 521 that needs to be dropped, one or more of the router-specific security rules for one or more of the routers 521 may be adjusted accordingly and provided to the routers 521 for use by the routers 521 to continue to mitigate the security event). For example, the feedback information received from the routers 521 may include operating parameters of the routers 521 associated with handling of traffic at the routers 521, which may be evaluated by the set of servers 522 to determine the efficacy of the router-specific security rules previously provided to the routers 521 (e.g., based on a determination that the operating parameters indicate an unexpected or unusual strain on the routers 521, one or more of the router-specific security rules for one or more of the routers 521 may be adjusted accordingly and provided to the routers 521 for use by the routers 521 to continue to mitigate the security event)). 15. Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view of Riddoch et al. (US 20250310259 A1) hereinafter Riddoch Regarding claims 21, claim 1 is incorporated. Labovitz/Zhu may not explicitly disclose wherein the one or more configuration updates are associated with a congestion control of the first networked device. However, Riddoch discloses wherein the one or more configuration updates are associated with a congestion control of the first networked device (para. [0015] network devices to be configured with new and/or updated congestion control algorithms while leveraging the speed advantages of hardware. Such updates can enable NICs or other network devices to use new and/or updated congestion control algorithms to support high-performance and low turn-around time communications). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz and include wherein the one or more configuration updates are associated with a congestion control of the first networked device using the teaching of Riddoch. One would have been motivated to do so in order to enable Network Interface Cards (NICs) or other network devices to be configured with new or updated congestion control algorithms while leveraging the speed advantages of hardware. 16. Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Labovitz in view Zhu and further in view of Hamlin et al. (US 20240193061 A1) hereinafter Hamlin Regarding claim 22, claim 1 is incorporated. Labovitz in view Zhu discloses wherein the one or more configuration updates are associated with the first networked device as recited in claim1 above . Labovitz in view Zhu may not explicitly disclose cluster wide zero thermal throttling (ZTT). However Hamlin discloses cluster wide zero thermal throttling (ZTT) (para. [0202] When thermal manager 1205 is notified of a thermal event by temperature sensor driver 1204 of thermal zone 1202, for example, it may start to periodically evaluate the temperature of that zone, and it may determine a thermal throttling performance percentage to apply to one or more IHS components therein. In some cases, such an evaluation may use thermal throttling algorithms outlined in the ACPI specification. [0203] Thermal manager 1205 may then notify all device drivers 1201A-N in zone 1202 to throttle performance by a specific percentage, and device drivers 1201A-N may translate the throttling hint to a device-class-specific action to reduce the IHS component's performance; that is, each device driver registered as a thermal throttling device receives a thermal throttling percentage request and translates that percentage to an action that makes sense for itself. Such periodic evaluation and throttling may be stopped when temperature sensor driver 1204 reports a temperature below the throttling threshold temperature, and throttling is no longer required. [0205] For example, when a device driver 1201A-N is for a processing core (e.g., in host processor 201 or any device 301-315 equipped with its own processing cores), thermal manager 1205 may communicate the thermal throttling percentage to a Processor Power Manager (PPM) within host OS 400, which allows core parking and processor idling as additional thermal mitigation possibilities. [0206] For display backlight control, thermal manager 1205 may communicate the thermal throttling percentage to the monitor driver (e.g., monitor.sys), which in turn decides the actual backlight level setting based upon this thermal input). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Labovitz in view of Zhu and include cluster wide zero thermal throttling (ZTT) using the teaching of Hamlin. One would have been motivated to do so in order to quickly and efficiently process, store and communicate the information. Conclusion 17. 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. 18. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kidest Mendaye whose telephone number is (571)272-2603. The examiner can normally be reached on Monday through Friday 7:00 am-5:00pm EST. 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, Ario Etienne can be reached on (571) 272-4001. 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. 06/10/2026 /KIDEST MENDAYE/ Examiner, Art Unit 2457 /ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457
Read full office action

Prosecution Timeline

Apr 03, 2024
Application Filed
Nov 13, 2025
Non-Final Rejection mailed — §103, §112
Feb 09, 2026
Applicant Interview (Telephonic)
Feb 13, 2026
Response Filed
Feb 21, 2026
Examiner Interview Summary
Jun 22, 2026
Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12683858
OPEN INTERFACE PREDICTIVE AND RESPONSIVE ADAPTOR SYSTEM AND METHOD
3y 5m to grant Granted Jul 14, 2026
Patent 12676809
COMMUNICATION SYSTEM, METHOD, AND APPARATUS
2y 5m to grant Granted Jul 07, 2026
Patent 12665849
SYSTEMS AND METHODS FOR OPTIMIZED PROTOCOL AWARE DYNAMIC CONTROL PLANE POLICING
2y 5m to grant Granted Jun 23, 2026
Patent 12659261
Detecting segment expansion changes in Segment Routing using Dynamic Shortest Path First
2y 6m to grant Granted Jun 16, 2026
Patent 12659377
REAL-TIME ACCESS TO REMOTE MEDIA PRODUCTION EDITING FUNCTIONALITY
1y 9m to grant Granted Jun 16, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

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

Prosecution Projections

3-4
Expected OA Rounds
81%
Grant Probability
99%
With Interview (+31.9%)
2y 9m (~5m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 364 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