Prosecution Insights
Last updated: April 17, 2026
Application No. 18/821,779

System and Method for Performing a Multi-Step, Multi-Factorial Decision Analysis

Non-Final OA §101§103
Filed
Aug 30, 2024
Examiner
KOLOSOWSKI-GAGER, KATHERINE
Art Unit
3687
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
unknown
OA Round
1 (Non-Final)
26%
Grant Probability
At Risk
1-2
OA Rounds
4y 3m
To Grant
60%
With Interview

Examiner Intelligence

Grants only 26% of cases
26%
Career Allow Rate
95 granted / 358 resolved
-25.5% vs TC avg
Strong +34% interview lift
Without
With
+33.6%
Interview Lift
resolved cases with interview
Typical timeline
4y 3m
Avg Prosecution
54 currently pending
Career history
412
Total Applications
across all art units

Statute-Specific Performance

§101
35.0%
-5.0% vs TC avg
§103
33.9%
-6.1% vs TC avg
§102
14.5%
-25.5% vs TC avg
§112
12.5%
-27.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 358 resolved cases

Office Action

§101 §103
DETAILED ACTION This action is in reference to the communication filed on 30 AUG 2024. Claims 1-20 are present and have been examined. 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. Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. As explained below, the claim(s) are directed to an abstract idea without significantly more. Step One: Is the Claim directed to a process, machine, manufacture or composition of matter? YES With respect to claim(s) 1-20 the independent claim(s) 1 recite(s) a method, i.e. a process, which is a statutory category of invention. Step 2A – Prong One: Is the claim directed to a law of nature, a natural phenomenon (product of nature) or an abstract idea? YES With respect to claim(s) 1-20, the independent claim(s) (claims 1) is/are directed, in part, to: A method for detecting sleep apnea for a healthcare provider from existing patient health data on an determining the identifying the data inputs in the healthcare record system type that are relevant to predicting sleep apnea in a patient; when a patient of the plurality of patients is being seen by the healthcare provider, automatically performing an initial risk assessment for sleep apnea for the patient based on the health history for the patient; These claim elements are considered to be abstract ideas because they are directed to mental processes – i.e. concepts performed in the human mind such as observation, evaluation, judgement, and opinion. Determining information from a source, identifying the types of a data, performing a risk assessment, and displaying the conclusion of the assessment are all examples of tasks that can reasonably be performed in the human mind. These claim elements are also found to be directed to certain methods of organizing human activity, including following rules or instructions, as well as the fundamental economic principle of mitigating risk(s). Using stored information to automatically make a risk assessment to then be concluded as existing is a set of rules or instructions for diagnosing sleep apnea. Similarly, a risk assessment is the essentially the first step to mitigating the risk of sleep apnea. If a claim limitation, under its broadest reasonable interpretation, covers concepts performed in the human mind such as observation evaluation judgement and opinion, then it falls within the mental process grouping of abstract ideas. If a claim limitation, under its broadest reasonable interpretation, covers fundamental economic principles or managing persona behaviors in terms of following instructions/rules, then it falls within the “method of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Step 2A – Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? NO. This judicial exception is not integrated into a practical application. In particular, the claim(s) recite(s) additional element – an “electronic” healthcare record system, as well as “installing an API configured to communicate with the EHR…”, sending and receiving of the information between the record system/API, as well as a nominal recitation of a display, to perform the claim steps. The electronic record system in general, as well as the API elements, are recited at a high level of generality and as such amount to no more than adding the words “apply it” to the judicial exception, or mere instructions to implement the abstract idea on a computer, or merely uses the computer as a tool to perform the abstract idea (see MPEP 2106.05f), or generally links the use of the judicial exception to a particular technological field of use/computing environment (see MPEP 2106.05h). No improvement to the functioning of the computer or any other technology or technical field in the API or record system as claimed (see MPEP 2106.05a), nor any other application or use of the judicial exception in some meaningful way beyond a general like between the use of the judicial exception to a particular technological environment (see MPEP 2106.05e). Examiner further notes that the sending and receiving of the data, as well as the nominal recitation of the display are found to be analogous to adding insignificant extra solution activity to the judicial exception(s) identified (see MPEP 2106.05g). Accordingly, this/these additional element(s) do(es) not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception? NO. The independent claim(s) is/are additionally directed to claim elements such an “electronic” healthcare record system, as well as “installing an API configured to communicate with the EHR…”, sending and receiving of the information between the record system/API, as well as a nominal recitation of a display. When considered individually, the above identified claim elements only contribute generic recitations of technical elements to the claims. It is readily apparent, for example, that the claim is not directed to any specific improvements of these elements. Examiner looks to Applicant’s specification in [0046] An application programming interface (API) is a set of rules and protocols that allows different software applications to communicate with each other. APIs define the methods and data formats that applications use to interact, allowing them to request and exchange information or services. A type of EHR system is first determined and an API selected to allow the system to interact with the healthcare provider's EHR system 12. [0044] In one application of the invention, a method for detecting sleep apnea for a healthcare provider from existing patient health data on an electronic healthcare record (EHR) system is provided. The EHR system 12 is a digital version of a patient's paper chart and includes comprehensive data about the patient's health history, diagnoses, treatments, medications, immunizations, allergies, radiology images and laboratory results. Many types of EHRs are common in the marketplace including EHR systems from Epic Systems, Cerner, Allscripts, Meditech, Athenahealth, NextGen Healthcare, eClinicalWorks, GE Healthcare (Centricity), Kareo, DrChrono, and the like. The different EHR systems may have different inputs, data tags, and graphical user interfaces. The choice of an EHR system often depends on the specific needs of the healthcare provider, including the size of the practice, specialty requirements, and budget. [0049] The data collection 16 of the system may include providing an API configured to communicate with CRM software used by the healthcare provider that has additional information about the plurality of patients. Any CRM data or other additional information that is relevant to predicting sleep apnea in the patient is identified, and the identified relevant additional information is used when performing the initial risk assessment 22 or the final risk assessment 32. These passages, as well as others, makes it clear that the invention is not directed to a technical improvement. When the claims are considered individually and as a whole, the additional elements noted above, appear to merely apply the abstract concept to a technical environment in a very general sense. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. The fact that the generic computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. As per dependent claims 2-20: Dependent claims 2-7, 11-13, 18-20 are not directed any additional abstract ideas and are also not directed to any additional non-abstract claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims and addressed above – such as further uses of the API, and further types of information displayed within the visual prompt itself including risk evaluation and options for treatment. While these descriptive elements may provide further helpful context for the claimed invention these elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Dependent claims 8-10, 16, 17, as well as claims 14, 15 recite additional abstract ideas. Claims 8-10, 16-17 recite example of a mathematical relationship, formula, equation or calculation in the cost-benefit/years added analysis computations of these claims. Claims 14-15 further recite commercial or legal interactions in the form of sales activities in providing the Application for sale and discussing revenue earned. These claims do not recite any additional elements beyond those considered above. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 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. The factual inquiries 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. Claim(s) 1-14, 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pauws et al (US 20240194355 A1, hereinafter Pauws), in view of Lim et al (US 20190328320 A1, hereinafter Lim). In reference to claim 1: Pauws teaches: A method for detecting sleep apnea for a healthcare provider from existing patient health data on an electronic healthcare record system having a health history for each of a plurality of patients (at least [fig 1 and related text] “The repository 142 may include one or more healthcare repositories such as, each of which may be considered data sources for medical records such as electronic health records (EHRs), electronic medical records (EMRs), and/or the like and, in this regard, may for example, include one or more data repositories for medical records such as a hospital EMR 144, an ambulatory EMR 146, an administrative claim 148, a general practice EMR 150, another EMR 152, etc. Each of these repositories may have the same or different formats or querying rules for accessing and/or file retrieval such as may be employed by the Centers for Medicare and Medicaid Services (CMS) system. Accordingly, formats and/or querying rules for communicating with (e.g., to query, read files, communicate with, etc.) each of the repositories may be stored in the SSI for later use…. The PCD may include the MSI and related information (e.g., ID, etc.) for each patient (e.g., case) of the patient cohort independently”) , the system comprising the acts of: determining the electronic healthcare record system type from a plurality of electronic healthcare record system types (at least [fig 1 and related text] data repository 142 contains various EMRs as noted in [0047], at [049] “ To perform the extraction, the data-ingestion module 132 may be operative to query the selected repositories in accordance with querying rules for the corresponding repository of the selected repositories from the repository 142. The PCD may include the MSI and related information (e.g., ID, etc.) for each patient (e.g., case) of the patient cohort independently.” At [050] “accordance with the present system, with regard to the selected repositories, the PCD from the repositories may be linked (e.g., together and/or within the PCD for given repositories) in accordance with various data source entities (DSEs) such as: a patient identifier (ID), an event identifier, a location identifier, coding elements including diseases/diagnoses (e.g., International Classification of Diseases (ICD)-9/10 codes), medical procedures (e.g., Healthcare Common Procedure Coding System (HCPCS)/Current Procedural Terminology (CPT) codes) and prescriptions to provide a complete overview of the PCD. Thus, once the DSE(s) is/are selected (e.g., by the clinician and/or the system), one or more corresponding repositories may be selected accordingly.”); [communication with the] electronic healthcare record type determined (at least [fig 1 and related text] network 108 communicates with EMR 144 on repository 142); identifying the data inputs in the healthcare record system type that are relevant to predicting sleep apnea in a patient (at least [fig 1 and related text including table 1] “ Example, patient cases with (insurance) claims may be sought in the specified period that may have corresponding ICD-10 codes or medications referring to common risk factors, symptoms, and/or signs for OSA which may generally be referred to as risk factors as illustrated in Table 1 below.” – Table 1 shows a list of risk factors, i.e. inputs from the medical records/EMR/EHR, see also element 134- pre-processing of the data for OSA is discussed in [052]); when a patient of the plurality of patients is being seen by the healthcare provider, automatically performing an initial risk assessment for sleep apnea for the patient based on the health history for the patient (at least [ fig 1 and related text] “[0062] The risk estimation module 136 may further compute a risk score for the selected condition (e.g., an OSA risk score in the present illustrative embodiments) for each patient case, for example, based on a presence and/or an absence of recognized risk factors in the patient case... In accordance with the present system, the risk estimation module 136 may then utilize these (22) risk factors (e.g., risk factors, symptoms, and/or signs) and/or others, to determine whether they are present in a patient case..” ) ; displaying a visual prompt to the healthcare provider informing the healthcare provider that the patient is at an elevated risk for sleep apnea while the patient is being seen by the healthcare provider (at least [fig 1 and related text] “In accordance with embodiments of the present system, various methods exist to present the OSA risk information to the patient, clinician, etc. For example, each patient's case or record may be annotated with a total OSA risk score, and risk level (e.g., high, moderate, low)... for example, when a clinician accesses the patient case (e.g., such as when viewing the patients' medical records, etc.), the risk presentation module 138 may render, on a rendering device of the system (e.g., display 192, display 122, etc.), one or more of the patient ID, the computed estimated risk, the assigned risk level and/or risk category (e.g., high risk for OSA, etc.), “). While Pauws as cited teaches all of the above, and at least infers the use of a mobile station, it does not specifically disclose the install/download of an API. Lim however does teach: installing an API configured to communicate with the electronic healthcare record type determined (at least [fig 26 and related text] “The host site 110 may also include an application programming interface (API) 402 with which the host site 110 may interact with other network entities on a programmatic or automated data transfer level. The API 402 and web interface 404 may be configured to interact with the sleep disorder diagnosis and treatment system 200 either directly or via an interface 406. The sleep disorder diagnosis and treatment system 200 may be configured to access a data storage device 103 and data 408 therein either directly or via the interface 406.” At [062] “As described in more detail below, a mobile software application (app) embodying a mobile version of an example embodiment as described herein can be installed and executed on a mobile device, such as a smartphone, a tablet device, laptop computer, or other form of mobile computing or communications device. In another embodiment, a website can be used as a hosted service provider without installing any software on the mobile device. In this embodiment, a user can use the features described herein just by directing a browser to the web site host through the use of the preinstalled or installed browser.” Pauws and Lim are analogous as both references disclose a means of diagnosing and treating a sleep disorder. Pauws as cited at least contemplates the remote communication with an EHR/EMR repository for individual patient information and medical history, and further considers that a mobile station may be used in said communication. As such, it would have been obvious to one of ordinary skill in the art that an API specifically would be installed and used as taught by Lim on the mobile device common to both references in order to create a more secure and efficient line of communication between the different record sources, and therefore a more streamlined patient experience. In reference to claim 2: Pauws further teaches: [communicating with] patient management software used by the healthcare provider that has additional information about the plurality of patients (at least [fig 1 and related text] “The repository 142 may include one or more healthcare repositories such as, each of which may be considered data sources for medical records such as electronic health records (EHRs), electronic medical records (EMRs), and/or the like and, in this regard, may for example, include one or more data repositories for medical records such as a hospital EMR 144, an ambulatory EMR 146, an administrative claim 148, a general practice EMR 150, another EMR 152, etc. Each of these repositories may have the same or different formats or querying rules for accessing and/or file retrieval such as may be employed by the Centers for Medicare and Medicaid Services (CMS) system. Accordingly, formats and/or querying rules for communicating with (e.g., to query, read files, communicate with, etc.) each of the repositories may be stored in the SSI for later use.” See also Data ingestion module 132: ”To perform the extraction, the data-ingestion module 132 may be operative to query the selected repositories in accordance with querying rules for the corresponding repository of the selected repositories from the repository 142. The PCD may include the MSI and related information (e.g., ID, etc.) for each patient (e.g., case) of the patient cohort independently.); identifying any data in the additional information that is relevant to predicting sleep apnea in the patient (at least [fig 1 and related text] risk estimation 136 operates to determine other demographic information or health conditions about the patient in order to update the risk estimation); using any identified relevant additional information when performing the risk assessment (at least fig 1 and related text including 136] “In accordance with the present system, the risk estimation module 136 may then utilize these (22) risk factors (e.g., risk factors, symptoms, and/or signs) and/or others, to determine whether they are present in a patient case, and for each one that is determined to be present, the process may assign a point (e.g., to increase a counter which may initially be set to 0 for each patient case). “). While Pauws as cited teaches all of the above, and at least infers the use of a mobile station, it does not specifically disclose the use of an API. Lim however does teach: providing an API configured to communicate with patient management software (at least [fig 26 and related text] “The host site 110 may also include an application programming interface (API) 402 with which the host site 110 may interact with other network entities on a programmatic or automated data transfer level. The API 402 and web interface 404 may be configured to interact with the sleep disorder diagnosis and treatment system 200 either directly or via an interface 406. The sleep disorder diagnosis and treatment system 200 may be configured to access a data storage device 103 and data 408 therein either directly or via the interface 406.” At [062] “As described in more detail below, a mobile software application (app) embodying a mobile version of an example embodiment as described herein can be installed and executed on a mobile device, such as a smartphone, a tablet device, laptop computer, or other form of mobile computing or communications device. In another embodiment, a website can be used as a hosted service provider without installing any software on the mobile device. In this embodiment, a user can use the features described herein just by directing a browser to the web site host through the use of the preinstalled or installed browser.” The motivation to include the use of an API as taught by Lim in the diagnosis system of Pauws is similar to that in claim 1 and is incorporated by reference herein. In reference to claim 3: Pauws further teaches: wherein the visual prompt is a popup that is consistent with the electronic healthcare record type and user-preferences and may appear beside patient summary data (at least [fig 1 and related text including 074-75] “In accordance with embodiments of the present system, various methods exist to present the OSA risk information to the patient, clinician, etc. For example, each patient's case or record may be annotated with a total OSA risk score, and risk level (e.g., high, moderate, low)... for example, when a clinician accesses the patient case (e.g., such as when viewing the patients' medical records, etc.), the risk presentation module 138 may render, on a rendering device of the system (e.g., display 192, display 122, etc.), one or more of the patient ID, the computed estimated risk, the assigned risk level and/or risk category (e.g., high risk for OSA, etc.), “). In reference to claim 4: Pauws further teaches: wherein the visual prompt provides risk information or cost benefit information that prompts the healthcare provider to collect and enter follow-up information that is relevant to determining whether the patient has sleep apnea and enters any responses to the prompts into the healthcare record system (at least [076] “High and intermediate patient cases may subsequently be presented to a clinician as a candidate to be referred to follow-up screening or diagnosis. Follow-up care may include, for example, one or more of: screening with traditional clinical screening tools (e.g., STOP-BANG, and/or the like), “ at [fig 2 and related text] “during act 209, the process may for example perform a screening survey on the patient cases that were marked positive from the patient cohort. Accordingly, a controller of the system may generate and render on a rendering device of the system a user interface with which the clinician and/or patient may interact to provide/answer questions from the screening survey that may be rendered on the rendering device. The answers may be utilized to determine whether the patient has OSA. This screening survey may include, for example, screening with one or more clinical screening tools for screening for sleep apnea such as STOP-BANG™ (SB), Epworth Sleepiness Scale™ (ESS), 4-Variable screening tool™ (4-V) and Berlin Questionnaire™, and/or the like. These clinical screening tools may vary in purpose (e.g., estimating high risk of OSA, detecting daytime sleepiness or insomnia, etc.).”) In reference to claim 5: Pauws further comprising the acts of calculating a patient risk level for the patient and displaying or changing the appearance of the information in the visual prompt to the healthcare provider when the patient risk level is greater than a selected value (at least [fig 1 and related text including 074-075] “For example, each patient's case or record may be annotated with a total OSA risk score, and risk level (e.g., high, moderate, low). Further, the risk score may be further annotated with the corresponding risk factors, symptoms and signs for suspected OSA as identified from the data…Further, multiple patient cases may be ordered and displayed list-wise on total OSA risk estimate from high to low risk. In this embodiment, the cases at the top of the list are the cases with the highest risk of OSA who require immediate attention from the medical professional. “ see [063-066, figs 3, 4 and related text] for discussion of threshold score for risk interval, at [068] “Two risk score thresholds need to be found—to discern three risk categories. The low risk threshold needs to be found between, for instance, 0 and 5 with good sensitivity and specificity. The high risk threshold needs to be found between 5 and 11 and also should have good sensitivity and specificity. Criteria of what constitutes good sensitivity and specificity dependent on context (e.g., sensitivity+specificity>1.5).”). In reference to claim 6: Pauws further teaches: wherein the initial risk assessment is performed and used to determine whether to identify the additional information (at least [fig 2 and related text] step 205: “Risk estimation may be performed which may include determination of one more risk score(s) which may be further annotated with corresponding risk factors, symptoms and signs for suspected OSA as identified from the data. Thereafter, suspected OSA cases in the patient cohort may be tagged as positive patient cases and the PCD may be updated to reflect this finding. Each of the patient cases that are marked positive (e.g., for risk of OSA) may have an OSA risk assigned thereto such as low, medium, or high. Patient cases with high, moderate, or low risk may be indicated as positive, intermediate, or negative cases for OSA, respectively. For the sake of clarity, positive and intermediate cases will be considered as positive in the present embodiments.”). In reference to claim 7: Paus further teaches: providing feedback to improve the accuracy of the initial risk assessment (at least [034, 044, 081] machine learning employed in the predictions, [0073] feedback loop for system capacity monitoring). In reference to claim 8: Pauws further teaches wherein patient health history is used to determine the benefit of an intervention such as diagnostic testing in the patient (at least [034, 049, 075-076, see also fig 1 and related text] to perform a cost-benefit analysis on whether the intervention is cost effective where the cost is the overall expected value of costs associated with the intervention including diagnosis and treatment and the benefit is the overall economic benefit of performing the intervention (at least [003-009] “If OSA is not recognized and thus left untreated in individuals, OSA can have a negative impact on an affected individual's everyday quality-of-life, mood, productivity, and safety in daily life due to daytime sleepiness. Since the indications of OSA are often ignored until there is some overt manifestation, there is a significant increase in the costs associated with treating OSA following the overt manifestation…although OSA is quite prevalent among the mass population, screening an asymptomatic mass population on obstructive sleep apnea (OSA) is not currently cost-effective and thus not recommended. Although cases of OSA will be found, mass screening is expected to have limited impact on health outcomes but will require an undue amount of effort and cost. In addition, the response rate (e.g., participation) of a mass screening instrument can be rather disappointing, resulting in self-selection and bias in the data and the screening results.” – i.e. the cost benefit analysis is enacted when screening the medical history of a patient). In reference to claim 9: Pauws further teaches: where the overall cost-benefit ratio is used to augment the information prompt according to user-specified or prespecified cutoff ratio (at least [0073] highest risk patients are prioritized in the cost capacity as specified for the diagnostic capacity for a facility or a given system, i.e. “The system may take into account the diagnostic capacity and may refer cases for a diagnostic follow-up starting from the highest risk patient cases (e.g., highest risk patients) and working towards lower risk patients in accordance with the determined risk level (or category) for each patient case in the corresponding risk level (or category) as long as the capacity limit (as discussed above-which is indicative of the diagnostic capacity or the target) has not been exceeded, for a given time period. For example, the system may be set to assign 50 cases a day to follow up procedures such as diagnostic polysomnography if that is the diagnostic capacity or diagnostic target.” – at [003-009] cost benefit analysis completed in the risk assessment). In reference to claim 10: Pauws further teaches: wherein the cost-benefit analysis incorporates a determination of potential costs of determining whether the patient has sleep apnea relative to the potential savings in health care if the patient is diagnosed with sleep apnea versus health care costs if the patient has sleep apnea but is undiagnosed (at least [003-009] “ If OSA is not recognized and thus left untreated in individuals, OSA can have a negative impact on an affected individual's everyday quality-of-life, mood, productivity, and safety in daily life due to daytime sleepiness. Since the indications of OSA are often ignored until there is some overt manifestation, there is a significant increase in the costs associated with treating OSA following the overt manifestation. For example, OSA increases cardiovascular risk including risks of systemic hypertension, pulmonary hypertension, all-cause mortality, congestive heart failure, cardiovascular disease, atrial fibrillation, stroke, arrhythmias, and myocardial infarction (MI), all of which can increase healthcare utilization costs of these individuals once these symptoms are manifested or otherwise identified.”). In reference to claim 11: Pauws further teaches: wherein the visual prompt comprises a listing of additional tests needed to determine whether the patient has sleep apnea (at least [0076] “ High and intermediate patient cases may subsequently be presented to a clinician as a candidate to be referred to follow-up screening or diagnosis. Follow-up care may include, for example, one or more of: screening with traditional clinical screening tools (e.g., STOP-BANG, and/or the like), nasal flow analyses, a home sleep study, an in-lab sleep study using polysomnography, and/or other treatment/diagnostic options.” At [0084] “Accordingly, a controller of the system may generate and render on a rendering device of the system a user interface with which the clinician and/or patient may interact to provide/answer questions from the screening survey that may be rendered on the rendering device. The answers may be utilized to determine whether the patient has OSA. This screening survey may include, for example, screening with one or more clinical screening tools for screening for sleep apnea such as STOP-BANG™ (SB), Epworth Sleepiness Scale™ (ESS), 4-Variable screening tool™ (4-V) and Berlin Questionnaire™, and/or the like. “). In reference to claim 12: Pauws further teaches: wherein the visual prompt includes a numerical risk level for the patient (at least [74] “ For example, each patient's case or record may be annotated with a total OSA risk score, and risk level (e.g., high, moderate, low).”). In reference to claim 13: Pauws/Lim teaches all of the limitations above. Lim further teaches offering a software program that installs the API when installed by the health care provider (at least [fig 26 and related text] “The host site 110 may also include an application programming interface (API) 402 with which the host site 110 may interact with other network entities on a programmatic or automated data transfer level. The API 402 and web interface 404 may be configured to interact with the sleep disorder diagnosis and treatment system 200 either directly or via an interface 406. The sleep disorder diagnosis and treatment system 200 may be configured to access a data storage device 103 and data 408 therein either directly or via the interface 406.” At [062] “As described in more detail below, a mobile software application (app) embodying a mobile version of an example embodiment as described herein can be installed and executed on a mobile device, such as a smartphone, a tablet device, laptop computer, or other form of mobile computing or communications device. In another embodiment, a website can be used as a hosted service provider without installing any software on the mobile device. In this embodiment, a user can use the features described herein just by directing a browser to the web site host through the use of the preinstalled or installed browser.” The motivation to include the use of an API as taught by Lim in the diagnosis system of Pauws is similar to that in claim 1 and is incorporated by reference herein. In reference to claim 14: Pauws/Lim teaches all of the above. Lim further teaches offering the software program for sale on an EHR marketplace (at least [0072] “As one option, the sleep disorder diagnosis and treatment system 200, or a portion thereof, can be downloaded to a user device 141 of user platform 140 and executed locally on a user device 141 (e.g., see FIG. 2 described below)… In one embodiment, the sleep disorder diagnosis and treatment system 200 can be implemented as a service in a service-oriented architecture (SOA) or in a Software-as-a-Service (SAAS) architecture. In any case, the functionality performed by the sleep disorder diagnosis and treatment system 200 is as described herein, whether the application is executed locally or remotely, relative to the user.”) Pauws/Lim are analogous as both references disclose a means of diagnosing and treating sleep disorders. Pauws at least considers the use of a mobile device, and as such the software being widely available as a service as taught by Lim would provide greater access for practitioners and patients alike. Lim teaches that the diagnosis of a sleep disorder using a “convenient and low cost mobile platform” would improve the diagnostic process for both the user and the practitioner. In reference to claim 18: Pauws further teaches: wherein the initial risk assessment is made in real time based on new data collected by the healthcare provider (at least [084] real time answers to the survey/screening questions are used in the determination of OSA). In reference to claim 19: Pauws further teaches: wherein the visual prompt allows the healthcare provider to schedule sleep apnea related appointments for the patient or order diagnostic tests (at least [075-76] “ The risk presentation module 138 may render a UI such as a graphical user interface (GUI) with which the patient or clinician may interact to view information, update information, schedule the corresponding patient to undergo the determined follow-up procedure or procedures, etc. Thereafter the risk presentation module 138 may further update the corresponding patient cases (record) to reflect any changes that may have been made such as scheduling determined follow-up procedure(s) and may update the PCD accordingly and store this information in a memory of the system (e.g., 196, 191, etc.) for further use… High and intermediate patient cases may subsequently be presented to a clinician as a candidate to be referred to follow-up screening or diagnosis. Follow-up care may include, for example, one or more of: screening with traditional clinical screening tools (e.g., STOP-BANG, and/or the like), nasal flow analyses, a home sleep study, an in-lab sleep study using polysomnography, and/or other treatment/diagnostic options. “) In reference to claim 20: Pauws further teaches: where the predictions may be calculated locally instead of communicating them through an API (at least [fig 1 and related text] pre-processing 134, risk estimation 136 calculated on OSAPS 131). Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pauws in view of Lim, further in view of Iyer et al (US 20170147759 A1, hereinafter Iyer.) In reference to claim 15: Pauws/Lim teaches all the limitations above, and further teaches testing volumes for sleep apnea. While one could infer that increased testing would result in increased revenue, the combination does not specifically teach incentivizing the provider. Iyer however does teach: incentivizing the healthcare provider to perform the initial risk assessment based on revenue gained from increased revenue from referral s(at least [0159-0160] “The perioperative healthcare management system 100 also includes a summary user interface to indicate the number of new patient visits to the primary care physician, the number of subsequent follow-up visits to the primary care physician, the number of in-patient visits by the primary care physician to the hospital for patient care, the number of sleep specialist visits, the number of sleep tests generated and the associated reading. This user interface illustrates the efficiency of the perioperative healthcare management system 100 in creating revenue by a referral process.”) Iyer is analogous to both Pauws and Lim in that all references disclose a means and process for diagnosing sleep apnea. One of ordinary skill in the art would have been motivated to include the revenue consideration as taught by Iyer in the interface common to all of the cited references, as obviously the medical diagnosis process for any disorder or disease has a cost associated with it, and subsequent appointments for the process would lead to additional revenue for the provider. As such one of ordinary skill would have found that including revenue in the information would lead to a more efficient referral process for the patient and the provider. Claim(s) 16, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pauws in view of Lim, further in view of Okubo et al (Cost-effectiveness of obstructive sleep apnea screening for patients with diabetes or chronic kidney disease, hereinafter Okubo). In reference to claim 16: Pauws teaches wherein there is a benefit to a diagnosed patient in terms of avoiding comorbidities or other related health concerns (see 003-009), but does not specifically disclose that benefit in years. Okubo further teaches: wherein the potential benefit to the patient is at least partially determined based on additional predicted patient life years (at least [page 1081, 1086-1088] Results Incremental cost-effectiveness ratios of OSA screening compared with do-nothing were calculated as ¥3,516,976 to 4,514,813/quality-adjusted life year (QALY) (US$35,170 to 45,148/QALY) for diabetes patients and ¥3,666,946 to 4, 006,866/QALY (US$36,669 to 40,069/QALY) for CKD patients. Conclusions Taking the threshold to judge cost-effectiveness according to a suggested value of social willingness to pay for one QALY gain in Japan as ¥5 million/QALY (US$50, 000QALY), OSA screening is cost-effective. Our results suggest that active case screening and treatment of OSA for untreated middle-aged male patients with diabetes or CKD could be justifiable as an efficient use of finite health-care resources in the world with high prevalence of these diseases.”). Okubo and Pauws are analogous art as they both disclose a consideration of the costs associated with diagnosing and treating sleep apnea. Pauws discloses specific costs associated with the testing and the lack of testing lading to a worsening co-condition, and as such it would have been obvious to one of ordinary skill in the art to consider the benefits to the user in terms of cost and additional years of living based on a treatment as taught by Okubo. Further, both Pauws and Okubo come to the same conclusion that the diagnosis and treatment of sleep apnea is cost-effective based on the patient(s) being considered. In reference to claim 17: Pauws teaches wherein there is a benefit to a diagnosed patient in terms of avoiding comorbidities or other related health concerns (see 003-009), but does not specifically disclose that benefit in quality adjusted years. Okubo however does teach: wherein the additional predicted patient life years are quality adjusted life years (at least [page 1081, 1086-1088] Results Incremental cost-effectiveness ratios of OSA screening compared with do-nothing were calculated as ¥3,516,976 to 4,514,813/quality-adjusted life year (QALY) (US$35,170 to 45,148/QALY) for diabetes patients and ¥3,666,946 to 4, 006,866/QALY (US$36,669 to 40,069/QALY) for CKD patients. Conclusions Taking the threshold to judge cost-effectiveness according to a suggested value of social willingness to pay for one QALY gain in Japan as ¥5 million/QALY (US$50, 000QALY), OSA screening is cost-effective. Our results suggest that active case screening and treatment of OSA for untreated middle-aged male patients with diabetes or CKD could be justifiable as an efficient use of finite health-care resources in the world with high prevalence of these diseases.”). Okubo and Pauws are analogous art as they both disclose a consideration of the costs associated with diagnosing and treating sleep apnea. Pauws discloses specific costs associated with the testing and the lack of testing lading to a worsening co-condition, and as such it would have been obvious to one of ordinary skill in the art to consider the benefits to the user in terms of cost and additional years of quality living based on a treatment as taught by Okubo. Further, both Pauws and Okubo come to the same conclusion that the diagnosis and treatment of sleep apnea is cost-effective based on the patient(s) being considered. Response to Arguments The following references made of record but not cited: US 20150164410 A1 to Selvaraj discloses a sleep apnea screening process. US 20230238142 A1 to Zotelo discloses a screening process for sleep apnea based on potential compliance with a treatment prescribed. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to KATHERINE KOLOSOWSKI-GAGER whose telephone number is (571)270-5920. The examiner can normally be reached Monday - Friday. 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, Mamon Obeid can be reached at 571-270-1813. 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. /KATHERINE . KOLOSOWSKI-GAGER/ Primary Examiner Art Unit 3687 /KATHERINE KOLOSOWSKI-GAGER/Primary Examiner, Art Unit 3687
Read full office action

Prosecution Timeline

Aug 30, 2024
Application Filed
Dec 13, 2025
Non-Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12499467
PREDICTING THE EFFECTIVENESS OF A MARKETING CAMPAIGN PRIOR TO DEPLOYMENT
2y 5m to grant Granted Dec 16, 2025
Patent 12462273
SYSTEM AND METHOD FOR USING DEVICE DISCOVERY TO PROVIDE ADVERTISING SERVICES
2y 5m to grant Granted Nov 04, 2025
Patent 12462938
MACHINE-LEARNING MODEL FOR GENERATING HEMOPHILIA PERTINENT PREDICTIONS USING SENSOR DATA
2y 5m to grant Granted Nov 04, 2025
Patent 12444507
BAYESIAN CAUSAL INFERENCE MODELS FOR HEALTHCARE TREATMENT USING REAL WORLD PATIENT DATA
2y 5m to grant Granted Oct 14, 2025
Patent 12437315
SYSTEMS AND METHODS FOR DYNAMICALLY DETERMINING EVENT CONTENT ITEMS
2y 5m to grant Granted Oct 07, 2025
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

1-2
Expected OA Rounds
26%
Grant Probability
60%
With Interview (+33.6%)
4y 3m
Median Time to Grant
Low
PTA Risk
Based on 358 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month