Dynamic discovery window for wireless communication between devices

Abstract

Embodiments described herein include a data receiving device for an analyte monitoring system. The data receiving device detects a disconnection between the data receiving device and a sensor control device of the analyte monitoring system. A data receiving device sets a duration of a scan window for receiving a connection packet from a sensor control device to a current length, and initiates the scan window. In response to determining that a connection between the data receiving device and the sensor control device has not been established based on a connection data packet received during the scan window, the data receiving device performs an iteration of a process to adjust the scan window, including increasing a duration of the scan window to a new length greater than the current length, and initiating the scan window based on the duration of the scan window of the new length.

Description

[0001] priority

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 368,849, filed on July 19, 2022, under 35 U.S.C. §119(e), which is incorporated herein by reference. Technical Field

[0003] The disclosed subject matter relates to a system for transmitting data between an analyte sensor and one or more receiving devices in an environment external to the analyte sensor. Background Art

[0004] Some analyte sensor devices can wirelessly transmit data to other computing devices and wirelessly receive data from other computing devices. Although some of these analyte sensor devices are equipped with powerful processors and operate using permanent power supplies, other analyte sensor devices are designed to operate efficiently using very little power. Low-power analyte sensor devices may also have lower computing power or resources than the devices with which these analyte sensor devices communicate. Low-power analyte sensor devices can rely on more powerful devices to perform more complex processing on the data being collected by the low-power analyte sensor devices. In some cases, the communication capabilities of these low-power analyte sensor devices are also limited, usually limited to short-range communication with devices in the same room. In order to offload data to another device, the low-power analyte sensor device can establish a communication session with the other device and transmit, for example, collected analyte data for analysis. However, in order to ensure real-time processing of data so that the most relevant data is available to users of low-power analyte sensor devices, some low-power analyte sensor devices must maintain a communication session to perform data processing. The communication session can still use short-range communication. If the low power analyte sensor device or other device moves out of range, the communication session is terminated and the data is left unprocessed. In addition to inconvenience to the user of the low power analyte sensor device, maintaining a communication session with another analyte sensor device drains the battery of the low power analyte sensor device, thereby reducing the operating life of the device.

[0005] In other low-power analyte sensor devices, the communication session is not always maintained. Instead, these low-power analyte sensor devices can establish a communication session when the backlog of historical data has not yet been unloaded to a more powerful device. In order to save battery life, once the data is uploaded, the communication session ends. After collecting more data, the low-power analyte sensor device can periodically check whether one or more appropriate receiving devices are within the range to rebuild the communication session, or can rely on the user to use the receiving device to request such data. If the receiving device is within the range, the low-power analyte sensor device establishes a new communication session to upload additional data. If the receiving device is out of range or unavailable when the low-power analyte sensor device is looking for the receiving device, the data cannot be uploaded. In addition, once the receiving device returns to the range of the analyte sensor device, the receiving device and the analyte sensor device rebuild the communication session, which may require additional time to transmit the additional data, so that the latest analyte data may not be immediately available to the user.

[0006] Therefore, there is a need for methods and systems implemented by low-power, low-cost analyte sensor devices that can efficiently provide current or high-priority analyte data to other devices for processing and output. Summary of the invention

[0007] Various aspects of the invention are set out in the independent claims, preferred features are set out in the dependent claims. Features of one aspect may be applicable to each aspect alone or in combination with other aspects.

[0008] The objects and advantages of the disclosed subject matter will be set forth in the following description and will be apparent from the description, and will be understood by the practice of the disclosed subject matter. Other advantages of the disclosed subject matter will be realized and obtained by the methods and systems particularly pointed out in the written description and its claims as well as the drawings.

[0009] To achieve these and other advantages, and in accordance with the purposes of the disclosed subject matter, as specifically implemented and broadly described, the disclosed subject matter includes systems and methods for accelerating the transmission of high priority data from an analyte sensor to one or more receiving devices by re-planning a reserved communication channel. Exemplary systems and methods may include methods for monitoring a subject using an analyte monitoring device. One or more processors of the analyte monitoring device generate sensor data indicating an analyte level measured by an analyte sensor. At least a portion of the analyte sensor may be percutaneously positioned to contact a bodily fluid of the subject. One or more processors of the analyte monitoring device may identify a subset of the sensor data based on a priority associated with the sensor data. One or more processors of the analyte monitoring device may prepare a data packet including the identified subset of sensor data and connection data associated with establishing a communication session with the analyte monitoring device. One or more processors of the analyte monitoring device may cause a transceiver of the analyte monitoring device to transmit the data packet to one or more user devices within the communication range of the transceiver. One or more processors of the analyte monitoring device may receive a confirmation signal indicating receipt of the sensor data from a first user device of the one or more user devices through the transceiver. In a specific embodiment, the data packet also includes identification data of the first user device for directing the data packet to the first user device. In a specific embodiment, before causing the transceiver of the analyte monitoring device to transmit a data packet, one or more processors of the analyte monitoring device may receive an activation command from the first user device. In a specific embodiment, the one or more processors of the analyte monitoring device may cause the transceiver to transmit a data packet by identifying one or more communication channels, which are associated with establishing a connection between devices through a specified communication protocol, and the one or more processors may generate a signal based on the data packet using the identified one or more communication channels. In a specific embodiment, after receiving a confirmation signal from the first user device, the one or more processors of the analyte monitoring device may use the transceiver to establish a communication session with the first user device. The one or more processors of the analyte monitoring device may cause the transceiver to transmit a second subset of sensor data to the first user device through the communication session. The second subset of sensor data is not included in the data packet. In a specific embodiment, the one or more processors of the analyte monitoring device may encrypt the identified subset of sensor data using an encryption key shared between the analyte monitoring device and the first user device. In a specific embodiment, a key rotation scheme may be used to dynamically determine or identify an encryption key. In a specific embodiment, the priority associated with the sensor data may be based on the time elapsed since the sensor data was collected. The sensor data with the highest priority may be the most recently collected. In particular embodiments, the priority associated with the sensor data is based on a condition of the subject determined from the sensor data.In a specific embodiment, one or more processors of the analyte monitoring device prepare connection data associated with establishing a communication session with the analyte monitoring device based on a regularly occurring time window. In a specific embodiment, by way of example and not limitation, the analyte may be glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, etc. In a specific embodiment, the data packet also includes the subject's temperature, heart rate, blood pressure, or exercise data.

[0010] According to other aspects of the disclosed subject matter, the system and method may include a method for monitoring the analyte level of a subject using a user device. One or more processors of the user device may use a communication module of the user device to send an activation command to an analyte monitoring device associated with the subject. One or more processors of the user device may use the communication module and receive a first set of sensor data from the analyte monitoring device during a first communication session with the analyte monitoring device. The first set of sensor data may indicate a first analyte level measured by the analyte monitoring device at a first time. One or more processors of the user device may close the first communication session. One or more processors of the user device may use the communication module to receive a data packet from the analyte monitoring device. The data packet may include connection data associated with establishing a second communication session with the analyte monitoring device. The data packet may include a second set of sensor data from the analyte monitoring device, the second set of sensor data indicating a second analyte level measured by the analyte monitoring device at a second time. One or more processors of the user device may output the second set of sensor data in an interface of the user device. In a specific embodiment, outputting the second set of sensor data includes causing the interface of the user device to indicate that the second set of sensor data corresponds to a current or recently determined analyte level measured by the analyte monitoring device by the one or more processors of the user device. In a specific embodiment, the one or more processors of the user device may output an alarm based on the second set of sensor data. In a specific embodiment, one or more processors of the user device can use the communication module to send a confirmation signal to the analyte monitoring device. The confirmation signal can indicate that the second group of sensor data has been received. In a specific embodiment, one or more processors of the user device can establish a second communication session with the analyte monitoring device based on the connection data of the data packet. One or more processors of the user device can receive a third group of sensor data, and the third group of sensor data indicates a third analyte level measured by the analyte monitoring device during the time period between the first time and the second time. In a specific embodiment, the second group of sensor data is included in the encrypted data payload of the data packet. The one or more processors of the user device can use the encryption key shared between the analyte monitoring device and the user device to decrypt the encrypted data payload of the data packet, and extract the second group of sensor data from the decrypted data payload. In a specific embodiment, the user device is associated with a user who has been permitted by the subject to receive sensor data on behalf of the subject.

[0011] According to other aspects of the disclosed subject matter, systems and methods may include an analyte monitoring device including one or more processors; an analyte sensor; a communication module and one or more memories communicatively coupled to the one or more processors, the analyte sensor, and the communication module. The one or more processors may be configured to generate sensor data indicating an analyte level measured by the analyte sensor. At least a portion of the analyte sensor is transcutaneously positioned in contact with a bodily fluid of a subject. The one or more processors may be configured to store the sensor data in one or more memories. The one or more processors may identify a first subset of sensor data corresponding to a first time from the one or more memories. The one or more processors may prepare a data packet including an identified subset of sensor data and connection data associated with establishing a communication session with the analyte monitoring device. The one or more processors may cause the communication module to transmit a data packet to one or more user devices within a communication range of the communication module. The one or more processors may receive a communication session request from a first user device in the one or more user devices through the communication module. The one or more processors may cause the communication module to transmit a second data packet to the first user device, the second data packet including a second subset of data corresponding to a second time.

[0012] For further advantage and in accordance with the purpose of the disclosed subject matter, as specifically implemented and broadly described, the disclosed subject matter also includes systems and methods for establishing, maintaining and transmitting data to multiple receiving devices using simultaneous communication sessions. Exemplary systems and methods may include an analyte monitoring device that monitors a subject using an analyte monitoring device. The analyte monitoring device may include one or more processors, an analyte sensor, a communication module, and one or more memories that are communicatively coupled to the one or more processors, the analyte sensor, and the communication module. The one or more memories include instructions that can be executed by one or more processors to configure the one or more processors to perform operations according to the technology disclosed herein. The one or more processors of the analyte monitoring device generate sensor data, the sensor data indicating the analyte level measured by the analyte sensor of the analyte monitoring device. At least a portion of the analyte sensor is transcutaneously positioned to contact the body fluid of the subject. The one or more processors of the analyte monitoring device receive a first request for sensor data from a first device and a second request for sensor data from a second device. The one or more processors of the analyte monitoring device select a first subset of the sensor data in response to the first request. The one or more processors of the analyte monitoring device select a second subset of the sensor data in response to the second request. The one or more processors of the analyte monitoring device prepare a first data packet including a first subset of the sensor data and a second data packet including a second subset of the sensor data. The one or more processors of the analyte monitoring device cause a communication module of the analyte monitoring device to transmit the first data packet to the first device. The one or more processors of the analyte monitoring device cause the communication module of the analyte monitoring device to transmit the second data packet to the second device.

[0013] In a specific embodiment, before causing the communication module of the analyte monitoring device to transmit the second data packet to the second device, the one or more processors of the analyte monitoring device receive a confirmation signal indicating the reception of the first subset of sensor data from the first device through the communication module. In a specific embodiment, the first request and the second request include criteria for selecting the first subset of sensor data and the second subset of sensor data, respectively. In a specific embodiment, the one or more processors of the analyte monitoring device select the first subset of sensor data or the second subset of sensor data based on the priority associated with the sensor data. In a specific embodiment, the one or more processors of the analyte monitoring device receive the first request for sensor data before the analyte monitoring device receives the second request for the second data, and before causing the communication module to transmit the second data packet to the second device, the communication module transmits the first data packet to the first device. In a specific embodiment, the first device or the second device is a health monitor or a health device. In a specific embodiment, the first device or the second device includes a medical component used by a subject based on the first subset of sensor data or the second subset of sensor data. In a specific embodiment, the first device or the second device includes a networking component to transmit the first subset of sensor data or the second subset of sensor data to one or more remote devices. In a specific embodiment, the first device is a smart phone and the second device is a smart watch.

[0014] In a specific embodiment, one or more processors of an analyte monitoring device establish a communication session with a second device via communication with a first device by: receiving a connection request from the first device via a communication module, the connection request including identification information of the second device and information facilitating a communication session with the second device, wherein the identification information is received by the first device from the second device during a communication session between the first device and the second device; transmitting a confirmation of the connection request to the second device using the information facilitating the communication session with the second device; and performing mutual authentication with the second device to generate a shared encryption key for a subsequent communication session. In a specific embodiment, a first request for sensor data includes an identifier of the first device. The identifier is an index in a mapping table stored by the analyte monitoring device. The one or more processors of the analyte monitoring device identify the first device based on querying the mapping table using the index from the first request. In a specific embodiment, the one or more processors of the analyte monitoring device encrypt a first subset of the sensor data using a first encryption key shared between the analyte monitoring device and the first device, and encrypt a second subset of the sensor data using a second encryption key shared between the analyte monitoring device and the second device. In a specific embodiment, the first encryption key and the second encryption key are dynamically determined or identified using a key rotation scheme. In specific embodiments, the analyte comprises glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, or uric acid.

[0015] The analyte sensor can exchange data with other devices called receivers controlled by the user. The receiver can use a commercial operating system that communicates with the analyte sensor through a wireless two-way communication link. As an example, a mobile device with a Bluetooth low energy (BLE) circuit can be used to communicate with certain analyte sensors. A two-way communication link can be formed using a wireless communication protocol that includes a connection request or advertising notification received by the receiver. The analysis device broadcasts advertising notifications at a predetermined constant frequency. Using advertising notifications to facilitate the establishment of wireless communications involves a large amount of power consumption of the analyte sensor.

[0016] During a typical advertising operation, an analyte sensor configured to operate using a short-range wireless communication protocol (e.g., BLE) transmits an advertising notification and searches for a scan request from a receiver. In some cases, when it is time to perform an advertising operation, the analyte sensor is in a sleep state, where the analyte sensor consumes relatively little power. Before the analyte sensor is able to transmit an advertising notification and search for a scan request, the analyte sensor wakes up from the sleep state. Whenever the analyte sensor wakes up from the sleep state, the analyte sensor performs a set of predetermined startup and initialization actions or tasks. The analyte sensor uses a certain amount of power to perform all startup and initialization tasks associated with the wake-up. During the life of the analyte sensor, the analyte sensor will enter the sleep state and wake up from the sleep state quite a number of times (e.g., several times per hour). Therefore, the actions and tasks performed during each wake-up operation, even if only the advertising operation is performed, use a relatively large amount of power during the life of the device.

[0017] According to other aspects of the disclosed subject matter, the analyte sensor may include a communication module having a communication circuit configured to wirelessly communicate with at least one other device (e.g., a receiver). The communication circuit may be configured to switch between a sleep state, a partially awake state, and a fully awake state. When in a fully awake state, the communication circuit may be configured to perform tasks and actions associated with a communication protocol startup (CPS) instruction set, which includes an advertisement scan-related (ASR) instruction subset and a non-ASR instruction subset. When in a partially awake state, the communication circuit may be configured to perform functions, such as an ASR instruction subset. The partially awake state may be implemented as a limited functional branch of a programming and hardware stack intended to operate certain aspects of the communication protocol. These functions may include preparing and transmitting an advertisement notification through one or more channels according to a wireless communication protocol and scanning one or more channels for a connection request from another device, and the advertisement notification may include a payload configured with dedicated information as discussed herein. When a connection request is not received, the communication circuit may return to a sleep state without performing an action or task associated with a non-ASR instruction subset of the CPS instruction set. Therefore, by achieving a partial wake-up state and performing only actions or tasks associated with a subset of non-ASR instructions when a connection request is received, the total and average power consumption of the communication circuit is reduced when the most common operations are waking up and sending advertising notifications.

[0018] According to other aspects of the disclosed subject matter, an analyte monitoring device may include one or more processors, an analyte sensor, a communication module, and one or more memories communicatively coupled to the one or more processors, the analyte sensor, and the communication module. The one or more processors may be configured to generate sensor data indicating an analyte level measured by the analyte sensor. At least a portion of the analyte sensor is percutaneously positioned to contact a bodily fluid of a subject. The one or more processors may be configured to initialize the communication module using an advertisement scan-related instruction set. The advertisement scan-related instruction set is a subset of the communication protocol startup instruction set, including an advertisement scan-related instruction set and a non-advertisement scan-related instruction set. The one or more processors may cause the communication module to publish one or more advertisement data packets and receive a connection request from a receiving device. The one or more processors may use a non-advertisement scan-related instruction set to complete the initialization of the communication module. The one or more processors may select a subset of the sensor data, prepare a data packet including a subset of the sensor data, and cause the communication module to transmit the data packet to the receiving device.

[0019] In a specific embodiment, the communication module may be initialized in response to detecting the expiration of the wake-up timer. In a specific embodiment, initializing the communication module includes transitioning the communication module from a sleep state to an active state. In a specific embodiment, after causing the communication module to issue one or more advertising packets, the one or more processors are further configured to determine that no connection request has been received from the receiving device for a period of time, transition the communication module from the awake state to the sleep state, and initialize the communication module for a second time using an advertising scan related instruction set, wherein the connection request is received from the receiving device after the communication module has been initialized for the second time. In a specific embodiment, the communication module transitions from the awake state to the sleep state without executing a non-advertising scan related instruction set. In a specific embodiment, the non-advertising scan related instruction set includes instructions related to initialization of a random access memory segment or block, initialization of sensing hardware, or initialization of an operating system service. In a specific embodiment, the advertising scan related instruction set includes instructions related to detecting the expiration of the wake-up timer, processor startup, initialization of a transmission circuit, formation of an advertising packet, transmission of an advertising packet, scanning one or more channels for a connection request from a receiving device, or verifying or rejecting an incoming connection request. In a specific embodiment, the connection request includes criteria for selecting a subset of sensor data. In particular embodiments, the one or more processors are further configured to select the subset of sensor data based on a priority associated with the sensor data.

[0020] On the other hand, a computer-implemented method is provided. Under the control of one or more processors of an analyte sensor, wherein the one or more processors are configured with specific executable instructions, the method may include collecting signals associated with detected analyte levels and executing program instructions to analyze the signals and / or manage storage of the signals and / or implement treatment. The method may also include, when in a fully awake state, wirelessly communicating with at least one other device and performing tasks and actions associated with a communication protocol start (CPS) instruction set, the CPS instruction set including an advertisement scan related (ASR) instruction subset and a non-ASR instruction subset. When in a partially awake state, the method may include performing functions such as an ASR instruction subset. These functions may include transmitting an advertisement notification over one or more channels according to a wireless communication protocol when no connection request is received, scanning one or more channels for a connection request from another device (e.g., a suitably configured receiver), and returning to a sleep state without performing actions or tasks associated with a non-ASR instruction subset of the CPS instruction set.

[0021] According to other aspects of the disclosed subject matter, a data receiving device for an analyte monitoring system includes one or more processors, a communication module, and one or more memories communicatively coupled to the one or more processors and the communication module. The one or more memories include instructions that can be executed by one or more processors to configure the one or more processors to perform operations according to the embodiments and purposes described herein. The data receiving device detects a disconnection between the data receiving device and the sensor control device of the analyte monitoring system. The sensor control device includes a communication module and an analyte sensor, and the analyte sensor is configured to be percutaneously positioned to contact the body fluid of a subject wearing the sensor control device. The data receiving device sets the duration of a scanning window for receiving a connection data packet from the sensor control device to a current length. The data receiving device initiates a scanning window based on the duration of the scanning window of the current length. In response to determining that the connection between the data receiving device and the sensor control device has not been established based on the connection data packet received during the scanning window, the data receiving device performs one or more iterations of a process to adjust the scanning window. The iterative process includes increasing the duration of the scanning window to a new length, the new length is greater than the current length, and initiating a scanning window based on the duration of the scanning window of the new length.

[0022] In a specific embodiment, after initiating the scan window based on the duration of the scan window of the current length, the data receiving device establishes a connection with the sensor control device, and in response to establishing the connection, synchronizes the clock maintained by the data receiving device with the clock maintained by the sensor control device. In a specific embodiment, the process of adjusting the scan window also includes comparing the duration of the scan window of the new scan window length with the scan window duration threshold. In a specific embodiment, the process of adjusting the scan window also includes resetting the duration of the scan window to a length less than the scan window duration threshold in response to determining that the duration of the scan window exceeds the scan window duration threshold. In a specific embodiment, the length less than the scan window duration threshold is equal to the duration of the scan window used after the disconnection is detected. In a specific embodiment, the amount by which the duration of the scan window is increased is a fixed amount. In a specific embodiment, the amount by which the duration of the scan window is increased is based on the current available battery power of the data receiving device. In a specific embodiment, the amount by which the duration of the scan window is increased is based on the last known available battery power of the sensor control device. In a specific embodiment, the amount by which the duration of the scan window is increased is based on a clock drift associated with the sensor control device or the data receiving device. In a specific embodiment, the process of adjusting the scan window includes modifying the start time of the scan window. In a specific embodiment, after initiating a scan window for a duration based on the current length of the scan window, the data receiving device establishes a connection with the sensor control device, and in response to establishing the connection, receives analyte data from the analyte sensor from the sensor control device. In a specific embodiment, the data receiving device outputs a value based on the analyte data for display. In a specific embodiment, the data receiving device uses the analyte data to modify a treatment implemented by the data receiving device. In a specific embodiment, the analyte sensor is configured to generate a data signal measuring the level of an analyte in a body fluid, and the analyte includes glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, or uric acid.

[0023] According to other aspects of the disclosed subject matter, a sensor control device of an analyte monitoring system includes one or more processors, an analyte sensor, a communication module, and one or more memories communicatively coupled to the one or more processors, the analyte sensor, and the communication module, wherein at least a portion of the analyte sensor is percutaneously positioned to contact a body fluid of a subject. The memory includes instructions that can be executed by one or more processors to configure the one or more processors to perform various operations. The sensor control device receives a request to initiate a communication session with a data receiving device of the analyte monitoring system via the communication module. The request to initiate a communication session includes identity information of the data receiving device. The sensor control device identifies a desired communication parameter configuration for the communication session from one or more memories and based on the identity information. The sensor control device initiates a communication parameter negotiation process with the data receiving device. The negotiation process includes providing a desired communication parameter configuration to the data receiving device. The sensor control device modifies one or more communication parameters of the communication session based on the negotiation process.

[0024] In a specific embodiment, the sensor control device initiates a communication session with the data receiving device using the modified communication parameters. In a specific embodiment, the sensor control device determines an analyte level of the subject based on the analyte sensor, and transmits the analyte level to the data receiving device in the communication session. In a specific embodiment, the sensor control device dynamically determines further modifications to the desired communication parameter configuration of the communication session, performs a second communication parameter negotiation process with the data receiving device, and modifies one or more communication parameters of the communication session based on the second negotiation process. In a specific embodiment, the sensor control device performs a communication link quality test based on multiple communication parameter configurations. In a specific embodiment, the sensor control device modifies the desired communication parameter configuration based on the available battery power of the sensor control device or the data receiving device.

[0025] It is to be understood that both the foregoing general description and the following detailed description are exemplary, and are intended to provide further explanation of the disclosed subject matter.

