Detection of abnormal computing environment behavior using glucose

Abstract

Detecting abnormal computing environment behavior using glucose is described. An anomaly detection system receives glucose measurements and event records during a first time period. Missing events missing from the event records during the first time period are identified by processing the glucose measurements using an event engine simulator. An anomaly detection model is generated based on the missing events during the first time period. The anomaly detection system then receives additional glucose measurements and additional event records during a second time period. Missing events missing from the additional event records during the second time period are identified by processing the additional glucose measurements using the event engine simulator. Anomalous behavior is detected when the identified missing events missing from the event records during the second time period are outside a predicted range of missing events of the anomaly detection model.

Description

Technical Field

[0001] This application was filed on November 24, 2020, and claims the benefit of U.S. Provisional Patent Application No. 63 / 117,705, titled "Detection of Anomalous Computing Environment Behavior Using Glucose", the entire disclosure of which is incorporated herein by reference.

Background Art

[0002] Diabetes is a metabolic condition that affects hundreds of millions of people and is one of the leading causes of death worldwide. For people living with type I diabetes, access to treatment is essential for their survival, and it can reduce adverse outcomes among people with type II diabetes. With appropriate treatment, serious damage to the heart, blood vessels, eyes, kidneys, and nerves caused by diabetes can be avoided. Regardless of the type of diabetes (e.g., type I or type II), successfully managing diabetes involves monitoring food and activity and making frequent adjustments to control a person's blood sugar, e.g., reducing significant fluctuations in a person's glucose and / or lowering a person's glucose overall.

[0003] Conventional glucose monitoring systems employ glucose monitoring devices to monitor a user's glucose and output glucose measurements to the user. As part of this, conventional glucose monitoring systems can also generate various events, such as low glucose alerts that can be output when a user's glucose value falls below or is predicted to fall below a low glucose threshold. Users of conventional glucose monitoring systems may come to rely on these events and alerts to take mitigation actions to prevent dangerous glucose-related situations from occurring.

[0004] Unfortunately, due to a variety of different circumstances, conventional glucose monitoring systems may fail to generate specific events. Such circumstances may include signal loss between the glucose monitoring device and the user's computing device, problems with the glucose monitoring device, operating system incompatibility issues, resource contention, and user behavior. For example, installing a new operating system for a specific brand of mobile device, or updating to a new version of that operating system, can cause incompatibility issues between the mobile device and the glucose monitoring device, leading to the glucose monitoring application failing to generate specific events.

[0005] Traditionally, the only way for application developers to detect and correct issues causing glucose monitoring applications to miss events has been through user feedback. Users of glucose monitoring devices may, for example, notice that their glucose monitoring application is failing to output low glucose alerts, and thus file a complaint. Once sufficient complaints are received, an investigation can be initiated to determine a solution to the problem causing the missing events. However, this traditional process for detecting missing events is slow, and typically requires a certain number of users to detect the problem before an investigation can be initiated. Furthermore, some missing events may not even be noticed by users and therefore go undetected based on user complaints. The inability to detect missing events quickly is detrimental to users who rely on the accuracy of events and alerts generated by glucose monitoring applications and devices, and could even lead to life-threatening problems. Therefore, it is crucial to detect missing events generated by glucose monitoring applications as quickly as possible. [Overview of the project] [Means for solving the problem]

[0006] To overcome these problems, the detection of anomalous computing environment behavior using glucose is utilized. The anomaly detection system receives glucose measurements collected by a wearable glucose monitoring device and event records associated with those glucose measurements during a first period. Missing events that are missing from the event records during the first period are identified by processing the glucose measurements using an event engine simulator. An anomaly detection model is generated based on the missing events during the first period. This anomaly detection model includes a predicted range of non-anomalous missing events during a second period, which follows the first period. The anomaly detection system also receives additional glucose measurements collected by the wearable glucose monitoring device and additional event records associated with those additional glucose measurements during the second period. Missing events that are missing from the additional event records during the second period are identified by processing the additional glucose measurements using an event engine simulator. Anomaly behavior is detected when the identified missing events that are missing from the event records during the second period are outside the predicted range of missing events in the anomaly detection model.

[0007] This summary provides a simplified selection of concepts that will be further described in the following "Modes for Carrying Out the Invention." Therefore, this summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Detailed explanations are provided in the attached diagram. [Brief explanation of the drawing]

[0008] [Figure 1] This is an explanatory diagram of an environment in a typical embodiment that is operational for using the techniques described herein. [Figure 2] A more detailed example of the wearable glucose monitoring device shown in Figure 1 is presented. [Figure 3]Figure 1 shows an example of an anomaly detection system that detects abnormal behavior in a computing environment by simulating events. [Figure 4] This document illustrates an exemplary embodiment of a user interface that displays a plot of observed behavior over time associated with a computing environment, and a visualization of the range of observed behavior that is not abnormal. [Figure 5] This document illustrates an exemplary embodiment of a user interface that displays notifications of detected abnormal behavior. [Figure 6] The procedure in an exemplary embodiment shows how an anomaly detection model is generated based on missing events identified during a first period. [Figure 7] Figure 6 illustrates the procedure in an exemplary embodiment where the generated anomaly detection model is used to detect abnormal behavior during a second period. [Figure 8] Referencing and / or using Figures 1 to 7, an example of a system including various components of an exemplary device that can be implemented as any type of computing device for implementing embodiments of the techniques described herein is shown. [Modes for carrying out the invention]

[0009] overview The detection of anomalous computing environment behavior using glucose is described. The anomaly detection system receives glucose measurements and event records associated with those glucose measurements collected by a wearable glucose monitoring device during a first period. These glucose measurements and event records can be received, for example, from a glucose monitoring application implemented on multiple computing devices. These computing devices obtain glucose measurements from their respective glucose monitoring devices, each collecting the user's glucose measurements. In some cases, for example, the glucose monitoring device is a wearable glucose monitoring device that collects glucose measurements from the user in real time at predetermined time intervals, for example, every 5 minutes.

[0010] The event engine of a glucose monitoring application is configured to process glucose measurements and generate events associated with glucose monitoring, such as glycemic events (e.g., hyperglycemia and hypoglycemia) and predicted glycemic events (e.g., upcoming hypoglycemia or upcoming hyperglycemia). These generated events may be output to the user's computing device and may also be recorded in an event log that maintains a list of all events generated by the event engine. For example, alerts and alarms may correspond to the types of events identified and recorded by the event engine. Generally, alerts and alarms may be triggered in response to dangerous or potentially dangerous health conditions identified and recorded by the event engine, in which case the glucose monitoring application is configured to produce an alert or alarm output (e.g., notify the user of the condition) via the computing device or some other device in response to the identification of such an event.

[0011] During operation, a wearable glucose monitoring device may be configured to transmit glucose measurements to a computing device at substantially predetermined time intervals, for example, once every 5 minutes. Generally, regardless of the configuration for transmitting measurements at predetermined time intervals, the glucose monitoring application, and therefore the event engine, may, for various reasons, fail to receive one or more of those measurements at their scheduled transmission times. For example, one or more measurements may not be received at their scheduled times due to signal loss between the computing device and the wearable glucose monitoring device (but conversely, they may be received thereafter). In scenarios where the event engine does not receive those glucose measurements on schedule, the event engine cannot generate a specific event, for example, it cannot generate an alert or alarm when measurements corresponding to a blood glucose event (e.g., hypoglycemia or hyperglycemia) are not received on schedule. When an event is not generated by the event engine and not output by the glucose monitoring application, the event engine also does not record that event in the event log. Therefore, such an event may be "missing" by the event engine and may be in a "missing" state from the event log. While signal loss is described as one cause of missing events, the event engine may miss events for various other reasons, without deviating from the intent or scope of the techniques described herein, which may in some cases be due to contention of computing device resources.

[0012] Traditionally, such data omissions can only be detected when a certain number of users complain about them. For example, a user might notice that a glucose monitoring application is failing to output low glucose alerts and therefore contact the glucose monitoring system with a complaint. Once enough complaints are received, an investigation can be initiated by the application developer or customer service staff to determine a solution to the problem. However, this process is slow and requires a significant number of users to detect the problem and raise their concerns. It is especially important to detect data omissions as quickly as possible if they are harmful to the user or even potentially life-threatening. Furthermore, low glucose-related data omissions often go unnoticed by the user, for example, when they occur while the user is asleep.

[0013] Therefore, to solve this problem in conventional systems, missing events that are missing from the event log during a first period are identified by processing glucose measurements using an event engine simulator, which is a replica of the event engine. This event engine simulator can be implemented using the same or similar logic (or parts of the same or similar logic) as the event engine in the glucose monitoring application. For example, the event engine simulator can be implemented using at least some of the same or similar source code as the event engine. The event engine simulator receives the same glucose measurements as the event engine and generates simulated events. These simulated events are then compared with the actual events in the event log during the first period to identify missing events from the event log. Thus, missing events correspond to simulated events that do not have a matching actual event in the event log during the first period.

[0014] Next, the anomaly detection system can determine whether a missing event in the second period is anomalous in light of past missing events determined in the first period preceding the second period. To do so, an anomaly detection model is generated based on the missing events identified in the first period. For example, this anomaly detection model may be generated based on missing events identified in the first period of eight weeks, and then this model can be used to detect anomalous behavior in the second period of one week. The anomaly detection model includes a predicted range of non-anomalous missing events in the second period.

[0015] In a similar manner to identifying missing events in the first period, the anomaly detection system receives additional glucose measurements collected by a wearable glucose monitoring device and event records associated with those additional glucose measurements during the second period. Missing events that are missing from the event records during the second period are identified by processing the additional glucose measurements using an event engine simulator. For example, the event engine simulator receives the same glucose measurements as the event engine during the second period and generates simulated events. These simulated events are then compared to the actual events in the event records during the second period to identify the missing events.

