Location-based trusted user policy

Abstract

A system for authenticating a user comprises one or more memories comprising executable instructions and data and one or more processors configured to execute the executable instructions. The instructions, when executed, cause the one or more processors to send a login request for a user to a server over a network, the login request comprising a username and a password; in response to a successful login, send a request for location information associated with the user to the server over the network, the location information comprising a trusted user flag and a country of residence (COR); and in response to the trusted user flag indicating that the user is trusted, execute one or more features of an application.

Description

Dexcom Ref. No.: 0989-PCT01LOCATION-BASED TRUSTED USER POLICYCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application Serial No. 63 / 719,020 (filed on November 11, 2024) the content of which is incorporated by reference herein in its entirety.BACKGROUND

[0002] Diabetes is a metabolic condition relating to the production or use of insulin by the body. Insulin is a hormone that allows the body to use glucose for energy, or store glucose as fat.

[0003] Diabetes mellitus is a disorder in which the pancreas cannot create sufficient insulin (Type I or insulin dependent) and / or in which insulin is not effective (Type 2 or non-insulin dependent). In the diabetic state, the victim suffers from high blood sugar, which causes an array of physiological derangements (kidney failure, skin ulcers, or bleeding into the vitreous of the eye) associated with the deterioration of small blood vessels. A hypoglycemic reaction (low blood sugar) may be induced by an inadvertent overdose of insulin, or after a normal dose of insulin or glucose-lowering agent accompanied by extraordinary exercise or insufficient food intake.

[0004] Conventionally, a diabetic patient carries a self-monitoring blood glucose (SMBG) monitor, which may require uncomfortable finger pricking methods. Due to the lack of comfort and convenience, a diabetic will normally only measure his or her glucose level two to four times per day. Unfortunately, these time intervals are spread so far apart that the diabetic will likely be alerted to a hyperglycemic or hypoglycemic condition too late, sometimes incurring dangerous side effects as a result. In fact, it is unlikely that a diabetic will take a timely SMBG value, and further the diabetic will not know if his or her blood glucose value is going up (higher) or down (lower), due to limitations of conventional methods.

[0005] Consequently, a variety of non-invasive, transdermal (e.g., transcutaneous) and / or implantable sensors are being developed for continuously detecting and / or quantifying blood glucose values. Generally, in a diabetes management system, these sensors wirelessly transmit raw or minimally processed data for subsequent display and / or analysis at one or more remote devices, which can include a display device, a server, or any other types of communication devices. A remote device, such as a display device, may then utilize a trusted softwareDexcom Ref. No.: 0989-PCT01 application (e.g., approved and / or provided by the manufacturer of the sensor), which takes the raw or minimally processed data and provides the user with information about the user's blood glucose levels. Because diabetes management systems using such implantable sensors can provide more up-to-date information to users, they may reduce the risk of a user failing to regulate the user's blood glucose levels.

[0006] Software applications commonly provide different features to users in different geographical locations, for example, due to different regulations existing in the geographical locations. For example, regulations in Country A may permit one or more features that are not permitted by regulations in Country B. Accordingly, software providers commonly implement safeguards to ensure that users are able to access certain features only where permitted by local regulations.

[0007] One challenge with implementing such an approach is encountered when a user who has installed a software application in Country A - which permits a particular application feature - temporarily travels to Country B, which does not permit the application feature. If the user encounters technical issues with the application or loses their device and is required to reinstall the software application, the login process may detect that the user is currently located in Country B, preventing the user from accessing the application feature associated with Country A or even most of the application itself. In general, the user must wait until they return to Country A before the application can confirm that they are authorized to access the application feature.

[0008] Additionally, other issues may be encountered by a user when they are traveling outside of Country A, including the user needing to change a username and / or password, unauthorized access and / or corruption of the user’s account. Each of these issues may require the user to wait until they return to Country A before the application can confirm that they are authorized to access a particular application feature that is not available in their current geographical location.

[0009] This background is provided to introduce a brief context for the summary and detailed description that follow. This background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1A illustrates an example diabetes management system, according to some embodiments disclosed herein.Dexcom Ref. No.: 0989-PCT01

[0011] FIG. IB illustrates the example diabetes management system of FIG. 1A in more detail, according to some embodiments disclosed herein.

[0012] FIG. 2 is a sequence diagram illustrating execution of a communication procedure between an analyte sensor system and a display device, according to certain embodiments.

[0013] FIG. 3 is a sequence diagram illustrating methods by which the display device obtains authentication data from a server system during a set-up process of a sensor application of the display device.

[0014] FIG. 4A is a sequence diagram illustrating an example device-centric mutual authentication protocol, according to some embodiments disclosed herein.

[0015] FIG. 4B is an example chain of certificates associated with the analyte sensor system, according to some embodiments disclosed herein.

[0016] FIG. 4C is a sequence diagram illustrating an example device-centric mutual authentication protocol, according to some embodiments disclosed herein.

[0017] FIG. 4D is a sequence diagram illustrating an example device-centric mutual authentication protocol, according to some embodiments disclosed herein.

[0018] FIG. 5 depicts a sequence diagram including operations between entities in a health management system, according to some embodiments disclosed herein.

[0019] FIG. 6 depicts a method for obtaining an application certificate for a health monitoring application of a display device for wireless communication with an analyte sensor system, according to some embodiments disclosed herein.

[0020] FIG. 7 depicts a method for obtaining an application certificate for a health monitoring application of a display device for wireless communication with an analyte sensor system, according to some embodiments disclosed herein.

[0021] FIG. 8 depicts aspects of an example communications device, according to some embodiments disclosed herein.

[0022] FIG. 9 depicts a sequence diagram illustrating operations for authenticating a user of an analyte sensor application during an initial login process, in accordance with embodiments of the present disclosure.Dexcom Ref. No.: 0989-PCT01

[0023] FIG. 10 depicts a sequence diagram illustrating operations for authenticating a user of an analyte sensor application during a subsequent login process after a user account has been created, in accordance with embodiments of the present disclosure.

[0024] FIG. 11 depicts a sequence diagram illustrating operations for authenticating a user of an analyte sensor application after installation or re-installation on a display device, in accordance with embodiments of the present disclosure.

[0025] FIG. 12 depicts a flow diagram describing certain functionality related to authenticating a user of an analyte sensor application, in accordance with embodiments of the present disclosure.DETAILED DESCRIPTION

[0026] Aspects of the present disclosure provide techniques, including apparatuses, methods, processing systems, and computer-readable mediums, for providing access to one or more software application features to a trusted user of an analyte sensor system, for example, based on the geographical location of the user or other indicators of trust.

[0027] Generally, a user wears an analyte sensor system and uses an analyte monitoring application installed on a display device (e.g., a smartphone, mobile device, tablet, etc.) to connect to the analyte sensor system, receive measured analyte sensor data, and display the measured analyte sensor data.

[0028] To configure the analyte monitoring application for a particular country’s regulatory requirements, the user selects that particular country as their country of residence (COR) when the user’s account is created. The analyte monitoring application checks the location of the display device (e.g., by matching the COR to the country based on GPS or location information, for example, location information associated with one or more cellular towers that a mobile device is communicating with, location information associated with IP address of the mobile device, location information associated with a wireless network (e.g., Wi-Fi network) coupled to the mobile device, etc.) to ensure that the user’s display device is physically present in the COR when the user’s account is created. In some embodiments, the analyte monitoring application may also check the location of the display device to ensure that the user’s display device is physically present in the COR every time the user logs in (e.g., after a new installation or a re-installation of the analyte monitoring application on the user’s display device). This location check may be part of the login process for the analyte monitoring application. After the initial login to the analyte monitoring application, the user may remain logged in until theDexcom Ref. No.: 0989-PCT01 analyte monitoring application crashes, restarts, or is re-installed on the display device. In some embodiments, the user’s session may end (e.g., expire after a period of time), which requires the user to login to the analyte monitoring application again.

[0029] This approach may be referred to as Geo-Enhanced Feature Control (GFC). Generally, a configuration server may set the configuration of the analyte monitoring application based on the COR. In other words, different features of the analyte monitoring application may be authorized in different countries. For example, the following features may be controlled by the configuration of the analyte monitoring application based on the COR: units of measure, configuration for customer survey information, silence all (alarms / alerts), sensor profile for wear locations and sensor types, medication logging, activity, and so on.

[0030] Unfortunately, a location check during the login process prevents a user who is located (e.g., traveling) outside of their COR from logging in and accessing the features of the analyte monitoring application that are associated with their COR. For example, the user may be prevented from logging in after reinstalling the analyte monitoring application on their display device when traveling outside their COR because the current location of the user’s display device does not match the COR selected during the creation of the account. A similar situation occurs when the user installs the analyte monitoring application on a new display device when traveling outside their COR. As a result, the user may be prevented from accessing certain features associated with their COR or even the analyte monitoring application until they travel back to their COR.

[0031] Embodiments of the present disclosure advantageously provide a trusted user indicator that allows the user to login to the analyte monitoring application on the user’s display device when traveling outside their COR.

[0032] In certain embodiments, the user’s account includes a trusted user flag or indicator to track whether the user is a trusted user (e.g., “trusted”) or not a trusted user (e.g., “not trusted”). A trusted user is allowed to log in to the analyte monitoring application on their display device without a location check. In other words, the analyte monitoring application may bypass or skip the location check for a trusted user so the user’s display device does not need to be located in the COR when the user logs in. In certain embodiments, the analyte monitoring application checks the trusted user flag during a location verification process that is associated with the login process and does not perform the location check when the trusted user flag is set to “trusted” or “true.”Dexcom Ref. No.: 0989-PCT01

[0033] When the user’s account is created, the trusted user flag may be set to “trusted” or “not trusted.” When the trusted user flag is set to “trusted” at the creation of the user’s account, further location checks may not be performed. When the trusted user flag is set to “not trusted,” a successful location check or other indicator of trust may be used to establish trusted user status.

[0034] For example, the trusted user flag may be set to “trusted” based on a successful location check during any login (e.g., subsequent to account creation) when the user’s display device is located in the user’s COR. Additionally, the trusted user flag may be set to “trusted” based on the user’s display device having at least one measured analyte value (e.g., an estimated glucose value or EGV) stored in the display device’s memory (or a server’s memory), which indicates that the user has previously logged into the analyte monitoring application and stored at least one measured analyte data from the user’s analyte sensor system.

[0035] In related embodiments described herein, when a user requests one or more features associated with a particular geographic location (e.g., when logging into a software application, such as a continuous glucose monitor (CGM) application), a remote server (e.g., an account management system, for instance, a centralized account management system or CAMS) accesses a database entry for the user and determines whether the user previously accessed the feature(s) associated with the geographic location and is therefore a “trusted user” with respect to the geographic location. If the user is a trusted user for the geographic location, then a token including a trusted user flag indicating that the user is “trusted” is transmitted to the software application executing on the user’s device, enabling the device to access the feature(s) associated with the geographic location. In some embodiments, upon receiving the token including the trusted user flag, the software application executing on the user’s device may bypass or skip a location check (e.g., by bypassing a GFC check). Accordingly, if the user previously logged into the software application in Country A, but is currently temporarily traveling within Country B, the user is still able to access application feature(s) that are available in Country A.

[0036] If on the other hand, the user is determined to not be a trusted user for the geographic location, then the token transmitted to the software application executing on the user’s device (e.g., by CAMS) includes a trusted user flag that indicates that the user is “not trusted.” As a result, upon receiving the token, the software application executing on the user’s device may perform a location check (e.g., a GFC check). If the user is in Country A (and has a COR of country A associated with their account), then the user will be granted access to the featuresDexcom Ref. No.: 0989-PCT01 associated with Country A. If, on the other hand, the user is not in Country A, then the user will not have access to the features associated with Country A (e.g., features that are not available in the country where the user is located).

[0037] Various techniques may be implemented to update the database (e.g., a database managed by CAMS) which indicates whether one or more users are trusted users (e.g., with respect to a particular geographic location). In some embodiments, when a user installs a software application and confirms that they are located in a particular geographical location (e.g., via a GFC check of location and COR), that result may be transmitted to a remote server (e.g., CAMS), which updates a database entry associated with the user to indicate that the user is a trusted user.

[0038] In some embodiments, a database entry associated with the user may be updated to reflect that the user is a trusted user for a particular geographic location upon detecting that the user is performing a software update. For example, if a user performs an update of a software application that has previously been granted access to features within Country A (e.g., based on performing a GFC check while present in Country A), then, upon detecting that the user has updated the software application, the database entry associated with the user may be updated (e.g., by CAMS) to indicate that the user is a trusted user with respect to Country A. Updating database entries in this manner may reduce or prevent technical issues that would otherwise be encountered when attempting to update a large number of entries within a live database that is being accessed by users.

[0039] In some embodiments, in lieu or (or in addition to) confirming whether a user is a trusted user based on the trusted user flag included in the token received from a remote server (e.g., CAMS), the software application may determine and / or confirm whether the user is a trusted user by detecting whether one or more data values (e.g., analyte values) generated by the application were previously stored on the remote server and / or stored locally on the user’s device. For example, if the software application is a CGM application, then the application may determine whether one or more estimated analyte values (e.g., EGVs) are stored locally on the device (e.g., an EGV database stored locally on a smartphone or other mobile device), indicating that the user previously accessed the software application within a particular geographical location and is therefore a trusted user within the geographical location (e.g., country) or a trusted user associated with the geographical location (e.g., country). If the software application detects that one or more data values generated by the application were previously stored locally on the user’s device, then the application may bypass a location checkDexcom Ref. No.: 0989-PCT01(e.g., the GFC check), enabling the user to access features associated with the geographical location (e.g., even if the user is located outside of the geographic location, for example, a country).

[0040] In some embodiments, if a user has not authorized personal data to be shared with a remote server associated with the software application (e.g., the user has “opted out” of data sharing), then the remote server may be unable to store a database entry indicating whether the user is a trusted user with respect to a particular geographical location. In such embodiments, the software application may instead determine whether one or more data values generated by the application were previously stored locally on the user’s device (e.g., upon receiving a token that includes a trusted user flag that indicates that the user is “not trusted,” based on trusted user data not being tracked for the user). Accordingly, even though the user does not share personal data with the remote server, the user is still able to access application features associated with a particular geographical location, for example, while temporarily traveling outside of the geographical location. For example, the user may be treated as trusted based on the one or more data values previously stored locally on the user’s device.

[0041] Advantageously, the techniques described herein enable a user to access software features that the user was previously authorized to access, such as when the user is required to reinstall the software application while temporarily being outside of their home country (e.g., COR). Additionally, the techniques described herein enable a database (e.g., user database managed by CAMS) to be updated more reliably, for example, as users update a software application on their devices.

[0042] Introduction to Health Management Systems

[0043] FIG. 1A depicts a health management system 100, such as a diabetes management system, that may be used in connection with embodiments of the present disclosure that involve gathering, monitoring, and / or providing information regarding analyte values present in a user's body, including for example the user's blood glucose values. Health management system 100 depicts aspects of analyte sensor system 8 (“SS 8”) that may be communicatively coupled to display devices 110, 120, 130, and 140, and / or server system 134.

[0044] In some embodiments, SS 8 is provided for measurement of an analyte in a host or a user. By way of an overview and an example, SS 8 may be implemented as an encapsulated microcontroller that makes sensor measurements, generates analyte data (e.g., by calculating values for continuous glucose monitoring data), and engages in wireless communications (e.g.,Dexcom Ref. No.: 0989-PCT01 via Bluetooth and / or other wireless protocols) to send such data to remote devices, such as display devices 110, 120, 130, 140, and / or server system 134. Paragraphs

[0137] -

[0140] and FIGS. 3A, 3B, and 4 of U.S. App. No. 2019 / 0336053 further describe an on-skin sensor assembly that, in certain embodiments, may be used in connection with SS 8. Paragraphs

[0137] -

[0140] and FIGS. 3A, 3B, and 4 of U.S. App. No. 2019 / 0336053 are incorporated herein by reference.

