Identity tokens for secure connection establishment in a health management system

Abstract

Aspects of the present disclosure provide techniques for using identity tokens to establish a secure wireless connection between a requesting node, such as a health monitoring application, and a target node, such as an analyte sensor system in a health management system. An example method performed by the requesting node includes transmitting an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node, receiving the identity token for the target node based on the identity token request message, wherein the identity token includes, at least, a certificate status associated with the certificate of the target node, and establishing a connection with the target node when the certificate status, included in the identity token, indicates that the certificate of the target node is valid.

Description

DexcomRef. No.: 0932-PCT01IDENTITY TOKENS FOR SECURE CONNECTION ESTABLISHMENT IN A HEALTH MANAGEMENT SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 738,402, filed December 23, 2024, which is assigned to the assignee of the present application and is hereby expressly incorporated by reference in its entirety for all applicable purposes, as if fully set forth herein.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 limitationsP+S Ref. No.: DEXC / 0932PC 1DexcomRef. No.: 0932-PCT01of 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. InP+S Ref. No.: DEXC / 0932PC 2DexcomRef. No.: 0932-PCT01such 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 for communication by an identity verification service (IVS) entity in a health management system. The method includes receiving, from a requesting node in the health management system, an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node, storing event information, associated with the identity token request message, in a database for detecting unauthorized activity associated with at least one of the requesting node or the target node, generating the identity token for the target node based on the identity token request message, wherein the identity token includes, at least, a certificate status associated with the certificate of the target node, and transmitting the identity token for the target node to the requesting node.

[0012] Certain embodiments of the present disclosure provide a method for communication by a requesting node in a health management system. The method includes transmitting an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node, receiving the identity token for the target node based on the identity token request message, wherein the identity token includes, at least, a certificate status associated with the certificate of the target node, andP+S Ref. No.: DEXC / 0932PC 3DexcomRef. No.: 0932-PCT01establishing a connection with the target node when the certificate status, included in the identity token, indicates that the certificate of the target node is valid.

[0013] Certain embodiments of the present disclosure provide a method for communication by a fraud detection service (FDS) entity in a health management system. The method includes receiving event information from an identity verification service (IVS) entity in the health management system, wherein the event information is associated with one or more identity token request messages of a requesting node in the health management system that request at least one identity token be generated for a target node in the health management system, detecting, based on the event information, unauthorized activity associated with at least one of the requesting node or the target node, and sending, based on the detected unauthorized activity, one or more revocation request signals to a device management system (DMS) entity to request that that a certificate of at least one of the requesting node or the target node be revoked.

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

[0015] The following description and the appended figures set forth certain features for purposes of illustration.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0018] FIG. 2 is a sequence diagram illustrating execution of a communicationP+S Ref. No.: DEXC / 0932PC 4DexcomRef. No.: 0932-PCT01procedure between an analyte sensor system and a display device, according to certain embodiments.

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

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

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

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

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

[0024] FIGS. 5A and 5B illustrate a sequence diagram including operations for establishing a connection between a sensor system (SS) and a health monitoring application (HMA), according to some embodiments disclosed herein.

[0025] FIG. 6 illustrates an example structure of a first identity token request message, according to some embodiments disclosed herein.

[0026] FIG. 7 illustrates operations for obtaining a joint identity token for the HMA and the SS, according to some embodiments disclosed herein.

[0027] FIG. 8 illustrates example operations for establishing a wireless connection between the HMA and the SS using identity tokens, according to some embodiments disclosed herein.

[0028] FIG. 9 illustrates example operations for establishing a wireless connection between the HMA and the SS associated with an identity token request timeout, according to some embodiments disclosed herein.

[0029] FIG. 10 illustrates operations that may be used to establish a connection between a proxy device and a receiver device using identity tokens, according to some embodiments disclosed herein.

[0030] FIG. 11 illustrates example operations for establishing a wireless connectionP+S Ref. No.: DEXC / 0932PC 5DexcomRef. No.: 0932-PCT01between a receiver device and an SS, via a proxy device, using identity tokens, according to some embodiments disclosed herein.

[0031] FIGS. 12, 13, 14, 15, and 16 illustrate different manners by which a fraud detection service (FDS) entity may be configured to detect unauthorized or fraudulent activity in a health management system, according to some embodiments disclosed herein.

[0032] FIG. 17 depicts a method for wireless communications.

[0033] FIG. 18 depicts a method for wireless communications.

[0034] FIG. 19 depicts a method for wireless communications.

[0035] FIG. 20 depicts aspects of an example communications device.

[0036] FIG. 21 depicts aspects of an example communications device.

[0037] FIG. 22 depicts aspects of an example communications device.DETAILED DESCRIPTION

[0038] Aspects of the present disclosure provide techniques, including apparatuses, methods, processing systems, and computer-readable mediums, for using identity tokens to establish a secure wireless connection between a requesting node, such as a health monitoring application, and a target node, such as an analyte sensor system, in a health management system. Additionally, aspects of the present disclosure provide techniques that may be used by a fraud detection service (FDS) entity to detect unauthorized or fraudulent activity in the health management system.Introduction to Health Management Systems

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

[0040] 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 implementedP+S Ref. No.: DEXC / 0932PC 6DexcomRef. No.: 0932-PCT01as 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.

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

[0042] 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, sensor electronics module 12 can include one or more potentiostats, a power source for providing power to analyte sensor 10, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to one or more display devices. Electronics can be affixed to a printed circuit board (PCB) within SS 8, or platform or the like, and can take a variety of forms. For example, the electronics can take the form of an integrated circuit (IC), such as an Application-Specific Integrated Circuit (ASIC), a microcontroller, a processor, and / or a state machine.

[0043] 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 forP+S Ref. No.: DEXC / 0932PC 7DexcomRef. No.: 0932-PCT01processing 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.

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

[0045] 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.P+S Ref. No.: DEXC / 0932PC 8DexcomRef. No.: 0932-PCT01

[0046] The plurality of display devices 110, 120, 130, 140 depicted in FIG. 1A may include a custom or proprietary display device, for example, analyte display device 110, especially designed for displaying certain types of displayable sensor information associated with analyte data received from sensor electronics module 12 (e.g., a numerical value and / or an arrow, in certain embodiments). In certain embodiments, one of the plurality of display devices 110, 120, 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.

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

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

[0049] The communication path between SS 8 and display device 150 is shown asP+S Ref. No.: DEXC / 0932PC 9DexcomRef. No.: 0932-PCT01wireless communication path 180. In certain embodiments, SS 8 and display device 150 are configured to wirelessly communicate over wireless 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 wireless 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.

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

[0051] 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 wirelessP+S Ref. No.: DEXC / 0932PC 10DexcomRef. No.: 0932-PCT01(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.

[0052] 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 (e.g., health monitoring application (HMA) 504), as further described below.

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

[0054] 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 electronicsP+S Ref. No.: DEXC / 0932PC 11DexcomRef. No.: 0932-PCT01module 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 SMC 13 may carry out all the functions of the one or more processors 11 and vice versa.

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

[0056] FIG. IB similarly illustrates the components of display device 150 in further detail. As shown, display device 150 includes connectivity interface 128, one or moreP+S Ref. No.: DEXC / 0932PC 12DexcomRef. No.: 0932-PCT01processors 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.

[0057] 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.P+S Ref. No.: DEXC / 0932PC 13DexcomRef. No.: 0932-PCT01

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

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

[0060] 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 viaP+S Ref. No.: DEXC / 0932PC 14DexcomRef. No.: 0932-PCT01a 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.

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

[0062] 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 theP+S Ref. No.: DEXC / 0932PC 15DexcomRef. No.: 0932-PCT01predetermined 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.

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

[0064] In certain embodiments, after downloading 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 Pairins Procedure

[0065] Establishing a secure wireless connection between SS 8 and display device 150 may involve engaging in identification, authentication, pairing, and / or bondingP+S Ref. No.: DEXC / 0932PC 16DexcomRef. No.: 0932-PCT01protocols 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.

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

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

[0068] 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 anyP+S Ref. No.: DEXC / 0932PC 17DexcomRef. No.: 0932-PCT01display devices.

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

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

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

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

[0073] 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 andP+S Ref. No.: DEXC / 0932PC 18DexcomRef. No.: 0932-PCT01display 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.

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

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

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

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

[0078] 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 adequatelyP+S Ref. No.: DEXC / 0932PC 19DexcomRef. No.: 0932-PCT01monitor 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.

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

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

[0081] 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 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 digitalP+S Ref. No.: DEXC / 0932PC 20DexcomRef. No.: 0932-PCT01authentication 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.

[0082] 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 public key, only the corresponding private key can be used to decrypt that information. Alternatively, private key is utilized to generate a digital signature which can be verified only with the corresponding public key to confirm that message’s authenticity. A third way that such a key-pair may be utilized is in key agreement algorithms such as Diffie-Hellman or Elliptic Curve Diffie-Hellman. Each side utilizes its private key and the other communicating party’s public key to compute the same shared secret utilized to further protect messages exchanged between them. 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.

[0083] 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 usingP+S Ref. No.: DEXC / 0932PC 21DexcomRef. No.: 0932-PCT01the 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.

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

[0085] The sequence diagram shown in FIG. 3 illustrates communications between display device 150 and server system 134, which result in display device 150 securely obtaining one or more signed certificates from server system 134. Communications between display device 150 and server system 134 may be triggered by the user downloading sensor application 121 or any other application (not shown) associated with the sensor application. As part of the 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.

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

[0087] 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) or Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm) withP+S Ref. No.: DEXC / 0932PC 22DexcomRef. No.: 0932-PCT01server 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).

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

[0089] 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 exchangeP+S Ref. No.: DEXC / 0932PC 23DexcomRef. No.: 0932-PCT01algorithm and would not have been able to engage in the cryptographic key exchange using that algorithm.

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

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

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

[0093] 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.P+S Ref. No.: DEXC / 0932PC 24DexcomRef. No.: 0932-PCT01

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

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

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

[0097] 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 intermediaryP+S Ref. No.: DEXC / 0932PC 25DexcomRef. No.: 0932-PCT01certificates associated with any SCAs 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.

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

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

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

[0101] 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.P+S Ref. No.: DEXC / 0932PC 26DexcomRef. No.: 0932-PCT01

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

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

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

[0105] 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.P+S Ref. No.: DEXC / 0932PC 27DexcomRef. No.: 0932-PCT014B, which illustrates SS 8’s chain of certificates.

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

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

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

[0109] 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’sP+S Ref. No.: DEXC / 0932PC 28DexcomRef. No.: 0932-PCT01certificate. 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.

[0110] Moving to FIG.4B, FIG.4B illustrates a chain of certificates associated with SS 8. In the example of FIG. 4B, two SCAs (e.g., which could be or include one or more servers or computing devices), having intermediary certificates 422 and 424, are involved in SS 8’s chain of certificates. As shown, SS 8’s chain of certificates starts with SS 8’s own certificate 420 and ends with server system 134’s certificate 426. In certain embodiments, SS 8’s certificate comprises SS 8’s public key (“SS-Pub”) and / or additional information, such as the name of SS 8, the certificate’s expiration information, etc. SS 8’s certificate also includes a 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.

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

[0112] 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 theP+S Ref. No.: DEXC / 0932PC 29DexcomRef. No.: 0932-PCT01same, then display device 150 concludes that the transmitting entity of SS 8’s credentials was in fact SS 8 itself.

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

[0114] 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 Identity Tokens for Secure Connection Establishment

[0115] Public key infrastructure (PKI) technology may be used in certain health management systems to perform authentication and secure communication between an analyte sensor system (SS) of the health management system and a health monitoring application (HMA) executing on a display device of the health management system. The HMA (e.g., HMA 504) may execute on one or more processor(s) 126 of a display device 150. The HMA (e.g., HMA 504) may be an analyte sensor application, such as analyte sensor application 121. The HMA may execute the functions or functionality associated with HMA 504 (e.g., as described with respect to FIGs 5A-22). PKI enables this secure communication through the use of respective pairs of public keys and private keys assigned to the SS and HMA. 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 or HMA) to ensure security.

[0116] The use of PKI begins with a trusted entity, known as a Certificate Authority (CA), issuing a respective digital certificate, signed by a private key of the CA, to each of the SS and HMA, and comprising a respective public key and identity information. Each of the HMA and SS may also locally generate a key pair with a private key and its corresponding public key.

[0117] When communication between the HMA and the SS is desired, the HMA and SS may engage in a certificate exchange procedure. During the certificate exchangeP+S Ref. No.: DEXC / 0932PC 30DexcomRef. No.: 0932-PCT01procedure, the HMA sends its respective certificate and its certificate issuer to the SS comprising its respective public key. Likewise, the SS may also send its respective certificate and its certificate issuer to the HMA including the public key for the SS. Each of the HMA and SS may then decrypt each other’s certificate using a public key associated with the CA to obtain each other’s public keys.

[0118] Thereafter, when, for example, the SS desires to securely send information to the HMA, such as analyte data, the SS may use the public key of the HMA to encrypt a message including the analyte data before transmitting the encrypted message to the HMA. Upon receiving the encrypted message, the HMA may use its private key to decrypt the encrypted message. Similarly, when the HMA desires to securely send information to the SS, the HMA may use the public key of the SS to encrypt a message before transmitting the encrypted message to the SS. Upon receiving the encrypted message, the SS may use its private key to decrypt the encrypted message.

[0119] A significant challenge arises in health management systems utilizing Public Key Infrastructure (PKI) technology, particularly with respect to the management and verification of digital certificates used to secure communication between devices such as an SS and an HMA. For example, once a digital certificate is issued by the CA to a device, it becomes difficult to ascertain a current status of that certificate, such as whether it remains valid, has been revoked, or is otherwise compromised.

[0120] This issue is especially challenging for SSs, which typically lack an internet connection, making it impossible for the SS to verify the validity of the certificate presented by the HMA during pairing or subsequent communications. As a result, there may be scenarios in which SSs may accept certificates from HMAs that are expired, revoked, compromised, or otherwise invalid, creating potential security vulnerabilities in the health management system. For example, a certificate may be valid or issued with a lifetime of one or more years and thus remain valid from an expiration perspective event though it has been compromised.

[0121] Furthermore, without a reliable mechanism for checking certificate statuses, there is an increased risk of unauthorized activity within the health management system. For example, if a private key is stolen from an SS or HMA for any reason, a valid certificate from an SS or HMA could be duplicated and used by counterfeit devices, allowing the counterfeit devices to essentially use normal authentication protocols andP+S Ref. No.: DEXC / 0932PC 31DexcomRef. No.: 0932-PCT01gain access to the health management system and could put a patient at risk.

[0122] Aspects of the present disclosure provide techniques for addressing the challenges related to the management and verification of digital certificates in health management systems, particularly in ensuring the validity of certificates and preventing unauthorized activities. For example, in some embodiments, these techniques may include the use of identity tokens that may be generated, by a trusted and secure entity in the health management system referred to as an identity verification service (IVS) entity, based on a certificate of a particular device and may indicate a certificate status of the certificate of this device. The identity token may then be used during a pairing procedure to ensure that the certificate associated with this particular device is valid before a connection is allowed to be established between this particular device and another device or an application.

[0123] Additionally, aspects of the present disclosure provide techniques for detecting unauthorized activity associated with one or more devices in the health management system. For example, every time an identity token is requested and generated for a particular device, the IVS entity (e.g., IVS entity 506) may be configured to store event information associated with this identity token in a database or other data store. This information may include, for example, (1) an identifier of a device requesting the identity token, (2) a location of the device requesting the identity token, (3) a time at which the identity token was requested at the IVS entity (e.g., IVS entity 506), and (4) an identifier of a device for which the identity token is requested.

[0124] This information may then be used by a fraud detection service (FDS) entity in the health management system to detect unauthorized activity associated with one or more devices in the health management system. In some cases, this unauthorized activity may include the duplication of certificates of the one or more devices and the unauthorized use of the duplicated certificates to access the health management system. This may be detected based on a large number of requests using the same identity information (e.g., a certificate, identifier, for instance, a serial number, etc.), repeated uses of same identity information beyond a sensor or transmitter life (e.g., beyond 10, 15, 21, or 30 days), repeated use of identity information from geographically different locations. Further, when unauthorized activity associated with the one or more devices is detected, the FDS entity may send a request to revoke one or more certificates associated with the one or more devices associated with the detected unauthorized activity.P+S Ref. No.: DEXC / 0932PC 32DexcomRef. No.: 0932-PCT01Obtaining Separate Identity Tokens during an Initial Pairing Procedure

[0125] FIGS. 5A and 5B illustrate a sequence diagram including operations for establishing a connection between an analyte sensor system (SS) 502 (e.g., SS 8 illustrated and described with respect to at least FIG.2) and a health monitoring application (HMA) 504 of a display device (e.g., the analyte sensor application 121 of the display device 150 illustrated and described with respect to at least FIG. 2) in a health management system using respective identity tokens. As shown, the operations may be performed by the SS 502, the display device (e.g., display device 150 executing the HMA 504), an identity verification service (IVS) entity 506, and a device management service (DMS) entity 508 in a health management system. In some embodiments, the IVS entity 506 may comprise a server (e.g., server system 134) or a logical entity included in the server configured for generating identity tokens. Similarly, in some embodiments, the DMS entity 508 may comprise a server (e.g., server system 134) or a logical entity included in the server configured for maintaining identity records (e.g., in a database or other data store) associated with various entities in the health management system. In some embodiments, the IVS entity 506 and DMS entity 508 may be included in the same server or different servers.

[0126] Further, in some embodiments, the IVS entity 506 may include one or more processors that may be individually or collectively configured to execute instructions stored on one or more memories of the IVS entity 506 and to cause the IVS entity 506 to perform one or more operations as discussed below. Similarly, in some embodiments, the DMS entity 508 may include one or more processors that may be individually or collectively configured to execute instructions stored on one or more memories of the DMS entity 508 and to cause the DMS entity 508 to perform one or more operations as discussed below.

