Patent ID: 12197319

DETAILED DESCRIPTION

It should be understood that the systems, devices, and methods described herein are not limited to the particular embodiments described below. Although referring to the medical field frequently, and in particular to the analyte monitoring and diabetes treatment fields, this is for the sole purpose of providing at least one embodiment. Other uses in other products, devices, systems, and methods are possible and the present subject matter is not to be limited to a medical field except as may be provided in the appended claims.

FIG.1is an illustrative view depicting an example embodiment of an in vivo-based analyte monitoring system100having a sensor control device102and a reader device120that 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 where the path140is wireless, a near field communication (NFC) protocol, RFID protocol, Bluetooth® or Bluetooth® Low Energy protocol, wireless local area network (“WLAN”) such as a Wi-Fi® network, proprietary protocol, or other protocols may be used (as will be discussed herein).

The reader device120is also capable of wired, wireless, or combined communication with a remote computer system170or server or servers over a communication path (or link)141and with other devices (e.g., a trusted computer system180) by way of a network, such as a communications network190, over a communication path (or link)142. The communication paths141and142can be part of a telecommunications network, such as a WLAN network, a local area network (LAN), a wide area network (WAN), the Internet, or other data network for uni-directional or bi-directional communication. In an alternative embodiment, the communication paths141and142can be the same path. All communications over the paths140,141, and142can be encrypted and the sensor control device102, the reader device120, the remote computer system170, and the trusted computer system180can each be configured to encrypt and decrypt those communications sent and received.

The sensor control device102can include a housing103containing an in vivo analyte monitoring circuitry and a power source (see, e.g.,FIGS.2A,2B, and2C). The in vivo analyte monitoring circuitry is electrically coupled with an analyte sensor104that extends through an adhesive patch105and projects away from the housing103. The in vivo analyte monitoring circuitry can also control the sensor. It should be noted that in this and all embodiments described herein, the sensor control device102can be alternatively referred to as a “sensor.”

An adhesive patch105contains an adhesive layer (not shown) for attachment to a skin surface of the body of the user. The sensor104is adapted to be inserted into the body of the user, where it can make contact with that user's body fluid (e.g., interstitial fluid (ISF) or blood) and be used, along with the in vivo analyte monitoring circuitry, to determine an analyte level of the user while at least a portion of the sensor is positioned in the user. That analyte level can be communicated (e.g., visually displayed) to the user, for example, on the reader device120and/or otherwise incorporated into a diabetes monitoring regime.

Also shown inFIG.1is an insertion device150that, when operated, transcutaneously positions a portion of the analyte sensor104through the user's skin and into contact with the bodily fluid, and positions the sensor control device102and the adhesive patch105onto the skin at a selected location. In certain embodiments, the sensor control device102, the analyte sensor104, and the adhesive patch105are sealed within the housing of the insertion device150before use, and in certain embodiments, the adhesive patch105itself provides a terminal seal of the insertion device150. Other devices, systems, and methods that may be used with embodiments herein, including variations of sensor control device102, are described, for example, 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.

Referring back toFIG.1, the analyte monitoring system100also includes the reader device120, which includes a display122to visually output information to the user and/or to accept an input from the user (e.g., if configured as a touch screen), and an input component121, such as a button, actuator, touch sensitive switch, capacitive switch, pressure sensitive switch, jog wheel, or other, to input data or commands to the reader device120or otherwise control the operation of the reader device120. It is noted that some embodiments may include display-less devices or devices without any user interface components. These devices may be functionalized to store data as a data logger and/or provide a conduit to transfer data from a sensor control device and/or a display-less device to another device and/or location.

In certain embodiments, the sensor control device102may be configured to store some or all of the monitored analyte related data received from the analyte sensor104in a memory during the monitoring time period, and maintain it in the memory until the usage period ends. In such embodiments, the stored data is retrieved from the sensor control device102at the conclusion of the monitoring time period, for example, after removing the analyte sensor104from the user by detaching the sensor control device102from the skin surface where it was positioned during the monitoring time period. In such data-logging configurations, the real time monitored analyte level is not communicated to the reader device120during the monitoring period, but rather, retrieved from the sensor control device102after the monitoring time period.

In certain embodiments, the input component121of the reader device120may include a microphone and the reader device120may include software configured to analyze the audio input received from the microphone, such that functions and operation of the reader device120may be controlled by voice commands. In certain embodiments, an output component of the reader device120includes a speaker (not shown) for outputting information such 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 to the sensor control device102.

In certain embodiments, the display122and the input component121may be integrated into a single component, for example a display that 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 of the reader device120by utilizing a set of pre-programmed 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, etc. 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.

The reader device120also includes one or more data communication ports123for 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, RS-232 ports, Ethernet ports, Firewire ports, or other data communication ports configured to connect to the compatible data cables. The reader device120may also include an integrated in vitro glucose meter, including an in vitro test strip port124to receive an in vitro glucose test strip for performing in vitro blood glucose measurements.

