WO2025240359A1

WO2025240359A1 - Techniques for issuing application-centric certificates for an analyte monitoring system

Info

Publication number: WO2025240359A1
Application number: PCT/US2025/028965
Authority: WO
Inventors: Xiaomin Chen
Original assignee: Dexcom Inc
Current assignee: Dexcom Inc
Priority date: 2024-05-13
Filing date: 2025-05-12
Publication date: 2025-11-20
Anticipated expiration: 2026-11-13

Abstract

Aspects of the present disclosure provide techniques for issuing application- centric certificates for a health monitoring application of a display device to allow anonymous users or users managed by a third-party organization to operate an analyte sensor system. An example method includes obtaining a set of credentials for an account provisioned without personal identification information of a user associated with the analyte sensor system, wherein the account is provisioned on an centralized account management services (CAMS) entity associated with a manufacturer of the analyte sensor system, sending, to a trusted identity provider (IdP) entity, the set of credentials for the account, obtaining, from the IdP entity, an access token, sending, to a certificate management system (CMS) entity, the access token and a signed message including a certificate signing request (CSR) and identity information for the health monitoring application, and obtaining the application-centric certificate for the health monitoring application.

Description

TECHNIQUES FOR ISSUING APPLICATION-CENTRIC CERTIFICATES FOR AN ANALYTE MONITORING SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and benefit of U.S. Provisional Patent Application No. 63/646,414, filed May 13, 2024, which is hereby assigned to the assignee hereof and hereby expressly incorporated by reference herein in its entirety as if fully set forth below and for all applicable purposes.

BACKGROUND

[0002] The present application relates generally to medical devices such as analyte sensors, and more particularly to systems, devices, and methods related to secure communications between medical devices and other communication devices in a diabetes management system.

[0003] 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.

[0004] 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.

[0005] 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 blood glucose value is going up (higher) or down (lower), due to limitations of conventional methods.

[0006] 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 software 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.

[0007] Using a wireless connection between a transcutaneous analyte sensor and one or more remote devices based on certain existing wireless communication protocols, however, may expose the sensor and/or the remote devices to safety, integrity, privacy, and availability issues (e.g., sensor and/or remote devices may become unavailable as a result of malicious attacks, etc.). As an example, an attacker may use a malicious device that impersonates the sensor to connect with and send inaccurate data (e.g., inaccurate blood glucose levels) to a user’s display device to cause harm to the user. In another example, an attacker may use a malicious device to impersonate the user’s display device, or the software application, and execute the software application on the user’s display device to gain access to the user’s sensor.

[0008] In such an example, the attacker may receive the user’s sensor data (e.g., blood glucose levels), thereby, violating the patient’s privacy. Also, in such an example, the attacker may transmit data to the sensor that may cause malfunction of the sensor or sensor electronics. For example, a malicious or an impersonated display device may inaccurately calibrate the sensor, thereby causing the sensor to provide inaccurate blood glucose measurements. Further, in the same example, the attacker may disrupt a communication session that the user has already established between the user’s sensor and the user’s own display device that executes a trusted software application. In certain other examples, a user themselves may use an unauthenticated software application, that may be executed on the user’s own display device, to connect with the user’s sensor. In such an example, the unauthenticated software application may not include the necessary safety measures needed to ensure the user’s data security and safety.

[0009] Moreover, guidelines from governing entities (e.g., Federal Drug Administration (FDA)) may require stringent security (e.g., cybersecurity) protocols for medical devices that may require authentication of each of the devices described above, as well as any software application executing thereon, to help eliminate some of the safety, integrity, privacy, and availability issues described above.

[0010] 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.

SUMMARY

[0011] Certain embodiments of the present disclosure provide a method, performed by a display device, for obtaining an application-centric certificate for a health monitoring application of the display device for wireless communication with an analyte sensor system. The method includes sending, to a trusted identity provider (IdP) entity associated with a manufacturer of the analyte sensor system, a set of credentials for an account provisioned without personal identification information of a user associated with the analyte sensor system, wherein: the account is provisioned on a centralized account management services (CAMS) entity that is associated with the manufacturer; and the display device is configured to display analyte data received from the analyte sensor system, obtaining, from the IdP entity in response to sending the set of credentials, an access token, sending, to a certificate management system (CMS) entity, the access token and a signed message requesting an application-centric certificate, wherein the signed message includes a certificate signing request (CSR) and identity information for the health monitoring application of the display device, obtaining, from a certificate authority (CA) entity via the CMS entity in response to the access token and signed message requesting the application-centric certificate, the application-centric certificate for the health monitoring application of the display device, and establishing a wireless connection with the analyte sensor system using the application-centric certificate.

[0012] Certain embodiments of the present disclosure provide a method, performed by a display device, for obtaining an application-centric certificate for a health monitoring application of the display device for wireless communication with an analyte sensor system. The method includes installing and executing the health monitoring application, wherein the health monitoring application is configured to display an analyte value associated with the analyte sensor system, displaying 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 anonymously, receiving, from a user associated with the analyte sensor system, input to establish the wireless connection with the analyte sensor system anonymously based on the option provided by the GUI, sending, to an identity management entity 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 anonymously, a set of credentials for an account provisioned without personal identification information associated with the user, receiving an access token for the health monitoring application in response to sending the set of credentials for the account, sending, to a certificate authority (CA) entity, a message requesting the application-centric certificate for the health monitoring application, wherein the message includes at least the access token for the health monitoring application, receiving the application-centric certificate for the health monitoring application in response to sending the message requesting the application-centric certificate for the health monitoring application, and establishing the wireless connection with the analyte sensor system using the application-centric certificate for the health monitoring application.

