Methods for authenticating medication delivery devices

Abstract

A medication delivery device configured to authenticate itself to a mobile device is disclosed. The delivery device may comprise a syringe assembly comprising a reservoir holding a liquid medication and a needle, a dose sensor for determining when the syringe assembly has initiated or completed a dose event, a wireless communication device, memory storing computer-executable instructions and a secret encryption key, and a processor. The processor may be configured to detect, using the dose sensor, when the syringe assembly has initiated or completed the dose event; receive a request for information regarding the dose event from the mobile device, the request including a timestamp; and transmit in response an encrypted packet comprising the requested information and the time stamp, wherein the encrypted packet has been encrypted using the secret encryption key.

Description

METHODS FOR AUTHENTICATING MEDICATION DELIVERY DEVICESFIELD OF THE DISCLOSURE

[0001] The present disclosure relates to systems and methods for authenticating medication delivery devices. More particularly, the present disclosure relates to systems and methods for authenticating medication delivery devices, such as autoinjectors, that report their injection data wirelessly for a limited time to a mobile device, such as a smartphone.BACKGROUND OF THE DISCLOSURE

[0002] Injection devices in the form of a syringe or which include a syringe are widely employed by medical professionals and users who self-medicate. Users suffering from a number of different diseases may frequently inject themselves with medication and a variety of devices have been developed to facilitate such self-medication. Automatic injection devices may include mechanisms to perform some of the steps of the injection process, thus making it more convenient for users to self-medicate. Such devices are particularly useful and convenient for users with limited manual dexterity who may have difficulty self-medicating otherwise. Such injection devices may be single dose devices that are disposed after a single dose, or multi-use devices that are disposed after multiple doses, or reusable devices that may be re-filled with medication. Such devices may also be fixed-dose devices that deliver the same dose every time, or they may be variable-dose devices that allow a user or a healthcare provider (HCP) to select an appropriate dose.

[0003] Some injection devices may include sensors that automatically detect and record the occurrence of a dose event, in which a dose of medication is delivered to a user. Such devices may also be configured to wirelessly report data regarding such dose events to a nearby mobile device, such as a user’s smartphone.SUMMARY

[0004] The present disclosure relates to systems and methods for authenticating medication delivery devices. In particular, the present disclosure relates to systems and methods for authenticating medication delivery devices, such as autoinjectors, that report their injection data wirelessly for a limited time to a mobile device, such as a smartphone.

[0005] According to an exemplary embodiment of the present disclosure, a medication delivery device configured to authenticate itself to a mobile device is disclosed.The delivery device may comprise a reservoir holding a liquid medication; a dose sensor configured to determine when the medication delivery device has initiated or completed a dose event in which a dose of the medication is delivered to a user; a wireless communication device; memory storing computer-executable instructions; and a processor configured to execute the instructions to: detect, using the dose sensor, when the syringe assembly has initiated or completed the dose event, receive, via the wireless communication device, a request for information regarding the dose event from the mobile device, the request including a time stamp, and transmit, via the wireless communication device, an encrypted packet comprising the requested information regarding the dose event and the time stamp, wherein the encrypted packet has been encrypted using a secret encryption key.

[0006] According to another embodiment of the present disclosure, a method for authenticating a medication delivery device at a mobile device is disclosed. The method may comprise receiving, by the mobile device, one or more unencrypted wireless communication packets from a medication delivery device, the unencrypted wireless packets comprising a unique identifier associated with the medication delivery device; transmitting, in response to receipt of the unencrypted packets, a request for dose information from the mobile device to the medication delivery device; receiving, by the mobile device, one or more encrypted wireless communication packets comprising the requested dose information; determining whether the mobile device is able to communicate with a cloud service provider via a cellular or wireless network; and if the mobile device is not able to communicate with the cloud service provider, storing the one or more encrypted wireless communication packets in a memory of the mobile device until the mobile device is able to communicate with the cloud service provider.

[0007] According to yet another embodiment of the present disclosure, a mobile device configured to authenticate a medication delivery device is disclosed. The mobile device may comprise a wireless communication device; memory storing instructions; and a processor configured to execute the instructions to implement the aforementioned method for authenticating a medication delivery device.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The above-mentioned and other features and advantages of this disclosure, and the manner of attaining them, will become more apparent and will be better understood byreference to the following description of embodiments of the invention taken in conjunction with the accompanying drawings, wherein:

[0009] FIG. 1 depicts an exemplary system for authenticating a medication delivery device at a mobile device, according to some embodiments.

[0010] FIG. 2 depicts an exemplary medication delivery device in its initial, pre-use configuration, according to some embodiments.

[0011] FIG. 3 depicts the exemplary delivery device with its end cap removed but before initiation of a dose event, according to some embodiments.

[0012] FIG. 4 depicts the exemplary delivery device after it has completed the dose event, according to some embodiments.

[0013] FIG. 5 provides a close-up view of a proximal portion of the delivery device and the printed circuit board mounted therein, according to some embodiments.

[0014] FIG. 6A provides a distal view of the printed circuit board of the delivery device, and FIG. 6B provides a proximal view of the printed circuit board, according to some embodiments.

[0015] FIGS. 7A-7B depict a communication sequence diagram showing an exemplary procedure for operating and authenticating the medication delivery device using a mobile device and a cloud server, according to some embodiments.

[0016] FIGS. 8A-8B depict a flow-chart showing exemplary logic for implementation on a processor of a mobile device for authenticating the medication delivery device, according to some embodiments.

[0017] Corresponding reference characters indicate corresponding parts throughout the several views. The exemplifications set out herein illustrate exemplary embodiments of the invention and such exemplifications are not to be constmed as limiting the scope of the invention in any manner.DETAILED DESCRIPTION

[0018] For purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended.

[0019] The present disclosure relates to systems and methods for authenticating medication delivery devices. More particularly, the present disclosure relates to systems and methods for authenticating medication delivery devices, such as autoinjectors, that report their injection data wirelessly for a limited time to a user’s mobile device, such as a smartphone. Such medication delivery devices may include sensors that automatically detect and record the initiation and / or completion of a dose event, in which the delivery device delivers a dose of medication to a user. When a dose event is detected and / or recorded, the delivery device may wirelessly report data regarding such dose events to a nearby mobile device, such as the user’s smartphone. The wirelessly reported data may include the date and / or time of the dose event, the amount of medication delivered, the type of medication delivered, data recorded by one or more sensors on the medication delivery device (e.g., skin contact sensors, temperature sensors, and the like), information about the medication delivery device (e.g., a unique serial number associated with the medication delivery device that uniquely identifies the device), and / or a status of the medication delivery device (e.g., an amount of medication remaining in the delivery device, an amount of battery capacity remaining in the delivery device, the presence and / or absence of any detected faults or errors in operation of the delivery device, and the like). This data may be transferred to the mobile device via a short-range wireless link such as (but not limited to) a Bluetooth communication link, a WiFi communication link, and / or a NFC communication link.

[0020] Once the mobile device receives the data, an application on the mobile device may log the data for various purposes. For example, such data may be used by the user of the mobile device and / or the medication delivery device to plan the user’s dosing schedule. The data may be used to, for instance, determine when the user should take his / her next dose of medication, which type of medication the user should take for his / her next dose, and / or how much medication the user should take for his / her next dose. The mobile device may also optionally forward this data to a cloud repository, where it may be used by the user’s health care provider (HCP), a payer, and / or a researcher conducting a clinical trial to track the user’s adherence to medication regimens over time. In systems that also log the user’s health conditions and / or symptoms, such medication adherence data may be used to evaluate the impact of the user’s medication on the user’s health conditions. Medication delivery devices that automatically detect and report dose events, and mobile devices that automatically receive and log such dose events, can help improve the accuracy and precision of the user’s medication log and reduce the burden on the user to manually keep track of such information.

[0021] When the mobile device receives this medication delivery data from such medication delivery devices, the mobile device should preferably authenticate the data to ensure that it is really coming from a genuine medication delivery device. Without authentication measures, an adversary may introduce errors into the user’s medication log by sending wireless data to the user’s mobile phone that poses as data sent from a legitimate medication delivery device but is in fact sent from a fraudulent or counterfeit medication delivery device or from a device that is not a medication delivery device at all. In some scenarios, an adversary may also record data transmitted wirelessly by a legitimate medication delivery device, then replay this recorded data later to the same (or a different) mobile device. If successful, such a replay attack may also cause the mobile device to record a dose event that did not in fact occur. In such cases, the usefulness and reliability of the user’s medication log may be compromised, which in turn may affect the user’s health or safety. For example, if the timing and / or amount of medication delivered logged in the user’s log is not reliable, this may cause the user to take his / her next dose of medication at an inappropriate time or take an inappropriate amount of medication with the user’s next dose. In addition, if the accuracy of the user’s medication log cannot be ensured, then the data cannot be relied upon by the user’s HCP or by a payer or researcher to draw sound conclusions regarding the user’s medication adherence or health outcomes.

[0022] The systems and method discussed herein are directed at mitigating some of these challenges. In some embodiments, the mobile device may attempt to authenticate a medication delivery device when it receives a wireless transmission from the delivery device. The wireless transmission received by the mobile device may include a unique serial number that uniquely identifies the medication delivery device. When the mobile device receives this transmission, the mobile device may attempt to authenticate the delivery device by sending this unique serial number to an online cloud server accessible via the Internet. When the cloud server receives this unique serial number, the cloud server may respond to the mobile device with a unique secret decryption key associated with the medication delivery device. As will be discussed in further detail herein, this secret decryption key may be used to authenticate data received from the mobile device from the medication delivery device.

