Patent Description:
Medication adherence is the act of timely filling or refilling prescriptions for medications. Medication compliance is the act of taking medication on schedule or as prescribed by a physician. According to the National Council on Patient Information and Education, poor medication adherence can lead to unnecessary disease progression and complications, reduced functional abilities and quality of life, additional medical costs and physician visits, increased use of expensive, specialized medical resources, and unneeded medication changes. Medication noncompliance can also lead to these and other adverse effects-the average length of hospital stays due to medication noncompliance is <NUM> days. In the United States, <NUM> percent of people are <NUM>% compliant (i.e., do not take their medication at all) even after they fill the prescription (i.e., are adherent).

There are a number of reasons why people are nonadherent and/or noncompliant with their medication regimen. The various factors that interfere with medication adherence and compliance include: social/economic-related factors such as age, race, economic status, literacy and costs; individual factors such as forgetfulness, treatment anxiety, misunderstood instructions and fear of addiction; medication-related factors such as the length or complexity of the treatment and the side-effects of the medication; and condition-related factors such as comorbidities and disabilities, and the overall severity of the condition.

By some estimates, up to <NUM>% of patients are noncompliant to some extent, making it difficult for doctors to assess if a medication regimen is effective. If the patient is not accurately or truthfully reporting his or her compliance, doctors do not have a means of obtaining more accurate information. Furthermore, patient tracking of which medications to take and when can be cumbersome and can be confusing for some patients.

There are various techniques and systems that try and improve patient adherence and/or compliance. For instance, some devices have been developed for mounting on pill bottles, including for example, devices that detect opening and closing of the device and alert a patient when to take a medication using a timer. Although, these prior art approaches provide at least some means to improve medication adherence and compliance, there is much room for significant advancement and improvement in the technology in order to reduce the cost and friction to the patient while improving the functionality.

<CIT> relates to a medication administration system for informing a medication administration time using real time communication to a patient.

<CIT> discloses a timer device incorporated into the cap of a medication bottle.

<CIT> discloses a timed medication container that sounds an alarm from the cap of a medication bottle when medication needs to be taken.

Embodiments of the present disclosure include systems and methods for monitoring medical adherence and compliance. Embodiments of this disclosure include, for example, medication containers (e.g., pill packages, bottles, etc.) with beacon transponders incorporated into the packaging (e.g., a cap or cover).

According to one aspect of the invention, there is provided a medication monitoring system as set out in claim <NUM>. The medication monitoring system includes a medication container and a cover. The medication monitoring system also includes a beacon system. The beacon system includes a beacon that transmits a wireless signal when the cover is removed from the medication container.

According to another aspect of the invention, there is provided a method for monitoring medication adherence and compliance as set out in claim <NUM>. The method includes detecting when a cover of a medication container is removed from the medication container. The method also includes transmitting based on the detection, a wireless signal from a beacon to a remote device, which indicates the opening of the medication container.

The beacon system includes two electrical contacts, and a rim of the medication container includes a conductor that connects the two electrical contacts when the cover is installed on the medication container.

Additional features and advantages will be set forth in part in the description that follows, and in part will be obvious from the description, or may be learned by practice of the disclosed embodiments. The features and advantages of the disclosed embodiments will be realized and attained by the elements and combinations particularly pointed out in the appended claims.

It is to be understood that both the foregoing general description and the following detailed description are examples and explanatory only and are not restrictive of the disclosed embodiments as claimed.

The accompanying drawings constitute a part of this specification. The drawings illustrate several embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosed embodiments as set forth in the accompanying claims.

The disclosed embodiments relate to medication containers (e.g., bottles) including beacons signaling when a medication container has been opened by a user. As a result, the beacon's signals can be monitored to indicate patient adherence and compliance with a medical regimen.

Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Where possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

<FIG> depicts an exemplary embodiment of a medication adherence and compliance system <NUM>, which in an illustrative embodiment may be a medication container, for example, a bottle <NUM> and a cover, for example, a cap <NUM>, and a beacon system <NUM>. Bottle <NUM> may be used to contain a medication (e.g., pills, tablets, capsules, suppositories, ampoules, subpackets of powder, etc.). Beacon system <NUM> may be designed to transmit a signal <NUM> to a remote device <NUM> when cap <NUM> is removed from bottle <NUM>, which may be considered an indication the patient has taken a dose of the medication.

While shown in <FIG> as a medication bottle <NUM>, other medication containers can be employed, including for example, droppers (e.g., eye), tubes, medication packets, ammo-packs, and other suitable medication containers. As shown in <FIG>, beacon system <NUM> may be associated with cap <NUM>. For example, beacon system <NUM> may be housed within or attached to cap <NUM>. In some embodiments, beacon system <NUM> may be molded into the material (e.g., plastic) of cap <NUM>. In other embodiments, beacon system <NUM> be attachable (e.g., fixedly or releasably) to cap <NUM>. In other embodiments, beacon system <NUM> may be associated with bottle <NUM> and/or cap <NUM>. In some embodiments, beacon system <NUM> may be incorporated into bottle <NUM> and/or cap <NUM> during manufacturing of the component(s). Beacon system <NUM> may be designed as described herein, such that the cost is sufficiently low that it can be incorporated into bottle <NUM> and/or cap <NUM> and be disposable with bottle <NUM> and/or cap <NUM> without being cost prohibitive. In some embodiments, cap <NUM> housing beacon system <NUM> may be reused by moving cap <NUM> from an empty bottle <NUM> to a new bottle when the medication prescription is refilled.

