Method and device for analyte monitoring

Abstract

Disclosed herein are system, method, and computer program product embodiments for generating personalized user interface elements for an evolving medical user interface that is in communication with an analyte monitoring system. The evolving medical user interface may be adapted based on a current and / or predicted condition of the user and may be personalized for users of the analyte monitoring system. The disclosed techniques generate personalized user interface elements using trained models that may be specific to the user and / or a population group(s) associated with the user. The disclosed medical user interface is dynamically adjusted based on new data from the user including user analyte data, user medical history data, and / or user activity data.

Description

METHOD AND DEVICE FOR ANALYTE MONITORINGCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 616,192, filed December 29, 2023, which is hereby incorporated by reference in its entirety.BACKGROUND

[0002] Medical conditions associated with analytes, such as diabetes, are typically lifelong journeys for the patient. A patient may have different needs at different stages of their medical condition. That is, a patient’s needs typically evolve or change as their medical condition progresses. For example, a patient just diagnosed with diabetes may have different needs then a patient that has managed their diabetes for several years.

[0003] There are conventional tools, such as software applications that communicate with a patient’s analyte monitoring device, that assist patients manage their conditions. These tools typically provide graphical user interfaces that provide recommendations or visualizations related to their analyte levels and their medications. But these conventional graphical user interfaces associated with analyte monitoring do not evolve with the patient’s needs.SUMMARY

[0004] Accordingly, a need exists for an evolving medical user interface that provides a personalized user experience that is adapted to meet a patient’s needs as the patient progresses through various stages of their medical condition. The evolving medical user interface is tuned to one or more characteristics including, but not limited to, the user’s current medical condition (e.g., their current glucose levels), the user’s medical history (e.g., their past glucose levels, trend information), user responses to user prompts, user’s tracked activities including food choices, meal sequences, and physical activity, a calculated mental state of the user, and / or cohort analysis which detects the user’s similarities with other patients in the user’s cohort(s).

[0005] An evolving medical user interface (EMUI) differs from and provides advantages over conventional personalized user interfaces in a number of ways. An EMUI is configured to connect with specific medical devices, such as a continuous glucose monitoring (CGM) sensor, and therefore may be customized based on real-time medical information from the user. In this manner, the EMUI has access to personal user information that is not typically available to other interfaces or applications. An EMUI may be configured to be displayed as part of a medical application stored on a user’s device. The CGM sensor may be configured to communicate only with the medical application.

[0006] When installed on the user device, the medical application may further be configured to track user activity across other applications on the user device. Examples of tracked user activity may include number of hours that the user is using the user device (beside the medical application), and the number of applications that the user has accessed over a predetermined period of time. The medical application may be configured to generate behavior models.

[0007] In addition, the medical application may be linked to and receive user data from third-party applications and devices, such as fitness tracker devices and fitness tracking applications. The medical application may be configured to utilize the user data as additional input a behavior model for decision making and presenting recommendations to the user

[0008] Another advantage for an EMUI is access to cohort data including medical data and user activity data. In some embodiments, CGM sensors for multiple patients may provide user CGM data to a backend system that is configured to anonymize the CGM data and perform cohort analysis on CGM data to provide further customization of the EMUI based on results. The EMUI may therefore be customized based not only on user information but on analysis of data from a cohort associated with the user.

[0009] An EMUI also can also adapt its user interface elements and personalize them for each user to increase the relevance and efficacy of recommendations and suggestions to the user. Because the EMUI is configured to receive real-time medical data as well as historical medical data, EMUI may adapt the user interface elements to be relevant to the particular condition of the user which increases the likelihood that any recommended actions or suggestions would be acted upon or useful to the user at that particular momentin time. Moreover, the personalized user interface elements may adapt over time as the medical condition of the user changes. The EMUI therefore provides a more dynamic user interface experience that is tuned to the particular medical needs of the user.

[0010] Because users need to make life decisions on a day-to-day basis and because a users’ needs and conditions vary on a day-to-day basis, static user interfaces which do not take into account user analyte data, user medical history data, and user activity data fails to provide relevant and user interfaces for the user to engage with and manage his medical condition. The personalized user interface elements of the EMUI describes in this disclosure improves the function of data receiving devices by displaying dynamic user interface elements that are tuned to a user’s specific medical needs. Disclosed herein are system, method, and computer program product embodiments for generating personalized user interface elements for an evolving medical user interface that is in communication with an analyte monitoring system. The evolving medical user interface may be adapted based on a current and / or predicted condition of the user and may be personalized for users of the analyte monitoring system. The disclosed techniques generate personalized user interface elements using trained models that may be specific to the user and / or a population group(s) associated with the user. The disclosed medical user interface is dynamically adjusted based on new data from the user including user analyte data, user medical history data, and / or user activity data.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the arts to make and use the embodiments.

[0012] FIG. 1 A is a system overview of a sensor applicator, data receiving device, monitoring system, network, and remote system.

[0013] FIG. IB is a diagram illustrating an operating environment of an example analyte monitoring system for use with the techniques described herein.

[0014] FIG. 2A is a block diagram depicting an example embodiment of a data receiving device.

[0015] FIG. 2B is a block diagram illustrating an example data receiving device for communicating with the sensor according to exemplary embodiments of the disclosed subject matter.

[0016] FIGS. 2C and 2D are block diagrams depicting example embodiments of sensor control devices.

[0017] FIG. 2E is a block diagram illustrating an example analyte sensor according to exemplary embodiments of the disclosed subject matter.

[0018] FIG. 3 A is a proximal perspective view depicting an example embodiment of a user preparing a tray for an assembly.

[0019] FIG. 3B is a side view depicting an example embodiment of a user preparing an applicator device for an assembly.

[0020] FIG. 3C is a proximal perspective view depicting an example embodiment of a user inserting an applicator device into a tray during an assembly.

[0021] FIG. 3D is a proximal perspective view depicting an example embodiment of a user removing an applicator device from a tray during an assembly.

[0022] FIG. 3E is a proximal perspective view depicting an example embodiment of a patient applying a sensor using an applicator device.

[0023] FIG. 3F is a proximal perspective view depicting an example embodiment of a patient with an applied sensor and a used applicator device.

[0024] FIG. 4A is a side view depicting an example embodiment of an applicator device coupled with a cap.

[0025] FIG. 4B is a side perspective view depicting an example embodiment of an applicator device and cap decoupled.

[0026] FIG. 4C is a perspective view depicting an example embodiment of a distal end of an applicator device and electronics housing.

[0027] FIG. 4D is a top perspective view of an exemplary applicator device in accordance with the disclosed subject matter.

[0028] FIG. 4E is a bottom perspective view of the applicator device of FIG. 4D.

[0029] FIG. 4F is an exploded view of the applicator device of FIG. 4D.

[0030] FIG. 4G is a side cutaway view of the applicator device of FIG. 4D.

[0031] FIG. 5 is a diagram illustrating example operational states of the sensor according to exemplary embodiments of the disclosed subject matter.

[0032] FIG. 6 is a diagram illustrating an example operational and data flow for over-the- air programming of a sensor according to the disclosed subject matter.

[0033] FIG. 7 is a diagram illustrating an example data flow for secure exchange of data between two devices according to the disclosed subject matter.

[0034] FIG. 8 is a block diagram of a CGM system that provides visualizations for the evolving medical user interface via an evolving medical user interface engine installed on a mobile device, according to some embodiments.

[0035] FIG. 9 is an example system for generating one or more personalized user interface elements for display on a EMUI

[0036] FIG. 10 is an example computer system useful for implementing various embodiments.

[0037] In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.DETAILED DESCRIPTION

[0038] Provided herein are system, apparatus, device, method and / or computer program product embodiments, and / or combinations and sub-combinations thereof, for providing an evolving medical user interface that dynamically adapts to different user conditions including medical status. The disclosed techniques utilize user data from a variety of sources - real-time medical data, historical medical data, cohort medical data, user device interaction - to providing a personalized user interface for each user that evolves as the user’s medical needs change as they manage their medical condition. The personalization may use trained user interface models to display personally relatable and adaptable visualizations of recommendations, user input sequences, and medical information to users at various stages of their medical journey.

[0039] Several embodiments are disclosed herein where the medical information relates to a user’s analyte information (e.g., glucose levels) that is provided by a continuous monitoring device that may be implanted in a user, which can provide real-time medical data for use in generating the evolving medical user interface. For example, in one embodiment, the continuous monitoring device may include a continuous glucose sensor.Other types and / or combinations of analytes are also possible, including but not limited to, lactate and ketone.

[0040] Several embodiments are disclosed herein for achieving an evolving medical user interface (EMUI) that includes personalized user interface elements that are tuned to one or more of a user’s medical condition, their activity level, their analyte level, their cohort association, and their mental condition. Examples of these personalized user interface elements include, for example, personalized nudges, streamlined user interfaces, task lists, virtual avatars, interfaces that are personalized based on a predicted user mentality, and recommendations based on one or more user cohorts.

[0041] In one embodiment, the EMUI may be implemented with an CGM application which may be configured with the ability to receive user data including medical data, device interaction data, and or user activity data such as meal sequences and / or physical activity from connected partner systems (e.g., via wellness apps, via partner app, via QR code from food menu, etc.). In this embodiment, the CGM application may be configured to communicate with a user interface model that is trained to provide recommendations for updating visualizations of the EMUI. The CGM application may provide the user data to the user interface model which can receive as input, the medical data, device interaction data, and or user activity data such as meal sequences and / or physical activity allows editing of food choices (e.g., in terms of amount, order, and / or timing) and physical activity (e.g., in terms of type, intensity, and / or duration), and the user interface model generates possible user interface changes based on the provided user data. The user interface model may also have access to other sources, such as healthcare provider (HCP) databases, caregiver information, and other medical sources that provide additional information regarding the user’s past, current, and potential medical conditions. The changes generated by the user interface model may then be used to update the EMUI for display to the user by the CGM application, or another visualization application associated with the CGM application. The user interface model may be a sub-subsystem separate from and implemented remotely to the CGM application, such as at a backend server.

[0042] In another embodiment, the user interface model may be a sub-subsystem integrated into the CGM system’s application and the EMUI generated by the user interface model may be visually embedded into the CGM system application’s UI flow.

[0043] In some embodiments, the EMUI is not limited to a single interface but may include personalized graphical user interface elements that are generated based on user data. Examples of personalized graphical user interface elements includes personalized nudges, virtual avatars, customized interfaces for engaging with a medical application and / or other users, and recommended actions to be taken to accomplish defined goals associated with the user’s medical condition. Examples of personalized nudges include notifications, alerts, and messages that are displayed to the user. Personalized nudges may be customized to encourage user action based on any combination of the user’s current medical condition, user’s predicted mentality or mood, the user’s current health goals. A virtual avatar can be configured to provide an interactive interface for engaging with the medical device installed on the user’s device. The appearance of the virtual avatar may also be customized to represent the user, the user’s caregiver, or the user’s friend. Embodiments of the virtual avatar include a customizing appearances as a visualization for user's mood / activity and glucose conditions, serving as chat interface to the user for responding to questions, and providing access to resources associated with the user’s medical condition, serving as the user's virtual presence in a community engagement-type forum with other users, serving as the interface for providing nudges, recommendations, and other messages, and / or serving as the interface for the user to engage with the medical application (e.g., putting the avatar to sleep indicates to the application that the user is sleeping which can then trigger sleeping functions associated with the medical application and / or in vivo analyte sensor).

[0044] In some embodiments, user applications in combination with backend servers may personalize and evolve EMUIs in a predictive manner. Features of EMUI may be adapted and surfaced for display on a user device based on a prediction of a user’s state at a current date and time, such as mood or personality. The user application may be installed on the user device and can be configured to actively and passively monitor user actions, actively request user input or responses, such as via prompts or interactive games, to gauge user mood and personality, and to actively and passively monitor other user data to which the user application has access (or has been granted access), such as user calendar, user activity via third-party devices, and user medical information.

[0045] Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may, ofcourse, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims.

[0046] As used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise.

[0047] The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed.

[0048] Generally, embodiments of the present disclosure include systems, devices, and methods for the use of analyte sensor insertion applicators for use with in vivo analyte monitoring systems. An applicator can be provided to the user in a sterile package with an electronics housing of the sensor control device contained therein. According to some embodiments, a structure separate from the applicator, such as a container, can also be provided to the user as a sterile package with a sensor subsystem and a sharp subsystem contained therein. The user can couple the sensor subsystem to the electronics housing, and can couple the sharp to the applicator with an assembly process that involves the insertion of the applicator into the container in a specified manner. In other embodiments, the applicator, sensor control device, sensor subsystem, and sharp subsystem can be provided in a single package. The applicator can be used to position the sensor control device on a human body with a sensor in contact with the wearer’s bodily fluid. The embodiments provided herein are improvements to reduce the likelihood that a sensor is improperly inserted or damaged, or elicits an adverse physiological response. Other improvements and advantages are provided as well. The various configurations of these devices are described in detail by way of the embodiments which are only examples.

[0049] Furthermore, many embodiments include in vivo analyte sensors structurally configured so that at least a portion of the sensor is, or can be, positioned in the body of a user to obtain information about at least one analyte of the body. It should be noted, however, that the embodiments disclosed herein can be used with in vivo analyte monitoring systems that incorporate in vitro capability, as well as purely in vitro or ex vivo analyte monitoring systems, including systems that are entirely non-invasive.

[0050] Furthermore, for each and every embodiment of a method disclosed herein, systems and devices capable of performing each of those embodiments are covered within the scope of the present disclosure. For example, embodiments of sensor control devices are disclosed and these devices can have one or more sensors, analyte monitoring circuits (e.g., an analog circuit), memories (e.g., for storing instructions), power sources, communication circuits, transmitters, receivers, processors and / or controllers (e.g., for executing instructions) that can perform any and all method steps or facilitate the execution of any and all method steps. These sensor control device embodiments can be used and can be capable of use to implement those steps performed by a sensor control device from any and all of the methods described herein.

[0051] Furthermore, the systems and methods presented herein can be used for operations of a sensor used in an analyte monitoring system, such as but not limited to wellness, fitness, dietary, research, information or any purposes involving analyte sensing over time. As used herein, “analyte sensor” or “sensor” can refer to any device capable of receiving sensor information from a user, including for purpose of illustration but not limited to, body temperature sensors, blood pressure sensors, pulse or heart-rate sensors, glucose level sensors, analyte sensors, physical activity sensors, body movement sensors, or any other sensors for collecting physical or biological information. Analytes measured by the analyte sensors can include, by way of example and not limitation, glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, etc.