[0026] The accompanying drawings, which are incorporated in and constitute a part of this specification, are used to illustrate and provide a further understanding of the methods and systems of the disclosed subject matter. Together with the description, the drawings serve to explain the principles of the disclosed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The details of the subject matter described herein, both its structure and operation, will become apparent by examination of the accompanying drawings, in which like reference numerals represent like parts.

[0028] Figure 1 is a diagram illustrating an operating environment of an exemplary analyte monitoring system for use with the techniques described herein.

[0029] Figure 2 is a block diagram illustrating an exemplary analyte sensor according to an exemplary implementation of the disclosed subject matter.

[0030] Figure 3 is a block diagram illustrating an exemplary data receiving device for communicating with a sensor according to an exemplary implementation of the disclosed subject matter.

[0031] Figure 4 is a diagram illustrating an exemplary packet.

[0032] Figure 5 is a diagram illustrating an exemplary operational flow of an analyte sensor in accordance with the disclosed subject matter.

[0033] Figure 6A-6C is a diagram illustrating an operating environment of an exemplary analyte sensor and multiple data receiving devices.

[0034] Figure 7 is a diagram illustrating an exemplary operational flow of an analyte sensor in accordance with the disclosed subject matter.

[0035] Figure 8 An example of an initialization block for a BLE peripheral application in a fully awake state is shown.

[0036] Fig. 9 An example of an initialization block of a BLE advertising application in a partial wake-up state is shown.

[0037] Fig.10 An example of an application switching sequence between a BLE advertising application in a partially awake state and a BLE advertising application in a fully awake state according to embodiments of the present invention is shown.

[0038] Fig.11 is a state machine diagram illustrating states of a communication circuit configured in accordance with embodiments herein.

[0039] Figure 12A-12C An embodiment of a device scan window in accordance with an embodiment of the disclosed subject matter is shown.

[0040] Fig.13 An exemplary operation flow of a data receiving device according to an embodiment of the disclosed subject matter is shown. DETAILED DESCRIPTION

[0041] Reference will now be made in detail to various exemplary embodiments of the disclosed subject matter, which are illustrated in the accompanying drawings. The structure of the disclosed subject matter and corresponding method of operation will be described in conjunction with the detailed description of the system.

[0042] The system and method proposed herein can be used for the operation of the sensor used in the analyte monitoring system, such as but not limited to health, fitness, diet, research, information or any purpose involving sensing analyte over time. As used herein, "analyte sensor" or "sensor" can refer to any device capable of receiving sensor information from a user, for the purpose of illustration, including but not limited to a temperature sensor, a blood pressure sensor, a pulse or heart rate sensor, a glucose level sensor, an analyte sensor, a body activity sensor, a body motion sensor or any other sensor for collecting physical or biological information. The analyte measured by the analyte sensor can include, for example, but not limited to, glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, etc. The purpose and advantages of the disclosed subject matter will be set forth in the following description and become apparent from the description. Other advantages of the disclosed subject matter will be realized and attained by the methods, devices and apparatus particularly pointed out in the written description and claims hereof as well as the appended drawings.

[0043] For purposes of illustration and not limitation, the present disclosure includes methods for accelerating the transmission of high priority data from an analyte sensor to one or more receiving devices by re-planning a reserved communication channel according to the disclosed subject matter. Exemplary systems and methods may include methods for monitoring a subject using an analyte monitoring device. One or more processors of the analyte monitoring device generate sensor data indicating an analyte level measured by the analyte sensor. At least a portion of the analyte sensor may be positioned transcutaneously to contact a bodily fluid of the subject. One or more processors of the analyte monitoring device may identify a subset of sensor data based on a priority associated with the sensor data. One or more processors of the analyte monitoring device may prepare a data packet including an identified subset of sensor data and connection data associated with establishing a communication session with the analyte monitoring device. One or more processors of the analyte monitoring device may cause a transceiver of the analyte monitoring device to transmit a data packet to one or more user devices within the communication range of the transceiver. One or more processors of the analyte monitoring device may receive a confirmation signal indicating the reception of the sensor data from a first user device in one or more user devices through the transceiver. In a specific embodiment, the data packet also includes identification data of the first user device for directing the data packet to the first user device. In a specific embodiment, before causing the transceiver of the analyte monitoring device to transmit a data packet, one or more processors of the analyte monitoring device may receive an activation command from the first user device. In a specific embodiment, the one or more processors of the analyte monitoring device may cause the transceiver to transmit a data packet using one or more identified communication channels by identifying one or more communication channels and generating signals based on the data packet, and the one or more communication channels are associated with establishing a connection between devices through a specified communication protocol. In a specific embodiment, after receiving a confirmation signal from the first user device, the one or more processors of the analyte monitoring device may use the transceiver to establish a communication session with the first user device. The one or more processors of the analyte monitoring device may cause the transceiver to transmit a second subset of sensor data to the first user device through the communication session. The second subset of sensor data is not included in the data packet. In a specific embodiment, the one or more processors of the analyte monitoring device may encrypt the identified subset of sensor data using an encryption key shared between the analyte monitoring device and the first user device. In a specific embodiment, a key rotation scheme may be used to dynamically determine or identify an encryption key. In a specific embodiment, the priority associated with the sensor data may be based on the time elapsed since the sensor data was collected. The sensor data with the highest priority may be the most recently collected. In particular embodiments, the priority associated with the sensor data is based on a condition of the subject determined from the sensor data.In a specific embodiment, one or more processors of the analyte monitoring device prepare connection data associated with establishing a communication session with the analyte monitoring device based on a regularly occurring time window. In a specific embodiment, by way of example and not limitation, the analyte may be glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, etc. In a specific embodiment, the data packet also includes the subject's temperature, heart rate, blood pressure, or exercise data.

[0044] According to other aspects of the disclosed subject matter, systems and methods may include a user device receiving a data packet from an analyte sensor associated with a subject. The user device may identify a data payload of the data packet. The user device may decrypt the data payload using an encryption key shared between the analyte sensor and the user device. The user device may extract the analyte data of the subject from the decrypted data payload. The extracted analyte data may correspond to a recently generated subset of the analyte data collected from the subject. The user device may output the extracted analyte data in an interface of the user device. In a specific embodiment, when the extracted analyte data is output, an interface of the user device may indicate that the extracted analyte data corresponds to the current or recently generated analyte reading of the analyte sensor to the subject. In a specific embodiment, the user device may output an alarm based on the analyte data. In a specific embodiment, the user device may extract identification information of the analyte sensor from the data payload of the data packet. The user device may send a confirmation signal to the analyte sensor, the confirmation signal indicating that the extracted analyte data has been received. The user device may establish a communication session with the analyte sensor based on the identification information of the analyte sensor. The user device may receive a collection of analyte data of the subject from the analyte sensor. In a specific embodiment, the communication session is associated with a current time, and when the analyte sensor and the user device have established a previous communication session, the previous communication session corresponds to the previous time. The historical set of analyte data includes analyte data of the subject collected by the analyte sensor between the previous time and the current time. In a specific embodiment, the user device can be associated with a user who has been authenticated by the subject to receive analyte data on behalf of the subject.

[0045] According to other aspects of the disclosed subject matter, systems and methods may include an analyte monitoring device, the analyte monitoring device including one or more processors, an analyte sensor, a communication module, and one or more memories communicatively coupled to the one or more processors, the analyte sensor, and the communication module. The one or more processors may be configured to generate sensor data indicating an analyte level measured by the analyte sensor. At least a portion of the analyte sensor is transcutaneously positioned to contact a body fluid of a subject. The one or more processors may be configured to store the sensor data in one or more memories. The one or more processors may identify a first subset of sensor data corresponding to a first time from the one or more memories. The one or more processors may prepare a data packet including an identified subset of sensor data and connection data associated with establishing a communication session with the analyte monitoring device. The one or more processors may cause the communication module to transmit a data packet to one or more user devices within the communication range of the communication module. The one or more processors may receive a communication session request from a first user device in the one or more user devices through the communication module. The one or more processors may cause the communication module to transmit a second data packet to the first user device, the second data packet including a second subset of data corresponding to a second time.

[0046] For further advantage and in accordance with the purpose of the disclosed subject matter, as specifically implemented and broadly described, the disclosed subject matter also includes systems and methods for establishing, maintaining and transmitting data to multiple receiving devices using simultaneous communication sessions. Exemplary systems and methods may include an analyte monitoring device that monitors a subject using an analyte monitoring device. The analyte monitoring device may include one or more processors, an analyte sensor, a communication module, and one or more memories that are communicatively coupled to the one or more processors, the analyte sensor, and the communication module. The one or more memories include instructions that can be executed by one or more processors to configure the one or more processors to perform operations according to the technology disclosed herein. The one or more processors of the analyte monitoring device generate sensor data, the sensor data indicating the analyte level measured by the analyte sensor of the analyte monitoring device. At least a portion of the analyte sensor is transcutaneously positioned to contact the body fluid of the subject. The one or more processors of the analyte monitoring device receive a first request for sensor data from a first device and a second request for sensor data from a second device. The one or more processors of the analyte monitoring device select a first subset of the sensor data in response to the first request. The one or more processors of the analyte monitoring device select a second subset of the sensor data in response to the second request. The one or more processors of the analyte monitoring device prepare a first data packet including a first subset of the sensor data and a second data packet including a second subset of the sensor data. The one or more processors of the analyte monitoring device cause a communication module of the analyte monitoring device to transmit the first data packet to the first device. The one or more processors of the analyte monitoring device cause the communication module of the analyte monitoring device to transmit the second data packet to the second device.

[0047] In a specific embodiment, before causing the communication module of the analyte monitoring device to transmit the second data packet to the second device, the one or more processors of the analyte monitoring device receive a confirmation signal indicating the reception of the first subset of sensor data from the first device through the communication module. In a specific embodiment, the first request and the second request include criteria for selecting the first subset of sensor data and the second subset of sensor data, respectively. In a specific embodiment, the one or more processors of the analyte monitoring device select the first subset of sensor data or the second subset of sensor data based on the priority associated with the sensor data. In a specific embodiment, the one or more processors of the analyte monitoring device receive the first request for sensor data before the analyte monitoring device receives the second request for the second data, and before causing the communication module to transmit the second data packet to the second device, the communication module transmits the first data packet to the first device. In a specific embodiment, the first device or the second device is a health monitor or a health device. In a specific embodiment, the first device or the second device includes a medical component used by a subject based on the first subset of sensor data or the second subset of sensor data. In a specific embodiment, the first device or the second device includes a networking component to transmit the first subset of sensor data or the second subset of sensor data to one or more remote devices. In a specific embodiment, the first device is a smart phone and the second device is a smart watch.

[0048] In a specific embodiment, one or more processors of an analyte monitoring device establish a communication session with a second device via communication with a first device by: receiving a connection request from the first device via a communication module, the connection request including identification information of the second device and information facilitating a communication session with the second device, wherein the identification information is received by the first device from the second device during a communication session between the first device and the second device; transmitting a confirmation of the connection request to the second device using the information facilitating the communication session with the second device; and performing mutual authentication with the second device to generate a shared encryption key for a subsequent communication session. In a specific embodiment, a first request for sensor data includes an identifier of the first device. The identifier is an index in a mapping table stored by the analyte monitoring device. The one or more processors of the analyte monitoring device identify the first device based on querying the mapping table using the index from the first request. In a specific embodiment, the one or more processors of the analyte monitoring device encrypt a first subset of the sensor data using a first encryption key shared between the analyte monitoring device and the first device, and encrypt a second subset of the sensor data using a second encryption key shared between the analyte monitoring device and the second device. In a specific embodiment, the first encryption key and the second encryption key are dynamically determined or identified using a key rotation scheme. In specific embodiments, the analyte comprises glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, or uric acid.

[0049] For purposes of illustration and not limitation, reference is made to Figure 1 An exemplary embodiment of an analyte monitoring system 100 of the disclosed subject matter is shown. Figure 1The operating environment of a preferred low-power analyte monitoring system 100 is shown, which can implement the technology described herein. The analyte monitoring system 100 may include a component system designed to provide monitoring of parameters (e.g., analyte levels) of a human or animal body, or other operations may be provided based on the configuration of various components. For example, the analyte monitoring system 100 may provide continuous glucose monitoring to a user, or may provide the delivery of drugs and other medicaments. As specifically implemented herein, the system may include a low-power sensor control device 110, also referred to as a sensor worn or attached to a body by a user, for which information is being collected. As specifically implemented herein, the sensor control device 110 may be a sealed disposable device to improve ease of use and reduce the risk of tampering, as further discussed herein. The low-power analyte monitoring system 100 may also include a data receiving device 120, which is configured as described herein to facilitate retrieval and transmission of data from the sensor control device 110, including analyte data.

[0050] As specifically implemented herein, the analyte monitoring system 100 may additionally or alternatively include a software or firmware library or application that is provided to a third party and incorporated into a multi-purpose hardware device 130, such as a mobile phone, a tablet computer, a personal computing device, or other similar computing devices capable of communicating with the sensor control device 110 via a communication link. The multi-purpose hardware may also include an embedded device, including but not limited to an insulin pump or an insulin pen, having an embedded library configured to communicate with the sensor control device 110. The multi-purpose device 130 that specifically implements and executes the software library may be referred to as a data receiving device for communicating with the sensor control device 110. As used herein, the data receiving device 120 may refer to a hardware device that is specifically manufactured for communicating with the sensor control device 110 within the analyte monitoring system 100, while the multi-purpose data receiving device 130 refers to a properly configured hardware device that is incorporated into a software or firmware library or is executing an application. As used herein, a data communication device refers to one or both of the data receiving device 120 or the multi-purpose data receiving device 130. It should be understood that the security architecture and design principles discussed herein are equally applicable to any appropriately configured system including a sensor control device 110, an appropriately configured data receiving device 120 or a multi-purpose data receiving device 130, and other similar components described herein. The role of the sensor control device 110 may be defined by the nature of the sensing hardware contained in the sensor control device 110.

[0051] As embodied herein, the sensor control device 110 may include a small, individually packaged, disposable device having a predetermined useful life (e.g., 1 day, 14 days, 30 days, etc.). The sensor 110 may be applied to the skin of the user's body and remain adhered during the sensor's life. As embodied herein, the sensor 110 may be designed to be selectively removed and remain functional when reapplied.

[0052] Although the illustrated embodiment of the analyte monitoring system 100 includes only one of each of the sensor control device 110, the data receiving device 120, the multi-purpose data receiving device 130, the user device 140, and the remote server 150, the present disclosure contemplates that the analyte monitoring system 100 includes multiple components in each component that interact in the overall system. For example, the embodiments disclosed herein include multiple sensors 110, the multiple sensors 110 may be associated with multiple users, and the multiple users communicate with the remote server 150. In addition, the remote server is shown as a single entity 150, however, it will be understood that multiple networked servers may be included, which may be geographically distributed to reduce latency and introduce intentional redundancy to avoid monitoring system downtime.

[0053] For purposes of illustration and not limitation, reference is made to Figure 2 An exemplary embodiment of a sensor control device 110 of the disclosed subject matter is shown. Figure 2 A block diagram of an exemplary sensor control device 110 according to an exemplary embodiment compatible with the security architecture and communication scheme described herein is shown. As embodied herein, the sensor control device 110 may include an application specific integrated circuit ("ASIC") 200 communicatively coupled to a communication module 240. By way of example only and not limitation, the exemplary communication module 240 may include a Bluetooth low energy ("BLE") chipset 241, a near field communication ("NFC") chipset, or other chipsets for similar short-range communication schemes, such as personal area networks according to the IEEE 802.15 protocol, the IEEE 802.11 protocol, infrared communications according to the Infrared Data Association standard (IrDA), etc. The communication module 240 may transmit and receive data and commands through interaction with a similarly capable communication module of the data receiving device 120 or the multi-purpose data receiving device 130. As embodied herein, certain communication chipsets may be embedded in the ASIC 200 (e.g., the NFC antenna 225).

[0054] As specifically implemented herein, since the sensor control device 110 is designed to be energy efficient, low-cost and possibly disposable, the ASIC 200 may include a microcontroller core 210, an onboard memory 220 and a storage device 230. The storage device 230 may store data used in an authentication and encryption security architecture. The data may have various elements and uses, including as described in the examples herein. The ASIC 200 may receive power from a power module 250 (e.g., an onboard battery) or from an NFC pulse. The power module 250 may only store relatively little charge. As specifically implemented herein, the sensor control device 110 may be a disposable device with a predetermined lifespan and does not have wide area network communication capabilities. As specifically implemented herein, the communication module 240 may provide communication under battery power.

[0055] The microcontroller 210 also includes a timing control circuit 211 for waking the sensor control device 110 from a sleep state. The timing control circuit 211 may include a clock for synchronizing the timing of advertisements or connection events, and for entering a sleep state between advertisements or connection events. The clock may determine when the sensor control device 110 should wake up next time after processing an advertisement or connection event before entering sleep. The timing control circuit 211 may then set an event so as to wake up in time at the next advertisement or connection event. In addition, the microcontroller 210 may include a startup module 212. The startup module may include program instructions stored in a ROM, which are used to control modules within the sensor control device 110 when executed, such as a memory 220, a communication module 240, etc. Additionally or alternatively, the startup module 212 may be located on another circuit within the sensor control device 110. The microcontroller 210 includes an operating system module 213. The operating system module 213 supports applications or other separate functions running within the sensor control device 110. Additionally or alternatively, the operating system module 213 may be located on another circuit. The sensor control device 110 may include a protocol stack 230, which may include a controller and a host, each of which includes various communication layers. The protocol stack 230 may include or specifically implement the operation of the sensor control device 110 to communicate with other devices using one or more communication protocols. Additionally or alternatively, the protocol stack 230 may be located on another circuit within the sensor control device 110, for example, within the communication module 240.

[0056] Although the present disclosure is described with respect to exemplary configurations of the sensor control device 110 and the ASIC 200, other suitable configurations can be envisioned. As an example, the processing hardware of the sensor control device 110 can be implemented as another type of special-purpose processor, for example, a field programmable gate array (FPGA). As specifically implemented herein, the processing hardware of the sensor control device 110 may include a general-purpose processing unit (e.g., a CPU) or another programmable processor temporarily configured by software to perform the functions of the sensor control device 110. More generally, the processing hardware can be implemented using hardware, firmware, software, or an appropriate combination of hardware, firmware, and software. For purposes of illustration and not limitation, the processing hardware of the sensor control device 110 can be defined by one or more factors, including computing power, power capacity, storage capacity, availability of network connections, and the like.

[0057] As specifically implemented herein, the communication module 240 of the sensor 100 can be or include one or more modules to support the sensor control device 110 to communicate with other devices of the analyte monitoring system 100. In some embodiments, the sensor control device 110 can, for example, communicate with the data receiving device 120 or the user device 140. The communication module 240 may include, for example, a cellular radio module. The cellular radio module may include one or more radio transceivers and / or chipsets for communicating using a broadband cellular network, including but not limited to third generation (3G), fourth generation (4G) and fifth generation (5G) networks. Using the cellular radio module, the sensor control device 110 can communicate with a remote device (e.g., a remote server 150) to provide analyte data (e.g., sensor readings), and can receive updates or alerts from the user.

[0058] As another example, the communication module 240 may include a BLE module 241 and / or an NFC module to facilitate communication with a data receiving device 120 or a user device 140 acting as an NFC scanner or a BLE endpoint. As used throughout this disclosure, Bluetooth Low Energy ("BLE") refers to a short-range communication protocol that is optimized to enable end users to simply pair Bluetooth devices. The communication module 240 may include additional or alternative chipsets for similar short-range communication schemes, such as personal area networks according to the IEEE 802.15 protocol, IEEE 802.11 protocol, infrared communications according to the Infrared Data Association standard (IrDA), etc. The communication module 240 may transmit and receive data and commands through interaction with a communication module of similar capabilities of the data receiving device 120 or the user device 140. Certain communication chipsets may be embedded in the ASIC 200 (e.g., an NFC antenna loop). In addition, although not shown, the communication module 240 of the sensor control device 110 may include a radio for communicating using a wireless local area network according to one or more IEEE 802.11 standards (e.g., 802.11a, 802.11b, 802.11g, 802.11n (also known as Wi-Fi 4), 802.11ac (also known as Wi-Fi 5), 802.11ax (also known as Wi-Fi 6)). The communication module 243 may also include its own memory 243, which is connected to the microcontroller core for the communication module 240 and / or to the microcontroller core 210 of the ASIC 200 of the sensor control device 110.

[0059] The communication module 240 may include communication circuits, for example, an antenna 244, a transceiver 245, a memory 243, a processor 246, and a collection of one or more transmitting amplifiers and receiving amplifiers (collectively referred to as amplifiers 247). Although not shown, the communication module 240 may include multiple groups of communication circuits (for example, one group for a supported communication protocol). For the sake of simplicity, only a single group of communication circuits is shown. In some cases, the processor 246 of the communication circuit may be similar to the microcontroller 210. Alternatively, the transceiver 245 may be configured as a single component or a separate transmitter and a separate receiver. One or more transmitting amplifiers 247 are configured to be selectively connected between the output of the transmitter of the transceiver 245 and the antenna 244. One or more receiving amplifiers 247 are configured to be selectively connected between the antenna 244 and the input of the receiver of the transceiver 245.

[0060] As explained herein, without the addition of a transmit or receive amplifier 247, the transmitter and receiver of the transceiver 245 exhibit certain power and sensitivity limitations based on the components and design of the particular implementation. One or more transmit amplifiers 247 may be provided to selectively connect between the antenna and the output of the transmitter to increase the transmission power, for example, up to 10 dBm. As another example, when operating alone without the addition of a separate receive amplifier 247, the receiver of the transceiver 245 may exhibit a receive sensitivity as low as -85 dBm. One or more receive amplifiers 247 may be provided to selectively connect between the antenna 244 and the receiver input of the transceiver 245 to increase the receive sensitivity, for example, down to -100 dBm.

[0061] As explained herein, when the communication module 240 is initialized, the transmitter of the transceiver 245 can transmit an advertising notification set in the form of a complex (e.g., a communication packet including at least a payload that includes information that helps initiate discovery and a communication session with another device), and then enter a sleep state according to the advertising interval. The receiver of the transceiver 245 performs a scanning operation during a receiving window to scan for connection requests. The connection request may be sent independently in response to the advertising notification or by other devices. During a separate receiving window, the scanning operation may be performed during the same time period as the transmission of the advertising notification 224 through the corresponding advertising channel. Optionally, the receiving window and the scanning operation may continue after the transmission of the advertising notification is completed. Therefore, the scanning operation and the receiving window may be temporarily aligned with the complex of the advertising notification, or extend beyond the complex of the advertising notification 224 and enter the sleep state of the advertising interval.

[0062] As specifically implemented herein, a first security layer for communication between the sensor control device 110 and other devices can be established based on a security protocol specified and integrated into the communication protocol used for communication (e.g., BLE security protocol, Wi-Fi 5 security protocol). Another security layer can be based on communication protocols that require that the communicating devices must be very close. In addition, certain packets and / or certain data included in packets can be encrypted, while other packets and / or data within packets are encrypted or unencrypted. As an example, connection data and / or connection packets dedicated to establishing a communication connection between devices can be largely unencrypted - even if included in a connection packet - in order to facilitate discovery by other devices, sensitive analyte data can be encrypted.