[0045] In certain embodiments, SS 8 includes an analyte sensor electronics module 12 and an analyte sensor 10 associated with analyte sensor electronics module 12. In certain embodiments, analyte sensor electronics module 12 includes electronic circuitry associated with measuring and processing analyte sensor data or information, including algorithms associated with processing and / or calibration of the analyte sensor data / information. Analyte sensor electronics module 12 may be physically / mechanically connected to analyte sensor 10 and can be integral with (i.e., non-releasably attached to) or releasably attachable to analyte sensor 10.

[0046] Analyte sensor electronics module 12 may also be electrically coupled to analyte sensor 10, such that the components may be electromechanically coupled to one another (e.g., (a) prior to insertion into a patient’s body, or (b) during the insertion into the patient’s body). Analyte sensor electronics module 12 may include hardware, firmware, and / or software that enable measurement and / or estimation of levels of the analyte in a host / user via analyte sensor 10 (e.g., which may be / include a glucose sensor). For example, analyte sensor electronics module 12 can include one or more potentiostats, a power source for providing power to analyte sensor 10, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to one or more display devices. Electronics can be affixed to a printed circuit board (PCB) within SS 8, or platform or the like, and can take a variety of forms. For example, the electronics can take the form of an integrated circuit (IC), such as an Application-Specific Integrated Circuit (ASIC), a microcontroller, a processor, and / or a state machine.

[0047] Analyte sensor electronics module 12 may include sensor electronics that are configured to process sensor information, such as sensor data, and generate transformed sensor data and displayable sensor information. Examples of systems and methods for processing sensor analyte data are described in more detail herein and in U.S. Pat. Nos. 7,310,544 and 6,931,327 and U.S. Patent Publication Nos. 2005 / 0043598, 2007 / 0032706, 2007 / 0016381,Dexcom Ref. No.: 0989-PCT012008 / 0033254, 2005 / 0203360, 2005 / 0154271, 2005 / 0192557, 2006 / 0222566, 2007 / 0203966 and 2007 / 0208245, all of which are incorporated herein by reference in their entireties.

[0048] Analyte sensor 10 is configured to measure a concentration or level of the analyte in the host. The term analyte is further defined by paragraph

[0117] of U.S. App. No. 2019 / 0336053. Paragraph

[0117] of U.S. App. No. 2019 / 0336053 is incorporated herein by reference. In some embodiments, analyte sensor 10 comprises a continuous glucose sensor, such as a subcutaneous, transdermal (e.g., transcutaneous), or intravascular device. In some embodiments, analyte sensor 10 can analyze a plurality of intermittent blood samples. Analyte sensor 10 can use any method of glucose-measurement, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, and the like. Additional details relating to a continuous glucose sensor are provided in paragraphs

[0072] -

[0076] of U.S. App. No. 13 / 827,577. Paragraphs

[0072] -

[0076] of U.S. App. No. 13 / 827,577 are incorporated herein by reference.

[0049] With further reference to FIG. 1A, display devices 110, 120, 130, and / or 140 can be configured for displaying (and / or alarming) displayable sensor information that may be transmitted by sensor electronics module 12 (e.g., in a customized data package that is transmitted to the display devices based on their respective preferences). Each of display devices 110, 120, 130, or 140 may respectively include a display such as touchscreen display 112, 122, 132, and / or 142 for displaying sensor information and / or analyte data to a user and / or receiving inputs from the user. For example, a graphical user interface (GUI) may be presented to the user for such purposes. In certain embodiments, the display devices may include other types of user interfaces such as voice user interface instead of or in addition to a touchscreen display for communicating sensor information to the user of the display device and / or receiving user inputs. In certain embodiments, one, some, or all of display devices 110, 120, 130, 140 may be configured to display or otherwise communicate the sensor information as it is communicated from sensor electronics module 12 (e.g., in a data package that is transmitted to respective display devices), without any additional prospective processing required for calibration and / or real-time display of the sensor data.

[0050] The plurality of display devices 110, 120, 130, 140 depicted in FIG. 1A may include a custom or proprietary display device, for example, analyte display device 110, especially designed for displaying certain types of displayable sensor information associated with analyte data received from sensor electronics module 12 (e.g., a numerical value and / or an arrow, in certain embodiments). In certain embodiments, one of the plurality of display devices 110, 120,Dexcom Ref. No.: 0989-PCT01130, 140 includes a smartphone, such as a mobile phone, based on an Android, iOS, or another operating system configured to display a graphical representation of the continuous sensor data (e.g., including current and / or historic data). In certain embodiments, health management system 100 further includes a medical delivery device (e.g., an insulin pump or pen). Sensor electronics module 12 may be configured to transmit sensor information and / or analyte data to medical delivery device. The medical delivery device (not shown) may be configured to administer a certain dosage of insulin or another medicament to the user based on the sensor information and / or analyte data (e.g., which may include a recommended insulin dosage) received from the sensor electronics module 12.

[0051] Server system 134 may be used to directly or indirectly collect analyte data from SS 8 and / or the plurality of display devices, for example, to perform analytics thereon, generate universal or individualized models for glucose levels and profiles, provide services or feedback, including from individuals or systems remotely monitoring the analyte data, perform or assist SS 8 and the plurality of display devices with identification, authentication, etc., according to the embodiments described herein, so on. Note that, in certain embodiments, server system 134 may be representative of multiple systems or computing devices that perform the functions of server system 134 (e.g., in a distributed manner).

[0052] FIG. IB illustrates a more detailed view of health management system 100 including a display device 150 that is communicatively coupled to SS 8. In certain embodiments, display device 150 may be any one of display devices 110, 120, 130, and 140 of FIG. 1A. In some embodiments, the display device 150 includes smartphone, such as a mobile phone, based on an Android, iOS, or another operating system configured to display a graphical representation of the continuous sensor data (e.g., including current and / or historic data). In some embodiments, the display device 150 may be a smartwatch or another type of device, such as an insulin pump or other type of pump.

[0053] The communication path between SS 8 and display device 150 is shown as communication path 180. In certain embodiments, SS 8 and display device 150 are configured to wirelessly communicate over communication path 180 using low range and / or distance wireless communication protocols. Examples of low range and / or distance wireless communication protocols include Bluetooth and Bluetooth Low Energy (BLE) protocols. In certain embodiments, other short range wireless communications may include Near Field Communications (NFC), radio frequency identification (RFID) communications, IR (infra-red) communications, optical communications. In certain embodiments, wireless communicationDexcom Ref. No.: 0989-PCT01 protocols other than low range and / or distance wireless communication protocols may be used for communication path 180, such as WiFi Direct. Display device 150 is also configured to connect to network 190 (e.g., local area network (LAN), wide area network (WAN), the Internet, etc.). For example, display device 150 may connect to network 190 via a wired (e.g., Ethernet) or wireless (e.g., WLAN, wireless WAN, cellular, Mesh network, personal area network (PAN) etc.) interface. Display device 150 is able to communicate with server system 134 through network 190. The communication path between display device 150 and server system 134 is shown as communication path 181 via network 190.

[0054] Note that, in certain embodiments, SS 8 may be able to independently (e.g., wirelessly) communicate with server system 134 through network 190. An independent communication path between SS 8 and server system 134 is shown as communication path 182. However, in certain other embodiments, SS 8 may not be configured with the necessary hardware / software to establish, for example, an independent wireless communication path with server system 134 through network 190. In such embodiments, SS 8 may communicate with server system 134 through display device 150. An indirect or pass-through communication path between SS 8 and server system 134 is shown as communication path 183.

[0055] In embodiments where display device 150 is a proprietary display device, such as display device 110 designed specifically for the communication of analyte data, display device 150 may not be configured with the necessary hardware / software for independently connecting to network 190. Instead, in certain such embodiments, display device 150 is configured to establish a wired or wireless communication path 184 (e.g., through a Universal System Bus (USB) connection) with computer device 103, which is configured to communicate with server system 134 through network 190. For example, computer device 103 may connect to network 190 via a wired (e.g., Ethernet) or wireless (e.g., WLAN, wireless WAN, cellular, etc.) interface. Note that in the embodiments described in relation to FIGS. 2A-8, unless otherwise noted, display device 150 is assumed to be capable of independently communicating with server system 134 through network 190, independent of computer device 103.

[0056] Health management system 100 additionally includes server system 134, which in turn includes server 135 that is coupled to memory / storage 136 which is non-volatile memory or storage for storing software programs, data, etc. (e.g., one or more computer storage systems, cloud-based storage systems and / or services, etc.). The server 134 includes at least one processor 137 coupled to a memory 138 and a network interface 139.Dexcom Ref. No.: 0989-PCT01

[0057] In certain embodiments, server system 134 may be located or execute in a public or private cloud. In certain embodiments, server system 134 is located or executes on-premises (“on-prem”). As discussed, server system 134 is configured to receive, collect, and / or monitor information, including analyte data and related information, as well as encryption / authentication information from SS 8 and / or display device 150. Such information may include input responsive to the analyte data or input (e.g., the user’s glucose measurements and other physiological / behavioral information) received in connection with an analyte monitoring or sensor application running on SS 8 or display device 150. This information may be stored in memory / storage 136 and may be processed, such as by an analytics engine capable of performing analytics on the information. An example of an analyte sensor application that may be executable on display device 150 is analyte sensor application 121, as further described below.

[0058] In certain embodiments, server system 134 at least partially directs communications between SS 8 and display device 150, for example, for facilitating authentication therebetween. Such communications include messaging (e.g., advertisement, command, or other messaging), message delivery, and analyte data. For example, in certain embodiments, server system 134 may process and exchange messages between SS 8 and display device 150 related to frequency bands, timing of transmissions, security, alarms, and so on. In certain embodiments, server system 134 may also update information stored on SS 8 and / or display device 150. In certain embodiments, server system 134 may send / receive information to / from SS 8 and or display device 150 in real-time or sporadically. Further, in certain embodiments, server system 134 may implement cloud computing capabilities for SS 8 and / or display device 150.

[0059] FIG. IB also illustrates the components of SS 8 in further detail. As shown, in certain embodiments, SS 8 includes analyte sensor 10 coupled to sensor electronics module 12. Sensor electronics module 12 includes sensor measurement circuitry 13 that is coupled to analyte sensor 10 for processing and managing sensor data. Sensor measurement circuitry 13 may also be coupled to one or more processors 11. In some embodiments, the one or more processors 11 may perform part or all of the functions of the sensor measurement circuitry 13 for obtaining and processing sensor measurement values from analyte sensor 10. The one or more processors 11 may also be coupled to storage 14 and real time clock (RTC) 17 for storing and tracking sensor data. In addition, the one or more processors 11 may be further coupled to a connectivity interface 15, which includes a radio unit or transceiver (TRX) 16 for sending sensor data and receiving requests and commands from an external device, such as display device 150. As usedDexcom Ref. No.: 0989-PCT01 herein, the term transceiver generally refers to a device or a collection of devices that enable SS 8 to (e.g., wirelessly) transmit and receive data. SS 8 may further include storage 14 and real time clock (RTC) 17 for storing and tracking sensor data. It is contemplated that, in some embodiments, the SMC 13 may carry out all the functions of the one or more processors 11 and vice versa.

[0060] Transceiver 16 may be configured with the necessary hardware and wireless communications protocols for enabling wireless communications between SS 8 and other devices, such as display device 150 and / or server system 134. For example, as described above, transceiver 16 may be configured with the necessary hardware and communication protocols to establish a Bluetooth or BLE connection with display device 150. As one of ordinary skill in the art appreciates, in such an example, the necessary hardware may include a Bluetooth or BLE security manager and / or other Bluetooth or BLE related hardware / software modules configured for Bluetooth or BLE communications standards. In some embodiments where SS 8 is configured to establish an independent communication path with server system 134, transceiver 16 may be configured with the necessary hardware and communication protocols (e.g., long range wireless cellular communication protocol, such as, GSM, CDMA, LTE, VoLTE, 3G, 4G, 5G communication protocols) for establishing a wireless connection to network 190 to connect with server system 134. As discussed elsewhere, other short range protocols, may also be used for communication between display device 150 and a SS 8 such as NFC, RFID, etc.

[0061] FIG. IB similarly illustrates the components of display device 150 in further detail. As shown, display device 150 includes connectivity interface 128, one or more processors 126, one or more memories 127, a real time clock (RTC) 163, a display 125 for presenting a graphical user interface (GUI), and a memory / storage 123. A bus (not shown here) may be used to interconnect the various elements of display device 150 and transfer data between these elements. Connectivity interface 128 includes a transceiver (TRX) 129 used for receiving sensor data from SS 8 and for sending requests, instructions, and / or data to SS 8 as well as server system 134. Transceiver 129 is coupled to other elements of display device 150 via connectivity interface 128 and / or the bus. Transceiver 129 may include multiple transceiver modules operable on different wireless standards. For example, transceiver 129 may be configured with one or more communication protocols, such as wireless communication protocol(s) for establishing a wireless communication path with network 190 and / or low range wireless communication protocol(s) (e.g., Bluetooth or BLE) for establishing a wirelessDexcom Ref. No.: 0989-PCT01 communication path 180 with SS 8. Additionally, connectivity interface 128 may in some cases include additional components for controlling radio and / or wired connections, such as baseband and / or Ethernet modems, audio / video codecs, and so on.

[0062] In some embodiments, when a standardized communication protocol is used between display device 150 and SS 8, commercially available transceiver circuits may be utilized that incorporate processing circuitry to handle low level data communication functions such as the management of data encoding, transmission frequencies, handshake protocols, security, and the like. In such embodiments, the one or more processors 126 of display device 150 and / or the one or more processors 11 of SS 8 may not need to manage these activities, but instead provide desired data values for transmission, and manage high level functions such as power up or down, set a rate at which messages are transmitted, and the like. Instructions and data values for performing these high level functions can be provided to the transceiver circuits via a data bus and transfer protocol established by the manufacturer of transceivers 129 and 16. However, in embodiments where a standardized communication protocol is not used between transceivers 129 and 16 (e.g., when non-standardized or modified protocols are used), the one or more processors 126 and 11 may be configured to execute instructions associated with proprietary communications protocols (e.g., one or more of the communications protocols described herein) to control and manage their respective transceivers. In addition, when nonstandardized or modified protocols are used, customized circuitries may be used to service such protocols.

[0063] The one or more processors 126 may include processor sub-modules, including, by way of example, an applications processor that interfaces with and / or controls other elements of display device 150 (e.g., connectivity interface 128, analyte sensor application 121 (hereinafter “sensor application 121”), display 125, RTC 163, one or more memories 127, memory / storage 123, etc.). In certain embodiments, the one or more processors 126 is configured to perform functions related to device management, such as, for example, managing lists of available or previously paired devices, information related to network conditions (e.g., link quality and the like), information related to the timing, type, and / or structure of messaging exchanged between SS 8 and display device 150, and so on. The one or more processors 126 may further be configured to receive and process user input, such as, for example, a user's biometric information, such as the user’s finger print (e.g., to authorize the user's access to data or to be used for authorization / encryption of data, including analyte data), as well as analyte data.Dexcom Ref. No.: 0989-PCT01

[0064] The one or more processors 126 may include and / or be coupled to circuitry such as logic circuits, memory, a battery and power circuitry, and other circuitry drivers for periphery components and audio components. The one or more processors 126 and any sub-processors thereof may include logic circuits for receiving, processing, and / or storing data received and / or input to display device 150, and data to be transmitted or delivered by display device 150. As described above, the one or more processors 126 may be coupled by a bus to display 125, connectivity interface 128, memory / storage 123, etc. Hence, the one or more processors 126 may receive and process electrical signals generated by these respective elements and thus perform various functions. By way of example, the one or more processors 126 may access stored content from memory / storage 123 and one or more memories 127 at the direction of analyte sensor application 121, and process the stored content to be displayed by display 125. Additionally, the one or more processors 126 may process the stored content for transmission via connectivity interface 128 to SS 8 and / or server system 134. Display device 150 may include other peripheral components not shown in detail in FIG. IB.