[0023] However, there may be scenarios in which the mobile device is unable to establish a communication link with the online cloud server, and therefore unable to authenticate the delivery device’s data. This may occur when the mobile device receives data from a medication delivery device during a time when the mobile device is unable to connectto the Internet. For example, the mobile device may receive the data from the delivery device when the mobile device is deep underground, in a remote area with no cellular coverage, or when the mobile device is configured to turn off its cellular antenna (e.g., the mobile device is put in airplane mode by the user).

[0024] In such cases, it may not be possible for the mobile device to authenticate the medication delivery device until the mobile device has re-established communication with the online cloud server. And since the data cannot be authenticated, the mobile device may be configured to not log, use, or rely upon such data. To get the mobile device to log, use, or rely upon such data, the user may simply wait until the mobile device has re-established communication with the cloud server before causing the delivery device to transmit its wireless data again. However, this may not always be feasible. For example, the medication delivery device may be configured to transmit its data for only a relatively short period (e.g., a few minutes or a few hours) after it finishes delivering a dose. After this period is up, the medication delivery device may run out of battery power, which would force it to stop transmitting its data. Or alternatively, the medication delivery device may be configured to stop transmitting after a certain preset time. If the mobile device is unable to re-establish communication with the online cloud server within that period (e.g., if the user is flying, or in a remote area without any cellular service), then the user would not be able to have the mobile device log, use, or rely upon such data.

[0025] In some scenarios, it may also impose a burden on the user to have to retain the medication delivery device until the mobile device is once again able to connect to the Internet and the cloud server. For example, if the medication delivery device is an injection device, the user would normally be instructed to dispose of the device in a nearby sharps container immediately after use. These instructions are for the user’s safety, since keeping an injection device with an exposed and used needle may pose a hazard for the user. If the user delivered the dose while his / her mobile device is connected to the Internet, then the user’s mobile device would be able to authenticate and log the dose event quickly (e.g., within a few seconds), and the user would be able to dispose of his / her delivery device promptly. If, however, the user delivered the dose while his / her mobile phone is unable to connect to the Internet, then the user may be forced to retain a used medication delivery device, potentially with a used sharp needle exposed, until the mobile device is once again able to connect to the Internet. Again, if the user is traveling through a remote area, this may force the user to holdon to the medication delivery device for multiple hours or even days, imposing a burden and a safety hazard on the user.

[0026] The systems and methods disclosed herein are directed at addressing one or more of the aforementioned challenges. Among other advantages, the systems and method herein provide a way for a mobile device to receive and retain a transmission from a delivery device and hold it in memory for an indefinite period of time (e.g., hours, days, or weeks) until the mobile device is able to authenticate the delivery device. If the delivery device ceases transmitting before the mobile device can authenticate the delivery device, the mobile device would still be able to log, use, and / or rely upon the delivery data contained within the received transmission once it authenticates the delivery device. This is so even if the authentication does not occur until well after the delivery device has ceased transmitting its data.

[0027] FIG. 1 depicts an exemplary system 100 for authenticating a medication delivery device at a mobile device. System 100 comprises three devices: a medicationdelivery device 102, a mobile device 120, and a remote or cloud server 140.

[0028] Medication-delivery device 102 illustratively includes a connected injection device. Such devices include a medication-delivery mechanism 106 that includes on-board reservoir 107 that stores a supply of medication, as well as a mechanism for delivering such stored medication into or onto the user’ s body. For example, the medication-delivery mechanism 106 may comprise a syringe assembly having a barrel that stores liquid medication, a needle, and a plunger that, when moved longitudinally along the barrel, forces the liquid medication out of the syringe assembly through the needle. When the medicationdelivery device 102 is placed on the user’s body and activated, the medication-delivery mechanism 106 may inject its supply of medication through a needle into the user's body. Medication-delivery device 102 may include devices that deliver its entire stored supply of medication in a single fixed dose (e.g., an autoinjector), devices that deliver its stored supply of medication in multiple fixed doses over a period of days or weeks (e.g., a multi-fixed-dose device), or devices that deliver its stored supply of medication in multiple variable / user- selectable doses over a period of days or weeks (e.g., an adjustable insulin pen) - in each case the medication -deli very mechanism 106 may be configured accordingly.

[0029] Medication-delivery device 102 further comprises processor 1 10 that is configured to execute control logic 114 stored in memory 1 12 of device 102. Processor 110may take the form of one or more microprocessors, microcontrollers, multiprocessors, embedded processors, digital signal processors (DSPs), or Application-Specific System Processors (ASSPs), and / or Application-Specific Integrated Circuits (ASICs). Control logic 114 contains computer-executable instructions (e.g., software and / or firmware) that is configured to, when executed by processor 110, cause device 102 to perform the functions described herein. For example, when executed by processor 110, control logic 114 may be operative to cause device 102 to use dose sensors 108 to sense when medication-delivery mechanism 106 has initiated or completed an operational event, such as, for example, a dose event in which a dose of medication is delivered. When executed by processor 110, control logic 114 may also be operative to cause device 102 to record data associated with this dose event (e.g., a time and / or date of the delivery, an amount of time that has elapsed since the dose, an amount of dose, a type of medication delivered, etc.), and transmit via communication device 104 data regarding the dose event to mobile device 120.

[0030] Dose sensors 108 may comprise any type of sensor that may be configured to sense movement of internal parts of medication-delivery device 102. Examples of such sensors include accelerometers and / or vibration sensors that detect shocks or vibrations caused by movement of internal parts of device 102, light emitters and detectors that can detect when parts of device 102 interrupt, reflect, or absorb a beam of light, capacitive sensors that detect changes in a capacitance or an electrical field formed by parts of the device 102 as said parts move relative to one another, electrical contact sensors with one or more metallic contacts that detects completion or breaking of an electrical circuit in response to movement of internal parts of device 102, magnetic sensors that sense changes in magnetic fields in response to movement of internal parts of device 102, optical encoders that detect linear or rotational movement of internal parts of the delivery machine based on changes in optical interference patterns, and other similar types of sensors. Various moving parts of device 102 associated with delivery of a dose of medication may be configured with any of the aforementioned types of sensors - examples of such moving parts include syringes and / or needles that extend and / or retract at the beginning or end of a dose event; plungers that translate longitudinally to pump liquid medication; dials, flanges, screws, or barrels that rotate as liquid drug is pumped or a syringe or needle is extended or retracted; or any other internal component on device 102 that moves at the beginning or end of a dose event.

[0031] Memory 112 is any suitable computer readable medium that is accessible by processor 110. Memory 112 may be a single storage device or multiple storage devices, maybe located internally or externally to processor 110, and may include both volatile and nonvolatile media. Exemplary memory 112 includes random-access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory, a magnetic storage device, optical disk storage, or any other suitable medium which is configured to store data and which is accessible by processor 110. In addition to control logic 114, memory 112 may also store a secret encryption key 115 that may be used by processor 110 to encrypt communications transmitted via communication device 104. Memory 112 may also store an identifier 117 (e.g., a serial number) that uniquely identifies and distinguishes the medication-delivery device 102 from other medication-delivery devices.

[0032] Communication device 104 may comprise any suitable wireless transmission circuit, component, and / or firmware that may be used by processor 110 to transmit data to and / or receive data from a device external to medication-delivery device. For example, communication device 104 may comprise a wireless transmission circuit configured to transmit and / or receive data via a Bluetooth, WiFi, NFC, RFID, or other transmission protocol. Communication device 104 may be used by medication-delivery device 102 to establish a wireless communication link 160 with mobile device 120.

[0033] Mobile device 120 illustratively includes a mobile device, such as a smartphone. Alternatively, any suitable computing device may be used, including but not limited to a laptop, desktop, or tablet, for example. Mobile device 120 includes at least one processor 130. Processor 130 may be configured to execute control logic 134 stored in memory 132 of mobile device 120. Processor 130 and memory 132 may take the form of any of the embodiments discussed above for processor 110 and memory 112, respectively. Control logic 134 may be configured to, when executed by processor 130, cause mobile device 120 to perform the functions described herein. For example, control logic 134 may cause mobile device 120 to receive, via communication device 124, data regarding a dose event from medication-delivery device 102, to authenticate delivery device 102 and / or the data received from said device 102, and to then process, log, and / or use the received data. Communication device 124 may comprise any suitable wireless transmission circuit or component that is configured to establish a wireless communication link 160 with mobile device 120, as well as a wireless communication link 170 with remote server 140. In some embodiments, wireless communication link 160 may employ a different wireless transmission protocol than wireless communication link 170. For example, while wireless link 160 may be a short-range communication protocol that only works over a range of 0.1mto several tens of meters, wireless communication link 170 may be a long-range communication protocol that transmits and receives data over longer distances. For instance, communication link 170 may comprise a communication link established over a network, such as a cellular network or the Internet, with the aid of one or more intermediate devices such as a cellular tower, switches, and / or routers (not shown). In cases where wireless communication link 160 and communication link 170 employ different wireless communication protocols or technologies, communication device 124 may comprise two separate circuits and / or components, one for each type of communication protocol or technology.

[0034] Mobile device 120 may further comprise a user interface 127 in communication with processor 130 and operative to provide user input data to the mobile device 120 and to receive and display data, information, and prompts generated by the mobile device. User interface 127 includes at least one input device for receiving user input and providing the user input to the system. In the illustrated embodiment, user interface 127 is a graphical user interface (GUI) including a touchscreen display operative to display data and receive user inputs. The touchscreen display allows the user to interact with presented information, menus, buttons, and other data to receive information from the system and to provide user input into the system. Alternatively, a keyboard, keypad, microphone, mouse pointer, or other suitable user input device may be provided.

