CROSS-REFERENCE TO RELATED APPLICATIONSThe present application claims priority to and the benefit of U.S. Provisional Patent Application Ser. No. 62/437,014, filed Dec. 20, 2016, which is incorporated by reference herein in its entirety for all purposes.
FIELDThe subject matter described herein relates to systems, devices, and methods for wireless communications in analyte monitoring devices.
BACKGROUNDThe detection and/or monitoring of analyte levels, such as glucose, ketones, lactate, oxygen, hemoglobin A1C, or the like, can be vitally important to the health of an individual having diabetes. Patients suffering from diabetes mellitus can experience complications including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and nephropathy. Diabetics are generally required to monitor their glucose levels to ensure that they are being maintained within a clinically safe range, and may also use this information to determine if and/or when insulin is needed to reduce glucose levels in their bodies or when additional glucose is needed to raise the level of glucose in their bodies.
Growing clinical data demonstrates a strong correlation between the frequency of glucose monitoring and glycemic control. Despite such correlation, many individuals diagnosed with a diabetic condition do not monitor their glucose levels as frequently as they should due to a combination of factors including convenience, testing discretion, pain associated with glucose testing, and cost.
As described in further detail below, one type of monitoring system is an in vivo analyte monitoring system, in which a sensor control device may be worn on the body of an individual that requires analyte monitoring. The sensor control device may have a small form-factor to increase comfort and convenience for the individual. The sensor control device may also be configured to wirelessly transmit analyte data to another device, on which the individual or her health care provider (HCP) can review the individual's data and make therapy decisions. Due to certain aspects of wireless communication protocols and the compact size of the sensor control device in these in vivo analyte monitoring systems, problems may arise relating to power management, signal noise interference, interoperability, data security and privacy.
For these and other reasons, needs exist for improved analyte monitoring systems, devices, and methods.
SUMMARYThe use of wireless communication protocols within an in vivo analyte monitoring system may present problems relating to power management, signal noise interference, interoperability, data security and privacy, to name a few. These problems can arise because manufacturers of sensor control devices may have little control over a user's reader devices (e.g., smartphones) and their associated operating systems. For example, a reader device's operating system may require that a sensor control device turn its communication circuitry (e.g., its transceiver) on and off at a frequent rate, which can create signal noise interference and rapid power consumption in the sensor control device. In addition, third party user interface applications on the reader device may prevent important information from being conveyed to and/or received by the user.
Furthermore, in recent years, the threat of unauthorized tracking of wireless devices has become a greater concern. For example, third parties may surreptitiously operate wireless device “trackers” at various geographical locations, which are designed to track the movement of an individual through a particular region based on an address of the wireless device. Thus, manufacturers have a need for enhanced privacy countermeasures, in particular, because in many embodiments, sensor control devices are designed to be continuously worn on the body of the user.
A number of embodiments of systems, devices and methods are provided that allow for improved power management, operation, interoperability, security and privacy for in vivo analyte monitoring systems utilizing wireless communication protocols. For example, in certain embodiments, a handheld relay device can be used to relay data indicative of a sensed analyte level between a sensor control device and one or more reader devices. In some embodiments, power latch circuitry can be used to activate devices having a test strip interface. As described herein, these embodiments and others can allow for reduced power consumption by sensor control devices and improved interoperability with a diverse range and number of reader devices and their respective operating systems. In further embodiments, advertising schemes for wireless protocols are described which can allow for increased security through encrypted analyte data carried in advertisement communications and enhanced privacy through anti-tracking routines.
Other systems, devices, methods, features and advantages of the subject matter described herein will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, devices, methods, features and advantages be included within this description, be within the scope of the subject matter described herein, and be protected by the accompanying claims. In no way should the features of the example embodiments be construed as limiting the appended claims, absent express recitation of those features in the claims.
BRIEF DESCRIPTION OF THE FIGURESThe 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. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely.
FIG. 1A is a high level diagram depicting an example embodiment of an in vivo analyte monitoring system.
FIG. 1B is a high level diagram depicting another example embodiment of an in vivo analyte monitoring system in which a handheld relay device is used.
FIG. 2A is a block diagram depicting an example embodiment of a reader device.
FIG. 2B is a block diagram depicting an example embodiment of a handheld relay device.
FIGS. 2C-D are block diagrams depicting example embodiments of a sensor control device.
FIG. 3 is a flow diagram depicting example embodiments of methods for monitoring and alarming in a handheld relay device.
FIGS. 4A-B are topology diagrams depicting examples of wireless network topologies for use with an in vivo analyte monitoring system.
FIG. 5A is a timeline diagram depicting an example embodiment of an advertising scheme for use with an in vivo analyte monitoring system.
FIG. 5B is a timeline diagram depicting another example embodiment of an advertising scheme for use with an in vivo analyte monitoring system.
FIG. 5C is a flow diagram depicting an example embodiment of a method for resolving a resolvable address in an advertisement packet.
FIGS. 6A-B are block diagrams depicting example embodiments of advertisement packets comprising analyte data.
FIG. 7A is a block diagram depicting an example embodiment of a handheld reader device with power latch circuitry.
FIG. 7B is a schematic diagram depicting an example embodiment of power latch circuitry.
DETAILED DESCRIPTIONBefore the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims.
As used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise.
The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed.
It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and substitutable with those from any other embodiment. If a certain feature, element, component, function, or step is described with respect to only one embodiment, then it should be understood that that feature, element, component, function, or step can be used with every other embodiment described herein unless explicitly stated otherwise. This paragraph therefore serves as antecedent basis and written support for the introduction of claims, at any time, that combine features, elements, components, functions, and steps from different embodiments, or that substitute features, elements, components, functions, and steps from one embodiment with those of another, even if the following description does not explicitly state, in a particular instance, that such combinations or substitutions are possible. It is explicitly acknowledged that express recitation of every possible combination and substitution is overly burdensome, especially given that the permissibility of each and every such combination and substitution will be readily recognized by those of ordinary skill in the art.
Generally, embodiments of the present disclosure are used with systems, devices, and methods for detecting at least one analyte, such as glucose, in a bodily fluid (e.g., subcutaneously within the interstitial fluid (“ISF”) or blood, within the dermal fluid of the dermal layer, or otherwise). Accordingly, many embodiments include in vivo analyte sensors structurally configured so that at least a portion of the sensor is, or can be, positioned in the body of a user to obtain information about at least one analyte of the body. It should be noted, however, that the embodiments disclosed herein can be used with in vivo analyte monitoring systems that incorporate in vitro capability, as well as purely in vitro or ex vivo analyte monitoring systems, including those systems that are entirely non-invasive.
Furthermore, for each and every embodiment of a method disclosed herein, systems and devices capable of performing each of those embodiments are covered within the scope of the present disclosure. For example, embodiments of sensor control devices are disclosed and these devices can have one or more sensors, analyte monitoring circuits (e.g., an analog circuit), memories (e.g., for storing instructions), power sources, communication circuits, transmitters, receivers, processors and/or controllers (e.g., for executing instructions) that can perform any and all method steps or facilitate the execution of any and all method steps. These sensor control device embodiments can be used and can be capable of use to implement those steps performed by a sensor control device from any and all of the methods described herein.
Likewise, embodiments of handheld relay devices and reader devices are disclosed having one or more transmitters, receivers, memories (e.g., for storing instructions), power sources, processors and/or controllers (e.g., for executing instructions) that can perform any and all method steps or facilitate the execution of any and all method steps. These embodiments of the handheld relay devices and reader devices can be used to implement those steps performed by a handheld relay device or reader device from any and all of the methods described herein.
Embodiments of trusted computer systems are also disclosed. These trusted computer systems can include one or more processors, controllers, transmitters, receivers, memories, databases, servers, and/or networks, and can be discretely located or distributed across multiple geographic locales. These embodiments of the trusted computer systems can be used to implement those steps performed by a trusted computer system from any and all of the methods described herein.
As mentioned, a number of embodiments of systems, devices, and methods are described herein that provide for improved power management, interoperability, data security and privacy for in vivo analyte monitoring systems which utilize wireless communications. These embodiments further allow for signal noise reduction and reduced power consumption by the sensor control device; centralized management of wireless connections between multiple and disparate reader devices through the use of a handheld relay device; enhanced security and privacy measures for wireless communications; to name a few features. Before describing these aspects of the embodiments in detail, however, it is first desirable to describe examples of devices that can be present within, for example, an in vivo analyte monitoring system, as well as examples of their operation, all of which can be used with the embodiments described herein.
There are various types of in vivo analyte monitoring systems. “Continuous Analyte Monitoring” systems (or “Continuous Glucose Monitoring” systems), for example, can transmit data from a sensor control device to a reader device continuously without prompting, e.g., automatically according to a schedule. “Flash Analyte Monitoring” systems (or “Flash Glucose Monitoring” systems or simply “Flash” systems), as another example, can transfer data from a sensor control device in response to a scan or request for data by a reader device, such as with a Near Field Communication (NFC) or Radio Frequency Identification (RFID) protocol. In vivo analyte monitoring systems can also operate without the need for finger stick calibration.
In vivo analyte monitoring systems can be differentiated from “in vitro” systems that contact a biological sample outside of the body (or rather “ex vivo”) and that typically include a meter device that has a port for receiving an analyte test strip carrying a bodily fluid of the user, which can be analyzed to determine the user's blood sugar level.
In vivo monitoring systems can include a sensor that, while positioned in vivo, makes contact with the bodily fluid of the user and senses the analyte levels contained therein. The sensor can be part of a sensor control device that resides on the body of the user and contains the electronics and power supply that enable and control the analyte sensing. The sensor control device, and variations thereof, can also be referred to as a “sensor control unit,” an “on-body electronics” device or unit, an “on-body” device or unit, or a “sensor data communication” device or unit, to name a few.
In vivo monitoring systems can also include one or more reader devices that receive sensed analyte data from the sensor control device either directly or through a handheld relay device, as described in further detail below. These reader devices can process and/or display the sensed analyte data, in any number of forms, to the user. These devices, and variations thereof, can be referred to as “handheld reader devices,” “reader devices” (or simply, “readers”), “handheld electronics” (or handhelds), “portable data processing” devices or units, “data receivers,” “receiver” devices or units (or simply receivers), or “remote” devices or units, to name a few. Other devices such as personal computers have also been utilized with or incorporated into in vivo and in vitro monitoring systems.
As further described herein, in vivo monitoring systems can also include a handheld relay device that relays sensed analyte data from the sensor control device to a reader device. In a general sense, the handheld relay device can include many of the same functionalities as the reader device. However, the handheld relay device may also include fewer features, such as a non-graphical user interface. In addition, because the handheld reader device and the sensor control device are often provided by the same manufacturer, the handheld reader device may also include additional features not present on reader devices. For example, the handheld relay device may be configured to communicate directly with a sensor control device using a proprietary wireless protocol, and further, can be configured to serve as a central hub from which sensed analyte data can be transmitted to one or more reader devices. Similarly, the handheld relay device can be configured to monitor itself for failure conditions according to parameters that are more rigorous or stringent than reader devices.
For reasons described with more detail below, the use of standard wireless communication protocols within an in vivo analyte monitoring system can pose challenges relating to power management, signal noise interference, interoperability, data security and privacy, to name a few. For wireless communications between a sensor control device and a reader device (e.g., a smartphone), for example, the reader device's operating system may require that the sensor control device turn its communication circuitry (e.g., its transceiver) on and off at a relatively frequent rate. This can create undesirable effects within the in vivo analyte monitoring system such as signal noise interference with sensitive analog sensor readings and rapid power consumption in the sensor control device.
As another example, the periodic release of new and updated operating system software on reader devices may present interoperability challenges in that a sensor control device may not be easily upgraded. Likewise, manufacturers of sensor control devices may have little control over reader devices, particularly where the reader device is a smartphone. In this regard, use of a reader device as a primary display device within an in vivo analyte monitoring system can be problematic in that manufacturers cannot control third party user interface applications installed on the reader device, which may obscure or impair important data, alerts and/or alarms. Thus, a need exists to ensure that sensor control devices and/or reader devices can be operated in a manner that is power efficient, does not interfere with sensor readings, and does not prevent important information from reaching the user.
Furthermore, in recent years, threats relating to the security and privacy of sensitive data communicated within a wireless in vivo analyte monitoring system, such as, for example, “man-in-the-middle” attacks and/or unauthorized tracking of wireless devices, have become a greater concern. As one example, third parties may intercept sensitive patient health information contained within wireless communications between a sensor control device and a reader device during a data transmission procedure. As another example, third parties may surreptitiously operate wireless device “trackers” at various geographical locations, which are designed to track the movement of an individual through a particular region based on an address of the wireless device. While certain wireless communication protocols have included countermeasures against such “trackers,” e.g., through the use of random and/or resolvable addresses in Bluetooth and Bluetooth Low Energy devices, these countermeasures have been shown to be inadequate. For instance, third-party trackers can be programmed to associate two or more randomly generated addresses with a particular wireless device. Based on a sequence of observable events in which a first device address disappears, followed by the appearance of a second device address, a tracker may deduce that the two device addresses correlate with a single wireless device.
The aforementioned problems, as well as others described below, are particularly amplified with regards to wireless communications in vivo analyte monitoring systems, since sensor control devices usually have a limited power supply and are designed to be continuously worn on the body of the user. The claimed solutions disclosed herein do not simply transplant a pre-existing practice or problem-solving method into a computer-based environment. Rather, these embodiments specifically address issues of power efficiency, interoperability, privacy and security that exist solely due to the environment of wireless communications within in vivo analyte monitoring systems. By way of a non-limiting example, some embodiments described herein utilize a handheld relay device between the sensor control unit and a reader device (e.g., smart phone). In these embodiments, the handheld relay device can be configured to communicate with the sensor control device using a proprietary wireless protocol, relay data with one or more reader devices, and/or install software updates relating to the various mobile operating systems of the one or more reader devices. In these example embodiments, the sensor control device can operate with reduced signal noise interference, greater power efficiency and fewer interoperability issues. In other example embodiments, to reduce the chance of “main-in-the-middle” attacks, the sensor control device can be configured to enter a state in which it exclusively accepts data and connection requests from the handheld relay device, and moreover, controls the timing interval of communications therewith. In still other example embodiments, to enhance privacy and data transmission efficiency, the sensor control device can utilize advertising schemes wherein multiple and overlapping device addresses are utilized and/or encrypted data can be placed within advertising packets. These example embodiments, as well as others described below, are necessarily rooted in the computer-based technology of wireless communications within in vivo analyte monitoring systems.
Furthermore, for all of the same reasons stated above, these solutions are directed to specific improvements in wireless communications within in vivo analyte monitoring systems, which indisputably constitute a computer-related technology. As one specific example, the use of a proprietary wireless protocol between the sensor control device and a handheld relay device enables the sensor control device to turn on and off the radio transmitter less frequently, resulting in greater power efficiency, less noise, and ultimately, improved sensor performance. Similarly, the use of a handheld relay device to interoperate with multiple reader devices allows for less consumption of power and resources on the sensor control device, and ultimately improved performance. Likewise, the use of a wireless communication advertising scheme with multiple and overlapping device addresses reflects a specific improvement in the privacy and security of data wirelessly transmitted by the sensor control device. Indeed, the elements of each embodiment described herein, when viewed both individually and as an ordered combination, amount to a significant and specific advancement in the technology of wireless communications, and in particular, the power efficiency, interoperability, security and privacy of patient data within in vivo analyte monitoring systems. For these reasons, as well as others, these embodiments are not abstract.
Example Embodiments of In Vivo Analyte Monitoring Systems
FIG. 1A is an illustrative view depicting an example of an in vivoanalyte monitoring system100A having asensor control device102 and areader device120 that communicate with each other over a local communication path (or link)140, which can be wired or wireless, and uni-directional or bi-directional. In embodiments wherepath140 is wireless, a near field communication (NFC) protocol, RFID protocol, Bluetooth or Bluetooth Low Energy protocol, Wi-Fi protocol, proprietary protocol, or the like can be used, including those communication protocols in existence as of the date of this filing or their later developed variants.
Bluetooth is a well-known standardized short range wireless communication protocol, and Bluetooth Low Energy is a version of the same that requires less power to operate. Bluetooth Low Energy (Bluetooth LE, BTLE, BLE) is also referred to as Bluetooth Smart or Bluetooth Smart Ready. BTLE is described in the Bluetooth Specification, version 4.0, published Jun. 30, 2010, and version 4.2, published Dec. 2, 2014, both of which are explicitly incorporated by reference herein for all purposes. The term “NFC” applies to a number of protocols (or standards) that set forth operating parameters, modulation schemes, coding, transfer speeds, frame format, and command definitions for NFC devices. The following is a non-exhaustive list of examples of these protocols, each of which (along with all of its sub-parts) is incorporated by reference herein in its entirety for all purposes: ECMA-340, ECMA-352, ISO/IEC 14443, ISO/IEC 15693, ISO/IEC 18000-3, ISO/IEC 18092, and ISO/IEC 21481.
Reader device120 is also capable of wired, wireless, or combined communication with aremote computer system170 over communication path (or link)141 and with trusted computer system180 throughnetwork190 and over communication path (or link)142.Communication paths141 and142 can be part of a telecommunications network, such as a Wi-Fi network, a local area network (LAN), a wide area network (WAN), the internet, or other data network for uni-directional or bi-directional communication. Trusted computer system180 can be accessed throughnetwork190. In an alternative embodiment,communication paths141 and142 can be the same path. All communications overpaths140,141, and142 can be encrypted andsensor control device102,reader device120,remote computer system170, and trusted computer system180 can each be configured to encrypt and decrypt those communications sent and received.
Variants ofdevices102 and120, as well as other components of an in vivo-based analyte monitoring system that are suitable for use with the system, device, and method embodiments set forth herein, are described in US Patent Application Publ. No. 2011/0213225 (the '225 Publication), which is incorporated by reference herein in its entirety for all purposes.
Sensor control device102 can include ahousing103 containing in vivo analyte monitoring circuitry and a power source. The in vivo analyte monitoring circuitry is electrically coupled with ananalyte sensor104 that extends through anadhesive patch105 and projects away fromhousing103.Adhesive patch105 contains an adhesive layer (not shown) for attachment to a skin surface of the body of the user. Other forms of body attachment to the body may be used, in addition to or instead of adhesive.
Sensor104 is adapted to be at least partially inserted into the body of the user, where it can make fluid contact with that user's bodily fluid (e.g., ISF, dermal fluid, or blood) and be used, along with the in vivo analyte monitoring circuitry, to measure analyte-related data of the user.Sensor104 and any accompanying sensor control electronics can be applied to the body in any desired manner. For example, also shown inFIG. 1A is an embodiment ofinsertion device150 that, when operated, transcutaneously (or subcutaneously) positions a portion ofanalyte sensor104 through the user's skin and into contact with the bodily fluid, and positionssensor control device102 withadhesive patch105 onto the skin. In other embodiments,insertion device150 can positionsensor104 first, and then accompanying sensor control electronics can be coupled withsensor104 afterwards, either manually or with the aid of a mechanical device. Other devices, systems, and methods that may be used with embodiments herein, including variations ofsensor control device102, are described, e.g., in U.S. Publication Nos. 2010/0324392, 2011/0106126, 2011/0190603, 2011/0191044, 2011/0082484, 2011/0319729, and 2012/0197222, the disclosures of each of which are incorporated herein by reference for all purposes.
After collecting the analyte-related data,sensor control device102 can then wirelessly communicate that data (such as, for example, data corresponding to monitored analyte level and/or monitored temperature data, and/or stored historical analyte related data) to areader device120 where, in certain embodiments, it can be algorithmically processed into data representative of the analyte level of the user and then displayed to the user and/or otherwise incorporated into a diabetes monitoring regime.
As shown inFIG. 1A,reader device120 includes adisplay122 to output information to the user and/or to accept an input from the user (e.g., if configured as a touch screen), and one optional input component121 (or more), such as a button, actuator, touch sensitive switch, capacitive switch, pressure sensitive switch, jog wheel or the like, to input data, commands, or otherwise control the operation ofreader device120.
In certain embodiments,input component121 ofreader device120 may include a microphone andreader device120 may include software configured to analyze audio input received from the microphone, such that functions and operation of thereader device120 may be controlled by voice commands. Voice commands can include commands to input data, power cycle a device, retrieve data fromsensor control device102, display data and/or reports, and perform other like operations. In certain embodiments, an output component ofreader device120 includes a speaker (not shown) for outputting information as audible signals. Similar voice responsive components such as a speaker, microphone and software routines to generate, process and store voice driven signals may be provided tosensor control device102.
In certain embodiments,display122 andinput component121 may be integrated into a single component, for example, where the display can detect the presence and location of a physical contact touch upon the display, such as a touch screen user interface. In such embodiments, the user may control the operation ofreader device120 by utilizing a set of preprogrammed motion commands, including, but not limited to, single or double tapping the display, dragging a finger or instrument across the display, motioning multiple fingers or instruments toward one another, motioning multiple fingers or instruments away from one another, or other gestures. In certain embodiments, a display includes a touch screen having areas of pixels with single or dual function capacitive elements that serve as LCD elements and touch sensors.
Reader device120 also includes one or moredata communication ports123 for wired data communication with external devices such as a remote terminal, e.g., a personal computer. Example data communication ports include USB ports, mini USB ports, USB Type-C ports, USB micro-A and/or micro-B ports, RS-232 ports, Ethernet ports, Firewire ports, or other similar data communication ports configured to connect to the compatible data cables.Reader device120 may also include an integrated or attachable in vitro glucose meter, including an in vitro test strip port (not shown) to receive an in vitro glucose test strip for performing in vitro blood glucose measurements.
Referring still toFIG. 1A,display122 can be configured to display a variety of information—some or all of which may be displayed at the same or at different times ondisplay122. The displayed information can be user-selectable so that a user can customize the information shown on a given display screen.Display122 may include, but is not limited to,graphical display138, for example, providing a graphical output of current analyte values in real time or over a monitored time period, which may show: markers such as meals, exercise, sleep, heart rate, blood pressure, etc.;numerical display132, for example, providing monitored glucose values (acquired or received in response to the request for the information); and trend ordirectional arrow display131 that indicates a rate of analyte change and/or a rate of the rate of analyte change, e.g., by moving locations ondisplay122.
As further shown inFIG. 1A,display122 may also include:date display135, which can provide date information for the user; time ofday information display139 providing time of day information to the user; batterylevel indicator display133 graphically showing the condition of the battery (rechargeable or disposable) ofreader device120; sensor calibrationstatus icon display134, for example, in monitoring systems that require periodic, routine or a predetermined number of user calibration events notifying the user that the analyte sensor calibration is necessary; audio/vibratorysettings icon display136 for displaying the status of the audio/vibratory output or alarm state; and wireless connectivitystatus icon display137 that provides indication of wireless communication connection with other devices such assensor control device102,remote computer system170, and/or trusted computer system180.Display122 may further include simulatedtouch screen buttons125,126 for accessing menus, changing display graph output configurations or otherwise controlling the operation ofreader device120.
In certain embodiments,reader device120 can be configured to output alarms, alert notifications, glucose values, etc., which may be visual, audible, tactile, or any combination thereof.Reader device120 may include other output components such as a speaker, vibratory output component and the like to provide audible and/or vibratory output indications to the user in addition to the visual output indication provided ondisplay122. For example, an output unit or display122 ofreader device120 may be configured to progressively increase or decrease an associated auditory or vibratory signal over a predetermined time period. The output unit ofdisplay122 of the reader device may be further configured to output one or more of a visual, auditory or vibratory signal associated with a connection status associated with another device (e.g.,sensor control device102 or handheld relay device200). Further details and other display embodiments can be found in, e.g., U.S. Publication No. 2011/0193704, which is incorporated herein by reference for all purposes.
Reader device120 can be connected to aremote terminal170, such as a personal computer, which can be used by the user or a medical professional to display and/or analyze the collected analyte data.Reader device120 can also be connected to a trusted computer system180 that can be used for authentication of a third party software application. In both instances,reader device120 can function as a data conduit to transfer the stored analyte level information from thesensor control device102 toremote terminal170 or trusted computer system180. In certain embodiments, the received data from thesensor control device102 may be stored (permanently or temporarily) in one or more memories ofreader device120.
Remote terminal170 may be a personal computer, a server terminal, a laptop computer, a tablet, or other suitable data processing device.Remote terminal170 can be (or include) software for data management and analysis and communication with the components in analyte monitoring system100. Operation and use ofremote terminal170 is further described in the'225 Publication incorporated herein. Analyte monitoring system100 can also be configured to operate with a data processing module (not shown), also as described in the incorporated '225 Publication.
Trusted computer system180 can be within the possession of the manufacturer or distributor ofsensor control device102, either physically or virtually through a secured connection, and can be used to perform authentication ofsensor control device102. Trusted computer system180 can also be used for the storage of encryption keys, e.g., identity resolution keys, which are further described below.
Referring now in further detail toreader device120, thatdevice120 can be a mobile communication device such as a mobile telephone including, but not limited to, a Wi-Fi or internet enabled smart phone, tablet, or personal digital assistant (PDA). Examples of smart phones can include those mobile phones based on a Windows® operating system, Android™ operating system, iPhone® operating system, Palm® WebOS™, Blackberry® operating system, or Symbian® operating system, with data network connectivity functionality for data communication over an internet connection and/or a local area network (LAN).
Reader device120 can also be configured as a mobile smart wearable electronics assembly, such as an optical assembly that is worn over or adjacent to the user's eye (e.g., a smart glass or smart glasses, such as Google glasses, which is a mobile communication device). This optical assembly can have a transparent display that displays information about the user's analyte level (as described herein) to the user while at the same time allowing the user to see through the display such that the user's overall vision is minimally obstructed. The optical assembly may be capable of wireless communications similar to a smart phone. Other examples of wearable electronics include devices that are worn around or in the proximity of the user's wrist (e.g., a watch, etc.), neck (e.g., a necklace, etc.), head (e.g., a headband, hat, etc.), chest, or the like.
FIG. 1B is an illustrative view depicting another example of an in vivoanalyte monitoring system100B having asensor control device102, ahandheld relay device200, and one ormore reader devices120. At a high level, in vivoanalyte monitoring system100B is similar to that ofsystem100A (FIG. 1A), except that ahandheld relay device200 can be used to relay data indicative of the sensed analyte level received fromsensor control device102 to one ormore reader devices120. In certain embodiments,handheld relay device200 can be configured to act as a hub to whichsensor control device102 can directly transmit data, and in turn,handheld relay device200 can transmit the received data to one ormore reader devices120, which can be configured as endpoints. In this regard, asensor control device102 is not required to communicate directly withreader device120 as previously shown insystem100A (FIG. 1A). Furthermore,sensor control device102 can be configured to enter into a state in which it only accepts connection requests and data requests directly fromhandheld relay device200. As described in further detail below, in situations where thesensor control device102 andhandheld relay device200 are manufactured by the same entity, a proprietary communication protocol can also be used atcommunication path143. In addition, thehandheld relay device200 may include atest strip interface224 for receiving analyte test strips and performing in vitro analyte measurements, which in turn may be visually displayed on adisplay222 of the handheld relay device, or transmitted to one ormore reader devices120.
For signal noise reduction, improved power management, enhanced security, interoperability, and other reasons, it may be advantageous to utilize ahandheld relay device200 to relay data wireless communications betweensensor control device102 and one ormore reader devices120 within the in vivoanalyte monitoring system100B ofFIG. 1B.
In one aspect,handheld relay device200 andsensor control device102 can be configured to use advertising and connection schemes in a wireless LAN, for example, that are not supported by the operating systems ofreader devices120. For example, according to the Bluetooth Low Energy (BTLE) standard protocol, each BTLE device can be configured according to a set of connection parameters, including a connection interval maximum parameter. The connection interval maximum parameter can determine how often a BTLE controller device (e.g., handheld relay device200) will ask for data from a BTLE peripheral device (e.g., sensor control device102). According to the BTLE standard protocol, the connection interval must be between 7.5 milliseconds and 4 seconds. (See “Specification of the Bluetooth System, Covered Core Package version 4.2,Volume 6” at page 76-77 (“4.5.1 Connection Events”).) Furthermore, third party manufacturers of reader devices may set their own requirements with regard to BTLE connection parameters. For example, for BTLE peripherals (e.g., sensor control devices102) communicating with Apple iOS devices, the connection interval parameter must be equal to or less than 2 seconds.
In some embodiments,handheld relay device200 can be configured to receive data transmissions fromsensor control device102 at a connection interval greater than the connection intervals allowed by mobile operating systems (e.g., iOS and Android) ofreader devices120, thereby reducing the number of times the radio transmitter ofsensor control device102 must turn on and off in a given period. This potentially reduces power consumption insensor control device102 and, moreover, can minimize signal noise interference from the radio transmitter, which can adversely impact sensitive analog sensor readings. By contrast, ahandheld relay device200 can be better suited for supportingmultiple reader devices120, because it can have a larger power supply than thesensor control device102 for the operation of its wireless communication circuitry, as well as fewer concerns regarding signal noise interference.
In further embodiments, the in vivo analyte monitoring system of100B allow for enhanced security and interoperability. For example, a proprietary wireless protocol may be used between thesensor control device102 and thehandheld relay device200, increasing the likelihood that data indicative of a sensed analyte level is transmitted from thesensor control device102 to ahandheld relay device200 in a secure and predictable manner. This can be advantageous because thesensor control device102 may have limited power, memory (e.g., for storing instructions), and processing capability (e.g., for executing instructions). Use of a proprietary communication protocol can alleviate the need for thesensor control device102 to accommodate for a variety of connection requirements attendant with the various operating systems (e.g., iOS, Android, Windows) of different reader devices, which can be taxing on asensor control device102 that may have limited resources.
Moreover, a proprietary communication protocol can offer improved security by mitigating the risk of “man-in-the-middle” attacks against thesensor control device102 and ahandheld relay device200. For example, encryption keys can be generated and exchanged betweensensor control device102 andhandheld relay device200 during a typical pairing procedure in which a communication channel is established between the two devices. One of any number of key generation algorithms, which are known in the art, can be used to generate a private key and a corresponding public key. Examples of key generation algorithms that can be used include, but are not limited to RSA algorithms such as those described in the Public-Key Cryptography Standards (PKCS). Any desired key length can be used, but keys with longer lengths will typically provide more security. For example, key lengths of 128 bits, 256 bits, 512 bits, 1024 bits, 2048 bits, and 4096 bits, as well as others, can be used.
According to the proprietary communication protocol, however, upon completion of the key exchange, the communication channel can be closed and need not remain open. Subsequently, data indicative of a sensed analyte level can be encrypted by thesensor control device102 using a private encryption key, and, in turn, decrypted by thehandheld relay device200 using a public encryption key. Accordingly,sensor control device102 enters into a state in which it exclusively accepts data and connection requests fromhandheld relay device200, and moreover, controls the timing interval of communications withhandheld relay device200.
This configuration can provide several advantages over prior modes of wireless communications in in vivo analyte monitoring systems, whereinhandheld relay device200 manages the timing intervals between communications. In those instances, wherehandheld relay device200 manages the timing of communications,sensor control device102 would be required to maintain and store previous data packets, to respond to requests fromhandheld relay device200, while concurrently compiling new data packets from analyte measurement data from the analyte sensor. This can be disadvantageous in thatsensor control device102 would require more power, storage and processing resources. In addition, simultaneous transmission and analyte measurements can have undesirable effects, such as signal noise interference with the analyte sensor. By contrast, according to some embodiments of the present disclosure, in instances wheresensor control device102 manages the timing intervals between communications,sensor control device102 can time the transmissions withhandheld relay device200 to coincide with periods in between analyte measurements. As such,sensor control device102 can be optimized to use less power, storage and processing resources, as well as avoid signal noise interference.
Furthermore, in embodiments wheresensor control device102 manages the timing intervals between communications,handheld relay device200 can discern the timing of thesensor control device102 from information in the data packets. For example,sensor control device102 can be configured to transmit data packets once per minute within a ten-second window. The precise time within the ten-second window at which the packet is sent can be determined by the packet number and the serial number ofsensor control device102. On initial connection withsensor control device102,handheld relay device200 can listen for a signal fromsensor control device102 for up to a minute. Upon receiving a first packet,handheld relay device200 can analyze the packet number and serial number ofsensor control device102, and thus discern the data transmission timing of the next packet based on a known time-hopping algorithm. In other embodiments,sensor control device102 can similarly provide life count and patch ID information according to a known time-hopping algorithm, such that thehandheld reader device200 can discern the timing ofsensor control device102 after receiving the first packet.
Data received byhandheld relay device200 can also be encrypted (in a similar manner described above with respect to data transmitted by the sensor control device102) and stored in amemory280 prior to transmission to one ormore reader devices120. Subsequently, data indicative of a sensed analyte level and the in vitro blood analyte measurements (e.g., test strip measurements) can be decrypted by thereader device120 using a public encryption key and displayed to the user.
Another example of an advantage provided through the use ofhandheld relay device200 can be increased interoperability. In particular, the frequent release of new or updated operating systems forreader devices120 may necessitate an update to devices which interoperate with the reader devices. It can be advantageous to deploy new software and/or firmware to ahandheld relay device200, instead of thesensor control device102, which may include an application-specific interface circuitry (ASIC) that cannot be easily reprogrammed.
Referring again toFIG. 1B,communications paths143 and144 between the devices shall be described in further detail.Sensor control device102 and thehandheld relay device200 can communicate with each other over a local communication path (or link)143, andhandheld relay device200 and one or more reader devices can communicate with each other over one or more local communication paths (or link)144.Handheld relay device200 can be configured to serve as a hub between thesensor control device102 and one ormore reader devices120. In this regard,handheld relay device200 can serve as a central device to accept and manage connections to endpoints (e.g., reader devices120), as well as relay the sensed analyte data received fromsensor control device102.Communication paths143 and/or144 can each be uni-directional or bi-directional. In embodiments wherepaths143 and/or144 are wireless, a near field communication (NFC) protocol, RFID protocol, Bluetooth or Bluetooth Low Energy protocol, Wi-Fi protocol, proprietary protocol or the like can be used, including those communication protocols in existence as of the date of this filing or their later developed variants. In an alternative embodiment,communications paths144 can be the same path, for example, via a broadcasting or multi-casting communication. Further, all communications overpaths143 and/or144 can be encrypted, andsensor control device102,handheld relay device200,reader devices120,remote computer system170, and trusted computer system180 can each be configured to encrypt and decrypt those communications sent and received.
As described above, a proprietary communication protocol can also be used atcommunication path143, particularly in instances where thesensor control device102 and thehandheld relay device200 are manufactured and/or supported by the same company. The proprietary communication protocol can be, for example, a variation of a standard wireless communication protocol, in which certain parameters can be configured with values which exceed a threshold minimum or maximum value in the standard protocol. As one example, for Bluetooth Low Energy devices, a connection interval maximum parameter can be implemented using a value that exceeds the 4 second maximum value that is set forth in the standard.
As shown inFIG. 1B,handheld relay device200 can include adisplay222 to output information to the user. For example, as depicted here,display222 is outputting a current glucose level of 216 mg/dl.Handheld relay device200 can also include anoptional input component221, such as a button, actuator, touch sensitive switch, capacitive switch, pressure sensitive switch, jog wheel or the like, to input data or commands tohandheld relay device200 or otherwise control the operation ofhandheld relay device200. In certain embodiments, an output component ofhandheld relay device200 includes a speaker (not shown) for outputting information as audible signals.
Handheld relay device200 also includes one or moredata communication ports223 for wired data communication with external devices such as a remote terminal, e.g., a personal computer. Example data communication ports include USB ports, mini USB ports, USB Type-C ports, USB micro-A and/or micro-B ports, RS-232 ports, Ethernet ports, Firewire ports, or other similar data communication ports configured to connect to the compatible data cables.Handheld relay device200 may also include an integrated or attachable in vitro glucose meter, including an in vitrotest strip interface224 to receive an in vitro glucose test strip for performing in vitro blood glucose measurements.
Referring still toFIG. 1B,display222 can be configured to display a variety of information—some or all of which may be displayed at the same or different time ondisplay222.Display222 may include, but is not limited to, providing a visual output of glucose values in real time or over a monitored time period; trend or directional arrow display that indicates a rate of analyte change and/or a rate of the rate of analyte change.Display222 may also include a date display; a time of day display; a battery level indicator display; an impaired screen display; an audio/vibratory settings icon display; and a wireless connectivity status icon display for providing an indication of wireless communication connection with devices such assensor control device102 andreader device120. In certain embodiments,display222 ofhandheld relay device200 has fewer functionalities relative to, for example, thedisplay122 ofreader device120. For example, as previously described,display122 andinput component121 ofreader device120 may include a graphical display, a touch screen user interface, and/or other display and input features of smart phone devices. By contrast,display222 ofhandheld relay device200, having a relatively small form factor, can be limited to a numerical display (i.e., does not have a graphical user interface), as shown inFIG. 1B, and/or one or more directional arrows to indicate a trend and/or rate of analyte change.
In certain embodiments,handheld relay device200 can be configured to output alarms, alert notifications, glucose values, etc., which may be visual, audible, tactile, or any combination thereof.Handheld relay device200 may include other output components such as a speaker, vibratory output component and the like to provide audible and/or vibratory output indications to the user in addition to the visual output indication provided ondisplay222. For example,output unit260 of handheld relay device200 (FIG. 2B) can be adapted to progressively increase or decrease an associated auditory or vibratory signal over a predetermined time period in response to a monitored condition or event.
Handheld relay device200 can be connected to one ormore reader devices120, which can be used by the user to display and/or analyze the collected analyte data. In turn, one ormore reader devices120, which can also be used by the user to display and/or analyze the collected data, can also be connected to a trusted computer system180 that can be used for authentication of a third party software application or, as another example, for the storage of data indicative of a sensed analyte level. In both instances,handheld relay device200 can function as a data conduit to transfer the stored analyte level information from thesensor control device102 to one ormore reader devices120. In certain embodiments, the received data from thesensor control device102 may be stored (permanently or temporarily) in one or more memories ofhandheld relay device200.
Referring again toFIG. 1B, it is noted that, in addition to the features, functionalities and attributes described above with respect to the in vivo analyte monitoring system of100B, thesensor control device102,reader device120,remote terminal170, and trusted computer system180, and each of the components included therewith, can each have any of the features, functionalities and attributes as described with respect to the in vivo analyte monitoring system of100A (FIG. 1A). Furthermore, although tworeader devices120 are depicted,system100B may comprise three, four, five or more similar ordissimilar reader devices120. Similarly,system100B can also comprise onereader device120.
The processing of data withinsystems100A and100B can be performed by one or more control logic units or processors of thehandheld relay device200, one ormore reader devices120,remote terminal170, trusted computer system180, and/orsensor control device102. For example, raw data measured by sensor104 (after conversion to digital form) can be algorithmically processed into a value that represents the analyte level and that is readily suitable for display to the user, and this can occur insensor control device102,handheld relay device200,reader device120,remote terminal170, or trusted computer system180. This algorithmic processing can include the calibration of the raw data, the application of environmental compensation (e.g., temperature-based adjustments), the application of a proprietary algorithm, and the like. The information derived from the raw data can be displayed in any of the manners described above on any display ofhandheld relay device200,reader device120,remote terminal170, or trusted computer system180.
The information may be utilized by the user to determine any necessary corrective actions to ensure the analyte level remains within an acceptable and/or clinically safe range. Other visual indicators, including colors, flashing, fading, etc., as well as audio indicators, including a change in pitch, volume, or tone of an audio output, and/or vibratory or other tactile indicators may also be incorporated into the outputting of trend data as means of notifying the user of the current level, direction, and/or rate of change of the monitored analyte level. For example, based on a determined rate of glucose change, programmed clinically significant glucose threshold levels (e.g., hyperglycemic and/or hypoglycemic levels), and current analyte level derived by an in vivo analyte sensor, an algorithm stored on a computer readable medium ofsystems100A and100B can be used to determine the time it will take to reach a clinically significant level and can be used to output a notification in advance of reaching the clinically significant level, e.g., 30 minutes before a clinically significant level is anticipated, and/or 20 minutes, and/or 10 minutes, and/or 5 minutes, and/or 3 minutes, and/or 1 minute, and so on, with outputs increasing in intensity or the like.
Example Embodiments of Reader DevicesFIG. 2A is a block diagram of an example embodiment of areader device120 configured as a smart phone. Here,reader device120 includes aninput component121,display122, andprocessing hardware326, which can include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips. Here,processing hardware326 includes acommunications processor322 having on-board memory323 and anapplications processor324 having on-board memory325.Reader device120 further includes anRF transceiver328 coupled with anRF antenna329, amemory330,multi-functional circuitry332 with one or more associatedantennas334, apower supply336, andpower management circuitry338.FIG. 2A is an abbreviated representation of the typical hardware and functionality that resides within a smart phone and those of ordinary skill in the art will readily recognize that other hardware and functionality (e.g., codecs, drivers, glue logic), can also be included.
Communications processor322 can interface withRF transceiver328 and perform analog-to-digital conversions, encoding and decoding, digital signal processing and other functions that facilitate the conversion of voice, video, and data signals into a format (e.g., in-phase and quadrature) suitable for provision toRF transceiver328, which can then transmit the signals wirelessly.Communications processor322 can also interface withRF transceiver328 to perform the reverse functions necessary to receive a wireless transmission and convert it into digital data, voice, and video.
Applications processor324 can be adapted to execute the operating system and any software applications that reside onreader device120, process video and graphics, and perform those other functions not related to the processing of communications transmitted and received overRF antenna329. The smart phone operating system will operate in conjunction with a number of applications onreader device120. Any number of applications (also known as “user interface applications”) can be running onreader device120 at any one time, and will typically include one or more applications that are related to a diabetes monitoring regime, in addition to the other commonly used applications that are unrelated to such a regime, e.g., email, calendar, weather, sports, games, etc. For example, the data indicative of a sensed analyte level and in vitro blood analyte measurements received by the reader device can be securely communicated to user interface applications residing inmemory325 of thereader device120. Such communications can be securely performed, for example, through the use of mobile application containerization or wrapping technologies.
Memory330 can be shared by one or more the various functional units present withinreader device120, or can be distributed amongst two or more of them (e.g., as separate memories present within different chips).Memory330 can also be a separate chip of its own.Memory330 is non-transitory, and can be volatile (e.g., RAM, etc.) and/or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.).
Multi-functional circuitry332 can be implemented as one or more chips and/or components (e.g., transmitter, receiver, transceiver, and/or other communication circuitry) that perform other functions such as local wireless communications (e.g., for Wi-Fi, Bluetooth, Bluetooth Low Energy, Near Field Communication (NFC), Radio Frequency Identification (RFID), and others) and determining the geographic position of reader device120 (e.g., global positioning system (GPS) hardware). One or moreother antennas334 are associated with thefunctional circuitry332 as needed to operate with the various protocols and circuits.
Power supply336 can include one or more batteries, which can be rechargeable or single-use disposable batteries.Power management circuitry338 can regulate battery charging and power supply monitoring, boost power, perform DC conversions, and the like.
As mentioned, thereader device120 may also include one or more data communication ports, such as USB ports, mini USB ports, USB Type-C ports, USB micro-A and/or micro-B ports, RS-232 ports, or any other wired communication ports for data communication with ahandheld relay device200,remote terminal170, trusted computer system180, orsensor control device102, to name a few.
In further embodiments,reader devices120 can be configured to receive data wirelessly overcommunication links140,144 fromsensor control device102 orhandheld relay device200. For example, thewireless communication circuitry328,334 ofreader device120 can be adapted to receive data indicative of a sensed analyte level, including a current analyte level, such as real-time analyte level information, historical analyte levels, a rate of change of an analyte level over a predetermined time period, and a rate of the rate of change of an analyte level. One ormore processors322,324 can be configured to convert the received data indicative of a sensed level into a user readable form. The converted data can be communicated to thedisplay122 for outputting information to the user in the form of one or more visual, auditory or vibratory signals.
In still a further embodiment, the user using in vivoanalyte monitoring system100A or100B (FIG. 1A or 1B) may manually input the blood glucose values using, for example, a user interface (for example, a keyboard, keypad, and the like) incorporated inreader device120. In the alternative, a user may manually input blood glucose values using, for example, a user interface incorporated in thehandheld relay device120 or aremote terminal170.
Example Embodiments of Handheld Relay DevicesFIG. 2B is a block schematic diagram depicting ahandheld relay device200, as shown inFIG. 1B, in accordance with one embodiment of the present disclosure. Referring toFIG. 2B, thehandheld relay device200 includes an analytetest strip interface224, anRF transceiver252, auser input221, atemperature detection section254, and aclock255, each of which is operatively coupled to one ormore processors257. As can be further seen from the Figure, thehandheld relay device200 also includes apower supply256 operatively coupled to a power conversion and monitoring section258. Further, the power conversion and monitoring section258 is also coupled to the one ormore processors257 of thehandheld relay device200. Moreover, also shown are aserial communication section259, and anoutput unit260, each operatively coupled to the one ormore processors257.
In one embodiment, thetest strip interface224 includes a test strip port adapted to receive a manual insertion of in vitro test strips and perform in vitro blood analyte measurements. The test strip can be used to perform an in vitro measurement of a user's glucose level. Those of ordinary skill in the art will appreciate that in vitro measurements of other analytes (e.g., ketones, lactate, hemoglobin A1C or the like) are within the scope of the present disclosure. In such a configuration,handheld relay device200 can process a fluid sample on a test strip, determine an analyte level contained therein, and display that result to a user. Various types of in vitro test strips can be suitable for use withhandheld relay device200. As a non-limiting example, test strips may be employed that only require a very small amount (e.g., one microliter or less, e.g., about 0.5 microliter or less, e.g., about 0.1 microliter or less) of applied sample to the strip in order to obtain accurate glucose information, e.g. FreeStyle® or Precision® blood glucose test strips and systems from Abbott Diabetes Care Inc.Handheld relay devices200 with in vitro monitors and test strip ports may be configured to conduct in vitro analyte monitoring with no user calibration in vitro test strips (i.e., no human intervention calibration), such as FreeStyle Lite glucose test strips from Abbott Diabetes Care Inc. Detailed description of such test strips and devices for conducting in vitro analyte monitoring is provided in U.S. Pat. Nos. 6,377,894, 6,616,819, 7,749,740, 7,418,285; U.S. Publication Nos. 2004/0118704, 2006/0091006, 2008/0066305, 2008/0267823, 2010/0094110, 2010/0094111, and 2010/0094112, and 2011/0184264, the disclosure of each of which are incorporated herein by reference for all purposes.
The in vitro analyte measurements can be communicated to theoutput unit260 for visually displaying on thedisplay222 ofhandheld relay device200, stored innon-volatile memory280, or transmitted by theRF transceiver252 ormulti-functional circuitry253 to another device, e.g., one ormore reader devices120. This manual testing of glucose can be used, for example, to calibrate sensor control unit102 (shown inFIG. 1B).
In one embodiment, theRF transceiver252 can be configured to communicate, via thecommunication links143 and144 (shown inFIG. 1B) with the communication circuitry168 (shown inFIGS. 2C and 2D) of thesensor control device102 or the RF transceivers of the one ormore reader devices120, to transmit and/or receive encoded data signals from the communication circuitry168 (shown inFIGS. 2C and 2D) for, among others, signal mixing, demodulation, and other data processing. One ormore antennas251 are associated withRF transceiver252 as needed to operate with the various protocols and circuits.
Multi-functional circuitry253 can be implemented as one or more chips and/or components (e.g., transmitter, receiver, transceiver, and/or other communication circuitry) that perform other functions such as local wireless communications (e.g., for Wi-Fi, Bluetooth, Bluetooth Low Energy, Near Field Communication (NFC), Radio Frequency Identification (RFID), and others) and determining the geographic position of handheld relay device200 (e.g., global positioning system (GPS) hardware). In certain embodiments, however, the wireless communication circuitry ofhandheld relay device200 is limited in functionality, relative toreader device120, for example, in that it does not include native Global System Mobile Communications (GSM) or Code Division Multiple Access (CDMA) functionality. In one embodiment, themulti-functional circuitry253 can be configured to communicate, via thecommunication links143 and144 (FIG. 1B) with the communication circuitry168 (shown inFIGS. 2C and 2D) of thesensor control device102 and the RF transceivers of the one ormore reader devices120, to transmit and/or receive encoded data signals from the communication circuitry168 (shown inFIGS. 2C and 2D) for, among others, signal mixing, demodulation, and other data processing. One ormore antennas261 are associated with thefunctional circuitry253 as needed to operate with the various protocols and circuits.
In a further embodiment, thehandheld relay device200 can be configured to receive data wirelessly over communication link143 fromsensor control device102. For example,wireless communication circuitry252,253 ofhandheld relay device200 can be adapted to receive data indicative of a sensed analyte level, including a current analyte level, such as real-time analyte level information, historical analyte levels, a rate of change of an analyte level over a predetermined time period, and a rate of the rate of change of an analyte level. One ormore processors257 can be configured to convert the received data indicative of a sensed level into a user readable form. The one ormore processors257 can also be configured to convert in vitro analyte measurements performed by thetest strip interface224 into a user readable format. The converted data and measurements can be communicated to theoutput unit260 for outputting information to the user in the form of one or more visual, auditory or vibratory signals.
Theinput device221 of thehandheld relay device200 is configured to allow the user to enter information into thehandheld relay device200 as needed. Thetemperature detection section254 is configured to provide temperature information of thehandheld relay device200 to the one ormore processors257, while theclock255 provides, among others, real time information to the one ormore processors257. Furthermore, theinput device221 of thehandheld relay device200 is limited in functionality, relative to thereader device120, and does not include a microphone or other voice-input functionalities.
Each of the various components of thehandheld relay device200 shown inFIG. 2B is powered by thepower supply256 which can include a battery. The battery can be a disposable, one-time use battery or a rechargeable battery (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion)) that may be recharged by a separate power supply recharging unit (not shown). Furthermore, the power conversion and monitoring section258 is configured to monitor the power usage by the various components in thehandheld relay device200 for effective power management and to alert the user, for example, in the event of power usage which renders thehandheld relay device200 in sub-optimal operating conditions. An example of such sub-optimal operating condition may include, for example, operating the vibration output mode (as discussed below) for a period of time thus substantially draining thepower supply256 while the one or more processors257 (thus, the handheld relay device200) is turned on. Moreover, the power conversion and monitoring section258 may additionally be configured to include a reverse polarity protection circuit such as a field effect transistor (FET) configured as a battery activated switch.
Theserial communication section259 in thehandheld relay device200 is configured to provide a bi-directional communication path from the testing and/or manufacturing equipment for, among others, initialization, testing, and configuration of thehandheld relay device200.Serial communication section259 can also be used to upload data to a computer, such as time-stamped blood glucose data. The communication link with an external device (not shown) can be made, for example, by cable, infrared (IR) or RF link.
Theoutput unit260 of thehandheld relay device200 is coupled to display222 and can provide, for example, numerical information for display to a user (e.g., a current glucose level). Additionally,output unit260 may also include an integrated speaker for outputting audible signals as well as to provide vibration output as commonly found in handheld electronic devices, such as mobile telephones presently available. In a further embodiment, thehandheld relay device200 also includes an electro-luminescent lamp configured to provide backlighting to theoutput unit260 for visual display in dark ambient surroundings.
Referring back toFIG. 2B, thehandheld relay device200 in one embodiment may also include a storage section such as a programmable,non-volatile memory device280 as part of the one or more processors257 (as shown here), or provided separately in thehandheld relay device200, operatively coupled to the one ormore processor257. The one ormore processors257 can be further configured to perform Manchester decoding, as well as error detection and correction upon the encoded data signals received from thesensor control unit102 via thecommunication link143.
Example Embodiments of Monitoring, Alarming and Reporting RoutinesIn some embodiments, monitoring, alarming and reporting routines can be stored in memory and executed by one or more processors of thehandheld relay device200 or areader device120. For example, a monitoring routine, stored inmemory280 ofhandheld relay device200, can be executed by one ormore processors257 to monitor the state of the wireless connections betweenhandheld relay device200 and thesensor control device102. The monitoring routine can further include a command to output a visual, audio or vibratory alarm in response to a loss of wireless connectivity with thesensor control device102. In some embodiments, for example, a monitoring routine can include the transmission of an alarm command from ahandheld relay device200 to areader device120.
Similarly, monitoring routines for failure conditions can be stored in memory of thehandheld relay device200 or the one ormore reader devices120. As described earlier, thesensor control device102 andhandheld relay device200 may be manufactured and/or sold by the same company. By contrast, reader devices120 (e.g., smartphone) can be manufactured by various third parties, and may also include any number of third party user interface applications. Thus, because the manufacturer of thehandheld relay device200 may have more control over its own devices, in some embodiments, the failure condition monitoring routines of thehandheld relay device200 can be configured with a greater degree of rigor than the failure condition monitoring routines of thereader device120. The heightened rigor for the failure condition monitoring routines on ahandheld relay device200 can comprise, for example, an increased rate of monitoring, the use of background application processing, and/or the use and prioritization of multithreaded applications.Handheld relay device200 can be configured by a manufacturer, for example, to provide a higher degree of priority for failure condition monitoring routines, in terms of memory allocation, processor usage, display usage and/or network bandwidth. By comparison, the degree of rigor (i.e., local prioritization) for failure condition monitoring routines on a reader device120 (e.g., smartphone), whose primary function may not be as a medical device, may be constrained by the mobile operating system and/or other third-party user interface applications. A failure condition monitoring routine on areader device120, for example, may be placed into background processing, or in a low-priority processing state, due to the presence of other third-party user interface applications. Similarly, the failure condition monitoring routine may enter into a suspended state and/or be unable to execute at all until it is returned to the foreground. In addition,reader devices120 may not be capable of prioritizing displayable events and/or allocating reserved network bandwidth for failure condition monitoring routines.
In some embodiments, the failure condition monitoring routine can further include a command to execute one or more predetermined fail-safe procedures in response to the detection of one or more failure conditions. Optionally, the failure conditions and fail-safe procedures may be configurable by a user ofhandheld relay device200, and may further require that the user input a passcode through theuser input device221 to confirm any changes thereto.
FIG. 3 is a flowchart diagram showing one embodiment of multiple monitoring andalarming routines350,450 for ahandheld relay device200 and areader device120. Turning to thehandheld relay device200, multiple monitoring andalarming routines350 are stored inmemory280 and executed by one ormore processors257. AtStep352,handheld relay device200 is initialized, for example, by powering on or power cycling the device. AtStep354,handheld relay device200 periodically performs a check to confirm that it has received data, e.g., data indicative of a sensed analyte level, fromsensor control device102.
AtStep356,handheld relay device200 evaluates the received data and the state of thehandheld relay device200 for the occurrence of one or more predetermined alarm conditions. In some embodiments, for example, predetermined alarm conditions may include the detection of a hypoglycemic or hyperglycemic condition, as determined from the sensed analyte data received from thesensor control device102 or the in vitro analyte measurements determined for a test sample received through a test strip port; the power reserve of thehandheld relay device200; and the wireless connectivity betweenhandheld relay device200 andsensor control device102. For example, a battery indicator icon on thedisplay222 of thehandheld relay device200 may indicate the approximate amount of power left in the device. If no predetermined alarm conditions are determined,handheld relay device200 can output a signal to the display indicating a normal status, or in the alternative, no output is sent to the display at all. If one or more predetermined alarm conditions are determined, atStep358, thehandheld relay device200 can output an alarm to thereader device120 overcommunication path144. Further, atStep360, thehandheld relay device200 can also output an alarm to the local display, for example, and can also generate an auditory or vibratory signal. As seen inFIG. 3, the monitoring and alarming routine350 can return toStep356 to continue checking for predetermined alarm conditions.
In some embodiments, thehandheld relay device200 can concurrently execute, by its one ormore processors257, instructions stored inmemory280 for the monitoring of failure conditions. Referring again to the monitoring andalarming routines350 inFIG. 3, atStep362, thehandheld relay device200 can periodically perform checks for one or more predetermined failure conditions at a first rigor. In some embodiments, for example, the predetermined failure conditions can include monitoring for an impaired display condition, a low power condition, a low data storage condition and a network communication failure condition. AtStep364,handheld relay device200 determines if one or more predetermined failure conditions has occurred. If so,handheld relay device200 can perform one or more fail-safe procedures atStep366. In some embodiments, the fail-safe procedures can include one or more of power cyclinghandheld relay device200, powering offhandheld relay device200, resettinghandheld relay device200 to factory default settings and outputting a visual notification to thedisplay222 of handheld relay device. If no failure conditions are determined, the routine can return toStep362 to continue monitoring for failure conditions at a first rigor.
Monitoring andalarm routines450 can also be stored in amemory325,330 and executed by one ormore processors324 of the one ormore reader devices120. Referring again toFIG. 3, atStep452,reader device120 is initialized, for example, by powering on or power cycling the device. AtStep454,reader device120 periodically performs a check to confirm that it has received data from thehandheld relay device200, which can include, for example, data indicative of a sensed analyte level. AtStep456, the monitoring routine can also determine if a command to output an alarm has been received from thehandheld relay device200, as previously described atStep358. If an alarm command is received, then thereader device120 can output an alarm atStep460. If an alarm command has not been received, then atStep458, thereader device120 checks for the occurrence of one or more predetermined alarm conditions, which may comprise any of the alarm conditions described above with respect to thehandheld relay device200. If an alarm condition is detected, then thereader device120 can output an alarm atStep460. If an alarm condition is not detected, then the reader device can output an indication to thedisplay122 that the current status is normal, or in the alternative, take no action and return toStep456 to continue monitoring for alarm commands and conditions.
In further embodiments, thereader device120 can concurrently execute, by its one ormore processors324, instructions stored inmemory325,330 for the monitoring of failure conditions. AtStep464,reader device120 can periodically perform checks for one or more predetermined failure conditions at a second rigor. As described earlier, in some embodiments, the degree of rigor for failure condition monitoring in thereader device120 is lower than the degree of rigor for failure condition monitoring in thehandheld relay device200. AtStep466, thereader device120 determines if one or more predetermined failure conditions has occurred. If so, thereader device120 can perform one or more fail-safe procedures atStep468. It should be understood that the predetermined failure conditions and fail-safe procedures in thereader device120 can include one or more of the same failure conditions and fail-safe procedures described above with respect to thehandheld relay device200. If no failure conditions are determined, the routine can return toStep464 to continue monitoring for failure conditions at a second rigor.
In certain embodiments,reader device120 can also be configured to store and retrieve data indicative of a sensed analyte level and in vitro blood analyte measurements, for the creation of reports. For example, a user ofreader device120 can use a user interface to choose a report from a plurality of selectable report formats. One ormore processors324 ofreader device120 can then retrieve at least a subset of the data indicative of the sensed analyte level and the in vitro blood analyte measurements based on the user's selection, organize the retrieved data, and output the selected report to display122 ofreader device120.
Example Embodiments of Sensor Control DevicesFIGS. 2C-D are block schematic diagrams depicting example embodiments ofsensor control device102 havinganalyte sensor104 and sensor electronics160 (including analyte monitoring circuitry) that can have the majority of the processing capability for rendering end-result data suitable for display to the user. InFIG. 2C, asingle semiconductor chip161 is depicted that can be a custom application specific integrated circuit (ASIC). Shown withinASIC161 are certain high-level functional units, including an analog front end (AFE)162, power management (or control)circuitry164,processor166, and communication circuitry168 (which can be implemented as a transmitter, receiver, transceiver, passive circuit, or otherwise according to the communication protocol). In this embodiment, bothAFE162 andprocessor166 are used as analyte monitoring circuitry, but in other embodiments either circuit can perform the analyte monitoring function.Processor166 can include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips.
Amemory163 is also included withinASIC161 and can be shared by the various functional units present withinASIC161, or can be distributed amongst two or more of them.Memory163 can also be a separate chip.Memory163 can be volatile and/or non-volatile memory. In this embodiment,ASIC161 is coupled withpower source170, which can be a coin cell battery, or the like.AFE162 interfaces with invivo analyte sensor104 and receives measurement data therefrom and outputs the data toprocessor166 in digital form, which in turn processes the data to arrive at the end-result glucose discrete and trend values, etc. This data can then be provided tocommunication circuitry168 for sending, by way ofantenna171, to handheld relay device200 (not shown), for example, where minimal further processing is needed by the resident software application to display the data.
FIG. 2D is similar toFIG. 2C but instead includes twodiscrete semiconductor chips162 and174, which can be packaged together or separately. Here,AFE162 is resident onASIC161.Processor166 is integrated withpower management circuitry164 andcommunication circuitry168 onchip174.AFE162 includesmemory163 andchip174 includesmemory165, which can be isolated or distributed within. In one example embodiment,AFE162 is combined withpower management circuitry164 andprocessor166 on one chip, whilecommunication circuitry168 is on a separate chip. In another example embodiment, bothAFE162 andcommunication circuitry168 are on one chip, andprocessor166 andpower management circuitry164 are on another chip. It should be noted that other chip combinations are possible, including three or more chips, each bearing responsibility for the separate functions described, or sharing one or more functions for fail-safe redundancy.
Performance of the data processing functions within the electronics of thesensor control device102 provides the flexibility forsystems100A and100B to schedule communication fromsensor control device102 to one ormore reader devices120 orhandheld relay device200, which in turn limits the number of unnecessary communications and can provide further power savings atsensor control device102.
Information may be communicated fromsensor control device102 to one ormore reader devices120 orhandheld relay device200 automatically and/or continuously when the analyte information is available, or may not be communicated automatically and/or continuously, but rather stored or logged in a memory ofsensor control device102, e.g., for later output. In another embodiment, information, including data indicative of a sensed analyte level, may be stored or logged in a memory ofhandheld relay device200 and/or one ormore reader devices120. Accordingly, in many embodiments ofsystems100A and100B, analyte information derived bysensor control device102 is made available in a user-usable or viewable form only when queried by the user such that the timing of data communication is selected by the user.
Data can be sent fromsensor control device102 tohandheld relay device200 and/or one ormore reader devices120 at the initiative of eithersensor control device102,handheld relay device200 or one ormore reader devices120. For example, in some example embodimentssensor control device102 can communicate data periodically in a broadcast-type fashion, such that an eligiblehandheld relay device200, if in range and in a listening state, can receive the communicated data (e.g., sensed analyte data). This is at the initiative ofsensor control device102 becausehandheld relay device200 does not have to send a request or other transmission that first promptssensor control device102 to communicate. Broadcasts can be performed, for example, using an active Wi-Fi, Bluetooth, or BTLE connection. The broadcasts can occur according to a schedule that is programmed within sensor control device102 (e.g., about every 1 minute, about every 5 minutes, about every 10 minutes, or the like). Broadcasts can also occur in a random or pseudorandom fashion, such as wheneversensor control device102 detects a change in the sensed analyte data. Further, broadcasts can occur in a repeated fashion regardless of whether each broadcast is actually received byhandheld relay device200.
Systems100A and100B can also be configured such that thehandheld relay device200 sends a transmission that promptssensor control device102 to communicate its data to thehandheld relay device200. Similarly,systems100A and100B can also be configured such that one ormore reader devices120 send a transmission that promptshandheld relay device200 to communicate its data to the one ormore reader devices120. This is generally referred to as “on-demand” data transfer. An on-demand data transfer can be initiated based on a schedule stored in the memory of thehandheld relay device200 or the one ormore reader devices120, or at the behest of the user via a user interface of thehandheld relay device200 or the one ormore reader devices120. For example, if the user wants to check his or her analyte level, the user could perform a scan ofsensor control device102 using an NFC, Bluetooth, BTLE, proprietary protocol or Wi-Fi connection. Data exchange can be accomplished using broadcasts only, on-demand transfers only, or any combination thereof.
Accordingly, once asensor control device102 is placed on the body so that at least a portion ofsensor104 is in contact with the bodily fluid and electrically coupled to the electronics withindevice102, sensor derived analyte information may be communicated in on-demand or broadcast fashion fromsensor control device102 tohandheld relay device200 or one ormore reader devices120. On-demand transfer can occur by first powering onhandheld relay device200 or one or more reader devices120 (or they may be continually powered) and executing a software algorithm stored in and accessed from a memory ofhandheld relay device200 or one ormore reader devices120 to generate one or more requests, commands, control signals, or data packets to send tosensor control device102. The software algorithm executed under, for example, the control ofprocessing hardware257 ofhandheld relay device200 may include routines to detect the position of thesensor control device102 relative tohandheld relay device200 to initiate the transmission of the generated request command, control signal and/or data packet.
Different types and/or forms and/or amounts of information may be sent as part of each on-demand or other transmission including, but not limited to, one or more of current analyte level information (i.e., real time or the most recently obtained analyte level information temporally corresponding to the time the reading is initiated), rate of change of an analyte over a predetermined time period, rate of the rate of change of an analyte (acceleration in the rate of change), or historical analyte information corresponding to analyte information obtained prior to a given reading and stored in a memory ofsensor control device102.
Some or all of real time, historical, rate of change, rate of rate of change (such as acceleration or deceleration) information may be sent tohandheld relay device200 or one ormore reader devices120 in a given communication or transmission. In certain embodiments, the type and/or form and/or amount of information sent tohandheld relay device200 or one ormore reader devices120 may be preprogrammed and/or unchangeable (e.g., preset at manufacturing), or may not be preprogrammed and/or unchangeable so that it may be selectable and/or changeable in the field one or more times (e.g., by activating a switch of the system, etc.). Accordingly, in certain embodiments,handheld relay device200 or one ormore reader device120 can output a current (real time) sensor-derived analyte value (e.g., in numerical format), a current rate of analyte change (e.g., in the form of an analyte rate indicator such as an arrow pointing in a direction to indicate the current rate), and analyte trend history data based on sensor readings acquired by and stored in memory of sensor control device102 (e.g., in the form of a graphical trace). Additionally, an on-skin or sensor temperature reading or measurement may be communicated fromsensor control device102 with each data communication. The temperature reading or measurement, however, may be used in conjunction with a software routine executed byhandheld relay device200 to correct or compensate the analyte measurement output to the user byhandheld relay device200, instead of or in addition to actually displaying the temperature measurement to the user.
U.S. Patent Publ. No. 2011/0213225 (the '225 Publication) generally describes components of an in vivo-based analyte monitoring system that are suitable for use with the authentication methods and hardware embodiments described herein. The '225 Publication is incorporated by reference herein in its entirety for all purposes. For other examples ofsensor control device102 andreader device120, see, e.g.,devices102 and120, respectively, as described in the incorporated '225 Publication.
Additional detailed description of the analyte monitoring system, and its various components including the functional descriptions of the transceivers are provided in U.S. Pat. No. 6,175,752 issued Jan. 16, 2001, entitled “Analyte Monitoring Device and Methods of Use”, and in application Ser. No. 10/745,878 filed Dec. 26, 2003, now U.S. Pat. No. 7,811,231, entitled “Continuous Glucose Monitoring System and Methods of Use”, each assigned to the Assignee of the present application, and each of which are incorporated herein by reference for all purposes.
Example Embodiments for Wireless Communication in In Vivo Analyte Monitoring SystemsIn all of the embodiments described herein, communications betweensensor control device102 and handheld relay device200 (as shown inFIG. 1B), can occur wirelessly using a Bluetooth, Bluetooth Low Energy (BTLE) or proprietary wireless protocol. Communications betweenhandheld relay device200 and reader device120 (as shown inFIG. 1B), or betweensensor control device102 and reader device120 (as shown inFIG. 1A), can occur wirelessly using a Bluetooth or Bluetooth Low Energy (BTLE) standard protocol. Further described below are example embodiments of Bluetooth and BTLE topologies and advertising schemes for use with in vivo analyte monitoring systems, like those described above and depicted inFIGS. 1A and 1B.
FIGS. 4A and 4B are diagrams showing example topologies for use with in vivo analyte monitoring systems, in which one or more devices communicate through a Bluetooth or BTLE protocol. Bluetooth and BTLE devices can communicate with each other in a piconet, which can comprise two or more devices occupying the same channel (or different channels), and synchronized to a common clock.FIG. 4A depicts an example embodiment of a BTLE topology withsensor control device102,handheld relay device200, andreader devices120 configured as asingle BTLE piconet410 comprising threechannels412,414, and416. In this embodiment,sensor control device102 can be configured as a slave device (S1) relative tohandheld relay device200, andhandheld relay device200 can be configured as a master device (M1) relative tosensor control device102.Reader devices120 can each be configured as master devices (M2, M3) relative tohandheld relay device200, andhandheld relay device200 can be configured as a slave device (S2, S3) toreader devices120.
Furthermore, in this embodiment,sensor control device102 can communicate withhandheld relay device200 over an advertising channel or a piconet physical channel. For example, the wireless communication circuitry ofsensor control device102 can be configured to transmit data according to a plurality of connection parameters, including a connection interval maximum parameter, a slave latency parameter, and a supervision timeout parameter. In one embodiment, the connection interval maximum parameter can be set to a value equal to or less than 2 seconds, between 2 and 4 seconds, or equal to or greater than 4 seconds. The supervision timeout parameter can also be set to a value equal to or less than 6 seconds, or greater than 6 seconds. Similarly,handheld relay device200 andreader devices120 can communicate with each other over different advertising channels or different piconet physical channels, either concurrently or non-concurrently, so as to avoid data collision. WhileFIG. 4A depicts tworeader devices120, the embodiment can include any number of similar ordissimilar reader devices120, including one device, three devices, four devices or more. Additionally, whileFIG. 4A showshandheld relay device200 as a centralized “hub” of the communication topology, areader device120,remote terminal170 or other computer device capable of wireless communications can also be used in its place.
FIG. 4B depicts an alternative embodiment of a BTLE topology, withsensor control device102,handheld relay device200, andreader devices120 configured as aBTLE scatternet420, which comprisespiconets422,424, and426, wherein each piconet comprises a separate channel. In this embodiment,sensor control device102 is configured as a slave device (S1) relative tohandheld relay device200, andhandheld relay device200 is configured as a master device (M1) relative to sensor control device.Reader devices120 are each configured as slave devices (S2, S3) relative tohandheld relay device200, and handheld relay device is configured as a master device (M2, M3) relative to eachreader device120.
As with the prior embodiment,sensor control device102 can communicate withhandheld relay device200 over an advertising channel or a piconet physical channel. Likewise, the wireless communication circuitry ofsensor control device102 can be configured to transmit data in accordance with the multiple connection parameters and options described with respect to topology410 (FIG. 4A). Furthermore, in some embodiments,sensor control device102 can be configured to operate in a discoverable state relative to thehandheld relay device200. Thehandheld relay device200 can also be configured to operate in a discoverable state relative to one ormore reader devices120. In addition, one ormore reader devices120 may be configured to operate in a discoverable state relative tohandheld relay device200.
In still other embodiments of BTLE topologies (not shown),sensor control device102 can be configured as a master device relative tohandheld relay device200, and handheld relay device can be configured as a slave device relative tosensor control device102. Similarly,reader devices120 can each be configured relative tohandheld relay device200 as described with respect to eitherFIG. 4A or 4B. That is,reader devices120 can serve as either master or slave devices relative tohandheld relay device200, and vice versa.
FIGS. 5A and 5B are timeline diagrams showing certain embodiments of Bluetooth and BTLE advertising schemes for use with in vivo analyte monitoring systems, as described above and depicted inFIGS. 1A, 1B, 4A and 4B. As described earlier, in recent years, the threat of unauthorized tracking of wireless devices has become a greater concern. For example, third parties may surreptitiously operate wireless device “trackers” at various geographical locations, which can then be used to track the movement of an individual based on a unique address of a wireless device carried by the individual. While certain wireless communication standard protocols have implemented countermeasures against such “trackers,” these countermeasures may be inadequate. For example, in accordance with the Bluetooth and BTLE standard protocols, wireless devices can be configured to periodically generate random addresses or resolvable addresses, which can be used to obscure the true identity of a wireless device and prevent it from being tracked. However, “trackers” have become more sophisticated and can associate two or more randomly generated addresses with a particular wireless device. In particular, a “tracker” may observe a sequence of events in which a first device address disappears, followed by the appearance of a second device address. By analyzing the timing of such events, a “tracker” can deduce that the two device addresses actually correlate to a single wireless device that has replaced an old device address with a new device address.
FIG. 5A is a timeline diagram depicting an embodiment of a BTLE advertising scheme that can be used to resist efforts to track asensor control device102,handheld relay device200, orreader device200 of the previously described in vivo analyte monitoring systems. In one example, the wireless communication circuitry ofsensor control device102 begins transmitting a first set of advertisement packets (AE1) at time, T1, each having a first address. The advertisement packets are transmitted periodically at a first rate (AR1) for a first predetermined period of time (P1). The first address can be a randomly generated address. Similarly, the first rate (AR1) and the first predetermined period of time (P1) can be based at least in part on a randomly generated number.
Referring still toFIG. 5A, at time, T2,sensor control device102 begins transmitting a second set of advertisement packets (AE2), wherein each packet has a second address. The second set of advertisement packets are transmitted periodically at a second rate (AR2) for a second predetermined period of time (P2). The second address (AE2) can be different from the first address (AE1), and can also be a randomly generated address. Similarly, the second rate (AR2) can be different from the first rate (AR1), and can also be based in part on a randomly generated number. The second predetermined period of time (P2) can be different from the first predetermined period of time (P1), and can also be based at least in part on a randomly generated number. At time, T3, the first predetermined period of time (P1) ends, andsensor control device102 ceases to transmit the first set of advertisement packets (AE1).Sensor control device102 continues to transmit the second set of advertisement packets (AE2) until time, T4, when the second predetermined period of time (P2) ends.
As shown by the shaded area ofFIG. 5A, the advertising scheme includes an overlapping period of time (Ov1) in which the first and second predetermined periods of time (P1, P2) are overlapping. The duration of the overlapping period of time (Ov1) can be based at least in part on a randomly generated number. In this regard, a tracker would be unable to associate the first address and second address withsensor control device102 based on the timing, initiation and cessation of the first and second advertisement packets.
FIG. 5B is a timeline diagram depicting another example embodiment of a BTLE advertising scheme that can be used to counteract efforts to track asensor control device102,handheld relay device200, orreader device120 of the previously described in vivo analyte monitoring systems. The embodiment shown inFIG. 5B is similar to that ofFIG. 5A, except that a third set of advertisement packets (AE3) are additionally transmitted at time, T4, each having a third address. The third set of advertisement packets (AE3) is transmitted periodically at a third rate (AR3) for a third predetermined period of time (P3). The third address can be a randomly generated address. Similarly, the third rate (AR3) and third predetermined period of time (P3) can be based at least in part on a randomly generated number.
Referring still toFIG. 5B, at time, T5, the second predetermined period of time (P2) ends, andsensor control device102 ceases to transmit the second set of advertisement packets (AE2). The third address can be different from the first and second addresses. The third rate (AR3) can be different from the first and second rates (AR1, AR2), and the third predetermined period of time (P3) can be also be different from the first and second predetermined periods of time (P1, P2).Sensor control device102 continues to transmit the third set of advertisement packets (AE3) until time, T6, when the third predetermined period of time (P3) ends.
As shown by the shaded areas ofFIG. 5B, the advertising schemes include two separate overlapping periods of time (Ov1, Ov2), wherein the first and second predetermined periods of time (P1, P2) are overlapping and the second and third predetermined periods of time (P2, P3) are overlapping. The duration of the second overlapping period of time (0v2) can be based at least in part on a randomly generated number. As with the previous embodiment, a tracker would be unable to associate the first, second and third addresses withsensor control device102 based on the timing, initiation and cessation of the first, second and third advertisement packets.
In the advertising scheme shown inFIG. 5B, the first and third predetermined periods of time (P1, P3) do not overlap with each other. It should be understood, however, that the advertising scheme can be configured such that the first and third predetermined periods of time (P1, P3) also overlap with each other, in addition to each overlapping with the second predetermined period of time (P2). Moreover, it should also be understood that the advertising schemes disclosed herein can also be configured such that any number of predetermined time periods (e.g., P1, P2, P3 and so on) can be either partially overlapping or completely overlapping.
In the embodiments described above, any or all of the first, second and third addresses can be 48-bit addresses, in accordance with the Bluetooth and BTLE standard protocols. Further, any or all of the first, second and third addresses can be generated by the one ormore processors166 ofsensor control device102 at the advent of a predetermined period of time. In an alternative embodiment, the addresses can be generated at other times such as, for example, during the manufacture ofsensor control device102, whensensor control device102 is powered on (or power cycled), due to a change in geographical location ofsensor control device102, or at any other time prior to the advent of a predetermined period of time. In yet another embodiment, the addresses can be generated based on the expiration of a timer routine executed bysensor control device102. Generated addresses can then be stored inmemory163,165 ofsensor control device102 and later retrieved prior to the advent of a predetermined period of time.
In further embodiments of advertising schemes, any or all of the first, second and third addresses can be resolvable addresses. In accordance with the Bluetooth and BTLE standard protocol, for example, a resolvable address can have a first portion of an address which is randomly generated, and a second portion of the address which can be resolved using an identity resolution key (IRK). The identity resolution key can be a shared secret, which can be stored in and retrieved from thememory163,165 ofsensor control device102, thememory280 ofhandheld relay device200, thememory323,325 of one ormore reader devices120, or in a trusted computer system180 accessible via anetwork190.
FIG. 5C is a flowchart diagram showing an example method in whichreader device120 attempts to determine identity ofsensor control device102 based on a first advertisement packet containing a resolvable address, as described in the above embodiments. Before describing the steps, it should be understood that one or more identity resolution keys (IRKs) can be generated by eithersensor control device102 orreader device120, and exchanged during a pairing process. One or more IRKs can be stored in amemory163,165 of thesensor control device102 and amemory323,325 of thereader device120. In an alternative embodiment, one or more IRKs can be stored in a trusted computer system180 for later retrieval byreader device120, for example. It should also be understood that although the described method refers toreader device120 as a device that can resolve the address of thesensor control device102, the same method can be utilized by thehandheld relay device200 described in prior embodiments and depicted inFIGS. 1B and 2B.
Turning toFIG. 5C, atStep572, areader device120 receives and stores the IRK during a pairing procedure withsensor control device102. In another embodiment, for example, thereader device120 can receive one or more IRKs from a trusted computer system180 over anetwork190, during a manufacturing process ofreader device120, or through any other means of communication. AtStep574,reader device120 receives a first advertisement packet, similar to the ones described above and depicted inFIGS. 5A and 5B. The first advertisement packet includes a first address that is resolvable. AtStep576,reader device120 extracts a first portion of the first advertisement packet. The extracted portion can comprise a 24-bit random part (prand). AtStep578,reader device120 retrieves an IRK and generates a hash value based on the IRK. For example, a random address hash function, stored in a memory of thereader device120, can be performed on the extracted portion (prand) of the first advertisement packet to generate a local hash value. AtStep580,reader device120 compares the generated hash value (or local hash value) with a second extracted portion of the advertisement packet. For example, the second extracted portion of the advertisement packet can be a 24-bit hash value. AtStep582, if there is a match between the generated hash value (or local hash value) and the second extracted portion, then, atStep590,reader device120 is able to resolve the address ofsensor control device102 and determine its identity. If there is not a match, atStep584,reader device120 determines if there are any additional IRKs available for retrieval. If so, atStep586,reader device120 retrieves the next IRK and performsSteps578,580 and582 in an attempt to resolve the address ofsensor control device102 using the next available IRK. If no remaining IRKs are available, the process ends atStep588, and thereader device120 is unable to resolve the address ofsensor control device102.
The steps in the flowchart ofFIG. 5C can be used for any advertisement packet containing a resolvable address, including, for example, the second and third sets of advertisement packets described above and depicted inFIGS. 5A and 5B.
In all of the embodiments described herein, communication can occur betweensensor control device102 andreader device120 and/orhandheld relay device200 using a Bluetooth or BTLE protocol. In every instance where communication betweendevices102,120 and200 is to occur, a paired connection can be established between two devices as set forth in the Bluetooth and BTLE standard protocols. However, significant time gaps can exist between the sending of communications betweendevices102 and120 (or200) and the maintenance of a paired connection, as well as the handshaking required for bringing up and tearing down paired connections, can require significant energy consumption bydevices102 and120 (or200). This is particularly problematic withsensor control device102, which typically has a small battery with a low power budget.
Therefore, to conserve power,sensor control device102 can be programmed to transmit data within the payload section of a typical advertisement packet (or channel) pursuant to the Bluetooth or BTLE standard protocols. Likewise,reader device120 and/orhandheld relay device200 can be programmed to extract this data from the payload section of the advertisement packet.
The data within the advertising packet can be any data desired for transmission fromsensor control device102. One example is data indicative of the user sensed analyte level. This data can be encrypted to maintain confidentiality and for integration within any and all of the authentication schemes described herein. For example, communications sent fromsensor control device102, can be a BTLE advertising packet containing theencrypted analyte data324 within the payload section of that advertising packet.
FIG. 6A is a block diagram depicting an example embodiment of aBTLE advertising packet602, having apreamble603, an access address604 (which together form a header section), a protocol data unit (PDU)605, and a cyclic redundancy check (CRC)606. In this embodiment,advertising packet602 is a connectable undirected advertising packet type, however,packet602 can be other types as well including a connectable directed advertising packet type, a non-connectable undirected advertising packet type, or a scannable undirected advertising packet type.
WithinPDU605 is anadvertising header section608 and anadvertising payload section610, as shown inFIG. 6B. Theencrypted analyte data324 is stored withinadvertising payload section610. The encrypted data should be smaller than the maximum payload of the advertising packet, although analyte data that is too large can be split across subsequent advertising packets if desired. Various amounts of data can be included in the advertising packet. In one embodiment, the BTLE protocol allows 22 bytes of payload to be included in an advertising packet, and thus the encrypted data is 22 bytes or less in size. (FIG. 6B shows some of the total available payload as unused.) Encryption schemes such as AES128 use a 16 byte block size, which can be accommodated within the advertising payload. Depending on the size of the measurement data for a single sensing of analyte level, at least one analyte level measurement can fit within the 16 byte encrypted block. In some embodiments, the data for two or three (or more) analyte level measurements will fit within the 16 byte encrypted block. In those embodiments,sensor control device102 can be programmed to insert the two or three (or more) most recent analyte level measurements into each 16 byte encrypted block.Reader device120 orhandheld relay device200 can then reconstruct the recent analyte level trends for the user, i.e., both current and limited historical analyte data, in case one or more prior measurements were not successfully transmitted bysensor control device102 or received byreader device120 orhandheld relay device200.
The period between subsequent advertising transmissions fromsensor control device102 can be set as desired. For example, the interval between the transmission of advertising packets can be one minute, two minutes, five minutes, 10 minutes, 15 minutes, one hour, and so forth. Furthermore, this interval can be variable so as to accommodate the user's preferences or conserve battery life, etc.
In embodiments that utilize this advertising packet approach,sensor control device102 and reader device120 (or handheld relay device200) can first establish a typical paired connection pursuant to the Bluetooth or BTLE standard protocols. This will allow the devices to become bonded so that each will recognize the other and will only conduct communications with the other. While this paired connection is established,devices102 and120 (or200) can exchange information so as to create any of the authentication regimes described herein. For example,device102 can transmit an identifier. In some embodiments, communication between multiple sensor control devices and one reader device (or one handheld relay device), or communication between multiple reader devices (or handheld relay devices) and one sensor control device is permitted. This is described in greater detail within U.S. Patent Application No. 62/001,343, filed May 21, 2014, which is incorporated by reference herein in its entirety for all purposes.
When using the advertising packets,sensor control device102 will be communicating in a unidirectional manner, with analyte data transmitted on a scheduled basis without prompting byreader device120. Shouldreader device120 need to transmit tosensor control device102, then a paired connection can be created.
Also provided herein are example embodiments of devices (and methods of operating the same) having a test strip interface that can be activated upon insertion of a test strip. These devices can includehandheld relay device200,reader device120, and/or an in vitro analyte meter. These devices can be kept in a power-off state, or a relatively low power (e.g., sleep) state, to minimize current draw from the power supply and maximize operating life. Upon insertion of a test strip, the device hardware and/or software can cause the device to exit the power-off (or low-power) state and enter a power-on (or relatively higher power) state for regular operation.
FIG. 7A is a block diagram depicting an example embodiment ofhandheld reader device200 with power latch (or connection)circuitry702. Here,power latch circuitry702 is electrically coupled withtest strip port706,power supply256, and power distribution node710 (e.g., a power plane).Test strip port706 is also coupled to a reference node701 (e.g., ground) and is configured to output an analog signal indicative of an analyte level in a sample ontest strip704 to analog front end (AFE) circuitry708, which can include conditioning circuitry (e.g., an operational amplifier) that conditions the analog signal for conversion to digital form by an A/D converter (not shown) that can be, for example, in AFE708 or in back endelectronic circuitry712.Test strip port706 and AFE708 can formtest strip interface224. Back endelectronic circuitry712, can include one ormore processors257 as well as one or more other components shown inFIG. 2B (e.g.,memory280,RF transceiver252,multi-functional circuitry252, etc.).Back end circuitry712 can be coupled withRF antenna251, an optionalsecondary switch714, andoutput unit260, which is in turn coupled withdisplay222.
Power latch circuitry702 can be configured to sense or detect the insertion oftest strip704 intotest strip port706 and, in response, connectpower supply256 to an electrical load, which can include all or part of the remaining circuitry withinrelay device200.Power latch circuitry702 can also be configured to maintain the connection ofpower supply256 aftertest strip704 is removed, and to continue to maintain the connection until instructed to disconnect, such as byprocessor257. In this manner,relay device200 can be kept in the power-off (or a relatively low power) state until needed by the user to perform an analyte measurement withtest strip704. Although described with respect tohandheld relay device200, these methods and circuits can likewise be implemented in embodiments of other devices having a test strip interface such asreader device120 or an in vitro meter.
InFIG. 7A,test strip704 can include aconductive region705 on a first end that is inserted intotest strip port706. Theconductive region705 can include, for example, one or more conductive traces or bars that electrically connect contacts intest strip port706 and create a closed circuit (e.g., a short) to reference node701 (see alsoFIG. 7B).Power latch circuit702 can sense or detect this connection toreference node701 and subsequently connect power supply256 (e.g., a rechargeable battery, a coin cell battery, or otherwise) to the device'spower node710. This power connection supplies power to each of the other circuits withindevice200 that are coupled topower node710 and allows these circuits to initiate operation or exit low-power sleep states and transition to a relatively higher power state, such as a power-on state.
FIG. 7B is a schematic diagram depicting an example embodiment ofpower latch circuitry702 and its connections in greater detail. Here,power latch circuitry702 includes a first transistor Q1 coupled with a second transistor Q2. In this embodiment, Q1 is a p-channel enhanced MOSFET and Q2 is an n-channel enhanced MOSFET, although other types of field effect transistors (FETs) can be used as well, with modifications as will be apparent to those of ordinary skill in the art. Those other transistor types can include, but are not limited to, JFET, MOSFET without bulk, MOSFET depleted, MESFET, or IGFET. Processes with low gate leakages and low drain-source leakages are particularly suitable for use with the control circuit embodiments described herein.
The drain of Q1 is connected topower node710 and the source of Q1 is connected topower source256 and a first end of resistor R1. The second end of R1 is connected to the gate of Q1, the drain of Q2, and a first end of resistor R2 (represented by node720). The source of Q2 is connected toreference node701 and the gate of Q2 is connected to a first end of resistor R3 and node722, which can receive a signal fromprocessor257. Resistor R3 is coupled between the gate of Q2 andreference node701.
Test strip port706 communicates with AFE708 through node724. The potential connection ofconductive region705 with corresponding contacts withintest strip port706 is visualized here as a switch707. (In other embodiments, the insertion ofstrip704 can trigger an actual switch to signal insertion.) In this embodiment, insertion ofstrip704 effectively closes switch707, and connects one end of R2 to reference (ground)node701 and pullsnode720 low, which biases the gate of Q1 towards a low voltage (e.g., a digital “0”). This activates Q1 (e.g., allows current to flow across the drain and source) and connectspower supply256 topower distribution node710. Each circuit connected topower node710 can then draw current fromsupply256, includingback end electronics712 andprocessor257.Processor257 can then enter its power-on (or relatively high power) state, perform an initialization routine if necessary, and generate a latch signal at node722.
The latch signal at node722 is a high voltage signal in this embodiment (e.g., a digital “1”) and activates Q2, which in turnfurther biases node720 towards a low voltage. At this point,circuit702 can be maintained in its power-supply connected state, such that removal of strip704 (and opening of switch707) will not disconnectpower supply256 frompower node710. Although not shown, a user accessible switch can also be coupled betweennode720 and ground, such that the user can cause connection ofsupply256 and activatedevice200 without the insertion ofstrip704.
In many embodiments R1 is chosen to have a value greater than R2. A high value for R1 minimizes leakage current through Q2. R3 assists in pulling node722 towards the low voltage ofreference node701 whenprocessor257 is disconnected, to prevent inadvertent activation of Q2. The embodiment ofFIG. 7B is described as functioning with signals of various voltage polarities (e.g., high and low), but those polarities are used only as an example and the same or similar functionality can be achieved by implementingcircuit702 to operate with polarity levels opposite to those described here.
After being activated,handheld relay device200 can perform various tasks. Wireless communication circuitry ofrelay device200 can transmit an attempt to establish a communication link with another device (e.g.,sensor control device102 or reader device120), for example, by initiating the transmission of an advertising signal according to a Bluetooth or BTLE protocol, and negotiate establishment of the wireless link. This can occur directly as a result of connection of the power supply to the wireless communication circuitry (through node710), or indirectly as a result ofprocessing circuitry257 instructing or otherwise causing the wireless communication circuitry to transmit the attempt.
Relay device200 can also begin the steps to conduct a sample measurement, such as by notifying (audibly, visually, through vibration, etc.) the user to dosestrip704, monitoring for strip fill, notifying the user when enough blood has been applied, performing the analyte measurement, displaying the result, and communicating the results to another device (e.g., tosensor control device102 for calibration or to reader device120). In some embodiments,relay device200 does not include a graphical display, or lacks a display altogether, and upon establishing the connection,reader device120 is used as the user interface to communicate with the user and control (or assist in controlling) the execution of the various sample measurement steps, and then display the measurement results.
Processor257 maintains control overlatch circuit702 via the latching signal applied to node722.Processor257, executing instructions from memory, can disconnectpower supply256 by changing the polarity of the latching signal at node722 from high to low. For example,processor257 can have a “time-out” function and can monitor the amount of time that, for example, has passed since insertion ofstrip704, since completion of the measurement, since display of the results, or since the last user action was taken, and upon reaching a maximum time duration of time, then change the polarity of the latching signal to disconnectsupply256.
Referring back toFIG. 7A,optional switch714 is coupled withback end electronics712 and can be used to resetdevice200. For example, if the communication link (e.g., BTLE) betweenrelay device200 and another device is lost, then the user can useswitch714 to reset back end electronics712 (or a sub-component thereof, such asprocessor257 or the communication circuitry) to reestablish the communication link.
The embodiments described with respect toFIGS. 7A and 7B can offer a number of improvements over conventional devices. For example, one such improvement is the increase in operating life achieved by enabling device activation upon insertion of a test strip, and by enabling device deactivation upon removal of the test strip or subsequently thereafter under the control of processing circuitry or a timer. The increase in operating life can be achieved by minimizing the draw of current from the power supply to only those times when the device is in use, and by keeping all or a majority of the device circuitry in the power-off (or low power) state during those times when the device is not being used.
In many instances entities are described herein as being coupled to other entities. The terms “coupled” and “connected” (or any of their forms) are used interchangeably herein and, in both cases, are generic to the direct coupling of two entities (without any non-negligible (e.g., parasitic) intervening entities) and the indirect coupling of two entities (with one or more non-negligible intervening entities). Where entities are shown as being directly coupled together, or described as coupled together without description of any intervening entity, those entities can be indirectly coupled together as well unless the context clearly dictates otherwise.
While the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that these embodiments are not to be limited to the particular form disclosed, but to the contrary, these embodiments are to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be recited in or added to the claims, as well as negative limitations that define the inventive scope of the claims by features, functions, steps, or elements that are not within that scope.