[0063] Additionally or alternatively, another security layer can be based on an application layer used by the sensor control device 110 and other devices in communication, wherein the application layer uses one or more block cipher encryption to establish mutual authentication and encryption of other devices in the analyte monitoring system 100. There are several benefits to using a non-standard encryption design implemented in the application layer. One benefit of this approach is that in some embodiments, the user can complete the pairing of the sensor control device 110 and another device with minimal interaction, for example, using only NFC scanning, without the need for additional input, such as entering a security code or confirming the pairing.

[0064] In order to perform its function, the sensor 100 may also include suitable sensing hardware 260 suitable for its function. As specifically implemented herein, the sensing hardware 260 may include an analyte sensor positioned percutaneously or subcutaneously to contact the body fluid of the subject. The analyte sensor can generate sensor data containing values ​​corresponding to the level of one or more analytes in the body fluid. Additionally or alternatively, the sensing hardware 260 may include, for example, an automatic syringe, which is opened to the user for self-administration of drugs or other medicaments. Therefore, the sensing hardware 260 may include a mechanism for driving the needle or plunger of the syringe to deliver the drug subcutaneously. The syringe can be pre-filled with drugs and can be operated in response to a triggering event. For example, the mechanism can drive the needle into the user's body and advance the plunger to deliver the drug subcutaneously through the needle.

[0065] As embodied herein, the sensor control device 110 can be configured as a body-attached syringe that can be attached to a user's body tissue (e.g., skin, organ, muscle, etc.) and is capable of automatically delivering a subcutaneous injection of a fixed or user-selected dose of a drug over a controlled or selected period of time. In such an embodiment, the sensing hardware 260 or analyte sensor can include, for example: an adhesive or other device for temporarily attaching the sensing hardware 260 to the user's body tissue; a main container for storing a drug or medicament; a drive mechanism configured to drive or allow a plunger to be released to expel the drug from the main container; a cannula needle (e.g., a solid needle); a flexible cannula disposed around the cannula needle; an insertion mechanism configured to insert the cannula needle and / or the flexible cannula into the user's body, and optionally retract the cannula needle, leaving the flexible cannula in the user's body; a fluid pathway connector configured to establish fluid communication between the main container and the flexible cannula when the device is activated; and an actuator (e.g., a user-movable button) configured to activate the device. As embodied herein, the on-body syringe may be pre-filled and / or pre-loaded.

[0066] In addition to mechanical components, the sensing hardware 260 may include electrical and / or electronic components. For example, an electronic switch may be coupled to the mechanism. The sensor control device 110 may establish authenticated communications, receive an encrypted signal, decrypt the signal using the techniques of the present disclosure, determine that the signal includes a command to operate a switch, and cause the switch to actuate a needle. Thus, the analyte sensor specifically implemented herein may be configured to perform an analyte function using the sensing hardware 260 in response to a remote command.

[0067] As specifically implemented herein, the sensing hardware 260 may include a travel sensor and an analog-to-digital converter to generate a digital signal indicating the distance traveled by the needle or plunger. While delivering the drug, the low-power sensor control device 110 may obtain a reading from the sensor, encrypt the reading using the techniques of the present disclosure, and securely report the reading to another device. Additionally or alternatively, the sensor control device 110 may report other measurements or parameters, such as the time of drug delivery, the amount of drug delivered, any problems encountered while delivering the drug, etc. The sensor control device 110 may be configured to provide data related to the operation of the sensing hardware 260 to a remote device.

[0068] The sensing hardware 260 may be configured to implement any suitable combination of one or more analyte functions and may include one or more sensing components. The sensing components may be configured to detect the operating state of the sensor control device 110 (e.g., unpackaged / prepared for administration, sterile barrier removal, contact with user body tissue, cannula and / or needle insertion, drug delivery start, actuator or button displacement, drug delivery completion, plunger position, fluid path obstruction, etc.), the condition of the sensor control device 110 or the drug contained therein (e.g., temperature, shock or vibration exposure, light, drug color, drug turbidity, drug viscosity, geographic location, spatial orientation, time information, ambient air pressure, etc.), and / or physiological information about the user (e.g., body temperature, blood pressure, pulse or heart rate, glucose level, physical activity or movement, fingerprint detection, etc.). The detected information may be unloaded from the sensor control device 110 to facilitate storage and analysis, for example, unloaded to the data receiving device 120, the multi-purpose data receiving device 130, or the remote server 150. As embodied herein, sensor control device 110 may be configured to receive encrypted data from other devices and transmit encrypted data to other devices.

[0069] Still reference Figure 2, the ASIC 200 of the sensor control device 110 can be configured to dynamically generate authentication and encryption keys using data stored in the storage device 230. The storage device 230 can also be pre-programmed with a set of valid authentication and encryption keys for a specific class of devices. The ASIC 200 can also be configured to use the received data to perform authentication processes (e.g., handshakes, mutual authentication, etc.) with other devices and apply the generated keys to sensitive data before transmitting the sensitive data, for example, sending the sensitive data to the remote server 150 through the communication module 240. The generated keys can be specific to the sensor control device 110, specific to a pair of devices (e.g., specific to a specific pairing of the sensor control device 110 and the data receiving device 120), specific to a communication session between the sensor control device 110 and the other device, specific to a message sent during a communication session, or specific to a data block contained in a message. The techniques implemented by the ASIC 200 and the communication module 240 of the sensor control device 110 are discussed in more detail herein.

[0070] For purposes of illustration and not limitation, reference is made to Figure 3 An exemplary embodiment of a data receiving device 120 for use with the disclosed subject matter is shown. The data receiving device 120 and the related multi-purpose data receiving device 130 include components that are closely related to the discussion of the sensor control device 110 and its operation, and may include additional components. In specific embodiments, the data receiving device 120 and the multi-purpose data receiving device 130 may be or include components provided by a third party, and are not necessarily limited to including devices manufactured by the same manufacturer as the sensor control device 110. In specific embodiments, the data receiving device 120 may include a one-time or limited-use device that is configured to operate for a specific purpose or within a specific time period. As an example, the data receiving device 120 may include components of a multi-purpose device that is specifically configured to receive data from the sensor control device 120.

[0071] Figure 3 An example data receiving device 120 is shown that is compatible with the security and computing architecture described herein with respect to the exemplary embodiments. As embodied herein, the data receiving device 120 may comprise a small device. The data receiving device 120 may optionally not be as limited in memory or processing power as the sensor control device 110, and as embodied herein, the data receiving device 120 may include sufficient memory for operational software storage and data storage and sufficient RAM for software execution to communicate with the sensor control device 110 as described herein. Figure 3As shown, the data receiving device 120 includes an ASIC 300, which includes a microcontroller 310, a memory 320, and a storage device 330, and is communicatively coupled to a communication module 340. As specifically implemented herein, the ASIC 300 can be the same as the ASIC 200 of the sensor control device 110. Alternatively, the ASIC 300 can be configured to include additional computing capabilities and functions. Power for the components of the data receiving device 120 can be delivered by a power module 350, which can include a rechargeable battery, allowing for continuous operation and continuous use, as specifically implemented herein.

[0072] Certain embodiments of the data receiving device 120 may also include a display 370 for conveniently viewing the analyte data received from the sensor control device 110 or other devices (e.g., user device 140 or remote server 150). The display 370 may be an energy-efficient display with a relatively low screen refresh rate to save energy and further reduce the cost of the data receiving device 120. The display 370 may be a low-cost touch screen to receive user input through one or more user interfaces. Although not shown, the data receiving device 120 may include separate user interface components (e.g., physical buttons, light sensors, microphones, etc.). The power of the components of the data receiving device 120 may be delivered by a power module 350, which may include a rechargeable battery as specifically implemented herein, allowing continuous operation and continuous use. In a specific embodiment, the data receiving device 120 or the multi-purpose device 130 may be configured without a display and may be used to relay information from the sensor control device 120 to another component or system.

[0073] Although illustrated as separate components, in certain embodiments, the processor of the communication module 340 may perform processing operations typically performed by the microcontroller 310 of the ASIC 300. Thus, the ASIC 300 may be removed and memory or other storage devices added to the communication module to simplify the hardware required for the data receiving device 120.

[0074] The communication module 340 may include a BLE 341 module and an NFC module 342. The data receiving device 120 may be configured to wirelessly connect to the sensor control device 110, and transmit commands to the sensor control device 110 and receive data from the sensor control device 110. As specifically implemented herein, the data receiving device 120 may be configured to operate as an NFC scanner and a BLE endpoint relative to the sensor control device 110 described herein through a specific module of the communication module 340 (e.g., a BLE module 342 or an NFC module 343). For example, the data receiving device 120 may use a first module of the communication module 340 to issue a command to the sensor control device 110 (e.g., an activation command for a data broadcast mode of a sensor; a command pairing identifying the data receiving device 120 with the sensor control device 110), and use a second module of the communication module 340 to receive data from the sensor control device 110 and transmit data to the sensor control device 110.

[0075] As specifically implemented herein, the data receiving device 120 can be configured to communicate via a universal serial bus (USB) module 345 of the communication module 340. The data receiving device 120 can communicate with the user device 140, for example, via the USB module 345. The data receiving device 120 can, for example, receive software or firmware updates via USB, receive bulk data via USB, or upload data to a remote server 150 via the user device 140. The USB connection can be authenticated at each insertion event. Authentication can use, for example, two, three, four, or five passes with different keys. The USB system can support a variety of different key sets for encryption and authentication. Keys can match different roles (clinical, manufacturer, user, etc.). Sensitive commands that may leak security information can use authenticated additional key sets to trigger authenticated encryption.

[0076] As another example, the communication module 340 may include, for example, a cellular radio module 344. The cellular radio module 344 may include one or more radio transceivers for communicating using a broadband cellular network, including but not limited to third generation (3G), fourth generation (4G), and fifth generation (5G) networks. Using the cellular radio module 344, the data receiving device 120 can communicate with the remote server 150 to receive analyte data or provide updates or inputs received from a user (e.g., via one or more user interfaces). In addition, the communication module 340 of the data receiving device 120 may include a Wi-Fi radio module 343 for communicating using a wireless local area network according to one or more IEEE 802.11 standards (e.g., 802.11a, 802.11b, 802.11g, 802.11n (also known as Wi-Fi 4), 802.11ac (also known as Wi-Fi 5), 802.11ax (also known as Wi-Fi 6)).

[0077] As used throughout this disclosure, Bluetooth Low Energy ("BLE") refers to a short-range communication protocol that is optimized to enable end users to simply pair Bluetooth devices. As described herein, the use of BLE on the sensor control device 110 may optionally not rely on the standard BLE implementation of Bluetooth to ensure security, but may use application layer encryption that uses one or more block ciphers to establish mutual authentication and encryption. There are several benefits to using a non-standard encryption design implemented in the application layer. One benefit of this approach is that the user can complete the pairing of the sensor control device 110 and the data receiving device 120 by simply scanning with an NFC scan, without the user providing additional input, such as entering a security code or confirming the BLE pairing between the data receiving device and the sensor control device 110. Another benefit is that this approach reduces the possibility of allowing devices that are not in close proximity to the sensor control device 110 to be paired accidentally or intentionally, at least in part because the information used to support the pairing process is shared via a backup short-range communication link (e.g., NFC) over a short-range rather than a longer-range BLE channel. In addition, since no BLE pairing and bonding scheme is involved, pairing of the sensor control device 110 can avoid implementation issues of chip vendors or loopholes in the BLE specification.

[0078] As embodied herein, the onboard storage device 330 of the data receiving device 120 is capable of storing the analyte data received from the sensor control device 110 for a longer period of time. In addition, as embodied herein, the multi-purpose data receiving device 130 or the user computing device 140 may be configured to communicate with the remote server 150 via a wide area network. As embodied herein, the sensor control device 110 may provide sensitive data to the data receiving device 120 or the multi-purpose data receiving device 130. The data receiving device 120 may transmit the sensitive data to the user computing device 140. The user computing device 140 (or the multi-purpose data receiving device 130) may in turn transmit the data to the remote server 150 for processing and analysis. When communicating with the remote server 150, the multi-purpose data receiving device 130 and the user computing device 140 may generate a unique user token based on the authentication certificate entered by the user and stored in the respective devices. The authentication certificate may be used to establish a secure connection to the remote server 150, and may further be used to appropriately encrypt any sensitive data provided to the remote server 150. As embodied herein, the multipurpose data receiving device 130 and the user computing device 140 may optionally not be limited in their use of processing power, and therefore, standard data encryption and transmission techniques may be used for transmission to the remote server 150 .

[0079] As specifically implemented herein, the data receiving device 120 may also include sensing hardware 260 similar to the sensor control device 110 or sensing hardware 360 ​​extended therefrom. By way of example only and not limitation, in an embodiment where the sensing hardware 260 of the sensor control device 110 is configured for continuous glucose monitoring, the sensing hardware 360 ​​of the data receiving device 120 may be configured with a blood glucose meter, compatible with blood glucose test strips, thereby extending the blood glucose monitoring of the sensor control device 110. In a specific embodiment, the compatible device 130 may be configured to operate in coordination with the sensor control device 110 and based on analyte data received from the sensor control device 110. As an example, in the case where the sensor control device 110 is a glucose sensor, the compatible device 130 may be or include an insulin pump or an insulin injection pen. The compatible device 130 may coordinately adjust the user's insulin dosage based on the glucose value received from the analyte sensor.

[0080] Figure 4 An exemplary package according to certain embodiments is shown. Specifically, Figure 4The layout of a packet 400 for transmitting analyte data and connection data (e.g., advertising data or data for establishing a connection between devices) is shown. The packet 400 can be prepared according to the technology disclosed herein. In a specific embodiment, the packet 400 may include a packet header 405. By way of example and not limitation, the packet header 405 may include information that will be used by a receiving device (e.g., a data receiving device 120 or a user device 140) to identify how the payload 410 should be interpreted. As an example, the packet header 405 may identify that the packet 400 includes connection data. As another example, the packet header 405 may identify that the packet 400 includes analyte data. The packet header 405 may include one or more identification values ​​specified by the manufacturer of the sensor control device 110 or selected according to the communication protocol. The identification value can uniquely indicate the purpose and potential use of the packet 400 to a receiving device configured to interpret the identification value. The identification value can be unique between manufacturers using, for example, a specific communication protocol compatible with the communication module of the sensor control device 110. For example, the identification value may indicate that the packet 400 is a data connection packet or an advertising data packet. As another example, the identification value may indicate that the packet 400 is an enhanced connection packet or an advertising packet including manufacturer-specific information, such as encrypted analyte data 425.

[0081] Additionally or alternatively, as embodied herein, packet header 405 may include information indicating that packet 400 originated from sensor control device 110. Packet 400 may indicate the manufacturer of sensor control device 110. In particular embodiments, the amount and scope of identifying information included in packet header 405 may be selected to ensure that payload 410 can be interpreted by a receiving device while still maintaining the security of the subject's identity, the sensor control device 110's identity, the analyte data included in the packet, etc.

[0082] Still reference Figure 4, the packet 400 may include a payload 410. The format of the payload 410 may be predetermined by the manufacturer of the sensor control device 110 to correspond to the information included in the packet header 405. Thus, the receiving device may interpret the data in the payload 410 using the packet header 405. In a specific embodiment, the payload 410 may include a payload header 415, connection data 420, and analyte data 425. The payload header 415 may include further information that facilitates the interpretation of the data included in the payload 410. For example, the payload header 415 may indicate the expected size of the payload 410, or classify or otherwise indicate the information included in the payload 410. As embodied herein, the sensor control device 110 may operate in different modes that are associated with the preparation and broadcasting of packets of different categories or types, which include payloads of corresponding categories or types. Various aspects of the data included in a given payload (e.g., the data type, the data format, or the arrangement or layout of the data) may vary based on the category of the payload. As an example and not limitation, in the connectable packet mode, the sensor control device 110 may include connection data 420 in the payload 410. The connectable packet mode may be configured to facilitate the sensor control device 110 to establish a communication session with the receiving device to unload the stored data. When operating in the connectable packet mode, the sensor control device 110 may allocate more space to the connection data 420 than the space otherwise allocated by the sensor control device 110. As another example and not limitation, in the information packet mode, the sensor control device 110 may include analyte data 425. The information packet mode may be configured to facilitate the sensor control device 110 to broadcast a selected subset of the analyte data for the receiving device to receive and interpret, without paying much attention to establishing a subsequent communication session. When operating in the information packet mode, the sensor control device 110 may allocate more space to the analyte data 425 than the space otherwise allocated by the sensor control device 110. As another example and not limitation, in the mixed packet mode, the sensor control device 110 may include the connection data 420 and the analyte data 425. In addition to or as an alternative to the connectable packet mode, the information packet mode, and the hybrid packet mode, the sensor control device 110 can operate in various other modes and / or include additional information within the payload 410. As an example, the sensor control device 110 can operate in a low power mode, in which the sensor control device 110 can adjust the number of packets broadcast and include data corresponding to a low power alert. The payload header 415 can specify the category of the payload 410 included in the packet 400.After the receiving device receives the packet 400, the receiving device may interpret the payload header 415 of the received packet 400 to determine the category of the received packet's payload 410. The receiving device may effectively determine how to interpret the received packet's payload 410 based on determining the category of the payload 410. Additionally or alternatively, the receiving device may detect an error in the payload 410, for example, based on data retrieved from the payload 410 not corresponding to an expected format or arrangement.

[0083] In a particular embodiment, the payload 410 may include connection data 420. The connection data 420 may include a set of parameters to facilitate the establishment of a connection between the receiving device and the sensor control device 110. For example, the connection data 420 may include information detailing the connection process desired by the sensor control device 110. The connection process may include an encoding scheme to be used by the sensor control device 110. In a particular embodiment, the connection data 420 may include an identifier of the sensor control device 110 and / or a device to which the sensor control device 110 wants to connect, if known. By way of example only and not limitation, the identifier may include a unique device identifier, an identifier associated with a communication protocol (e.g., a Bluetooth identifier or a BLE identifier), an identifier associated with the networking and / or communication hardware of the sensor control device 110 (e.g., a media access control address (“MAC address”)), or other suitable identifier. If the communication protocol used by the analyte sensor (e.g., a communication protocol compatible with the communication module 240 of the sensor control device 110) supports the use of multiple communication channels and / or channel modulation, the connection data may include information for the receiving device to initiate a communication session accordingly. In particular embodiments, the packet 400 may be configured to appear as a data packet or advertising data packet that complies with an established communication protocol or standard supported by the communication module 240 of the sensor control device 110. For example, to promote broad compatibility with the sensor control device 110, the sensor control device 110 may use one or more connection promotion or advertising data formats specified by the communication protocol. The connection data 420 included in the payload 410 may be configured according to those formats.

[0084] In a specific embodiment, the payload 410 may also include analyte data 425. As described herein, the sensor control device 110 may include sensing hardware 260, which may include one or more sensors. Analyte data 425 may include data received from one or more sensors. As an example and not limitation, the data may include raw data from one or more components of the sensing hardware 260 (e.g., signal values ​​read from an analog-to-digital converter), data for processing raw data from components of the sensing hardware 260 (e.g., temperature levels, noise levels, etc.), data that has been processed by the sensor control device 110 into another usable format (e.g., human-readable data), etc. The data may also include derived values ​​calculated from the sensor data, such as calculated rates of change, trend values, predicted values, etc. Additionally or alternatively, the sensing hardware 260 may include components for delivering treatment to the subject's analyte data. For example, the sensor control device 110 may include an insulin pump, and the sensing hardware 260 may include hardware for injecting a certain amount of insulin. Analyte data 425 may include information related to the delivered therapy, including, but not limited to, the frequency of therapy, the cumulative amount or effect of therapy delivered, the remaining capacity of sensing hardware 260 to deliver therapy, the time when therapy was last delivered, and the like.

[0085] In a specific embodiment, the payload 410 may also include an integrity check value 430. The integrity check value 430 may be a value calculated or derived from the data included in the payload 410 or the packet 400, which may be used as a way for the receiving device to effectively determine whether the data in the payload 410 has been intentionally or unintentionally modified during transmission, encryption / decryption, etc. As described above, the data stored in the payload 410 may include the analyte data 425 or other sensitive data of the subject. Ensuring the integrity of the data is an important feature of the analyte monitoring system 100, especially in the case where the data can be used to generate an alarm or inform a diagnosis about the health of the subject. In a specific embodiment, when the receiving device receives the packet 400 (and decrypts the payload 410, if the integrity check value 430 is stored in the payload 410), the receiving device may compare the value of the integrity check value 430 with the corresponding check value 430. If the received integrity check value 430 does not correspond to the corresponding check value 430, the receiving device may ignore the payload 410, or notify the sensor control device 110, the subject, or the user of the receiving device of a possible error. In a particular embodiment, the corresponding check value may include a value calculated by the receiving device after receiving the packet 400 using the same algorithm or formula and input data used by the sensor control device 110 when preparing the integrity check value 430 before transmission. By way of example and not limitation, the integrity check value 430 may include an error detection code whose size is determined based on the size of the payload 410 and / or the packet 400. By way of another example and not limitation, the integrity check value 430 may include a checksum or other cryptographic hash value derived from the data in the payload 410 or the packet 430.

[0086] Packet 400 may include Figure 4Other values ​​not shown in the packet 400. As an example, the packet 400 may include a counter value corresponding to the total normal operation time of the sensor control device 110. The data packet 400 may include a value representing the expected remaining functional life of the sensor control device 110 (e.g., the expected remaining battery life of the sensor control device 110, the expected remaining availability of any limited time use material within the sensor control device 110, etc.). The packet 400 may include, for example, a timestamp corresponding to the time when the analyte data 425 was collected or the time when the packet 400 was sent. The receiving device may use the timestamp to verify that the analyte data 425 corresponds to data useful to the subject and / or the user of the receiving device. For example, if the age of the timestamp associated with the packet 400 is greater than the threshold age, the receiving device may determine not to represent the analyte data 425 as containing the current value of the analyte data 425, but to represent the analyte data 425 as containing only the most recent value of the analyte data 425. In a specific embodiment, the packet 400 may include manufacturer-specific data set or requested by the manufacturer of the sensor control device 110 and / or the operator of the analyte monitoring system 100.

[0087] In particular embodiments, some or all of the data included in the data payload 410 may be encrypted. For example, the entirety of the payload 410 may be encrypted, data included in the payload 410 may be encrypted in addition to the payload header 415, only the analyte data 425 or the connection data 420 may be encrypted, and so on. In particular embodiments, the sensor control device 110 may encrypt the appropriate data prior to preparing the payload 410 and the packet 400. As described herein, the encryption performed by the sensor control device 110 may be informed by a balance between the computational complexity of the cipher and the low-cost components used in the sensor control device 110.