[0016] Next, abnormal behavior is detected when the identified missing events during the second period fall outside the predicted range of missing events for the anomaly detection model. For example, a certain number of missing events may be expected across a group of thousands or millions of users. Therefore, an abnormal event is detected when the number of missing events falls outside the predicted range of missing events for the anomaly detection model. For example, if the predicted range of missing events defined by the anomaly detection model is 10 to 30 missing events per day, then abnormal behavior will be identified if the number of missing events during a given day is 40, which exceeds the upper threshold of 30 for the predicted range of missing events. In contrast, if 20 missing events are identified during a given day, abnormal behavior will not be detected because 20 missing events fall within the predicted range of missing events for that day. According to the technique described herein, the range can also be described, or alternatively, in terms of percentages, for example, the percentage of all events across the entire user group.

[0017] Therefore, the techniques described herein solve many of the problems of conventional systems by automatically detecting abnormal behavior at an early stage. That is, rather than relying on a certain scale of user complaints to detect problems causing missing events, the techniques described herein simulate events (e.g., daily) to detect missing events that may correspond to abnormal behavior. In particular, by modeling the behavior of missing events over a previous period, the system tolerates a certain number of missing events each day that fall within the normal range of missing events. However, when the number of missing events falls outside the predicted range, abnormal behavior can be quickly identified and addressed before the problem causing the missing events leads to even more missing events for the user. Thus, the ability to quickly identify abnormal behavior allows for the rapid resolution of problems causing abnormal behavior, which reduces many health-related problems for users who rely on glucose monitoring applications.

[0018] In the following description, first, a typical environment in which the techniques described in this specification can be used will be described. Next, details of exemplary embodiments and examples of procedures that can be performed in the typical environment, as well as in other environments, will be described. The execution of typical procedures is not limited to that typical environment, and that typical environment is not limited to the execution of those typical procedures.

[0019] Example of Environment FIG. 1 is an explanatory diagram of an environment 100 in an exemplary embodiment operable to employ detection of abnormal computing environment behavior using glucose, as described in this specification. This illustrated environment 100 includes a person 102 depicted as wearing a wearable glucose monitoring device 104. This illustrated environment 100 also includes a computing device 106, other users within a user population 108 wearing the glucose monitoring device 104, and a glucose monitoring platform 110. The wearable glucose monitoring device 104, the computing device 106, the user population 108, and the glucose monitoring platform 110 are communicatively coupled, including via a network 112.

[0020] Alternatively or additionally, the wearable glucose monitoring device 104 and the computing device 106 can be communicatively coupled in other ways, such as using one or more wireless communication protocols or techniques. By way of example, the wearable glucose monitoring device 104 and the computing device 106 can communicate with each other using one or more of Bluetooth (e.g., a Bluetooth Low Energy link), near-field communication (NFC), 5G, and the like.

[0021] According to the techniques described herein, the wearable glucose monitoring device 104 is configured to provide glucose measurements of a person 102. Although wearable glucose monitoring devices are discussed herein, it should be understood that abnormal computing environment behavior can be associated with other devices that can provide glucose measurements, such as non-wearable glucose devices (e.g., blood glucose meters that require finger pricks), patches, etc., and can be detected using glucose. However, in embodiments involving the wearable glucose monitoring device 104, the wearable glucose monitoring device can be configured with a glucose sensor that continuously detects an analyte indicative of the person 102's glucose to enable the generation of glucose measurements. In the illustrated environment 100 and throughout the detailed description, these measurements are represented as glucose measurements 114.

[0022] In one or more embodiments, the wearable glucose monitoring device 104 is a continuous glucose monitoring (CGM) system. As used herein, the term "continuous" when used in connection with glucose monitoring may refer to the ability of a device to generate measurements substantially continuously, such that the device can generate glucose measurements 114 at time intervals (e.g., every hour, every 30 minutes, every 5 minutes, etc.) in response to establishing a communication connection with a different device (e.g., when computing device 106 establishes a wireless connection with wearable glucose monitoring device 104 to retrieve one or more of the measurements). This functionality is discussed in more detail in connection with FIG. 2, along with further aspects of the configuration of the wearable glucose monitoring device 104.

[0023] Furthermore, the wearable glucose monitoring device 104 transmits glucose measurements 114 to the computing device 106 via a wireless connection or the like. The wearable glucose monitoring device 104 can transmit these measurements in real time, for example, when they are generated using a glucose sensor. Alternatively or additionally, the wearable glucose monitoring device 104 can transmit glucose measurements 114 to the computing device 106 at set time intervals. For example, the wearable glucose monitoring device 104 can be configured to transmit glucose measurements 114 to the computing device 106 every 5 minutes (when those measurements are being generated). The time interval at which glucose measurements 114 are transmitted may differ from the above example without deviating from the spirit or scope of the technique described herein. These measurements may be transmitted to the computing device 106 by the wearable glucose monitoring device 104 according to other basis of the technique described herein, such as based on a request from the computing device 106. In any case, the computing device 106 can at least temporarily store the glucose measurement values ​​114 of person 102, for example, in the computer-readable storage medium of the computing device 106.

[0024] In addition to the glucose measurement value 114, the wearable glucose monitoring device 104 can generate and transmit supplemental sensor information (not shown) to the computing device 106, for example, via a wireless connection. The wearable glucose monitoring device 104 can transmit this information together with the glucose measurement value 114 when the glucose measurement value 114 is transmitted, and thus the supplemental sensor information as well. Alternatively or additionally, the wearable glucose monitoring device 104 can transmit supplemental sensor information to the computing device 106 at set time intervals, and this supplemental sensor information may or may not match the glucose measurement value 114 when it is transmitted to the computing device 106. The supplemental sensor information may be transmitted to the computing device 106 according to various other criteria, and it should be understood that this supplemental sensor information may or may not match the glucose measurement value 114 when it is transmitted to the computing device 106, without deviating from the spirit or scope of the technique described herein.

[0025] Supplemental sensor information can correspond to various types of information that supplement the glucose measurement value 114 according to the techniques described herein. For example, supplemental sensor information may include information describing the state of one or more sensors of the wearable glucose monitoring device 104, for example, one or more states indicating whether one or more sensors are operating within a normal (e.g., predicted) operating threshold and / or whether one or more sensors are not operating normally. In addition to information describing sensor operation, supplemental sensor information may describe the operation and / or status of one or more other components of the wearable glucose monitoring device 104, some examples of which may include the battery state, the state of the transmitter or receiver for sending and receiving communications, and information about communications being sent and / or received. Additionally or alternatively, supplemental sensor information may include notifications (e.g., alerts and / or alarms) triggered by the onboard logic of the wearable glucose monitoring device 104 (e.g., implemented in hardware, firmware, and / or software) based on the glucose measurement value 114 generated by the wearable glucose monitoring device 104. Such supplemental sensor information can describe various other aspects related to the glucose measurement value 114 and the operation of the wearable glucose monitoring device 104 without departing from the spirit or scope of the technique described herein.

[0026] Although the computing device 106 is exemplified as a mobile device (e.g., a mobile phone), it can be configured in a variety of ways without departing from the spirit or scope of the techniques described herein. For example, the computing device 106 may be configured as a different type of mobile device (e.g., a wearable device or a tablet device), a desktop computer, or a laptop computer, among other form factors. In one or more embodiments, the computing device 106 may be configured as a dedicated device associated with the glucose monitoring platform 110, which has functions such as, for example, acquiring glucose measurements 114 from a wearable glucose monitoring device 104, performing various calculations related to the glucose measurements 114, displaying information related to the glucose measurements 114 and the glucose monitoring platform 110, and transmitting the glucose measurements 114 to the glucose monitoring platform 110.

[0027] Furthermore, the computing device 106 can represent two or more devices using the techniques described herein. In one or more scenarios, for example, the computing device 106 can represent both a wearable device (e.g., a smartwatch) and a mobile phone. In such scenarios, both of these devices may be capable of performing at least some of the same operations, such as retrieving glucose measurements 114 from a wearable glucose monitoring device 104, transmitting those measurements to a glucose monitoring platform 110 via a network 112, and displaying information related to the glucose measurements 114. Alternatively or additionally, different devices may have different capabilities that other devices do not have or that are limited to devices specified through computing instructions.

[0028] In a scenario where computing device 106 corresponds to a separate smartwatch and mobile phone, for example, the smartwatch may be configured with various sensors and functions for measuring various physiological markers of person 102 (e.g., heart rate, heart rate variability, respiration, blood flow velocity, etc.) and activity (e.g., walking or other exercise). In this scenario, the mobile phone may not be configured with these sensors and functions, or may include a limited amount of such functions. However, in other scenarios, the mobile phone may be able to provide the same functions. Continuing with this particular scenario, the mobile phone may have capabilities that the smartwatch does not, such as a camera for capturing images associated with glucose monitoring, and a certain amount of computing resources (e.g., battery and processing speed) that enable the mobile phone to perform calculations related to glucose measurements 114 more efficiently. Even in scenarios where the smartwatch can perform such calculations, computing instructions can be limited to the mobile phone to perform those calculations, thereby avoiding burdening both devices and efficiently utilizing available resources. To this extent, the computing device 106 can be configured in a manner different from that described herein and represent a different number of devices without departing from the spirit and scope of the techniques described herein.

[0029] According to the described technique, the computing device 106 includes a glucose monitoring application 116. Generally, the glucose monitoring application 116 is configured to perform various activities related to glucose monitoring. Examples of these activities include, but are not limited to, preparing a wearable glucose monitoring device 104 for the insertion and generation of glucose measurements 114 (e.g., via the exchange of various electronic communications), obtaining glucose measurements 114 and supplemental sensor information from the wearable glucose monitoring device 104, monitoring the operational health of the glucose monitoring device 104, displaying information about monitored glucose (e.g., a time-series plot of glucose measurements 114 for person 102) at the output of a user interface (e.g., display) via the computing device 106, and displaying decision support information (e.g., a digital coach, social characteristics related to glucose monitoring and management, educational information, etc.) at the output of a user interface or user interface element via the computing device 106.