[0052] As mentioned, a number of embodiments of systems, devices, and methods are described herein that provide for the improved assembly and use of dermal sensor insertion devices for use with in vivo analyte monitoring systems. In particular, several embodiments of the present disclosure are designed to improve the method of sensor insertion with respect to in vivo analyte monitoring systems and, in particular, to prevent the premature retraction of an insertion sharp during a sensor insertion process. Some embodiments, for example, include a dermal sensor insertion mechanism with an increased firing velocity and a delayed sharp retraction. In other embodiments, the sharp retraction mechanism can be motion-actuated such that the sharp is not retracted until theuser pulls the applicator away from the skin. Consequently, these embodiments can reduce the likelihood of prematurely withdrawing an insertion sharp during a sensor insertion process; decrease the likelihood of improper sensor insertion; and decrease the likelihood of damaging a sensor during the sensor insertion process, to name a few advantages. Several embodiments of the present disclosure also provide for improved insertion sharp subsystems to account for the small scale of dermal sensors and the relatively shallow insertion path present in a subject’s dermal layer. In addition, several embodiments of the present disclosure are designed to prevent undesirable axial and / or rotational movement of applicator components during sensor insertion. Accordingly, these embodiments can reduce the likelihood of instability of a positioned dermal sensor, irritation at the insertion site, damage to surrounding tissue, and breakage of capillary blood vessels resulting in fouling of the dermal fluid with blood, to name a few advantages. In addition, to mitigate inaccurate sensor readings which can be caused by trauma at the insertion site, several embodiments of the present disclosure can reduce the end-depth penetration of the needle relative to the sensor tip during insertion.

[0053] Before describing these aspects of the embodiments in detail, however, it is first desirable to describe examples of devices that can be present within, for example, an in vivo analyte monitoring system, as well as examples of their operation, all of which can be used with the embodiments described herein.

[0054] There are various types of in vivo analyte monitoring systems. CGM systems, for example, can transmit data from a sensor control device to a data receiving device continuously without prompting, e.g., automatically according to a schedule. “Flash Analyte Monitoring” systems (or “Flash Glucose Monitoring” systems or simply “Flash” systems), as another example, can transfer data from a sensor control device in response to a scan or request for data by a data receiving device, such as with a Near Field Communication (“NFC”) or Radio Frequency Identification (“RFID”) protocol. In vivo analyte monitoring systems can also operate without the need for finger stick calibration.

[0055] In vivo analyte monitoring systems can be differentiated from in vitro systems that contact a biological sample outside of the body (or ex vivo) and that typically include a meter device that has a port for receiving an analyte test strip carrying bodily fluid of the user, which can be analyzed to determine the user’s blood sugar level.

[0056] In vivo monitoring systems can include a sensor that, while positioned in vivo, makes contact with the bodily fluid of the user and senses the analyte levels contained therein. The sensor can be part of the sensor control device that resides on the body of the user and contains the electronics and power supply that enable and control the analyte sensing. The sensor control device, and variations thereof, can also be referred to as a “sensor control unit,” an “on-body electronics” device or unit, an “on-body” device or unit, or a “sensor data communication” device or unit, to name a few.

[0057] In vivo monitoring systems can also include a device that receives sensed analyte data from the sensor control device and processes and / or displays that sensed analyte data, in any number of forms, to the user. This device, and variations thereof, can be referred to as a “handheld reader device,” “reader device” (or simply a “reader”), “handheld electronics” (or simply a “handheld”), a “portable data processing” device or unit, a “data receiver,” a “receiver” device or unit (or simply a “receiver”), or a “remote” device or unit, to name a few. Other devices such as personal computers have also been utilized with or incorporated into in vivo and in vitro monitoring systems.Exemplary In vivo Analyte Monitoring System

[0058] FIG. 1 A is a conceptual diagram depicting an example embodiment of an analyte monitoring system 100 that includes sensor applicator 150, sensor control device 102, and data receiving device 120. Here, sensor applicator 150 can be used to deliver sensor control device 102 to a monitoring location on a user’s skin where in vivo analyte sensor 104 is maintained in position for a period of time by adhesive patch 105. Sensor control device 102 is further described in FIGS. 2B and 2C, and can communicate with data receiving device 120 via a communication path 141 using a wired or wireless technique. Example wireless protocols include Bluetooth, Bluetooth Low Energy (“BLE” or “BTLE”), Bluetooth SMART, NFC, and others. Users can monitor applications installed in memory on data receiving device 120 using display 122 and input component 121 and the device battery can be recharged using power port 123. More detail about data receiving device 120 is set forth with respect to FIG. 2A below. Data receiving device 120 can communicate with local computer system 175 via a communication path 141 using a wired or wireless technique. Local computer system 175 can include one or more of a laptop, desktop, tablet, phablet, smartphone, set-top box, video game console, or other computing device and wireless communication can include any of a number ofapplicable wireless networking protocols including Bluetooth, BTLE, Wi-Fi or others. Local computer system 175 can communicate via communications path 143 with a network 190 similar to how data receiving device 120 can communicate via a communications path 142 with network 190, by wired or wireless technique as described previously. Network 190 can be any of a number of networks, such as private networks and public networks, local area or wide area networks, and so forth. A trusted computer system 180 can include a server and can provide authentication services and secured data storage and can communicate via communications path 144 with network 190 by wired or wireless technique. Trusted computer system 180 is described in further detail below with reference to FIG. 8.

[0059] FIG. IB illustrates an operating environment of analyte monitoring system 100a capable of embodying the techniques described herein. Analyte monitoring system 100a may include a system of components designed to provide monitoring of parameters, such as analyte levels, of a human or animal body or can provide for other operations based on the configurations of the various components. As embodied herein, the system may include analyte sensor 110, or simply “sensor” worn by the user or attached to the body for which information is being collected. As embodied herein, analyte sensor 110 can be a sealed, disposable device with a predetermined active use lifetime (e.g., 1 day, 14 days, 30 days, etc.). Analyte sensor 110 may be applied to the skin of the user body and remain adhered over the duration of the sensor lifetime or can be designed to be selectively removed and remain functional when reapplied. Analyte monitoring system 100a can further include data receiving device 120 or multi-purpose data receiving device 130 configured as described herein to facilitate retrieval and delivery of data, including analyte data, from analyte sensor 110.

[0060] As embodied herein, analyte monitoring system 100a can include a software or firmware library or application provided, for example via remote application server 155 or application storefront server 160, to a third-party and incorporated into multi-purpose data receiving device 130 such as a mobile phone, tablet, personal computing device, or other similar computing device capable of communicating with analyte sensor 110 over a communication link. Multi-purpose hardware can further include embedded devices, including, but not limited to insulin pumps or insulin pens, having an embedded library configured to communicate with analyte sensor 110. Although the illustratedembodiments of analyte monitoring system 100a include only one of each of the illustrated devices, this disclosure contemplates analyte monitoring system 100a incorporating multiples of each component interacting throughout the system. For example and without limitation, as embodied herein, data receiving device 120 and / or multi-purpose data receiving device 130 can include multiples of each. As embodied herein, multi-purpose data receiving device 130 can communicate directly with analyte sensor 110 as described herein. Additionally or alternatively, multi-purpose data receiving device 130 can communicate with multi-purpose data receiving device 130 to provide analyte data, or visualization or analysis of the data, for secondary display to the user or other authorized parties.Exemplary Data Receiving Device

[0061] FIG. 2A is a block diagram depicting an example embodiment of a data receiving device 120 configured as a smartphone. Here, data receiving device 120 can include a display 122, input component 121, and processing core 206 including communications processor 222 coupled with memory 223 and applications processor 224 coupled with memory 225. Also included can be separate memory 230, RF transceiver 228 with antenna 229, and power supply 226 with power management subsystem 238. Further included can be a multi-functional transceiver 232 which can communicate over Wi-Fi, NFC, Bluetooth, BTLE, and GPS with antenna 234. As understood by one of skill in the art, these components are electrically and communicatively coupled in a manner to make a functional device.

[0062] Memory 230 may be configured to store the medical application (e.g., CGM application) and a trained user interface model. The trained user interface model is a machine learning model that can be trained remotely from data receiving device, such as at remote application server 155 or any other server associated with the medical application. The trained user interface model may be configured to generate proposed user interface modifications to the evolving medical user interface (EMUI) of the medical application installed on data receiving device 120. The trained user interface model may be implemented as subsystem of the medical application and both can be configured to receive and process medical data including real-time medical data from a medical sensor (e.g., CGM sensor) and historical medical data (e.g., stored on the data receiving device 120 or remotely, such as at a backend database or server). The trained user interfacemodel and / or the medical application may also be granted access privileges to user interactions with data receiving device 120 that include, for example, other applications installed on the data receiving device 120, duration of user interaction with the data receiving device 120 and / or the other installed applications, and date and time of user interaction with the data receiving device 120 and / or the other installed applications. The trained user interface model and / or the medical application may also be configured to connect with databases remote from data receiving device 120 that may include historical medical data, such as medical history from an HCP, as well as cohort data that represents anonymized medical data collected from the medical sensors of other users. A cohort may be established for the current user based on one or more similar characteristics to the current user, such as, user age, sex / gender, user medical condition(s), user medical history, user location, activity level, occupation, education level, and user preference, just to name a few examples.Exemplary Data Receiving Device Architecture

[0063] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of data receiving device 120 for use with the disclosed subject matter as shown in FIG. 2B. Data receiving device 120 and the related multi-purpose data receiving device 130 include components germane to the discussion of analyte sensor 110 and its operations and additional components can be included. Data receiving device 120 may also be implemented with components for generating different interface elements of the EMUI that is displayed to the user. For example, data receiving device 120 may receive and store a user interface model trained to receive any combination of user analyte data, user medical history, and other user activity data (e.g., device interaction, tracked physical activity, tracked meals) and generate the interface elements for the EMUI. In particular embodiments, data receiving device 120 and multi-purpose data receiving device 130 can be or include components provided by a third party and are not necessarily restricted to include devices made by the same manufacturer as analyte sensor 110.

[0064] As illustrated in FIG. 2B, data receiving device 120 includes ASIC 4000 having microcontroller 4010, memory 4020, and storage 4030 and communicatively coupled with a communication subsystem 4040. Power for the components of data receiving device 120 can be delivered by power subsystem 4050, which as embodied herein caninclude a rechargeable batery. Data receiving device 120 can further include display 4070 for facilitating review of analyte data received from analyte sensor 110 or other device (e.g., user device 140 or remote application server 155). Data receiving device 120 can include separate user interface components (e.g., physical keys, light sensors, microphones, etc.).

[0065] Memory 4020 may be configured to store a medical application (e.g., CGM application) that is configured to communicate with and receive data from the analyte sensor of the user. The medical application may further be implemented with a trained user interface model, similar to the configuration discussed with regard to FIG. 2A.

[0066] Communication subsystem 4040 can include BLE subsystem 4041 and NFC subsystem 4042. Data receiving device 120 can be configured to wirelessly couple with analyte sensor 110 and transmit commands to and receive data from analyte sensor 110. As embodied herein, data receiving device 120 can be configured to operate, with respect to analyte sensor 110 as described herein, as an NFC scanner and a BLE end point via specific subsystems (e.g, BLE subsystem 4042 or NFC subsystem 4043) of communication subsystem 4040. For example, data receiving device 120 can issue commands (e.g, activation commands for a data broadcast mode of the sensor; pairing commands to identify data receiving device 120) to analyte sensor 110 using a first subsystem of the communication subsystem 4040 and receive data from and transmit data to analyte sensor 110 using a second subsystem of the communication subsystem 4040. Data receiving device 120 can be configured for communication with user device 140 via a Universal Serial Bus (“USB”) subsystem 4045 of the communication subsystem 4040.

[0067] As another example, communication subsystem 4040 can include, for example, cellular radio subsystem 4044. The cellular radio subsystem 4044 can include one or more radio transceivers for communicating using broadband cellular networks, including, but not limited to third generation (“3G”), fourth generation (“4G”), and fifth generation (“5G”) networks. Additionally, communication subsystem 4040 of data receiving device 120 can include Wi-Fi radio subsystem 4043 for communication using a wireless local area network according to one or more of the IEEE 802.11 standards (e.g. , 802. I la, 802.11b, 802.11g, 802.1 In (aka Wi-Fi 4), 802.1 lac (aka Wi-Fi 5), 802.1 lax (aka Wi-Fi 6)). Using cellular radio subsystem 4044 or Wi-Fi radio subsystem 4043, data receiving device 120 can communicate with remote application server 155 to receive analyte dataor provide updates or input received from a user (e.g., through one or more user interfaces). Although not illustrated, communication subsystem 5040 of analyte sensor 110 can similarly include a cellular radio subsystem or Wi-Fi radio subsystem.

[0068] As embodied herein, on-board storage 4030 of data receiving device 120 can store analyte data received from analyte sensor 110. Further, data receiving device 120, multipurpose data receiving device 130, or user device 140 can be configured to communicate with remote application server 155 via a wide area network. As embodied herein, analyte sensor 110 can provide data to data receiving device 120 or multi-purpose data receiving device 130. Data receiving device 120 can transmit the data to user device 140. User device 140 (or multi-purpose data receiving device 130) can in turn transmit that data to remote application server 155 for processing and analysis.

[0069] As embodied herein, data receiving device 120 can further include sensing hardware 4060 similar to, or expanded from, sensing hardware 5060 of analyte sensor 110. In particular embodiments, data receiving device 120 can be configured to operate in coordination with analyte sensor 110 and based on analyte data received from the analyte sensor 110. As an example, where analyte sensor 110 is a glucose sensor, data receiving device 120 can be or include an insulin pump or insulin injection pen. In coordination, multi-purpose data receiving device 130 can adjust an insulin dosage for a user based on glucose values received from the analyte sensor.Exemplary Sensor Control Devices

[0070] FIGS. 2C and 2D are block diagrams depicting example embodiments of sensor control device 102 having in vivo analyte sensor 104 and sensor electronics 169 (including analyte monitoring circuitry) that can have the majority of the processing capability for rendering end-result data suitable for display to the user. In FIG. 2C, a single semiconductor chip 161 is depicted that can be a custom application specific integrated circuit (“ASIC”). Shown within ASIC 161 are certain high-level functional units, including an analog front end (“AFE”) 162, power management circuitry 164, processor 166, and communication circuitry 168 (which can be implemented as a transmitter, receiver, transceiver, passive circuit, or otherwise according to the communication protocol). In this embodiment, both AFE 162 and processor 166 are used as analyte monitoring circuitry, but in other embodiments either circuit can perform the analyte monitoring function. Processor 166 can include one or more processors,microprocessors, controllers, and / or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips.

[0071] Memory 163 is also included within ASIC 161 and can be shared by the various functional units present within ASIC 161, or can be distributed amongst two or more of them. Memory 163 can also be a separate chip. Memory 163 can be volatile and / or nonvolatile memory. In this embodiment, ASIC 161 is coupled with power source 170, which can be a coin cell battery, or the like. AFE 162 interfaces with in vivo analyte sensor 104 and receives measurement data therefrom and outputs the data to processor 166 in digital form, which in turn processes the data to arrive at the end-result glucose discrete and trend values, etc. This data can then be provided to communication circuitry 168 for sending, by way of antenna 171, to data receiving device 120 (not shown), for example, where minimal further processing is needed by the resident software application to display the data.