Referring still toFIG.1, the display122can be configured to display a variety of information—some or all of which may be displayed at the same or different time on the display122. The displayed information can be user-selectable so that a user can customize the information shown on a given display screen. The display122may include, but is not limited to, a graphical display138, for example, providing a graphical output of glucose values 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 a trend or directional arrow display131that indicates a rate of analyte change and/or a rate of the rate of analyte change, e.g., by moving locations on display122).

As further shown inFIG.1, the display122may also include: date display135, which can provide date information for the user; time of day information display139providing time of day information to the user; battery level indicator display133graphically showing the condition of the battery (rechargeable or disposable) of the reader device120; the sensor calibration status 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/vibratory settings icon display136for displaying the status of the audio/vibratory output or alarm state; and wireless connectivity status icon display137that provides indication of wireless communication connection with other devices such as sensor control device102, remote computer system170, and/or trusted computer system180. As additionally shown inFIG.1, the display122may further include simulated touch screen buttons125,126for accessing menus, changing display graph output configurations or otherwise for controlling the operation of reader device120.

With continued reference toFIG.1, in certain embodiments, the reader device120can be configured to output alarms, alert notifications, glucose values, etc., which may be visual, audible, tactile, or any combination thereof. In one aspect, the reader device120may 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 on display122. Further details and other display embodiments can be found in, e.g., U.S. Publication No. 2011/0193704, which is incorporated herein by reference.

Data can be sent from the sensor control device102to the reader device120at the initiative of either the sensor control device102or the reader device120. For example, in some embodiments the sensor control device102can communicate data periodically in a broadcast-type fashion, such that an eligible reader device120, if in range and in a listening state, can receive the communicated data (e.g., sensed analyte data). This is at the initiative of the sensor control device102because the reader device120does not send a request or other transmission that first prompts the sensor control device102to communicate in one embodiment. The broadcasts can occur according to a schedule that is known to both devices102and120, or can occur in a random or pseudorandom fashion, such as whenever the sensor control device102detects a change in the sensed analyte data. Further, broadcasts can occur in a repeated fashion regardless of whether each broadcast is actually received by a reader device120.

In another embodiment, the reader device120sends a transmission that prompts the sensor control device102to communicate its data to the reader device120. This is sometimes referred to as “on-demand” data transfer. An on-demand data transfer can be initiated based on a schedule stored in the memory of the reader device120, or at the behest of the user via a user interface of the reader device120. Data exchange can be accomplished using broadcasts only, on-demand transfers only, or any combination thereof.

For example, the reader device120may be configured to transmit one or more commands to the sensor control device102to initiate data transfer, and in response, the sensor control device102may be configured to wirelessly communicate stored analyte related data collected during the monitoring time period to the reader device120.

The reader device120may in turn be connected to the remote 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. The reader device120may also be connected to a trusted computer system180. In both instances, the reader device120can function as a data conduit to transfer the stored analyte level information from the sensor control device102to the remote terminal170or the trusted computer system180. In certain embodiments, the received data from the sensor control device102may be stored (permanently or temporarily) in one or more memories of the reader device120. The reader device120can also be configured as a data conduit to pass the data received from the sensor control device102to a remote terminal170. In one embodiment, the reader device120may take the form of a programmed iPhone® mobile telephone made by the Apple, Inc.

The remote terminal170may be a personal computer, a server, a laptop computer, a tablet, or other suitable data processing device. The remote terminal170can be (or include) software for data management and analysis and communication with the components in analyte monitoring system100. For example, the remote terminal170may be connected to a local area network (“LAN”), a wide area network (“WAN”), wireless local area network (“WLAN”), or other data network for unidirectional or bidirectional data communication between the remote terminal170and the reader device120. In one embodiment, the remote terminal may be nearby the reader device120and may include one or more computer terminals located at a physician's office or a healthcare facility. In other embodiments, the remote terminal170may be located at a location other than nearby the reader device120, and may be located quite far away. For example, the remote terminal170and the reader device120could be in different rooms or different buildings of the same facility. In other embodiments, they may be separated by much greater distances.

In certain embodiments, the analyte monitoring system100can also be configured to operate with a separate, optional data communication/processing device such as a data processing module160as described in U.S. Publication No. 2011/0213225, incorporated herein by reference. The data processing module160may include components to communicate using one or more wireless communication protocols such as, for example but not limited to, an infrared (IR) protocol, a Bluetooth® protocol, a Zigbee® protocol, and the 802.11 wireless LAN protocol. Additional descriptions of communication protocols including those based on the Bluetooth® protocol and/or the Zigbee® protocol can be found in U.S. Publication No. 2006/0193375, incorporated herein by reference. The data processing module160may further include communication ports, drivers, or connectors to establish wired communication with one or more of the reader device120(via communication link161), the sensor control device102(via communication link162), the remote terminal170(via communication link163), or a communication network190including, for example but not limited to, a USB connector and/or USB port, an Ethernet connector and/or port, a FireWire connector and/or port, or an RS-232 port and/or connector.

In certain embodiments, the data processing module160is programmed to transmit a polling or query signal to the sensor control device102at a predetermined time interval (e.g., once every minute, once every five minutes, or other), and in response, receive the monitored analyte level information from the sensor control device102. The data processing module160stores in its memory the received analyte level information, and/or relays or retransmits the received information to another device such as the reader device120. More specifically in certain embodiments, the data processing module160may be configured as a data relay device to retransmit or pass through the received analyte level data from the sensor control device102to the reader device120or a remote terminal (for example, over a data network such as a cellular or WiFi® data network) or both.