[0065] In certain embodiments, the one or more memories 127 may include volatile memory, such as random access memory (RAM) for storing data and / or instructions for software programs and applications, such as analyte sensor application 121, support modules 161, and so on. Display 125 presents a GUI associated with operating system (OS) 162 and / or analyte sensor application 121. In various embodiments, a user may interact with analyte sensor application 121 via a corresponding GUI 124 (see FIGS. 9 and 11) presented on display 125. By way of example, display 125 may be a touchscreen display that accepts touch input. Analyte sensor application 121 may process and / or present analyte-related data received by display device 150 and present such data via display 125. Additionally, analyte sensor application 121 may be used to obtain, access, display, control, and / or interface with analyte data and related messaging and processes associated with SS 8 (e.g., and / or any other medical device (e.g., insulin pump or pen) that are communicatively coupled with display device 150), as is described in further detail herein.

[0066] Memory / storage 123 may be a non-volatile memory or storage for storing software programs, instructions, data, etc. For example, memory / storage 123 may store analyte sensor application 121 that, when executed using the one or more processors 126, for example, receives input (e.g., by a conventional hard / soft key or a touch screen, voice detection, or other input mechanism), and allows a user to interact with the analyte data and related content via display 125. In various embodiments, memory / storage 123 may also store user input dataDexcom Ref. No.: 0989-PCT01 and / or other data collected by display device 150 (e.g., input from other users gathered via analyte sensor application 121). Memory / storage 123 may further be used to store volumes of analyte data received from SS 8 (or any other medical data received from other medical devices (e.g., insulin pump, pen, etc.) for later retrieval and use, e.g., for determining trends and triggering alerts.

[0067] As described above, SS 8, in certain embodiments, gathers analyte data from analyte sensor 10 and transmits the same or a modified version of the collected data to display device 150. Data points regarding analyte values may be gathered and transmitted over the life of analyte sensor 10 (e.g., in the range of 1 to 30 days or more). New measurements may be transmitted often enough to adequately monitor glucose levels. In certain embodiments, rather than having the transmission and receiving circuitry of each of SS 8 and display device 150 continuously communicate, SS 8 and display device 150 may regularly and / or periodically establish a communication channel among each other. Thus, in such embodiments, SS 8 may, for example, communicate with display device 150 at predetermined time intervals. The duration of the predetermined time interval can be selected to be long enough so that SS 8 does not consume too much power by transmitting data more frequently than needed, yet frequent enough to provide substantially real-time sensor information (e.g., measured glucose values or analyte data) to display device 150 for output (e.g., via display 125) to the user. While the predetermined time interval is every five minutes in some embodiments, it is appreciated that this time interval can be varied to be any desired length of time. In other embodiments, transceivers 129 and 16 may be continuously communicating. For example, in certain embodiments, transceivers 129 and 16 may establish a session or connection there between and continue to communicate together until the connection is lost.

[0068] Analyte sensor application 121 may be downloaded, installed, and initially configured / setup on display device 150. For example, display device 150 may obtain analyte sensor application 121 from server system 134, or from another source, such as an application store or the like, via a network, e.g., network 190. Following installation and setup, analyte sensor application 121 may be configured to access, process, and / or interface with analyte data (e.g., whether stored on server system 134, locally from memory / storage 123, from SS 8, or any other medical device). By way of example, analyte sensor application 121 may present a menu that includes various controls or commands that may be executed in connection with the operation of SS 8, display device 150, one or more other display devices (e.g., display device 110, 130, 140, etc.), and / or one or more other partner devices, such as an insulin pump. ForDexcom Ref. No.: 0989-PCT01 example, analyte sensor application 121 may be used to interface with or control other display and / or partner devices, for example, to deliver or make available thereto analyte data, including for example by receiving / sending analyte data directly to the other display and / or partner device and / or by sending an instruction for SS 8 and the other display and / or partner device to be connected.

[0069] In certain embodiments, after downloading sensor application 121, as one of the initial steps, the user may be directed by sensor application 121 to establish a secure wireless connection between the display device 150 to the SS 8 of the user, which the user may have already placed on their body. A wireless communication path 180 between display device 150 and SS 8 allows SS 8 to transmit analyte measurements to display device 150 and for the two devices to engage in any of the other interactions described above.

[0070] Example Authentication and Pairing Procedure

[0071] Establishing a secure wireless connection between SS 8 and display device 150 may involve engaging in identification, authentication, pairing, and / or bonding protocols or methods. Identification protocols may be designed, for example, to allow display device 150 to effectively identify the SS 8. Authentication protocols may be designed to allow the SS 8 and display device 150 to verify whether the other peer device is a trusted device. Pairing and bonding protocols may be designed to allow for the exchange of information between the SS 8 and display device 150 to establish an encrypted connection for communication.

[0072] FIG. 2 is a network sequence diagram 200 illustrating execution of a communication procedure between an SS 8 and a display device 150, according to certain embodiments. In certain embodiments, the communication procedure may include invitation, authentication, pairing, and / or bonding between the SS 8 and the display device 150.

[0073] The various tasks performed in connection with the procedures illustrated in FIG. 2 may be performed, for example, by respective processors executing instructions embodied in respective non-transitory computer-readable media. The tasks or operations performed in connection with the procedures may be performed by hardware, software, firmware, or any combination thereof incorporated into one or more of computing devices. It will be appreciated upon studying the present disclosure that such procedures may include any number of additional or alternative tasks or operations. Note that some of the steps illustrated in FIG. 2 may be performed in a different order than illustrated in FIG. 2 or may be performed in parallel or overlap in time. Accordingly, the reference numbers assigned to the different steps illustratedDexcom Ref. No.: 0989-PCT01 in FIG. 2 may not be indicative of the order in which they are performed, in certain embodiments. Additionally, the procedures may be incorporated into more comprehensive procedures or processes having additional functionality not described in detail herein with specific reference to FIG. 2.

[0074] Also, while network sequence diagram 200 illustrates the execution of communication procedures for wireless communications between SS 8 and display device 150, steps illustrated in network sequence diagram 200 may be similarly followed when establishing wireless communication between SS 8 and one of a variety of other devices (e.g., a router, a hub, or any other computing device). In certain embodiments, network sequence diagram 200 illustrates communication procedures for an initial connection between SS 8 and a first display device 150. That is, in certain embodiments, the steps of network sequence diagram 200 may be performed when SS 8 has not yet paired with any display devices.

[0075] In FIG. 2, prior to performing authentication, pairing, and bonding, SS 8 may be configured to send invitations to display devices, such as display device 150 depicted in FIG.2, that are available for connection. This may be performed, for example, by transmitting generic invitations, as shown in step(s) 202 1-N of FIG. 2. Step(s) 202 1-N may be performed as part of an “invitation phase.” In certain embodiments, the display device 150 may scan for SS 8 or another like sensor system to connect to. Scanning for SS 8 generally entails receiving and processing invitation messages that are being broadcast by SS 8.

[0076] Generally, when SS 8 (or its sensor electronics module 106) is first activated, in order to be identified by and pair with one or more display devices, SS 8 is configured to broadcast generic invitations. In the embodiments of FIG. 2, at step(s) 202 1-N, SS 8 broadcasts generic invitation(s). A generic invitation may be broadcast over multiple frequency channels. SS 8 may broadcast the generic invitation periodically at defined intervals. In certain embodiments, SS 8 broadcasts the generic invitation as soon as SS 8 is powered on.

[0077] The generic invitation packet may include a header (e.g., a 2-byte header) and a variable size payload (e.g., 6-37 bytes). The header may include one or more fields, including, for example, a PDU Type field, one or more reserved fields, etc. The payload may include an invitation address (e.g., a 48-bit BLE MAC address or a Generic Address Profile (GAP) address of SS 8) and one or more invitation data structures, described in more detail below.

[0078] After detecting the generic invitation, display device 150, at step 204, may respond to the generic invitation by sending a connection request to SS 8. Upon receiving the connectionDexcom Ref. No.: 0989-PCT01 request, SS 8 may accept, deny, or simply ignore the request. If there are no grounds for denying or ignoring a connection request, SS 8 may accept the request and connect to the display device that sent the request. As shown at step 206, for example, SS 8 sends a connection response message to display device 150 indicating the request is granted. Then, a data connection between SS 8 and display device 150 may be established.

[0079] In certain embodiments, after a data connection is established between SS 8 and display device 150, an authentication procedure may be employed before data (e.g., analyte data) is actually exchanged (e.g., at step 216). For example, at step 208, SS 8 and display device 150 perform authentication during an authentication phase. The authentication may be performed according to an authentication protocol, examples of which may include, a challenge-response protocol, a certificate-based protocol, token authentication, public key infrastructure (PKI) protocols, password authenticated key exchange (PAKE) protocols, and the like.

[0080] After the authentication phase, SS 8 and display device 150 may perform pairing and bonding. Steps 210, 212, and / or 214 may be performed as part of the “pairing and bonding phase”. At step 210, display device 150 may send a pairing request to SS 8 and, at step 212, SS 8 may respond with a pairing response. In some examples, the pairing process involves the exchange of information, such as information relating to Input / Output (IO) capabilities, Man- In-The-Middle (MITM) protection, etc. During the pairing between SS 8 and display device 150, the two devices may agree on a temporary key (TK), whose value may depend on the pairing method that is used.

[0081] At step 214, SS 8 and display device 150 engage in bonding. During bonding, the devices may store additional information about each other. For example, after the exchange of security features and the encryption of the connection during pairing, the devices bond by generating and exchanging a long term key (LTK) and storing the LTK for later use.

[0082] After bonding with display device 150, SS 8 may add display device 150 to a targeted device list. A targeted device list may be a data array or some other data structure maintained in memory by SS 8 and may include devices with which SS 8 has previously paired and bonded. By adding display device 150 to a targeted device list, SS 8 and display device 150 may more quickly reconnect for subsequent connections.

[0083] After pairing and bonding, SS 8 and display device 150 are ready to exchange data over a secure connection. For example, SS 8 may encrypt data (e.g., at the BLE layer), including analyte measurements associated with the user, for transmission to display device 150 at stepDexcom Ref. No.: 0989-PCT01224 using the LTK. Display device 150 may similarly encrypt data for transmission to SS 8 using the LTK.

[0084] As mentioned previously, SS 8 gathers analyte data and transmits the same or a modified version of the collected data to display device 150. Data points regarding analyte values may be gathered and transmitted over the life of SS 8 (e.g., in the range of 1 to 30 days or more). New measurements may be transmitted often enough to adequately monitor analyte levels of a user of SS 8. In certain embodiments, for power savings, rather than having the transmission and receiving circuitry of each of SS 8 and display device 150 continuously communicate, SS 8 and display device 150 may regularly and / or periodically establish a communication channel among each other.

[0085] Thus, in such embodiments, SS 8 may, for example, communicate with display device 150 at predetermined time intervals (e.g., by switching between a sleep mode and an operational mode periodically). The duration of the predetermined time interval may be selected to be long enough so that SS 8 does not consume too much power by transmitting data more frequently than needed, yet frequent enough to provide substantially real-time sensor information (e.g., measured glucose values or analyte data) to the display device for output to the user. This time interval may be varied to be any desired length of time. For example, in certain embodiments, SS 8 may “wake up” every few minutes (e.g., five minutes) to exchange data with display device 150 but go into a sleep mode in-between the intervals. Each time SS 8 “wakes up”, SS 8 and display device 150 may perform connection procedures for reestablishing a secure wireless connection between the two devices. In other embodiments, SS 8 and display device 150 may be continuously communicating. For example, in certain embodiments, SS 8 and display device 150 may establish a session or connection there between and continue to communicate together until the connection is lost.

[0086] In the embodiments of FIG. 2, SS 8 is configured to go into sleep mode subsequent to pairing, bonding, and exchanging data with display device 150. Accordingly, at step 218, SS 8 and display device 150 disconnect.

[0087] Example Secure Data Exchange between the Display Device and Server System

[0088] FIG. 3 is a process flow diagram illustrating methods by which display device 150 obtains authentication data from server system 134 during the set-up process of sensor application 121, which executes on display device 150. The secure exchange of data between display device 150 and server system 134, based on any embodiments of any of the methodsDexcom Ref. No.: 0989-PCT01 described with respect to FIG. 3, configures sensor application 121 with authentication data that allows display device 150 to subsequently authenticate and establish a secure connection with SS 8, as described in relation to FIGS. 4A-4D. In certain embodiments, the authentication data that sensor application 121 obtains from server system 134 includes a number of digital authentication certificates, also referred to as public key certificates, (herein after “certificates”) for use by display device 150 to authenticate SS 8 using what are referred to herein as devicecentric mutual authentication protocols (described in relation to FIGS. 4A-4D). As further described below, SS 8 may similarly be configured with a set of certificates, thereby, allowing SS 8 to authenticate display device 150 using the same device-centric mutual authentication protocols. In certain embodiments, SS 8 is configured with these certificates during the manufacturing process. It is contemplated that in some examples, certificates, tokens, and / or encryption keys may be used for authenticating partner devices (e.g., medical delivery devices, such as insulin pumps and / or pens). It is further contemplated that the certificates, tokens, and / or encryption keys may also be obtained from the partner devices to authenticate SS8 and / or the display device or other partner devices as well.

[0089] In certain embodiments, a certificate is an electronic document generated for authentication of a device that conforms to a public key infrastructure (PKI) scheme. A certificate may be referred to as a credential token herein. PKI refers to a set of roles, policies, hardware, software, and procedures for creating managing, distributing, using, storing, and revoking certificates as well as managing public-key encryption. In a typical PKI scheme, each device may generate or be configured with a key-pair, including a public key and a private key. When information is encrypted using the private key, only the corresponding public key can be used to decrypt that information and vice versa. A public key of the device may be disseminated widely while the device’s private key is typically known only to the device and not shared with any other devices. For example, in certain embodiments, each of display device 150, SS 8, and server system 134 may generate or be configured with a distinct key-pair.

[0090] As one of its roles, PKI binds public keys with respective identities of devices. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). The primary role of the CA is to digitally sign and publish the public key bound to a given device. This is done using the CA's own private key, so that trust in the user key relies on one's trust in the validity of the CA's key. In certain embodiments, server system 134 performs the functions of a root CA (RCA) by issuing and, directly or indirectly, signing certificates of display device 150 and SS 8. An RCA is an entity that verifies all otherDexcom Ref. No.: 0989-PCT01 entities in a system. As such, server system 134 may be referred to as a diabetes trust management system, which issues and signs certificates of display device 150 and SS 8 or any other partner devices, thereby allowing them to authenticate each other by engaging in the device-centric trust management protocols.

[0091] In certain embodiments, server system 134, as the RCA, directly signs a device’s certificate (e.g., certificate of display device 150 and / or SS 8) using its private key. Alternatively, in some embodiments, indirect certificate signing may be used, whereby server system 134 signs a subordinate certificate authority’s (“SCA’s”) intermediary certificate and the SCA then uses its own private key to sign the device’s certificate. The involvement of SCAs in certificate signings creates a chain of trust, as shown and described further in relation to FIG. 4B. In certain embodiments, one SCA may be involved while, in certain other embodiments, multiple SCAs may be involved.

[0092] The sequence diagram shown in FIG. 3 illustrates communications between display device 150 and server system 134, which result in display device 150 securely obtaining one or more signed certificates from server system 134. Communications between display device 150 and server system 134 may be triggered by the user downloading sensor application 121 or any other application (not shown) associated with the sensor application. As part of the setup process, sensor application 121 then connects with server system 134 to obtain any necessary information that may be later used for interactions between display device 150 and SS 8.

[0093] At step 302, the user downloads sensor application 121. For example, the user downloads sensor application 121 from an application store (e.g., App Store) and initiates the set-up process.