[0072] FIG. 2D is similar to FIG. 2C but instead includes two discrete semiconductor chips 162 and 174, which can be packaged together or separately. Here, AFE 162 is resident on ASIC 161. Processor 166 is integrated with power management circuitry 164 and communication circuitry 168 on chip 174. AFE 162 includes memory 163 and chip 174 includes memory 165, which can be isolated or distributed within. In one example embodiment, AFE 162 is combined with power management circuitry 164 and processor 166 on one chip, while communication circuitry 168 is on a separate chip. In another example embodiment, both AFE 162 and communication circuitry 168 are on one chip, and processor 166 and power management circuitry 164 are on another chip. It should be noted that other chip combinations are possible, including three or more chips, each bearing responsibility for the separate functions described, or sharing one or more functions for fail-safe redundancy.

[0073] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of analyte sensor 110 for use with the disclosed subject matter as shown in FIG. 2E. FIG. 2E illustrates a block diagram of an example analyte sensor 110 according to exemplary embodiments compatible with the security architecture and communication schemes described herein.

[0074] As embodied herein, analyte sensor 110 can include ASIC 5000 communicatively coupled with a communication subsystem 5040. ASIC 5000 can include a microcontrollercore 5010, on-board memory 5020, and storage memory 5030. Storage memory 5030 can store data used in an authentication and encryption security architecture. Storage memory 5030 can store programming instructions for analyte sensor 110. As embodied herein, certain communication chipsets can be embedded in the ASIC 5000 (e.g., an NFC transceiver 5025). ASIC 5000 can receive power from a power subsystem 5050, such as an on-board battery or from an NFC pulse. Storage memory 5030 of the ASIC 5000 can be programmed to include information such as an identifier for analyte sensor 110 for identification and tracking purposes. Storage memory 5030 can also be programmed with configuration or calibration parameters for use by analyte sensor 110 and its various components. Storage memory 5030 can include rewritable or one-time programming (“OTP”) memory. The storage memory 5030 can be updated using techniques described herein to extend the usefulness of analyte sensor 110.

[0075] As embodied herein, communication subsystem 5040 of sensor 110 can be or include one or more subsystems to support analyte sensor 110 communicating with other devices of the analyte monitoring system 100. As an example only and not by way of limitation, example communication subsystems 5040 can include BLE subsystem 5041 As used throughout this disclosure, BLE refers to a short-range communication protocol optimized to make pairing of Bluetooth devices simple for end users. Communication subsystem 5040 can transmit and receive data and commands via interaction with similarly-capable communication subsystems of data receiving device 120 or user device 140. Communication subsystem 5040 can include additional or alternative chipsets for use with similar short-range communication schemes, such as a personal area network according to IEEE 802.15 protocols, IEEE 802.11 protocols, infrared communications according to the Infrared Data Association standards (IrDA), etc.

[0076] To perform its functionalities, sensor 110 can further include suitable sensing hardware 5060 appropriate to its function. As embodied herein, sensing hardware 5060 can include an analyte sensor transcutaneously or subcutaneously positioned in contact with a bodily fluid of a subject. The analyte sensor can generate sensor data containing values corresponding to levels of one or more analytes within the bodily fluid.Exemplary Assembly Processes for Sensor Control Devices

[0077] The components of sensor control device 102 can be acquired by a user in multiple packages requiring final assembly by the user before delivery to an appropriateuser location. FIGS. 3A-3D depict an example embodiment of an assembly process for sensor control device 102 by a user, including preparation of separate components before coupling the components in order to ready the sensor for delivery. FIGS. 3E-3F depict an example embodiment of delivery of sensor control device 102 to an appropriate user location by selecting the appropriate delivery location and applying device 102 to the location.

[0078] FIG. 3 A is a proximal perspective view depicting an example embodiment of user preparing tray 814, configured here as a tray (although other packages / containers can be used), for an assembly process. The user can accomplish this preparation by removing lid 812 from tray 814 to expose platform 816, for instance by peeling a non-adhered portion of lid 812 away from tray 814 such that adhered portions of lid 812 are removed. Removal of lid 812 can be appropriate in various embodiments so long as platform 816 is adequately exposed within tray 814. Lid 812 can then be placed aside.

[0079] FIG. 3B is a side view depicting an example embodiment of a user preparing an applicator device 150 for assembly. Applicator device 150 can be provided in a sterile package sealed by a cap 708. Preparation of applicator device 150 can include uncoupling housing 702 from cap 708 to expose sheath 704 (FIG. 3C). This can be accomplished by unscrewing (or otherwise uncoupling) cap 708 from housing 702. Cap 708 can then be placed aside.

[0080] FIG. 3C is a proximal perspective view depicting an example embodiment of a user inserting applicator device 150 into tray 814 during an assembly. Initially, the user can insert sheath 704 into platform 816 inside tray 814 after aligning a housing orienting feature (or slot or recess) and tray orienting feature 924 (an abutment or detent). Inserting sheath 704 into platform 816 temporarily unlocks sheath 704 relative to housing 702 and also temporarily unlocks platform 816 relative to tray 814. At this stage, removal of applicator device 150 from tray 814 will result in the same state prior to initial insertion of applicator device 150 into tray 814 (z.e., the process can be reversed or aborted at this point and then repeated without consequence).

[0081] Sheath 704 can maintain position within platform 816 with respect to housing 702 while housing 702 is distally advanced, coupling with platform 816 to distally advance platform 816 with respect to tray 814. This step unlocks and collapses platform 816 within tray 814. Sheath 704 can contact and disengage locking features (not shown)within tray 814 that unlock sheath 704 with respect to housing 702 and prevent sheath 704 from moving (relatively) while housing 702 continues to distally advance platform 816. At the end of advancement of housing 702 and platform 816, sheath 704 is permanently unlocked relative to housing 702. A sharp and sensor (not shown) within tray 814 can be coupled with an electronics housing (not shown) within housing 702 at the end of the distal advancement of housing 702. Operation and interaction of the applicator device 150 and tray 814 are further described below.

[0082] FIG. 3D is a proximal perspective view depicting an example embodiment of a user removing an applicator device 150 from tray 814 during an assembly. A user can remove applicator 150 from tray 814 by proximally advancing housing 702 with respect to tray 814 or other motions having the same end effect of uncoupling applicator 150 and tray 814. The applicator device 150 is removed with sensor control device 102 (not shown) fully assembled (sharp, sensor, electronics) therein and positioned for delivery.

[0083] FIG. 3E is a proximal perspective view depicting an example embodiment of a patient applying sensor control device 102 using applicator device 150 to a target area of skin, for instance, on an abdomen or other appropriate location. Advancing housing 702 distally collapses sheath 704 within housing 702 and applies the sensor to the target location such that an adhesive layer on the bottom side of sensor control device 102 adheres to the skin. The sharp is automatically retracted when housing 702 is fully advanced, while the sensor (not shown) is left in position to measure analyte levels.

[0084] FIG. 3F is a proximal perspective view depicting an example embodiment of a patient with sensor control device 102 in an applied position. The user can then remove applicator 150 from the application site.

[0085] Analyte monitoring system 100, described with respect to FIGS. 3A-3F and elsewhere herein, can provide a reduced or eliminated chance of accidental breakage, permanent deformation, or incorrect assembly of applicator components compared to prior art systems. Since housing 702 directly engages platform 816 while sheath 704 unlocks, rather than indirect engagement via sheath 704, relative angularity between sheath 704 and housing 702 will not result in breakage or permanent deformation of the arms or other components. The potential for relatively high forces (such as in conventional devices) during assembly will be reduced, which in turn reduces the chance of unsuccessful user assembly.Exemplary Sensor Applicator Devices

[0086] FIG. 4A is a side view depicting an example embodiment of an applicator device 150 coupled with screw cap 708. This is an example of how applicator 150 is shipped to and received by a user, prior to assembly by the user with a sensor. FIG. 4B is a side perspective view depicting applicator 150 and cap 708 after being decoupled. FIG. 4C is a perspective view depicting an example embodiment of a distal end of applicator device 150 with electronics housing 706 and adhesive patch 105 removed from the position they would have retained within sensor carrier 710 of sheath 704, when cap 708 is in place.

[0087] Referring to FIG. 4D-G for purpose of illustration and not limitation, applicator device 20150 can be provided to a user as a single integrated assembly. FIGs. 4D and 4E provide perspective top and bottom views, respectively, of the applicator device 20150, FIG. 4F provides an exploded view of applicator device 20150 and FIG. 4G provides a side cut-away view. The perspective views illustrate how applicator 20150 is shipped to and received by a user. The exploded and cut-away views illustrate the components of applicator device 20150. The applicator device 20150 can include a housing 20702, gasket 20701, sheath 20704, sharp carrier 201102, spring 205612, sensor carrier 20710 (also referred to as a “puck carrier”), sharp hub 205014, sensor control device (also referred to as a “puck”) 20102, adhesive patch 20105, desiccant 20502, cap 20708, serial label 20709, and tamper evidence feature 20712. As received by a user, only housing 20702, cap 20708, tamper evidence feature 20712, and label 20709 are visible. The tamper evidence feature 20712 can be, for example, a sticker coupled to each of housing 20702 and cap 20708, and tamper evidence feature 20712 can be damaged, for example, irreparably, by uncoupling housing 20702 and cap 20708, thereby indicating to a user that housing 20702 and cap 20708 have been previously uncoupled. These features are described in greater detail below.Exemplary Sensor States and Activation

[0088] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of a high-level depiction of a state machine representation 500 of the actions that can be taken by analyte sensor 110 as shown in FIG. 5. After initialization, the sensor enters state 505, which relates to the manufacture of analyte sensor 110. In the manufacture state 505, analyte sensor 110 can be configured for operation, for example,the storage memory 5030 can be written. At various times while in state 505, analyte sensor 110 checks for a received command to go to storage state 515. Upon entry to storage state 515, the sensor performs a software integrity check. While in storage state 515, the sensor can also receive an activation request command before advancing to insertion detection state 525.

[0089] Upon entry to state 525, analyte sensor 110 can store information relating to devices authenticated to communicate with the sensor as set during activation or initialize algorithms related to conducting and interpreting measurements from sensing hardware 5060. Analyte sensor 110 can also initialize a lifecycle timer, responsible for maintaining an active count of the time of operation of analyte sensor 110 and begin communication with authenticated devices to transmit recorded data. While in insertion detection state 525, the sensor can enter state 530, where analyte sensor 110 checks whether the time of operation is equal to a predetermined threshold. This time of operation threshold can correspond to a timeout function for determining whether an insertion has been successful. If the time of operation has reached the threshold, analyte sensor 110 advances to state 535, in which analyte sensor 110 checks whether the average data reading is greater than a threshold amount corresponding to an expected data reading volume for triggering detection of a successful insertion. If the data reading volume is lower than the threshold while in state 535, the sensor advances to state 540, corresponding to a failed insertion. If the data reading volume satisfies the threshold, the sensor advances to active paired state 555.

[0090] Active paired state 555 of analyte sensor 110 reflects the state while analyte sensor 110 is operating as normal by recording measurements, processing the measurements, and reporting them as appropriate. While in active paired state 555, analyte sensor 110 sends measurement results or attempts to establish a connection with data receiving device 120. Analyte sensor 110 also increments the time of operation. Once analyte sensor 110 reaches a predetermined threshold time of operation (e.g., once the time of operation reaches a predetermined threshold), analyte sensor 110 transitions to active expired state 565. Active expired state 565 of analyte sensor 110 reflects the state while analyte sensor 110 has operated for its maximum predetermined amount of time.

[0091] While in active expired state 565, analyte sensor 110 can generally perform operations relating to winding down operation and ensuring that the collectedmeasurements have been securely transmitted to receiving devices as needed. For example, while in active expired state 565, analyte sensor 110 can transmit collected data and, if no connection is available, can increase efforts to discover authenticated devices nearby and establish and connection therewith. While in active expired state 565, analyte sensor 110 can receive a shutdown command at state 570. If no shutdown command is received, analyte sensor 110 can also, at state 575, check if the time of operation has exceeded a final operation threshold. The final operation threshold can be based on the battery life of analyte sensor 110. The normal termination state 580 corresponds to the final operations of analyte sensor 110 and ultimately shutting down analyte sensor 110.

[0092] Before a sensor is activated, ASIC 5000 resides in a low power storage mode state. The activation process can begin, for example, when an incoming RF field (e.g., NFC field) drives the voltage of the power supply to the ASIC 5000 above a reset threshold, which causes analyte sensor 110 to enter a wake-up state. While in the wake-up state, ASIC 5000 enters an activation sequence state. ASIC 5000 then wakes communication subsystem 5040. Communication subsystem 5040 is initialized, triggering a power on self-test. The power on self-test can include ASIC 5000 communicating with communication subsystem 5040 using a prescribed sequence of reading and writing data to verify the memory and one-time programmable memory are not corrupted.

[0093] When ASIC 5000 enters the measurement mode for the first time, an insertion detection sequence is performed to verify that analyte sensor 110 has been properly installed onto the patient’s body before a proper measurement can take place. First, analyte sensor 110 interprets a command to activate the measurement configuration process, causing the ASIC 5000 to enter measurement command mode. Analyte sensor 110 then temporarily enters the measurement lifecycle state to run a number of consecutive measurements to test whether the insertion has been successful. Communication subsystem 5040 or ASIC 5000 evaluates the measurement results to determine insertion success. When insertion is deemed successful, analyte sensor 110 enters a measurement state, in which analyte sensor 110 begins taking regular measurements using sensing hardware 5060. If analyte sensor 110 determines that the insertion was not successful, analyte sensor 110 is triggered into an insertion failure mode, in which ASIC 5000 is commanded back to storage mode while communication subsystem 5040 disables itself.Exemplary Over- the- Air Updates

[0094] FIG. IB further illustrates an example operating environment for providing over- the-air (“OTA”) updates for use with the techniques described herein. An operator of analyte monitoring system 100 can bundle updates for data receiving device 120 or analyte sensor 110 into updates for an application executing on multi-purpose data receiving device 130. Using available communication channels between data receiving device 120, multi-purpose data receiving device 130, and analyte sensor 110, multipurpose data receiving device 130 can receive regular updates for data receiving device 120 or analyte sensor 110 and initiate installation of the updates on data receiving device 120 or analyte sensor 110. Multi-purpose data receiving device 130 acts as an installation or update platform for data receiving device 120 or analyte sensor 110 because the application that enables the multi-purpose data receiving device 130 to communicate with analyte sensor 110, data receiving device 120 and / or remote application server 155 can update software or firmware on data receiving device 120 or analyte sensor 110 without wide-area networking capabilities.