Turning to <FIG>, a schematic representation of beacon system <NUM> according to an example embodiment of the present disclosure is shown. As shown in <FIG>, beacon system <NUM> may be located within cap <NUM>. Beacon system <NUM> may include a beacon <NUM>. In some illustrative embodiments, beacon <NUM> may be a BLUETOOTH, BLUETOOTH Smart, BLUETOOTH <NUM>, or BLUETOOTH Low Energy (BLE) beacon. In other embodiments, beacon <NUM> may use other protocols, for example, beacon <NUM> may use passive WiFi, ZIGBEE, 6LoWPAN or Z-Wave.

In some embodiments, beacon <NUM> may include an internal power source, as will be described in further detail below, or in other embodiments beacon system <NUM> may include a separate power source (not shown) operatively connected to beacon <NUM>. For example, the power source may be a battery, capacitor, or other power storage device.

Beacon system <NUM> may also include electrical contacts <NUM> operatively connected to beacon <NUM> and configured to be operatively connected to a conductive strip <NUM>. In some embodiments, as shown in <FIG>, conductive strip <NUM> may be positioned along the rim of bottle <NUM>. Conductive strip <NUM> may extend part way or all the way around the rim of bottle <NUM>. In some embodiments, the rim or all of bottle <NUM> may be formed using a conductive plastic or polymer (e.g., carbon filled thermoplastic elastomer), thus enabling the conductive strip <NUM> to be incorporated into bottle <NUM> as part of the initial manufacturing (e.g., injection molding) of bottle <NUM>.

Beacon system <NUM> may be designed such that when cap <NUM> is screwed onto bottle <NUM>, as shown illustrated in <FIG>, electrical contacts <NUM> contact conductive strip <NUM>. And when conductive strip <NUM> is contacting electrical contacts <NUM>, a closed circuit that "shorts" the electrical contacts <NUM> may be formed. For example, electrical contacts <NUM> may be connected to an input (e.g., a reset input) of beacon <NUM> and ground or other connection. Therefore, when cap <NUM> is installed on bottle <NUM>, conductive strip <NUM> can short electrical contacts <NUM> such that beacon <NUM> is held in reset. When in reset, beacon <NUM> may remain in low-power standby mode, but when cap <NUM> is removed and conductive strip <NUM> interrupts the "short" circuit the reset can be disengaged. With the reset is disengaged, beacon <NUM> can wake up and begin transmitting signal <NUM>, as will be described in detail further herein. Thus, when cap <NUM> is removed from bottle <NUM>, the short circuit is broken, which is detected by beacon <NUM>, causing beacon <NUM> to transmit signal <NUM> indicating that bottle <NUM> has been opened.

Other cap designs are also contemplated. For example, <FIG> shows a cross-sectional perspective view of another embodiment of a cap <NUM>' installed on bottle <NUM> that may be designed to detect the removal of cap <NUM>' from bottle <NUM>. Cap <NUM>' may include a liner <NUM> that may be contained within cap <NUM>' and designed to span the opening of bottle <NUM> and cover the rim of bottle <NUM> when cap <NUM>' is secured to the top, as shown in <FIG>. Liner <NUM> may be designed to slide up or down within cap <NUM>' when cap <NUM>' is secured to or removed from bottle <NUM>. For example, when cap <NUM>' is removed from bottle <NUM>, liner <NUM> may slide down to the bottom of cap <NUM>' where an outer ring of liner <NUM> may rest on a ledge, tabs, clips, or other feature that may extend in from an outer wall of cap <NUM>'. In some embodiments, liner <NUM> may be designed to slide down to the bottom of cap <NUM>' as a result of gravity. In some other embodiments, cap <NUM>' may include a spring <NUM> that forces liner <NUM> to slide down cap <NUM>' when cap <NUM>' is removed from bottle <NUM>. When cap <NUM>' is screwed on to bottle <NUM>, the rim of bottle <NUM> will apply a force on liner <NUM> causing it to slide up into cap <NUM>'. For embodiments with spring <NUM>, the force created by screwing cap <NUM>' on to bottle <NUM> may be sufficient to overcome the force applied by spring <NUM>.