[0094] At step 304, display device 150 and server system 134 engage in a cryptographic key exchange. In certain embodiments, during the set-up process, based on instructions provided by analyte sensor application 121, display device 150 engages in or initiates a cryptographic key exchange (e.g., key-agreement protocol such as the Diffie-Hellman (DH) key exchange algorithm) with server system 134 in order to generate an encryption key for use in encrypting any further communications between display device 150 and server system 134. In certain embodiments, engaging in the cryptographic key exchange may involve proving to server system 134 that display device 150 is in possession of a shared secret (e.g., cryptographic key exchange algorithm, key, etc.) and vice versa. Being in possession of the shared secret is proofDexcom Ref. No.: 0989-PCT01 that display device 150 can be trusted by server system 134 and vice versa. After display device 150 and server system 134 complete the execution of the cryptographic key exchange algorithm, each of display device 150 and server system 134 is in possession of the encryption key that is used to encrypt any subsequent data transmitted there between (e.g., in steps 306- 312).

[0095] In certain embodiments, the cryptographic key exchange algorithm includes a keyagreement protocol. A key agreement protocol is a protocol whereby two or more parties can agree on a key in such a way that both influence the outcome. One example of a key agreement protocol may be an exponential key exchange algorithm, such as the Diffie-Hellman (DH) key exchange algorithm. DH key exchange is a method of securely exchanging cryptographic keys over an insecure channel. Different versions of the DH key exchange are also within the scope of the disclosure. For example, in certain embodiments, the cryptographic key exchange algorithm may include an elliptic-curve DH (ECDH), which is a key agreement protocol that allows two parties, each having an elliptic-curve public-private key pair, to establish an encryption key over an insecure channel.

[0096] In certain embodiments, during the set-up process, based on instructions provided by sensor application 121, display device 150 engages in or initiates a cryptographic key exchange to prove to server system 134 that display device 150 is in possession of a shared secret (e.g., cryptographic key exchange algorithm, etc.). In other words, in certain other embodiments, server system 134 and display device 150 engage in a cryptographic key exchange that does not result in generating an encryption key but merely works to allow server system 134 and display device 150 to authenticate each other. In such embodiments, sensor application 121 is already configured with the shared secret, which may be cryptographic key exchange algorithm. In other words, because display device 150 is able to engage in the cryptographic key exchange algorithm, server system 134 can conclude that display device 150 is trustworthy, otherwise display device 150 would not have been configured with such a cryptographic key exchange algorithm and would not have been able to engage in the cryptographic key exchange using that algorithm.

[0097] Once server system 134 is able to determine that display device 150 knows the shared secret, server system 134 determines that it can trust display device 150 and vice versa. In other words, display device 150 is authenticated by server system 134 and vice versa. In certain embodiments, the shared secret is an encryption key that may also be used for encryption ofDexcom Ref. No.: 0989-PCT01 any subsequent data transmitted between server system 134 and display device 150 (e.g., in steps 306-312).

[0098] At step 306, display device 150 transmits an encrypted certificate signing request to server system 134. In certain embodiments, display device 150 encrypts the certificate signing request using the encryption key that display device 150 obtained at step 304 or was already configured with. In certain embodiments, display device 150 is configured with a first certificate for use in authentication between display device 150 and SS 8 and a second certificate for use in authentication between display device 150 and server system 134. In certain embodiments, display device 150 is similarly configured with a first key-pair (i.e., a first public key and a first private key) for use in authentication between display device 150 and SS 8 and a second key pair (i.e., a second public key and a second private key) for use in authentication between display device 150 and server system 134.

[0099] In certain embodiments, the certificate signing request includes the first certificate and the second certificate. In certain embodiments, the first certificate includes the first public key and the second certificate includes the second public key. The certificate signing request indicates a request to server system 134, which performs the functions of a RCA, for signing the first and the second certificates.

[0100] Note that, in certain embodiments, by engaging in the cryptographic key exchange of step 304, display device 150 and server system 134 have already authenticated each other prior to step 306. More specifically, when each device determines that the other is similarly configured with the same cryptographic key exchange algorithm, which may be a custom cryptographic key exchange algorithm, the device may conclude that the other can be trusted. That is because, if the other device was malicious, it would most likely not be configured with the same exact cryptographic key exchange algorithm, or at least a custom cryptographic key exchange algorithm.

[0101] However, in certain other embodiments, the second key-pair and the second certificate may additionally or instead be used for authentication in subsequent connections between server system 134 and display device 150. In certain other embodiments, however, additional authentication may not be performed between display device 150 and server system 134 (e.g., to increase resource efficiency, such as compute and storage efficiency). Therefore, display device 150 may not be configured with the second key-pair and a second certificate. In such embodiments, the certificate signing request does not include the second certificate.Dexcom Ref. No.: 0989-PCT01

[0102] At step 308, server system 134 transmits signed certificate(s) to display device 150. As described above, in certain embodiments, server system 134 directly signs certificates and, in certain other embodiments, server system 134 indirectly signs certificates. In certain embodiments, signing a certificate includes encrypting information (or encrypting a hash thereof) included in the certificate, resulting in a digital signature that is then included in the certificate. Examples of signed certificates are shown in FIG. 4B, which is further described below.

[0103] In certain embodiments, where the certificate signing request includes the first and the second certificates, server system 134 may sign the certificates using server system 134’ s private key. In such embodiments, server system 134 may send server system 134’s own signed certificate (i.e., signed with server system 134’ s private key) as well as the first and the second certificates of display device 150, which are signed by server system 134, to display device 150. In certain other embodiments, server system 134 may send server system 134’ s own signed certificate and display device 150’ s first and second certificates, which are signed by a SCA, to display device 150. In other words, in such embodiments, the first and the second certificates are not directly signed by server system 134 (e.g., to add an extra layer of security and reduce the risk of any information about the server system 134 or its keys / certificate being exposed). In certain embodiments, the transmission of the one or more signed certificates from server system 134 to display device 150 is encrypted using an encryption key that server system 134 may obtain, generate, or be configured with at step 304.

[0104] At optional step 310, display device 150 sends server system 134 a request for intermediary certificates and / or black-listed certificates. For example, if at step 308, server system 134 sends display device 150’ s certificates that are not directly signed by server system 134, display device 150 may at step 310 then request any intermediary certificates associated with any SCAs involved. In addition, display device 150’ s request at step 310 may include a request forblack-listed certificates. Black-listed certificates refer to certificates of entities (e.g., devices, SCAs, etc.) that should not be trusted by display device 150 any longer. For example, black-listed certificates may indicate unauthorized partner devices (e.g., pump devices) or any unauthorized and / or faulty transmitters.

[0105] At optional step 312, server system 134 sends display device 150 any intermediary and / or black-listed certificates that were requested by display device 150 and also available at server system 134. It is contemplated that in some embodiments a server system may be a partner device or a partner server system that the display device communicates forDexcom Ref. No.: 0989-PCT01 authentication. It is further contemplated that a partner device may communicate with the server system 134 for authentication.

[0106] Accordingly, FIG. 3 illustrates a method by which display device 150 transmits a certificate signing request to server system 134, which may include a first and / or a second certificate.

[0107] Example Device-centric Authenticating Protocol

[0108] FIG. 4A is a sequence diagram illustrating display device 150 and SS 8 engaging in a device-centric authentication protocol, such as a PKI authentication protocol. FIG. 4B illustrates an example chain of certificates that may be used as part of the device-centric authentication protocol. FIGS. 4C and 4D illustrate alternative and / or additional embodiments for performing the device-centric authentication protocol. As such, FIGS. 4A, 4B, 4C, and 4D are described together for clarity.

[0109] At step 402 of FIG. 4A, display device 150 transmits its credentials or authentication data (e.g., described with respect to FIG. 3) to SS 8. In certain embodiments, as shown in step 402 of FIG. 4C, display device 150’ s credentials include display device 150’s certificate as well as a message signed by display device 150. In certain embodiments, as shown in step 402 FIG. 4D, display device 150’ s credentials may include display device 150’ s certificate. In certain embodiments, display device 150’s certificate comprises display device 150’s public key (“DD-Pub”) and / or additional information, such as the name of display device 150, the certificate’s expiration information, etc. In certain embodiments, display device 150’s certificate also includes a digital signature of server system 134 or a SCA.

[0110] In certain embodiments, a message that is signed by display device 150 refers to a message that includes a first portion that is unencrypted as well as a second portion that includes a digital signature. In certain embodiments, the digital signature refer to an encrypted hash of the first portion. In certain embodiments, display device 150 encrypts the hash of the first portion using its private key (“DD-Priv”).

[0111] In certain embodiments where display device 150’s certificate is not directly signed by server system 134’ s private key, display device 150 may also be configured to transmit intermediary certificates of any SCAs involved in display device 150’s chain of certificates. However, in certain embodiments, SS 8 may be already configured with such intermediary certificate(s), in which case display device 150 may refrain from transmitting such intermediary certificate(s) to SS 8.Dexcom Ref. No.: 0989-PCT01

[0112] At step 404 of FIG. 4A, SS 8 verifies display device 150’s credentials. In certain embodiments, SS 8 is configured (e.g., stores) with a signed certificate of server system 134, including server system 134’s public key (“RCA-Pub”). In certain embodiments where display device 150’s certificate is signed by server system 134 private key (“RCA-Priv”), SS 8 uses the RCA-Pub to decrypt or verify the digital signature included in display device 150’s certificate. Note that the RCA-Pub is able to decrypt what has been signed with the RCA-Priv. Therefore, if SS 8 is able to decrypt the digital signature, and the resulting information is equal to the hash of the first unencrypted portion in display device 150’ s certificate, then SS 8 is able to conclude that display device 150 is trusted by server system 134 because RCA-Priv was used to sign display device 150’ s certificate. If SS 8 fails to decrypt the digital signature, SS 8 concludes that display device 150 should not be trusted and ends the device-centric mutual authentication protocol. Note that, in certain embodiments, SS 8 may communicate with and be authenticated by the server system 134 directly and vice versa (via WiFi, cellular, etc.).

[0113] In certain embodiments where one or more intermediary certificates are involved in display device 150’ s chain of certificates, SS 8 authenticates each of the intermediary certificates involved, starting from the intermediary certificate that is signed by RCA-Priv (i.e., the intermediary certificate of the SCA just below server system 134 in the chain of certificates) and ending with the intermediary certificate whose private key was used to sign display device 150’s certificate. Once all intermediary certificates are authenticated, SS 8 authenticates display device 150’s certificate. Details relating to authenticating a chain of certificates is described with respect to step 408 as well as FIG. 4B, which illustrates SS 8’s chain of certificates.

[0114] As described above, FIGS. 4C and 4D illustrate alternative embodiments for performing the device-centric authentication protocol, including step 404, shown in FIG. 4A. In certain embodiments, in FIG. 4C, where display device 150’s credentials include a message signed by display device 150, at step 404, SS 8 uses the signed message to determine whether or not it was actually display device 150 itself that transmitted display device 150’s credentials at step 402. In other words, SS 8 verifies the integrity of the transmitting entity of display device 150’s credentials, which involves verifying that the transmitter is in possession of DD- Priv. Note that the transmitting entity of display device 150’ s credentials is the entity that transmitted the display device 150’s credentials. Because no other device than display device 150 can be in possession of DD-Priv, by ensuring that the transmitting entity is in possessionDexcom Ref. No.: 0989-PCT01 of DD-priv, SS 8 may conclude that the transmitting entity of display device 150’s credentials is in fact display device 150.

[0115] To verify whether the transmitting entity is in possession of DD-Priv, SS 8 uses DD- Pub from display device 150’s certificate (which SS 8 already authenticated in step 404) and decrypts the encrypted portion (i.e., second portion) of the signed message. If an unencrypted version of the second portion is equal to a hash of the first portion of the signed message, then it means that the signed message was signed by DD-Priv. Therefore, SS 8 concludes that the transmitting entity that transmitted display device 150’s credentials was in fact display device 150 itself. Performing this integrity verification may be advantageous to protect against an attacker that may have improperly obtained display device 150’s certificate (e.g., a man in the middle attacker that has intercepted display device 150 during a transmission of display device 150’s credentials) and be attempting to impersonate display device 150.

[0116] In certain embodiments of FIG. 4D, where display device 150’ s credentials do not include a message signed by display device 150, the integrity of the transmitting entity of display device 150’ s credentials may be verified during execution of a key verification protocol.

[0117] Referring back to FIG. 4A, at step 406, SS 8 transmits its credentials to display device 150. In certain embodiments, as shown in step 406 of FIG. 4C, SS 8’s credentials include SS 8’s certificate as well as a message signed by SS 8. In certain embodiments, as shown in step 406 of FIG. 4D, SS 8’s credentials only include SS 8’s certificate. In certain embodiments, SS 8’s certificate is signed directly by server system 134 and, in certain other embodiments, SS 8’s certificate is signed by a SCA. In certain embodiments where SS 8’s certificate is signed by a SCA, at step 406, SS 8 may also transmit any intermediary certificates in SS 8’s chain of certificates. Note that steps 404-408 are triggered because display device 105 sent its credentials to SS 8 at step 402.

[0118] Moving to FIG. 4B, FIG. 4B illustrates a chain of certificates associated with SS 8. In the example of FIG. 4B, two SCAs (e.g., which could be or include one or more servers or computing devices), having intermediary certificates 422 and 424, are involved in SS 8’s chain of certificates. As shown, SS 8’s chain of certificates starts with SS 8’s own certificate 420 and ends with server system 134’s certificate 426. In certain embodiments, SS 8’s certificate comprises SS 8’s public key (“SS-Pub”) and / or additional information, such as the name of SS 8, the certificate’s expiration information, etc. SS 8’s certificate also includes a digitalDexcom Ref. No.: 0989-PCT01 signature, which refers to a hash of the information in SS 8’s certificate 420 (e.g., SS 8’s name, SS-Pub, and the certificate’s expiration information) that is encrypted with a private key of SCA 2 (e.g., which could be or include one or more servers or computing devices). Similarly, intermediary certificate 422 is signed by a private key of SCA 1 and intermediary certificate 424 is signed by the RCA-Priv of server system 134.

[0119] Referring back to FIG. 4A, at step 408, display device 150 verifies SS 8’s credentials. For example, display device 150 may initially verify the identity of certificate 424 by decrypting the digital signature in certificate 424 using the RCA-Pub. Following that, display device 150 hashes the information included in certificate 424 (except for the digital signature). If the result of the hashing and the decrypting are the same, the authenticity of certificate 424 is verified. Display device 150 similarly verifies the authenticity of certificates 422 and 420. Once certificate 420 is also verified, display device 150 is able to conclude that SS 8 is trusted by server system 134.

[0120] In certain embodiments of FIG. 4C, where SS 8’s credentials include a message signed by SS 8, display device 150 uses the signed message to determine whether or not it was actually SS 8 itself that transmitted SS 8’s credentials at step 406. Verifying the integrity of the transmitting entity of SS 8’s credentials is performed in a similar manner described above. More specifically, verifying the integrity of the transmitting entity of SS 8’s credentials includes decrypting the signed message using SS-Pub and hashing the information in the message. If the result of the decryption and hashing are the same, then display device 150 concludes that the transmitting entity of SS 8’s credentials was in fact SS 8 itself.

[0121] Once display device 150 and SS 8 have verified each other’s credentials, they have each authenticated that the other is trusted by server system 134, e.g., the diabetes trust management system.

[0122] FIG. 4C, as described above, illustrates a device-centric authentication protocol whereby display device 150 and SS 8 are configured to transmit signed messages to each other for integrity verification purposes. FIG. 4D, as described above, illustrates a device-centric authentication protocol whereby display device 150 and SS 8 are configured not to transmit signed messages to each other for integrity verification purposes.

[0123] Aspects Related to Issuing Application Certificates for Users