In certain embodiments, the sensor control device102and the data processing module160may be positioned on the skin surface of the user within a predetermined distance of each other (for example, about 1 to 12 inches (2.5 to 30 cm) or less) such that periodic communication between the sensor control device102and data processing module160is maintained. Alternatively, the data processing module160may be worn on a belt or clothing item of the user, such that the desired distance for communication between the sensor control device102and data processing module160for data communication is maintained. The housing of the data processing module160may be configured to couple to or engage with the sensor control device102such that the two devices are combined or integrated as a single assembly and positioned on the skin surface. In further embodiments, the data processing module160is detachably engaged or connected to the sensor control device102providing additional modularity such that data processing module160may be optionally removed or reattached as desired.

Both the sensor control device102and the data processing module160are candidates for having an ASIC or multiple ASICs. They may be manufactured in large quantities because both may be prescribed for numerous patients.

Referring again toFIG.1, in certain embodiments, the data processing module160is programmed to transmit a command or signal to the sensor control device102at a predetermined time interval, such as once every minute, or at any other suitable or desired programmable time interval to request analyte related data from the sensor control device102. When the data processing module160receives the requested analyte related data, it stores the received data. In this manner, the analyte monitoring system100may be configured to receive the continuously monitored analyte related information at the programmed or programmable time interval, which is stored and/or displayed to the user. The stored data in the data processing module160may be subsequently provided or transmitted to the reader device120, the remote terminal170, or the like for subsequent data analysis such as identifying a frequency of periods of glycemic level excursions over the monitored time period, or the frequency of the alarm event occurrence during the monitored time period, for example, to improve therapy related decisions. Using this information, the doctor, healthcare provider, or the user may adjust or recommend modification to the diet, daily habits and routines such as exercise, and the like.

In another embodiment, the data processing module160transmits a command or signal to the sensor control device102to receive the analyte related data in response to a user activation of a switch provided on the data processing module160or a user initiated command received from the reader device120. In further embodiments, the data processing module160is configured to transmit a command or signal to the sensor control device102in response to receiving a user initiated command only after a predetermined time interval has elapsed. For example, in certain embodiments, if the user does not initiate communication within a programmed time period, such as for example about five hours from last communication, the data processing module160may be programmed to automatically transmit a request command or signal to the sensor control device102. Alternatively, the data processing module160may be programmed to activate an alarm to notify the user that a predetermined time period has elapsed since the last communication between the data processing module160and the sensor control device102. In this manner, users or healthcare providers may program or configure the data processing module160to provide certain compliance with an analyte monitoring regimen, so that frequent determination of analyte levels is maintained or performed by the user.

The remote terminal170in certain embodiments may include one or more computer terminals located at a medical professional's office or a healthcare facility. For example, the remote terminal170may be located at a location other than the location of the reader device120although it may be nearby. Alternatively, the remote terminal may be located in a different room or rooms or different buildings, or even further apart from the reader device120.

The trusted computer system180can be within the possession of the manufacturer or distributor of the sensor control device102, either physically or virtually through a secured connection, and can be used to provide software updates to the sensor control device102and/or perform other functions with respect to the sensor control device102. The trusted computer system180can be trusted simply by virtue of it being within the possession or control of the manufacturer, such in the case where it is a typical web server. Alternatively, the trusted computer system180can be implemented in a more secure fashion such as by requiring additional password, encryption, firewall, or other Internet access security enhancements that guard against counterfeiter attacks or other unauthorized access, such as by computer hackers.

The trusted computer system180can also be referred to as a registration computer system180, or simply a computer system180. The trusted computer system180can include one or more computers, servers, networks, databases, and the like.

In certain embodiments, programmed or programmable alarm conditions may be detected for example, a detected glucose level monitored by the analyte sensor104that is outside a predetermined acceptable range indicating a physiological condition which requires attention or intervention for medical treatment or analysis such as, for example, a hypoglycemic condition, a hyperglycemic condition, an impending hyperglycemic condition or an impending hypoglycemic condition. One or more output indications may be generated by the control logic or the processor of the sensor control device102and output to the user on a user interface of the sensor control device102so that corrective action may be timely taken. If the reader device120is within communication range, the output indications or alarm data may be communicated to the reader device120whose processor, upon detection of the alarm data, can control the display122to output one or more notifications.

In certain embodiments, the control logic or microprocessors of the sensor control device102include software programs to determine future or anticipated analyte levels based on information obtained from the analyte sensor104, e.g., the current analyte level, the rate of change of the analyte level, the acceleration of the analyte level change, and/or analyte trend information, which can be determined based on a historical trend or direction of analyte level fluctuation as a function of time during a monitored time period. Predictive alarm parameters may be programmed or are programmable in the reader device120, or the sensor control device102, or both, and output to the user in advance of anticipating the user's analyte level reaching the future level. This provides the user an opportunity to take timely corrective action.