[0030] In one or more embodiments, the glucose monitoring application 116 is configured to process glucose measurements 114 to identify events associated with glucose monitoring, such as blood glucose events (e.g., hyperglycemia and hypoglycemia) and predicted blood glucose events (e.g., upcoming hypoglycemia or upcoming hyperglycemia). To process glucose measurements 114 to identify such events, the glucose monitoring application 116 may utilize an event engine 120. This event engine 120 receives glucose measurements 114 as input, processes those measurements according to underlying logic (e.g., heuristic rules, one or more machine learning models, and / or threshold comparisons), and can output an instruction indicating the identified event when an event has been identified according to its processing. In response to the event engine 120 outputting an event, the event engine 120 and / or the glucose monitoring application 116 may record the event in an event log 122.

[0031] For example, alerts and alarms may correspond to one or more event types identified by the event engine 120 and output for recording in the event log 122. Generally, alerts and alarms may be triggered for dangerous or potentially dangerous health conditions identified and output for recording by the event engine 120. In relation to the event engine 120 that outputs alert or alarm events, the glucose monitoring application 116 may be configured to produce an alert or alarm signal output (e.g., notify the user of the condition) via the computing device 106 or some other device. The alert or alarm signal may be output via a display (e.g., via the display device of the computing device 106), via an audible component, and / or via a haptic feedback component, to name a few. The alert event log 124 may correspond to one of several records that make up the event log 122 and may be configured to retain alert and alarm events identified and output by the event engine 120 for an extended period. According to the technique described herein, the alert event log 124 contains a history of alerts and / or alarms triggered by the event engine 120 and entered into the alert event log 124. According to the technique described herein, a given alert or alarm triggered by the event engine 120 may have a corresponding entry in the alert event log 124.

[0032] In the illustrated example, the computing device 106 includes a storage device 118. This storage device 118 is illustrated to store glucose measurement values ​​114 and an event record 122, including an alert event record 124. It should be understood that the storage device 118 can store various data associated with glucose monitoring, such as supplemental sensor information, without departing from the spirit or scope of the technique described herein. Furthermore, the storage device 118 can also represent one or more databases, as well as other types of storage devices that can store glucose measurement values ​​114 and event records 122.

[0033] In one or more embodiments, the glucose monitoring application 116 can transmit glucose measurements 114, event records 122 (or a portion thereof), and other information (e.g., supplemental sensor information) to the glucose monitoring platform 110. This may be referred to as information “written” to the glucose monitoring platform 110. The glucose monitoring platform 110 can process and store glucose measurements 114 and event records 122 of person 102, as well as glucose measurements 114 and event records 122 of users in a user group 108, in relation to various functions. According to the techniques described herein, for example, the glucose monitoring platform 110 can utilize the glucose measurements 114 and event records 122 of person 102 and user group 108 to identify abnormal behavior in one or more computing environments, such as a specific version of an operating system and / or abnormal behavior of the glucose monitoring application 116 on a mobile device of a specific brand.

[0034] The anomaly detection system 126 is configured to detect abnormal behavior by acquiring at least glucose measurements 114 and event records 122, and by processing them using one or more anomaly detection techniques. In one or more embodiments, the glucose monitoring platform 110 stores glucose measurements 114, event records 122, and supplemental sensor information of person 102 and user population 108 in a storage device 128. Similar to the storage device 118, the storage device 128 can also represent one or more databases and other types of storage devices capable of storing such information. In connection with detecting anomalies, the anomaly detection system 126 can acquire one or more of the glucose measurements 114 and event records 122 from the storage device 128. The anomaly detection system 126 can then detect anomalies, in part, by using an event engine simulator 130.

[0035] In general, the event engine simulator 130 is a replica of the event engine 120. As used herein, the term “replica” means a configuration that enables the event engine simulator 130 to generate a simulated event in response to receiving the same glucose measurement values ​​114 as the event engine 120, in a scenario in which the event engine 120 is configured to generate an event. For example, in a scenario in which a particular set of glucose measurement values ​​indicates an impending adverse health condition, and the event engine 120 is configured to generate an event (e.g., an alert) in response to receiving that particular set of glucose measurement values ​​as input, the event engine simulator 130 is configured to generate a simulated event (e.g., an alert) in response to receiving that particular set of glucose measurement values ​​as input. The event engine simulator 130 may also be configured to generate simulated events for different scenarios related to glucose monitoring (e.g., in addition to alerts and alarms), in which case the event engine 120 may be configured to generate events for different scenarios related to glucose monitoring.

[0036] To simulate the events generated by the event engine 120, the event engine simulator 130 may be implemented using the same or similar logic (or a portion of the same or similar logic). As a non-limiting example, the event engine simulator 130 may be implemented using at least some of the same or similar source code as the event engine 120, at least some of the same or similar executable code as the event engine 120, at least some of the same or similar sets of rules used by the event engine 120, at least some of the same or similar models (e.g., machine learning models) used by the event engine 120, etc. It should be understood that the event engine simulator 130 can be configured in various ways to simulate the processing and output of the event engine 120 in order to simulate the behavior of the event engine 120, without departing from the spirit or scope of the techniques described herein.

[0037] However, in contrast to the event engine 120, the event engine simulator 130 can operate in a controlled simulation environment, for example, during scheduled simulations (e.g., daily) on the glucose monitoring platform 110, rather than operating in real time as part of the computing device 106 where the glucose monitoring application 116 could "compete" with other applications on the computing device 106 for computing resources. The event engine 120 may be configured to process glucose measurements 114 from a person 102 when those measurements are received from the wearable glucose monitoring device 104. During operation, the wearable glucose monitoring device 104 may be configured to send glucose measurements 114 to the computing device 106 at substantially predetermined time intervals, for example, once every 5 minutes. In general, despite being configured to transmit measurements at predetermined time intervals, the glucose monitoring application 116, and therefore the event engine 120, may, for various reasons, fail to receive one or more of those measurements at their scheduled transmission time. For example, one or more measurements may not be received at their scheduled time due to signal loss between the computing device 106 and the wearable glucose monitoring device 104 (but may be received later). In scenarios where the event engine 120 does not receive those glucose measurements 114 on schedule, the event engine 120 cannot generate a specific event, for example, it cannot generate an alert or alarm when measurements corresponding to a blood glucose event (e.g., hypoglycemia or hyperglycemia) are not received on schedule. When an event is not generated or output by the event engine 120, the event engine 120 also cannot record that event in the event log 122. Therefore, such events may be "missing" by the event engine 120 and "missing" from the event log 122.

[0038] While signal loss is described as one cause of a missing event, the event engine 120 may miss events for various other reasons without deviating from its intent or scope, which may in some cases be due to contention for resources on the computing device 106. For example, the operating system of the computing device 106 may run the glucose monitoring application 116 in the background for one or more other applications, so that one or more other applications have priority over the computing resources of the computing device 106. Alternatively or additionally, the operating system of the computing device 106 may prevent events output by the event engine from being recorded in the event log 122 while in operation. Alternatively or additionally, the provider of the operating system of the computing device 106 may change how resources are allocated between versions of the operating system. For this reason, the glucose monitoring application 116 may not be configured at the time of distribution to access those resources in a way that causes the event engine 120 to continue processing glucose measurements 114 for each single scheduled transmission time. The event engine 120 may also miss events due to user actions such as closing the glucose monitoring application 116, powering off or restarting the computing device 106, or turning off a communicative connection (e.g., Bluetooth or other wireless connection with the wearable glucose monitoring device 104). The event engine 120 may also miss events due to failures in the computing environment of the computing device 106, generally such as crashes, malfunctions, executable code or memory corruption, or malware. It should be understood that the above reasons are only a few of the reasons why the event engine 120 may miss events, and furthermore, the event engine 120 may miss events for different reasons without deviating from the intent or scope of the techniques described herein.

[0039] Deploying the event engine 120 as part of the environment of computing device 106 to process data when glucose monitoring-related data is received, while competing with other applications for the resources of computing device 106, is in contrast to the operation of the event engine simulator 130. For example, the environment in which the event engine simulator 130 is deployed can generally be controlled (e.g., by an anomaly detection system 126) to eliminate sources of events that are missing in relation to the simulation. As an example, instead of receiving data when it is generated and transmitted by person 102's wearable glucose monitoring device 104, the event engine simulator 130 can retrieve data from the storage device 128 for person 102, and even for users of a user group 108 that may reach thousands, hundreds of thousands, millions, or more. Furthermore, the event engine simulator 130 can be configured to access large amounts of historical data from the storage device 128 for the simulation, for example, data for person 102 and user group 108 over the previous nine weeks. Furthermore, before the data is provided to the event engine simulator 130, any missing data may be interpolated and incorporated, so that all the data for each period, for example, glucose measurements 114, are provided as input to the event engine simulator 130.

[0040] Furthermore, the anomaly detection system 126 can allocate computing resources (e.g., processing cycles, memory, etc.) to the event engine simulator 130 while it processes glucose measurements 114 of person 102 and user group 108 to identify glucose-related events for person 102 and user group 108, for example, while the event engine simulator 130 simulates events. Through control of the simulation environment, the anomaly detection system 126 enables the event engine simulator 130 to generate simulated events for actual events generated by the event engine 120, as well as for events that were missing from the event engine 120. Missing events can be determined by comparing the events simulated by the event engine simulator 130 with actual events generated by the event engine 120 and recorded in the event record 122. As will be described in more detail below, the anomaly detection system 126 can then determine whether the determined missing events in a given period are anomaly in light of past missing events determined in preceding periods. Consider the following explanation in Figure 2 in the context of, for example, continuously measuring glucose and obtaining data that describes such measurements.

