Securing analyte sensor data via improved certificate issuance and validation

Abstract

In some embodiments, a method includes receiving a certificate request from a user device associated with an analyte sensor. The method also includes, responsive to the receiving, determining a current capacity of a server system, where the current capacity is selected from: a first level, a second level indicative of less capacity than the first level, and a third level indicative of less capacity than the second level. The method also includes, responsive to a determination that the current capacity corresponds to the third level, initiating deferred processing of the certificate request. The method also includes, responsive to a determination that the current capacity corresponds to the second level, conditionally processing the certificate request based on a wait time associated with the certificate request. The method also includes, responsive to a determination that the current capacity corresponds to the first level, processing the certificate request.

Description

DexcomRef. No.: 0992-PCT01SECURING ANALYTE SENSOR DATA VIA IMPROVED CERTIFICATE ISSUANCE AND VALIDATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and benefit of U.S. Provisional Patent Application No. 63 / 779,647 filed March 28, 2025, which application is hereby expressly incorporated by reference herein in its entirety as if fully set forth below and for all applicable purposes.INTRODUCTION

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

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

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

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

[0005] Consequently, a variety of non-invasive, transdermal (e.g., transcutaneous) and / or implantable sensors are being developed for continuously detecting and / or quantifying blood glucose values. Generally, in a diabetes management system, these sensors wirelessly transmit raw or minimally processed data for subsequent display and / or analysis at one or more remote devices, which can include a display device, a server, or any other types of communication devices. A remote device, such as a display device, may then utilize a trusted 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.

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

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

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

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

[0010] In some embodiments, one general aspect includes a method of controlling a flow of certificate requests by a server system. The method includes receiving a certificate request from a user device associated with an analyte sensor. The method also includes, responsive to the receiving, determining a current service capacity of the server system, where the current service capacity is selected from a plurality of predefined capacity levels that include: a first capacity level, a second capacity level indicative of less capacity than the first capacity level, and a third capacity level indicative of less capacity than the second capacity level. The method also includes, responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferred processing of the certificate request. The method also includes, responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request. The method also includes, responsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request.

[0011] In some embodiments, another general aspect includes a server system for controlling a flow of certificate requests. The server system includes one or more processors configured to execute instructions stored on one or more memories to cause the server system to perform one or more operations. The one or more operations include receiving a certificate request from a user device associated with an analyte sensor. TheDexcomRef. No.: 0992-PCT01one or more operations further include, responsive to the receiving, determining a current service capacity of the server system, where the current service capacity is selected from a plurality of predefined capacity levels that include: a first capacity level, a second capacity level indicative of less capacity than the first capacity level, and a third capacity level indicative of less capacity than the second capacity level. The one or more operations further include, responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferred processing of the certificate request. The one or more operations further include, responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request. The one or more operations further include, responsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request.

[0012] In some embodiments, another general aspect includes a non-transitory computer-readable medium. The non-transitory computer-readable medium includes instructions that, when executed by one or more processors of a server system, cause a server system to perform a method of controlling a flow of certificate requests. The method includes receiving a certificate request from a user device associated with an analyte sensor. The method also includes, responsive to the receiving, determining a current service capacity of the server system, where the current service capacity is selected from a plurality of predefined capacity levels that include: a first capacity level, a second capacity level indicative of less capacity than the first capacity level, and a third capacity level indicative of less capacity than the second capacity level. The method also includes, responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferred processing of the certificate request. The method also includes, responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request. The method also includes, responsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request.

[0013] In some embodiments, another general aspect includes a method of validating certificates on an analyte sensor system. The method includes receiving a communication request from a user device. The method also includes receiving a certificate associatedDexcomRef. No.: 0992-PCT01with the communication request, where the certificate includes expiration information associated with the certificate. The method also includes determining a reference date based on stored data in memory associated with the analyte sensor system. The method also includes rejecting the communication request responsive to a determination, based on the reference date and the expiration information, that the certificate has expired.

[0014] In some embodiments, another general aspect includes an analyte sensor system. The analyte sensor system includes an analyte sensor configured to generate analyte measurements associated with analyte levels of a patient. The analyte sensor system also includes a sensor electronics module coupled to the analyte sensor. The sensor electronics module is configured to receive a communication request from a user device. The sensor electronics module is further configured to receive a certificate associated with the communication request, where the certificate includes expiration information associated with the certificate. The sensor electronics module is further configured to determine a reference date based on stored data in memory associated with the analyte sensor system. The sensor electronics module is further configured to reject the communication request responsive to a determination, based on the reference date and the expiration information, that the certificate has expired.

[0015] In some embodiments, another general aspect includes a non-transitory computer-readable medium. The non-transitory computer-readable medium includes instructions that, when executed by one or more processors of an analyte sensor system, cause the analyte sensor system to perform a method of validating certificates on an analyte sensor system. The method includes receiving a communication request from a user device. The method also includes receiving a certificate associated with the communication request, where the certificate includes expiration information associated with the certificate. The method also includes determining a reference date based on stored data in memory associated with the analyte sensor system. The method also includes rejecting the communication request responsive to a determination, based on the reference date and the expiration information, that the certificate has expired.

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

[0017] FIG. 1A illustrates an example health management system, according toDexcomRef. No.: 0992-PCT01some embodiments disclosed herein.

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

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

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

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

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

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

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

[0025] FIG. 5 illustrates an example of a process for tracking pre-deployment time of an analyte sensor system, according to some embodiments disclosed herein.

[0026] FIG. 6 illustrates an example of a process for validating certificates on an analyte sensor system, according to some embodiments disclosed herein.

[0027] FIG. 7 illustrates an example of a system for controlling a flow of certificate requests, according to some embodiments disclosed herein.

[0028] FIG. 8 illustrates an example of a process for controlling flow of certificate requests on a server system, according to some embodiments disclosed herein.

[0029] FIG. 9 illustrates an example of a process for initiating deferred processing of a certificate request from a user device, according to some embodiments disclosed herein.

[0030] FIG. 10 illustrates an example of a process for conditional processing of a certificate request from a user device, according to some embodiments disclosed herein.DexcomRef. No.: 0992-PCT01

[0031] FIG. 11 depicts a method of controlling a flow of certificate requests by a server system, according to some embodiments disclosed herein.

[0032] FIG. 12 depicts an example of a method for validating certificates by an analyte sensor system, according to some embodiments disclosed herein.

[0033] FIG. 13 depicts aspects of an example health management server system according to some embodiments disclosed herein.

[0034] FIG. 14 depicts aspects of an example health management device 1400 according to some embodiments disclosed hereinDETAILED DESCRIPTION

[0035] Aspects of the present disclosure provide techniques, including apparatuses, methods, processing systems, and computer-readable mediums, for validating certificates on an analyte sensor system based on stored data indicating a reference date. Additionally, aspects of the present disclosure provide techniques, including apparatuses, methods, processing systems, and computer-readable mediums, for controlling a flow of certificate requests on a server system based on a plurality of service capacity levels.Introduction to Health Management Systems

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

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

[0137] -

