Prosecution Insights
Last updated: April 18, 2026
Application No. 18/776,827

CONTROL SYSTEM FOR CONFIGURING AND MONITORING A NETWORK SYSTEM

Final Rejection §103
Filed
Jul 18, 2024
Examiner
TURRIATE GASTULO, JUAN CARLOS
Art Unit
2446
Tech Center
2400 — Computer Networks
Assignee
Oceus Networks LLC
OA Round
2 (Final)
72%
Grant Probability
Favorable
3-4
OA Rounds
3y 2m
To Grant
99%
With Interview

Examiner Intelligence

Grants 72% — above average
72%
Career Allow Rate
270 granted / 376 resolved
+13.8% vs TC avg
Strong +36% interview lift
Without
With
+35.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
28 currently pending
Career history
404
Total Applications
across all art units

Statute-Specific Performance

§101
13.8%
-26.2% vs TC avg
§103
55.4%
+15.4% vs TC avg
§102
14.3%
-25.7% vs TC avg
§112
8.4%
-31.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 376 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 This action is in response to application filed 01/02/2026. Claims 1-3, 6-9, 12-13, 16-24 are pending in this application. Response to Arguments Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claim Objections Claims 1 is objected to because of the following informalities: The claim is missing a semicolon in line 29 of the claim (see. “monitoring…using the second network configuration baseline”). Appropriate correction is required. Claims 2 and 13 are objected to because of the following informalities: The claims end with two periods. Appropriate correction is required. Claims 6 is objected to because of the following informalities: The claim amendment added a period and removed semicolon in the middle of the claim (“modifying…in accordance with the selected at least one configuration . ”) . Appropriate correction is required. Note: The text of any deleted subject matter must be shown by strike-through except that double brackets placed before and after the deleted characters may be used to show the deletion of five or fewer consecutive characters (e.g., [[error]]). Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 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. Claims 1-3, 6, 8-9, 12-13, 16, 18-20, 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Chaganti et al. (US 10,514,907 B2) in further view of Kothuri et al. (US 11,290,330 B1) in further view Balasubramanian et al. (WO 2020/264319 A1). Regarding claim 1, Chaganti discloses a method comprising: receiving a first network configuration baseline of a cellular network system, the first network configuration baseline identifying a plurality of configurations of a plurality of components of the cellular network system, wherein the plurality of components comprises a plurality of hardware components and a plurality of software components (column 15, 42-47: a baseline configuration associated with the logical group is obtained. In one or more embodiments of the invention, the obtained baseline configuration specifies hardware, firmware, firmware settings, and applications for user resources of computing devices), wherein the plurality of configurations comprise a plurality of hardware configurations for the plurality of hardware components and a plurality of software configurations for the plurality of software components of the cellular network system (column 6, 10-16: each logical group may have an associated baseline configuration. The baseline configuration may specify the hardware, software (e.g., firmware and/or applications), and configurations of the hardware and software of user resources of a computing device. The baseline configuration may be enforced on all computing devices of the logical group. Column 21, 15-21: the communication interface (812) may include an integrated circuit for connecting the computing device (800) to a network (not shown) such as mobile network, or any other type of network) and/or to another device, such as another computing device); monitoring the plurality of hardware components and the plurality of software components using the first network configuration baseline (column 16, 3-4, column 17, 31-35: The configuration of the computing device may be obtained by reading the configurations of the user resources of the computing device…the obtained configuration is compared to a baseline configuration to identify any differences between the obtained configuration and the baseline configuration); determining at least one network error based at least in part on the monitoring (column 16, 5-9: it is determined whether an override attribute is associated with the second computing device. The override attribute may specify a deviation from, e.g., may be in conflict with, the baseline configuration. The deviation may a difference from the hardware, firmware, firmware settings, or applications specified by the baseline configuration); identifying at least one hardware component of the plurality of hardware components corresponding to the at least one network error (column 15, 48-59: a dependency of the computing device on a second computing device of the logical group is identified. The dependency may be a functional dependency. In one or more embodiments of the invention, the dependency specifies a relationship between the computing device and the second computing device. The relationship may indicate that the computing device depends on the second computing device for the computing device to perform one or more of its functions. The relationship may be, for example, reliance on the second computing device for storage services, computing services, or any other type of service); identifying at least one configuration of the at least one hardware component that is different from a corresponding configuration of the at least one hardware component in the first network configuration baseline (column 16, 31-45: at least one override attribute associated with the second computing device is obtained. In one or more embodiments of the invention, the at least one override attribute is obtained by comparing the configuration of the second computing device to the baseline configuration. Any differences identified by the comparison may be used as the at least one override attribute. In other words, any configurations of the second computing device that are different from the configurations specified by the baseline configuration may be used as override attributes. In other words, the override attribute may be a difference between a resource of the user resources and the baseline configuration. User resources may include any number of resources, e.g., hardware components, firmware, firmware settings, applications, and application settings); modifying the at least one hardware component in accordance with the selected at least one configuration (column 17, 5-20: the configuration of the computing device is updated based on the modified obtained baseline configuration. Updating the baseline configuration of the computing device may cause hardware component(s) to be enabled/disabled, firmware to be loaded, firmware settings to be changed, and/or applications to be loaded/disabled to configure the user resources of the computing device to match the modified obtained baseline configuration); generating a second network configuration baseline for the cellular network system based at least in part on the modifying the at least one hardware component in accordance with the at least one configuration (column 16, 58-column 17, 4: the obtained baseline configuration is modified using the obtained at least one override attribute. In one or more embodiments of the invention, the obtained baseline configuration is modified by replacing configurations of the baseline configuration with corresponding override parameters (e.g. second network configuration baseline). For example, a software version of a driver in a baseline configuration may be replaced with a different software version of the driver specified by the override parameters. The obtained baseline configuration may be modified by replacing any number of configurations of the obtained baseline configuration with any number of override parameters without departing from the invention. The modified baseline configuration may be referred to as an updated baseline configuration); monitoring the plurality of hardware components and the plurality of software components using the second network configuration baseline (column 16, 3-4, column 17, 31-35: The configuration of the computing device may be obtained by reading the configurations of the user resources of the computing device…the obtained configuration is compared to a baseline configuration to identify any differences between the obtained configuration and the baseline configuration). However, Chaganti does not disclose determining a second at least one network error based at least in part on the monitoring using the second network configuration baseline; and modifying the at least one hardware component in accordance with the first network configuration baseline. In an analogous art, Kothuri discloses determining a second at least one network error based at least in part on the monitoring using the second network configuration baseline; and modifying the at least one hardware component in accordance with the first network configuration baseline (column 14, 49-64: the cloud control plane identifies a first cluster on an edge network that has an issue…The issue may include a disk failure, high latency, CPU, I/O, or network contention, prevalence of bully VMs, low tolerance or replication factor, an out-of-date version of a disk firmware, hypervisor, cluster management service (e.g. component). The processor identifies a first configuration update. In some embodiments, the first configuration update is to update a first configuration state (e.g., first configuration settings). Column 15, 9-11: If the processor determines that the issue is not resolved (e.g. second error), the processor changes the first configuration update on the first cluster. Column 21-28: the processor rolls backs/reverts, or sends instructions/request to roll back/revert, the first configuration update such that the second configuration state of the first cluster is returned to the first configuration state that it had before the first configuration update. In some embodiments, the processor performs a remediation action in response to sending the first configuration update, determining that the issue is resolved) Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Chaganti to comprise “determining a second at least one network error based at least in part on the monitoring using the second network configuration baseline; and modifying the at least one hardware component in accordance with the first network configuration baseline” taught by Kothuri. One of ordinary skilled in the art would have been motivated because it would have enabled to determine whether the configuration update request introduced any regressions in order to roll back the changes on the edge and cloud (Kothuri, column 10, 34-37). However, Chaganti-Kothuri does not disclose identifying, using a trained machine learning model, a plurality of possible configurations for the at least one hardware component to address the at least one network error; selecting, using a trained machine learning model, at least one configuration from the plurality of possible configurations for the at least one hardware component. In an analogous art, Balasubramanian discloses identifying, using a trained machine learning model, a plurality of possible configurations for the at least one hardware component to address the at least one network error ([0058], [0060], [0128]: the monitoring device may utilize machine learning techniques to determine patterns of performance based on system state information associated with performance events. System state information for an event may be collected and used to train a machine learning model based on determining correlations between attributes of dependencies and the monitored application entering an unhealthy state. During later, similar events, the machine learning model may be used to generate a recommended action based on past corrective actions. The monitoring application may also use information about baseline (and/or waterline) performance and unhealthy performance events to generate a health report using the trained model, indicating to a user information such as a predicted likelihood that the monitored application will enter an unhealthy operating state); selecting, using a trained machine learning model, at least one configuration from the plurality of possible configurations for the at least one hardware component ([0052], [0131], [0160]: the monitoring device may train a machine learning model based on a set of incident records and the corresponding corrective actions…the machine learning processes may cluster the events and determine emergent trends and patterns of performance for use in generating predictions regarding operation of the monitored application. Through clustering, the monitoring device may identify which changes are effective to remediate particular problems, and may recommend similar action in future unhealthy operating status events. Thus, the monitoring device may observe many candidates for suitable corrective action, but based on correlating changes made across similar events may be able to determine corrective action that may address the issues underlying the unhealthy operating status event). Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Chaganti-Kothuri to comprise “identifying, using a trained machine learning model, a plurality of possible configurations for the at least one hardware component to address the at least one network error; selecting, using a trained machine learning model, at least one configuration from the plurality of possible configurations for the at least one hardware component” taught by Balasubramanian. One of ordinary skilled in the art would have been motivated because it would have enabled to provide for enhanced monitoring of application health and facilitate identifying dependencies causing reduced system performance or another unhealthy system status (Balasubramanian, [0002]). Regarding claim 3, Chaganti-Kothuri-Balasubramanian discloses the method of claim 2, wherein the at least one network error comprises at least one of: a hardware port assignment that deviates from a hardware port assignment in the first network configuration baseline, a software port assignment that deviates from a software port assignment in the first network configuration baseline, a hardware configuration of a particular hardware component that is different from a hardware configuration of the particular hardware component in the first network configuration baseline, a software version of a particular software component that is different from a software version of the particular software component in the first network configuration baseline, a software configuration of the particular software component that is different from a software configuration of the particular software component in the first network configuration baseline (Chaganti, column 16, 58-column 17, 4: a software version of a driver in a baseline configuration may be replaced with a different software version of the driver specified by the override parameters. The obtained baseline configuration may be modified by replacing any number of configurations of the obtained baseline configuration with any number of override parameters without departing from the invention), network latency that satisfies a network latency threshold, packet loss that satisfies a packet loss threshold, unauthorized access to at least one hardware component or at least one software component, an amount of network traffic that satisfies a network traffic threshold, network traffic patterns that deviate a threshold amount from a network traffic pattern threshold, a threshold number of failed login attempts, network connectivity of the particular hardware component satisfying a network connectivity threshold, a power failure of the particular hardware component, or power usage of the particular hardware component that satisfies a power usage threshold. Regarding claim 6, Chaganti-Kothuri-Balasubramanian discloses the method of claim 2. Chaganti discloses wherein the at least one component is at least one hardware component of the plurality of hardware components, the method further comprising: modifying the at least one hardware component in accordance with the selected at least one configuration (Chaganti, column 17, 5-20: the configuration of the computing device is updated based on the modified obtained baseline configuration. Updating the baseline configuration of the computing device may cause hardware component(s) to be enabled/disabled, firmware to be loaded, firmware settings to be changed, and/or applications to be loaded/disabled to configure the user resources of the computing device to match the modified obtained baseline configuration); generating a second network configuration baseline for the cellular network system based at least in part on the modifying the at least one hardware component in accordance with the at least one configuration (Chaganti, column 16, 58-column 17, 4: the obtained baseline configuration is modified using the obtained at least one override attribute. In one or more embodiments of the invention, the obtained baseline configuration is modified by replacing configurations of the baseline configuration with corresponding override parameters (e.g. second network configuration baseline). For example, a software version of a driver in a baseline configuration may be replaced with a different software version of the driver specified by the override parameters. The obtained baseline configuration may be modified by replacing any number of configurations of the obtained baseline configuration with any number of override parameters without departing from the invention. The modified baseline configuration may be referred to as an updated baseline configuration); and monitoring the plurality of components using the second network configuration baseline (Chaganti, column 16, 3-4, column 17, 31-35: The configuration of the computing device may be obtained by reading the configurations of the user resources of the computing device…the obtained configuration is compared to a baseline configuration to identify any differences between the obtained configuration and the baseline configuration). However, Chaganti-Kothuri does not disclose identifying a plurality of possible configurations for the at least one hardware component to address the at least one network error; selecting at least one configuration from the plurality of possible configurations for the at least one hardware component. In an analogous art, Balasubramanian discloses identifying a plurality of possible configurations for the at least one hardware component to address the at least one network error ([0058], [0060], [0128]: the monitoring device may utilize machine learning techniques to determine patterns of performance based on system state information associated with performance events. System state information for an event may be collected and used to train a machine learning model based on determining correlations between attributes of dependencies and the monitored application entering an unhealthy state. During later, similar events, the machine learning model may be used to generate a recommended action based on past corrective actions. The monitoring application may also use information about baseline (and/or waterline) performance and unhealthy performance events to generate a health report using the trained model, indicating to a user information such as a predicted likelihood that the monitored application will enter an unhealthy operating state); selecting at least one configuration from the plurality of possible configurations for the at least one hardware component ([0052], [0131], [0160]: the monitoring device may train a machine learning model based on a set of incident records and the corresponding corrective actions…the machine learning processes may cluster the events and determine emergent trends and patterns of performance for use in generating predictions regarding operation of the monitored application. Through clustering, the monitoring device may identify which changes are effective to remediate particular problems, and may recommend similar action in future unhealthy operating status events. Thus, the monitoring device may observe many candidates for suitable corrective action, but based on correlating changes made across similar events may be able to determine corrective action that may address the issues underlying the unhealthy operating status event). Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Chaganti-Kothuri to comprise “identifying a plurality of possible configurations for the at least one hardware component to address the at least one network error; selecting at least one configuration from the plurality of possible configurations for the at least one hardware component” taught by Balasubramanian. One of ordinary skilled in the art would have been motivated because it would have enabled to provide for enhanced monitoring of application health and facilitate identifying dependencies causing reduced system performance or another unhealthy system status (Balasubramanian, [0002]). Regarding claim 8, Chaganti-Kothuri-Balasubramanian discloses the method of claim 2, wherein the at least one component is at least one hardware component of the plurality of hardware components, the method further comprising: identifying at least one configuration of the at least one hardware component that is different from a corresponding configuration of the at least one hardware component in the first network configuration baseline (Chaganti, column 17, 5-7: the configuration of the computing device is updated based on the modified obtained baseline configuration); modifying the identified at least one configuration of the at least one hardware component to the corresponding configuration of the at least one hardware component in the first network configuration baseline; updating firmware of the at least one hardware component (Chaganti, column 17, 5-20: the configuration of the computing device is updated based on the modified obtained baseline configuration); generating a second network configuration baseline for the cellular network system based at least in part on the updated firmware (Chaganti, column 17, 8-13: Updating the baseline configuration of the computing device may cause hardware component(s) to be enabled/disabled, firmware to be loaded, firmware settings to be changed, and/or applications to be loaded/disabled to configure the user resources of the computing device to match the modified obtained baseline configuration); monitoring the plurality of components using the second network configuration baseline (Chaganti, column 16, 3-4, column 17, 31-35: The configuration of the computing device may be obtained by reading the configurations of the user resources of the computing device…the obtained configuration is compared to a baseline configuration to identify any differences between the obtained configuration and the baseline configuration). Regarding claim 9, Chaganti-Kothuri-Balasubramanian discloses the method of claim 2, wherein the at least one component is at least one software component of the plurality of software components, the method further comprising: identifying at least one of a configuration of the at least one software component or a software version of the at least one software component that is different from a corresponding configuration or version, respectively, of the at least one software component in the first network configuration baseline (Chaganti, column 16, 58-column 17, 4: the obtained baseline configuration is modified using the obtained at least one override attribute. In one or more embodiments of the invention, the obtained baseline configuration is modified by replacing configurations of the baseline configuration with corresponding override parameters (e.g. second network configuration baseline). For example, a software version of a driver in a baseline configuration may be replaced with a different software version of the driver specified by the override parameters. The obtained baseline configuration may be modified by replacing any number of configurations of the obtained baseline configuration with any number of override parameters without departing from the invention. The modified baseline configuration may be referred to as an updated baseline configuration); modifying the at least one of the identified configuration or the identified software version of the at least one software component to the corresponding configuration or version, respectively, of the at least one software component in the first network configuration baseline (Chaganti, column 16, 58-column 17, 4: a software version of a driver in a baseline configuration may be replaced with a different software version of the driver specified by the override parameters. The obtained baseline configuration may be modified by replacing any number of configurations of the obtained baseline configuration with any number of override parameters without departing from the invention); and continue monitoring the plurality of components using the first network configuration baseline (Chaganti, column 6, 4-9: the configuration for each computing device may be dynamically determined based on logical groups of computing devices and dependencies of the computing devices within each logical grouping. column 16, 3-4, column 17, 31-35: The configuration of the computing device may be obtained by reading the configurations of the user resources of the computing device…the obtained configuration is compared to a baseline configuration to identify any differences between the obtained configuration and the baseline configuration). Regarding claim 12, Chaganti-Kothuri-Balasubramanian discloses the method of claim 2. Chaganti discloses wherein the at least one component is at least one software component of the plurality of software components, the method further comprising: identifying at least one configuration of the at least one software component that is different from a corresponding configuration of the at least one software component in the first network configuration baseline (column 16, 31-45: at least one override attribute associated with the second computing device is obtained. In one or more embodiments of the invention, the at least one override attribute is obtained by comparing the configuration of the second computing device to the baseline configuration. Any differences identified by the comparison may be used as the at least one override attribute. In other words, any configurations of the second computing device that are different from the configurations specified by the baseline configuration may be used as override attributes. In other words, the override attribute may be a difference between a resource of the user resources and the baseline configuration. User resources may include any number of resources, e.g., hardware components, firmware, firmware settings, applications, and application settings); modifying the at least one software component in accordance with the selected at least one configuration (Chaganti, column 17, 5-20: the configuration of the computing device is updated based on the modified obtained baseline configuration); generating a second network configuration baseline for the cellular network system based at least in part on the modifying the at least one software component in accordance with the at least one configuration (Chaganti, column 17, 8-13: Updating the baseline configuration of the computing device may cause hardware component(s) to be enabled/disabled, firmware to be loaded, firmware settings to be changed, and/or applications to be loaded/disabled to configure the user resources of the computing device to match the modified obtained baseline configuration); and monitoring the plurality of components using the second network configuration baseline (Chaganti, column 16, 3-4, column 17, 31-35: The configuration of the computing device may be obtained by reading the configurations of the user resources of the computing device…the obtained configuration is compared to a baseline configuration to identify any differences between the obtained configuration and the baseline configuration). However, Chaganti-Kothuri does not disclose identifying, using a trained machine learning model, a plurality of possible configurations for the at least one software component to address the at least one network error; selecting, using a trained machine learning model, at least one configuration from the plurality of possible configurations for the at least one software component. In an analogous art, Balasubramanian discloses identifying, using a trained machine learning model, a plurality of possible configurations for the at least one software component to address the at least one network error ([0058], [0060], [0128]: the monitoring device may utilize machine learning techniques to determine patterns of performance based on system state information associated with performance events. System state information for an event may be collected and used to train a machine learning model based on determining correlations between attributes of dependencies and the monitored application entering an unhealthy state. During later, similar events, the machine learning model may be used to generate a recommended action based on past corrective actions); selecting, using a trained machine learning model, at least one configuration from the plurality of possible configurations for the at least one software component ([0052], [0131], [0160]: the monitoring device may train a machine learning model based on a set of incident records and the corresponding corrective actions…the machine learning processes may cluster the events and determine emergent trends and patterns of performance for use in generating predictions regarding operation of the monitored application. Through clustering, the monitoring device may identify which changes are effective to remediate particular problems, and may recommend similar action in future unhealthy operating status events. Thus, the monitoring device may observe many candidates for suitable corrective action, but based on correlating changes made across similar events may be able to determine corrective action that may address the issues underlying the unhealthy operating status event). Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Chaganti-Kothuri to comprise “identifying, using a trained machine learning model, a plurality of possible configurations for the at least one software component to address the at least one network error; selecting, using a trained machine learning model, at least one configuration from the plurality of possible configurations for the at least one software component.” taught by Balasubramanian. One of ordinary skilled in the art would have been motivated because it would have enabled to provide for enhanced monitoring of application health and facilitate identifying dependencies causing reduced system performance or another unhealthy system status (Balasubramanian, [0002]). Regarding claims 2, 13 and 19; the claims are interpreted and rejected for the same reason as set forth in claim 1. Regarding claims 16 and 20; the claims are interpreted and rejected for the same reason as set forth in claim 6. Regarding claims 18 and 22; the claims are interpreted and rejected for the same reason as set forth in claim 8. Regarding claim 23; the claim is interpreted and rejected for the same reason as set forth in claim 9. Regarding claim 24; the claim is interpreted and rejected for the same reason as set forth in claim 12. Claims 7, 17, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Chaganti in view of Kothuri in view of Balasubramanian, as applied to claim 2, in further view of Kim et al. (US 2022/0132432 A1). Regarding claim 7, Chaganti-Kothuri-Balasubramanian discloses the method of claim 2. However, Chaganti-Kothuri-Balasubramanian does not disclose wherein the at least one component is at least one hardware component of the plurality of hardware components, the method further comprising: determining a power usage of the at least one hardware component satisfies a power usage threshold for the at least one hardware component in the first network configuration baseline; identifying, at least one other hardware component of the plurality of hardware components that is available; modifying a power usage threshold for the at least one other hardware component based at least in part on the determining the power usage of the at least one hardware component satisfies the power usage threshold for the at least one hardware component; adjusting a power distribution associated with the at least one hardware component and the at least one other hardware component; and generating an alert based at least in part on the determining the power usage of the at least one hardware component satisfies the power usage threshold for the at least one hardware component. In an analogous art, Kim discloses determining a power usage of the at least one hardware component satisfies a power usage threshold for the at least one hardware component in the first network configuration baseline ([0145]: in a power control method in an IAB node, a child node may periodically transmit a SRS to the IAB node (S1701). In addition, the IAB node may measure a received signal strength of the SRS. Here, the received signal strength may be a RSSI or the like. Accordingly, the IAB node may determine a DL minimum power P.sub.DL,min required for DL transmission based on the measured received signal strength (S1702)); identifying, at least one other hardware component of the plurality of hardware components that is available; modifying a power usage threshold for the at least one other hardware component based at least in part on the determining the power usage of the at least one hardware component satisfies the power usage threshold for the at least one hardware component ([0145]-[0146]: Then, the IAB node may calculate a UL available power P.sub.UL,max by subtracting the DL minimum power P.sub.DL,min from a UL maximum power P.sub.TX,max that is a maximum power available for UL transmission. the parent node may receive the uplink control information from the IAB node, and may identify the available UL power included in the received uplink control information); adjusting a power distribution associated with the at least one hardware component and the at least one other hardware component ([0146]: the parent node may select a transmit power within a range that does not exceed the available UL power and inform the IAB node of information on the selected transmit power to perform power control (S1705). Accordingly, the IAB node may transmit a UL signal using the transmit power according to the information on the selected transmit power received from the parent node); and generating an alert based at least in part on the determining the power usage of the at least one hardware component satisfies the power usage threshold for the at least one hardware component ([0116]: the IAB node may inform the determined transmit powers to the terminal and the child node). Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Chaganti-Kothuri-Balasubramanian to comprise “wherein the at least one component is at least one hardware component of the plurality of hardware components, the method further comprising: determining a power usage of the at least one hardware component satisfies a power usage threshold for the at least one hardware component in the first network configuration baseline; identifying, at least one other hardware component of the plurality of hardware components that is available; modifying a power usage threshold for the at least one other hardware component based at least in part on the determining the power usage of the at least one hardware component satisfies the power usage threshold for the at least one hardware component; adjusting a power distribution associated with the at least one hardware component and the at least one other hardware component; and generating an alert based at least in part on the determining the power usage of the at least one hardware component satisfies the power usage threshold for the at least one hardware component” taught by Kim. One of ordinary skilled in the art would have been motivated because it would have enabled to periodically perform UL power control for the terminal and the child node so that the measured power difference does not exceed the threshold (Kim, [0117]). Regarding claims 17 and 21; the claims are interpreted and rejected for the same reason as set forth in claim 7. Additional References The prior art made of record and not relied upon is considered pertinent to applicants disclosure. DeHaan et al., US 9,201,485 B2: Power Management in Managed Network Having Hardware Based and Virtual Resources. Satapathy et al., US 2020/0073656 A1: Method and Apparatus for Drift Management in Clustered Environment. 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 JUAN C TURRIATE GASTULO whose telephone number is (571)272-6707. The examiner can normally be reached Monday - Friday 8 am-4 pm. 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, Brian J Gillis can be reached at 571-272-7952. 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. /J.C.T/Examiner, Art Unit 2446 /BRIAN J. GILLIS/Supervisory Patent Examiner, Art Unit 2446
Read full office action

Prosecution Timeline

Jul 18, 2024
Application Filed
Sep 27, 2025
Non-Final Rejection — §103
Dec 31, 2025
Applicant Interview (Telephonic)
Jan 02, 2026
Response Filed
Jan 08, 2026
Examiner Interview Summary
Apr 01, 2026
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12603795
INFORMATION PROCESSING TERMINAL, INFORMATION PROCESSING DEVICE, AND SYSTEM
2y 5m to grant Granted Apr 14, 2026
Patent 12587432
Visual Map for Network Alerts
2y 5m to grant Granted Mar 24, 2026
Patent 12574436
BLOCKCHAIN MACHINE BROADCAST PROTOCOL WITH LOSS RECOVERY
2y 5m to grant Granted Mar 10, 2026
Patent 12566427
Method and System for Synchronizing Configuration Data in a Plant
2y 5m to grant Granted Mar 03, 2026
Patent 12568059
UPDATING COMMUNICATIONS WITH MACHINE LEARNING AND PLATFORM CONTEXT
2y 5m to grant Granted Mar 03, 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
72%
Grant Probability
99%
With Interview (+35.9%)
3y 2m
Median Time to Grant
Moderate
PTA Risk
Based on 376 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