[0041] Figure 2 shows a more detailed example 200 of an embodiment of the wearable glucose monitoring device 104 of Figure 1. In particular, the illustrated example 200 includes a top view and a corresponding side view of the wearable glucose monitoring device 104. It should be understood that the wearable glucose monitoring device 104 can be modified in various ways in the embodiments described below without departing from the spirit or scope of the techniques described herein. As mentioned above, for example, abnormal computing environment behavior can be detected using glucose in conjunction with other types of devices for glucose monitoring, such as non-wearable devices (e.g., blood glucose meters requiring finger prick), patches, etc.

[0042] In this example 200, the wearable glucose monitoring device 104 is illustrated to include a sensor 202 and a sensor module 204. Here, the sensor 202 is shown in a side view, for example, inserted subcutaneously in the skin 206 of a person 102. The sensor module 204 is shown as a dashed rectangle in a top view. The wearable glucose monitoring device 104 also includes a transmitter 208 in the illustrated example 200. The use of a dashed rectangle for the sensor module 204 indicates that the sensor module may be housed within the housing of the transmitter 208 or otherwise mounted. In this example 200, the wearable glucose monitoring device 104 further includes an adhesive pad 210 and a mounting mechanism 212.

[0043] During operation, the sensor 202, adhesive pad 210, and mounting mechanism 212 may be assembled to form an application assembly, which is configured to be applied to the skin 206 so that the sensor 202 is subcutaneously inserted as depicted. In such a scenario, the transmitter 208 may be attached to the assembly after being attached to the skin 206 via the mounting mechanism 212. Alternatively, the transmitter 208 may be incorporated as part of the attachment assembly, so that the sensor 202, adhesive pad 210, mounting mechanism 212, and transmitter 208 (having sensor module 204) can all be attached to the skin 206 at once. In one or more embodiments, this attachment assembly is attached to the skin 206 using a separate sensor attachment (not shown). Unlike the finger puncture required by conventional blood glucose meters, the user-initiated attachment of the wearable glucose monitoring device 104 is virtually painless and does not require blood sampling. Furthermore, the automated sensor attachment device generally allows a person 102 to implant the sensor 202 subcutaneously in the skin 206 without the assistance of a clinician or healthcare provider.

[0044] This adhesive assembly can also be removed by peeling the adhesive pad 210 from the skin 206. It should be understood that, as illustrated, the wearable glucose monitoring device 104 and its various components are simply one exemplary form factor, and the wearable glucose monitoring device 104 and its components may have different form factors without departing from the spirit or scope of the technique described herein.

[0045] During operation, the sensor 202 is communicatively coupled to the sensor module 204 via at least one communication channel, which can be wireless or wired. Transmission from the sensor 202 to the sensor module 204, or from the sensor module 204 to the sensor 202, can be carried out actively or passively, and these transmissions can be continuous (e.g., analog) or discrete (e.g., digital).

[0046] Sensor 202 may be a device, molecule, and / or chemical substance that changes or causes a change in response to an event that is at least partially independent of sensor 202. Sensor module 204 is implemented to receive indications of changes to sensor 202 or indications of changes caused by sensor 202. For example, sensor 202 may include glucose oxidase, which reacts with glucose and oxygen to form hydrogen peroxide that is electrochemically detectable by sensor module 204, which may include electrodes. In this example, sensor 202 may be configured as a glucose sensor, or may include a glucose sensor, configured to detect an analyte in blood or interstitial fluid that indicates a glucose level using one or more measurement techniques. In one or more embodiments, sensor 202 may also be configured to detect an analyte in blood or interstitial fluid that indicates other markers, such as lactate levels, which can improve accuracy in identifying or predicting glucose-based events. Additionally or alternatively, the wearable glucose monitoring device 104 may include additional sensors to sensor 202 for detecting those analytes that indicate other markers.

[0047] In another example, sensor 202 (or additional sensors not shown in the wearable glucose monitoring device 104) may include first and second conductors, and sensor module 204 may electrically detect changes in potential across its first and second conductors. In this example, sensor module 204 and sensor 202 are configured as thermocouples such that the change in potential corresponds to a change in temperature. In some examples, sensor module 204 and sensor 202 are configured to detect a single analyte, e.g., glucose. In other examples, sensor module 204 and sensor 202 are configured to detect multiple analytes, e.g., sodium, potassium, carbon dioxide, and glucose. Alternatively or additionally, the wearable glucose monitoring device 104 may include multiple sensors for detecting not only one or more analytes (e.g., sodium, potassium, carbon dioxide, glucose, and insulin) but also one or more environmental conditions (e.g., temperature). Therefore, the sensor module 204 and sensor 202 (and any additional sensors) can detect the presence of one or more analytes, the absence of one or more analytes, and / or changes in one or more environmental conditions.

[0048] In one or more embodiments, the sensor module 204 may include a processor and memory (not shown). The sensor module 204 can utilize the processor to generate glucose measurement values ​​114 based on communication with the sensor 202 exhibiting the changes described above. Based on these communications from the sensor 202, the sensor module 204 is further configured to generate a transmittable data package containing at least one glucose measurement value 114. In one or more embodiments, the sensor module 204 may configure its packages to include additional data, including supplemental sensor information 214, as an example (not limited to), such supplemental sensor information may correspond to supplemental sensor information described in relation to Figure 1 but not illustrated. Such supplemental sensor information may include any combination of information described in relation to Figure 1, a sensor identifier, sensor status, temperature corresponding to the glucose measurement value 114, and measurements of other analytes corresponding to the glucose measurement value 114. It should be understood that the supplemental sensor information 214 may include various data supplementing at least one glucose measurement value 114 without departing from the spirit or scope of the techniques described herein.

[0049] In embodiments where the wearable glucose monitoring device 104 is configured for wireless transmission, the transmitter 208 can wirelessly transmit glucose measurements 114 and / or supplemental sensor information 214 as a data stream to a computing device. Alternatively or additionally, the sensor module 204 may buffer the glucose measurements 114 and / or supplemental sensor information 214 (for example, in the memory of the sensor module 204 and / or other physical computer-readable storage medium of the wearable glucose monitoring device 104) and later have the transmitter 208 transmit the buffered glucose measurements 114 and / or buffered supplemental sensor information 214 at various intervals, for example, time intervals (every second, every 30 seconds, every minute, every 5 minutes, every hour, etc.), storage intervals (when the buffered glucose measurements 114 and / or supplemental sensor information 214 reach a threshold amount of data or a number of measurements), etc.

[0050] Having considered examples of environments and wearable glucose monitoring devices, we now consider a description of some examples of techniques for detecting anomalous computing environment behavior using glucose, using one or more embodiments.

[0051] Detection of anomalous computing environment behavior using glucose Figure 3 shows an example 300 of a system in which the anomaly detection system of Figure 1 detects abnormal behavior in a computing environment by simulating events. This illustrated example 300 is shown in Figure 1 to include an anomaly detection system 126 having an event engine simulator 130 and receiving glucose measurements 114 and event records 122 as inputs.

[0052] In illustrated example 300, the anomaly detection system 126 further includes a comparison module 302, a model manager 304, and an anomaly detection model 306 to detect abnormal behavior 308 in the computing environment. While the anomaly detection system 126 is illustrated with these various components, it should be understood that in embodiments, the anomaly detection system 126 may include fewer, more, and / or different components without departing from the spirit or scope of the techniques described herein.

[0053] According to the technique described herein, the event engine simulator 130 is configured to generate a simulated event 310. In this example 300, the event engine simulator 130 is shown to receive glucose measurement values ​​114 as input, but in one or more embodiments, the event engine simulator 130 can receive additional or different data as input to generate a simulated event 310. For example, the event engine simulator 130 can additionally or alternatively receive supplemental sensor information 214 and / or other information (e.g., health tracking information, application usage data, user profile information) to generate a simulated event 310.

[0054] In any case, the event engine simulator 130 is configured in one or more embodiments to process glucose measurements 114 and generate simulated events 310 based on the processing of those glucose measurements 114. According to the technique described herein, the event engine simulator 130 can, in operation, obtain glucose measurements 114 for person 102 and for a user population 108 or a subset of the user population 108. For example, the event engine simulator 130 can obtain glucose measurements 114 for a subset of the user population 108 that meet specified criteria.Such criteria include, but are not limited to, the type of computing device on which the glucose monitoring application 116 runs (e.g., mobile phone, smartwatch, tablet, dedicated glucose monitoring device, etc.), the manufacturer and / or model of the computing device on which the glucose monitoring application 116 runs (e.g., Apple® iPhone 12, Samsung® Galaxy, Google® Pixel Phone). 5, etc.), the operating system of the computing device on which the glucose monitoring application 116 runs (e.g., iOS, Android, etc.), the version of the operating system, the type of communicative coupling with the wearable glucose monitoring device 104 (e.g., Bluetooth, 5G, NFC, etc.), the status of the communicative coupling with the wearable glucose monitoring device 104, identification information of the server that provides one or more services (of the glucose monitoring platform 110) to the glucose monitoring application 116 via the network 112, the status of the server that provides one or more services to the glucose monitoring application 116, the identifier of the hardware associated with the computing device 106 (e.g., onboard and / or communicatively coupled), the identifier of the software of the computing device 106 (e.g., including other applications), the manufacturer and / or model of the glucose monitoring device (e.g., Dexcom® G5, Dexcom® G6, Dexcom® G7, Abbott® Freestyle Libre, Abbott® Freestyle Libre) 2) This may include the manufacturing lot of the glucose monitoring device (or components of the glucose monitoring device), user demographics, user location, and version of the glucose monitoring application 116. Therefore, it should be understood that the event engine simulator 130 can acquire data for a subset of user populations 108, selected based on the specifications of one or more of the various criteria, without deviating from the spirit or scope of the techniques described herein.