[0140] and FIGS. 3A, 3B, and 4 of U.S. App. No.2019 / 0336053 further describe an on-skin sensor assembly that, in certain embodiments,DexcomRef. No.: 0992-PCT01may 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.

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

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

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

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

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

[0043] 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, oneDexcomRef. No.: 0992-PCT01of 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.

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

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

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

[0047] 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. Communication between server system 134 and other components and services (e.g., a database service or certificate service as shown in FIG.7) may occur via communication path 186.

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

[0049] 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 health management application (HMA) 121, as further described below.

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

[0051] FIG. IB also illustrates the components of SS 8 in further detail. As shown, in certain embodiments, SS 8 includes analyte sensor 10 coupled to sensor electronics module 12. Sensor electronics module 12 includes sensor measurement circuitry 13 that is coupled to analyte sensor 10 for processing and managing sensor data. Sensor measurement circuitry 13 may also be coupled to one or more processors 11. In some embodiments, the one or more processors 11 may perform part or all of the functions ofDexcomRef. No.: 0992-PCT01the 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 one or more memories 14 (e.g., storage) 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 utilize one or more memories 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.

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

[0053] FIG. IB similarly illustrates the components of display device 150 in further detail. As shown, display device 150 includes connectivity interface 128, one or more processors 126, one or more memories 127, a real time clock (RTC) 163, a display 125 for presenting a graphical user interface (GUI), and a storage 123. Abus (not shown here) may be used to interconnect the various elements of display device 150 and transfer data between these elements. Connectivity interface 128 includes a transceiver (TRX)DexcomRef. No.: 0992-PCT01129 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 orBLE) 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.

[0054] 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- standard! zed 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.

[0055] 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, HMA 121, display 125, RTC 163, one or more memories 127, storage 123, etc.). In certainDexcomRef. No.: 0992-PCT01embodiments, 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.

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

[0057] 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 HMA 121. Display 125 presents a GUI associated with operating system 162 and / or HMA 121. In various embodiments, a user may interact with HMA 121 via a corresponding GUI presented on display 125. By way of example, display 125 may be a touchscreen display that accepts touch input. HMA 121 may process and / or present analyte-related data received by display device 150 and present such data via display 125. Additionally, HMA 121 may be used to obtain, access, display, control, and / or interface with analyte data and related messaging and processesDexcomRef. No.: 0992-PCT01associated 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.

[0058] Storage 123 may be a non-volatile storage for storing software programs, instructions, data, etc. For example, storage 123 may store HMA 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 HMA 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.

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

[0060] HMA 121 may be downloaded, installed, and initially configured / setup on display device 150. For example, display device 150 may obtain HMA 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, HMA 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, HMA 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, HMA 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.

[0061] In certain embodiments, after downloading HMA 121, as one of the initial steps, the user may be directed by HMA 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 Pairing Procedure

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

[0063] 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 includeDexcomRef. No.: 0992-PCT01invitation, authentication, pairing, and / or bonding between the SS 8 and the display device 150.

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

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

[0066] 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.DexcomRef. No.: 0992-PCT01

[0067] Generally, when SS 8 (or its sensor electronics module 12) 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.

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

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

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

[0071] 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 pairingDexcomRef. No.: 0992-PCT01process 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.

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

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

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

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

[0076] 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 provideDexcomRef. No.: 0992-PCT01substantially 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.

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

[0078] 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 ofHMA 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 HMA 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 HMA 121 obtains from server system 134 includes a number of digital authentication certificates, also referred to as public key certificates, (herein after “certificates”) for use by display device 150 to authenticate SS 8 using what are referred to herein as device-centric mutual authentication protocols (described in relation to FIGS. 4A-4D) As further described below, SS 8 may similarly be configured with a set of certificates, thereby, allowing SS 8 to authenticate display device 150 using the same device-centric mutual authentication protocols. In certain embodiments, SS 8 is configured with these certificates during the manufacturing process. It is contemplated that in some examples, certificates, tokens, and / or encryption keys may be used for authenticating partner devices (e.g., medical delivery devices, such as insulin pumps and / or pens). It is further contemplated that the certificates, tokens, and / or encryption keys may also be obtained from the partner devices to authenticate SS8 and / or the displayDexcomRef. No.: 0992-PCT01device or other partner devices as well.

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

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

[0081] 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,DexcomRef. No.: 0992-PCT01whereby server system 134 signs a subordinate certificate authority’s (“SCA’s”) intermediary certificate and the SC A 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.

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

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

[0084] 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 HMA 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) with server system 134 in order to generate an encryption key for use in encrypting any further communications between display device 150 and server system 134. In certain embodiments, engaging in the cryptographic key exchange may involve proving to server system 134 that display device 150 is in possession of a shared secret (e.g., cryptographic key exchange algorithm, key, etc.) and vice versa. Being in possession of the shared secret is proof that display device 150 can be trusted by server system 134 and vice versa. After display device 150 and server system 134 complete the execution of the cryptographic key exchange algorithm, each of display device 150 and server system 134 is in possession of the encryption key that is used to encrypt any subsequent data transmitted there between (e.g., in steps 306-312).

[0085] In certain embodiments, the cryptographic key exchange algorithm includes a key-agreement protocol. A key agreement protocol is a protocol whereby two or moreDexcomRef. No.: 0992-PCT01parties 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.

[0086] In certain embodiments, during the set-up process, based on instructions provided by HMA 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, HMA 121 is already configured with the shared secret, which may be cryptographic key exchange algorithm. In other words, because display device 150 is able to engage in the cryptographic key exchange algorithm, server system 134 can conclude that display device 150 is trustworthy, otherwise display device 150 would not have been configured with such a cryptographic key exchange algorithm and would not have been able to engage in the cryptographic key exchange using that algorithm.

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

[0088] 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 150DexcomRef. No.: 0992-PCT01and 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.

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

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

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

[0092] 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 signatureDexcomRef. No.: 0992-PCT01that is then included in the certificate. Examples of signed certificates are shown in FIG.4B, which is further described below.

[0093] 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 SC A, 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.

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

[0095] 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.DexcomRef. No.: 0992-PCT01

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

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

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

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

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

[0101] At step 404 of FIG. 4A, SS 8 verifies display device 150’s credentials. InDexcomRef. No.: 0992-PCT01certain 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.).

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

[0103] 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 thatDexcomRef. No.: 0992-PCT01the transmitting entity of display device 150’s credentials is in fact display device 150.

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

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

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

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

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

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

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

[0111] 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.DexcomRef. No.: 0992-PCT01Aspects Related to Certificate Validation on an Analyte Sensor System

[0112] Public key infrastructure (PKI) technology may be used in certain health management systems to perform authentication and secure communication between an SS (e.g., SS 8) of the health management system and a health monitoring application (HMA) (e.g., HMA 121) executing on a display device of the health management system (e.g., any of display devices 110, 120, 130, 140, and 150). 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 verify digital signatures and may be freely distributed and widely accessible, while a private key may be used to generate digital signatures and is kept confidential by its assigned owner (e.g., the SS or HMA) to ensure security.