[0035] Remote server 140 is illustrated in FIG. 1 as comprising a processor 150 (which may take the form of any of the embodiments described previously for processors 110 and 130). Processor 150 may also be configured to execute logic 154 stored in a memory 152 (which may also take the form of any of the embodiments described previously for memory 112 and 132). When logic 154 is executed by processor 150, it may be configured to cause the remote server to implement the functions described herein, e.g., to respond to inquiries from the mobile device 120 via communications device 144 and communication link 170. As a general matter, remote server 140 responds to inquiries from mobile devices 120, thus enabling such mobile devices to authenticate medication-delivery devices 102.

[0036] Memory 152 may also comprise a database 158. Database 158 may store, in turn, a table 157 that contains a plurality of identifiers, each corresponding to a unique medication delivery device 102 (or to a unique type of delivery device 102), as well as one or more decryption keys associated with each of the plurality of identifiers. In some embodiments, the decryption key associated with a particular delivery device 102 may be thesame as the encryption key for that particular delivery device. In other embodiments, the decryption key may be different from the encryption key for a particular delivery device. Server 140 may also optionally include a user-interface 156, which may take the form of any of the embodiments discussed above for user-interface 127. Although remote server 140 is described and illustrated as a single device, in general the remote server 140 may take the form of a “cloud” server, in which a set of two or more machines are collectively equipped, configured, and programmed to perform the functions described as being performed by remote server 140 herein. The same may be said for each individual component within remote server 140: although server 140 is depicted as having only one single processor 150, user-interface 156, and memory 152, the functions performed by each component may be distributed across multiple components, e.g., multiple processors, user-interfaces, and memory.

[0037] An exemplary medication delivery device 202 is illustrated in various operational states in FIGS. 2-5. Examples of such a device and its operation are described in U.S. Pat. No. 8,734,394 B2, entitled Automatic Injection Device with Delay Mechanism Including Dual Functioning Biasing Member, issued May 27, 2014 to Adams et al. and in U.S. Patent No. 11,123,488, entitled Status Sensing Systems within an Injection Device Assembly, issued September 21, 2021 to Adams et al., the entire disclosure of both of which are hereby incorporated herein by reference. Medication delivery device 202 is one possible embodiment of device 102 depicted and discussed above in FIG. 1. However, other embodiments of device 102 that are different from device 202 are also possible and within the scope of this disclosure. Device 202 includes a syringe assembly 22, a drive mechanism 24, a retraction mechanism 26, and a printed circuit board (PCB) 82 shown later, for example, in FIG. 5. While device 202 includes a retraction mechanism, some embodiments of device 102 may not include any retraction mechanism. Syringe assembly 22 includes a barrel 30 forming a container body for holding a medication, and a piston 32 disposed within the barrel 30 for driving the medication outside the barrel. Syringe assembly 22 also includes a needle assembly 33 having a hollow injection needle 34 and a needle hub 35 which mounts needle 34 to syringe barrel 30. Advancing piston 32 within barrel 30 toward needle 34 dispenses medication through needle 34.

[0038] Device 202 may further comprise a medication, such as for example, within the syringe barrel 30. In another embodiment, a system may comprise one or more devices including device 202 and a medication. The term "medication" refers to one or moretherapeutic agents including but not limited to epinephrine, anaesthetics, analgesics, steroids, insulins, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, GLP-1 receptor agonists such as dulaglutide or liraglutide, glucagon, glucagon analogs, glucagon derivatives, gastric inhibitory polypeptide (GIP), GIP analogs, GIP derivatives, combined GIP / GLP-1 agonists such as tirzepatide or retatrutide, basal insulins, such insulin efsitora alfa, oxyntomodulin analogs, oxyntomodulin derivatives, and other treatments for diabetes and / or obesity, such as with lepodisiran (LPA siRNA), volenrelaxin, amylin agonist long acting, PNPLA3 siRNA, APOC3 siRNA, DACRA qw II, GIPR agonist long acting, glucose sensing insulin receptor agonist, nisotirostide, bimagrunab, NRG4 agonist, SCAP siRNA, mazdutide, therapeutic antibodies including but not limited to IL-23 antibody analogs or derivatives, such as mirikizumab that can be used for treatment of Crohn’s disease or ulcerative colitis, IL- 17 antibody analogs or derivatives, such as ixekizumab that can be used for treatment of plaque psoriasis, IL-13 antibody analogs or derivatives, such as lebrikizumab that can be used for treatment of atopic dermatitis, therapeutic agents for pain-related and / or migraine treatments, such as galcanezumab or lasmiditan, or for treatment of atopic dermatitis, such as with lebrikizumab ucenprubart, for treatment of Alzheimer’s and / or dementia, such as with donanemab, remtemetug, or GRN gene therapy, for treatment of Parkinson’s disease and / or Gaucher’s disease, such as with GBA1 gene therapy, for treatment of Hidradenitis Suppurativa, such as with eltrekibart, for treatment of rheumatoid arthritis, such as with peresolimab, and any therapeutic agent, such as with CD 19 for multiple sclerosis, that is capable of delivery by the devices described herein. Devices according to the present disclosure may be operated in a manner generally as described herein by a user (for example, a healthcare professional, a caregiver, or another person) to deliver one or more medications to a patient (for example, another person or the user).

[0039] FIGS. 2-3 illustrate device 202 in its initial, pre-use configuration with its end cap attached and end cap removed, respectively, but before initiation of a dose event. Here, an end cap 36 is secured to an injection device housing 38 and covers a proximal end opening 40 in housing 38. As used herein, distal and proximal refer to axial locations relative to an injection site when the apparatus is oriented for use at such site, whereby, for example, proximal end of the housing refers to the housing end that is closest to such injection site, and distal end of the housing refers to the housing end that is farthest from such injection site. Housing 38 may be formed from a plastic material and is shown extending generally longitudinally between a distal end in close proximity to an actuating button 52 and aproximal end in close proximity to the proximal end opening 40 along a longitudinal axis 48. As shown in FIG. 3, housing 38 may comprise a user-graspable portion 37 configured to be grasped by a hand of a user, the user-graspable portion 37 extending a radial distance 41 outward from longitudinal axis 48. Also as shown in FIG. 3, housing 38 may also comprise an outwardly-flared body lower portion 39 at a proximal end of the housing adjacent the proximal opening 40. The body lower portion 39 extends a radial distance 43 outward from longitudinal axis 48 that is greater than the radial distance 41. End portion 39 may slope smoothly radially outward from the user-graspable portion 37, as shown in FIGS. 2-4. In other embodiments, end portion 39 may take the form of other shapes.

[0040] A needle guard 42 is mounted on syringe assembly 22 and covers and surrounds needle 34. End cap 36 and needle guard 42 protect the user from accidental needle pricks and also protect needle 34 from damage. When using device 202 to dispense medication, for example, injecting the medication into a patient, end cap 36 and needle guard 42 are first removed. FIG. 3 illustrates device 202 after removal of end cap 36 and needle guard 42 from syringe assembly 22, wherein the syringe assembly is in a storage position and device 202 is ready for a dose event.

[0041] Syringe assembly 22 is moveable relative to the injection device 202 between a storage position and an injection position. FIG. 4 illustrates device 202 after the syringe assembly 22 has been moved relative to device 202 to an injection position from its storage position that is shown in FIG. 3. In the storage position (FIGS. 2 and 3), needle 34 is retracted to a position such that needle 34 is disposed within housing 38 of device 202. In the injection position (FIG. 4), needle 34 projects outwardly from housing 38 beyond proximal opening 40 in the proximal direction parallel to longitudinal axis 48 whereby needle 34 may be inserted into a patient.

[0042] Drive mechanism 24 includes a plunger 44 which engages piston 32. Drive mechanism 24 includes a spring 46 that drives plunger 44 in a translational movement. In the illustrated embodiment, spring 46 advances plunger 44 along a linear path defined by the longitudinal axis 48 of device 202. As plunger 44 is advanced, foot 50 of plunger 44 contacts piston 32. As the plunger 44 is further advanced, syringe assembly 22 is advanced along axis 48 from its storage position to its injection position. After advancement of syringe assembly 22 to its injection position, the continued proximal advancement of plunger 44 advances piston 32 proximally within barrel 30 from its initial piston position (shown in FIGS. 2 and 3) to its final piston position (shown FIG. 4) to cause medication to be dispensed from needle 34in a dose event. Prior to any dispensing of medication and when syringe barrel 30 holds the full original volume of medication, piston 32 will be in its initial piston position. After advancing piston 32 the full extent of its travel length toward needle assembly 33, piston 32 will be in its final piston position proximate needle assembly 33 and the medication from within barrel 30 will have been discharged. In some embodiments, barrel 30 of syringe assembly 22 holds a single dose of medication which will be delivered in a single dose event when piston 32 advances from its initial piston position to its final piston position within barrel 30. While the device is shown as a single use device, device 202 may also be configured as a multiple-use device with appropriate modifications. For example, in a multiple-use device, the drive mechanism 24 may be configured to advance the piston 32 only part of the way down the length of barrel 30 with each dose.

[0043] To activate drive mechanism 24, a person depresses actuating button 52 at the distal end of device 202. Depressing button 52 disengages one or two elongate prongs 54 on plunger 44 from a shuttle assembly 60 thereby allowing spring 46 to axially advance syringe assembly 32 to its injection position, and once the syringe assembly has reached said injection position, to advance plunger 44 within barrel 30 to deliver the medication. Spring 46 has a helical shape and surrounds prongs 54. The proximal end of spring 46 biasingly engages a flange on plunger 44.