[0095] As embodied herein, remote application server 155 operated by the manufacturer of analyte sensor 110 and / or the operator of analyte monitoring system 100 can provide software and firmware updates to the devices of analyte monitoring system 100. In particular embodiments, remote application server 155 can provides the updated software and firmware to user device 140 or directly to a multi-purpose data receiving device. As embodied herein, remote application server 155 can also provide application software updates to application storefront server 160 using interfaces provided by the application storefront. Multi-purpose data receiving device 130 can contact the application storefront server 160 periodically to download and install the updates.

[0096] After multi-purpose data receiving device 130 downloads an application update including a firmware or software update for data receiving device 120 or analyte sensor 110, data receiving device 120 or analyte sensor 110 and multi-purpose data receiving device 130 establish a connection. Multi-purpose data receiving device 130 determines that a firmware or software update is available for data receiving device 120 or analyte sensor 110. Multi-purpose data receiving device 130 can prepare the software or firmware update for delivery to data receiving device 120 or analyte sensor 110. As an example, multi-purpose data receiving device 130 can compress or segment the data associatedwith the software or firmware update, can encrypt or decrypt the firmware or software update, or can perform an integrity check of the firmware or software update. Multipurpose data receiving device 130 sends the data for the firmware or software update to data receiving device 120 or analyte sensor 110. Multi-purpose data receiving device 130 can also send a command to data receiving device 120 or analyte sensor 110 to initiate the update. Additionally or alternatively, multi-purpose data receiving device 130 can provide a notification to the user of multi-purpose data receiving device 130 and include instructions for facilitating the update, such as instructions to keep data receiving device 120 and multi-purpose data receiving device 130 connected to a power source and in close proximity until the update is complete.

[0097] Data receiving device 120 or analyte sensor 110 receives the data for the update and the command to initiate the update from multi-purpose data receiving device 130. Data receiving device 120 can then install the firmware or software update. To install the update, data receiving device 120 or analyte sensor 110 can place or restart itself in a so- called “safe” mode with limited operational capabilities. Once the update is completed, data receiving device 120 or analyte sensor 110 re-enters or resets into a standard operational mode. Data receiving device 120 or analyte sensor 110 can perform one or more self-tests to determine that the firmware or software update was installed successfully. Multi-purpose data receiving device 130 can receive the notification of the successful update. Multi-purpose data receiving device 130 can then report a confirmation of the successful update to remote application server 155.

[0098] In particular embodiments, storage memory 5030 of analyte sensor 110 includes OTP memory. The term OTP memory can refer to memory that includes access restrictions and security to facilitate writing to particular addresses or segments in the memory a predetermined number of times. Memory 5030 can be prearranged into multiple pre-allocated memory blocks or containers. The containers are pre-allocated into a fixed size. If storage memory 5030 is OTP memory, the containers can be considered to be in a non-programmable state. Additional containers which have not yet been written to can be placed into a programmable or writable state. Containerizing storage memory 5030 in this fashion can improve the transportability of code and data to be written to storage memory 5030. Updating the software of a device (e.g., the sensor device described herein) stored in an OTP memory can be performed by superseding only thecode in a particular previously-written container or containers with updated code written to a new container or containers, rather than replacing the entire code in the memory. In a second embodiment, the memory is not prearranged. Instead, the space allocated for data is dynamically allocated or determined as needed. Incremental updates can be issued, as containers of varying sizes can be defined where updates are anticipated.

[0099] FIG. 6 is a diagram illustrating an example operational and data flow for over-the- air (“OTA”) programming of storage memory 5030 in analyte monitoring system 100 as well as use of the memory after the OTA programming in execution of processes by analyte sensor 110 according to the disclosed subject matter. In the example OTA programming 600 illustrated in FIG. 6, a request is sent from an external device (e.g., multi-purpose data receiving device 130) to initiate OTA programming (or reprogramming). At 611, communication subsystem 240 of analyte sensor 110 receives an OTA programming command. Communication subsystem 240 sends the OTA programming command to the microcontroller 210 of analyte sensor 110.

[0100] At 631, after receiving the OTA programming command, microcontroller 210 validates the OTA programming command. Microcontroller 210 can determine, for example, whether the OTA programming command is signed with an appropriate digital signature token. Upon determining that the OTA programming command is valid, microcontroller 210 can set the sensor device into an OTA programming mode. At 632, microcontroller 210 can validate the OTA programming data. At 633, microcontroller 210 can reset analyte sensor 110 to re-initialize analyte sensor 110 in a programming state. Once analyte sensor 110 has transitioned into the OTA programming state, microcontroller 210 can begin to write data to the rewriteable memory (e.g., memory 5020) of the sensor device at 634 and write data to OTP memory 550 of the sensor device at 635 (e.g., storage memory 5030). The data written by the microcontroller 210 can be based on the validated OTA programming data. Microcontroller 210 can write data to cause one or more programming blocks or regions of OTP memory 550 to be marked invalid or inaccessible. The data written to the free or unused portion of OTP memory 550 can be used to replace invalidated or inaccessible programming blocks of OTP memory 550. After microcontroller 210 writes the data to the respective memories at 634 and 635, microcontroller 210 can perform one or more software integrity checks to ensure that errors were not introduced into the programming blocks during the writing process.Once microcontroller 210 is able to determine that the data has been written without errors, microcontroller 210 can resume standard operations of the sensor device.

[0101] In execution mode, at 636, microcontroller 210 can retrieve a programming manifest or profile from the rewriteable memory. The programming manifest or profile can include a listing of the valid software programming blocks and can include a guide to program execution for analyte sensor 110. By following the programming manifest or profile, microcontroller 210 can determine which memory blocks of OTP memory 550 are appropriate to execute and avoid execution of out-of-date or invalidated programming blocks or reference to out-of-date data. At 637, microcontroller 210 can selectively retrieve memory blocks from OTP memory 550. At 638, microcontroller 210 can use the retrieved memory blocks, by executing programming code stored or using variable stored in the memory.Exemplary Security and Other Architecture Features

[0102] As embodied herein a first layer of security for communications between analyte sensor 110 and other devices can be established based on security protocols specified by and integrated in the communication protocols used for the communication. Another layer of security can be based on communication protocols that necessitate close proximity of communicating devices. Furthermore certain packets and / or certain data included within packets can be encrypted while other packets and / or data within packets is otherwise encrypted or not encrypted. Additionally or alternatively, application layer encryption can be used with one or more block ciphers or stream ciphers to establish mutual authentication and communication encryption with other devices in the analyte monitoring system 100.

[0103] ASIC 5000 of analyte sensor 110 can be configured to dynamically generate authentication and encryption keys using data retained within storage memory 5030. Storage memory 5030 can also be pre-programmed with a set of valid authentication and encryption keys to use with particular classes of devices. ASIC 5000 can be further configured to perform authentication procedures with other devices using received data and apply the generated key to sensitive data prior to transmitting the sensitive data. The generated key can be unique to analyte sensor 110, unique to a pair of devices, unique to a communication session between analyte sensor 110 and other device, unique to amessage sent during a communication session, or unique to a block of data contained within a message.

[0104] Both analyte sensor 110 and data receiving device 120 can ensure the authorization of the other party in a communication session to, for example, issue a command or receive data. In particular embodiments, identity authentication can be performed through two features. First, the party asserting its identity provides a validated certificate signed by the manufacturer of the device or the operator of analyte monitoring system 100. Second, authentication can be enforced through the use of public keys and private keys, and shared secrets derived therefrom, established by the devices of analyte monitoring system 100 or established by the operator of the analyte monitoring system 100. To confirm the identity of the other party, the party can provide proof that the party has control of its private key.

[0105] The manufacturer of analyte sensor 110, data receiving device 120, or provider of the application for multi-purpose data receiving device 130 can provide information and programming necessary for the devices to securely communicate through secured programming and updates. For example, the manufacturer can provide information that can be used to generate encryption keys for each device, including secured root keys for analyte sensor 110 and optionally for data receiving device 120 that can be used in combination with device-specific information and operational data (e.g., entropy -based random values) to generate encryption values unique to the device, session, or data transmission as need.

[0106] Analyte data associated with a user is sensitive data at least in part because this information can be used for a variety of purposes, including for health monitoring and medication dosing decisions. In addition to user data, analyte monitoring system 100 can enforce security hardening against efforts by outside parties to reverse-engineering. Communication connections can be encrypted using a device-unique or session-unique encryption key. Encrypted communications or unencrypted communications between any two devices can be verified with transmission integrity checks built into the communications. Analyte sensor 110 operations can be protected from tampering by restricting access to read and write functions to the memory 5020 via a communication interface. The sensor can be configured to grant access only to known or “trusted” devices, provided in a “whitelisf ’ or only to devices that can provide a predeterminedcode associated with the manufacturer or an otherwise authenticated user. A whitelist can represent an exclusive range, meaning that no connection identifiers besides those included in the whitelist will be used, or a preferred range, in which the whitelist is searched first, but other devices can still be used. Analyte sensor 110 can further deny and shut down connection requests if the requestor cannot complete a login procedure over a communication interface within a predetermined period of time (e.g., within four seconds). These characteristics safeguard against specific denial of service attacks, and in particular against denial of service attacks on a BLE interface.

[0107] As embodied herein, analyte monitoring system 100 can employ periodic key rotation to further reduce the likelihood of key compromise and exploitation. A key rotation strategy employed by analyte monitoring system 100 can be designed to support backward compatibility of field-deployed or distributed devices. As an example, analyte monitoring system 100 can employ keys for downstream devices (e.g., devices that are in the field or cannot be feasibly provided updates) that are designed to be compatible with multiple generations of keys used by upstream devices.

[0108] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of a message sequence diagram for use with the disclosed subject matter as shown in FIG. 7 and demonstrating an example exchange of data between a pair of devices, particularly analyte sensor 110 and data receiving device 120. Data receiving device 120 can, as embodied herein, be data receiving device 120 or multi-purpose data receiving device 130. At step 755, data receiving device 120 can transmit a sensor activation command to analyte sensor 110, for example via a short-range communication protocol. Analyte sensor 110 can, prior to step 755 be in a primarily dormant state, preserving its battery until full activation is needed. After activation during step 760, analyte sensor 110 can collect data or perform other operations as appropriate to the sensing hardware 5060 of analyte sensor 110. At step 765, data receiving device 120 can an initiate authentication request command. In response to the authentication request command, both analyte sensor 110 and data receiving device 120 can engage in a mutual authentication process in step 770. Step 770 can involve the transfer of data, including challenge parameters that allow analyte sensor 110 and data receiving device 120 to ensure that the other device is sufficiently capable of adhering to an agreed-upon security framework described herein. Mutual authentication can be based on mechanisms forauthentication of two or more entities to each other with or without on-line trusted third parties to verify establishment of a secret key via challenge-response. Mutual authentication can be performed using two-, three-, four-, or five-pass authentication, or similar versions thereof.

[0109] Following a successful step 770, at step 775 analyte sensor 110 can provide data receiving device 120 with a sensor secret. The sensor secret can contain sensor-unique values and be derived from random values generated during manufacture. The sensor secret can be encrypted prior to or during transmission to prevent third-parties from accessing the secret. The sensor secret can be encrypted via one or more of the keys generated by or in response to the mutual authentication process. At step 780, data receiving device 120 can derive a sensor-unique encryption key from the sensor secret. The sensor-unique encryption key can further be session-unique. As such, the sensorunique encryption key can be determined by each device without being transmitted between analyte sensor 110 or data receiving device 120. At step 785, analyte sensor 110 can encrypt data to be included in payload. At step 790, analyte sensor 110 can transmit the encrypted payload 740 to data receiving device 120 using the communication link established between the appropriate communication models of analyte sensor 110 and data receiving device 120. At step 795, data receiving device 120 can decrypt the payload using the sensor-unique encryption key derived during step 780. Following step 795, analyte sensor 110 can deliver additional (including newly collected) data and data receiving device 120 can process the received data appropriately.

[0110] As discussed herein, analyte sensor 110 can be a device with restricted processing power, battery supply, and storage. The encryption techniques used by analyte sensor 110 (e.g., the cipher algorithm or the choice of implementation of the algorithm) can be selected based at least in part on these restrictions. Data receiving device 120 can be a more powerful device with fewer restrictions of this nature. Therefore, data receiving device 120 can employ more sophisticated, computationally intense encryption techniques, such as cipher algorithms and implementations.Architecture for Evolving Medical Graphical User Interfaces[OHl] FIG. 8 is a block diagram of CGM system 800 for providing evolving medical graphical user interfaces to users, according to some embodiments. CGM system 800 may include one or more of in vivo analyte sensor 104 (or in another embodiment analytesensor 110), wearable 106, NFC source 811, data receiving device 120, trusted computer system 180, and partner API 830. Additionally, user 802 may interact with CGM system 800. In some embodiments, CGM system 800 may be used with QR code 808.

[0112] User 802 may be a human monitoring their glucose levels using a CGM device, such as an in vivo analyte sensor (e.g., in vivo analyte sensor 104 described above). CGM system 800 may accommodate a wide array of user types, data receiving devices, and analyte sensors. For example, user 802 may be a diabetic having type-1, type-2, or gestational diabetes; as another example, user 802 may be patient whose lactate levels are being monitored as part of a hospital alert system. User 802 may be categorized into one or more user types across a diverse user base with different needs and interaction levels. For example, user 802 may categorized as a proactive person with type-1 diabetes on multiple daily doses of insulin (“MDI”) that frequently checks their glucose levels, carbohydrate counts, takes post meal correction insulin boluses, and periodically titrates their insulin dosing parameter may have a good sense of how to use CGM data without additional support. As another example, user 802 may be categorized as a person with type-2 diabetes that does not take insulin and may be unsure why their glucose rises differently on certain occasions. As yet another example, user 802 may be categorized as a family member or other suitable, authorized agent or caregiver of a person with diabetes. As yet another example, user 802 may be categorized as a doctor or other medical professional. As another example, user 802 may be categorized as a non-diabetic that uses the disclosed tools to monitor their health more generally. Accordingly, in addition to glucose, user 802 may monitor other analytes including ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, etc.

[0113] Wearable 106 may be an electronic device worn by user 802. For example, wearable 106 may be a smartwatch, health-monitoring device, smart glasses or other augmented reality device, or other wearable computing device. Wearable 106 may perform healthmonitoring functions, such as monitoring a user’s vital signs and performing epidemiological functions (e.g., contact tracing and providing communication to an emergency medical service). Wearable 106 may also monitor physical activities of user802, e.g., step counts and the length and intensity of exercise session and other details. In some embodiments, wearable 106 may provide additional functions, such as access to email, cellular service, and calendar functions. Wearable 106 may be worn on a user’s limbs or neck, implantable in user’s body, as glasses or a helmet designed to provide computer-generated reality experiences e.g., augmented and / or virtual reality), any other suitable wearable device, and combinations thereof. Wearable 106 may be in communication with in vivo analyte sensor 104 for receiving and displaying analyte data provided by in vivo analyte sensor 104. Data receiving device 120 may also be in communication with in vivo analyte sensor 104 for receiving, processing, and / or displaying analyte data provided by in vivo analyte sensor 104.