Cap <NUM>' may also include a beacon system <NUM>' similar to beacon system <NUM>, which may be, for example, a print circuit board that may include a beacon <NUM>' and electrical contacts <NUM>' or a micro switch <NUM>. Beacon system <NUM>' may be secured to the upper surface of liner <NUM> and thus slide up and down with liner <NUM>. As shown in <FIG>, cap <NUM>' may have an inner ring <NUM>, which is designed to contact micro switch <NUM> when cap <NUM>' is secured. Contact between micro switch <NUM> and inner ring <NUM> may be designed to complete the "short" circuit resetting beacon <NUM>' and stopping beacon <NUM>' from transmitting signal <NUM>. When contact between micro switch <NUM> and inner ring <NUM> is cut off, the short circuit may be broken, which is detected by beacon <NUM>', causing beacon <NUM>' to transmit the signal that bottle <NUM> has been opened.

In some embodiments, a conductive foam may be used as micro switch <NUM>. For example, in some embodiments, the conductive foam may be conductive electrostatic discharge (ESD) foam. In some embodiments, the conductive foam may be formed of a polymer (e.g., polyurethane, polyethylene, or the like). The conductive foam may be positioned such that when cap <NUM>' is installed on bottle <NUM>, the conductive foam is compressed (e.g., between beacon system <NUM>' and cap <NUM>'), and when in the compressed state the conductive foam has a resistance sufficiently low to complete the closed circuit that "shorts" the electrical contacts <NUM>' that may be in contact with the conductive foam. When cap <NUM>' is removed from bottle <NUM>, the conductive foam may return to an uncompressed state and when in the uncompressed state the conductive foam may have a resistance sufficiently high to interrupt the "short" circuit between the electrical contacts <NUM>'.

The resistance of the conductive foam in the compressed state and the uncompressed state can be selected based on the circuit design of beacon system <NUM>'. The resistance of the conductive foam in the compressed state can be, for example, less than about <NUM> kOhm, <NUM> kOhm, <NUM> kOhm, <NUM> kOhm, <NUM> kOhm, or less. The resistance of the conductive foam in the uncompressed state can be, for example, greater than about <NUM> MOhm, <NUM> MOhm, <NUM> MOhm, <NUM> MOhm, or more. In some embodiments, beacon system <NUM>' may include an on-chip resistor having a resistance of about <NUM> MOhm and the resistance difference between the compressed and uncompressed state of the conductive foam may be about 10X difference from the on-board resistance of the on-board resistor. For example, the resistance of the conductive foam in the compressed state may be about <NUM> kOhm or less while the resistance of the conductive foam in the uncompressed state may be about <NUM> MOhm or more. In this example, the difference in the resistance of the conductive foam between the compressed and uncompressed state may be about 100X. It is contemplated that in other embodiments the difference in the resistance of the conductive foam in the compressed and uncompressed states may be greater than our less than about 100X, for example, about 125X, about 150X, about 175X, about 200X, about 75X, about 50X, about 25X, about 10X, about 5X, or about 2X.

The positioning of the conductive foam may vary depending on the construction of bottle <NUM>, cap <NUM>', beacon system <NUM>', and/or liner <NUM>'. In some embodiments, the conductive foam may be secured to beacon system <NUM>', for example, across electrical contacts <NUM>' so when cap <NUM>' is removed it returns to its uncompressed state. In other embodiments, the conductive foam may be secured to cap <NUM>' (e.g., inner ring <NUM>) and aligned with electrical contacts <NUM>' so that when cap <NUM>' is removed the conductive foam returns to its uncompressed state and depending on the thickness of the conductive foam it may completely separate from beacon system <NUM>' and electrical contacts <NUM>'. The thickness of the conductive foam can vary, for example, between about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>, about <NUM> to about <NUM>.

In some embodiments, a coversheet (not shown) may be positioned between the beacon system <NUM>' and cap <NUM>' may cover at least a portion of beacon system <NUM>' and micro switch <NUM> (e.g., the conductive foam). The coversheet may protect inner ring <NUM> of cap <NUM>' as well as the beacon system <NUM>' from being damaged. The coversheet may also provide a wider contact surface for initiating the compression of the conductive foam in the event the conductive foam is not precisely aligned, for example, with inner ring <NUM> of cap <NUM>'. In some embodiments, the conductive foam may be secured to the coversheet.

In some embodiments, instead of a micro switch <NUM>, electrical contacts <NUM>' and a conductive strip <NUM>' may be used to complete and cutoff the short circuit as described herein with regard to electrical contacts <NUM> and conductive strip <NUM>. Electrical contacts <NUM>' may be positioned on a surface of beacon system <NUM> (e.g., of the print circuit board) while conductive strip <NUM>' may be positioned on inner ring <NUM> or vice versa.

Cap <NUM>' and liner <NUM> may be made of the same material or different materials. For example, in some embodiments, cap <NUM>' may be made of a higher density more rigid material (e.g., high-density polyethylene) while liner <NUM> is made of a lower density more flexible material (e.g., low-density polyethylene). The flexibility of liner <NUM> may enable it to act as a liner and a seal when cap <NUM>' is installed on bottle <NUM>, thereby reducing or preventing contaminants or moisture from entering bottle <NUM>. For example, inner ring <NUM> and the rim of bottle <NUM> may act on liner <NUM> when cap <NUM>' is installed, as shown in <FIG>, to deflect liner <NUM> creating a spring like force within liner <NUM> that cause a seal to form between liner <NUM> and the rim of bottle <NUM>.

