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 .
Status of Claims
Claims 1-5, 7-9, 11, 13, 15-16, and 18-24 are currently pending.
Claims 6, 10, 12, 14, and 17 are canceled.
Claims 21-24 are new.
Claims 1-3, 5, 7-9, 11, 13, 15-16, 18-20 are amended.
Claims 1-5, 7-9, 11, 13, 15-16, and 18-24 are rejected.
Claim Objections
Claim 21 is objected to because of the following informalities: “receiving, from the at least of the accelerometer and the altimeter”, should read “receiving, from the at least one of the accelerometer and the altimeter”. Appropriate correction is required.
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 therefore, subject to the conditions and requirements of this title.
Claims 1-5, 7-9, 11, 13, 15-16, and 18-24 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-5, 7-9, 11, 13, 15-16, 18, and 21-24 are directed toward a method (i.e. a process), claim 19 is directed towards an early warning system (i.e., machine), and claim 20 is directed toward a non-transitory, tangible computer-readable medium (i.e., manufacture). 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, 19, and 20 recite 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 for operating an early warning system to predict a heart failure decompensation event associated with a patient in a home setting, the method comprising: receiving, by a processor implemented in the early warning system, continuous lactate data from a continuous lactate monitoring system associated with the patient, wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices; providing, by the processor, (a) the continuous lactate data and (b) patient health information associated with the patient as inputs to a patient prediction model to generate a predicted heart failure decompensation event, wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information; receiving, by the processor, the predicted heart failure decompensation event from the patient prediction model, wherein the predicted heart failure decompensation event is generated based on the inputs; identifying, by the processor and based on the predicted heart failure decompensation event, a recipient device from the plurality of recipient devices to receive a notification, wherein the recipient device is located at a second location; and transmitting, by the processor, the notification to the recipient device, wherein content of the notification is specific to the recipient device”.
The limitations of receiving, continuous lactate data associated with the patient; providing, (a) the continuous lactate data and (b) patient health information associated with the patient as inputs to generate a predicted heart failure decompensation event, wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information; receiving, the predicted heart failure decompensation event, wherein the predicted heart failure decompensation event is generated based on the inputs; identifying, and based on the predicted heart failure decompensation event, receive a notification; and transmitting, the notification, wherein content of the notification is specific, 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, generate, identifying, and transmitting, 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.
Claim 19 recites: “An early warning system for predicting a heart failure decompensation event associated with a patient in a home setting comprising: a processor configured to be in communication with a continuous lactate monitoring system at a first location associated with the home setting and a plurality of recipient devices; and a memory coupled to the processor and storing a patient prediction model and instructions that when executed by the processor cause the processor to: receive continuous lactate data from the continuous lactate monitoring system (a) the continuous lactate data and (b) patient health information as inputs to a patient prediction model to generate a predicted heart failure decompensation event, wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information; receive, from the patient prediction model, the predicted heart failure decompensation event, wherein the predicted heart failure decompensation event is determined based on the inputs; identify a recipient device of the plurality of recipient devices to receive a notification based on the predicted heart failure decompensation event, wherein the recipient device is located at a second location; and transmit the notification based on the predicted heart failure decompensation event, wherein content of the notification is specific to the recipient device”.
The limitations of receive continuous lactate data (a) the continuous lactate data and (b) patient health information as inputs to generate a predicted heart failure decompensation event, wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information; receive, the predicted heart failure decompensation event, wherein the predicted heart failure decompensation event is determined based on the inputs; identify to receive a notification based on the predicted heart failure decompensation event, ; and transmit the notification based on the predicted heart failure decompensation event, wherein content of the notification is specific, 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 receive, identify, generate, and transmit, 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.
Claim 20 recites: “A non-transitory, tangible computer-readable medium having instructions stored thereon that, when executed by at least one computing device in an early warning system configured to predict a heart failure decompensation event associated with a patient in a home setting, cause a processor of the at least one computing device to perform operations comprising: receiving, by the processor, continuous lactate data from a continuous lactate monitoring system, wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices; providing, by the processor, a) the continuous lactate data and (b) patient health information as inputs to a patient prediction model to generate a predicted heart failure decompensation event, wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information; receiving, by the processor from the patient prediction model, the predicted heart failure decompensation event, wherein the predicted heart failure decompensation event is generated based on the inputs; identifying, by the processor, a recipient device of the plurality of recipient devices to receive a notification based on the predicted heart failure decompensation event, wherein the recipient device is located at a second location; and transmitting the notification based on the predicted heart failure decompensation event to the recipient device at the second location, wherein content of the notification comprises is specific to the recipient device”.
The limitations of receiving, continuous lactate data; providing, a) the continuous lactate data and (b) patient health information as inputs to generate a predicted heart failure decompensation event, wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information; receiving, the predicted heart failure decompensation event, wherein the predicted heart failure decompensation event is generated based on the inputs; identifying, of the plurality of recipient devices to receive a notification based on the predicted heart failure decompensation event; and transmitting the notification based on the predicted heart failure decompensation event, wherein content of the notification comprises is specific, 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, identifying, and transmitting, 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.
Dependent claims 2-5, 7-9, 11, 13, 15-16, 18, and 21-24 include other limitations, for example:
Claim 21 recites the additional elements of a “accelerometer”, “altimeter”, and “processor”;
Claim 22 recites the additional elements of “patient prediction models”;
only serve to further limit the abstract idea, and hence are nonetheless directed towards fundamentally the same abstract idea as independent claims 1, 19, and 20. 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-5, 7-9, 11, 13, 15-16, and 18-24 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 “processor”, “early warning system”, “continuous lactate monitoring system”, “recipient devices”, “patient prediction model”, “memory”, and “non-transitory, tangible computer-readable medium”, which amount to merely invoking a computer as a tool to perform the abstract idea, e.g. see FIG. 1, [0007], [0033], and [0037]-[0040], 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, “by a processor implemented in the early warning system”, “from a continuous lactate monitoring system”, “wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices”, “by the processor”, “to a patient prediction model”, “by the processor”, “from the patient prediction model”, “by the processor”, “a recipient device from the plurality of recipient devices to”, “wherein the recipient device is located at a second location”, “by the processor”, “to the recipient device”, “to the recipient device”, “a processor configured to be in communication with a continuous lactate monitoring system at a first location associated with the home setting and a plurality of recipient devices; and a memory coupled to the processor and storing a patient prediction model and instructions that when executed by the processor cause the processor to”, “to a patient prediction model”, “from a continuous lactate monitoring system, wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices”, and “A non-transitory, tangible computer-readable medium having instructions stored thereon that, when executed by at least one computing device in an early warning system configured to predict a heart failure decompensation event associated with a patient in a home setting, cause a processor of the at least one computing device 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, by a processor implemented in the early warning system, continuous lactate data from a continuous lactate monitoring system associated with the patient, wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices”, “receiving, by the processor, the predicted heart failure decompensation event from the patient prediction model, wherein the predicted heart failure decompensation event is generated based on the inputs”, and “receive a notification”, 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, 11, 13, 15-16, 18, and 21-24 include other limitations, but as stated above, the limitations recited by these claims do not include any additional elements beyond those already recited in independent claims 1, 19, and 20, and hence also do not integrate the aforementioned abstract idea into a practical application.
Step 2B:
The claims do not include additional elements (i.e., “processor”, “early warning system”, “continuous lactate monitoring system”, “recipient devices”, “patient prediction model”, “memory”, and “non-transitory, tangible computer-readable medium”) 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, 11, 13, 15-16, 18, and 21-24 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, 19, and 20, and hence do not amount to “significantly more” than the abstract idea.
Additionally, the additional elements (i.e., “receiving, by a processor implemented in the early warning system, continuous lactate data from a continuous lactate monitoring system associated with the patient, wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices”, “receiving, by the processor, the predicted heart failure decompensation event from the patient prediction model, wherein the predicted heart failure decompensation event is generated based on the inputs”, and “receive a notification”), 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-5, 7-9, 11, 13, 15-16, and 18-24 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-9, 11, 13, 15-16, and 18-24 are rejected under 35 U.S.C. 103 as being unpatentable over Ray et al. (US 20230240589 A1), hereinafter Ray, in view of Stahmann et al. (US 20160287091 A1), hereinafter Stahmann, and Xu et al. (US 20180310136 A1), hereinafter Xu.
Regarding claim 1, Ray teaches a method for operating an early warning system to predict a decompensation event associated with a patient in a home setting, the method comprising: receiving, by a processor implemented in the early warning system, continuous lactate data from a continuous lactate monitoring system associated with the patient (Ray, FIG. 4, [0005]: “Lactate is measured and analyzed using various approaches including central laboratory methods, near patient blood gas analysis, and analysis using portable point of care (POC) handheld devices”, [0007]: “For this reason, small hand-held devices, much like glucose meters, have been made available for lactate measuring and analysis. A user may carry a self-monitoring lactate monitor which typically requires the user to prick his or her finger to measure his or her lactate levels”, and [0012]: “FIG. 4 is a flow diagram illustrating an example method for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with some example aspects of the present disclosure”), wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices (Ray, FIG. 4, [0051]: “decision support engine 114 executes partially on one or more local devices, such as display device 107, and partially on one or more computing devices in a private or a public cloud. In some other embodiments, decision support engine 114 executes entirely on one or more local devices, such as display device 107 or analyte sensor system 104 (e.g., sensor electronics module 204 of FIG. 2 )”, [0052]: “application 106 may obtain additional inputs 128 through manual user input, one or more other non-analyte sensors or devices, other applications executing on display device 107, etc. Non-analyte sensors and devices include one or more of, but are not limited to, an insulin pump, respiratory sensor, sensors or devices provided by display device 107 (e.g., accelerometer, camera, global positioning system (GPS), heart rate monitor, etc.) or other user accessories (e.g., a smart watch), or any other sensors or devices that provide relevant information about the user”, [0135]: “FIG. 4 is a flow diagram illustrating example method 400 for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with certain example aspects of the present disclosure… Method 400 may be performed by decision support system 100 to collect data, including for example, analyte data, patient information, and non-analyte 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, 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”, [0155]: “At block 406, method 400 continues by processing the analyte data from the first time period to determine at least one lactate clearance rate. Block 406, in certain embodiments, may be performed by decision support engine 114”); providing, by the processor, (a) the continuous lactate data (Ray, FIG. 4, [0005]: “Lactate is measured and analyzed using various approaches including central laboratory methods, near patient blood gas analysis, and analysis using portable point of care (POC) handheld devices”, [0007]: “For this reason, small hand-held devices, much like glucose meters, have been made available for lactate measuring and analysis. A user may carry a self-monitoring lactate monitor which typically requires the user to prick his or her finger to measure his or her lactate levels”, and [0012]: “FIG. 4 is a flow diagram illustrating an example method for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with some example aspects of the present disclosure”) and (b) patient health information associated with the patient (Ray, [0193]: “In certain embodiments, such rules may be determined based on training server system 140 analyzing historical patient records from historical records database 112”) as inputs to a patient prediction model (Ray, [0042]: “As described in more detail herein, the population data may be provided in a form of a dataset including data records of historical patients with varying stages of liver disease. Each data record is then featurized (e.g., refined into a set of one or more features, or predictor variables) and labeled. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning models. In certain embodiments, each data record is labeled with its corresponding liver disease diagnosis, assigned disease score, risk assessment, etc. The features associated with each data record may be used as input into the machine learning models, and the generated output may be compared to label(s) assigned to each of the data records”) to generate a predicted decompensation event (Ray, [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. Early detection of such decompensation and/or other complications may allow for intervention at the earliest possible stage to ultimately improve liver disease outcomes”), wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information (Ray, [0032]: “Physicians use information from a patient's history, physical examination, laboratory findings, and other diagnostic tests to diagnose and stage a disease to prescribe appropriate treatment” and [0054]: “User profile 118 also includes demographic info 120, disease progression info 122, and/or medication info 124. In certain embodiments, such information may be provided through user input or obtained from certain data stores (e.g., electronic medical records (EMRs), etc.). In certain embodiments, demographic info 120 may include one or more of the user's age, body mass index (BMI), ethnicity, gender, etc. In certain embodiments, disease progression info 122 may include information about a disease of a user, such as whether the user has been previously diagnosed with cirrhosis, liver fibrosis, NAFLD, NASH, hepatic ischemia reperfusion injury, primary biliary cholangitis (PBC), primary sclerosing cholangitis (PSC), or whether the user has been previously diagnosed with liver disease caused by viruses, such as hepatitis A, hepatitis B, or hepatitis C. In certain embodiments, information about a user's disease may also include the length of time since diagnosis, the level of disease control, level of compliance with liver disease management therapy, predicted liver function, other types of diagnosis (e.g., heart disease, obesity) or measures of health (e.g., heart rate, exercise, stress, sleep, etc.), and/or the like”); receiving, by the processor, the predicted decompensation event from the patient prediction model, wherein the predicted decompensation event is generated based on the inputs (Ray, FIG. 6, [0014]: “FIG. 6 is a flow diagram depicting a method for training machine learning models to provide a prediction of liver disease diagnosis, according to certain embodiments of the present disclosure”, [0040]-[0043]: “As described in more detail herein, the population data may be provided in a form of a dataset including data records of historical patients with varying stages of liver disease. Each data record is then featurized (e.g., refined into a set of one or more features, or predictor variables) and labeled. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning models. In certain embodiments, each data record is labeled with its corresponding liver disease diagnosis, assigned disease score, risk assessment, etc. The features associated with each data record may be used as input into the machine learning models, and the generated output may be compared to label(s) assigned to each of the data records. The models may compute a loss based on the difference between the generated output and the provided label. This loss can then be used to modify the internal parameters or weights of the models. By iteratively processing features associated with each data record corresponding to each historical patient, the models may be iteratively refined to generate accurate predictions of liver disease presence and severity in a patient”); identifying, by the processor and based on the predicted decompensation event, a recipient device from the plurality of recipient devices to receive a notification, (Ray, [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 (not shown)” and [0215]: “In certain embodiments, computing device 700 is representative of mobile device 107 associated with the user. In certain embodiments, as discussed above, the mobile device 107 can include the user's laptop, computer, smartphone, and the like. In another embodiment, computing device 700 is a server executing in a cloud environment”); and transmitting, by the processor, the notification to the recipient device, wherein content of the notification is specific to the recipient device (Ray, FIG. 2, [0048]-[0049]: “continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to an electric medical records (EMR) system and/or an interface engine (not shown in FIG. 1 ). An EMR system is a software platform which allows for the electronic entry, storage, and maintenance of digital medical data. An interface engine is a data synchronization tool to ensure that EMR databases and other systems databases are in sync on a network. An EMR system is generally used throughout hospitals and/or other caregiver facilities to document clinical information on patients over long periods. EMR systems organize and present data in ways that assist clinicians with, for example, interpreting health conditions and providing ongoing care, scheduling, billing, and follow up. Data contained in an EMR system may also be used to create reports for clinical care and/or disease management for a patient… continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to display device 107 for use by application 106. In some embodiments, continuous analyte monitoring system 104 transmits the analyte measurements to display device 107 through a wireless connection (e.g., Bluetooth connection, WiFi connection and/or NFC). The transmission of analyte measurements may be broadcast or on-demand and continuous (e.g., fully continuous, semi-continuous, or periodic). In certain embodiments, display device 107 is a smart phone. However, in certain other embodiments, display device 107 may instead be any other type of computing device such as a laptop computer, a smart watch, a tablet, or any other computing device capable of executing application 106. Continuous analyte monitoring system 104 may be described in more detail with respect to FIG. 2”).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Ray and Stahman do not teach wherein the recipient device is located at a second location.
However, Xu teaches wherein the recipient device is located at a second location (Xu, [0026]: “Software executing on the server device can cause the message to be transmitted to a designated recipient device, which may be another wearable device, connected device, or the like”, [0027]: “The system includes a wearable device 100, a connected device 102, a server device 104, a map system 106, and a recipient device 108”, [0033]: “the companion application 114 can include functionality for associating ones of the input elements 112 of the wearable device 100 with different events that may occur with respect to the wearable device 100 and/or the user thereof. The companion application 114 can include functionality for differentiating between events that occur with respect to the wearable device 100 and/or the user thereof based on the data generated using the sensors 110 and/or the input elements 112 (e.g., based on associations between aspects thereof and the specific events)”, [0037]: “The recipient device 108 is a computing device not operated by the user of the wearable device 100. The recipient device 108 can be a wearable device, a mobile device, or another computing device. The recipient device 108 can be designated as a recipient of messages generated based on data communicated from the wearable device 100. For example, the companion application 114 executing on the connected device 102 can include functionality for designating the recipient device 108 to receive applicable messages generated by the server device, such as based on an identifier thereof. For example, where the recipient device 108 is a mobile device, the identifier can be a telephone number or email address, such as may be included within an entry in a contact list. In another example, where the recipient device 108 is a wearable device, the companion application 114 can query records available to the server device 104 for an identifier of that wearable device, such as a proprietary identifier”, [0041]: “Data indicative of the event, such as an indication of the fall and geolocation coordinates of the wearable device 100, can be transmitted from the wearable device 100 to the server device 104 via the network 122. The address identification mechanism 116 can use the transmitted geolocation coordinates and the map data 120 from the map system 106 to identify an address-based location of the wearable device 100”, and [0112]: “ The sets of geolocation coordinates of the sequence may reflect different locations of the wearable device, such as where the wearable device has moved since a first determined geolocation coordinate set”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray and Stahman to incorporate the teachings of Xu and account for communicating data to a server, such as to record information received as input from the user thereof or based on the occurrence of an event (Xu, Abstract and [0003]).
Regarding claim 2, Ray teaches the content comprises a recommendation for treating the predicted decompensation event (Ray, [0050]-[0051]: “Application 106 is a mobile health application that is configured to receive and analyze analyte measurements from analyte monitoring system 104. In particular, application 106 stores information about a user, including the user's analyte measurements, in a user profile 118 associated with the user for processing and analysis, as well as for use by decision support engine 114 to provide decision support recommendations or guidance to the user… As discussed in more detail herein, decision support engine 114 may provide decision support recommendations to the user via application 106. Decision support engine 114 provides decision support recommendations based on information included in user profile 118”, [0066]: “to perform analytics thereon for determining the probability of the presence and/or severity of liver disease for the user and providing one or more recommendations for treatment based, at least in part, on the determination”, [0071]-[0072]: “Output 144 generated by decision support engine 114 may also provide one or more recommendations for treatment based on the prediction. Output 144 may be provided to the user (e.g., through application 106), to a user's caretaker (e.g., a parent, a relative, a guardian, a teacher, a nurse, etc.), to a user's physician, or any other individual that has an interest in the wellbeing of the user for purposes of improving the user's health, such as, in some cases by effectuating the recommended treatment”, and [0074]-[0075]).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Regarding claim 3, Ray does not teach the predicted heart failure decompensation event comprises a change in pulmonary pressure.
However, Stahmann teaches the predicted heart failure decompensation event comprises a change in pulmonary pressure (Stahmann, [0162]: “In a second example, a composite parameter indicative of pulmonary vascular resistance (PVR) is generated using an acquired cardiac output parameter (C.O.), a mean pulmonary artery pressure parameter (/PPA), and one of a mean pulmonary capillary wedge pressure parameter (/PCW) and a mean left atrial pressure parameter (/PLA)”, [0168]: “Fluid then continues to be retained, causing the progressive peripheral and pulmonary edema that characterizes overt congestive heart failure”, [0173]: “In one example, fluid in the subject's lungs (i.e., acute pulmonary edema) is used as a CHF physiologic parameter. In one example, acute pulmonary edema is measured by an implantable sensor that senses transthoracic impedance, a low frequency component of which changes with edema status. In another example, acute pulmonary edema is measured on an X-ray by a user, and an indication of the degree of edema is input to CHF parameter input device by the user at external user interface. An increase in pulmonary edema correlates to a future worsening of the subject's CHF status during the predetermined future time period”, and [0200]: “a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Regarding claim 4, Ray further teaches the patient prediction model is a machine learning model (Ray, FIG. 6, [0042]-[0044]: “Output 144 generated by decision support engine 114 may also provide one or more recommendations for treatment based on the prediction. Output 144 may be provided to the user (e.g., through application 106), to a user's caretaker (e.g., a parent, a relative, a guardian, a teacher, a nurse, etc.), to a user's physician, or any other individual that has an interest in the wellbeing of the user for purposes of improving the user's health, such as, in some cases by effectuating the recommended treatment… through the combination of a continuous analyte monitoring system with machine learnings and/or algorithms for diagnosing, staging, and assessing risk of liver disease, the decision support system described herein may provide the necessary accuracy and reliability patients expect. For example, biases, human errors, and emotional influence may be minimized when assessing the presence and severity of liver disease in patients. Further, machine learning models and algorithms in combination with analyte monitoring systems may provide insight into patterns and or trends of decreasing health of a patient, at least with respect to the liver, which may have been previously missed”).
Regarding claim 5, Ray further teaches the current vital sign information comprises heart-related information (Ray, [0038]: “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” and [0091]: “sensor electronics module 204 may also be in communication with other non-analyte sensors 206. Non-analyte sensors 206 may include, but are not limited to, an altimeter sensor, an accelerometer sensor, a temperature sensor, a respiration rate sensor. Non-analyte sensors 206 may also include monitors such as heart rate monitors, blood pressure monitors, pulse oximeters, caloric intake, and medicament delivery devices”).
Regarding claim 7, Ray further teaches the continuous lactate monitoring system comprises a dual-analyte sensor configured to detect lactate and one of glucose, creatinine, or ketones (Ray, FIGS. 9A-9E, FIGS. 12A-12D, [0037]: “For example, the analyte data may include continuously monitored lactate data in addition to other continuously monitored analyte data, such as glucose, ketones, and potassium”, [0046], [0313]: “one example, at least a dual enzyme domain configuration in which each layer contains one or more specific enzymes and optionally one or more cofactors is provided. In a broad sense, one example of a continuous multi-analyte sensor configuration is depicted in FIG. 9A where a first membrane 855 (EZL1) comprising at least one enzyme (Enzyme 1) of the at least two enzyme domain configuration is proximal to at least one surface of a WE”).
Regarding claim 8, Ray further teaches generating the content to include an instruction configured to cause the recipient device to adjust or maintain administration of a dosage of a substance (Ray, [0090]: “As mentioned, 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”).
Regarding claim 9, Ray teaches the content of the notification is determined based on one or more of a time of day, and level of severity of the predicted decompensation event (Ray, [0240], [0285]-[0286], [0294], and [0344]), and wherein identifying the recipient device is based on the one or more of the time of day, and the level of severity of the predicted decompensation event (Ray, [0240], [0285]-[0286], [0294], and [0344]).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Ray and Stahman do not teach a proximity of the recipient device to the patient.
However, Xu teaches a proximity of the recipient device to the patient (Xu, [0026]: “Software executing on the server device can cause the message to be transmitted to a designated recipient device, which may be another wearable device, connected device, or the like”, [0027]: “The system includes a wearable device 100, a connected device 102, a server device 104, a map system 106, and a recipient device 108”, [0033]: “the companion application 114 can include functionality for associating ones of the input elements 112 of the wearable device 100 with different events that may occur with respect to the wearable device 100 and/or the user thereof. The companion application 114 can include functionality for differentiating between events that occur with respect to the wearable device 100 and/or the user thereof based on the data generated using the sensors 110 and/or the input elements 112 (e.g., based on associations between aspects thereof and the specific events)”, [0037]: “The recipient device 108 is a computing device not operated by the user of the wearable device 100. The recipient device 108 can be a wearable device, a mobile device, or another computing device. The recipient device 108 can be designated as a recipient of messages generated based on data communicated from the wearable device 100. For example, the companion application 114 executing on the connected device 102 can include functionality for designating the recipient device 108 to receive applicable messages generated by the server device, such as based on an identifier thereof. For example, where the recipient device 108 is a mobile device, the identifier can be a telephone number or email address, such as may be included within an entry in a contact list. In another example, where the recipient device 108 is a wearable device, the companion application 114 can query records available to the server device 104 for an identifier of that wearable device, such as a proprietary identifier”, [0041]: “Data indicative of the event, such as an indication of the fall and geolocation coordinates of the wearable device 100, can be transmitted from the wearable device 100 to the server device 104 via the network 122. The address identification mechanism 116 can use the transmitted geolocation coordinates and the map data 120 from the map system 106 to identify an address-based location of the wearable device 100”, [0048]: “For example, the server device 104 can include functionality for locating other users of wearable devices that are close in physical proximity to the user of the wearable device 100. For example, after receiving a notification including location data from the wearable device 100 or the connected device 102, the server device 104 can query a database or other data store for recent records of wearable devices based on the location data included in the notification. The server device 104 can then transmit an indication of one or more nearby other users to the wearable device 100 or the connected device 102”, and [0112]: “ The sets of geolocation coordinates of the sequence may reflect different locations of the wearable device, such as where the wearable device has moved since a first determined geolocation coordinate set”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray and Stahman to incorporate the teachings of Xu and account for communicating data to a server, such as to record information received as input from the user thereof or based on the occurrence of an event (Xu, Abstract and [0003]).
Regarding claim 11, Ray further teaches wherein the continuous lactate data comprises a trend in the continuous lactate data (Ray, [0034]: “Such continuous monitoring of analytes is advantageous in diagnosing and staging a disease of a patient given the continuous measurements provide continuously up to date measurements as well as information on the trend and rate of analyte change over a continuous period”) and an absolute value of a lactate value (Ray, [0121]: “Additionally, acute events such as liver decompensation and hypoglycemia in liver disease users, may be identified before severe acute symptoms become overwhelmingly debilitating by measuring rates of changes and absolute levels of insulin, glucose, and lactate in users” and [0155]: “the number of times lactate rates of change (absolute) are above a specified value, and/or information on these values when exercising or not exercising) may similarly be calculated and used to generate a disease prediction or generate a treatment recommendation as discussed relative to block 414 and block 416”).
Regarding claim 13, Ray further teaches the trend is a rate of change of the lactate value over a given time period (Ray, [0121]: “Additionally, acute events such as liver decompensation and hypoglycemia in liver disease users, may be identified before severe acute symptoms become overwhelmingly debilitating by measuring rates of changes and absolute levels of insulin, glucose, and lactate in users” and [0155]: “the number of times lactate rates of change (absolute) are above a specified value, and/or information on these values when exercising or not exercising) may similarly be calculated and used to generate a disease prediction or generate a treatment recommendation as discussed relative to block 414 and block 416”).
Regarding claim 15, Ray teaches the content comprises one or more recommended actions (Ray, [0050]-[0051]: “Application 106 is a mobile health application that is configured to receive and analyze analyte measurements from analyte monitoring system 104. In particular, application 106 stores information about a user, including the user's analyte measurements, in a user profile 118 associated with the user for processing and analysis, as well as for use by decision support engine 114 to provide decision support recommendations or guidance to the user… As discussed in more detail herein, decision support engine 114 may provide decision support recommendations to the user via application 106. Decision support engine 114 provides decision support recommendations based on information included in user profile 118”, [0066]: “to perform analytics thereon for determining the probability of the presence and/or severity of liver disease for the user and providing one or more recommendations for treatment based, at least in part, on the determination”, [0071]-[0072]: “Output 144 generated by decision support engine 114 may also provide one or more recommendations for treatment based on the prediction. Output 144 may be provided to the user (e.g., through application 106), to a user's caretaker (e.g., a parent, a relative, a guardian, a teacher, a nurse, etc.), to a user's physician, or any other individual that has an interest in the wellbeing of the user for purposes of improving the user's health, such as, in some cases by effectuating the recommended treatment”, and [0074]-[0075]), wherein the one or more recommended actions is determined based on one or more of a proximity of recipient device to the patient, time of day, and a level of severity of the predicted decompensation event (Ray, [0051]: “As discussed in more detail herein, decision support engine 114 may provide decision support recommendations to the user via application 106. Decision support engine 114 provides decision support recommendations based on information included in user profile 118.”, [0188]: “As described in more detail below, decision support engine 114 may use this second lactate clearance as a metric for predicting the presence and/or severity of liver disease in the user”, [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)”, [0240], [0285]-[0286], [0294], and [0344]).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Regarding claim 16, Ray teaches the content includes an instruction configured to cause the recipient device to administer an intervention to the patient based on the predicted decompensation event (Ray, [0090]: “As mentioned, 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”).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Regarding claim 18, Ray further teaches the instruction is configured to cause the recipient device to administer an adjusted dosage of a substance (Ray, [0090]: “As mentioned, 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” and [0200]: “Accordingly, in certain embodiments, decision support engine 114, at block 416, may recommend the user stop taking the previously prescribed medication, and in some cases, recommend an alternative medication for consumption by the user. In certain other embodiments, decision support engine 114, at block 416, may recommend the user take a lower dosage of the previously prescribed medication. In certain embodiments, decision support engine 114 may recommend titration of the dosage of the previously prescribed medication to determine an ideal dosage for the user (e.g., while monitoring liver health of the user)”).
Regarding claim 19, Ray teaches an early warning system for predicting a decompensation event associated with a patient in a home setting comprising (Ray, [0215]): a processor configured to be in communication with a continuous lactate monitoring system at a first location associated with the home setting and a plurality of recipient devices (Ray, FIG. 4 and [0215]); and a memory coupled to the processor and storing a patient prediction model and instructions that when executed by the processor cause the processor to: receive continuous lactate data from the continuous lactate monitoring system (Ray, FIG. 4, [0005]: “Lactate is measured and analyzed using various approaches including central laboratory methods, near patient blood gas analysis, and analysis using portable point of care (POC) handheld devices”, [0007]: “For this reason, small hand-held devices, much like glucose meters, have been made available for lactate measuring and analysis. A user may carry a self-monitoring lactate monitor which typically requires the user to prick his or her finger to measure his or her lactate levels”, and [0012]: “FIG. 4 is a flow diagram illustrating an example method for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with some example aspects of the present disclosure”) (a) the continuous lactate data (Ray, FIG. 4, [0005]: “Lactate is measured and analyzed using various approaches including central laboratory methods, near patient blood gas analysis, and analysis using portable point of care (POC) handheld devices”, [0007]: “For this reason, small hand-held devices, much like glucose meters, have been made available for lactate measuring and analysis. A user may carry a self-monitoring lactate monitor which typically requires the user to prick his or her finger to measure his or her lactate levels”, and [0012]: “FIG. 4 is a flow diagram illustrating an example method for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with some example aspects of the present disclosure”) and (b) patient health information (Ray, [0193]: “In certain embodiments, such rules may be determined based on training server system 140 analyzing historical patient records from historical records database 112”) as inputs to a patient prediction model (Ray, [0042]: “As described in more detail herein, the population data may be provided in a form of a dataset including data records of historical patients with varying stages of liver disease. Each data record is then featurized (e.g., refined into a set of one or more features, or predictor variables) and labeled. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning models. In certain embodiments, each data record is labeled with its corresponding liver disease diagnosis, assigned disease score, risk assessment, etc. The features associated with each data record may be used as input into the machine learning models, and the generated output may be compared to label(s) assigned to each of the data records”) to generate a predicted decompensation event (Ray, [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. Early detection of such decompensation and/or other complications may allow for intervention at the earliest possible stage to ultimately improve liver disease outcomes”), wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information (Ray, [0032]: “Physicians use information from a patient's history, physical examination, laboratory findings, and other diagnostic tests to diagnose and stage a disease to prescribe appropriate treatment” and [0054]: “User profile 118 also includes demographic info 120, disease progression info 122, and/or medication info 124. In certain embodiments, such information may be provided through user input or obtained from certain data stores (e.g., electronic medical records (EMRs), etc.). In certain embodiments, demographic info 120 may include one or more of the user's age, body mass index (BMI), ethnicity, gender, etc. In certain embodiments, disease progression info 122 may include information about a disease of a user, such as whether the user has been previously diagnosed with cirrhosis, liver fibrosis, NAFLD, NASH, hepatic ischemia reperfusion injury, primary biliary cholangitis (PBC), primary sclerosing cholangitis (PSC), or whether the user has been previously diagnosed with liver disease caused by viruses, such as hepatitis A, hepatitis B, or hepatitis C. In certain embodiments, information about a user's disease may also include the length of time since diagnosis, the level of disease control, level of compliance with liver disease management therapy, predicted liver function, other types of diagnosis (e.g., heart disease, obesity) or measures of health (e.g., heart rate, exercise, stress, sleep, etc.), and/or the like”); receive, from the patient prediction model, the predicted decompensation event, wherein the predicted decompensation event is determined based on the inputs (Ray, FIG. 6, [0014]: “FIG. 6 is a flow diagram depicting a method for training machine learning models to provide a prediction of liver disease diagnosis, according to certain embodiments of the present disclosure”, [0040]-[0043]: “As described in more detail herein, the population data may be provided in a form of a dataset including data records of historical patients with varying stages of liver disease. Each data record is then featurized (e.g., refined into a set of one or more features, or predictor variables) and labeled. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning models. In certain embodiments, each data record is labeled with its corresponding liver disease diagnosis, assigned disease score, risk assessment, etc. The features associated with each data record may be used as input into the machine learning models, and the generated output may be compared to label(s) assigned to each of the data records. The models may compute a loss based on the difference between the generated output and the provided label. This loss can then be used to modify the internal parameters or weights of the models. By iteratively processing features associated with each data record corresponding to each historical patient, the models may be iteratively refined to generate accurate predictions of liver disease presence and severity in a patient”); identify a recipient device of the plurality of recipient devices to receive a notification based on the predicted decompensation event (Ray, [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 (not shown)” and [0215]: “In certain embodiments, computing device 700 is representative of mobile device 107 associated with the user. In certain embodiments, as discussed above, the mobile device 107 can include the user's laptop, computer, smartphone, and the like. In another embodiment, computing device 700 is a server executing in a cloud environment”); and transmit the notification based on the predicted decompensation event, wherein content of the notification is specific to the recipient device (Ray, FIG. 2, [0048]-[0049]: “continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to an electric medical records (EMR) system and/or an interface engine (not shown in FIG. 1 ). An EMR system is a software platform which allows for the electronic entry, storage, and maintenance of digital medical data. An interface engine is a data synchronization tool to ensure that EMR databases and other systems databases are in sync on a network. An EMR system is generally used throughout hospitals and/or other caregiver facilities to document clinical information on patients over long periods. EMR systems organize and present data in ways that assist clinicians with, for example, interpreting health conditions and providing ongoing care, scheduling, billing, and follow up. Data contained in an EMR system may also be used to create reports for clinical care and/or disease management for a patient… continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to display device 107 for use by application 106. In some embodiments, continuous analyte monitoring system 104 transmits the analyte measurements to display device 107 through a wireless connection (e.g., Bluetooth connection, WiFi connection and/or NFC). The transmission of analyte measurements may be broadcast or on-demand and continuous (e.g., fully continuous, semi-continuous, or periodic). In certain embodiments, display device 107 is a smart phone. However, in certain other embodiments, display device 107 may instead be any other type of computing device such as a laptop computer, a smart watch, a tablet, or any other computing device capable of executing application 106. Continuous analyte monitoring system 104 may be described in more detail with respect to FIG. 2”).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]). It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Ray and Stahman do not teach wherein the recipient device is located at a second location.
However, Xu teaches wherein the recipient device is located at a second location (Xu, [0026]: “Software executing on the server device can cause the message to be transmitted to a designated recipient device, which may be another wearable device, connected device, or the like”, [0027]: “The system includes a wearable device 100, a connected device 102, a server device 104, a map system 106, and a recipient device 108”, [0033]: “the companion application 114 can include functionality for associating ones of the input elements 112 of the wearable device 100 with different events that may occur with respect to the wearable device 100 and/or the user thereof. The companion application 114 can include functionality for differentiating between events that occur with respect to the wearable device 100 and/or the user thereof based on the data generated using the sensors 110 and/or the input elements 112 (e.g., based on associations between aspects thereof and the specific events)”, [0037]: “The recipient device 108 is a computing device not operated by the user of the wearable device 100. The recipient device 108 can be a wearable device, a mobile device, or another computing device. The recipient device 108 can be designated as a recipient of messages generated based on data communicated from the wearable device 100. For example, the companion application 114 executing on the connected device 102 can include functionality for designating the recipient device 108 to receive applicable messages generated by the server device, such as based on an identifier thereof. For example, where the recipient device 108 is a mobile device, the identifier can be a telephone number or email address, such as may be included within an entry in a contact list. In another example, where the recipient device 108 is a wearable device, the companion application 114 can query records available to the server device 104 for an identifier of that wearable device, such as a proprietary identifier”, [0041]: “Data indicative of the event, such as an indication of the fall and geolocation coordinates of the wearable device 100, can be transmitted from the wearable device 100 to the server device 104 via the network 122. The address identification mechanism 116 can use the transmitted geolocation coordinates and the map data 120 from the map system 106 to identify an address-based location of the wearable device 100”, and [0112]: “ The sets of geolocation coordinates of the sequence may reflect different locations of the wearable device, such as where the wearable device has moved since a first determined geolocation coordinate set”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray and Stahman to incorporate the teachings of Xu and account for communicating data to a server, such as to record information received as input from the user thereof or based on the occurrence of an event (Xu, Abstract and [0003]).
Regarding claim 20, Ray teaches a non-transitory, tangible computer-readable medium having instructions stored thereon that, when executed by at least one computing device in an early warning system configured to predict a decompensation event associated with a patient in a home setting, cause a processor of the at least one computing device to perform operations comprising (Ray, [0215]): receiving, by the processor, continuous lactate data from a continuous lactate monitoring system (Ray, FIG. 4, [0005]: “Lactate is measured and analyzed using various approaches including central laboratory methods, near patient blood gas analysis, and analysis using portable point of care (POC) handheld devices”, [0007]: “For this reason, small hand-held devices, much like glucose meters, have been made available for lactate measuring and analysis. A user may carry a self-monitoring lactate monitor which typically requires the user to prick his or her finger to measure his or her lactate levels”, and [0012]: “FIG. 4 is a flow diagram illustrating an example method for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with some example aspects of the present disclosure”), wherein the early warning system is configured to communicate with the continuous lactate monitoring system located at a first location associated with the home setting and with a plurality of recipient devices (Ray, FIG. 4, [0135]: “FIG. 4 is a flow diagram illustrating example method 400 for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with certain example aspects of the present disclosure… Method 400 may be performed by decision support system 100 to collect data, including for example, analyte data, patient information, and non-analyte 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, 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”, [0155]: “At block 406, method 400 continues by processing the analyte data from the first time period to determine at least one lactate clearance rate. Block 406, in certain embodiments, may be performed by decision support engine 114”); providing, by the processor, (a) the continuous lactate data (Ray, FIG. 4, [0005]: “Lactate is measured and analyzed using various approaches including central laboratory methods, near patient blood gas analysis, and analysis using portable point of care (POC) handheld devices”, [0007]: “For this reason, small hand-held devices, much like glucose meters, have been made available for lactate measuring and analysis. A user may carry a self-monitoring lactate monitor which typically requires the user to prick his or her finger to measure his or her lactate levels”, and [0012]: “FIG. 4 is a flow diagram illustrating an example method for providing decision support using a continuous analyte sensor including, at least, a continuous lactate sensor, in accordance with some example aspects of the present disclosure”) and (b) patient health information (Ray, [0193]: “In certain embodiments, such rules may be determined based on training server system 140 analyzing historical patient records from historical records database 112”) as inputs to a patient prediction model (Ray, [0042]: “As described in more detail herein, the population data may be provided in a form of a dataset including data records of historical patients with varying stages of liver disease. Each data record is then featurized (e.g., refined into a set of one or more features, or predictor variables) and labeled. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning models. In certain embodiments, each data record is labeled with its corresponding liver disease diagnosis, assigned disease score, risk assessment, etc. The features associated with each data record may be used as input into the machine learning models, and the generated output may be compared to label(s) assigned to each of the data records”) to generate a predicted decompensation event (Ray, [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. Early detection of such decompensation and/or other complications may allow for intervention at the earliest possible stage to ultimately improve liver disease outcomes”), wherein the patient health information comprises one or more of patient procedure history, patient medical history, or current vital sign information (Ray, [0032]: “Physicians use information from a patient's history, physical examination, laboratory findings, and other diagnostic tests to diagnose and stage a disease to prescribe appropriate treatment” and [0054]: “User profile 118 also includes demographic info 120, disease progression info 122, and/or medication info 124. In certain embodiments, such information may be provided through user input or obtained from certain data stores (e.g., electronic medical records (EMRs), etc.). In certain embodiments, demographic info 120 may include one or more of the user's age, body mass index (BMI), ethnicity, gender, etc. In certain embodiments, disease progression info 122 may include information about a disease of a user, such as whether the user has been previously diagnosed with cirrhosis, liver fibrosis, NAFLD, NASH, hepatic ischemia reperfusion injury, primary biliary cholangitis (PBC), primary sclerosing cholangitis (PSC), or whether the user has been previously diagnosed with liver disease caused by viruses, such as hepatitis A, hepatitis B, or hepatitis C. In certain embodiments, information about a user's disease may also include the length of time since diagnosis, the level of disease control, level of compliance with liver disease management therapy, predicted liver function, other types of diagnosis (e.g., heart disease, obesity) or measures of health (e.g., heart rate, exercise, stress, sleep, etc.), and/or the like”); receiving, by the processor from the patient prediction model, the predicted decompensation event, wherein the predicted decompensation event is generated based on the inputs (Ray, FIG. 6, [0014]: “FIG. 6 is a flow diagram depicting a method for training machine learning models to provide a prediction of liver disease diagnosis, according to certain embodiments of the present disclosure”, [0040]-[0043]: “As described in more detail herein, the population data may be provided in a form of a dataset including data records of historical patients with varying stages of liver disease. Each data record is then featurized (e.g., refined into a set of one or more features, or predictor variables) and labeled. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning models. In certain embodiments, each data record is labeled with its corresponding liver disease diagnosis, assigned disease score, risk assessment, etc. The features associated with each data record may be used as input into the machine learning models, and the generated output may be compared to label(s) assigned to each of the data records. The models may compute a loss based on the difference between the generated output and the provided label. This loss can then be used to modify the internal parameters or weights of the models. By iteratively processing features associated with each data record corresponding to each historical patient, the models may be iteratively refined to generate accurate predictions of liver disease presence and severity in a patient”); identifying, by the processor, a recipient device of the plurality of recipient devices to receive a notification based on the predicted decompensation event (Ray, [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 (not shown)” and [0215]: “In certain embodiments, computing device 700 is representative of mobile device 107 associated with the user. In certain embodiments, as discussed above, the mobile device 107 can include the user's laptop, computer, smartphone, and the like. In another embodiment, computing device 700 is a server executing in a cloud environment”); and transmitting the notification based on the predicted decompensation event, wherein content of the notification comprises is specific to the recipient device (Ray, FIG. 2, [0048]-[0049]: “continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to an electric medical records (EMR) system and/or an interface engine (not shown in FIG. 1 ). An EMR system is a software platform which allows for the electronic entry, storage, and maintenance of digital medical data. An interface engine is a data synchronization tool to ensure that EMR databases and other systems databases are in sync on a network. An EMR system is generally used throughout hospitals and/or other caregiver facilities to document clinical information on patients over long periods. EMR systems organize and present data in ways that assist clinicians with, for example, interpreting health conditions and providing ongoing care, scheduling, billing, and follow up. Data contained in an EMR system may also be used to create reports for clinical care and/or disease management for a patient… continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to display device 107 for use by application 106. In some embodiments, continuous analyte monitoring system 104 transmits the analyte measurements to display device 107 through a wireless connection (e.g., Bluetooth connection, WiFi connection and/or NFC). The transmission of analyte measurements may be broadcast or on-demand and continuous (e.g., fully continuous, semi-continuous, or periodic). In certain embodiments, display device 107 is a smart phone. However, in certain other embodiments, display device 107 may instead be any other type of computing device such as a laptop computer, a smart watch, a tablet, or any other computing device capable of executing application 106. Continuous analyte monitoring system 104 may be described in more detail with respect to FIG. 2”).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Ray and Stahman do not teach to the recipient device at the second location and wherein the recipient device is located at a second location.
However, Xu teaches to the recipient device at the second location and wherein the recipient device is located at a second location (Xu, [0026]: “Software executing on the server device can cause the message to be transmitted to a designated recipient device, which may be another wearable device, connected device, or the like”, [0027]: “The system includes a wearable device 100, a connected device 102, a server device 104, a map system 106, and a recipient device 108”, [0033]: “the companion application 114 can include functionality for associating ones of the input elements 112 of the wearable device 100 with different events that may occur with respect to the wearable device 100 and/or the user thereof. The companion application 114 can include functionality for differentiating between events that occur with respect to the wearable device 100 and/or the user thereof based on the data generated using the sensors 110 and/or the input elements 112 (e.g., based on associations between aspects thereof and the specific events)”, [0037]: “The recipient device 108 is a computing device not operated by the user of the wearable device 100. The recipient device 108 can be a wearable device, a mobile device, or another computing device. The recipient device 108 can be designated as a recipient of messages generated based on data communicated from the wearable device 100. For example, the companion application 114 executing on the connected device 102 can include functionality for designating the recipient device 108 to receive applicable messages generated by the server device, such as based on an identifier thereof. For example, where the recipient device 108 is a mobile device, the identifier can be a telephone number or email address, such as may be included within an entry in a contact list. In another example, where the recipient device 108 is a wearable device, the companion application 114 can query records available to the server device 104 for an identifier of that wearable device, such as a proprietary identifier”, [0041]: “Data indicative of the event, such as an indication of the fall and geolocation coordinates of the wearable device 100, can be transmitted from the wearable device 100 to the server device 104 via the network 122. The address identification mechanism 116 can use the transmitted geolocation coordinates and the map data 120 from the map system 106 to identify an address-based location of the wearable device 100”, and [0112]: “ The sets of geolocation coordinates of the sequence may reflect different locations of the wearable device, such as where the wearable device has moved since a first determined geolocation coordinate set”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray and Stahman to incorporate the teachings of Xu and account for communicating data to a server, such as to record information received as input from the user thereof or based on the occurrence of an event (Xu, Abstract and [0003]).
Regarding claim 21, Ray teaches the early warning system is communicatively coupled to at least one of an accelerometer and an altimeter (Ray, [0091]: “Non-analyte sensors 206 may include, but are not limited to, an altimeter sensor, an accelerometer sensor, a temperature sensor, a respiration rate sensor”), the method further comprising: receiving, from the at least of the accelerometer and the altimeter, patient activity information (Ray, [0091]: “Further, as mentioned, sensor electronics module 204 may also be in communication with other non-analyte sensors 206. Non-analyte sensors 206 may include, but are not limited to, an altimeter sensor, an accelerometer sensor, a temperature sensor, a respiration rate sensor. Non-analyte sensors 206 may also include monitors such as heart rate monitors, blood pressure monitors, pulse oximeters, caloric intake, and medicament delivery devices. One or more of these non-analyte sensors 206 may provide data to decision support engine 114 described further below. In some aspects, a user may manually provide some of the data for processing by training server system 140 and/or decision support engine 114 of FIG. 1”, and [0099]: “Exercise information may be any information surrounding activities requiring physical exertion by the user. For example, exercise information may range from information related to low intensity (e.g., walking) and high intensity (e.g., sprinting) physical exertion. In certain embodiments, exercise information may be provided, for example, by an accelerometer sensor on a wearable device such as a watch, fitness tracker, and/or patch. In certain embodiments, exercise information may also be provided through manual user input and/or through a surrogate sensor and prediction algorithm measuring changes to heart rate (or other cardiac metrics)”); determining that a period of time for the patient activity information corresponds to a period of time associated with the predicted decompensation event (Ray, [0110]: “DAM 116 may first identify which measured lactate values are to be used for calculating the baseline lactate by identifying lactate values that may have been affected by an external event, such the consumption of food, exercise, medication, or other perturbation that would disrupt the capture of a lactate baseline measurement”); and updating, by the processor, the predicted decompensation event based on the patient activity information (Ray, [0035]: “A single point in time reading may be influenced by a patient's activity, such as exercise or diet changes near or during the point in time”, [0099]: “Exercise information may be any information surrounding activities requiring physical exertion by the user”, [0120], and [0131]-[0133]).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]). It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Regarding claim 22, Ray further teaches the predicted patient model is selected from a plurality of patient prediction models, and wherein the selecting is performed in response to receiving the patient health information (Ray, [0069]: “Generally, the features that best characterize the patterns in the data are selected to create predictive machine learning models. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning model”).
Regarding claim 23, Ray teaches based on a level of severity of the predicted decompensation event (Ray, [0040]: “For example, certain aspects are directed to algorithms and/or machine-learning models designed to assess the presence and severity of liver disease in a patient”, [0041]: “Based on these parameters, 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”, and [0043]: “By iteratively processing features associated with each data record corresponding to each historical patient, the models may be iteratively refined to generate accurate predictions of liver disease presence and severity in a patient”).
Although Ray teaches a liver decompensation event, Ray does not teach heart failure decompensation event.
However, Stahmann teaches heart failure decompensation event (Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray to incorporate the teachings of Stahman and account for appropriately process the large amount of sensed data to provide meaningful information, providing and reporting meaningful data, and provide an accurate indication of the overall health of the patient (Stahmann, Abstract and [0006]).
Ray and Stahman do not teach to identifying the recipient device.
However, Xu teaches identifying the recipient device (Xu, [0026]: “Software executing on the server device can cause the message to be transmitted to a designated recipient device, which may be another wearable device, connected device, or the like”, [0027]: “The system includes a wearable device 100, a connected device 102, a server device 104, a map system 106, and a recipient device 108”, [0033]: “the companion application 114 can include functionality for associating ones of the input elements 112 of the wearable device 100 with different events that may occur with respect to the wearable device 100 and/or the user thereof. The companion application 114 can include functionality for differentiating between events that occur with respect to the wearable device 100 and/or the user thereof based on the data generated using the sensors 110 and/or the input elements 112 (e.g., based on associations between aspects thereof and the specific events)”, [0037]: “The recipient device 108 is a computing device not operated by the user of the wearable device 100. The recipient device 108 can be a wearable device, a mobile device, or another computing device. The recipient device 108 can be designated as a recipient of messages generated based on data communicated from the wearable device 100. For example, the companion application 114 executing on the connected device 102 can include functionality for designating the recipient device 108 to receive applicable messages generated by the server device, such as based on an identifier thereof. For example, where the recipient device 108 is a mobile device, the identifier can be a telephone number or email address, such as may be included within an entry in a contact list. In another example, where the recipient device 108 is a wearable device, the companion application 114 can query records available to the server device 104 for an identifier of that wearable device, such as a proprietary identifier”, [0041]: “Data indicative of the event, such as an indication of the fall and geolocation coordinates of the wearable device 100, can be transmitted from the wearable device 100 to the server device 104 via the network 122. The address identification mechanism 116 can use the transmitted geolocation coordinates and the map data 120 from the map system 106 to identify an address-based location of the wearable device 100”, and [0112]: “ The sets of geolocation coordinates of the sequence may reflect different locations of the wearable device, such as where the wearable device has moved since a first determined geolocation coordinate set”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Ray and Stahman to incorporate the teachings of Xu and account for communicating data to a server, such as to record information received as input from the user thereof or based on the occurrence of an event (Xu, Abstract and [0003]).
Regarding claim 24, Ray further teaches the continuous lactate data comprises a cumulative sum of lactate levels of a period of time (Ray, [0109], [0110]: “a user's lactate baseline may be determined by calculating an average lactate levels over a specified amount of time where fluctuations are not expected”, [0155], [0165]-[0167]: “At block 508, decision support engine 114 determines an amount of time it takes for the peak lactate value of each of the two identified periods to reduce to a baseline lactate level of the user. As mentioned with respect to FIG. 3 , a baseline lactate level may be indicative of the user's normal lactate values while the user is at rest (e.g., sedentary). Assuming a baseline lactate level of the user is 2 mmol/L, decision support system 100 may determine an amount of time it takes measured lactate levels to reach 2 mmol/L after peak lactate concentrations of 8 mmol/L and 5 mmol/L”, and Claim 13).
Response to Arguments
Applicant's arguments filed 03/25/2026 have been fully considered but they are not persuasive. Regarding the 35 U.S.C. 101 Rejection, Applicant argues the judicial exception is integrated into a practical application because the claims recite an improved architecture that integrates a machine learning modeling into an early warning system and includes a unique and non-generic arrangement of components. Examiner respectfully disagrees. The claims still recite an abstract idea as a certain method of organizing human activity (see MPEP 2106.04(a)(2) states “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”. Additionally, the computer components (i.e., early warning system, processor, prediction model, etc.) are recited at a high level such that amount to computer tools and merely apply/link to the judicial exception (see MPEP 2106.05(f) states “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)” and MPEP 2106.05(a) states “Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology.” And improvement to the technology/technical field should improve the function of a computer, however, MPEP2106.05(a) states “If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology”.
Applicant argues the claim is eligible similar to Ex parte Desjardins, hereinafter Desjardins. Examiner respectfully disagrees. Desjardins was eligible because the improvement to the machine learning model by allowing the model to learn new tasks successively while protecting the knowledge of prior tasks, thus changing how the machine learning model operates. The current claims do not recite such improvements to the prediction model. Instead, the prediction model is used in an ordinary capacity that does not perform task completion and task remembrance as in Desjardins. Therefore, the 35 U.S.C. 101 Rejection is maintained.
Regarding the 35 U.S.C. 102 Rejection, Applicant argues the amendments to the claims such as, “a heart failure decompensation event… determined based on [] inputs” to a patient prediction model is not taught by the prior art. Although, the prior art, Ray, does not teach “heart decompensation event”, Ray does teach “liver decompensation event” (see Ray, paragraph [0121]: “Additionally, acute events such as liver decompensation and hypoglycemia in liver disease users, may be identified before severe acute symptoms become overwhelmingly debilitating by measuring rates of changes and absolute levels of insulin, glucose, and lactate in users” and [0127]: “decision support engine 114 may use a MELD score (or other liver disease metric/score) in combination with lactate data (or other analyte data) to predict liver disease progression and liver decompensation”). However, the new 35 U.S.C. 103 Rejection, teaches the amendment of “heart failure decompensation event” (see Stahmann, FIG. 27-28, [0200]: “If the device has a thoracic impedance sensor for measuring minute ventilation, a parameter related to the frequency of decompensation events may be obtained by detecting pulmonary congestion”, [0203]-[0204]). Therefore, the prior art rejection (35 U.S.C. 103) is maintained.
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.
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