[0113] 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. When communication between the HMA and the SS is desired, the HMA and SS may engage in a certificate exchange procedure. During the certificate exchange procedure, the HMA provides its respective certificate to the SS. Likewise, the SS may also provide its respective certificate to the HMA. Each endpoint may verify that the other endpoint owns its certificate, for example, by supplying a random challenge value for the other endpoint to sign with its private key. When the signed value is returned, each endpoint may use the public key from the certificate to verify the signature, thus proving ownership of the certificate.

[0114] Both the HMA and SS may be programmed with a certificate of the trusted CA and may use a public key from that certificate to verify the signature of the certificate provided by the other endpoint. A valid signature indicates that the endpoint is an authentic device. Thereafter, further communication, including transmission of encrypted analyte data, may commence.

[0115] A significant challenge arises with respect to the management and verification of digital certificates used to secure communication between devices such as an SS and an HMA. When a CA issues a digital certificate, the CA may embed in the digital certificate a date range during which the digital certificate is valid. One of the most basic steps in validating a digital certificate is ensuring that when the digital certificate isDexcomRef. No.: 0992-PCT01presented for authentication, the current time is within the digital certificate’s validity period. For internet-connected devices, which have access to secure time resources, enforcing the expiration of digital certificates may be fairly straightforward. However, enforcing the expiration of digital certificates may be especially challenging for SSs, which typically have no real-time clock and lack an internet connection. Accordingly, it is generally infeasible for the SS to verify a validity period of the digital certificate (e.g., to determine if the certificate is expired) presented by the HMA during pairing or subsequent communications.

[0116] Among numerous limitations in this regard, SSs are typically unaware of a current or real-time date and time. A display device or other devices (e.g., an insulin pump) that may be attempting to connect to an SS cannot be trusted to provide an accurate date and time because if the device (or application) is compromised, it may provide an inaccurate date and time to circumvent certificate validation. As a result, there may be scenarios in which SSs may accept certificates that are expired, thus creating potential security vulnerabilities in the health management system and putting a patient at risk.

[0117] Additionally, without a reliable mechanism for checking certificate expiration, 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 once-valid but now-expired certificate from an SS or HMA could be duplicated and used by counterfeit devices, thus allowing the counterfeit devices to essentially use normal authentication protocols to gain access to the health management system, which puts a patient at further risk. Similarly, if an expired certificate is copied, for example, as part of a data compromise, the copied certificate may be maliciously or improperly reused to gain access to the health management system, which likewise puts a patient at further risk.

[0118] Accordingly, aspects of the present disclosure provide techniques to enable an SS to validate a certificate in the absence of an RTC or access to the internet. In some embodiments, these techniques may include the use of a reference date stored in an SS, which may be used to validate a digital certificate. For example, an SS can maintain, in its memory, stored data indicative of a reference date for certificate validation. The stored data may indicate, for example, a factory-established date of manufacture or another date configured prior to the SS leaving a manufacturing or company location. In some aspects, the stored data may include a time counter that is periodically incremented, for example,DexcomRef. No.: 0992-PCT01to track time (e.g., from the date of manufacture) until the SS is deployed in relation to a user (e.g., incremented daily, weekly, etc.). For example, prior to deployment (e.g., during storage), the SS can periodically wake and increment a time counter, thereby tracking time with minimal battery depletion and without network access or real-time time / date information.

[0119] In certain aspects, following deployment, the SS can use the stored date and / or time data to validate certificates (e.g., to determine whether the certificates have expired). For example, if a certificate is associated with an expiration date that is equal to or after the reference date indicated by the stored data, the certificate can be identified as expired, thereby improving device security in the absence of network access or real-time time / date information. Therefore, in certain aspects, the SS can more accurately validate a digital certificate using the aforementioned stored data, which makes the SS less susceptible to unauthorized activity of the type described above. Examples will be described with respect to FIGS. 5-6.

[0120] Although certain examples are described in terms of an SS that does not have access to a real-time date and time, in some aspects, an SS can include, for example, a GPS sensor to obtain current time. In these aspects, the current time may be used by the SS to evaluate whether a certificate is expired.Example of Tracking Pre-Deployment Time of an Analyte Sensor System

[0121] FIG. 5 illustrates an example of a process 500 for tracking pre-deployment time of an SS, according to some embodiments disclosed herein. The process 500 can be executed, for example, by an SS such as the SS 8 of FIGS. 1A-B. More particularly, in some aspects, the process 500 can be executed by a sensor electronics module of the SS, such as the sensor electronics module 12 of FIGS. 1A-B. In certain aspects, the process 500 can be initiated on the SS, for example, prior to the SS leaving a manufacturing or company location. For example, the process 500 can be initiated on a factory-established date of manufacture or other date indicated in stored data on the SS.

[0122] At block 502, the SS initiates a sleep mode. In some aspects, the block 502 may include, for example, initially setting a timer for waking the SS (e.g., a day timer). The sleep mode may correspond to a low-power mode of the SS in which, for example, battery power is only utilized to operate the timer. At block 504, the SS remains in sleep mode until expiration of the timer. At block 506, the SS wakes and increments a timeDexcomRef. No.: 0992-PCT01counter in memory thereof. As an example, the timer may be set to 24 hours, causing the SS to wake up daily and increment the time counter (e.g., incrementing the timer by one day). Accordingly, in this example, the time counter may keep track of how many days have passed since the SS left the manufacturing or company location.

[0123] From block 506, the process 500 returns to block 502 and repeats. The process 500 can continue, for example, until deployment (e.g., first activation) of the SS in relation to a user, until the SS is paired with a user device, or until other suitable termination criteria is satisfied. In this way, the SS tracks pre-deployment time of the SS, such as storage time, by periodically waking and incrementing the time counter. The time counter in combination, for example, with a factory-established date (e.g., a date of manufacture), may be used by the SS at the time of certificate validation to determine a current date and time.Example of Certificate Validation on an Analyte Sensor System Based on Stored Data

[0124] FIG. 6 illustrates an example of a process 600 for validating certificates on an SS, according to some embodiments disclosed herein. The process 600 may be executed, for example, by an SS such as the SS 8 of FIGS. 1A-B. More particularly, in some aspects, the process 600 may be executed by a sensor electronics module of the SS, such as the sensor electronics module 12 of FIGS. 1A-B.

[0125] At block 602, the SS receives a communication request from a user device. In various aspects, the communication request may be a connection request, a pairing request, an authentication request, a request to exchange data (e.g., analyte sensor data) and / or another type of request. In various aspects, the user device may be any of display devices 110, 120, 130, and 140 of FIG. 1A. For example, the user device may be a smartphone, a smartwatch, a receiver device, a medical delivery device (e.g., an insulin pump or pen), an augmented reality (AR) and / or virtual reality (VR) headset, and / or the like.

[0126] At block 604, the SS receives a certificate associated with the communication request. In some aspects, the certificate may be included with the communication request. In some aspects, the certificate includes or indicates expiration information associated with the certificate. The expiration information may indicate, for example, an expiration date, a validity period for the certificate, etc.