[0013] Other aspects provide: an apparatus operable, configured, or otherwise adapted to perform the aforementioned methods as well as those described elsewhere herein; a non-transitory, computer-readable media comprising instructions that, when executed by one or more processors of an apparatus, cause the apparatus to perform the aforementioned methods as well as those described elsewhere herein; a computer program product embodied on a computer-readable storage medium comprising code for performing the aforementioned methods as well as those described elsewhere herein; and an apparatus comprising means for performing the aforementioned methods as well as those described elsewhere herein. By way of example, an apparatus may comprise a processing system, a device with a processing system, or processing systems cooperating over one or more networks.

[0014] The following description and the appended figures set forth certain features for purposes of illustration.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG. 1A illustrates an example diabetes management system, according to some embodiments disclosed herein.

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

[0017] 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.

[0018] 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.

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

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

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

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

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

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

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

[0026] FIG. 7 depicts a method for obtaining an application-centric certificate for a health monitoring application of a display device for wireless communication with an analyte sensor system, according to some embodiments disclosed herein. [0027] FIG. 8 depicts aspects of an example communications device, according to some embodiments disclosed herein.

DETAILED DESCRIPTION

[0028] Aspects of the present disclosure provide techniques, including apparatuses, methods, processing systems, and computer-readable mediums, for issuing applicationcentric certificates for a health monitoring application of a display device to allow anonymous users or users managed by a third-party organization to operate an analyte sensor system associated with a manufacturer.

[0029] For example, in order for the health monitoring application of a display device associated with a user to be able to communicate with an analyte sensor system associated with the user, the display device and analyte sensor system must first perform a pairing process. This pairing process requires the analyte sensor system and display device to perform mutual authentication in which respective certificates, validated by a trusted Certificate Authority (CA), are exchanged between the display device and analyte sensor system. While the certificate for the analyte sensor system is typically issued during a manufacturing process of the analyte sensor system, the certificate for a health monitoring application of the display device may be acquired after installation of the health monitoring application.

[0030] For example, in order to receive the certificate for the health monitoring application of the display device, the user is required to sign into a user account provisioned on a centralized account management system (CAMS) entity associated with the manufacturer of the analyte sensor system. Additionally, in order to provision the user account, the user is required to provide personal identification information, such as an email, a full name, a birthdate, etc. However, there may be scenarios in which providing this personal identification information to provision the user account is undesirable. For example, there may be scenarios in which the user is managed by a third-party organization that is separate from the manufacturer of the analyte sensor system. In other scenarios, the user may be part of a clinical trial in which the user must remain anonymous.

[0031] Accordingly, aspects of the present disclosure describe techniques that enable users to operate the analyte sensor system and health monitoring application without creating a user account with the manufacturer of the analyte sensor system or providing personal identification information. For example, rather than requiring a manufacturerspecific user account to authenticate the user and to obtain a certificate for the health monitoring application, the techniques presented herein may instead involve the use of an account provisioned without personal identification information of the user, such as a client account associated with a third-party organization or partner.

Introduction to Health Management Systems

[0032] 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 SS 8 (hereinafter “SS 8”) that may be communicatively coupled to display devices 110, 120, 130, and 140, and/or server system 134.

[0033] 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., 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.

[0034] In certain embodiments, SS 8 includes a sensor electronics module 12 and an analyte sensor 10 associated with sensor electronics module 12. In certain embodiments, the 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. The 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.

[0035] 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). 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, the sensor electronics module 12 may 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 may 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.

[0036] The 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, 2008/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.

[0037] 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. [0038] 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.

[0039] The plurality of display devices 110, 120, 130, 140 depicted in FIG. 1A may include a custom or proprietary display device, for example, 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, 130, 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.

[0040] 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).

[0041] 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.

[0042] 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 communication 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.

[0043] 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.

[0044] 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.

[0045] Health management system 100 additionally includes server system 134, which in turn includes server 135 that is coupled to storage 136 (e.g., one or more computer storage systems, cloud-based storage systems and/or services, etc.). 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/authenti cation 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 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.

[0046] 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 realtime or sporadically. Further, in certain embodiments, server system 134 may implement cloud computing capabilities for SS 8 and/or display device 150.

[0047] 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 used 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 sensor measurement circuitry 13 may carry out all the functions of the one or more processors 11 and vice versa.

[0048] 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.

[0049] 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 storage 123. Abus (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 wireless 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.

[0050] 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 non-standardized or modified protocols are used, customized circuitries may be used to service such protocols.

[0051] 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, 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.

[0052] 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, 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 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.

[0053] 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. Display 125 presents a GUI associated with operating system 162 and/or analyte sensor application 121. In various embodiments, a user may interact with analyte sensor application 121 via a corresponding GUI 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.

[0054] Storage 123 may be a non-volatile storage for storing software programs, instructions, data, etc. For example, 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, storage 123 may also store user input data and/or other data collected by display device 150 (e.g., input from other users gathered via analyte sensor application 121). 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.

[0055] 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.

[0056] 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 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. For 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.

[0057] In certain embodiments, after downloading the analyte sensor application 121, as one of the initial steps, the user may be directed by analyte 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.

Example Authentication and Pair ins Procedure

[0058] 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.

[0059] 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.

[0060] 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 illustrated 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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 connection 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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 step 224 using the LTK. Display device 150 may similarly encrypt data for transmission to SS 8 using the LTK.

[0071] 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.

[0072] 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 re-establishing 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.

[0073] 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.

Example Secure Data Exchange between the Display Device and Server System

[0074] 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 analyte 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 methods described with respect to FIG. 3, configures the analyte 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 analyte 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 device-centric 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.

[0075] 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.

[0076] 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 other 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.

[0077] 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.

[0078] 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 the analyte sensor application 121 or any other application (not shown) associated with the sensor application. As part of the set-up process, analyte 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.

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

[0080] 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 proof 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).

[0081] In certain embodiments, the cryptographic key exchange algorithm includes a key-agreement 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.

[0082] 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 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, analyte 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.

[0083] Once server system 134 is able to determine that display device 150 knows the shared secret, server system 134 determines that it can trust the 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 of any subsequent data transmitted between server system 134 and display device 150 (e.g., in steps 306-312).

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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 SC As involved. In addition, display device 150’s request at step 310 may include a request for black-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.