[0088] Figure 5 An exemplary process 500 for transmitting analyte data within a connection packet from a sensor control device 110 (e.g., an analyte monitoring device) according to an embodiment disclosed herein is shown. The exemplary process 500 also includes actions that the sensor control device 110 can take after the analyte data has been transmitted. Through the process 500, the analyte data is transmitted in an encrypted payload of a data packet through a communication channel for device discoverability, accelerating the transmission of high priority analyte data. As shown, the process 500 can be repeated, and each iteration of the process 500 can follow one or more paths based at least in part on the behavior of the sensor control device 110 and other devices of the analyte monitoring system 100.

[0089] At 505, the sensor control device 110 may collect analyte data from the subject. As described herein, the sensor control device 110 may include sensing hardware for monitoring the health status of the subject (e.g., the wearer of the sensor control device 110). In a specific embodiment, the sensing hardware may include an analyte sensor for measuring the level of an analyte (e.g., glucose, lactate, oxygen, etc.) in the subject's body fluid (e.g., blood, sweat, extracellular fluid or interstitial fluid, etc.). In a specific embodiment, the sensing hardware may include a temperature sensor, an activity or motion sensor, a heart rate sensor, or other sensing hardware. The sensor control device 110 may receive input from the sensing hardware (e.g., an analyte sensor, a temperature sensor, etc.) in a streaming manner, which input may include or correspond to the health characteristics or status of the subject (e.g., analyte level, blood or skin temperature, etc.). In a specific embodiment, the input from the sensing hardware may be processed by an analyte sensor. The input may be temporarily stored in a memory of the sensor control device 110 (e.g., a volatile memory or a RAM of an ASIC or other control unit). As described, the sensor control device 110 may be a relatively low-cost sensor control device 110 that may lack significant computing power, storage, or output capabilities (e.g., to output information related to the analyte data). Therefore, the sensor control device 110 may offload the received data to another device after the received data has been stored in the memory of the sensor control device 110, for example, for further processing or display.

[0090] At 510, the sensor control device 110 may determine an operating mode of the sensor control device 110, which, as described herein, is associated with the preparation and broadcasting of packets of different categories or types that include payloads of corresponding categories or types. Specifically, the sensor control device 110 may periodically broadcast data from sensing hardware and / or information that facilitates a connection between the sensor control device 110 and a receiving device (e.g., a data receiving device 120, a multi-purpose data receiving device 130, or a user device 140). The sensor control device 110 may prepare and broadcast packets, such as packet 400, that include selected data. As an example, the sensor control device 110 may prepare and broadcast packets once per second, once every two seconds, once every five seconds, and so on. As specifically implemented herein, the sensor control device 110 may select which information to include in the packets. For example, the sensor control device 110 may select which information to include periodically (e.g., packets with connectivity data are evenly split between packets with analyte data, a pattern of one packet with connectivity data is followed by every five packets with analyte data, five packets with connectivity data is followed by every fifty packets with analyte data, etc.). The sensor control device 110 may select which information to include based on the last time the sensor control device 110 connected to the receiving device or unloaded data contained in the memory of the analyte sensor to the receiving device, the amount of battery life remaining, or the expiration date of the sensor control device 110, etc.

[0091] At 510, if the sensor control device 110 determines to operate in the information packet mode, then at 515, the sensor control device 110 identifies the analyte data contained in the data packet. The analyte sensor can select the analyte data from the memory of the sensor control device 110 to include in the packet. In a specific embodiment, the amount of space available in the packet (e.g., in the payload 410 of the packet 400) can be adjusted to reduce the computational cost of frequently preparing and sending packets and reduce the chance that the receiving device can only receive a portion of the packet. Therefore, a subset of the analyte data stored by the sensor control device 110 can be identified for inclusion in the packet.

[0092] In a specific embodiment, the sensor control device 110 can use a prioritization scheme to determine which analyte data are included in the package. The sensor control device 110 can determine the priority of the analyte data and select the data included in the package based on the priority. As an example, the priority can be related to the age of the analyte data (e.g., the time since the analyte data was collected). In a specific embodiment, the sensor control device 110 can set the highest priority for the recently collected data to ensure that if the receiving device receives the package and outputs the analyte data, the user of the receiving device can see the recent or current analyte data. As another example, the sensor control device 110 can set the highest priority for the severity or urgency of the analyte data. For example, the analyte data can include the analyte level in the subject's fluid. The analyte level can be associated with one or more thresholds, and the threshold indicates, for example, a range of safe levels, a level above or below that is determined to be safe, a level of high or low danger, etc. The priority of the analyte data can be determined by comparing the analyte data with one or more thresholds. Then, if the receiving device receives the package and outputs the analyte data, the user of the receiving device can receive the most urgent or most critical data. More than one prioritization scheme can be used together. For example, all analyte data having the same urgency priority may be sorted according to the age of the analyte data.

[0093] At 520, the sensor control device 110 may encrypt the analyte data identified as being contained in the data packet. As described herein, the analyte data may include sensitive information about the health or identity of the subject. In order to protect sensitive information, the sensor control device 110 may use one or more block ciphers or other encryption schemes to encrypt the analyte data. In a specific embodiment, the sensor control device 110 may use a private key stored by the sensor control device 110 as an encryption key. As described herein, a public key associated with the private key of the sensor control device 110 may be provided to a user device configured to (and optionally authorized to) receive and process analyte data from a subject to decrypt the data upon reception. In an embodiment where the sensor control device 110 and the receiving device have already identified each other (e.g., the sensor control device 110 and the receiving device have previously established a communication session or the receiving device has issued an activation command to the sensor control device 110), the sensor control device 110 and the receiving device may agree on an encryption key for subsequent iterations of the process. In a specific embodiment, an encryption key may be dynamically generated, for example, based on a device secret or private value and a deterministic change value (e.g., a monotonically increasing value or timestamp). The receiving device may use the same device secret and the deterministic changing value to calculate the decryption key. In particular embodiments, a key rotation scheme may be used to select the encryption key.

[0094] As specifically implemented herein, the public key shared by the sensor control device 110 and the receiving device can be established by using a multi-step process, in which the sensor control device 110 authenticates itself to the receiving device, and the receiving device authenticates itself to the sensor control device 110. This is used to verify that the sensor control device 110 is a real (authentic) sensor compatible with the receiving device, and the receiving device is approved to receive data from the sensor control device 110. For example, the receiving device can provide the sensor control device 110 with a valid certificate or token digitally signed by the manufacturer of the sensor control device 110 or the receiving device or the operator of the analyte monitoring system 100. The certificate or token can be verified by confirming that the certificate or token has been digitally signed using a key associated with the appropriate manufacturer or operator. Similarly, the sensor control device 110 can provide a valid certificate or token to the receiving device, which has been digitally signed using a key associated with the appropriate manufacturer or operator. Each certificate or token can include a public key uniquely paired with a private key known to the device providing the certificate or token. The private key can also be established by an appropriate manufacturer or operator of the analyte monitoring system. Once a valid certificate or token is received, the device providing the certificate or token may also prove that it controls the private key. Proof of control can be established by decrypting selected information (e.g., a randomized or non-sequential value) encrypted using the public key included in the verified certificate. This information can be used to generate a shared symmetric authentication key that can be used for subsequent authentication and encryption.

[0095] At 510, if the analyte sensor determines to operate in the connectable packet mode or the non-information packet mode, then at 525, the sensor control device 110 prepares connection data 525 to be included in the data. As described herein, the connection data 525 may include data that facilitates receiving a device request and opening a communication session with the sensor control device 110. The connection data 525 may include data specifying a protocol that the sensor control device 110 may use to accept the communication session request.

[0096] In particular embodiments, the sensor control device 110 may include one or both of the connection data and the analyte data in a single packet, for example, when operating in a mixed packet mode ( Figure 5). For example, rather than determining which of analyte data or connection data to include, the decision at 510 may include determining whether to include connection data, wherein each packet includes analyte data. The decision at 510 may include determining whether to include analyte data, wherein each packet includes connection data. In specific embodiments, the size allocated to the packet may be limited to facilitate reducing transmission errors. The decision of which data to include (e.g., connection data or analyte data) may result from a programmed or dynamic determination of whether the sensor control device 110 prioritizes establishing a connection or broadcasting a packet with analyte data. Additionally or alternatively, other types of data may optionally be included in the packet, and the decision at 510 may include determining whether to include other types of data with the analyte data or the connection data.

[0097] At 530, the sensor control device 110 may prepare a data packet for broadcasting. Depending on the operating mode determined at 510, the data packet may include analyte data, connection data, or other data. The sensor control device 110 may prepare the selected data into a payload by setting the collected data into a predetermined format that the receiving device can interpret. The sensor control device 110 may prepare a header for the payload that provides information to the receiving device so that the receiving device can determine how to interpret the payload. The sensor control device 110 may verify the payload, for example, by preparing one or more integrity check values ​​for the payload. The sensor control device 110 may prepare a header for a data packet including a payload to facilitate a receiving device that is not configured to interpret the payload 110 in the environment of the sensor control device 110 to determine whether the data in the packet can be used. In a specific embodiment, for example, where the sensor control device 110 has previously been paired with a receiving device, as described herein, the header of the data packet may include identification data of the receiving device to direct the data packet to the receiving device.

[0098] At 535, the sensor control device 110 may broadcast the data packet to the environment of the analyte sensor and / or transmit the data packet to one or more receiving devices within the communication range of the analyte sensor using the communication module of the analyte sensor. The environment may include multiple receiving devices (e.g., data receiving device 120, multi-purpose data receiving device 130, user device 140, etc.). Broadcasting may involve causing one or more transceivers (e.g., transceivers of the communication module 240 of the analyte sensor) to transmit a signal including the data packet in the environment using one or more communication channels specified by the communication protocol used by the communication module. The signal may be non-directional, or not directed to a specific receiving device in the environment. The communication channel may be reserved specifically for broadcast packets, which may include connection information to facilitate discovery and establishment of communication sessions between devices.