[0127] At block 606, the SS determines a reference date based on stored data in itsDexcomRef. No.: 0992-PCT01memory. As discussed previously, in some aspects, the stored data may indicate a factory-established date, such as a date of manufacture, such that the reference date is the factory-established date. In some aspects, the stored data may include, for example, both a factory-established (e.g., a date of manufacture) and a time counter that is periodically incremented as discussed relative to FIG. 5. In these aspects, the reference date can be determined based on the factory-established date and the time counter. For example, if the time counter indicates a number of days since the factory-established date, the reference date may correspond to the indicated number of days after the factory-established date.

[0128] At decision block 608, the SS determines, based on the stored data and the expiration information associated with the certificate, whether the certificate has expired. In general, the certificate may be deemed “expired” or “invalid” if it expires before the reference date, if it expires on or before the reference date, and / or the like. For example, if the expiration information includes an expiration date, the certificate may be deemed “expired” if the expiration date is earlier than the reference date, equal to the reference date, and / or the like. In another example, if the expiration information indicates a validity period for the certificate, the certificate may be deemed “expired” if the validity period ends prior to the reference date, if the validity period ends on the reference date, and / or the like. Other examples of determining expiration will be apparent to one skilled in the art after a detailed review of the present disclosure.

[0129] If it is determined, at the decision block 608, that the certificate has expired, the SS rejects the communication request at block 610. The rejection can include, for example, terminating a connection establishment procedure, a pairing procedure, an authentication procedure, a data exchange procedure, and / or the like. Otherwise, if no determination is made, at the decision block 608, that the certificate has expired, the SS accepts or further processes the communication request at block 612. In some aspects, the block 612 can include accepting the communication request, for example, if there are no further prerequisites to such acceptance (e.g., additional authentication). In other aspects, the block 612 can include implementing any additional prerequisites for accepting the communication request (e.g., additional authentication). After either block 610 or block 612, the process 600 ends.Aspects Related to Managing a Flow of Certificate Requests on a Server SystemDexcomRef. No.: 0992-PCT01

[0130] Another significant challenge arises with respect to managing a flow of certificate requests on server systems. A server system (e.g., server system 134) may perform, or coordinate, the functions of a CA by issuing certificates to an HMA (e.g., HMA 121), as generally discussed above. For example, as part of its typical operation, the server system may receive, from the HMA, a request to issue a certificate (referred to herein as a “certificate request”). In response, the server system may process the request and issue a certificate to the HMA.

[0131] Across a large user base, the server system may periodically experience large bursts of certificate requests. These bursts may be due, for example, to the release of a new version of the HMA or the release of a new product (e.g., a new SS or a new display device). Although the server system may employ automatic scaling to increase capacity in response to increased demand, there are practical limits to how much capacity can be increased. Furthermore, performance is often adversely impacted by limitations of downstream services, such as a database or PKI service.

[0132] As a result of the foregoing factors, a burst in certificate requests from HMAs may result in degraded system performance, for example, as measured by less throughput and greater latency. If the burst persists, certificate requests may time out or receive other performance-related errors. These errors, in turn, may cause the HMAs to immediately retry the same certificate requests. Across a large user base, a large number of retries typically triggers an even greater burst until, ultimately, the server system becomes unresponsive and / or is brought down. At this point, users are no longer able to establish secure communication between their HMA and SS, which may negatively impact patient health (e.g., the ability to get analyte measurements or data).

[0133] In response to the above problems, in certain aspects, a server system can control the flow of certificate requests based on a plurality of predefined service capacity levels that are indicative of progressively decreasing system capacity for processing certificate requests. The plurality of predefined service levels may include two, three, four, five, or any other suitable number of levels. For illustrative purposes, examples will be periodically described herein with three service capacity levels. These three illustrative levels may be periodically referred to herein as “Level 1,” “Level 2,” and “Level 3,” with each subsequent level indicating further diminishment in the server system’s capacity for processing certificate requests.DexcomRef. No.: 0992-PCT01

[0134] In some aspects, one or more of the predefined service capacity levels may be defined, at least part, by an average transaction time on the server system. Continuing the above example of three illustrative levels, Level 1 may represent normal or acceptable operation of the server system (e.g., average transaction time less than a first defined threshold, such as 500 milliseconds). Level 2 may represent a level of system busyness that is elevated compared to Level 1 but that is less extreme than that represented by Level 3 (e.g., an average transaction time greater than the first defined threshold above and less than or equal to a second defined threshold, such as 1 second). Level 3 may represent a highest level of system busyness (e.g., an average transaction time greater the second defined threshold above, such as 1 second).

[0135] In addition, or alternatively, one or more of the predefined service capacity levels may be defined, at least in part, by a status of a downstream service on which the server system relies (e.g., a database or PKI service). For example, the PKI service being down or non-responsive may correspond to Level 3. In another example, the PKI service operating at a degraded status (e.g., a status indicating that the PKI service is running but operating at an elevated level of busyness) may correspond to Level 2. The degraded status may be identified based on any suitable criteria such as, for example, an average response time by the PKI service (e.g., an average response time in excess of a defined threshold may correspond to Level 2), a number of requests sent to the PKI service (e.g., exceeding a preset rate limit for the PKI service may correspond to Level 2), and / or the like. As noted previously, the predefined service levels may differ from the foregoing examples in number and / or definition without deviating from the principles described herein.

[0136] In certain aspects, the server system can use the predefined service capacity levels to control flow in response to a certificate request from a user device (e.g., executing an HMA), such as a smartphone, a smartwatch, a receiver device, a medical delivery device (e.g., an insulin pump or pen), an augmented reality (AR) and / or virtual reality (VR) headset, and / or the like. If a current service capacity corresponds, for example, to Level 3 above, the server system can choose not to accept the certificate request for processing. Rather, the server system can defer processing of the certificate request, for example, until a subsequent retry by the user device. For example, the server system can notify the user device of deferred processing, which notification may instruct the user device to retry the request at later time, while maintaining a wait time for theDexcomRef. No.: 0992-PCT01certificate request in storage. In this way, the wait time can continue to increase with the passage of time, thereby preserving the wait time for when the user device retries the certificate request. If a current service capacity corresponds to Level 2 above, the server system can conditionally process the certificate request. For example, the certificate request may be processed if a current wait time satisfies a wait threshold; otherwise, processing may be deferred as with Level 3. If a current service capacity corresponds to Level 1 above, the server system can process the certificate request, for example, by initiating a process for issuing a certificate to the user device.

[0137] In certain aspects, the server system’s utilization of the predefined service capacity levels to control flow may produce various technical effects or advantages. For example, such utilization may prevent the server system from being overrun by sudden bursts of certificate requests as discussed above, thereby decreasing system downtime and average transaction time. By way of further example, such utilization may improve a corresponding ability and speed of a user device to pair with an SS, thereby improving patient health. Examples will be described relative to FIGS. 7-10.Example System for Controlling a Flow of Certificate Requests

[0138] FIG. 7 illustrates an example of a system 700 for controlling a flow of certificate requests, according to some embodiments disclosed herein. The system 700 includes a server system 734 that interacts with user display devices 750 (e.g., each executing an HMA), shared storage 736, a database service 735, and a PKI service 737, for example, to control the flow of certificate requests. In general, the server system 734 can operate as described, for example, with respect to the server system 134 of FIG. IB.In some aspects, the server system can be, or can include, a Kubemetes cluster that executes one or more containerized applications.