[0127] As shown in FIG. 5A, operations begin at 510 with the SS 502 and HMA 504 performing an initial pairing process with each other. In some embodiments, the initial pairing process may involve a certificate exchange in which the SS 502 sends a certificate of the SS 502 to the HMA 504 and the HMA 504 sends a certificate of the HMA 504 to the SS 502. In some embodiments, the certificate of the SS 502 may include certificate unique identifier information that uniquely identifies the certificate of the SS 502, such as a subject distinguished name (DN) of the SS 502 (e.g., one or more identifiers or attributes which may be combined together, for exampleP+S Ref. No.: DEXC / 0932PC 33DexcomRef. No.: 0932-PCT0100,0000,00000000,8PECAwABAgMAAQIDAAHy8w,COMG9T001,55, 8436, 00058741, A8ECAwCBDteAWIDEFOjq3,DEXG9T050, etc.) or a certificate serial number. Further, in some embodiments, the certificate of the SS 502 may include an identifier of the SS 502 to which the certificate was issued (e.g., a serial number, such as 17533d0b6ac6ef55ef9c07735d97bd780l 545409, 05fc037b0d9775b5554e3ca787d390df56691e41, etc.), a PKI public key of the SS 502, and a signature generated based on the contents of the certificate using a private key of a trusted certificate authority (CA) that issued the certificate. Similarly, the certificate of the HMA 504 may include certificate unique identifier information (e.g., DN, serial number, thumbprint, etc.) that uniquely identifies the certificate of the HMA 504, such as a subject DN of the HMA 504 or a certificate serial number. In some embodiments, the DN of the HMA 504 and the certificate serial number may be unique within the CA, meaning they are unique among the certificates issued by the same CA. A thumbprint may be globally unique (e.g., 8al7b32fa8aab21505f7a20fc4a6bl70c8d23192, c8d23192a8aab215c4a6bl7005f7a20f8al7b32f, etc.) Additionally, in some embodiments, the certificate of the HMA 504 may include at least an identifier of the HMA 504 to which the certificate was issued (e.g., such as a thumbprint (e.g., 164f833cd7aad437e320ef345930409249feca9a210a04ff81fde3e8e2b50e71, b897f87a987609ebcae51107bc381722090322852cc320ff0e61bfbla0076bla, etc.), a PKI public key of the HMA 504, and a signature generated based on the contents of the certificate using a private key of the trusted CA that issued the certificate.

[0128] At 512, the HMA 504 sends a first identity token request message, requesting an identity token for the HMA 504. It should be appreciated that the device that transmits or sends the identity token request message may be considered a requesting node while the device for which the identity token is being requested may be considered a target node. Accordingly, in the case that the HMA 504 requests an identity token for itself, the HMA 504 may be considered both the requesting node and the target node.

[0129] FIG. 6 illustrates an example structure of a first identity token request message 600. As shown in FIG. 6, the first identity token request message 600 may include a certificate 602 of the device (e.g., target device) for which the identity token is being requested, a DN 604 of the device (e.g., requesting node) submitting the request for the identity token, an indication 606 of the data that is being requested regarding the device for which the identity token is being requested, a current timestamp 608 (e.g.,P+S Ref. No.: DEXC / 0932PC 34DexcomRef. No.: 0932-PCT012025-09-03T15:28:05.250, 2025-08-12T15:50:50.123Z, etc.), and a signature 610 (e.g., generated by the owner of the certificate, for instance, certificate 602) (e.g., a digital signature using SHA256 hash: 5699351al02b7c27ac8019d385a01b5ede64d73d9fbb37c4ef3b3881a4255477, using another cryptographic function, such as, a2f5db2dcd8c55d5576f0f6afca29a2a3157f9d7e22e06762b471ca8e2cee070b47104defce 572c444b66370dfdb8c29f34adcf41b40748878dfea21ef357502, etc.). For example, in the case that the HMA 504 is requesting an identity token for itself, the first identity token request message 600 may include the certificate of the HMA 504, the DN of the HMA 504, a current timestamp, and a signature. In some embodiments, the signature may be generated by the owner of the certificate submitted in the request using a PKI private key of the owner of the certificate. For example, in the case that the HMA 504 is requesting an identity token for itself, the signature may be generated by using the PKI private key of the HMA 504 to sign the certificate of the HMA 504, the DN of the HMA 504, and a current timestamp. In some embodiments, the signature may allow a validating or verifying entity, such as the I VS entity 506, to know that the HMA 504 is the owner and is in possession of the certificate that is included in the first identity token request message.

[0130] As noted above, the first identity token request message may include the indication 606 of the data that is being requested. In some embodiments, the indication 606 may comprise a 2-byte encoded hex value that indicates the data that is being requested regarding HMA 504. In some embodiments, each bit of the 2-byte encoded hex value may contain searchable data (e.g., to be determined by the IVS, DMS, or combination that can be returned in response to the identity token request). For example, in some embodiments, each bit may be a flag indicating whether a particular piece of data is being requested. As an example, a first bit may be for a current status associated with the certificate of the HMA 504 (e.g., valid, expired, revoked), a second bit may be for an identity status associated with the HMA 504, a third bit may be for a partner ID associated with the HMA 504, a fourth bit may be for a unique identifier associated with the HMA 504, a fifth bit may be for a start date of the certificate of the HMA 504, a sixth bit may be for an end date of the certificate of the HMA 504, a seventh bit may be for a batch ID associated with the certificate of the HMA 504, an eighth bit may be for a partner status of a partner associated with the HMA 504.P+S Ref. No.: DEXC / 0932PC 35DexcomRef. No.: 0932-PCT01

[0131] Returning to FIG. 5A, as shown at 514, the IVS entity 506 may validate a structure of the first identity token request message received from the HMA 504. For example, in some embodiments, the first identity token request message may be expected to have a particular format or structure, as shown in FIG. 6. The IVS entity 506 may verify that there is no missing data in the first identity token request message and that the first identity token request message adheres to the expected structure. Thereafter, the IVS entity 506 may validate that the certificate of the HMA 504 has been issued by the trusted CA. For example, in some embodiments, validating that the certificate of the HMA 504 has been issued by the trusted CA may include verifying the signature of the trusted CA included in the certificate of the HMA 504 using the public key of the trusted CA. For example, if the signature matches the certificate, the IVS entity 506 may validate that the certificate was issued by the trusted CA. Thereafter, the IVS entity 506 may verify the signature of the first identity token request message (e.g., signature 610) by using the public key of the HMA 504. The IVS entity 506 may also verify that the timestamp included in the first identity token request message is within a threshold amount of time (e.g., the first identity token request message was recently generated or within a specific time period).

[0132] At 516, the IVS entity 506 sends a request to the DMS entity 508 for an identity record associated with the HMA 504. In some embodiments, this request may include the certificate unique identifier information of the certificate of the HMA 504. In some embodiments, the request for the identity record associated with the HMA 504 may also include the timestamp that was included in the first identity token request message 600. Further, in some cases, the request for the identity record may include an indication of what information is being requested. For example, in some cases, the request for the identity record may include the 2-byte encoded hex value described above, which indicates what information that the IVS entity 506 is requesting.

[0133] At 518, the DMS entity 508 retrieves the identity records associated with the HMA 504. In some embodiments, the DMS entity 508 is configured to use the certificate unique identifier information to retrieve the identity record associated with the HMA 504. For example, in some embodiments, the DMS entity 508 may use the certificate unique identifier information to search a database of identity records and may find an identity record that matches the certificate unique identifier information (e.g., associated with HMA 504).P+S Ref. No.: DEXC / 0932PC 36DexcomRef. No.: 0932-PCT01

[0134] At 520, the IVS entity 506 may record event information regarding the request for the identity token for the HMA 504 into a fraud detection service (FDS) database or data store for future fraud analysis. This event information may include, for example, a time (e.g., Tl) at which the identity record is requested, an identifier of the device that has requested the identity token (e.g., the certificate unique identifier information of the HMA 504), location information of the device that has requested the identity token (e.g., location information of the HMA 504, for instance, country, city, global position service (GPS) coordinates, etc.), and an identifier of the device for which the identity token is requested (e.g., the certificate unique identifier information the HMA 504 or the SS 502 in the case of a sensor system identity token request).

[0135] At 522, the DMS entity 508 may return, to the IVS entity 506, the identity record associated with the HMA 504. In some embodiments, the identity record associated with the HMA 504 may include the information that is requested based on the 2-byte hex value included within the request for the identity record of the HMA 504. For example, in some embodiments, the identity record of the HMA 504 may indicate an identity status of the HMA 504, a certificate status of the certificate of the HMA 504 (e.g., valid, expired, revoked), a validity date associated with the certificate of the HMA 504 (e.g., start date and / or end date), a partner status, etc. In some embodiments, if the DMS entity 508 does not return the identity record associated with the HMA 504, the DMS entity 508 may return an error to the IVS entity 506 and the IVS entity 506 may return a valid status to the HMA 504 as long as the certificate the certificate of the HMA 504 is valid and trusted (e.g., based on being issued from a trusted CA). Otherwise, the IVS entity 506 may return an invalid status to the HMA 504 which will then terminate paring at 562.

[0136] At 524, the IVS entity 506 generates an identity token for the HMA 504 based on the identity record (e.g., from DMS 508) associated with the HMA 504. In some embodiments, the identity token for the HMA 504 may comprise a JSON Web Token (JWT), including a header, a payload, and a signature. In some cases, the header may indicate a token type of the identity token (e.g., JWT) and a signing algorithm used for the signature, such as HS256 (HMAC with SHA-256), ECDSA with SHA-256, or RS256 (RSA with SHA-256). In some embodiments, the payload of the identity token may include one or more of the following elements: an issuer name associated with the certificate of the HMA 504 (e.g., an identifier of the trusted CA), a subject nameP+S Ref. No. : DEXC / 0932PC 37DexcomRef. No.: 0932-PCT01associated with the certificate of the HMA 504 (e.g., an identifier of the HMA 504), a public key of the certificate of the HMA 504, a certificate status of the certificate of the HMA 504 (e.g., valid, expired, revoked), an action (e.g., no action, user warning, refuse connection), a warning message, an error message, a public key associated with the signature of the identity token for verifying the identity token, and a validity period (e.g., a period of time that the identity token is valid and non-expired). In some embodiments, the signature of the identity token may be generated using the signing algorithm to encrypt or hash the header and the payload of the identity token. In some cases, the signature may be generated using a private signing key of the IVS entity 506.

[0137] At 526, the IVS entity 506 may send, to the HMA 504, the identity token for the HMA 504.

[0138] At 528, the HMA 504 may determine whether the HMA 504 itself is valid based on the identity token for the HMA 504. For example, in some embodiments, the HMA 504 may first validate the identity token for the HMA 504. For example, in some embodiments, validating the identity token for the HMA 504 may include verifying the signature based on the public key included in the identity token. Thereafter, assuming the identity token for the HMA 504 is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the HMA 504 may then determine whether the HMA 504 is valid based, for example, on the certificate status associated with the certificate of the HMA 504 (e.g., valid, expired, revoked). In some embodiments, if the certificate status indicates “valid” the HMA 504 may be configured to persist the identity token and continue to 530. If, however, the certificate status indicates “expired,” “revoked,” or otherwise “invalid,” the operations may skip to 562 in FIG. 5B with the pairing procedure between the SS 502 and the HMA 504 being terminated. In some embodiments, if the status indicates that the certificate is expired or otherwise invalid, the HMA 504 may communicate with the trusted CA to obtain a new certificate and may reperform the operations described above to obtain a new identity token.

[0139] As shown at 530 in FIG. 5B, the HMA 504 may send a message to the SS 502 requesting an identity token of the SS 502.

[0140] At 532, the SS 502 may send an identity token response message to the HMA 504. In some embodiments, when the SS 502 is being used for the first time, the SS 502 may not have an identity token. In such cases, the identity token response message mayP+S Ref. No.: DEXC / 0932PC 38DexcomRef. No.: 0932-PCT01indicate that the SS 502 does not have an identity token.

[0141] At 534, if the SS 502 indicates that it does not have an identity token, or when the SS 502 sends an identity token which is already expired or otherwise invalid, the HMA 504 may send a request for a signature or hash of the SS 502.

[0142] At 536, the SS 502 may send the signature of the SS 502 to the HMA 504. In some embodiments, the signature of the SS 502 may be generated in a similar manner as the signature of the HMA 504 described above. For example, in some embodiments, the signature of the SS 502 may be generated by using a PKI private key of the SS 502 to sign the certificate of the SS 502, the DN of the HMA 504 (e.g., included within the certificate of the HMA 504 obtained by the SS 502 during the certificate exchange at 510), and a timestamp.

[0143] At 538, the HMA 504 sends a second identity token request message, requesting an identity token for the SS 502 to IVS entity 506. It should be appreciated that, in this scenario, that the HMA 504 may be considered as a requesting node while the SS 502 may be considered as a target node.

[0144] In some embodiments, the second identity token request message may include the certificate of the SS 502, the DN of the HMA 504, the signature of the SS 502 obtained at 536, and a timestamp. The second identity token request message may also include a signature, generated by the HMA 504, for the contents of the entire second identity token request message (e.g., the certificate of the SS 502, the DN of the HMA 504, the signature of the SS 502, etc.). In some embodiments, the signature generated by the HMA 504 may allow a verifying entity, such as the IVS entity 506, to confirm an identity of the requesting node (e.g., HMA 504) sending the second identity token request message. In some embodiments, the HMA 504 may obtain the certificate of the SS 502 during the certificate exchange described with respect to 510 in FIG. 5A. In some embodiments, the signature of the SS 502 may allow a validating or verifying entity, such as the IVS entity 506, to know or confirm that the SS 502 is the owner and is in possession of the certificate that is included in the second identity token request message.

[0145] In some embodiments, the second identity token request message may also include a 2-byte encoded hex value indicating the type of information being requested associated with the SS 502. For example, in some embodiments, each bit may be a flag indicating whether a particular piece of data is being requested. As an example, a first bitP+S Ref. No.: DEXC / 0932PC 39DexcomRef. No.: 0932-PCT01may be for a current status associated with the certificate of the SS 502 (e.g., valid or invalid e.g., (expired, revoked)), a second bit may be for an identity status associated with the SS 502 (e.g., 1100000000000000 (C000) for requesting an identity status, for example, under review, valid, invalid, expired, revoked, etc.), a third bit may be for a partner ID, a fourth bit may be for an identifier (e.g., 0001000000000000 (1000) for a requesting identifier associated with SS 502 within a record database, for example, within DMS 508), a fifth bit may be for a start date of the certificate of the SS 502, a sixth bit may be for an end (expiration) date of the certificate of the SS 502, a seventh bit may be for a batch ID (e.g., 0000001000000000 (0200) for requesting a batch ID associated with a group of certificates, group identities, etc.), an eighth bit may be for a partner status (e.g., 0000000100000000 (0100) for requesting whether a partner status is valid or invalid, for example, whether a partner device is proper to communicate with).

[0146] At 540, the IVS entity 506 may validate a structure of the second identity token request message received from the HMA 504. For example, in some embodiments, the second identity token request message may be expected to have a particular format or structure, as shown in FIG. 6. The IVS entity 506 may verify that there is not any missing data in the second identity token request message and that the second identity token request message adheres to the expected structure. Thereafter, the IVS entity 506 may validate that the certificate of the SS 502 has been issued by the trusted CA, for example, by verifying the signature of the certificate of the SS 502 using the public key of the trusted CA. For example, if the signature matches the certificate, the IVS entity 506 may validate that the certificate was issued by the trusted CA.

[0147] Thereafter, the IVS entity 506 may validate the signature of the second identity token request message. For example, in some embodiments, the IVS entity 506 may validate the signature of the second identity token request message by using the public key of the HMA 504. The IVS entity 506 may also verify that the timestamp included in the second identity token request message is within a threshold amount of time (e.g., the second identity token request message was recently generated or within a specific time period).

[0148] At 542, the IVS entity 506 will send a request to the DMS entity 508 for an identity record associated with the SS 502. In some embodiments, this request may include the certificate unique identifier information of the certificate of the SS 502 (e.g., a thumbprint, such as 400ddb91d7545d0982fad301e7525bb8606cl9c8,P+S Ref. No.: DEXC / 0932PC 40DexcomRef. No.: 0932-PCT018c5787e3028f8a246136al657350e09db0e9aac7, etc.). In some embodiments, the request for the identity record associated with the SS 502 may also include a timestamp of when the second identity token request was made included in the second identity token request message. Further, in some cases, the request for the identity record may include an indication of what information is being requested. For example, in some cases, the request for the identity record may include the 2-byte encoded hex value described above, which indicates the information that the IVS entity 506 is requesting.

[0149] In some embodiments, the IVS entity 506 may determine that a sensor session at the SS 502 has been started based on the reception of the identity token request message that requests the identity token for the SS 502. Accordingly, based on determination that the sensor session has started at the SS 502, in some embodiments, the request sent to the DMS entity 508 by the IVS entity 506 may request that the identity record associated with the SS 502 be updated to indicate a start date of the sensor session of the SS 502. In some embodiments, the start date of the SS 502 may be used to detect unauthorized device activity associated with the SS 502 (e.g., the certificate of the SS 502 has been reproduced and used with another device) since sensor sessions typically may last 10-15 days. Additionally, in some embodiments, the request sent by the IVS entity 506 to the DMS entity 508 may request that the identity record for the SS 502 be updated to reflect an association between the HMA 504 and the SS 502. This association may also be used to determine unauthorized device activity associated with the SS 502 since the SS 502 may only be associated with only a reasonably small number of HMA 504 devices (e.g., a smartphone, smartwatch, receiver, pump, or a combination thereof). For example, the association between the SS 502 and the HMA 504 may be used to detect that the certificate of the SS 502 has been duplicated and used in another device, since in this scenario the same certificate of the SS 502 may be associated with multiple HMAs (and display devices, for instance, display device 150).

[0150] At 544, the DMS entity 508 retrieves the identity records associated with the SS 502. In some embodiments, the DMS entity 508 is configured to use the certificate unique identifier information to retrieve the identity record associated with the SS 502. For example, in some embodiments, the DMS entity 508 may use the certificate unique identifier information to search a database of identity records and may find an identity record that matches the certificate unique identifier information (e.g., associated with the SS 502).P+S Ref. No.: DEXC / 0932PC 41DexcomRef. No.: 0932-PCT01

[0151] At 546, the IVS entity 506 may record event information regarding the request for the identity token for the SS 502 into a FDS database for future fraud analysis. In this case, because the HMA 504 is requesting the identity token for the SS 502, the event information may include: a time (e.g., Tl) at which the identity record for the SS 502 is requested, an identifier of the HMA 504 that requested the identity token (e.g., the certificate unique identifier information the HMA 504), location information (e.g., GPS coordinates, city, state, zip code, country, etc.) of the HMA 504, and an identifier of the SS 502 (e.g., the certificate unique identifier information the SS 502).

[0152] At 548, the DMS entity 508 may return, to the IVS entity 506, the identity record associated with the SS 502. In some embodiments, the identity record associated with the SS 502 may include the information that is requested based on the 2-byte hex value included within the request for the identity record of the SS 502. For example, in some embodiments, the identity record of the SS 502 may indicate an identity status of the SS 502 (e.g., 0000000100000000 (0100)), a certificate status of the certificate of the SS 502 (e.g., valid or invalid (e.g., expired or revoked)), a validity date associated with the certificate of the SS 502 (e.g., start date and / or end date), a partner status (e.g., either a bit value of “0” or “1”, where a bit value of “1” may cause the IVS entity 506 to include the partner status), etc. In some embodiments, if the DMS entity 508 does not return the identity record associated with the SS 502, the DMS entity 508 may return an error to the IVS entity 506 and the IVS entity 506 may return a valid status to the HMA 504 as long as the certificate of the SS 502 is valid and trusted (e.g., based on being issued from a trusted CA). For example, if an identity record does not exist for a particular SS 502 in DMS entity 508, an identity record may be created (e.g., with default values, using data from the certificate of the SS 502, a combination thereof, etc.) based on the certificate of the SS 502 being valid and issued by a trusted CA. Otherwise, the IVS entity 506 may return an invalid status to the HMA 504 which will then terminate paring at 562.

[0153] At 550, the IVS entity 506 generates an identity token for the SS 502 based on the identity record associated with the SS 502 (e.g., from DMS 508). In some embodiments, the identity token for the SS 502 may comprise a JWT, including a header, a payload, and a signature. In some cases, the header may indicate a type of token (e.g., JWT) and a signing algorithm used for the signature, such as HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256). In some embodiments, the payload of the identity token may include one or more of the following elements: an issuer name associated withP+S Ref. No.: DEXC / 0932PC 42DexcomRef. No.: 0932-PCT01the certificate of the SS 502 (e.g., an identifier of the trusted CA), a subject name associated with the certificate of the SS 502 (e.g., an identifier of the SS 502), a public key of the certificate of the SS 502, a certificate status of the certificate of the SS 502 (e.g., valid or invalid (e.g., expired or revoked)), an action (e.g., no action, user warning, refuse connection), a warning message, an error message, a public key used to sign the identity token, and a validity period (e.g., a period of time that the identity token is valid and non-expired). In some embodiments, the signature of the identity token may be generated using the signing algorithm indicated in the identity token to encrypt or hash the header and the payload of the identity token. In some cases, the signature may be generated using the private signing key of the I VS entity 506.