[0099] At 540, within a determined period of time after broadcasting the data packet into the environment, the sensor control device 110 may wait to receive an acknowledgment signal from a user device in the environment. As described herein, the environment of the sensor control device 110 may include multiple receiving devices. Each receiving device may receive a signal including a packet broadcast by the sensor control device 110. Each receiving device may attempt to process the packet to determine whether the data of the packet can or should be used. For example, a receiving device may analyze a header of a data packet to determine whether the data packet is directed to the receiving device or is non-directed. If the data packet is not directed to another device, the receiving device may attempt to read the payload, for example, according to a protocol listed in a header of the data packet. In the event that the payload is encrypted, the receiving device may attempt to decrypt the data packet using, for example, a stored encryption key. If the receiving device has a suitable decryption key, the receiving device may decrypt the payload and process the data contained therein. For example, if the data of the payload includes analyte data, the receiving device can extract the analyte data of the subject from the decrypted data payload, process the extracted analyte data if necessary, and output the analyte data to a user of the receiving device (e.g., provide the analyte data to a display of the receiving device, output one or more warnings or alarms based on the analyte data, upload the analyte data to a remote server, etc.). When outputting the extracted analyte data, the receiving device can indicate that the analyte data corresponds to the highest priority data (e.g., the most recently collected data, the most urgent data based on the user's condition, etc.).

[0100] After processing the data packet and payload, the receiving device may attempt to transmit an acknowledgment signal to the sensor control device 110 to indicate that the payload of the data packet has been received. As an example, if the payload does not include connection data, the receiving device may broadcast a non-directional packet including information that can be interpreted by the sensor control device 110. The non-directional packet may include an encrypted payload encrypted using a shared encryption key or scheme, including information for the sensor control device 110 to acknowledge that the payload has been received. As another example, if the payload does include connection data, the receiving device may attempt to send a confirmation signal with a connection request, for example, using a connection protocol specified by the connection data.

[0101] At 540, if the sensor control device 110 receives the confirmation signal during the time period in which the sensor control device 110 is turned on to receive the confirmation signal, the sensor control device 110 may take further action based on the confirmation signal. For example, as shown, at 545, the sensor control device 110 may establish a communication session with the receiving device from which the confirmation signal was received. Establishing the communication session may include employing multi-step device authentication and handshaking, which may reuse a shared encryption key, and additionally or alternatively, may use an additional communication session key to encrypt data exchanged between the sensor control device 110 and the receiving device in transmission.

[0102] At 550, the sensor control device 110 can use the communication session to backfill the analyte data to the receiving device. For example, the sensor control device 110 can use the communication session to unload the analyte data stored by the analyte sensor, which has not been previously unloaded to one or more receiving devices for processing and / or reporting. As described herein, the analyte sensor can collect analyte data in a streaming manner, for example, continuously or regularly, for example, once a minute during the life of the sensor control device 110. The sensor control device 110 can be disconnected from the receiving device or exceed the range of the receiving device. Therefore, the sensor control device 110 stores a certain amount of analyte data (for example, within a predetermined time period). When the sensor control device 110 is reconnected to the receiving device, the analyte sensor can determine which data has not been unloaded, prepare the data for transmission through the communication session, and send the data to the receiving device. In a specific embodiment, the sensor control device 110 can, for example, delete these data after sending all the analyte data unloaded to the receiving device. Additionally or alternatively, the sensor control device 110 may include sufficient memory to store analyte data generated during its lifetime, particularly if the sensor control device 110 is designed to have a limited lifespan. Additionally or alternatively, the sensor control device 110 may save the analyte data until the space is needed, and overwrite some pieces of the data first (e.g., the oldest, lowest priority, or least relevant data may be deleted or overwritten first).

[0103] In some embodiments, after the sensor control device 110 establishes a communication session, the receiving device can determine the data to be backfilled by the sensor control device 110. As an example, the receiving device can track the analyte data received over time (e.g., through one or more communication sessions). As another example, the received analyte data can also be stored with a timestamp associated with the time when the analyte data was generated and / or the date and time associated with the analyte reading used to generate the analyte data. As another example, the received analyte data can be stored with a counter value that is uniquely attributed to a set of analyte data. For example, the counter value can be incremented with each additional reading of the analyte data by the sensor control device 110. The receiving device can determine that there is a gap in the stored analyte data based on the timestamp and / or the counter value. The receiving device can request the sensor control device 110 to send the missing data, for example, by specifying a timestamp range and / or a counter value range for the missing. In response, the sensor control device 110 can identify the analyte data corresponding to the timestamp range and / or the counter value range, and transmit the analyte data to the receiving device. Once all of the analyte data specified by the ranges is provided to the sensor control device 110 and / or the receiving device, a confirmation is provided that all of the specified data has been received.

[0104] Additionally or alternatively, the sensor control device 110 determines data to be backfilled after the communication session is established. When identifying analyte data to be backfilled, the sensor control device 110 can also unload all stored data except the highest priority data (included in the broadcast data packet). As another example, the analyte sensor can store a timestamp of the last time analyte data was unloaded from the sensor control device 110. The analyte sensor can identify analyte data records between the timestamp and the current timestamp and transmit the identified analyte data. In specific embodiments, the backfill process can also use a data prioritization scheme (e.g., first in, first out; last in, first out; highest priority, most severe, other priority schemes, or combinations thereof).

[0105] As specifically implemented herein, the sensor control device 110 may maintain a record of the time elapsed since the sensor control device 110 has received a confirmation signal from the user device and / or the time elapsed since a successful communication session has been completed. As an example, the sensor control device 110 may associate a timestamp with the confirmation signal and, upon receiving the confirmation signal, update the timestamp accordingly. Additionally or alternatively, the sensor control device 110 may maintain other records indicating the state of the analyte data stored on the sensor control device 110 and the communication history between the sensor control device 110 and the receiving device. As an example, the sensor control device 110 may include a record of the time since the last communication session, the earliest analyte data record stored on the analyte sensor, and the like. After the communication session is closed, the sensor control device 110 may update the record associated with the time since the last communication session. Note that the sensor control device 110 may store separate timestamps associated with the confirmation signal and the communication session. By maintaining two timestamps (or other records indicating communications between the sensor control device 110 and the receiving device), the sensor control device 110 can track the presence of the receiving device in the environment of the analyte 110 and also track the historical integrity of data offloaded from the sensor control device 110. As described herein, the sensor control device 110 can use the indication of the presence or absence of the receiving device in the environment to change its behavior in an attempt to facilitate a connection.

[0106] At 540, if the analyte sensor determines that no confirmation has been received from the receiving device, the sensor control device 110 may determine at 555 whether the time since the sensor control device 110 last received the confirmation meets the threshold time. Additionally or alternatively, the sensor control device 110 may determine whether the time since the last communication session or the age of the latest analyte record received meets the threshold. Other metrics may also be used to determine whether the sensor control device 110 should change its behavior to try to facilitate the connection. The metric may indicate, for example, that there is a connection problem between the sensor control device 110 and the receiving device, that the sensor control device 110 and the receiving device are not within a suitable proximity (e.g., a distance based on the communication range of the communication module 240 of the sensor control device 110), that the receiving device is disabled, etc. In an embodiment in which the connection data is only included in a subset of the packets sent by the sensor control device 110, the inability to receive the confirmation signal may be due to the sensor control device 110 and the receiving device not being within the necessary range at the appropriate time (e.g., when the packet including the connection data is being broadcast).

[0107] If, at 555, the sensor control device 110 determines that the time since the last acknowledgement or communication session does exceed a threshold, or other indicia of a potential communication problem exists, then at 560, the sensor control device 110 may be configured to change its discoverability behavior in an attempt to increase the probability that a receiving device will receive an appropriate data packet and / or provide an acknowledgement signal, or to reduce limitations that may result in a failure to receive an acknowledgement signal. Changing the discoverability behavior of the sensor control device 110 may include, for example, but not limited to, changing the frequency with which connection data is included in data packets, changing the frequency at which data packets are typically transmitted, extending or shortening the broadcast window for data packets, changing the amount of time that the sensor control device 110 listens for an acknowledgement signal after a broadcast, including directed transmissions to one or more devices that have previously communicated with the sensor control device 110 (e.g., through one or more attempted transmissions) and / or to one or more devices on a whitelist of known or authorized devices, changing the transmission power associated with the communication module when broadcasting data packets (e.g., to increase the broadcast range or reduce energy consumption and extend the battery life of the analyte sensor), changing the rate at which data packets are prepared and broadcast, or a combination of one or more other changes. Additionally or alternatively, the receiving device may similarly adjust parameters associated with the device's listening behavior to increase the likelihood of receiving a data packet including connection data. For example, after a threshold time period has passed during which no data packets have been received by the receiving device, the receiving device may increase the amount of time or frequency during which the receiving device's communication hardware is active and able to receive connection data (e.g., increase the window in which scans are performed for data packets, particularly data packets including connection data). If the attempt to increase discoverability is unsuccessful after a particular time period, the sensor control device 110 and the receiving device may revert to the original settings.

[0108] As specifically implemented herein, the sensor control device 110 can be configured to broadcast data packets using two types of windows. The first window refers to the rate at which the sensor control device 110 is configured to operate the communication hardware. The second window refers to the rate at which the sensor control device 110 is configured to actively transmit data packets (e.g., broadcast). As an example, the first window may indicate that the sensor control device 110 operates the communication hardware to send and / or receive data packets (including connection data) during the first 2 seconds of each 60-second cycle. The second window may indicate that during each 2-second window, the sensor control device 110 transmits a data packet every 60 milliseconds. During the rest of the 2-second window, the sensor control device 110 is listening. The sensor control device 110 can extend or shorten either window to modify the discoverability behavior of the sensor control device 110. For example, a 2-second window can be extended to 4 seconds (e.g., the first 4 seconds in each 60-second cycle) or shortened to 1 second (e.g., the first second in each 60-second cycle). As another example, the 60 second period can be lengthened (e.g., to save battery by reducing the amount of time the communication hardware is active) or shortened (e.g., to increase the likelihood that the communication hardware is active when the receiving device is in range). As another example, the 60 millisecond period can be lengthened or shortened.

[0109] In a specific embodiment, the discoverability behavior of the analyte sensor can be stored in a discoverability profile and can be changed based on one or more factors (e.g., the state of the sensor control device 110) and / or by applying rules based on the state of the sensor control device 110. For example, when the battery power of the sensor control device 110 is below a certain amount, the rule can cause the sensor control device 110 to reduce the power consumed by the broadcast process. As another example, the configuration settings associated with broadcasting or otherwise transmitting packets can be adjusted based on the ambient temperature, the temperature of the sensor control device 110, or the temperature of certain components of the communication hardware of the sensor control device 110. For example, when the temperature of the sensor control device 110 or its communication hardware reaches a first threshold temperature (e.g., below a threshold or exceeding a threshold), the transmission power associated with the broadcast process can be reduced. In addition, when the temperature reaches a second threshold temperature, the process of transmitting a packet including connection data (e.g., an advertising data packet) can be suspended altogether. After the temperature returns to meet another threshold, the process can be restarted and / or the transmission power can be adjusted. In addition to modifying the transmission power, other parameters associated with the transmission capabilities of the communication hardware of the sensor control device 110 or the process may be modified, including but not limited to transmission rate, frequency, and timing. As another example, when the analyte data indicates that the subject is or will experience a negative health event, the rule may cause the sensor control device 110 to increase its discoverability to alert the receiving device of the negative health event. Since the process 500 is repeated many times and may be repeated over the working life of the sensor control device 110, changes to the device discoverability may propagate and affect future iterations of the process 500.

[0110] At 555 , if the sensor control device 110 determines that the time since the last confirmation has not exceeded a threshold, or other indicia of a communication problem does not exist, the analyte sensor returns to 505 , continues to collect analyte data 110 , and the process 500 repeats.

[0111] In a specific embodiment, the sensor control device 110 may receive an activation command from a specific user device. In a specific embodiment, the activation command may be received via a first communication interface (e.g., NFC), and the sensor control device 110 may broadcast packets via a second communication interface (e.g., BLE). The activation command may be received before the sensor control device 110 begins collecting analyte data, before the analyte sensor broadcasts data, or at any point during process 500. The sensor control device 110 and the receiving device may use the activation command to positively identify each device to each other. The activation command may include instructions related to the broadcast or discoverability behavior of the sensor control device 110. These instructions may affect, for example, the rate at which the analyte sensor prepares data (including but not limited to connection data, analyte data, or other data), the rate at which the analyte sensor broadcasts packets, whether packets are directed to a specific user device or broadcast to an environment external to the analyte sensor, or execution. Figure 5 other relevant parameters of the sensor control device 110 of the process 500 shown. The activation command may also include instructions as to whether the process 500 should be used under any circumstances. For example, prior to receiving the activation command, the sensor control device 110 may be configured to operate in a connectable packet mode and not transmit analyte data in packets (e.g., each packet includes connection data but not analyte data). Then, after receiving the activation command, the sensor control device 110 may be configured to selectively operate in an information packet mode to transmit analyte data in broadcast packets, which may be transmitted, for example, according to a predetermined schedule or a user-defined schedule, as described herein. As embodied herein, the sensor control device 110 and the receiving device may use the activation command to initiate a first communication session during which analyte data (e.g., currently stored by the sensor control device 110) is offloaded to the receiving device. The first communication session may be in Figure 5 The sensor control device 110 and the receiving device may close the communication session before the process 500.

[0112] As an example, the subject (or the user of the receiving device) can instruct the receiving device to send an activation command to the sensor control device 110 so that the analyte sensor enters the broadcast mode, wherein the current analyte data is sent via a data packet according to the embodiment disclosed herein. The sensor control device 110 can continue to operate in the broadcast mode within a fixed or specified amount of time or before the sensor control device 110 receives a deactivation command. As an example, an athlete running around a track can wear the sensor control device 110, and it is desired to send the analyte data to the receiving device, which keeps substantially stationary around the track (for example, held by a coach or other observer). In a normal (for example, non-broadcast) mode, the sensor control device 110 cannot establish a communication session with the receiving device to send the relevant analyte data to be output by the receiving device. Before the athlete starts running around the track, the athlete can make the receiving device send an activation command to the sensor control device 110 to initiate the broadcast mode and identify the receiving device. Then, when the athlete runs around the track, the sensor control device 110 can broadcast the analyte data received by the receiving device. The receiving device may process the analyte data using the embodiments disclosed herein, output current analyte data, issue alerts regarding the athlete's health, and quickly send the highest priority analyte data.

[0113] By inserting analyte data into a data packet, as embodied herein, the sensor control device 110 can improve the speed and reliability of transmitting high priority or current analyte data to a user of a receiving device, wherein the data packet is broadcast on or using a communication channel that is normally used only to discover and establish a communication session. Rather than waiting to establish a communication session and offload the appropriate data from the sensor control device 110 to the receiving device, the sensor control device 110 and the receiving device can exchange the most relevant data first and allow the user of the receiving device to view the most relevant data while offloading the remaining data stored on the sensor control device 110. Thus, in addition to improving the actual transmission speed of the most relevant data, the user's perception of the transmission speed of the remaining data is also improved.

[0114] According to various aspects of the disclosed subject matter, and as embodied herein, the sensor control device 110 may be configured to communicate with multiple devices simultaneously by adapting the characteristics of the communication protocol or medium supported by the hardware and radio of the sensor control device 110. As an example, the BLE module 241 of the communication module 240 may be provided with software or firmware to enable multiple simultaneous connections between the sensor control device 110 as a central device and other devices as peripheral devices or as peripheral devices where another device is a central device. Although the BLE terminology is referenced in the examples described herein, this is to strike a balance between brevity and a complete explanation of the technology of the present disclosure, and should not be interpreted as being limited to a specific technical protocol or standard.

[0115] A connection and subsequent communication session between two devices using a communication protocol such as BLE can be characterized by a similar physical channel operating between the two devices (e.g., the sensor control device 110 and the data receiving device 120). The physical channel may include a single channel or a series of channels, including, for example, but not limited to, using an agreed series of channels determined by a common clock and channel hopping or a hopping sequence. The common clock may be managed by the hardware clock of the control device in the pair. The channel hopping or hopping sequence may be determined based on a unique attribute of one or more devices of the communication session, such as an identifier of the device (e.g., a unique identifier, a BLE identifier, etc.). A communication session may use a similar amount of available communication spectrum, and multiple such communication sessions may exist in proximity. In some embodiments, each set of devices in a communication session uses a different physical channel or a series of channels to manage interference between devices in the same proximity. In some embodiments, devices in the same proximity may share channels through a channel reuse scheme, such as those based on code division or time division algorithms.

[0116] To participate in multiple simultaneous communication sessions, BLE devices such as the sensor control device 110 and the data receiving device 120 or the multi-purpose data receiving device 130 switch between channels based on time division multiplexing. In some embodiments, to avoid conflicts, a device may be prevented from controlling multiple simultaneous communication sessions. In addition to being classified as a device controlling or participating in a communication session, a device may also be classified as an advertiser or a scanner. An advertiser is a device that invites other devices to connect by broadcasting a connection packet on a common communication channel. A device that can interpret the connection packet can initiate communication with the advertiser. A scanner is a device that listens for connection packets transmitted by an advertiser.

[0117] Figure 6A-6C is a diagram illustrating an operating environment of an exemplary analyte sensor having multiple data receiving devices. Figure 6A-6CAn environment is shown in which the sensor control device 110 initiates or maintains a simultaneous communication session with both a data receiving device 125a and a data receiving device 125b. One or more of the data receiving device 125a and the data receiving device 125b may be a data receiving device 120 as described herein or a multi-purpose data receiving device 130 as described herein. As an example, the data receiving device 125a may be a data receiving device 120 provided by a manufacturer of the sensor control device 110 to facilitate monitoring the output of the sensor control device 110. The data receiving device 125b may be a second data receiving device 120, e.g., associated with a different user than the user, or may be used as a backup device (e.g., in the event that the user loses the data receiving device 125b). As another example, the data receiving device 125b can be a multi-purpose data receiving device 130 having a different form factor than the data receiving device 125a, such as a smart phone, tablet, smart watch, wearable health monitor or health device, such as an insulin pump or insulin, cardiac device, wearable health monitor, or other device that would benefit from the availability of output provided by the sensor control device 110. In a specific embodiment, one or more of the data receiving device 125a or the data receiving device 125b can be a home monitor or server relay that is configured to provide output from the sensor control device 110 to a remote device (e.g., a user device 140 or a remote server 150). In this way, using the techniques described herein, and using a short-range communication protocol such as BLE or high-frequency Wi-Fi, the sensor control device 110 can provide output to both the local data receiving device 125a and the secondary remote device. The techniques described herein can be used with data receiving devices 125a and 125b that include medical functions and non-medical functions. In particular, the techniques described herein can be used with a data receiving device 125a that does not have medical functionality for evaluation purposes, such as a consumer health monitor, whether standalone or incorporated into other multi-purpose devices. Although only two data receiving devices are shown, these environments can be expanded to include more than two data receiving devices communicating with a sensor control device 110, multiple sensors 110 communicating, or multiple data receiving devices communicating with each other.

[0118] Fig. 6AAn environment 600 is shown in which a sensor control device 110 communicates with a data receiving device 125b via a data receiving device 125a. In this environment, the data receiving device 125a acts as a relay between the sensor control device 110 and the data receiving device 125b, allowing other devices to piggyback on the connection between the sensor control device 110 and the data receiving device 125a and the data receiving device 125a and the data receiving device 125b. The data receiving device 125a is a trusted third party or intermediary device between the sensor control device 110 and the data receiving device 125b. The data receiving device 125a can act as a gateway or router for data between the sensor control device 110 and the data receiving device 125b. For example, the data receiving device 125a can perform a security check to authenticate the sensor control device 110 and the data receiving device 125b (and in some cases, as described herein, can directly enable further communication between the sensor control device 110 and the data receiving device 125b).

[0119] The data receiving device 125a can help one or more of the sensor control device 110 and the data receiving device 125b prepare requests for other devices and respond to requests issued by other devices. As an example, the data receiving device 125a can receive a request to the sensor control device 110 from the data receiving device 125b, and interpret or convert the request into a format that can be used by the sensor control device 110. When converting the request to the sensor control device 110 on behalf of the data receiving device 125b, the data receiving device 125a, which acts as a router for the request, can enable the sensor control device 110 and the data receiving device 125b to operate more efficiently or expand their functions with minimal additional overhead. In addition, the data receiving device 125a can present a device-agnostic interface for the two devices, increasing the interoperability of the sensor control device 110 and the data receiving device 125b.

[0120] In a specific embodiment, one or more of the sensor control device 110 and the data receiving device 125b are unaware of other devices in the environment 600. For example, as part of normal operation, the sensor control device 110 can provide output data to the data receiving device 125a. The data receiving device 125b can request access to data corresponding to the output from the sensor control device 110. However, the data receiving device 125b can request data without knowing the source of the data, for example, the identity of the sensor control device 110 in the environment 610. This lack of knowledge is advantageous in the case where, for example, the data receiving device 125a is a central hub or a common device of a system involving the sensor control device 110 and the data receiving device 125a and the sensor control device 110 and the data receiving device 125b. In addition, through this system, the privacy and security of users and other potential users of the sensor control device 110 and the data receiving device 125b can be protected because the identity of the device can be protected. Even if the sensor control device 110 and the data receiving device 125b are aware of the other device, the data receiving device 125a can process the output and data from the sensor control device 110 on behalf of the data receiving device 125b. For example, the sensor control device 110 can output raw values ​​to the data receiving device 125a, and the data receiving device 125a can apply one or more algorithms to the data so that the data receiving device 125b can use the data more effectively. In addition, the data receiving device 125a can generate data or instructions for display by the data receiving device 125b. As an example, the data receiving device 125a can generate instructions based on the data from the sensor control device 110 to modify the user interface of the data receiving device 125b. In such an example, the data receiving device 125b does not directly access the data from the sensor control device 110, but accesses the user interface instructions or transmits the data directly to the user interface for the user to view.

[0121] Figure 6BAn environment 610 is shown in which the sensor control device 110 communicates with the data receiving device 125a and the data receiving device 125b via separate communication sessions. In the environment 610, the sensor control device 110 can maintain more than one simultaneous communication session. In some embodiments, maintaining more than one simultaneous communication session can include receiving a request from each of the data receiving device 125a and the data receiving device 125b, determining the identity of the requesting device (e.g., whether the request was issued by the data receiving device 125a or the data receiving device 125b), determining an appropriate response (e.g., but not limited to, which can depend on the identity of the requesting device), and transmitting the response in a format that the requesting device understands. In some embodiments, security measures can be taken to reduce the risk of crosstalk, interference, or data snooping between the data receiving device 125a and the data receiving device 125b (e.g., the data receiving device 125a unintentionally interferes with the communication between the sensor control device 110 and the data receiving device 125b, or the data receiving device 125b attempts to access the communication between the sensor control device 110 and the data receiving device 125a). These security measures may include using unique encryption keys to protect data packets sent between the sensor control device 110 and the data receiving device 125a or the data receiving device 125b, a unique communication channel or channel hopping process for the communication session between the sensor control device 110 and the data receiving device 125a or the data receiving device 125b, and other similar measures.

[0122] In a specific embodiment, the sensor control device 110 identifies the device that has issued the request based on the communication medium of the request. For example, the sensor control device 110 and the data receiving device 125a may have agreed to use a specific communication channel for the sensor control device 110 to receive the request, and the sensor control device 110 and the data receiving device 125b may have agreed to use a different communication channel or sensor control device 110 to receive the request. Then, the sensor control device 110 can assume that the request received on the specific communication channel is from the data receiving device 125a. In a specific embodiment, the sensor control device 110 identifies the device that has issued the request based on the request itself. For example, the request may include information identifying the device that issued the request. The request from the data receiving device 125a may include a unique identifier of the data receiving device 125a, and the request from the data receiving device 125b may include a unique identifier of the data receiving device 125b. Once the request is received, the sensor control device 110 checks the information provided in the request to identify the device that issued the request. The sensor control device 110 can store a library or mapping of unique identifiers to data receiving devices. Using this mapping, requests from data receiving device 125a and data receiving device 125b can avoid including plain text identifiers. As an example, during the initial phase of pairing between sensor control device 110 and data receiving device 125a, sensor control device 110 and data receiving device 125a can agree on an identifier for data receiving device 125a or a scheme for determining an identifier for data receiving device 125a. Upon receiving a request, sensor control device 110 can reference the mapping to positively determine that data receiving device 125a has issued a request. A third party without access to the mapping will not be able to determine the identity of data receiving device 125a.

[0123] Figure 6CAn environment 620 is shown in which the sensor control device 110 acts as a relay for data receiving devices 125a and 125b, for example, by receiving input or commands from the data receiving device 125a, and in response, transmitting data to the data receiving device 125b. Therefore, the sensor control device 110 promotes indirect communication between the data receiving device 125a and the data receiving device 125b. In the environment 620, the data receiving device 125a and the data receiving device 125b can operate without the direct knowledge of other devices. In some embodiments, the data receiving device 125a and the data receiving device 125b may be incompatible or cannot communicate directly. However, because the sensor control device 110 can create a secure communication session with each other, the sensor control device 110 can promote the exchange of information between devices. As an example, the data receiving device 125a can be a connected medical device, for example, an insulin pump, and the data receiving device 125b can be a smart phone configured with a software application to facilitate monitoring the output from the sensor control device 110. As specifically implemented herein, data receiving device 125a and data receiving device 125b will not be configured to communicate. However, it may be advantageous to make software applications know the medical intervention initiated by insulin pump. Therefore, insulin pump (data receiving device 125a) can notify sensor control device 110 when dispensing insulin, and sensor control device 110 can relay this information to software applications (data receiving device 125b), so that smart phone can directly record events, rather than the existence of indirect inference events for example. As shown, the sensor control device 110 configured to operate in environment (e.g., environment 620) can increase the interoperability of data receiving device 125a and data receiving device 125b.

[0124] Figure 7 A process of establishing a communication session between the sensor control device 110 and the data receiving device 125b using the data receiving device 125a and transmitting analyte data according to the communication session is shown.

[0125] At 705, the data receiving device 125a and the sensor control device 110 establish a connection or communication session. In a specific embodiment, the sensor control device 110 and the data receiving device 125a can use a first communication protocol for short-range wireless communication, such as Bluetooth or BLE. The connection can be performed through a pairing process supported by the communication protocol. As an example, the sensor control device 110 can be configured to broadcast a connection packet periodically to facilitate other devices to discover and connect to the sensor control device 110. The data receiving device 125a can receive the connection packet and use the information contained therein to establish a connection and mutual authentication with the sensor control device 110. As another example, the data receiving device 125a can use a second communication protocol to establish a communication session between the sensor control device 110 and the data receiving device 125a. For example, the data receiving device 125a can initiate an NFC communication session when it is brought into a suitable close range to exchange information, thereby allowing the sensor control device 110 and the data receiving device 125a to pair and authenticate each other.

[0126] At 710, the data receiving device 125a and the data receiving device 125b establish a connection or communication session. For purposes of illustration and not limitation, as described herein, the data receiving device 125a and the data receiving device 125b may be the same type of data receiving device (e.g., two data receiving devices including a multi-purpose data receiving device 130 configured with a downloaded library or software application), two independent data receiving devices owned by the same user (e.g., a multi-purpose data receiving device 130 and a smart watch), two independent data receiving devices owned by a user wearing the sensor control device 110 and an authorized monitor such as a parent, a coach, or a medical caregiver, a data receiving device for monitoring the output of the sensor control device 110, different instances of a data receiving device for taking action based on the output of the sensor control device 110, such as a connected medical device (e.g., an insulin pump or insulin pen) or a connected exercise device (e.g., a treadmill, an exercise bike), or various other suitable combinations. The data receiving device 125a and the data receiving device 125b may communicate using one or more short-range or medium-range communication protocols.

[0127] At 715, the data receiving device 125b receives a request to connect to the sensor control device 110. The request to connect to the sensor control device 110 may be initiated by a user of the data receiving device 125b. The request may indicate that the user wishes to use the data receiving device 125b to monitor the output of the sensor control device 110, or to pair the data receiving device 125b and the sensor control device 110 to enable additional functionality of the data receiving device 125b. In some embodiments, the request may be automatically initiated in response to the user indicating that they have an available sensor control device 110 for use with the data receiving device 125b. In response to receiving the request, the data receiving device 125b determines that it cannot connect directly to the sensor control device 110, and must use the existing connection between the data receiving device 125a and the sensor control device 110 to establish a connection with the sensor control device 110.

[0128] At 720, the data receiving device 125b sends a connection request to the data receiving device 125a. In response to determining that the existing connection between the data receiving device 125a and the sensor control device 110 will be used to establish a connection with the sensor control device 110, the data receiving device 125b prepares a connection request, indicating to the data receiving device 125a the request to use the existing connection. For example, the data receiving device 125b may include in the request information information identifying the data receiving device 125b (e.g., the address of the data receiving device 125b, the BLE handle of the data receiving device 125b), the user of the data receiving device 125b or the sensor control device 110 (e.g., the unique identifier of the user, or a public authentication key prepared by or for the data receiving device 125b or the sensor control device 110), information identifying how the sensor control device 110 and the data receiving device 125b will initiate the connection (e.g., the communication channel or channel hopping protocol that the devices will use), and other information to verify the request and take action on it.

[0129] At 725, the data receiving device 125a receives the connection request and prepares the connection request for the sensor control device 110. In some embodiments, the data receiving device 125a can perform steps to verify the request and authenticate the data receiving device 125b and the user of the data receiving device 125b. For example, the data receiving device 125a can query the information included in the connection request from the data receiving device 125b. The data receiving device 125a can provide the information to a remote server 150 associated with the sensor control device 110. The remote server 150 can confirm the validity of the information and take other security-related actions to, for example, determine that the data receiving device 125b is not attempting to reuse expired credentials or establish a connection with an incorrect sensor control device 110. Additionally or alternatively, the data receiving device 125a can be configured to perform operations to verify the connection request.

[0130] At 730, the data receiving device 125a sends a connection request to the sensor control device 110. After verifying the connection request from the data receiving device 125b, the data receiving device 125a may repackage the information of the connection request from the data receiving device 125b for use by the sensor control device 110. With the connection request, the data receiving device 125a may include information asserting or confirming the validity of the data receiving device 125b and the connection request. The sensor control device 110 may use the information asserting the validity of the data receiving device 125b to confirm the request and simplify the process of initiating a connection between the sensor control device 110 and the data receiving device 125b.

[0131] At 735, the sensor control device 110 receives a connection request from the data receiving device 125a. Based on the connection request, the sensor control device 110 identifies the data receiving device 125b (e.g., using the BLE handle of the data receiving device 125b included in the connection request) and the mechanism for initiating the connection. For example, the connection request may include the type of security algorithm used for the connection, or the communication channel or channel hopping scheme used to facilitate the connection. The sensor control device 110 may determine whether the data receiving device 125b has previously initiated a connection with the sensor control device 110 to speed up the connection process. For example, the sensor control device 110 may store a mapping table of devices connected thereto. The mapping table may include an identifier or handle of the device and a locally assigned identifier (e.g., an index in a table) generated by the sensor control device 110 to serve as a shorthand for future references to the device. If the identifier of the data receiving device 125b is found in the table, or if the data receiving device 125b has provided a valid locally assigned identifier, the sensor control device 110 may infer that the data receiving device 125b can communicate with the sensor control device 110 before. If the identifier of the data receiving device 125 b does not appear in the mapping table, the sensor control device 110 may generate a new entry for the data receiving device 125 b and continue to establish pairing with the data receiving device 125 b .

[0132] At 740, the sensor control device 110 sends a connection confirmation to the data receiving device 125b. The connection confirmation may indicate to the data receiving device 125b that the sensor control device 110 has received the connection request. The connection confirmation may further identify the sensor control device 110 to the data receiving device 125b. The connection confirmation may also include information to be used to initiate mutual authentication between the sensor control device 110 and the data receiving device 125b. As an example, the connection confirmation may include a public key for the sensor control device 110 or a shared authentication key generated based on information included in the connection request from the data receiving device 125b.

[0133] At 745, the data receiving device 125b receives the connection confirmation. In response to receiving the connection confirmation, the data receiving device 125b confirms that the connection confirmation is from the correct sensor control device 110. For example, the connection confirmation may include information identifying the sensor control device 110, which the data receiving device compares with information identifying the sensor control device 110 stored by the data receiving device 125b. In some embodiments, the data receiving device 125b confirms the identity of the sensor control device 110 by presenting information identifying the sensor control device 110 that has responded to the connection request to a user of the data receiving device 125b. The user confirms the identity of the sensor control device 110 by responding to the prompt of the data receiving device 125b.

[0134] At 750, the sensor control device 110 and the data receiving device 125b may perform mutual authentication. Based on the information exchanged between the sensor control device 110 and the data receiving device 125b (e.g., in the connection request and the connection confirmation), the sensor control device 110 and the data receiving device 125b may independently generate a shared key. The shared key may be based on the public key and the private key of the sensor control device 110 and the data receiving device 125b, and applied to random data agreed upon by the sensor control device 110 and the data receiving device 125b. The shared key may be selected so that only a device having both the public key of the sensor control device 110 and the data receiving device 125b and the private key of at least one of the sensor control device 110 or the data receiving device 125b (e.g., a non-shared key) can generate a shared key (shared secret). Using the shared key, the sensor control device 110 and the data receiving device 125b may verify the identity of the other device by confirming that the other device has access to the private key corresponding to the shared public key. After confirming the identity of the other device, the sensor control device 110 and the data receiving device 125b may generate a mutual encryption value or scheme for a subsequent communication session between the sensor control device 110 and the data receiving device 125b.

[0135] After performing mutual authentication, the sensor control device 110 and the data receiving device 125b are ready to initiate a secure communication session. In a specific embodiment, the sensor control device 110 can store an identifier of the data receiving device 125b, which facilitates the sensor control device 110 to identify the connection request from the data receiving device 125b. For example, the sensor control device 110 can store a mapping between the identifier of the data receiving device 125b and the mutual encryption value in the local storage device 230 or the memory 220.

[0136] refer to Figure 7 715-750, these actions may be performed when the data receiving device 125b is not able to connect directly to the sensor control device 110 on its own. For example, the data receiving device 125b may have user input capabilities so that a user uses the data receiving device 125a to control the data receiving device 125b. In the case where the data receiving device 125b can directly initiate a connection to the sensor control device 110, the process of establishing a communication session between the sensor control device 110 and the data receiving device 125b follows a standard process and may be performed without data exchange between the data receiving device 125a and the data receiving device 125b to facilitate the request.

[0137] At 755, the data receiving device 125b initiates a request for data from the sensor control device 110, and at 760, the data receiving device 125a initiates a request for data from the sensor control device 110. Although the requests are shown in a particular order, this is for illustration purposes only, and the data receiving device 125a may initiate a request for data from the sensor control device 110 before the data receiving device 125b. In a specific embodiment, the request from the data receiving device 125a or the data receiving device 125b may be initiated periodically. For example, the data receiving device 125a and the data receiving device 125b may be configured to transmit data requests for the sensor control device 110 according to a preset schedule (e.g., once every 60 seconds, once every 10 seconds, twice per second, etc.). The schedule may be determined based on the computing power of the device and factors such as the power or battery charge of the device. The schedule may be further determined based on the amount of data to be requested or the amount of time since the requesting device was last able to retrieve data from the sensor control device 110. In some embodiments, the schedule is determined independently between the sensor control device 110 and each of the data receiving devices 125a and 125b, i.e., the data receiving device 125a and the data receiving device 125b are unaware of the scheduled time of the other. In other embodiments, the schedule is determined using input from the data receiving device 125a and the data receiving device 125b, thereby allowing the two devices to negotiate the schedule and avoid interfering with each other's requests. This approach, while adding some computational complexity and requiring the devices to be aware of each other in some way, allows load balancing of the sensor control device 110 and minimizes the occurrence of parallel requests and processing.

[0138] In a specific embodiment, a request from the data receiving device 125a or the data receiving device 125b can be initiated when the data receiving device 125a or the data receiving device 125b enters the communication range of the sensor control device 110. For example, the data receiving device 125a and the data receiving device 125b can be configured to send a polling request to determine the identity of nearby devices. Additionally or alternatively, the sensor control device 110 can be configured to periodically send advertisements or connection requests to all nearby devices. Upon receiving the advertisement request, the data receiving device 125a or the data receiving device 125b can initiate a data request.

[0139] At 765, the sensor control device 110 processes the data request from the data receiving device 125a and the data receiving device 125b. In a specific embodiment, in order to process the data request, the sensor control device 110 first confirms the authentication of the data receiving device 125a or the data receiving device 125b. As an example, the sensor control device 110 first identifies which device sent the request. As an example, as described above, each request may include information identifying the requesting device, such as a unique or local identifier of the data receiving device 125a or the data receiving device 125b (e.g., a BLE handle or a shorthand for a handle managed internally by the sensor control device 110). The sensor control device 110 then confirms that the requesting device has permission or has been authenticated to request data from the sensor control device 110. If the device does not have the necessary permission, the request may be rejected or converted into a request to establish a connection directly with the sensor control device 110. By way of example, determining that the requesting device has permission may include comparing the identifier of the requesting device with an identifier stored by the sensor control device 110 as a result of a previous connection request, and is a set of permissions granted to the device. Once the identity and permissions of the requesting device are established, the sensor control device 110 proceeds to determine how to respond to the request.

[0140] In a specific embodiment, the data request from the data receiving device 125a and the data receiving device 125b may include information indicating what type of data each device is requesting. As an example, the sensor control device 110 can process and store data related to a specific analyte level detected in the user. Data can be stored according to a key or a queue system, in which data can be easily indexed to a specific event or time period. Therefore, data related to a specific analyte level can be stored together with a timestamp unique to each data record. The data request from the data receiving device 125a and the data receiving device 125b can be associated with a key representing the analyte data range requested by the device. As an example, the request may include a timestamp, a timestamp range, a unique identifier, or a life count associated with the data record requested by the requesting device. In response to each request, the sensor control device 110 can retrieve the requested data from its storage device 230.

[0141] In a specific embodiment, the sensor control device 110 can track which data has been provided to which data receiving devices. As an example, each entry including an analyte level (or other sensing level) can be annotated with information including the identity of the data receiving device that has requested and received the data, a timestamp or count associated with the request, and a timestamp or count associated with the data receiving device receiving the response to the request. In this case, unless otherwise stated, a data request from the data receiving device 125 or the data receiving device 125b can be interpreted as a request to provide all missing data. When preparing information to be provided to the data receiving device, the sensor control device 110 can determine which data records have not yet been provided to the requesting device.

[0142] Once the appropriate record is identified, the sensor control device 110 packages the data into a response to the data request. As an example, the sensor control device 110 prepares a response message including a payload that includes the requested data (or data identified for the data receiving device that initiated the request). The sensor control device 110 can receive requests and send responses asynchronously, and the sensor control device 110 can further note which data receiving device the response message is for. Therefore, the data requested by the data receiving device 125a and the data receiving device 125b can be different. As an example, the data receiving device 125a can be updated more frequently, so the individual response is smaller. As another example, the data receiving device 125b can only request a subset of the data associated with a specified time (e.g., in the evening or after a meal), so the data receiving device 125b does not request all data from the sensor control device 110.

[0143] The sensor control device 110 responds to the request from the data receiving device 125a at 770. In response to the request, the sensor control device 110 transmits a response packet prepared for the data receiving device 125a to the data receiving device 125a using, for example, an agreed upon communication scheme between the two devices or using an established communication session.

[0144] At 775, the sensor control device 110 processes the data request from the data receiving device 125b. Although illustrated as separate steps, much of the processing for processing the request from the data receiving device 125b may be similar to processing the request from the data receiving device 125a, except that the sensor control device 110 identifies the data for the data receiving device 125b and prepares a packet for receipt by the data receiving device 125b. At 780, the sensor control device 110 responds to the request from the data receiving device 125b.

[0145] As discussed, the sensor control device 110 can respond to the requests in a variety of orders, such as in the same order as they were received, based on pre-established priorities (e.g., requests from data receiving device 125a always take precedence over requests from data receiving device 125b), based on the time since the request was received, based on a schedule (e.g., pending requests from data receiving device 125a are responded to every 10th second of every minute, and pending requests from data receiving device 125b are responded to every 40th second of every minute), the size of the requests, the size of the pending responses, and other suitable response schemes.

[0146] The data receiving device 125a and the data receiving device 125b may continue to initiate requests from the sensor control device 110 to maintain an active communication session. In some embodiments, the communication session may time out due to inactivity to preserve the battery life of the sensor control device 110 and possibly the data receiving device 125a and the data receiving device 125b. Therefore, when the data receiving device 125a and the data receiving device 125b are within the communication range of the sensor control device 110, a request may be initiated to the sensor control device 110 to keep the connection active. If the connection is deactivated due to inactivity, the data receiving device 125a or the data receiving device 125b may initiate a new communication session with the sensor control device 110 using the shared key or and existing authentication key, or may request and generate a new authentication key using the techniques described herein.

[0147] To further manage the battery life of the sensor control device 110, the sensor control device 110 can change various aspects of the hardware operation. As an example, when the sensor control device 110 expects to communicate with two or more data receiving devices in a simultaneous communication session, the sensor control device 110 monitors additional channels associated with the communication session information set by the data receiving device. This additional monitoring uses more battery life. In order to perform additional communication sessions with additional devices, the sensor control device 110 uses even more battery life. The monitoring of additional channels involves certain hardware processes that can be dynamically changed based on the number of potential communication sessions that the sensor control device 110 is monitoring. As an example, the sensor control device 110 can adjust the number of connection packets sent as advertising data packets, adjust the amount of time each transmission is active, adjust the number of transmission cycles or the iteration rate of the transmission cycles, adjust the amount of time in active receiving mode or the frequency of switching to active receiving mode, or make other dynamic adjustments as appropriate to balance the ability of the sensor control device 110 to initiate and maintain communication sessions with the adjusted battery life of the sensor control device 110.

[0148] The communication module 240 of the sensor control device 110 can be configured to process or manage a bidirectional communication link between the sensor control device 110 and the receiver 120. The communication module 240 may include a communication circuit configured to switch between a sleep state, a partially awake state, and a fully awake state. For example, when in a fully awake state, the communication circuit may be configured to perform tasks and actions associated with a communication protocol start (CPS) instruction set 221, which may include an advertisement scan related (ASR) instruction subset 222 and a non-ASR instruction subset 223. When in a partially awake state, the communication circuit is configured to execute the ASR instruction subset 222. The ASR instruction subset 222 may include transmitting an advertisement notification 224 over one or more channels according to a wireless communication protocol (e.g., BLE) and scanning one or more channels for a connection request from a receiver or other device. Alternatively, the advertisement notification 224 may be stored in the communication module 240. Conversely, when no connection request is received, the communication circuit may return to a sleep state without performing actions or tasks associated with the non-ASR instruction subset 223 of the CPS instruction set 221. In Figure 2 In the example of , the CPS instruction set 221 can be stored in the memory 220 and / or 243 accessed by the microcontroller 210 and / or the processor 246 of the communication module 240, respectively. The CPS instruction set 221 can provide the microcontroller 210 and / or the processor 246 with wireless protocol syntax to assemble data packets, advertising notifications, connection requests, connection responses, establish communication links, and / or divide data received from the receiver 120. Additionally or alternatively, the CPS instruction set 221 can generally be stored in ROM, RAM, firmware, or other memory on the communication module 240 or the sensor control device 110. As another example, the CPS instruction set 221 can be "stored" by the setting of the hardware circuit within the communication module 240 or the sensor control device 110.

[0149] In an embodiment, when the CPS instruction set 221 is executed when the BLE peripheral application is in a fully awake state, the communication circuit of the communication module 240 can utilize a first amount of power. In addition, when the ASR instruction subset 222 is executed when the BLE peripheral application is in a partially awake state, the CPS instruction set 221 can utilize a second amount of power that is less than the first amount of power. Compared with the tasks and actions of the ASR instruction subset 222, the CPS instruction set 221 may include more tasks and actions that take longer and more power to implement. For example, the second amount of power and time to implement the ASR instruction subset can be 40%-80% of the first amount of power and time to implement the entire CPS instruction set. As another example, the second amount of power and time to implement the ASR instruction subset can be 50%-65% of the first amount of power and time to implement the entire CPS instruction set.

[0150] The communication module 240 includes a receiver that scans for connection requests from the receiver 120. As described herein, the communication module 240 can be controlled by the microcontroller 210 and can support one or more wireless communication protocols when communicating with the receiver 120, such as Bluetooth Low Energy (e.g., using the BLE module 241), Bluetooth, Medical Implant Communication Service (MICS), Wi-Fi, cellular communication, or other similar protocols. The communication module 240 can include a transmitter, a receiver, and / or a transceiver. Optionally, the communication module 240 can be electrically coupled to an antenna.

[0151] The microcontroller 210 is coupled to the memory 220 via a suitable data / address bus 296. The memory 220 may store programmable operating parameters used by the microcontroller 210. The microcontroller 210 may modify the operating parameters as needed to customize the operation of the sensor control device 110 to suit the needs of a particular wearer. The memory 220 may also store data sets (raw data, summary data, historical data, trends, histograms, etc.), for example, the levels of one or more analytes over a period of time (e.g., 1 hour, 24 hours, 7 days, 1 month). The data sets stored in the memory 220 may be selected and packaged into data packets (e.g., data packets 400) and sent to a receiving device (e.g., receiver 120). The memory 220 may store instructions to direct the microcontroller 210 to analyze the electrical signals from the sensing hardware 260, thereby identifying features of interest and deriving values ​​for storage and presentation.

[0152] In addition, the memory 220 stores a CPS instruction set 221. The CPS instruction set 221 may be loaded into the memory 220 at the time of manufacture, at the time of activation, at the time of installation, or throughout operation. For example, during a communication session, the receiver 120 may provide updates to the CPS instruction set stored in the memory 220. The CPS instruction set 221 includes an ASR instruction subset 222 and a non-ASR instruction subset 223. The ASR instruction subset 222 may include instructions related to at least two of the following: expiration of a wake-up timer; processor startup; initialization of a transmission circuit; formation of an advertising data packet; transmission of an advertising data packet; scanning one or more channels for a connection request from another device (e.g., the receiver 120); and verification or rejection of an incoming connection request. The non-ASR instruction subset 223 may include instructions related to at least two of the following: initialization of a random access memory (RAM) segment / block; initialization of the sensing hardware 260; initialization of operating system services; and initialization of the CPS instruction set 221. In one embodiment, the ASR instruction subset 222 does not include instructions related to at least two of: initialization of random access memory (RAM) segments / blocks; initialization of sensing hardware 260; initialization of operating system services; and initialization of the CPS instruction set 221.

[0153] According to an embodiment of the present invention, the advertising schedule included in the CPS instruction set 221 can balance fast advertising with low power and low sensitivity and slow advertising with high power and high sensitivity. This balance can be used to provide remote automatic connection for fast communication and remote monitoring. As explained herein, once a connection is established between the receiver 120 and the sensor control device 110, the communication module 240 can set the transmission power and receiving sensitivity to the desired communication session level (e.g., high) for the duration of the communication session. The transmission power and receiving sensitivity can be set to the desired communication session level, regardless of whether the connection is established using short-range or long-range advertising, thereby providing the desired communication distance during the active communication session. For example, if the subject wants to force a communication session, the patient can bring the receiver 120 close to the sensor control device 110 to start a communication session based on a short-range advertisement. Then, once the connection is established, the communication module 240 adjusts the transmission power and receiving sensitivity to the communication session level (e.g., maximum power setting), thereby allowing the subject to leave the receiver 120 on the table or otherwise not in hand without encountering any interruption of the communication session.

[0154] Additionally or alternatively, one or more separate advertising schedules included in the CPS instruction set 221 may be stored in the memory 220 for use in conjunction with each respective receiver 120. For example, when the sensor control device 110 initially begins communicating with a particular receiver 120, the receiver 120 may download the corresponding advertising schedule included in the CPS instruction set 221 and instructions for using the advertising schedule included in the CPS instruction set 221 until otherwise instructed. Subsequently, the sensor control device 110 may communicate with another receiver 120 that downloads a corresponding new advertising schedule included in the CPS instruction set 221 and instructions for using the new advertising schedule included in the CPS instruction set 221 until otherwise instructed. As another example, the sensor control device 110 may update the advertising schedule included in the CPS instruction set 221 throughout the operation, for example, based on a success rate in establishing a communication link, based on a delay in establishing a communication link, and the like.

[0155] The operating parameters of the sensor control device 110, including but not limited to the CPS instruction set 221, can be non-intrusively programmed into the memory 220 via the communication module 240 that communicates bidirectionally with the receiver 120 wirelessly. In some embodiments, the communication module 240 can be controlled by the microcontroller 210 and receive data for transmission from the microcontroller 210. The communication module 240 allows data from the sensing hardware 260 and status information related to the operation of the sensor control device 110 (contained in the microcontroller 210, the memory 220, or the storage device 230) to be sent to the receiver 120 via the established bidirectional communication link. The communication module 240 also allows the receiver 120 to program new parameters and advertising schedules for the sensor control device 110.

[0156] The communication module 240 transmits one or more advertising notifications or advertising data packets 400 on one or more advertising channels. Each advertising channel is a point-to-multipoint unidirectional channel used to transmit a repeating pattern of system information messages, such as a network identification included in the advertising notification, an RF channel that allows a communication link to be established, etc. As described herein, in some embodiments, in addition to the connection data 420 within its payload 410, the advertising notification may also include analyte data 425. Based on an advertising schedule stored in the memory 220, the advertising notification may be repeatedly transmitted after a set duration or advertising interval until a communication link is established with the receiver 120.

[0157] Figure 8An example of a set of initialization operations is shown that may be performed, for example, by a BLE peripheral application when entering a fully awake state. Although described in the context of the BLE communication protocol, similar operations may be performed when the sensor control device 110 is configured to operate using other communication protocols. The illustrated process represents a non-limiting example of a set of initialization actions or tasks of a BLE peripheral application operating when the communication circuit of the communication module 240 is in a fully awake state.

[0158] At 810, the wake-up timer expires and the BLE peripheral application is activated. For example, the sensor control device 110 may wake up from a predetermined sleep interval. This interval may occur between connection or advertising events. These connection or advertising events may be caused by Figure 2 The timing control circuit 211 shown is controlled. The timing control circuit 211 may include a sleep clock. When the wake-up timer expires at the end of the sleep interval, the timing control circuit 211 may process the current connection or advertising event and establish a new sleep interval using the sleep clock.

[0159] At 815, the processor startup routine begins. For example, the startup module 212 can be used to control the startup process of the processor. For example, after the timing control circuit 211 has determined the wake-up interval of the sensor control device 110, the startup module 212 may include or access a ROM (e.g., memory 220 or 243) or a non-volatile flash memory, which has a startup code for controlling the startup process. The ROM can load the startup process. The startup process can include power-on, operating system loading, and transfer of control to the operating system. For example, after the power-on activity is initiated by the user, condition, timer or other stimulus, a routine can be executed to ensure that the device driver is operating normally. Any problems encountered may interrupt the startup process. Each device in the startup list can load its own routine to ensure correct communication between the device and the startup module 212. After the routine is successfully completed, the operating system 213 can be loaded.

[0160] At 820, the communication circuit of the communication module 240 is initialized. The communication module 240 is controlled by the microcontroller 210 and can support one or more wireless communication protocols, such as BLE, Bluetooth, MICS, etc., while communicating with the receiver 120. The communication module 240 transmits one or more advertising notifications on one or more advertising channels. Each advertising channel is a point-to-multipoint unidirectional channel for transmitting repeated payloads, which may include connection data 420, which includes system information messages, such as network identification, channels allowed to establish a communication link, etc. Based on the advertising schedule stored in the memory 220, the advertising notifications can be repeatedly transmitted after a set duration or advertising interval until a communication link is established with the receiver 120.

[0161] At 825, the memory 220 is initialized. For example, operating parameters may be loaded into certain memory locations and / or registers. The memory 220 may store programmable operating parameters used by the microcontroller 210. The memory 220 also stores data sets, such as data generated from or by the sensing hardware 260, or data processed by the microcontroller 210 based on data generated from or by the sensing hardware 260. The memory 220 may also store instructions to direct the microcontroller 210 to analyze the data generated from or by the sensing hardware 260 to identify features or priorities of interest and derive values ​​for presentation to the receiver 120. In addition, the memory 220 stores one or more advertising schedules included in the CPS instruction set 221.

[0162] At 830, the sensing hardware 260 may be initialized. For example, the sensing hardware 260 may require a brief warm-up period before usable data may be retrieved from or by the sensing hardware 260. During initialization, the warm-up period may be enforced, or a voltage may be applied to the sensing hardware 260 to accelerate the warm-up period. Once the sensing hardware 260 is ready, data or other values ​​may be retrieved from the sensing hardware 260. For example, the microcontroller 210 may record and process current values ​​of the levels of one or more specific analytes.

[0163] At 835, if the sensor control device 110 supports the operating system 213 as a basic operating layer, the operating system services are initialized. After successfully completing the BIOS, the operating system 213 can begin running applications or other functions of the sensor control device 110. The operating system 213 can include various applications for collecting and analyzing biosignals (e.g., analyte levels).

[0164] At 840, the BLE protocol stack 230 is initialized. The protocol stack 230 may include a host and a controller including multiple layers for communication.

[0165] At 845, the BLE peripheral application transmits one or more advertising notifications. The protocol stack 230 controls when the advertising notifications are sent. The link layer (LL) of the controller of the protocol stack 230 can control the radio frequency (RF) state of the device, which can include the advertising state. Scan request and scan response activities occur during the advertising interval of the two applications.

[0166] At 850, the sensor control device 110 determines, for example, via a BLE peripheral application, whether a connection request has been received (e.g., from a receiver 120 in the environment of the sensor control device 110). If there is no connection request, the process ends and the IMD returns to sleep, as shown at 860. Alternatively, if a connection request is received, the process proceeds to 855.

[0167] At 855, the sensor control device 110 analyzes the content of the connection request, for example, via a BLE peripheral application, to determine whether the connection request is sent by an authorized receiver 120. If the connection request is sent by an authorized receiver 120, the sensor control device 110 and the receiver 120 may exchange additional information to initiate a communication session. The receiver 120 and the sensor control device 110 may connect, and the sensor control device 110 may send data collected by the sensor control device 110 (e.g., via the sensor hardware 260). As an example, the sensor control device 110 may automatically or based on a request from the receiver 120 backfill data that has not yet been transmitted to the receiver 120. At this point in the process, the sensor control device 110 is fully awake.

[0168] Fig. 9 An example of initialization operation of a process 900 of a BLE peripheral application in a partial wake-up state is shown. The BLE peripheral application operates in a partial wake-up state until full power is required and is presented from a firmware perspective, interacting with a Bluetooth low energy system-on-chip (SoC). Although shown in the context of the BLE communication protocol, similar applications and processes can be used for the sensor control device 110 when operating using other communication protocols.

[0169] At 910, the wake-up timer expires and a partial wake-up (low power) BLE application is activated. For example, the sensor control device 110 may wake up from a predetermined sleep interval. This interval may occur between connection or advertising events. These connection or advertising events may be caused by Figure 2 The timing control circuit 211 shown is controlled by the timing control circuit 211. The timing control circuit 211 may include a sleep clock. When the wake-up timer expires at the end of the sleep interval, the timing control circuit 211 can process the current connection or advertising event and establish a new sleep interval using the sleep clock. At this point in the process, the sensor control device 110 is partially awakened.

[0170] At 915, a processor startup routine is implemented similar to the routine described in conjunction with the operation at 810. At 920, similar to the routine described in conjunction with the operation at 815, the communication circuitry of the communication module 240 is initialized.

[0171] A low power BLE application operating using process 900 skips steps 825 to 840, as shown by a BLE peripheral application in a fully awake state. During this portion of the process, the low power BLE application does not necessarily initialize the memory blocks, sensing hardware 260, or the complete BLE protocol stack. This change in the process shortens the time required for the processor and hardware modules to be active during each advertising opportunity, thereby saving battery power.

[0172] At 925, the BLE peripheral application constructs and sends one or more advertising notifications. In some embodiments, the advertising notification is executed and includes a payload 410 having only the connection data 420. In some embodiments, the advertising notification is generated to further include the most recent or highest priority analyte data 425, which can be encrypted before being included in the advertising data packet payload 410.

[0173] At 930, the BLE peripheral application determines whether a connection request is received. The connection request may be received from one or more receiving devices (e.g., receiver 120) in the environment of the sensor control device 110. If a connection request is not received, the process ends and the sensor control device 110 returns to sleep, as shown in 940. Alternatively, if a connection request is received, the process proceeds to 935. At 935, the BLE peripheral application analyzes the connection request and initiates a communication session as needed. At this point in the process, the sensor control device 110 begins to perform skipped operations to transition to a fully awake state.

[0174] Fig.10 An example of an application switching sequence between a low power (partial wake-up) advertising application and a (full wake-up) BLE peripheral firmware application is shown. The sensor control device 110 transmits an advertising notification 1010 in an advertising interval 1012 during different advertising time periods when in a partially awake state. The receiver 120 transmits a scan request 1015 to request a connection to the sensor control device 110. Once the scan request 1015 is received by the sensor control device 110, a scan response 1020 may be sent to the receiver 120. If the scan response 1020 indicates that the receiver 120 is approved to connect 1040 and subsequent communication 1045 with the sensor control device 110, a switching operation 1025 is initiated, and when a connection request 1035 is received, the partially awake advertising application 1005 switches to a fully awake advertising 1030. The partially awake advertising application 1005 hands over the process to the fully awake advertising application 1030. The scan request 1015 may be processed by analyzing the identification characteristics of the receiver 120.

[0175] When the full wake-up advertising application 1030 takes control, the memory block 220 is initialized in the full wake-up advertising application ( Figure 8825 in the example. For example, program instructions or parameters may be loaded into RAM, registers, or other memory locations. Various indexes in the memory are initialized. In addition, the sensing hardware 260 is initialized (operation 830). In addition, the operating system services may be initialized (operation 835), and the BLE protocol stack 230 may be fully initialized (operation 840). Thereafter, a communication session is established.

[0176] Fig.11 1 is a state machine diagram illustrating states of a communication circuit of a sensor control device 110 configured in accordance with embodiments disclosed herein. Initially, the communication circuit begins in a sleep state 1110. The communication circuit remains in the sleep state until a wake-up timer expires. Once the wake-up timer expires, the communication circuit transitions from the sleep state to a partially awake state 1120, which may also be referred to as a low-power advertising state. During the partially awake state, the communication circuit is configured to transmit advertising notifications over one or more channels in accordance with a wireless communication protocol and scan the one or more channels for connection requests from a receiver.

[0177] If a connection request is received from the receiver 120, the connection circuit can be configured to transition to a fully awake state 1130. The fully awake state can also be considered a full power or standard advertising state. During the fully awake state, the communication circuit is configured to perform tasks and actions associated with a communication protocol start (CPS) instruction set, which includes an advertising scan related (ASR) instruction subset and a non-ASR instruction subset. After completing the required processing tasks, the communication circuit can return to the sleep state until the next wake-up timer expires.

[0178] However, if a connection request is not received, the communication circuitry may return directly to the sleep state 1110 without performing actions or tasks associated with the non-ASR instruction subset of the CPS instruction set.

[0179] When the communication circuit executes the CPS instruction set while in a fully awake state, the sensor control device 110 utilizes a first amount of power. When executing the ASR instruction subset while in a partially awake state, the sensor control device 110 utilizes a second amount of power that is less than the first amount of power. The entire CPS instruction set includes more tasks and actions that require longer time and more power to implement than the limited set of tasks and actions of the ASR instruction subset.

[0180] The communication circuitry may include additional or alternative hardware or firmware, in which case the ASR instruction subset may include instructions related to at least two of: expiration of a wake-up timer; processor startup; initialization of a transmission circuit; transmission of an advertising packet; scanning one or more channels for a connection request from receiver 120; or validating or rejecting an incoming connection request. In some embodiments, the ASR instruction subset may not include a non-ASR instruction subset. The non-ASR instruction subset may include instructions related to at least two of: initialization of a random access memory (RAM) segment or block; initialization of an external instrument component; initialization of an operating system service; or initialization of a communication protocol stack.

[0181] As described herein, for the sensor control device 110 and the data receiving device 120 (or the multi-purpose device 130, etc.) used to establish a communication session, the sensor control device 110 and the data receiving device 120 transmit an initial data packet, which includes information useful for establishing a communication session. This data, which may be referred to as connection data or connection parameters, may be exchanged in a packet of a specific configuration called an advertising data packet. A device attempting to initialize a connection may broadcast an advertising data packet according to a predefined schedule established by the communication protocol used by the device. By way of example only and not limitation, a device utilizing the BLE communication protocol may broadcast an advertising data packet according to a set schedule and using a specific communication frequency reserved for advertising data packets. The sensor control device 110 may repeatedly broadcast advertising data packets when there is no communication session activity. When another device receives an advertising data packet, it may interpret the data included in the data packet and determine whether the device can and should respond to the advertising data packet to initialize a communication session with the sensor control device 120.

[0182] When the device is operating in scanning mode, the device will only receive advertising packets when actively listening for advertising packets. When a device (e.g., data receiving device 120) is not operating in scanning mode, the device may be at risk of missing advertising packets and other requests to initiate a communication session. Therefore, in order to avoid missing potential critical advertising packets, it may be desirable to increase the time spent in scanning mode as much as possible. However, operating in scanning mode consumes a lot of battery power. Scanning mode may require continuous use of communication hardware (e.g., a suitable radio) and processing hardware to interpret any received data packets. This use of battery power can significantly reduce the total battery life of the data receiving device 120, limiting its effectiveness in performing other functions. Therefore, a balance is usually sought between the time spent in scanning mode and the time spent in a low power state. One method includes arranging the time spent in scanning mode so that the device is in scanning mode only for a small portion of the time. In order to increase the chance that the data receiving device 120 can receive a communication packet from the sensor control device 110, the scanning window can be selected or dynamically changed to be consistent with the advertising packet schedule used by the sensor control device 110.

[0183] Fig. 12A A first embodiment of an advertisement schedule and a scanning window schedule used by two devices is shown. Specifically, Fig. 12A An example of synchronization of the advertising schedule of the sensor control device 110 with the scanning window schedule of the data receiving device 120 is shown. The sensor control device 110 is configured to prepare and broadcast advertising data packets 1205 regularly and repeatedly. For example, the sensor control device 110 can be configured to broadcast advertising data packets 1205 once every 10 seconds, 30 seconds, 1 minute, 2 minutes, 5 minutes, etc. As another example, the sensor control device 110 can be configured to broadcast a burst or cluster of advertising data packets simultaneously (e.g., five packets are broadcast in rapid succession every two minutes). As another example, the sensor control device 110 can be configured to quickly broadcast advertising data packets 1205 during short windows that repeat regularly (e.g., repeatedly broadcast advertising data packets for two seconds every two minutes). The advertising schedules described are examples given for illustrative purposes only, and other variations are possible.

[0184] To facilitate the data receiving device 120 to receive the advertising data packets 1205, the data receiving device 120 may operate in a scanning mode during a designated time window 1210 that also repeats. As an example, the data receiving device 120 may operate in a two minute period and operate in the scanning mode in the first ten second window 1210 of the two minute period. During the remaining 110 seconds, the data receiving device 120 may conserve battery power by operating in a low power state. To maximize the ability of the data receiving device 120 to receive the advertising data packets 1205 from the sensor control device 110, the start of the window 1210 may be selected or adjusted to coincide with the timing of the advertising data packet broadcast 1205. For example, the advertising schedule of the sensor control device 110 may be provided in advance to the manufacturer of the data receiving device 120 so that the data receiving device 120 may be pre-configured to operate in the scanning mode while broadcasting the advertising data packets 1205. As another example, during an initial communication session between the sensor control device 110 and the data receiving device 120 (e.g., during a pairing process), the sensor control device 110 may provide details of its advertising schedule to the data receiving device 120, and the data receiving device may adjust its scanning window schedule accordingly. Similarly, in some embodiments, the sensor control device 110 may adapt its advertising schedule to the scanning window schedule of the data receiving device 120. In other embodiments, the advertising and / or scanning window schedules may be specified by the communication protocol itself, or may be specified by the provider of the communication module used by one or more devices.

[0185] While an agreed-upon advertising and scanning window schedule can improve the overlap between advertising windows and scanning windows, this approach can have drawbacks. For example, maintaining overlap requires that both devices time their respective windows precisely. The two devices must maintain consistent internal clocks to maintain synchronization. Fig. 12B As shown, if one or more of the internal clocks are changed or erroneous, synchronization may be disrupted. One way to overcome the potential errors of the internal clocks is to include a buffer time in the scan window length and start time period (e.g., increasing the window to a period beyond that strictly necessary, or starting the scan window earlier than the time when the advertising packet is actually expected to be broadcast). However, this requires the device to operate in the scan mode for a longer period of time, which consumes additional battery power.

[0186] Fig. 12B A second embodiment of an advertisement schedule and a scanning window schedule used by two devices is shown. Specifically, Fig. 12BAn example is shown in which the advertisement schedule of the sensor control device 110 is not synchronized with the scanning window schedule of the data receiving device 120. Because the advertisement schedule and the scanning window schedule are not synchronized, in the example shown, when the data receiving device 120 is in the scanning mode, the advertisement of the sensor control device 110 cannot be received by the data receiving device 120. Therefore, the sensor control device 110 and the data receiving device 120 cannot connect and communicate.

[0187] For example, if an ASIC or other processor used in one or more of the sensor control device 110 and the data receiving device 120 cannot maintain an accurate clock, a fault may occur. Fig. 12B . In some embodiments, the sensor control device 110 and the data receiving device 120 may be designed as disposable devices that are used a limited number of times and / or for a limited period of time. Therefore, the cost of the components is strictly controlled, and one area of ​​cost savings may be the ASIC or other processor. As an example, processors naturally experience slight drift (e.g., less than 5%, less than 3%, or less than 1%) or other errors that increase depending on environmental conditions (e.g., extreme heat or cold can affect the processing speed of the processor or ASIC, which can further exacerbate errors). When the two devices are expected to communicate frequently, the drift level is generally considered acceptable because the frequent communication enables the two devices to resynchronize periodically and / or when it is determined that the degree of difference between the internal clocks of the sensor control device 110 and the data receiving device 120 exceeds a certain threshold. In situations where the two devices are expected to be in close proximity and communication on a continuous basis, for example, the sensor control device 110 and the data receiving device 120 are used as disposable monitoring components of a larger multi-purpose hardware system, it can be assumed that the two devices will be able to resynchronize periodically. However, the opportunity to resynchronize is not necessarily guaranteed, and when longer periods of time are allowed to execute without resynchronization, the drift between the internal clocks of the two devices may exceed an acceptable threshold, resulting in Fig. 12B The situation shown. Because the two devices are out of sync, they cannot reconnect and resynchronize. In some embodiments, to reduce the risk of asynchrony, the frequency of the advertising window and / or scanning window schedule can be reduced (making the advertising data packet broadcast or scanning operation more frequent), or the active window per time period can be increased. However, these methods will significantly increase the battery power consumed by these operations.

[0188] As described herein, an alternative approach may be to dynamically modify the scan window schedule to attempt to reestablish the overlap between the advertising window and the scan window. Fig. 12C A third embodiment of an advertisement schedule and a scanning window schedule used by two devices is shown. Specifically, Fig. 12CAn example is shown in which the data receiving device 120 employs techniques consistent with those discussed herein to remedy potential synchronization issues between the data receiving device 120 and the sensor control device 110. Fig. 12C In the illustrated example, the particular strategy employed by the data receiving device 120 may be referred to as an iterative or iteratively extended scan window schedule.

[0189] exist Fig. 12C In the example shown, the data receiving device 120 and the sensor control device 110 are initially synchronized on the advertising and scanning window schedules. However, the two devices lose synchronization due to, for example, environmental conditions of the devices, causing them to be unable to connect for a long time. The data receiving device 120 can determine that the device has been disconnected (or has been disconnected for a threshold amount of time). The data receiving device 120 can initiate a protocol to dynamically modify the scanning window schedule in an attempt to reestablish the overlap between the advertising window and the scanning window. The data receiving device 120 uses a first scanning window 1210a corresponding to standard operation (e.g., for a first time period). Upon failure to detect the advertising data packet 1205 and / or initiate a communication session with the sensor control device 110, the data receiving device 120 increases the length of the scanning window to last for a second time period. In an embodiment, the data receiving device 120 can additionally or alternatively modify the starting point of the scanning window (e.g., to an earlier or later time period). In the example shown, the data receiving device 120 extends the scan window outward from the middle so that part of the additional time added to the first scan window 1210a is added to the beginning of the second scan window 1210b, and part of the additional time is added to the end of the second scan window. If the data receiving device 120 cannot receive the advertising data packet 1205 during the second scan window 1210b, the time period is extended again. This process continues until during the sixth scan window 1210c shown, the scan window 1210c overlaps with the advertising data packet 1205 again, and the sensor control device 110 and the data receiving device 120 can connect and resynchronize again.

[0190] Fig.13 An exemplary operation flow of the data receiving device 120 according to an embodiment of the disclosed subject matter is shown. Specifically, Fig.13 An example method 1300 performed by the data receiving device 120 is shown to implement iteratively extending a scanning window schedule, e.g. Fig. 12C13. At 1310, the data receiving device 120 detects that the data receiving device 120 and the sensor control device 110 have been disconnected. As an example, the data receiving device 120 may detect that the communication between the devices has timed out due to the absence of communication traffic within a threshold time period. As another example, the data receiving device 120 may detect that the data receiving device 120 has not received an advertising data packet from the sensor control device 110 for more than a threshold duration. In some embodiments, the data receiving device 120 and the sensor control device 110 do not maintain a continuous communication session before disconnection, but instead establish a short connection window to transmit data. In the described embodiments, the data receiving device 120 may detect that the device is disconnected by evaluating the length of time since the last successful data transmission.

[0191] At 1320, the data receiving device 120 can set the scan window to an initial duration. In some embodiments, the initial duration can be a period of time as long as a standard scan window (e.g., a scan window used outside of an iterative search process if different scan windows are used for different purposes). In some embodiments, the initial duration can be shorter than the standard scan window. The initial scan window can be, for example, 1 second, 2 seconds, 3 seconds, etc. In some embodiments, the initial scan window can be selected based on the expected delay in processing the connection data to minimize extraneous scans.

[0192] At 1330, the data receiving device 120 initiates a scan window according to the periodic scan schedule and the initial scan window. As an example, the periodic scan schedule may specify that a scan window will be initiated approximately every 1 minute, 2 minutes, or 5 minutes regardless of the size of the scan window. Therefore, the data receiving device 120 initiates a scan window of the duration of the initial scan window at the next instance of the scan window period.

[0193] At 1335, the data receiving device 120 determines whether a connection with the sensor control device 110 has been established based on the advertising data packets received during the scanning window. For example, the data receiving device 120 may monitor whether any advertising data packets have been received during the scanning window. The data receiving device 120 may determine whether any of the received advertising data packets originated from the sensor control device 110 that was recently disconnected from it. The data receiving device 120 may further determine whether the connection data in the advertising data packets is sufficient to enable the data receiving device 120 and the sensor control device 110 to reestablish a connection. If reestablishment is possible, at 1350, the data receiving device 120 and the sensor control device 110 may exchange data, resynchronize their internal clocks, and otherwise continue normal operation.

[0194] If the data receiving device 120 determines that a connection cannot be established with the sensor control device 110, then at 1340, the data receiving device 120 increases the duration of the scan window. In some embodiments, the scan window is increased by a fixed amount (e.g., 0.5 seconds, 1 second, etc.). In some embodiments, the scan window is increased by a specified amount based on, for example, at least one of the following: the current duration of the scan window, the number of iterations of the method 1300, the duration since the sensor control device 110 and the data receiving device 120 were disconnected, the current available battery power of the data receiving device 120, and other considerations. As an example, the specified amount can be based on or retrieved from a value in a lookup table stored in a memory of the data receiving device or a pre-programmed function of the data receiving device 120. In some embodiments, the amount by which the scan window duration is increased is based on possible drift between the internal clocks of the data receiving device 120 and the sensor control device 110, including but not limited to worst case or average drift.

[0195] In addition to adjusting the duration of the scan window, or in lieu of adjusting the duration of the scan window, the data receiving device 120 can modify the timing of the scan window. For example, an increased amount of time can be added to the beginning of the window (causing the window to start earlier in time), the end of the window (causing the window to extend longer), or a combination of both. An equal amount of time can be removed from the end or beginning of the time window, respectively, to move the scan window over time. In one approach, time is added "from the middle out" so that the window grows on both sides. This approach enables the data receiving device 120 to account for possible drift in the start time of the advertising time, which can push the advertising data packet broadcast to an earlier or later start time.

[0196] At 1345, the data receiving device 120 may determine whether the duration of the increased scan window exceeds a threshold scan window duration. As discussed herein, the data receiving device 120 may have a limited battery, and the length of the scan window is a factor in maximizing battery life. Therefore, the data receiving device 120 may be configured with a maximum allowable scan window to limit the amount of time that the data receiving device 120 is in scan mode. In some embodiments, the maximum scan window duration may be based on at least one of the following factors: the current environment of the data receiving device 120, the current available battery life of the data receiving device 120, the last known battery life of the sensor control device 110, and / or the properties of the advertising schedule of the sensor control device 120. As an example, the sensor control device 110 may be configured with an advertising schedule with a fixed time period such that an advertising data packet is sent at least once per cycle. The cycle length may be, for example, 30 seconds, 1 minute, 2 minutes, 5 minutes, etc. The cycle may be provided to the data receiving device 120 and used as the maximum scan window duration. Thus, when the scan window is at its maximum level, it is guaranteed to overlap the expected advertising period regardless of any desynchronization being experienced. Extending the maximum scan window beyond the cycle length is redundant and wastes battery power.

[0197] If the increased scanning window duration does not exceed the threshold scanning window duration, the data receiving device 120 returns to 1330 and initiates a scanning window based on the increased scanning window duration. The process then continues as described above.

[0198] If the duration of the increased scan window exceeds the maximum scan window threshold, the data receiving device 120 has executed the scan window for longer than the cycle length, and some other factors may prevent the data receiving device 120 and the sensor control device 110 from establishing a connection (e.g., the battery of the sensor control device 110 is dead, environmental factors prevent connection, etc.). Therefore, further extending the scan window would be unnecessary. In order to better use the battery of the data receiving device 120 and reduce the average battery cost of the scan window, the data receiving device 120 returns to 1320 and resets the scan window duration to the duration of the initial scan window (or some other scan window duration that is shorter than the maximum value) before continuing the scanning process described herein.

[0199] The method 1300 may be repeated until the data receiving device 120 is able to resynchronize with the sensor control device 110 or exchange data with the sensor control device 110. In some embodiments, the method 1300 may be repeated for a fixed number of cycles, after which the data receiving device 120 may enter a more aggressive power saving mode assuming that communication with the sensor control device 110 is permanently lost. In some embodiments, various steps of the method 1300 may be modified as the number of iterations of the method 1300 is performed. For example, the maximum scan window threshold may be increased or decreased, the amount by which the scan window duration is increased (e.g., at 1340), the criteria used to determine whether a connection can be established at 1335 may be changed, and other similar modifications may be made.

[0200] The dynamically and iteratively determined scan window method described in method 1300 can reduce the average battery power used when using a scan window to reestablish a connection between a data receiving device 120 and a sensor control device 110. As an example, assuming that any drift that has occurred is relatively small, if the disconnection is recent, the method uses a shorter scan window. The method also includes a mode in which a maximum scan window can be defined based on the advertising period length used by the sensor control device 110, which ensures that there will be overlapping periods as long as no external factors prevent the connection. Therefore, the method involves an improvement over previous techniques that rely on fixed scan window lengths.

[0201] In a specific embodiment, when initiating a communication session between the data receiving device 120 and the sensor control device 110, the connection parameter information is exchanged. The device can use the connection parameter information to initiate the communication session. In some embodiments, one or more of the data receiving device 120 or the sensor control device 110 can select the connection parameter information to improve the connection quality of the communication session. As an example, the connection parameter information can include at least one of the following by way of example and not limitation: connection retry timeout, interconnection retry timeout, monitoring timeout, maximum interval, minimum interval, waiting time, and monitoring timeout. Once the connection parameter information is selected, the device (e.g., the sensor control device 110) can request to adjust the connection parameter configuration to the selected parameters in a process called negotiation. Not all devices support negotiation of all devices.

[0202] In some examples, a peripheral device (e.g., a sensor control device 110) will support communication with multiple devices using a standard protocol (e.g., BLE). Each possible communication partner device is typically capable of maintaining a communication session under various parameter configurations. The differences between the available communication parameters can vary based on, for example, the goals and preferences of the manufacturer of other devices or device components (e.g., the manufacturer of the communication module itself), the physical configuration of the other devices, or the available battery power or operating mode of the device. As an example, it may be the case that a first manufacturer only makes specific communication parameter configurations available for connections using a communication protocol to maintain a consistent use safety or power consumption experience. These communication parameter configurations may be more stringent than configurations provided by other manufacturers. However, devices typically only support strict configurations to simplify integration with various partner devices - even if the configuration is not ideal for a particular use case.

[0203] In a specific embodiment, the sensor control device 110 can be configured to access or determine the connection parameter information based on the identity of the data receiving device 120 with which the communication session is initiated. As an example, the identity of the data receiving device 120 or its manufacturer can be exchanged during the communication session initiation process. The sensor control device 110 can be configured with a database of appropriate connection parameter information that is accessible based on the identity of the data receiving device 120. When a communication session is initiated, the sensor control device 110 can retrieve the appropriate connection parameter information and provide the connection parameter information to the data receiving device 120 as a request to modify the communication parameter configuration of the communication session. Therefore, the selected communication parameter configuration can be customized for a specific data receiving device 120 to improve communication data quality, reliability, throughput speed, etc. The process by which the sensor control device 110 dynamically determines the connection parameter information to be used in connection with a given data receiving device further enables the sensor control device 110 to maintain support for the most stringent requirements while having the advantages of a looser range of acceptable parameters available to other manufacturers and partners.

[0204] As discussed herein, certain manufacturers of data receiving devices 120 may impose individual requirements on certain communication parameters to be used by sensor control devices 110 and other examples of peripheral devices. Table 1 provides examples of parameters that different manufacturers and different devices may use, illustrating the challenges of supporting optimal communication settings for a variety of devices.

[0205] Table 1

[0206] equipment Connection interval Slave Wait Time Monitoring timeout Manufacturer 1; Device 1 30ms 0 720ms Manufacturer 2; Device 1 48.75ms 0 5000ms Manufacturer 2; Device 2 50ms 0 4500ms Manufacturer 3; Device 1 25ms 0 4000ms

[0207] Thus, the embodiments of the present invention provide better adaptability and expansion opportunities for the use of future data receiving devices 120 and multi-purpose devices 130 with sensor control devices 110. For example, the desired combination of communication parameters can be determined by collaborative sharing of communication parameter configurations and measurements of communication quality and reliability. As described herein, the analyte monitoring system 100 can provide accurate and field-tested parameter values ​​based on feedback from the data receiving device 120 or its user. A closed-loop feedback system can be provided that is capable of i) continuously improving connection reliability and quality, ii) adapting to manufacturing changes in the data receiving device 120 and multi-purpose device 13, and iii) adapting to introduced data receiving devices 120 and multi-purpose devices 130. These methods and systems further avoid the need for software updates for sensor control devices of different or newer mobile devices, and thus reduce the number of regulatory submissions.