Processing of the data within the monitoring system100can be performed by one or more control logic units or processors of the reader device120, the data processing module160, the remote terminal170, the trusted computer system180, and/or the sensor control device102. Such information may be displayed as, for example, a graph (such as a line graph) to indicate to the user the current, historical, and/or predicted future analyte levels as measured and predicted by the analyte monitoring system100. Such information may also be displayed as directional arrows (for example, see the trend or directional arrow display131) or other icon(s), e.g., the position of which on the screen is relative to a reference point to indicate whether the analyte level is increasing or decreasing as well as the acceleration or deceleration of the increase or decrease in the analyte level. This 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 of the system100can 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.

The sensor control device102and data processing device160discussed above may very possibly include one or more ASICs. Both the sensor control device and the processing device can be small and light devices for attaching to a patient. The in vivo insertion device102is likely to be disposable after each use, and both may be manufactured in large quantities due to their use by many patients afflicted with the same disease. In both cases, algorithms residing in the devices for generating and/or processing biological data may change and software updates may be desirable for their ASICs.

FIGS.2A,2B, and2Care block schematic diagrams depicting example embodiments of electrical circuits that receive signals at an input, process those signals with a processor, and output data signals, each of which has a processor that is controlled by an application program stored in a read-only-memory. More specifically, each circuit shown in these figures receives input signals from an analyte sensor104at an analog front end202, processes those input signals with a processor206, and outputs data signals at an antenna211. The application program controlling the processor206is stored in a ROM203,205, and230respectively.

FIGS.2A and2Bpresent a sensor control device102having an analyte sensor104and sensor control electronics110(including analyte monitoring circuitry) that can optionally have the majority of the processing capability for rendering end-result data suitable for display to the user. InFIG.2A, a single semiconductor chip201is depicted that can be a custom application specific integrated circuit (“ASIC”). Shown within the ASIC201are certain high-level functional units, including an analog front end (“AFE”)202, power management (or control) circuitry204, a processor206, and communication circuitry208used to feed an antenna211. In this embodiment, both the AFE202and the processor206are used as analyte monitoring circuitry, but in other embodiments either circuit can perform the analyte monitoring function. The processor206can be any type of hardware processor that is capable of executing a program provided as software or in other form, including a microprocessor, a processing unit, a processing core, a control unit, a controller, or a microcontroller, to name a few.

A memory203is also included within the ASIC201ofFIG.2Aand can be shared by the various functional units present within the ASIC201, or can be distributed amongst two or more of them. The memory203can also be a separate chip. This memory203can include volatile and non-volatile memory, and this and all other embodiments of memory (or storage) herein are non-transitory (i.e., not a propagating signal) in all forms. In this embodiment, the ASIC201is coupled with a power source210, which can be a coin cell battery, or other source. The AFE202has an input that interfaces with the output of an in vivo analyte sensor104in this embodiment and receives measurement data therefrom. The AFE outputs the data to the processor206in digital form, which in turn processes the data to arrive at the end-result glucose discrete and trend values, etc. A processing application program is run in this embodiment to control the input, processing, and output of data by the ASIC. This application program is stored primarily in a read-only form on the ASIC.

The end-result or output data generated by the processor206can then be provided to the communication circuitry208of the ASIC for propagating by way of an antenna211(an output) in this embodiment, to a reader device120(shown inFIG.1) where further processing may be performed as needed by the resident software application on the reader device to display the data, or otherwise use it.

FIG.2Bis similar toFIG.2Abut instead includes two discrete semiconductor chips212and214, which can be packaged together or separately. Here, the AFE202is resident on the ASIC212. The processor206is integrated with the power management circuitry204and the communication circuitry208on the chip214. The AFE202includes a memory203and the chip214includes a memory205, which can be isolated or distributed within. In one example embodiment, the AFE202is combined with the power management circuitry204and the processor206on one chip, while the communication circuitry208is on a separate chip. In another example embodiment, both the AFE202and the communication circuitry208are on one chip, and the processor206and the power management circuitry204are 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.

In the case ofFIG.2B, each of the memories203and205of the two chips212and214respectively may include a ROM in which the majority of an application program is stored for the respective chip. In another embodiment, a single application program capable of running both chips may be stored in either or both ROM portions of both memories203or205.

Performance of the data processing functions within the electronics of the sensor control device102(FIG.1) provides the flexibility for the system100to schedule communications from the sensor control device102to the reader device120, which in turn limits the number of unnecessary communications and can provide further power savings at the sensor control device102.

FIG.2Cis a block diagram depicting another embodiment of a sensor control device102. As with the embodiments described with respect toFIGS.2A and2B, an analyte sensor104(input), an antenna211(output), and a power source210are coupled with the sensor control electronics110. Sensor control electronics110include the analog front end (“AFE”)202, the power management circuitry204, the processor206, and the communication circuitry208. Here, the sensor control electronics110are shown with the memory divided into both volatile and non-volatile memory units (or portions). Specifically, the sensor control electronics110include ROM230(non-volatile), random access memory (RAM)232(volatile), and ferroelectric RAM (FRAM)234(non-volatile). Other types of non-volatile memory can also be used, including, but not limited to, flash memory, magnetoresistive RAM (MRAM), erasable programmable read-only memory (e.g., EPROM or EEPROM), a hard disk, an optical disc, and a holographic memory.