[0091] 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 for authentication. It is further contemplated that a partner device may communicate with the server system 134 for authentication.

[0092] 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.

Example Device-centric Authenticating Protocol

[0093] FIG. 4A is a sequence diagram illustrating the 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. [0094] 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.

[0095] 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”).

[0096] 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 the display device 150 may refrain from transmitting such intermediary certificate(s) to SS 8.

[0097] 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’s 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.).

[0098] 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.

[0099] 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 possession of DD-priv, SS 8 may conclude that the transmitting entity of display device 150’s credentials is in fact the display device 150.

[0100] 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 the 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.

[0101] 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.

[0102] 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.

[0103] Moving to FIG. 4B, FIG. 4B illustrates a chain of certificates associated with SS 8. In the example of FIG. 4B, two SC As (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 digital 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

Aspects Related to Issuing Application-Centric Certificates for Anonymous Users

[0108] 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 analyte 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.

[0109] 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 150 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 SS 8.

[0110] 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.

[OHl] 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 its private key, this ensures that only the display device 150 can access the decrypted message, including the analyte data.

[0112] 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 SS 8 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.

[0113] 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 proved. 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.

[0114] As can be seen, the certificate for the health monitoring application depends, in part, on an access token, which may be obtained from Centralized Account Management Services (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 that user account. However, to register an account in CAMS, the user may need to provide personal identification information, such as an email, a full name, a birthdate, etc. As a result, because the user may be required to provide personal identification information in order to obtain the access token that is used to obtain a certificate, this certificate may be considered a user-centric certificate (e.g., a certificate obtained based on personal identification information of a user). [0115] In some cases, requiring a user to provide personal identification information to register a manufacturer-specific user account may be acceptable for users that are managed by the manufacturer of the SS 8 so that the manufacturer can individually identify the user and track the user’s analyte data. However, requiring such a user account and personal identification information may not be possible in other scenarios. One such scenario may involve a third-party partner that manages users via a third-party health monitoring application to which manufacturer of the SS 8 does not have access. Additionally, requiring a manufacturer-specific user account and personal identification information may not be possible for clinical trial scenarios in which, while a health monitoring application associated with the manufacturer of SS 8 may be used with the SS 8, the identities of users included within the clinical trial must remain anonymous.

[0116] Another scenario may involve the use of an open authentication (OAuth) authorization protocol that may allow users to use the health monitoring application associated with the manufacturer of the SS 8 by signing into a third-party account using their credentials from another platform, such as a social media platform including Facebook® and X® and/or another technology platform including Google® and Apple® — without creating a manufacturer-specific user account. Similarly, another scenario may involve the use of an authorization protocol of a trusted third-party organization, such as a trusted university, that may allow users of that trusted third-party organization to use the health monitoring application associated with the manufacturer of the SS 8 by signing into an account associated with the trusted third-party organization without creating a manufacturer-specific user account.

[0117] Accordingly, aspects of the present disclosure describe techniques that may enable users to operate the SS 8 and health monitoring application without creating a manufacturer-specific user account or providing personal identification information. Additionally, these techniques may still comply with the CP described above, allow for unique identification of the associated health monitoring application, and enable anonymous tracking of user data. For example, to satisfy the CP when the SS 8 is to be used by an anonymous user or by a user managed by a third-party, rather than requiring a manufacturer-specific user account and associated personal identification information to obtain an access token (e.g., which, in turn, would be used to obtain a user-certificate for the health monitoring application), an account provisioned without personal identification information of a user associated with the analyte sensor system, such as a client account or partner account for a third-party organization or partner provisioned on behalf of an anonymous user, may be used for authentication to obtain the access token. In other embodiments, as described below, a user may be permitted to login to a user account associated with a third-party organization for authentication and to obtain an access token rather than requiring a manufacturer-specific user account.

[0118] After obtaining the access token, the health monitoring application may generate a signed message containing identification information of the health monitoring application, including an application type, an application version, phone hardware, etc., which may uniquely identify the health monitoring application executing on the display device 150. The health monitoring application may then send the signed message, the access token, and a C SR to a certificate management system (CMS) entity for verification prior to a CA issuing an application-centric certificate. In some embodiments, the application-centric certificate may be a certificate that is issued based on identity information for the health monitoring application rather than being issued based on personal identification information of a user.

[0119] Once the health monitoring application has received the application-centric certificate, the display device 150 and the SS 8 may perform a pairing procedure using the application-centric certificate to establish a wireless connection with each other, which may be used for communicating analyte data of a user of the analyte sensor system. By using the account provisioned without personal identification information of the user or the user account associated with the third-party organization, the user may not be required to provide any of their personal identification information (e.g., to the manufacturer of the SS 8) to use the SS 8, allowing the user to remain substantially anonymous. As noted above, this may be helpful in scenarios in which the user is managed by a third-party organization and/or when the user is part of a clinical trial or otherwise desires to remain anonymous while using the SS 8.

Example Operations of Entities in a Health Management System

[0120] FIG. 5A depicts a sequence diagram including operations 500A between entities in a health management system, such as the health management system 100. As will be described below, operations 500A relate to techniques for issuing an applicationcentric certificate for a health monitoring application of the display device 150 associated with a user that is managed by a third-party organization or otherwise desires to remain anonymous.

[0121] 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 CMS 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 CMS 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-centric certificate for the health monitoring application 506. In some embodiments, the IdP entity 508, the CAMS entity 510, the CMS 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 CMS entity 512, and the CA entity 514 to one or more third parties, not associated with the third-party organization). In some embodiments, the IdP entity 508, the CAMS entity 510, the CMS 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.

[0122] As shown, operations 500A begin at 516 with the user 502 downloading the health monitoring application 506 from the application repository 504 and installing the health monitoring application 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 be a third-party health monitoring application developed by or for a third-party organization that is separate from a manufacturer of the SS 8 and not managed by manufacturer of the SS 8. In such cases, the user 502 may be a user whose analyte data is being managed by the third-party organization and not by the manufacturer 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 manufacturer to directly manage the analyte data of the user 502. However, in some embodiments, the user 502 may be an anonymous user of the health monitoring application 506 that desires to not share personally identifying information (e.g., name, birthdate, address, etc.) with the manufacturer of the SS 8, such as a patient in a clinical trial.

[0123] In a scenario involving the third-party organization managing users through a third-party health monitoring application 506, prior to using the health monitoring application 506, the third-party organization may agree to perform identify proofing on behalf of the manufacturer of the SS 8 for the users that are managed by the third-party organization. Based on this agreement, the manufacturer of the SS 8 may provision a client account for the third-party organization in or on the CAMS entity 510 and may provide a set of account credentials for the client account to the third-party organization. In some embodiments, the third-party organization client account may be provisioned specifically for the third-party health monitoring application 506. In some embodiments, the third-party organization client account may be provisioned without personal identification information associated with the user 502.

[0124] In other words, the third-party organization application account comprises a generalized account for the third-party organization, which is not specific to any one user managed by the third-party organization (e.g., the third-party organization client account is not specific to the user 502). Accordingly, when using the SS 8 with the third-party health monitoring application 506, the user 502 may remain substantially anonymous to the manufacturer of the SS 8 since the user 502 may use the set of credentials for the client account for the third-party organization rather than providing personal identification information to setup and use a manufacturer-specific user account. In other words, from the perspective of the manufacturer of the SS 8, the user 502 is an anonymous user. An anonymous user is a user whose account does not store, and is not provisioned with, any personal identification information of the user. In some embodiments, an anonymous user may include a user that is permitted to login with a user account that is provisioned with a third-party organization for authentication and whose personal identification information is not shared with the manufacturer of the SS 8.

[0125] In some embodiments, the set of credentials for the client account may include, for example, a secret (e.g., a password) and a client ID (e.g., username) for the third-party organization. In some embodiments, the third-party organization may develop the third-party health monitoring application 506 using a software development kit (SDK) of the manufacturer with use of one or more application programing interfaces (APIs) for accessing the SS 8. In some embodiments, the third-party organization may embed the account credentials for the third-party application account within the third-party health monitoring application 506 for use when pairing the display device 150 corresponding to the user 502 to the SS 8 of the user 502.

[0126] In some embodiments, the health monitoring application 506 may provide the user 502 with a selectable option to remain anonymous on a graphic user interface (GUI) of the health monitoring application 506. For example, when the health monitoring application 506 is executed, the display device 150 may be configured to display the GUI of the health monitoring application, which provides an option to establish a wireless connection with the SS 8 anonymously (e.g., without providing personal identification information of the user 502 to the manufacturer of the SS 8). In some embodiments, the display device 150, via the health monitoring application 506, may receive input to establish the wireless connection with the SS 8 based on the option provided by the GUI. In some embodiments, when the input is received, the health monitoring application 506 may be configured to use a set of credentials embedded within the health monitoring application 506 to obtain an access token for the health monitoring application 506, as explained in greater detail below. In some embodiments, the set of credentials embedded within the health monitoring application 506 may comprise the set of credentials associated with a third-party organization client account or may include a set of credentials for an anonymous user account associated with the manufacturer of the SS 8. In some embodiments, the anonymous user account may be provisioned, by the manufacturer of the SS 8, for an anonymous user that is directly managed by the manufacturer without personal identification information of this anonymous user.

[0127] 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).