[0055] As described above, the event engine simulator 130 is configured to process glucose measurements 114, identify or predict glucose-related events in glucose, and output simulated events 310 in response to the identification or prediction of such glucose-related events. According to the technique described herein, the event engine simulator 130 is configured to identify or predict events and output simulated events 310 based on the fact that the event engine 120 is configured to process a series of glucose measurements 114, which identify or predict events and record those events in the event record 122. This ability of the event engine simulator 130 to simulate the event engine 120 is based on the configuration of the event engine simulator 130, which allows the event engine simulator to simulate the event engine 120 for one or more types of recordings, i.e., the event engine simulator 130 may, in some embodiments, be configured to simulate the capabilities of the event engine 120 to generate simulated alert events, but not to simulate related events in a pause state. As described above in relation to the illustrated Example 100, for example, the event engine simulator 130 may be configured to simulate the event engine based on embodiments that use at least some of the same or similar source code as the event engine 120, at least some of the same or similar executable code as the event engine 120, at least some of the same or similar rule sets used by the event engine 120, at least some of the same or similar models (e.g., machine learning models) used by the event engine 120, etc. It should be understood that the configuration of the event engine simulator 130 is updated over time so that the event engine simulator 130 can simulate many more behaviors of the event engine 120, for example, it can generate simulated events 310 for many more events generated by the event engine 120.

[0056] However, it should be understood that in one or more embodiments, the event engine simulator 130 may be configured not to simply generate simulated events 310 for all event types in which the event engine 120 is configured to generate events. Alternatively or additionally, the event engine simulator 130 may be configured to generate simulated events 310 for only one or more specified types of events, and not generate them for unspecified event types. Simulated event generation may be limited in these ways because users of the anomaly detection system 126 (e.g., developers associated with the glucose monitoring platform 110) may have little or no use for one or more events (or types of events) generated by the event engine 120, even if they exist. Furthermore, since the event engine 120 is configured to generate events during simulations using data from the user group 108 (or even a subset of the user group 108), simulating all of the desired events may require a certain amount of computing resources (e.g., processing cycles and / or memory) that would interfere with the provision of other services of the glucose monitoring platform 110 and / or incur costs exceeding those of the business associated with the glucose monitoring platform 110.

[0057] In any case, the event engine simulator 130 can process glucose measurements 114 to identify various events and generate simulated events 310 in response to these identifications. The simulated events 310 can then be compared with actual events generated by the event engine 120 and recorded in the event record 122, from which "missing events" can be determined. The anomaly detection model 306 can then process these missing events to determine whether the missing events determined over a given period are anomalies compared to past missing events.

[0058] As an example, the event engine simulator 130 is configured in one or more embodiments to generate simulated events 310 to simulate alerts and alarms generated by the event engine 120, so that, for example, abnormal behavior 308, if present, can be determined over a given period in relation to the alerts and alarms. As described above, actual events generated and recorded by the event engine 120 remain in the event record for a longer period, and consequently, alerts and alarms generated and recorded by the event engine 120 remain in the alert event record 124 for a longer period. In this example 300, the alerts and alarms actually recorded in the alert event record 124 are shown as recorded alerts 312. It should be understood that the glucose measurements 114, event record 122, alert event record 124, and recorded alerts 312 shown in this example 300 may correspond to data from each user of a user group 108 being considered for a given simulation. In other words, the event engine simulator 130 can receive glucose measurements 114 for each user that are considered in relation to a given simulation, and the comparison module 302 can receive alert event records 124 for each user that are considered in relation to a given simulation.

[0059] Generally speaking, the comparison module 302 determines missing events by comparing simulated events 310 with recorded events. In an example where simulated events 310 are generated for alerts and alarms, the comparison module 302 is configured to compare the simulated events 310, which represent the alerts and alarms that should have been generated by the event engine 120, with the recorded alerts 312, i.e., the alerts and alarms that were actually generated and recorded by the event engine 120. The comparison module 302 can compare simulated events 310 with recorded events in a variety of ways without departing from the spirit or scope of the techniques described herein. As an example that is not limited, the comparison module 302 can take a first event from the simulated events 310 and repeat it across events in the event log 122 to determine whether the actual event corresponding to the first event is included in the event log 122. If the actual event corresponding to the first event is included in the event record, the comparison module 302 can proceed by extracting the second event from the simulated event 310 and repeating this process across the events in the event record 122 to determine whether the actual event corresponding to the second event is included in the event record.

[0060] However, if the actual event corresponding to the first event is not included in the event log 122, the comparison module 302 may determine that the first event corresponds to a “missing event” from the event log 122. The comparison module 302 may output the missing events, or otherwise maintain a record of the missing events, for example, a counter that increments each time a missing event is determined, a reference (e.g., a list of identifiers) to each of the simulated events 310 that have been determined to be missing from the event log 122, and / or a list of the determined missing events (e.g., including details of the events similar to how they were recorded by the event engine 120). The comparison module 302 may process each of the simulated events 310 in a similar manner to determine whether or not they are included in the event log 122. The comparison module 302 may compare the simulated events 310 with the event log 122 in other ways without departing from the spirit or scope of the technique described herein. Continuing with examples of alerts and alarms, where the event engine simulator 130 generates simulated events 310 for alerts and alarms, for example, the comparison module 302 can simply compare several simulated events 310 with several recorded alerts 312 over the same period. Alternatively or additionally, the comparison module 302 can determine missing events using one or more sampling techniques.

[0061] As described above, the comparison module 302 is configured to output missing events or some indication of such missing events, which may include a timestamp indicating the approximate time when the event engine 120 should have generated and / or recorded the event in the event log 122, or otherwise be associated with such a timestamp. In this example 300, the comparison module 302 is illustrated to output, for example, a first missing event 314 and a second missing event 316, which are determined based on comparing a simulated event 310 with a recorded alert 312. Thus, the first missing event 314 and the second missing event 316 may correspond to missing alerts and / or alarms in this example 300. In scenarios where the anomaly detection system 126 is determining anomalies for other types of events, the first missing event 314 and the second missing event 316 may correspond to those other types of events that have been determined to be missing.

[0062] According to the technique described herein, a first missing event 314 may correspond to a simulated event associated with a time within a first period, and a second missing event 316 may correspond to a simulated event associated with a time within a second period, where the first period precedes the second period. In one or more embodiments, glucose measurements 114 and events recorded in the event record 122 may be configured as chronological data, for example, they may be configured as time-series data. Based on this, the simulated event 310, as well as the first missing event 314 and the second missing event 316, may also be configured as chronological data, for example, as time series. Chronological means that the data (e.g., each measurement, event, and / or record) may be indexed or listed in chronological order, or otherwise associated with a specific time (e.g., according to an associated timestamp).

[0063] In any case, the first missing event 314 may correspond to a time preceding a certain point in time, and the second missing event 316 may correspond to that point in time and / or the time following that point in time. In one or more embodiments, the point in time may correspond to a past time, for example, not the current time when the anomaly detection model 306 is actually used and processes the data to determine the anomaly behavior 308. For example, the anomaly detection system 126 may be deployed to detect the anomaly behavior 308 over a period of interest (e.g., one week) preceding the current time. In this example, the anomaly detection model 306 may be further configured to detect the anomaly behavior 308 over the period of interest based on a past period preceding the period of interest, for example, eight weeks preceding the week of interest. Thus, the point in time in this example used to separate the first missing event 314 from the second missing event 316 may correspond to one week before the current time.

[0064] Consider an example where the anomaly detection model 306 determines anomaly behavior 308 over preceding weeks based on events in the eight weeks prior to the current week. In this example, the first missing event 314 may correspond to weeks 2-9, and the second missing event 316 may correspond to week 1, where week 9 is the past week furthest from the current time, and week 1 is the past week closest to the current time. While this example certainly describes a time span of several weeks, the anomaly detection model 306 may be configured to determine anomaly behavior 308 based on different time periods, such as days (e.g., determining anomaly behavior over a given day based on one or more past days preceding that day), hours (e.g., determining anomaly behavior over a given time based on one or more past times preceding that time), minutes, months, and quarters, to give a few examples. Without departing from the spirit or scope of the technique described herein, the anomaly detection model 306 can determine anomaly behavior 308 over various time periods and from different amounts of time preceding such periods (e.g., it is not limited to an 8:1 ratio).

[0065] Generally, the model manager 304 is configured to generate an anomaly detection model 306, or otherwise train it. In particular, the model manager 304 can generate an anomaly detection model, or otherwise train it, based on a first set of historical data in chronological order, for example, a first missing event 314. When the model manager 304 generates an anomaly detection model 306, it is configured to determine whether an anomaly exists in a second set of historical data, for example, whether an anomaly exists in a second missing event 316. In one or more embodiments, the model manager 304 generates an anomaly detection model 306 based on a first set of historical data to model the predicted range of non-anomalous behavior. In the context of missing events, for example, the model manager 304 can generate an anomaly detection model 306 based on a first missing event 314 to model the predicted range (e.g., per day) of non-anomalous missing events.