In this and all of the embodiments described herein, the various structural and functional elements (e.g., processor256, AFE252, communication circuitry258, memory253, ROM230, RAM232, FRAM234, power management circuitry254, sensor104, serial interface229) can be configured to communicate with every other element directly (e.g., via a dedicated pathway or bus), indirectly (e.g., via one or more common or shared buses), or any combination of the two.

In certain embodiments, part or all of the application software is stored within the ROM230. Data structures within the ROM230that will be modified during use can be copied into the writable memory, e.g., the RAM232or the FRAM234. As described herein, revisions to the application software or other software components can also be stored to the FRAM234during the board assembly or test phase (i.e., after fabrication and packaging of the semiconductor chips).

Also included with the sensor control electronics110is a serial interface229. In certain embodiments, the serial interface229is for serial testing and can be configured as a boundary scan interface linked to a boundary scan architecture that permits access to the internal circuitry of the sensor control electronics110that may not otherwise be accessible after the sensor control electronics110are assembled into a semiconductor package, or onto a larger printed circuit board (PCB), and the like. The serial interface229can permit the writing of new software or programming to the sensor control electronics110, such as replacement code for code stored within the ROM230, as is described in further detail herein. By this means, the application program or programs can be revised.

In certain embodiments, the boundary scan architecture can be a Joint Test Action Group (JTAG) architecture, or other architecture conforming to IEEE 1149.1 (Standard Test Access Port and Boundary Scan Architecture), although the boundary scan architecture is not limited to such. In one embodiment where serial interface229is in a JTAG configuration (not shown), the serial interface229includes four externally accessible inputs and/or outputs (e.g., pins, pads, or connectors, and the like) that can be (or can be equivalent to) a Test Data In (TDI) input, a Test Data Out (TDO) output, a Test Clock (TCK) input, and a Test Mode Select (TMS) input. A Test Reset (TRST) can also optionally be included. The TDI can be used for inputting any data or software (not necessarily test related) into the device and the TDO can be used for outputting any data from the device. The TCK can be used as a clock and the TMS can be used to switch the architecture between various modes or state machine states. Together they can permit the serial advancement of data or software through a chain of internal registers (not shown) and into the internal circuitry and memory as needed.

The sensor control electronics110depicted inFIG.2Ccan be implemented as one single semiconductor chip or as multiple chips located on one or more PCBs. If implemented as multiple chips, the functions provided by each of AFE202, power management circuitry204, processor206, communication circuitry208, ROM230, RAM232, and FRAM234can be implemented on separate chips or can be dispersed such that each resides on more than one chip, or any combination readily recognized to those of ordinary skill in the art.

As mentioned above, all or part of the programming or software for the sensor control device102and other devices can be hardcoded, or permanently coded, within the ROM230. The software could be stored within another type of non-volatile memory as well. Regardless of the type of ROM or other non-volatile memory that is used, if the software is permanently coded, semi-permanently coded, or otherwise difficult or undesirable to revise, then the systems, devices, and methods described herein can provide an efficient, flexible, and/or cost-effective way to effectively revise that software.

Embodiments in which such permanent programming or software in a read-only memory is revised will now be described. The revision or replacement of software functions that are resident within the ROM of an integrated circuit, ASIC, or other device is discussed. In embodiments herein, the application program may be referred to as application programming or programming or application software or software, all of which are meant to indicate, e.g., primarily permanent programming that exists in a device and that includes numerous software functions. The term “function” is used broadly herein to encompass any program instruction, or sequence of instructions, that performs a specific task. In many embodiments, the function will be named and/or stored in a known location and the application software will be capable of calling that function by its name or location. Various computer languages refer to software functions using different terminology such as routines, subroutines, procedures, methods, programs, subprograms, or callable units, each of which are within the scope of the term “function” as used herein. Likewise, the systems, devices, and methods described herein are not limited to any particular programming language.

It should be understood, however, that the present subject matter can be likewise embodied in other technology, for example, including, but not limited to those in which the software functions are resident within another type of non-volatile memory other than ROM and the modification of aspects of software other than functions. In other words, those of ordinary skill in the art will readily recognize that the subject matter described and claimed herein can be used in many implementations other than that of a sensor control device having a ROM that is used in an in vivo analyte monitoring environment as described and shown herein.

FIG.7presents a system view of an embodiment of an integrated circuit which in this case is an application-specific integrated circuit700(ASIC), and the revision of its programming. The ASIC700includes a processor206, a ROM230, and random access memory702(RAM). Outside the ASIC, but connected to it, is a switch704that activates the processor206, input data706upon which the processor is to operate, and output data708produced by the processor for other uses. The input data is received at an input port710and the output data is transmitted at an output port712.

Turning now to the ROM230, an application program714is stored therein as well as original functions716that may be called and executed by the processor. Also stored in the ROM is an original function lookup data structure718that provides an identifier and an address for each of the original functions in the ROM that may be called and executed by the processor206when programmed with the application program714. The application program calls functions by function identifier in this embodiment.