[0114] Wearable 106 may be in communication to provide user activity data to EMUI engine 810, which may be configured to generate the evolving medical user interface for display on data receiving device 120. Wearable 106 may provide user data resulting from the health-monitoring functions to EMUI engine 810. In some embodiments, EMUI engine 810 may be a subsystem installed on data receiving device 120 and may be integrated as part of a medical application configured to communicate with in vivo analyte sensor 104. In some embodiments, EMUI engine 810 may also integrate the user interface model which receives, as an input, the health-monitoring functions from wearable 106.

[0115] EMUI engine 810 may also be configured to receive user activity data from other sources including sensors in data receiving device 120 and / or from user input via an interface provided by the medical application installed on the data receiving device 120. For example, data receiving device 120 may track and store user interaction with the data receiving device 120 such as length of time the user has used the data receiving device 120, other applications installed on the data receiving device 120, and historical usage including trend data regarding usage of the data receiving device 120.

[0116] In an embodiment, data receiving device 120 may establish a connection with wearable 106 to receive the user activity data and provide the received data to EMUI engine 810 for generation of the personalized user interface elements.

[0117] In an embodiment, trusted computer system 180 may establish a connection to with wearable 106. For example, physical activity input subsystem 822 may establish a link to wearable 106. This may occur automatically or in response to user 802commencing a synchronization process. This process may link and establish communications between wearable 106 and data receiving device 120, trusted computer system 180, and / or sensor control device 102.

[0118] In embodiments where data receiving device 120 is connected to wearable 106, data receiving device 120 may receive a quantifiable measurement from wearable 106. The quantifiable measurement may be, e.g., a heart rate, a number of steps, respiration rate, and other data measured by wearable 106.

[0119] EMUI engine 810 may also be configured to receive analyte data from in vivo analyte sensor 104, either directly or indirectly, such as via a medical application installed on data receiving device 120 and that is configured to communicate only with the in vivo analyte sensor 104. EMUI engine 810 may utilize the user data from wearable 106 and / or analyte data from in vivo analyte sensor 104.

[0120] EMUI engine 810 may be further configured to receive user medical history data, which may be stored locally at data receiving device 120, a remote database, such as trusted computer system 180, or a combination of both. The user medical history data may include, but is not limited to, data about the user’s medical condition organized by date, the user’s historical analyte information including trend data, and notes or other information from an HCP(s) that have provided care to the user.

[0121] QR code 808 may be a barcode or other coding mechanism that may be scanned by user 802 (e.g., by accessing a camera feature built into data receiving device 120). Such partner systems may include restaurants, diet programs, exercise programs, etc. For example, QR code 808 may be printed and affixed to a table in a restaurant or otherwise displayed for user 802. QR Code 808 may encode an identifier that uniquely identifies a partner restaurant, particular menu, and / or particular food choices on a menu. These food choices may include communicable sets of parameters that allow the user interface discussed below to select one or more items from a menu to create a what-if scenario predicting future glycemic information.

[0122] NFC source 811 may provide an alternative method of communicating with partner systems to receive menu options and parameters. NFC source 811 may be a hub network, peer-to-peer connections like Bluetooth, Z-Wave, ZigBee, or other appropriate configuration. NFC source 811 may rely on an appropriate NFC communication protocolto facilitate data exchange between data receiving device 120 and / or wearable 106 with partner systems.

[0123] Trusted computer system 180 is described above with reference to FIG. 1. In an embodiment, trusted computer system 180 may include servers, desktops, and other type of electronic device that support CGM system 800 by processing web-based traffic and HTTP request methods and is configured to communicate with the medical application installed on data receiving device 120. Trusted computer system 180 may store data server-side for retrieval by data receiving device 120. CGM system may return web pages to the users via HTTP for display on display 122. The returned pages may include images, stylesheets, and scripts, the content and nature of which will be appreciated by those skilled in the relevant art(s). Trusted computer system 180 may cause data receiving device 120 to display visualizations or provide data to data receiving device 120 to generate and display of glucose-level visualizations. In an embodiment, trusted computer system 180 may include one or more of personalization subsystem 821, physical activity input subsystem 822, personalized interface profiles 823, visualization subsystem 824, partner integration subsystem 825, app repository 826, and database 827.

[0124] Personalization subsystem 821 may be configured as a remote version of EMUI engine 810. Personalization subsystem 821 may remotely generate interface elements (e.g., nudges, avatars, analysis) for display on an EMUI. Personalization subsystem may also store personalization profiles for all users, including user 802, that have installed the medical application on their respective data receiving device 120. For example, personalization subsystem 821 may combine user analyte data, user medical history data, and user activity data (e.g., food choice or exercise) in a personalized interface profile.

[0125] Personalization subsystem 821 may also include a model trainer for training user interface models that can be trained specific to a particular user or a particular group of users based on one or more common characteristics (e.g., users with the same medical conditions, female users, users in a particular location). User interface models that are specific to a user provide personalized user interface elements based on data that is specific to the user. In one embodiment, the user-specific data may be retrieved from any of data receiving device 120 or personalized interface profiles 823. User interface models that are specific to a particular group (or cohort) of users may provide personalized user interface elements based on data that is common to the group of users. In someembodiments, a user may be associated with multiple user interface models based on the characteristic(s) that are used to associate the group of users. For example, there may be a user interface model for diabetic users, a user interface for users at certain stages of their medical condition, a user interface for diabetic users within a particular age group, just to name a few examples.

[0126] In some embodiments, the model trainer is configured to perform steps including acquisition of one or more datasets, pre-processing of the dataset to ensure that the data is prepared for training the user interface models for generating appropriate visualization elements for the user interfaces, performing the training phase based on the pre-processed datasets, and performing an evaluation phase to evaluate performance of the user interface model.

[0127] For dataset acquisition, personalization subsystem 821 may acquire datasets from various sources, such as patient databases, medical history files, APIs, and real-time sensor feeds. In some embodiments, the dataset comprises multiple records, where each record includes one or more features (independent variables). In some embodiments, each record may include an associated label (e.g., dependent variable or target), which is used for supervised learning tasks, while unlabeled data can be used for unsupervised learning. In particular, datasets may include data regarding user information, user moods, and different types of user interfaces and visual interface elements.

[0128] In some embodiments, training the user interface models is based on supervised learning with labels mapping user information, such as medical history, user action patterns with software applications and their user device to specific moods or tonality. Examples of labels include amusement, neutral, different tonalities such as irritation, aggressive, depressed. Examples of medical history include user glucose data (e.g., current and historical), user diagnoses, and information from a user’s electronic medical records. Examples of user action patterns include application session lengths, sleep patterns, typing speed, typing errors, mouse movements, scroll patterns, and alert responsiveness (e.g., how quickly a user responds to alerts or notification, whether the user ignores alerts).

[0129] Datasets may also include different language sets that are organized based on different emotional contexts (such as mood, tonality) and assist in training the model in producing visual interfaces and content that is personalized based on predicted usermood. These language sets may include labelled data that indicate emotional categories (e.g., happy, sad, depressed, anger, irritation) and can include content such as comments, posts, conversations that are labelled based on the different emotional categories.

[0130] Datasets may also include labelled user interface or design patterns and examples of visual interface elements that are linked to specific emotional contexts. The labelled user interface information may also include recorded responses to different visual interface elements (such as color, theme, text prompts, layouts).

[0131] For the pre-processing phase, personalization subsystem 821 process the datasets for training. Preprocessing may include steps of data cleaning, data normalization, categorical encoding, and data splitting. Data cleaning includes removing or imputing missing values, eliminating duplicate entries, and correcting inconsistencies in the dataset. In particular, personalization subsystem 821 may analyze datasets to remove duplicate or conflicting emotion labels. Data normalization can include balancing emotional category labels, which can be imbalanced between different emotions (e.g., neutral vs. angry), to ensure that each label is given an appropriate balance within the dataset. Data splitting includes dividing the dataset into two or more subsets, typically training and testing sets. A portion of the data is used for model training, and the remaining portion is reserved for model evaluation to prevent overfitting. Emotional category labels can be split between different sets to avoid bios and samples from the same user or emotional category can be split between different datasets.

[0132] In particular, the present disclosure provides user interface models for generating visual interface elements based on predicted user mood of emotional context. In some embodiments, user interface models may be implemented as single hybrid model or a multiple model approach. Under the hybrid model, all data modalities (e.g., user medical data, user action pattern data) may be combined into a single feature input or vector for a single user interface model. This embodiment provides an easier input pipeline but easier to maintain (and retrain) but may not be as personalized as the multiple model approach. Under that approach, each of the different inputs may be provided to specific sub-models. For example, user medical data may be input for one specific sub-model and user action patterns may be input for another specific sub-model, and the outputs of these different sub-models may be combined (e.g. in a fusion layer) to generate the prediction and subsequent visual interface generation.

[0133] In some embodiments, the training phase begins by choosing a suitable model architecture for processing the datasets (e.g., physiological signals, user actions) such as the hybrid model or the multiple model architecture. Regardless of the architecture, personalization subsystem 821 may form a baseline model to gauge performance. A sample training loop may start by splitting the dataset into training, validation, and test sets (as discussed above) and training the model using the split datasets. During training, personalization subsystem 821 may optimize model weights or parameters using a loss function for classification of emotional states and mood.

[0134] In some embodiments, the baseline model may be generated initially based on segmentation input provided by a user (e.g., from an interactive tool displayed on the user device, based on user interaction with the mobile device, based on user preferences entered by the user at the mobile device), and the baseline model may be subsequently updated based on additional information such as user glucose information (e.g., glucose data, glucose history), user medical information (e.g., patient history, patient vitals), user action patterns (e.g., with the mobile device), and / or updated by the user (e.g., preferences, interactions with a visual interface element). The updated baseline model may then be continuously updated based on additional information such as updated glucose information, updated medical information, and user action patterns associated with the application on the user device that tracks user actions with the application, alerts, and notifications.

[0135] In some embodiments, personalization subsystem 821 may utilize hyperparameter tuning — e.g., grid search, random search, or Bayesian optimization — to refine learning rate, depth of layers or trees, dropout rates, and other critical parameters. For the evaluation phase, monitoring performance metrics such as accuracy, Fl score, or RMSE (depending on whether the task is classification or regression) assists in early stopping, preventing overfitting, and selecting the best model iteration.

[0136] In some embodiments, personalization subsystem 821 may utilize a combination of user interface models for generating user interface elements for the user. For example, personalization subsystem 821 may utilize a model that is specific to the user and one or more user interface model(s) that are specific to the groups associated with the user. Utilizing multiple models may increase the relevance of the user interface elements whichwill help ensure that the user take appropriate action in response to viewing the user interface elements.

[0137] In some embodiments, the user interface models may be configured to receive inputs (e.g., user analyte data, user medical history data, and user activity data) that are used to drive the generation of one or more user interface elements that are predicted to be relevant and useful personalized interface elements to be displayed on the EMUI. The inputs may additionally be used to train the user interface models. Output of the user interface models include one or more personalized user interface elements for the user. In some embodiments, the personalized user interface elements can be ranked or prioritized based on a probability or likelihood that the information provided by the user interface elements will be relevant or useful to the user in his current state and / or sometime in the future.

[0138] In some embodiments, EMUI engine 810 on data receiving device 120 is configured to monitor inputs, such as by to actively and passively monitor user actions, actively request user input or responses, such as via prompts or interactive games, to gauge user mood and personality, and to actively and passively monitor other user data to which the user application has access (or has been granted access), such as user calendar, user activity via third-party devices, and user medical information.

[0139] One example of a prompt includes an interactive tool for receiving user input in response to predefined questions. In some embodiments, the interactive tool may be used to establish a baseline profile for the user based on inputs provided to EMUI engine 810, which may be configured to characterize the user into, for example, a particular notification category segment (e.g., active user, guided user, passive / indifferent user, and routine-oriented user). Category segments may associated with different types of alerts, notifications, messaging, and messaging sequences, that are customized to maximize the changes that a user will enact a recommended course of action. For example, an active user may want to receive all information available (e.g., will receive most alerts, notifications, and messages), a guided user may want to receive specific guidance (e.g., will receive simplified alerts, notifications, and messages), an indifferent user may want to only receive important information (e.g., will receive only critical alerts, notifications, and messages), and a routine-oriented user may want to receive information at certain times of day or for certain events (e.g., will receive alerts, notifications, and messages atparticular scheduling preferences). It should be understood that fewer or more user segments may be used — each with different alert, notification, and message preferences. In some examples, the user’s category segment may change over time.

[0140] Other examples of prompts for receiving user input include detecting user interactions with the application (e.g., usage patterns associated with alerts, notifications, physical activity, interactions with visual interface elements, real-time queries displayed by visual interface elements) and detecting updates to user preferences or profile settings. In some embodiments, EMUI engine 810 may utilize some combination of each of these prompts to generate a baseline profile.

[0141] In some embodiments, the interactive tool may be configured with a customized algorithm implemented with EMUI engine 810 that is trained or developed for specific applications of EMUI engine 810, such as lifestyle monitoring or glucose monitoring. After EMUI engine 810 establishes the baseline profile, EMUI engine 810 may use the baseline profile to generate the baseline communication protocol for the user. The baseline communication protocol may include message types, alarm types, message sequences, tonality preferences, and notification scheduling preferences that are specific to the baseline profile of the user.

[0142] In some embodiments, the baseline profile generated from the interactive tool comprises at least one segmentation category that is used to configure the behavior of EMUI engine 810 with regard to personalization, notifications, and other types of messaging to be displayed. The type of segmentation category may indicate a periodicity of notifications (e.g., low frequency vs high frequency), types of notifications (text vs. voice vs. mixed media), and the types of visual user interface elements (e.g., gamification of information, text-based display of information), and the tone of content within visual interface elements.

[0143] In some embodiments, the baseline model may be subsequently updated based on additional information such as user glucose information (e.g., glucose data, glucose history) and user medical information (e.g., patient history, patient vitals). The updated baseline model may then be continuously updated based on additional information such as updated glucose information, updated medical information, and user action patterns associated with the application on the user device that tracks user actions with the application, alerts, and notifications.

[0144] EMUI engine 810 may be configured to retrieve one or more prompt variables based on the type of segmentation category, with the one or more prompt variables being inserted into a prompt input to EMUI engine 810. Prompt variables may be predefined and associated with each segmentation category to specify the formatting and content of visual elements from EMUI engine 810.