[0208] Optionally, the information exchanged before or during the establishment of the communication session may include battery status information of the data receiving device 120 and the sensor control device 110. The sensor control device 110 may also include the battery status information in the determination operation for selecting appropriate connection parameter information to provide to the data receiving device 120 as a request to adjust the communication parameter configuration. Other available information may be further used to dynamically adjust the communication parameter configuration based on the current status of the device and the environmental conditions. For example, the ambient noise level of the environment may be measured and used to adjust the communication parameters to improve the reliability of the data connection.

[0209] In some embodiments, appropriate communication parameter settings may be determined before a communication session between the sensor control device 110 and the data receiving device 120 is initiated. As an example, the manufacturer of the sensor control device 110 may test various possible data receiving devices 120 and multi-purpose devices 130 to determine the ideal communication parameters used between the devices under various environmental conditions. For example, such a process may be performed during a certification process required before the data receiving device 120 can be used with the sensor control device 110. The results of the testing may include a compact database linking device manufacturer, brand, model, and software version information with a specific set of communication parameter information. The certification or manual testing process allows an expert to provide an opinion on the best parameters for a particular data receiving device 120.

[0210] In some embodiments, the communication parameter information may be dynamically determined when a communication session is initiated. As an example, the sensor control device 110 may be configured to request maximum and minimum settings for the relevant communication parameters enabled by the data receiving device 120 when a communication session is initiated. The sensor control device 110 may determine whether the maximum setting can be supported, modify the maximum setting as needed, and use the maximum value as the requested communication parameter configuration. As another example, the sensor control device 110 may be configured to have the ability to perform a data link quality test or a self-authentication process. During the data link quality test, the sensor control device 110 may request a series of communication parameter configurations, evaluate the link quality between the sensor control device 110 and the data receiving device 120, and select a communication parameter configuration based on the evaluation.