[0044] Shuttle assembly 60 may include an upper shuttle member 62 and a lower shuttle member 64. Shuttle members 62, 64 are fixed together in the final assembly. In the final assembly, upper shuttle member 62 captures button 52 and spring 46 limiting the axial movement of these parts in the distal direction. Prongs 54 engage surfaces on upper shuttle 62 when the device is in the condition shown in FIGS. 2 and 3. Depressing button 52 causes tabs on button 52 to engage ramps on prongs 54 to bias prongs 54 inwardly to disengage prongs 54 from upper shuttle member 62. After prongs 54 have been disengaged, spring 46 exerts a biasing force on the flange of plunger 44 to advance plunger 44 from the position shown in FIG. 3 to the position shown in FIG. 4. As plunger 44 is advanced, it moves syringe assembly 22 to the injection position and then advances piston 32 to dispense medication as discussed above.

[0045] After the dose event is complete, retraction mechanism 26 optionally moves syringe assembly 22 from the injection position shown in FIG. 4 back to a retracted position. More specifically, the retraction mechanism is adapted to move the syringe assembly from the injection position to the retracted position in a retraction movement. The retractedposition may be similar to the storage position in that the syringe assembly is drawn back into the housing 38 such that needle 34 no longer projects proximally from proximal opening 40 and is disposed entirely within housing 38. In some embodiments, the retracted position may be the same as the storage position. In other embodiments, however, a syringe assembly 22 in the retracted position may be located slightly proximal or distal to a syringe assembly in the storage position. In the illustrated embodiment, the retraction mechanism includes a spring 66, a syringe carrier 68 and a rotary member 70 that acts as a follower. Further details about retraction mechanism 26 may be found in U.S. Pat. No. 8,734,394 B2, entitled Automatic Injection Device with Delay Mechanism Including Dual Functioning Biasing Member, issued May 27, 2014 to Adams et al. and in U.S. Patent No. 11,123,488, entitled Status Sensing Systems within an Injection Device Assembly, issued September 21, 2021 to Adams et al., the entire disclosure of both of which are hereby incorporated herein by reference. In yet other embodiments, the device 202 may include no retraction mechanism 26 such that the syringe assembly remains in its injection position indefinitely after the medication has been dispensed, until the syringe assembly is manually removed or repositioned by a user.

[0046] Although FIGS. 2-4 depict and describe an exemplary drive mechanism 24 and an exemplary retraction mechanism 26, other mechanisms may also be used to drive syringe assembly 22 from the storage position to the injection position, and / or from the injection position to the retracted position. Such drive and / or retraction mechanisms may (but need not) include one or more springs or deformable parts that store energy when they are held in a pre-triggered state and, when triggered, release said stored energy to drive the syringe assembly from the storage position to the injection position, and / or from the injection position to the retracted position. Such mechanisms may (but need not) include mechanisms that generate motive force using chemical reactions or processes, e.g., by generating gas through the mixture of two or more reagents, or by igniting a small amount of combustible or explosive material. Such chemically-driven mechanisms may comprise one or more storage containers for the chemical reagents, a trigger that punctures or opens said storage containers, allows said reagents to mix, and / or which provides a spark or other ignition source for beginning the chemical reaction, and a movable piston or other component that moves in response to increasing gas pressure generated by the resulting chemical reaction. Such mechanisms may (but need not) include mechanisms that use stored electrical power (e.g., in a battery) to ran electric motors that drive and / or retract the syringe assembly, or to trigger other physical or chemical mechanisms. Such mechanisms may (but need not) includehydraulic or pneumatic systems (e.g., tubes), gears, cables, pulleys, or other known components for transferring kinetic energy from one component to another. In some embodiments, rather than having separate mechanisms for driving the syringe assembly and then retracting the syringe assembly, a single mechanism may be configured to both drive and then retract the syringe assembly.

[0047] FIG. 5 shows a close-up view of the outwardly-flared body lower portion 39 of medication-delivery device 202, in which the housing 38 has been rendered translucent in order to show PCB 82 disposed therein. PCB 82 may be arranged perpendicular to the longitudinal axis 48. In embodiments where there is more than one PCB, such PCBs may be arranged stacked on top of one another and / or arranged next to each other. The PCB 82 defines an opening 83 (see FIGS. 6A and 6B) through which injection needle 34 of syringe assembly 22 is configured to pass, for example, when end cap 36 is removed and the injection needle is driven proximally to inject the patient during a dose event.

[0048] FIG. 6A shows a top perspective view of the PCB 82, while FIG. 6B shows a bottom perspective view of the same PCB 82, according to some embodiments of device 202. PCB 82 comprises a top surface 82a (shown in FIG. 6A) and a bottom surface 82b (shown in FIG. 6B, top surface 82a and bottom surface 82b are understood to be part of PCB 82). Top surface 82a includes or supports a power source 602 which, in some embodiments, may comprise a battery such as a coin cell battery mounted on battery clips (only the battery clips are depicted in FIG. 6A). Power source 602 provides electrical power to the electrical components integrated or coupled with injection device 202. An optional battery door (not shown) in housing 38 may hinge or swing open to allow access to power source 602. PCB 82 may also include a processing circuit 608. In some embodiments, processing circuit 608 may take the form of a System on Chip (SOC) integrated circuit that includes a processor (e.g., processor 110), memory (e.g., memory 112), and input / output ports. PCB 82 may also include or be communicatively coupled to a plurality of different types of sensors, such as a basecap removal sensor 610, an accelerometer 612, a temperature sensor 625, and / or one or more capacitive pad(s) 622 and 623.

[0049] Basecap removal sensor 610 may allow processing circuit 608 to detect whether basecap 36 is attached to housing 38 or has been removed by a user. Basecap removal sensor 610 may be communicatively or electrically coupled with processing circuit 608.

[0050] Accelerometer 612 may detect shocks or accelerations caused by initiation of a dose event in which syringe assembly 22 is driven by drive mechanism 24 from the storage position to the injection position. Accelerometer 612 may also detect shocks or accelerations caused by a retraction movement upon completion of the dose event in which syringe assembly 22 is driven by the retraction mechanism 26 from the injection position to the retracted position. Accelerometer 612 may send an output signal to processing circuit 608 via one or more electrical connections to allow processing circuit to analyze the output signal.

[0051] In some embodiments, processing circuit 608 may analyze the signal output from accelerometer 612 to determine a certain condition or state of the device 202, or to detect the occurrence of a certain event or action. For example, processing circuit 608 may analyze the output signal to discern when the basecap 36 has been removed, or when the actuation button 52 has been unlocked. Processing circuit 608 may also be configured to determine when a dose event is initiated or completed based on signals from accelerometer 612, either alone or in conjunction with signals from one or more skin contact sensors.

[0052] When a dose event is initiated, drive mechanism 24 is activated to drive the syringe assembly 22 from the storage position to the injection position. This driving motion imparts one or more accelerations that may be detected in the signal output from accelerometer 612. For example, the pushing force imparted by drive mechanism 24 as it drives syringe assembly 22 from the storage position in the proximal direction may cause accelerometer 612 to detect an acceleration in the distal direction along longitudinal axis 48. When syringe assembly 22 hits its stopping position at its injection position at the end of this driving motion, the sudden stop of syringe assembly 22 may cause accelerometer 612 to detect an acceleration in the proximal direction along longitudinal axis 48. Either this proximal or distal acceleration (or both) may cause accelerometer 612 to output a first acceleration spike that may be detected by processing circuit 608. This first acceleration spike may be indicative of initiation of a dose event. In some embodiments, processing circuit 608 may determine that a dose event has been initiated upon detection of the first acceleration spike alone. In other embodiments, processing circuit 608 may determine that a dose event has been initiated only when one or both of skin contact sensors 622, 623 detect contact with skin tissue at the time that a first acceleration spike is detected by accelerometer 612.

[0053] Similarly, when a dose event has been completed, the retraction mechanism 26 is activated to drive the syringe assembly 22 from the injection position to the retracted position. This driving motion imparts one or more accelerations that may also be detected inthe signal output from accelerometer 612. For example, the pushing force imparted by retraction mechanism 26 as it drives syringe assembly 22 from the injection position in the distal direction may cause accelerometer 612 to detect an acceleration in the proximal direction along longitudinal axis 48. When syringe assembly reaches the retracted position, the sudden stop of syringe assembly 22 may cause accelerometer 612 to detect an acceleration in the distal direction along longitudinal axis 48. Either this proximal or distal acceleration (or both) may cause accelerometer 612 to output a second acceleration spike that may be detected by processing circuit 608. This second acceleration spike may be indicative of completion of the dose event. In some embodiments, processing circuit 608 may determine that a dose event has been completed upon detection of the second acceleration spike alone. In other embodiments, processing circuit 608 may determine that the dose event has been completed only when one or both of skin contact sensors 622, 623 detect contact with skin tissue at the time that the second acceleration spike is detected by accelerometer 612, or detect contact with skin tissue at least once between the first and the second acceleration spike. Further details and additional methods for detecting initiation and / or completion of dose events using accelerometer 612 and / or skin contact sensors 622, 623 are described in U.S. Patent No. 11,123,488, entitled Status Sensing Systems within an Injection Device Assembly, issued September 21, 2021 to Adams et al., the entire disclosure of which is hereby incorporated by reference. As used herein, an "acceleration spike" is defined as any artifact in an acceleration or vibration signal output by an accelerometer or vibration sensor (e.g., a piezo sensor) that is indicative of initiation and / or completion of a dose event.

