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 .
Claims 1-20 are pending for examination in the instant application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/11/2025 and 03/05/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The language of the claim raises a question whether the claim is directed merely to an abstract idea that is not tied to a technological art, environment or machine, the language of the claim directed (as the various claimed modules can just be a software) to a program per se claim (Warmerdam, 33 F.3d at 1360, 31 USPQ2d at 1759, 1760).
The claim recites, receiving a measurement, inputting it into a scoring model, applying multiple function, weighting outputs, combining weighted outputs int a score and comparing the score to a threshold.
This is pure data analysis, mathematical processing, and classification, which falls squarely into an abstract idea and therefore step 1 fails.
Step2: does the claim include “significantly more”?
No. The claim uses only generic computing components e.g., analysis agent, scoring model or machine learning model. These are purely functional, with no structural limitations, no specific ML architecture, no training mechanism, no hardware constraints, and no improvement to computer functionality.
The operations are generic and therefore, Step 2 also fails.
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(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ricci et al. (Pub. No.: US 2018/0139116 A1), hereinafter “Ricci” in view of Pablo et al. (Patent No.: US 11018958 B2), hereinafter “Pablo”.
As to claim 20. Ricci disclose, a system (Ricci, Abstract) comprising:
a first API in communication with an end user application and configured to receive at least one application KPI from the end user application (Ricci, [0014-0015], Ricci discloses a data extractor 120 that communicates with sources of network and related data and provides that data to a data analyzer.).
a second API in communication with a network and configured to receive network data (Ricci, [0013-0015], Ricci discloses a data extractor that receives network data (log data, counters, RNC/BTS/MME data, throughput, latency, etc.) and provides it to a data analyzer; this maps directly to a second API that ingests network telemetry); and
an analysis agent in communication with the first API and the second API, the analysis agent configured to: receive, in real-time, the at least one application KPI from the first API and the network data from the second API (Ricci, fig.2, [0026], [0033], Ricci discloses, a KPI analyzer 222 and performance index generator 202 that receive KPI and network data for analysis and that can operate periodically or continually to analyze KPI components; This teaches an analysis component that ingests both KPI and network data for scoring/analysis.);
wherein the scoring model is a machine learning model configured to: receive the at least one application KPI and the network data; input the at least one application KPI and the network data into a plurality of functions; weight the output of each function by a corresponding weight of a plurality of weights; and combine the weighted output to generate the end user score (Ricci, [0020], [0033], Ricci teaches KPI weighting for contribution to an overall performance index and explicitly contemplates machine learning approaches (e.g., linear regression, neural networks) for determining thresholds and analysis. Ricci therefore, discloses the use of ML techniques and weighted KPI contributions as part of score generation. This maps to the claimed ML scoring model architecture in part (weights plus ML). Ricci specifically in [0020] teaches that, each key performance indicator may be associated with a corresponding weight value, which may be used to determine a contribution of the key performance indicator to an overall performance index score (i.e., a score that indicates an overall system health) for a particular communication network and in [0033], various machine learning approaches (e.g., linear regression, neural networks, statistical approaches, etc.) can be used to determine appropriate threshold values per dimension.);
compare the end user score to a predetermined threshold (Ricci, [0018, [0036-0037], Ricci repeatedly teaches comparing KPI values or scores to threshold values (single or min/max thresholds) and assigning pass/fail or graded ratings based on threshold comparisons; applying the same thresholding to an end-user score is taught.);
determine that the end user application is experiencing an impairment in response to the end user score being less than the predetermined threshold (Ricci, [0039-0040], Ricci teaches that a failed threshold comparison indicates a network problem and that failed KPI checks can trigger further analysis and actions; treating a score below threshold as an impairment is the functional equivalent of Ricci’s failure logic.);
identify a type and a location of the impairment (Ricci, [0029-0031], Ricci discloses, multidimensional KPI analysis across service, location, device, and network dimensions and explicitly describes calculating KPI values per location, device, and service to identify polarization and localized problems. This teaches identification of location and characterization of problem type across dimensions.); and
determine a resolution action for the impairment based on type and the location of the impairment (Ricci, [0015], [0040], Ricci discloses a network automation system 106 that, upon notification of KPI anomalies, can automatically modify configuration/settings, deploy software updates, increase/decrease transmission power, or perform other corrective actions including location-specific actions based on identified KPI failures.).
While Ricci describes receiving network, device, survey, and business-support data, it does not explicitly call this interface an “API” receiving application KPIs from an end-user application; the data extractor is the closest teaching;
input the at least one application KPI and the network data into a scoring model that outputs an end user score, the end user score correlating to whether the end user application's internet connection is impaired.
Pablo discloses a similar concept in the same field of endeavor including, collecting device/application KPIs (UE KPIs) from user devices or applications and using those KPIs as inputs to ML models for diagnosis and scoring (Pablo, Abstract);
input the at least one application KPI and the network data into a scoring model that outputs an end user score, the end user score correlating to whether the end user application's internet connection is impaired (Pablo, col.10, lines 13-25, Pablo though out the specification describes ML model trained on combined device (application/UE) KPIs and network KPIs to predict/extrapolate KPIs and to output device level impairment indicators/scores.).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art to combine the teachings of Ricci’s data extractor as a first API that also receives application/UE KPIs as taught by Pablo to improve correlation between user experience and network KPIs.
As to claim 1 and claim 10 are rejected for same rationale as applied to claim 20 above.
As to claim 2. The combined teachings of Ricci and Pablo discloses the invention substantially including, determining that the end user application is experiencing an impairment in response to the end user score being less than the predetermined threshold (Ricci, [0039-0040], comparing KPI-derived scores to thresholds and threating failed threshold comparison as indicators of problems; the system then triggers further analysis or actions when a threshold is failed.);
identifying a type and a location of the impairment (Ricci, [0029-0031], multidimensional KPI analysis (service, location , device, network) and calculating KPI values per location/device/service to identify polarized or localized problems, which supports identifying both the type (dimension/category) and the location of an impairment.); and
determining a resolution action for the impairment based on type and the location of the impairment (Ricci, [0015], [0040], upon identification of KPI anomalies (including location specific anomalies), a network automation system can automatically modify configuration /settings, deploy updates, adjust transmission power, or perform other corrective actions targeted to the affected network elements or location.).
As to claim 3. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the predetermined threshold comprises at least three ranges of values (Ricci, [0019], Ricci expressly teaches minimum and maximum threshold values and an intermediate range between them, i.e. a three-range threshold scheme (good / fair / poor)., and
wherein the impairment is determined when the end user score is within two of the three ranges of values (Ricci, [0018], [0039], teaches assigning pass/fail/intermediate ratings based on threshold comparisons and treating failed threshold comparisons as indicators of problem that trigger further actions. Interpreting “impairment” as occurring when the end user score falls into two of the three defined ranges (e.g., intermediate or poor) is a routine application of Ricci’s thresholding and failure logic: scores in non-good ranges are identified as degraded and cause remediation flows. .
As to claim 4. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the plurality of weights are manually defined by a developer (Ricci, [0020], teaches that each KPI is associated with a corresponding weight value that determines the KPI’s contribution to an overall performance index score. While Ricci does not use the exact phrase “manually defined by a developer” the specification describes maintaining and assigning weight values of KPIs (i.e., explicit weight values associated with each KPI), which is the direct teaching of having a plurality of weights that can be set (and thus can be manually defined) by an implementer.).
As to claim 5. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the plurality of functions are trained using labeled training data having a plurality of training data, each training data having at least one measurement and a corresponding training score (Pablo, Col.11, lines 22-40, throughout the specification Pablo describes ML model training on KPI vectors and network/device measurements; training data sets includes measured KPI values paired with target/ predicted KPI values or labels used to train the model to predict/extrapolate device level KPI outcomes and impairment indicators.).
As to claim 6. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the at least one measurement comprises at least one application KPI received from a first (API) in communication with the end user application and network data received from a second API in communication with a network (Pablo, col.1-col.2, describing collection and use of device/UE/application KPIs as inputs to ML modes. Additionally, Ricci discloses, [0013-0015], [0022-0026], ingestion and analysis of network data and KPI based scoring).
As to claim 7. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the at least one application KPI comprises bandwidth, framerate, packet latency, jitter, bit rate, and packet loss and the network data comprises packet latency, jitter, bit rate, and packet loss (Pablo, col.1-col.2, describing collection and use of device level / application level PIIs (UE KPIs) as inputs to ML models and diagnostic engines; teaches measuring device/application metrics such as throughput/bandwidth, frame/stream metrics, packet latency, jitter, bit-rate and packet loss for user devices and applications. Additionally, Ricci discloses, [0013-0014], network data (packet latency, jitter, bit rate, packet loss).).
As to claim 8. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the at least one measurement is collected in the cloud and stored in at least one of a remote server or a remote database (Ricci, [0022], data that pertains to each of the key performance indicators (e.g., the network data 110, shown in FIG. 1) can be accessed and can be compared to the corresponding thresholds.).
As to claim 9. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the end user score is a scalar number (Ricci, [0020], [0022], generating an overall performance index score that represents system health. The score is treated as a single numeric value derived from weighted KPI contributions. This matches the requirement that the end user score is a scalar.).
As to claim 11. Is rejected for same rationale as applied to claim 2 above.
As to claim 12. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the analysis agent is further configured to transmit instructions for the resolution action to at least one of an end user, a developer, or a network operator (Ricci, [0015], [0040]).
As to claim 13. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the analysis agent operates on at least one of a cloud network, a remote server, or a remote database (Ricci, [0014]).
As to claim 14. Is rejected for same rationale as applied to claim 8 above.
As to claim 15. Is rejected for same rationale as applied to claim 7 above.
As to claim 16. Is rejected for same rationale as applied to claim 9 above.
As to claim 17. The combined teachings of Ricci and Pablo discloses the invention substantially including, wherein the scoring model is a machine learning model configured to: receive the at least one application KPI and the network data (Ricci, [0014] data extractor receives network data and Pablo col.3, lines 15-22, receiving application KPIs);
input the at least one application KPI and the network data into a plurality of functions (Ricci, [0020] implies multiple KPI functions, each producing an output and Pablo disclose ML models with multiple internal functions.);
weight the output of each function by a corresponding weight of a plurality of weights (Ricci, [0020], each key performance indicator may be associated with a corresponding weight value.); and
combine the weighted output to generate the end user score (Ricci, [0022], Ricci’s performance index generator combines weighted KPI outputs int a single score.).
As to claim 18. Is rejected for same rationale as applied to claim 4 above.
As to claim 19. Is rejected for same rationale as applied to claim 5 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see the attached PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAUQIR HUSSAIN whose telephone number is (571)270-1247. The examiner can normally be reached M-F 7:00 - 8:00 with IFP.
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, Vivek Srivastava can be reached at 571 272-7304. 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.
/Tauqir Hussain/Primary Examiner, Art Unit 2449
Prosecution Insights