[0145] Prompt variables may specify the frequency of notifications, the types of notifications, the types of output for the content. For example, one segmentation category may indicate that a user requires more guidance and supportive-type messaging and the associated prompt variables may specify the formatting and content of the message based on that information from the segmentation category. For example, the prompt variable for this segmentation category may indicate notification should be displayed at a higher frequency.

[0146] In some embodiments, prompt variables may be text-based or mixed media (e.g., including images and audio). Text-based prompt variables may include specific language indicating the format of the output from EMUI engine 810, such as the frequency at which notifications are displayed and the visual formatting of the notifications. Visual prompt variables may display exemplary formatting for notifications or messages. Audio prompt messages may include the tone of a voice to be used when playing audio-based notifications or messages.

[0147] As another example, EMUI engine 810 may retrieve the appropriate prompt variables based on the segmentation category where the prompt variables specifies that output of the EMUI engine 810 should be generated in accordance with certain tonal parameters (e.g., soothing, comforting). As noted above, tonal parameters may be specified in text-based format, video format, or audio format. As another example, another segmentation category may indicate that another user requires more gamification for presentation of content. EMUI engine 810 may then retrieve prompt variables associated with this category that specifies the formatting and content of output from EMUI engine 810 that presents the output in the form of games or interactive graphics (e.g., which can be specified within the prompt variable as a video, image, and / or audio format).

[0148] EMUI engine 810 or personalization subsystem 821 may be configured to continuously update the baseline profile based on new inputs, such as user medicalinformation (historical, current, updated), user glucose information (historical, current, updated), and user action patterns, which results in an evolving profile that is updated to accommodate different moods and behaviors of the user on various days, times, or specific periods in the user’s life.

[0149] In some embodiments, EMUI engine 810 may be configured to monitor and process various other user inputs. These inputs may include, but are not limited to textual inputs, such as responses or messages received by the EMUI engine 810. Examples of textual inputs include any input typed by the user in response to prompts, alerts, message, and other notifications provided by EMUI engine 810.

[0150] In some embodiments, EMUI engine 810 may be configured to process audio data provided via a microphone of data receiving device 120. EMUI engine 810 may be configured to process audio data, such as voice inputs, for subject matter, tone, pitch, and sentiment, for detecting a current user mood or sentiment.

[0151] In some embodiments, EMUI engine 810 may be configured to process the user action patterns with EMUI engine such as touch gestures, typing speed, or device movement patterns, ignored alerts or notifications.

[0152] In some embodiments, personalization subsystem 821 may provide inputs to the user interface model. The inputs include user analyte data (e.g., provided by an in vivo analyte sensor), user medical history data (e.g., data regarding the user’s medical condition), and user activity data (e.g., user meal history, exercise data, device interaction data). The user interface elements may output by the user interface model include but are not limited to, intelligent nudges, trimmed display of information (e.g., vacation mode display), one or more tasks to accomplish a provided or predicted goal (e.g., reducing glycemic impact of a meal), a personalized avatar, and personalized offers for accessing additional devices such as sensors (e.g., as a voucher for retrieving such devices from a store).

[0153] Examples of medical history data include insulin dose delivery records, other medication delivery records, and medical conditions. Examples of user activity data include food consumption, physical activity, user location, user events, current day-of- the-week, current time-of-day, and current calendar date (e.g., holidays).

[0154] In some embodiments, user interface models may be trained deep-learning based approaches. The method used may dictate the information needed to train the userinterface model. Deep Learning (DL) is a category of Machine Learning (ML) techniques for training models to preform classification and prediction tasks. In the context of generating personalized user interface elements, a user interface model can take as input, pass it through trained Artificial Neural Network (or similar type of training model), and produce one or more personalized user interface elements for display on the EMUI. In some embodiments, the EMUI may be updated on a periodic basis with new user interface elements that are generated in response to new inputs, such as new user analyte data or user activity data.

[0155] Training the model using deep learning does not require specific identification of features to be generated in the user interface model, but rather relies on the design of a more generic neural network structure that can self-adapt to the detection of features in the data that correlate to different types of user interface elements. This adaption may be accomplished through the training process of the user interface model by feeding into it user analyte data, user medical history data, and user activity data with known user interface elements, so that the user interface model can automatically learn of the patterns and adjust its model parameters to look for the most relevant features that correlate to the different types of user interface elements. The result of this training process is a user interface model tailored to generation of personalized user interface models.

[0156] In this manner, the user interface models (whether the model was initially trained to a particular user or a particular group of users) may be further personalized to each specific user based on the unique characteristics of each user to generate user interface elements that are more specific and relevant to a user’s current and / or future status or condition. A greater extent of personalization of the user interface elements may be achieved by developing a user interface model for each person using the data collected from that particular person only. There are two technical barriers for developing and deploy personalized model for each user in this manner: the time it takes to collect enough user-specific data for developing the model and the cost for training and deploying a personally developed ML model for each user.

[0157] In some embodiments, user interface models may be trained for a particular disease (e.g., diabetes) or on an even more granular level, such as different stages of a particular disease (e.g., first year of diabetes, second year of diabetes). In this manner, a EMUI may include personalized user interface elements that can be customized at adesired granularity for the user’s particular condition. For example, personalized user interface elements for a 30-y ear-old male user who was diagnosed with diabetes in the past year would be different from personalized user interface elements for a 50-year-old female who has had diabetes for 15 years. In this example, the EMUI engine 810 would use a different user interface model for generating the personalized user interface elements for the 30 year old male than the 50-year-old female. As non-limiting example, EMUI engine 810 may utilize a user interface model that is trained for male patients with diabetes and another user interface model that is trained for female patients with diabetes. As another non-limiting example, EMUI engine 810 may utilize a user interface model that is trained for patients who have been diagnosed with diabetes within the past year and another user interface model that is trained for patients who have been treating their diabetes for over 10 years. As another non-limiting example, the user interface model may be trained for patients based on their medication, such as whether on oral meds, basal injections, rapid acting insulin injections, and / or a combination.

[0158] In this manner, the different user interface models may adapt the EMUI for each user based on their specific characteristics and as they progress through their medical journey of treating their medical condition.

[0159] In some embodiments, EMUI engine 810 and / or personalization subsystem 821 may employ a hybrid strategy, first utilizing a user interface model trained based on a larger dataset from a cohort or population of users and then gradually replacing the population-based user interface model with a personal user-specific model over time as more data from the user is collected for input. In some embodiments, the personal user interface model can gradually replace the population-based model over a period of time or always used in combination. In either embodiment, the user interface elements can be generated based on a weighted average of the population and user-specific user interface models, and the weight of the user-specific model can be gradually increased from 0 to 100% while the weight of the population model is gradually decreased. Personalization subsystem 821 may employ a model selector which may be used to select between the population model and user-specific model and for adjusting the weights between them.

[0160] In some embodiments, population models may be implemented as pre-trained models and stored on data receiving device 120 and / or a remote server, such as trusted computer system 180. Pre-trained models may be models used by personalizationsubsystem 821 to generate personalized user interface elements that include one or more intelligent nudges, goal or tasks associated with a user’s medical condition, a virtual avatar that is customized for the user and configured to provide an interactive element to the EMUI, and cohort analysis that provides interface elements that enable a user to communicate with other users through the EMUI. As noted above, pre-trained population models may include, as inputs, user analyte data, user medical history data, and user activity data. User activity data include food related data such as glycemic index, glycemic load, food composition, food category labels, glucose appearance, profile features, pre-meal glucose, and other suitable values. User activity data may also include physical activity related data such as steps per unit time, heart rates, an exercise mode, a duration, and other suitable values. User activity data may also include device interaction data such as user activity on data receiving device 120.

[0161] User activity input subsystem 822 may be used to receive and store data related to user activity including food choice, physical activity, and user interaction with data receiving device 120. In some embodiments, a food choice may also specify a quantity or portion size. The term “food” may be used interchangeably with “meal” and so food choice referred to in may also be referred to as a meal choice or a sequence of meals. Parameters may be associated with the meal choice that allow personalization subsystem 821 to generate user interface elements that include messages related to the food choice. Broadly speaking, parameters may be first-principles-based or clinical-practice-based. In the context of meal choice, first-principles-based parameters and clinical-practice-based parameters correspond to parameters that are involved in describing the effect of a meal on a person’s glucose, either based on first-principles derivation or clinical practice. For example, first-principles-based models are generally represented by one or more equations with variables that vary over time, representing physical or conceptual compartments involved in the process of a meal affecting the person’s glucose. The parameters involved in these equations are considered first-principles-based parameters and predominantly involve compartment-based-modeling — z.e., modeling one or more compartments with a pre-determined static or dynamic relationship. In contrast, clinical- based-parameters are parameters that are commonly used to describe certain quantification and / or qualification of the nature of the meal effect on glucose in clinical practice. For example, first-principles-based parameters specific to a meal choice may be:(1) rate of glucose appearance profile in an averaged person with standard food bioavailability, and (2) information needed for a user’s gastric emptying related to the meal choice such as solid-liquid ratio of the meal. Examples of clinical-practice-based parameters specific to a meal choice may be: (1) glycemic index, (2) glycemic load, (3) macronutrient composition (percentage of carbohydrate, fat and protein), and (4) fiber content.

[0162] Because a meal choice may use first-principles-based parameters that are more naturally mathematically modelled, personalization subsystem 821 may support differing classes of meal information. For example, categorization fields may be the branded name of a food item as chosen by a partner restaurant, generic meal name (e.g. whole fried onion), or a general category (e.g, fried appetizer, bread, pasta). Personalization subsystem 821 may generate a random forest subsystem or other supervised machine learning model that reconciles all possible combinations of meal information types to provide unified meal input information.

[0163] Personalized glycemic profiles 823 may include user medical history data and personalized parameters for users including user 802. User medical history data may include past readings of glucose data tracked over time and data and parameters about past and / or current exercise sessions. Personalized glycemic profiles 823 may also include user-specific parameters. The user-specific parameters may comprise personalized adjustment parameters that are discussed in further detail below with reference to personalized parameters, which may be personalized adjustment parameters for personalizing user interface elements. Examples of adjustment parameters include user preferences, changes to user analyte data over time (z.e., trends), and changes to user medical history data over time. Once generated, personalized interface profiles 823 may be used for generating the personalized user interface elements. Population profiles may be selected that have characteristics similar to user 802 and then utilized for generating additional personalize user interface elements that are personalized based on the cohort associated with user 802.

[0164] Visualization subsystem 824 may generate and update the EMUI that include the personalized user interface elements as they are generated. Visualization subsystem may also selectively include personalized user interface elements based on certain options (e.g., vacation mode, user mentality) to increase the efficiency and impact of the interfaceelements so that the user 802 is more likely to take action based on the personalized user interface elements.

[0165] Partner integration subsystem 825 may integrate with partner systems. Such partner systems may include restaurants, diet programs, exercise programs, etc. Partner integration subsystem 825 may access APIs provided by partner system to receive appropriately structured and parameterized information about food choices and / or exercise sessions. As discussed below, this parameterized information may be used by Personalization subsystem 821 to predict future glucose values.

[0166] Partner integration subsystem 825 may establish a link to a partner system such as partner API 830. Such partner systems may include restaurants, diet programs, exercise programs, etc. In one embodiment, partner integration subsystem 825 may access menu options in response to user 802 scanning QR code 808 in a partner restaurant. Partner integration subsystem 825 may also access menu options via communications over NFC source 811.

[0167] Partner integration subsystem 825 may import food options and a communicable set of parameters for each menu choice by accessing partner API 830. For example, partner API 830 may provide an endpoint such as get_items() that partner integration subsystem 825 may access to receive both the menu items selectable by user 802 and the parameters associated with each menu item used by Personalization subsystem 821 to predict a near future glucose value.

[0168] User 802 may select a particular menu choice. User 802 may also indicate the portion size of the item. Data receiving device 120 may provide differing methodologies for entering the meal information. For example, user 802 may select categories of fields such as the branded name of a food item as chosen by a partner restaurant, generic meal name (e.g. whole fried onion), or a general category (e.g. fried appetizer). In another embodiment, user 802 may select a menu option in a partner system (e.g., in an ordering tool provided by the partner), and partner API 830 may communicate the user selection to data receiving device 120. By communicating the menu item to data receiving device 120, it obviates the need for user 802 to enter the menu selection in both the partner system and the data receiving device 120.

[0169] Personalization subsystem 821 may generate a personalized user interface element. Personalization of user interface (visual) elements may be based on anycombination of user information included information provided via a selected menu item, a history of user meal choices or sequences, and the user segment. Personalization subsystem 821 may combine user analyte data, user medical history data, and information related to a user choice (such as food choice or exercise). Personalization subsystem 821 may employ a variety of machine learning models and user profiles to generate personalized user interface elements, such as personalized nudges or messages, that provide guidance or suggested actions for the user to take based on the provided food choice. Visualization subsystem 824 may display the personalized user interface element on the EMUI. The visualization data may be presented as a single trace (z.e., a line), a range, or using another suitable approach that allows the user to view future data relative to their latest glucose profile. This time range may be several minutes or several hours or other suitable time range.

[0170] Personalization subsystem 821 may be configured to dynamically modify content and tone of predefined or preexisting messages, alerts, and other communications based on a detected current mood or current state of mind of the user, such as via the baseline profile or via an updated profile. Examples of this processing may include sentiment analysis techniques for textual and audio inputs, machine learning algorithms for recognizing patterns in physical and biometric data, and contextual analysis to correlate environmental factors with historical mood trends.

[0171] In some embodiments, based on the detected mood, personalization subsystem 821 can dynamically modify the content and tone of preexisting messages to better suit the user's current emotional state. This modification may include tone adjustment for converting a neutral notification into a more empathetic or motivational message, content reordering for highlighting specific portions of a notification most relevant to the user's mood, and simplification for reducing the complexity of information for users detected to be in an overwhelmed state.

[0172] In some embodiments, personalization subsystem 821 may determine an ideal sequence of notifications or alerts based on any combination of user information accessible to personalization subsystem 821, including user segment, user predicted mood and previous interactions (e.g., user action patterns, user profile). This sequence detection can involve prioritization algorithms for determining the urgency and relevance ofmessages for the detected mood, engagement tracking for adapting subsequent notifications based on the user's interaction with previous messages.

[0173] App repository 826 may be a catalog of installable applications from which clientside components running on data receiving device 120 may be downloaded and installed. While FIG. 8 displays app repository 826 within trusted computer system 180, in other embodiments, app repository 826 may be a widely used app repository from which mobile device applications may be downloaded and installed onto data receiving device 120.