For the purposes of this disclosure, all previous and subsequent description in reference to cap <NUM>, beacon system <NUM>, beacon <NUM>, electrical contacts <NUM>, and conductive strip <NUM> are all equally applicable to cap <NUM>', beacon system <NUM>', beacon <NUM>', electrical contacts <NUM>', and conductive strip <NUM>', and vice versa, besides where a distinction is noted.

It is contemplated that other techniques or mechanisms may be used to detect the removal of cap <NUM> from bottle <NUM>. For example, some embodiments may utilize a pressure sensor positioned between cap <NUM> and bottle <NUM> and when the pressure changes (e.g., when cap <NUM> is removed), the pressure sensor may interrupt the "short" circuit causing beacon <NUM> to transmit the signal that bottle <NUM> has been opened.

In some embodiments, the removal of cap <NUM> from bottle <NUM> may trigger a change in signal <NUM> transmitted from beacon <NUM> rather than simply initiating the transmitting of signal <NUM> from beacon <NUM>. For example, in some embodiments, beacon system <NUM> may be designed to transmit one identifiable signal while cap <NUM> is installed on bottle <NUM> and then change to or begin transmitting a second identifiable signal once cap <NUM> is removed from bottle <NUM>. The transmission of the second identifiable signal may be recognized as an indication the patient has taken a dose of the medication.

These one or more signals may be received by a remote device <NUM> (e.g., a smart phone) or other associated device, which can use the event (i.e., receiving of the sign or a change of the signal) as evidence that the patient has taken the medication. Beacon <NUM> may be a low-energy radio transponder.

Now the operation of an exemplary embodiment of beacon <NUM> will be described with reference to <FIG>. As illustrated in <FIG>, beacon <NUM> may include a packetizer <NUM> (e.g., a BLE packetizer), an oscillator <NUM>, a powertrain <NUM>, and an amplifier <NUM>. These components, as described herein, may be used to transmit signal <NUM> as shown in <FIG> from beacon system <NUM>. In some embodiments, beacon <NUM> may be enabled to receive a signal from another device (e.g., remote device <NUM>). In other embodiments, beacon <NUM> may be configured to operate as solely a transmitter. For example, beacon <NUM> may transmit a signal that may be received by remote device <NUM>, without pairing with remote device <NUM>.

Embodiments of beacon <NUM> with only transmitting capability may have decreased power consumption due to the elimination of the receiving hardware. In addition, eliminating the receiving hardware may also decrease the manufacturing cost of beacon <NUM>. Furthermore, the size of beacon <NUM> may also be decreased due to the elimination of the receiving hardware.

Returning to <FIG>, packetizer <NUM> may receive a signal via host controller interface (HCI). In some embodiments, packetizer <NUM> may interface with a processor (not shown) of beacon system <NUM> or may interface with electrical contacts <NUM>. In some embodiments, the signal that packetizer <NUM> receives may include data, which may be included in the signal transmitted by beacon <NUM>. For example, in some embodiments where packetizer <NUM> interfaces with a process, the signal received from the processor may include parameters such as encryption parameters, modulation parameters, a mode of operation of beacon <NUM>, packet type, etc. Additional parameters may be used to configure beacon <NUM> to generate a specific signal, which may be transmitted by beacon <NUM>.

In some embodiments, the signal received via HCI may be indicative of a mode of operation of beacon <NUM>. For some embodiments, the mode of operation may depend on the functionality of beacon <NUM>. In some embodiments, the functionality of beacon <NUM> may be predetermined, for example, beacon <NUM> may be used in a specific application.

In some embodiments, the modes of operation of beacon <NUM> may include an advertising mode in which an advertising protocol (e.g., BLE) is used to periodically transmit data packets referred to as advertising packets (also referred to herein as "advertisement packets"). The advertising packets may carry data indicative of beacon <NUM> (e.g., a unique identification number (UID)).

In some embodiments, the mode of operation of beacon <NUM> may affect its power consumption. For example, beacon <NUM> may decrease power consumption by using advertising protocols. Advertising protocols may enable beacon <NUM> to operate with low power consumption by periodically broadcasting signal <NUM> during certain time intervals. For example, in some embodiments, beacon <NUM> may only advertise when cap <NUM> is removed and the "short" circuit is interrupted. During time intervals where beacon <NUM> is not broadcasting a signal, beacon <NUM> may be idle or turn-off in a standby mode (e.g., hibernate). By turning on only when transmitting a signal in active transmit mode, beacon <NUM> may decrease its power consumption, which may be advantageous for devices with a finite power source. As such, advertising protocols enable beacon <NUM> to advertise data to one or more remote devices <NUM> while maintaining low power consumption for beacon <NUM>.