[0054] PCB 83 may further comprise temperature sensor 625. Many types of medication need to be stored at a first, relatively cool temperature (e.g., between 36 and 46 degrees Fahrenheit, or 2 and 8 degrees Celsius) to prevent spoliation, but then need to be warmed up to a second, warmer temperature (e.g., to room temperature, or between 65 and 75 degrees Fahrenheit, or 18 and 24 degrees Celsius) before being injected into the patient's body. To ensure that the medication within barrel 30 is stored at the appropriate storage temperature, and / or to ensure that the medication is warmed to the appropriate injection temperature, injection device 202 may be equipped with a mechanism for estimating the temperature of the medication. By ensuring that the medication has warmed up to the appropriate temperature, this information can be transmitted to a phone, or the device itself could signal a patient that the device is ready for use. In some embodiments, this temperature-measurement function may be performed by temperature sensor 625 directlymounted on the PCB 82 to estimate the temperature of the medication. This temperature sensor may be communicatively or electrically coupled to processing circuit 608, and outputs a temperature output signal that is received and analyzed by the processing circuit. In one example, the temperature sensor 625 is mounted to the distal surface of PCB, and in some instances, disposed circumferentially spaced from the pads 622, 623.

[0055] Temperature sensor 625 may comprise any of a plurality of types of temperature sensors that may be mounted on a PCB, such as but not limited to a thermistor (e.g., a negative temperature coefficient (NTC) thermistor, or a resistance temperature detector (RTD)), a thermocouple, or a semiconductor-based temperature sensor. Temperature sensor 625 may be configured and positioned to measure a temperature of a thermal ballast. The thermal ballast may comprise all or a portion of the silicon substrate of PCB 82 itself. Alternatively, the thermal ballast may comprise a suitable heat sink comprised of other materials (e.g. a polymer) that is mounted on PCB 82. The thermal ballast may be is in contact with, or surround all or a portion of, temperature sensor 625.

[0056] Near Field Communication (NFC) or Bluetooth Low Energy (BLE) connectivity may be provided by one or more antennas 604 mounted on the PCB 82. Such antennas 604 may be considered part of, or all of, communication device 104 described previously in FIG. 1. Antennas 604 may receive signals from processing circuit 608 that cause the antennas to send wireless communications to external devices. Although FIG. 6A depicts only one antenna 604, some embodiments may comprise two or more antennas, e.g., one BLE antenna and a separate NFC antenna. In some embodiments, processing circuit 608 may itself comprise an integrated BLE antenna, while antenna 604 may comprise an NFC antenna. Some embodiments may also use chip antennas instead of PCB trace antennas as depicted.

[0057] PCB may also be communicatively coupled or integrated with a plurality of sensors that detect contact with skin tissue. Skin contact sensors may be used to verify proper contact with the user's skin before the user activates injection device 202. Injection device 202 may also indicate to the user which sensors detect skin contact and which do not; this lets the user know which way he or she should tilt or move the injection device 202 before injection. This functionality decreases the likelihood of failed injections in which the needle 34 fails to penetrate the skin of the user or penetrates at an improperly shallow angle.

[0058] FIGS. 6B depicts an exemplary embodiment that includes two capacitive pads622 and 623 to detect skin contact. Pads 622, 623 are shown as discrete planar structures disposed along the distal surface of the PCB. Capacitive pads 622 and 623 may be configured to detect proximity of human tissue by such tissue's effect on an electrical field created by the sensor, e.g., by measuring the effect of such human tissue on the capacitance of an electrical circuit being monitored or measured by the sensor. Capacitance sensors do not require a metallic, electrical terminal that directly contacts skin tissue, and so may be partially or completely sealed behind a protective, non-conducting cover (e.g., made of plastic). This may increase the durability of the capacitance sensor by decreasing seepage of moisture or foreign substances into sensitive electrical components. Capacitance sensors may also reduce the danger of electrostatic discharge damaging sensitive electrical components within the device, since capacitance sensors do not require exposed metallic contacts. Capacitive pads 622 and623 may each individually detect contact with skin tissue, such that processing circuit 608 may determine when one pad detects contact but the other does not. Although FIGS. 6B depicts two capacitive pads 622 and 623, other embodiments may have less or more capacitive pads. For instance, PCB 82 may include only a single capacitive pad, or it may have three, four, five, six, or more capacitive pads.

[0059] FIGS. 7A and 7B depict a communication sequence diagram showing an exemplary procedure for operating and authenticating medication delivery device 102. These diagrams show an exemplary set of interactions between a user 702, a delivery device 102, a mobile device 120, and a cloud or remote server 140. When a user first receives or purchases medication delivery device 102, the user may place the device 102 in a refrigerator to prevent the medication stored therein from spoiling. When it is time for a dose, the user may remove the device 102 from the fridge and leave it in an environment having an ambient temperature that is close to or at room temperature to allow the medication to warm up. This is represented by step “1. Remove from refrigeration” in FIG. 7A. This warming process may take approximately 30 minutes - this is represented by step “2. Warmup.”

[0060] Once an appropriate of time has elapsed, and / or the medication has warmed to the appropriate temperature, the user picks up delivery device 102 and removes basecap 36 by manually grasping basecap 36 and pulling it in the proximal direction until basecap 36 separates from housing 38 (step “3. Remove Base Cap.”). Removal of basecap 36 exposes proximal end opening 40. In some embodiments, removal of basecap 36 may be detected by basecap removal sensor 610, which causes processing circuit 608 to “wake up”, e.g., poweror boot up, or transition from a lower power state to a higher power state. Such a transition may involve activating certain components that were previously powered-off (e.g., sensors, processors, memory, transmitters), or running certain components in a higher power state (e.g., running a processor at a higher clock rate, thus causing the processor to consume more power). In some of these embodiments, removal of the basecap 36 causes processing circuit 608 to begin periodically transmitting wireless packets via communication device 104 (which includes antennas 604) - this is represented by step “4. Transmit advertising packets.” These packets are meant to notify or “advertise” to any listening mobile devices 120 nearby of the presence and / or status of delivery device 102, and so are referred to herein as “advertising packets.” These packets may comprise a serial number (e.g., identifier 117) that uniquely identifies the medication delivery device 102, as well as information regarding a status of the device 102. This status information may indicate, for example, whether the device 102 has dispensed its store of medication, a battery charge remaining in power source 602, an amount of time that has elapsed since the basecap 36 was removed, a type of medication stored in device 102, a manufacturing lot or batch number associated with the medication stored in device 102 which may be used to identify when, where, and / or how the medication was manufactured, a temperature currently sensed by temperature sensor 625, and a capacitance sensed by each of, or both of, capacitive skin contact pads 622 and 623.

[0061] When the medication has warmed up, the user may place the proximal end opening 40 against an injection site on the user’s body. In embodiments where device 102 is locked against inadvertent actuation, the user may unlock device 102 at this point by actuating a button, turning a lever, or flipping a switch (not shown). The user then depresses actuating button 52, which causes drive mechanism 24 to move syringe assembly 22 from its storage position to its injection position, as previously described. As syringe assembly 22 moves into its injection position, the tip of needle 34 projects proximally beyond the plane of proximal end opening 40 and pierces the skin of the user. Drive mechanism 24 drives plunger 44 to dispense medication through needle 34 into the body of the user. When the dose is complete, the retraction mechanism 26 retracts syringe assembly 22 back to its storage position, as previously described. This corresponds to step “5. Deliver injection.”

[0062] The beginning and / or the end of this dose event may be detected by processing circuit 608 using accelerometer 612, as previously described. When processing circuit 608 detects that a dose event has been initiated, or that a dose event has been completed, processing circuit 608 may update the advertising packets it is sending out to indicate that theinjection has been initiated and / or completed (“6. Update advertising packets to indicate injection completed.”). The advertising packets may also be supplemented to indicate a date and / or time of the dose event. Alternatively, or in addition, the advertising packets may include information indicative of an amount of time that has elapsed since the dose event was initiated or completed, which may be used by mobile device 120 to work out the date and / or time of the dose event by subtracting said amount of time from the date and / or time of receipt of said advertising packets.

[0063] When a mobile device 120 receives an advertising packet from delivery device 102, mobile device 120 may extract the serial number (e.g., identifier 117) that uniquely identifies delivery device 102 from within the packet and store it in memory (step “7. Save serial number.”). If the advertising packet that mobile device 120 receives indicates that the delivery device 102 has initiated and / or completed a dose event, mobile device 120 may send a wireless connection request back to delivery device 102 (“8. Connection request.”). If delivery device 102 receives this request, it may respond with an acknowledgement indicating that it is ready to initiate the authentication process described below in FIG. 7B (“9. Connection successful”). In some embodiments, steps 8 and 9 may be omitted, and mobile device 120 may proceed directly to step 10 from step 7.

[0064] Turning now to FIG. 7B, when the mobile device 120 receives the “connection successful” acknowledgement from delivery device 102, the mobile device may generate and save a timestamp indicative of the current time (“10. Save timestamp”). The timestamp may include the date and / or time at which the mobile device saved the timestamp, or it may consist of or include data generated deterministically from the current date and / or time. After saving the timestamp, mobile device 20 sends the saved timestamp to the delivery device 102 (“11. Timestamp (cleartext)”). In some but not all embodiments, this timestamp may be sent to delivery device 102 in cleartext.