[0066] As part of determining anomalous behavior 308, the anomaly detection model 306 can process a second set of time-sequential data to determine which observed behaviors, when described by the second set of time-sequential data, fall within the prediction range of the anomaly detection model 306, and therefore are not anomalous. The anomaly detection model 306 can also determine which observed behaviors, when described by the second set of time-sequential data, fall outside the prediction range of the anomaly detection model 306, and therefore are anomalous. In response to processing data determined to be outside the prediction range, the anomaly detection model 306 outputs anomalous behavior 308. In the context of missing events, a missing event described by a second missing event 316 (e.g., the number or percentage of missing events per day) that falls within the prediction range of the anomaly detection model 306 (e.g., also constitutes the number or percentage of missing events per day) is not anomalous. However, missing events described by a second missing event 316 (e.g., the number or percentage of missing events per day) that fall outside the prediction range of the anomaly detection model 306 (e.g., also consisting of the number or percentage of missing events per day) are considered anomalies. For these anomaly events, the anomaly detection model 306 outputs an anomaly behavior 308.

[0067] The model manager 304 can generate anomaly detection models 306 according to various algorithms. Generation using time-sequential data (e.g., time-series data) is described above and below, but in different embodiments, the anomaly detection model 306 may be implemented using algorithms that leverage non-time-sequential data, at least in part. However, in at least one embodiment that requires time-sequential data, the model manager 304 can configure the anomaly detection model 306 as a Prophet model. In the Prophet model embodiment, the model manager 304 can generate anomaly detection model 306, and as a result, to give a few examples, seasonal features observed in a first dataset (e.g., a first missing event 314) are represented using a Fourier series, holiday features observed in the first dataset (e.g., changes in behavior determined in relation to an event such as Thanksgiving) are represented using indicator features, and / or the model is fitted using Markov chain Monte Carlo sampling.

[0068] Generally, the Prophet model predicts future uncertainties based on the frequency and magnitude of change points, and as a result, if there are change points that deviate frequently and / or statistically significantly from the "mean" of the data (e.g., with respect to magnitude), the prediction range is wider (e.g., less certain) than if there are fewer and less significant deviations. However, in a relatively wide range, the anomaly detection model 306 may fail to detect as anomalies behaviors of the computing environment that could be better determined to be anomalies, such as behaviors that could pose a physical danger to the user of the glucose monitoring application 116 and / or the wearable glucose monitoring device 104 (e.g., missing alerts and alarms). Therefore, in one or more embodiments, the anomaly detection model 306 can be modified from the basic Prophet model embodiment to narrow the prediction range, for example, by setting a model parameter to zero that corresponds to the number of future change points (e.g., the number of change points that will occur during the period corresponding to the second dataset and subsequent datasets). Although abnormal behavior is described above and below as falling outside the prediction range, in one or more embodiments, the anomaly detection model 306 may detect anomalies in other ways, such as by detecting time-series data drift (e.g., upward or downward) (even if the data generally remains within the prediction range). It should be understood that the model manager 304 can configure the anomaly detection model 306 and detect anomalies in the computing environment based on glucose and using any of the various anomaly detection techniques, without deviating from the spirit or scope of the techniques described herein.

[0069] In addition to missing events, the anomaly detection model 306 may be configured to output indications of abnormal behavior 308 for various metrics associated with the wearable glucose monitoring device 104, the glucose monitoring application 116, and / or the glucose monitoring platform 110. Examples of these other metrics include, but are not limited to, glucose measurements (e.g., for detecting drift over time, or changes in the computing environment, and / or other anomalies that may occur due to different configurations of the wearable glucose monitoring device 104), crash count (e.g., of the glucose monitoring application 116, the computing device 106, and / or the server devices of the glucose monitoring platform), crash rate, number of writes per day (e.g., of glucose measurements 114 and event logs 122 from the computing device 106 to the glucose monitoring platform 110), and packet captures. This may include, for example, glucose measurements 114 transmitted from a wearable glucose monitoring device 104 to a computing device 106, the number of packets captured per user over a period (e.g., one day), the number of data writes per period (e.g., glucose measurements 114 and event logs 122) per day for a user group 108 to the glucose monitoring platform 110, the number of users in the user group 108 with language code errors, and the number or percentage of times users view the glucose trend screen of the glucose monitoring application 116 over a period (e.g., per day).

[0070] In one or more embodiments, the abnormal behavior 308 indicates which data in the second dataset is abnormal, for example, which of the second missing events 316 constitutes the abnormal behavior 308. For example, the abnormal behavior 308 may indicate which day corresponding to the second missing event 316 has an abnormal missing event that is above or below the predicted range of the anomaly detection model 306. In response to the output of the abnormal behavior 308 by the anomaly detection model 306, the anomaly detection system 126 may output the abnormal behavior 308, or a notification of the abnormal behavior, to one or more users, for example, developers associated with the glucose monitoring platform 110. Without departing from the spirit or scope of the techniques described herein, the anomaly detection system 126 may output the abnormal behavior 308 and / or a notification of the abnormal behavior in various ways, such as sending an email to users designated to receive emails about the abnormal behavior, outputting a notification on the mobile devices of users designated to receive notifications about the abnormal behavior, or displaying a visualization of the abnormal behavior through the user interface of the anomaly detection system 126. In the context of displaying a user interface that visually communicates abnormal behavior 308, consider the following explanation of Figure 4.

[0071] Figure 4 shows an example of a user interface embodiment that displays a plot of observed behavior associated with the computing environment over time, and a visualization of the range of observed behavior that is not abnormal.

[0072] Example 400 includes a display device 402 that displays a user interface 404, which is associated with an anomaly detection system 126 according to the technique described herein and visually presents anomalies identified in data collected by, for example, a glucose monitoring platform 110. Certainly, anomaly behavior 308 may be presented in other ways according to the technique described herein, such as by emitting sound via an audible report.

[0073] Here, the user interface 404 includes a graph 406 that plots the indications for the first missing event 314 and the second missing event 316 over time. In particular, graph 406 plots the number of missing events per day, as indicated by the first missing event 314 and the second missing event 316. Event indications 408 and 410 are examples of indications for the first missing event 314 showing the number of missing events per day, and event indications 412 and 414 are examples of indications for the second missing event 316 showing the number of missing events per day. Thus, event indications plotted to the left of the anomaly detection time 416 (e.g., preceding in the time series) correspond to the first missing event 314, and therefore, event indications plotted to the right of the anomaly detection time 416 (e.g., following in the time series) correspond to the second missing event 316.

[0074] According to the techniques described herein, the anomaly detection model 306 is generated based on data associated with a time prior to the anomaly detection time 416. Furthermore, the anomaly detection model 306 is configured to determine anomalies in the data associated with a time after the anomaly detection time 416. In one or more embodiments, the anomaly detection model 306 is configured to determine anomalies in the data associated with the anomaly detection time 416, for example, as shown in illustrated example 400. Alternatively, the anomaly detection model may be generated based on data associated with the anomaly detection time 416.

[0075] In addition to the plotted event indications, graph 406 also includes a range visualization 418. This range visualization 418 corresponds to the range modeled by the anomaly detection model 306. In this example 400, the range visualization 418 includes a visualization of the predicted range 420, which corresponds to the portion of the range visualization 418 that follows (e.g., in time) the anomaly detection time 416. Generally, the anomaly detection model 306 uses the predicted range 420 to determine the anomaly behavior 308. In the illustrated example 400, data corresponding to indications outside the predicted range 420 are anomaly, and data corresponding to indications within the predicted range 420 are not anomaly. For this purpose, indications 422 and 424 correspond to anomaly behavior 308 because they are outside the predicted range 420. Furthermore, those indications 422 and 424 are further displayed along with visual indicators 426 and 428, which indicate that indications 422 and 424 correspond to anomaly behavior 308. Here, visual indicators 426 and 428 are illustrated as asterisks, but it should be understood that these indications can be highlighted in various ways to indicate abnormality without departing from the spirit or scope of the technique described herein. In one or more embodiments, indications that do not include visual indicators and for which abnormal behavior has been determined do not correspond to abnormal behavior.

[0076] In this example 400, the user interface 404 generally includes various means that may be user-selectable for performing various tasks in relation to the graph 406 and the determined abnormal behavior 308. For example, the user interface 404 may include means that, to name a few, the user can zoom in or out on the graph 406 (or a portion thereof), pan on the graph 406 (or a portion thereof or an unpresented portion), select various pieces of information on the graph (e.g., displayed instructions for presenting further information in relation to a selected instruction), share the graph 406 with one or more other users (e.g., via a link to a web page, via a web-based application, or in a message such as an email), and notify one or more users (e.g., via email) about the abnormal behavior. Certainly, the user interface for presenting the abnormal behavior 308 may be configured to include various means that enable different tasks to be performed in relation to the abnormal behavior 308 and its visualization, without departing from the spirit or scope of the techniques described herein.

[0077] Figure 5 shows an example 500 of a user interface embodiment that displays notifications of detected abnormal behavior.

[0078] In this example 500, computing device 502 is shown to display a user interface 504 (e.g., a lock screen) via display device 506 of computing device 502. Here, notification 508 is further presented via user interface 504. This notification 508 contains information about detected abnormal behavior, e.g., abnormal behavior 308. For example, an anomaly detection system 126 may display notification 508 on computing device 502 for a user associated with the anomaly detection system 126, e.g., a developer associated with glucose monitoring platform 110 who is designated to receive notifications about one or more types of detected abnormal behavior. The user may be notified about abnormal behavior 308 in various other ways (e.g., by email) without departing from the spirit or scope of the techniques described herein.

[0079] Having described typical details of a technique using glucose for detecting anomalous computing environment behavior, we now consider some example procedures to illustrate additional aspects of this technique.

[0080] Exemplary procedure This section describes an example of a procedure for detecting anomalous computing environment behavior using glucose. The aspects of the procedure may be implemented in hardware, firmware, software, or a combination thereof. The procedure is presented as a set of blocks specifying actions to be performed by one or more devices, and is not necessarily limited to the order in which the actions are performed by each block. In at least some embodiments, the procedure is performed by an anomaly detection system, such as an anomaly detection system 126, which uses an event engine simulator 130, a comparison model 302, a model manager 304, and an anomaly detection model 306.