BLE protocols may include different types of advertising packets. The advertising packet type may specify, for example, a configuration of beacon <NUM>. For example, the advertising packet type may specify whether beacon <NUM> is connectable and/or scannable. A connectable beacon <NUM> may pair with another device (e.g., BLUETOOTH device), and a scannable beacon <NUM> may broadcast and advertising packet in response to receiving a scan request from another device, (e.g., BLUETOOTH device). Furthermore, an advertising packet may be a directed packet. For example, a directed packet may include the beacon <NUM> address and remote device's <NUM> address, whereas an undirected packet may not be directed toward a particular remote device <NUM> (i.e., receiver).

The configuration of beacon <NUM>, which may be specified by the advertising packet type, may also affect the power consumption of beacon <NUM>. For example, beacon <NUM> in a connectable and scannable configuration may use more power than a beacon <NUM> in a non-connectable and non-scannable configuration. This is because beacon <NUM> in a connectable and scannable configuration has a longer active transmit time than beacon <NUM> operating in the non-connectable and non-scannable configuration.

As explained above, in some embodiments, beacon <NUM> may operate only as a transmitter and therefore may not be able to operate in a connectable configuration. Furthermore, in some embodiment, the transmitter may not be able to receive scan requests from other devices. Thus, in some embodiments, beacon <NUM> may be operating in a non-connectable and non-scannable configuration in order to decrease power consumption.

There are additional advantages besides lower power consumption that may be achieve by beacon <NUM> using BLE advertising protocols. For example, remote device <NUM> may discover BLUETOOTH device located near remote device <NUM> faster (and consuming less energy) using advertising protocols than by using other protocols. Advertising protocols may use three fixed channels of a wireless spectrum, e.g., the <NUM> wireless spectrum. Thus, by not scanning the full wireless spectrum, remote device <NUM> may detect other BLUETOOTH device over the three fixed channels, enabling for the receiving and sending of BLE advertisement packets faster than the other protocols.

Returning now to <FIG>, packetizer <NUM> may use the data included in the signal received via HCI to generate a data signal, which may include one or more data packets. Packetizer <NUM> may receive instructions to generate a data signal including one or more data packets according to an advertising protocol. In some embodiments, the instructions may detail the type of advertising event to broadcast. For example as explained above, the type of advertising event may determine whether the device is connectable and/or scannable, and/or whether the packet is directed. In an example, packetizer <NUM> may receive data indicative of instructions to generate a data signal that includes a non-connectable, non-scannable, and undirected advertising event.

Oscillator <NUM> may generate an RF carrier signal that may carry the data signal generated by packetizer <NUM>. The RF signal carrying the data may then be broadcasted by beacon <NUM>. As illustrated in <FIG>, oscillator <NUM> may be a free-running oscillator, which may be used to directly generate an RF carrier signal. Thus, a free-running oscillator is an alternative to using a frequency synthesizer (i.e., Phase Locked Loop (PLL) synthesizer) to generate an RF carrier signal. Typically, a frequency synthesizer, which also includes a frequency reference circuit, may dissipate a significant portion of a transmitter's power. Accordingly, using a free-running oscillator may result in considerable power savings, which may be advantageous in achieve low power consumption operation for beacon <NUM>.

Both the turn-on time for the frequency synthesizer to lock to its frequency reference and the turn-on time of its frequency reference circuit may be significant compared to the packet duration. Therefore, the turn-on time (i.e., time to go from sleep mode to active transmit mode) for a transmitter using a frequency synthesizer may be greater than a transmitter using a free-running oscillator. A longer turn-on time may result in greater power dissipation. Accordingly, using the free-running oscillator, which may have a reduced turn-on time compared to a frequency synthesizer, may result in further power savings.

The free-running oscillator may directly generate the RF carrier signal, which may have a frequency within a wireless spectrum, e.g., the <NUM> wireless spectrum. For example, the free-running oscillator may directly generate a RF carrier signal that has a frequency of one of the three channels in the <NUM> band that are allocated to BLE advertising protocols according to BLUETOOTH specifications. The three channels are specified as <NUM> wide channels with frequencies of <NUM>, <NUM>, and <NUM>.

Note that the example oscillator provided in <FIG> and the accompanying description herein is for illustrative purposes only and should not be considered limiting. For instance, beacon <NUM> may include more than one free-running oscillator. In some embodiments, beacon <NUM> may include three free-running oscillators, each of which may be used to generate a carrier signal at a frequency of the three BLE channels. In such examples, beacon <NUM> may utilize methods such as multichannel transmission and frequency hopping.

In some embodiment, free-running oscillator <NUM> may be a Pierce oscillator, which is illustrated in <FIG>. The Pierce oscillator <NUM> may include a transistor <NUM>, a biasing resistor <NUM>, capacitors <NUM> and <NUM>, and a resonator <NUM>. Resonator <NUM>, which may extend out from beacon <NUM>, may be used as a filter to filter the oscillation frequency. Further, the total capacitance of the two capacitors <NUM> and <NUM>, as seen by the resonator, may be referred to as the "load" capacitance. " The load capacitance may affect how far the oscillator loop is resonating, relative to the desired resonant frequency. Accordingly, selectively choosing the resonator, which may have a specific load capacitance requirement, may determine the oscillation frequency.