[0154] At 552, the IVS entity 506 may send, to the HMA 504, the identity token for the SS 502.

[0155] At 554, the HMA 504 may determine whether the identity token for the SS 502 is valid. For example, the HMA 504 may utilize the public key included in the identity token to verify its signature. Thereafter, assuming the identity token for the SS 502 is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the HMA 504 may then determine whether the SS 502 is valid based, for example, on the certificate status associated with the certificate of the SS 502 (e.g., valid or invalid (e.g., expired or revoked)). In some embodiments, if the certificate status associated with the certificate of the SS 502 indicates “valid,” operations may continue to 556. If, however, the certificate status associated with the certificate of the SS 502 indicates “expired,” “revoked,” or otherwise “invalid,” the operations may skip to 562 with the pairing procedure between the SS 502 and the HMA 504 being terminated.

[0156] In some cases, rather than terminating the pairing procedure between the SS 502 and the HMA 504 when the certificate status associated with the certificate of the SS 502 indicates “expired,” “revoked,” or otherwise “invalid,” the HMA 504 may display a warning notification to a user that indicates that the certificate of the SS 502 cannot be validated. In some embodiments, an action taken by the HMA 504 when the certificate status associated with the certificate of the SS 502 indicates “expired,” “revoked,” or otherwise “invalid,” may be configured based on policy information included within the identity token for the SS 502. For example, as noted above, the identity token for the SS 502 may indicate an action to be taken by the HMA 504, such as no action, user warning, or refuse connection. Accordingly, in some embodiments, when the certificate statusP+S Ref. No.: DEXC / 0932PC 43DexcomRef. No.: 0932-PCT01associated with the certificate of the SS 502 indicates “expired,” “revoked,” or otherwise “invalid,” the HMA 504 may display the warning notification to the user based on the policy configuration, allowing the user to select whether to continue the pairing procedure and establish a wireless connection between the HMA 504 and SS 502. Alternatively, as discussed above, when the policy information indicates to refuse connection, operations may skip to 562 with the pairing procedure between the SS 502 and the HMA 504 being terminated.

[0157] At 556, when the HMA 504 is able to validate the identity token for the SS 502, the HMA 504 may then send, to the SS 502, the identity token for the SS 502. The SS 502 may then be configured to persist the identity token for the SS 502 for future use.

[0158] At 558, the HMA 504 may send, to the SS 502, the identity token for the HMA 504.

[0159] At 560, the SS 502 may determine whether the HMA 504 is valid based on the identity token for the HMA 504. For example, the SS 502 may verify the signature in the identity token for the HMA 504 using the public key included in the identity token for the HMA 504. Thereafter, assuming the identity token for the HMA 504 is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the SS 502 may then determine whether the HMA 504 is valid based, for example, on the certificate status associated with the certificate of the HMA 504 (e.g., valid or invalid (e.g., expired or revoked)). In some embodiments, if the certificate status associated with the certificate of the HMA 504 indicates “valid,” operations may continue to 564. If, the certificate status associated with the certificate of the HMA 504 indicates “expired,” “revoked,” or otherwise “invalid,” the operations may skip to 562 with the pairing procedure between the SS 502 and the HMA 504 being terminated.

[0160] At 564, when the certificate status associated with the certificate of the HMA 504 indicates “valid,” then the SS 502 may be configured to complete the pairing procedure with the HMA 504 and establish a wireless connection with the HMA 504 (e.g., as described above with respect to FIG. 2, etc.).Obtaining a Joint Identity Token during an Initial Pairing Procedure

[0161] In some embodiments, rather than separately requesting identity tokens for the HMA 504 and the SS 502, as described with respect to FIGS. 5A and 5B, a joint identity token for both the HMA 504 and SS 502 may be requested. Accordingly, FIG. 7P+S Ref. No.: DEXC / 0932PC 44DexcomRef. No.: 0932-PCT01illustrates operations for obtaining a joint identity token for the HMA 504 and the SS 502.

[0162] As shown, operations begin at 710 with the SS 502 and HMA 504 performing an initial pairing process with each other. In some embodiments, the initial pairing process may involve a certificate exchange in which the SS 502 sends a certificate of the SS 502 to the HMA 504 and the HMA 504 sends a certificate of the HMA 504 to the SS 502.

[0163] At 712, if the SS 502 indicates that it does not have an identity token, the HMA 504 may send a request for a signature or hash of the SS 502.

[0164] At 714, the SS 502 may send the signature of the SS 502 to the HMA 504. In some embodiments, the signature of the SS 502 may be generated by the SS 502 by using a PKI private key of the SS 502 to sign the certificate of the SS 502, the DN of the HMA 504, and a timestamp.

[0165] At 716, the HMA 504 sends a joint identity token request message to the IVS entity 506, requesting a joint identity token for the HMA 504 and the SS 502. It should be appreciated that, in this scenario, that the HMA 504 may be considered as a requesting node while the SS 502, as well as the HMA 504, may be considered as a target node.

[0166] In some embodiments, the joint identity token request message may include the certificate of the HMA 504, the certificate of the SS 502, the DN of the HMA 504 and the DN of the SS 502, a signature generated by the HMA 504, the signature generated by the SS 502, a timestamp, and an encoded hex value indicating what information is being requested in the joint identity token request message. For example, in some cases, the request for the identity record may include the 2-byte encoded hex value described above, which indicates what information is being requested from the IVS entity 506. In some embodiments, the signature generated by the HMA 504 may be generated by using the private key of the HMA 504 to sign the certificate of the HMA 504, the DN of the HMA 504, and the timestamp.

[0167] At 718, the IVS entity 506 validates the joint identity token request message. For example, the IVS entity 506 may validate a structure of the joint identity token request message (e.g., similar to identity token request message 600), validate the certificate of the HMA 504 and the certificate of the SS 502, and validate the signature generated by the HMA 504 and the signature generated by the SS 502. In some embodiments, the IVS entity 506 may also validate the DN of the SS 502 and the DN of the HMA 504.

[0168] At 720, the IVS entity 506 sends one or more requests to the DMS entity 508P+S Ref. No.: DEXC / 0932PC 45DexcomRef. No.: 0932-PCT01for respective identity records associated with the HMA 504 and the SS 502. In some embodiments, this request may include certificate unique identifier information of the certificate of the HMA 504 as well as certificate unique identifier information of the certificate of the SS 502. In some embodiments, the one or more requests for the respective identity records may also include a timestamp of when the one or more requests are being made. Further, in some cases, the one or more requests for the identity records may include an indication of what information is being requested. For example, in some cases, the request for the identity record may include an encoded hex value (e.g., similar to the encode hex value described above), which indicates the information that the IVS entity 506 is requesting.

[0169] At 722, the DMS entity 508 retrieves the identity records associated with the HMA 504 and SS 502. In some embodiments, the DMS entity 508 is configured to use the certificate unique identifier information of the certificate of the HMA 504 to retrieve the identity record associated with the HMA 504. For example, in some embodiments, the DMS entity 508 may use the certificate unique identifier information of the HMA 504 to search a database of identity records and may find an identity record that matches the certificate unique identifier information of the certificate of the HMA 504. Similarly, the DMS entity 508 is configured to use the certificate unique identifier information of the certificate of the SS 502 to retrieve the identity record associated with the SS 502. For example, in some embodiments, the DMS entity 508 may use the certificate unique identifier information of the SS 502 to search a database of identity records and may find an identity record that matches the certificate unique identifier information of the certificate of the SS 502.

[0170] At 724, the IVS entity 506 may record event information regarding the one or more requests for the identity records into the FDS database for future fraud analysis. For example, in some embodiments, regarding the request for the identity record associated with the HMA 504, the event information may include: a time (e.g., Tl) at which the identity record for the HMA 504 is requested, an identifier of the HMA 504 that requested the identity token for the HMA 504 (e.g., the certificate unique identifier information the HMA 504), location information of the HMA 504. In some embodiments, regarding the request for the identity record associated with the SS 502, the event information may include: a time (e.g., Tl) at which the identity record for the SS 502 is requested, an identifier of the HMA 504 that requested the identity token (e.g., theP+S Ref. No.: DEXC / 0932PC 46DexcomRef. No.: 0932-PCT01certificate unique identifier information the HMA 504), location information of the HMA 504, and an identifier of the SS 502 (e.g., the certificate unique identifier information the SS 502).

[0171] At 726, the DMS entity 508 may return, to the IVS entity 506, the respective identity records associated with the HMA 504 and the SS 502. In some embodiments, the respective identity records associated with the HMA 504 and the SS 502 may include the information that is requested based on the hex value included within the one or more requests for the respective identity record of the HMA 504 and the SS 502. For example, in some embodiments, the identity record of the HMA 504 may indicate an identity status of the HMA 504, a certificate status of the certificate of the HMA 504 (e.g., valid or invalid (e.g., expired or revoked)), a validity date associated with the certificate of the HMA 504 (e.g., start date and / or end date), a partner status, etc. Further, in some embodiments, the identity record of the SS 502 may indicate an identity status of the SS 502, a certificate status of the certificate of the SS 502 (e.g., valid or invalid (e.g., expired or revoked)), a validity date associated with the certificate of the SS 502 (e.g., start date and / or end date), a partner status, etc.

[0172] At 728, the IVS entity 506 generates a joint identity token for the HMA 504 and the SS 502 based on the identity record associated with the HMA 504 and the identity record associated with the SS 502. As discussed above, the joint identity token may include a header, a payload, and a signature. In some cases, the header may indicate a type of token (e.g., JWT) and a signing algorithm used for the signature, such as HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256). In some embodiments, the payload of the identity token may include one or more of the following elements: an issuer name associated with the certificate of the HMA 504 (e.g., an identifier of the trusted CA), a subject name associated with the certificate of the HMA 504 (e.g., an identifier of the HMA 504), a public key of the certificate of the HMA 504, a certificate status of the certificate of the HMA 504 (e.g., valid or invalid (e.g., expired or revoked)), an issuer name associated with the certificate of the SS 502 (e.g., an identifier of the trusted CA), a subject name associated with the certificate of the SS 502 (e.g., an identifier of the SS 502), a public key of the certificate of the SS 502, a certificate status of the certificate of the SS 502 (e.g., valid or invalid (e.g., expired or revoked)), an action (e.g., no action, user warning, refuse connection), a warning message, an error message, a public key used to verify the identity token signature, and a validity period (e.g., a period of time that theP+S Ref. No.: DEXC / 0932PC 47DexcomRef. No.: 0932-PCT01identity token is valid and non-expired). In some embodiments, the signature of the joint identity token may be generated using the signing algorithm indicated in the joint identity token to encrypt or hash the header and the payload of the identity token. In some cases, the signature may be generated using a private signing key of the IVS entity 506.

[0173] At 730, the IVS entity 506 may send, to the HMA 504, the joint identity token for the HMA 504 and the SS 502.

[0174] At 732, the HMA 504 may also send the joint identity token for the HMA 504 and the SS 502 to the SS 502.

[0175] At 734, the SS 502 may determine whether the HMA 504 is valid based on the joint identity token. For example, the SS 502 may verify the signature of the joint identity token using the public key included in the joint identity token. Thereafter, assuming the joint identity token is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the SS 502 may then determine whether the HMA 504 is valid based, for example, on the certificate status associated with the certificate of the HMA 504 (e.g., valid or invalid (e.g., expired or revoked)). In some embodiments, if the certificate status associated with the certificate of the HMA 504 indicates “valid,” operations may continue to 738 with the SS 502 and the HMA 504 completing the pairing procedure and establishing a wireless connection. If, the certificate status associated with the certificate of the HMA 504 indicates “expired,” “revoked,” or otherwise “invalid,” the operations may skip to 740 with the pairing procedure between the SS 502 and the HMA 504 being terminated.

[0176] At 736, the HMA 504 may determine whether the SS 502 is valid based on the joint identity token. For example, the HMA 504 may verify the joint identity token signature using the public key included in the joint identity token Thereafter, assuming the joint identity token is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the HMA 504 may then determine whether the SS 502 is valid based, for example, on the certificate status associated with the certificate of the SS 502 (e.g., valid or invalid (e.g., expired or revoked)). In some embodiments, if the certificate status associated with the certificate of the SS 502 indicates “valid,” operations may continue to 738 with the SS 502 and the HMA 504 completing the pairing procedure and establishing a wireless connection. If, the certificate status associated with the certificate of the SS 502 indicates “expired,” “revoked,” or otherwise “invalid,” theP+S Ref. No.: DEXC / 0932PC 48DexcomRef. No.: 0932-PCT01operations may skip to 740 with the pairing procedure between the SS 502 and the HMA 504 being terminated.Establishing a Wireless Connection between an HMA and SS

[0177] FIG. 8 illustrates example operations for establishing a wireless connection between the HMA 504 of a display device (e.g., display device 150) and the SS 502 (e.g., SS 8) using identity tokens. In some embodiments, the operations illustrated in FIG. 8 assume that the HMA 504 has already obtained an identity token for itself (e.g., as described with respected FIG 5A).

[0178] As shown at 810, the HMA 504 of the display device may begin establishing a wireless connection with the SS 502. In some embodiments, this may include transmitting or sending a pairing request to the SS 502. In some embodiments, the pairing request may include an identity token for the HMA 504.

[0179] At 812, the SS 502 may validate the identity token for the HMA 504. For example, in some embodiments, validating the identity token for the HMA 504 may include verifying a signature of the identity token for the HMA 504 based on a public key included in the identity token for the HMA 504. Thereafter, assuming the identity token for the HMA 504 is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the SS 502 may then determine whether the HMA 504 is valid based, for example, on the certificate status associated with the certificate of the HMA 504 (e.g., valid or invalid (e.g., expired or revoked)) included within the token for the HMA 504.

[0180] At 814, if the SS 502 determines that the HMA 504 is valid, the procedure for establishing the wireless connection may continue.

[0181] At 816, the SS 502 may transmit or send a certificate of the SS 502 to the HMA 504.

[0182] At 818, the HMA 504 may validate the certificate of the SS 502. For example, in some embodiments, validating the certificate of the SS 502 may include verifying a signature of the certificate of the SS 502 using a public key of the trusted CA that signed the certificate of the SS 502.

[0183] At 820, assuming that the certificate of the SS 502 is valid, the HMA 504 of the display device may send an identity token request message to the IVS entity 506,P+S Ref. No.: DEXC / 0932PC 49DexcomRef. No.: 0932-PCT01requesting an identity token for the SS 502. It should be appreciated that, in this scenario, that the HMA 504 may be considered as a requesting node while the SS 502 may be considered as a target node.

[0184] In some embodiments, the identity token request message may include, at least, the certificate of the SS 502. In some embodiments, the identity token request message may also include a DN of the HMA 504 and a signature generated by the SS 502. In some embodiments, identity token request messages sent to the IVS entity 506 may be rate-limited and requests messages exceeding a pre-configured rate may be dropped by the IVS entity 506. In some embodiments, the HMA 504 may add a random wait time before a retry after a request message is dropped due to a high rate of requests sent to IVS entity 506.

