Patent Application
20240040348
The disclosed subject matter relates to a system for transmitting data between an analyte sensor and one or more receiving devices in an external environment of the analyte sensor.
Certain analyte sensor devices can wirelessly transmit data to, and receive data from, other computing devices. While some of these analyte sensor devices are equipped with powerful processors and operate using a permanent power supply, other analyte sensor devices are designed to operate efficiently, using little power. Low-power analyte sensor devices can also have less computational capabilities or resources than the devices with which these analyte sensor devices are communicating. The low-power analyte sensor devices can rely on more powerful devices to perform more complex processing of the data the low-power analyte sensor devices are collecting. In some cases, these low-power analyte sensor devices have restricted communication abilities as well, typically limited to short-range communication with devices that are within the same room. 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, to ensure real-time processing of data, such that the most relevant data is available to a user of the low-power analyte sensor device, some low-power analyte sensor devices must maintain the communication session for data processing to be performed. The communication session can still use the short-range communication. If the low-power analyte sensor device or other device are moved out of range, the communication session can terminate, and data can be left unprocessed. In addition to inconveniencing the users of the low-power analyte sensor device, maintaining a communication session with another analyte sensor device can drain the battery of the low-power analyte sensor device, reducing the operational lifetime of the device.
In other low-power analyte sensor devices, communication sessions are not constantly maintained. Instead, these low-power analyte sensor devices can establish a communication session when there is a backlog of historical data that has yet to be offloaded to a more powerful device. To conserve battery life, once the data has been 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 range to reestablish a communication session, or can rely on the user to request such data using the receiving device. If a receiving device is in range, the low-power analyte sensor device establishes a new communication session to upload the additional data. If the receiving device is out of range or otherwise unavailable while the low-power analyte sensor device is looking for it, the data cannot be uploaded. Moreover, once the receiving device returns within range of the analyte sensor device, the receiving device and analyte sensor device re-establish a communication session, which can take additional time before additional data can be transferred such that the latest analyte data may not be immediately available to the user.
Accordingly, there is an opportunity for methods and systems that can be implemented by low-power, and low-cost, analyte sensor devices to efficiently provide current or high priority analyte data to other devices for processing and output.
Aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applied to each aspect alone or in combination with other aspects.
The purpose and advantages of the disclosed subject matter will be set forth in and apparent from the description that follows, as well as will be learned by practice of the disclosed subject matter. Additional advantages of the disclosed subject matter will be realized and attained by the methods and systems particularly pointed out in the written description and claims hereof, as well as from the drawings.
To achieve these and other advantages and in accordance with the purpose of the disclosed subject matter, as embodied and broadly described, the disclosed subject matter includes systems and methods for expedited delivery of high-priority data from an analyte sensor to one or more receiving devices by repurposing reserved communication channels. Exemplary systems and methods can include a method for monitoring a subject using an analyte monitoring device. One or more processors of the analyte monitoring device generate sensor data indicative of an analyte level measured by an analyte sensor. At least a portion of the analyte sensor can be transcutaneously positioned in contact with a bodily fluid of the subject. The one or more processors of the analyte monitoring device can identify a subset of the sensor data based on a priority level associated with the sensor data. The one or more processors of the analyte monitoring device can prepare a data packet that includes the identified subset of the sensor data and connection data associated with establishing a communication session with the analyte monitoring device. The one or more processors of the analyte monitoring device can cause a transceiver of the analyte monitoring device to transmit the data packet to one or more user devices within a communication range of the transceiver. The one or more processors of the analyte monitoring device can receive, through the transceiver and from a first user device of the one or more user devices, an acknowledgement signal indicating receipt of the sensor data. In particular embodiments, the data packet further includes identification data for the first user device for directing the data packet to the first user device. In particular embodiments, prior to causing the transceiver of the analyte monitoring device to transmit the data packet, the one or more processors of the analyte monitoring device can receive an activation command from the first user device. In particular embodiments, the one or more processors of the analyte monitoring device can cause the transceiver to transmit the data packet by identifying one or more communication channels that are associated, by a specified communication protocol, with establishing connections between devices and generating a signal based on the data packet using the one or more identified communication channels. In particular embodiments, after receiving the acknowledgement signal from the first user device, the one or more processors of the analyte monitoring device can establish the communication session with the first user device using the transceiver. The one or more processors of the analyte monitoring device can cause the transceiver to transmit a second subset of the sensor data to the first user device through the communication session. The second subset of the sensor data was not included in the data packet. In particular embodiments, the one or more processors of the analyte monitoring device can encrypt the identified subset of the sensor data using an encryption key shared between the analyte monitoring device and the first user device. In particular embodiments, the encryption key can be dynamically determined or identified using a key-rotation scheme. In particular embodiments, the priority level associated with the sensor data can be based on a time elapsed since the sensor data was collected. The sensor data with a highest priority level can be the most recently collected. In particular embodiments, the priority level associated with the sensor data is based on a condition of the subject determined from the sensor data. In particular embodiments, the one or more processors of the analyte monitoring device prepares connection data associated with establishing the communication session with the analyte monitoring device based on a periodically occurring window of time. In particular embodiments, the analyte can be, by way of example and not limitation, glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, 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 particular embodiments, the data packet further includes a temperature, heart rate, blood pressure, or movement data of the subject.
According to other aspects of the disclosed subject matter, systems and methods can include a method for monitoring analyte levels of a subject using a user device. One or more processors of the user device can send, using a communication module of the user device, an activation command to an analyte monitoring device associated with the subject. The one or more processors of the user device can receive, using the communication module and during a first communication session with the analyte monitoring device, a first set of sensor data from the analyte monitoring device. The first set of sensor data can be indicative of a first analyte level measured by the analyte monitoring device at a first time. The one or more processors of the user device can close the first communication session. The one or more processors of the user device can receive, using the communication module, a data packet from the analyte monitoring device. The data packet can include connection data associated with establishing a second communication session with the analyte monitoring device. The data packet can include a second set of sensor data from the analyte monitoring device indicative of a second analyte level measured by the analyte monitoring device at a second time. The one or more processors of the user device can output the second set of sensor data in an interface of the user device. In particular embodiments, outputting the second set of sensor data include causing, by the one or more processors of the user device, the interface of the user device to indicate that the second set of sensor data corresponds to a current or most recently determined analyte level measured by the analyte monitoring device. In particular embodiments, the one or more processors of the user device can output an alarm based on the second set of sensor data. In particular embodiments, the one or more processors of the user device can send, using the communication module, an acknowledgement signal to the analyte monitoring device. The acknowledgement signal can indicate that the second set of sensor data has been received. In particular embodiments, the one or more processors of the user device can establish the second communication session with the analyte monitoring device based on the connection data of the data packet. The one or more processors of the user device can receive a third set of sensor data indicative of a third analyte level measured by the analyte monitoring device during a period of time between the first time and the second time. In particular embodiments, the second set of sensor data is included in an encrypted data payload of the data packet. The one or more processors of the user device can decrypt the encrypted data payload of the data packet using an encryption key shared between the analyte monitoring device and the user device and extract the second set of sensor data from the decrypted data payload. In particular embodiments, the user device is associated with a user who has been approved by the subject to receive the sensor data on behalf of the subject.
According to other aspects of the disclosed subject matter, systems and method can include an analyte monitoring device that 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. The one or more processors can be configured to generate sensor data indicative of 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 the subject. The one or more processors can be configured to store the sensor data in the one or more memories. The one or more processors can identify, from the one or more memories, a first subset of the sensor data corresponding to a first time. The one or more processors can prepare a data packet including the identified subset of the sensor data and connection data associated with establishing a communication session with the analyte monitoring device. The one or more processors can cause the communication module to transmit the data packet to one or more user devices within a communication range of the communication module. The one or more processors can receive, through the communication module, a communication session request from a first user device of the one or more user devices. The one or more processors can cause the communication module to transmit a second data packet to the first user device, the second data packet including a second subset of the data corresponding to a second time.
To further advantages and in accordance with the purpose of the disclosed subject matter, as embodied and broadly described, the disclosed subject matter further includes systems and methods for establishing, maintaining, and transmitting data to multiple receiving devices using concurrent communication sessions. Exemplary systems and methods can include an analyte monitoring device for monitoring a subject using an analyte monitoring device. The analyte monitoring device can 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 memories include instructions executable by the one or more processors to configure the one or more processors to perform operations in accordance with the techniques disclose herein. One or more processors of the analyte monitoring device generate sensor data indicative of an analyte level measured by an analyte sensor of the analyte monitoring device. At least a portion of the analyte sensor is transcutaneously positioned in contact with a bodily fluid of the subject. The one or more processors of the analyte monitoring device receive a first request for the sensor data from a first device and a second request for the sensor data from a second device. The one or more processors of the analyte monitoring device select a first subset of the sensor data responsive to the first request. The one or more processors of the analyte monitoring device select a second subset of the sensor data responsive to the second request. The one or more processors of the analyte monitoring device prepare a first data packet including the first subset of the sensor data and a second data packet including the second subset of the sensor data. The one or more processors of the analyte monitoring device cause the 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.
In particular embodiments, prior to 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, through the communication module and from the first device, an acknowledgement signal indicating receipt of the first subset of the sensor data. In particular embodiments, the first request and the second request include criteria for selecting the first subset of the sensor data and the second subset of the sensor data, respectively. In particular embodiments, the one or more processors of the analyte monitoring device select the first subset of the sensor data or the second subset of the sensor data based on a priority level associated with the sensor data. In particular embodiments, the one or more processors of the analyte monitoring device cause the communication module to transmit the first data packet to the first device before causing the communication module to transmit the second data packet to the second device based on the analyte monitoring device receiving the first request for the sensor data before receiving the second request for the second data. In particular embodiments, the first device or the second device is a fitness monitor or fitness device. In particular embodiments, the first device or the second device includes medical components for use by the subject based on the first subset of the sensor data or the second subset of the sensor data. In particular embodiments, the first device or the second device includes networking components to transmit the first subset of the sensor data or the second subset of the sensor data to one or more remote devices. In particular embodiments, the first device is a smartphone and the second device is a smartwatch.
In particular embodiments, the one or more processors of the analyte monitoring device establish, a communication session with the second device through communication with the first device by: receiving, from the first device and via the communication module, a connection request including identification information for the second device and information to facilitate a communication session with the second device, where the identification information was received by the first device from the second device during a communication session between the first device and the second device; transmitting an acknowledgement of the connection request to the second device using the information to facilitate the communication session with the second device; and performing a mutual authentication with the second device to generate a shared encryption key for subsequent communication sessions. In particular embodiments, the first request for the sensor data includes an identifier for 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 particular embodiments, the one or more processors of the analyte monitoring device encrypt the first subset of the sensor data using a first encryption key shared between the analyte monitoring device and the first device and encrypt the second subset of the sensor data using a second encryption key shared between the analyte monitoring device and the second device. In particular embodiments, the first encryption key and second encryption key are dynamically determined or identified using a key-rotation scheme. In particular embodiments, the analyte includes glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, or uric acid.
An analyte sensor can exchange data with other devices, referred to as receivers, controlled by users. The receivers can use commercial operating systems that communicate through wireless bi-directional communication links with the analyte sensor. As one example, mobile devices with Bluetooth Low Energy (BLE) circuitry are available for communication with certain analyte sensors. The bi-directional communication links can be formed using a wireless communication protocol that includes connection requests or advertisement notices received by the receivers. The advertisement notices are broadcast by the analyte device at predetermined constant frequencies. The use of the advertising notices to facilitate the establishment of wireless communications involves a significant power consumption for the analyte sensor.
During a typical advertising operation, an analyte sensor configured to operate with a short-range wireless communication protocol such as BLE, transmits advertisement notices and searches for scan requests from receivers. In some cases, the analyte sensor is in a sleep state, in which the analyte sensor consumes relatively little power, when it is time to perform an advertising operation. The analyte sensor wakes up from the sleep state before the analyte sensor is able to transmit an advertisement notice and searches for a scan request. Each time the analyte sensor awakes from the sleep state, the analyte sensor performs a predetermined set of startup and initialization actions or tasks. The analyte sensor utilizes a certain amount of power to perform all of the startup and initialization tasks associated with waking up. Over the lifetime of an analyte sensor, the analyte sensor will go to sleep and awake from the sleep state a substantially large number of times (e.g., several times each hour). Consequently, the actions and tasks that are performed during every wake-up operation, even if just to perform an advertising operation, utilize a relatively large amount of power over the life of the device.
According to other aspects of the disclosed subject matter, an analyte sensor can include a communication module with communication circuitry configured to wirelessly communicate with at least one other device, such as a receiver. The communication circuitry can be configured to transition between a sleep state, a partial awake state and a fully awake state. When in the fully awake state, the communication circuitry can be configured to execute tasks and actions associated with a communications protocol startup (CPS) instruction set that includes an advertisement scanning related (ASR) instruction subset and a non-ASR instruction subset. When in the partially awake state, the communication circuitry can be configured to execute functions, such as the ASR instruction subset. The partially awake state can be implemented as a limited-functionality branch of a programming and hardware stack directed to operating certain aspects of a communication protocol. The functions can include to prepare and transmit advertising notices, which can include payloads configured with specialized information as discussed herein, over one or more channels according to a wireless communications protocol and to scan the one or more channels for a connection request from another device. When a connection request is not received, the communication circuitry can return to the sleep state without performing actions or tasks associated with the non-ASR instruction subset of the CPS instruction set. Therefore, by implementing the partially awake state and only performing actions or tasks associated with the non-ASR instruction subset when a connection request is received, the total and average power consumption of the communication circuitry is reduced when the most common operation is to wake and send advertisement notices.
According to other aspects of the disclosed subject matter, an analyte monitoring device can 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 can be configured to generate sensor data indicative of 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 the subject. The one or more processors can be configured to initialize the communication module using an advertisement scanning related instruction set. The advertisement scanning related instruction set is a subset of a communications protocol startup instruction set including the advertisement scanning related instruction set and a non-advertisement scanning related instruction set. The one or more processors can cause the communication module to issue one or more advertising data packets and receive a connection request from a receiving device. The one or more processors can complete initialization of the communication module using the non-advertisement scanning related instruction set. The one or more processors can select a subset of the sensor data, prepare a data packet comprising the subset of the sensor data, and cause the communication module to transmit the data packet to the receiving device.
In particular embodiments the communication module can be initialized responsive to the detection of expiration of a wakeup timer. In particular embodiments, initializing the communication module includes transitioning the communication module from a sleep state to an active state. In particular embodiments, after causing the communication module to issue the one or more advertising data packets, the one or more processors are further configured to determine that the connection request has not 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 using an advertisement scanning related instruction set a second time, wherein the connection request is received from the receiving device after the communication module has been initialized the second time. In particular embodiments, the communication module is transitioned from the awake state to the sleep state without executing the non-advertisement scanning related instruction set. In particular embodiments, the non-advertisement scanning 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 particular embodiments, the advertisement scanning related instruction set includes instructions related to detecting expiration of a wake-up timer, processor startup, initialization of a transmit circuit, formation of advertising data packets, transmission of advertising data packets, scanning one or more channels for a connection request from the receiving device, or validating or denying an incoming connection request. In particular embodiments, the connection request includes criteria for selecting the subset of the sensor data. In particular embodiments, the one or more processors are further configured to select the subset of the sensor data based on a priority level associated with the sensor data.
In another aspect, a computer implemented method is provided. Under control of one or more processors of an analyte sensor, where the one or more processors are configured with specific executable instructions, the method can include collecting signals related to detected analyte levels, and implementing program instructions to analyze the signals and/or manage storage of the signals and/or deliver a therapy. The method can also include communicating wirelessly with at least one other device and executing tasks and actions associated with a communications protocol startup (CPS) instruction set that includes an advertisement scanning related (ASR) instruction subset and a non-ASR instruction subset when in the fully awake state. When in a partially awake state, the method can include executing functions such as the ASR instruction subset. The functions can include transmitting advertising notices over one or more channels according to a wireless communications protocol, scanning the 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 the non-ASR instruction subset of the CPS instruction set when a connection request is not received.
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 executable by the one or more processors to configure the one or more processors to perform operations according to the embodiments and objectives described herein. The data receiving device detects a disconnect between the data receiving device and a sensor control device of the analyte monitoring system. The sensor control device includes a communication module and an analyte sensor configured to be transcutanteously positioned in contact with a bodily fluid of a subject wearing the sensor control device. The data receiving device sets a duration of a scan window for receiving connection data packets from the sensor control device to a current length. The data receiving device initiates the scan window based on the duration of the scan window at the current length. The data receiving device, in response to determining that a connection between the data receiving device and sensor control device has not been established based on connection data packets received during the scan window, performs one or more iterations of a process to adjust the scan window. The iterative process includes increasing a duration of the scan window to a new length, the new length being greater than the current length and initiating the scan window based on the duration of the scan window at the new length.
In particular embodiments, the data receiving device subsequent to initiating the scan window based on the duration of the scan window at the current length establishes a connection with the sensor control device and, in response to establishing the connection, synchronizes a clock maintained by the data receiving device with a clock maintained by the sensor control device. In particular embodiments, the process to adjust the scan window further includes comparing the duration of the scan window at the new scan window length to a scan window duration threshold. In particular embodiments, the process to adjust the scan window further includes, in response to determining that the duration of the scan window exceeds the scan window duration threshold, resetting the duration of the scan window to a length that is less than the scan window duration threshold. In particular embodiments, the length that is less than the scan window duration threshold is equal to the duration of the scan window used after the disconnection was detected. In particular embodiments, the amount by which the duration of the scan window is increased is a fixed amount. In particular embodiments, the amount by which the duration of the scan window is increased is based on a current available battery power of the data receiving device. In particular embodiments, the amount by which the duration of the scan window is increased is based on a last known available battery power of the sensor control device. In particular embodiments, the amount by which the duration of the scan window is increased is based on clock drifts associated with a sensor control device or a data receiving device. In particular embodiments, the process to adjust the scan window includes modifying a start time of the scan window. In particular embodiments, the data receiving device, subsequent to initiating the scan window based on the duration of the scan window at the current length establishes a connection with the sensor control device and, in response to establishing the connection, receives, from the sensor control device, analyte data originating from the analyte sensor. In particular embodiments, the data receiving device outputs a value based on the analyte data for display. In particular embodiments, the data receiving device uses the analyte data to modify a therapy administered by the data receiving device. In particular embodiments, the analyte sensor is configured to generate data signals measuring a level of an analyte in the bodily fluid and the analyte includes glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, or uric acid.
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, where 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. The memories include instructions executable by the one or more processors to configure the one or more processors to perform various operations. The sensor control device receives, via the communication module, a request to initiate a communication session with a data receiving device of the analyte monitoring system. The request to initiate the communication session includes identity information for the data receiving device. The sensor control device identifies, from the one or more memories and based on the identity information, a preferred communication parameter configuration for the communication session. The sensor control device initiates a communication parameter negotiation procedure with the data receiving device. The negotiation procedure includes providing the preferred communication parameter configuration to the data receiving device. The sensor control device modifies one or more communication parameters for the communication session based on the negotiation procedure.
In particular embodiments, the sensor control device initiates the communication session with the data receiving device using the modified communication parameters. In particular embodiments, the sensor control device determines a level of an analyte of the subject based on the analyte sensor and transmits the level of the analyte to the data receiving device in the communication session. In particular embodiments, the sensor control device dynamically determines a further modification to the preferred communication parameter configuration for the communication session, conducts a second communication parameter negotiation procedure with the data receiving device, and modifies one or more communication parameters for the communication session based on the second negotiation procedure. In particular embodiments, the sensor control device conducts a communication link quality test based on multiple communication parameter configurations. In particular embodiments, the sensor control device modifies the preferred communication parameter configuration based on an available battery level of the sensor control device or data receiving device.
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.
The accompanying drawings, which are incorporated in and constitute part of this specification, are included to illustrate and provide a further understanding of the methods and systems of the disclosed subject matter. Together with the description, the drawings explain the principles of the disclosed subject matter.
The details of the subject matter set forth herein, both as to its structure and operation, may be apparent by study of the accompanying figures, in which like reference numerals refer to like parts.
Reference will now be made in detail to the various exemplary embodiments of the disclosed subject matter, exemplary embodiments of which are illustrated in the accompanying drawings. The structure and corresponding method of operation of the disclosed subject matter will be described in conjunction with the detailed description of the system
The systems and methods presented herein can be used for operations of a sensor used in an analyte monitoring system, such as but not limited to wellness, fitness, dietary, research, information or any purposes involving analyte sensing over time. As used herein, “analyte sensor” or “sensor” can refer to any device capable of receiving sensor information from a user, including for purpose of illustration but not limited to, body temperature sensors, blood pressure sensors, pulse or heart-rate sensors, glucose level sensors, analyte sensors, physical activity sensors, body movement sensors, or any other sensors for collecting physical or biological information. Analytes measured by the analyte sensors can include, by way of example and not limitation, glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, 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 and apparent from the description that follows. Additional advantages of the disclosed subject matter will be realized and attained by the methods, apparatus, and devices particularly pointed out in the written description and claims thereof, as well as from the appended drawings.
For purpose of illustration and not limitation, this disclosure includes methods for expedited delivery of high-priority data from an analyte sensor to one or more receiving devices by repurposing reserved communication channels in accordance with the disclosed subject matter. Exemplary systems and methods can include a method for monitoring a subject using an analyte monitoring device. One or more processors of the analyte monitoring device generate sensor data indicative of an analyte level measured by an analyte sensor. At least a portion of the analyte sensor can be transcutaneously positioned in contact with a bodily fluid of the subject. The one or more processors of the analyte monitoring device can identify a subset of the sensor data based on a priority level associated with the sensor data. The one or more processors of the analyte monitoring device can prepare a data packet that includes the identified subset of the sensor data and connection data associated with establishing a communication session with the analyte monitoring device. The one or more processors of the analyte monitoring device can cause a transceiver of the analyte monitoring device to transmit the data packet to one or more user devices within a communication range of the transceiver. The one or more processors of the analyte monitoring device can receive, through the transceiver and from a first user device of the one or more user devices, an acknowledgement signal indicating receipt of the sensor data. In particular embodiments, the data packet further includes identification data for the first user device for directing the data packet to the first user device. In particular embodiments, prior to causing the transceiver of the analyte monitoring device to transmit the data packet, the one or more processors of the analyte monitoring device can receive an activation command from the first user device. In particular embodiments, the one or more processors of the analyte monitoring device can cause the transceiver to transmit the data packet by identifying one or more communication channels that are associated, by a specified communication protocol, with establishing connections between devices and generating a signal based on the data packet using the one or more identified communication channels. In particular embodiments, after receiving the acknowledgement signal from the first user device, the one or more processors of the analyte monitoring device can establish the communication session with the first user device using the transceiver. The one or more processors of the analyte monitoring device can cause the transceiver to transmit a second subset of the sensor data to the first user device through the communication session. The second subset of the sensor data was not included in the data packet. In particular embodiments, the one or more processors of the analyte monitoring device can encrypt the identified subset of the sensor data using an encryption key shared between the analyte monitoring device and the first user device. In particular embodiments, the encryption key can be dynamically determined or identified using a key-rotation scheme. In particular embodiments, the priority level associated with the sensor data can be based on a time elapsed since the sensor data was collected. The sensor data with a highest priority level can be the most recently collected. In particular embodiments, the priority level associated with the sensor data is based on a condition of the subject determined from the sensor data. In particular embodiments, the one or more processors of the analyte monitoring device prepares connection data associated with establishing the communication session with the analyte monitoring device based on a periodically occurring window of time. In particular embodiments, the analyte can be, by way of example and not limitation, glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, 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 particular embodiments, the data packet further includes a temperature, heart rate, blood pressure, or movement data of the subject.
According to other aspects of the disclosed subject matter, systems and methods can include a user device receiving a data packet from an analyte sensor associated with a subject. The user device can identify a data payload of the data packet. The user device can decrypt the data payload using an encryption key shared between the analyte sensor and the user device. The user device can extract analyte data for the subject from the decrypted data payload. The extracted analyte data can correspond to a most recently generated subset of analyte data gathered from the subject. The user device can output the extracted analyte data in an interface of the user device. In particular embodiments, while outputting the extracted analyte data, the interface of the user device can indicate that the extracted analyte data corresponds to a current or most recently generated analyte reading of the subject by the analyte sensor. In particular embodiments, the user device can output an alarm based on the analyte data. In particular embodiments, the user device can extract identification information for the analyte sensor from the data payload of the data packet. The user device can send an acknowledgement signal to the analyte sensor that indicates that the extracted analyte data has been received. The user device can establish a communication session with the analyte sensor based on the identification information for the analyte sensor. The user device can receive a collection of analyte data for the subject from the analyte sensor. In particular embodiments, 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 a previous time. The historical collection of analyte data includes analyte data for the subject collected by the analyte sensor between the previous time and the current time. In particular embodiments, the user device can be associated with a user who has been authenticated by the subject to receive the analyte data on behalf of the subject.
According to other aspects of the disclosed subject matter, systems and method can include an analyte monitoring device that 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. The one or more processors can be configured to generate sensor data indicative of 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 the subject. The one or more processors can be configured to store the sensor data in the one or more memories. The one or more processors can identify, from the one or more memories, a first subset of the sensor data corresponding to a first time. The one or more processors can prepare a data packet including the identified subset of the sensor data and connection data associated with establishing a communication session with the analyte monitoring device. The one or more processors can cause the communication module to transmit the data packet to one or more user devices within a communication range of the communication module. The one or more processors can receive, through the communication module, a communication session request from a first user device of the one or more user devices. The one or more processors can cause the communication module to transmit a second data packet to the first user device, the second data packet including a second subset of the data corresponding to a second time.
To further advantages and in accordance with the purpose of the disclosed subject matter, as embodied and broadly described, the disclosed subject matter further includes systems and methods for establishing, maintaining, and transmitting data to multiple receiving devices using concurrent communication sessions. Exemplary systems and methods can include an analyte monitoring device for monitoring a subject using an analyte monitoring device. The analyte monitoring device can 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 memories include instructions executable by the one or more processors to configure the one or more processors to perform operations in accordance with the techniques disclose herein. One or more processors of the analyte monitoring device generate sensor data indicative of an analyte level measured by an analyte sensor of the analyte monitoring device. At least a portion of the analyte sensor is transcutaneously positioned in contact with a bodily fluid of the subject. The one or more processors of the analyte monitoring device receive a first request for the sensor data from a first device and a second request for the sensor data from a second device. The one or more processors of the analyte monitoring device select a first subset of the sensor data responsive to the first request. The one or more processors of the analyte monitoring device select a second subset of the sensor data responsive to the second request. The one or more processors of the analyte monitoring device prepare a first data packet including the first subset of the sensor data and a second data packet including the second subset of the sensor data. The one or more processors of the analyte monitoring device cause the 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.
In particular embodiments, prior to 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, through the communication module and from the first device, an acknowledgement signal indicating receipt of the first subset of the sensor data. In particular embodiments, the first request and the second request include criteria for selecting the first subset of the sensor data and the second subset of the sensor data, respectively. In particular embodiments, the one or more processors of the analyte monitoring device select the first subset of the sensor data or the second subset of the sensor data based on a priority level associated with the sensor data. In particular embodiments, the one or more processors of the analyte monitoring device cause the communication module to transmit the first data packet to the first device before causing the communication module to transmit the second data packet to the second device based on the analyte monitoring device receiving the first request for the sensor data before receiving the second request for the second data. In particular embodiments, the first device or the second device is a fitness monitor or fitness device. In particular embodiments, the first device or the second device includes medical components for use by the subject based on the first subset of the sensor data or the second subset of the sensor data. In particular embodiments, the first device or the second device includes networking components to transmit the first subset of the sensor data or the second subset of the sensor data to one or more remote devices. In particular embodiments, the first device is a smartphone and the second device is a smartwatch.
In particular embodiments, the one or more processors of the analyte monitoring device establish, a communication session with the second device through communication with the first device by: receiving, from the first device and via the communication module, a connection request including identification information for the second device and information to facilitate a communication session with the second device, where the identification information was received by the first device from the second device during a communication session between the first device and the second device; transmitting an acknowledgement of the connection request to the second device using the information to facilitate the communication session with the second device; and performing a mutual authentication with the second device to generate a shared encryption key for subsequent communication sessions. In particular embodiments, the first request for the sensor data includes an identifier for 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 particular embodiments, the one or more processors of the analyte monitoring device encrypt the first subset of the sensor data using a first encryption key shared between the analyte monitoring device and the first device and encrypt the second subset of the sensor data using a second encryption key shared between the analyte monitoring device and the second device. In particular embodiments, the first encryption key and second encryption key are dynamically determined or identified using a key-rotation scheme. In particular embodiments, the analyte includes glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, or uric acid.
For purpose of illustration and not limitation, reference is made to the exemplary embodiment of an analyte monitoring system 100 for use with the disclosed subject matter as shown in
As embodied herein, the analyte monitoring system 100 can, additionally or alternatively, include a software or firmware library or application provided to a third-party and incorporated into a multi-purpose hardware device 130 such as a mobile phone, tablet, personal computing device, or other similar computing device capable of communicating with the sensor control device 110 over a communication link. Multi-purpose hardware can further include embedded devices, including, but not limited to insulin pumps or insulin pens, having an embedded library configured to communicate with the sensor control device 110. Multi-purpose device 130 embodying and executing the software library can be referred to as a data receiving device for communicating with the sensor control device 110. As used herein, a data receiving device 120 can refer to a hardware device specifically manufactured for communicating with the sensor control device 110 within the analyte monitoring system 100 whereas a multi-purpose data receiving device 130 refers to a suitably configured hardware device which incorporates the software or firmware library or is executing the application. As used herein, a data communicating device refers to either or both of a data receiving device 120 or a multi-purpose data receiving device 130. It will be understood that the security architecture and design principles discussed herein are equally applicable to any suitably configured system involving a sensor control device 110, a suitably configured data receiving device 120 or multi-purpose data receiving device 130, and other similar components as those described herein. The role of the sensor control device 110 can be defined by the nature of the sensing hardware embodied in the sensor control device 110.
As embodied herein, the sensor control device 110 can include small, individually-packaged disposable devices with a predetermined active use lifetime (e.g., 1 day, 14 days, 30 days, etc.). Sensors 110 can be applied to the skin of the user body and remain adhered over the duration of the sensor lifetime. As embodied herein, sensors 110 can be designed to be selectively removed and remain functional when reapplied.
Although the illustrated embodiments of the analyte monitoring system 100 include only one of each of the sensor control device 110, data receiving device 120, multi-purpose data receiving device 130, user device 140, and remote server 150, this disclosure contemplates the analyte monitoring system 100 incorporate multiples of each component interacting throughout the system. For example, the embodiments disclosed herein include multiple sensors 110 that can be associated with multiple users which are in communication with the remote server 150. Additionally, the remote server is illustrated as a single entity 150, however will be understood that it can encompass multiple networked servers that can be geographically distributed to reduce latency and introduce deliberate redundancy to avoid monitoring system downtime.
For purpose of illustration and not limitation, reference is made to the exemplary embodiment of a sensor control device 110 for use with the disclosed subject matter as shown in
As embodied herein, as the sensor control device 110 is designed to be power-efficient, low-cost, and possibly disposable, the ASIC 200 can include a microcontroller core 210, on-board memory 220, and storage memory 230. The storage memory 230 can store data used in an authentication and encryption security architecture. The data can have various elements and uses, including as described in the examples herein. The ASIC 200 can receive power from a power module 250, such as an on-board battery or from an NFC pulse. The power module 250 can store only a relatively small charge. As embodied herein, the sensor control device 110 can be a disposable device with a predetermined life span, and without wide-area network communication capability. As embodied herein, the communication module 240 can provide for communication under battery power.
The microcontroller 210 further includes timing control circuitry 211 used, among other things, to wake the sensor control device 110 from a sleep state. The timing control circuitry 211 can include a clock for synchronizing the timing of advertising or connection events and for entering a sleep state between the advertising or connection events. The clock can determine when the sensor control device 110 should wake up next after processing the advertising or connection events before going to sleep. The timing circuitry 211 can then set an event to wake up in time for the next advertising or connection events. Additionally, the microcontroller 210 can include a startup module 212. The startup module can include program instructions saved in ROM that, when executed, are utilized to control modules within the sensor control device 110, such as the memory 220, communication module 240, and the like. Additionally or alternatively, the startup module 212 can 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 the applications or other individual functions that run within the sensor control device 110. Additionally or alternatively, the operating system module 213 can be located on another circuit. The sensor control device 110 can include a protocol stack 230, which can include a controller and a host, each containing various communication layers. The protocol stack 230 can include or embody the operations for the sensor control device 110 to communicate with other device using one or more communication protocols. Additionally or alternatively, the protocol stack 230 can be located on another circuit within the sensor control device 110 such as within the communication module 240.
Although this disclosure is described with respect to exemplary configurations of the sensor control device 110 and the ASIC 200, other suitable configurations are envisioned. As an example, processing hardware of the sensor control device 110 can be implemented as another type of special-purpose processor, such as a field programmable gate array (FPGA). As embodied herein, the processing hardware of the sensor control device 110 can include a general-purpose processing unit (e.g., a CPU) or another programmable processor that is temporarily configured by software to execute the functions of the sensor control device 110. More generally, the processing hardware can be implemented using hardware, firmware, software, or a suitable combination of hardware, firmware, and software. For purpose of illustration and not limitation, the processing hardware of the sensor control device 110 can be defined by one or more factors including computational capability, power capacity, memory capacity, availability of a network connection, etc.
As embodied herein, the communication module 240 of the sensor 100 can be or include one or more modules to support the sensor control device 110 communicating with other devices of the analyte monitoring system 100. In certain embodiments, the sensor control device 110 can communicate, for example, with a data receiving device 120 or user device 140. The communication module 240 can include, for example, a cellular radio module. The cellular radio module can include one or more radio transceivers and/or chipsets for communicating using broadband cellular networks, 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 the remote devices (e.g., remote server 150) to provide analyte data (e.g., sensor readings) and can receive updates or alerts for the user.
As another example, the communication module 240 can include a BLE module 241 and/or an NFC module to facilitate communication with a data receiving device 120 or user device 140 acting as an NFC scanner or BLE endpoint. As used throughout this disclosure, Bluetooth Low Energy (“BLE”) refers to a short-range communication protocol optimized to make pairing of Bluetooth devices simple for end users. The communication module 240 can include additional or alternative chipsets for use with similar short-range communication schemes, such as a personal area network according to IEEE 802.15 protocols, IEEE 802.11 protocols, infrared communications according to the Infrared Data Association standards (IrDA), etc. The communication module 240 can transmit and receive data and commands via interaction with similarly-capable communication modules of a data receiving device 120 or user device 140. Certain communication chipsets can be embedded in the ASIC 200 (e.g., an NFC antennae loop). Additionally, although not illustrated, the communication module 240 of the sensor control device 110 can include a radio for communication using a wireless local area network according to one or more of the IEEE 802.11 standards (e.g., 802.11a, 802.11b, 802.11g, 802.11n (aka Wi-Fi 4), 802.11ac (aka Wi-Fi 5), 802.11ax (aka Wi-Fi 6)). The communication module 243 can further include a memory 243 of its own that is coupled with a microcontroller core for the communication module 240 and/or is coupled with the microcontroller core 210 of the ASIC 200 of the sensor control device 110.
The communication module 240 can include communication circuitry, such as an antenna 244, a transceiver 245, memory 243, a processor 246 and a collection of one or more transmit amplifiers and receive amplifiers (shown collectively as amplifiers 247). Although not illustrated, the communication module 240 can include multiple sets of communication circuitry (e.g., one for each supported communication protocol). For brevity, only a single set of the communication circuitry is illustrated. In certain cases, the processor 246 of the communication circuitry can be similar to the microcontroller 210. Optionally, the transceiver 245 can be provided as a single component or a separate transmitter and a separate receiver. The one or more transmit amplifiers 247 are configured to be selectively connected between an output of the transmitter of the transceiver 245 and the antenna 244. The one or more receive amplifiers 247 are configured to be selectively connected between the antenna 244 and an input of the receiver of the transceiver 245.
As explained herein, the transmitter and receiver of the transceiver 245 exhibit certain power and sensitivity limits based on the components and design of a particular implementation, without the addition of transmit or receive amplifiers 247. One or more transmit amplifiers 247 can be provided to be selectively connected between the output of the transmitter in the antenna to boost the transmit power, such as up to 10 dBm. As another example, the receiver of the transceiver 245 can exhibit a receive sensitivity down to −85 dBm when operated alone without the addition of a separate receive amplifier 247. One or more receive amplifiers 247 can be provided to be selectively connected between the antenna 244 and the input of the receiver of the transceiver 245 to boost the receive sensitivity, such as down to −100 dBm.
As explained herein, while the communication module 240 is initialized, the transmitter of the transceiver 245 can transmit advertisement notices (e.g., communication packets comprising at least a payload including information to facilitate the initiation of discovery and a communication session with another device) arranged in complexes, followed by sleep states in accordance with an advertisement interval. The receiver of the transceiver 245 performs scan operations, during a receive window, to scan for connection requests. Connection requests can be sent in response to advertisement notices or independently by other devices. The scan operation, during an individual receive window, can be performed during the same period of time as transmission of the advertisement notices 224 over corresponding advertisement channels. Optionally, the receive window and scan operation can continue after completion of transmission of the advertisement notices. Hence, the scan operation and receive window can temporarily align with the complex of advertisement notices or extend beyond the complex of advertisement notices 224 into the sleep state of the advertisement interval.
As embodied herein a first layer of security for communications between the sensor control device 110 and other devices can be established based on security protocols specified by and integrated in the communication protocols used for the communication (e.g., BLE security protocols, Wi-Fi 5 security protocols). Another layer of security can be based on communication protocols that necessitate close proximity of communicating devices. Furthermore certain packets and/or certain data included within packets can be encrypted while other packets and/or data within packets is otherwise encrypted or not encrypted. As an example, connection data and/or connection packets devoted to establishing communication connections between devices can be largely unencrypted—sensitive analyte data can be encrypted, even if included in a connection packet in order to facilitate discovery by other devices.
Additionally or alternatively, another layer of security can be based on used, by the sensor control device 110 and other devices in communication, of application layer encryption using one or more block ciphers to establish mutual authentication and encryption of other devices in the analyte monitoring system 100. The use of a non-standard encryption design implemented in the application layer has several benefits. One benefit of this approach is that in certain embodiments the user can complete the pairing of a sensor control device 110 and another device with minimal interaction, e.g., using only an NFC scan and without requiring additional input, such as entering a security pin or confirming pairing.
To perform its functionalities, the sensor 100 can further include suitable sensing hardware 260 appropriate to its function. As embodied herein, the sensing hardware 260 can include an analyte sensor transcutaneously or subcutaneously positioned in contact with a bodily fluid of a subject. The analyte sensor can generate sensor data containing values corresponding to levels of one or more analytes within the bodily fluid. Additionally or alternatively, the sensing hardware 260 can include, for example, an autoinjector prescribed to a user for self-administering a drug or other medicament. Accordingly, the sensing hardware 260 can include a mechanism that drives a needle or a plunger of a syringe in order to subcutaneously deliver a drug. The syringe can be pre-filled with the drug and can operate in response to a triggering event. For example, the mechanism can drive the needle into the user and advance the plunger to deliver the drug subcutaneously via the needle.
As embodied herein, the sensor control device 110 can be configured as an on-body injector attachable to a user's body tissue (e.g., skin, organ, muscle, etc.) and 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 embodiments, the sensing hardware 260 or analyte sensor can include, for example, an adhesive or other means for temporarily attaching the sensing hardware 260 to the user's body tissue, a primary container for storing a drug or medicament, a drive mechanism configured to drive or permit the release of a plunger to discharge the drug from the primary container, a trocar (e.g., a solid core needle), a flexible cannula disposed around the trocar, an insertion mechanism configured to insert the trocar and/or flexible cannula into the user and optionally retract the trocar leaving the flexible cannula in the user, a fluid pathway connector configured to establish fluid communication between the primary container and the flexible cannula upon device activation, and an actuator (e.g., a user displaceable button) configured to activate the device. As embodied herein, the on-body injector can be pre-filled and/or pre-loaded.
In addition to mechanical components, the sensing hardware 260 can include electric and/or electronic components. For example, an electronic switch can be coupled to the mechanism. The sensor control device 110 can establish an authenticated communication, receive an encrypted signal, decrypt the signal using the techniques of this disclosure, determine that the signal includes a command to operate the switch, and cause the switch to drive the needle. Thus, the analyte sensor embodied herein can be configured to perform an analyte function using the sensing hardware 260 in response to a remote command.
As embodied herein, the sensing hardware 260 can include a travel sensor and an analog-to-digital converter to generate a digital signal indicative of the distance travelled by the needle or plunger. Upon delivering the medicament, the low-power sensor control device 110 can obtain a reading from the sensor, encrypt the reading using the techniques of this disclosure, and securely report the reading to another device. Additionally or alternatively, the sensor control device 110 can report other measurements or parameters, such as a time at which the medicant was delivered, volume of medicant delivered, any issues encountered while delivering the medicament, etc. The sensor control device 110 can be configured to provide data related to the operation of the sensing hardware 260 to a remote device.
The sensing hardware 260 can be configured to implement any suitable combination of one or more analyte functions and can include one or more sensing components. Sensing components can be configured to detect an operational state of the sensor control device 110 (e.g., unpackaged/ready for administration, sterile barrier removal, contact with user's body tissue, cannula and/or needle insertion, drug delivery initiation, actuator or button displacement, drug delivery completion, plunger position, fluid pathway occlusion, etc.), a condition of the sensor control device 110 or drug contained therein (e.g., temperature, shock or vibration exposure, light exposure, drug color, drug turbidity, drug viscosity, geographic location, spatial orientation, temporal information, ambient air pressure, etc.), and/or physiological information about the user (e.g., body temperature, blood pressure, pulse or heart rate, glucose levels, physical activity or movement, fingerprint detection, etc.). This detected information can be offloaded from the sensor control device 110 to facilitate storage and analysis, for example to a data receiving device 120, multi-purpose data receiving device 130, or remote server 150. As embodied herein, the sensor control device 110 can be configured to both receive encrypted data from other devices and transmit encrypted data to the other devices.
Referring still to
For purpose of illustration and not limitation, reference is made to the exemplary embodiment of a data receiving device 120 for use with the disclosed subject matter as shown in
Certain embodiments of the data receiving device 120 can further include a display 370 for facilitating review of analyte data received from a sensor control device 110 or other device (e.g., user device 140 or remote server 150). The display 370 can be a power-efficient display with a relatively low screen refresh rate to conserve energy use and further reduce the cost of the data receiving device 120. The display 370 can be a low-cost touch screen to receive user input through one or more user interfaces. Although not illustrated, the data receiving device 120 can include separate user interface components (e.g., physical keys, light sensors, microphones, etc.). Power for the components of the data receiving device 120 can be delivered by a power module 350, which as embodied herein can include a rechargeable battery, allowing for sustained operations and continued use. In particular embodiments, the data receiving device 120 or multi-purpose device 130 can be configured without a display and can be used to relay information from the sensor control device 120 to another component or system.
Although illustrated as separate components, in particular embodiments, a processor of the communication module 340 can perform the processing operations ordinarily performed by the microcontroller 310 of the ASIC 300. Therefore, the ASIC 300 can be removed, and memory and other storage added to the communication module to simplify the hardware required of the data receiving device 120.
The communication module 340 can include a BLE 341 module and an NFC module 342. The data receiving device 120 can be configured to wirelessly couple with the sensor control device 110 and transmit commands to and receive data from the sensor control device 110. As embodied herein, the data receiving device 120 can be configured to operate, with respect to the sensor control device 110 as described herein, as an NFC scanner and a BLE end point via specific modules (e.g., BLE module 342 or NFC module 343) of the communication module 340. For example, the data receiving device 120 can issue commands (e.g., activation commands for a data broadcast mode of the sensor; pairing commands to identify the data receiving device 120 with the sensor control device 110) to the sensor control device 110 using a first module of the communication module 340 and receive data from and transmit data to the sensor control device 110 using a second module of the communication module 340.
As embodied herein, the data receiving device 120 can be configured for communication via a Universal Serial Bus (USB) module 345 of the communication module 340. The data receiving device 120 can communicate with a user device 140 for example over 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 the remote server 150 via the user device 140. USB connections can be authenticated on each plug event. Authentication can use, for example, a two-, three-, four, or five-pass design with different keys. The USB system can support a variety of different sets of keys for encryption and authentication. Keys can be aligned with differential roles (clinical, manufacturer, user, etc.). Sensitive commands that can leak security information can trigger authenticated encryption using an authenticated additional keyset.
As another example, the communication module 340 can include, for example, a cellular radio module 344. The cellular radio module 344 can include one or more radio transceivers for communicating using broadband cellular networks, 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 input received from a user (e.g., through one or more user interfaces). Additionally, the communication module 340 of the data receiving device 120 can include a Wi-Fi radio module 343 for communication using a wireless local area network according to one or more of the IEEE 802.11 standards (e.g., 802.11a, 802.11b, 802.11g, 802.11n (aka Wi-Fi 4), 802.11ac (aka Wi-Fi 5), 802.11ax (aka Wi-Fi 6)).
As used throughout this disclosure, Bluetooth Low Energy (“BLE”) refers to a short-range communication protocol optimized to make pairing of Bluetooth devices simple for end users. As described herein, the use of BLE on the sensor control device 110 can optionally not rely on standard BLE implementation of Bluetooth for security but can instead use application layer encryption using one or more block ciphers to establish mutual authentication and encryption. The use of a non-standard encryption design implemented in the application layer has several benefits. One benefit of this approach is that the user can complete the pairing of the sensor control device 110 and data receiving device 120 with only an NFC scan and without involving the user providing additional input, such as entering a security pin or confirming BLE pairing between the data receiving device and the sensor control device 110. Another benefit is that this approach mitigates the potential to allow devices that are not in the immediate proximity of the sensor control device 110 to inadvertently or intentionally pair, at least in part because the information used to support the pairing process is shared via a back-up short-range communication link (e.g., NFC) over a short range instead of over the longer-range BLE channel. Furthermore, as BLE pairing and bonding schemes are not involved, pairing of the sensor control device 110 can avoid implementation issues by chip vendors or vulnerabilities in the BLE specification.
As embodied herein, the on-board storage 330 of the data receiving device 120 can be capable of storing analyte data received from the sensor control device 110 over an extended period of time. Further, the multi-purpose data receiving device 130 or a user computing device 140 as embodied herein can be configured to communicate with a remote server 150 via a wide area network. As embodied herein, the sensor control device 110 can provide sensitive data to the data receiving device 120 or multi-purpose data receiving device 130. The data receiving device 120 can transmit the sensitive data to the user computing device 140. The user computing device 140 (or the multi-purpose data receiving device 130) can in turn transmit that data to a remote server 150 for processing and analysis. In communicating with the remote server 150, multi-purpose data receiving device 130 and user computing device 140 can generate unique user tokens according to authentication credentials entered by a user and stored at the respective device. The authentication credentials can be used to establish a secure connection to the remote server 150 and can be further used to encrypt any sensitive data provided to the remote server 150 as appropriate. As embodied herein multi-purpose data receiving device 130 and user computing device 140 can optionally not be as restricted in their use of processing power, and therefore, standard data encryption and transmission techniques can be used in transmitted to the remote server 150.
As embodied herein, the data receiving device 120 can further include sensing hardware 360 similar to, or expanded from, the sensing hardware 260 of the sensor control device 110. As an example only, and not by way of limitation, in an embodiment in which 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 can be configured with a blood glucose meter, compatible for use with blood glucose test strips, thus expanding on the blood glucose monitoring of the sensor control device 110. In particular embodiments, the compatible device 130 can 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, where the sensor control device 110 glucose sensor, the compatible device 130 can be or include an insulin pump or insulin injection pen. In coordination, the compatible device 130 can adjust an insulin dosage for a user based on glucose values received from the analyte sensor.
Additionally or alternatively, as embodied herein, the packet header 405 can include information signifying that the packet 400 originated from a sensor control device 110. The packet 400 can indicate the manufacturer of the sensor control device 110. In particular embodiments, the amount and extent of identifying information included in the packet header 405 can be selected in order to ensure that the payload 410 can be interpreted by receiving devices while still preserving the security of the identity of the subject, the identity of the sensor control device 110, the analyte data included in the packet, etc.
Referring still to
In particular embodiments, the payload 410 can include connection data 420. The connection data 420, can include a set of parameters to facilitate a receiving device establishing a connection with the sensor control device 110. For example, the connection data 420 can include information detailing the connection procedure expected by the sensor control device 110. The connection procedure can include an encoding scheme that will be used by the sensor control device 110. In particular embodiments the connection data 420 can include an identifier for the sensor control device 110 and/or for the device the sensor control device 110 intends to connect with, if known. As an example only and not limitation, the identifier can include a unique device identifier, an identifier associated with the communication protocol (e.g., a Bluetooth identifier or BLE identifier), an identifier associated with 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., the communication protocol compatible with the communication module 240 of the sensor control device 110) supports the use of multiple communication channels and/or channel hopping, the connection data can include information for the receiving device to initiate a communication session accordingly. In particular embodiments, the packet 400 can be configured to appear as a data packet or advertising packet conforming to an established communication protocol or standard supported by the communication module 240 of the sensor control device 110. For example, to facilitate wide compatibility with the sensor control device 110, the sensor control device 110 can use one or more connection-facilitating or advertising data formats as specified by the communication protocol. The connection data 420 included in the payload 410 can be configured according to those formats.
In particular embodiments, the payload 410 can further include analyte data 425. As described herein, the sensor control device 110 can include sensing hardware 260, which can include one or more sensors. The analyte data 425 can include data received from one or more of the sensors. As an example, and not limitation, the data can include raw data from one or more components of the sensing hardware 260 (e.g., a signal value read from an analog-to-digital converter), data used to process raw data from the components of the sensing hardware 260 (e.g., a temperature level, noise level, etc.), data that has been processed by the sensor control device 110 into another usable format (e.g., human-readable data), etc. The data can further include derivative values calculated from the sensor data, such as calculated rates of changes, trending values, projected values, etc. Additionally or alternatively, the sensing hardware 260 can include components to deliver a therapy to the subject analyte data. For example, the sensor control device 110 can include an insulin pump and the sensing hardware 260 can include hardware to inject an amount of insulin. The analyte data 425 can include information relating to the therapy delivered, including, but not limited to, the frequency of therapy, the cumulative amount or effect of the therapy delivered, the remaining capability of the sensing hardware 260 to deliver the therapy, the time the therapy was most recently delivered, etc.
In particular embodiments, the payload 410 can further include an integrity check value 430. The integrity check value 430 can be a value computed or derived from the data included in the payload 410 or packet 400 that can serve as an way for a receiving device to efficiently determine whether the data in the payload 410 has been intentionally or unintentionally modified during transmission, encryption/decryption, etc. As described, the data stored in the payload 410 can include analyte data 425 or other sensitive data of the subject. Especially where the data can be used to generate alerts or inform diagnoses regarding the health of the subject, ensuring the integrity of the data is an important feature of the analyte monitoring system 100. In particular embodiments, when a 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 can compare to the value of the integrity check value 430 to a counterpart check value 430. If the received integrity check value 430 does not correspond to the counterpart check value 430, the receiving device can disregard the payload 410 or inform the sensor control device 110, subject, or user of the receiving device of a possible error. In particular embodiments, the counterpart check value can include a value calculated by the received device after receiving the packet 400 using the same algorithm or formula and input data as would have been used by the sensor control device 110 in preparing the integrity check value 430 prior to transmission. As an example and not limitation, the integrity check value 430 can include an error detection code with a size determined based on the size of the payload 410 and/or the packet 400. As another example and not limitation, the integrity check value 430 can include a checksum or other cryptographic hash value derived from the data in the payload 410 or packet 430.
The packet 400 can include other values not shown in
In particular embodiments, some or all of the data included in the data payload 410 can be encrypted. For example, the entirety of the payload 410 can be encrypted, the data included in the payload 410 besides the payload header 415 can be encrypted, only the analyte data 425 or the connection data 420 can be encrypted, etc. In particular embodiments, the sensor control device 110 can encrypt the appropriate data prior to preparing the payload 410 and packet 400. As described herein, encryption performed by the sensor control device 110 can be informed by balancing the computational complexity of a cipher with the lower-cost components used in the sensor control device 110.
At 505, the sensor control device 110 can collect analyte data from a subject. As described herein, the sensor control device 110 can include sensing hardware that is useful for monitoring the health status of the subject (e.g., the wearer of the sensor control device 110). In particular embodiments, the sensing hardware can include an analyte sensor for measuring the levels of an analyte (e.g., glucose, lactate, oxygen, etc.) in a bodily fluid of the subject (e.g., blood, sweat, extracellular or interstitial fluid, etc.). In particular embodiments, the sensing hardware can include a temperature sensor, an activity or motion sensor, a heart rate sensor, or other sensing hardware. The sensor control device 110 can receive input from the sensing hardware (e.g., analyte sensor, temperature sensor, etc.) in a streaming manner that can include or correspond to a health feature or status of the subject (e.g., levels of the analyte, blood or skin temperature, etc.). In particular embodiments, the input from the sensing hardware can be processed by the analyte sensor. The input can be temporarily stored into a memory of the sensor control device 110 (e.g., a volatile memory or RAM of an ASIC or other control unit). As described, the sensor control device 110 can be a relatively low-cost sensor control device 110 that may lack significant computing power, storage, or output capabilities (e.g., to output information relating to the analyte data). The sensor control device 110 can therefore offload the received data, after it has been stored in the memory of the sensor control device 110, to another device, e.g., for further processing or display.
At 510, the sensor control device 110 can determine an operating mode of the sensor control device 110 relating, as described herein, to the preparation and broadcast of different categories or types of packets that include corresponding categories or types of payloads. In particular, the sensor control device 110 can periodically broadcast data from the sensing hardware and/or information to facilitate a connection between the sensor control device 110 and a receiving device (e.g., data receiving device 120, multi-purpose data receiving device 130, or user device 140). The sensor control device 110 can prepare and broadcast a packet, e.g., packet 400, including selected data. As an example, the sensor control device 110 can prepare and broadcast the packet once every second, once every two seconds, once every 5 seconds, etc. As embodied herein, the sensor control device 110 can select which information to include in the packet. For example, the sensor control device 110 can select which information to include on a periodic basis (e.g., packets with connection data are split evenly between packets with analyte data, packets with analyte data five times for every packet with connection data, a pattern of 50 packets with analyte data followed by 5 packets of connection data, etc.). The sensor control device 110 can select which information to include based on the last time the sensor control device 110 connected with a receiving device or offloaded data included in the memory of the analyte sensor to a receiving device, the amount of battery life remaining or term of usefulness of the sensor control device 110, etc.
If, at 510, the sensor control device 110 determines that it is operating in an informational packet mode, then at 515, the sensor control device 110 identifies analyte data for inclusion in the data packet. The analyte sensor can select analyte data from the memory of the sensor control device 110 for inclusion in the packet. In particular embodiments, the amount of space available in the packet (e.g., in the payload 410 of the packet 400) can be adjusted in order to reduce the computational cost of preparing and sending the packet frequently and reduce the chance that only a portion of the packet can be received by a receiving device. Therefore, a subset of the analyte data stored by the sensor control device 110 can be identified for inclusion in the packet.
In particular embodiments, the sensor control device 110 can use a prioritization scheme to determine which analyte data to include in the packet. The sensor control device 110 can determine a priority level for analyte data and select data for inclusion in the packet based on the priority level. As an example, the priority level can relate to an age of the analyte data (e.g., a time since the analyte data was collected). In particular embodiments, the sensor control device 110 can set the highest priority level for the most recently collected data to ensure that, if the receiving device receives the packet and outputs the analyte data, the user of the receiving device can see the most recent or current analyte data. As another example, the sensor control device 110 can set the highest priority level for the severity or urgency of the analyte data. For example, the analyte data can include levels of an analyte in a fluid of the subject. The levels of the analyte can be associated with one or more thresholds that indicate, for example, a range of safe levels, levels that are higher or lower than is determined to be safe, levels that are dangerously high or low, etc. The priority levels of analyte data can be determined by comparing the analyte data to the one or more thresholds. Then, if the receiving device receives the packet and outputs the analyte data, the user of the receiving device can receive the most urgent or critical data. One more prioritization schemes can be used together. For example, all analyte data of the same urgency priority level can be ordered according to the age of the analyte data.
At 520, the sensor control device 110 can encrypt the analyte data identified for inclusion in the data packet. As described herein, the analyte data can include sensitive information about the health or identity of the subject. To protect the sensitive information, the sensor control device 110 can use one or more block ciphers or other encryption schemes to encrypt the analyte data. In particular embodiments, the sensor control device 110 can use, as an encryption key, a private key stored by the sensor control device 110. As described herein, user devices that are configured (and optionally authorized) to receive and process the analyte data from the subject, can be provided a public key, related to the private key of the sensor control device 110 to decrypt the data upon receipt. In embodiments where the sensor control device 110 and receiving device have been identified to each other (e.g., where the sensor control device 110 and receiving device have previously established a communication session or the receiving device issued an activation command to the sensor control device 110), the sensor control device 110 and receiving device can agree on a encryption key to use for subsequent iterations of the process. In particular embodiments, the encryption key can be dynamically generated, for example, based on a device secret or private value and a deterministically-changing value (e.g., a monotonically-increasing value or a timestamp). The receiving device can use the same device secret and deterministically-changing value to calculate a decryption key. In particular embodiments, the encryption key can be selected using a key-rotation scheme.
As embodied herein, the public keys shared by the sensor control device 110 and receiving devices can be established through the use of multi-step processes 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 an authentic sensor compatible with the receiving device and that the receiving device is approved to receive data from the sensor control device 110. For example, the receiving device can provide, to the sensor control device 110, a valid certificate or token that has been digital signed by the manufacturer of the sensor control device 110 or receiving device or the operator of the analyte monitoring system 100. The certificate or token can be validated by confirming that it has been digitally signed using a key associated with the appropriate manufacturer or operator. Similarly, the sensor control device 110 can provide, to the receiving device, a valid certificate or token that has similar 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 offering the certificate or token. The private key can also be established by the appropriate manufacturer or operator of the analyte monitoring system. Once a validated certificate or token is received, the device that offers the certificate or token can also prove that it has control of the private key. Proof of control can be established by decrypting selected information (e.g., a randomized or non-sequential value) that was encrypted using the public key included in the validated certificate. That information can be used to generate a shared symmetric authentication key which can be used for subsequent authentication and encryption.
If, at 510, the analyte sensor determines that it is operating in a connectable packet mode or a non-informational 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 can include data to facilitate a receiving device requesting and opening a communication session with the sensor control device 110. The connection data 525 can include data specifying the protocol that can be used by the sensor control device 110 to accept communication session requests.
In particular embodiments, the sensor control device 110 can include either one or both of the connection data and analyte data in a single packet, e.g., while operating in a mixed packet mode (not illustrated in
At 530, the sensor control device 110 can prepare a data packet for broadcast. Depending on the operating mode determined at 510, the data packet can include analyte data, connection data, or other data. The sensor control device 110 can prepare the selected data into a payload by arranging the collected data into a predetermined format that can be interpreted by a receiving device. The sensor control device 110 can prepare a header for the payload that provides information to the receiving device so that it can determine how to interpret the payload. The sensor control device 110 can validate the payload, such as by preparing one or more integrity check values for the payload. The sensor control device 110 can prepare a header for the data packet which includes the payload to facilitate receiving devices in the environment of the sensor control device 110 that are not configured to interpret the payload 110 in determining whether or not it will be able to use the data in the packet. In particular embodiments, such as where the sensor control device 110 has been previously paired with a receiving device, as described herein, the header of the data packet can include identification data for the receiving device to direct the data packet to the receiving device.
At 535, the sensor control device 110 can broadcast the data packet into an environment of the analyte sensor and/or transmit the data packet to one or more receiving devices within a communication range of the analyte sensor using a communication module of the analyte sensor. The environment can include multiple receiving devices (e.g., data receiving devices 120, multi-purpose data receiving device 130, user devices 140, etc.). Broadcasting can involve causing one or more transceivers (e.g., 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 that are specified by the communication protocol used by the communication module. The signal can be undirected, or not directed towards a particular receiving device in the environment. The communication channels can be reserved specifically for broadcast packets that can include connection information to facilitate the discovery and establishing of communication sessions between device.
At 540, for a determined period of time after broadcasting the data packet into the environment, the sensor control device 110 can wait to receive an acknowledgement signal from a user device in the environment. As described herein, the environment of the sensor control device 110 can include multiple receiving devices. Each of the receiving devices can receive the signal including the packet broadcast by the sensor control device 110. Each receiving device can attempt to process the packet to determine whether it can or should use the data of the packet. For example, a receiving device can analyze the header of the data packet to determine if the data packet is directed to it or is undirected. If the data packet is not directed to another device, the receiving device can attempt to read the payload, for example, according to protocols set out in the header of the data packet. Where the payload is encrypted, the receiving device can 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 can decrypt the payload and process the data included therein. For example, if the data of the payload includes analyte data, the receiving device can extract the analyte data for the subject from the decrypted data payload, process the extracted analyte data if needed, 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 alerts or alarms based on the analyte data, upload the analyte data to a remote server, etc.). While outputting the extracted analyte data, the receiving device can indicate that the analyte data corresponds to highest priority data (e.g., most recently collected data, most urgent data according to the condition of the user, etc.).
After processing the data packet and payload, the receiving device can attempt to transmit an acknowledgement 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 did not include connection data, the receiving device can broadcast an undirected packet that includes information interpretable by the sensor control device 110. The undirected packet can include an encrypted payload, encrypted using the shared encryption key or scheme, that includes information for the sensor control device 110 to confirm that the payload has been received. As another example, if the payload did include connection data, the receiving device can attempt to send the acknowledgement signal with a connection request, for example, using the connection protocol specified by the connection data.
If, at 540, the sensor control device 110 receives an acknowledgement signal during the period of time during which the sensor control device 110 is open to receiving the acknowledgement signal, the sensor control device 110 can take further action based on the acknowledgement signal. For example, and as illustrated, at 545, the sensor control device 110 can establish a communication session with the receiving device from which the acknowledgement signal was received. Establishing the communication session can include employing a multi-step device authentication and handshake, which can re-use the shared encryption key, and, additionally or alternatively, can use an additional communication session key to encrypt data exchanged between the sensor control device 110 and receiving device in transmission.
At 550, the sensor control device 110 can use the communication session to backfill analyte data with the receiving device. For example, the sensor control device 110 can use the communication session to offload analyte data stored by the analyte sensor that has not previously been offloaded 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 periodically, such as once per minute over a lifespan of the sensor control device 110. The sensor control device 110 can be disconnected or out of range from the receiving device. The sensor control device 110 therefore stores an amount of analyte data (e.g., over a predetermined period of time). When the sensor control device 110 reconnects with a receiving device, the analyte sensor can determine which data has not yet been offloaded, prepare that data for transmission over the communication session, and send the data to the receiving device. In particular embodiments, the sensor control device 110 can, for example, delete all analyte data offloaded to a receiving device after it has been sent. Additionally or alternatively, the sensor control device 110 can include sufficient memory to store the analyte data generated during its lifetime, particularly if the sensor control device 110 is designed with a limited term of use. Additionally or alternatively, the sensor control device 110 can preserve analyte data until space is required and overwrite certain segments of data first (e.g., the oldest, lowest priority, or least relevant data can be deleted or overwritten first).
In certain embodiments, the receiving device can determine the data to be backfilled by the sensor control device 110 after the communication session is established by the sensor control device 110. As an example, the receiving device can track the analyte data that has been received over time (e.g., over one or more communication sessions). As another example, the received analyte data can also be stored with a timestamp associated with when the analyte data was generated and/or the date and time associated with the analyte reading that was used to generate the analyte data. As another example, the received analyte data can be stored with a counter value uniquely attributed to a set of analyte data. For example, the counter value can be incremented with each additional reading of analyte data by the sensor control device 110. The receiving device can determine, based on the timestamp and/or counter value that gaps in the stored analyte data are present. The receiving device can request the sensor control device 110 to send the missing data, for example, by specifying the missing timestamp range and/or counter value range. In response, the sensor control device 110 can identify the analyte data corresponding to the timestamp range and/or counter value range and transmit the analyte data to the receiving device. Once all analyte data specified by the range are provided the sensor control device 110 and/or the receiving device, a confirmation that all specified data has been received is provided.
Additionally or alternatively, the sensor control device 110 determines the data to backfill after establishing the communication session. When identifying the analyte data to backfill, the sensor control device 110 can offload all stored data besides the highest priority data (which was included in the broadcast data packet). As another example, the analyte sensor can store a timestamp of the last time analyte data was offload from the sensor control device 110. The analyte sensor can identify analyte data records between that timestamp and a current timestamp and transmit the identified analyte data. In particular embodiments, the backfill procedure can also use a data prioritization scheme (e.g., first in first out; last in first out; highest priority, most severe, other prioritization scheme, or a combination thereof).
As embodied herein, the sensor control device 110 can maintain a record for the time elapsed since the sensor control device 110 has received an acknowledgement signal from the user device and/or a time elapsed since a successful communication session has been completed. As an example, the sensor control device 110 can associate a timestamp with an acknowledgment signal and upon receiving an acknowledgement signal, update the timestamp accordingly. Additionally, or alternatively, the sensor control device 110 can maintain other records indicative of the status of the analyte data stored on the sensor control device 110 and of the communication history between the sensor control device 110 and the receiving device. As an example, the sensor control device 110 can include a record of the time since the last communication session, the oldest analyte data record stored on the analyte sensor, etc. After the communication session is closed, the sensor control device 110 can update the record associated with the time since the last communication session. Note that the sensor control device 110 can store separate timestamps associated with acknowledgement signals and with communication sessions. By maintaining two timestamps (or other records indicative of the communication 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 completeness of the data offloaded from the sensor control device 110. As described herein, the indication, or lack, of presence of the receiving device in the environment can be used by the sensor control device 110 to alter its behavior to attempt to facilitate a connection.
If, at 540, the analyte sensor determines that it has not received an acknowledgement from a receiving device, the sensor control device 110 can, at 555, determine whether the time since the sensor control device 110 last received an acknowledgement satisfies a threshold time. Additionally or alternatively, sensor control device 110 can determine whether a time since the last communication session or the age of the latest analyte record received satisfies a threshold. Other metrics can also be used to determine whether the sensor control device 110 should alter its behavior to attempt to facilitate a connection. The metrics can indicate, for example, that there is a connection issue between the sensor control device 110 and receiving device, that the sensor control device 110 and receiving device have not been 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 embodiments where connection data is included in only a subset of the packets sent by the sensor control device 110, the inability to receive an acknowledgement signal can be a function of the sensor control device 110 and receiving device not being within a requisite range at the appropriate time (e.g., when a packet including connection data is being broadcast).
If, at 555, the sensor control device 110 determines that the time since the last acknowledgement or communication session does exceed the threshold, or other indicia of a potential communication issue are present, at 560, the sensor control device 110 can be configured to alter its discoverability behavior to attempt to increase the probability of the receiving device receiving an appropriate data packet and/or provide an acknowledgement signal or otherwise reduce restrictions that can be causing an inability to receive an acknowledgement signal. Altering the discoverability behavior of the sensor control device 110 can include, for example and without limitation, altering the frequency at which connection data is included the data packet, altering how frequently data packets are transmitted generally, lengthening or shortening the broadcast window for data packets, altering the amount of time that the sensor control device 110 listens for acknowledgement signals after broadcasting, including directed transmissions to one or more devices (e.g., through one or more attempted transmissions) that have previously communicated with the sensor control device 110 and/or to one or more devices on a whitelist of known or authorized devices, altering a transmission power associated with the communication module when broadcasting the data packets (e.g., to increase the range of the broadcast or decrease energy consumed and extend the life of the battery of the analyte sensor), altering the rate of preparing and broadcasting data packets, or a combination of one or more other alterations. Additionally, or alternatively, the receiving device can similarly adjust parameters relating to the listening behavior of the device to increase the likelihood of receiving a data packet including connection data. For example, after a threshold period of time elapses in which the receiving device does not receive a data packet, the receiving device can increase the amount of time or the frequency that the communication hardware of the receiving device is active and capable of receiving connection data (e.g., increasing the window of performing scans for data packets, in particular data packets including connection data). The sensor control device 110 and receiving device can revert back to original settings if the attempts to increase discoverability are not successful after a specific period of time.
As embodied 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 be actively transmitting data packets (e.g., broadcasting). As an example, the first window can 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 period. The second window can indicate that, during each 2 second window, the sensor control device 110 transmits a data packet every 60 milliseconds. The rest of the time during the 2 second window, the sensor control device 110 is listening. The sensor control device 110 can lengthen or shorten either window to modify the discoverability behavior of the sensor control device 110. For example, the 2 second window can be expanded to 4 seconds (e.g., the first 4 seconds in each 60 second period) or shortened to 1 second (e.g., the first second in each 60 second period). As another example, the second period can be lengthened (e.g., to conserve 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 while a receiving device is in range). As another example, the period can be lengthened or shortened.
In particular embodiments, the discoverability behavior of the analyte sensor can be stored in a discoverability profile, and alterations can be made based on one or more factors, such as the status of the sensor control device 110 and/or by applying rules based on the status of the sensor control device 110. For example, when the battery level of the sensor control device 110 is below a certain amount, the rules can cause the sensor control device 110 to decrease the power consumed by the broadcast process. As another example, 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 communication hardware of the sensor control device 110. For example, when the temperature of the sensor control device 110 or communication hardware thereof reaches a first threshold temperature (e.g., falls below the threshold or alternatively exceeds the threshold), the transmission power associated with the broadcast process can be lowered. Additionally, when the temperature reaches a second threshold temperature, the process of transmitting packets including connection data (e.g., advertising data packets) can be paused altogether. The process can be restarting and/or the transmission power can be adjusted after the temperature reverts to satisfy another threshold. In addition to modifying the transmission power, other parameters associated with the transmission capabilities or processes of the communication hardware of the sensor control device 110 can 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 is about to be, experiencing a negative health event, the rules can cause the sensor control device 110 to increase its discoverability to alert the receiving device of the negative health event. As the process 500 repeats multiple times, and can repeat throughout the operative life of the sensor control device 110, alterations made to device discoverability can be propagated and affect future iterations of process 500.
If, at 555, the sensor control device 110 determines that the time since last acknowledgement does not exceed the threshold, or that other indicia of a communication issue are not present, the analyte sensor returns to 505 where analyte data 110 continues to be collected and process 500 is repeated.
In particular embodiments, the sensor control device 110 can receive an activation command from a particular user device. In particular embodiments, the activation command can be received over a first communication interface (e.g., NFC), while the sensor control device 110 can broadcast packets over a second communication interface (e.g., BLE). The activation command can be received prior to the sensor control device 110 beginning to collect analyte data, prior to the analyte sensor broadcasting data, or at any point during the process 500. The activation command can be used by the sensor control device 110 and receiving device to affirmatively identify each device to the other. The activation command can include instructions relating to the broadcast or discoverability behavior of the sensor control device 110. The instructions can 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 the packets are directed to the particular user device or broadcast into the environment external to the analyte sensor, or other related parameters of the sensor control device 110 performing the process 500 illustrated in
As an example, a subject (or user of a receiving device) can instruct the receiving device to send an activation command to the sensor control device 110 to cause the analyte sensor to enter a broadcast mode where current analyte data is sent via data packets according to the embodiments disclosed herein. The sensor control device 110 can continue operating in the broadcast mode for a fixed or specified amount of time or until the sensor control device 110 receives a deactivation command. As an example, an athlete running around a track can be wearing a sensor control device 110 and desire for analyte data to be sent to a receiving device that is kept substantially stationary around the track (e.g., being held by a coach or other observer). In an ordinary (e.g., non-broadcast) mode, the sensor control device 110 cannot establish a communication session with the receiving device to send pertinent analyte data to be output by the receiving device. Prior to the athlete beginning to run around the track, the athlete can cause the receiving device to issue an activation command to the sensor control device 110 to initiate the broadcast mode and identify the receiving device. Then, while the athlete runs around the track, the sensor control device 110 can broadcast analyte data to be received by the receiving device. The receiving device can process the analyte data, output current analyte data, issue alerts as to the health of the athlete using the embodiments disclosed herein to quickly send the highest-priority analyte data.
By inserting the analyte data into a data packet that is broadcast on or with communication channels ordinarily used only for the discovery and establishing of communication sessions, the sensor control device 110, as embodied herein, can increase the speed and reliability that high priority or current analyte data is delivered to a user of a receiving device. Rather than waiting for a communication session to be established and the appropriate data to be offloaded from the sensor control device 110 to the receiving device, the sensor control device 110 and receiving device can exchange the most relevant data first and allow the user of the receiving device to review the most relevant data while the rest of the data stored on the sensor control device 110 is offloaded. Thus, in addition to increasing the actual speed of delivery of the most relevant data, the user's perception of the speed of delivery of the rest of the data is also improved.
According to aspects of the disclosed subject matter, and as embodied herein, a sensor control device 110 can be configured to communicate with multiple devices concurrently by adapting the features of a communication protocol or medium supported by the hardware and radios of the sensor control device 110. As an example, the BLE module 241 of the communication module 240 can be provided with software or firmware to enable multiple concurrent connections between the sensor control device 110 as a central device and the other devices as peripheral devices, or as a peripheral device where another device is a central device. Although examples described herein reference BLE terminology, this is to balance brevity with a complete explanation of the techniques of this disclosure and should not be interpreted as a limiting to only a particular technology protocol or standard.
Connections, and ensuing communication sessions, between two devices using a communication protocol such as BLE can be characterized by a similar physical channel operated between the two devices (e.g., a sensor control device 110 and data receiving device 120). The physical channel can include a single channel or a series of channels, including for example and without limitation using an agreed upon series of channels determined by a common clock and channel- or frequency-hopping sequence. The common clock can be governed by a hardware clock of a controlling device in the pair. The channel- or frequency-hopping sequence can be determined based on unique attributes of one or more devices of the communication session, such as an identifier for the device (e.g., unique identifier, BLE identifier, etc.). Communication sessions can use a similar amount of the available communication spectrum, and multiple such communication sessions can exist in proximity. In certain embodiment, each collection of devices in a communication session uses a different physical channel or series of channels, to manage interference of devices in the same proximity. In certain embodiments, devices in the same proximity can share a channel through channel multiplexing schemes, such as those based on code-division or time-division algorithms.
To participate in multiple concurrent communication sessions, a BLE device, such as a sensor control device 110 and data receiving device 120 or multi-purpose data receiving device 130 switches between channels on a time-division multiplexing basis. In certain embodiments, to avoid collisions, a device can be prevented from controlling multiple communication sessions concurrency. In addition to being classified as controlling or participating devices in a communication session, devices can be categorized as advertisers or scanners. Advertisers are devices that invite connections with other devices by broadcasting connection packets on common communication channels. Devices that are able to interpret the connection packets can initiate communications with the advertiser. Scanners are devices that listen for connection packets transmitted by advertisers.
The data receiving device 125a can assist one or more of the sensor control device 110 and data receiving device 125b with preparing requests for the other device and responding to requests issued by the other device. As an example, the data receiving device 125a can receive a request from the data receiving device 125b for the sensor control device 110 and interpret or translate the request into a format usable by the sensor control device 110. In translating the request for the sensor control device 110 on behalf of the data receiving device 125b, the data receiving device 125a acting as a router for the requests can enable the sensor control device 110 and data receiving device 125b to operate more efficiently or expand their functionalities with minimal additional overhead. Additionally, the data receiving device 125a can present a device-agnostic interface for both devices, increasing the interoperability of the sensor control device 110 and data receiving device 125b.
In particular embodiments, one or more of sensor control device 110 and data receiving device 125b are not aware of the other device in the environment 600. For example, the sensor control device 110 can provide output data to the data receiving device 125a as part of normal operations. The data receiving device 125b can request access to data corresponding to output from the sensor control device 110. However, the data receiving device 125b can request the data without knowing the origin of the data, such as the identity of sensor control device 110 in the environment 610. This arrangement can be advantageous where, for example, data receiving device 125a is a central hub or common device to systems involving the sensor control device 110 and data receiving device 125a and sensor control device 110 and data receiving device 125b. Furthermore, through this system, the privacy and security of the user and other potential users of the sensor control device 110 and data receiving device 125b can be protected because the identity of the device can be protected. Even if the sensor control device 110 and data receiving device 125b are aware of the other device, data receiving device 125a can process output and data from sensor control device 110 on behalf of data receiving device 125b. For example, the sensor control device 110 can output raw values to the data receiving device 125a and data receiving device 125a can apply one or more algorithms to the data so that it can more effectively be used by data receiving device 125b. Additionally, the data receiving device 125a can generate data or instructions for display by data receiving device 125b. As an example, data receiving device 125a can generate instructions to modify a user interface of data receiving device 125b based on data from sensor control device 110. In such an example, data receiving device 125b does not directly access the data from sensor control device 110, but instead accesses the user interface instructions or passes the data directly through to the user interface for review by a user.
In particular embodiments, the sensor control device 110 identifies the device that has issued a request based on the communication medium of the request. For example, the sensor control device 110 and data receiving device 125a can have agreed upon use of a particular communication channel for the sensor control device 110 to receive requests and the sensor control device 110 and data receiving device 125b can have agreed upon use of a different communication channel or the sensor control device 110 to receive requests. Then, the sensor control device 110 can assume that a request received on the particular communication channel is from the data receiving device 125a. In particular embodiments, the sensor control device 110 identifies the device that has issued a request based on the request itself. For example, the request can include information to identify the device that has issued the request. A request from the data receiving device 125a can include a unique identifier for the data receiving device 125a while a request from the data receiving device 125b can include a unique identifier for the data receiving device 125b. Upon receiving the request, the sensor control device 110 reviews the information provided in the request to identify the device that has 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 the data receiving device 125a and data receiving device 125b can avoid including plaintext identifiers. As an example, during an initiation stage of a pairing between the sensor control device 110 and data receiving device 125a, the sensor control device 110 and data receiving device 125a can agree on an identifier for the data receiving device 125a or a scheme for determining an identifier for the data receiving device 125a. Upon receiving a request, the sensor control device 110 can reference the mapping to positively determine that the data receiving device 125a has issued the request. A third party without access to the mapping would be unable to determine the identity of the data receiving device 125a.
At 705, the data receiving device 125a and sensor control device 110 establish a connection or communication session. In particular embodiments, the sensor control device 110 and 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 though a pairing process supported by the communication protocol. As an example, the sensor control device 110 can be configured to periodically broadcast connection packets to facilitate other devices discovering and connecting to the sensor control device 110. The data receiving device 125a can receive a connection packet and, using the information contained therein, 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 the communication session between the sensor control device 110 and data receiving device 125a. For example, the data receiving device 125a can, upon being brought within a suitably close range, initiate an NFC communication session to exchange information allow the sensor control device 110 and data receiving device 125a to pair and mutually authenticate.
At 710, the data receiving device 125a and data receiving device 125b establish a connection or communication session. For purpose of illustration and not limitation, as described herein, the data receiving device 125a and data receiving device 125b can be different instances of the same kind of data receiving device (e.g., two data receiving devices comprising a multi-purpose data receiving device 130 configured with a downloaded library or software application), two separate data receiving devices owned by the same user (e.g., a multi-purpose data receiving device 130 and a smartwatch), two separate data receiving devices owned by a user wearing the sensor control device 110 and by an authorized monitor such as a parent, coach, or medical caretaker, a data receiving device for monitoring the output of the sensor control device 110 and a data receiving device for acting based on the output of the sensor control device 110, such as a connected medical device like an insulin pump or pen, or a connected exercise equipment like a treadmill, fitness bike, or a variety of other suitable combinations. The data receiving device 125a and data receiving device 125b can communicate using one or more short- or medium-range communication protocols.
At 715, the data receiving device 125b receives a request to connect with the sensor control device 110. The request to connect with the sensor control device 110 can be initiated by a user of the data receiving device 125b. The request can indicate that that 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 sensor control device 110 to enable additional functionality of the data receiving device 125b. In some embodiments, the request can be initiated automatically in response to a 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 is unable to connect directly with the sensor control device 110 and must use an existing connection between the data receiving device 125a and sensor control device 110 to establish the connection with the sensor control device 110.
At 720, the data receiving device 125b sends a connection request to the data receiving device 125a. In response to determining that it will use the existing connection between the data receiving device 125a and sensor control device 110 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 can include in the request information identifying the data receiving device 125b (e.g., an address of the data receiving device 125b, a BLE handle for the data receiving device 125b), the user of the data receiving device 125b, or the sensor control device 110 (e.g., a unique identifier for the user, or a public authentication key prepared by or for the data receiving device 125b or sensor control device 110), information identifying how the sensor control device 110 and data receiving device 125b will initiate the connection (e.g., a communication channel or channel-hopping protocol to be used by the devices), and other information to validate and act on the request.
At 725, the data receiving device 125a receives the connection request and prepares a connection request for the sensor control device 110. In certain embodiments, the data receiving device 125a can perform steps to validate the request and authenticate the data receiving device 125b and user of the data receiving device 125b. For example, the data receiving device 125a can interrogate 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 validate the connection request.
At 730, the data receiving device 125a sends the connection request to the sensor control device 110. After validating the connection request from the data receiving device 125b, the data receiving device 125a can repackage the information from 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 can include information asserting or confirming the validity of the data receiving device 125b and the connection request. The sensor control device 110 can use the information asserting the validity of the data receiving device 125b to confirm the request and streamline the process of initiating the connection between the sensor control device 110 and the data receiving device 125b.
At 735, the sensor control device 110 receives the connection request from the data receiving devices 125a. From the connection request, the sensor control device 110 identifies the data receiving device 125b (e.g., using a BLE handle for the data receiving device 125b included in the connection request) and a mechanism to use to initiate the connection. For example, the connection request can include a security algorithm type to be used for the connection or a communication channel or channel-hopping scheme to use to facilitate the connection. The sensor control device 110 can determine if the data receiving device 125b has previously initiated a connection with the sensor control device 110 to expedite the connection procedure. For example, the sensor control device 110 can store a mapping table of devices with which it has connected. The mapping table can include identifiers or handles for the devices and a locally assigned identifier (e.g., an index in the table) generated by the sensor control device 110 to act as a shorthand to reference the device in the future. If the identifier for the data receiving device 125b is found in the table, or if the data receiving device 125b has provided valid locally assigned identifier, then the sensor control device 110 can conclude that the data receiving device 125b can communicated with the sensor control device 110 before. If the identifier for the data receiving device 125b does not appear in the mapping table, the sensor control device 110 can generate a new entry for the data receiving device 125b and proceed to establish a pairing with the data receiving device 125b.
At 740, the sensor control device 110 sends a connection acknowledgement to the data receiving device 125b. The connection acknowledgement can indicate to the data receiving device 125b that the sensor control device 110 has received the connection request. The connection acknowledge can further identify the sensor control device 110 to the data receiving device 125b. The connection acknowledgement can further include information that will be used to initiate a mutual authentication between the sensor control device 110 and data receiving device 125b. As an example, the connection acknowledgement can 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.
At 745, the data receiving device 125b receives the connection acknowledgement. In response to receiving the connection acknowledgement, the data receiving device 125b confirms that the connection acknowledgement is from the correct sensor control device 110. For example, the connection acknowledge can include information identifying the sensor control device 110 which the data receiving device 125b compares against information stored by the data receiving device 125b identifying the sensor control device 110. In certain 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 a prompt at the data receiving device 125b.
At 750, the sensor control device 110 and data receiving device 125b can conduct a mutual authentication. Based on information exchanged between the sensor control device 110 and data receiving device 125b (for example, in the connection request and connection acknowledgement), the sensor control device 110 and data receiving device 125b can independently generate a shared secret. The shared secret can be based on public keys and private keys of the sensor control device 110 and the data receiving device 125b as applied to a piece of random data that is agreed-upon by the sensor control device 110 and the data receiving device 125b. The shared secret can be selected such that only a device with both a public key of the sensor control device 110 and data receiving device 125b and a private key (e.g., a non-shared key) of at least one of the sensor control device 110 or data receiving device 125b would be able to generate the shared secret. Using the shared secret, the sensor control device 110 and data receiving device 125b can verify the identity of the other device by confirming that the other device has access to the private key corresponding to a shared public key. After confirming the identity of the other device, the sensor control device 110 and data receiving device 125b can generate a mutual encryption value or scheme for subsequent communication sessions between the sensor control device 110 and data receiving device 125b.
After performing the mutual authentication, the sensor control device 110 and data receiving device 125b are ready to initiate a secured communication session. In particular embodiments, the sensor control device 110 can store an identifier for the data receiving device 125b that facilitates the sensor control device 110 recognizing connection requests from the data receiving device 125b. For example, the sensor control device 110 can store, in local storage 230 or memory 220, a mapping between the identifier for the data receiving device 125b and the mutual encryption value.
With reference to 715-750 of
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 illustrative purposes only, and the data receiving device 125a can initiate a request for data from the sensor control device 110 prior to the data receiving device 125b. In particular embodiments, the request from the data receiving device 125a or data receiving device 125b can be initiated periodically. For example, the data receiving device 125a and data receiving device 125b can be configured to transmit a request for data addressed to the sensor control device 110 according to a preset schedule (e.g., once every 60 seconds, once every 10 seconds, twice every second, etc.). The schedule can be determined based on the computational abilities of the device as well as factors such as the power or battery level of the device. The schedule can 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 between the sensor control device 110 and each of the data receiving device 125a and data receiving device 125b independently, that is data receiving device 125a and data receiving device 125b are not aware of the scheduled time for the other. In other embodiments, the schedule is determined with input from data receiving device 125a and data receiving device 125b, allowing the two devices to negotiate on the schedule and avoid interfering with each other's requests. This approach, though adding some computational complexity and requiring the devices to, in some way, be aware of each other, allows for load balancing for the sensor control device 110 and minimizes the appearance of parallel requests and processing.
In particular embodiments, the request from the data receiving device 125a or data receiving device 125b can be initiated upon the data receiving device 125a or data receiving device 125b coming into communicative range of the sensor control device 110. For example, the data receiving device 125a and data receiving device 125b can be configured to send polling requests to determine the identity of nearby devices. Additionally or alternatively, the sensor control device 110 can be configured to periodically send advertising or connection requests to all nearby devices. Upon receiving an advertising request, the data receiving device 125a or data receiving device 125b can initiate the request for data.
At 765, the sensor control device 110 processes the requests for data from the data receiving device 125a and the data receiving device 125b. In particular embodiments, to process the requests for data, the sensor control device 110 first confirms the authentication of the data receiving device 125a or data receiving device 125b. As an example, the sensor control device 110 first identifies which device sent a request. As an example, and as described above, the requests can each include information to identify the requesting device, such as a unique or local identifier (e.g., BLE handle or a shorthand for the handle managed internally by the sensor control device 110) for the data receiving device 125a or data receiving device 125b. The sensor control device 110 then confirms that the requesting device has permission or has otherwise been authenticated to request data from the sensor control device 110. If the device does not have the requisite permission, then the request can be either rejected or converted to a request to establish a connection directly with the sensor control device 110. Determining that the requesting device has permission can include, by way of example, comparing the identifier for the requesting device with identifiers stored by the sensor control device 110 as a result of previous connection requests and identifying a set of permissions granted to that device. Once the identity and the permissions for the requesting device are established, the sensor control device 110 proceeds to determine how to response to the requests.
In particular embodiments, the requests for data from the data receiving device 125a and data receiving device 125b can include information to indicate what type of data each device is requesting. As an example, the sensor control device 110 can process and store data related to levels of specified analytes detected in the user. The data can be stored according to a key or queue system in which the data can be easily indexed to a specific event or a period of time. As such, the data related to the levels of the specified analytes can be stored with a timestamp unique to each data record. The requests for data from the data receiving device 125a and data receiving device 125b can be associated with a key representing a range of analyte data requested by the device. As an example, the request can include a timestamp, range of timestamp, unique identifier, or life count associated with data records requested by the requesting device. In response to each request, the sensor control device 110 can retrieve the requested data from its storage 230.
In particular embodiments, the sensor control device 110 can track which data has been provided to which data receiving devices. As an example, each entry comprising analyte levels (or other sensed levels) can be annotated with information including the identity of data receiving devices that have requested and receiving that data, a timestamp or count associated with the request, and a timestamp or a count associated with the data receiving device receiving a response to the request. In such cases, unless specified otherwise, a request for data from a data receiving device 125 or data receiving device 125b can be interpreted as a request to provide all missing data. In preparing information to provide to the data receiving device, the sensor control device 110 can determine which data records have not yet been provided to the requesting device.
Once the appropriate records have been identified, the sensor control device 110 packages the data into a response to the request for data. As an example, the sensor control device 110 prepares a response message include a payload comprising the requested data (or data otherwise 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 intended for. As such, the data requested by the data receiving device 125a and data receiving device 125b can be different. As an example, the data receiving device 125a can be updated more frequently, so individual responses are smaller. As another example, the data receiving device 125b can request only subsets of data associated with specified times (e.g., during nights or after meals), so the data receiving device 125b does not request all data from the sensor control device 110.
At 770, the sensor control device 110 responds to the request from the data receiving device 125a. To respond to the request, the sensor control device 110 transmits the response packet prepared for the data receiving device 125a to the data receiving device 125a using, for example, an agreed communication scheme between the two devices or using the establish communication session.
At 775, the sensor control device 110 processes the request for data from the data receiving device 125b. Although illustrated as a separate step, much of the processing for processing the request from the data receiving device 125b can be similar to processing the request from the data receiving device 125a, the difference being that the sensor control device 110 identifies data for the data receiving device 125b and prepares the packet for reception by the data receiving device 125b. At 780, the sensor control device 110 responds to the request from the data receiving device 125b.
As discussed, the sensor control device 110 can respond to the request in a variety of orders, such as in the same order as received, according to a pre-established priority (e.g., request from data receiving device 125a always take priority over requests from data receiving device 125b), based on the time since the request has been received, based on a schedule (e.g., pending requests from data receiving device 125a are responded to on every 10th second of the minute and pending requests from data receiving device 125b are responded to on every 40th second of the minute), the size of the request, the size of the pending response, and other suitable response schemes.
Data receiving device 125a and data receiving device 125b can continue to initiate requests from the sensor control device 110 to maintain an active communication session. In certain embodiments, communication session can time out through inactivity to preserve the battery life of the sensor control device 110 and possibly data receiving device 125a and data receiving device 125b. Data receiving device 125a and data receiving device 125b therefore can, while they are within a communication range of the sensor control device 110, initiate requests to the sensor control device 110 to keep the connection active. If the connection is deactivated through inactivity, data receiving device 125a or data receiving device 125b can initiate a new communication session with the sensor control device 110 using the shared secret or and existing authentication key or can request and generate a new authentication key using the techniques described herein.
To further manage the battery life of the sensor control device 110, the sensor control device 110 can alter 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 concurrent communication sessions, the sensor control device 110 monitors additional channels correlating with the communication session information set by the data receiving devices. This additional monitoring uses more battery life. To perform additional communication sessions with additional devices, the sensor control device 110 uses even more battery life. The monitoring on additional channels involves certain hardware processes that can be dynamically altered 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, adjusting the number of transmission cycles or the rate of iteration of the transmission cycles, adjust the amount of time in an active receiving mode or the frequency of transition to the 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.
The communication module 240 of the sensor control device 110 can be configured to handle or manage the bi-directional communication link between the sensor control device 110 and a receiver 120. The communication module 240 can include communication circuitry configured to transition between a sleep state, a partial awake state, and a fully awake state. For example, when in the fully awake state, the communication circuitry can be configured to execute tasks and actions associated with a communications protocol startup (CPS) instruction set 221 that can include an advertisement scanning related (ASR) instruction subset 222 and a non-ASR instruction subset 223. The communication circuitry, when in the partially awake state, is configured to execute the ASR instruction subset 222. The ASR instruction subset 222 can include transmitting advertising notices 224 over one or more channels according to a wireless communications protocol (e.g., BLE) and scanning the one or more channels for a connection request from a receiver or other device. Alternatively, the advertising notices 224 can be stored in the communication module 240. Conversely, when a connection request is not received, the communication circuitry can return to the sleep state without performing actions or tasks associated with the non-ASR instruction subset 223 of the CPS instruction set 221. In the example of
In an embodiment, the communication circuitry of the communication module 240, when executing the CPS instruction set 221 with the BLE peripheral application in the fully awake state, can utilize a first amount of power. Also, when executing the ASR instruction subset 222 with the BLE peripheral application in the partially awake state, the CPS instruction set 221 can utilize a second amount of power that is less than the first amount of power. The CPS instruction set 221 can include more tasks and actions that take a longer period of time and more power to implement in comparison to the tasks and actions of the ASR instruction subset 222. For example, the second amount of power and amount of time, to implement the ASR instruction subset, can be between 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 amount of time, to implement the ASR instruction subset, can be between 50%-65% of the first amount of power and time to implement the entire CPS instruction set.
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 while communicating with the receiver 120, such as Bluetooth low energy (e.g., using 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, receiver, and/or a transceiver. Optionally, the communication module 240 can be electrically coupled to an antenna.
The microcontroller 210 is coupled to the memory 220 by a suitable data/address bus 296. The memory 220 can store the programmable operating parameters used by the microcontroller 210. The microcontroller 210 can modify the operating parameters, as required, in order to customize the operation of sensor control device 110 to suit the needs of a particular wearer. The memory 220 can also store data sets (raw data, summary data, historical data, trends, histograms, etc.), such as 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 can be selected and packaged into data packets (e.g., data packet 400) and sent to receiving devices (e.g., receiver 120). The memory 220 can store instructions to direct the microcontroller 210 to analyze the electrical signals from the sensing hardware 260 to identify characteristics of interest and derive values for storage and presentation.
In addition, the memory 220 stores CPS instruction set 221. The CPS instruction set 221 can be loaded in 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, a receiver 120 can provide updates to the CPS instruction set stored in the memory 220. The CPS instruction set 221 includes the ASR instruction subset 222 and non-ASR instruction subset 223. The ASR instruction subset 222 can include instructions related to at least two of the following: expiration of a wake-up timer; processor startup; initialization of a transmit circuit; formation of advertising data packets; transmission of advertising data packets; scanning one or more channels for a connection request from another device (e.g., receiver 120); and validating or denying an incoming connection request. The non-ASR instruction subset 223 can include instructions related to at least two of the following: initialization of a random-access memory (RAM) segment/block; initialization of sensing hardware 260; initialization of an operating system service; 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 the following: initialization of a random-access memory (RAM) segment/block; initialization of sensing hardware 260; initialization of an operating system service; and initialization of the CPS instruction set 221.
In accordance with embodiments herein, advertisement schedules included in the CPS instruction set 221 can balance fast advertisement at low power and low sensitivity in conjunction with slow advertisement at high power and high sensitivity. The balance can be taken to afford quick communications and longer range automatic connections for remote monitoring. As explained herein, once a connection is made between the receiver 120 and the sensor control device 110, the communication module 240 can set the transmit power and receive sensitivity to a desired communications session level (e.g., high) for a duration of the communication session. The transmit power and receive sensitivity can be set to the desired communications session level regardless of whether the connection was established using short or long range advertisement, thereby affording a desired communications distance during an active communications session. For example, if a subject wanted to force a communication session, the patient can hold the receiver 120 close to the sensor control device 110 in order to begin the communications session in accordance with short range advertisement. Then, once the connection is made, the communication module 240 adjusts the transmit power and receive sensitivity to a communications session level (e.g., max power settings), thereby allowing the subject to leave the receiver 120 on a table or otherwise out of hand without experiencing any disruption of the communication session.
Additionally or alternatively, one or more separate advertisement schedules included in the CPS instruction set 221 can be stored in the memory 220 to be used in connection with individual corresponding receivers 120. For example, when a sensor control device 110 initially begins communicating with a particular receiver 120, the receiver 120 can download a corresponding advertisement schedule included in the CPS instruction set 221, along with the instruction to utilize the advertisement schedule included in the CPS instruction set 221 until otherwise instructed. Subsequently, the sensor control device 110 can communicate with another receiver 120 that downloads a corresponding new advertisement schedule included in the CPS instruction set 221, along with an instruction to utilize the new advertisement schedule included in the CPS instruction set 221 until otherwise instructed. As a further example, the sensor control device 110 can update the advertisement schedule included in the CPS instruction set 221 throughout operation, such as based upon the success rate at which communications links are established, based on delays when establishing communications links and the like.
The operating parameters of the sensor control device 110, including but not limited to the CPS instruction set 221, can be non-invasively programmed into the memory 220 through the communication module 240 in bi-directional wireless communication with the receiver 120. In some embodiments, the communication module 240 can be controlled by the microcontroller 210 and receives data for transmission from the microcontroller 210. The communication module 240 allows data from the sensing hardware 260 and status information relating to the operation of the sensor control device 110 (as contained in the microcontroller 210, memory 220, or storage 230) to be sent to the receiver 120 through an established bi-directional communication link. The communication module 240 also allows the receiver 120 to program new parameters and advertisement schedules for the sensor control device 110.
The communication module 240 transmits one or more advertisement notices or advertisement packets 400 on one or more advertisement channels. Each advertisement channel is a point to multipoint, unidirectional, channel to carry a repeating pattern of system information messages such as network identification, allowable RF channels to establish the communication link, or the like that is included within the advertisement notice. As described herein, in certain embodiments, the advertisement notice can include analyte data 425 in addition to connection data 420 within its payload 410. The advertisement notice can be repeatedly transmitted after a set duration or an advertisement interval based on an advertisement schedule stored in the memory 220 until the communication link is established with the receiver 120.
At 810, the wakeup timer expires and the BLE peripheral application is activated. For example, the sensor control device 110 can wake up from a predetermined sleep interval. This interval can occur in between connection or advertising events. These connection or advertising events can be controlled by the timing control circuitry 211 as shown in
At 815, a processor startup routine commences. For example, the startup module 212 can be utilized to control a boot process of the processor. For example, after the timing control circuitry 211 has determined a wakeup interval for the sensor control device 110, the startup module 212 can include or access ROM (e.g., memory 220 or 243) or non-volatile Flash memory with boot code utilized to control the boot process. The ROM can load the boot process. The boot process can include power on, operating system load, and transfer of control to the operating system. For example, subsequent to a power on activity initiated by a user, condition, timer, or other stimulus, a routine can be executed to ensure that the device drivers are functioning properly. Any issues encountered can halt the boot process. Each device in a boot list can load its own routine to ensure proper communication between the devices and the startup module 212. After a successfully completed routine, the operating system 213 can be loaded.
At 820, the communication circuitry 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 while communicating with the receiver 120, such as BLE, Bluetooth, MICS, and/or the like. The communication module 240 transmits one or more advertisement notices on one or more advertisement channels. Each advertisement channel is a point to multipoint, unidirectional, channel to carry a repeating payload, which may include, connection data 420 including system information messages such as network identification, allowable channels to establish the communication link, or the like. The advertisement notice can be repeatedly transmitted after a set duration or an advertisement interval based on an advertisement schedule stored in the memory 220 until the communication link is established with the receiver 120.
At 825, the memory 220 is initialized. For example, operating parameters can be loaded into certain memory locations and/or registers. The memory 220 can 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 processed by the microcontroller 210 from the data generated from or by the sensing hardware 260. The memory 220 can also store instructions to direct the microcontroller 210 to analyze the data generated from or by the sensing hardware 260 to identify characteristics of interest or priority and derive values for presentation to the receiver 120. Additionally, the memory 220 stores one or more advertisement schedules included in the CPS instruction set 221.
At 830, the sensing hardware 260 can be initialized. For example, the sensing hardware 260 can require a short warmup period before usable data can be retrieved from or by the sensing hardware 260. During initialization, this warmup period can be enforced or voltage can be applied to the sensing hardware 260 to expedite the warmup period. Once the sensing hardware 260 is ready, data or other values can be retrieved from the sensing hardware 260. For example, a current value for levels of one or more particular analytes can be recorded and processed by the microcontroller 210.
At 835, if the sensor control device 110 supports an operating system 213 as a base operating layer, operating system services are initialized. After a successful completed BIOS, the operating system 213 can commence to run applications or other functions of the sensor control device 110. The operating system 213 can comprise various application programs for collecting and analyzing biological signals such as analyte levels.
At 840, the BLE protocol stack 230 is initialized. The protocol stack 230 can include a host and controller comprising multiple layers utilized for communication.
At 845, the BLE peripheral application transmits one or more advertising notices. The protocol stack 230 controls the time at which the advertising notices are sent. The Link Layer (LL) of the controller of the protocol stack 230 can control the radiofrequency (RF) state of the device, which can include the advertising state. The scan request and scan response activities occur during the advertising intervals of both applications.
At 850, the sensor control device 110, e.g., via the BLE peripheral application, determines whether a connection request has been received (e.g., from a receiver 120 in the environment of the sensor control device 110). If there are no connection requests, the process ends and the IMD goes back to sleep as illustrated at 860. Alternatively, if a connection request is received, the process proceeds to 855.
At 855, the sensor control device 110, e.g., via BLE peripheral application, analyzes the content of the connection request, such as to determine if the connection request was sent by an authorized receiver 120. If the connection request is sent by an authorized receiver 120, the sensor control device 110 and receiver 120 can exchange additional information to initiate a communications session. The receiver 120 and sensor control device 110 can connect, and the sensor control device 110 can send data gathered by the sensor control device 110 (e.g., through the sensor hardware 260). As an example, the sensor control device 110 can backfill data not yet transmitted to the receiver 120 either automatically or based on a request from the receiver 120. At this point in the process, the sensor control device 110 is fully awake.
At 910, the wakeup timer expires and activates a partially wake (low power) BLE application. For example, the sensor control device 110 can wake up from a predetermined sleep interval. This interval can occur in between connection or advertising events. These connection or advertising events can be controlled by the timing control circuitry 211 as shown in
At 915, the processor startup routine is implemented similar to the routine described in connection with the operations at 810. At 920, the communication circuitry of the communication module 240 is initialized similar to the routine described in connection with the operations at 815.
The low power BLE application operating using the process 900 skips the steps from 825 through 840 as shown in the BLE peripheral application in a fully awake state. The low power BLE application does not necessarily initialize the memory block, the sensing hardware 260, or the full BLE protocol stack during this portion of the process. This change in process shortens the time necessary for the processor and hardware blocks to be active during each advertising opportunity, conserving battery power.
At 925, the BLE peripheral application constructs and sends one or more advertising notices. In certain embodiments, the advertising notices are preformed and include payloads 410 with only connection data 420. In certain embodiments, the advertising notices are generated to further include most recent or highest priority analyte data 425, which may be encrypted before inclusion in the advertising packet payload 410.
At 930, the BLE peripheral application determines whether a connection request was received. The connection request can be received from one or more receiving devices (e.g., receiver 120) in the environment of the sensor control device 110. If no connection request is received, the process ends and the sensor control device 110 goes back to sleep as illustrated at 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 communications session if appropriate. At this point in the process, the sensor control device 110 begins to perform the skipped operations to transition into the fully awake state.
When the fully awake advertising application 1030 takes control, the memory block 220 is initialized (operation 825 in
If a connection request is received from a receiver 120, the connection circuitry 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 circuitry is configured to execute tasks and actions associated with a communications protocol startup (CPS) instruction set that includes an advertisement scanning related (ASR) instruction subset and a non-ASR instruction subset. After completing the required handling duties, the communication circuitry can return to the sleep state until the next wakeup timer expires.
If, however, a connection request is not received, the communication circuitry can return directly to sleep state 1110, without performing actions or tasks associated with the non-ASR instruction subset of the CPS instruction set.
When the communication circuitry executes the CPS instruction set while in the fully awake state, the sensor control device 110 utilizes a first amount of power. When executing the ASR instruction subset while in the partially awake state, the sensor control device 110 utilizes a second amount of power that is less than the first amount of power. The complete CPS instruction set includes more tasks and actions that take a longer period of time and more power to implement versus the limited set of task and actions of the ASR instruction subset.
The communication circuitry can include additional or alternative hardware or firmware, in which case the ASR instruction subset can include instructions related to at least two of the following: expiration of a wake-up timer; processor startup; initialization of a transmit circuit; transmission of advertising data packets; scanning one or more channels for a connection request from a receiver 120; or validating or denying an incoming connection request. In certain embodiments, the ASR instruction subset can not include the non-ASR instruction subset. The non-ASR instruction subset can include instructions related to at least two of the following: 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 communications protocol stack.
As described herein, for a sensor control device 110 and data receiving device 120 (or multi-purpose device 130, etc.) to establish a communication session, the sensor control device 110 and data receiving device 120 communicate initial data packets comprising information useful for establishing the communication session. This data, which may be referred to as connection data or connection parameters, can be exchanged in specifically configured packets which can be referred to as advertising data packets. A device seeking to initialize a connection can broadcast advertising data packets according to a predefined schedule established by a communication protocol used by the device. As an example only and not by way of limitation, a device utilizing the BLE communication protocol can broadcast advertising data packets according to a set temporal schedule and using specific communication frequencies which are reserved for use for advertising data packets. The sensor control device 110 can, when no communication session is active, repeatedly broadcast advertising data packets. When another device receives the advertising data packet, it can interpret the data included in the data packet and determine if the device can and should respond to the advertising data packet to initialize a communication session with the sensor control device 120.
A device will only receive the advertising packet when it is actively listening for advertising data packets while operating in a scanning mode. When the device, e.g., a data receiving device 120 is not operating in the scanning mode, it can risk missing advertising data packets and other requests to initiate a communication session. Therefore, to avoid missing potentially critical advertising data packets, it can be desirable to maximize the time spent in the scanning mode. However, operating in the scanning mode can use a significant amount of battery power. The scanning mode can require the constant use of communication hardware (e.g., suitable radios) as well as processing hardware to interpret any received data packets. This use of battery power can significantly reduce the total battery life of a data receiving device 120, limiting its effectiveness at performing other functions. Therefore, a balance is often sought between time spent in the scanning mode and time spent in lower-power states. One approach involves scheduling the time spent in the scanning mode so that the device is only in a scanning mode for a fraction of the time. To increase the chances that a data receiving device 120 is able to receive communication packets from a sensor control device 110, the scanning window can be selected or dynamically altered to coincide with an advertising data packet schedule used by the sensor control device 110.
To facilitate the data receiving device 120 receiving the advertising data packets 1205, the data receiving device 120 can operating in a scanning mode during a specified window 1210 of time that also repeats. As an example, a data receiving device 120 can operate on a two minute cycle and operate in a scanning mode for the first ten second window 1210 of the two minute cycle. During the remaining 110 seconds, the data receiving device 120 can conserve battery power by operating in a lower power state. To maximize the ability of the data receiving device 120 receiving advertising data packets 1205 from the sensor control device 110, the beginning of the window 1210 can be selected or adjusted to coincide with the timing of advertising packet broadcast 1205. For example, the advertising schedule of the sensor control device 110 can be provided to the manufacturer of the data receiving device 120 in advance, so that the data receiving device 120 can be pre-configured to operate in the scanning mode while advertising data packets 1205 are being broadcast. As another example, during an initial communication session between the sensor control device 110 and data receiving device 120 (e.g., in a pairing process), the sensor control device 110 can provide the details of its advertising schedule to the data receiving device 120, which can adapt its scanning window schedule accordingly. Similarly, in certain embodiments the sensor control device 110 can adapt its advertising schedule to the scanning window schedule of the data receiving device 120. In other embodiments, the advertising and/or scanning window schedule can be dictated by the communication protocol itself or can be dictated by a provider of a communication module used by one or more of the devices.
While an agreed-upon advertising and scanning window schedule can improve the rate of overlap of the advertising window and the scanning window, this approach can have flaws. As an example, the maintenance of the overlap requires both devices to accurately time their respective windows. Both devices must maintain consistent internal clocks to maintain the synchronization. If one or more of the internal clocks is subject to variation or error, synchronization can be broken, as illustrated in
The situation illustrated in
As described herein, an alternative approach can be to dynamically modify the scanning window schedule to attempt to re-establish the overlap between the advertising window and the scanning window.
In the example illustrated in
At 1320, the data receiving device 120 can set a scanning window to an initial duration of time. In some embodiments, the initial duration of time can be a period of time as long as a standard scanning window (e.g., the scanning window used outside of the iterative searching process, if different scanning windows are used for different purposes). In some embodiments, the initial duration of time can be shorter than a standard scanning window. The initial scanning window can be for, example, 1 second, 2 seconds, 3 seconds, etc. In certain embodiments, the initial scanning window can be selected based on anticipated delays for processing connection data to minimize extraneous scans.
At 1330, the data receiving device 120 initiates a scan window according to the periodic scanning schedule and the initial scan window. As an example, the periodic scanning schedule can dictate that, regardless of the size of the scan window, the scan window will be initiated approximately every 1 minute, two minutes, five minutes. The data receiving device 120 therefore initiates the scan window for the length of the initial scan window duration at the next instance of the scanning window cycle.
At 1335, the data receiving device 120 determines if it has been able to establish a connection with the sensor control device 110 based on advertising data packets received during the scan window. For example, the data receiving device 120 can monitor whether it has received any advertising data packets during the scan window. The data receiving device 120 can determine whether any of the received advertising data packets originated from the sensor control device 110 from which it was recently disconnected. The data receiving device 120 can further determine if the connection data in the advertising data packets were sufficient to enable the data receiving device 120 re-establish the connection with the sensor control device 110. If so, then at 1350, the data receiving device 120 and sensor control device 110 can exchange data, resynchronize their internal clocks, and otherwise proceed with normal operations.
If the data receiving device 120 determines that it was not able to establish a connection 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 formulaic amount based on, for example, at least one of: the current duration of the scan window, the number of the iteration through the method 1300, the duration of time since the sensor control device 110 and data receiving device 120 were disconnected, the current available battery power of the data receiving device 120, and other considerations. As an example, the formulaic amount can be based on or retrieved from values stored in a lookup table in storage of the data receiving device or a pre-programmed function of the programming of the data receiving device 120. In some embodiments, the scan window duration is increased by an amount based on the possible drift between the internal clocks of the data receiving device 120 and the sensor control device 110, including, but not limited to, the worst case scenario or average drift.
In addition to or instead of adjusting the duration of the scan window, the data receiving device 120 can modify the timing of the scan window. As an example, the amount of time added can be added to the beginning of the window (so that the window starts earlier in time), the end of the window (so that the window extends longer), or a combination of the two. An equivalent amount of time may correspondingly be removed from the end or beginning of the time window to move the scan window through time. In one approach, the 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 period, which can push the advertising data packet broadcasts to earlier or later start times.
At 1345, the data receiving device 120 can determine if the duration of the increased scan window exceeds a threshold scan window duration. As discussed herein, the data receiving device 120 can have a limited battery and the length of the scan window is one factor in maximizing the longevity of the battery life. Therefore, the data receiving device 120 can be configured with a maximum allowable scan window to limit the amount of time that the data receiving device 120 is in the scanning mode. In some embodiments, the maximum scan window duration can be based on factors such as at least one of: 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 properties of the advertising schedule of the sensor control device 120. As an example, the sensor control device 110 can be configured with an advertising schedule with a fixed period such that advertising packets are sent at least once every cycle. The cycle length can be, for example, 30 seconds, 1 minutes, 2 minutes, 5 minutes, etc. The data receiving device 120 can be provided the cycle and use the cycle length as the maximum scan window duration. As such, when the scan window is at the maximum level, the scanning window can be guaranteed to overlap with the expected advertising period regardless of any desynchronization being experienced. Extending the maximum scan window beyond the cycle length would be redundant and wasteful of battery power.
If the duration of the increased scan window does not exceed the threshold scan window duration, then the data receiving device 120 returns to 1330 and initiates a scan window based on the increased scan window duration. The process then continues as described above.
If the duration of the increased scan window does exceed the maximum scan window threshold, then the data receiving device 120 has executed a scan window for longer than the cycle length and some other factors are likely preventing the data receiving device 120 and sensor control device 110 from establishing a connection (e.g., the battery of the sensor control device 110 has died, environmental factors are preventing the connection, etc.). Therefore, extending the scan window further would be redundant. To better use the battery of the data receiving device 120, and lower the average battery cost of the scan windows, 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 shorter than the maximum) before continuing the process of scanning as described herein.
The method 1300 can be iterated repeatedly until the data receiving device 120 is able to resynchronize with the sensor control device 110 or otherwise exchange data with the sensor control device 110. In some embodiments, the method 1300 can be iterated for a fixed number of cycles, after which the data receiving device 120 can enter into a more aggressive power saving mode under the assumption that communication with the sensor control device 110 is permanently lost. In some embodiments, various steps of the method 1300 can be modified as the number of iterations of the method 1300 are performed. For example, the maximum scan window threshold can be raised or lowered, the amount that the scan window duration is increased (e.g., at 1340) can be raised or lowered, criteria for determining if a connection can be established at 1335 can be changed, and other similar modifications can be made.
The dynamic and iteratively determined scanning window approach described in the method 1300 can reduce the average battery power used when using scanning windows to reestablish a connection between a data receiving device 120 and a sensor control device 110. As an example, the approach uses a shorter scanning window if the disconnect is recent, under the assumption that any drift that has occurred will be relatively minor. The approach also includes a mode in which the maximum scanning window can be defined based on the advertising cycle length used by the sensor control device 110, which guarantees that a period of overlap will exist as long as there are no external factors preventing the connection. The approach therefore incorporates an improvement over previous techniques which rely on fixed scanning window lengths.
In particular embodiments, connection parameter information is exchanged when a communication session between a data receiving device 120 and sensor control device 110 is initiated. The connection parameter information can be used by the devices to initiate the communication session. In some embodiments, one or more of the data receiving device 120 or sensor control device 110 can select the connection parameter information to improve the connection quality of the ensuring communication session. As an example, the connection parameter information can include, by way of example and not limitation at least one of: connection retry timeout, inter-connect retry timeout, supervision timeout, maximum interval, minimum interval, latency, and supervision timeout. Once connection parameter information is selected, the device (e.g., the sensor control device 110) can request that connection parameter configurations be adjusted to the selected parameters in a process known as negotiation. Not all devices support negotiation for all devices.
In some examples, a peripheral device (e.g., a sensor control device 110) will support communication with a wide variety of devices using a standard protocol (e.g., BLE). Each of the possible communication partner devices will often be capable of maintaining communication sessions across a variety of parameter configurations. The difference between available communication parameters can vary based on, for example, the goals and preferences of the manufacturer of the other device or components of the device (e.g., the manufacturer of the communication module itself), the physical configuration of the other device, or the available battery power or operating mode of the device. As an example, it can be the case that a first manufacturer make only specific communication parameter configurations available for connections using the communication protocol to maintain a consistent security or power consumption experience for uses. These communication parameter configurations can be stricter than the configurations available from other manufacturers. However, it is common for devices to only support the strict configuration as a way to simplify integration with a variety of partner devices—even if the configuration is not ideal for specific use cases.
In particular embodiments, a sensor control device 110 can be configured to access or determination connection parameter information based on the identity of the data receiving device 120 with which it is initiating the communication session. As an example, the identity of the data receiving device 120 or the manufacturer thereof, 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 accessible based on the identity of the data receiving device 120. When initiating the communication session, 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 for the communication session. The selected communication parameter configuration can therefore be customized to the particular data receiving device 120 to improve communication data quality, reliability, throughput speeds, etc. The process by which the sensor control device 110 dynamically determines connection parameter information to be used with a given data receiving device further enables the sensor control device 110 to maintain support with the strictest requirements while taking advantage of more relaxed ranges of acceptable parameters made available by other manufacturers and partners.
As discussed herein, certain manufacturers of data receiving devices 120 can enforce individualized requirements for certain communication parameters to be used with sensor control devise 110 and other examples of peripheral devices. Table 1 provides an example of parameters that may be used by different manufacturers and for different devices, which illustrates the challenges of supporting optimal communication settings across a variety of devices.
Accordingly, embodiments herein afford better adaptability and expansion opportunity for use of future data receiving devices 120 and multi-purpose devices 130 with sensor control devices 110. For example, desired combinations of communication parameters may be determined through a collaborative sharing of communication parameter configurations and measures of communication quality and reliability. As described herein, the analyte monitoring system 100 can provide accuracy and field tested parameter values based on feedback from data receiving devices 120 or users thereof. A closed loop feedback system can be provided that is able i) to continuously improve connection reliability and quality, ii) to adapt to manufacturing changes for data receiving devices 120 and multi-purpose devices 13, and iii) to adapt to data receiving devices 120 and multi-purpose devices 130 as introduced. The methods and systems further avoid a need to make software updates for sensor control devices for different or newer mobile devices and hence reduce a number of regulatory submissions.
Optionally, information exchanged before or during the establishment of the communication session can include battery condition information of the data receiving device 120 and the sensor control device 110. The sensor control device 110 can further incorporate the battery condition information in a determining operation for selecting the appropriate connection parameter information to provide to the data receiving device 120 as a request to adjust the communication parameter configuration. Other available information can further be used to dynamically adjust the communication parameter configuration based on current conditions of the devices as well as environmental conditions. For example, an ambient noise level of the environment can be measured and used to adjust the communication parameters to improve data connection reliability.
In some embodiments, the appropriate communication parameters settings can be determined in advance of the communication session initiation between the sensor control device 110 and the data receiving device 120. As an example, the manufacturer of the sensor control device 110 can test a variety of potential data receiving devices 120 and multi-purpose devices 130 to determine ideal communication parameter parameters to be used between the devices for a variety of environmental conditions. Such a process can be performed, for example, during a certification process required before a data receiving device 120 can be used with the sensor control device 110. The results of the testing can include a compact database linking device manufacturer, make, model, and software version information with specific sets of communication parameter information. A certification or manual testing process allows for expert opinion on the best parameters to use for specific data receiving device 120.
In some embodiments, the communication parameter information can be determined dynamically when the communication session is initiated. As an example, the sensor control device 110 can be configured to request, when a communication session is initiated, the maximum and minimum settings for relevant communication parameters enabled by for the data receiving device 120. The sensor control device 110 can determine whether it can support the maximum settings, modify them as needed, and use the maximum values as the request communication parameter configuration. As another example, a sensor control device 110 can be configured with the ability to perform a data link quality test or self-certification procedure. During the data link quality test, the sensor control device 110 can request a series of communication parameter configurations, evaluate a link quality between the sensor control device 110 and data receiving device 120, and select a communication parameter configuration based on the evaluations.
In accordance with at least some embodiments, the parameter values may be identified through machine learning methodologies implemented on one or more systems of the analyte monitoring system 100 (e.g., remote servers 150). The sensor control device 110 and data receiving device 120 can be configured to report communication parameters used to the analyte monitoring system 100. Over time, the analyte monitoring system 100 can collect performance measures concerning one or more characteristics of interest in connection with communications sessions for a large pool of sensor control devices 110 and data receiving devices 120. Based on the information collected over time, the analyte monitoring system 100 identifies predetermined parameter sets that exhibit a preferred performance in communication sessions.
The term “communications parameter” refers to one or more parameters related to a wireless protocol of interest. Non-limiting examples of wireless protocols include, as discussed herein, Bluetooth Low Energy (BLE), Bluetooth, ZigBee, or the like. For example, the BLE protocol is defined within “Bluetooth Specification Version 4.1, published Dec. 3, 2013 (incorporated herein by reference). The BLE protocol is a master-slave protocol operating within a frequency range of 2400-2483.5 MHz (including guard bands). The BLE protocol uses 20 RF channels using a 2 MHz bandwidth. The 20 RF channels are allocated into two channel types, a data channel (having 37 channels) and an advertising channel (having 3 channels). The data channel is used by devices on a BLE network for communication between connected devices. The advertising channel is used by devices on the BLE network to discover new devices, initiate a connection, and broadcast data. Each RF channel (data and advertising channel) is allocated a unique channel index, such that, if two devices wish to communicate, the transceivers of each device must be tuned to the same RF channel at the same time. Optionally, additional or alternative communications protocols may be utilized. A non-limiting list of BLE connection parameters includes Connection Retry Timeout, Inter Connect Retry Timeout, and Supervision Timeout. A non-limiting list of BLE data transfer parameters includes Normal Min Interval, Normal Max Interval, Normal Latency, Normal Supervision Timeout, Low Battery Min Interval, Low Battery Max Interval, Low Battery Latency, and Low Battery Supervision Timeout.
Not illustrated is the manufacture of the devices used in the analyte monitoring system 100 illustrated in
The manufacturer can imbue each sensor control device 110 with a unique identifier (“UID”) and other identifying information, such as an identifier for the manufacturer, identifier for the communication module and manufacturer, or any other suitable identifying information for the sensor or sensor components. As an example, the UID can be derived from sensor-unique data, such as from a serial number assigned to each ASIC 200 embodied in the sensor control device 110 by the ASIC vendor, from a serial number assigned to a communication module 240 embodied in the sensor control device 110 by a communication module vendor, from a random value generated by the sensor manufacturer, etc. Additionally or alternatively, the UID can also be derived from manufacturing values including a lot number for the sensor control device 110 or its components, a day, date, or time of manufacturer of the sensor control device 110 or its key components, the manufacturing location, process, or 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 can be accompanied by encryption keys and several generated random values that are also unique to each sensor control device 110. Similar processes can be used to establish the secure identity of a receiving device, such as a data receiving device 120.
As 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 pertain to medical information about a user, the data is highly sensitive and can be beneficial to be protected. Analyte data associated with a user is sensitive data at least in part because this information can be used for a variety of purposes, including for health monitoring and medication dosing decisions. In addition to user data, the analyte monitoring system 100 can enforce security hardening against efforts by outside parties to reverse-engineering. The security architecture described herein can include various combinations of control features described herein, including, but not limited to the protection of communication between devices, the protection of proprietary information within components and applications, and the protection of secrets and primary keying material. As embodied herein, encryption and authentication can be used as exemplary technical controls for providing protective features. As embodied herein, the various components of the analyte monitoring system 100 can be configured compliant with a security interface designed to protect the Confidentiality, Integrity and Availability (“CIA”) of this communication and associated data. To address these CIA concerns, security functions can be incorporated into the design of the hardware and software of the analyte monitoring system 100.
As embodied herein, to facilitate the confidentiality of data, communication connections between any two devices (e.g., a sensor control device 110 and receiving device) can be mutually authenticated prior to transmitting sensitive data by either device. Communication connections can be encrypted using a device-unique or session-unique encryption key. As embodied herein, the encryption parameters can be configured to change with every data block of the communication.
As embodied herein, to protect the integrity of data, encrypted communications or unencrypted communications between any two devices (e.g., a sensor control device 110 and receiving device) can be verified with transmission integrity checks built into the communications. As an example, as described herein, data transmitted by a sensor control device 110 to a receiving device through a communication session can be validated by the receiving device with transmission integrity checks prior to the receiving device acting on or storing the data. As another example, and as described herein, payloads of broadcast data packets can include integrity check values. Furthermore, data written to a memory of the sensor control device 110 can be verified or validated with integrity checks prior to execution. As embodied herein, session key information, which can be used to encrypt the communication, can be exchanged between two devices after the devices have each been authenticated. Integrity check values can include, for example, an error detection code or error correction code, including as an example and not by way of limitation, non-secure error-detecting codes, minimum distance coding, repetition codes, parity bits, checksums, cyclic redundancy checks, cryptographic hash functions, error correction codes, and other suitable methods for detecting the presence of an error in a digital message.
As embodied herein, minimum distance coding includes a random-error correcting code that provides a strict guarantee on number of detectable errors. Minimum distance coding involves choosing 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 a standard array. Minimum distance coding is considered useful where the probability that an error occurs is independent of the position of a given symbol and errors can be considered independent events. These assumptions can be particularly applicable for transmissions over a binary symmetric channel.
Additionally or alternatively, as embodied herein, a repetition code relates to a coding scheme that repeats bits across a channel to guarantee that communication messages are received error-free. Given a stream of data to be transmitted, the data divided into blocks of bits. Each block is transmitted and re-transmitted some predetermined number of times. An error is detected if any transmission of the repeated block differs.
In addition, or as a further alternative, as embodied herein, a checksum is a value relative to a message or stored block of data based on a modular arithmetic sum of message code words of a fixed word length. The checksum can be directed from the entire block of data or subset thereof. Checksums are generated using a checksum function or cryptographic hash function that is configured to output significantly different checksum values (or hash values) for minor changes to the targeted message. A parity bit is a bit added to a group of bits in transmission to ensure that the counted number of certain bits in the outcome is even or odd. For example, the parity bit can be used to ensure that the number of bits with value 0 is odd. A parity bit can then detect single errors or a repeating fixed number of errors. A parity bit can be considered a special case of a checksum.
As embodied herein, to further reduce or prevent unauthorized access to the devices of the analyte monitoring system 100, root keys (e.g., keys used to generate device-unique or session-unique keys) can optionally not be stored on the sensor control device 110 and can be encrypted in storage by the remote server 150 or on other device having more computing power than the sensor control device 110 (e.g., data receiving device 120). As embodied herein, the root keys can be stored in an obfuscated manner to prevent a third-party from easily accessing the root keys. The root keys can also be stored in different states of encryption based on where in the storage they are stored. As embodied herein, to facilitate the availability of data, sensor control device 110 operations can be protected from tampering during service life, in which the sensor control device 110 can be configured to be disposable, for example and as embodied herein by restricting access to write functions to the memory 220 via a communication interface (e.g., BLE and NFC). The sensor can be configured to grant access only to known devices (e.g., identifier by a MAC address or UID) or only to devices that can provide a predetermined code associated with the manufacturer or an otherwise authenticated user. Access to read functions of the memory 220 can also be enforced, including for example where the read function attempts to access particular areas of the memory 220 that have been designated secure or sensitive. The sensor control device 110 can further reject any communication connection request that does not complete authentication within a specified amount of time to safeguard against specific denial of service attacks on the communication interface including attempted man-in-the-middle (MITM) style attacks. Furthermore, the general authentication and encryption design, described herein, can support interoperable usage where sensor control device 110 data can be made available to other “trusted” data receiving devices without being permanently bound to a single device.
As embodied herein, the devices, including 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 each employ a variety of security practices to ensure the confidentiality of data exchanged over communication sessions 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 proactively identify and connect with trusted local-area, wide-area, or cellular broadband networks and continuously verify the integrity of those connections. The sensor control device 110 can further deny and shut down connection requests if the requestor cannot complete a proprietary login procedure over a communication interface within a predetermined period of time (e.g., within four seconds). For example and without limitation, such configurations can further safeguard against denial of service attacks.
As embodied herein, the sensor control device 110 and receiving device can support establishing long-term connection pairs by storing encryption and authentication keys associated with other devices. For example, the sensor control device 110 or data receiving device can associate a connection identifier with encryption and authentication keys used to establish a connection to another device. In this manner, the devices can re-establish dropped connections more quickly, at least in part because the devices can avoid establishing a new authentication pairing and can proceed directly to exchanging information via encrypted communication protocols. After a connection is successfully established, the device can refrain from broadcasting connection identifiers and other information to establish a new connection and can communicate using an agreed channel-hopping scheme to reduce the opportunity for third-parties to listen to the communication.
Data transmission and storage integrity can be actively managed using on-chip hardware functions. While encryption can provide a secure means of transmitting data in a tamper-proof manner, encryption and decryption can be computationally expensive processes. Furthermore, transmission failures can be difficult to differentiate from attacks. As described previously, a fast, hardware-based error detection code can be used for data integrity. As an example, as embodied herein, an appropriately-sized error detection code for the length of the message (e.g., a 16-bit CRC) can be used, although other suitable hardware-based error detection codes can be used in accordance with the disclosed subject matter. Programming instructions that access, generate, or manipulate sensitive data can be stored in memory blocks or containers that are further protected with additional security measures, for example encryption.
As embodied herein, the analyte monitoring system 100 can employ periodic key rotation to further reduce the likelihood of key compromise and exploitation. A key rotation strategy employed 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 employ keys for downstream devices (e.g., devices that are in the field or cannot be feasibly provided updates) that are designed to be compatible with multiple generations of keys used by upstream devices. Additionally, and according to the subject matter herein, keys can be securely updated by invalidating memory blocks including out-of-date keys which are then replaced with data written to new memory. Rotation of keys can be initiated by the manufacturer or the 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 procedures for generating keys. During manufacture of sensors 110 that are intended to use the new set of keys, the manufacturer can propagate the new set of keys to newly manufactured sensors 110. The manufacturer can also push updates to deployed devices in communication with the remote server 150 to extend the new set of keys or set of procedures for generating keys to the deployed devices. As a further alternative, key rotation can be based on an agreed-upon schedule, where the devices are configured to adjust the keys used according to some time- or event-driven function.
In summary, embodiments described herein include a data receiving device for an analyte monitoring system. The data receiving device detects a disconnect 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 connection data packets from the 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 sensor control device has not been established based on connection data packets received during the scan window, the data receiving device performs iterations of a process to adjust the scan window, involving increasing a duration of the scan window to a new length that is greater than the current length and initiating the scan window based on the duration of the scan window at the new length.
In addition to the specific embodiments claimed below, the disclosed subject matter is also directed to other embodiments having any other possible combination of the dependent features claimed below and those disclosed above and in the attached figures. As such, the particular features disclosed herein can be combined with each other in other manners within the scope of the disclosed subject matter such that the disclosed subject matter can be recognized as also specifically directed to other embodiments having any other possible combinations. Thus, the foregoing description of specific embodiments of the disclosed subject matter has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosed subject matter to those embodiments disclosed.
It will be apparent to those skilled in the art that various modifications and variations can be made in the method and system of the disclosed subject matter without departing from the spirit or scope of the disclosed subject matter. Thus, it is intended that the disclosed subject matter include modifications and variations that are within the scope of the appended claims and their equivalents.
This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application No. 63/368,849, filed 19 Jul. 2022, which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63368849 | Jul 2022 | US |