[0139] The user devices 750 can operate, for example, as described relative to the display device 150 of FIG. IB. More generally, the user devices 750 can each execute an HMA, such as the HMA 121, as discussed relative to the user display device 150 of FIG. IB. The user devices 750 can include, for example, smartphones, smartwatches, receiver devices, medical delivery devices (e.g., an insulin pumps or pens), AR and / or VR headsets, and / or the like.

[0140] The database service 735 and the PKI service 737 are examples of downstream services on which the server system 734 may rely to perform its functionsDexcomRef. No.: 0992-PCT01such as processing certificate requests from one or more of the user devices 750. As discussed previously, performance of the server system 734 can be impacted by the availability of such downstream services.

[0141] The shared storage 736 may include one or more databases, flat files, or other storage that maintains transaction times, average transaction times, other performance measurements, data related to each certificate request received, wait times, etc. The shared storage can be shared, for example, among servers of the server system 734. In some aspects, the shared storage 736 can correspond to the storage 136 of FIG. IB.

[0142] In certain aspects, the server system 734 maintains and updates the shared storage 736. In an example, the server system 734 can maintain, in the shared storage 736, performance measurements such as an average transaction time over a predefined period (e.g., 5 minutes). In another example, the server system 734 can maintain, in the shared storage 736, wait times and other data for certificate requests that have been received and not processed. In another example, the server system 734 can maintain, in the shared storage 736, statuses of one or more downstream services on which it relies, such as statuses of the database service 735 and / or the PKI service 737.

[0143] In certain aspects, the server system 734 can control the flow of certificate requests based on a plurality of predefined service capacity levels. As discussed previously, in some aspects, the plurality of predefined service capacity levels can be defined, at least in part, by an average transaction time over a defined period (e.g., 5 minutes). Table 1 provides an illustrative example of three defined service capacity levels denoted as “Level 1,” “Level 2,” and “Level 3,” with each subsequent level indicating further diminishment in the server system’s capacity for processing certificate requests. As noted previously, the predefined service levels may differ from what is shown in Table 1 (e.g., the predefined service levels may differ in number and / or definition without deviating from the principles described herein). For clarity, however, the illustrative example shown in Table 1 will be used to demonstrate example operation of the server system 734.EXAMPLE EXAMPLE DEFINITION SERVICE CAPACITY LEVELAverage transaction time less than or equal to a first defined Level 1threshold (e.g., 500 milliseconds).DexcomRef. No.: 0992-PCT01Average transaction time greater than the first defined Level 2 threshold above (e.g., 500 milliseconds) and less than or equal to a second defined threshold (e.g., 1 second).Average transaction time greater than the second defined Level 3threshold above (e.g., 1 second).Table 1

[0144] In some aspects, one or more of the predefined service capacity levels may be defined, at least part, by a status of a downstream service on which the server system relies (e.g., the database or PKI service). For example, data indicating a particular status of the downstream service (e.g., that the service is busy or not operational) may be independent criteria sufficient for Level 3. The data may be, for example, an error or status code issued by the downstream service.

[0145] In some aspects, one or more of the predefined service capacity levels may be defined by both a status of the downstream service and average transaction time. For example, a particular status of the downstream service (e.g., a status code indicative that the downstream service is busy) in combination with an average transaction time over a defined period (e.g., greater than 500 milliseconds over the last 5 minutes) may be independent criteria sufficient for Level 3.Example of Controlling a Flow of Certificate Requests

[0146] FIG. 8 illustrates an example of a process 800 for controlling flow of certificate requests on a server system, according to some embodiments disclosed herein. The process 800 can be executed, for example, by a server system such as the server system 734 of FIG. 7. In certain aspects, a different iteration of the process 800 can be executed by the server system for each certificate request that is received by the server system.

[0147] At block 802, the server system receives a certificate request from a user device such as one of the user devices 750 of FIG. 7. In some aspects, the certificate request may be originated, for example, by an HMA such as the HMA 121 of FIG. IB.In some aspects, the certificate request may be an initial request for a certificate, such that a wait time associated with the certificate request begins at zero with the receipt of the request. In some aspects, the certificate request may be a retry of a previous certificate request, for example, following initiation of deferred processing, as further discussed below. In these aspects, a wait time associated with the request may be that of the previousDexcomRef. No.: 0992-PCT01certificate request.

[0148] At block 804, the server system determines a current service capacity of the server system. For example, the current service capacity may correspond to Level 1, 2 or 3, as discussed above relative to Table 1. For example, the server system can determine an average transaction time over a predefined period (e.g., 5 minutes) and can compare the average transaction time to thresholds or other criteria associated with Level 1, 2, and 3, such as the thresholds shown in Table 1. In addition, or alternatively, the server system can determine a status of one or more downstream services, such as the database service 735 and / or the PKI service 737 of FIG. 7.

[0149] At decision block 806, the server system determines whether the current service capacity corresponds to Level 3, for example, according to any of the criteria or definitions discussed previously. If it is determined, at the decision block 806, that the current service capacity corresponds to Level 3, at block 808, the server system initiates deferred processing of the certificate request. According to this example, since the current service capacity corresponds to Level 3, the server system does not accept the certificate request for processing. Rather, processing may be deferred, for example, until a subsequent retry of the request. An example of initiating deferred processing will be described relative to FIG. 9.

[0150] If it is determined, at the decision block 806, that the current service capacity does not correspond to Level 3, the process 800 proceeds to decision block 810. At decision block 810, the server system determines whether the current service capacity corresponds to Level 2, for example, according to any of the criteria or definitions discussed previously. If it is determined, at the decision block 810, that the current service capacity corresponds to Level 2, at block 812, the server system conditionally processes the certificate request based on wait time. In certain aspects, the block 812 may include, for example, processing the certificate request if a current wait time satisfies a wait threshold or other suitable criteria; otherwise, processing may be deferred as with Level 3. An example of conditional processing will be described relative to FIG. 10.

[0151] If it is determined, at the decision block 810, that the current service capacity does not correspond to Level 2, the process 800 proceeds to block 814. According to the example of FIG. 8, the fact that the current service capacity does not correspond to Level 2 or 3 indicates that the current service capacity corresponds to Level 1. At block 814, theDexcomRef. No.: 0992-PCT01server system processes the certificate request. The processing at block 814 may include, for example, initiating a process for issuing a certificate to the user device. The initiating can involve, for example, queuing the certificate request for handling and / or the like. In some aspects, if the process for issuing a certificate is successful, a code indicative of success can be issued to the user device. In some aspects, if the process for issuing a certificate is unsuccessful, an error code can be issued to the user device and a wait time can be reset. After block 808, 812, or 814, the process 800 ends.

[0152] Note that FIG. 8 is just one example of a process, and other processes including fewer, additional, or alternative steps or blocks are possible consistent with this disclosure.Example of Deferred Processing of Certificate Requests

[0153] FIG. 9 illustrates an example of a process 900 for initiating deferred processing of a certificate request from a user device, for example, until a subsequent retry of the request, according to some embodiments disclosed herein. The process 900 can be executed, for example, by a server system such as the server system 734 of FIG.7.