[0185] At 822, the IVS entity 506 may obtain an identity record associated with the SS 502 based on information included within the certificate of the SS 502, such as certificate unique identifier information (e.g., a subject DN or a certificate serial number). In some embodiments, the IVS entity 506 may obtain the identity record associated with the SS 502 from a DMS entity, such as the DMS entity 508 described with respect to FIGS. 5A and 5B. For example, the IVS entity 506 may transmit or send a request message requesting the identity record associated with the SS 502, which may include the certificate unique identifier information (e.g., of the SS 502). The DMS entity may then search a database of identity records based on the certificate unique identifier information to locate the identity record associated with the SS 502. In some embodiments, the identity records associated with the SS 502 and HMA 504 may be created when certificates are issued for SS 502 and HMA 504. For example, in some embodiments, the identity record for the SS 502 may be created in the DMS entity 508 during manufacturing of the SS 502 when the certificate of the SS 502 is issued. Additionally, in some embodiments, the identity record for HMA 504 may be created in the DMS entity 508 when the HMA 504 is run for the first time and a certificate is issued to the HMA 504 (e.g., from a certificate authority).

[0186] At 824, after obtaining the identity record associated with the SS 502, the IVS entity may generate an identity token for the SS 502 based on the identity record associated with the SS 502. The IVS entity 506 may then send the identity token for the SS 502 to the HMA 504, as shown at 826.P+S Ref. No.: DEXC / 0932PC 50DexcomRef. No.: 0932-PCT01

[0187] At 828, the HMA 504 may validate the identity token for the SS 502. For example, in some embodiments, the identity token for the SS 502 may include a signature generated based on a private signing key of the IVS entity 506. The HMA 504 may verify the signature using a public key of the IVS entity 506 included in the identity token.

[0188] At 830, assuming that the identity token for the SS 502 is valid, the SS 502 and HMA 504 may continue with the pairing procedure and establish a wireless connection with each other.

[0189] At 832, if the identity token for the SS 502 is not valid, the HMA 504 may terminate the pairing procedure and may not establish a wireless connection with the SS 502.Establishing a Wireless Connection with an Identity Token Request Timeout

[0190] FIG. 9 illustrates example operations for establishing a wireless connection between the HMA 504 of a display device and an SS 502 using identity tokens. The operations shown in FIG. 9 involve a scenario in which a request for an identity token for the SS 502 times out. In some embodiments, the operations illustrated in FIG. 9 assume that the HMA 504 has already obtained an identity token for itself (e.g., as described with respected FIG 5A).

[0191] At 910, the HMA 504 of the display device may begin establishing a wireless connection with the SS 502. For example, in some embodiments, establishing a wireless connection with the SS 502 may include initiating a pairing procedure. In some embodiments, the paring procedure may include transmitting or sending a pairing request to the SS 502. In some embodiments, the pairing request may include an identity token for the HMA 504.

[0192] At 912, the SS 502 may validate the identity token for the HMA 504. For example, in some embodiments, validating the identity token for the HMA 504 may include verifying a signature of the identity token for the HMA 504 based on a public key of the HMA 504 included in the identity token for the HMA 504. Thereafter, assuming the identity token for the HMA 504 is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the SS 502 may then determine whether the HMA 504 is valid based, for example, on the certificate status associated with the certificate of the HMA 504 (e.g., valid or invalid (e.g., expired or revoked)) included within the token for the HMA 504.P+S Ref. No.: DEXC / 0932PC 51DexcomRef. No.: 0932-PCT01

[0193] At 914, if the SS 502 determines that the HMA 504 is valid, the procedure for establishing the wireless connection may continue.

[0194] At 916, the SS 502 may transmit or send a certificate of the SS 502 to the HMA 504.

[0195] At918, the HMA 504 may validate the certificate of the SS 502. For example, in some embodiments, validating the certificate of the SS 502 may include verifying a signature of the certificate of the SS 502 using a public key of the trusted CA that signed the certificate of the SS 502.

[0196] At 920, assuming that the certificate of the SS 502 is valid, the HMA 504 of the display device may send an identity token request message to the IVS entity 506, requesting an identity token for the SS 502. It should be appreciated that, in this scenario, that the HMA 504 may be considered as a requesting node while the SS 502 may be considered as a target node. In some embodiments, the identity token request message may include, at least, the certificate of the SS 502. In some embodiments, the identity token request message may also include a DN of the HMA 504 and a signature generated by the SS 502.

[0197] In some embodiments, rather than receiving an identity token associated with the SS 502 from the IVS entity 506, the identity token request message sent to the IVS entity 506 may timeout. In other words, the HMA 504 may send the identity token request message to the IVS entity 506 but may not receive a response from the IVS entity 506 within a threshold amount of time (e.g., 60 seconds, 2 minutes, etc.).

[0198] In some embodiments, when the request message for the identity token for the SS 502 times out and the HMA 504 does not receive a response from the IVS entity 506 within the threshold amount of time, rather than terminating the procedure for establishing the wireless connection between the HMA 504 and the SS 502, the HMA 504 may instead display a warning notification to a user that indicates that the certificate of the SS 502 cannot be validated, as shown 922. In some embodiments, the warning notification may provide the user with the option to continue with establishing the connection with the SS 502 or to terminate the procedure for establishing the connection.

[0199] In some embodiments, when the user selects to continue with establishing the connection with the SS 502, the SS 502 and HMA 504 may continue to establish the connection, as shown at 924.P+S Ref. No.: DEXC / 0932PC 52DexcomRef. No.: 0932-PCT01

[0200] At 926, the HMA 504 may set a retry timer associated with obtaining the identity token for the SS 502. A length of the retry timer or a value of the timer may be variable (e.g., three retries, five retries, etc.) or a random amount of time.

[0201] At 928, after expiration of the retry timer, the HMA 504 may send another identity token request message to the IVS entity 506, requesting the identity token for the SS 502. In some embodiments, HMA may retry requesting the identity token of the SS 502 a particular number of times (e.g., three times, six retries, etc.), a variable number of times, a random number of times, etc. The number of retries may be configured value or setting of HMA 504 (e.g., configured in HMA 504, configured based communication of HMA 504 with IVS 506, etc.).

[0202] At 930, the HMA 504 may receive the identity token for the SS 502 from the IVS entity 506 based on the identity token request message (e.g., at 928). However, in some embodiments, if the HMA 504 does not receive the identity token of the SS 502 from the IVS entity 506 at 930 within a certain number of requests or within a certain amount of time, operations 900 may proceed to 934 with the HMA 504 terminating the pairing procedure.

[0203] At 932, the HMA 504 may validate the identity token for the SS 502. In some embodiments, validating the identity token for the SS 502 may include verifying a signature of the identity token for the SS 502. For example, in some embodiments, the identity token for the SS 502 may include a signature generated based on a private signing key of the IVS entity 506. The HMA 504 may verify the signature using a public key of the IVS entity 506 included in the identity token.

[0204] In some embodiments, the identity token for the SS 502 may indicate a certificate status associated with the certificate of the SS 502. In some embodiments, after validating the identity token for the SS 502, if the certificate status included therein indicates “expired,” “revoked,” or otherwise “invalid,” the HMA 504 may terminate the wireless connection with the SS 502, as shown at 934.Establishing a Connection between a Proxy Device and a Receiver Device

[0205] In some embodiments, rather than using an HMA on a display device that has direct internet access, such as a smartphone, to receive analyte data from an SS, a user may instead use a display device without direct internet access, such as a dedicated receiver device (e.g., analyte display device 110), to receive the analyte data from the SS.P+S Ref. No.: DEXC / 0932PC 53DexcomRef. No.: 0932-PCT01In such scenarios, however, in order to use an identity token to validate the SS, the receiver device may first need to establish a connection with a proxy device. The proxy device may have direct access to the internet and may be configured to relay communications between the receiver device and an IVS entity. FIG. 10 illustrates operations that may be used to establish a connection between a proxy device 1002 and a receiver device 1004, for example, using identity tokens. In some embodiments, the receiver device 1004 may be an example of the display device 150 depicted and described with respect to FIG. IB, but may lack a direct internet access capability. In some embodiments, the proxy device 1002 may be an example of or may be similar to the display device 150 depicted and described with respect to FIG. IB, and may have a direct internet access capability.

[0206] At 1010, the proxy device 1002 may initiate a connection establishment procedure with the receiver device 1004 to establish a universal serial bus (USB) connection (or other wired or wireless connection) between the proxy device 1002 and the receiver device 1004. In some embodiments, initiating the connection establishment procedure may include the proxy device 1002 sending a connection request message to the receiver device 1004. In some embodiments, the connection request message may include an identity token for the proxy device 1002 (e.g., including the certificate of the proxy device 1002). In some embodiments, the proxy device 1002 may have obtained the identity token for itself prior to attempting to establish the connection with the receiver device 1004, for example, using techniques similar to those described above with respect to the HMA 504 in FIG. 5A.

[0207] At 1012, the receiver device 1004 may validate the identity token for the proxy device 1002. For example, in some embodiments, validating the identity token for the proxy device 1002 may include verifying a signature of the identity token for the proxy device 1002 based on a public key associated with the proxy device 1002 included in the identity token for the proxy device 1002. Thereafter, assuming the identity token for the proxy device 1002 is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the receiver device 1004 may then determine whether the proxy device 1002 is valid based, for example, on a certificate status associated with a certificate of the proxy device 1002 (e.g., valid or invalid (e.g., expired or revoked)).

[0208] At 1014, if the receiver device 1004 determines that the proxy device 1002 isP+S Ref. No.: DEXC / 0932PC 54DexcomRef. No.: 0932-PCT01valid, the procedure for establishing the wireless connection may continue.

[0209] At 1016, the receiver device 1004 may transmit or send a certificate of the receiver device 1004 to the proxy device 1002.

[0210] At 1018, the proxy device 1002 may validate the certificate of the receiver device 1004. For example, in some embodiments, validating the certificate of the receiver device 1004 may include verifying a signature of the certificate of the receiver device 1004 using a public key of a trusted CA that signed the certificate of the receiver device 1004.

[0211] At 1020, assuming that the certificate of the receiver device 1004 is valid, the proxy device 1002 may send an identity token request message to the IVS entity 506, requesting an identity token for the receiver device 1004. It should be appreciated that, in this scenario, that the proxy device 1002 may be considered as a requesting node while the receiver device 1004 may be considered as a target node.

[0212] In some embodiments, the identity token request message may include, at least, the certificate of the receiver device 1004. In some embodiments, the identity token request message may also include a DN of the proxy device 1002, and a signature generated by the receiver device 1004 (e.g., based on a private key of the receiver device 1004). In some embodiments, identity token request messages sent to the IVS entity 506 may be rate-limited and requests messages exceeding a pre-configured rate may be dropped by the IVS entity 506. In some embodiments, the proxy device 1002 may add a random wait time before a retry after a request message is dropped due to a high rate of requests sent to IVS entity 506.

[0213] At 1022, the IVS entity 506 may obtain the identity record associated with the receiver device 1004 from the DMS entity 508. In some embodiments, the IVS entity 506 may obtain an identity record (e.g., from DMS 508) associated with the receiver device 1004 based on information included within the certificate of the receiver device 1004, such as certificate unique identifier information (e.g., a subject DN or a certificate serial number). For example, the IVS entity 506 may transmit or send a request message requesting the identity record associated with the receiver device 1004, which may include the certificate unique identifier information. The DMS entity 508 may then search a database of identity records based on the certificate unique identifier information to locate the identity record associated with the receiver device 1004.P+S Ref. No.: DEXC / 0932PC 55DexcomRef. No.: 0932-PCT01

[0214] At 1024, after obtaining the identity record associated with the receiver device 1004, the IVS entity 506 may generate an identity token for the receiver device 1004 based on the identity record associated with the receiver device 1004. Thereafter, at 1026, the IVS entity 506 may send the identity token for the receiver device 1004 to the proxy device 1002.

[0215] At 1028, the proxy device 1002 may validate the identity token for the receiver device 1004. For example, in some embodiments, the identity token for the receiver device 1004 may include a signature generated based on a private signing key of the IVS entity 506. The proxy device 1002 may verify the signature using a public key of the IVS entity 506 included in the identity token. In some cases, after validating the identity token for the receiver device 1004, the proxy device 1002 may send the identity token for the receiver device 1004 to the receiver device 1004 (e.g., as part of 1030).

[0216] At 1030, assuming that the identity token for the receiver device 1004 is valid, the receiver device 1004 and proxy device 1002 may continue with the connection establishment procedure and establish a USB or other connection with each other.

[0217] At 1032, if the identity token for the receiver device 1004 is not valid, the proxy device 1002 may terminate the connection establishment procedure and may not establish a wireless connection with the receiver device 1004.Establishing a Connection between a Receiver Device and an SS using a Proxy Device

[0218] FIG. 11 illustrates example operations for establishing a wireless connection between the receiver device 1004 and the SS 502, via the proxy device 1002, using identity tokens. In some embodiments, the operations in FIG. 11 also include obtaining and validating an identity token for the SS 502 by the receiver device 1004 via the proxy device 1002. These operations assume that the receiver device 1004 and the proxy device 1002 have already established a connection with each other (e.g., a USB connection, wireless connection, etc.), that the receiver device 1004 has already obtained an identity token for itself, and that the proxy device 1002 has already obtained an identity token for itself (e.g., as described with respect to FIG. 10).

[0219] As shown at 1110, the receiver device 1004 may begin establishing a wireless connection with the SS 502. For example, in some embodiments, establishing the wireless connection with the SS 502 may include initiating a pairing procedure. In some embodiments, the paring procedure may include transmitting or sending a pairing requestP+S Ref. No.: DEXC / 0932PC 56DexcomRef. No.: 0932-PCT01to the SS 502. In some embodiments, the pairing request may include an identity token for the receiver device 1004.

[0220] At 1112, the SS 502 may validate the identity token for the receiver device 1004. For example, in some embodiments, validating the identity token for the receiver device 1004 may include verifying a signature of the identity token for the receiver device 1004 based on a public key of the receiver device 1004 included in the identity token for the receiver device 1004. Thereafter, assuming the identity token for the receiver device 1004 is valid (e.g., has not been tampered with, damaged, corrupted, etc., based on verifying the signature), the SS 502 may then determine whether the receiver device 1004 is valid based, for example, on the certificate status associated with the certificate of the receiver device 1004 (e.g., valid or invalid (e.g., expired or revoked))indicated in the identity token for the receiver device 1004.

[0221] At 1114, if the SS 502 determines that the receiver device 1004 is valid, the procedure for establishing the wireless connection may continue.

[0222] At 1116, the SS 502 may transmit or send a certificate of the SS 502 to the receiver device 1004.

[0223] At 1118, the receiver device 1004 may validate the certificate of the SS 502. For example, in some embodiments, validating the certificate of the SS 502 may include verifying a signature of the certificate of the SS 502 using a public key of a trusted CA that signed the certificate of the SS 502.

[0224] At 1120, since the receiver device 1004 may not have direct access to the internet, the receiver device 1004 may send an identity token request message to the proxy device 1002. In some embodiments, the identity token request message may request an identity token for the SS 502 and may include, at least, the certificate of the SS 502. In some embodiments, the identity token request message may also include a DN of the receiver device 1004 and a signature generated by the SS 502.

[0225] At 1122, the proxy device 1002 forwards the identity token request message to the IVS entity 506 to request the identity token for the SS 502. It should be appreciated that, in this scenario, that the receiver device 1004 and / or the proxy device 1002 may be considered as a requesting node while the SS 502 may be considered as a target node.

[0226] At 1124, the IVS entity 506 may obtain the identity record associated with the SS 502 from the DMS entity 508. In some embodiments, the IVS entity 506 mayP+S Ref. No.: DEXC / 0932PC 57DexcomRef. No.: 0932-PCT01obtain an identity record associated with the SS 502 based on information included within the certificate of the SS 502, such as certificate unique identifier information (e.g., a subject DN or a certificate serial number). For example, the IVS entity 506 may transmit a request message requesting the identity record associated with the SS 502, which may include the certificate unique identifier information. The DMS entity 508 may then search a database of identity records based on the certificate unique identifier information to locate the identity record associated with the SS 502.

[0227] At 1126, after obtaining the identity record associated with the SS 502, the IVS entity 506 may generate an identity token for the SS 502 based on the identity record associated with the SS 502. At 1128, the IVS entity 506 may send the identity token for the SS 502 to the proxy device 1002.

[0228] At 1130, the proxy device 1002 forwards the identity token for the SS 502 to the receiver device 1004.

[0229] At 1132, the receiver device 1004 may validate the identity token for the SS 502. For example, in some embodiments, the identity token for the SS 502 may include a signature generated based on a private signing key of the IVS entity 506. The receiver device 1004 may verify the signature using a public key of the IVS entity 506 included in the identity token. In some cases, after validating the identity token for the SS 502, the receiver device 1004 may send the identity token for the SS 502 to the SS 502.

[0230] At 1134, assuming that the identity token for the SS 502 is validated, the SS 502 and receiver device 1004 may continue with the pairing procedure and establish a wireless connection with each other.

[0231] At 1136, if the identity token for the SS 502 is not valid, the receiver device 1004 may terminate the pairing procedure and may not establish a wireless connection with the SS 502.Aspects Related to Fraud Detection in a Health management system

[0232] As discussed above, the IVS entity 506 may record or store event information into a FDS database of an FDS entity associated with requests for identity tokens for various devices. For example, for each identity token that is requested, the IVS entity 506 may send event information to the FDS database that indicates (1) the device that requested the identity token, (2) the location associated with the device that requested the identity token, (3) the time at which the identity token request was made (e.g., aP+S Ref. No.: DEXC / 0932PC 58DexcomRef. No.: 0932-PCT01timestamp), and (4) the device for which the identity token is requested. For example, in a scenario in which the HMA 504 requests an identity token for the SS 502, the event information may indicate (1) an identifier of the HMA 504, such as a subject DN of the HMA 504, (2) a location (e.g., GPS location or city, state, and country) of the HMA 504 (e.g., a location associated with a device executing the HMA 504) when the HMA 504 sent the identity token request message to the IVS entity requesting the identity token for the SS 502, (3) the time at which the identity token request message was received from the HMA 504 (e.g., by IVS entity 506), and (4) an identifier of the SS 502 for which the identity token is being sought, such as a DN of the SS 502.