[0124] PKI may be used to perform authentication and secure communication between the SS 8 of the health management system 100 and a health monitoring application, such as the analyteDexcom Ref. No.: 0989-PCT01 sensor application 121, executing on the display device 150 of the health management system 100. As discussed above, PKI enables this secure communication through the use of respective pairs of public keys and private keys assigned to the SS 8 and the display device 150. A public key may be used to encrypt data and may be freely distributed and widely accessible, while a private key may be used to decrypt the encrypted data and is kept confidential by its assigned owner (e.g., the SS 8 or display device 150) to ensure security.

[0125] The use of PKI begins with the display device 150 locally generating an asymmetric key pair, including a PKI public key and a PKI private key. The display device may then transmit a certificate signing request (CSR), including the public key of the display device 150 to a trusted entity, known as a Certificate Authority (CA). In response to the CSR, the CA may bind the public key included in the CSR to the display device 150 and may issue a digital certificate, signed by a private key of the CA, to the display device 150 that includes the public key of the display device 150 and identity information of the display device 150. In some cases, rather than performing a similar process as performed by the display device for generating the asymmetric key pair and receiving the digital certificate, the SS 8 may instead be provisioned with a respective asymmetric key pair and a digital certificate (e.g., including the public key for the SS 8 and identity information of the SS 8) by a manufacturer of the analyte sensor system.

[0126] When communication between the display device 150 and the SS 8 is desired, the display device 150 and SS 8 may engage in a certificate exchange procedure, as shown in steps 402 and 406 of FIGS. 4A, 4C, and 4D. During the certificate exchange procedure the display device 150 provides its respective certificate to the SS 8 comprising its respective public key. Likewise, the SS 8 may also provide its respective certificate to the display device 150 including the public key for the SS 8. Each of the display device 150 and SS 8 may then decrypt each other’s certificate using a private key associated with the CA to obtain each other’s public keys.

[0127] Thereafter, when, for example, the SS 8 desires to securely send information to the display device 150, such as analyte data, the SS 8 may use the public key of the display device 150 (e.g., obtained from the certificate of the display device 150) to encrypt a message including the analyte data before transmitting the encrypted message to the display device 150. Upon receiving the encrypted message, the display device 150 may use its private key to decrypt the encrypted message. Since the encrypted message may only be decrypted using the private key of the display device 150 and since only the display device 150 has access to itsDexcom Ref. No.: 0989-PCT01 private key, this ensures that only the display device 150 can access the decrypted message, including the analyte data.

[0128] As described above, to improve security, PKI may be used for wireless communications between the SS 8 and the health monitoring application (e.g., analyte sensor application 121) executing on the display device 150. When the health monitoring application connects to the analyte sensor system through a pairing procedure, certificates from both the SS 8 and the health monitoring application of the display device 150 are used to perform mutual authentication. Only valid certificates issued by a trusted CA may be accepted during the pairing procedure. For the SS 8, a certificate may be issued during a manufacturing process of the SS 8 at a secure manufacturing site. However, a certificate for the health monitoring application of the display device 150 may need to be issued after the health monitoring application is installed on the display device 150.

[0129] In some cases, per a certificate policy (CP) of a manufacturer of the SS 8, prior to issuing a certificate to an end-entity (such as a user or the health monitoring application of the display device 150), for use with communicating with the SS 8, an identity of the end-entity must be authenticated or proofed. To meet this requirement of the CP and to obtain a certificate, the health monitoring application may be required to provide the following information along with a signed certificate signing request (CSR): (1) a secure message including a software ID associated with the health monitoring application (e.g., software version, display device identifier, etc.), which may be signed by a cryptographic key (e.g., a PKI private key of the display device 150), and (2) an access token, such as a JSON Web Token (JWT), signed by a trusted identity provider (IdP) entity. The secure message may provide identity information for the display device 150 and health monitoring application identity, while the access token may provide identity information of a user. The health monitoring application of the display device 150 may then provide the secure message, access token, and CSR to a PKI service that performs a PKI Registration Authority (RA) role to validate the provided information before submitting the CSR to the CA for certificate issuance for the health monitoring application of the display device 150.

[0130] As can be seen, the certificate for the health monitoring application depends, in part, on an access token, which may be obtained from the CAMS entity associated with the manufacturer of the SS 8. Further, to obtain the access token, a user must first have a manufacturer- specific user account registered with the CAMS entity of the manufacturer and must provide credentials to the CAMS entity to sign into (login) that user account. To registerDexcom Ref. No.: 0989-PCT01 a user account in CAMS, the user selects a set of credentials to login to the user account, such as a username and a password. The user account may also include personal identifying information (PIT) provided by the user, such as an email address, a full name, a COR, and so on. The user account may be managed by a CAMS of the manufacturer, as in more detail described below.

[0131] Example Operations of Entities in a Health Management System

[0132] FIG. 5 depicts a sequence diagram including operations 500 between entities in a health management system, such as the health management system 100. As will be described below, operations 500 relate to techniques for issuing an application certificate for a health monitoring application of the display device 150 associated with a user.

[0133] As shown, the entities include a user 502, the SS 8, an application repository 504, a health monitoring application 506 of the display device 150, a trusted identity provider (IdP) entity 508, a CAMS entity 510, a CLM entity 512, and a CA entity 514. The health monitoring application 506 may be an example of the analyte sensor application 121 described with respect to FIG. IB. In some embodiments, the IdP entity 508, the CAMS entity 510, the CLM entity 512, and the CA entity 514 may be associated with, managed by, or provide authentication services for a manufacturer of the SS 8. In some embodiments, the CA entity 514 may be a PKI software as a service (SaaS) entity configured to receive certificate signing requests and to issue certificates, such as the application certificate for the health monitoring application 506. In some embodiments, the IdP entity 508, the CAMS entity 510, the CLM entity 512, and the CA entity 514 may be hosted by the manufacturer of the SS 8 or may otherwise be associated with the manufacturer of the SS 8 (e.g., the manufacturer may contract out certain functionalities provided by the IdP entity 508, the CAMS entity 510, the CLM entity 512, and the CA entity 514 to one or more third parties). In some embodiments, the IdP entity 508, the CAMS entity 510, the CLM entity 512, and the CA entity 514 may be implemented as different logical entities within a single server or may be distributed across multiple servers.

[0134] As shown, operations 500 begin at 516 with the user 502 downloading the health monitoring application 506 from the application repository 504 and installing the health monitoring application 506 on the display device 150 for communicating with, and monitoring analyte data received from, the SS 8. In some embodiments, the health monitoring application 506 may have been developed by or for the manufacturer of the SS 8 and may be used to allow the manufacture to directly manage the analyte data of the user 502.Dexcom Ref. No.: 0989-PCT01

[0135] As shown, once the health monitoring application 506 has been downloaded and installed on the display device 150, the user 502 may provide input to the display device 150 at 518 to execute or “run” the health monitoring application 506, which may begin a mutual authentication process (e.g., a device-centric authentication protocol, such as PKI) between the SS 8 and the health monitoring application 506 of the display device 150 (e.g., as described herein).

[0136] In some embodiments, as shown at 520, prior to performing the mutual authentication process, the user 502 may optionally be prompted to perform a challenge-response test, such as a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) . The challenge-response test may be designed to block mass automatic generation of access tokens and application certificates by non-human entities, such as “bots.” For example, as shown at 522, the user 502 may be required to enter a set of letters or numbers displayed on the GUI of the health monitoring application 506 or may be required to solve a puzzle or perform some other task, such as dragging a slider to match a shape with a corresponding cutout displayed on the GUI of the health monitoring application 506.

[0137] In some embodiments, whether the user 502 is required to perform the challengeresponse test may depend on an authentication assurance level with the user 502. If, however, the health monitoring application 506 is simply installed on the display device 150 and assigned to the user 502 without any substantive authentication measures (e.g., the user 502 is not required to self-authenticate), this may not provide a sufficient authentication assurance level to avoid the chances that the health monitoring application 506 is used to access tokens and application certificates are automatically generated on a mass scale. In this case, since the level of security may not be sufficient, the user 502 may be required to perform the challengeresponse test to ensure that the entity (e.g., the user 502) that is requesting the access token and application certificate is a human rather than a non-human entity.

[0138] As shown at 524, if the user successfully completes the challenge-response test, the health monitoring application 506 may proceed to send a message (e.g., a “sign-in” message) to the IdP entity 508, including a set of credentials for the user account(such as a username and a password). The user account may also include a trusted user flag and a COR, as well as additional personal identification information (PII) of the user 502 or protected health information (PHI) of the user 502. The personal identification information may include representation of information that permits the identity of an individual (e.g., user 502) to whom the information applies to be reasonably inferred by either direct or indirect means. TheDexcom Ref. No.: 0989-PCT01 protected health information may include any information in a medical record or designated record set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment.

[0139] Thereafter, as shown at 526, the IdP entity 508 forwards the set of credentials received from the health monitoring application 506 to the CAMS entity 510 for authentication. If the credentials match an account provisioned in the CAMS entity 510 (e.g., a user account), the CAMS entity 510 sends a response message to the IdP entity 508 at 528, indicating that the account credentials have been authenticated.

[0140] At shown at 530, in response to receiving the response message from the CAMS entity 510 indicating that the set of credentials have been authenticated, the IdP entity 508 may then generate an access token for the health monitoring application 506. In some embodiments, the access token may comprise a JSON Web Token (JWT), which may include three parts: a header, a payload, and signature. The header may indicate a token type (e.g., JWT) and a cryptographic algorithm employed for signing (e.g., Hash-based Message Authentication Code using Secure Hash Algorithm 256-bit (HS256)). The payload encapsulates claims, which encompass statements regarding the entity and supplementary data. For example, these claims may indicate information such as the issuer of the token, the subject of the token, an expiration time of the token, and audience of the token (e.g., identifies recipients for whom the token is intended). Finally, the signature is generated by encoding a concatenation of the header and payload and then applying a digital signature algorithm (e.g., HS256) using a secret key.

[0141] Thereafter, as shown at 532, the IdP entity 508 may then send the access token to the health monitoring application 506. In some embodiments, as described above, the access token may include a trusted user flag for the user account.

[0142] At 534, the health monitoring application 506 may then generate a PKI key pair and a certificate signing request (CSR). For example, the PKI key pair generated by the health monitoring application 506 may include a public key and a private key of the health monitoring application 506, and may be stored in a secure location accessible by the health monitoring application 506. Additionally, the CSR may include the public key of, or accessible by, the health monitoring application 506 and a request that an application certificate be issued for the health monitoring application 506 for use when pairing with the SS 8.

[0143] In some embodiments, the health monitoring application 506 may use cryptographic APIs to generate the PKI key pair, including the public key and private key. For example, inDexcom Ref. No.: 0989-PCT01 some embodiments, the PKI key pair may include an elliptic curve cryptography (ECC) key pair, which may be generated by selecting a specific elliptic curve equation and a point on that curve called the generator point. The private key may be a randomly chosen number, while the public key is derived by multiplying the generator point by the private key. For example, the private key may be generated by selecting a random integer d within a specific range defined by the elliptic curve's parameters. The public key may then be derived from the private key using point multiplication on the elliptic curve. For example, this may involve a scalar multiplication operation where the generator point G (a fixed point on the curve with known coordinates) is repeatedly added to itself d times, where d is the private key. Mathematically, the public key Q is calculated as: Q =dxG, where Q is the resulting public key, d is the private key, and G is the generator point.

[0144] Thereafter, as shown at 536, the health monitoring application 506 may then generate a signed message. The signed message may include the CSR and identity information identifying the health monitoring application 506, such as application type of the health monitoring application 506 (e.g., iOS or Android), a version number of the health monitoring application 506, or an indication of a hardware type of the display device 150, and / or other identity information that identifies the health monitoring application 506. In some embodiments, the signed message may be signed using the private key of the health monitoring application 506.

[0145] Thereafter, as shown at 538, the health monitoring application 506 sends the access token (e.g., including the identity information of the user) and the signed message (e.g., including the CSR and the identity information identifying the health monitoring application 506) to the CEM entity 512 for validation.

[0146] At 540, if the CSR and access token received from the health monitoring application 506 are validated by the CEM entity 512, the CLM entity 512 may send the CSR to the CA entity 514, requesting that the CA entity 514 issue an application certificate for the health monitoring application 506.

[0147] As shown at 542, in response to the CSR, the CA entity 514 may issue the application certificate for the health monitoring application 506. The application certificate may include the public key of the health monitoring application 506 (e.g., which was included in the CSR) and may be signed using a private key of the CA entity 514.Dexcom Ref. No.: 0989-PCT01

[0148] As shown at 544, after issuing the application certificate for the health monitoring application 506, the CA entity 514 may then send the application certificate to the CLM entity 512 before it is forwarded by the CLM entity 512 to the health monitoring application 506 of the display device 150 at 546.

[0149] Thereafter, at 548, the health monitoring application 506 may bind the public key included within the application certificate with the private key generated by the health monitoring application 506 at 534.

[0150] Thereafter, at 550, the health monitoring application 506 may proceed with establishing a wireless connection (e.g., Bluetooth, Wi-Fi, cellular, etc.) with the SS 8 by performing an authentication or pairing procedure to pair with the SS 8. In some embodiments, the authentication or pairing procedure may be based on one or more authentication protocols, such as the PKI scheme described above. For example, as discussed above, in order to authenticate and pair with the SS 8 using the PKI scheme, the health monitoring application 506 and the SS 8 may engage in a certificate exchange procedure. During the certificate exchange procedure, the health monitoring application 506 may provide the application certificate to the SS 8 containing the public key for the health monitoring application 506. Likewise, the SS 8 may also provide a certificate to the health monitoring application 506 of the display device 150 including a public key for the SS 8. Since each certificate is signed by the private key of the CA entity 514, the health monitoring application 506 and the SS 8 may then each decrypt each other’s certificate using the private key associated with the CA to obtain each other’s public keys. Stated otherwise, the health monitoring application 506 may decrypt the certificate received from the SS 8 to obtain the public key of the SS 8. Similarly, the SS 8 may decrypt the certificate received from the health monitoring application 506 to obtain the public key of the health monitoring application 506.

[0151] Thereafter, when, for example, the SS 8 desires to securely send information to the health monitoring application 506 on the display device 150, such as analyte data, the SS 8 may use the public key of the health monitoring application 506 to encrypt a message including the analyte data, as shown at 552. The SS 8 may then transmit the encrypted message to the health monitoring application on the display device, as shown at 554. Thereafter, as shown at 556, upon receiving the encrypted message, the health monitoring application 506 may use its private key to decrypt the encrypted message to obtain the analyte data. At 558, the health monitoring application 506 may process the analyte data and display it to the user 502.Dexcom Ref. No.: 0989-PCT01

[0152] It should be appreciated that, while authentication and pairing between the SS 8 and the health monitoring application 506 of the display device 150 may, in some cases, include additional steps involving other authentication protocols, such as PAKE, these additional authentication steps and other authentication protocols are optional and are not required to practice the techniques presented above with respect to FIG. 5.

[0153] Example Operations of a Display Device

[0154] FIG. 6 shows an example of a method 600 for obtaining an application certificate for a health monitoring application of a display device for wireless communication with an analyte sensor system. The method 600 may be performed by a display device, such as the display device 150 depicted and described with respect to FIGS. IB, 2, 3, 4A, 4C, 4D, and 5. In some embodiments, method 600 may be performed by one or more processors of the display device, such as the one or more processors 126, based on instructions stored in one or more memories. For example, in some embodiments, the display device may include one or more memories, such as the one or more memories 127, including instructions that, when executed by the one or more processors, cause the display device to perform the method 600. In some embodiments, the instructions may be associated or embedded in a health monitoring application installed on the display device, such as the health monitoring application 506 depicted and described with respect to FIG. 5. The analyte sensor system may be an example of the SS 8 depicted and described with respect to FIGS. IB, 2, 3, 4A, 4C, 4D, and 5.