[0128] In some embodiments, as shown at 520, prior to performing the mutual authentication process, the user 502 may optionally be prompted to perform a challengeresponse 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-centric 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.

[0129] In some embodiments, whether the user 502 is required to perform the challenge-response test may depend on an authentication assurance level with the user 502. For example, if the user 502 is managed by the third-party organization and is required to perform some sort of digital authentication (e.g., user login to a third-party organization account management system, entering a one-time password, performing two-factor authentication, etc.) for the third-party health monitoring application 506 prior to pairing the third-party health monitoring application 506 with the SS 8, this may provide a sufficient authentication assurance level or security level to reduce the possibility that access tokens and application-centric certificates are automatically generated on a mass scale by non-human entities. In this case, the third-party logon may be sufficient and the user 502 may not be required to perform the challenge-response test.

[0130] 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-centric 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 challenge-response test to ensure that the entity (e.g., the user 502) that is requesting the access token and application-centric certificate is a human rather than a non-human entity.

[0131] 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 the set of credentials for the client account of the third-party organization or an anonymous user account associated with the manufacturer of the SS 8. By using the set of credentials for the client account of the third-party organization or the anonymous user account associated with the manufacturer of the SS 8, the user 502 may not be required to provide any personal identification information (PII) of the user 502 or protected health information (PHI) of the user 502, allowing the user 502 to remain anonymous from the perspective of the manufacturer of the SS 8. The personal identification information may include 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. The 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.

[0132] 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 set of credentials match an account provisioned in the CAMS entity 510 (e.g., client account of the third-party organization or the anonymous user account associated with the manufacturer of the SS 8), the CAMS entity 510 sends a response message to the IdP entity 508 at 528, indicating that the set of credentials have been authenticated.

[0133] 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., Hashbased Message Authentication Code using Secure Hash Algorithm 256-bit (HS256)). The payload encapsulates claims, which may indicate information such as the issuer of the token, identity information indicating the subject of the token (e.g., a client ID associated with the third-party organization client account or a client ID of the anonymous user account), an expiration time of the token, audience of the token (e.g., identifies recipients for whom the token is intended), and a scope of the access token (e.g., what it may be used for, such as obtaining an application-centric certificate for the health monitoring application 506). It should be appreciated that the claims of the payload are pieces of information asserted about a subject. In some embodiments, the claims may include registered claims, which may include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before time), jat (issued at time), and jti (JWT ID). In some embodiments, a claim may appear as a name/value pair. For example, the name claim ("name": "John Doe") asserts that the name of a user or a partner application is authenticated, and the aud claim ("aud": "DDLM") specifies the recipient for which the JWT is intended. Finally, the signature may be generated by encoding a concatenation of the header and payload and then applying a digital signature algorithm (e.g., HS256) using a secret key.