[0081] Figure 6 shows step 600 in an example of an embodiment in which an anomaly detection model is generated based on missing events identified during a first period.

[0082] Glucose measurements collected by a wearable glucose monitoring device, and event records associated with those glucose measurements, are received during the first period (block 602). For example, the anomaly detection system 126 receives glucose measurements 114 and event records 122 collected by the wearable glucose monitoring device 104 as input during the first period.

[0083] Missing events from the event log are identified during the first period by processing glucose measurements using the event engine simulator (block 604). For example, the event engine simulator 130 of the anomaly detection system 126 processes glucose measurements 114 taken during the first period to generate a simulated event 310. The comparison module 302 of the anomaly detection system 126 then compares the simulated event 310 with recorded events in the event log 122 that were actually generated by the event engine of the glucose monitoring application associated with each wearable glucose monitoring device 104. In an example that is not limited to this, the comparison module 302 may take the first event from the simulated event 310 and iterate over the actual events stored in the event log 122 to determine whether the actual event corresponding to the first event is included in the event log 122. If the actual event corresponding to the first event is included in the event log 122, the comparison module 302 can proceed by retrieving the second event from the simulated event 310 and repeating this process across the events in the event log 122 to determine whether the actual event corresponding to the second event is included in the event log.

[0084] However, if the actual event corresponding to the first event is not included in the event log 122, the comparison module 302 may determine that the first event corresponds to the first missing event 314 from the event log 122. The comparison module 302 may, to give a few examples, output the first missing event 314, or otherwise maintain a record of the first missing event 314, such as a counter that increments each time a missing event is determined, a reference (e.g., a list of identifiers) to each of the simulated events 310 that have been determined to be missing from the event log 122, and / or a list of determined missing events (e.g., including details of the events similar to how they were recorded by the event engine 120). The comparison module 302 may process each of the simulated events 310 in a similar manner to determine whether or not they are included in the event log.

[0085] An anomaly detection model is generated based on missing events during a first period (block 606). According to the principles described herein, the anomaly detection model includes a predicted range of missing events during a second period. As an example, the model manager 304 of the anomaly detection system 126 is configured to generate an anomaly detection model 306, or otherwise train it. The model manager 304 can generate the anomaly detection model 306 according to various algorithms. In particular, the model manager 304 can generate an anomaly detection model, or otherwise train it, based on a first set of historical data in chronological order, for example, a first missing event 314. Once the model manager 304 generates the anomaly detection model 306, it is configured to determine whether an anomaly exists in a second set of chronological data, for example, whether an anomaly exists in a second missing event 316.

[0086] In the context of using an anomaly detection model to determine whether an anomaly exists in a second set of time-sequential data, consider Figure 7, which illustrates step 700 in an example embodiment of detecting anomaly behavior during a second period using the anomaly detection model generated in Figure 6.

[0087] Additional glucose measurements collected by a wearable glucose monitoring device, and additional event records associated with those additional glucose measurements, are received during the second period (block 702). For example, the anomaly detection system 126 receives glucose measurements 114 and event records 122 collected by the wearable glucose monitoring device 104 as input during the second period. In particular, the first period may precede the second period.

[0088] Missing events from the additional event log are identified during the second period by processing the additional glucose measurements using the event engine simulator (block 704). For example, similar to block 604 in Figure 6, the event engine simulator 130 of the anomaly detection system 126 processes the glucose measurements 114 acquired during the second period to generate a simulated event 310. The comparison module 302 of the anomaly detection system 126 then compares the simulated event 310 with the recorded event in the event log 122 that was actually generated during the second period by the event engine of the glucose monitoring application associated with each wearable glucose monitoring device 104. If the actual event corresponding to the simulated event 310 is not included in the event log 122, the comparison module 302 can determine that the simulated event corresponds to a second missing event 316 from the event log 122. The comparison module 302 can output the second missing event 316, or otherwise retain a record of the second missing event 316. In particular, the first missing event 314 can correspond to a time preceding a certain point in time, and the second missing event 316 can correspond to that point in time and / or the time following that point in time. Consider an example where the anomaly detection model 306 determines anomaly behavior 308 over the preceding weeks based on events in the eight weeks prior to that week, the first missing event 314 can correspond to weeks 2-9, and the second missing event 316 can correspond to week 1, where week 9 is the past week furthest from the current time, and week 1 is the past week closest to the current time.

[0089] Anomaly behavior is detected (block 706) when an identified missing event that is missing from additional event recordings during the second period falls outside the predicted range of the anomaly detection model for missing events. For example, the anomaly detection model 306 outputs anomaly behavior 308 in response to processing data that the model determines to be outside its predicted range. In the context of missing events, a missing event described by a second missing event 316 (e.g., the number or percentage of missing events per day) that falls within the predicted range of the anomaly detection model 306 (e.g., also constitutes the number or percentage of missing events per day) is not anomaly. However, a missing event described by a second missing event 316 (e.g., the number or percentage of missing events per day) that falls outside the predicted range of the anomaly detection model 306 (e.g., also constitutes the number or percentage of missing events per day) is anomaly. For these anomaly events, the anomaly detection model 306 outputs anomaly behavior 308.

[0090] Having described examples of procedures according to one or more embodiments, we now consider examples of systems and devices that may be used to implement the various techniques described herein.

[0091] Exemplary systems and devices Figure 8 shows an example of a system in general, 800, which includes an example of a computing device 802 representing one or more computing systems and / or devices capable of implementing various techniques described herein. This is illustrated by including an anomaly detection system 126 and a glucose monitoring platform 110. The computing device 802 may be, for example, a service provider's server, a device associated with a client (e.g., a client device), an on-chip device, and / or any other suitable computing device or computing system.

[0092] The computing device 802 as shown in the illustration includes a processing system 804, one or more computer-readable media 806, and one or more I / O interfaces 808 that are communicatively coupled to each other. Although not shown, the computing device 802 may further include a system bus or other data and command transfer system coupled to various components. The system bus may include any one or a combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of the various bus architectures. Various other examples, such as control lines and data lines, are also considered.

[0093] The processing system 804 represents a function for performing one or more operations using hardware. Therefore, the processing system 804 is exemplified as including hardware elements 810, which may be configured as a processor, a functional block, etc. This may include embodiments within the hardware as application-specific integrated circuits or other logic devices formed using one or more semiconductors. The hardware elements 810 are not limited by the materials on which they are formed or the processing mechanisms employed therein. For example, a processor may consist of semiconductors and / or transistors (e.g., electronic integrated circuits, ICs). In such a context, processor-executable instructions may be electronically executable instructions.

[0094] The computer-readable medium 806 is exemplified as including memory / storage 812. Memory / storage 812 represents memory / storage capacity associated with one or more computer-readable media. Memory / storage component 812 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disks, magnetic disks). Memory / storage component 812 may also include fixed media (e.g., RAM, ROM, fixed hard drives) and removable media (e.g., flash memory, removable hard drives, optical disks). The computer-readable medium 806 may be configured in various other ways, as further described below.

[0095] The input / output interface 808 represents a function that allows the user to input commands and information into the computing device 802, and that allows information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include keyboards, cursor control devices (e.g., mice), microphones, scanners, touch functions (e.g., capacitive sensors or other sensors configured to detect physical contact), and cameras (e.g., using visible wavelengths or invisible wavelengths such as infrared frequencies to recognize movement as non-contact gestures). Examples of output devices include display devices (e.g., monitors or projectors), speakers, printers, network cards, and haptic response devices. Thus, the computing device 802 can be configured in various ways to support user interaction, as further described below.

[0096] This specification may describe various techniques in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, etc., that perform a specific task or implement a specific abstract data type. As used herein, the terms “module,” “function,” and “component” generally refer to software, firmware, hardware, or a combination thereof. A characteristic feature of the techniques described herein is that they are platform-independent, meaning that these techniques can be implemented on a variety of commercial computing platforms with diverse processors.

[0097] Embodiments of the modules and techniques described may be stored in or transmitted through some form of computer-readable medium. The computer-readable medium may include a variety of media that can be accessed by the computing device 802. For example, but not limited to, the computer-readable medium may include "computer-readable storage media" and "computer-readable signaling media."

[0098] "Computer-readable storage medium" may refer to a medium and / or device that enables the permanent and / or non-temporary storage of information, as opposed to mere signal transmission, carrier waves, or signals themselves. Therefore, computer-readable storage medium refers to a non-signal transmission medium. Computer-readable storage medium includes hardware such as volatile and non-volatile, removable and non-removable media, and / or storage devices implemented in a manner or technique suitable for storing information such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Examples of computer-readable storage medium may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage, hard disk, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage devices, tangible media, or products suitable for storing desired information and accessible by a computer.

[0099] A “computer-readable signaling medium” may refer to a signal-carrying medium configured to transmit instructions to the hardware of a computing device 802 via a network or the like. A signaling medium may typically embody computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves, data signals, or other transport mechanisms. A signaling medium also includes any information-transmitting medium. The term “modulated data signal” means a signal having one or more of its characteristics set or modified in a manner that encodes information in the signal. Examples, though not limited to, include communication media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0100] As previously described, the hardware element 810 and the computer-readable medium 806 represent modules, programmable device logic, and / or fixed device logic implemented in hardware form, which, in some embodiments, can be employed to implement at least some aspects of the techniques described herein, such as for executing one or more instructions. Hardware may include components of integrated circuits or on-chip systems, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other embodiments in silicon or other hardware. In this context, hardware can operate as a processing device that executes program tasks defined by instructions and / or logic embodied by the hardware, as well as hardware used to store instructions for execution, such as the computer-readable storage medium described previously.

