Detailed Notice
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/25/2026 has been entered.
Status of Claims
Claims 1-2, 5, 7, 9-10, 13-15, 18-25, 27-28, 30-34, 36, and 38-40 are currently pending.
Claims 3-4, 6, 8, 11-12, 14-17, 26, 29, 35, and 37 are canceled.
Claims 1 and 10 are amended,
Claims 39 and 40 are new.
Claims 1-2, 5, 7, 9-10, 13-15, 18-25, 27-28, 30- 34, 36, and 38-40 are rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 39 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 39 recites the limitation "prior to receiving the triage assessment information: training the machine-learning model to generate opioid use disorder risk predictions based on triage assessments of patients without utilizing historical data, wherein training the machine-learning model comprises: generating the training data representing the set of historical patients; compiling the set of historical patients into a set of cohorts based on a set of International Classification of Diseases (ICD) diagnoses, wherein the set of cohorts comprises (a) a first subset of one or more cohorts having documented opioid use disorder events corresponding to one or more types of opioid use disorder events, and (b) a second subset of one or more cohorts having no history of opioid use disorder events; based on the set of cohorts, determining a set of weights or relationships that indicate a likelihood of near-future opioid use disorder; based on the set of weights or relationships, compiling a prediction model and a set of input variables to the prediction model for generating opioid use disorder risk predictions based on triage assessments of patients without utilizing historical data".
There is insufficient antecedent basis for this limitation in the claim. It is unclear how there would be documented opioid use disorder events (e.g., “compiling the set of historical patients into a set of cohorts based on a set of International Classification of Diseases (ICD) diagnoses, wherein the set of cohorts comprises (a) a first subset of one or more cohorts having documented opioid use disorder events corresponding to one or more types of opioid use disorder events”) without using historical data (e.g., “training the machine-learning model to generate opioid use disorder risk predictions based on triage assessments of patients without utilizing historical data”). Additionally, claim 39 conflicts with claim 19. Claim 19 recites “the machine-learning model having been trained to generate the prediction element comprising the predicted risk of opioid use disorder based on training data representing a set of historical patients, the training data obtained at least in part from an electronic health records system, and the training data indicating for each patient of the set of historical patients, a status with respect to opioid use disorder and one or more variables associated with risk factors for opioid use disorder”. The “training data obtained from electronic health record system”, “training data”, “status with respect to opioid use disorder”, and “one or more variables associated with risk factors for opioid use disorder” would be considered “historical data” for a patient. Therefore, it is unclear how claim 39, which depends on claim 19, would be able to train the machine-learning model to generate opioid use disorder risk predictions based on triage assessments of patients without utilizing historical data.
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-2, 5, 7, 9-10, 13-15, 18-25, 27-28, 30-34, 36, and 38-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1:
In the instant case, claims 1-2, 5, 7, 9, and 40 are directed toward a method (i.e., process), claims 10, 13-15, and 18 are directed toward a non-transitory computer readable media (i.e., manufacture), and claims 19-25, 27-28, 30-34, 36, and 38-39 are directed toward a system (i.e., machine). Thus, each of the claims falls within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A—Prong 1:
Independent claims 1, 10, and 19 recites steps that, under their broadest reasonable interpretations, cover performance of the limitations of a certain method of organizing human activity but for the recitation of generic computer components.
Claim 1 recites: “A method comprising: receiving, via a healthcare computing system, triage assessment information associated with an emergency department encounter comprising an emergency department triage for a patient, wherein the triage assessment information comprises clinical notes pertaining to the emergency department encounter, wherein the clinical notes comprise at least one of: a condition of the patient during the emergency department encounter, or a treatment administered to the patient during the emergency department encounter; receiving, via the healthcare computing system, a request from a clinician to open an electronic health record of the patient for the emergency department encounter comprising the emergency department triage for the patient; determining that historical data for the patient is unavailable; responsive to (a) receiving (i) the request from the clinician to open the electronic health record of the patient and (ii) the triage assessment information and (b) determining that historical data for the patient is unavailable, causing the healthcare computing system to utilize a machine-learning model to generate a predicted risk of opioid use disorder for the patient based on the triage assessment information, wherein causing the healthcare computing system to utilize the machine-learning model to generate the predicted risk of opioid use disorder comprises: directing, to a machine-learning model, an input element comprising the triage assessment information including the clinical notes pertaining to the emergency department encounter, to cause the machine-learning model to generate a prediction element comprising a predicted risk of opioid use disorder for the patient based on the triage assessment information including the clinical notes, the machine-learning model having been trained to generate the prediction element comprising the predicted risk of opioid use disorder based on training data representing a set of historical patients, the training data obtained at least in part from an electronic health records system, and the training data indicating for each patient of the set of historical patients, a status with respect to opioid use disorder and one or more variables associated with risk factors for opioid use disorder; determining, based on the prediction element, that the predicted risk of opioid use disorder for the patient meets a threshold risk, wherein the clinical notes comprise one or more contributing factors to the predicted risk of opioid use disorder, the one or more contributing factors based on at least one of the condition or the treatment; responsive to determining, based on the prediction element, that the predicted risk of opioid use disorder for the patient meets the threshold risk: based on the predicted risk meeting the threshold risk, selecting, via the healthcare computing system, a non-opioid treatment plan for the patient from a group of non-opioid treatment plans corresponding, respectively, to different threshold risks; providing, via the healthcare computing system, within the electronic health record of the patient, the predicted risk of opioid use disorder for the patient and the non- opioid treatment plan for the patient corresponding to the predicted risk of opioid use disorder; based on the clinical notes comprising the one or more contributing factors to the predicted risk of opioid use disorder, providing, via the healthcare computing system, within the electronic health record of the patient, an indication of the one or more contributing factors to the predicted risk of opioid use disorder; and initiating the non-opioid treatment plan for the patient during the emergency department encounter at least by generating, for display on a graphical user interface of the healthcare computing system, (i) an alert corresponding to the predicted risk of opioid use disorder, (ii) a details interface comprising the one or more contributing factors to the predicted risk of opioid use disorder, and (iii) the non- opioid treatment plan for the patient, wherein the alert, the details interface, and the non-opioid treatment plan are visible via the graphical user interface when an authorized user accesses the electronic health record of the patient via the healthcare computing system during the emergency department encounter”.
The limitations of receiving, triage assessment information associated with an emergency department encounter comprising an emergency department triage for a patient, wherein the triage assessment information comprises clinical notes pertaining to the emergency department encounter, wherein the clinical notes comprise at least one of: a condition of the patient during the emergency department encounter, or a treatment administered to the patient during the emergency department encounter; receiving, a request from a clinician for the emergency department encounter comprising the emergency department triage for the patient; determining that historical data for the patient is unavailable; responsive to (a) receiving (i) the request from the clinician and (ii) the triage assessment information and (b) determining that historical data for the patient is unavailable, generate a predicted risk of opioid use disorder for the patient based on the triage assessment information, wherein to generate the predicted risk of opioid use disorder comprises: directing, the triage assessment information including the clinical notes pertaining to the emergency department encounter, a predicted risk of opioid use disorder for the patient based on the triage assessment information including the clinical notes, the predicted risk of opioid use disorder based on training data representing a set of historical patients, and the training data indicating for each patient of the set of historical patients, a status with respect to opioid use disorder and one or more variables associated with risk factors for opioid use disorder; determining, that the predicted risk of opioid use disorder for the patient meets a threshold risk, wherein the clinical notes comprise one or more contributing factors to the predicted risk of opioid use disorder, the one or more contributing factors based on at least one of the condition or the treatment; responsive to determining, that the predicted risk of opioid use disorder for the patient meets the threshold risk: based on the predicted risk meeting the threshold risk, selecting, a non-opioid treatment plan for the patient from a group of non-opioid treatment plans corresponding, respectively, to different threshold risks; providing, the predicted risk of opioid use disorder for the patient and the non-opioid treatment plan for the patient corresponding to the predicted risk of opioid use disorder; based on the clinical notes comprising the one or more contributing factors to the predicted risk of opioid use disorder, providing, an indication of the one or more contributing factors to the predicted risk of opioid use disorder; and initiating the non-opioid treatment plan for the patient during the emergency department encounter at least by generating, for display (i) an alert corresponding to the predicted risk of opioid use disorder, (ii) the one or more contributing factors to the predicted risk of opioid use disorder, and (iii) the non- opioid treatment plan for the patient, wherein the alert, and the non-opioid treatment plan are visible when an authorized user accesses the electronic health record of the patient during the emergency department encounter, given the broadest reasonable interpretation, cover the abstract idea of a certain method of organizing human activity because they recite managing personal behavior or relationships or interactions between people (i.e. social activities, teaching, and following rules or instructions—in this case the aforementioned steps recite a process of receiving, determining, generate, directing, predict, selecting, providing, initiating, and display, which is properly interpreted as a “personal behavior”), but instead automates the process via a computer model, e.g. see MPEP 2106.04(a)(2). Any limitations not identified above as part of the abstract idea are deemed “additional elements”, and will be discussed in further detail below.
Further, the abstract idea of claim 19 is identical as the abstract idea of claim 1. This limitation, given the broadest reasonable interpretation, also falls under the abstract idea of a certain method of organizing human activity because it recites managing personal behavior or relationships or interactions between people.
Additionally, claim 10 recites: “One or more non-transitory computer-readable storage media having computer-executable instructions embodied thereon that, when executed by at least one processor, cause the at least one processor to perform operations comprising: receiving, via a healthcare computing system, triage assessment information associated with an emergency department encounter comprising an emergency department triage for a patient, wherein the triage assessment information comprises clinical notes pertaining to the emergency department encounter, wherein the clinical notes comprise at least one of: a condition of the patient during the emergency department encounter, or a treatment administered to the patient during the emergency department encounter; determining that historical data for the patient is unavailable; responsive to receiving the triage assessment information and determining that historical data for the patient is unavailable: directing, to a machine-learning model, an input element comprising the triage assessment information including the clinical notes pertaining to the emergency department encounter, to cause the machine-learning model to generate a prediction element comprising a predicted risk of opioid use disorder for the patient based on the triage assessment information including the clinical notes, the machine-learning model having been trained to generate the prediction element comprising the predicted risk of opioid use disorder based on training data representing a set of historical patients, the training data obtained at least in part from an electronic health records system, and the training data indicating for each patient of the set of historical patients, a status with respect to opioid use disorder and one or more variables associated with risk factors for opioid use disorder; determining, based on the prediction element, that the predicted risk of opioid use disorder for the patient meets a threshold risk, wherein the clinical notes comprise one or more contributing factors to the predicted risk of opioid use disorder, the one or more contributing factors based on at least one of the condition or the treatment; responsive to determining, based on the prediction element, that the predicted risk of opioid use disorder for the patient meets the threshold risk: based on the predicted risk meeting the threshold risk, selecting, via the healthcare computing system, a non-opioid treatment plan for the patient from a group of non-opioid treatment plans corresponding, respectively, to different threshold risks; providing, via the healthcare computing system, within an electronic health record of the patient, the predicted risk of opioid use disorder for the patient and the non-opioid treatment plan for the patient corresponding to the predicted risk of opioid use disorder; based on the clinical notes comprising the one or more contributing factors to the predicted risk of opioid use disorder, providing, via the healthcare computing system, within the electronic health record of the patient, an indication of the one or more contributing factors to the predicted risk of opioid use disorder; initiating the non-opioid treatment plan for the patient during the emergency department encounter at least by generating, for display on a graphical user interface of the healthcare computing system, (i) an alert corresponding to the predicted risk of opioid use disorder, (ii) a details interface comprising the one or more contributing factors to the predicted risk of opioid use disorder, and (iii) the non- opioid treatment plan for the patient, wherein the alert, the details interface, and the non-opioid treatment plan are visible via the graphical user interface when an authorized user accesses the electronic health record of the patient via the healthcare computing system during the emergency department encounter; transmitting the alert and the non-opioid treatment plan to a remote computer accessible by a clinician associated with the patient, wherein the alert and the non-opioid treatment plan are accessible by the clinician via the remote computer; receiving an interaction with the alert within the electronic health record of the patient; and responsive to receiving the interaction with the alert, providing, via the healthcare computing system, an alert detail comprising at least one of: the predicted risk of opioid use disorder, one or more risk factors specific to the patient, the non-opioid treatment plan, or one or more risk mitigation options”.
The limitations of receiving, triage assessment information associated with an emergency department encounter comprising an emergency department triage for a patient, wherein the triage assessment information comprises clinical notes pertaining to the emergency department encounter, wherein the clinical notes comprise at least one of: a condition of the patient during the emergency department encounter, or a treatment administered to the patient during the emergency department encounter; determining that historical data for the patient is unavailable; responsive to receiving the triage assessment information and determining that historical data for the patient is unavailable: directing, the triage assessment information including the clinical notes pertaining to the emergency department encounter, to a predicted risk of opioid use disorder for the patient based on the triage assessment information including the clinical notes, the predicted risk of opioid use disorder based on training data representing a set of historical patients, and the training data indicating for each patient of the set of historical patients, a status with respect to opioid use disorder and one or more variables associated with risk factors for opioid use disorder; determining, that the predicted risk of opioid use disorder for the patient meets a threshold risk, wherein the clinical notes comprise one or more contributing factors to the predicted risk of opioid use disorder, the one or more contributing factors based on at least one of the condition or the treatment; responsive to determining, that the predicted risk of opioid use disorder for the patient meets the threshold risk: based on the predicted risk meeting the threshold risk, selecting, a non-opioid treatment plan for the patient from a group of non-opioid treatment plans corresponding, respectively, to different threshold risks; providing, the predicted risk of opioid use disorder for the patient and the non-opioid treatment plan for the patient corresponding to the predicted risk of opioid use disorder; based on the clinical notes comprising the one or more contributing factors to the predicted risk of opioid use disorder, providing, an indication of the one or more contributing factors to the predicted risk of opioid use disorder; initiating the non-opioid treatment plan for the patient during the emergency department encounter at least by generating, for display (i) an alert corresponding to the predicted risk of opioid use disorder, (ii) the one or more contributing factors to the predicted risk of opioid use disorder, and (iii) the non- opioid treatment plan for the patient, wherein the alert, the details interface, and the non-opioid treatment plan are visible when an authorized user accesses the electronic health record of the patient during the emergency department encounter; transmitting the alert and the non-opioid treatment plan accessible by a clinician associated with the patient, wherein the alert and the non-opioid treatment plan are accessible by the clinician; receiving an interaction with the alert; and responsive to receiving the interaction with the alert, providing, an alert detail comprising at least one of: the predicted risk of opioid use disorder, one or more risk factors specific to the patient, the non-opioid treatment plan, or one or more risk mitigation options, given the broadest reasonable interpretation, cover the abstract idea of a certain method of organizing human activity because they recite managing personal behavior or relationships or interactions between people (i.e. social activities, teaching, and following rules or instructions—in this case the aforementioned steps recite a process of receiving, determining, directing, generate, selecting, providing, predict, initiating, and transmitting, which is properly interpreted as a “personal behavior”), but instead automates the process via a computer model or machine learning, e.g. see MPEP 2106.04(a)(2). Any limitations not identified above as part of the abstract idea are deemed “additional elements”, and will be discussed in further detail below.
Dependent claims 2, 5, 7, 9, 13-15, 18, 20-25, 27-28, 30-34, 36, and 38-40 include other limitations, as well as specific step of data to be processed, received, and applied, but these only serve to further limit the abstract idea and do not add and additional elements, and hence are nonetheless directed towards fundamentally the same abstract idea as independent claims 1, 10, and 19. However, recitation of an abstract idea is not the end of the 35 U.S.C. 101 analysis. Each of the claims must be analyzed for additional elements that indicate the abstract idea is integrated into a practical application to determine whether the claim is considered to be “directed to” an abstract idea.
Step 2A—Prong 2:
Claims 1-2, 5, 7, 9-10, 13-15, 18-25, 27-28, 30- 34, 36, and 38-40 are not integrated into a practical application because the additional elements (i.e. any limitations that are not identified as part of the abstract idea) amount to no more than limitations which:
Amount to mere instructions to apply an exception—for example, the recitation of “healthcare computing system”, “machine-learning model”, “input element”, “electronic health records system”, “graphical user interface”, “details interface”, “processor”, and “non-transitory computer-readable storage media”, which amount to merely invoking a computer as a tool to perform the abstract idea, e.g. see FIG. 1-3 and [0006]-[0024], of the present specification, and see further MPEP 2106.05(f);
Generally linking the abstract idea to a particular technological environment or field of use, for example, “via a healthcare computing system”, “ via the healthcare computing system”, “causing the healthcare computing system to utilize a machine-learning model to”, “causing the healthcare computing system to utilize the machine-learning model to”, “to a machine-learning model, an input element comprising”, “to cause the machine-learning model to generate a prediction element comprising”, “the machine-learning model having been trained to generate the prediction element comprising”, “the training data obtained at least in part from an electronic health records system”, “based on the prediction element”, “based on the prediction element”, “via the healthcare computing system”, “via the healthcare computing system”, “via the healthcare computing system”, “ on a graphical user interface of the healthcare computing system”, “a details interface comprising”, “via the graphical user interface”, “via the healthcare computing system”, “within the electronic health record of the patient,”, “to open an electronic health record of the patient”, “via a healthcare computing system”, “to a machine-learning model, an input element comprising”, “cause the machine-learning model to generate a prediction element comprising”, “the machine-learning model having been trained to generate the prediction element comprising”, “the training data obtained at least in part from an electronic health records system”, “based on the prediction element”, “based on the prediction element”, “via the healthcare computing system”, “via the healthcare computing system, within an electronic health record of the patient”, “via the healthcare computing system, within the electronic health record of the patient”, “on a graphical user interface of the healthcare computing system”, “a details interface comprising”, “via the graphical user interface”, “via the healthcare computing system”, “to a remote computer”, “via the remote computer”, “within the electronic health record of the patient”, “via the healthcare computing system”, and “one or more non-transitory computer-readable storage media having computer-executable instructions embodied thereon that, when executed by at least one processor, cause the at least one processor to perform operations comprising”, which amounts to limiting the abstract idea to the field of technology/the environment of computers, see MPEP 2106.05(h); and/or
Merely acquiring information for further analysis by the system and the particular manner of acquisition is not described or shown to be important, for example, “receiving, via a healthcare computing system, triage assessment information associated with an emergency department encounter comprising an emergency department triage for a patient, wherein the triage assessment information comprises clinical notes pertaining to the emergency department encounter”, “receiving, via the healthcare computing system, a request from a clinician to open an electronic health record of the patient for the emergency department encounter comprising the emergency department triage for the patient”, “receiving (i) the request from the clinician to open the electronic health record of the patient”, and “receiving the triage assessment information”, which amounts to insignificant extra-solution activity in the form of mere data gathering because it merely functions tangentially to the main idea of the invention and serves only to bring in the data necessary for the inventions main analysis, see MPEP 2106.05(g).
Additionally, dependent claims 2, 5, 7, 9, 13-15, 18, 20-25, 27-28, 30-34, 36, and 38-40 include other limitations (Italics refers to abstract idea and bold refers to additional element):
2. The method of claim 1, wherein the machine-learning model is trained for at least one of: a first population of patients that has been previously diagnosed with opioid use disorder; or a second population of patients that has not been previously diagnosed with opioid use disorder.
5. The method of claim 1, wherein the non-opioid treatment plan comprises one or more of: providing opioid safety education to the patient, providing education on alternate pain management methods to the patient, conducting an opioid use disorder screening, initiating screening, brief intervention, and referral to treatment (SBIRT) assessment, providing medication-assisted treatment (MAT), providing an order for a social worker, conducting a urine drug screening, prescribing or provisioning Naloxone, providing a referral for treatment, or following-up to confirm the patient attended a referral appointment.
7. The method of claim 1, wherein the alert indicates that the predicted risk of opioid use disorder for the patient exceeds the threshold risk.
9. The method of claim 7, further comprising: receiving an interaction with the alert within the electronic health record of the patient; and responsive to receiving the interaction with the alert, providing, via the healthcare computing system, an alert detail comprising at least one of: the predicted risk of opioid use disorder, one or more risk factors specific to the patient, the non-opioid treatment plan, or one or more risk mitigation options.
13. The media of claim 10, wherein the alert indicates that the predicted risk of opioid use disorder for the patient exceeds the threshold risk.
14. The media of claim 13, further comprising: receiving an interaction with the alert within the electronic health record of the patient; and responsive to receiving the interaction with the alert, providing, via the healthcare computing system, an alert detail comprising at least one of: the predicted risk of opioid use disorder, one or more risk factors specific to the patient, the non-opioid treatment plan, or one or more risk mitigation options.
15. The media of claim 10, wherein the machine-learning model is trained for at least one of: a first population of patients that has been previously diagnosed with opioid use disorder; or a second population of patients that has not been previously diagnosed with opioid use disorder.
18. The media of claim 10, wherein the non-opioid treatment plan comprises at least one of: providing opioid safety education to the patient, providing education on alternate pain management methods to the patient, conducting an opioid use disorder screening, initiating screening, brief intervention, and referral to treatment (SBIRT) assessment, providing medication-assisted treatment (MAT), providing an order for a social worker, conducting a urine drug screening, prescribing or provisioning Naloxone, providing a referral for treatment, or following-up to confirm the patient attended a referral appointment.
20. The system of claim 19, wherein the alert indicates that the predicted risk of opioid use disorder for the patient exceeds the threshold risk.
21. The system of claim 19, wherein the operations further comprise: subsequent to generating the alert, further training the machine-learning model based on additional training data representing an additional set of historical patients.
22. The system of claim 19, wherein the operations further comprise: further training the machine-learning model based on additional training data comprising additional emergency department encounters.
23. The system of claim 19, wherein the operations further comprise: further training the machine-learning model based on additional training data comprising the triage assessment information.
24. The system of claim 19, wherein the triage assessment information comprises data at least partially derived by invoking at least one natural language processing algorithm to identify one or more relevant variables in unstructured free text associated with the emergency department encounter.
25. The system of claim 19, wherein the operations further comprise: further training the machine-learning model with additional training data at least partially derived by invoking at least one natural language processing algorithm to identify one or more relevant variables in unstructured free text associated with additional emergency department encounters.
27. The system of claim 19, wherein the operations further comprise: further identifying, via a training component of the machine-learning model, one or more input variables for the machine-learning model that reduce a likelihood of opioid use disorder.
28. The system of claim 19, wherein the training data comprises at least one of: gender, age, prior opioid use disorder diagnosis, prior opioid use disorder events, prior opioids, prior emergency department encounters, prior inpatient encounters, other medications, drug screening tests, hepatitis C tests, tobacco use questionnaires, prior results from medical tests, social history questionnaires, or other diagnoses.
30. The system of claim 19, wherein the operations further comprise: receiving, via the healthcare computing system, a request from a clinician to open the electronic health record of the patient for the emergency department encounter comprising the emergency department triage for the patient; and in response to receiving the request, causing the healthcare computing system to utilize the machine-learning model to generate the predicted risk of opioid use disorder for the patient based on the triage assessment information.
31. The system of claim 19, wherein the training data comprises documented opioid use disorder treatment events, and wherein the machine-learning model is trained for a population of patients that has not been previously diagnosed with opioid use disorder.
32. The system of claim 19, wherein the set of historical patients comprises one or more of: a first cohort having documented opioid use disorder events; or a second cohort having no history of opioid use disorder events.
33. The system of claim 27, wherein further identifying one or more input variables for the machine-learning model comprises: determining one or more weights or relationships that indicate a likelihood of near-future opioid use disorder, and determining one or more items that mitigate a potential opioid use disorder.
34. The system of claim 19, wherein the non-opioid treatment plan comprises: conducting an opioid use disorder screening.
36. The system of claim 19, wherein the operations further comprise: transmitting the alert and the non-opioid treatment plan to a remote computer accessible by a clinician associated with the patient, wherein the alert and the non-opioid treatment plan are accessible by the clinician via the remote computer.
38. The system of claim 19, wherein the operations further comprise: receiving an interaction with the alert within the electronic health record of the patient; and responsive to receiving the interaction with the alert, providing, via the healthcare computing system, an alert detail comprising at least one of: the predicted risk of opioid use disorder, one or more risk factors specific to the patient, the non-opioid treatment plan, or one or more risk mitigation options.
39. The system of claim 19, wherein the operations further comprise: prior to receiving the triage assessment information: training the machine-learning model to generate opioid use disorder risk predictions based on triage assessments of patients without utilizing historical data, wherein training the machine-learning model comprises: generating the training data representing the set of historical patients; compiling the set of historical patients into a set of cohorts based on a set of International Classification of Diseases (ICD) diagnoses, wherein the set of cohorts comprises (a) a first subset of one or more cohorts having documented opioid use disorder events corresponding to one or more types of opioid use disorder events, and (b) a second subset of one or more cohorts having no history of opioid use disorder events; based on the set of cohorts, determining a set of weights or relationships that indicate a likelihood of near-future opioid use disorder; based on the set of weights or relationships, compiling a prediction model and a set of input variables to the prediction model for generating opioid use disorder risk predictions based on triage assessments of patients without utilizing historical data.
40. The method of claim 1, further comprising: responsive to (a) receiving the request from the clinician to open the electronic health record of the patient and (b) determining that the predicted risk of opioid use disorder for the patient meets the threshold risk: transmitting the alert and the non-opioid treatment plan to a remote computer accessible by a clinician associated with the patient, wherein the alert and the non-opioid treatment plan are accessible by the clinician via the remote computer; receiving an interaction with the alert within the electronic health record of the patient; and responsive to receiving the interaction with the alert, providing, via the healthcare computing system, an alert detail comprising at least one of: the predicted risk of opioid use disorder, one or more risk factors specific to the patient, the non-opioid treatment plan, or one or more risk mitigation options.
but as stated above, the limitations recited by these claims also do not integrate the aforementioned abstract idea into a practical application.
Step 2B:
The claims do not include additional elements (i.e., “healthcare computing system”, “machine-learning model”, “input element”, “electronic health records system”, “graphical user interface”, “details interface”, “processor”, and “non-transitory computer-readable storage media”) that are sufficient to amount to “significantly more” than the judicial exception because the additional elements (i.e. the elements other than the abstract idea), as stated above, are directed towards no more than limitations that amount to mere instructions to apply the exception, and/or generally link the abstract idea to a particular technological environment or field of use, which even when reevaluated under the considerations of Step 2B of the analysis, do not amount to “significantly more” than the abstract idea.
Dependent claims 2, 5, 7, 9, 13-15, 18, 20-25, 27-28, 30-34, 36, and 38-40 include other limitations, but none of these limitations are deemed significantly more than the abstract idea because, as stated above, the aforementioned dependent claims do not recite any additional elements not already recited in independent claims 1, 10, and 19, and hence do not amount to “significantly more” than the abstract idea.
Additionally, the additional elements (i.e., “receiving, via a healthcare computing system, triage assessment information associated with an emergency department encounter comprising an emergency department triage for a patient, wherein the triage assessment information comprises clinical notes pertaining to the emergency department encounter”, “receiving, via the healthcare computing system, a request from a clinician to open an electronic health record of the patient for the emergency department encounter comprising the emergency department triage for the patient”, “receiving (i) the request from the clinician to open the electronic health record of the patient”, and “receiving the triage assessment information”), add extra solution activity, which comprises limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in a particular field as demonstrated by:
Relevant court decisions (See MPEP 2106.05(d)(II)):
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) (“Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink.” (emphasis added)).
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, whether taken individually or as an ordered combination, claims 1-2, 5, 7, 9-10, 13-15, 18-25, 27-28, 30- 34, 36, and 38-40 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Response to Arguments
Applicant's arguments filed 02/25/206 have been fully considered but they are not persuasive.
Regarding the 35 U.S.C. 101 Rejection, Applicant argues Examiner did not establish the broadest reasonable interpretation (hereinafter BRI) prior to examining the claim for eligibility, but instead removed limitations from claim 1 before establishing BRI. More specifically, Applicant argues the Examiner has stripped away technical elements.
Examiner respectfully disagrees. The “stripped” away technical elements are additional elements and not part of the abstract idea (i.e., machine learning model, computing system, graphical user interfaces, processors, electronic health record system, etc.). Examiner explicitly points out the abstract idea, minus the additional elements, which are then addressed in Prong 2. Additionally, MPEP 2106.04(a)(2)(II) recites “the sub-groupings encompass both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the “certain methods of organizing human activity” grouping”. Therefore, under BRI, a person is capable of performing the limitations in the claims with the assistance of the technical/additional elements.
Applicant further argues Examiner has isolated specific verbs from their context within the independent claims, but that these verbs refer to computer-system operations that are tied to the technological context.
Examiner respectfully disagrees. As stated above, the technical elements are the additional elements that the abstract idea is being applied or “tied to”, which is not shown to be an improvement. MPEP 2106.05(f) states “Requiring more than mere instructions to apply an exception does not mean that the claim must be narrow in order to be eligible. The courts have identified some broad claims as eligible see, e.g. McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 120 USPQ2d 1091 (Fed. Cir. 2016); Thales Visionix Inc. v. United States, 850 F.3d. 1343, 121 USPQ2d 1898 (Fed. Cir. 2017), and some narrow claims as ineligible see e.g. Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 112 USPQ2d 1750 (Fed. Cir. 2014); Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 119 USPQ2d 1739 (Fed. Cir. 2016)… The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words “apply it”. See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015)… Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer” does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).”
Applicant argues the claims do not recite an abstract idea of a certain method of organizing human activity and cannot be practically performed in the human mind. Applicant further argues the Office lacks “substantial evidence” to support any conclusion that the aforementioned features of claim 1 allegedly would be instructions followed by humans. Applicant further argues the claims cannot be practically performed in the human mind, similar to Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1147-49, 120 USPQ2d 1473, 1480-81 (Fed. Cir. 2016), hereinafter Synopsys.
Examiner respectfully disagrees. “Substantial evidence” is not required by the MPEP to establish the claims recite an abstract idea. MPEP 2106.04(a) states “Examiners should determine whether a claim recites an abstract idea by (1) identifying the specific limitation(s) in the claim under examination that the examiner believes recites an abstract idea, and (2) determining whether the identified limitations(s) fall within at least one of the groupings of abstract ideas listed above”. Examiner has clearly identified specific limitations recite and abstract idea and which limitations fall within at least one groupings of abstract ideas as listed by the MPEP. In Synopsys the court disagreed with the patentee that the claimed methods of logic circuit design were intended to be used in conjunction with computer-based design tools, and were thus not mental processes. It interpreted the claims as encompassing nothing other than pure mental steps (and thus falling within an abstract idea grouping) because the claims did not include any limitations requiring computer implementation. Furthermore, the machine learning element/model in the claims is not part of the abstract idea, but an additional element that is being applied to the abstract idea (see MPEP 2106(II)).
Applicant also argues the claims are similar to Ex parte Hannun, Example #39, Example #23, and Example #37, Claim 2.
Examiner respectfully disagrees. Ex parte Hannun is directed to a method of converting speech to text using a trained neural network. Example #39 recites features of training a neural network for facial detection. Example #23 recites features of dynamically relocating textual information within an underlying window displayed in a graphical user interface. Example #37, claim 2 recites features of rearranging icons on a graphical user interface (GUI) of a computer system. The claims recite features of training a machine learning model to predict the likelihood of near-future OUD for patients presenting in an emergency department. Ex parte Hannun, Example #39, Example #37, Claim 2, and Example #23 Claim 1 were eligible because they did not recite an abstract idea, however, the instant claims do recite an abstract idea. Additionally, none of the features are similar to any of the listed Examples and Ex parte Hannun. Also, in Applicant’s arguments with respect to Example #23, it is unclear which claim of the example Applicant alleges the instant claims are analogous with. Claim 1 of Example #23 recite no abstract idea, which is unlike the instant claims that do recite an abstract idea. Claims 2 and 3 of Example #23 are ineligible because they recite abstract ideas without significantly more or integrating the abstract idea into a practical application. Claim 4 of Example #23 was eligible because even though it recites an abstract idea, the abstract idea is integrated into a practical application by improving the function of the computer by scaling and relocating textual information in overlapping windows, which also improves the ability of the computer to display information and interact with the user. The current application and claims does not improve the function of a computer nor integrate that abstract into a practical application in a similar manner to Example #23, claim 4.
Applicant argues any alleged abstract idea is integrated into a practical application because claim 1 improves health computing systems technology associated with emergency department triage, including opioid use disorder prediction technology. Applicant argues the claims provide a technological solution to overcome a problem specifically arising in healthcare computing systems associated with triaging a patient during an emergency department encounter when no historical data is available for a patient. Applicant argues the claims uses a machine learning model to utilize a novel source of data, thus improves healthcare computing systems technology associated with emergency department triage. Applicant also argues the claims improves healthcare computing systems technology associated with emergency department tirage, including graphical user interfaces (GUI), because the healthcare computing system selects a non-opioid treatment plan for the patient and initiates the non-opioid treatment plan by generating an alert and the non-opioid treatment plan for display, thus the GUI is an improved tool for use by clinicians during emergency department encounters.
Examiner respectfully disagrees. The use of the additional elements of GUI, machine healthcare computing system, machine-learning model, input element, electronic health records system, graphical user interface, details interface, processor, etc. are recited at a high level of generality that they amount to computer tools. As stated above the abstract idea is being tied/applied to the additional elements (see MPEP 2106.05(f)). Additionally, more accurately/efficiently triaging patients, even when no historical data is used, is not a technical improvement, but a business practice improvement. Also, this practice is not new and predates computers, internet, or similar technology. The GUI is also being generalized and merely being applied to the abstract idea of displaying. Examiner also notes that an abstract idea cannot integrate itself into a practical application, only the improvement of the function of the technology or technical field. Therefore, the claims do not integrate the abstract idea into a practical application.
Applicant also argues this is similar to Example #47, claim 3.
Examiner respectfully disagrees. Example #47, claim 3 recites features of using an artificial neural network (ANN) to detect malicious network packets, which is not similar to training a machine learning model to predict the likelihood of near-future OUD for patients presenting in an emergency department. Furthermore, claim 3 of Example #47 was eligible because detecting a source address associated with malicious network packets, automatically dropping the one or more malicious network packets and blocking future traffic from the source address, was held to improve network security, which integrated the abstract idea into a practical application. Again, this is also not similar to training a machine learning model to predict the likelihood of near-future OUD for patients presenting in an emergency department.
Applicant argues the claims provide a technological solution to a technological problem because the use of triage assessment information includes clinical notes pertaining to an emergency department encounter to predict risk of opioid use disorder is a “particular solution” to the problem that conventional systems are unable to accurately predict OUD, especially when no historical data is available.
Examiner respectfully disagrees. The claims and the technology (machine learning model, computing system, processor, GUI, etc.) are recited at a high level with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result. Furthermore, MPEP 2106.05(f)(1) recites “By way of example, in Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017)” hereinafter Intellectual Ventures, “the steps in the claims described “the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’” 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of “collecting, displaying, and manipulating data.” 850 F.3d at 1340; 121 USPQ2d at 1946. In addition to the abstract idea, the claims also recited the additional element of modifying the underlying XML document in response to modifications made in the dynamic document. 850 F.3d at 1342; 121 USPQ2d at 1947-48. Although the claims purported to modify the underlying XML document in response to modifications made in the dynamic document, nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents. The court thus held the claims ineligible, because the additional limitations provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words “apply it”. 850 F.3d at 1341-42; 121 USPQ2d at 1947-48 (citing Electric Power Group., 830 F.3d at 1356, 1356, USPQ2d at 1743-44”. Just like in Intellectual Ventures, the abstract idea of collecting/receiving data (e.g., no historical data and opioid use data), displaying (e.g., a prediction or non-opioid treatment), and manipulating data are applied to the additional elements (e.g., machine learning model, interface, GUI, processor, etc.). Therefore, the claims do not integrate the abstract idea into a practical application.
Applicant also argues claims are similar to Example #42.
Examiner respectfully disagrees. Example #42 is eligible because the additional elements recite a specific improvement over prior art systems by allowing remote users to share information in real time in a standardized format regardless of the format in which the information was input by the user. Example #42 addressed a shortcoming in the prior art that was solved by the claimed invention. The claims do not recite a solution to a technical problem like the invention that made Example #42 eligible, nor addresses a shortcoming in the prior art similar to Example #42.
Applicant argues the claims amount to significantly more than the judicial exception and that the Examiner failed to apply the standards for determining patent eligibility under Step 2B.
Examiner respectfully disagrees. MPEP 2106.05 recites “lack of novelty under 35 U.S.C. 102 or obviousness under 35 U.S.C. 103 of a claimed invention does not necessarily indicate that additional elements are well-understood, routine, conventional elements. Because they are separate and distinct requirements from eligibility, patentability of the claimed invention under 35 U.S.C. 102 and 103 with respect to the prior art is neither required for, nor a guarantee of, patent eligibility under 35 U.S.C. 101” and “Limitations that the courts have found not to be enough to qualify as “significantly more” when recited in a claim with a judicial exception include: i. Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 573 U.S. at 225-26, 110 USPQ2d at 1984 (see MPEP § 2106.05(f)); ii. Simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984 (see MPEP § 2106.05(d)); iii. Adding insignificant extra-solution activity to the judicial exception, e.g., mere data gathering in conjunction with a law of nature or abstract idea such as a step of obtaining information about credit card transactions so that the information can be analyzed by an abstract mental process, as discussed in CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011) (see MPEP § 2106.05(g)); or iv. Generally linking the use of the judicial exception to a particular technological environment or field of use, e.g., a claim describing how the abstract idea of hedging could be used in the commodities and energy markets, as discussed in Bilski v. Kappos, 561 U.S. 593, 595, 95 USPQ2d 1001, 1010 (2010) or a claim limiting the use of a mathematical formula to the petrochemical and oil-refining fields, as discussed in Parker v. Flook, 437 U.S. 584, 588-90, 198 USPQ 193, 197-98 (1978) (MPEP § 2106.05(h))”. Examiner has explicitly cited MPEP and court cases in the previous and current Office action. Examiner has reiterated how the claims do not amount to significantly more, has analyzed the additional elements individually and in combination, and has clearly shown how the abstract idea is not integrated by the additional elements, but merely applies the abstract idea to the additional element. Therefore, the 35 U.S.C. 101 Rejection is maintained.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHAEL SOJIN STONE whose telephone number is (571)272-8798. The examiner can normally be reached Monday-Friday 7 AM - 7 PM (EST).
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, Peter Choi can be reached at (469) 295-9171. 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.
/R.S.S./Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
Prosecution Insights