[0134] 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 identity information of the subject of the access token, such as the client ID associated with the third-party organization client account or the client ID associated with the anonymous user account.

[0135] 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-centric certificate be issued for the health monitoring application 506 for use when pairing with the SS 8.

[0136] 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, in 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 (e.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 may be calculated as: Q =d*G, where Q is the resulting public key, d is the private key, and G is the generator point.

[0137] 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.

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

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

[0140] As shown at 542, in response to the CSR, the CA entity 514 may issue the application-centric certificate for the health monitoring application 506. The applicationcentric 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.

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

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

[0143] In some embodiments, the techniques described above may be performed on behalf of the user 502 by another individual. For example, in a clinical trial scenario, clinical trial staff may prepare the display device 150 ahead of time for use by the user 502. For example, in some embodiments, as part of setting up the clinical trial, the clinical trial staff may download and install the health monitoring application 506 on the display device 150 at 516. Thereafter, the clinical trial staff may execute the health monitoring application at 518, causing the set of credentials to be sent to the IdP entity 508 at 524. Finally, after the application-centric certificate for the health monitoring application 506 has been returned to the health monitoring application 506, the clinical trial staff may provide the display device 150, including the health monitoring application 506, to the user 502 for use with the SS 8.

[0144] 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-centric 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 a public 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.

[0145] 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 506 on the display device 150, 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.

[0146] FIG. 5B illustrates a sequence diagram depicting operations 500B between components of a health management system, such as health management system 100. Operations 500B include many of the same operations as operations 500A described with reference to FIG. 5A, but pertain to techniques for issuing an application-centric certificate for a health monitoring application of the display device 150 associated with a user when an OAuth authorization protocol (e.g., a social media platform login (Facebook®, X®), email login (Google®), or cloud storage platform login (Apple®)) or another third-party authorization protocol is used to allow users to use the health monitoring application without creating a manufacturer-specific user account.

[0147] As shown, operations 500B begin at 560 with the user 502 downloading the health monitoring application 506 from the application repository 504 and installing the health monitoring application 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 be a third-party health monitoring application developed by or for a third-party organization that is separate from a manufacturer of the SS 8. In some embodiments, when the health monitoring application 506 is a third-party health monitoring application, the health monitoring application 506 may allow a user to login to a user-specific account associated with the third-party organization using a set of credentials.

[0148] In some embodiments, the health monitoring application 506 may have been developed by or for the manufacturer of the SS 8. In some embodiments, when the health monitoring application 506 is a health monitoring application of the manufacturer of the SS 8 (e.g., developed for or by the manufacturer), the health monitoring application 506 may allow a user to login to a user account associated with a trusted third-party organization, such as a university, or may allow a user to use an OAuth authorization protocol to login to a user account associated with another platform, such as a social media account, an email account, or the like.

[0149] 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 562 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). [0150] For example, as shown at 564, after executing the health monitoring application 506, the health monitoring application 506 may prompt the user 502 to login to a user account of a third-party organization, such as a social media or other platform account associated with the user 502, an email account associated with the user 502, a trusted third-party organization user account associated with the user 502 (e.g., a user account at a trusted university), or the like. In some embodiments, the user 502 may be prompted to login to the user account of the third-party organization using a particular authentication protocol, such as an OAuth authentication protocol or an authentication protocol associated with a trusted third-party organization (e.g., a university, etc.).

[0151] In some embodiments, because user account is associated with a third-party organization and not with the manufacturer of the SS 8, when logging into the third-party user account, the user 502 may not be required to provide any personal identification information (PII) of the user 502 or protected health information (PHI) of the user 502 to the manufacturer of the SS 8, allowing the user 502 to remain anonymous from the perspective of the manufacturer of the SS 8.

[0152] As shown at 566, when prompted to login, the user 502 may provide, to the health monitoring application 506, a set of credentials (e.g., account credentials, such as a username and password) for the user account of the third-party organization. Thereafter, at 568, the health monitoring application 506 may proceed with sending a message (e.g., a “sign-in” message) to the IdP entity 508, including the set of credentials for the user account of the third-party organization.

[0153] In some embodiments, the IdP entity 508 may recognize that the set of credentials provided within the message from the health monitoring application 506 do not belong to an account associated with the manufacturer of the SS 8, such as client account provisioned in the CAMS entity 510 described with respect to FIG. 5A. For example, in some embodiments, based on the set of credentials or other user account identification information included within the message (e.g., email domain information, an organization identifier, a client ID, etc.), the IdP entity 508 may determine that the set of credentials is associated with a user account of the third-party organization.

[0154] As shown at 568, in response to the determination that the set of credentials is associated with a user account of a third-party organization, the IdP entity 508 may forward the set of credentials to a third-party IdP/identity management (IdM) entity 511 of the third-party organization for authenticating the set of credentials at 570. In some embodiments, the third-party IdP/IdM entity 511 may include a federated IdP and a third- party IdM. In some embodiments, the third-party IdP/IdM entity 511 may include a social media IdP or other platform IdP.

[0155] In some embodiments, if the set of credentials match a user account associated with the third-party IdP/IdM entity 511 of the third-party organization, the third-party IdP/IdM entity 511 sends a response message to the IdP entity 508 at 572, indicating that the set of credentials have been authenticated. In some embodiments, the response message may also include identity information indicating the user account of the third-party organization.