Upon receiving an activation signal from the switch704, the processor206automatically accesses the ROM230and copies the original function lookup data structure718to the RAM702. In this case, and for illustrative purposes only to more clearly show an embodiment, the RAM702is shown as having two portions, the RAM1 portion720and the RAM2 portion722. In this embodiment, the processor copies the original function lookup data structure718from the ROM to the RAM1720. For purposes of clarity only, the lookup data structure in the ROM230is labeled as the “original function lookup data structure.” The lookup data structure copied to the RAM1 is labeled as the “revised function lookup data structure” and is indicated in the drawing by numeral724.

In this ASIC700, the basic input/output system or “BIOS” of the processor has been programmed to instruct the processor to automatically copy the original function lookup data structure718to the RAM1720upon activation. Similarly, the processor BIOS causes the processor to search the RAM2722for a revision lookup data structure726. If one is not found, the processor BIOS programs the processor206to access the ROM230and run the application program714. In response to a call made by the running application program for a function, usually by calling an identifier of that function, the processor will access the revised function lookup data structure724in RAM1720to locate the called identifier of that function, read the address of that function716among the functions stored in the ROM230and will execute that function as stored in the ROM230.

However, a revision lookup data structure726can be stored in the RAM2722. A revision lookup data structure may be stored during production of the ASIC700, or it may be stored at a later time, and if one is store, its accompanying revised function728are also stored in RAM2 in this embodiment. For example, a revision lookup data structure726and revised functions728may be uploaded to the ASIC through the input port710at a time where the original functions are revised. In such a case, the processor206is programmed to receive the revision lookup data structure at the input port710and store it in the RAM2726. If a revision lookup data structure already exists in the RAM2, it may be overwritten by the new revision lookup data structure, or may be deactivated and the new revision lookup data structure stored elsewhere in the RAM2, or other action may be taken to use the new revision lookup data structure, as is determined for the particular ASIC and the revisions uploaded.

In the event that the processor206locates a revision lookup data structure726in the RAM2722, the processor would compare the function identifiers and addresses of the revision lookup data structure with those identifiers and addresses in the revised function lookup data structure724that was copied from the original function data structure718in the ROM230. In the event that the revision lookup data structure includes a different address for at least one function than what is in the revised function lookup data structure, the processor will update the address for that identifier in the revised function lookup data structure to that revised address. In the embodiment ofFIG.7, that revised address would be a memory address of the RAM2722where the revised functions728are stored, rather than the original functions716stored in the ROM. In other embodiments, the revised functions can be stored elsewhere for access by the processor206.

After the revised function lookup data structure724has been revised in the case where a revision lookup data structure726exists, or is the same as the original function lookup data structure718in the case where no revisions exist, the processor206now accesses the ROM230, loads the application program714, and is thereby programmed to receive input data706, process that input data in accordance with the running application program714, and provide data output708through the output port712. As is shown, the processor206, the ROM230, and the RAM702all exist on the same ASIC700. Thus, that ASIC has effectively been reprogrammed through the use of only the RAM702on the ASIC itself. This results in a very rapid and lower cost system and allows the ASIC programming to be easily revised. No complex programmable logic arrays or other arrays of logic elements are necessary. The revised programming and the revision lookup data structure need only be uploaded to the RAM2722of the ASIC700.

FIG.3is a flow diagram depicting an example embodiment of a system and method300of revising software in a device having permanent application programming. In this case, the embodiment includes the analyte monitoring environment. In many embodiments, the method300described below can be coded in software, either generally or as one or more software functions, and can be executed by a processor, such as the processor206(and its variants) described with respect toFIGS.2A,2B, and2C. In some embodiments, the method300can be performed by a software revision function (which can also be referred to as a patch function for patching the ROM code). The method300begins with302, where the address of a function lookup data structure402(FIG.4A) is located in the ROM (e.g., the ROM230described with respect toFIG.2C). At304, the function lookup data structure402is copied from the ROM to a writable memory device (e.g., to RAM232or FRAM234as described with respect toFIG.2C).

An example embodiment of a function lookup data structure402is depicted inFIG.4A. The function lookup data structure402can include a compilation of some or all of the software functions that can be called by the permanent application software. In this embodiment, the function lookup data structure402includes an identifier410for each software function stored within the ROM230, as well as the corresponding address412, or pointer, for that software function in the ROM. The identifier can be any string of characters that is known to identify the software function, e.g., an index, or a name. Here, the function lookup data structure402includes N identifiers and the corresponding addresses.

Referring back now toFIG.3, at306, the address of a revision lookup data structure404is located within the writable non-volatile memory (e.g., the FRAM234). An example embodiment of revision lookup data structure404is depicted inFIG.4B. The revision lookup data structure404can include a compilation of an identifier410and an address414(or pointer) for one or more software functions that are intended to replace corresponding functions set forth in the function lookup data structure402and stored in the ROM230. In this embodiment, the revision lookup data structure404includes the identifier for each software function to be replaced (e.g., using only those same identifiers set forth in the function lookup data structure402) and the corresponding new address for that replacement function within the writable non-volatile memory (e.g., the FRAM234). In many instances (but not all), only a subset of the software functions set forth in the function lookup data structure402will be replaced by software functions set forth in the revision lookup data structure404. For instance, in one implementation there may be one-hundred software functions set forth in the function lookup data structure402, and only a handful of those are replaced by functions set forth in the revision lookup data structure404(e.g., functions24,46, and72in the embodiment ofFIG.4B).