[0154] At block 902, the server system receives a certificate request from a user device, for example, as described relative to block 802 of FIG.8. At block 904, the server system determines that a current service capacity of the server system corresponds to a capacity level at which deferred processing is initiated, such as Level 3 discussed above relative to Table 1. In certain aspects, execution of block 904 may correspond to execution of blocks 804 and 806 of FIG. 8. In some aspects, blocks 906 and 908 (discussed below) may collectively correspond to initiating deferred processing, as discussed relative to block 808 of FIG. 8.

[0155] At block 906, the server system notifies the user device of deferred processing. The block 906 may include, for example, issuing a status code indicative of the deferred processing to the user device. In some aspects, the notification can serve as an instruction to the user device to wait a defined period of time (e.g., 5 minutes) to retry the request. In some aspects, the user device, or the HMA executing thereon, can present a message to a user based on the status code. The message can indicate, for example, that the server system is busy and ask that the user retry the certificate request after the defined period of time (e.g., 5 minutes). For example, the HMA GUI can display a message ofDexcomRef. No.: 0992-PCT01“Certificate service is currently busy, please try again in 5 minutes.” In some aspects, the user device, or the HMA, can automatically retry the certificate request after the defined period of time.

[0156] At block 908, the server system maintains a wait time for the certificate request in the shared storage. In this way, the wait time can continue to increase with the passage of time, thereby preserving the wait time for when the user device retries the certificate request. In some aspects, when the user device retries the certificate request (e.g., after the defined period of time mentioned above), the certificate request may qualify for conditional processing due to the increasing wait time as discussed above relative to block 812 of FIG. 8 and below relative to FIG. 10 (e.g., if a then-existing current system capacity corresponds to Level 2 and a then-existing wait time exceeds a wait threshold or other suitable criteria). After block 908, the process 900 ends.

[0157] Note that FIG. 9 is just one example of a process, and other processes including fewer, additional, or alternative steps or blocks are possible consistent with this disclosure.Example of Conditional Processing of Certificate Requests

[0158] FIG. 10 illustrates an example of a process 1000 for conditional processing of a certificate request from a user device, according to some embodiments disclosed herein. The process 1000 can be executed, for example, by a server system such as the server system 734 of FIG. 7.

[0159] At block 1002, the server system receives a certificate request from a user device, for example, as described relative to block 802 of FIG. 8. At block 1004, the server system determines that a current service capacity of the server system corresponds to a capacity level at which conditional processing is performed, such as Level 2 discussed above relative to Table 1. In certain aspects, execution of block 1004 may correspond to execution of blocks 804, 806, and 810 of FIG. 8. In some aspects, blocks 1006-1010 (discussed below) may collectively correspond to performing conditional processing, as discussed relative to block 812 of FIG. 8.

[0160] At decision block 1006, the server system determines whether a wait time associated with the certificate request satisfies a wait threshold (or other suitable criteria). The wait threshold may be, for example, a predefined wait threshold such as, for example, 3 minutes, 4 minutes, etc. If it is determined, at the decision block 1006, that the wait timeDexcomRef. No.: 0992-PCT01associated with the certificate request satisfies the wait threshold, at block 1008, the server system processes the certificate request. In certain aspects, satisfaction of the wait threshold may indicate that the certificate request should be processed, even though current demand is elevated, for example, as indicated by the capacity level. Block 1008 may include, for example, executing the functionality described relative to block 814 of FIG. 8

[0161] If it is determined, at the decision block 1006, that the wait time associated with the certificate request does not satisfy the wait threshold, at block 1010, the server system initiates deferred processing of the certificate request. Block 1010 may include, for example, executing the functionality described relative to blocks 906 and 908 of FIG.9. After block 1008 or 1010, the process 1000 ends.

[0162] Note that FIG. 10 is just one example of a process, and other processes including fewer, additional, or alternative steps or blocks are possible consistent with this disclosure.Example Operations

[0163] FIG. 11 shows an example of a method 1100 of controlling a flow of certificate requests by a server system, such as the server system 134 of FIG. IB or the server system 734 of FIG. 7.

[0164] Method 1100 begins at step 1105 with receiving a certificate request from a user device associated with an analyte sensor. 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. 13.

[0165] Method 1100 then proceeds to step 1110 with responsive to the receiving, determining a current service capacity of the server system, where the current service capacity is selected from a plurality of predefined capacity levels comprising: a first capacity level, a second capacity level indicative of less capacity than the first capacity level, a third capacity level indicative of less capacity than the second capacity level. 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. 13.

[0166] Method 1100 then proceeds to step 1115 with responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferredDexcomRef. No.: 0992-PCT01processing of the certificate request. In some cases, the operations of this step refer to, or may be performed by, circuitry for initiating and / or code for initiating as described with reference to FIG. 13.

[0167] Method 1100 then proceeds to step 1120 with responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request. In some cases, the operations of this step refer to, or may be performed by, circuitry for processing and / or code for processing as described with reference to FIG.13

[0168] Method 1100 then proceeds to step 1125 with responsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request. In some cases, the operations of this step refer to, or may be performed by, circuitry for processing and / or code for processing as described with reference to FIG.13

[0169] In some aspects, the conditionally processing comprises determining whether the wait time satisfies a wait threshold, responsive to a determination that the wait time satisfies the wait threshold, processing the certificate request, and responsive to a determination that the wait time does not satisfy the wait threshold, initiating deferred processing of the certificate request.

[0170] In some aspects, the initiating deferred processing comprises notifying the user device of the deferred processing and maintaining the wait time in storage associated with the server system.

[0171] In some aspects, the notifying comprises issuing a status code indicative of the deferred processing to the user device.

[0172] In some aspects, the processing the certificate request comprises initiating a process for issuing a certificate to the user device, where the certificate enables the user device to perform an authentication protocol with an analyte sensor system prior to pairing with the analyte sensor system.

[0173] In some aspects, the current service capacity is based on an average transaction time on the server system over a defined period.

[0174] In some aspects, the current service capacity is based on a status of aDexcomRef. No.: 0992-PCT01downstream service used by the server system.

[0175] In some aspects, the certificate request is originated by a health monitoring application executing on the user device.

[0176] In one aspect, method 1100, or any aspect related to it, may be performed by an apparatus, such as health management server system 1300 of FIG. 13, which includes various components operable, configured, or adapted to perform the method 1100. Health management server system 1300 is described below in further detail.

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

[0178] FIG. 12 shows an example of a method 1200 of validating certificates by an analyte sensor system, such as the SS 8 of FIGS. 1A-B.

[0179] Method 1200 begins at step 1205 with receiving a communication request from a user device. 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.14

[0180] Method 1200 then proceeds to step 1210 with receiving a certificate associated with the communication request, the certificate comprising expiration information associated with the certificate. 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. 14.

[0181] Method 1200 then proceeds to step 1215 with determining a reference date based on stored data in memory associated with the analyte sensor system. 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. 14.

[0182] Method 1200 then proceeds to step 1220 with rejecting the communication request responsive to a determination, based on the reference date and the expiration information, that the certificate has expired. In some cases, the operations of this step refer to, or may be performed by, circuitry for rejecting and / or code for rejecting as described with reference to FIG. 14.