[0156] Thereafter, at 530, in response to receiving the response message from the third-party IdP/IdM entity 511 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 indicate information such as the issuer of the token, identity information indicating the subject of the token (e.g., a client IF of the user account of the third-party organization or another client ID that identifies the third-party organization), an expiration time of the token, audience of the token (e.g., identifies recipients for whom the token is intended), and a scope of the access token (e.g., what it may be used for, such as obtaining an applicationcentric certificate for the health monitoring application 506).

[0157] Thereafter, as shown, the remaining operations of FIG. 5B (e.g., operations 530 through 558) may be the same as those previously described with respect to FIG. 5A. Accordingly, after the IdP entity 508 generates the access token for the health monitoring application 506, operations 500B continue with operations for issuing an applicationcentric certificate for the health monitoring application 506, establishing a wireless connection between the health monitoring application 506 and the SS 8 based on the application-centric certificate, and communicating analyte data between the health monitoring application 506 and the SS 8. Additional details regarding the remaining operations shown in FIG. 5B are described above with respect to operations 530 through 558 of FIG. 5 A.

[0158] 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 FIGS. 5A and 5B

Example Operations of a Display Device

[0159] FIG. 6 shows an example of a method 600 for obtaining an applicationcentric 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, 5A, and 5B. 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 FIGS. 5A and 5B. 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.

[0160] As shown, method 600 begins at 602 with the display device obtaining a set of credentials for an account provisioned account provisioned without personal identification information of a user associated with the analyte sensor system. In some embodiments, the account is provisioned on a centralized account management services (CAMS) entity (e.g., CAMS entity 510 of FIGS. 5A and 5B) 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.

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

[0162] At 606, the display device obtains, from the IdP entity in response to sending the set of credentials, an access token. [0163] At 608, the display device sends, to a certificate management system (CMS) entity (e.g., CMS entity 512 of FIGS. 5A and 5B), the access token and a signed message requesting an application-centric certificate, wherein the signed message includes a certificate signing request (CSR) and identity information for the health monitoring application of the display device.

[0164] At 610, the display device obtains, from a certificate authority (CA) entity (e.g., CA entity 514 of FIGS. 5A and 5B) via the CMS entity in response to the access token and the signed message requesting the application-centric certificate, the application-centric certificate for the health monitoring application of the display device.

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

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

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

[0168] In some embodiments, the user is managed by a third-party organization separate from the manufacturer of the analyte sensor system. In some embodiments, the account comprises a client account for the third-party organization, wherein the client account is not specific to the user.

[0169] 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 applicationcentric certificate for the health monitoring application. In some embodiments, the application-centric certificate includes the public key associated with the health monitoring application and is signed based on a private key of the CA entity.

[0170] In some embodiments, the identity information for the health monitoring application includes at least one of an application type of the health monitoring application, a version number of the health monitoring application, or an indication of a hardware type of the display device. [0171] In some embodiments, the signed message and the access token are not associated with identity information of a user of the health monitoring application. For example, in some embodiments, the signed message and the access token lack the personal identification information of the user.

[0172] In some embodiments, method 600 further includes displaying a challengeresponse 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.

[0173] In some embodiments, the application-centric 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-centric certificate. In some embodiments, performing the pairing procedure with the analyte sensor system may include sending the application-centric certificate for the health monitoring application to the analyte sensor 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.

[0174] 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.

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

[0176] FIG. 7 shows an example of a method 700 for obtaining an applicationcentric 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, 5A, and 5B. 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 FIGS. 5A and 5B. 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, 5 A, and 5B.

[0177] 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.

[0178] 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 anonymously.

[0179] 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 anonymously based on the option provided by the GUI.

[0180] At 708, the display device sends, to an identity management entity (e.g., IdP entity 508 described with respect to FIGS. 5A and 5B) 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 anonymously, a set of credentials for an account provisioned without personal identification information associated with the user.

[0181] 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.

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

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

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

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

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

[0187] In some embodiments, the account comprises a client account for a third- party organization. In some embodiments, the client account is not specific to the user.

[0188] In some embodiments, the anonymous user account comprises an account for an anonymous user of the analyte sensor system provisioned without personal identification information of the anonymous user.

[0189] 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.

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

[0191] In some embodiments, the message includes a certificate signing request (CSR) requesting the application-centric 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-centric certificate for the health monitoring application. [0192] In some embodiments, the application-centric certificate includes the public key associated with the health monitoring application and is signed based on a private key of the CA entity.

[0193] In some embodiments, the message further includes identity information for the health monitoring application. In some embodiments, the identity information for the health monitoring application includes at least one of an application type of the health monitoring application, a version number of the health monitoring application, or an indication of a hardware type of the display device.

[0194] In some embodiments, the message is not associated with identity information of a user of the health monitoring application.

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

[0196] 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-centric certificate.

[0197] In some embodiments, performing the pairing procedure with the analyte sensor system comprises sending the application-centric 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.

[0198] 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.

[0199] In some embodiments, the set of credentials are embedded in the health monitoring application. Example Communications Device

[0200] 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, 5A, 5B, and 6.

[0201] 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.

[0202] 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/or 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.

[0203] 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.

[0204] 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 circuitry 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.

[0205] 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.

Example Clauses

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

[0207] Clause 1 : A method, performed by a display device, for obtaining an application-centric certificate for a health monitoring application of the display device for wireless communication with an analyte sensor system, comprising: sending, to a trusted identity provider (IdP) entity associated with a manufacturer of the analyte sensor system, a set of credentials for an account provisioned without personal identification information of a user associated with the analyte sensor system, wherein: the account is provisioned on a centralized account management services (CAMS) entity that is associated with the manufacturer; and the display device is configured to display analyte data received from the analyte sensor system; obtaining, from the IdP entity in response to sending the set of credentials, an access token; sending, to a certificate management system (CMS) entity, the access token and a signed message requesting an application-centric certificate, wherein the signed message includes a certificate signing request (CSR) and identity information for the health monitoring application of the display device; obtaining, from a certificate authority (CA) entity via the CMS entity in response to the access token and the signed message requesting the application-centric certificate, the application-centric certificate for the health monitoring application of the display device; and establishing a wireless connection with the analyte sensor system using the application-centric certificate.