[0174] Database 827 may store the user analyte data, user medical history data, and the user activity data that are used to generate one or more personalized user interfaces for display on the EMUI. Database 827 may be a relational database, a NoSQL database or other horizontally scaling database, a digital ledger technology or blockchain, or any other suitable storage mechanism. For instance, database 827 may be a commercially available database management system to store and retrieve data. In an embodiment, database 827 may be retrieved data from a centralized storage area network (SAN), network-attached storage (NAS), redundant array of independent disks, and / or any other configuration of storage devices to supply sufficient storage capacity to store database tables and supporting structures. Sufficient storage may alternatively exist in any other physically attached magnetic storage, cloud storage, or additional storage medium. In an embodiment, database 827 may deploy a hard-disk interface, such as ATA, SATA, SCSI, SAS, and / or fibre for interfacing with storage mediums housing data.

[0175] Partner API 830 may be a secure interface that facilitates interactions between data receiving device 120 and partner systems. Such partner systems may include restaurants and diet programs. Partner API 830 is associated with an endpoint, z.e., a resource (often represented as a unique URL) that may accept requests to the services provided. For example, partner API 830 may leverage various communication standards and protocols, e.g., TLS, SSL, HTTP, HTTPS, etc., to further communication between various components. Partner API 830 may provide an addition level of security for both the client / requestor and server / responder because limited types of communications transpire between the client and server, obviating the need for any party to fully expose its data. By accepting and responding to requests, partner API 830 may provide functions that allow data receiving device 120 to receive a particular menu and / or particular foodchoices on a menu from a partner restaurant. These food choices may include communicable sets of parameters that allow the user interface discussed below to select one or more items from a menu to create a what-if scenario predicting future glycemic information.Evolving Medical User Interfaces

[0176] FIG. 9 is an example flowchart 900 for generating one or more personalized user interface elements for display on a EMUI, according to some embodiments. The flowchart provided in FIG. 9 is merely exemplary, and one skilled in the relevant art(s) will appreciate that many approaches may be taken to provide personalized user interface elements in accordance with this disclosure.

[0177] Flowchart 900 depicts data sources providing user analyte data 902, user medical history data 904, and user activity data 906 to an EMUI engine 908. As described above, EMUI engine 908 may be implemented locally at a data receiving device on which a medical application is installed to communicate with an in vivo sensor (e.g., data receiving device 120) or remotely at a server that is configured to communicate with the data receiving device (e.g., personalization subsystem 821).

[0178] In some embodiments, user analyte data 902 may include current and / or recent analyte readings received by data receiving device 120 from in vivo analyte sensor 104. One example of user analyte data 902 includes glucose values provided from a CGM sensor. User analyte data 902 may include the analyte readings in various formats including values that vary over a period of time (e.g., over the past day, three days, seven days). In some embodiments, user analyte data 902 may further include a timestamp indicating a time that the reading was taken and trend information indicating trends of the analyte data over a period of time.

[0179] User medical history data 904 may include data from sources that provide information about the user’s medical history. Example of sources include hospital databases, sensor manufacturer databases, HCP databases, and electronic medical records (EMR). The purpose of user medical history data 904 is personalize the EMUI 920 as the user’s medical condition progresses through its various stages (e.g., initial diagnosis, treatments, recovery, etc.) Accordingly, using user medical history data as part of generating personalized user interface elements for display on the EMUI 920 allows the interface to evolve with the user’s needs and condition. In some embodiments, an initialstep may include providing all medical data of the user starting from the diagnosis and including doctors’ visits and hospital visits. Subsequently, medical history data may be updates incrementally as the user continues treatment of the medical condition.

[0180] User activity data 906 may include data from sources that provide information about the user’s other activity, including their food / meals, physical activity, and their interaction with data receiving device 120. This data may be provided from a dedicated food / activity tracker that track’s a user’s food choices including calories at times of day, size of meal, and other meal details. Other possible features include tagging favorite foods and providing food trends.

[0181] EMUI engine 908 may be configured to sequence the user activity data 906, which may include organizing user’s food / meals and / or activity into a sequence of food consumption and / or exercise. Sequencing may be performed automatically, such as via user preferences that indicate a general sequence in which meals or food options are generally eaten (e.g., salad eaten first, tiramisu eaten last) or via a sequencing model that is trained (on a per-user basis or per population basis) for organizing options or activities into a particular sequence. For example, either the user preferences or sequencing model may organize the food choices / meals and / or activity into a temporal order.

[0182] In some embodiment, EMUI engine 908 may personalize meal sequences based on user analyte data 902. EMUI engine 908 may receive user analyte data 902 from a continuous glucose monitoring system. The meal sequencing may be adapted to reflect impact on glucose level of the user based on user analyte data 902. EMUI engine 908 may adjust or suggest different sequencing of provided meals that takes into account the user analyte data 902. For example, user analyte data 902 may indicate different impacts of meals or food on user glucose levels.

[0183] EMUI engine 908 may be configured to retrieve one or more prompt variables associated with the user analyte data 902 and incorporate the retrieved prompt variables as part of an input to EMUI engine 908 when generating the meal sequence. The prompt variables may include predefined text or media that defines the format and / or content for the meal sequencing. For example, a predefined prompt variable may indicate that meals with carbs above a certain threshold amount should be consumed after one or more meals with a protein and / or fiber amount above a certain threshold amount.

[0184] As another example, a predefined prompt variable may also indicate the type of content be output, such as a “best meal” or other labelling for meals based on the determined impact using user analyte data 902.

[0185] In some embodiments, user analyte data 902 may also indicate a retrospective analysis of meals and their glycemic impact on the user (e.g., a meal that had the highest or lowest glycemic impact). Another predefined prompt variable may indicate that EMUI engine 908 should incorporate specific information, such as the retrospective analysis of meals when generating output for display on the personalized user interface elements.

[0186] EMUI engine 908 may direct received input to one or more user interface models for generating personalized user interface elements, which can be categorized into different output categories such as intelligent nudges 910, goal / task generation 912, virtual avatar 914, mentality interfaces 916, and cohort view 918. In some embodiments, EMUI engine 908 may implement the one or more user interface models and therefore receive input including prompt variables and generate output. In some embodiments, EMUI engine 908 may be in communication with the user interface models, which can be implemented remotely, such as a server. In such embodiments, EMUI engine 908 is configured to package inputs, including any prompt variables, transmit the input to the user interface models, and receive corresponding output from the user interface models.

[0187] There may be different prompt variables associated with each output category. For example, there may be prompt variables associated with intelligent nudges 910, goal / task generation 912, virtual avatar 914, mentality interfaces 916, and cohort view 918. As an example, a prompt variable for intelligent nudges 910 may be inserted into a prompt input to instruct the user interface model to generate output with content for a nudge (e.g., an alert, notification) in a desired format (e.g., text message, video, animation). As another example, a prompt variable for mentality interfaces 916 may include description or examples of tonal characteristics (e.g., alerting, calming, soothing, supportive) that may be inserted into a prompt input to instruct the user interface model to generate output with content having the specific tonal characteristics.

[0188] Intelligent nudges 910 are personalized messages for the user to take actions with respect to their medical condition and based on one or more of the user analyte data 902, the user medical history data 904, and the user activity data 906. The personalized message may be displayed by EMUI 920 for providing rewards and recognition,recognizing and rewarding user actions, and encouraging user actions. As will be discussed with respect to mentality interfaces 916, intelligent nudges 910 may also be adapted based on user mood (e.g., nudges / messages vs. encouragement) and / or to convey different nudge "personalities" or tonality to fit the user's current mentality or mood.

[0189] An example of a reward message is a voucher that can be provided via the medical application to obtain new sensors. For example, the intelligent nudge 910 may be a barcode or QR code that can be scanned at a pharmacy or store. The barcode or QR code is linked to the distribution of a new sensor to the user such that when the barcode or QR code is scanned, the pharmacy or store receives a message authorizing the distribution of the sensor to the user. In some embodiments, a voucher message may be generated based on one or more of the user analyte data. For example, the user analyte data may indicate a certain amount of data since the sensor was activated for the user or that the previous analyte readings have been inconsistent which could indicate that the sensor is becoming loose or that the sensor tip is coming out of the skin.

[0190] Another example of an intelligent nudge is providing connections between foods / meals, physical activity, and glucose levels. EMUI engine 908 may generate a nudge to inform the user about the relationship between a food / meal, physical activity, and the user’s glucose level for a certain period of time (e.g., over the last few hours, over the past day). In some embodiments, EMUI engine 908 may utilize a user interface model trained based on food / meals and physical activity and is trained to provide correlations between foods / meals, physical activity, and glucose levels.

[0191] Intelligent nudges 910 may also be linked to goal / task generation 912. A user or a medical application may set a goal for the user (e.g., physical activity goal, caloric intake goal, glucose level goal). EMUI engine 908 may determine, based on one or more of the user analyte data 902, the user medical history data 904, and the user activity data 906 that the user has met the goal and generate an intelligent nudge to recognize that the goal has been met.

[0192] Goal / task generation 912 assist patients in achieving established goals by providing discrete steps / tasks to achieve a specified goal. These discrete tasks may be packaged in an intelligent nudge and displayed to the user sequentially (as each task is completed) or all at once (like a checklist). As one example, there may be a goal for a user to maintain a glucose level below a certain threshold for an entire day. EMUI engine908 may utilize one or more of the user analyte data, the user medical history data, and the user activity data to generate tasks for the user to accomplish that goal. This task may be based on user analyte levels and activity data from previous time periods and EMUI engine 908 is utilizing that information to forecast which tasks will be most likely to assist the use in maintaining the glucose level below the particular threshold. For example, EMUI engine 908 may determine, based on one or more of the user analyte data, the user medical history data, and the user activity data, that the user had maintained glucose levels below the set threshold on days where the user at breakfast, lunch, and dinner and had a certain amount of physical activity. EMUI engine 908 may then use that analysis to generate the tasks to accomplish that same goal.

[0193] In some embodiments, prompt variables associated with a segmentation category may specify the types of goals or tasks to be output as part of goal / task generation 912. For example, a prompt variable may specify a ranking of tasks for the user and goals that are specific to the user or for the segmentation category. Another prompt variable may indicate how much data, such as user analyte data 902, the user medical history data 904, and the user activity data 906, that should be included as part of the input for generating the tasks and goals.

[0194] EMUI engine 908 may also generate a virtual avatar 914 that is displayed by a medical application and could have multiple uses and embodiments. Example embodiments for a virtual avatar 914 include a visualization for user's current mood, activity, and / or glucose conditions, providing an interface for responding to questions and providing access to resources, being deployed as the user's virtual presence in a community engagement forum with other users, serving as the visualization for displaying the intelligent nudges 910, providing an interface based on the user’s predicted mentality or mood (ie., adapting avatar "tonality" or behavior based on user mood / activity), and providing a manipulable interface for the user to indicate his current mood or activity (e.g., putting avatar to sleep to indicate he is going to bed or in a swimsuit to indicate vacation mode).

[0195] There may be one or more prompt variable associated with a segmentation category for generating the virtual avatar 914. For example, the segmentation category associated with a user may specify prompt variables that can include user's current mood (e.g., as determined based on active or passive user activity tracking), user physicalactivity, and / or glucose conditions, visualization preferences for the user (e.g., female or male avatar), tonality preferences, and audio preferences. EMUI engine 908 may retrieve the prompt variables associated with the segmentation category and include as part of an input to the user interface model for generating the virtual avatar 914.

[0196] Aspects of virtual avatar 914 may be personalized based on the embodiment and the data provided from the user. For example, the appearance of the avatar to reflect how the user is feeling and / or their current state (e.g., activity, medical condition). EMUI engine 908 may determine the user’s feeling and / or current state based on user input (e.g., user responding to questions) and / or based on one or more of the user analyte data, the user medical history data, and the user activity data. For example, EMUI engine 908 may provide user analyte data, the user medical history data, and / or the user activity data to one or more user interface models trained to predict user emotions based on any combination of the user’s analyte levels, user’s previous medical history, and their user activity data. Predicting a user’s mental state is discussed further with regard to the mentality interface 916.

[0197] EMUI engine 908 may combine functions of intelligent nudges 910 and virtual avatar 914. For example, the virtual avatar 914 may be utilized to display any intelligent nudges 910 (e.g., as if the avatar were providing the message). EMUI engine 908 may utilize a user interface model to generate intelligent nudges 910 based on a predicted user emotion or mental state. In some embodiments, the intelligent nudges 910 may include recommendations (e.g., take a nap, exercise, eat a high-fiber snack) and the virtual avatar 914 may be adjusted to visually depict the recommended action to encourage the user to perform the recommended action. For example, the virtual avatar 914 may visually take a nap, exercise, or eat an apple based on the content of the intelligent nudge. In other embodiments, virtual avatar 914 merely communicates the intelligent nudge 910 to the user (e.g., as a coach).

[0198] EMUI engine 908 may adjust behavior of the virtual avatar 914 and / or tonality of intelligent nudges based on the predicted user mood or mental state and / or user preference. EMUI engine 908 may rely on another user interface model to determine behavior and tonality that would likely be more effective in causing the user to take the recommended action based on the predicted user mood. For example, a user in a predicted sad or depressed mood may respond more positively to seeing the virtual avatar 914performing the recommended action instead of a virtual avatar 914 that is attempting to coach or encourage the user the perform the recommended action.

[0199] EMUI engine 908 may configure virtual avatar 914 to be manipulable via an input of data receiving device 120. User may manipulate virtual avatar 914 as a way of communicating his current mood and / or activity to EMUI engine 908. For example, virtual avatar 914 may be associated with predefined actions (e.g., being put to sleep, being put in exercise or vacation clothes, happy or sad faces) which are selectable to indicate the user’s mood or activity which may be used by EMUI engine 908 to generate the personalized user interface elements, such as the intelligent nudges 910 or for a particular mentality interface 916, as discussed below.

[0200] In some embodiments, virtual avatar 914 may also be connected to an Al subsystem and provide an Al prompt interface for responding to user queries in an on- demand manner. Al subsystem may be trained to specifically respond to inquiries regarding medical conditions and / or sensor production information. For example, the Al subsystem may be trained to provide information specific to diabetes and a CGM sensor.

[0201] Mentality interface 916 may adjust personalized user interface elements based on a predicted (or provided) user mental state or condition and / or a user preference. EMUI engine 908 may utilize active (e.g., prompts, questions, avatar interaction, interactive tool discussed in FIG. 8) and passive (behavior tracking via user activity data) methods for determining user mental state. An example of a user preference is a feature provided by EMUI engine 908 that would allow the user to turn on or off certain user interface elements. For example, EMUI engine 908 may provide a menu for turning off food- related or exercise-related user interface elements. When selected, EMUI engine 908 may prevent those types of user interface elements from being displayed on the EMUI 920.