[0211] According to at least some embodiments, parameter values ​​may be identified by machine learning methods implemented on one or more systems (e.g., remote server 150) of analyte monitoring system 100. Sensor control device 110 and data receiving device 120 may be configured to report the communication parameters used to analyte monitoring system 100. Over time, analyte monitoring system 100 may collect performance measurements of one or more features of interest associated with communication sessions for a large number of sensor control devices 110 and data receiving devices 120. Based on the information collected over time, analyte monitoring system 100 identifies a predetermined set of parameters that exhibits a preferred performance in the communication session.

[0212] The term "communication parameter" refers to one or more parameters associated with a wireless protocol of interest. As discussed herein, non-limiting examples of wireless protocols include Bluetooth Low Energy (BLE), Bluetooth, ZigBee, etc. For example, the BLE protocol is defined in the "Bluetooth Specification Version 4.1" released on December 3, 2013 (incorporated herein by reference). The BLE protocol is a master-slave protocol operating in the frequency range of 2400-2483.5MHz (including the guard band). The BLE protocol uses 20 RF channels with a bandwidth of 2MHz. The 20 RF channels are allocated into two channel types, data channels (with 37 channels) and advertising channels (with 3 channels). Devices on the BLE network use data channels to communicate between connected devices. Devices on the BLE network use advertising channels to discover new devices, initiate connections, and broadcast data. Each RF channel (data and advertising channels) is assigned a unique channel index so that if two devices wish to communicate, the transceiver of each device must be tuned to the same RF channel at the same time. Optionally, additional or alternative communication protocols can be utilized. A non-limiting list of BLE connection parameters includes connection retry timeout, interconnect retry timeout, and monitoring timeout. A non-limiting list of BLE data transmission parameters includes normal minimum interval, normal maximum interval, normal wait time, normal monitoring timeout, low battery minimum interval, low battery maximum interval, low battery wait time, and low battery monitoring timeout.