[0208] Clause 2: The method of Clause 1, wherein the health monitoring application is associated with a user.

[0209] Clause 3: The method of claim 2, wherein: the user is managed by a third- party organization separate from the manufacturer of the analyte sensor system; and the account comprises a client account for the third-party organization, wherein the client account is not specific to the user.

[0210] Clause 4: The method of any one of Clauses 1-3, further comprising 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.

[0211] Clause 5: The method of Clause 4, wherein the signed message is signed using the private key associated with the health monitoring application.

[0212] Clause 6: The method of Clause 5, wherein the CSR includes: the public key associated with the health monitoring application; and a request to issue the applicationcentric certificate for the health monitoring application.

[0213] Clause 7: The method of Clause 6, wherein the application-centric certificate includes the public key associated with the health monitoring application and is signed based on a private key of the CA entity. [0214] Clause 8: The method of any one of Clauses 1-7, wherein the identity information for the health monitoring application includes at least one of an application type of the health monitoring application, a version number of the health monitoring application, or an indication of a hardware type of the display device.

[0215] Clause 9: The method of any one of Clauses 1-8, wherein the signed message and the access token are not associated with identity information of a user of the health monitoring application.

[0216] Clause 10: The method of any one of Clauses 1-9, further comprising: displaying a challenge-response test on a graphic user interface (GUI) of the health monitoring application; and receiving input successfully completing the challengeresponse test, wherein sending the set of credentials to the IdP entity is based on the input successfully completing the challenge-response test.

[0217] Clause 11 : The method of Clause 10, wherein displaying the challengeresponse test is based on an authentication assurance level associated with a user of the analyte sensor system.

[0218] Clause 12: The method of any one of Clauses 1-11, wherein the applicationcentric certificate comprises a public key of the health monitoring application.

[0219] Clause 13: The method of Clause 12, wherein establishing the wireless connection with the analyte sensor system comprises performing a pairing procedure with the analyte sensor system using the application-centric certificate.

[0220] Clause 14: The method of Clause 13, wherein performing the pairing procedure with the analyte sensor system comprises: sending the application-centric certificate for the health monitoring application to the analyte sensor 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.

[0221] Clause 15: The method of Clause 14, further comprising, 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, wherein the encrypted message is encrypted based on the public key of the health monitoring application; and decrypting the encrypted message using a private key of the health monitoring application to obtain the analyte data of the user. [0222] Clause 16: The method of any one of Clauses 1-15, wherein the set of credentials are embedded in the health monitoring application.

[0223] Clause 17: A method, performed by a display device, for obtaining an application-centric certificate for a health monitoring application of a display device for wireless communication with an analyte sensor system, comprising: installing and executing the health monitoring application, wherein the health monitoring application is configured to display an analyte value associated with the analyte sensor system; displaying 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 anonymously; receiving, from a user associated with the analyte sensor system, input to establish the wireless connection with the analyte sensor system anonymously based on the option provided by the GUI; sending, to an identity management entity 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 anonymously, a set of credentials for an account provisioned without personal identification information associated with the user; receiving an access token for the health monitoring application in response to sending the set of credentials for the account; sending, to a certificate authority (CA) entity, a message requesting the application-centric certificate for the health monitoring application, wherein the message includes at least the access token for the health monitoring application; receiving the application-centric certificate for the health monitoring application in response to sending the message requesting the application-centric certificate for the health monitoring application; and establishing the wireless connection with the analyte sensor system using the application-centric certificate for the health monitoring application.

[0224] Clause 18: The method of Clause 17, further comprising: displaying a challenge-response test on the GUI of the health monitoring application; and receiving input successfully completing the challenge-response test, wherein sending the set of credentials to the identity management entity is based on the input successfully completing the challenge-response test.

[0225] Clause 19: The method of Clause 18, wherein displaying the challengeresponse test is based on an authentication assurance level associated with a user of the analyte sensor system. [0226] Clause 20: The method of any one of Clauses 17-19, wherein the account comprises a client account for a third-party organization, wherein the client account is not specific to the user.

[0227] Clause 21 : The method of any one of Clauses 17-20, further comprising 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.

[0228] Clause 22: The method of Clause 21, wherein the message is signed using the private key associated with the health monitoring application.

[0229] Clause 23: The method of Clause 22, wherein: the message includes a certificate signing request (CSR) requesting the application-centric certificate for the health monitoring application; and the CSR includes: the public key associated with the health monitoring application; and a request to issue the application-centric certificate for the health monitoring application.

[0230] Clause 24: The method of Clause 23, wherein the application-centric certificate includes the public key associated with the health monitoring application and is signed based on a private key of the CA entity.

[0231] Clause 25: The method of any one of Clauses 17-24, wherein: the message further includes identity information for the health monitoring application; and the identity information for the health monitoring application includes at least one of an application type of the health monitoring application, a version number of the health monitoring application, or an indication of a hardware type of the display device.

[0232] Clause 26: The method of any one of Clauses 17-25, wherein the message is not associated with identity information of a user of the health monitoring application.

[0233] Clause 27: The method of any one of Clauses 17-26, wherein the applicationcentric certificate comprises a public key of the health monitoring application.

[0234] Clause 28: The method of Clause 27, wherein establishing the wireless connection with the analyte sensor system comprises performing a pairing procedure with the analyte sensor system using the application-centric certificate.

[0235] Clause 29: The method of Clause 28, wherein performing the pairing procedure with the analyte sensor system comprises: sending the application-centric certificate for the health monitoring application to the analyte sensor 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.

[0236] Clause 30: The method of Clause 29, further comprising, 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, wherein the encrypted message is encrypted based on the public key of the health monitoring application; and decrypting the encrypted message using a private key of the health monitoring application to obtain the analyte data of the user.