[0183] In some aspects, the determination that the certificate has expired is based onDexcomRef. No.: 0992-PCT01an expiration date of the certificate being earlier than the reference date.

[0184] In some aspects, the determination that the certificate has expired is based on an expiration date of the certificate being equal to the reference date.

[0185] In some aspects, the determination that the certificate has expired is based on at least one of the following: a validity period for the certificate ending before the reference date or the validity period for the certificate ending on the reference date.

[0186] In some aspects, the stored data comprises a factory-established date of manufacture and the reference date is the factory-established date of manufacture.

[0187] In some aspects, the stored data comprises a factory-established date of manufacture and a time counter and the reference date is determined based on the factory-established date of manufacture and the time counter.

[0188] In some aspects, the method 1200 further includes, prior to the receiving the communication request, the analyte sensor system periodically waking and incrementing the time counter to track pre-deployment time of the analyte sensor system. In some cases, the operations of this step refer to, or may be performed by, circuitry for periodically waking and incrementing and / or code for periodically waking and incrementing as described with reference to FIG. 14.

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

[0190] Note that FIG. 12 is just one example of a method, and other methods including fewer, additional, or alternative steps are possible consistent with this disclosure.Example Health Management Server System

[0191] FIG. 13 depicts aspects of an example health management server system 1300, such as the server system 134 of FIG. IB and / or the server system 734 of FIG. 7.

[0192] The health management server system 1300 includes a processing system 1305 coupled to a network interface 1395. The network interface 1395 is configured to enable health management server system 1300 to communicate over a network, such as network 190 described with respect to FIG. IB. The processing system 1305 may beDexcomRef. No.: 0992-PCT01configured to perform processing functions for the health management server system 1300, including processing requests received by the health management system 1300 and / or responses or notifications to be provided by the health management server system 1300.

[0193] The processing system 1305 includes one or more processors 1310. The one or more processors 1310 are coupled to a computer-readable medium / memory 1345 via a bus 1380. In certain aspects, the computer-readable medium / memory 1345 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 1310, cause the one or more processors 1310 to perform the method 1100 described with respect to FIG. 11, or any aspect related to it. Note that reference to a processor of health management server system 1300 performing a function may include one or more processors 1310 of health management server system 1300 performing that function.

[0194] In the depicted example, the computer-readable medium / memory 1345 stores code (e.g., executable instructions), such as code for receiving 1350, code for determining 1355, code for initiating 1360, code for processing 1365, code for notifying 1370, and code for issuing 1375. Processing of the code for receiving 1350, code for determining 1355, code for initiating 1360, code for processing 1365, code for notifying 1370, and code for issuing 1375 may cause the health management server system 1300 to perform the method 1100 described with respect to FIG. 11, or any aspect related to it.

[0195] The one or more processors 1310 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium / memory 1345, including circuitry such as circuitry for receiving 1315, circuitry for determining 1320, circuitry for initiating 1325, circuitry for processing 1330, circuitry for notifying 1335, and circuitry for issuing 1340. Processing with circuitry for receiving 1315, circuitry for determining 1320, circuitry for initiating 1325, circuitry for processing 1330, circuitry for notifying 1335, and circuitry for issuing 1340 may cause the health management server system 1300 to perform the method 1100 described with respect to FIG. 11, or any aspect related to it.Example Health Management Device

[0196] FIG. 14 depicts aspects of an example health management device 1400. In some aspects, health management device 1400 is analyte sensor system, such as the SS 8DexcomRef. No.: 0992-PCT01of FIGS. 1A-B

[0197] The health management device 1400 includes a processing system 1405 coupled to the transceiver 1465 (e.g., a transmitter and / or a receiver). The transceiver 1465 is configured to transmit and receive signals for the health management device 1400 via the antenna 1470, such as the various signals and messages as described herein. The processing system 1405 may be configured to perform processing functions for the health management device 1400, including processing signals received and / or to be transmitted by the health management device 1400.

[0198] The health management device 1400 includes an analyte sensor 1401 configured to perform measurements of an analyte concentration level of a user of the health management device 1400. In various aspects, the analyte sensor 1401 may be representative of the analyte sensor 10 as described with respect to FIGS. 1A-B. The processing system 1405 includes one or more processors 1410. In various aspects, the one or more processors 1410 may be representative of the one or more processors 11 as described with respect to FIG. IB. The analyte sensor 1401 and the one or more processors 1410 are coupled to a computer-readable medium / memory 1435 via a bus 1460. In some aspects, the computer-readable medium / memory 1435 may be representative of the one or more memories 14 as described with respect to FIG. IB.

[0199] In certain aspects, the computer-readable medium / memory 1435 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 1410, cause the one or more processors 1410 to perform the method 1200 described with respect to FIG. 12, or any aspect related to it. Note that reference to a processor of health management device 1400 performing a function may include one or more processors 1410 of health management device 1400 performing that function.

[0200] In the depicted example, the computer-readable medium / memory 1435 stores code (e.g., executable instructions), such as code for receiving 1440, code for determining 1445, code for rejecting 1450, and code for periodically waking and incrementing 1455. Processing of the code for receiving 1440, code for determining 1445, code for rejecting 1450, and code for periodically waking and incrementing 1455 may cause the health management device 1400 to perform the method 1200 described with respect to FIG. 12, or any aspect related to it.DexcomRef. No.: 0992-PCT01

[0201] The one or more processors 1410 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium / memory 1435, including circuitry such as circuitry for receiving 1415, circuitry for determining 1420, circuitry for rejecting 1425, and circuitry for periodically waking and incrementing 1430. Processing with circuitry for receiving 1415, circuitry for determining 1420, circuitry for rejecting 1425, and circuitry for periodically waking and incrementing 1430 may cause the health management device 1400 to perform the method 1200 described with respect to FIG. 12, or any aspect related to it.Example Clauses

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

[0203] Clause 1 : A method of controlling a flow of certificate requests by a server system, comprising: receiving a certificate request from a user device associated with an analyte sensor; responsive to the receiving, determining a current service capacity of the server system, wherein the current service capacity is selected from a plurality of predefined capacity levels comprising: a first capacity level, a second capacity level indicative of less capacity than the first capacity level, and a third capacity level indicative of less capacity than the second capacity level; responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferred processing of the certificate request; responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request; and responsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request.

[0204] Clause 2: The method of Clause 1, wherein the conditionally processing comprises: determining whether the wait time satisfies a wait threshold; responsive to a determination that the wait time satisfies the wait threshold, processing the certificate request; and responsive to a determination that the wait time does not satisfy the wait threshold, initiating deferred processing of the certificate request.

[0205] Clause 3: The method of any one of Clauses 1-2, wherein the initiating deferred processing comprises: notifying the user device of the deferred processing; and maintaining the wait time in storage associated with the server system.

[0206] Clause 4: The method of Clause 3, wherein the notifying comprises issuing aDexcomRef. No.: 0992-PCT01status code indicative of the deferred processing to the user device.

[0207] Clause 5: The method of any one of Clauses 1-4, wherein the processing the certificate request comprises initiating a process for issuing a certificate to the user device, where the certificate enables the user device to perform an authentication protocol with an analyte sensor system prior to pairing with the analyte sensor system.

