DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
This action is in reply to the reply received February 2, 2026 (hereinafter “Reply”).
Claims 1, 12, 19, and 20 are amended.
Claims 1-20 are pending.
Claim Rejections - 35 U.S.C. § 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 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. Claims 1-20 are directed to an abstract idea without significantly more as required by the Alice test as discussed below.
Step 1
Claims 1-20 are directed to a process, machine, manufacture, or composition of matter.
Step 2A
Claims 1-20 are directed to abstract ideas, as explained below.
Prong one of the Step 2A analysis requires identifying the specific limitation(s) in the claim under examination that the examiner believes recites an abstract idea; and determining whether the identified limitation(s) falls within at least one of the groupings of abstract ideas of mathematical concepts, mental processes, and certain methods of organizing human activity.
The claims recite the following limitations that are directed to abstract ideas. Claim 1 recites monitoring live feedback information received over a course of care of a patient, wherein the live feedback comprises physiological information regarding a physiological state of the patient; employing artificial intelligence to identify, based on the live feedback information, an event or condition associated with the course of care of the patient that warrants clinical attention or a clinical response; evaluating the identified event or condition against one or more responses eligibility criteria derived from historical healthcare information, clinical information, or standard operating procedures; and upon satisfaction of the response eligibility criteria, utilizing generative artificial intelligence (AI) to generate a response that facilitates reducing an adverse outcome of the course of care, wherein the response varies based on a classified type of the event or condition, and generating the response without autonomously executing a clinical action. Claims 12 and 19 recite similar features as claim 1. Clams 2-11, 13-18, and 20 further specify characteristics of these abstract ideas or characteristics of the data used thereby.
These limitations describe abstract ideas that correspond to concepts identified as abstract ideas by the courts as mental processes—such as concepts performed in the human mind (including an observation, evaluation, judgment, or opinion)—because the claimed features identified above are concepts performed in the human mind (including an observation, evaluation, judgment, or opinion).
These limitations describe abstract ideas that correspond to concepts identified as abstract ideas by the courts as certain methods of organizing human activity—such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)— because the claimed features identified above manage personal behavior or relationships or interactions between people including following rules or instructions.
Thus, the concepts set forth in claims 1-20 recite abstract ideas.
Prong two of the Step 2A requires identifying whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluating those additional elements to determine whether they integrate the exception into a practical application of the exception. “Integration into a practical application” requires an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Further, “integration into a practical application” uses the considerations laid out by the Supreme Court and the Federal Circuit to evaluate whether the judicial exception is integrated into a practical application, such as considerations discussed in M.P.E.P. § 2106.05(a)-(h).
The claims recite the following additional elements beyond those identified above as being directed to an abstract idea. Claim 1 recites a memory, processor, computer, components (e.g., software) for implementing features, and providing a response to a device. Claim 12 recites similar features as claim 1. Claim 19 recites similar features as claim 1 and further recites a tangible computer-readable storage medium and a computing system. Claims 5 and 16 recite generating and sending a notification. Claims 7-9 and 18 recite presenting information on a graphical user interface (GUI).
The identified judicial exception(s) are not integrated into a practical application for the following reasons.
First, evaluated individually, the additional elements do not integrate the identified abstract ideas into a practical application. The additional computer elements identified above—the memory, processor, computer, components (e.g., software), GUI, tangible computer-readable storage medium, devices, and computing system —are recited at a high level of generality. Inclusion of these elements amounts to mere instructions to implement the identified abstract ideas on a computer. See M.P.E.P. § 2106.05(f). The use of conventional computer elements to transmit information between devices (including providing a response to a device and generating and sending a notification) and presenting the information is the insignificant, extra-solution activity of mere data gathering or outputting in conjunction with a law of nature or abstract idea. See M.P.E.P. § 2106.05(g). To the extent that the claims transform data, the mere manipulation of data is not a transformation. See M.P.E.P. § 2106.05(c). Inclusion of the computing system in the claims amounts to generally linking the use of the judicial exception to a particular technological environment or field of use. See M.P.E.P. § 2106.05(h). Thus, taken alone, the additional elements do not amount to significantly more than a judicial exception.
Second, evaluating the claim limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. See M.P.E.P. § 2106.05(a). Their collective functions merely provide an implementation of the identified abstract ideas on a computer system in the general field of use of applying artificial intelligence algorithms in healthcare delivery. See M.P.E.P. § 2106.05(h).
Thus, claims 1-20 recite mathematical concepts, mental processes, or certain methods of organizing human activity without including additional elements that integrate the exception into a practical application of the exception.
Accordingly, claims 1-20 are directed to abstract ideas.
Step 2B
Claims 1-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
The analysis above describes how the claims recite the additional elements beyond those identified above as being directed to an abstract idea, as well as why identified judicial exception(s) are not integrated into a practical application. These findings are hereby incorporated into the analysis of the additional elements when considered both individually and in combination. Additional features of these analyses are discussed below.
Evaluated individually, the additional elements do not amount to significantly more than a judicial exception. In addition to the factors discussed regarding Step 2A, prong two, these additional computer elements also provide conventional computer functions that do not add meaningful limits to practicing the abstract idea. Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system. The use of generic computer components to transmit information between devices (including providing a response to a device and generating and sending a notification) and presenting the information is the well-understood, routine, and conventional computer functions of receiving or transmitting data over a network, e.g., the Internet, and does not impose any meaningful limit on the computer implementation of the identified abstract ideas. See M.P.E.P. § 2106.05(d)(II). Thus, taken alone, the additional elements do not amount to significantly more than a judicial exception.
Evaluating the claim limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. In addition to the factors discussed regarding Step 2A, prong two, there is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely amount to mere instructions to implement the identified abstract ideas on a computer.
Thus, claims 1-20, taken individually and as an ordered combination of elements, are not directed to eligible subject matter since they are directed to an abstract idea without significantly more.
Claim Rejections - 35 U.S.C. § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. § 102(a)(1)-(2) as being anticipated by Ray et al. (U.S. Pub. No. 2023/0240589 A1) (hereinafter “Ray”).
Claims 1, 12, and 19: Ray, as shown, discloses the following limitations:
a memory that stores computer executable components (see at least ¶ [0214]: FIG. 7 is a block diagram depicting a computing device 700 configured to execute a decision support engine (e.g., decision support engine 114), according to certain embodiments disclosed herein. Although depicted as a single physical device, in embodiments, computing device 700 may be implemented using virtual device(s), and/or across a number of devices, such as in a cloud environment. As illustrated, computing device 700 includes a processor 705, memory 710, storage 715, a network interface 725, and one or more I/O interfaces 720. In the illustrated embodiment, processor 705 retrieves and executes programming instructions stored in memory 710, as well as stores and retrieves application data residing in storage 715. Processor 705 is generally representative of a single CPU and/or GPU, multiple CPUs and/or GPUs, a single CPU and/or GPU having multiple processing cores, and the like. Memory 710 is generally included to be representative of a random access memory. Storage 715 may be any combination of disk drives, flash-based storage devices, and the like, and may include fixed and/or removable storage devices, such as fixed disk drives, removable memory cards, caches, optical storage, network attached storage (NAS), or storage area networks (SAN); see also at least ¶¶ [0215]-[0217]);
a processor that executes the computer executable components stored in the memory (see at least ¶¶ [0214]-[0217] and the analysis above), wherein the computer executable components comprise:
a monitoring component configured to monitor live feedback information received over a course of care of a patient, wherein the live feedback comprises physiological information regarding a physiological state of the patient (see at least ¶ [0145]: continuous analyte monitoring system 104 may continuously monitor ketone levels of the user, during a first time period. In some embodiments, ketone levels may be monitored in conjunction with or in lieu of other analytes (e.g., glucose, lactate, etc.). In such embodiments, the measured ketone concentrations may be used for diagnosing, staging, assessing risks of liver disease, and/or assessing different treatments for liver disease. For example, in some cases, ketone specific metrics may aid in the recommendation of a specific diet for the user diagnosed with liver disease, and further provide real-time feedback on the improvement of liver dysfunction after implementation of the recommended diet; see also at least ¶ [0053]: DAM 113 of decision support engine 114 is configured to process the set of inputs 128 to determine one or more metrics 130. Metrics 130, discussed in more detail below with respect to FIG. 3, may, at least in some cases, be generally indicative of the health or state of a user, such as one or more of the user’s physiological state, trends associated with the health or state of a user, etc. In certain embodiments, metrics 130 may then be used by decision support engine 114 as input for providing guidance to a user. As shown, metrics 130 are also stored in user profile 118);
a significant event/condition identification component configured to employ artificial intelligence to identify, based on the live feedback information, an event or condition associated with the course of care of the patient that warrants clinical attention or a clinical response (see at least ¶ [0207]: the training server system 140 then uses information in each of the records to train an artificial intelligence or ML model (for simplicity referred to as “ML model” herein). Examples of types of information included in a patient's user profile were provided above. The information in each of these records may be featurized (e.g., manually or by training server system 140), resulting in features that can be used as input features for training the ML model. For example, a patient record may include or be used to generate features related to an age of a patient, a gender of the patient, an occupation of the patient, lactate clearance rates, lactate area under the curve, an average change (e.g., average delta) in lactate clearance from a first timestamp to a subsequent timestamp for the patient, other lactate metrics described herein, an average change (e.g., average delta) in liver disease diagnosis from a first timestamp to a subsequent timestamp for the patient, and/or any other data points in the patient record (e.g., inputs 128, metrics 130, etc.); see also at least ¶ [0043]: the combination of a continuous analyte monitoring system with machine learning models and/or algorithms for diagnosing, staging, and assessing risk of liver disease provided by the decision support system described herein enables real-time diagnosis to allow early intervention. In particular, the decision support system may be used to provide an early alert of liver decompensation and/or deliver information about other complications related to the liver); and
a response component configured to:
evaluate the identified event or condition against one or more responses eligibility criteria derived from historical healthcare delivery information, clinician information, or standard operating procedures (see at least ¶ [0039]: the decision support system presented in Ray is designed to provide a diagnosis for patients with, or at risk of, liver disease as well as disease decision support to assist the patient in managing their liver disease, or a risk thereof. Providing liver disease decision support may involve using large amounts of collected data, including for example, the analyte data, patient information, and secondary sensor data mentioned above, to (1) automatically detect and classify abnormal liver conditions, (2) assess the presence and severity of liver disease, (3) risk stratify patients to identify those patients with a high risk of liver disease, (4) identify risks (e.g., mortality risk, liver cancer risk, etc.) associated with a current liver disease diagnosis—i.e., all steps that evaluate the identified event or condition, (5) make patient-specific treatment decisions or recommendations for liver disease, and (6) provide information on the effect of an intervention (e.g., an effect of a lifestyle change of the patient, an effect of a surgical procedure, an effect of the patient taking new medication, etc.). In other words, the decision support system presented herein may offer information to direct and help improve care for patients with, or at risk, of liver disease; see also at least ¶ [0101]: in certain embodiments, treatment/medication information—i.e., criteria derived from historical healthcare delivery information—is also provided as an input. Medication information may include information about the type, dosage, and/or timing of when one or more medications are to be taken by the user—i.e., criteria derived from historical healthcare delivery information; see also at least ¶¶ [0155], [0159], and [0212]), and
upon satisfaction of the response eligibility criteria, utilize generative artificial intelligence (AI) to generate a response that facilitates reducing an adverse outcome of the course of care, wherein the response varies based on a classified type of the event or condition (see at least ¶ [0199]: method 400 continues at block 416 by decision support engine 114 generating one or more recommendations for treatment, based, at least in part, on the disease prediction generated at block 414. In particular, decision support engine 114 makes liver disease treatment decisions or recommendations for the user. Treatment recommendations may include recommendations for lifestyle modification and/or one or more drugs to prescribe, titrate, or avoid use by the user. Decision support engine 114 may output such recommendations for treatment to the user (e.g., through application 106); see also at least ¶ [0212]: the model(s) can then be used to assess, in real-time, the presence and/or severity of liver disease of a user using application 106, provide treatment recommendations, and/or make other types of predictions discussed above. In certain embodiments, the training server system 140 may continue to train the model(s) in an “online” manner by using input features and labels associated with new patient records; see also at least ¶ [0213]: similar methods for training illustrated in FIG. 6 using historical patient records may also be used to train models using patient-specific records to create more personalized models for making predictions associated with liver disease. For example, a model trained using historical patient records that is deployed for a particular user, may be further re-trained after deployment. For example, the model may be re-trained after the model is deployed for a specific patient to create a more personalized model for the patient. The more personalized model may be able to more accurately make liver disease-related predictions for the patient based on the patient's own data (as opposed to only historical patient record data), including the patient's own inputs 128 and metrics 130; see also at least ¶¶ [0039], [0101], [0155], and [0200]), and
wherein the response component is further configured to generate and provide the response to a device associated with an entity involved with treating the patient in association with the course of care without autonomously executing a clinical action (see at least ¶ [0199]: method 400 continues at block 416 by decision support engine 114 generating one or more recommendations for treatment, based, at least in part, on the disease prediction generated at block 414. In particular, decision support engine 114 makes liver disease treatment decisions or recommendations for the user. Treatment recommendations may include recommendations for lifestyle modification and/or one or more drugs to prescribe, titrate, or avoid use by the user. Decision support engine 114 may output such recommendations for treatment to the user (e.g., through application 106); see also at least ¶¶ [0039], [0101], [0155], and [0200]. In Ray, the example of providing a treatment recommendation alone—that is not acted—on amounts to generat[ing] and provid[ing] a response without autonomously executing a clinical action).
Claims 2 and 13: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the significant event/condition identification component is configured to identify the event or condition using machine learning analysis of historical healthcare delivery information regarding same or similar courses of care and one or more standard operating procedures defined for the course of care (see at least ¶ [0036]: certain embodiments described in Ray provide a technical solution to the technical problem described above by providing decision support around liver disease using a continuous analyte monitoring system, including, at least, a continuous lactate sensor. As used herein, the term “continuous” may mean fully continuous, semi-continuous, periodic, etc. The decision support may be provided in the form of risk assessment, diagnosis, staging, and/or recommendations for treatment of liver disease, as described in more detail herein. As used herein, risk assessment may refer to the evaluation or estimation of liver disease of a patient reaching a more advanced stage, mortality risk, liver cancer risk, and the like; see also at least ¶ [0061]: user profiles 118 stored in user database 110 may also be stored in historical records database 112. User profiles 118 stored in historical records database 112 may provide a repository of up-to-date information and historical information for each user of application 106. Thus, historical records database 112 essentially provides all data related to each user of application 106, where data is stored according to an associated timestamp. The timestamp associated with information stored in historical records database 112 may identify, for example, when information related to a user has been obtained and/or updated; see also at least ¶ [0213]: similar methods for training illustrated in FIG. 6 using historical patient records may also be used to train models using patient-specific records to create more personalized models for making predictions associated with liver disease. For example, a model trained using historical patient records that is deployed for a particular user, may be further re-trained after deployment. For example, the model may be re-trained after the model is deployed for a specific patient to create a more personalized model for the patient. The more personalized model may be able to more accurately make liver disease-related predictions for the patient based on the patient's own data (as opposed to only historical patient record data), including the patient's own inputs 128 and metrics 130).
Claims 3 and 14: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the significant event/condition identification component is further configured to identify the event or condition based on information regarding a medical health history of the patient (see at least ¶ [0038]: the continuously monitored lactate data may indicate, or be used for determining, the patient’s lactate levels, lactate production rates, lactate metabolism, and/or lactate clearance rates. Certain embodiments of the present disclosure provide techniques and systems for more accurately determining a patient’s lactate clearance rate using the continuously monitored lactate data as well as correcting a patient's lactate clearance rate by using measurements associated with the non-analyte sensor data and/or other patient information, as further described below. As described above, the collected data also includes patient information, which may include information related to age, gender, family history of liver disease, other health conditions, etc. Secondary sensor data may include accelerometer data, heart rate data, temperature, blood pressure, or any other sensor data other than analyte data; see also at least ¶ [0061]: user profiles 118 stored in user database 110 may also be stored in historical records database 112. User profiles 118 stored in historical records database 112 may provide a repository of up-to-date information and historical information for each user of application 106. Thus, historical records database 112 essentially provides all data related to each user of application 106, where data is stored according to an associated timestamp. The timestamp associated with information stored in historical records database 112 may identify, for example, when information related to a user has been obtained and/or updated).
Claims 4 and 15: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the significant event/condition identification component is further configured to identify the event or condition based on information regarding one or more clinicians responsible for treating the patient in association with the course of care, including at least one of: a current level of fatigue of the one or more clinicians, a current workload of the one or more clinicians, and historical performance information for the one or more clinicians (see at least ¶ [0063]: historical records database 112 may include data for one or more patients who are not users of continuous analyte monitoring system 104 and/or application 106. For example, historical records database 112 may include information (e.g., user profile(s)) related to one or more patients analyzed by, for example, a healthcare physician (or other known method), and not previously diagnosed with liver disease, as well as information (e.g., user profile(s)) related to one or more patients analyzed by, for example, a healthcare physician (or other known method) and were previously diagnosed with liver disease. Data stored in historical records database 112 may be referred to herein as population dat; see also at least ¶ [0101]: treatment/medication information is also provided as an input. Medication information may include information about the type, dosage, and/or timing of when one or more medications are to be taken by the user. Treatment information may include information regarding different lifestyle habits recommended by the user's physician. For example, the user's physician may recommend a user drink alcohol sparingly, exercise for a minimum of thirty minutes a day, or cut calories by 500 to 1,000 calories daily to improve liver health. In certain embodiments, treatment/medication information may be provided through manual user input).
Claims 5 and 16: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the response comprises a notification regarding the significant event or condition and wherein the response component comprises a notification component configured to generate and send the notification to the device (see at least ¶ [0088]: the plurality of display devices may include a custom display device specially designed for displaying certain types of displayable sensor data associated with analyte data received from sensor electronics module. In certain embodiments, the plurality of display devices may be configured for providing alerts/alarms based on the displayable sensor data. Display device 210 is an example of such a custom device. In some embodiments, one of the plurality of display devices is a smartphone, such as display device 220 which represents a mobile phone, using a commercially available operating system (OS), and configured to display a graphical representation of the continuous sensor data (e.g., including current and historic data). Other display devices can include other hand-held devices, such as display device 230 which represents a tablet, display device 240 which represents a smart watch, medical device 208 (e.g., an insulin delivery device or a blood glucose meter), and/or a desktop or laptop computer; see also at least ¶¶ [0039], [0101], [0155], and [0199]-[0200]).
Claims 6 and 17: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the notification comprises a mechanism for providing an acknowledgment indicating the notification was received, and wherein the response component further comprises an acknowledgment component configured to track information regarding whether the acknowledgment was received and timing of reception of the acknowledgment (see at least ¶ [0104]: input received from non-analyte sensors may include input relating to a user's insulin delivery. In particular, input related to the user's insulin delivery may be received, via a wireless connection on a smart pen, via user input, and/or from an insulin pump. Insulin delivery information may include one or more of insulin volume, time of delivery, etc. Other parameters, such as insulin action time or duration of insulin action, may also be received as inputs; see also at least ¶ [0133]: a lactate clearance rate may be expressed as a function of lactate half-life of a user. In particular, an inverse relationship exists between the lactate clearance rate and lactate half-life. In a diseased liver, the slope of lactate clearance is reduced as the calculated lactate half-life increases. As liver disease progresses, the slope of lactate clearance is further reduced and the calculated lactate half-life further increases. Thus, lactate half-life may be indicative of the lactate clearance rate of a user. Lactate clearance rates calculated over time may be time-stamped and stored in the user's profile 118; see also at least ¶¶ [0039], [0088], [0101], [0155], and [0199]-[0200]).
Claims 7 and 18: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the response component comprises an interface component and wherein the response comprises updating, by the interface component, a graphical user interface in real-time to reflect occurrence of the event or condition, wherein the graphical user interface tracks events and conditions associated with the course of care in real-time (see at least ¶ [0088]: the plurality of display devices may include a custom display device specially designed for displaying certain types of displayable sensor data associated with analyte data received from sensor electronics module. In certain embodiments, the plurality of display devices may be configured for providing alerts/alarms based on the displayable sensor data. Display device 210 is an example of such a custom device. In some embodiments, one of the plurality of display devices is a smartphone, such as display device 220 which represents a mobile phone, using a commercially available operating system (OS), and configured to display a graphical representation of the continuous sensor data (e.g., including current and historic data). Other display devices can include other hand-held devices, such as display device 230 which represents a tablet, display device 240 which represents a smart watch, medical device 208 (e.g., an insulin delivery device or a blood glucose meter), and/or a desktop or laptop computer; see also at least ¶ [0090]: sensor electronics module 204 may be in communication with a medical device 208. Medical device 208 may be a passive device in some example embodiments of the disclosure. For example, medical device 208 may be an insulin pump for administering insulin to a user. For a variety of reasons, it may be desirable for such an insulin pump to receive and track glucose, lactate, and potassium values transmitted from continuous analyte monitoring system 104, where continuous analyte sensor 202 is configured to measure glucose, lactate, and/or potassium; see also at least ¶¶ [0039], [0101], [0155], and [0199]-[0200]).
Claim 8: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
a monitoring parameter update component configured to determine one or more parameters related to the event or condition, and wherein the interface component is further configured update the graphical use interface to comprise information that tracks the one or more parameters (see at least ¶ [0088]: the plurality of display devices may include a custom display device specially designed for displaying certain types of displayable sensor data associated with analyte data received from sensor electronics module. In certain embodiments, the plurality of display devices may be configured for providing alerts/alarms based on the displayable sensor data. Display device 210 is an example of such a custom device. In some embodiments, one of the plurality of display devices is a smartphone, such as display device 220 which represents a mobile phone, using a commercially available operating system (OS), and configured to display a graphical representation of the continuous sensor data (e.g., including current and historic data). Other display devices can include other hand-held devices, such as display device 230 which represents a tablet, display device 240 which represents a smart watch, medical device 208 (e.g., an insulin delivery device or a blood glucose meter), and/or a desktop or laptop computer; see also at least ¶ [0090]: sensor electronics module 204 may be in communication with a medical device 208. Medical device 208 may be a passive device in some example embodiments of the disclosure. For example, medical device 208 may be an insulin pump for administering insulin to a user. For a variety of reasons, it may be desirable for such an insulin pump to receive and track glucose, lactate, and potassium values transmitted from continuous analyte monitoring system 104, where continuous analyte sensor 202 is configured to measure glucose, lactate, and/or potassium; see also at least ¶ [0137]: lactate may need to be continuously monitored to continually assess parameters such as lactate clearance rate (also indicative of lactate half-life), lactate levels, lactate production rates, and lactate baselines for diagnosing, staging, treating, and assessing risks of liver disease in real-time; see also at least ¶¶ [0039], [0101], [0155], and [0199]-[0200]).
Claim 9: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
a prioritization component configured to determine a priority order of the significant events and conditions and wherein the interface component is further configured to update the graphical user interface to reflect the priority order (see at least ¶ [0039]: the decision support system presented in Ray is designed to provide a diagnosis for patients with, or at risk of, liver disease as well as disease decision support to assist the patient in managing their liver disease, or a risk thereof. Providing liver disease decision support may involve using large amounts of collected data, including for example, the analyte data, patient information, and secondary sensor data mentioned above, to (1) automatically detect and classify abnormal liver conditions, (2) assess the presence and severity of liver disease, (3) risk stratify patients to identify those patients with a high risk of liver disease, (4) identify risks (e.g., mortality risk, liver cancer risk, etc.) associated with a current liver disease diagnosis, (5) make patient-specific treatment decisions or recommendations for liver disease, and (6) provide information on the effect of an intervention (e.g., an effect of a lifestyle change of the patient, an effect of a surgical procedure, an effect of the patient taking new medication, etc.). In other words, the decision support system presented in Ray may offer information to direct and help improve care for patients with, or at risk, of liver disease; see also at least ¶ [0041]: the algorithms and/or machine-learning models may provide a risk assessment of one or more liver disease types and severity, as well the progression a patient has made towards one or more of those liver disease types. The algorithms and/or machine-learning models may take into consideration population data, personalized patient-specific data, or a combination of both when diagnosing and staging liver disease for a patient).
Claim 10: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the response comprises a recommended clinical response for performance by one or more clinicians responsible for providing medical treatment to the patient in association with the course of care, and wherein the response component comprises a recommendation component configured to employ artificial intelligence to determine the recommended clinical response based on the event or condition and provide the one or more clinicians with information recommending performance of the recommended clinical response (see at least ¶ [0040]: the decision support system described in Ray may use various algorithms or artificial intelligence (AI) models, such as machine-learning models, trained based on patient-specific data and/or population data to provide real-time decision support to a patient based on the collected information about the patient; see also at least ¶ [0101]: treatment/medication information is also provided as an input. Medication information may include information about the type, dosage, and/or timing of when one or more medications are to be taken by the user. Treatment information may include information regarding different lifestyle habits recommended by the user's physician. For example, the user's physician may recommend a user drink alcohol sparingly, exercise for a minimum of thirty minutes a day, or cut calories by 500 to 1,000 calories daily to improve liver health. In certain embodiments, treatment/medication information may be provided through manual user input; see also at least ¶ [0207]: the training server system 140 then uses information in each of the records to train an artificial intelligence or ML model).
Claim 11: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the recommendation component is configured to determine the response based on information regarding the one or more clinicians, including at least one of, a current level of fatigue of the one or more clinicians, a current workload of the one or more clinicians, and historical performance information for the one or more clinicians (see at least ¶ [0063]: historical records database 112 may include data for one or more patients who are not users of continuous analyte monitoring system 104 and/or application 106. For example, historical records database 112 may include information (e.g., user profile(s)) related to one or more patients analyzed by, for example, a healthcare physician (or other known method), and not previously diagnosed with liver disease, as well as information (e.g., user profile(s)) related to one or more patients analyzed by, for example, a healthcare physician (or other known method) and were previously diagnosed with liver disease. Data stored in historical records database 112 may be referred to herein as population data; see also at least ¶ [0101]: treatment/medication information is also provided as an input. Medication information may include information about the type, dosage, and/or timing of when one or more medications are to be taken by the user. Treatment information may include information regarding different lifestyle habits recommended by the user's physician. For example, the user's physician may recommend a user drink alcohol sparingly, exercise for a minimum of thirty minutes a day, or cut calories by 500 to 1,000 calories daily to improve liver health. In certain embodiments, treatment/medication information may be provided through manual user input;).
Claim 20: Ray discloses the limitations as shown in the rejections above. Further, Ray, as shown, discloses the following limitations:
wherein the employing machine learning comprises evaluating historical healthcare delivery information regarding same or similar courses of care and operating information regarding one or more standard operating procedures defined for the course of care to identify events or conditions associated with the course of care that are correlated to one or more adverse outcomes (see at least ¶ [0036]: certain embodiments described in Ray provide a technical solution to the technical problem described above by providing decision support around liver disease using a continuous analyte monitoring system, including, at least, a continuous lactate sensor. As used herein, the term “continuous” may mean fully continuous, semi-continuous, periodic, etc. The decision support may be provided in the form of risk assessment, diagnosis, staging, and/or recommendations for treatment of liver disease, as described in more detail herein. As used herein, risk assessment may refer to the evaluation or estimation of liver disease of a patient reaching a more advanced stage, mortality risk, liver cancer risk, and the like; see also at least ¶ [0061]: user profiles 118 stored in user database 110 may also be stored in historical records database 112. User profiles 118 stored in historical records database 112 may provide a repository of up-to-date information and historical information for each user of application 106. Thus, historical records database 112 essentially provides all data related to each user of application 106, where data is stored according to an associated timestamp. The timestamp associated with information stored in historical records database 112 may identify, for example, when information related to a user has been obtained and/or updated; see also at least ¶ [0213]: similar methods for training illustrated in FIG. 6 using historical patient records may also be used to train models using patient-specific records to create more personalized models for making predictions associated with liver disease. For example, a model trained using historical patient records that is deployed for a particular user, may be further re-trained after deployment. For example, the model may be re-trained after the model is deployed for a specific patient to create a more personalized model for the patient. The more personalized model may be able to more accurately make liver disease-related predictions for the patient based on the patient's own data (as opposed to only historical patient record data), including the patient's own inputs 128 and metrics 130).
Response to Arguments
The arguments submitted with the Reply have been fully considered. The amendments obviate one of the previous two rejections under § 101 of claims 19 and 20 (for not being recited to a statutory class of invention). The remaining arguments are not persuasive.
Arguments Regarding the Rejections Under 35 U.S.C. § 101
Applicant argues that “the Office’s characterization of the claims as being ‘directed to’ abstract mental processes or generalized decision-making is inconsistent with the claim language.” Reply, 8. Examiner disagrees, because the identification of the features directed to abstract relies mainly on claim features that were taken almost completely verbatim from the claims.
Applicant presents several arguments that the claims do not recite abstract ideas because a computer system “conditionally controls the execution” of its claimed algorithm. Reply, p. 9. Examiner disagrees. First, the features identified as directed to abstract ideas do not require any computer implement. Second, subsequent analysis under the Alice test finds that inclusion of the computer system in the claims amounts to mere instructions to implement the identified abstract ideas on a computer. See M.P.E.P. § 2106.05(f).
Applicant argues that the claims “recite a specific technical implementation in which generative AI is conditionally invoked only after evaluation against defined response eligibility criteria, and the generated response is constrained to being informational in nature and delivered to a device associated with a treating entity.” Reply, p. 9. Applicant presents similar arguments that rely on identification of these features a being technical in nature. Reply, p. 10.
Examiner disagrees, because besides the last argued feature of delivering information to a device, the remaining feature is not technical but instead, has been identified as a part of the identified abstract ideas, and thus, cannot demonstrate a practical application or significantly more under the Alice test. The rejections explain why recitation of the feature for delivering the output of this abstract algorithm is insufficient to confer eligibility (whether considered alone or in combination with the other claim features).
Arguments Regarding the Rejections Under 35 U.S.C. § 102
Applicant argues that the claims “expressly recite a two-stage, conditionally gated control sequence in which (i) an event or condition is identified using artificial intelligence based on live feedback information, and (ii) prior to generating any response, the identified event or condition is evaluated against one or more response edibility criteria …” and that Ray does not disclose these features. Reply, p. 11. Applicant presents similar arguments at pages 12-13 of the Reply.
Examiner disagrees, because as shown by the revised anticipation rejections, Ray discloses this “two-stage” sequence. For example, Ray discloses at ¶ [0039] several features numbered (1)-(4) involved in evaluating the eligibility criteria before generat[ing] a response. See also block 406 of FIG. 4 and the corresponding description of those processes depicted thereby. Ray discloses that—at a subsequent stage—one or more recommendations are generated based on the disease prediction. For example, Ray discloses at ¶ [0199] that its method 400 continues at block 416 by decision support engine 114 generating one or more recommendations for treatment, based, at least in part, on the disease prediction generated at block 414. See also, e.g., ¶ [0212].
Applicant argues that “Ray’s disclosure of generating recommendations based on model outputs does not inherently disclose a system or method that withholds execution of generative AI unless and until eligibility criteria are satisfied, as expressly required by the claims.” Reply, p. 11.
Examiner disagrees, because applicant appears to be arguing features that are not required by the claims. The independent claims do not provide any requirement or even discussion of what the system is required to do when any of the claimed conditions are not met. And the claims certainly do not include any language mandating that the system “withholds execution of generative AI unless and until eligibility criteria are satisfied.” Thus, the assertion that these features are “expressly required by the claims” does not appear to have any evidentiary support in the claims or elsewhere in the application.
Applicant argues that Ray does not disclose wherein the response component is further configured to generate and provide the response […] without autonomously executing a clinical action. Reply, pp. 11-12.
Examiner disagrees, because in Ray, the example of providing a treatment recommendation alone—that is not acted—on amounts to generat[ing] and provid[ing] a response without autonomously executing a clinical action. See Ray, e.g., at ¶ [0199].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The following references have been cited to further show the state of the art with respect to artificial intelligence algorithms in healthcare delivery.
McNair et al. (U.S. Pat. No. 11,972,872 B1) (forecasting clinical events from short physiologic timeseries); and
Reddy et al. (“Artificial intelligence-enabled healthcare delivery.” Journal of the Royal Society of Medicine 112.1 (2019): 22-28).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Tokarczyk, whose telephone number is 571-272-9594. The examiner can normally be reached Monday-Thursday between 6:00 AM and 4:00 PM Eastern.
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.
/CHRISTOPHER B TOKARCZYK/ Primary Examiner, Art Unit 3687
Prosecution Insights