[0237] Clause 31 : The method of any one of Clauses 17-30, wherein the set of credentials are embedded in the health monitoring application.

[0238] Clause 32: An apparatus, comprising: one or more processors configured to execute instructions stored on one or more memories and to cause the apparatus to perform a method in accordance with any combination of Clauses 1-31.

[0239] Clause 33: An apparatus, comprising means for performing a method in accordance with any combination of Clauses 1-31.

[0240] Clause 34: A non-transitory computer-readable medium comprising executable instructions that, when executed by one or more processors of an apparatus, cause the apparatus to perform a method in accordance with any combination of Clauses 1-31.

[0241] Clause 35: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any combination of Clauses 1-31.

Additional Considerations

[0242] 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.

[0243] 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, the 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.

[0244] 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.

[0245] 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.

[0246] 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 the 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.

[0247] 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 sub-operations 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.

[0248] 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.

[0249] 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.

[0250] 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

1. A method, performed by a display device, for obtaining an application-centric certificate for a health monitoring application of the display device for wireless communication with an analyte sensor system, comprising: sending, to a trusted identity provider (IdP) entity associated with a manufacturer of the analyte sensor system, a set of credentials for an account provisioned without personal identification information of a user associated with the analyte sensor system, wherein: the account is provisioned on a centralized account management services (CAMS) entity that is associated with the manufacturer; and the display device is configured to display analyte data received from the analyte sensor system; obtaining, from the IdP entity in response to sending the set of credentials, an access token; sending, to a certificate management system (CMS) entity, the access token and a signed message requesting an application-centric certificate, wherein the signed message includes a certificate signing request (CSR) and identity information for the health monitoring application of the display device; obtaining, from a certificate authority (CA) entity via the CMS entity in response to the access token and signed message requesting the application-centric certificate, the application-centric certificate for the health monitoring application of the display device; and establishing a wireless connection with the analyte sensor system using the application-centric certificate.

2. The method of claim 1, wherein the health monitoring application is associated with a user.

3. The method of claim 2, wherein the user is managed by a third-party organization separate from the manufacturer of the analyte sensor system.

4. The method of claim 3, wherein: the account comprises a client account for the third-party organization; and the client account is not specific to the user.

5. The method of claim 1, further comprising 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, wherein: the signed message is signed using the private key associated with the health monitoring application; and the CSR includes: the public key associated with the health monitoring application; and a request to issue the application-centric certificate for the health monitoring application.

6. The method of claim 5, wherein the application-centric certificate includes the public key associated with the health monitoring application and is signed based on a private key of the CA entity.

7. The method of claim 1, wherein the identity information for the health monitoring application includes at least one of an application type of the health monitoring application, a version number of the health monitoring application, or an indication of a hardware type of the display device.

8. The method of claim 1, wherein the signed message and the access token are not associated with identity information of a user of the health monitoring application.

9. The method of claim 1, further comprising: displaying a challenge-response test on a graphic user interface (GUI) of the health monitoring application; and 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; and displaying the challenge-response test is based on an authentication assurance level associated with a user of the analyte sensor system.

10. The method of claim 1, wherein: the application-centric certificate comprises a public key of the health monitoring application; and establishing the wireless connection with the analyte sensor system comprises performing a pairing procedure with the analyte sensor system using the applicationcentric certificate.

11. The method of claim 10, wherein performing the pairing procedure with the analyte sensor system comprises: sending the application-centric certificate for the health monitoring application to the analyte sensor 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.

12. The method of claim 11, further comprising, after performing the pairing procedure with the analyte sensor system: receiving an encrypted message from the analyte sensor system including the analyte data of a user of the analyte sensor system, wherein the encrypted message is encrypted based on the public key of the health monitoring application; and decrypting the encrypted message using a private key of the health monitoring application to obtain the analyte data of the user.

13. The method of claim 1, wherein the set of credentials are embedded in the health monitoring application.

14. A method, performed by a display device, for obtaining an application-centric certificate for a health monitoring application of a display device for wireless communication with an analyte sensor system, comprising: installing and executing the health monitoring application, wherein the health monitoring application is configured to display an analyte value associated with the analyte sensor system; displaying 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 anonymously; receiving, from a user associated with the analyte sensor system, input to establish the wireless connection with the analyte sensor system anonymously based on the option provided by the GUI; sending, to an identity management entity 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 anonymously, a set of credentials for an account provisioned without personal identification information associated with the user; receiving an access token for the health monitoring application in response to sending the set of credentials for the account; sending, to a certificate authority (CA) entity, a message requesting the application-centric certificate for the health monitoring application, wherein the message includes at least the access token for the health monitoring application; receiving the application-centric certificate for the health monitoring application in response to sending the message requesting the application-centric certificate for the health monitoring application; and establishing the wireless connection with the analyte sensor system using the application-centric certificate for the health monitoring application.

15. A display device for obtaining an application-centric certificate for a health monitoring application of the display device for wireless communication with an analyte sensor system, comprising: one or more processors configured to execute instructions stored on one or more memories and to cause the display device to: send, to a trusted identity provider (IdP) entity associated with a manufacturer of the analyte sensor system, a set of credentials for an account provisioned without personal identification information of a user associated with the analyte sensor system, wherein: the account is provisioned on a centralized account management services (CAMS) entity that is associated with the manufacturer; and the display device is configured to display analyte data received from the analyte sensor system; obtain, from the IdP entity in response to sending the set of credentials, an access token; send, to a certificate management system (CMS) entity, the access token and a signed message requesting an application-centric certificate, wherein the signed message includes a certificate signing request (CSR) and identity information for the health monitoring application of the display device; obtain, from a certificate authority (CA) entity via the CMS entity in response to the access token and the signed message requesting the applicationcentric certificate, the application-centric certificate for the health monitoring application of the display device; and establish a wireless connection with the analyte sensor system using the application-centric certificate.