[0065] Upon receiving the timestamp, the delivery device 102 sends back an encrypted wireless packet that has been encrypted using a secret encryption key (e.g., encryption key 115) known only to the delivery device 102 and potentially cloud server 140. The encrypted packet contains both (i) the timestamp that it received from mobile device 120 at step 10, and (ii) information regarding the injection delivered (i.e., the dose event) at step 5. This step corresponds to step “12. Encrypted Packet (timestamp & data)” in FIG. 7B. The information regarding the dose event may include some or all of the same information included in the advertising packets sent at step “6. Update advertising packets to indicateinjection complete”, e.g., a date and / or time of the dose event, and / or an amount of time that has elapsed since the dose event was initiated or completed. This information may also include some or all of the same information discussed at step “4. Transmit advertising packets”, e.g., a type of medication injected, and / or a manufacturing lot or batch number associated with the medication stored in device 102. The information may also include data indicative of whether or not the capacitive pads 622 and / or 623 sensed skin contact at least once, or throughout, the dose event, whether any “liftoff” events were detected in which skin contact was not detected at any point throughout the dose event, the temperature sensed by sensor 625 at the time of the dose event, a current amount of power remaining in power source 602. whether the basecap removal sensor 610 sensed that basecap 36 has been replaced over proximal end opening 40, and / or any other data that may be stored in memory 112 of medication delivery device 102, or recorded by or derived from the output of any of the sensors of device 102.

[0066] Upon receiving the encrypted packet of step 12, mobile device 120 determines whether mobile device 120 can connect to cloud server 140 (Step “13. Is connection available?”). This may comprise determining whether mobile device 120 is able to connect to the Internet through, for example, a WiFi or cellular connection. Even if mobile device 120 is able to connect to the Internet, this determination may also comprise determining whether mobile device 120 determining whether it is able to connect with cloud server 140 specifically. This may be accomplished by sending a “ping” or connection request from mobile device 120 to cloud server 140, and waiting for an acknowledgment from cloud server 140. If mobile device 120 is able to connect to cloud server 140, it proceeds to step 14. If not, mobile device 120 saves the encrypted packet that mobile device received at step 12 into memory (e.g., to memory 132), then re-executes step 13 periodically, such as once a second, once a minute, once every few minutes or once an hour. The frequency at which mobile device 120 re-executes step 13 (or said another way, the duration of time that mobile device 120 waits before re-executing step 13) is a configurable parameter that may be adjusted by the user and / or system administrators as needed. In some embodiments, step 13 may be re- executed until the user instructs the mobile device 120 to stop, or until a configurable amount of time (e.g., a number of hours or days) or number of attempts has been reached. In some optional embodiments, step 13 may be re-executed until a new encrypted packet is received (see, e.g., at step 12) from the same or another medication delivery device 102 is received, in which case any previously -held encrypted packet may be discarded from memory.Alternatively, or in addition, if mobile device 120 is unable to connect to cloud server 140, the mobile application handling the encrypted packet may save the encrypted packet into a sync queue and wait until the mobile application receives an indication from an operating system of mobile device 120 that internet connectivity has been restored. In such embodiments, step 13 is not re-executed per se, but the mobile application handling the encrypted packet merely pauses processing of the encrypted packet and refrains from moving on to step 14 until the application receives the aforementioned indication from the operating system.

[0067] If mobile device 120 can connect to the cloud server 140, mobile device 120 sends the unique serial number associated with delivery device 102 (extracted from advertising packets sent from delivery device 102 and saved into the mobile device’s memory at step “7. Save serial number”) to cloud server 140. This serial number may be sent in cleartext via communication link 170. (“14. Serial number (cleartext)”). In some embodiments, mobile device 120 must authenticate itself to cloud server 140 before, or concurrent with, sending the unique serial number. For example, mobile device 120 may authenticate itself to cloud server 140 by providing a verified user ID and password or a security token. Alternatively, or in addition, mobile device 120 may authenticate itself to cloud server 140 by providing a mobile device ID. If the mobile device ID does not match the ID of the user’ s primary mobile device (as recorded by the cloud server from previous cloud calls from that specific user), the cloud server may reject the request. This authentication requirement prevents attackers from tricking the cloud server into providing decryption keys to someone other than a legitimate user.

[0068] Upon receiving the serial number at step 14, and assuming the cloud server can successfully authenticate mobile device 120, the cloud server 140 responds to mobile device 120 with a unique decryption key associated with delivery device 102’s serial number. (“15. Decryption Key”). In some encryption protocols, the encryption key and the decryption key may be one and the same key - in other protocols, the two keys may differ. The cloud server 140 may look up this decryption key by accessing database 156 and retrieving the unique decryption key associated with delivery device 102’ s unique serial number.

[0069] Upon receipt of the decryption key from cloud server 140, mobile device 120 may then use the received decryption key to decrypt the encrypted packet it received from delivery device 102 at step 12. Once the encrypted packet has been decrypted, mobile device 120 then retrieves the timestamp that delivery device 102 included within the packet, andcompares the timestamp retrieved from the encrypted packet with the timestamp that mobile device 120 saved at step “10. Save timestamp’’). If the retrieved timestamp does not match the saved timestamp, mobile device 120 rejects delivery device 102, as well as any information received therefrom, as inauthentic. If the retrieved timestamp matches the saved timestamp, mobile device 120 declares delivery device 102, and the information included within the encrypted packet received at step 12, authentic. This step corresponds to step “16. Decrypt I validate timestamp.”

[0070] The use of a decryption key retrieved from cloud server 140 mitigates the possibility of an adversary sending dose event data to mobile device 120 that poses as data sent from a legitimate delivery device 102 but is in fact transmitted by a fraudulent or counterfeit delivery device, or a device that is not a medication delivery device at all. If the advertising packet sent by a counterfeit device at step 4 does not contain a serial number that cloud server 140 recognizes, the cloud server 140 would return an error message at step 15 indicating that the serial number could not be found. Upon receipt of such an error message, mobile device 120 may conclude that the advertising packets were sent by a counterfeit device. Alternatively, if the advertising packets sent by a counterfeit device at step 4 does contain a serial number that cloud server 140 recognizes (i.e., the serial number corresponds to a genuine delivery device 102), but the counterfeit device does not possess secret encryption key 115 corresponding to that serial number, then when mobile device 120 attempts to decrypt the encrypted and validate the timestamp at step 16, the resulting decryption process would not work. This is because the decryption key returned by cloud server 140 at step 15 is designed to only successfully decrypt data that has been encrypted using secret encryption key 115 possessed by delivery device 102. If the decryption key returned by cloud server 140 is applied to data encrypted using some other encryption key, the output data would be nonsensical and the decryption operation would fail. If this happens at step 16, i.e., if mobile device 120 finds itself unable to successfully decrypt the encrypted packet received at step 12 from delivery device 102 with the decryption key received at step 15 from cloud server 140, the mobile device 120 may also conclude that the advertising packets were sent by a counterfeit device. In addition, the use of a timestamp mitigates the possibility of replay attacks, where an adversary records data transmitted wirelessly by a legitimate medication delivery device 102, then replays this recorded data later to the same (or a different) mobile device 120. Since the timestamp retrieved from such a recorded transmission would likely not match the timestamp saved by mobile device 120 at step 10,mobile device 120 would reject such a replay attack as originating from a fraudulent or counterfeit delivery device 102.

[0071] Finally, at step 17 (“If timestamp valid: decrypt / use data; If timestamp invalid: Discard data”), the mobile device determines whether to use data received from delivery device 102 depending on the results of the authentication at step 16. If delivery device and / or the information included within the encrypted packet is authenticated, then mobile device 120 may proceed to store, log, and / or use this information. Such use may include saving or displaying the dose event information in a log of the user’s medication doses. Such use may also include using this information to calculate a date and / or time for the user’s next dose. Alternatively, or in addition, this authenticated information may also be used to calculate an amount for the user’s next dose. In some embodiments, such authenticated dosing information may also be reported to a healthcare provider (HCP), a researcher, and / or a payer. This reporting may be accomplished, for instance, by sending this information to cloud server 140 via communication link 170. A HCP, researcher, and / or payer may use this authenticated information to track the user’s adherence to a medication regimen, and / or used to assess or validate the user’s response to the medication.

[0072] If the delivery device and / or the information included therein is declared inauthentic, the mobile device may delete or ignore the information included within the encryption packet or otherwise received from the delivery device 102, and / or refrain from including this information in the user’s medication log. The mobile device may also refrain from forwarding this information onto a HCP, researcher, and / or payer (e.g., refrain from transmitting this information to cloud server 140). Alternatively, or in addition, the mobile device may save and / or display the information from the encryption packet and / or delivery device, or forward this information onto the HCP, researcher, and / or payer, but warn any viewer of this information (e.g., through text, symbols, color, audible tones, or other discernible flags delivered through user-interface 127) that the information could not be authenticated and may be fraudulent or counterfeit. For instance, if the information is declared inauthentic, the mobile device may still display and / or log the information but add a text pop-up box or a danger symbol to alert the user that the information may be fraudulent or counterfeit.

[0073] In the authentication scheme discussed in FIGS. 7A and 7B, it is important to prevent attackers from gaining unauthorized access to secret decryption keys of delivery devices. In some embodiments, an additional layer of security may be implemented toprevent this from happening. For example, the mobile device 120 can send to the cloud server 140, as part of the communication at step 14, the encrypted packet received from the delivery device 102 at step 12 as well as the timestamp saved by the mobile device at step 10. Upon receipt of the communication at step 14, the cloud server can (i) look up the decryption key associated with the serial number of the delivery device 102, (ii) use the decryption key to decrypt the encrypted packet received from the delivery device, (iii) extract the timestamp saved within the encrypted packet, and (iv) compare the extracted timestamp with the timestamp saved by the mobile device at step 10. The cloud server 140 can proceed to step 15 (i.e., sending of the decryption key back to the mobile device 120) only if the extracted timestamp matches the saved timestamp. If the extracted timestamp does not match the saved timestamp, the cloud server 140 would refrain from proceeding to step 15. In this way, the cloud server 140 does not unnecessarily expose the decryption key by sending it to a (potentially fraudulent) mobile device 120.