In some embodiments, the resonator <NUM> may be a thin-film bulk acoustic resonator (FBAR). An FBAR resonator <NUM> may include a piezoelectric thin film between two metal layers. FBAR are high-Q resonators that may have a stable and a low phase-noise center frequency, which may be the oscillation frequency. In some embodiments, FBAR resonators may have a Q of several hundred. In other embodiments, FBAR resonators may have an (unloaded) Q of over one thousand. Further, temperature compensation may be used to maintain the center frequency of FBAR resonator <NUM> at the frequency of the wireless channel.

The example resonator <NUM> shown in <FIG> and the accompanying description herein is for illustrative purposes only and should not be considered limiting. Any suitable resonator may be used. For example, the resonator may be any high frequency resonator, which may provide an oscillation frequency with stability and an accuracy that may meet BLUETOOTH standards. In other examples, the resonator may be a crystal resonator. For one example, the resonator may be a quartz resonator.

As noted above, the RF carrier signal generated by oscillator <NUM> may be used to carry the data signal generated by packetizer <NUM>. More specifically, the data signal generated by packetizer <NUM> may act as a tuning code, which may have a specific symbol rate. Further, the tuning code may be used to directly modulate the RF carrier signal. Accordingly, the modulated RF carrier signal may carry the data signal generated by packetizer <NUM>. Within examples, the tuning code may modulate the RF carrier signal according to at least BLE's protocols.

For instance, BLE protocols specify using Gaussian Frequency Shift Keying (GFSK) as the modulation scheme to modulate the RF carrier signal. Accordingly, the tuning code may be used to modulate the RF carrier signal to two different frequencies of the same advertising channel according to GFSK. Additionally and/or alternatively, the tuning code may be used to modulate the RF carrier signal to two different frequencies of the same advertising channel according to Binary Frequency Shift Keying (BFSK). Oscillator <NUM> may include a bank of switched capacitors, represented by variable capacitors <NUM> and <NUM> in <FIG>, which may be used to adjust the load capacitance of Pierce oscillator <NUM>. As explained above, adjusting the load capacitance of Pierce oscillator <NUM> may adjust the oscillation frequency. The digital data signal, indicative of digital "<NUM>" and "<NUM>", may be used to modify the load capacitance of Pierce oscillator <NUM>, such that oscillator <NUM> may generate a modulated signal of two frequencies, one of which corresponds to digital "<NUM>" and the other to digital "<NUM>.

The modulated RF signal, carrying the data signal, may be transmitted to a class-D power amplifier <NUM>, as illustrated in <FIG>. In some embodiments, at least a portion of the modulated signal may be transmitted to a prescaler <NUM>. Prescaler <NUM> may scale the signal and provide the scaled signal to packetizer <NUM>, where it may be used as a clock source. For example, prescaler <NUM> may scale down the <NUM> signal to a <NUM> or <NUM> signal. By using a portion of the carrier signal as a clock source for packetizer <NUM>, there may be no need for a separate timing source for packetizer <NUM>, thereby further decreasing power consumption.

As illustrated in <FIG>, the modulated RF carrier signal may be amplified using class-D power amplifier <NUM>. The amplified signal may then be transmitted to the radio (represented as "RF" in <FIG>) where it may be broadcast over the air as signal <NUM>. As explained above, in some embodiments, beacon <NUM> may be operating in advertising mode, which involves beacon <NUM> periodically transmitting advertising packets. Accordingly, the broadcasted RF signal may include advertisement packets, which may be received by one or more remote devices <NUM>.

Beacon <NUM> may be powered by powertrain <NUM>. Powertrain <NUM> may include a low dropout regulator (LDO) <NUM>, a power on reset (PoR) <NUM>, a bandgap voltage reference (Bandgap) <NUM>, and a real time clock (RTC) <NUM>. Note that the RTC <NUM> may have a low frequency and may operate without a crystal reference, as packetizer <NUM> may use a signal from oscillator <NUM> as described above.

Beacon <NUM>, as described herein, may transmit a signal to one or more remote devices <NUM> by carrying out one or more steps or functions, as described below. First, beacon <NUM> may generate, based on data, a data signal comprising one or more data packets. In some embodiments, the data may include information such as encryption parameters, modulation parameters, mode of operation of the device, packet type etc. In some embodiments, the data packet may be a non-connectable, non-scannable advertising packet. For the next step, beacon <NUM> may generate an RF signal using an oscillator circuit. Next, beacon <NUM> may directly modulate the RF signal, based on the data signal, to generate a modulated RF signal. As noted above, the modulated RF signal may conform to BLE protocols. Further, the RF signal may be directly modulated by using the data signal to adjust the load capacitance of oscillator <NUM> using the bank of switched capacitors. For the next step, beacon <NUM> may amplify the modulated RF signal. Next, beacon <NUM> may broadcast the amplified RF signal (i.e., signal <NUM>) on the wireless channel. As described here, the wireless channel may be a channel in the <NUM> spectrum.