[0155] As shown, method 600 begins at 602 with the display device obtaining a set of credentials for an account provisioned with personal identification information of a user associated with the analyte sensor system. In some embodiments, the account is provisioned on a CAMS entity (e.g., CAMS entity 510 of FIG. 5) that is associated with a manufacturer of the analyte sensor system. In some embodiments, the display device is configured to display analyte data received from the analyte sensor system.

[0156] At 604, the display device sends, to a trusted identity provider (IdP) entity (e.g., IdP entity 508 of FIG. 5) associated with a manufacturer of the analyte sensor system, the set of credentials for the account.

[0157] At 606, the display device obtains, from the IdP entity in response to sending the set of credentials, an access token.

[0158] At 608, the display device sends, to a certificate lifecycle management system (CEM) entity (e.g., CEM entity 512 of FIG. 5), the access token and a signed message requesting anDexcom Ref. No.: 0989-PCT01 application certificate, wherein the signed message includes a certificate signing request (CSR) and identity information for the health monitoring application of the display device.

[0159] At 610, the display device obtains, from a certificate authority (CA) entity (e.g., CA entity 514 of FIG. 5) via the CLM entity in response to the access token and the signed message requesting the application certificate, the application certificate for the health monitoring application of the display device.

[0160] At 612, the display device establishes a wireless connection with the analyte sensor system using the application certificate.

[0161] At 614, the display device optionally receives encrypted analyte data from the analyte sensor system using the wireless connection.

[0162] In some embodiments, the health monitoring application is associated with a user.

[0163] In some embodiments, the method 600 further includes generating an asymmetric key pair, including a private key associated with the health monitoring application and a public key associated with the health monitoring application. In some embodiments, the signed message is signed using the private key associated with the health monitoring application. In some embodiments, the CSR includes the public key associated with the health monitoring application and a request to issue the application certificate for the health monitoring application. In some embodiments, the application certificate includes the public key associated with the health monitoring application and is signed based on a private key of the CA entity.

[0164] In some embodiments, method 600 further includes displaying a challenge-response test on a graphic user interface (GUI) of the health monitoring application. In some embodiments, method 600 further includes receiving input successfully completing the challenge-response test, wherein sending the set of credentials to the IdP entity is based on the input successfully completing the challenge-response test. In some embodiments, displaying the challenge-response test is based on an authentication assurance level associated with a user of the analyte sensor system.

[0165] In some embodiments, the application certificate comprises a public key infrastructure (PKI) public key of the health monitoring application. In some embodiments, establishing the wireless connection with the analyte sensor system at 612 includes performing a pairing procedure with the analyte sensor system using the application certificate. In some embodiments, performing the pairing procedure with the analyte sensor system may include sending the application certificate for the health monitoring application to the analyte sensorDexcom Ref. No.: 0989-PCT01 system, receiving a certificate for the analyte sensor system, and decrypting the certificate for the analyte sensor system based on a private key associated with the CA entity to obtain a public key for the analyte sensor system.

[0166] In some embodiments, method 600 further includes, after performing the pairing procedure with the analyte sensor system, receiving an encrypted message from the analyte sensor system including analyte data of a user of the analyte sensor system. In some embodiments, the encrypted message is encrypted based on the public key of the health monitoring application. In some embodiments, method 600 further includes decrypting the encrypted message using a private key of the health monitoring application to obtain the analyte data of the user.

[0167] In some embodiments, the set of credentials are embedded in the health monitoring application.

[0168] FIG. 7 shows an example of a method 700 for obtaining an application certificate for a health monitoring application of a display device for wireless communication with an analyte sensor system. The method 700 may be performed by a display device, such as the display device 150 depicted and described with respect to FIGS. IB, 2, 3, 4A, 4C, 4D, and 5. In some embodiments, method 700 may be performed by one or more processors of the display device, such as the one or more processors 126, based on instructions stored in one or more memories. For example, in some embodiments, the display device may include one or more memories, such as the one or more memories 127, including instructions that, when executed by the one or more processors, cause the display device to perform the method 700. In some embodiments, the instructions may be associated or embedded in a health monitoring application installed on the display device, such as the health monitoring application 506 depicted and described with respect to FIG. 5. The analyte sensor system may be an example of the SS 8 depicted and described with respect to FIGS. IB, 2, 3, 4A, 4C, 4D, and 5.

[0169] As shown, method 700 begins at 702 with the display device installing and executing the health monitoring application. In some embodiments, the health monitoring application is configured to display an analyte value associated with the analyte sensor system.

[0170] At 704, the display device displays a graphical user interface (GUI) of the health monitoring application, wherein the GUI provides an option to establish a wireless connection with the analyte sensor system.Dexcom Ref. No.: 0989-PCT01

[0171] At 706, the display device receives, from a user associated with the analyte sensor system, input to establish the wireless connection with the analyte sensor system based on the option provided by the GUI.

[0172] At 708, the display device sends, to an identity management entity (e.g., IdP entity 508 described with respect to FIG. 5) associated with a manufacturer of the analyte sensor system in response to receiving the input to establish the wireless connection with the analyte sensor system, a set of credentials for an account provisioned with personal identification information associated with the user.

[0173] At 710, the display device receives an access token for the health monitoring application in response to sending the set of credentials for the account.

[0174] At 712, the display device sends, to a certificate authority (CA) entity (e.g., CA entity 514 described with respect to FIG. 5), a message requesting the application certificate for the health monitoring application, wherein the message includes at least the access token for the health monitoring application.

[0175] At 714, the display device receives the application certificate for the health monitoring application in response to sending the message requesting the application certificate for the health monitoring application.

[0176] At 716, the display device establishes the wireless connection with the analyte sensor system using the application certificate for the health monitoring application.

[0177] In some embodiments, method 700 further includes displaying a challenge-response test on the GUI of the health monitoring application. In some embodiments, method 700 further includes receiving input successfully completing the challenge-response test. In some embodiments, sending the set of credentials to the identity management entity at 708 is based on the input successfully completing the challenge-response test.

[0178] In some embodiments, displaying the challenge-response test is based on an authentication assurance level associated with a user of the analyte sensor system.

[0179] In some embodiments, the user account comprises an account for a user of the analyte sensor system provisioned with personal identification information of the user.

[0180] In some embodiments, method 700 further includes generating an asymmetric key pair, including a private key associated with the health monitoring application and a public key associated with the health monitoring application.Dexcom Ref. No.: 0989-PCT01

[0181] In some embodiments, the message is signed using the private key associated with the health monitoring application.

[0182] In some embodiments, the message includes a certificate signing request (CSR) requesting the application certificate for the health monitoring application. In some embodiments, the CSR includes: the public key associated with the health monitoring application; and a request to issue the application certificate for the health monitoring application.

[0183] In some embodiments, the application certificate includes the public key associated with the health monitoring application and is signed based on a private key of the CA entity.

[0184] In some embodiments, the application certificate comprises a public key of the health monitoring application.

[0185] In some embodiments, establishing the wireless connection with the analyte sensor system at 716 comprises performing a pairing procedure with the analyte sensor system using the application certificate.

[0186] In some embodiments, performing the pairing procedure with the analyte sensor system comprises sending the application certificate for the health monitoring application to the analyte sensor system. In some embodiments, performing the pairing procedure with the analyte sensor system comprises receiving a certificate for the analyte sensor system; and decrypting the certificate for the analyte sensor system based on a private key associated with the CA entity to obtain a public key for the analyte sensor system.

[0187] In some embodiments, method 700 further includes, after performing the pairing procedure with the analyte sensor system, receiving an encrypted message from the analyte sensor system including analyte data of a user of the analyte sensor system. In some embodiments, the encrypted message is encrypted based on the public key of the health monitoring application. In some embodiments, method 700 further includes decrypting the encrypted message using a private key of the health monitoring application to obtain the analyte data of the user.

[0188] In some embodiments, the set of credentials are embedded in the health monitoring application.

[0189] Example Communications DeviceDexcom Ref. No.: 0989-PCT01

[0190] FIG. 8 depicts aspects of an example communications device 800. In some aspects, communications device 800 is a display device, such as display device 150 described above with respect to FIGS. IB, 2, 3, 4A, 4C, 4D, 5, and 6.

[0191] The communications device 800 includes a processing system 805 coupled to the transceiver 855 (e.g., a transmitter and / or a receiver). The transceiver 855 is configured to transmit and receive signals for the communications device 800 via the antenna 860, such as the various signals and messages as described herein. The processing system 805 may be configured to perform processing functions for the communications device 800, including processing signals received and / or to be transmitted by the communications device 800.

[0192] The processing system 805 includes one or more processors 810. In various aspects, the one or more processors 810 may be representative of the one or more processors 126, as described with respect to FIG. IB. The one or more processors 810 are coupled to a computer- readable medium / memory 830 via a bus 850. In some aspects, the computer-readable medium / memory 830may be representative of the one or more memories 127 and memory / storage 123, as described with respect to FIG. IB. In certain aspects, the computer- readable medium / memory 830 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 810, cause the one or more processors 810 to perform the method 600 described with respect to FIG. 6 and / or the method 700 described with respect to FIG. 7, or any aspect related to these methods. Note that reference to a processor performing a function of communications device 800 may include one or more processors 810 performing that function of communications device 800.

[0193] In the depicted example, computer-readable medium / memory 830 stores code (e.g., executable instructions), such as code for obtaining 835, code for sending 836, code for establishing 837, code for generating 838, code for displaying 839, code for receiving 840, code for performing 841, and code for decrypting 842. Processing of the code for obtaining 835, code for sending 836, code for establishing 837, code for generating 838, code for displaying 839, code for receiving 840, code for performing 841, and code for decrypting 842 may cause the communications device 800 to perform the method 600 described with respect to FIG. 6 and / or the method 700 described with respect to FIG. 7, or any aspect related to these methods.

[0194] The one or more processors 810 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium / memory 830, including circuitryDexcom Ref. No.: 0989-PCT01 such as circuitry for obtaining 815, circuitry for sending 816, circuitry for establishing 817, circuitry for generating 818, circuitry for displaying 819, circuitry for receiving 820, circuitry for performing 821, and circuitry for decrypting 822. Processing with circuitry for obtaining 815, circuitry for sending 816, circuitry for establishing 817, circuitry for generating 818, circuitry for displaying 819, circuitry for receiving 820, circuitry for performing 821, and circuitry for decrypting 822 may cause the communications device 800 to perform the method 600 described with respect to FIG. 6 and / or the method 700 described with respect to FIG. 7, or any aspect related to these methods.

[0195] Various components of the communications device 800 may provide means for performing the method 600 described with respect to FIG. 6 and / or the method 700 described with respect to FIG. 7, or any aspect related to these methods. For example, means for transmitting, sending or outputting for transmission may include transceiver 129 of the display device 150 illustrated in FIG. IB and / or the transceiver 855 and the antenna 860 of the communications device 800 in FIG. 8. Means for receiving or obtaining may include transceiver 129 of the display device 150 illustrated in FIG. IB and / or the transceiver 855 and the antenna 860 of the communications device 800 in FIG. 8. Means for establishing, means for generating, means for displaying, means for performing, and means for decrypting may include one or more processors, such as the one or more processors 126 of the display device 150 illustrated in FIG. IB and / or the one or more processors 810 of the communications device 800 in FIG. 8. In some cases, means for displaying may further include the display 125 of the display device 150 illustrated in FIG. IB.

[0196] Example Trusted User Indicator

[0197] FIG. 9 depicts a sequence diagram 900 illustrating operations for authenticating a user of an analyte sensor application 121 during an initial login process, in accordance with embodiments of the present disclosure. Portions of the sequence 900 may be respectively performed by the analyte sensor application 121 and the support modules 161 executing on the display device 150 of FIG. IB, the CAMS 510 of FIG. 5, and the configuration server (CS) 511. The messages exchanged between the display device 150 and the CAMS 510, between the display device 150 and the CS 511, and between the CAMS 510 and the CS 511 may be encrypted.

[0198] As described above, the processor 126 of the display device 150 executes the OS 162 and presents the GUI 124 to the user on the display 125. In a default state or screen, the GUIDexcom Ref. No.: 0989-PCT01124 depicts an application selection interface that presents one or more user-selectable icons that represent applications that are available for execution by the processor 126, such as the analyte sensor application 121. Generally, the applications may include or be supported by libraries, frameworks, software development kits (SDKs), application programming interfaces (APIs), communication orchestration modules, authorization management modules, and so on, collectively represented by support modules 161.

[0199] The sequence block 905 depicts the interactions between the GUI 124, the analyte monitoring application 121, the CAMS 510, and the CS 511 during user account creation and configuration of the analyte monitoring application 121 (e.g., after the initial installation of the analyte monitoring application 121 but before an initial login).

[0200] In certain embodiments, analyte monitoring application 121 may present a web-based user interface (e.g., WebView, browser window, etc.) or the user may select an icon representing a web browser application to access a web page hosted by the CAMS 510 (e.g., the server system 134) to create a user account. The web page requests that the user provide a username (e.g., email address, name, etc.), a password, and a COR for configuration of the features of the analyte sensor application 121. The user may input this data in respective text fields presented by the GUI 124. Alternatively, the GUI 124 may present a list of countries (e.g., a list of two-letter country codes) in the GUI 124 for selection by the user of a COR (e.g., via a drop down menu). In some embodiments, the CAMS 510 may request geographic location information from the display device 150 (e.g., cellular network tower location, etc.) and customize the list of countries based on the location information.

[0201] In response, the CAMS 510 creates a user account associated with the user and stores the user account in a memory (e.g., the memory 138 and / or the memory / storage 136 of the server system 134). The user account includes, inter alia, the username, the password, the COR selected by the user, and a trusted user flag. In certain embodiments, the CAMS 510 sets the trusted user flag to “not trusted.” The CAMS 510 then sends an instruction to the CS 511 to set the user configuration of the analyte monitoring application 121 installed on the display device 150 based on the COR stored in the user account associated with the user.

[0202] In other embodiments, rather than a web browser, the analyte monitoring application 121 may provide a custom interface that requests that the user provide a username, a password, and a COR when the analyte monitoring application 121 is launched for the first time by the user. In some embodiments, the analyte monitoring application 121 may request that the userDexcom Ref. No.: 0989-PCT01 grant permission to determine the geographic location of the display device 150, and in response to the user granting permission, perform an initial GFC check using the geographic location of the display device 150 (e.g., provided by an OS function) and the COR selected by the user. If the analyte sensor application 121 determines that the geographic location does not match the COR selected by the user in the respective field, the analyte sensor application 121 may display a notification in the GUI 124 indicating that an improper or incorrect COR was selected by the user. If the analyte sensor application 121 successfully determines that the geographic location matches the COR selected by the user, the analyte sensor application 121 sends the set of credentials (e.g., the username and password) and the COR selected by the user to the CAMS 510 over the network 190.

[0203] After the user account associated with the user is created by the CAMS 510, the analyte sensor application 121 is ready to perform the initial login process depicted in sequence blocks 910, 920, 930, and 904.

[0204] The sequence block 910 depicts the initial interactions between the analyte sensor application 121 and the GUI 124 presented to the user (e.g., as part of an initial login).

[0205] The user selects the icon representing the analyte sensor application 121 depicted by the GUI 124 to launch the analyte sensor application 121, which causes the processor 126 to execute the analyte sensor application 121. The analyte sensor application 121 replaces the application selection interface provided by the OS 162 with a custom interface for the analyte sensor application 121, which is presented by the GUI 124. The analyte sensor application 121 then requests that the user grant permission to determine the geographic location of the display device 150. In some embodiments, the analyte sensor application 121 was launched during the account creation process described above or previously and does not need to be re-launched.

[0206] After the user grants permission to determine the geographic location of the display device 150, the analyte sensor application 121 calls an OS function to access the geographic location of the display device 150, such as global positioning system (GPS) coordinates provided by a GPS receiver coupled to the processor 126. Alternatively, the OS function may determine the geographic location of the display device 150 based on wireless network information provided by the connectivity interface 128, such as the identity and geographic location of the cell phone tower to which the transceiver 129 is connected, the identity and location of a WiFi router and network to which the transceiver 129 is connected, a location associated with an IP address of the display device 150, and so on. In certain embodiments, theDexcom Ref. No.: 0989-PCT01 analyte sensor application 121 (or the support modules 161) converts or maps the geographic location of the display device 150 to a standard country code, such as an ISO 3166-1 two-letter country code.

