Patent Application
20210241916
The following commonly assigned U.S. Patent Applications are incorporated herein by reference in their entireties:
U.S. Patent Application Publication No. 2020/0077931, entitled “FORECASTING BLOOD GLUCOSE CONCENTRATION.”
U.S. Patent Application Publication No. 2020/0375549, entitled “SYSTEMS FOR BIOMONITORING AND BLOOD GLUCOSE FORECASTING, AND ASSOCIATED METHODS.”
This disclosure relates generally to data processing and, in particular, to systems and methods for forecasting and/or explaining health metrics of a user.
Health of a human being may be assessed using various metrics, such as weight, blood pressure, blood glucose levels, or cholesterol levels. These metrics may be indicative of medical conditions, such as hypertension, diabetes, or prediabetes. Various programs exist to assist individuals in making behavioral changes to improve health metrics, such as by lowering their blood pressure, blood glucose concentration, or weight. However, significant and lasting improvements in these metrics may take weeks or even months to achieve. During that time, individuals may not know if their efforts are likely to succeed, and that uncertainty may reduce their motivation to make long-term behavioral changes. Additionally, it may be difficult for individuals to determine what kinds of behavioral changes are likely to produce significant improvements in health metrics.
Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale. Instead, emphasis is placed on illustrating clearly the principles of the present disclosure. The drawings should not be taken to limit the disclosure to the specific embodiments depicted, but are for explanation and understanding only.
The present technology generally relates to systems and methods for forecasting, explaining, and/or interpreting various health metrics, including, for example, blood pressure, blood glucose values (e.g., long term average blood glucose values), weight values, and/or other measurements of a user's health state. In some embodiments, for example, a method for forecasting a health metric of a user includes receiving health data of the user (e.g., blood pressure data, blood glucose data, heart rate data, weight data, etc.), and determining a plurality of features from the health data. The features can be categorized into a plurality of feature groups, each feature group associated with a health factor (e.g., blood pressure, blood glucose, weight, diet, activity, demographics, etc.). The method can further include generating a prediction of the health metric by inputting the features into a prediction model (e.g., a machine learning model trained on data from many different individuals). The prediction can provide an estimated probability that the user's health metric will achieve a target value and/or be within a target range at a future time period (e.g., one, two, three, four, five, six, or more months in the future).
The present technology can also assist the user in making lifestyle changes by predicting which health factors are likely to significantly influence the health metric. In some embodiments, the method further includes determining a contribution of each feature group to the prediction of the health metric (e.g., using an explanation model and/or attribution algorithm). Subsequently, the method can include outputting a notification to the user including the prediction and at least one health factor associated with the feature group(s) determined to have contributed to the prediction (e.g., the feature group having the greatest contribution to the prediction). The present technology can provide accurate, long-term forecasts of many different types of health metrics, which can be beneficial in helping users monitor and/or predict their progress towards their health goals. The present technology can also guide, motivate, and/or otherwise assist the user in improving their health by predicting which health factors are most likely to contribute to significant and lasting changes in health metrics.
As used herein, the term “health metrics” encompasses any measure relevant to a user's health state, including, but not limited to, measurements and/or estimates of any of the following: blood pressure, blood glucose (e.g., blood glucose levels and/or time-in-range values), weight, body mass index (BMI), waist circumference, body fat percentage, cholesterol, triglycerides, heart rate, respiratory rate, body temperature, gases (e.g., oxygen, carbon dioxide), electrolytes (e.g., bicarbonate, potassium, sodium, magnesium, chloride, lactic acid), blood urea nitrogen (BUN), creatinine, ketones, alcohols, neurotransmitters, amino acids, hormones, disease biomarkers (e.g., cancer biomarkers, cardiovascular disease biomarkers), and/or combinations thereof. Such health metrics may also be interchangeably referred to herein as “metabolic metric data,” “metabolic health metrics,” “metabolic metrics,” “metric data,” and/or “metrics.”
The headings provided herein are for convenience only and are not intended to limit or interpret the scope or meaning of the technology.
A person's health can be assessed using various health metrics, such as weight, blood pressure, blood glucose levels, cholesterol levels, and many others. One or more of these metrics may be indicative of health conditions (e.g., hypertension, diabetes, prediabetes, etc.) that would benefit from medical treatment, lifestyle changes, etc. For example, diabetes mellitus (DM) is a group of metabolic disorders characterized by high blood glucose levels over a prolonged period. Typical symptoms of such conditions include frequent urination, increased thirst, increased hunger, etc. If left untreated, diabetes can cause many complications. There are three main types of diabetes: Type 1 diabetes, Type 2 diabetes, and gestational diabetes. Type 1 diabetes results from the pancreas' failure to produce enough insulin. In Type 2 diabetes, cells fail to respond to insulin properly. Gestational diabetes occurs when pregnant women without a previous history of diabetes develop high blood glucose levels.
Diabetes affects a significant percentage of the world's population. Timely and proper diagnoses and treatment are essential to maintaining a relatively healthy lifestyle for individuals with diabetes. Application of treatment typically relies on accurate determination of glucose concentration in the blood of an individual at a present time and/or in the future. However, conventional blood glucose monitoring systems may be unable to provide real-time analytics, personalized analytics, or blood glucose concentration forecasting, or may not provide such information in a rapid, reliable, and accurate manner.
Prediabetes is a serious medical condition characterized by higher than normal blood sugar levels that are not yet high enough to be diagnosed as Type 2 diabetes. With prediabetes, the cells in the body do not respond normally to insulin, which causes the pancreas to produce more insulin to try to elicit the appropriate response. Eventually, however, the pancreas is unable to keep up and blood glucose levels rise, causing prediabetes and, later on, Type 2 diabetes. Typically, prediabetes may go undetected until occurrence of serious health problems, e.g., Type 2 diabetes. There are several risk factors that are associated with prediabetes: being overweight, being 45 years or older, having a family history of Type 2 diabetes, being physically inactive, having gestational diabetes (diabetes during pregnancy), giving birth to a baby who weighed more than 9 pounds, having polycystic ovary syndrome, and others. Various lifestyle, diet, habit, and/or other changes may be helpful in dealing with prediabetes and/or eventual Type 2 diabetes.
As stated above, assessment of whether a person has diabetes and/or prediabetes may begin with measuring the person's blood glucose concentration, which is typically measured in milligrams per deciliter (mg/dL). As blood glucose values can vary during the day, especially in individuals with diabetes, average blood glucose values are generally used to assess long term progress. Average blood glucose values can be estimated directly as the average of many instantaneous measurements over a time period (e.g., a month or more). Alternatively or in combination, HbA1c, a measure of the amount of glycation of red blood cells, which is generally proportional to average blood glucose concentration, is also commonly used.
Hypertension, which is sometimes referred to as high blood pressure, is a long-term medical condition where the blood pressure in an individual's arteries is constantly elevated. Long-term high blood pressure is considered a major risk factor for coronary artery disease, stroke, heart failure, atrial fibrillation, peripheral arterial disease, vision loss, chronic kidney disease, dementia, and other serious medical conditions. There are several factors that increase likelihood of high blood pressure. Some of these include lifestyle factors, e.g., excess use of salt in a diet, excess body weight, smoking, alcohol use, etc. Others include identifiable causes, such as serious medical conditions, e.g., chronic kidney disease, narrowing of the kidney arteries, an endocrine disorder, etc.
Blood pressure can be measured using systolic and diastolic pressures corresponding to maximum and minimum pressures, respectively. For most adults, normal resting blood pressure is in a range of 100-130 millimeters mercury (mmHg) systolic and 60-80 mmHg diastolic. Consistent measurements of blood pressure above these ranges may be considered high blood pressure. Normal and high blood pressure ranges for children may be different.
Treatment of diseases and/or conditions such as high blood pressure, diabetes or prediabetes, etc., may prevent or mitigate detrimental effects on the person's health and/or reduce the risk of developing more serious medical conditions. In some embodiments, the individual may respond to a combination of medicine, lifestyle changes, or both. Lifestyle changes may include, for example, weight loss, physical exercise, decreased salt intake, decreased alcohol intake, a healthier diet, etc. However, it may take weeks or months before meaningful changes become evident (e.g., based on heart function data, etc.), and individuals may lose motivation if they are uncertain whether their lifestyle changes are having any meaningful impact on their health. Accordingly, there is a need for improved systems and methods that forecast future changes in the user's health metrics and/or provide explanations for changes in the health metrics to guide users in reaching their health goals.
In some embodiments, for example, the present technology relates to a computer-implemented method for forecasting and interpreting one or more metabolic health metrics for a user. The method may include determining features (e.g., input data parameters) for training a forecasting data model, training the model, generating predictions of one or more of health metrics (e.g., average blood pressure, average blood glucose, weight, etc.), determining confidence intervals for the predictions, determining a probability of reaching a goal (e.g., a target value of one or more metabolic health metric), combining forecasting data, confidence intervals and the determined probability for display to a user, and interpreting the forecasted data, e.g., to provide feedback to the user.
In some embodiments, the present technology provides a computing system and/or framework for performing such determining, forecasting and/or interpretation of health metric data related to the user. The health metric data may include, for example, blood pressure data, blood glucose concentration (e.g., average, standalone, etc.) data, weight data, etc. and/or any combination thereof.
Non-transitory computer program products (i.e., physically embodied computer program products) are also described that store instructions, which when executed by one or more data processors of one or more computing systems, causes at least one data processor to perform the operations disclosed herein. Similarly, computer systems are also described that may include one or more data processors and memory coupled to the one or more data processors. The memory may temporarily or permanently store instructions that cause at least one processor to perform one or more of the operations described herein. In addition, methods may be implemented by one or more data processors either within a single computing system or distributed among two or more computing systems. Such computing systems may be connected and may exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc.
The details of one or more variations of the present technology described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims.
In some embodiments, the system 102 receives input data from one or more user devices 104. The user devices 104 can be any device associated with a user or patient, and can be used to obtain health metric data (e.g., blood pressure data, blood glucose data, weight data) and/or any other relevant input data (e.g., food data, medication data, physical activity data, sleep data, demographic data, etc.) relating to the user and/or any other users (e.g., appropriately anonymized patient data). In the illustrated embodiment, for example, the user devices 104 include at least one biosensor 104a (e.g., a sensor for obtaining user data), at least one mobile device 104b (e.g., a smartphone or tablet computer), and, optionally, at least one wearable device 104c (e.g., a smartwatch or fitness tracker). In other embodiments, however, one or more of the devices 104a-c can be omitted and/or other types of user devices can be included (e.g., computing devices such as personal computers, laptop computers, etc.). Additionally, although
The biosensor(s) 104a can include any device capable of obtaining user health data, such as implanted sensors, non-implanted sensors, invasive sensors, minimally invasive sensors, non-invasive sensors, wearable sensors, etc. In some embodiments, the biosensor(s) 104a are configured to monitor and/or analyze one or more of the following: body fluids (e.g., blood, interstitial fluid, sweat, etc.), tissue (e.g., optical characteristics of body structures, anatomical features, skin, etc.), and/or vitals (e.g., heat rate, blood pressure, etc.). For example, the biosensor(s) 104a can include at least one blood pressure sensor configured to obtain blood pressure measurements of the user, using any suitable technique known to those of skill in the art. As another example, the biosensor(s) 104a can include at least one sensor configured to analyze body fluids (e.g., blood, interstitial fluid, sweat, etc.) from the user to determine levels of an analyte in the body fluid, such as blood glucose levels. In some embodiments, the biosensor(s) 104a can include at least blood glucose sensor, such as a continuous glucose monitoring (CGM) sensor.
The monitoring performed by the biosensor(s) 104a can be performed continuously, periodically, or a suitable combination thereof. For example, the biosensor(s) 104a can obtain user data at any suitable time interval, such as every minute, 2 minutes, 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 60 minutes, 2 hours, 12 hours, 24 hours, 48 hours, etc. In some embodiments, the time interval is within a range from 5 minutes to 10 minutes. Optionally, the biosensor(s) 104a can include other capabilities, such as processing, transmitting, receiving, and/or other computing capabilities.
The user devices 104 can also include one or more devices that allow for entry of additional types of data, such as meal or nutrition data (e.g., number of meals; timing of meals; number of calories; amount of carbohydrates, fats, sugars, etc.), medical history or other data (e.g., current and/or previous weight, height, BMI, age, sleeping patterns, medical conditions, cholesterol levels, diabetes type, family history, user health history, diagnoses, blood pressure, etc.), physical activity and/or exercise data (e.g., time and/or duration of activity; activity type such as walking, running, swimming; strenuousness of the activity such as low, moderate, high; etc.), personal data (e.g., name, gender, demographics, social network information, etc.), medication data (e.g., timing and/or dosages of medications such as insulin, prescription and/or non-prescription medications taken), blood glucose data (e.g., current and/or previous blood glucose measurements, current and/or previous HbA1c data values), and/or any other data, and/or any combination thereof.
In some embodiments, one or more of the user devices 104 can be configured to obtain other physiological data of the user, such as cardiovascular data, respiratory data, body temperature data (e.g., skin temperature data), sleep data, stress level data (e.g., cortisol and/or other chemical indicators of stress levels), a1c data, biomarker data (e.g., for other diseases or conditions), energy consumption data, oxygen consumption data, and/or data of any other suitable physiological parameters. For example, cardiovascular data can include any physiological parameter related to the user's cardiovascular health, such as blood pressure data, heart rate data, arrhythmia event data (if any), pacemaker data, etc. In some embodiments, the cardiovascular data can be the “most recent” data, e.g., data taken within the last minute, 2 minutes, 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 60 minutes, 2 hours, etc. For example, the blood pressure data can include systolic and/or diastolic blood pressure measurement(s) of the user.
In some embodiments, some or all of the user devices 104 are configured to continuously obtain any of the above data (including blood pressure data, blood glucose data, health data, etc.) from the user over a particular time period (e.g., hours, days, weeks, months, years). For example, data can be obtained at a predetermined time interval (e.g., once every minute, 2 minutes, 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 60 minutes, 2 hours, 12 hours, 24 hours, 48 hours, etc.), at random time intervals, or combinations thereof. The time interval for data collection can be set by the user, by another user (e.g., a physician), by the system 102, or by the user device 104 itself (e.g., as part of an automated data collection program). The user device 104 can obtain the data automatically or semi-automatically (e.g., by automatically prompting the user to provide such data at a particular time), or from manual input by the user (e.g., without prompts from the user device 104). In some embodiments, data may be provided to the system 102 at predetermined time intervals (e.g., once every minute, 2 minutes, 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 60 minutes, 2 hours, etc.), continuously, in real-time, upon receiving a query, manually, automatically (e.g., upon detection of new data), semi-automatically, etc. The time interval at which the user device 104 obtains data may or may not be the same as the time interval at which the user device 104 transmits the data to the system 102.
The user devices 104 can obtain any of the above data in various ways, such as using one or more of the following components: a microphone (e.g., a separate microphone or a microphone imbedded in the device), a speaker, a screen (e.g., using a touchscreen, a stylus pen, and/or in any other fashion), a keyboard, a mouse, a camera, a camcorder, a telephone, a smartphone, a tablet computer, a personal computer, a laptop computer, a sensor (e.g., a sensor included in or operably coupled to the user device 104), and/or any other device. The data obtained by the user devices 104 can include metadata, structured content data, unstructured content data, embedded data, nested data, hard disk data, memory card data, cellular telephone memory data, smartphone memory data, main memory images and/or data, forensic containers, zip files, files, memory images, and/or any other data/information. The data can be in various formats, such as text, numerical, alpha-numerical, hierarchically arranged data, table data, email messages, text files, video, audio, graphics, etc. Optionally, any of the above data can be filtered, smoothed, augmented, annotated, or otherwise processed (e.g., by the user devices 104 and/or the system 102) before being used for analysis and/or forecasting, as described in greater detail below. Alternatively, the user devices 104 can transmit raw data directly to the system 102, and the system 102 can process the raw data for use in the operations described herein.
In some embodiments, any of the above data can be queried by one or more of the user devices 104 from one or more databases (e.g., the database 106, a third-party database, etc.). The user device 104 can generate a query and transmit the query to the system 102, which can determine which database may contain requisite information and then connect with that database to execute a query and retrieve appropriate information. In other embodiments, the user device 104 can receive the data directly from the third-party database and transmit the received data to the system 102, or can instruct the third-party database to transmit the data to the system 102. In some embodiments, the system 102 can include various application programming interfaces (APIs) and/or communication interfaces that can allow interfacing between user devices 104, databases, and/or any other components.
Optionally, the system 102 can also obtain any of the above data from various third party sources, e.g., with or without a query initiated by a user device 104. In some embodiments, the system 102 can be communicatively coupled to various public and/or private databases that can store various information, such as census information, health statistics (e.g., appropriately anonymized), demographic information, population information, and/or any other information. For example, the system 102 can obtain information about health metrics such as blood pressure levels and/or forecasts of blood pressure levels of a plurality of users (e.g., without identifying the users) of the system 102, nutrition data relating to such users, exercise data, social network information, and/or any other information and/or any combination thereof, as described in greater detail below. Additionally, the system 102 can also execute a query or other command to obtain data from the user devices 104 and/or access data stored in the database 106. The data can include data related to the particular user and/or a plurality of patients or other users (e.g., historical blood pressure levels, historical blood glucose concentrations, prior predictions and/or analyses of blood pressure levels and/or blood glucose concentrations, health history data, medical condition history data, exercise history data, nutrition data, etc.), as described herein.
The database 106 can be used to store various types of data obtained and/or used by the system 102. For example, any of the above data can be stored in the database 106. The database 106 can also be used to store data generated by the system 102, such as previous predictions or forecasts produced by the system 102. In some embodiments, the database 106 includes data for multiple users, such as at least 50, 100, 200, 500, 1000, 2000, 3000, 4000, 5000, or 10,000 different users. The data can be appropriately anonymized to ensure compliance with various privacy standards. The database 106 can store information in various formats, such as table format, column-row format, key-value format, etc. (e.g., each key can be indicative of various attributes associated with the user and each corresponding value can be indicative of the attribute's value (e.g., measurement, time, etc.)). In some embodiments, the system 102 obtains data from different types of user devices 104 and/or other data sources, some of which may provide data in disparate formats (e.g., based on the particular software and/or hardware used). In such embodiments, the system 102 can convert the data to a standardized format for storage in the database 106 The standardized format can be configured to facilitate searching and/or retrieval of the data for use in the various methods described herein. Optionally, the standardized format can be organized in a manner suitable for use with the machine learning techniques disclosed herein.
In some embodiments, the database 106 stores one or more tables that can be accessed through queries generated by the system 102 and/or the user devices 104. The tables can store different types of information (e.g., one table can store blood pressure data, another table can store blood glucose data, yet another table can store user health data, etc.), where one table can be updated as a result of an update to another table. Alternatively, a single table can store multiple types of information.
For example, Table 1 below illustrates exemplary health and/or behavioral data that may be provided to the system 102 and/or stored in the database 106. The data in Table 1 can be generated by one or more user devices 104, as previously described. For example, the data can be automatically collected from the user (e.g., from a blood pressure measurement device, fitness tracking device, etc.) and/or may be manually entered by the user (e.g., via a computing device such as a mobile device). Each entry in Table 1 is labeled with a user ID, and includes a time stamp indicating when the data was obtained, the type of data, the data value, and corresponding units of measurement.
As another example, Table 2 below illustrates exemplary personal data that may be provided to the system 102 and/or stored in the database 106. The data in Table 2 can be generated by one or more user devices 104, as previously described. Each entry in Table 2 is labeled with a user ID, and includes personal information for that particular user such as the time zone and/or geographic region in which the user is located, the user's age, the user's gender, and the type of the diabetes the user has (if applicable).
In some embodiments, one or more users can access the system 102 via the user devices 104, e.g., to send data to the system 102 (e.g., blood pressure data, health data, other user data), receive data from the system 102 (e.g., a predicted blood pressure or other health metric), and/or other such operations. The users can be individual users (e.g., patients, healthcare professionals, etc.), computing devices, software applications, objects, functions, and/or any other types of users and/or any combination thereof. The user devices 104 can implement a software application (e.g., a mobile application, web application) configured to receive data from the user (e.g., input manually by the user, automatically sensed from the user), and can use the data to initiate processing by the system 102. For example, upon obtaining appropriate data (e.g., blood pressure data, health data, etc. as discussed above), the user device 104 can generate an instruction and/or command to the system 102, e.g., to process the obtained data, store the data in the database 106, extract additional data from one or more databases, and/or perform analysis of the data. The instruction/command can be in a form of a query, a function call, and/or any other type of instruction/command. In some embodiments, the instructions/commands can be provided using a microphone (e.g., a separate microphone or a microphone imbedded in the user device 104), a speaker, a screen (e.g., using a touchscreen, a stylus pen, and/or in any other fashion), a keyboard, a mouse, a camera, a camcorder, a telephone, a smartphone, a tablet computer, a personal computer, a laptop computer, and/or using any other device. The user device 104 can also instruct the system 102 to perform an analysis of data stored in the database 106 and/or input via the user device 104.
In some embodiments, the system 102 processes and uses the data provided by the user to produce automated decision support. As discussed further below, the system 102 can analyze the obtained data, including past data, continuously supplied data, and/or any other data (e.g., using a statistical analysis, machine learning analysis, etc.), and generate a forecast of an expected health metric (e.g., blood pressure level, blood glucose level, etc.) for the user. Optionally, the system 102 can also provide interpretations, recommendations, notifications, and/or other information related to the obtained data and/or the forecasted health metric. The system 102 can perform such analyses at any suitable frequency and/or any suitable number of times (e.g., once, multiple times, on a continuous basis, etc.). For example, when updated data is supplied to the system 102 (e.g., from the user devices 104), the system 102 can reassess and update its previous prediction, if appropriate. In performing its analysis, the system 102 can also generate additional queries to obtain further information (e.g., from the user devices 104, the database 106, or third party sources). In some embodiments, the user device 104 can automatically supply the system 102 with such information. Receipt of updated and/or additional information can automatically trigger the system 102 to execute a process for reanalyzing, reassessing, or otherwise updating previous predictions.
In some embodiments, the system 102 is configured to forecast the user's health metrics using one or more machine learning models. The machine learning models can include supervised learning models, unsupervised learning models, semi-supervised learning models, and/or reinforcement learning models. Examples of machine learning models suitable for use with the present technology include, but are not limited to: regression algorithms (e.g., ordinary least squares regression, linear regression, logistic regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing), instance-based algorithms (e.g., k-nearest neighbor, learning vector quantization, self-organizing map, locally weighted learning, support vector machines), regularization algorithms (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, least-angle regression), decision tree algorithms (e.g., classification and regression trees, Iterative Dichotomiser 3 (ID3), C4.5, C5.0, chi-squared automatic interaction detection, decision stump, M5, conditional decision trees), Bayesian algorithms (e.g., naïve Bayes, Gaussian naïve Bayes, multinomial naïve Bayes, averaged one-dependence estimators, Bayesian belief networks, Bayesian networks), clustering algorithms (e.g., k-means, k-medians, expectation maximization, hierarchical clustering), association rule learning algorithms (e.g., apriori algorithm, ECLAT algorithm), artificial neural networks (e.g., perceptron, multilayer perceptrons, back-propagation, stochastic gradient descent, Hopfield networks, radial basis function networks), deep learning algorithms (e.g., convolutional neural networks, recurrent neural networks, long short-term memory networks, stacked auto-encoders, deep Boltzmann machines, deep belief networks), dimensionality reduction algorithms (e.g., principle component analysis, principle component regression, partial least squares regression, Sammon mapping, multidimensional scaling, projection pursuit, discriminant analysis), time series forecasting algorithms (e.g., exponential smoothing, autoregressive models, autoregressive with exogenous input (ARX) models, autoregressive moving average (ARMA) models, autoregressive moving average with exogenous inputs (ARMAX) models, autoregressive integrated moving average (ARIMA) models, autoregressive conditional heteroskedasticity (ARCH) models), and ensemble algorithms (e.g., boosting, bootstrapped aggregation, AdaBoost, blending, stacking, gradient boosting machines, gradient boosted trees, random forest). Additional examples of machine learning models suitable for use with the forecasting techniques herein are discussed further below.
Although
The system 102 and user devices 104 can be operably and communicatively coupled to each other via the network 108. The network 108 can be or include one or more communications networks, and can include at least one of the following: a wired network, a wireless network, a metropolitan area network (“MAN”), a local area network (“LAN”), a wide area network (“WAN”), a virtual local area network (“VLAN”), an internet, an extranet, an intranet, and/or any other type of network and/or any combination thereof. Additionally, although
The various components 102-108 illustrated in
The process 300 may be executed for any suitable user, including those that may have been diagnosed (or have the same and/or similar and/or related conditions) with hypertension, cardiovascular disorders, diabetes, and/or any other conditions. In other embodiments, however, the process 300 can be executed for a user who has not been diagnosed with a specific condition, e.g., a user who is simply seeking to improve and/or maintain their state of health. Further, the process 300 may be configured to generate metabolic health metric forecasts (e.g., whether the user's blood pressure is likely to increase, decrease, or remain unchanged, etc.) during a predetermined period of time, at a predetermined time point, etc. By way of a non-limiting example, the process 300 may be configured to generate a forecast of metabolic health metric values that may be expected 30 days from the start of the forecast process execution.
Referring first to
Referring next to
In some embodiments, the input data may include at least one of the following: current and/or previous blood pressure measurement data of a user and/or other users; current and/or previous heart rate measurement data of the user and/or other users; current and/or previous blood glucose measurement data of the user and/or other users; meal characteristics data (e.g., number of meals, time of meals, grams carbohydrates and other nutrients (e.g., salt, cholesterol, etc.) consumed during meal times, whether currently and/or in the past), and/or any other meal data); physical exercise data (e.g., workout times, activity type (e.g., walking, running, etc.); current and/or previous weight, height, BMI, etc. data of the user and/or other users; current and/or previous HbA1c data values of the user and/or other users; medical history data related to the user and/or other users (e.g., family history, user health history, diagnoses, blood pressure, etc.); prescription and non-prescription medication data; sleep data; various optional personal data (e.g., geographic location, ethnicity, race, gender, etc.); diagnostic data, etc. Any of the above data types may be also obtained from other users (which may be anonym ized, if appropriate).
The input data can be obtained in many different ways, such as via manual entry by the user and/or other users, collected automatically through one or more sensors, activity trackers, smart watches, smartphones, medical equipment, and/or any other devices and/or systems. In some embodiments, for example, the data is collected from one or more data sources, such as the database 106 of
At block 314, the process 302 can include executing a feature engineering process (e.g., using the feature calculation component 204 of
At block 314a, the input data can be filtered using one or more filters. For example, the input data can be filtered to exclude one or more data values that are determined to be invalid, e.g., values that may be too high and/or low to be possible for a particular health measurement (e.g., blood pressure, blood glucose, heart rate, weight, etc.). As another example, one or more outlier values (e.g., values that are many standard deviations away from all prior entries for that user) can also be excluded. In yet another example, duplicate values can also be excluded. Additionally, contradictory values can be removed or excluded from further calculations. For example, if two values of the same health measurement have different values but are separated by a very short time (e.g., less than one minute), either the first, the last, or an average of the two values may be used. The selection of the particular value may be dependent on the specific health measurement.
At block 314b, the process 302 can include analyzing data values relating to various types of health measurements. In some embodiments, for example, block 314b includes calculating averages and/or other statistics values for one or more health measurements, such as blood pressure (e.g., systolic and/or diastolic), sleep, heart rate, blood glucose, doses of medications, carbohydrates and/or other nutrients, physical activity, etc. The analysis may be performed at specific times, e.g., at the times when blood pressure has been measured.
At block 314c, the process 302 can include determining cross-correlations between values. In some embodiments, the cross-correlation may be computed over time between averages of systolic and diastolic blood pressures, blood pressure and heart rate, blood pressure and blood glucose, and/or other pairs and/or groups of variables corresponding to various health measurements.
At block 314d, the process 302 can include determining features for use in metabolic health metric forecasting. This can include computation of features of changes in statistics of historical averages and/or any other determined values. For example, the features can include values (e.g., the most recent value or set of values) and/or statistics (e.g., averages, standard deviations, ranges, sums, differences, ratios, maximums, minimums, percentiles, probabilities, cross-correlations, time-in-range) for any suitable health data, including, but not limited to, any of the following: blood glucose levels, blood pressure levels, heart rate, weight, food intake, medical history, demographics, diagnoses and/or medical conditions, medications, sleep patterns, activity patterns, and/or combinations thereof. Features can be computed across health data obtained over any suitable length of time (e.g., 15 days, 30 days, 60 days, or 90 days) and at any suitable time period before the prediction is made (e.g., immediately before the prediction, 15 days before the prediction, 30 days before the prediction, 60 days before the prediction, or 90 days before the prediction).
Optionally, the features can be categorized into feature groups, also referred to herein as “explanation groups.” Each feature group can be associated with a corresponding health factor, such that features within the same feature group are all related to the same underlying health factor, e.g., all features in a “blood pressure” feature group are computed from the user's blood pressure data, all features in a “blood glucose” feature group are computed from the user's blood glucose data, etc. Examples of health factors that may be used to determine feature groups include, but are not limited to: blood pressure (e.g., blood pressure history), blood glucose (e.g., blood glucose history), heart rate (e.g., heart rate history), multi-factor interactions (e.g., blood pressure-glucose interactions, blood pressure-heart rate interactions), demographic factors, meal intake (e.g., food history), sleep (e.g., sleep history), weight (e.g., weight history), activity (e.g., activity history), medical conditions and/or diagnoses, and the like.
Table 3 below illustrates a representative set of determined features and their corresponding explanation groups, in accordance with embodiments of the present technology.
At block 316, the process 302 can include performing model training and/or testing (e.g., using the metabolic metric prediction model component 206 of
At block 316a, the process 302 can include dividing the determined features into one or more training sets and/or one or more test sets. For example, a training set can include all features and/or records prior to a cut-off date, and a test set can include all feature and/or records after the cut-off date. As can be understood, any desired training and/or test sets can be generated.
In some embodiments, features are calculated at each time new data becomes available. However, the features used for purposes of training and/or testing can be determined using data points for a specific user that are sufficiently far apart in time. Features and/or targets calculated at nearby times may be based on many of the same data points, which may be undesirable for prediction accuracy. For example, a 30-day average blood pressure ending on April 20th may use many of the same blood pressure measurements as a 30-day average blood pressure ending on April 21st. The use of such nearby points in the training and/or testing sets may bias the resulting model in undesirable ways that may overstate and/or degrade the model's predictive power. To reduce or prevent the occurrence of these issues, the process 302 can set a minimum time between data points for training and/or testing purposes for each user.
Table 4 illustrates representative minimum separation time values and the corresponding improvements in model accuracy, in accordance with embodiments of the present technology. Although the data in Table 4 is shown for blood pressure predictions, it will be appreciated the approaches described herein can be applied to predictions of other types of health metrics (e.g., blood glucose, weight, etc.). Table 4 shows improvements in model accuracy calculated across all users and for users having a 30-day average blood pressure value greater than 135 mmHg at the time of the forecast. In Example 1 of Table 4, the minimum separation time between data points was selected based on the desired forecast horizon to meet a requirement that adjacent data points are based on time periods that have no more than 3 days' data in common. In Example 2 of Table 4, the minimum data separation was set to 30 days regardless of the forecast horizon. As shown in Table 4, the Example 2 approach provided improvement over the Example 1 approach for shorter forecast horizons. In other embodiments, the separation between data points for training can be selected to improve accuracy. For example, in the cases shown in Table 4, the separation can be specified to be 30 days, or 30 days less than the forecast horizon, whichever is greater.
At block 316b, the process 302 can include training the model(s) using a supervised learning model technique. The model(s) can include, for example, a Gradient Boosted Trees model and/or any other suitable machine learning model configured to learn a mapping from a set of input points to a desired target value. The model(s) can be trained on data from a plurality of users simultaneously, so that experiences of one or more users may be used to inform predictions of other users having similar features. This can allow the model(s) to make predictions even for users with few data points and/or with irregular and/or incomplete input data.
At block 316c, the process 302 can include testing the trained model(s). For example, the trained model(s) can be used to predict metabolic health metric values in a test set. The predicted metrics can then be compared to the actual metrics to determine the accuracy of the model(s). If the model accuracy is not satisfactory, the model(s) can be re-trained, e.g., using additional and/or different training sets. Optionally, different candidate feature sets can be compared (e.g., based on accuracy of the resulting training model(s)), and the feature set that generated the best testing performance can be selected for future use.
One of skill in the art will appreciate that there are many measures of accuracy. For example, one measure can include a comparison of the model skill with a naïve predictor, such as persistence (e.g., “predict that the future value will be the same as the current value”). The model score can be generated and can correspond to a relative reduction in root mean square error (RMSE) compared to the naïve predictor, e.g., 1−RMSEmodel/RMSEnaïve. This measure will equal 1 if the model prediction has zero error, and will equal zero if the model prediction has the same error as the naïve prediction. If the model errors are larger than the naïve errors, this accuracy measure will be negative.
At block 318, the process 302 can optionally include determining one or more confidence intervals for the forecasted data (e.g., using the confidence bounds model component 208 of
In such models, each data item may correspond to one “leaf” of each tree, and each leaf may have a “weight” that can be determined when the model is trained. The predicted value for that data item may be the sum of the weights of the leaves that that data item ends up in for each tree. The weights may be determined as follows: each tree's contribution may be considered to be a correction to the running sum. For example, to compute weights in a leaf of a 4th tree, the training routine can look at the predictions for the items in that leaf from summing their weights from the first three trees. All those 3-tree predictions may have some error, and the mean value of that 3-tree error for those items becomes the correction value, or the weight of the tree-4 leaf being computed. As such, the weight of that tree-4 leaf may be the mean value of the 3-tree errors of the items in that leaf multiplied by a value that depends on the model parameters being trained.
In some embodiments, the weight does not consider the spread of the 3-tree errors. For example, the errors of items in the tree-4 leaf could range from 10 to 12, with an average value of 11, or they could range from −89 to +202, with an average value of 11: the weight may be the same. However, the 4-tree prediction errors may be larger in the second case than in the first. In some embodiments, the process 302 can assume that if the prediction is the sum of each leaf's errors' mean, then the variance of the prediction may be the sum of each leaf's errors' variance. The process 302 can then examine the trained model (e.g., XGBoost model) and determine the variance of errors in each leaf of each tree, and turn that into a “variance model.” The inputs to the variance model may be the same as the inputs to the prediction model: for each prediction, the variance model adds up the variances of the leaf that prediction lands in for each tree.
The prediction errors may not be normally distributed; however, the error distributions may be very close between training and test sets. Next, the error distribution for training set predictions with the same variance as the prediction in question may be ascertained. The quantiles of that training set distribution may then be assumed to be the quantiles of the prediction in question.
At block 320, the process 302 can optionally include generating one or more explanation models (e.g., using the explanation model component 210 of
Referring back to
Referring next to
At block 324, the process 304 can include determining a probability of the user reaching a health metric goal (e.g., using the probability of reaching goal component 240 of
At block 326, the process 304 can include generating an explanation of change of forecast (e.g., using the components 234-238 of
The forecast explanation can be generated in many different ways. For example, as in the previous step (block 324), the same features used as inputs to the forecast model(s) can also be used as inputs to the explanation model(s). The explanation model(s) can be configured to determine a contribution of each feature to the forecast value. These contributions may be positive (e.g., factors increasing the likelihood of reaching a specific blood pressure goal, weight goal, etc.) and/or negative (e.g., decreasing the likelihood of reaching a specific blood pressure goal, weight goal, etc.). In some embodiments, certain features and/or feature groups may be more influential and/or contribute more to the forecast than other features and/or feature groups (e.g., meal intake, weight, blood glucose concentration, age, etc.). As such, the forecast explanation may make a reference to those features and/or feature groups directly, e.g., the user is likely/unlikely to reach a specific blood pressure goal “based on your salt intake and heart rate history.” In some embodiments, many data contributions, corresponding to respective features and/or feature groups, can be configured to affect the final forecast determination, as illustrated by blocks 326a-326e shown in
At block 326a, the process 304 can include collecting one or more features that can be used in generation of a forecast. As previously discussed, the features can include values and/or statistics for one or more of the following data points: blood glucose levels, blood pressure levels, heart rate, weight, food intake, medical history, demographics, diagnoses and/or medical conditions, medications, sleep patterns, activity patterns, and/or combinations thereof. One or more obtained features can be grouped in one or more feature or explanation groups, with each explanation group being associated with a corresponding health factor (e.g., blood pressure, blood glucose, heart rate, demographics, diagnoses, meal intake, sleep, weight, activity, etc.). Representative examples of features and explanation groups are illustrated in Table 3 above, and also described further below with reference to Tables 5A-6B.
At block 326b, for each forecast, the process 304 can include summing the contributions of each feature within each explanation group into subtotals, to determine the individual contribution of each explanation group to the forecast. The subtotal for an explanation group may be positive, negative, or zero. The overall forecast value may then be equal to the sum of each group's subtotal. As previously discussed, the contributions of each feature can be determined using any suitable technique, such as a SHAP attribution algorithm or other attribution algorithm.
At block 326c, the process 304 can include determining the absolute values of each explanation group's subtotal to determine the corresponding magnitudes of each subtotal. The magnitude of the subtotal may be proportional to the contribution of that explanation group to the forecast, e.g., a larger magnitude indicates a larger contribution, a smaller magnitude indicates a smaller contribution, a zero magnitude indicates no contribution.
At block 326d, the process 304 can include determining the main contributing factors (e.g., weight, blood glucose, meal intake, etc.) to the forecast. The main contributing factors may be determined by selecting the explanation groups having the largest magnitudes. Any number of explanation groups may be selected, e.g., a fixed number (e.g., the top three groups), a number that depends on their contribution values (e.g., define the gross total change as the sum of the magnitudes, and select a sufficient number of groups to collectively account for at least 95% of the gross total change (or any other suitable percentage)), etc.
At 326e, the process 304 can generate explanation groups that are likely to be the driving explanatory factors for the forecast (e.g., “based mainly on your sleeping and eating patterns”). In some embodiments, in order to understand factors leading to the change in, for example, a blood pressure forecast from a prior blood pressure forecast, explanatory contributions of the two forecasts may be compared. The difference in contributions may explain the change in likelihood of success of achieving a health metric goal. For example, if the forecast probability of success has increased by five percentage points, and all contributions are the same in both forecasts except for diet (e.g., which has increased by five percentage points), then the improvement in the forecast may be due to improvements in the diet. In some embodiments, changes in contributions from one forecast to the next forecast may be aggregated and/or filtered using processes described above to generate a “digest” of main factors contributing to the change in forecasted blood pressure values.
Tables 5A-6B illustrate representative examples of experimental determinations of feature group contributions for generating an explanation of a forecast or prediction, in accordance with embodiments of the present technology. Although Tables 5A-6B are described with reference to a prediction of a blood pressure health metric, it will be appreciated that similar tables and/or calculations may be generated for any other suitable health metric. The following abbreviations are used in Tables 5A-6B: “bp”—blood pressure, “bg”—blood glucose concentration, “hr”—heart rate, “demo/diag”—demographics/diagnosis, “med”—medications taken, “food”—meals ingested, “weight”—weight measurement, “activity”—exercise data.
Table 5A lists each feature used in the prediction, a description of the feature, the feature or explanation group to which each feature belongs, the SHAP-value contribution of each feature to the three-month and one-month predictions, and the change of SHAP value between the 3 month and 1 month predictions for each feature. The “Value 3 Months Prediction” and “Value 1 Month Prediction” columns represent deviations from a baseline blood pressure value (in this experimental example, 129.9 mmHg) for predictions made three months and one month before the target date, respectively. As can be seen in Table 5A, the total deviation summed across all features for the three-month prediction is approximately −4.0, and the total deviation for the one-month prediction is approximately −7.4.
Table 5B summarizes the prediction data from Table 5A. For the three-month prediction (prediction made July 8 for an October 8 target date), the predicted 30-day average blood pressure value is 129.9 mmHg-4.0 mmHg=125.9 mmHg. For the one-month prediction (prediction made September 9 for an October 8 target date), the predicted 30-day average blood pressure value is 129.9 mmHg-7.4 mmHg=122.5 mmHg. The change between predictions is thus −3.355 mmHg.
Table 6A shows feature group subtotals for the change between predictions and Table 6B shows the contribution of each feature group to the change between predictions. The data listed in Table 6A is obtained by summing the “Change Since Last Prediction” data from Table 5A for each feature group to generate each feature group subtotal. In Table 6B, the “Change” column corresponds to the subtotal data from Table 6A, the “Abs (Change)” column lists the magnitude (absolute value) of the subtotal, the “% Of Abs Change” column lists the percentage of the total change in the prediction contributed by each feature group, and the “Cumulative % Of Abs Change” lists the running sum of feature group contributions. As can be seen in Tables 6A and 6B, the top contributing feature groups (e.g., based on absolute values) can account for more than 95% of the total change between predictions. In this example, the main contributors are blood pressure (81% contribution), blood glucose (12% contribution), and weight values (5% contribution). However, as can be understood, in other embodiments, the main contributors may be other factors and/or combinations of factors, such as blood pressure and sleep, blood pressure, food, medications and weight, etc.
Referring again to
At block 330, the process 304 can include generating a graphical representation of the results of the process 304 (e.g., using the message generation component 246 of
Referring again to
The method 500 can be used to predict any of the health metrics described herein. For example, the health metrics can include metrics related to any of the following: blood pressure, blood glucose (e.g., 30-day time-in-range and/or other time-in-range metric), weight, BMI, waist circumference, body fat percentage, cholesterol, triglycerides, heart rate, respiratory rate, body temperature, gases (e.g., oxygen, carbon dioxide), electrolytes (e.g., bicarbonate, potassium, sodium, magnesium, chloride, lactic acid), BUN, creatinine, ketones, alcohols, neurotransmitters, amino acids, hormones, disease biomarkers (e.g., cancer biomarkers, cardiovascular disease biomarkers), and/or combinations thereof. The prediction can be made for any suitable time period, such as at least one week, two weeks, three weeks, four weeks, one month, two months, three months, four months, five months, six months, seven months, eight months, nine months, ten months, 11 months, or 12 months in the future from the date of the prediction.
At block 510, the method 500 begins with receiving health data of a user. As discussed above, the health data can include any data relevant to the user's health state. Examples of health data include, but are not limited to, any of the following: blood pressure data (e.g., current and/or previous measurements of systolic and/or diastolic blood pressure), blood glucose data (e.g., current and/or previous blood glucose measurements, current and/or previous HbA1c data values), heart rate data, food data (e.g., number of meals; timing of meals; number of calories; amount of carbohydrates, fats, sugars, etc.), medical history data (e.g., current and/or previous weight, height, BMI, age, sleeping patterns, medical conditions, cholesterol levels, diabetes type, family history, user health history, diagnoses, blood pressure, etc.), activity data (e.g., time and/or duration of activity; activity type such as walking, running, swimming; strenuousness of the activity such as low, moderate, high; etc.), personal data (e.g., name, gender, demographics, social network information, etc.), medication data (e.g., timing and/or dosages of medications such as insulin, prescription and/or non-prescription medications taken), and/or any other suitable data (e.g., basal energy consumption, oxygen consumption) or combination thereof. The health data can be obtained automatically by one or more biosensors (e.g., the biosensor(s) 104a of
Optionally, block 510 can further include receiving a health goal for the user. The health goal can be a target value and/or range for a particular health metric (e.g., blood pressure, blood glucose, weight, etc.) that the user wishes to achieve in the future (e.g., one, two, three, four, five, six, or more months in the future). For example, the health goal can be for the user's health metric to achieve a target value and/or range, to be greater than a target value and/or range, to be less than a target value and/or range, etc. The health goal can be determined by the user, by a healthcare professional, set based on healthcare guidelines (e.g., based on the user's characteristics), or suitable combinations thereof. The health goal can be input by the user via a user device, transmitted to the system from a healthcare professional's device, retrieved from a database or server, or any other suitable technique. Optionally, block 510 can include receiving multiple health goals for multiple different health metrics.
At block 520, the method 500 continues with determining a plurality of features and feature groups from the health data of block 510. The features can be determined from the health data using any suitable approach. For example, as discussed above with reference to
In some embodiments, the features are classified in a plurality of feature groups, each feature group being associated with a respective health factor. Each health factor can relate to an aspect of the user's health that may influence the predicted health metric. As previously discussed with reference to
At block 530, the method 500 can include generating a prediction of a health metric of the user. The prediction can be generated using one or more prediction models, e.g., as previously discussed with reference to
The prediction can provide an estimated value and/or range for the health metric at a future time point. The future time point can be at least one, two, three, four, five, six, seven, eight, nine, ten, 11, 12, or more months from the date of the prediction. Alternatively or in combination, the prediction can provide an estimated probability that the health metric will achieve a particular target value and/or range at the future time point. In such embodiments, the predicted probability can be expressed quantitatively (e.g., an x % chance of achieving the goal) and/or qualitatively (e.g., highly likely, likely, unlikely, highly unlikely).
At block 540, the method 500 can also include identifying at least one health factor that contributed to the prediction. The health factor can be identified in various ways, such as by selecting one or more feature groups that provided a threshold contribution to the prediction, then determining the health factor(s) associated with the selected feature group(s). For example, as previously discussed with reference to
Based on the determined contributions, block 540 can further include identifying one or more feature groups determined to have contributed to the prediction (e.g., feature group(s) whose contribution met a threshold value and/or other suitable criteria). For example, block 540 can include identifying at least one, two, three, or more feature groups having the greatest contribution(s) to the prediction, e.g., by ranking the feature groups in order of contribution magnitude. As another example, feature groups can be identified based on the percentage and/or proportion of the contribution made to the prediction, e.g., all feature groups contributing at least 10%, 25%, 50%, or 75% to the prediction; feature groups that collectively account for at least 50%, 75%, 90%, or 95% of the prediction; and so on.
At block 550, the method 500 can include outputting a notification to the user. The notification can include the prediction of the health metric and, optionally, the at least one health factor determined to have contributed to the prediction (e.g., as discussed above with reference to block 540). For example, if the blood glucose feature group was determined to have contributed to the prediction, the notification can include a support message or other feedback informing the user that the predicted outcome can be at least partially attributed to the user's blood glucose levels. The notification can be provided in any suitable format, such as textual, visual, graphical, audible, and/or other formats. The notification can be output to the user via a graphical user interface on a user device or any other suitable computing device.
The method 500 can optionally include determining a recommended action for the user to improve their health metrics, based on the prediction and/or contributing health factor(s). For example, if the method 500 determines that a certain health factor is particularly influential in causing the user to achieve or not achieve their health goal, the notification can inform the user with recommended actions with respect to that health factor (e.g., decreasing blood glucose levels; increasing physical activity; improving sleep patterns; altering dietary intake; etc.). The recommendation can be customized to the particular user, e.g., based on user feedback, behavioral patterns, etc. For example, the method 500 can account for whether the user has historically complied or not complied with a particular lifestyle change, whether the user has expressed a preference for certain types of behavioral interventions, etc. Such information can also be used as input for generating future recommendations and/or other notifications to assist the user in meeting their health goals.
In some embodiments, the approaches described herein provide improved accuracy in predicting various health metrics (e.g., 30-day time-in-range, 30-day average blood glucose values, 30-day average blood pressure values, weight, etc.) compared to conventional techniques. For example, the RMSE of predictions generated in accordance with embodiments of the present technology can be no more than 20%, 15%, 10%, or 5%. The relative reduction in RMSE compared to a naïve predictor (e.g., a persistence model) can be at least 10%, 15%, 20%, 25%, 30%, 40%, or 50%. The enhanced accuracy can assist users in monitoring and managing their health conditions, as well as in making decisions regarding lifestyle changes and/or other actions to improve their health.
The systems and methods disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations thereof. Moreover, the above-noted features and other aspects and principles of the present disclosed implementations may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various processes and operations according to the embodiments disclosed herein, or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and may be implemented by a suitable combination of hardware, software, and/or firmware. For example, various general-purpose machines may be used with programs written in accordance with teachings of the disclosed embodiments, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.
The systems and methods disclosed herein may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program may be written in any form of programming language, including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
These computer programs, which may also be referred to programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and/or device, such as for example magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs), used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor. The machine-readable medium may store such machine instructions non-transitorily, such as for example as would a non-transient solid state memory or a magnetic hard drive or any equivalent storage medium. The machine-readable medium may alternatively or additionally store such machine instructions in a transient manner, such as for example as would a processor cache or other random access memory associated with one or more physical processor cores.
To provide for interaction with a user, the subject matter described herein may be implemented on a computer having a display device, such as for example a cathode ray tube (CRT) or a liquid crystal display (LCD) monitor for displaying information to the user and a keyboard and a pointing device, such as for example a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well. For example, feedback provided to the user may be any form of sensory feedback, such as for example visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including, but not limited to, acoustic, speech, or tactile input.
The technology described herein may be implemented in a computing system that includes a back-end component, such as for example one or more data servers, or that includes a middleware component, such as for example one or more application servers, or that includes a front-end component, such as for example one or more client computers having a graphical user interface or a Web browser through which a user may interact with an embodiment of the technology described herein, or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication, such as for example a communication network. Examples of communication networks include, but are not limited to, a local area network (“LAN”), a wide area network (“WAN”), and the Internet.
The computing system may include clients and servers. A client and server are generally, but not exclusively, remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
The embodiments set forth in the foregoing description do not represent all embodiments consistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject matter. Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and/or variations may be provided in addition to those set forth herein. For example, the embodiments described above may be directed to various combinations and sub-combinations of the disclosed features and/or combinations and sub-combinations of several further features disclosed above. In addition, the logic flows depicted in the accompanying figures and/or described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Other embodiments may be within the scope of the following claims.
As used herein, the term “user” may refer to any entity including a person or a computer.
The words “comprising,” “having,” “containing,” and “including,” and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items.
As used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
As used herein, the phrase “and/or” as in “A and/or B” refers to A alone, B alone, and A and B.
As used herein, the term “user” can refer to any entity including a person or a computer.
Although ordinal numbers such as first, second, and the like can, in some situations, relate to an order; as used in this document ordinal numbers do not necessarily imply an order. For example, ordinal numbers can be merely used to distinguish one item from another. For example, to distinguish a first event from a second event, but need not imply any chronological ordering or a fixed reference system (such that a first event in one paragraph of the description can be different from a first event in another paragraph of the description).
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
The present application claims the benefit of U.S. Provisional Patent Application No. 62/970,282, filed on Feb. 5, 2020, which is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62970282 | Feb 2020 | US |