[0101] Various techniques described herein can be implemented using the aforementioned combinations. Thus, software, hardware, or executable modules may be implemented on some form of computer-readable storage medium and / or as one or more instructions and / or logic embodied by one or more hardware elements 810. Computing device 802 may be configured to implement specific instructions and / or functions corresponding to software and / or hardware modules. Therefore, embodiments of modules executable as software by computing device 802 may be achieved, for example, in hardware, at least partially, through the use of computer-readable storage medium and / or hardware elements 810 of processing system 804. Instructions and / or functions may be executable / operable by one or more manufactured articles (e.g., one or more computing devices 802 and / or processing system 804) for implementing the techniques, modules, and examples described herein.

[0102] The techniques described herein may be supported by various configurations of the computing device 802 and are not limited to specific examples of the techniques described herein. This functionality may also be implemented in whole or in part through the use of a distributed system, such as on a “cloud” 814 via platform 816, as described below.

[0103] This cloud 814 includes and / or represents a platform 816 for resources 818. Platform 816 extracts the underlying functions of the hardware (e.g., servers) and software resources of the cloud 814. Resources 818 may include applications and / or data that can be used while computer processing is running on a server located remotely from computing device 802. Resources 818 may also include services provided over the internet and / or over a subscriber network such as a cellular network or Wi-Fi network.

[0104] Platform 816 can extract resources and functions for connecting computing device 802 with other computing devices. Platform 816 can also extract resource scaling to provide a scale level that responds to the demands faced by resource 818, which is implemented via Platform 816. Thus, in embodiments of interconnected devices, embodiments of the functions described herein can be distributed throughout the entire system 800. For example, this function can be partially implemented on computing device 802 and via Platform 816, which extracts the functions of cloud 814.

[0105] conclusion While the systems and techniques are described in a language specific to structural features and / or methodological actions, it should be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms for implementing the claimed subject matter. [Explanation of Symbols]

[0106] 100 Environment 102 people 104 Wearable glucose monitoring device 106 Computing Devices 108 user groups 110 Glucose Monitoring Platform 112 Network 114 glucose measurement values 116 Glucose Monitoring Applications 118 Storage Devices 120 Event Engine 122 Event Log 124 Alert Event Log 126 Anomaly Detection System 128 Storage Devices 130 Event Engine Simulator 200 cases 202 Sensors 204 Sensor Module 206 Skin 208 Transmitter 210 Adhesive Pads 212 Mounting mechanism 214 Supplementary Sensor Information 300 cases 302 Comparison Module 304 Model Manager 306 Anomaly Detection Models 308 Abnormal behavior 310 Simulated Events 312 Recorded Alerts 314 First Missing Event 316 Second Missing Event 400 cases 404 User Interface 406 Graphs Event indications 408, 410, 412, 414 416 Anomaly detection time 418 Range Visualization 420 Prediction range 422, 424 instructions 426, 428 Visual Indicators 500 cases 502 Computing Devices 504 User Interface 506 Display Devices 508 notification 600 steps Blocks 602, 604, and 606 700 steps Blocks 702, 704, and 706 800 System 802 Computing Devices 804 Processing System 806 Computer-readable media 808 I / O Interface 810 Hardware Elements 812 memory / storage devices 814 Cloud 816 Platforms 818 resources

Claims

1. It is a method, The anomaly detection system receives glucose measurements collected by a wearable glucose monitoring device and event records associated with the glucose measurements during a first period. The event engine simulator of the anomaly detection system processes the glucose measurement values ​​to identify missing events that are missing from the event record during the first period, A method comprising: a model manager of the anomaly detection system generating an anomaly detection model which predicts the range of the number of non-anomalous missing events in the next period based on data of missing events that occurred over a certain period in the past, wherein the anomaly detection model is generated based on the missing events during the first period, and the generation of the anomaly detection model includes a predicted range of missing events during the second period which are non-anomalous.

2. Identifying the missing events that are missing from the event record during the first period is Using the aforementioned event engine simulator, the glucose measurement values ​​are processed to generate a simulated event, The method according to claim 1, further comprising comparing the simulated events with actual events in the event record for the first period to identify the missing events that are missing from the event record for the first period.

3. The method according to claim 2, wherein the missing events include simulated events that do not have a matching actual event in the event record during the first period.

4. The method according to claim 1, wherein the event engine simulator includes a copy of the event engine of a glucose monitoring application associated with the wearable glucose monitoring device.

5. The anomaly detection system receives additional glucose measurements collected by the wearable glucose monitoring device and additional event records associated with the additional glucose measurements during the second period, The event engine simulator of the anomaly detection system processes the additional glucose measurements to identify missing events that are missing from the additional event record during the second period. The anomaly detection system detects abnormal behavior when an identified missing event that is missing from the additional event record during the second period falls outside the predicted range of the missing event in the anomaly detection model. The method according to claim 1, further comprising outputting the abnormal behavior.

6. The method according to claim 5, wherein the predicted range of missing events in the anomaly detection model corresponds to the predicted range of non-anomalous missing events per day, and detecting the anomaly behavior includes detecting the anomaly behavior when the missing event missing from the additional event record for the first day of the second period is outside the predicted range of non-anomalous missing events per day.

7. The method according to claim 6, further comprising detecting non-abnormal behavior when the missing event that is missing from the additional event record for the second day of the second period falls within the predicted range of the number of missing events per day that is non-abnormal.

8. Identifying the missing events that are missing from the additional event records during the second period is Using the event engine simulator, the additional glucose measurements are processed to generate additional simulated events. The method of claim 5, further comprising comparing the additional simulated events with actual events in the event record during the second period to identify the missing events that are missing from the event record during the second period.

9. The method according to claim 1, wherein the event record includes a low glucose alert generated by the wearable glucose monitoring device during the first period.

10. The method according to claim 1, wherein the first period precedes the second period.

11. The method according to claim 1, further comprising displaying an abnormal behavior user interface that plots the missing events during the first period and the second period.

12. The method according to claim 11, wherein the abnormal behavior user interface visually indicates the predicted range of the missing events.

13. The method according to claim 12, wherein missing events plotted outside the predicted range of missing events are displayed using a visual indicator to indicate that the missing events correspond to abnormal behavior.

14. A computer-readable storage device that includes stored instructions that perform an operation in response to execution by one or more processors, wherein the operation is: During the first period, the system receives glucose measurements collected by a wearable glucose monitoring device, and event records associated with the glucose measurements. By processing the glucose measurements using an event engine simulator, missing events that are missing from the event record during the first period are identified. A computer-readable storage device that generates an anomaly detection model, which is a model that predicts the range of the number of non-anomalous missing events in the next period based on data of missing events that occurred over a certain period in the past, wherein the anomaly detection model is generated based on the missing events during the first period, and the anomaly detection model includes a predicted range of missing events during the second period that are non-anomalous.

15. Identifying the missing events that are missing from the event record during the first period is Using the aforementioned event engine simulator, the glucose measurement values ​​are processed to generate a simulated event, The computer-readable storage device according to claim 14, further comprising comparing the simulated events with actual events in the event record for the first period to identify the missing events that are missing from the event record for the first period.

16. The computer-readable storage device according to claim 15, wherein the missing events include simulated events for which there are no matching actual events in the event record during the first period.

17. The computer-readable storage device according to claim 14, wherein the event engine simulator includes a copy of the event engine of a glucose monitoring application associated with the wearable glucose monitoring device.

18. The aforementioned operation, During the second period, the system receives additional glucose measurements collected by the wearable glucose monitoring device, and additional event records associated with the additional glucose measurements. By processing the additional glucose measurements using the event engine simulator, the missing events that are missing from the additional event record during the second period are identified. When an identified missing event that is missing from the additional event record during the second period falls outside the predicted range of the missing event in the anomaly detection model, abnormal behavior is detected. The computer-readable storage device according to claim 14, further comprising outputting the aforementioned abnormal behavior.

19. The computer-readable storage device according to claim 18, wherein the predicted range of missing events in the anomaly detection model corresponds to the predicted range of non-anomalous missing events per day, and detecting the anomaly behavior includes detecting the anomaly behavior when the missing event missing from the additional event record for the first day of the second period is outside the predicted range of non-anomalous missing events per day.

20. The computer-readable storage device according to claim 19, further comprising detecting non-abnormal behavior when the missing event from the additional event record for the second day of the second period falls within the predicted range of non-abnormal daily missing events.

21. Identifying the missing events that are missing from the additional event records during the second period is Using the event engine simulator, the additional glucose measurements are processed to generate additional simulated events. The computer-readable storage device according to claim 18, further comprising comparing the additional simulated events with actual events in the event record during the second period to identify the missing events that are missing from the event record during the second period.

22. The computer-readable storage device according to claim 14, wherein the event record includes a low glucose alert generated by the wearable glucose monitoring device during the first period.

23. The computer-readable storage device according to claim 14, wherein the first period precedes the second period.

24. The computer-readable storage device according to claim 14, further comprising the operation of displaying an abnormal behavior user interface that plots the missing events during the first period and the second period.

25. The computer-readable storage device according to claim 24, wherein the abnormal behavior user interface visually indicates the predicted range of the missing events.

26. The computer-readable storage device according to claim 25, wherein missing events plotted outside the predicted range of missing events are displayed using a visual indicator to indicate that the missing events correspond to abnormal behavior.

27. An anomaly detection system, During the first period, an event engine simulator receives glucose measurements collected by a wearable glucose monitoring device and event records associated with the glucose measurements, and processes the glucose measurements to generate simulated events. A comparison module for identifying missing events from the event record by comparing the simulated events with actual events in the event record during the first period, An anomaly detection system comprising: a model manager for generating an anomaly detection model, which is a model that predicts the range of the number of non-anomalous missing events in the next period based on data of missing events that occurred over a certain period in the past, wherein the anomaly detection model generates an anomaly detection model based on the missing events during the first period and includes a predicted range of non-anomalous missing events in the second period.

Images