[0207] If the user does not grant permission to determine the geographic location of the display device 150, the analyte sensor application 121 may wait for permission to be granted or simply ceases execution. After the geographic location of the display device 150 has been determined, the analyte sensor application 121 requests that the user provide the username and password.

[0208] The sequence block 920 depicts the next interactions between the analyte sensor application 121 and the account management system or CAMS 510, and between the CAMS 510 and the CS 511.

[0209] The GUI 124 then prompts the user to initially login by providing their username and password. In response to receiving the initial login request for the user over the network 190, the CAMS 510 accesses the user account associated with the user. As described above, the user account includes the trusted user flag, the username, the password, and the COR. The CAMS 510 may set the trusted user flag to “trusted” or “not trusted” when the user’s account is created (as described above). When the trusted user flag is set to “trusted” at the creation of the user’s account, no further location checks are needed. When the trusted user flag is set to “not trusted,” a successful location check or other indicator of trust may be used to establish trusted user status (e.g., at a time after account creation). In certain embodiments, the CAMS 510 sets the trusted user flag to “not trusted.”

[0210] For example, the trusted user flag may be set to “trusted” based on a successful location check during any login when the user’s display device 150 is located in the user’s COR. Additionally, the trusted user flag may be set to “trusted” based on having at least one measured analyte value (e.g., an estimated glucose value or EGV) stored in the memory 123 of the display device 150 (or the memory of the CAMS 510, server system 134, cloud storage, etc.), which indicates that the user has previously logged into the analyte monitoring application 121 and stored measured analyte data from the user’s analyte sensor system (e.g., SS 8).

[0211] In certain embodiments, the analyte sensor application 121 sends a location information request with the initial login request to the CAMS 510 to begin a location verification process. In some embodiments, the initial login request includes the location information request. In response to receiving the location information request, the CAMS 510 accesses the trusted user flag and the COR in the user account associated with the user and sends the trusted user flagDexcom Ref. No.: 0989-PCT01 and the COR to the display device 150 over the network 190. In some embodiments, the CAMS 510 simply sends the trusted user flag and the COR to the display device 150 (e.g., without receiving a separate location information request).

[0212] In certain embodiments, the CAMS 510 sends the trusted user flag and the COR as claims in a token, such as a JSON (JavaScript Object Notation) Web Token (JWT). Each claim may be represented as a key-value pair, which is a data structure in which a “key” is associated with a “value.” The key is a unique identifier (such as “trusted user flag”), and the value is the data or information tied to that key (such as “trusted” or “not trusted”). For example, a claim with a key of “trusted user flag” and a value of “trusted” states that the user is a trusted user, while a claim with the key “trusted user flag” and a value of “not trusted” states that the user is not a trusted user.

[0213] In response to receiving the initial login request for the user over the network 190, the CAMS 510 may also send a user configuration message to the CS 511 over the network 190. And, in response to receiving the user configuration message, the CS 511 may set a user configuration associated with the analyte sensor application 121 executing on the processor 126 of the display device 150. The user configuration may include one or more geography associated features including, for example, units of measure, configuration for customer survey information, silence all (e.g., alarms, alerts, etc.), sensor profile for wear locations and sensor types (e.g., sensor session duration, for example, 10 days, 15 days, etc., sensor models, etc.), customer engagement platform (e.g., a messaging platform, user notification settings, etc.), supported connected dosing device brands (e.g., insulin pen device brands, insulin pump device brands, etc.), multiple display device support (e.g., direct to watch, wearable display device support, etc.), medication logging (e.g., dosing information, dosing time information, etc.), activity (e.g., exercises, steps, etc.), analyte (e.g., glucose) sharing (e.g., data import and export to other applications or platforms), data sharing services (e.g., sharing with clinical or health systems, reporting applications or platforms, etc.), communication distance ranges (e.g., extended BLE range labeling), target range (e.g., whether a user can adjust target analyte range), events supported (e.g., fasting, meal logging, for example, with pictures, etc.) and so on.

[0214] The sequence block 930 depicts the interaction between the analyte sensor application 121 and the GUI 124 when the trusted user flag is set to “trusted” - the analyte sensor application 121 provides a notification to the GUI 124 that the user has successfully logged in. In other words, when the trusted user flag is set to “trusted,” the GFC check that is performedDexcom Ref. No.: 0989-PCT01 in sequence block 940 may be bypassed or skipped (e.g., or the result of the GCF check ignored), and one or more features of the analyte monitoring application 121 are executed without performing location verification. For example, the analyte sensor application 121 may display a GUI 124 for setting up an analyte sensor or continuing a sensor session.

[0215] The sequence block 940 depicts the interactions between the analyte sensor application 121, the GUI 124, the support modules 161, and the CAMS 510 when the trusted user flag is set to “not trusted.” The sequence block 940 also includes sequence blocks 942 and 944.

[0216] The analyte sensor application 121 calls the OS function to access the geographic location of the display device 150 and performs another GFC check using the geographic location of the display device 150 provided by the OS function and the COR provided by the token (e.g., received from CAMS 510 at block 920).

[0217] The sequence block 942 depicts the interactions between the analyte sensor application 121, the support modules 161, and the CAMS 510 when the analyte sensor application 121 successfully determines that the geographic location matches the COR provided by the user. The analyte sensor application 121 sets the trusted user flag to indicate that the user is trusted (based on the match of the location and the COR), stores the trusted user flag in the memory 123 and / or the memory 127, and instructs the support modules 161 (e.g., an SDK) to send the trusted user flag to the CAMS 510 over the network 190. In response to receiving the trusted user flag from the display device 150, the CAMS 510 stores the trusted user flag in the user account associated with the user in memory. In other words, the CAMS 510 sets the trusted user flag in the user account associated with the user to “trusted.”

[0218] The sequence block 944 depicts the interaction between the analyte sensor application 121 and the GUI 124 when the geographic location does not match the COR provided by the token - the analyte sensor application 121 provides a notification to the GUI 124 that the user has not successfully logged in and may block or cease further execution. In other words, in response to unsuccessful determination that the geographic location matches the COR, the analyte sensor application 121 ceases execution.

[0219] FIG. 10 depicts a sequence diagram 1000 illustrating operations for authenticating a user of an analyte sensor application 121 during a subsequent login process after a user account has been created, in accordance with embodiments of the present disclosure. Portions of the sequence may be respectively performed by the analyte sensor application 121 and the support modules 161 executing on the display device 150 of FIG. IB, and the CAMS 510 of FIG. 5.Dexcom Ref. No.: 0989-PCT01Sequence diagram 1000 may be performed after a trust user flag has been set or before a trusted user flag has been set. The messages exchanged between the display device 150 and the CAMS 510 may be encrypted.

[0220] The sequence block 1010 depicts the interactions between the analyte sensor application 121, the GUI 124, the support modules 161, and the CAMS 510.

[0221] The user selects the icon representing the analyte sensor application 121 depicted by the GUI 124 to launch the analyte sensor application 121, which causes the processor 126 to execute the analyte sensor application 121. The analyte sensor application 121 replaces the application selection interface provided by the OS 162 with a custom interface for the analyte sensor application 121, which is presented by the GUI 124. The analyte sensor application 121 then requests that the user grant permission to determine the geographic location of the display device 150. In some embodiments, the request for permission to determine the geographic location of the display device may skipped if the user has granted analyte sensor application 121 permission to access geographic location information (e.g., when the analyte sensor application 121 is in use).

[0222] After the user grants permission to determine the geographic location of the display device 150, the analyte sensor application 121 calls the OS function to access the geographic location of the display device 150, as described above with respect to sequence block 910. If the user does not grant permission to determine the geographic location of the display device 150, the analyte sensor application 121 may wait for permission to be granted or simply cease execution.

[0223] After the geographic location of the display device 150 has been determined, the analyte sensor application 121 requests that the user provide a set of credentials for login (as described above), and the analyte sensor application 121 sends a login request including the set of credentials (e.g., username or login and password) to the CAMS 510 over the network 190. The CAMS 510 accesses a user account database stored in memory, verifies the set of credentials in the login request against the account database, and accesses the user account that matches the set of credentials. Upon the matching of credentials, the CAMS 510 then sends a login successful notification to the analyte sensor application 121.

[0224] In some embodiments, the user account associated with the user may not include a trusted user flag because the account was not created according to the process depicted in FIG. 9 (e.g., the account was created prior to functionality for setting the trusted user flag, theDexcom Ref. No.: 0989-PCT01 trusted user flag could not be set, etc.). In this situation, the CAMS 510 creates a trusted user flag, sets the trusted user flag to “not trusted,” and stores the trusted user flag in the user account associated with the user. Such user accounts may be referred to as legacy or pre-existing user accounts.

[0225] If the set of credentials does not match a user account, the CAMS 510 then sends a login unsuccessful notification to the analyte sensor application 121, which may prompt the user to re-enter their set of credentials.

[0226] In response to receiving the successful login notification, the analyte sensor application 121 instructs the support modules 161 to perform authentication of the user. In certain embodiments, the analyte sensor application 121 first instructs the support modules 161 to send a location information request to the CAMS 510 that includes a request for a token, including the trusted user flag and the COR, for the user (such as a JWT). In response, the CAMS 510 sends a request token result that indicates whether the request for the token is approved or disapproved. If the request token result indicates that the token request has been disapproved, the support modules 161 send a notification to the analyte sensor application 121 to cease execution.

[0227] The sequence block 1020 depicts the next interactions between the analyte sensor application 121, the support modules 161, the memory 127, and the CAMS 510 after the request token result indicates that the token request has been approved and the authentication continues.

[0228] The CAMS 510 sends the token to the support modules 161, which saves the token in the memory 127 (e.g., in a local database, for example, associated with analyte sensor application 121). The token includes, among other things, the trusted user flag and the COR from the user account associated with the user. Alternatively, the support modules 161 may simply save the trusted user flag to the memory 127, as depicted by sequence block 1022.

[0229] The support modules 161 then send a perform authentication result notification to the analyte sensor application 121 to indicate that the support modules 161 have stored the trusted user flag in the memory 127.

[0230] In response to receiving the perform authentication result notification, the analyte sensor application 121 instructs the support modules 161 to perform a GFC check using the location determined in the sequence block 1010. The support modules 161 may convert or map the geographic location of the display device 150 to a standard country code, such as an ISODexcom Ref. No.: 0989-PCT013166-1 two-letter country code (as discussed above), and then read the trusted user flag stored in the memory 127.

[0231] The sequence block 1024 depicts the next interactions between the analyte sensor application 121, the support modules 161, and the memory 127 after the trusted user flag has been read from the memory 127 (and the geographic location has been determined).

[0232] When the trusted user flag is set to “trusted,” the support modules 161 send a perform GFC check result 1025 that indicates the GFC check was successful (e.g., a value of “true”). In other words, when the trusted user flag is set to “trusted,” the GFC check that is performed in sequence block 1024 is bypassed or skipped (e.g., or the result of the GFC check ignored), and one or more features of the analyte monitoring application 121 are executed without performing location verification. For example, analyte sensor application 121 may display a GUI 124 for setting up an analyte sensor or continuing a sensor session.

[0233] When the trusted user flag is set to “not trusted,” the sequence block 1026 depicts the next interactions between the analyte sensor application 121, the support modules 161, and the memory 127 after the trusted user flag has been read from the memory 127.

[0234] When the geographic location matches the COR provided by the token, the support modules 161 set the trusted user flag stored in the memory 127 to “trusted,” and sends a perform GFC check result 1025 that indicates the GFC check was successful (e.g., a value of “true”).

[0235] When the geographic location does not match the COR provided by the token, the support modules 161 set the trusted user flag stored in the memory 127 to “not trusted,” and sends a perform GFC check result 1025 that indicates the GFC check was not successful (e.g., a value of “false”). In certain embodiments, the support modules 161 may then determine whether other indicators of trust are present, such as EGV values stored in the memory 123 and / or the memory 127, as discussed below with respect to FIG. 11.

[0236] The sequence block 1030 depicts the next interactions between the analyte sensor application 121, the support modules 161, and the CAMS 510 after the trusted user flag has been set to “trusted” in sequence block 1026 and saved to the memory 127.

[0237] The analyte sensor application 121 instructs the support modules 161 to perform an update to the trusted user flag stored in the user account associated with the user in the CAMS 510. The updating of the trusted user flag may be performed based on a GFC, e.g., as described with respect to sequence block 1024 (GFC check), or an analyte value check, e.g., as described with respect to sequence block 1112 depicted in FIG. 11 (EGV check or GFC check). TheDexcom Ref. No.: 0989-PCT01 support modules 161 then update the trusted user flag, as depicted in sequence block 1032, which sends the trusted user flag the CAMS 510 over the network 190. The CAMS 510 then stores the trusted user flag in the user account associated with the user in memory (e.g., memory 123, memory 127, etc.), and returns an update trusted user flag result indicating success to the support modules 161 over the network 190. The support modules 161 then return a perform update result to the analyte sensor application 121 indicating success.

[0238] FIG. 11 depicts a sequence diagram 1100 illustrating operations for authenticating a user of an analyte sensor application 121 after installation (e.g., a new installation) or re- installation on a display device 150, in accordance with embodiments of the present disclosure. Portions of the sequence may be respectively performed by the analyte sensor application 121 and the support modules 161 executing on the display device 150 of FIG. IB, and the CAMS 510 of FIG. 5. In some embodiments, a re-installation may be treated as a new installation (e.g., based on whether prior installation data remains in memory or storage). The messages exchanged between the display device 150 and the CAMS 510 may be encrypted.

[0239] After installation of the analyte sensor application 121 on the display device 150 and prior to entering the sequence block 1110, certain interactions depicted in the sequence block 1010 are performed, including launching the analyte sensor application 121, requesting and granting permission to determine the geographic location of the display device 150, accessing the geographic location of the display device 150, sending a login request including the user’s set of credentials to the CAMS 510, and receiving a login successful notification from the CAMS 510.

[0240] The sequence block 1110 depicts the interactions between the analyte sensor application 121, the support modules 161, and the CAMS 510 after the user has successfully logged in. Sequence block 1110 depicts a new installation of the analyte sensor application 121.

[0241] In response to receiving the successful login notification, the analyte sensor application 121 instructs the support modules 161 to perform authentication of the user. In certain embodiments, the analyte sensor application 121 first instructs the support modules 161 to send a location information request to the CAMS 510 that includes a request for a token, including the trusted user flag and the COR, for the user (such as a JWT). In response, the CAMS 510 sends a request token result that indicates whether the request for the token is approved or disapproved. If the request token result indicates that the token request has been disapproved,Dexcom Ref. No.: 0989-PCT01 the support modules 161 send a notification to the analyte sensor application 121 to cease execution.

[0242] After the request for the token is approved, the CAMS 510 sends the token to the support modules 161, which saves the token in the memory 127 (e.g., in a local database, for example, associated with analyte sensor application 121). The token includes, among other things, the trusted user flag and the COR from the user account associated with the user. After the token is received, the support modules 161 send the analyte sensor application 121 a perform authentication result.

[0243] When the trusted user flag is set to “trusted,” the perform authentication result includes a notification to the analyte sensor application 121 to proceed with execution. In other words, when the trusted user flag is set to “trusted,” the GFC check that is performed in sequence block 1112 is bypassed or skipped (e.g., or the result of the GFC check ignored), and one or more features of the analyte monitoring application 121 are executed without performing location verification. For example, analyte sensor application 121 may display a GUI 124 for setting up an analyte sensor or continuing a sensor session. When the trusted user flag is set to “not trusted,” the perform authentication result includes a notification to the analyte sensor application 121 to determine whether the user is a trusted user.