[0074] FIGS. 8A and 8B shows exemplary logic 800 for implementation on processor 130 of mobile device 120, according to some embodiments. When executed by processor 130, logic 800 enables mobile device 120 to participate in the communications flow described above with respect to FIGS. 7A-7B. At step 802, mobile device 120 receives one or more unencrypted wireless communication packets from a medication delivery device (e.g., device 102), the unencrypted packets comprising a unique identifier associated with the medication delivery device. Such communication packets may be received in the form of a Bluetooth advertising packet, or in accordance with another wireless transmission protocol or format (e.g., WiFi, NFC, RFID). The unique identifier may comprise any alphanumeric code or sequence of characters that uniquely identifies a medication delivery device from other medication delivery devices. The unencrypted communication packet may further comprise additional data, such as whether the device 102 has dispensed its store of medication, a battery charge remaining in power source 602, an amount of time that has elapsed since the basecap 36 was removed, a type of medication stored in device 102, a manufacturing lot or batch number associated with the medication stored in device 102 which may be used to identify when, where, and / or how the medication was manufactured, a temperature currently sensed by temperature sensor 625, and a capacitance sensed by each of, or both of, capacitive pads 622 and 623.

[0075] At step 804, mobile device 120 transmits, in response to receipt of the unencrypted packets, a request for dose information to the medication delivery device. Thisrequest for dose information may comprise a first timestamp generated and saved by the mobile device 120. The timestamp may include the date and / or time at which the mobile device saved the timestamp, or it may consist of or include data generated deterministically from the current date and / or time. The timestamp may be generated by the mobile device based on a current date and / or time as determined by an on-board clock and / or calendar on the mobile device. In some embodiments, the first timestamp may be sent in cleartext, i.e., in a non-encrypted format.

[0076] At step 806, mobile device 120 receives, in response to the request transmitted at step 804, one or more encrypted wireless communication packets from the delivery device 102. Each such encrypted packet may comprise the requested dose information and a second timestamp. The requested dose information may comprise a date and / or time of a dose event. Alternatively, or in addition, the requested dose information may comprise an amount of time that has elapsed since the dose event was initiated or completed until the encrypted communication packet was transmitted by delivery device 102 (using this information, mobile device 120 may work out a date and / or time at which the dose event was initiated or completed by subtracting this amount of time from a current date and / or time). The requested dose information may also comprise a type of medication delivered, an expiration date for the medication, and / or manufacturing-related information associated with the delivered medication, such as a manufacturing lot or batch number. The requested dose information may also include data indicative of whether or not the capacitive pads 622 and / or 623 sensed skin contact at least once, or throughout, the dose event, whether any “liftoff’ events were detected in which skin contact was not detected at any point throughout the dose event, the temperature sensed by sensor 625 at the time of the dose event, a current amount of power remaining in power source 602, whether the basecap removal sensor 610 sensed that basecap 36 has been replaced over proximal end opening 40, and / or any other data that may be stored in memory 112 of medication delivery device 102, or recorded by or derived from the output of any of the sensors of device 102. The second timestamp may be any data indicative of or generated from a date and / or a time. The encrypted packet may be encrypted using a secret encryption key stored at the delivery device 102 and may be decrypted only using a secret decryption key.

[0077] At step 808, mobile device 120 determines whether it is able to communicate with cloud service provider, e.g., remote server 140. This may comprise determining whether mobile device 120 is able to connect to the Internet through, for example, a WiFi or cellularconnection. Even if mobile device 120 is able to connect to the Internet, this determination may also comprise determining whether mobile device 120 is able to connect with cloud server 140 specifically. If mobile device 120 is not able to connect to cloud server 140, logic 800 branches to step 810, where mobile device 120 stores the one or more encrypted wireless communication packets, in their original encrypted form, in a memory of the mobile device. In some embodiments, step 810 is executed regardless of whether mobile device 120 is able to connect to cloud server 140 - in other embodiments, step 810 is executed only if mobile device 120 is unable to connect to cloud server 140. Regardless of whether step 810 is executed at all times or only when mobile device is unable to connect to cloud server 140, if logic 800 determines that it is unable to connect to cloud server 140, logic 800 then continually branches back to step 808 and re-checks if mobile device 120 is able to connect to cloud server 140. The frequency at which mobile device 120 attempts to reconnect with cloud server 140 is a configurable parameter that may be adjusted by a system administrator as needed according to different embodiments. For example, mobile device 120 may attempt to connect to cloud server 140 once a minute, once every few minutes, once an hour, once a day, or at any other frequency. Alternatively or in addition, if logic 800 determines that it is unable to connect to cloud server 140, logic 800 may wait after step 810 until an operating system of the mobile device indicates that internet connectivity has been restored before moving on to step 812 at FIG. 8B. In such embodiments, step 808 is not re-executed per se, but logic 800 merely pauses processing of the encrypted packet and refrains from moving on to step 812 until it receives the aforementioned indication from the operating system. In the flowchart depicted in FIG. 8 A, the arrows connecting step 810 back to step 808, as well as the aiTows connecting steps 810, 811, and 812, are depicted in dashed lines to indicate these are alternative embodiments that may be implemented separately or simultaneously.

[0078] If mobile device 120 can connect with cloud server 140, logic 800 branches to step 812 at FIG. 8B. At step 812, mobile device 120 requests a decryption key associated with the unique identifier of the medication delivery device from the cloud service provider. This request may comprise a transmission, sent via communication link 170 between mobile device 120 and cloud server 140, that comprises the unique identifier of the medication delivery device 102 received at step 802. In some embodiments, the request / transmission at step 812 is the means by which mobile device 120 checks whether it can connect to cloud server 140. In such embodiments, step 812 and step 810 may be considered a single step,which is fulfilled and / or accomplished through the transmission of a single wireless transmission.

[0079] At step 814, in response to the transmission sent at step 814, mobile device 120 receives the requested decryption key from the cloud service provider. The cloud service provider may look up and retrieve the requested decryption key by consulting an internal database (e.g., database 156), and look up the decryption key associated with the unique identifier sent by mobile device 120 at step 812. In some encryption protocols, the encryption key and the decryption key may be one and the same key - in other protocols, the two keys may differ.

[0080] At step 816, mobile device 120 uses the decryption key received at step 814 to decrypt the encrypted wireless communication packet received at step 806. Once the encrypted packet has been decrypted, mobile device 120 then retrieves the second timestamp stored therein. At step 818, the mobile device 120 compares the retrieved second timestamp with the first timestamp that mobile device 120 had sent to the medication delivery device 102 at step 804.

[0081] If the two timestamps match, logic 800 branches to step 820, where the medication delivery device 102 is declared authentic, and the requested dose information is logged and / or used. Such use may include saving or displaying the dose event information in a log of the user’s medication doses. Such use may also include using this information to calculate a date and / or time for the user’s next dose. Alternatively, or in addition, this authenticated information may also be used to calculate an amount for the user’s next dose. In some embodiments, such authenticated dosing information may also be reported to a healthcare provider (HCP), a researcher, and / or a payer. For instance, this authenticated information may be used to track the user’s adherence to a medication regimen, and / or used to assess or validate the user’s response to the medication.

[0082] If the two timestamps do not match, logic 800 branches to step 822, where the medication delivery device 102 is declared not authentic, and the requested dose information is discarded (e.g., not saved or displayed in the user’s medication log, not used to calculate the user’s next dose, etc.). Alternatively, or in addition, the information received from medication delivery device 102 may be used and / or stored, but may be flagged as being potentially unreliable, so the user either knows not to rely on the information or to proceed with caution.

[0083] If mobile device 120 encounters an error at any point during logic 800, it may conclude that delivery device 102 is not authentic. For example, if mobile device 120 receives an error message from the cloud service provider at step 814 instead of the requested decryption key (indicating, for instance, that the unique identifier sent to cloud server 140 at 812 could not be found), mobile device 120 may conclude that delivery device 102 is not authentic. Similarly, if mobile device finds it is unable to decrypt the one or more encrypted wireless packets at step 816 using the decryption key received from the cloud server 140 at step 814, the mobile device may also conclude that delivery device 102 is not authentic.

[0084] The terms "first", "second", "third" and the like, whether used in the description or in the claims, are provided for distinguishing between similar elements and not necessarily for describing a sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances (unless clearly disclosed otherwise) and that the embodiments of the disclosure described herein are capable of operation in other sequences and / or arrangements than are described or illustrated herein.

[0085] While this invention has been described as having exemplary designs, the present invention can be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the invention using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which this invention pertains.

[0086] Various aspects are described in this disclosure, which include, but are not limited to, the following aspects:

[0087] 1. A medication delivery device configured to authenticate itself to a mobile device, the delivery device comprising: a reservoir holding a liquid medication; a dose sensor configured to determine when the medication delivery device has initiated or completed a dose event in which a dose of the mediation is delivered to a user; a wireless communication device; memory storing computer-executable instructions; and a processor configured to execute the instructions to: detect, using the dose sensor, when the medication delivery device has initiated or completed the dose event, receive, via the wireless communication device, a request for information regarding the dose event from the mobile device, the request including a time stamp, and transmit, via the wireless communication device, an encryptedpacket comprising the requested information regarding the dose event and the time stamp, wherein the encrypted packet has been encrypted using a secret encryption key.