[0233] In some embodiments, the FDS entity may be configured to use the event information stored in the FDS database to detect unauthorized activity associated with one or more devices identified in the event information and to prevent other unauthorized devices from accessing the health management system. Such unauthorized activity may include duplicating a device’s certificate and attempting to use the duplicated certificate to access the health management system. For example, in some cases, an entity may attempt to duplicate a certificate of an authorized or otherwise legitimate SS and use this certificate to allow other non-legitimate or non-authorized SSs to access the health management system. Similarly, there may be instances in which an entity attempts to duplicate a certificate of a legitimate or authorized HMA and use this certificate to allow another non-legitimate or non-authorized HMA or other applications to access the health monitoring application or associated data / systems (e.g., a cloud system).

[0234] In some embodiments, when the FDS entity detects unauthorized activity associated with a certain device that is identified by the event information (e.g., a certificate of this device has been duplicated and reused), the FDS entity may be configured to send a revocation request to the DMS entity to have a certificate associated with this device revoked. In such cases, when the DMS entity receives this revocation request, the DMS entity may update an identity record associated with this device (e.g., and with this device’s certificate) to indicate that the certificate status of this device is revoked, which may prevent any further unauthorized devices from using this device’s certificate to request an identity token to access the health management system.

[0235] In some embodiments, unauthorized activity associated with devices that are identified by the event information may be detected or identified by the FDS entity in different manners, as shown in FIGS. 12-16.P+S Ref. No.: DEXC / 0932PC 59DexcomRef. No.: 0932-PCT01

[0236] FIG. 12 illustrates a scenario in which an FDS entity 1202 may detect unauthorized activity associated with at least one SS identified by the event information based on a number of times that an identity token is requested for the at least one SS. For example, when it is detected that an identity token for the at least one SS or the certificate of the SS has been requested more than a threshold number of times, this may signify that a certificate of the at least one SS has been duplicated and is being used in an attempt to manufacture fraudulent SS devices that may not have been approved by an appropriate health regulatory body (e.g., FDA) and gain access to the health management system.

[0237] In some embodiments, the FDS entity 1202 may comprise a server or a logical entity included in the server configured for detecting unauthorized or fraudulent activity in a health management system. In some embodiments, FDS entity 1202 may be included within the same server or a different server as the IVS entity 506 and the DMS entity 508 described above. Further, in some embodiments, the FDS entity 1202 may include one or more processors that may be individually or collectively configured to execute instructions stored on one or more memories of the FDS entity 1202 and to cause the FDS entity 1202 to perform one or more operations as discussed below.

[0238] As shown in FIG. 12, the IVS entity 506 may receive an identity token request message from an HMA 504, requesting an identity token for the at least one SS, such as the SS 502. It should be appreciated that, while FIG. 12 illustrates that identity token request message being received from the HMA 504, the identity token request message may be received from another device, such as the proxy device 1002 or another device described herein that transmits identity token request messages to the IVS entity 506.

[0239] After receiving the identity token request message from the HMA 504, the IVS entity 506 may report or send event information 1204 to an FDS database 1206. In some embodiments, the FDS database 1206 may be included within the one or more memories of the FDS entity 1202 or may be maintained in a server external to the FDS entity 1202.

[0240] In some embodiments, the event information 1204 may be stored in the FDS database 1206 in respective identity token request records and may include (1) an identifier of the HMA 504 (e.g., identifier “XYZ”, such as a DN of the HMA 504 or another identifier), (2) a location (LOCI) of the HMA 504 (e.g., or of a device executingP+S Ref. No.: DEXC / 0932PC 60DexcomRef. No.: 0932-PCT01the HMA 504), (3) a time (Tl) at which the identity token request message was received by the IVS entity 506, and (4) an identifier of the SS for which the identity token is requested (e.g., identifier “ABC,” such as a DN of the SS, another unique identifier associated with a certificate of the SS, or another identifier). In some embodiments, the event information may implicitly indicate an association between the HMA 504 and the SS for which the identity token is being requested. While FIG. 12 illustrates the IVS entity 506 recording event information associated with a single identity token request message from a single HMA 504, it should be appreciated that the IVS entity 506 may receive identity token request messages for numerous HMAs and devices within the health management system. As such, the FDS database 1206 may include a plurality of different identity token request records associated with the numerous HMAs and devices within the health management system.

[0241] As noted above, the FDS entity 1202 illustrated in FIG. 12 may be configured to detect unauthorized activity associated with at least one SS identified by the event information based on a number of times that respective identity tokens are requested for the at least one SS. In some embodiments, to detect the unauthorized activity, the FDS entity 1202 may be configured to sort the identity token request records stored in the FDS database 1206 according to a number of times that an identity token is requested for a particular device. For example, as illustrated at 1208, the FDS entity 1202 may sort the identity token request records in decreasing order according to the number of times that an identity token is requested for a particular SS (e.g., including a SS certificate). As an example, FIG. 12 illustrates at 1210 that (1) an identity token for a first SS associated with the identifier 123456 (e.g., associated with a certificate of that SS) has been requested 1,500 times, (2) an identity token for a second SS associated with the identifier 123457 (e.g., associated with a certificate of that SS) has been requested 825 times, (3) an identity token for a third SS associated with the identifier 000111 (e.g., associated with a certificate of that SS) has been requested 200 times, (4) an identity token for a fourth SS associated with the identifier 333444 (e.g., associated with a certificate of that SS) has been requested 5 times, and (5) an identity token for a fifth SS associated with the identifier 333555 (e.g., associated with a certificate of that SS) has been requested 2 times.

[0242] As shown at 1212, the FDS entity 1202 may then be configured to select the identity token request records in the FDS database 1206 that correspond to SSs for which an identity record has been requested more than a threshold number of times. In someP+S Ref. No.: DEXC / 0932PC 61DexcomRef. No.: 0932-PCT01embodiments, the FDS entity 1202 may select the threshold number of times to be large enough to (1) account for innocuous errors in obtaining an identity record for a particular device (e.g., poor connection, request timeout, a software bug, etc.) and to (2) account for the particular device connecting with several other devices or other partner devices. For example, in some cases, an SS may be expected to be able to communicate with several devices, partner devices, or a combination thereof, such as an HMA 504 on a smartphone, a receiver device, an insulin pump, a smart watch, etc. As such, the threshold number of times may be selected to be large enough to allow the SS to connect with one or more of these devices or partner devices. Additionally, the FDS entity 1202 may also select the threshold number of times to be small enough to significantly reduce the risk that identity tokens are being requested for unauthorized devices.

[0243] In the example shown in FIG. 12, the threshold number of times may be selected by the FDS entity 1202 to be 25. Accordingly, in this case, as shown at 1214, the FDS entity 1202 may be configured to select the identity records corresponding to the SS with the identifier 123456, the SS with the identifier 123457, and the SS with the identifier 000111, since identity tokens for each of these SSs have been requested more than 25 times. In some cases, because the number of times that identity tokens have been requested for these SSs is greater than 25 times, this may indicate that these SSs are associated with unauthorized activity, such as the certificates associated with these SSs being duplicated and used in an attempt to manufacture fraudulent SS devices that may not have been approved by an appropriate health regulatory body (e.g., FDA) and give them access to the health management system.

[0244] In some embodiments, as shown at 1216, after selecting identity token request records, the FDS entity 1202 may be configured to send one or more revocation request signals to the DMS entity 508 to request that the respective certificates associated with the SSs corresponding to the selected identity token request records be revoked. In some embodiments, the FDS entity 1202 may be configured (e.g., by an operator, automatically based on an algorithm, semi-automatically, etc.) to send the one or more revocation signals to request that the respective certificates (e.g., a public certificate and a private certificate pair) associated with one or more SSs, one or more HMAs, one or more receivers, one or more proxies, etc., if it is determined that an associated private certificate or key (e.g., stored on an SS, stored on a mobile device or part of an HMA, stored on a receiver, stored on a proxy, etc.) has been compromised (e.g., published orP+S Ref. No.: DEXC / 0932PC 62DexcomRef. No.: 0932-PCT01leaked to the internet, otherwise made available to the public, compromised in some way, etc.). In some embodiments, when the DMS entity 508 receives the one or more revocation request signals, the DMS entity 508 may update identity records associated with these SSs (e.g., and with these SSs’ certificates) to indicate that the certificate statuses of these SSs are revoked, which may prevent any further unauthorized devices from using the certificates of these SSs to request identity tokens to establish connections or access the health management system.

[0245] In some embodiments, as shown at 1218, prior to sending the one or more revocation request signals, the FDS entity 1202 may be further optionally configured to receive input (e.g., from an operator of the FDS entity 1202) confirming or denying the unauthorized activity associated with the SSs that corresponds to the selected identity token request records. In some embodiments, if the FDS entity 1202 receives an input confirming the unauthorized activity, the FDS entity 1202 may proceed with sending the one or more revocation request signals to the DMS entity 508. If, however, the FDS entity 1202 receives input denying the unauthorized activity (e.g., from an operator or administrator of the FDS entity), the FDS entity 1202 may refrain from transmitting the one or more revocation request signals to the DMS entity 508.

[0246] FIG. 13 illustrates a scenario in which the FDS entity 1202 may detect unauthorized activity associated with at least one SS, such as the SS 502, identified by the event information based on a time differential between a first time at which a first identity token request message is received for the at least one SS and a second time at which a subsequent or most-recent identity token request message is received for the at least one SS.

[0247] For example, when a first identity token request message is received for an SS, this may implicitly indicate the SS has been deployed on to a user and that a sensor session (e.g., analyte monitoring session) has begun on this SS. Typically, this sensor session may last between 10 to 15 days, after which the SS may be discarded by the user. However, a certificate of this SS may be valid for a period of up to 2 years to account for a period of time during which the SS may be stored after being manufactured and before being deployed onto a user (e.g., including time that is spent traveling through a supply chain, being on a shelf or in inventory such as at a pharmacy or store). Accordingly, because the certificate of this SS may be valid for up to two years, this certificate has the potential to be duplicated and used by other unauthorized devices even after expiration ofP+S Ref. No.: DEXC / 0932PC 63DexcomRef. No.: 0932-PCT01the 10-to-15-day sensor session associated with the SS.

[0248] Such unauthorized activity, however, may be detected and prevented by the FDS entity 1202 based on a time differential between a first time at which a first identity token request message is received for the SS and a second time at which a subsequent identity token request message is received for the SS (e.g., using a certificate associated with the SS). For example, if the FDS entity 1202 detects that the time differential associated with the SS’s certificate is greater than a threshold time differential (e.g., longer than a sensor session), the FDS entity 1202 may be configured to send a revocation request signal to the DMS entity 508 to update an identity record associated with the SS (e.g., and the SS’s certificate) to indicate that the certificate status of the certificate of the SS is revoked, which may prevent any unauthorized devices from using the certificate of this SS to request identity tokens to access the health management system.

[0249] For example, as shown in FIG. 13, the IVS entity 506 may receive an identity token request message from the HMA 504, requesting an identity token for an SS, such as the SS 502. It should be appreciated that, while FIG. 13 illustrates that identity token request message being received from the HMA 504, the identity token request message may be received from another device, such as a proxy device 1002 or another device described herein that transmits identity token request messages to the IVS entity 506.

[0250] After receiving the identity token request message from the HMA 504, the IVS entity 506 may report event information 1302 to the FDS database 1206. The event information 1302 may be stored in the FDS database 1206 in respective identity token request records and may include (1) an identifier of the HMA 504 (e.g., identifier “XYZ,” such as a DN of the HMA 504 or another identifier), (2) a location (LOCI) of the HMA 504 (e.g., or of a device executing the HMA 504), (3) a time (Tl) at which the identity token request message was received by the IVS entity 506, and (4) an identifier of the SS for which the identity token is requested (e.g., identifier “ABC,” such as a DN of the SS or another identifier). In some embodiments, the event information 1302 may implicitly indicate an association between the HMA 504 and the SS for which the identity token is being requested. While FIG. 13 only illustrates the IVS entity 506 recording event information 1302 associated with a single identity token request message from a single HMA 504, it should be appreciated that the IVS entity 506 may receive identity token request messages for numerous HMAs and devices within the health management system. As such, the FDS database 1206 may include a plurality of different identity token requestP+S Ref. No.: DEXC / 0932PC 64DexcomRef. No.: 0932-PCT01records associated with the numerous HMAs and devices within the health management system.

[0251] As noted above, the FDS entity 1202 illustrated in FIG. 13 may be configured to detect unauthorized activity associated with at least one SS identified by the event information 1302 based on a time differential between a first time (Tl) at which a first identity token request message is received for a particular device and a second time (T2) at which a subsequent or most-recent identity token request message is received for the particular device (e.g., including a SS certificate). In some embodiments, to detect the unauthorized activity, the FDS entity 1202 may be configured to sort the identity token request records stored in the FDS database 1206 in a decreasing order according to time differentials, as shown at 1304. As shown at 1306, after sorting, FIG. 13 illustrates that (1) a first SS with the identifier 123456 (e.g., associated with a certificate of that SS) is associated with a time differential of 365 days between a first identity token request for this SS and a most-recent identity token request for this SS, (2) a second SS with the identifier 123457 (e.g., associated with a certificate of that SS) is associated with a time differential of 60 days between a first identity token request for this SS and a most-recent identity token request for this SS, (3) a third SS with the identifier 000111 (e.g., associated with a certificate of that SS) associated with a time differential of 30 days between a first identity token request for this SS and a most-recent identity token request for this SS, (4) a fourth SS with the identifier 333444 (e.g., associated with a certificate of that SS) is associated with a time differential of 2 days between a first identity token request for this SS and a most-recent identity token request for this SS, and (5) a fifth SS with the identifier 333555 (e.g., associated with a certificate of that SS) is associated with a time differential of 1 day between a first identity token request for this SS and a most-recent identity token request for this SS.

[0252] As shown at 1308, the FDS entity 1202 may then be configured to select the identity token request records in the FDS database 1206 that correspond to SSs having a time differential between a first identity token request and a most-recent identity token request greater than a threshold time differential. In some embodiments, the FDS entity 1202 may select the threshold time differential to be large enough to account for variations in sensor session length and to allow for an SS to be paired or repaired with different devices during a sensor session. Additionally, the FDS entity 1202 may also select the threshold time differential to be small enough to significantly reduce the risk that identityP+S Ref. No.: DEXC / 0932PC 65DexcomRef. No.: 0932-PCT01tokens are being requested for unauthorized devices.

[0253] In the example shown in FIG. 13, the threshold time differential may be selected by the FDS entity 1202 to be 15 days, which is a maximum duration sensor session of an SS is expected to last. Accordingly, in this case, as shown at 1310, the FDS entity 1202 may be configured to select the identity records corresponding to the SS with the identifier 123456, the SS with the identifier 123457, and the SS with the identifier 000111, since each of these SSs have time differentials greater than 15 days. In some cases, because the time differentials for these SSs are greater than 15 days (e.g., long after a sensor session associated with these SSs is expected to last), this may indicate that these SSs are associated with unauthorized activity, such as the certificates associated with these SSs being duplicated and used in an attempt to manufacture fraudulent SS devices that may not have been approved by an appropriate health regulatory body (e.g., FDA) and gain access to the health management system.

[0254] In some embodiments, as shown at 1312, after selecting identity token request records, the FDS entity 1202 may be configured to send one or more revocation request signals to the DMS entity 508 to request that the respective certificates associated with the SSs corresponding to the selected identity token request records be revoked. In some embodiments, when the DMS entity 508 receives the one or more revocation request signals, the DMS entity 508 may update identity records associated with these SSs (e.g., and with these SSs’ certificates) to indicate that the certificate statuses of these SSs are revoked, which may prevent any further unauthorized devices from using the certificates of these SSs to request identity tokens to establish connections or access the health management system.

[0255] In some embodiments, as shown at 1314, prior to sending the one or more revocation request signals, the FDS entity 1202 may be further optionally configured to receive input (e.g., from an operator of the FDS entity 1202) confirming or denying the unauthorized activity associated with the SSs that corresponds to the selected identity token request records. In some embodiments, if the FDS entity 1202 receives an input confirming the unauthorized activity, the FDS entity 1202 may proceed with sending the one or more revocation request signals to the DMS entity 508. If, however, the FDS entity 1202 receives input denying the unauthorized activity (e.g., from an operator or administrator of the FDS entity), the FDS entity 1202 may refrain from transmitting the one or more revocation request signals to the DMS entity 508.P+S Ref. No.: DEXC / 0932PC 66DexcomRef. No.: 0932-PCT01

[0256] FIG. 14 illustrates a scenario in which the FDS entity 1202 may detect unauthorized activity associated with at least one HMA, such as the HMA 504, identified by the event information based on a number of identity tokens that are requested by the at least one HMA for different SSs.

[0257] For example, when a user deploys and begins to use an SS, an HMA of a display device of the user may request an identity token for that SS. The user may continue to use this SS until a sensor session associated with that SS expires, which is typically between 10 to 15 days. Thereafter, the user may deploy and begin using a new SS, which requires the HMA to request another identity token for the new SS. As a result, over the course of a period of time during which a certificate of the HMA is valid, which for example may be about 2 years, the HMA may be expected to request identity tokens for a threshold number of different SSs. Accordingly, this threshold number of different SSs may be used to determine whether there is any unauthorized activity associated with the HMA since, if the HMA requests identity tokens for more than the threshold number of different SSs, this may indicate that the certificate of the HMA may have been duplicated and is being used with other non-legitimate or non-authorized HMAs.

[0258] For example, as shown in FIG. 14, the IVS entity 506 may receive an identity token request message from the HMA 504, requesting an identity token for an SS. It should be appreciated that, while FIG. 14 illustrates that identity token request message being received from the HMA 504, the identity token request message may be received from another device, such as a proxy device 1002 or another device described herein that transmits identity token request messages to the IVS entity 506.