As discussed herein, beacon <NUM> can be configured to turn on and transmit signal <NUM> when cap <NUM> is removed. In some embodiments, beacon <NUM> may transmit signal <NUM> for the duration cap <NUM> is while in other embodiments beacon <NUM> may transmit signal <NUM> for a fixed duration once cap <NUM> is removed.

As described herein, in some embodiments, remote device <NUM> can be detected by beacon <NUM> when it comes in range and opens communication. Various protocols may be used for this, including for example, proximity beacon application program interface (API) and Eddystone protocol available from Google. As will be appreciated from this disclosure, other communication protocols may be utilized.

In some embodiments, beacon <NUM> can broadcast encrypted data. For example, system <NUM> can include an encryption key, such as a QR or bar code on bottle <NUM> or cap <NUM>. Remote device <NUM>, or other device, can be used to scan the code (e.g., using an on-board camera), input the code, or otherwise receive the encryption key, and use the key to receive encrypted data from beacon <NUM>. In this way, only authorized devices may receive and decrypt data from signal <NUM>, which can increase security, for example when undirected transmissions are used.

In some embodiments, beacon <NUM> may broadcast signal <NUM> not just when cap <NUM> is removed from bottle <NUM>, but instead beacon <NUM> may broadcast signal <NUM> (i.e., send data) that may be received by remote device <NUM> when idle. For example, beacon <NUM> may broadcast an idle status signal that may be terminated when beacon <NUM> begins broadcasting the signal indicating cap <NUM> is removed.

Remote device <NUM> may be a smart phone, a smart watch, or other programmable user interface device with a mobile operating system. The smartphone or device may include a controller. The controller may include one or more hardware processors, such as one or more central processing units (CPUs). The processor(s) may execute a set of instructions to perform operations. The set of instructions may be programmed and stored in one or more memory devices. Examples of memory devices include non-volatile memory (e.g., a flash memory), volatile memory (e.g., a random access memory (RAM)), and other memory components. In some embodiments, the controller may be configured run programmed instructions or software to execute operations, as described herein. The controller may also include one or more interfaces to communicate with beacons of packets or packet bundles.

Remote device <NUM> may run or execute a programmable application ("the app") designed to interface with beacon system <NUM>. The app may be downloadable to remote device <NUM> via the internet or an app store, for example, the PLAY STORE operated by Google.

The app may be programmed with a wide range of functionality. For example, the app may be programmed to receive medication prescription information. The medication prescription information may include, for example, the patient's name, patient identifier (e.g., a date of birth), the type of medication, the strength or the dose of medication (e.g., <NUM>, <NUM>, one pill, two pill, etc.), the frequency of dose (e.g., daily, twice daily, as needed, etc.), the duration of the prescription (e.g., three days, four days, five days, six days, <NUM> week, <NUM> weeks, indefinitely, etc.), the number of doses, the number of refills prescribed, the route by which it is to be delivered (e.g., orally), the time of day doses are to be taken, or other relevant information (e.g., take with food, take with water, etc.). The app may receive the medication prescription information in a variety of ways. For example, the medication prescription information may be transmitted to the app when the prescription is picked up at the pharmacy or downloaded (e.g., via an internet based patient login). Alternatively, the medication prescription information could be contained on the label (e.g., written out, as a bar code, or a QR label) and may be scanned by remote device <NUM> (e.g., using an on-board camera) and loaded into the application. The medication prescription information could also be input manually by a patient, a caregiver, or other individual by typing it in or speaking into remote device <NUM>.

In some embodiments, remote device <NUM> may upload and/or cross-check some or all of the medication prescription information to patient's medical record by accessing, for example, the cloud where the patient's medical records may be stored. This can enable a patient's medical records to be updated real time with all of their medication prescriptions.

The app may be programmed to detect each time a signal from beacon <NUM> is transmitted, which is representative that the medication is being taken, and log the time and date at which the medication is taken. If the patient is taking multiple medications the app may be programmed to differentiate the signal from each beacon <NUM> and log the time and date corresponding to the correct medication. For some embodiments, the app may be programmed to display a prompt asking the patient to confirm they took the medication.

For some embodiments, the app may be programmed to remind the patient to take a medication. For example, if the app has not detect a signal indicating cap <NUM> has been removed within a prescribed window in which the patient was supposed to take the medication, then the app can prompt the user to take the medication.