[0088] 2. The medication delivery device of aspect 1 wherein the reservoir is part of a syringe assembly that includes a needle.

[0089] 3. The medication delivery device of aspect 2, wherein the dose sensor comprises an accelerometer configured to sense movement of the syringe assembly.

[0090] 4. The medication delivery device of aspect 1, wherein the dose sensor comprises at least one of a light sensor configured to detect movement of internal parts of the medication delivery device, a capacitance sensor configured to sense changes in capacitance induced by movement of internal parts of the medication delivery device, and an electrical contact sensor with one or more metallic contacts configured to detect completion or breaking of an electrical circuit in response to movement of internal parts of the medication delivery device.

[0091] 5. The medication delivery device of any one of aspects 1-4, wherein the processor is configured to periodically transmit advertising packets via the wireless communication device when the processor detects via the dose sensor that the medication delivery device has initiated or completed the dose event.

[0092] 6. The medication delivery device of any one of aspects 1-4, wherein: the processor is configured to periodically transmit advertising packets before the processor detects that the medication delivery device has initiated or completed the dose event; when the processor detects that the medication delivery device has initiated or completed the dose of medication, the processor is configured to alter the periodically transmitted advertising packets to indicate that the dose event has been initiated or completed.

[0093] 7. The medication delivery device of any one of aspects 5-6, wherein the advertising packets comprises a unique identifier for the medication delivery device.

[0094] 8. The medication delivery device of any one of aspects 1-7, wherein the requested dose information included in the encrypted packet comprises data indicative of at least one of a date on which the dose event was initiated or completed, a time at which thedose event was initiated or completed, or an amount of time that has elapsed since the dose event was initiated or completed.

[0095] 9. A method for authenticating a medication delivery device at a mobile device, the method comprising: receiving, by the mobile device, one or more unencrypted wireless communication packets from a medication delivery device, the unencrypted wireless packets comprising a unique identifier associated with the medication delivery device: transmitting, in response to receipt of the unencrypted packets, a request for dose information from the mobile device to the medication delivery device; receiving, by the mobile device, one or more encrypted wireless communication packets comprising the requested dose information; determining whether the mobile device is able to communicate with a cloud service provider via a cellular or wireless network; and if the mobile device is not able to communicate with the cloud service provider, storing the one or more encrypted wireless communication packets in a memory of the mobile device until the mobile device is able to communicate with the cloud service provider.

[0096] 10. The method of aspect 9, wherein if the mobile device is not able to communicate with the cloud service provider, the method further comprises periodically repeating the determining step until communications with the cloud service provider can be established.

[0097] 11. The method of any one of aspects 9-10, wherein if the mobile device is able to communicate with the cloud service provider, the method further comprises; requesting, by the mobile device, a decryption key associated with the unique identifier of the medication delivery device from the cloud service provider; receiving, by the mobile device, the requested decryption key from the cloud service provider; and using the received decryption key to decrypt the one or more encrypted wireless communication packets.

[0098] 12. The method of aspect 11, wherein: the request for dose information transmitted by the mobile device comprises a first timestamp; the one or more encrypted wireless communication packets received from the medication delivery device comprise a second timestamp; and if the mobile device is able to communicate with the cloud provider, the method further comprises: retrieving the second timestamp from the decrypted one or more wireless communication packets; and determining whether the retrieved second timestamp matches the first timestamp.

[0099] 13. The method of any one of aspects 9-12, wherein the dose information comprises data indicative of a date or time for each of one or more dose events.

[0100] 14. The method of any one of aspects 9-13, wherein the dose information comprises data indicative of a dose size for each of one or more dose events.

[0101] 15. The method of any one of aspects 13-14, further comprising including the dose information in a medication log of the user if the retrieved second timestamp is determined to match the first timestamp.

[0102] 16. The method of any one of aspects 13-14, further comprising sending the dose information to the cloud service provider if the retrieved second timestamp is determined to match the first timestamp.

[0103] 17. The method of any one of aspects 13-14, further comprising displaying a warning on a user-interface that the dose information could not be authenticated if the retrieved second timestamp does not match the first timestamp.

[0104] 18. The method of any one of aspects 9-14, wherein the medication delivery device is a medication injection device.

[0105] 19. The method of aspect 18, wherein the medication delivery device is an autoinjector.

[0106] 20. A mobile device configured to authenticate a medication delivery device, the mobile device comprising: a wireless communication device; memory storing instructions; and a processor configured to execute the instructions to implement the method of any one of aspects 9-19.

[0107] 21. Non-transitory computer-readable media comprising instructions that, when executed by one or more processors, are operable to cause the one or more processors to implement the method of any one of aspects 9-19.

Claims

WHAT IS CLAIMED IS:

1. A medication delivery device configured to authenticate itself to a mobile device, the delivery device comprising: a reservoir holding a liquid medication; a dose sensor configured to determine when the medication delivery device has initiated or completed a dose event in which a dose of the medication is delivered to a user; a wireless communication device; memory storing computer-executable instructions; and a processor configured to execute the instructions to: detect, using the dose sensor, when the medication delivery device has initiated or completed the dose event, receive, via the wireless communication device, a request for information regarding the dose event from the mobile device, the request including a time stamp, and transmit, via the wireless communication device, an encrypted packet comprising the requested information regarding the dose event and the time stamp, wherein the encrypted packet has been encrypted using a secret encryption key.

2. The medication delivery device of claim 1 wherein the reservoir is part of a syringe assembly that includes a needle.

3. The medication delivery device of claim 2, wherein the dose sensor comprises an accelerometer configured to sense movement of the syringe assembly.

4. The medication delivery device of claim 1, wherein the dose sensor comprises at least one of a light sensor configured to detect movement of internal parts of the medication delivery device, a capacitance sensor configured to sense changes in capacitance induced by movement of internal parts of the medication delivery device, and an electrical contact sensor with one or more metallic contacts configured to detect completion or breaking of an electricalcircuit in response to movement of internal parts of the medication delivery device.

5. The medication delivery device of any one of claims 1-4, wherein the processor is configured to periodically transmit advertising packets via the wireless communication device when the processor detects via the dose sensor that the medication delivery device has initiated or completed the dose event.

6. The medication delivery device of any one of claims 1-4, wherein: the processor is configured to periodically transmit advertising packets before the processor detects that the medication delivery device has initiated or completed the dose event; when the processor detects that the medication delivery device has initiated or completed the dose of medication, the processor is configured to alter the periodically transmitted advertising packets to indicate that the dose event has been initiated or completed.

7. The medication delivery device of any one of claims 5-6, wherein the advertising packets comprises a unique identifier for the medication delivery device.

8. The medication delivery device of any one of claims 1-7, wherein the requested dose information included in the encrypted packet comprises data indicative of at least one of a date on which the dose event was initiated or completed, a time at which the dose event was initiated or completed, or an amount of time that has elapsed since the dose event was initiated or completed.

9. A method for authenticating a medication delivery device at a mobile device, the method comprising: receiving, by the mobile device, one or more unencrypted wireless communication packets from a medication delivery device, the unencrypted wireless packets comprising a unique identifier associated with the medication delivery device; transmitting, in response to receipt of the unencrypted packets, a request for dose information from the mobile device to the medication delivery device;receiving, by the mobile device, one or more encrypted wireless communication packets comprising the requested dose information; determining whether the mobile device is able to communicate with a cloud service provider via a cellular or wireless network; and if the mobile device is not able to communicate with the cloud service provider, storing the one or more encrypted wireless communication packets in a memory of the mobile device until the mobile device is able to communicate with the cloud service provider.

10. The method of claim 9, wherein if the mobile device is not able to communicate with the cloud service provider, the method further comprises periodically repeating the determining step until communications with the cloud service provider can be established.

11. The method of any one of claims 9-10, wherein if the mobile device is able to communicate with the cloud service provider, the method further comprises: requesting, by the mobile device, a decryption key associated with the unique identifier of the medication delivery device from the cloud service provider; receiving, by the mobile device, the requested decryption key from the cloud service provider; and using the received decryption key to decrypt the one or more encrypted wireless communication packets.

12. The method of claim 11, wherein: the request for dose information transmitted by the mobile device comprises a first timestamp; the one or more encrypted wireless communication packets received from the medication delivery device comprise a second timestamp; and if the mobile device is able to communicate with the cloud provider, the method further comprises:retrieving the second timestamp from the decrypted one or more wireless communication packets; and determining whether the retrieved second timestamp matches the first timestamp.

13. The method of any one of claims 9-12, wherein the dose information comprises data indicative of a date or time for each of one or more dose events.

14. The method of any one of claims 9-13, wherein the dose information comprises data indicative of a dose size for each of one or more dose events.

15. The method of any one of claims 13-14, further comprising including the dose information in a medication log of the user if the retrieved second timestamp is determined to match the first timestamp.

16. The method of any one of claims 13-14, further comprising sending the dose information to the cloud service provider if the retrieved second timestamp is determined to match the first timestamp.

17. The method of any one of claims 13-14, further comprising displaying a warning on a user-interface that the dose information could not be authenticated if the retrieved second timestamp does not match the first timestamp.

18. The method of any one of claims 9-14, wherein the medication delivery device is a medication injection device.

19. The method of claim 18, wherein the medication delivery device is an autoinjector.

20. A mobile device configured to authenticate a medication delivery device, the mobile device comprising: a wireless communication device; memory storing instructions; anda processor configured to execute the instructions to implement the method of any one of claims 9-19.

21. Non-transitory computer-readable media comprising instructions that, when executed by one or more processors, are operable to cause the one or more processors to implement the method of any one of claims 9-19.

Images