[0244] The sequence block 1112 depicts the interactions between the analyte sensor application 121, the support modules 161, and the CAMS 510 when the trusted user flag is set to “not trusted.” In some embodiments, portions of sequence block 1112 may be performed to set the trusted user flag to “trusted.”

[0245] The analyte sensor application 121 first instructs the support modules 161 to perform an EGV check. The support modules 161 then check the memory 123 and / or the memory 127 to determine whether one or more EGVs are stored therein, which indicates that the user has previously logged in and stored measured analyte data from the user’s analyte sensor system (e.g., SS 8). In some embodiments, the support modules 161 may send a request to the CAMS 510 to determine whether one or more EGVs are stored in memory, which also indicates that the user has previously logged in and stored measured analyte data from the user’s analyte sensor system (e.g., SS 8). In some embodiments, CAM 510 may store an indicator of whether an analyte value (e.g., EGV, raw analyte value, etc.) has been stored in a server or cloud database (e.g., separate from CAMS 510).Dexcom Ref. No.: 0989-PCT01

[0246] When the support modules 161 determine that one or more EGVs are stored in the memory 123 and / or the memory 127 (or the memory of the CAMS 510), the support modules 161 set the trusted user flag stored in the memory 127 to “trusted,” and send a perform EGV check result to the analyte sensor application 121 that indicates that the user is a trusted user and to proceed with execution (e.g., a value of “true”). The analyte sensor application 121 may then a signal or an instruction to the support modules 161 to perform an update to set the trusted user flag to “trusted” in the user account stored in the memory of the CAMS 510, as depicted in more detail in the sequence block 1030.

[0247] In response to receiving the perform EGV check result that indicates no EGVs were discovered (e.g., a value of “false”), the analyte sensor application 121 may instruct the support modules 161 to perform a GFC check using the location determined earlier and the COR from the token.

[0248] When the geographic location matches the COR provided by the token, the support modules 161 set the trusted user flag stored in the memory 127 to “trusted,” and send a perform GFC check result to the analyte sensor application 121 that indicates that the GFC check was successful (e.g., a value of “true”). In some embodiments, the trusted user flag being set to trusted results in the GFC check being bypassed or skipped while an indication of the GFC check being successful is sent. The analyte sensor application 121 may then instruct the support modules 161 to perform an update to set the trusted user flag to “trusted” in the user account stored in the memory of the CAMS 510, as depicted in more detail in the sequence block 1030.

[0249] When the geographic location does not match the COR provided by the token, the support modules 161 send a perform GFC check result to the analyte sensor application 121 that indicates the GFC check was not successful and not to proceed with execution (e.g., a value of “false”).

[0250] FIG. 12 depicts a flow diagram 1200 describing certain functionality related to authenticating a user of an analyte sensor application 121, in accordance with embodiments of the present disclosure.

[0251] At block 1210, the display device 150 sends a login request for a user to the CAMS 510 over the network 190, as described above with respect to FIGS. 9-11. The login request includes a username and a password.

[0252] At block 1220, in response to a successful login, the display device 150 sends a request for location information associated with the user to the CAMS 510 over the network 190, asDexcom Ref. No.: 0989-PCT01 described above with respect to FIG. 9. The location information includes a trusted user flag and a COR.

[0253] At block 1230, in response to the trusted user flag indicating that the user is trusted, the display device 150 executes one or more features of the analyte monitoring application 121, as described above with respect to FIG. 9. In certain embodiments, at least one of the features is a regulated feature (e.g., a feature of a medical device that is regulated by a governmental regulatory agency, such as the U.S. Food and Drug Administration).

[0254] Example Clauses

[0255] Implementation examples are described in the following numbered clauses:

[0256] Clause 1: A system, comprising: one or more memories comprising executable instructions and data; and one or more processors configured to execute the executable instructions to cause the one or more processors to: send a login request for a user to a server over a network, the login request comprising a username and a password; in response to a successful login, send a request for location information associated with the user to the server over the network, the location information comprising a trusted user flag and a country of residence (COR); and in response to the trusted user flag indicating that the user is trusted, execute one or more features of an application, wherein at least one of the features is associated with an analyte value.

[0257] Clause 2: The system according to Clause 1, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is trusted, bypass location verification.

[0258] Clause 3: The system according to Clause 1 or 2, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is not trusted, perform location verification comprising: determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, executing one or more features of the application.

[0259] Clause 4: The system according to Clause 3, wherein the one or more processors are further configured to: in response to the geographic location not matching the COR: determine whether one or more (EGVs) are stored in one or more memories of the system; and in response to successful determination that one or more EGVs are stored in the one or more memories, executing one or more features of the application.Dexcom Ref. No.: 0989-PCT01

[0260] Clause 5: The system according to Clause 1 or 2, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is not trusted: determine whether one or more EGVs are stored in the one or more memories; and in response to successful determination that one or more EGVs are stored in the one or more memories, executing one or more features of the application.

[0261] Clause 6: The system according to Clause 5, wherein the one or more processors are further configured to: in response to one or more EGVs not being stored in the one or more memories, perform location verification comprising: determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, executing one or more features of the application.

[0262] Clause 7: The system according to Clause 1 or 2, wherein the one or more processors are further configured to: in response to a user account creation request, send the username, the password, and the COR to the server over the network; send an initial login request for the user to the server over the network, the initial login request comprising the username and the password; in response to a successful initial login, send a request for location information associated with the user to the server over the network, the location information comprising the trusted user flag and the COR; in response to the trusted user flag indicating that the user is not trusted, determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, execute one or more features of the application.

[0263] Clause 8: The system according to Clause 7, wherein the one or more processors are further configured to: in response to unsuccessful determination that the geographic location matches the COR, cease execution of the application.

[0264] Clause 9: The system of Clause 7, wherein the one or more processors are further configured to: in response to the user account creation request, receive the username, the password, and a selection of the COR as input from the user; determine a geographic location of the system; and in response to the geographic location not matching the COR, display a notification to the user indicating that an improper COR has been selected.

[0265] Clause 10: The system of Clause 7, wherein the one or more processors are further configured to: receive, from a configuration server over the network, a user configuration for the application based on the COR.Dexcom Ref. No.: 0989-PCT01

[0266] Clause 11: The system of Clause 1 or 2, wherein the one or more processors are further configured to: after installation of the application, send a request for the location information associated with the user to the server over the network; and in response to the trusted user flag indicating that the user is trusted, proceed with execution of the application.

[0267] Clause 12: The system of Clause 11, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is not trusted: determine whether one or more EGVs are stored in the one or more memories; and in response to successful determination that one or more EGVs are stored in the one or more memories, execute one or more features of the application.

[0268] Clause 13: The system of Clause 12, wherein the one or more processors are further configured to: in response to one or more EGVs not being stored in the one or more memories, perform location verification comprising: determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, execute one or more features of the application.

[0269] Clause 14: The system of Clause 1 or 2, wherein: the application is an analyte monitoring application; and at least one of the features is a regulated feature.

[0270] Clause 15: A method, comprising: sending a login request for a user to a server over a network, the login request comprising a username and a password; in response to a successful login, sending a request for location information associated with the user to the server over the network, the location information comprising a trusted user flag and a country of residence (COR); and in response to the trusted user flag indicating that the user is trusted, executing one or more features of an application.

[0271] Clause 16: A system, comprising: a server coupled to a network, the server comprising one or more memories and one or more processors configured to: in response to receiving a login request for a user over the network, login the user based on a user account associated with the user, and send a successful login response over the network, the user account including a username, a password, a country of residence (COR), and a trusted user flag; and in response to receiving a request for location information associated with the user over the network, access the user account associated with the user, and send the location information over the network, the location information comprising the trusted user flag and the COR; and a display device coupled to the network, the display device comprising one or more memories and one or more processors configured to: send the login request for the user to the server over the network, theDexcom Ref. No.: 0989-PCT01 login request comprising the username and the password; in response to a successful login, send the request for location information associated with the user to the server over the network; and in response to the trusted user flag indicating that the user is trusted, execute one or more features of an application, wherein at least one of the features is associated with an analyte value.

[0272] Clause 16: A system, comprising: a server coupled to a network, the server comprising one or more memories and one or more processors configured to: in response to receiving a login request for a user from a display device over the network, login the user based on a user account associated with the user, and send a successful login response to the display device over the network, the user account including a username, a password, a country of residence (COR), and a trusted user flag; and in response to receiving a request for location information associated with the user from the display device over the network, access the user account associated with the user, and send the location information to the display device over the network, the location information comprising the trusted user flag and the COR.Additional Considerations

[0273] In this document, the terms “computer program medium” and “computer usable medium” and “computer readable medium”, as well as variations thereof, are used to generally refer to transitory or non-transitory media. These and other various forms of computer program media or computer usable / readable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, may generally be referred to as “computer program code” or a “computer program product” or “instructions” (which may be grouped in the form of computer programs or other groupings). When executed, such instructions may enable a computing module, such as the SS 8, display device 150, circuitry related thereto, and / or a processor thereof or connected thereto to perform features or functions of the present disclosure as discussed herein (for example, in connection with methods described above and / or in the claims), including for example when the same is / are incorporated into a system, apparatus, device and / or the like.

[0274] Various embodiments have been described with reference to specific example features thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the various embodiments as set forth in the appended claims. The specification and figures are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will be appreciated that, for clarity purposes, theDexcom Ref. No.: 0989-PCT01 above description has described embodiments with reference to different functional units. However, it will be apparent that any suitable distribution of functionality between different functional units may be used without detracting from the invention. For example, functionality illustrated to be performed by separate computing devices may be performed by the same computing device. Likewise, functionality illustrated to be performed by a single computing device may be distributed amongst several computing devices. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

[0275] Although described above in terms of various example embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead may be applied, alone or in various combinations, to one or more of the other embodiments of the present application, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus, the breadth and scope of the present application should not be limited by any of the above-described example embodiments.

[0276] Terms and phrases used in the present application, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide illustrative instances of the item in discussion, not an exhaustive or limiting list thereof; the terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like; the term “set” should be read to include one or more objects of the type included in the set; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Similarly, the plural may in some cases be recognized as applicable to the singular and vice versa. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future.

[0277] The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that theDexcom Ref. No.: 0989-PCT01 narrower case is intended or required in instances where such broadening phrases may be absent. The use of the term “module” does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic, circuitry, or other components, may be combined in a single package or separately maintained and may further be distributed in multiple groupings or packages or across multiple locations.

[0278] Additionally, the various embodiments set forth herein are described in terms of example block diagrams, flow charts, and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives may be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration. Moreover, the operations and suboperations of various methods described herein are not necessarily limited to the order described or shown in the figures, and one of skill in the art will appreciate, upon studying the present disclosure, variations of the order of the operations described herein that are within the spirit and scope of the disclosure.

[0279] It will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by execution of computer program instructions. These computer program instructions may be loaded onto a computer or other programmable data processing apparatus (such as a controller, microcontroller, microprocessor or the like) in a sensor electronics system to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create instructions for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks presented herein.Dexcom Ref. No.: 0989-PCT01

[0280] It should be appreciated that all methods and processes disclosed herein may be used in any glucose or other analyte monitoring system, continuous or intermittent. It should further be appreciated that the implementation and / or execution of all methods and processes may be performed by any suitable devices or systems, whether local or remote. Further, any combination of devices or systems may be used to implement the present methods and processes.

[0281] In addition, the operations and sub-operations of methods described herein may be carried out or implemented, in some cases, by one or more of the components, elements, devices, modules, circuitry, processors, etc. of systems, apparatuses, devices, environments, and / or computing modules described herein and referenced in various of figures of the present disclosure, as well as one or more sub- components, elements, devices, modules, processors, circuitry, and the like depicted therein and / or described with respect thereto. In such instances, the description of the methods or aspects thereof may refer to a corresponding component, element, etc., but regardless of whether an explicit reference is made, one of skill in the art will recognize upon studying the present disclosure when the corresponding component, element, etc. may be used. Further, it will be appreciated that such references do not necessarily limit the described methods to the particular component, element, etc. referred to. Thus, it will be appreciated by one of skill in the art that aspects and features described above in connection with (sub-) components, elements, devices, modules, and circuitry, etc., including variations thereof, may be applied to the various operations described in connection with methods described herein, and vice versa, without departing from the scope of the present disclosure.

Claims

Dexcom Ref. No.: 0989-PCT01WHAT IS CLAIMED IS:

1. A system, comprising: one or more memories comprising executable instructions and data; and one or more processors configured to execute the executable instructions to cause the one or more processors to: send a login request for a user to a server over a network, the login request comprising a username and a password; in response to a successful login, send a request for location information associated with the user to the server over the network, the location information comprising a trusted user flag and a country of residence (COR); and in response to the trusted user flag indicating that the user is trusted, execute one or more features of an application, wherein at least one of the features is associated with an analyte value.

2. The system according to claim 1, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is trusted, bypass location verification.

3. The system according to claim 1 or 2, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is not trusted, perform location verification comprising: determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, executing one or more features of the application.

4. The system according to claim 3, wherein the one or more processors are further configured to: in response to the geographic location not matching the COR: determine whether one or more (EGVs) are stored in one or more memories of the system; andDexcom Ref. No.: 0989-PCT01 in response to successful determination that one or more EGVs are stored in the one or more memories, executing one or more features of the application.

5. The system according to claim 1 or 2, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is not trusted: determine whether one or more EGVs are stored in the one or more memories; and in response to successful determination that one or more EGVs are stored in the one or more memories, executing one or more features of the application.

6. The system according to claim 5, wherein the one or more processors are further configured to: in response to one or more EGV s not being stored in the one or more memories, perform location verification comprising: determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, executing one or more features of the application.

7. The system according to claim 1 or 2, wherein the one or more processors are further configured to: in response to a user account creation request, send the username, the password, and the COR to the server over the network; send an initial login request for the user to the server over the network, the initial login request comprising the username and the password; in response to a successful initial login, send a request for location information associated with the user to the server over the network, the location information comprising the trusted user flag and the COR; in response to the trusted user flag indicating that the user is not trusted, determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, execute one or more features of the application.Dexcom Ref. No.: 0989-PCT018. The system according to claim 7, wherein the one or more processors are further configured to: in response to unsuccessful determination that the geographic location matches the COR, cease execution of the application.

9. The system of claim 7, wherein the one or more processors are further configured to: in response to the user account creation request, receive the username, the password, and a selection of the COR as input from the user; determine a geographic location of the system; and in response to the geographic location not matching the COR, display a notification to the user indicating that an improper COR has been selected.

10. The system of claim 7, wherein the one or more processors are further configured to: receive, from a configuration server over the network, a user configuration for the application based on the COR.

11. The system of claim 1 or 2, wherein the one or more processors are further configured to: after installation of the application, send a request for the location information associated with the user to the server over the network; and in response to the trusted user flag indicating that the user is trusted, proceed with execution of the application.

12. The system of claim 11, wherein the one or more processors are further configured to: in response to the trusted user flag indicating that the user is not trusted: determine whether one or more EGVs are stored in the one or more memories; and in response to successful determination that one or more EGVs are stored in the one or more memories, execute one or more features of the application.Dexcom Ref. No.: 0989-PCT0113. The system of claim 12, wherein the one or more processors are further configured to: in response to one or more EGV s not being stored in the one or more memories, perform location verification comprising: determine a geographic location of the system; and in response to successful determination that the geographic location matches the COR, execute one or more features of the application.

14. The system of claim 1 or 2, wherein: the application is an analyte monitoring application; and at least one of the features is a regulated feature.

15. A method, comprising: sending a login request for a user to a server over a network, the login request comprising a username and a password; in response to a successful login, sending a request for location information associated with the user to the server over the network, the location information comprising a trusted user flag and a country of residence (COR); and in response to the trusted user flag indicating that the user is trusted, executing one or more features of an application.

Images