DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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) 1-2, 6-9, 14, and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Chou et al. (CN107197421A).
Regarding claim 1, Chou et al. teach A system for monitoring network issues via a user device (Chou [0088] One or more of UE 314-220 ), the system comprising:
at least one processor (Chou [0109] one or more processors 804); and
at least one memory coupled to the at least one processor, (Chou [0110] volatile memory (e.g., dynamic random access memory 808, also known as DRAM), non-volatile memory (e.g., read-only memory 810 (also known as "ROM"), the memory having computer-executable instructions stored thereon (Chou [0111] volatile memory (e.g., DRAM 808), non-volatile memory (e.g., ROM 810), flash memory 812, and mass storage devices may include programming instructions )that, when executed by the at least one processor, cause the system to:
monitor, by the user device, a network connection of the user device (Chou [0072] a number of measurements performed by the first UE or the first eNB or other means that provides the first RLF report, such as one or more of the following: Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), identifier of the cell (with which the first UE was connected before the first UE disconnected from the RAT),);
identify a time at which a network issue occurred and the network issue (Chou [0072] a timestamp representing the time of the disconnection.) the network issue being associated with a network to which the user device was connected at the time the network issue occurred (Chou [0072] identifier of the cell (with which the first UE was connected before the first UE disconnected from the RAT)), based on the monitored network connection metrics (Chou [0072] a number of measurements performed by the first UE or the first eNB);
identify a cell site to which the user device was connected during the time at which the identified network issue occurred (Chou [0072] Receiver circuit 322 can be configured to receive data representing a first RLF report from a first eNB serving the first UE (e.g., eNB 308 when it serves UE 314)); and
cause the identified network issue to be remedied based on the cell site, the identified network issue, and the time at which the identified network issue occurred (Chou [0080] the correction action circuit 326 may be configured to adjust one or more cells of the E-UTRAN. . . a command to perform a correction action may be transmitted to one or more components of system 300, such as one or more of eNB 308-312)
Regarding claim 2, Chou et al. teaches The system of claim 1, wherein to cause the identified network issue to be remedied, the system is further caused to:
transmit data indicating the cell site, the identified network issue, and the time at which the identified network issue occurred (Chou [0072] receiver circuitry 322 may be configured to receive data representing a first RLF report. The first RLF report may include information about a first user UE (e.g., UE 314) disconnecting from an E-UTRAN) to a system configured to remedy network issues ((Chou [0080] the correction action circuit 326 may be configured to adjust one or more cells of the E-UTRAN. . . a command to perform a correction action may be transmitted to one or more components of system 300, such as one or more of eNB 308-312) ).
Regarding claim 6, Chou et al. teaches The system of claim 1, wherein to cause the identified network issue to be remedied, the system is further caused to:
determine a cause of the identified network issue based on the data indicating the cell site , the identified network issue, and the time at which the identified network issue occurred (Chou [0076] coverage analysis circuitry 324 may be configured to identify holes in the coverage area of a RAT (e.g., E-UTRAN technology) supported by system 300, based at least in part on multiple RLF reports (e.g., the first and second RLF reports discussed above).)
Regarding claim 7, Chou et al. teaches The system of claim 6, wherein the cause of the identified network issue includes one or more of:
a cell site;
a state of the user device;
a location of the user device (Chou [0076] coverage analysis circuitry 324 may be configured to identify holes in the coverage area of a RAT (e.g., E-UTRAN technology) supported by system 300, based at least in part on multiple RLF reports (e.g., the first and second RLF reports discussed above); and
one or more network connection metrics.
Regarding claim 8, Chou et al. teaches The system of claim 1, wherein the identified network issue includes one or more of:
a dropped call;
a dropped data packet (Chou [0106] packet latency, drop rate, and loss rate);
a network connection metric that has exceeded a threshold range); and
a network connection metric associated with a network connection between the user device and a roaming network.
Regarding claim 9, Chou et al. teaches The system of claim 1, wherein the system is further caused to:
transmit, by the user device, an indication of the set of network connection metrics to a system configured to remedy network issues (Chou [0104] NM device 302 can perform automatic CCO actions to adjust one or more cells of the E-UTRAN to provide additional services to geographically underserved areas.) contemporaneously as new network connection metrics are monitored (Chou [0072] number of measurements performed by the first UE or the first eNB or other means that provides the first RLF report, such as one or more of the following: Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ)).
Regarding claim 14, Chou et al. teach A system (Chou [0109] an NM device (e.g., NM device 302 of FIG. 3) for monitoring network issues based on data received from a plurality of user devices, the system comprising:
at least one processor (Chou [0109] one or more processors 804); and
at least one memory coupled to the at least one processor (Chou [0110] volatile memory (e.g., dynamic random access memory 808, also known as DRAM), non-volatile memory (e.g., read-only memory 810 (also known as "ROM"), the memory having computer-executable instructions stored thereon (Chou [0111] volatile memory (e.g., DRAM 808), non-volatile memory (e.g., ROM 810), flash memory 812, and mass storage devices may include programming instructions )that, when executed by the at least one processor, cause the system to:
receive, from the plurality of user devices, one or more network connection metrics, each of the one or more network connection metrics describing an aspect of a network connection a user device of the plurality of user devices (Chou [0072]-[0073] receiver circuitry 322 may be configured to receive data representing a first RLF report. The first RLF report may include information about a first user UE (e.g., UE 314) disconnecting from an E-UTRAN or other RAT supported by system 300. For example, an RLF report may include any of a number of measurements performed by the first UE or the first eNB or other means that provides the first RLF report, such as one or more of the following: Reference Signal Received Power (RSRP), ... receiver circuitry 322 may be configured to receive a second RLF report. The second RLF report may include information regarding the second UE disconnecting from the E-UTRAN or other RATs supported by System 300)
identify a time at which a network issue associated with a user device occurred, wherein the network issue is associated with a network to which the user device was connected at the time at which the network issue occurred (Chou [0072] a timestamp representing the time of the disconnection.) , based on the received network connection metrics (Chou [0072] a number of measurements performed by the first UE or the first eNB);
identify a cell site to which the user device was connected during the time at which the identified network issue occurred (Chou [0072] Receiver circuit 322 can be configured to receive data representing a first RLF report from a first eNB serving the first UE (e.g., eNB 308 when it serves UE 314)); and
cause the identified network issue to be remedied based on the cell site, the identified network issue, and the time at which the identified network issue occurred (Chou [0080] the correction action circuit 326 may be configured to adjust one or more cells of the E-UTRAN. . . a command to perform a correction action may be transmitted to one or more components of system 300, such as one or more of eNB 308-312)
Regarding claim 19, Chou et al. teach A non-transitory processor-readable storage medium that stores at least one of instructions or data (Chou [0111] volatile memory (e.g., DRAM 808), non-volatile memory (e.g., ROM 810), flash memory 812, and mass storage devices may include programming instructions), the instructions or data, when executed by at least one processor (Chou [0109] one or more processors 804) cause the at least one processor to perform a method comprising:
receiving, via a plurality of user devices, one or more network connection metrics (Chou [0072]-[0073] receiver circuitry 322 may be configured to receive data representing a first RLF report. The first RLF report may include information about a first user UE (e.g., UE 314) disconnecting from an E-UTRAN or other RAT supported by system 300. For example, an RLF report may include any of a number of measurements performed by the first UE or the first eNB or other means that provides the first RLF report, such as one or more of the following: Reference Signal Received Power (RSRP), ... receiver circuitry 322 may be configured to receive a second RLF report. The second RLF report may include information regarding the second UE disconnecting from the E-UTRAN or other RATs supported by System 300);
identifying a network issue associated with a user device of the plurality of user devices (Chou [0072] Receiver circuit 322 can be configured to receive data representing a first RLF report from a first eNB serving the first UE (e.g., eNB 308 when it serves UE 314)),and a time at which the network issue (Chou [0072] a timestamp representing the time of the disconnection.) , based on the received network connection metrics (Chou [0072] a number of measurements performed by the first UE or the first eNB), the network issue being further associated with a network to which the user device was connected at the time the network issue occurred (Chou [0072] The first RLF report may include information about a first user UE (e.g., UE 314) disconnecting from an E-UTRAN or other RAT supported by system 300.);
identifying a cell site to which the user device was connected during the time at which the identified network issue occurred (Chou [0072] Receiver circuit 322 can be configured to receive data representing a first RLF report from a first eNB serving the first UE (e.g., eNB 308 when it serves UE 314)); and
causing the identified network issue to be remedied based on the cell site, the identified network issue, and the time at which the identified network issue occurred (Chou [0080] the correction action circuit 326 may be configured to adjust one or more cells of the E-UTRAN. . . a command to perform a correction action may be transmitted to one or more components of system 300, such as one or more of eNB 308-312) .
Regarding claim 20, Chou et al. teaches The non-transitory processor-readable storage medium of claim 19, wherein the at least one processor is at least one processor of one or more of:
a Self-Organizing Network (“SON”);
a Radio Access Network Intelligent Controller (“RIC”) (Chou [0069] NM device 302 may include receiver circuitry 322, coverage analysis circuitry 324, and correction action circuitry 326.); and
the user device of the plurality of user devices
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, 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.
Claim 3-4 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Chou et al. in view of Shori et al. (US 20230370338 A1)
Regarding claim 3, Chou et al. teaches The system of claim 1, but does not teach wherein the system is further caused to:
receive training data, the training data including an indication of one or more network issues, one or more times at which the one or more network issues occurred, and one or more cell sites associated with the one or more network issues ;
train a machine learning model to predict whether a network issue regarding a network connection of a user device is to occur based on the training data, wherein the machine learning model takes one or more network connection metrics as input.
In a similar endeavor, Shori et al. teach
receive training data, the training data including an indication of one or more network issues, one or more times at which the one or more network issues occurred, and one or more cell sites associated with the one or more network issues (Shori [0011] the ML models may be trained based on performance metrics, error data, and failures );
train a machine learning model to predict whether a network issue regarding a network connection of a user device is to occur (Shori [0011] Various ML models may be configured to predict service degradations, detect performance anomalies (e.g., failures or outages), and determine the root causes associated with such degradations and anomalies) based on the training data, wherein the machine learning model takes one or more network connection metrics as input (Shori [0011] the ML models may be trained based on performance metrics, error data, and failures ).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Chou et al. by incorporating Shori et al. ML to arrive at the invention
The motivation of doing so would have predicted future network connection issues.
Regarding claim 4, Chou et al. teaches The system of claim 1, but does not teach wherein the system is further caused to:
predict whether a network issue regarding the network connection of the user device is to occur by applying at least a portion of the set of network connection metrics to a machine learning model trained to predict whether a network issue is to occur regarding the network connection of the user device; and
generate, based on the predicted network issue, a remedy for the predicted network issue.
In a similar endeavor, Shori et al. teach
predict whether a network issue regarding the network connection of the user device is to occur (Shori [0011] Various ML models may be configured to predict service degradations, detect performance anomalies (e.g., failures or outages), and determine the root causes associated with such degradations and anomalies) by applying at least a portion of the set of network connection metrics to a machine learning model (Shori [0011] the ML models may be trained based on performance metrics, error data, and failures) trained to predict whether a network issue is to occur regarding the network connection of the user device (Shori [0053] train and execute ML models to detect or predict operational issues (e.g., service degradation or anomalies) within the telecommunications network.); and
generate, based on the predicted network issue, a remedy for the predicted network issue (Shori [0012] machine learning systems that can more quickly detect, isolate, and repair service outages within the complex service architecture of a wireless network).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Chou et al. by incorporating Shori et al. ML to arrive at the invention
The motivation of doing so would have predicted future network connection issues.
Regarding claim 16, Chou et al. teaches The system of claim 1, but does not teach wherein the system is further caused to:
generate training data based on data indicating network connection metrics, data indicating identified network issues, data indicating one or more times at which a network issue occurred, and data indicating one or more cell sites; and
train a machine learning model to predict whether a network issue regarding a network connection of a user device is likely to occur based on the training data, wherein the machine learning model receives one or more network connection metrics as input.
In a similar endeavor, Shori et al. teach
generate training data based on data indicating network connection metrics (Shori [0015] ML models trained based on the combination of application server output data (e.g., errors, failures, throughput, etc.) and the corresponding performance of the communication services provided by the network (e.g., voice, data, and messaging metrics), data indicating identified network issues (Shori [0015] ML models trained based on the combination of application server output data (e.g., errors, failures, throughput, etc.),) data indicating one or more times at which a network issue occurred (Shori [0046] The ML analysis component 306 also may analyze the results of the ML model instances 304 over time to detect patterns), and data indicating one or more cell sites (Shori [0040] The ML system 124 may use data received from the core wireless network and computing infrastructure 214 (e.g., data 216 including service metrics outages and data 218 including application server node errors and performance metrics) to train and execute various ML models ); and
train a machine learning model to predict whether a network issue regarding a network connection of a user device is likely to occur based on the training data (Shori [0053] train and execute ML models to detect or predict operational issues (e.g., service degradation or anomalies) within the telecommunications network), wherein the machine learning model receives one or more network connection metrics as input (Shori [0015] ML models trained based on the combination of application server output data (e.g., errors, failures, throughput, etc.) and the corresponding performance of the communication services provided by the network (e.g., voice, data, and messaging metrics).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Chou et al. by incorporating Shori et al. ML to arrive at the invention
The motivation of doing so would have predicted future network connection issues.
Regarding claim 17, Chou et al. teaches The system of claim 1, but do not teach wherein the system is further caused to:
predict whether a network issue is likely to occur regarding the network connection of the user device by applying at least a portion of the one or more network connection metrics to a machine learning model trained to predict whether a network issue is likely to occur regarding the network connection of a user device; and
generate, based on the predicted network issue, a remedy for the predicted network issue.
In a similar endeavor, Shori et al. teach
predict whether a network issue is likely to occur regarding the network connection of the user device (Shori [0053] train and execute ML models to detect or predict operational issues (e.g., service degradation or anomalies) within the telecommunications network) by applying at least a portion of the one or more network connection metrics to a machine learning model (Shori [0015] ML models trained based on the combination of application server output data (e.g., errors, failures, throughput, etc.) and the corresponding performance of the communication services provided by the network (e.g., voice, data, and messaging metrics) trained to predict whether a network issue is likely to occur regarding the network connection of a user device (Shori [0053] train and execute ML models to detect or predict operational issues (e.g., service degradation or anomalies) within the telecommunications network); and
generate, based on the predicted network issue, a remedy for the predicted network issue (Shori [0051] determine a root cause, affected nodes, and/or repair recommendations for the service degradation issues and/or anomalies detected by the ML model instances 304).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Chou et al. by incorporating Shori et al. ML to arrive at the invention
The motivation of doing so would have predicted future network connection issues.
Claims 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chou et al. in view of An et al. (US 20250150803 A1)
Regarding claim 12, Chou al. teaches The system of claim 1,but do not teach
wherein to monitor the set of network connection metrics, the system is further caused to:
detect whether the user device is connected to a roaming network or a home network.
In a similar endeavor, An et al. teach
wherein to monitor the set of network connection metrics, the system is further caused to:
detect whether the user device is connected to a roaming network or a home network (An [0068] upon detecting that the mobile device is roaming such that the SIM applet immediately begins collecting performance data associated with the visited network.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Chou et al. by incorporating An et al. to arrive at the invention.
The motivation of doing so would have determined to connect to a roaming network based on the collected performance data
Regarding claim 18, Chou et al. teaches The system of claim 1, but do not teach wherein the system is further caused to:
detect whether the user device is connected to a roaming network or a home network.
In a similar endeavor, An et al. teach
detect whether the user device is connected to a roaming network or a home network (An [0068] detecting whether the mobile device is roaming. If not, the method 300 returns to block 306, where the method 300 continues to monitor location of the mobile device on the home network).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Chou et al. by incorporating An et al. to arrive at the invention.
The motivation of doing so would have determined to connect to a roaming network based on the collected performance data
Allowable Subject Matter
Claims 5, 10-11, 13, and 15 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.
The following is a statement of reasons for the indication of allowable subject matter: .
Regarding claim 5, the combination of Chou et al., and Shori et al. teaches The system of claim 4, but does not teach wherein to cause the identified network issue to be remedied, the system is further caused to:
determine whether the predicted network issue is a network issue of a same type as the identified network issue; and
in response to determining that the predicted network issue is a network issue of the same type as the identified network issue, applying the generated remedy to the user device.
Regarding claim 10, Chou et al. teaches The system of claim 9, but does not teach wherein to transmit the indication of the set of network connection metrics, the system is further caused to:
identify a status of the user device;
determine, based on the status of the user device, whether contemporaneously transmitting the indication of the set of network connection metrics will be detrimental to a functioning of the user device; and
based on a determination that contemporaneously transmitting the indication of the set of network connection metrics will be detrimental to the functioning of the user device, pausing the transmission of the indication of the set of network connection metrics.
Regarding claim 11, Chou al. teaches The system of claim 1, but do not teach
wherein to cause the identified network issue to be remedied, the system is further caused to:
transmit data indicating the cell site, the identified network issue, and the time at which the identified network issue occurred, to a system associated with a roaming network to which the user device has connected in the past.
Regarding claim 13, Chou et al. teaches The system of claim 1, wherein to cause the identified network issue to be remedied, the system is further caused to:
receive data regarding one or more network issues experienced by user devices other than the user device (chou [0073] receiver circuitry 322 may be configured to receive a second RLF report. The second RLF report may include information regarding the second UE disconnecting from the E-UTRAN or other RATs supported by System 300).
Chou et al do not teach
determine, based on the data regarding one or more network issues experienced by user devices other than the user device, whether the identified network issue is related to one or more attributes of the user device; and
based on a determination that the identified network issue is related to one or more attributes of the user device, cause at least one attribute of the user device to change.
Regarding claim 15, Chou et al. teach The system of claim 14, wherein to cause the identified network issue to be remedied, the system is further caused to:
receive data regarding a set of network connection metrics of one or more user devices other than the user device (Chou [0073] receiver circuitry 322 may be configured to receive a second RLF report. The second RLF report may include information regarding the second UE disconnecting from the E-UTRAN or other RATs supported by System 300.
Chou et al. do not teach
receive a set of attributes of the one or more user devices);
determine, based on the data regarding set of network connection metrics and the set of attributes, whether the identified network issue is related to one or more attributes of the user device.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAID M ELNOUBI whose telephone number is (571)272-9732. The examiner can normally be reached Monday-Friday 9:30AM to 6:00PM ET.
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, Kathy Wang-Hurst can be reached at 571-270-5371. 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.
/SAID M ELNOUBI/ Examiner, Art Unit 2644