The app may be programmed to prompt the user in a variety of ways. For example, remote device <NUM> may display a message on the screen, ring, vibrate, or flash light (e.g., flash screen or flash on-board camera flash). The app may be programmed to escalate the intrusiveness of the prompt based on various factors (e.g., the urgency or importance of the medication or the length of time that has passed since an initial prompt was issued. The app may be programmed to enable the patient to override a prompt. For example, if the patient took the medication, but remote device <NUM> missed the signal transmission from beacon <NUM> because it was out of range, for example, the patient may input that they took the medication.

In some embodiments, the app may be programmed to send a prompt reminding the patient in advance of when they should be taking a medication. This may be advantageous if a medication requires that the user eat before or take with a drink so the reminder can enable the patient to plan accordingly.

In some embodiments, the app may be programmed to send a prompt to the patient if the app detects that the patient may be taking the wrong medication. For example, if the patient is on two or more medications and at the time the patient is scheduled to a take a first medication the patient opens the bottle for a second medication, the app may prompt the patient to the error.

In some embodiments, the app may be programmed to prompt the patient with instructions corresponding to taking of the medication. The corresponding instructions may include, for example, take with food, take with water, take with a certain quantity of water, do not drink alcohol while taking, do not drive after taking, etc..

For some embodiments, the app may be programmed to prompt the patient if the patient is taking the medication outside a prescribed window. For some embodiments, where the patient's prescription "is as needed," the app may be programmed to prompt the patient to input the dose amount of the medication taken each time bottle <NUM> is opened so the doses can be logged. For some embodiments, the app may keep track of the number of doses left in bottle <NUM> and may prompt the patient to request a refill prior to being empty or in some embodiments the app may generate and send a refill request directly to a caregiver and/or a pharmacy.

For some embodiments, the app may be programmed to ask the patient questions associated with the medication prescription. For example, the app may ask the user to confirm they will not be drinking alcohol if the medication cannot be taken while drinking or the app may ask the user to confirm they will not be operating a vehicle if the medication cannot be taken if a patient will be operating a vehicle. For some embodiments, the app may ask the patient whether the patient is experiencing any side effects that may be associated with the medication. Whether the patient is experiencing side effects may then be transmitted to a caregiver (e.g., doctor, psychiatrist, nurse practitioner, etc.), which may use this information to evaluate and/or modify the prescription as needed.

For some embodiments, the app may be programmed to prompt the patient if the app determines that the patient is leaving home without their medication. For example, the app may be programmed to recognize the patient's home or other known wifi, GPS location, or vehicle BLUETOOTH connection and if the app determines the patient is moving (e.g., based on loss or change of wifi signal, change in GPS location, or detection of vehicle Bluetooth connection) and the app is not receiving a signal (e.g., a status signal from beacon <NUM>) the app may prompt the user that their medication is not with them. The app may be programmed only to prompt the user if the patient is going to need to take the medication in the near future (e.g., the next two hours, next four hours, next six hours, or next eight hours).

The functionality of the app may be configurable by the patient. In other words, the patient may select what prompts they want to receive and what prompts they do not. For some embodiments, some prompts may be compulsory while other prompts may be selectable. For some embodiments a caregiver may select what prompts are active and not active.

Although system <NUM> is described primarily in reference to prescription medications, system <NUM> may also be used in conjunction with non-prescription medications, vitamins, supplements, etc. And, although system <NUM> is described primarily in reference to a pill or capsule bottle, system <NUM> may be incorporated into other medication containers, bottles, or dispensers. For example, system <NUM> may be used with eye drop bottles, ointment tubes, or other medication containers.

<FIG> shows an illustrative process <NUM> for monitoring medication adherence and compliance, consistent with embodiments of the present disclosure. Process <NUM> may be implemented using any of the exemplary embodiments of system <NUM> described herein, including those illustrated and described with reference to <FIG> and <FIG>, <FIG>, and <FIG>.

At step <NUM>, the system can detect when the cover or cap is removed from the medication container. For example, as discussed above, the removal of the cap may open a closed circuit thus resetting the beacon. At step <NUM>, the beacon can transmit based on the detection, a signal from the beacon to a remote device, which indicates the opening of the medication bottle. Optionally at step <NUM>, an application running on the remote device may recognize the signal as an indication that a patient has taken a medication from the bottle and create a record of when the patient takes the medication based on detection of the signal. Optionally at step <NUM>, the remote device may obtain prescription medication information by scanning a label of the medication, inputting by the user, or transmitting by the pharmacy, as described herein. Optionally at step <NUM>, the remote device may prompt the patient when to take the medication. For example, the remote device may prompt the patient with a reminder to take the medication in advance or may prompt the patient to take the medication if the patient has not taken the medication during a prescribed window. Optionally at step <NUM>, the remote device may prompt the patient to answer questions associated with taking the medication, as described herein. Optionally at step <NUM>, the remote device may upload or transmit the record and/or the patient's answers to the patient's medical record or to a caregiver. Process <NUM> as described herein may optionally include numerous other steps utilizing the above described functionality of system <NUM> and the application interfacing with beacon system <NUM>. Process <NUM> may vary based on the functionality selected by the patient and/or the caregiver.

Claim 1:
A medication monitoring system (<NUM>) comprising:
a medication container (<NUM>) and a cover (<NUM>); and
a beacon system (<NUM>), which includes at least one beacon (<NUM>) that transmits a wireless signal (<NUM>) when the cover is removed from the medication container,
characterised in that:
the beacon system includes two electrical contacts (<NUM>), and a rim of the medication container includes a conductor (<NUM>) configured to form a short circuit between the two electrical contacts when the cover is installed on the medication container, such that the beacon is held in a reset state when the cover is installed on the medication container, wherein the beacon is in a low-power standby mode while it is held in the reset state; and
the beacon is configured to transmit the wireless signal when the short circuit between the two electrical contacts is interrupted.