[0259] After receiving the identity token request message from the HMA 504, the IVS entity 506 may report event information 1402 to the FDS database 1206. The event information 1402 may be stored in the FDS database 1206 in respective identity token request records and may include (1) an identifier of the HMA 504 (e.g., identifier “XYZ,” such as a DN of the HMA 504 or another identifier), (2) a location (LOCI) of the HMA 504 (e.g., or of a device executing the HMA 504), (3) a time (Tl) at which the identity token request message was received by the IVS entity 506, and (4) an identifier of the SS for which the identity token is requested (e.g., identifier “ABC,” such as a DN of the SS or another identifier). In some embodiments, the event information 1402 may implicitly indicate an association between the HMA 504 and the SS for which the identity token is being requested. While FIG. 14 only illustrates the IVS entity 506 recording eventP+S Ref. No.: DEXC / 0932PC 67DexcomRef. No.: 0932-PCT01information 1402 associated with a single identity token request message from a single HMA, it should be appreciated that the IVS entity 506 may receive multiple identity token request messages from the single HMA for different SSs over the course of a validity period of a certificate of this HMA. Additionally, it should be appreciated that the IVS entity 506 may also receive multiple identity token request messages from multiple other HMAs requesting identity tokens for other SSs. As such, the FDS database 1206 may include a plurality of different identity token request records associated with the numerous devices (e.g., display devices executing HMAs, SSs, proxy devices, etc.) within the health management system.

[0260] As noted above, the FDS entity 1202 illustrated in FIG. 14 may be configured to detect unauthorized activity associated with at least one HMA, such as the HMA 504, identified by the event information 1402 based on a number of identity tokens that are requested by the at least one HMA for different SSs. In some embodiments, to detect the unauthorized activity, the FDS entity 1202 may be configured to sort the identity token request records stored in the FDS database 1206 from each different HMA in decreasing order according to a number of identity tokens that are requested for each different HMA (e.g., grouped by an identifier of a respective certificate of each HMA), as shown at 1404. For example, as shown at 1406, after sorting, FIG. 14 illustrates that (1) a first HMA associated with the identifier XYZ-1 (e.g., associated with a certificate of the first HMA) has requested identity tokens for 10,000 different SSs, (2) a second HMA associated with the identifier XYZ-2 (e.g., associated with a certificate of the second HMA) has requested identity tokens for 5,000 different SSs, (3) a third HMA associated with the identifier XYZ-3 (e.g., associated with a certificate of the third HMA) has requested identity tokens for 500 different SSs, (4) a fourth HMA associated with the identifier XYZ-4 (e.g., associated with a certificate of the third HMA) has requested identity tokens for 50 different SSs, and (5) a fifth HMA associated with the identifier XYZ-5 (e.g., associated with a certificate of the third HMA) has requested identity tokens for 25 different SSs.

[0261] As shown at 1408, the FDS entity 1202 may then be configured to select the identity token request records in the FDS database 1206 that correspond to HMAs that have requested identity tokens for more than a threshold number (T) of different SSs. In some embodiments, the FDS entity 1202 may select the threshold number of different SSs to be large enough to account for a minimum number of different SSs that one HMA may be expected to request identity tokens for during a period of time that a certificate ofP+S Ref. No.: DEXC / 0932PC 68DexcomRef. No.: 0932-PCT01the HMA is valid for (e.g., two years) as well as to account for a user having trouble with a number of SSs and having to deploy and use new SSs prior to expiration of the typical 10-day or 15-day sensor session. For example, over the course of a year, the HMA may request about 36 different identity tokens for SSs assuming that the user deploys and begins to use a different SS every 10 days. Since a certificate of the HMA is valid for a period of two years, the HMA may be expected to request a minimum of about 72 different identity tokens for 72 different SSs over the course the two-year period during which the certificate of the HMA is valid. Further, there may be instances in which the user may have trouble with a certain SS and may have to switch to using a new SS prior to expiration of a typical 10-day sensor session of the certain SS (e.g., due to a sensor failure, accidental removal of a sensor, etc.), causing the HMA to request more identity tokens over the course of the two-year period than the minimum.

[0262] Accordingly, the FDS entity 1202 may select the threshold number of different SSs to be large enough to account for this minimum number of different SSs that an HMA may be expected to request identity tokens for during the period of time that the certificate of the HMA is valid for and to account for the possibility that the user may have to deploy and use additional SSs prior to expiration of a typical 10-day sensor session. For example, as illustrated in FIG. 14, the threshold number (T) of different SSs may be selected by the FDS entity 1202 to be 200 different SSs (or transmitters of SSs).

[0263] Accordingly, in this case, as shown at 1410, the FDS entity 1202 may be configured to select the identity records corresponding to the first HMA associated with the identifier XYZ-1, the second HMA associated with the identifier XYZ-2, and third HMA associated with the identifier XYZ-3, since each of these HMAs have requested identity tokens for more than 200 SSs. In some cases, because these HMAs have requested identity tokens for more than 200 SSs, this may indicate that these HMAs are associated with unauthorized activity, such as the certificates associated with these HMAs being duplicated and used in an attempt to publish or manufacture unauthorized HMAs (e.g., mobile applications or display devices) which have not been approved by a health regulatory body (e.g., FDA) and are capable connecting to legitimate SSs.

[0264] In some embodiments, as shown at 1412, after selecting identity token request records, the FDS entity 1202 may be configured to send one or more revocation request signals to the DMS entity 508 to request that the respective certificates associated with the HMAs (e.g., HMAs XYZ-1, XYZ-2, and XYZ-3) corresponding to the selectedP+S Ref. No.: DEXC / 0932PC 69DexcomRef. No.: 0932-PCT01identity token request records be revoked. In some embodiments, when the DMS entity 508 receives the one or more revocation request signals, the DMS entity 508 may update identity records associated with these HMAs (e.g., HMAs XYZ-1, XYZ-2, and XYZ-3, and their respective certificates or identities) to indicate that the certificate statuses of these HMAs are revoked, which may prevent any further unauthorized HMAs from using the certificates of these HMAs to request identity tokens to establish connections or access the health management system.

[0265] In some embodiments, at shown at 1414, prior to sending the one or more revocation request signals, the FDS entity 1202 may be further optionally configured to receive input (e.g., from an operator of the FDS entity 1202) confirming or denying the unauthorized activity associated with the HMAs that correspond to the selected identity token request records. In some embodiments, if the FDS entity 1202 receives an input confirming the unauthorized activity, the FDS entity 1202 may proceed with sending the one or more revocation request signals to the DMS entity 508. If, however, the FDS entity 1202 receives input denying the unauthorized activity (e.g., from an operator or administrator of the FDS entity), the FDS entity 1202 may refrain from transmitting the one or more revocation request signals to the DMS entity 508.

[0266] FIG. 15 illustrates a scenario in which the FDS entity 1202 may detect unauthorized activity associated with at least one SS identified by the event information based on a number of identity tokens that are requested for the at least one SS after expiration of a validity period associated with the at least one SS (e.g., based on a length of the sensor session associated with the SS).

[0267] For example, in some embodiments, when the at least one SS is deployed onto a user and is paired with an HMA, the HMA may send an identity token request message to the IVS entity 506 that requests an identity token for the at least one SS. Additionally, after the at least one SS is deployed onto the user, a sensor session of the at least one SS may be started, which may have a duration lasting anywhere between 10 days, 15 days, or 31 days. The duration of this sensor session may therefore define a validity period during which identity tokens for the at least one SS may be legitimately requested. However, any identity tokens that are requested for the at least one SS after expiration of the validity period may amount to unauthorized activity, which may be detected by the FDS entity 1202 and prevented.P+S Ref. No. : DEXC / 0932PC 70DexcomRef. No.: 0932-PCT01

[0268] For example, in some embodiments, when an identity token request record associated with the at least one SS is first saved into the FDS database 1206 (e.g., the at least one SS is new), the FDS entity 1202 may be configured to update this record with a validity period associated with the at least one SS. The FDS entity 1202 may then monitor identity token requests for the at least one SS in view of the validity period associated with the at least one SS. In some embodiments, based on the monitoring, if the FDS entity 1202 detects that the identity tokens are being requested for the at least one SS after expiration of the validity period, the FDS entity 1202 may be configured to send a revocation request signal to the DMS entity 508 to update an identity record associated with the SS (e.g., and the SS’s certificate) to indicate that the certificate status of the certificate of the at least one SS is revoked, which may prevent any unauthorized devices from using the certificate of the at least one SS to request identity tokens to access the health management system.

[0269] For example, as shown in FIG. 15, the IVS entity 506 may receive an identity token request message from an HMA, such as the HMA 504, requesting an identity token for an SS, such as the SS 502. It should be appreciated that, while FIG. 15 illustrates that identity token request message being received from the HMA 504, the identity token request message may be received from another device, such as a proxy device 1002 or another device described herein that transmits identity token request messages to the IVS entity 506.

[0270] After receiving the identity token request message from the HMA 504, the IVS entity 506 may report event information 1502 to the FDS database 1206 associated with the identity token request message. The event information 1502 may be stored in the FDS database 1206 in an identity token request record and may include (1) an identifier of the HMA 504 (e.g., identifier “XYZ,” such as a DN of the HMA 504 or another identifier), (2) a location (LOCI) of the HMA 504 (e.g., or of a device executing the HMA 504), (3) a time (Tl) at which the identity token request message was received by the IVS entity 506, and (4) an identifier of the SS for which the identity token is requested (e.g., identifier “ABC,” such as a DN of the SS, another unique identifier associated with a certificate of the SS, or another identifier). In some embodiments, the event information 1502 may implicitly indicate an association between the HMA 504 and the SS for which the identity token is being requested. While FIG. 15 only illustrates the IVS entity 506 recording event information 1502 associated with a single identity token request messageP+S Ref. No.: DEXC / 0932PC 71DexcomRef. No.: 0932-PCT01from a single HMA, it should be appreciated that the IVS entity 506 may receive identity token request messages for numerous devices within the health management system. As such, the FDS database 1206 may include a plurality of different identity token request records associated with the numerous devices within the health management system.