The term “data structure” is used herein, such as with respect to the function and revision lookup data structures, to broadly refer to any organization of data in software or in hardware that enables the organized data to be referenced by the application software. Examples of data structures include, but are not limited to, an array, a set, a tree, a software table, a software list, a record, a database, an object, a union, a hardware lookup table, or hardware lookup list. The function lookup data structure402and the revision lookup data structure404can also be implemented as a sequence of software instructions (e.g., as a software function). It should be noted that, for ease of illustration, the data structures402and404are depicted as human readable tables inFIGS.4A and4B. Those of ordinary skill in the art will readily recognize that these data structures402and404would be implemented in machine-readable formats in many actual implementations.

Again referring back toFIG.3, at308, a first function identifier410in the revision lookup data structure404is referenced and the corresponding new address414for the replacement function is read. At310, the first function identifier is located in the copied function lookup data structure402in the writable memory and, at312, the corresponding address for that first function identifier in the writable memory is replaced with the new address for that first function taken from revision lookup data structure404. An example of a revised function lookup data structure406is shown inFIG.4C, where Address_024, Address_046, and Address_072 in the function lookup data structure402(FIG.4A) have been replaced with New_Address_024, New_Address_046, and New_Address_072 taken from the example of the revision lookup data structure404depicted inFIG.4B. Thus, the revised function lookup data structure406ofFIG.4Cincludes the same function identifiers410asFIGS.4A and4Bbut has revised the function address to replace the function address with the replacement function address ofFIG.4B. This new structure is the revised function lookup data structure724ofFIG.7.

In many embodiments, method300and the other methods described herein are performed during the initialization or startup of the sensor control device102(e.g., after being activated or powered on). This is so that any revisions to software functions716stored in the ROM230are immediately identified and implemented. After completion of the initialization or startup routine, the sensor control device102can enter a normal operation or post-initialization mode where it can begin to collect analyte data, process the data, and/or transfer it to another device for display or further analysis, as described above. While in the normal operation mode, each time a function is called in the application software714, the system will refer to the now-revised version of the function lookup data structure406(e.g., seeFIG.4C and724inFIG.7) to identify the address for the called function in the memory. The address for the called function, if that function was not revised, may reside within the ROM and the processor will execute that ROM non-revised version of the function716. Alternatively, the address for the called function, if that function was revised, may reside within the writable non-volatile memory (e.g., FRAM234) and the processor will execute the FRAM version of the function728. It should be noted that the headers for the columns of the various data structures (e.g., Function Identifiers, Function Addresses, etc.) are shown inFIGS.4A,4B, and4Cfor ease of illustration only, and can be omitted if desired.

As described above in relation toFIG.7, the initialization process of the device in which the ASIC700is used, includes revising any program or software functions if such exist. This can be done as a priority program of the ASIC. The example of a ROM BIOS was given but other ways of engaging the initialization routine may be used.

Another example embodiment of a system and method of revising software, in particular a program located on read-only memory such as in an ASIC, is depicted inFIG.5A. Here, the method500is similar to the previous method300but includes steps to verify the integrity of the data in another embodiment of the revision lookup data structure404(FIG. B) depicted inFIG.5B. A checksum502is calculated for the compiled and memory-linked revision lookup data structure404, and this checksum502is stored in the memory during the assembly or test process. The sensor control device102is then shipped to the user and, in certain embodiments, when that user activates the sensor control device102, the resident processor performs an initialization or startup routine at510.

As part of the initialization or startup routine, a number of software functions are executed, including a revision function (or patch function). At512, the revision function executes a data verification procedure. In some embodiments, this can include making reference to the revision lookup data structure504ofFIG.5Band reading a count506of the number of functions to be replaced or patched. The revision function can have at its disposal a value representing the amount of memory space that is allocated to the identifier and address of a single replacement function in the revision lookup data structure504. The revision function can utilize this value with count506to calculate the total memory space allocated to revision lookup data structure504(or a portion thereof). This calculated checksum value can then be compared to the stored checksum value502to determine if they match. If there is a match, the data can be treated as verified. If there is not a match, then the system can interpret this as a data error and report it to the application software and/or the user, and potentially enter a termination state.

A determination as to whether the data is verified is depicted as decision514. If the data is verified, then the processor can begin replacing functions and, if not, then an error can be generated at515. In this embodiment, the identifiers are configured as sequential indices. At516, it is determined if the index for the first (or next) function to be replaced in the revision lookup data structure504is less than the number of replaceable functions in the function lookup data structure402to the writable memory. If not, then the system generates an error at515. If the index is less, then at517the new address for the function to be replaced is read and, at518, that new address is written over the old address for that first function in the function lookup data structure402. At520, it is determined if there is another function to be replaced and, if so, steps514,516, and518are repeated for that next function. The process continues until all functions have been replaced or an error is generated.