[0202] There may be one or more prompt variable associated with a segmentation category for generating the mentality interface 916. For example, the segmentation category associated with a user may specify prompt variables that can include user's current mood (e.g., as determined based on active or passive user activity tracking) and tonality preferences. EMUI engine 908 may retrieve the prompt variables associated with the segmentation category and include as part of an input to the user interface model for generating the mentality interface 916.

[0203] One example of a mentality interface is a vacation mode (e.g., when the user is on vacation, on holiday, taking a break from a routine, etc.), which can be indicated for example, by user preference, user interaction with the virtual avatar 914, and / or geolocation detection of data receiving device 120. In some embodiments, an interface set to a vacation mode modifies the user interface elements that are displayed on the interface. For example, the interface may be modified to display a reduced number of user interface elements, a configurable number of user interface elements (can be customized by the user, turned on or off by the user). Other non-limiting examples of user interface elements include alerts, notifications, and glucose visualizations such as trend data, charts, graphs, tables). Configurable aspects of user interface elements can further include frequency of display, frequency of updates, threshold values for different alert criticalities e.g., critical, severe, normal), and threshold values for displaying glucose data, just to name a few examples.

[0204] Another example is a streamlined interface that prevents or emphasizes personalized user interface elements based on the user’s predicted (or provided) mental state. For example, if the user’s mental state indicates that they are not in the mood to exercise, EMUI engine 908 is configured to prevent intelligent nudges 910 related to exercise from being displayed to the user. This adaptation of EMUI engine 908 displaying or preventing the display of certain user interface elements may occur on an on-going basis (e.g., throughout the day) and based on any changes to the user’s mental state. That is, mentality interface 916 may adapt recommendations on a day-to-day basis rather than following a strict protocol of encouragement

[0205] Mentality interface 916 may also include providing access to stress management tools such as meditation. This access may be a link to an external website or application. In other examples, mentality interface 916 may display stress management tools within the app. For example, mentality interface 916 may display meditation exercises, display tips for reducing stress, etc. Mentality interface 916 may coordinate with EMUI engine 908 to generate mood profiles for users and provide the mood profiles as part of the user activity data that is provided for training user interface models as well as utilizing trained user interface models for generating personalized user interface elements.

[0206] Mentality interface 916 may also be configured with interfaces (e.g., in combination with virtual avatar 914) to facilitate patient engagement via the personalizeduser interface elements. The user interface elements are generated in a personalized manner for each user based on user characteristics including personality, mood, feelings that particular day, analyte levels, and medication history.

[0207] Cohort view 918 is a personalized user interface element that includes features related to users that are similar to one or more characteristics of the user. Cohort view 918 is configured to organize user analyte data, user medical history data, and user activity data on a population basis to increase the accuracy and relevancy of personalized user interface elements. For example, user interface models may be trained based on data organized based on a per-user or per-population (cohort) basis. Examples of cohort characteristics include disease, gender, age, analyte levels, medical history, and activity level. As noted above, cohorts may be organized at different levels of granularity which can combine one or more characteristics into a user interface model. Cohort view 918 may also coordinate with intelligent nudges 910 to provide recommendations / suggestions based on activity, actions, and / or conditions of similar patients to increase relevance and efficacy of the recommendation.Exemplary Computer Embodiment

[0208] Various embodiments may be implemented, for example, using one or more well- known computer systems, such as computer system 1000 shown in FIG. 10. One or more computer systems 1000 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

[0209] Computer system 1000 may include one or more processors (also called central processing units, or CPUs), such as a processor 1004. Processor 1004 may be connected to a communication infrastructure or bus 1006.

[0210] Computer system 1000 may also include user input / output device(s) 1008, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 1006 through user input / output interface(s) 1002.

[0211] One or more of processors 1004 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0212] Computer system 1000 may also include a main or primary memory 1008, such as random-access memory (RAM). Main memory 1008 may include one or more levels of cache. Main memory 1008 may have stored therein control logic (z.e., computer software) and / or data.

[0213] Computer system 1000 may also include one or more secondary storage devices or memory 1010. Secondary memory 1010 may include, for example, a hard disk drive 1012 and / or a removable storage device or drive 1014. Removable storage drive 1014 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and / or any other storage device / drive.

[0214] Removable storage drive 1014 may interact with a removable storage unit 1018. Removable storage unit 1018 may include a computer usable or readable storage device having stored thereon computer software (control logic) and / or data. Removable storage unit 1018 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and / any other computer data storage device. Removable storage drive 1014 may read from and / or write to removable storage unit 1018.

[0215] Secondary memory 1010 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and / or other instructions and / or data to be accessed by computer system 1000. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 1022 and an interface 1020. Examples of the removable storage unit 1022 and the interface 1020 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and / or any other removable storage unit and associated interface.

[0216] Computer system 1000 may further include a communication or network interface 1024. Communication interface 1024 may enable computer system 1000 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 1028). For example, communication interface 1024 may allow computer system 1000 to communicate with external or remote devices 1028 over communications path 1026, which may be wired and / or wireless (or a combination thereof), and which may includeany combination of LANs, WANs, the Internet, etc. Control logic and / or data may be transmitted to and from computer system 1000 via communication path 1026.

[0217] Computer system 1000 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and / or embedded system, to name a few non-limiting examples, or any combination thereof.

[0218] Computer system 1000 may be a client or server, accessing or hosting any applications and / or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“onpremise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (laaS), etc.); and / or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

[0219] Any applicable data structures, file formats, and schemas in computer system 1000 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

[0220] In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 1000, main memory 1008, secondary memory 1010, and removable storage units 1018 and 1022, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 1000), may cause such data processing devices to operate as described herein.

[0221] Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and / or computer architectures other than that shown in FIG. 10. In particular, embodiments can operate with software, hardware, and / or operating system implementations other than those described herein.

[0222] It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

[0223] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and / or entities illustrated in the figures and / or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

[0224] Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

[0225] References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned ordescribed herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and / or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0226] The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.Clauses

[0227] Exemplary embodiments are set out in the following numbered clauses.1. A method, comprising: receiving, at a mobile device, user segmentation input; generating a baseline user profile based on the user segmentation input; receiving, at a mobile device, user glucose data from an in vivo glucose sensor, wherein the in vivo glucose sensor is configured to be attached to a user; receiving, at the mobile device, user medical history data from a remote source; updating the baseline user profile based on the user glucose data and the user medical history data; generating, based on a user interface model, a personalized user interface element based on the updated baseline user profile; displaying a visualization comprising the personalized user interface element on a mobile application running on the mobile device; receiving, at the mobile device, user activity data from at least one of the mobile device or a wearable device associated with the user; generating a second personalized user interface element based on the user activity data, the user glucose data, and the user medical history data; and updating the visualization to display the second personalized user interface element.2. The method of clause 1, wherein the user interface model generates a predicted condition of the user.3. The method of clause 2, wherein the personalized user interface element comprises a personalized message that includes content for addressing the predicted condition.4. The method of clause 2 or 3, wherein the personalized user interface element comprises a personalized avatar that represents the predicted condition of the user.5. The method of any preceding clause, wherein the predicted condition comprises at least one of a user glucose level and a determined user mood.6. The method of any preceding clause, wherein the user interface model is configured to receive, as input, the user analyte data and the user medical history data, and provide, as output, the personalized user interface element.7. The method of any preceding clause, wherein the user interface model is stored at the mobile device.8. The method of any preceding clause, wherein the user interface model is a machine learning model and / or a trained model which is optionally trained remotely, and / or is trained specific to a particular user or group of users based on one or more characteristics.9. The method of any preceding clause, wherein the user analyte data comprises glucose data of the user over a predetermined period of time.10. The method of any preceding clause, wherein the user segmentation input is determined based on at least one of user interaction with the mobile device or via an interactive query tool displayed by the mobile device.11. A mobile device comprising: a memory; a processor coupled to the memory and configured to: receive user segmentation input; generate a baseline user profile based on the user segmentation input;receive user glucose data from an in vivo glucose sensor, wherein the in vivo glucose sensor is configured to be attached to a user; receive user medical history data from a remote source; update the baseline user profile based on the user glucose data and the user medical history data; generate, based on a user interface model, a personalized user interface element based on the updated baseline user profile; display a visualization comprising the personalized user interface element on a mobile application running on the mobile device; receive user activity data from at least one of the mobile device or a wearable device associated with the user; generate a second personalized user interface element based on the user activity data, the user glucose data, and the user medical history data; and update the visualization to display the second personalized user interface element.12. The mobile device of clause 11, wherein the user interface model generates a predicted condition of the user.13. The mobile device of clause 11 or 12, wherein the personalized user interface element comprises a personalized message that includes content for addressing the predicted condition.14. The mobile device of any preceding clause, wherein the personalized user interface element comprises a personalized avatar that represents the predicted condition of the user.15. The mobile device of any preceding clause, wherein the user interface model is configured to receive, as input, the user analyte data and the user medical history data, and provide, as output, the personalized user interface element.16. The mobile device of any preceding clause, wherein the user interface model is stored at the mobile device.17. The mobile device of any preceding clause, wherein the user interface model is a machine learning model and / or a trained model which is optionally trained remotely, and / or is trained specific to a particular user or group of users based on one or more characteristics.18. The mobile device of any preceding clause, wherein the user analyte data comprises glucose data of the user over a predetermined period of time.19. A non-transitory computer-readable device having instructions stored thereon that, when executed by a computing device, causes the computing device to perform operations comprising: receiving, at the computing device, user medical history data from a remote source; updating the baseline user profile based on the user glucose data and the user medical history data; generating, based on a user interface model, a personalized user interface element based on the updated baseline user profile; displaying a visualization comprising the personalized user interface element on a mobile application running on the computing device; receiving, at the computing device, user activity data from at least one of the mobile device or a wearable device associated with the user; generating a second personalized user interface element based on the user activity data, the user glucose data, and the user medical history data; and updating the visualization to display the second personalized user interface element.20. The non-transitory computer-readable device of clause 19, wherein the user interface model generates a predicted condition of the user.21. The non-transitory computer-readable device of clause 19 or 20, wherein the personalized user interface element comprises a personalized message that includes content for addressing the predicted condition.22. The non-transitory computer-readable device of any preceding clause, wherein the personalized user interface element comprises a personalized avatar that represents the predicted condition of the user.23. The non-transitory computer-readable device of any preceding clause, wherein the user interface model is configured to receive, as input, the user analyte data and the user medical history data, and provide, as output, the personalized user interface element.24. The non-transitory computer-readable device of any preceding clause, wherein the user interface model is stored at the mobile device.25. The non-transitory computer-readable device of any preceding clause, wherein the user interface model is a machine learning model and / or a trained model which is optionally trained remotely, and / or is trained specific to a particular user or group of users based on one or more characteristics.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: receiving, at a mobile device, user segmentation input; generating a baseline user profile based on the user segmentation input; receiving, at a mobile device, user glucose data from an in vivo glucose sensor, wherein the in vivo glucose sensor is configured to be attached to a user; receiving, at the mobile device, user medical history data from a remote source; updating the baseline user profile based on the user glucose data and the user medical history data; generating, based on a user interface model, a personalized user interface element based on the updated baseline user profile; displaying a visualization comprising the personalized user interface element on a mobile application running on the mobile device; receiving, at the mobile device, user activity data from at least one of the mobile device or a wearable device associated with the user; generating a second personalized user interface element based on the user activity data, the user glucose data, and the user medical history data; and updating the visualization to display the second personalized user interface element.

2. The method of claim 1, wherein the user interface model generates a predicted condition of the user.

3. The method of claim 2, wherein the personalized user interface element comprises a personalized message that includes content for addressing the predicted condition.

4. The method of claim 2, wherein the personalized user interface element comprises a personalized avatar that represents the predicted condition of the user.

5. The method of claim 4, wherein the predicted condition comprises at least one of a user glucose level and a determined user mood.

6. The method of claim 1, wherein the user interface model is configured to receive, as input, the user glucose data and the user medical history data, and provide, as output, the personalized user interface element.

7. The method of claim 1, wherein the user interface model is stored at the mobile device.

8. The method of claim 1, wherein the user interface model is a machine learning model and / or a trained model which is optionally trained remotely, and / or is trained specific to a particular user or group of users based on one or more characteristics.

9. The method of claim 1, wherein the user glucose data comprises glucose data of the user over a predetermined period of time.

10. The method of claim 1, wherein the user segmentation input is determined based on at least one of user interaction with the mobile device or via an interactive query tool displayed by the mobile device.

11. A mobile device comprising: a memory; a processor coupled to the memory and configured to: receive user segmentation input; generate a baseline user profile based on the user segmentation input; receive user glucose data from an in vivo glucose sensor, wherein the in vivo glucose sensor is configured to be attached to a user; receive user medical history data from a remote source; update the baseline user profile based on the user glucose data and the user medical history data; generate, based on a user interface model, a personalized user interface element based on the updated baseline user profile; display a visualization comprising the personalized user interface element on a mobile application running on the mobile device;receive user activity data from at least one of the mobile device or a wearable device associated with the user; generate a second personalized user interface element based on the user activity data, the user glucose data, and the user medical history data; and update the visualization to display the second personalized user interface element.

12. The mobile device of claim 11, wherein the user interface model generates a predicted condition of the user.

13. The mobile device of claim 12, wherein the personalized user interface element comprises a personalized message that includes content for addressing the predicted condition.

14. The mobile device of claim 12, wherein the personalized user interface element comprises a personalized avatar that represents the predicted condition of the user.

15. The mobile device of claim 11, wherein the user interface model is configured to receive, as input, the user glucose data and the user medical history data, and provide, as output, the personalized user interface element.

16. The mobile device of claim 11, wherein the user interface model is stored at the mobile device.

17. The mobile device of claim 11, wherein the user interface model is a machine learning model and / or a trained model which is optionally trained remotely, and / or is trained specific to a particular user or group of users based on one or more characteristics.

18. The mobile device of claim 11, wherein the user glucose data comprises glucose data of the user over a predetermined period of time.

19. A non-transitory computer-readable device having instructions stored thereon that, when executed by a computing device, causes the computing device to perform operations comprising: receiving, at the computing device, user segmentation input; generating a baseline user profile based on the user segmentation input; receiving, at the computing device, user glucose data from an in vivo glucose sensor, wherein the in vivo glucose sensor is configured to be attached to a user; receiving, at the computing device, user medical history data from a remote source; updating the baseline user profile based on the user glucose data and the user medical history data; generating, based on a user interface model, a personalized user interface element based on the updated baseline user profile; displaying a visualization comprising the personalized user interface element on a mobile application running on the computing device; receiving, at the computing device, user activity data from at least one of the mobile device or a wearable device associated with the user; generating a second personalized user interface element based on the user activity data, the user glucose data, and the user medical history data; and updating the visualization to display the second personalized user interface element.

20. The non-transitory computer-readable device of claim 20, wherein the user interface model generates a predicted condition of the user.

Images