DETAILED ACTION
This Office action is in response to the RCE filed 9 July 2026. Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9 July 2026 has been entered.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 14 and 15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Agarwal et al. (EP 3985939).
For Claim 14, Agarwal teaches a computer server comprising: a Network Operations Center (“NOC”) processor; and a non-transient NOC data store, coupled to the NOC processor (see paragraphs 13, 25: NOC; paragraphs 27, 35: processor, data store), storing:
first computer instructions, which when executed by the NOC processor, instantiate an Outage Notification Monitor (“ONM”) (see paragraphs 76, 79-80, 94-95: monitoring for outages) which performs ONM operations including:
notifying, via a corresponding control coupling, a User Mobile Device (“UMD”) when a change of status in a Mobile Communications Network (“MCN”) component is detected which impacts current usage of the MCN by the UMD (see paragraphs 88, 112: customer notifications).
For Claim 15, Agarwal teaches the computer server, wherein the non-transient NOC data store further stores:
second computer instructions, which when executed by the NOC processor, instruct the ONM to perform outage prediction operations including:
predicting a future status change in one of the MCN components; determining an impact of the future status change on the UMD (see paragraphs76, 79-80); and
notifying, via the corresponding control coupling, the UMD of the impact of the future status change (see paragraphs 88, 112).
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) in view of Agarwal et al. (EP 3985939).
For Claim 1, Kavuri teaches a system comprising:
a plurality of Mobile Communications Network (“MCN”) components including: a first network link; a first hub; a second hub; wherein the second hub is coupled with the first hub via the first network link; a first node; wherein the first node is coupled to the first hub; a second node; wherein the second node is coupled to the second hub; (see paragraphs 66, 69: core network components on path comprising links, access nodes coupled to core)
a first User Mobile Device (“UMD1”); wherein the UMD1 is wirelessly coupled to the MCN via the first node; a second User Mobile Device (“UMD2”); wherein the UMD2 is wirelessly coupled to the MCN via the second node; and wherein the UMD2 is communicatively coupled to the UMD1 via a first communications path provided by the MCN and using a plurality of MCN components that further include the second node, the second hub, the first network link, the first hub, and the first node (see Figure 1, paragraphs 66, 62-63: user equipment in communication via core network and access nodes).
Kavuri as applied above is not explicit as to, but Agarwal teaches a Network Operations Center (“NOC”), configured to monitor a current operating status of each of the MCN components (see paragraphs 13, 35: NOC), comprising:
a NOC processor (see paragraphs 27, 35);
a non-transient NOC data store, coupled to the NOC processor (see paragraph 27), storing:
first computer instructions, which when executed by the NOC processor, instantiate an Outage Notification Monitor (“ONM”) which performs ONM operations (see paragraphs 76, 79-80, 94-95)including:
notifying at least one of the UMD1 and the UMD2, via a corresponding control coupling between the NOC and an affected at least one of the UMD1 and the UMD2, when a change in the current operating status in one of the MCN components is detected (see paragraphs 88, 112).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a NOC as in Agarwal when monitoring the network as in Kavuri. One of ordinary skill would have been able to do so with the reasonably predictable result of providing support to customers in a well-known and efficient manner.
For Claim 2, Kavuri as applied above is not explicit as to, but Agarwal teaches the system, wherein the change of current operating status in one of the MCN components results in a degradation in a Quality of Service (“QoS”) provided by the MCN to at least one of the UMD1 and the UMD2 (see paragraphs 112, 137: QoS and QoE); and
wherein the NOC notifies at least one of the UMD1 and the UMD2, via the corresponding control coupling, of the degradation in the QOS provided by the MCN (see paragraphs 88-89, 112).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor quality as in Agarwal when monitoring the network as in Kavuri. One of ordinary skill would have been able to do so with the reasonably predictable result of providing support to customers in a well-known and efficient manner.
For Claim 3, Kavuri as applied above is not explicit as to, but Agarwal teaches the system, wherein the non-transient NOC data store further stores: second computer instructions, which when execute by the NOC processor, instantiate a Network Link Status Monitor (“NLSM”) which performs NLSM operations (see paragraphs 54-55: link status monitoring) including:
monitoring link data for a link status change (see paragraphs 54-55, 59, 63: link status monitoring, link data); and
wherein the NOC notifies at least one of the UMD1 and the UMD2, via the corresponding control coupling, of the link status change (see paragraphs 88-89, 112: topology issues).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor link quality as in Agarwal when monitoring the network as in Kavuri. One of ordinary skill would have been able to do so with the reasonably predictable result of providing support to customers in a well-known and efficient manner.
Claim(s) 4 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) and Agarwal et al. (EP 3985939) as applied to claims 1 and 3 above, and further in view of McLain et al. (US 2002/0145562), Yadav et al. (US 2022/0014424) and Dutta et al. (US 2023/0115255).
For Claim 4, the references as applied above are not explicit as to, but McLain teaches the system wherein, the ONM operations further include:
upon receiving a notification of the link status change: retrieving a current dependency set for the first network link (see paragraphs 7, 33-37);
populating, based on the current dependency set, an impacted UMD data set (see paragraphs 7, 33-37);
determining, when UMD1 is on the impacted UMD data set, a first impact of the link status change on UMD1 (see paragraphs 7, 33-37: for multiple UMDs);
determining, when UMD2 is on the impacted UMD data set, a second impact of the link status change on UMD2 (see paragraphs 7, 33-37: for multiple UMDs); and
notifying, via the corresponding control coupling, as appropriate, the UMD1 of the first impact and the UMD2 of the second impact (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to determine the cause of issues on the network as in McClain when managing a network as in Kavuri. The motivation would be to efficiently determine and resolve communication issues.
The references as applied above are not explicit as to, but Yadav teaches a data store wherein the link data is stored in the data store (see paragraphs 28-30: collection of data for analysis and monitoring);
wherein the NLSM operations further include: monitoring the data lake for the link status change (see paragraph 31: detect degradation); and notifying, when detected, the ONM of the link status change (see paragraph 34: alert to NOC).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor data and provide an alert as in Yadav when monitoring a network as in Kavuri and McLain. The motivation would be to provide for timely mitigation of detected issues.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, McClain, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
For Claim 5, the references as applied above are not explicit as to, but McClain teaches the system, wherein, the ONM operations further include: determining a respective impact of the change in component status on at least one UMD identified on an impacted UMD data set (see paragraphs 7, 33-37); and
Notifying, via the corresponding control coupling, the at least one UMD identified on the impacted UMD data set of the respective impact of the change in component status (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor effects on UMDs as in McLain when implementing the network of Kavuri. The motivation would be to ensure effective usage of network resources.
The references as applied above are not explicit as to, but Yadav teaches the system, wherein the first network link includes a first network link component (see paragraph 28);
wherein the link data includes first network component link status data for the first network link component (see paragraph 28);
wherein the first network component link status data is stored in a data store (see paragraph 29);
wherein the NLSM operations further include: monitoring the first network link component status data for a change in component status (see paragraphs 29, 30); and
notifying, when detected, the ONM of the change in the component status (see paragraph 34).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to aggregate data relating to links as in Yadav when implementing the network of Kavuri and McLain. The motivation would be to consider historical patterns of network conditions.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, McClain, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
Claim(s) 6-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) and Agarwal et al. (EP 3985939) as applied to claim 1 above, and further in view of Rahman (US 2011/0075553).
For Claim 6, while Kavuri does teach the presence of core devices (see paragraph 66), Kavuri as applied above is not explicit as to, but Agarwal teaches the system, wherein the non-transient NOC data store further stores:
second computer instructions, which when executed by the NOC processor, instantiate a Network Link Status Monitor (“NLSM”) which monitors link data for a link status change (see paragraphs 54-55, 59, 63: link status monitoring).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor links as in Agarwal when implementing the system of Kavuri. The motivation would be to collect information necessary for ensuring effective usage of network resources.
The references as applied above are not explicit as to, but Rahman teaches third computer instructions, which when executed by the NOC processor, instantiate a Hub Status Monitor (“HSM”) which monitors first hub data for a first hub status change and monitors second hub data for a second hub status change (see abstract, paragraphs 73, 75, 78).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor hub devices as in Rahman when implementing network monitoring as in Kavuri and Agarwal. The motivation would be to maintain user services even in the event of core network outages.
For Claim 7, Kavuri further teaches the system, wherein the non-transient NOC data store further stores: fourth computer instructions, which when executed by the NOC processor, instantiate a Node Status Monitor (“NSM”) which monitors first node data for a first node status change and monitors second node data for a second node status change (see paragraph 190: node channel condition monitoring, between node and UE).
For Claim 8, Kavuri further teaches the system, wherein the non-transient NOC data store further stores: fifth computer instructions, which when executed by the NOC processor, instantiate a User Mobile Device Status Monitor (“UMDSM”) which monitors UMD1 data for a UMD1 status change and monitors UMD2 data for a UMD2 status change (see paragraph 190: node channel condition monitoring, between node and UE).
Claim(s) 9 and 12-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849), Agarwal et al. (EP 3985939), and Rahman (US 2011/0075553) as applied to claims 1 and 6-8 above, and further in view of McLain et al. (US 2002/0145562), Yadav et al. (US 2022/0014424) and Dutta et al. (US 2023/0115255).
For Claim 9, the references as applied above are not explicit as to, but McLain teaches the system wherein, the ONM operations further include:
upon receiving a notification of the given status change: retrieving a current dependency set for at least one of the first network link, the first hub, the second hub, the first node, and the second node (see paragraphs 7, 33-37);
populating, based on the current dependency set, an impacted UMD data set (see paragraphs 7, 33-37);
determining, when UMD1 is on the impacted UMD data set, a first impact of the given status change on UMD1 (see paragraphs 7, 33-37);
determining, when UMD2 is on the impacted UMD data set, a second impact of the given status change on UMD2 (see paragraphs 7, 33-37); and
notifying, via the corresponding control coupling, as appropriate, the UMD1 of the first impact and the UMD2 of the second impact (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to determine the cause of issues on the network as in McClain when managing a network as in Kavuri and Agarwal. The motivation would be to efficiently determine and resolve communication issues.
The references as applied above are not explicit as to, but Yadav teaches a data store; wherein the link data is stored in the data store; wherein the first hub data is stored in the data store; wherein the second hub data is stored in the data store; wherein the first node data is stored in the data store; wherein the second node data is stored in the data store (see paragraphs 28-30: collection of data for monitoring);
wherein the NLSM, HSM, and NSM perform operations including: respectively monitoring the data store for a given status change (see paragraph 31);
wherein the given status change is at least one of a link status change, a first hub status change, a second hub status change, a first node status change, and a second node status change (see paragraphs 31, 34); and
notifying the ONM when the given status change is detected (see paragraph 34).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor data and provide an alert as in Yadav when monitoring a network as in Kavuri, Agarwal, and McLain. The motivation would be to provide for timely mitigation of detected issues.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, Agarwal, McClain, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
For Claim 12, the references as applied above are not explicit as to, but McLain teaches the system, wherein, the ONM operations further include:
determining if a work-around is available to address, at least in part, at least one of the first impact and the second impact (see paragraphs 7, 33-37: adjustments to mitigate interference);
instructing, when the work-around is available, a reconfiguration of at least one component of the plurality of MCN components (see paragraphs 7, 33-37); and
wherein the reconfiguration alleviates, at least in part, at least one of the first impact and the second impact (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to mitigate issues on the network as in McClain when managing a network as in Kavuri and Agarwal. The motivation would be to efficiently determine and resolve communication issues to improve user services.
For Claim 13, the references as applied above are not explicit as to, but McLain teaches the system, wherein, the ONM operations further include:
determining whether the first impact has been alleviated (see paragraphs 33-37); and
notifying the UMD1, via the corresponding control coupling, when the first impact has been alleviated (see paragraphs 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to mitigate issues on the network as in McClain when managing a network as in Kavuri and Agarwal. The motivation would be to efficiently determine and resolve communication issues to improve user services.
Claim(s) 16 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (EP 3985939) as applied to claims 14 and 15 above, and further in view of Ko et al. (US 2015/0280973).
For Claim 16, Agarwal as applied above is not explicit as to, but Ko teaches the computer server, wherein the second computer instructions further include:
generating a network outage model that identifies, based on historical data, multiple interdependencies between two or more data sets (see paragraphs 22, 24, 27);
wherein the two or more data sets include data for one or more MCN components (see paragraph 27); and
generating a UMD outage model based on an application of past path data for the UMD to the network outage model (see paragraphs 20, 30).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to model outages as in Ko when implementing the system of Agarwal. One of ordinary skill would have been able to do so with the reasonably predictable results of interpreting network behaviors in accord with past behaviors.
For Claim 17, Agarwal as applied above is not explicit as to, but Ko teaches the computer server, wherein the two or more data sets include at least one of: historic signal strength data for at least one of the MCN components and the UMD; historic Quality of Service (“QoS”) data for at least one of the MCN components and the UMD; historic network data for the MCN (see paragraphs 22, 30); historic outage data for the MCN; and historic Geographic Information System (“GIS”) data for the UMD.
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to model outages as in Ko when implementing the system of Agarwal. One of ordinary skill would have been able to do so with the reasonably predictable results of interpreting network behaviors in accord with past behaviors.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (EP 3985939) as applied to claim 14 above, and further in view of Yadav et al. (US 2022/0014424).
For Claim 18, While Agarwal does teach that the outage prediction operations are further performed based on a current data set (see paragraphs 76, 79-80), Agarwal as applied above is not explicit as to, but Yadav teaches the computer server, wherein the outage prediction operations are further performed based on a current data set that includes at least one of: current signal strength data for at least one of the MCN components and the UMD (see paragraph 33: RSSI); current QoS data for at least one of the MCN components and the UMD; current outage data for the MCN (see paragraph 33: failure cause code); and current GIS data for the UMD.
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to predict and notify outages using parameters as in Yadav when implementing the system of Agarwal. The motivation would be to provide timely recommendations to handle problems.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (EP 3985939) and Yadav et al. (US 2022/0014424) as applied to claims 14-15 and 18 above, and further in view of Kavuri et al. (US 2019/0349849), Rahman (US 2011/0075553), and Dutta et al. (US 2023/0115255).
For Claim 19, Agarwal as modified by Yadav above further teaches second computer instructions, which when execute by the NOC processor, instantiate a Network Link Status Monitor (“NLSM”) which monitors the data lake for data indicative of a first link status change (see paragraphs 54-55, 59, 63: link monitoring).
The references as applied above are not explicit as to, but Kavuri teaches the server, wherein the MCN components include: a first link; a first hub; a second hub; wherein the first link couples the first hub with the second hub; a first node coupled to the first hub; a second node coupled to the second hub; and a store lake storing data for the MCN components (see paragraphs 66, 69: core network components on bath comprising links, access nodes coupled to core; paragraphs 72, 104: operations necessarily require data store);
fourth computer instructions, which when executed by the NOC processor, instantiate a Node Status Monitor (“NSM”) which monitors the data store for data indicative of at least one of a first node status change and a second node status change (see paragraph 109); and
fifth computer instructions, which when executed by the NOC processor, instantiate a MUDSM which monitors the UMD for a UMD status change (see paragraph 109).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor data to monitor data for the various elements as in Kavuri when implementing the system of Agarwal. The motivation would be to ensure consideration of multiple factors that contribute to network issues.
The references as applied above are not explicit as to, but Rahman teaches third computer instructions, which when executed by the NOC processor, instantiate a Hub Status Monitor (“HSM”) which monitors the data lake for data indicative of at least one of a first hub status change and second hub status change (see abstract, paragraphs 73, 75, 78).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor hub devices as in Rahman when implementing network monitoring as in Kavuri and Agarwal. The motivation would be to maintain user services even in the event of core network outages.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, Agarwal, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) in view of Agarwal et al. (EP 3985939) and Rahman (US 2011/0075553).
For Claim 20, Kavuri teaches a non-transitory computer readable medium, having stored thereon computer instructions (see paragraphs 23, 155-157) which, when executed by a processor for a Mobile Communications Network (“MCN”) having two or more MCN components including at least one of an MCN link, an MCN hub, and an MCN node (see paragraphs 66, 69: core network components on bath comprising links, access nodes coupled to core), cause the NOC to perform operations comprising:
instantiate a Node Status Monitor which detects data indicative of a status change in the MCN node (see paragraph 190: node channel condition monitoring, between node and UE).
Kavuri as applied above is not explicit as to, but Agarwal teaches a Network Operations Center (“NOC”) (see paragraphs 13, 35: NOC) and operations to instantiate a Network Link Status Monitor which detects data indicative of a status change in the MCN link (see paragraphs 54-55: link status monitoring); and
instantiate an Outage Notification Monitor (“ONM”) which notifies a User Mobile Device (“UMD”), via a corresponding control coupling, when a change of status in at least one of the two or more MCN components is detected which impacts current usage of the MCN by the UMD (see paragraphs 88-89, 112).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to provide the network monitoring and remediation function as in Agarwal when implementing a network as in Kavuri. The motivation would be to ensure effective usage of network resources.
The references as applied above are not explicit as to, but Rahman teaches instantiating a Hub Status Monitor which detects data indicative of a status change in the MCN hub (see abstract, paragraphs 73, 75, 78).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor hub devices as in Rahman when implementing network monitoring as in Kavuri and Agarwal. The motivation would be to maintain user services even in the event of core network outages.
Allowable Subject Matter
Claims 10-11 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
The amendment filed 9 July 2026 has been entered.
Applicant’s arguments with respect to rejections under 35 USC 103 have been fully considered, but are moot in view of the new grounds of rejection introduced herein. The claims remain rejected under 35 USC 102 and 35 USC 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Francisco et al. (US 2006/0285489) teaches a network monitoring system which provides alerts to affected UEs. Costa et al. (US 2017/0085436) teaches a network monitoring system in which a user can interface with a NOC.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CASSANDRA L DECKER whose telephone number is (571)270-3946. The examiner can normally be reached 7:30 am - 4:00 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, Faruk Hamza can be reached at 571-272-7969. 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.
/CASSANDRA L DECKER/Examiner, Art Unit 2466 7/29/2026
/FARUK HAMZA/Supervisory Patent Examiner, Art Unit 2466