[0213] exist Figure 1 The manufacture of the devices used in the illustrated analyte monitoring system 100 is not shown, including the sensor control device 110, the data receiving device 120, and the software or application programming interface that can be used by or with the remote server 150, the multi-purpose data receiving device 130, and other user devices 140. The manufacturer may choose to provide the information and programming required for the device to communicate securely through secure programming and updates (e.g., one-time programming, encrypted software or firmware updates, etc.). For example, the manufacturer may provide information that can be used to generate encryption keys for each device, including a secure root key for the sensor control device 110 and optionally for the data receiving device 120, which can be used in combination with device-specific information and operational data (e.g., a random value based on entropy) to generate encryption values ​​unique to the device, session, or data transmission as needed. These encryption keys can be used, for example, to verify data transmitted from an external device (e.g., a data receiving device 120, a multi-purpose data receiving device 130, a user device 140, etc.) to the analyte sensor 110.

[0214] The manufacturer may assign a unique identifier ("UID") and other identification information to each sensor control device 110, such as an identifier of the manufacturer, an identifier of the communication module and the manufacturer, or any other suitable identification information of the sensor or sensor component. As an example, the UID may be derived from sensor-specific data, such as a serial number assigned by an ASIC vendor to each ASIC 200 included in the sensor control device 110, a serial number assigned by a communication module vendor to the communication module 240 included in the sensor control device 110, a random value generated by the sensor manufacturer, etc. Additionally or alternatively, the UID may also be derived from manufacturing values, which include a batch number of the sensor control device 110 or its components, a day, date or time of manufacture of the sensor control device 110 or its key components, a manufacturing location, process or production line of the sensor or its key components, and other information that can be used to identify when and how the sensor was manufactured. The UID may be accompanied by an encryption key and several generated random values, which are also unique to each sensor control device 110. A similar process may be used to establish a secure identity of a receiving device (e.g., a data receiving device 120).

[0215] Since the data collected by the sensor control device 110 and exchanged between the sensor control device 110 and other devices in the analyte monitoring system 100 belong to medical information about the user, the data is highly sensitive and it is advantageous to protect it. The analyte data associated with the user is at least partially sensitive data because the information can be used for a variety of purposes, including health monitoring and drug dosage decisions. In addition to user data, the analyte monitoring system 100 can perform security reinforcement to prevent reverse engineering by outsiders. The security architecture described herein may include various combinations of control features described herein, including but not limited to protecting communications between devices, protecting proprietary information within components and applications, and protecting secrets and key materials. As specifically implemented herein, encryption and authentication can be used as exemplary technical controls to provide protection features. As specifically implemented herein, the various components of the analyte monitoring system 100 can be configured to comply with a security interface designed to protect the confidentiality, integrity and availability ("CIA") of the communication and related data. In order to address these CIA issues, security functions can be included in the design of the hardware and software of the analyte monitoring system 100.

[0216] As specifically implemented herein, to promote confidentiality of data, a communication connection between any two devices (e.g., a sensor control device 110 and a receiving device) can be mutually authenticated before sensitive data is transmitted by either device. The communication connection can be encrypted using a device-unique or session-unique encryption key. As specifically implemented herein, encryption parameters can be configured to change with each data block of the communication.

[0217] As specifically implemented herein, in order to protect the integrity of data, encrypted or unencrypted communications between any two devices (e.g., sensor control device 110 and receiving device) can be verified with a transmission integrity check built into the communication. As an example, as described herein, data transmitted by the sensor control device 110 to the receiving device through a communication session can be verified by the receiving device using a transmission integrity check before the receiving device acts on or stores the data. As another example, as described herein, the payload of the broadcast data packet can include an integrity check value. In addition, the data written to the memory of the sensor control device 110 can be verified or confirmed with an integrity check before execution. As specifically implemented herein, after both devices have been authenticated, session key information that can be used for encrypted communication can be exchanged between the two devices. The integrity check value can include, for example, an error detection code or an error correction code, including, by way of example and not by way of limitation, a non-secure error detection code, a minimum distance coding, a repetition code, a parity bit, a checksum, a cyclic redundancy check, a cryptographic hash function, an error correction code, and other suitable methods for detecting errors in digital messages.

[0218] As specifically implemented herein, minimum distance coding includes a random error correction code that provides a strict guarantee on the number of detectable errors. Minimum distance coding includes selecting a codeword to represent a received value that minimizes the Hamming distance between the value and the representation. Minimum distance coding or nearest neighbor coding can be assisted using standard arrays. Minimum distance coding is considered useful when the probability of an error occurring is independent of the position of a given symbol and the errors can be considered as independent events. These assumptions are particularly applicable to transmission over a binary symmetric channel.

[0219] Additionally or alternatively, as embodied herein, a repetition code relates to a coding scheme that repeats bits over a channel to ensure that a communication message is received without error. Given a data stream to be transmitted, the data is divided into blocks of bits. Each block is transmitted and retransmitted a predetermined number of times. If any transmission of a repeated block is different, an error is detected.

[0220] In addition, or as another alternative, as specifically implemented herein, the checksum is a value relative to a message or a stored data block based on a modular arithmetic sum of a message codeword of a fixed word length. The checksum can be guided from the entire data block or a subset thereof. The checksum is generated using a checksum function or a cryptographic hash function that is configured to output a significantly different checksum value (or hash value) for a slight change in the target message. A parity bit is a bit added to a group of bits during transmission to ensure that the count of certain bits in the result is an even or odd number. For example, a parity bit can be used to ensure that the number of bits with a value of 0 is an odd number. The parity bit can then detect a single error or a fixed number of repeated errors. The parity bit can be considered a special case of a checksum.

[0221] As specifically implemented herein, in order to further reduce or prevent unauthorized access to the devices of the analyte monitoring system 100, the root key (e.g., a key for generating a device-unique or session-unique key) may optionally not be stored on the sensor control device 110, and may be encrypted by the remote server 150 when stored, or encrypted on other devices (e.g., data receiving devices 120) having greater computing power than the sensor control device 110. As specifically implemented herein, the root key may be stored in an obfuscated manner to prevent third parties from easily accessing the root key. The root key may also be stored in different encryption states based on its storage location in the memory. As specifically implemented herein, in order to promote the availability of data, the operation of the sensor control device 110 may be protected from tampering during the service life, wherein the sensor control device 110 may be configured to be disposable, for example and as specifically implemented herein, by limiting access to the write function of the memory 220 via the communication interface (e.g., BLE and NFC). The sensor can be configured to grant access only to known devices (e.g., identifiers by MAC address or UID) or only to devices that can provide a predetermined code associated with the manufacturer or other authenticated user. Access to the read function of the memory 220 can also be enforced, including, for example, the read function attempts to access specific areas of the memory 220 that have been designated as secure or sensitive. The sensor control device 110 can also reject any communication connection request that does not complete the authentication within a specified amount of time to prevent specific denial of service attacks on the communication interface, including attempted man-in-the-middle (MITM) attacks. In addition, the general authentication and encryption design described herein can support interoperable use, where the data of the sensor control device 110 can be obtained by other "trusted" data receiving devices, rather than being permanently bound to a single device.

[0222] As specifically implemented herein, devices including the sensor control device 110 and receiving devices in the environment of the sensor control device 110 (e.g., data receiving device 120, multi-purpose data receiving device 130, user device 140, etc.) can adopt various security practices to ensure the confidentiality of data exchanged on the communication session, and facilitate the relevant devices to find and establish connections with trusted endpoints. As an example, the sensor control device 110 can be configured to actively identify and connect to trusted local, wide area or cellular broadband networks, and continuously verify the integrity of these connections. If the requester cannot complete the proprietary login process through the communication interface within a predetermined time period (e.g., within four seconds), the sensor control device 110 can further reject and close the connection request. For example, but not limited to, this configuration can further prevent denial of service attacks.

[0223] As embodied herein, the sensor control device 110 and the receiving device can support the establishment of a long-term connection pair by storing encryption and authentication keys associated with other devices. For example, the sensor control device 110 or the data receiving device can associate a connection identifier with an encryption and authentication key used to establish a connection with another device. In this way, the devices can reestablish lost connections more quickly, at least in part because the devices can avoid establishing a new authentication pairing and can exchange information directly through an encrypted communication protocol. After successfully establishing a connection, the device can avoid broadcasting a connection identifier and other information to establish a new connection, and can communicate using an agreed-upon channel hopping scheme to reduce the chances of a third party eavesdropping on the communication.

[0224] On-chip hardware functions can be used to actively manage data transmission and storage integrity. Although encryption can provide a secure means of transmitting data in a tamper-proof manner, encryption and decryption can be computationally expensive processes. In addition, transmission failures may be difficult to distinguish from attacks. As previously described, hardware-based fast error detection codes can be used for data integrity. As an example, as specifically implemented herein, an error detection code of an appropriate size for the message length (e.g., a 16-bit CRC) can be used, but other suitable hardware-based error detection codes can be used in accordance with the disclosed subject matter. Programming instructions to access, generate, or manipulate sensitive data can be stored in memory blocks or containers, which are further protected by additional security measures (e.g., encryption).

[0225] As specifically implemented herein, the analyte monitoring system 100 can use periodic key rotation to further reduce the possibility of key leakage and exploitation. The key rotation strategy adopted by the analyte monitoring system 100 can be designed to ensure backward compatibility of field-deployed or distributed devices. As an example, the analyte monitoring system 100 can use keys for downstream devices (e.g., devices on site or devices that cannot be feasibly provided with updates) that are designed to be compatible with multiple generations of keys used by upstream devices. In addition, according to the subject matter of this article, the keys can be securely updated by invalidating the storage blocks including expired keys and then replacing these expired keys with data written to the new memory. The rotation of the key can be initiated by the manufacturer or operator of the analyte monitoring system 100. For example, the manufacturer or operator of the analyte monitoring system 100 can generate a new set of keys or define a new set of processes for generating keys. During the manufacture of the sensor 110 intended to use a new set of keys, the manufacturer can transmit a new set of keys to the newly manufactured sensor 110. The manufacturer may also push updates to deployed devices that communicate with the remote server 150 to extend a new set of keys or a new set of processes for generating keys to deployed devices. As a further alternative, key rotation may be based on an agreed-upon schedule, where devices are configured to adjust the keys used based on some time or event-driven function.

[0226] In summary, embodiments described herein include a data receiving device for an analyte monitoring system. The data receiving device detects a disconnection between the data receiving device and a sensor control device of the analyte monitoring system. The data receiving device sets a duration of a scan window for receiving a connection data packet from the sensor control device to a current length and starts the scan window. In response to determining that a connection between the data receiving device and the sensor control device has not been established based on a connection data packet received during the scan window, the data receiving device performs an iteration of a process to adjust the scan window, including increasing the duration of the scan window to a new length greater than the current length, and starting the scan window based on the duration of the scan window of the new length.

[0227] In addition to the specific embodiments claimed below, the disclosed subject matter also relates to other embodiments having the dependent features claimed below and any other possible combination of those features disclosed above and in the accompanying drawings. Therefore, the specific features disclosed herein can be combined with each other in other ways within the scope of the disclosed subject matter, so that the disclosed subject matter can be considered to be particularly directed to other embodiments having any other possible combination. Therefore, for the purpose of illustration and description, the foregoing description of specific embodiments of the disclosed subject matter has been presented. It is not intended to be exhaustive or to limit the disclosed subject matter to those embodiments disclosed.

[0228] It will be apparent to those skilled in the art that various modifications and variations may be made to the methods and systems of the disclosed subject matter without departing from the spirit or scope of the disclosed subject matter. Therefore, the disclosed subject matter is intended to include modifications and variations within the scope of the appended claims and their equivalents.

[0229] Implementations are further exemplified in the following numbered items:

[0230] Item 1. A data receiving device for an analyte monitoring system, comprising:

[0231] means for detecting a disconnection between a data receiving device and a sensor control device of an analyte monitoring system, the sensor control device comprising a communication module and an analyte sensor, the analyte sensor being configured to be transcutaneously positioned in contact with a bodily fluid of a subject wearing the sensor control device;

[0232] means for setting the duration of a scan window for receiving connection packets from the sensor control device to a current length;

[0233] means for initiating a scanning window based on a duration of the scanning window of a current length; and

[0234] Means for performing one or more iterations of a process to adjust the scanning window in response to determining that a connection between the data receiving device and the sensor control device has not been established based on a connection data packet received during the scanning window, the means for performing further comprising:

[0235] means for increasing the duration of the scan window to a new length, the new length being greater than the current length; and

[0236] Means for initiating a scanning window based on a duration of the scanning window of a new length.

[0237] Item 2. The data receiving device according to Item 1, further comprising:

[0238] means for establishing a connection with the sensor control device after initiating a scanning window for a duration based on the current length of the scanning window; and

[0239] Means for synchronizing a clock maintained by the data receiving device with a clock maintained by the sensor control device in response to establishing the connection.

[0240] Item 3. The data receiving device according to Item 1 or 2, further comprising:

[0241] Means for comparing the duration of the scan window of the new scan window length to a scan window duration threshold.

[0242] Item 4. The data receiving device according to Item 3, further comprising:

[0243] Means for resetting the duration of the scan window to a length less than the scan window duration threshold in response to determining that the duration of the scan window exceeds the scan window duration threshold.

[0244] Item 5. The data receiving device according to Item 4, wherein the length less than the scanning window duration threshold is equal to the duration of the scanning window used after the disconnection is detected.

[0245] Item 6. The data receiving device according to any one of Items 1 to 5, wherein the amount by which the duration of the scanning window is increased is a fixed amount.

[0246] Item 7. The data receiving device of any one of Items 1-6, wherein the amount by which the duration of the scanning window is increased is based on a currently available battery charge of the data receiving device.

[0247] Item 8. The data receiving device of any one of Items 1-7, wherein the amount by which the duration of the scanning window is increased is based on a last known available battery charge of the sensor control device.

[0248] Item 9. The data receiving device according to any one of Items 1-8, wherein the means for adjusting the scanning window comprises means for modifying a start time of the scanning window.

[0249] Item 10. The data receiving device according to any one of Items 1 to 9, further comprising:

[0250] means for establishing a connection with the sensor control device after initiating a scanning window for a duration based on the current length of the scanning window; and

[0251] Means for receiving analyte data originating from the analyte sensor from the sensor control device in response to establishing the connection.

[0252] Item 11. The data receiving device of Item 10, further comprising means for outputting a value based on the analyte data for display.

[0253] Item 12. A data receiving device according to Item 10 or 11, further comprising means for using the analyte data to modify a treatment implemented by the data receiving device.

[0254] Item 13. A data receiving device according to any one of Items 1-12, wherein the analyte sensor is configured to generate a data signal measuring the level of an analyte in a body fluid, and wherein the analyte includes glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein or uric acid.

[0255] Item 14. A sensor control device of an analyte monitoring system, the sensor control device comprising:

[0256] an analyte sensor, wherein at least a portion of the analyte sensor is transcutaneously positioned in contact with a bodily fluid of a subject;

[0257] a communication module; and

[0258] means for receiving, via the communication module, a request to initiate a communication session with a data receiving device of the analyte monitoring system, wherein the request to initiate the communication session includes identity information of the data receiving device;

[0259] means for identifying a desired communication parameter configuration for a communication session based on the identity information;

[0260] means for initiating a communication parameter negotiation process with a data receiving device, wherein the negotiation process includes providing a desired communication parameter configuration to the data receiving device; and

[0261] Means for modifying one or more communication parameters of a communication session based on a negotiation process.

[0262] Item 15. The sensor control device of Item 14, further comprising means for initiating a communication session with a data receiving device using the modified communication parameters.

[0263] Item 16. The sensor control device according to Item 14 or 15, further comprising:

[0264] means for determining the level of an analyte in a subject based on an analyte sensor; and

[0265] Means for transmitting the analyte level to a data receiving device in a communication session.

[0266] Item 17. The sensor control device according to any one of Items 14-16, further comprising:

[0267] means for dynamically determining further modifications to the desired communications parameter configuration for the communications session;

[0268] means for conducting a second communication parameter negotiation process with the data receiving device, wherein the second negotiation process includes providing further modifications to the agreed communication parameter configuration to the data receiving device; and

[0269] One or more communication parameters of the communication session are modified based on the second negotiation process.

[0270] Clause 18. The sensor control device of clause 17, wherein dynamically determining further modifications to the desired communication parameter configuration for the communication session comprises performing a communication link quality test based on the plurality of communication parameter configurations.

[0271] Clause 19. A sensor control device according to clause 17 or 18, wherein dynamically determining further modifications to the desired communication parameter configuration for the communication session includes modifying the desired communication parameter configuration based on available battery power of the sensor control device or the data receiving device.

Claims

1. A data receiving device for an analyte monitoring system, comprising: one or more processors; Communication module; as well as one or more memories communicatively coupled to the one or more processors and the communication module and comprising instructions executable by the one or more processors to configure the one or more processors to perform operations comprising: detecting a disconnection between the data receiving device and a sensor control device of the analyte monitoring system, the sensor control device comprising a communication module and an analyte sensor configured to be transcutaneously positioned in contact with a bodily fluid of a subject wearing the sensor control device; setting the duration of a scan window for receiving connection packets from the sensor control device to a current length; initiating the scanning window based on the duration of the scanning window of the current length; and In response to determining that a connection between the data receiving device and the sensor control device has not been established based on the connection data packet received during the scanning window, performing one or more iterations of a process to adjust the scanning window, the process comprising operations including: increasing the duration of the scan window to a new length, the new length being greater than the current length; and The scanning window is initiated based on the duration of the scanning window of the new length.

2. The data receiving device according to claim 1, wherein: The instructions are further executable by the one or more processors to configure the one or more processors to perform further operations comprising: after initiating the scan window based on the duration of the scan window of the current length: establishing a connection with the sensor control device; and In response to establishing the connection, a clock held by the data receiving device is synchronized with a clock held by the sensor control device.

3. The data receiving device according to claim 1 or 2, wherein: The process of adjusting the scanning window includes the following operations: The duration of the scan window of a new scan window length is compared to a scan window duration threshold.

4. The data receiving device according to claim 3, wherein: The process of adjusting the scanning window includes the following operations: In response to determining that the duration of the scan window exceeds the scan window duration threshold, the duration of the scan window is reset to a length less than the scan window duration threshold.

5. The data receiving device according to claim 4, wherein: The length that is less than the scanning window duration threshold is equal to the duration of the scanning window used after the disconnection is detected.

6. The data receiving device according to any one of claims 1 to 5, wherein: The amount by which the duration of the scan window is increased is a fixed amount.

7. The data receiving device according to any one of claims 1 to 6, wherein: The amount by which the duration of the scan window is increased is based on a currently available battery charge of the data receiving device.

8. The data receiving device according to any one of claims 1 to 7, wherein: The amount by which the duration of the scanning window is increased is based on a last known available battery charge of the sensor control device.

9. The data receiving device according to any one of claims 1 to 8, wherein: The process of adjusting the scanning window includes the following operations: Modify the start time of the scan window.

10. The data receiving device according to any one of claims 1 to 9, wherein: The instructions are further executable by the one or more processors to configure the one or more processors to perform further operations comprising, after initiating the scanning window based on the duration of the scanning window of the current length: establishing a connection with the sensor control device; and In response to establishing the connection, analyte data originating from the analyte sensor is received from the sensor control device.

11. The data receiving device according to claim 10, wherein: The instructions are also executable by the one or more processors to configure the one or more processors to perform further operations including: Values ​​based on the analyte data are output for display.

12. The data receiving device according to claim 10 or 11, wherein: The instructions are also executable by the one or more processors to configure the one or more processors to perform further operations including: The analyte data is used to modify therapy implemented by the data receiving device.

13. The data receiving device according to any one of claims 1 to 12, wherein: The analyte sensor is configured to generate a data signal measuring the level of an analyte in the bodily fluid, and wherein the analyte comprises glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine aminotransferase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, or uric acid.

14. A sensor control device for an analyte monitoring system, the sensor control device comprising: one or more processors; an analyte sensor, wherein at least a portion of the analyte sensor is transcutaneously positioned in contact with a bodily fluid of a subject; a communication module; and one or more memories communicatively coupled to the one or more processors, the analyte sensor, and the communication module, and comprising instructions executable by the one or more processors to configure the one or more processors to perform operations comprising: receiving, via the communication module, a request to initiate a communication session with a data receiving device of the analyte monitoring system, wherein the request to initiate the communication session includes identity information of the data receiving device; identifying, from the one or more memories, a desired communications parameter configuration for the communications session based on the identity information; Initiating a communication parameter negotiation process with the data receiving device, wherein the negotiation process includes providing the desired communication parameter configuration to the data receiving device; and One or more communication parameters of the communication session are modified based on the negotiation process.

15. The sensor control device according to claim 14, wherein: The instructions are also executable by the one or more processors to configure the one or more processors to perform operations, the operations also including: The communication session with the data receiving device is initiated using the modified communication parameters.

16. The sensor control device according to claim 14 or 15, wherein: The instructions are also executable by the one or more processors to configure the one or more processors to perform operations, the operations also including: determining an analyte level of the subject based on the analyte sensor; and The analyte level is transmitted to the data receiving device in the communication session.

17. The sensor control device according to any one of claims 14 to 16, wherein: The instructions are also executable by the one or more processors to configure the one or more processors to perform operations, the operations also including: dynamically determining further modifications to the desired communications parameter configuration for the communications session; performing a second communication parameter negotiation process with the data receiving device, wherein the second negotiation process includes providing the further modification to the agreed communication parameter configuration to the data receiving device; and One or more communication parameters of the communication session are modified based on the second negotiation process.

18. The sensor control device according to claim 17, wherein: Dynamically determining further modifications to the desired communication parameter configuration for the communication session includes performing a communication link quality test based on a plurality of communication parameter configurations.

19. The sensor control device according to claim 17 or 18, wherein: Dynamically determining further modifications to the desired communication parameter configuration for the communication session includes modifying the desired communication parameter configuration based on an available battery charge of the sensor control device or the data receiving device.

Images