Also provided herein are methods of manufacturing a sensor control device102, that can take the form of an ASIC.FIG.6Ais a flow diagram depicting an example embodiment of one such method600. At602, one or more semiconductor chips having a ROM with software hardcoded therein are produced. At604, the one or more semiconductor chips are assembled onto a PCB in a configuration where writable non-volatile memory resident within the one or more chips is not directly accessible, i.e., the memory bus and control signal leads are not present at an externally accessible interface. Then, at606, one or more replacement software functions and a revision lookup data structure are written to the writable non-volatile memory using an indirect access channel.

In one example embodiment, the indirect access channel is a serial interface229(e.g., a boundary scan interface,FIG.2C) that provides access to the memory bus and control signals for the writable non-volatile memory. In this embodiment, the replacement software functions and revision lookup data structure are serially loaded into the serial interface and iteratively loaded into the memory so that they are available to be used by the application software after execution of a revision procedure, such as those described with respect to method300and method500herein.

In another example embodiment, the indirect access channel is an RF interface through the communication circuitry208(FIG.2C). Here, the replacement software functions and the revision lookup data structure are transmitted over an RF wavelength to the communication circuitry208, which receives them and routes them to the processor206, or in other programming unit, which can then write the received software and the data structure to the writable non-volatile memory.

In many implementations, the sensor control device102of the embodiment discussed is designed to have as small a profile as possible so as not to draw notice to its presence on the user's skin and to minimize costs and power usage. Smaller size, lower cost, and lower power requirements are reasons why ASICs are used in many devices. As such, memory space can be strictly allocated.FIG.6Bdepicts an example embodiment of the FRAM234that conceptually illustrates a method of storing data thereon. Here, a first portion651of the FRAM234is reserved for the storage of data, parameters, and the like that are used by the application software in the performance of the analyte monitoring functions. One example of this data can be calibrated parameters that are individually determined for each sensor control device102during the assembly and test processes. This first portion651is located at the top, or beginning at the first address, of the FRAM234in this embodiment.

A second portion652of the FRAM234, which can be located directly following the first portion651, contains the revision lookup data structure404or504. A third portion653of the FRAM234begins at the bottom, or last address, of the FRAM234and proceeds in a reverse fashion. This third portion653can contain the replacement software functions. The revision lookup data structure404or504can alternatively be stored in the third portion653with the replacement software functions being instead stored in the second portion652. Memory layouts can vary between implementations and the second portion652need not begin immediately after a first portion651and the third portion653need not begin at the absolute bottom of the memory as shown here. As new replacement functions are generated, the corresponding entries in the revision lookup data structure404are added to the second portion652, which grows downward as shown here. Likewise, the software replacement functions themselves are stored in the third portion653, which grows in an upward fashion. During compilation and linking of the compiled code to memory locations, conflicts in the usage of the FRAM can be identified, and resolved, if possible.

Referring back toFIG.6A, upon completion of the storage of the replacement software functions and the data structure, and any remaining assembly and/or testing, then at608, the sensor control device102can be shipped or otherwise provided through distribution channels to the user.

For many of the embodiments described herein, the function lookup data structure is stored within the ROM and later revised (in the RAM) by the revision lookup data structure stored in the FRAM. In alternative embodiments, the function lookup data structure can instead be stored in the writable non-volatile memory (e.g., the FRAM) alongside the replacement software functions. In these alternative embodiments, a revision lookup data structure is not required as the most current version of the function lookup data structure is loaded into the writable non-volatile memory during the assembly or post-assembly manufacturing procedures. Thus, the need to revise the function lookup data structure is also obviated, and instead the application software and processor can proceed directly to referencing the function lookup data structure after every qualifying function call.

All embodiments described herein can be used and claimed with respect to different fields of use both within and outside of the healthcare industry. Regarding one aspect of the healthcare industry, these embodiments can be claimed as used in all variations of in vivo, in vitro, and ex vivo analyte monitoring systems described herein.

The embodiments described with respect toFIGS.6A and6Bare equally applicable to these alternative embodiments, and one of ordinary skill in the art will readily recognize that reference to the revision lookup data structure with respect toFIGS.6A and6Bcan be replaced with reference to the function lookup data structure. The storage of the function lookup data structure directly within the writable non-volatile memory may not be desired in instances where the memory capacity of the device is strictly allocated, as the function lookup data structure can be comprehensive of all or most software functions performed by the device, and can be significantly larger than the revision lookup data structure.

The embodiments described herein, and the claims thereto, are directed to patent eligible subject matter. They do not constitute abstract ideas for a myriad of reasons. One such reason is that any claim that provides for the ability to dynamically update permanent or semi-permanent programming allows the performance of the computing device to be improved, errors to be corrected, or other deficiencies rectified, which thus constitutes an improvement to the functioning of the computer itself and thus qualifies as “significantly more” than an abstract idea.

In many instances, entities are described herein as being coupled to other entities. It should be understood that 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, it should be understood that those entities can be indirectly coupled together as well unless the context clearly dictates otherwise.

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 subject matter 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.

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 scope of the claims by features, functions, steps, or elements that are not within that scope.