[0208] Clause 6: The method of any one of Clauses 1-5, wherein the current service capacity is based on an average transaction time on the server system over a defined period.

[0209] Clause 7: The method of any one of Clauses 1-6, wherein the current service capacity is based on a status of a downstream service used by the server system.

[0210] Clause 8: The method of any one of Clauses 1-7, wherein the certificate request is originated by a health monitoring application executing on the user device.

[0211] Clause 9: A method of validating certificates by an analyte sensor system, comprising: receiving a communication request from a user device; receiving a certificate associated with the communication request, the certificate comprising expiration information associated with the certificate; determining a reference date based on stored data in memory associated with the analyte sensor system; and rejecting the communication request responsive to a determination, based on the reference date and the expiration information, that the certificate has expired.

[0212] Clause 10: The method of Clause 9, wherein the determination that the certificate has expired is based on an expiration date of the certificate being earlier than the reference date.

[0213] Clause 11 : The method of any one of Clauses 9-10, wherein the determination that the certificate has expired is based on an expiration date of the certificate being equal to the reference date.

[0214] Clause 12: The method of any one of Clauses 9-11, wherein the determination that the certificate has expired is based on at least one of the following: a validity period for the certificate ending before the reference date; or the validity period for the certificate ending on the reference date.

[0215] Clause 13: The method of any one of Clauses 9-12, wherein: the stored data comprises a factory-established date of manufacture; and the reference date is the factory -DexcomRef. No.: 0992-PCT01established date of manufacture.

[0216] Clause 14: The method of any one of Clauses 9-13, wherein: the stored data comprises a factory-established date of manufacture and a time counter; and the reference date is determined based on the factory-established date of manufacture and the time counter.

[0217] Clause 15: The method of Clause 14, further comprising , prior to the receiving the communication request, the analyte sensor system periodically waking and incrementing the time counter to track pre-deployment time of the analyte sensor system.

[0218] Clause 16: An apparatus, comprising: at least one memory comprising executable instructions; and at least one processor configured to execute the executable instructions and cause the apparatus to perform a method in accordance with any combination of Clauses 1-15.

[0219] Clause 17: An apparatus, comprising means for performing a method in accordance with any combination of Clauses 1-15.

[0220] Clause 18: 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-15.

[0221] Clause 19: 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-15.Additional Considerations

[0222] 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, user devices 750,DexcomRef. No.: 0992-PCT01server system 734, 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.

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

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

[0225] 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;DexcomRef. No.: 0992-PCT01the terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like; the term “set” should be read to include one or more objects of the type included in the set; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Similarly, the plural may in some cases be recognized as applicable to the singular and vice versa. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future.

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

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

[0228] 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 loadedDexcomRef. No.: 0992-PCT01onto a computer or other programmable data processing apparatus (such as a controller, microcontroller, microprocessor or the like) in a sensor electronics system to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create instructions for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks presented herein.

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

[0230] 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 skillDexcomRef. No.: 0992-PCT01in the art that aspects and features described above in connection with (sub-) components, elements, devices, modules, and circuitry, etc., including variations thereof, may be applied to the various operations described in connection with methods described herein, and vice versa, without departing from the scope of the present disclosure.

Claims

DexcomRef. No.: 0992-PCT01CLAIMS1. A method of controlling a flow of certificate requests by a server system, comprising:receiving a certificate request from a user device associated with an analyte sensor;responsive to the receiving, determining a current service capacity of the server system, wherein the current service capacity is selected from a plurality of predefined capacity levels comprising:a first capacity level;a second capacity level indicative of less capacity than the first capacity level; anda third capacity level indicative of less capacity than the second capacity level;responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferred processing of the certificate request;responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request; andresponsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request.

2. The method of claim 1, wherein the conditionally processing comprises: determining whether the wait time satisfies a wait threshold;responsive to a determination that the wait time satisfies the wait threshold, processing the certificate request; andresponsive to a determination that the wait time does not satisfy the wait threshold, initiating deferred processing of the certificate request.

3. The method of claim 1, wherein the initiating deferred processing comprises:notifying the user device of the deferred processing; andmaintaining the wait time in storage associated with the server system.DexcomRef. No.: 0992-PCT014. The method of claim 3, wherein the notifying comprises issuing a status code indicative of the deferred processing to the user device.

5. The method of claim 1, wherein the processing the certificate request comprises initiating a process for issuing a certificate to the user device, wherein the certificate enables the user device to perform an authentication protocol with an analyte sensor system prior to pairing with the analyte sensor system.

6. The method of claim 1, wherein the current service capacity is based on an average transaction time on the server system over a defined period.

7. The method of claim 1, wherein the current service capacity is based on a status of a downstream service used by the server system.

8. The method of claim 1, wherein the certificate request is originated by a health monitoring application executing on the user device.

9. A server system for controlling a flow of certificate requests, the server system comprising:one or more processors configured to execute instructions stored on one or more memories to cause the server system to perform one or more operations comprising:receiving a certificate request from a user device associated with an analyte sensor;responsive to the receiving, determining a current service capacity of the server system, wherein the current service capacity is selected from a plurality of predefined capacity levels comprising:a first capacity level;a second capacity level indicative of less capacity than the first capacity level; anda third capacity level indicative of less capacity than the second capacity level;responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferred processing of the certificate request;DexcomRef. No.: 0992-PCT01responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request; and responsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request.

10. The server system of claim 9, wherein the conditionally processing comprises:determining whether the wait time satisfies a wait threshold;responsive to a determination that the wait time satisfies the wait threshold, processing the certificate request; andresponsive to a determination that the wait time does not satisfy the wait threshold, initiating deferred processing of the certificate request.

11. The server system of claim 9, wherein the initiating deferred processing comprises:notifying the user device of the deferred processing; andmaintaining the wait time in storage associated with the server system.

12. The server system of claim 11, wherein the notifying comprises issuing a status code indicative of the deferred processing to the user device.

13. The server system of claim 9, wherein the processing the certificate request comprises initiating a process for issuing a certificate to the user device, wherein the certificate enables the user device to perform an authentication protocol with an analyte sensor system prior to pairing with the analyte sensor system.

14. The server system of claim 9, wherein the current service capacity is based on an average transaction time on the server system over a defined period.DexcomRef. No.: 0992-PCT0115. A non-transitory computer-readable medium, comprising instructions that, when executed by one or more processors of a server system, cause the server system to perform a method of controlling a flow of certificate requests, the method comprising:receiving a certificate request from a user device associated with an analyte sensor;responsive to the receiving, determining a current service capacity of the server system, wherein the current service capacity is selected from a plurality of predefined capacity levels comprising:a first capacity level;a second capacity level indicative of less capacity than the first capacity level; anda third capacity level indicative of less capacity than the second capacity level;responsive to a determination that the current service capacity corresponds to the third capacity level, initiating deferred processing of the certificate request;responsive to a determination that the current service capacity corresponds to the second capacity level, conditionally processing the certificate request based on a wait time associated with the certificate request; andresponsive to a determination that the current service capacity corresponds to the first capacity level, processing the certificate request.

Images