[0271] In some embodiments, as shown at 1504, the FDS entity 1202 may determine whether the SS identified in the identity token request record stored in the FDS database 1206 is a new SS (e.g., an SS for which there are no other identity token requests records stored in the FDS database 1206). In some embodiments, if the FDS entity 1202 determines that the SS identified in the identity token request record stored in the FDS database 1206 is a new SS, the FDS entity 1202 may be configured to update the identity token request record to include a validity period for the SS (e.g., and the SS's certificate), as shown at 1506. In some embodiments, the FDS entity 1202 may determine the validity period based on the time at which the identity token request message associated with the SS was received (Now) at the IVS entity 506 and based on a sensor session duration or lifetime (Lifetime(Device Type)) associated with the SS. In some embodiments, the FDS entity 1202 may determine the sensor session duration associated with the SS based on the identifier of the SS (e.g., a serial number, a certificate associated with the SS, etc.). For example, in some embodiments, the identifier of the SS may indicate a particular device type of the SS, which may indicate that the SS is associated with one of a 10-day sensor session duration, a 15-day sensor session duration, a 31-day sensor session duration, or another sensor session duration. In some embodiments, the validity period may be expressed as a difference between a validity start time and a validity end time. For example, the validity start time (e.g., time X) may be the time at which the identity token request message was received at the IVS entity 506. The validity end time may then be equal to the start time plus the sensor session duration or lifetime associated with the device type of the SS (e.g., validity end time = X + lifetime, where X is now or current time and the lifetime depends on a device type of SS).

[0272] As noted above, the FDS entity 1202 illustrated in FIG. 15 may be configured to detect unauthorized activity associated with at least one SS identified by the event information 1502 stored in the FDS database 1206 based on a number of identity tokens that are requested for the at least one SS after expiration of validity period associated with the at least one SS. For example, in some embodiments, as shown at 1507, the FDS entity 1202 may be configured to select identity token request records stored in the FDSP+S Ref. No.: DEXC / 0932PC 72DexcomRef. No.: 0932-PCT01database 1206 associated with SSs for which one or more identity tokens have been requested after expiration of respective validity periods associated with these SSs.

[0273] As shown at 1508, the FDS entity 1202 may then be configured to sort the selected identity token request records in decreasing order of a number of identity tokens that have been requested after the expiration of the respective validity periods associated with the SSs corresponding to the selected identity token request records. For example, as shown at 1510, after sorting of the identity token request records, FIG. 15 illustrates that (1) an identity token for a first SS associated with the identifier 123456 has been requested 10,000 times, (2) an identity token for a second SS associated with the identifier 1234567 has been requested 2,000 times, and (3) an identity token for a third SS associated with the identifier 000111 has been requested 500 times.

[0274] In some embodiments, after sorting, the FDS entity 1202 may be configured to flag, as being associated with unauthorized activity, a threshold number of the selected identity token request records associated with SSs having the highest number of identity tokens requested after expiration of the respective validity periods associated with these SSs. For example, the threshold number of identity token requests selected by the FDS entity 1202 may be 10. For example, with reference to FIG. 15, the FDS entity 1202 may flag the identity records associated with the first SS, the second SS, and the third SS as being associated with unauthorized activity, as shown at 1510.

[0275] Thereafter, as shown at 1512, the FDS entity 1202 may be further optionally configured to receive input (e.g., from an operator of the FDS entity 1202) confirming or denying the unauthorized activity associated with the SSs that correspond to the flagged identity token request records. In some embodiments, as shown at 1514, if the FDS entity 1202 receives an input confirming the unauthorized activity, the FDS entity 1202 may then be configured to send one or more revocation request signals to the DMS entity 508 to request that the respective certificates associated with the SSs corresponding to the flagged identity token request records be revoked. In some embodiments, when the DMS entity 508 receives the one or more revocation request signals, the DMS entity 508 may update identity records associated with these SSs (e.g., and with these SSs’ certificates) to indicate that the certificate statuses of these SSs are revoked, which may prevent any further unauthorized SSs from using the certificates of the flagged SSs to request identity tokens to establish connections or access the health management system. If, however, the FDS entity 1202 receives input denying the unauthorized activity (e.g., from an operatorP+S Ref. No.: DEXC / 0932PC 73DexcomRef. No.: 0932-PCT01or administrator of the FDS entity), the FDS entity 1202 may refrain from transmitting the one or more revocation request signals to the DMS entity 508.

[0276] FIG. 16 illustrates a scenario in which the FDS entity 1202 may detect unauthorized activity associated with at least one HMA, such as the HMA 504, identified by the event information based on a threshold number of different locations in which identity tokens are requested by the at least one HMA for different SSs. In some embodiments, the threshold is set based on a number of different locations in which an HMA certificate is being used. These may include locations associated with overlapping sensor sessions, locations used within a short time period that would not be reasonably possible given realistic travel speeds, or a combination thereof.. For example, the threshold may be set to three different locations where the HMA certificate is used in overlapping different sensor sessions that are too far apart, or where a of distance between the locations is too great for practical travel speeds (e.g., locations separated by 10,000 miles, 5000 miles, 1000 miles, etc.).

[0277] For example, when a user deploys and begins using an SS (e.g., SS 502), an HMA, such as the HMA 504, may request an identity token for that SS. The user may continue using this SS until the associated sensor session expires, which is usually after 10 to 15 days. At that point, the user may deploy a new SS, requiring the HMA to request another identity token. In most cases, the new SS is deployed in the same general location as the previous SS, such as within the user’s home or a city, state, etc. Consequently, the location from which the HMA requests identity tokens for successive SSs may remain generally consistent. In some instances, however, the user may travel before deploying the new SS, resulting in the HMA requesting the identity token from a different location than for the previous SS. Nevertheless, when the HMA is used by the same user, the number of different locations from which it requests identity tokens for various SSs during the validity period of the HMA’s certificate (e.g., generally two years) is relatively low (e.g., below a threshold number of different locations). Accordingly, this threshold number of different locations may be used to determine whether there is any unauthorized activity associated with the HMA since, if the HMA requests identity tokens for SSs in a number of different locations that is more than the threshold number of different locations, this may indicate that the certificate of the HMA may have been duplicated and is being used with other non-legitimate or non-authorized HMAs.

[0278] For example, as shown in FIG. 16, the IVS entity 506 may receive an identityP+S Ref. No.: DEXC / 0932PC 74DexcomRef. No.: 0932-PCT01token request message from an HMA, such as HMA 504, requesting an identity token for an SS, such as SS 502. It should be appreciated that, while FIG. 16 illustrates that identity token request message being received from the HMA 504, the identity token request message may be received from another device, such as a proxy device 1002 or another device described herein that transmits identity token request messages to the IVS entity 506.

[0279] After receiving the identity token request message from the HMA 504, the IVS entity 506 may report event information 1602 to the FDS database 1206. The event information 1602 may be stored in the FDS database 1206 in respective identity token request records and may include (1) an identifier of the HMA 504 (e.g., identifier “XYZ,” such as a DN of the HMA 504 or another identifier), (2) a location (e.g., LOCI, such as a GPS location, city, state, country, etc.) of the HMA 504 (e.g., or of a device executing the HMA 504), (3) a time (Tl) at which the identity token request message was received by the IVS entity 506, and (4) an identifier of the SS for which the identity token is requested (e.g., identifier “ABC,” such as a DN of the SS, another unique identifier associated with a certificate of the SS, or another identifier). In some embodiments, the event information 1602 may implicitly indicate an association between the HMA 504 and the SS for which the identity token is being requested. While FIG. 16 only illustrates the IVS entity 506 recording event information 1602 associated with a single identity token request message from a single HMA, it should be appreciated that the IVS entity 506 may receive multiple identity token request messages from the single HMA for different SSs over the course of a validity period of a certificate of this HMA. Additionally, it should be appreciated that the IVS entity 506 may also receive multiple identity token request messages from multiple other HMA requesting identity tokens for other SSs. As such, the FDS database 1206 may include a plurality of different identity token request records associated with the numerous devices within the health management system.

[0280] As noted above, the FDS entity 1202 illustrated in FIG. 16 may be configured to detect unauthorized activity associated with at least one HMA identified by the event information 1602 based on a threshold number of different locations in which identity tokens are requested by the at least one HMA for different SSs. In some embodiments, to detect the unauthorized activity, the FDS entity 1202 may be configured to sort the identity token request records stored in the FDS database 1206 from each different HMA in decreasing order according to a number of different locations at which each differentP+S Ref. No.: DEXC / 0932PC 75DexcomRef. No.: 0932-PCT01HMA has requested identity tokens for the different SSs, as shown at 1604. For example, as shown at 1606, FIG. 16 illustrates that (1) a first HMA associated with the identifier XYZ-1 has requested identity tokens for different SSs from 100 different locations, (2) a second HMA associated with the identifier XYZ-2 has requested identity tokens for different SSs from 25 different locations, (3) a third HMA associated with the identifier XYZ-3 has requested identity tokens for different SSs from 10 different locations, (4) a fourth HMA associated with the identifier XYZ-4 has requested identity tokens for different SSs from 4 different locations, and (5) a fifth HMA associated with the identifier XYZ-5 has requested identity tokens for different SSs from 3 different locations. In some embodiments, two locations may be different from each other if they are significantly far apart from each other, such as in two different countries, two different states, two different cities, more than a threshold distance apart, etc.

[0281] As shown at 1608, the FDS entity 1202 may then be configured to select the identity token request records in the FDS database 1206 that correspond to HMAs that have requested identity tokens from more than a threshold number of different locations. In some embodiments, the FDS entity 1202 may select the threshold number of different locations to be large enough to account for normal travel of a user over the course of a period of time that a certificate of the HMA is valid for (e.g., two years). Additionally, the FDS entity 1202 may also select the threshold number of different locations to be small enough to significantly reduce the risk that a certificate of the HMA could be copied and used to request identity tokens for unauthorized devices in many different locations. For example, as illustrated in FIG. 16, the threshold number of different locations may be selected by the FDS entity 1202 to be 4 different locations. The threshold may be further based on 4 different locations associated with concurrent or overlapping sensors sessions, locations that are above a distance threshold away (e.g., 5,000 miles), or a combination thereof.

[0282] Accordingly, in this case, as shown at 1610, the FDS entity 1202 may be configured to select the identity records corresponding to the first HMA associated with the identifier XYZ-1, the second HMA associated with the identifier XYZ-2, and third HMA associated with the identifier XYZ-3, since each of these HMAs have requested identity tokens for different SSs from more than 4 different locations. In some cases, because these HMAs have requested identity tokens for different SSs in more than 4 different locations, this may indicate that these HMAs are associated with unauthorizedP+S Ref. No.: DEXC / 0932PC 76DexcomRef. No.: 0932-PCT01activity, such as the certificates associated with these HMAs being duplicated and used in an attempt to publish or manufacture unauthorized HMAs (e.g., mobile applications or display devices) which have not been approved by a health regulatory body (e.g., FDA) and are capable connecting to legitimate SSs.

[0283] In some embodiments, as shown at 1612, after selecting identity token request records, the FDS entity 1202 may be configured to send one or more revocation request signals to the DMS entity 508 to request that the respective certificates associated with the HMAs corresponding to the selected identity token request records be revoked. In some embodiments, when the DMS entity 508 receives the one or more revocation request signals, the DMS entity 508 may update identity records associated with these HMAs (e.g., HMAs XYZ-1, XYZ-2, and XYZ-3, and their respective certificates or identities) to indicate that the certificate statuses of these HMAs are revoked, which may prevent any further unauthorized HMAs from using the certificates of these HMAs to request identity tokens to access the health management system.

[0284] In some embodiments, as shown at 1614, prior to sending the one or more revocation request signals, the FDS entity 1202 may be further configured to receive input (e.g., from an operator of the FDS entity 1202) confirming or denying the unauthorized activity associated with the HMAs that correspond to the selected identity token request records. In some embodiments, if the FDS entity 1202 receives an input confirming the unauthorized activity, the FDS entity 1202 may proceed with sending the one or more revocation request signals to the DMS entity 508. If, however, the FDS entity 1202 receives input denying the unauthorized activity, the FDS entity 1202 may refrain from transmitting the one or more revocation request signals to the DMS entity 508.Example Operations

[0285] FIG. 17 shows an example of a method 1700 of communication by an identity verification service (IVS) entity in a health management system, such as IVS entity 506 described above with respect to FIGS. 5A, 5B, and / or 6-16.

[0286] Method 1700 begins at step 1705 with receiving, from a requesting node in the health management system, an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node. In some cases, the operations of this step refer to, or may be performed by, circuitry for receiving and / orP+S Ref. No.: DEXC / 0932PC 77DexcomRef. No.: 0932-PCT01code for receiving as described with reference to FIG. 20.

[0287] Method 1700 then proceeds to step 1710 with storing event information, associated with the identity token request message in a database for detecting unauthorized activity associated with at least one of the requesting node or the target node. In some cases, the operations of this step refer to, or may be performed by, circuitry for storing and / or code for storing as described with reference to FIG. 20.

[0288] Method 1700 then proceeds to step 1715 with generating the identity token for the target node based on the identity token request message, wherein the identity token includes, at least, a certificate status associated with the certificate of the target node. In some cases, the operations of this step refer to, or may be performed by, circuitry for generating and / or code for generating as described with reference to FIG. 20.

[0289] Method 1700 then proceeds to step 1720 with transmitting the identity token for the target node to the requesting node. In some cases, the operations of this step refer to, or may be performed by, circuitry for transmitting and / or code for transmitting as described with reference to FIG. 20.

[0290] In some aspects, the requesting node and the target node are a health monitoring application.

[0291] In some aspects, the requesting node is a health monitoring application; and the target node is an analyte sensor system.

[0292] In some aspects, the event information comprises at least one of: an identifier of the requesting node; a location of the requesting node; a time at which the identity token request message was received; or an identifier of the target node for which the identity token is requested.

[0293] In some aspects, the identity token request message further includes: a distinguished name (DN) of the requesting node; an indication of what data is being requested regarding the target node; a timestamp; and a signature generated by the target node.

[0294] In some aspects, the method 1700 further includes sending, to a device management service (DMS) entity based on the identity token request message, a request for an identity record associated with the target node. In some cases, the operations of this step refer to, or may be performed by, circuitry for sending and / or code for sending asP+S Ref. No.: DEXC / 0932PC 78DexcomRef. No.: 0932-PCT01described with reference to FIG. 20.

[0295] In some aspects, the request for the identity record associated with the target node includes: certificate unique identifier information of the certificate of the target node; a timestamp included in the identity token request message; and an indication of what data is being requested regarding the target node.

[0296] In some aspects, the method 1700 further includes receiving, from the DMS entity, the identity record associated with the target node based on the request for the identity record associated with the target node. In some cases, the operations of this step refer to, or may be performed by, circuitry for receiving and / or code for receiving as described with reference to FIG. 20.

[0297] In some aspects, generating the identity token for the target node is further based on the identity record associated with the target node received from the DMS entity.

[0298] In some aspects, the identity token for the target node further includes: a header; a payload; and a signature.

[0299] In some aspects, the header indicates: a token type of the identity token; and a signing algorithm used for the signature.

[0300] In some aspects, the payload includes at least: an issuer name associated with the certificate of the target node; a subject name associated with the certificate of the target node; the certificate status associated with the certificate of the target node; and a public key of the IVS entity associated with the signature of the identity token for the target node.

[0301] In some aspects, the signature comprises a hash of the header and payload generated based on the signing algorithm and a private signing key of the IVS entity that corresponds to the public key.

[0302] In some aspects, the identity token for the target node has a validity period that is less than a validity period of the certificate of the target node.

[0303] In one aspect, method 1700, or any aspect related to it, may be performed by an apparatus, such as health management device 2000 of FIG.20, which includes various components operable, configured, or adapted to perform the method 1700. Health management device 2000 is described below in further detail.

[0304] Note that FIG. 17 is just one example of a method, and other methodsP+S Ref. No.: DEXC / 0932PC 79DexcomRef. No.: 0932-PCT01including fewer, additional, or alternative steps are possible consistent with this disclosure.

[0305] FIG. 18 shows an example of a method 1800 of communication by a requesting node in a health management system, such as the HMA 504 described above with respect to FIGS. 5A, 5B, and / or 6-16 or the proxy device 1002 described above with respect to FIGS. 10 and / or 11.

[0306] Method 1800 begins at step 1805 with transmitting an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node. In some cases, the operations of this step refer to, or may be performed by, circuitry for transmitting and / or code for transmitting as described with reference to FIG. 21.

[0307] Method 1800 then proceeds to step 1810 with receiving the identity token for the target node based on the identity token request message, wherein the identity token for the target node includes, at least, a certificate status associated with the certificate of the target node. In some cases, the operations of this step refer to, or may be performed by, circuitry for receiving and / or code for receiving as described with reference to FIG.21

[0308] Method 1800 then proceeds to step 1815 with establishing a connection with the target node when the certificate status, included in the identity token, indicates that the certificate of the target node is valid. In some cases, the operations of this step refer to, or may be performed by, circuitry for establishing and / or code for establishing as described with reference to FIG. 21.

[0309] In some aspects, the requesting node is a health monitoring application; and the target node is an analyte sensor system.

[0310] In some aspects, the requesting node is a proxy device having direct access to the internet; and the target node is a receiver device that lacks direct access to the internet.

[0311] In some aspects, the identity token for the target node further includes: a header; a payload; and a signature.

[0312] In some aspects, the header indicates: a token type of the identity token; and a signing algorithm used for the signature.P+S Ref. No.: DEXC / 0932PC 80DexcomRef. No.: 0932-PCT01

[0313] In some aspects, the payload includes at least: an issuer name associated with the certificate of the target node; a subject name associated with the certificate of the target node; the certificate status associated with the certificate of the target node; and a public key of an identity verification service (IVS) entity associated with the signature of the identity token for the target node.

[0314] In some aspects, the signature comprises a hash of the header and payload generated based on the signing algorithm and a private signing key of the IVS entity that corresponds to the public key.

[0315] In some aspects, the method 1800 further includes determining a validity of the identity token for the target node by verifying the signature with the public key of the IVS entity. In some cases, the operations of this step refer to, or may be performed by, circuitry for determining and / or code for determining as described with reference to FIG.21

[0316] In some aspects, establishing the connection with the target node is further based on the validity of the identity token.

[0317] In some aspects, the method 1800 further includes terminating a pairing procedure or connection establishment procedure for establishing the connection with the target node when at least one of the certificate status, included in the identity token, indicates that the certificate of the target node is invalid or a certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid. In some cases, the operations of this step refer to, or may be performed by, circuitry for terminating and / or code for terminating as described with reference to FIG. 21

[0318] In some aspects, the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when number of times that the identity token for the target node is requested is greater than or equal to a threshold number of times.

[0319] In some aspects, the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a time differential between a first time at which a first identity token for the target node is requested and a second time at with a second identity token for the target node is requested is greater than a threshold time differential.P+S Ref. No.: DEXC / 0932PC 81DexcomRef. No.: 0932-PCT01

[0320] In some aspects, the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a number of identity tokens that are requested for the target node after expiration of a validity period associated with the target node is greater than a threshold.

[0321] In some aspects, the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of identity tokens that are requested by the requesting node for different target nodes is greater than a threshold number of different target nodes.

[0322] In some aspects, the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of different locations in which identity tokens are requested by the requesting node for different target nodes is greater than or equal to a threshold.

[0323] In one aspect, method 1800, or any aspect related to it, may be performed by an apparatus, such as health management device 2100 of FIG.21, which includes various components operable, configured, or adapted to perform the method 1800. Health management device 2100 is described below in further detail.

[0324] Note that FIG. 18 is just one example of a method, and other methods including fewer, additional, or alternative steps are possible consistent with this disclosure.

[0325] FIG. 19 shows an example of a method 1900 of communication by a fraud detection service (FDS) entity in a health management system, such as FDS entity 1202 described above with respect to FIGS. 12-16.

[0326] Method 1900 begins at step 1905 with receiving event information from an identity verification service (IVS) entity in the health management system, wherein the event information is associated with one or more identity token request messages of a requesting node in the health management system that request at least one identity token be generated for a target node in the health management system. In some cases, the operations of this step refer to, or may be performed by, circuitry for receiving and / or code for receiving as described with reference to FIG. 22.

[0327] Method 1900 then proceeds to step 1910 with detecting, based on the event information, unauthorized activity associated with at least one of the requesting node or the target node. In some cases, the operations of this step refer to, or may be performedP+S Ref. No.: DEXC / 0932PC 82DexcomRef. No.: 0932-PCT01by, circuitry for detecting and / or code for detecting as described with reference to FIG.22.

[0328] Method 1900 then proceeds to step 1915 with sending, based on the detected unauthorized activity, one or more revocation request signals to a device management system (DMS) entity to request that that a certificate of at least one of the requesting node or the target node be revoked. In some cases, the operations of this step refer to, or may be performed by, circuitry for sending and / or code for sending as described with reference to FIG. 22

[0329] In some aspects, detecting the unauthorized activity is based on a number of times that the identity token for the target node is requested being greater than or equal to a threshold number of times.

[0330] In some aspects, detecting the unauthorized activity is based on a time differential between a first time at which a first identity token for the target node is requested and a second time at with a second identity token for the target node is requested being greater than a threshold time differential.

[0331] In some aspects, detecting the unauthorized activity is based on a number of identity tokens that are requested by the requesting node for different target nodes being greater than a threshold number of different target nodes.

[0332] In some aspects, detecting the unauthorized activity is based on a number of identity tokens that are requested for the target node after expiration of a validity period associated with the target node.

[0333] In some aspects, detecting the unauthorized activity is based on a threshold number of different locations in which identity tokens are requested by the requesting node for different target nodes.

[0334] In one aspect, method 1900, or any aspect related to it, may be performed by an apparatus, such as health management device 2200 of FIG.22, which includes various components operable, configured, or adapted to perform the method 1900. Health management device 2200 is described below in further detail.

[0335] Note that FIG. 19 is just one example of a method, and other methods including fewer, additional, or alternative steps are possible consistent with this disclosure.P+S Ref. No.: DEXC / 0932PC 83DexcomRef. No.: 0932-PCT01Example Health Management Device (s)

[0336] FIG. 20 depicts aspects of an example health management device 2000. In some aspects, health management device 2000 is an IVS entity, such as IVS entity 506 described above with respect to FIGS. 5A, 5B, and / or 6-16.

[0337] The health management device 2000 includes a processing system 2005 coupled to the transceiver 2075 (e.g., a transmitter and / or a receiver). The transceiver 2075 is configured to transmit and receive signals for the health management device 2000, such as the various signals as described herein. The processing system 2005 may be configured to perform processing functions for the health management device 2000, including processing signals received and / or to be transmitted by the health management device 2000.

[0338] The processing system 2005 includes one or more processors 2010. The one or more processors 2010 are coupled to a computer-readable medium / memory 2040 via a bus 2070. In certain aspects, the computer-readable medium / memory 2040 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 2010, cause the one or more processors 2010 to perform the method 1700 described with respect to FIG. 17 and / or one or more operations depicted and described with respect to any of FIGS. 5A, 5B, and / or 6-16. Note that reference to a processor performing a function of health management device 2000 may include one or more processors 2010 performing that function of health management device 2000.

[0339] In the depicted example, computer-readable medium / memory 2040 stores code (e.g., executable instructions), such as code for receiving 2045, code for generating 2050, code for storing 2055, code for transmitting 2060, and code for sending 2065. Processing of the code for receiving 2045, code for generating 2050, code for storing 2055, code for transmitting 2060, and code for sending 2065 may cause the health management device 2000 to perform the method 1700 described with respect to FIG. 17 and / or one or more operations depicted and described with respect to any of FIGS. 5A, 5B, and / or 6-16.

[0340] The one or more processors 2010 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium / memory 2040, including circuitry such as circuitry for receiving 2015, circuitry for generating 2020, circuitry for storing 2025, circuitry for transmitting 2030, and circuitry for sending 2035. ProcessingP+S Ref. No.: DEXC / 0932PC 84DexcomRef. No.: 0932-PCT01with circuitry for receiving 2015, circuitry for generating 2020, circuitry for storing 2025, circuitry for transmitting 2030, and circuitry for sending 2035 may cause the health management device 2000 to perform the method 1700 described with respect to FIG. 17 and / or one or more operations depicted and described with respect to any of FIGS. 5A, 5B, and / or 6-16.

[0341] FIG. 21 depicts aspects of an example health management device 2100. In some aspects, health management device 2100 is a requesting node. For example, in some embodiments, the health management device 2100 is a display device including the HMA 504 described above with respect to FIGS. 5A, 5B, and / or 6-16. In some embodiments, the health management device 2100 is the proxy device 1002 described above with respect to FIGS. 10 and / or 11.

[0342] The health management device 2100 includes a processing system 2105 coupled to the transceiver 2175 (e.g., a transmitter and / or a receiver). The transceiver 2175 is configured to transmit and receive signals for the health management device 2100, such as the various signals as described herein. The processing system 2105 may be configured to perform processing functions for the health management device 2100, including processing signals received and / or to be transmitted by the health management device 2100.

[0343] The processing system 2105 includes one or more processors 2110. The one or more processors 2110 are coupled to a computer-readable medium / memory 2140 via a bus 2170. In certain aspects, the computer-readable medium / memory 2140 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 2110, cause the one or more processors 2110 to perform the method 1800 described with respect to FIG. 18 and / or one or more operations depicted and described with respect to any of FIGS. 5A, 5B, and / or 6-16. Note that reference to a processor performing a function of health management device 2100 may include one or more processors 2110 performing that function of health management device 2100.

[0344] In the depicted example, computer-readable medium / memory 2140 stores code (e.g., executable instructions), such as code for transmitting 2145, code for receiving 2150, code for establishing 2155, code for determining 2160, and code for terminating 2165. Processing of the code for transmitting 2145, code for receiving 2150, code for establishing 2155, code for determining 2160, and code for terminating 2165 may causeP+S Ref. No.: DEXC / 0932PC 85DexcomRef. No.: 0932-PCT01the health management device 2100 to perform the method 1800 described with respect to FIG. 18 and / or one or more operations depicted and described with respect to any of FIGS. 5A, 5B, and / or 6-16.

[0345] The one or more processors 2110 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium / memory 2140, including circuitry such as circuitry for transmitting 2115, circuitry for receiving 2120, circuitry for establishing 2125, circuitry for determining 2130, and circuitry for terminating 2135. Processing with circuitry for transmitting 2115, circuitry for receiving 2120, circuitry for establishing 2125, circuitry for determining 2130, and circuitry for terminating 2135 may cause the health management device 2100 to perform the method 1800 described with respect to FIG. 18 and / or one or more operations depicted and described with respect to any of FIGS. 5 A, 5B, and / or 6-16.

[0346] FIG. 22 depicts aspects of an example health management device 2200. In some aspects, health management device 2200 is an FDS entity, such as FDS entity 1202 described above with respect to FIGS. 12-16.

[0347] The health management device 2200 includes a processing system 2205 coupled to the transceiver 2255 (e.g., a transmitter and / or a receiver). The transceiver 2255 is configured to transmit and receive signals for the health management device 2200, such as the various signals as described herein. The processing system 2205 may be configured to perform processing functions for the health management device 2200, including processing signals received and / or to be transmitted by the health management device 2200.

[0348] The processing system 2205 includes one or more processors 2210. The one or more processors 2210 are coupled to a computer-readable medium / memory 2230 via a bus 2250. In certain aspects, the computer-readable medium / memory 2230 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 2210, cause the one or more processors 2210 to perform the method 1900 described with respect to FIG. 19 and / or one or more operations depicted and described with respect to any of FIGS. 12-16. Note that reference to a processor performing a function of health management device 2200 may include one or more processors 2210 performing that function of health management device 2200.

[0349] In the depicted example, computer-readable medium / memory 2230 storesP+S Ref. No.: DEXC / 0932PC 86DexcomRef. No.: 0932-PCT01code (e.g., executable instructions), such as code for receiving 2235, code for detecting 2240, and code for sending 2245. Processing of the code for receiving 2235, code for detecting 2240, and code for sending 2245 may cause the health management device 2200 to perform the method 1900 described with respect to FIG. 19 and / or one or more operations depicted and described with respect to any of FIGS. 12-16.

[0350] The one or more processors 2210 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium / memory 2230, including circuitry such as circuitry for receiving 2215, circuitry for detecting 2220, and circuitry for sending 2225. Processing with circuitry for receiving 2215, circuitry for detecting 2220, and circuitry for sending 2225 may cause the health management device 2200 to perform the method 1900 described with respect to FIG. 19 and / or one or more operations depicted and described with respect to any of FIGS. 12-16.Example Clauses

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

[0352] Clause 1 : A method for communication by an identity verification service (IVS) entity in a health management system, comprising: receiving, from a requesting node in the health management system, an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node; storing event information, associated with the identity token request message, in a database for detecting unauthorized activity associated with at least one of the requesting node or the target node; generating the identity token for the target node based on the identity token request message, wherein the identity token includes, at least, a certificate status associated with the certificate of the target node; and transmitting the identity token for the target node to the requesting node.

[0353] Clause 2: The method of Clause 1, wherein the requesting node and the target node are a health monitoring application.

[0354] Clause 3: The method of any one of Clauses 1-2, wherein: the requesting node is a health monitoring application; and the target node is an analyte sensor system.

[0355] Clause 4: The method of any one of Clauses 1-3, wherein the event information comprises at least one of: an identifier of the requesting node; a location ofP+S Ref. No.: DEXC / 0932PC 87DexcomRef. No.: 0932-PCT01the requesting node; a time at which the identity token request message was received; or an identifier of the target node for which the identity token is requested.

[0356] Clause 5: The method of any one of Clauses 1-4, wherein the identity token request message further includes: distinguished name (DN) of the requesting node; an indication of what data is being requested regarding the target node; a timestamp; and a signature generated by the target node.

[0357] Clause 6: The method of any one of Clauses 1-5, further comprising sending, to a device management service (DMS) entity based on the identity token request message, a request for an identity record associated with the target node.

[0358] Clause 7: The method of Clause 6, wherein the request for the identity record associated with the target node includes: certificate unique identifier information of the certificate of the target node; a timestamp included in the identity token request message; and an indication of what data is being requested regarding the target node.

[0359] Clause 8: The method of Clause 6, further comprising receiving, from the DMS entity, the identity record associated with the target node based on the request for the identity record associated with the target node.

[0360] Clause 9: The method of Clause 8, wherein generating the identity token for the target node is further based on the identity record associated with the target node received from the DMS entity.

[0361] Clause 10: The method of any one of Clauses 1-9, wherein the identity token for the target node further includes: a header; a payload; and a signature.

[0362] Clause 11: The method of Clause 10, wherein the header indicates: a token type of the identity token; and a signing algorithm used for the signature.

[0363] Clause 12: The method of Clause 11, wherein the payload includes at least: an issuer name associated with the certificate of the target node; a subject name associated with the certificate of the target node; the certificate status associated with the certificate of the target node; and a public key of the IVS entity associated with the signature of the identity token for the target node.

[0364] Clause 13 : The method of Clause 12, wherein the signature comprises a hash of the header and payload generated based on the signing algorithm and a private signing key of the IVS entity that corresponds to the public key.P+S Ref. No.: DEXC / 0932PC 88DexcomRef. No.: 0932-PCT01

[0365] Clause 14: The method of any one of Clauses 1-13, wherein the identity token for the target node has a validity period that is less than a validity period of the certificate of the target node.

[0366] Clause 15: A method for communication by a requesting node in a health management system, comprising: transmitting an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node; receiving the identity token for the target node based on the identity token request message, wherein the identity token for the target node includes, at least, a certificate status associated with the certificate of the target node; and establishing a connection with the target node when the certificate status, included in the identity token, indicates that the certificate of the target node is valid.

[0367] Clause 16: The method of Clause 15, wherein: the requesting node is a health monitoring application; and the target node is an analyte sensor system.

[0368] Clause 17: The method of any one of Clauses 15-16, wherein: the requesting node is a proxy device having direct access to the internet; and the target node is a receiver device that lacks direct access to the internet.

[0369] Clause 18: The method of any one of Clauses 15-17, wherein the identity token for the target node further includes: a header; a payload; and a signature.

[0370] Clause 19: The method of Clause 18, wherein the header indicates: a token type of the identity token; and a signing algorithm used for the signature.

[0371] Clause 20: The method of Clause 19, wherein the payload includes at least: an issuer name associated with the certificate of the target node; a subject name associated with the certificate of the target node; the certificate status associated with the certificate of the target node; and a public key of an identity verification service (IVS) entity associated with the signature of the identity token for the target node.

[0372] Clause 21 : The method of Clause 20, wherein the signature comprises a hash of the header and payload generated based on the signing algorithm and a private signing key of the IVS entity that corresponds to the public key.

[0373] Clause 22: The method of Clause 21, further comprising determining a validity of the identity token for the target node by verifying the signature with the publicP+S Ref. No.: DEXC / 0932PC 89DexcomRef. No.: 0932-PCT01key of the I VS entity.

[0374] Clause 23: The method of Clause 22, wherein establishing the connection with the target node is further based on the validity of the identity token.

[0375] Clause 24: The method of any one of Clauses 15-23, further comprising terminating a pairing procedure or connection establishment procedure for establishing the connection with the target node when at least one of: the certificate status, included in the identity token, indicates that the certificate of the target node is invalid; or a certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid.

[0376] Clause 25: The method of Clause 24, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when number of times that the identity token for the target node is requested is greater than or equal to a threshold number of times.

[0377] Clause 26: The method of any one of Clauses 24-25, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a time differential between a first time at which a first identity token for the target node is requested and a second time at with a second identity token for the target node is requested is greater than a threshold time differential.

[0378] Clause 27: The method of any one of Clauses 24-26, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a number of identity tokens that are requested for the target node after expiration of a validity period associated with the target node is greater than a threshold.

[0379] Clause 28: The method of any one of Clauses 24-27, wherein the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of identity tokens that are requested by the requesting node for different target nodes is greater than a threshold number of different target nodes.

[0380] Clause 29: The method of any one of Clauses 24-28, wherein the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of different locations in which identity tokens are requested by the requesting node for different target nodes is greater than orP+S Ref. No.: DEXC / 0932PC 90DexcomRef. No.: 0932-PCT01equal to a threshold.

[0381] Clause 30: A method for communication by a fraud detection service (FDS) entity in a health management system, comprising: receiving event information from an identity verification service (IVS) entity in the health management system, wherein the event information is associated with one or more identity token request messages of a requesting node in the health management system that request at least one identity token be generated for a target node in the health management system; detecting, based on the event information, unauthorized activity associated with at least one of the requesting node or the target node; and sending, based on the detected unauthorized activity, one or more revocation request signals to a device management system (DMS) entity to request that that a certificate of at least one of the requesting node or the target node be revoked.

[0382] Clause 31: The method of Clause 30, wherein detecting the unauthorized activity is based on a number of times that the identity token for the target node is requested being greater than or equal to a threshold number of times.

[0383] Clause 32: The method of any one of Clauses 30-31, wherein detecting the unauthorized activity is based on a time differential between a first time at which a first identity token for the target node is requested and a second time at with a second identity token for the target node is requested being greater than a threshold time differential.

[0384] Clause 33: The method of any one of Clauses 30-32, wherein detecting the unauthorized activity is based on a number of identity tokens that are requested by the requesting node for different target nodes being greater than a threshold number of different target nodes.

[0385] Clause 34: The method of any one of Clauses 30-33, wherein detecting the unauthorized activity is based on a number of identity tokens that are requested for the target node after expiration of a validity period associated with the target node.

[0386] Clause 35: The method of any one of Clauses 30-34, wherein detecting the unauthorized activity is based on a threshold number of different locations in which identity tokens are requested by the requesting node for different target nodes.

[0387] Clause 36: A requesting node in a health management system, comprising: one or more memories comprising executable instructions; and one or more processors configured to execute the executable instructions to cause the requesting node to: transmit an identity token request message that requests an identity token for a target node in theP+S Ref. No.: DEXC / 0932PC 91DexcomRef. No.: 0932-PCT01health management system, wherein the identity token request message includes, at least, a certificate of the target node; receive the identity token for the target node based on the identity token request message, wherein the identity token for the target node includes, at least, a certificate status associated with the certificate of the target node; and establish a connection with the target node when the certificate status, included in the identity token, indicates that the certificate of the target node is valid.

[0388] Clause 37: The requesting node of Clause 36, wherein: the requesting node is a health monitoring application; and the target node is an analyte sensor system.

[0389] Clause 38: The requesting node of any one of Clauses 36-37, wherein: the requesting node is a proxy device having direct access to the internet; and the target node is a receiver device that lacks direct access to the internet.

[0390] Clause 39: The requesting node of any one of Clauses 36-38, wherein the identity token for the target node further includes a header, a payload, and a signature.

[0391] Clause 40: The requesting node of Clause 39, wherein the header indicates: a token type of the identity token; and a signing algorithm used for the signature.

[0392] Clause 41: The requesting node of Clause 40, wherein the payload includes at least: an issuer name associated with the certificate of the target node; a subject name associated with the certificate of the target node; the certificate status associated with the certificate of the target node; and a public key of an identity verification service (IVS) entity associated with the signature of the identity token for the target node.

[0393] Clause 42: The requesting node of Clause 41, wherein the signature comprises a hash of the header and payload generated based on the signing algorithm and a private signing key of the IVS entity that corresponds to the public key.

[0394] Clause 43: The requesting node of Clause 42, wherein: the one or more processors are further configured to cause the requesting node to determine a validity of the identity token for the target node; to determine the validity of the identity token for the target node, the one or more processors are configured to cause the requesting node to verify the signature with the public key of the IVS entity; and the one or more processors are configured to cause the requesting node to establish the connection with the target node further based on the validity of the identity token.

[0395] Clause 44: The requesting node of any one of Clauses 36-43, wherein the oneP+S Ref. No.: DEXC / 0932PC 92DexcomRef. No.: 0932-PCT01or more processors are further configured to cause the requesting node to terminate a pairing procedure or connection establishment procedure for establishing the connection with the target node when at least one of: the certificate status, included in the identity token, indicates that the certificate of the target node is invalid; or a certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid.

[0396] Clause 45: The requesting node of Clause 44, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when number of times that the identity token for the target node is requested is greater than or equal to a threshold number of times.

[0397] Clause 46: The requesting node of any one of Clauses 44-45, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a time differential between a first time at which a first identity token for the target node is requested and a second time at with a second identity token for the target node is requested is greater than a threshold time differential.

[0398] Clause 47: The requesting node of any one of Clauses 44-46, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a number of identity tokens that are requested for the target node after expiration of a validity period associated with the target node is greater than a threshold.

[0399] Clause 48: The requesting node of any one of Clauses 44-47, wherein the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of identity tokens that are requested by the requesting node for different target nodes is greater than a threshold number of different target nodes.

[0400] Clause 49: The requesting node of any one of Clauses 44-48, wherein the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of different locations in which identity tokens are requested by the requesting node for different target nodes is greater than or equal to a threshold.

[0401] Clause 50: An apparatus, comprising: one or more memories comprisingP+S Ref. No.: DEXC / 0932PC 93DexcomRef. No.: 0932-PCT01executable instructions; and one or more processors configured to execute the executable instructions and cause the apparatus to perform a method in accordance with any combination of Clauses 1-35.

[0402] Clause 51: An apparatus, comprising means for performing a method in accordance with any combination of Clauses 1-35.

[0403] Clause 52: A non-transitory computer-readable medium comprising executable instructions that, when executed by at least one processor of an apparatus, cause the apparatus to perform a method in accordance with any combination of Clauses 1-35.

[0404] Clause 53: 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-35Additional Considerations

[0405] 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, SS 502, HMA 504, IVS entity 506, DMS entity 508, FDS entity 1202, circuitry related thereto, and / or one or more processors 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.

[0406] 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 beP+S Ref. No.: DEXC / 0932PC 94DexcomRef. No.: 0932-PCT01appreciated 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.

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

[0408] 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 artisanP+S Ref. No.: DEXC / 0932PC 95DexcomRef. No.: 0932-PCT01now or at any time in the future.

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

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

[0411] 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 otherP+S Ref. No.: DEXC / 0932PC 96DexcomRef. No.: 0932-PCT01programmable 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.

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

[0413] 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.P+S Ref. No.: DEXC / 0932PC 97

Claims

DexcomRef. No.: 0932-PCT01CLAIMS1. A requesting node in a health management system, comprising:one or more memories comprising executable instructions; andone or more processors configured to execute the executable instructions to cause the requesting node to:transmit an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node;receive the identity token for the target node based on the identity token request message, wherein the identity token for the target node includes, at least, a certificate status associated with the certificate of the target node; and establish a connection with the target node when the certificate status, included in the identity token, indicates that the certificate of the target node is valid.

2. The requesting node of claim 1, wherein:the requesting node is a health monitoring application; andthe target node is an analyte sensor system.

3. The requesting node of claim 1, wherein:the requesting node is a proxy device having direct access to the internet; and the target node is a receiver device that lacks direct access to the internet.

4. The requesting node of claim 1, wherein the identity token for the target node further includes a header, a payload, and a signature.

5. The requesting node of claim 4, wherein the header indicates:a token type of the identity token; anda signing algorithm used for the signature.

6. The requesting node of claim 5, wherein the payload includes at least:an issuer name associated with the certificate of the target node;a subject name associated with the certificate of the target node;the certificate status associated with the certificate of the target node; andP+S Ref. No.: DEXC / 0932PC 98DexcomRef. No.: 0932-PCT01a public key of an identity verification service (IVS) entity associated with the signature of the identity token for the target node.

7. The requesting node of claim 6, wherein the signature comprises a hash of the header and payload generated based on the signing algorithm and a private signing key of the IVS entity that corresponds to the public key.

8. The requesting node of claim 7, wherein:the one or more processors are further configured to cause the requesting node to determine a validity of the identity token for the target node;to determine the validity of the identity token for the target node, the one or more processors are configured to cause the requesting node to verify the signature with the public key of the IVS entity; andthe one or more processors are configured to cause the requesting node to establish the connection with the target node further based on the validity of the identity token.

9. The requesting node of claim 1, wherein the one or more processors are further configured to cause the requesting node to terminate a pairing procedure or connection establishment procedure for establishing the connection with the target node when at least one of:the certificate status, included in the identity token, indicates that the certificate of the target node is invalid; ora certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid.

10. The requesting node of claim 9, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when number of times that the identity token for the target node is requested is greater than or equal to a threshold number of times.

11. The requesting node of claim 9, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a time differential between a first time at which a first identity token for the targetP+S Ref. No.: DEXC / 0932PC 99DexcomRef. No.: 0932-PCT01node is requested and a second time at with a second identity token for the target node is requested is greater than a threshold time differential.

12. The requesting node of claim 9, wherein the certificate status associated with the certificate of the target node indicates that the certificate of the target node is invalid when a number of identity tokens that are requested for the target node after expiration of a validity period associated with the target node is greater than a threshold.

13. The requesting node of claim 9, wherein the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of identity tokens that are requested by the requesting node for different target nodes is greater than a threshold number of different target nodes.

14. The requesting node of claim 9, wherein the certificate status associated with the certificate of the requesting node indicates that the certificate of the requesting node is invalid when a number of different locations in which identity tokens are requested by the requesting node for different target nodes is greater than or equal to a threshold.

15. A method for communication by a requesting node in a health management system, comprising:transmitting an identity token request message that requests an identity token for a target node in the health management system, wherein the identity token request message includes, at least, a certificate of the target node;receiving the identity token for the target node based on the identity token request message, wherein the identity token for the target node includes, at least, a certificate status associated with the certificate of the target node; andestablishing a connection with the target node when the certificate status, included in the identity token, indicates that the certificate of the target node is valid.P+S Ref. No.: DEXC / 0932PC 100

Images