Management system for medication

Abstract

A management system for medication includes an electronic case configured to support a user's medication and a computing device configured to communicate with the case. The case includes one or more sensors, such as a pressure sensor, to produce sensor information indicating whether the medication is disposed in the case, a battery sensor to indicate a charge level of the case, and, in some examples, a location sensor to indicate a location of the case. A controller obtains the sensor information and provides status information to the computing device. The computing device provides notifications based on the status information and, in some examples, automatically or semi-automatically initiates communications to designated emergency contacts in response to determining that medication has been removed from the case. The case can include light sources and a speaker controlled by the controller. An identifier, such as a near-field communication tag, can associate the case with a user. Status information can be shared with additional users (e.g., caregivers). The system is suitable for emergency medications such as epinephrine nasal spray.

Description

MANAGEMENT SYSTEM FOR MEDICATIONPRIORITY CLAIM

[0001] The present disclosure claims priority to US provisional patent application 63 / 740769 filed December 31 , 2024, the contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to management systems, and, more particularly, to a management system for medication.BACKGROUND

[0003] Users may have one or more medications to maintain their health. For example, users may have emergency medications, such as epinephrine nasal sprays, epinephrine autoinjectors, glucose tablets, and the like. Users may desire to ensure emergency medications are usable and accessible so that users can be ready and prepared for emergencies that may require emergency medications.

[0004] Conventional medication management devices, such as those described in U.S. Patent No. 11,386,771 have incorporated various sensing and communication features to track medication presence or general readiness. However, such systems have typically relied on indirect indicators such as pressure or contact sensors within the case to infer the presence of a medication unit, or on user input to confirm device status. These approaches are problematic in that they can misclassify a medication unit that is inserted but already expended as being ready for use, or may indicate readiness when a dummy or training unit is present. Moreover, configurations that depend on multi-sensor fusion or complex calibration sequences can be prone to false positives, degraded reliability over time, and increased power consumption. Accordingly, there remains a need for improved systems that can more reliably determine medication readiness using simpler, more deterministic sensing architectures while avoiding the pitfalls of conventional presence-based detection systems.SUMMARY

[0005] An aspect of the specification provides a management system for medication, said system including: a case configured to support a medication unit of a user, said medication unit having a plunger movable between a retracted position and an extended position, a Page 1 of 33P13650PC00sensor disposed in said case and positioned to detect a state of said plunger, said sensor configured to generate sensor information indicative of whether said plunger is in a doseready position, and a computing device configured to communicate with said case, said computing device being configured to provide status information to a user based on said sensor information, wherein said status information indicates a dose-ready state when said plunger is detected in said dose-ready position and a not-ready state when said plunger is not detected in said dose-ready position.

[0006] An aspect of the specification provides a management system, wherein said sensor includes an optical, magnetic, or mechanical displacement sensor configured to detect an axial position of said plunger.

[0007] An aspect of the specification provides a management system, wherein said computing device is configured to determine said dose-ready state based solely on said sensor information without reliance on pressure, weight, or load measurements.

[0008] An aspect of the specification provides a management system, wherein said computing device is configured to execute a deterministic thresholding routine that transitions from a not-ready state to a dose-ready state only upon detection of a plunger signal exceeding a predefined displacement threshold.

[0009] An aspect of the specification provides a management system, wherein said computing device is further configured to maintain said dose-ready state until detection of a monotonic change in said plunger signal corresponding to a dose discharge event.

[0010] An aspect of the specification provides a management system, wherein said computing device is configured to default to a not-ready state in the absence of a qualifying plunger signal.

[0011] An aspect of the specification provides a management system, wherein said sensor includes a Hall-effect sensor aligned with said plunger, said Hall-effect sensor generating said sensor information in response to motion of a magnetic element coupled to said plunger.

[0012] An aspect of the specification provides a management system, wherein said sensor includes a reflective optical sensor positioned to detect movement of an optical feature disposed on said plunger.

[0013] An aspect of the specification provides a management system, wherein said computing device is configured to display a visual indicator or provide an audible notification representing said dose-ready state.Page 2 of 33P13650PC00

[0014] An aspect of the specification provides a management system, wherein said case further includes a controller configured to filter said sensor information to reduce transient noise and to provide filtered data to said computing device for determination of said doseready state.

[0015] An aspect of the specification provides a management system further including a management engine for group administration of a plurality of cases.

[0016] An aspect of the specification provides a case according to any of the foregoing.

[0017] An aspect of the specification provides a computing device wherein the computing device has multiple accounts associated with a plurality of cases.

[0018] An aspect of the specification provides a management engine according to any of the foregoing.

[0019] An aspect of the specification provides a management system for medication, said system including: a case configured to support the medication of a user, wherein said case includes a sensor configured to produce sensor information indicating a status of whether the medication is disposed in said case; and a computing device configured to communicate with said case, wherein said computing device is configured to provide status information to a user based on said sensor information.

[0020] An aspect of the specification provides a management system enables or facilitates users to manage medication such as, for example, epinephrine nasal sprays for use during emergency allergic reactions. The system may include a case that can support two epinephrine nasal sprays for a patient, and can communicate with a computing device for providing information related to the case to the patient. The information may indicate a location of the case, a charge level of the case, and / or whether the nasal sprays are disposed in the case. The information related to the case may also be provided to one or more users such as, for example, caregivers, parents, and / or guardians of patient.

[0021] The computing device may provide notifications related to the emergency medication and / or the case based on the status information so that patient may be assured that case is in a location where patient can effectively retrieve case in an event of an emergency and case has usable emergency medication. The system may send one or more communications in response to determining nasal spray has been removed from case, or that medication dose is not available, to notify one or more contacts that patient has experienced an emergency allergic reaction.Page 3 of 33P13650PC00

[0022] In one example of the present disclosure, a management system for medication includes an electronic case that can support the medication of a user. The case has a sensor that can produce sensor information indicating a status of whether the medication is disposed in the case. The management system has a computing device that can communicate with the case. The computing device can provide status information to a user based on the sensor information.

[0023] In another example, the sensor is a pressure sensor.

[0024] In yet another example, further including another computing device that can provide the status information to another user.

[0025] In another example of the present disclosure, an electronic case for medication includes a housing that can support the medication, a first sensor that can generate first information indicating the medication is not disposed in the housing, a second sensor that can generate second information indicating a charge level of the case, and a controller that can obtain the first and second information, and provide third information based on the first and second information to a computing device.

[0026] In another example, the case further includes a third sensor that can generate fourth information indicating a location of the case, the third information further based on the fourth information.

[0027] In yet another example, the case further includes a speaker communicatively coupled to the controller. The controller can trigger the speaker to produce a sound in response to fourth information obtained from the computing device.

[0028] In still another example, the first sensor is a pressure sensor.

[0029] In a further example, an identifier can associate the case with a user.

[0030] In yet another example, the identifier is a near-field communication tag.

[0031] In still another example, the medication is epinephrine nasal spray.

[0032] Thus, the system may be implemented and used to improve management of medication. This is accomplished by an electronic case that has sensors for monitoring the status of the case, and a computing device that can communicate with the case for providing status information to patient, caregivers, and / or healthcare providers of patient. Further, communications can be automatically or semi-automatically provided to emergency contacts if controller determines that the patient has experienced an allergic reaction, which may reduce delays in contacting emergency contacts.Page 4 of 33P13650PC00

[0033] The present specification also contemplates methods, systems, apparatuses and computer readable media according to any of the foregoing.

[0034] These and other objects, advantages, purposes, and features of this disclosure will become apparent upon review of the following specification in conjunction with the drawings.BRIEF DESCRIPTION OF THE FIGURES

[0035] The present specification includes the attached Figures, in which:

[0036] FIG. 1 is a diagram of a management system for medication, the system including a medication case, a data network, and a computing device;

[0037] FIG. 2 is a block diagram of the medication case of FIG. 1 .

[0038] FIG. 3 is a block diagram of the computing device of FIG. 1 .

[0039] FIG. 4 is a flowchart showing example operation of the case.

[0040] FIG 5. is a system diagram showing a plurality of cases and computing devices and additionally including a management engine.

[0041] FIG 6. is a flowchart showing example operation of the management engine.

[0042] FIG 7. shows the nasal spray case of FIG. 1 in greater detail.DETAILED DESCRIPTION

[0043] Referring now to the drawings and illustrative examples depicted therein, an environment 10 has a system 12 for managing a medication unit such as, for example, epinephrine nasal sprays for use during emergency allergic reactions. Management system 12 has an electronic case 14 that can store an epinephrine nasal spray 16 prescribed to a user or patient. System 12 can provide the patient with output information indicating a status of case 14 so that the patient may be better prepared to administer nasal spray 16 in an event of an emergency allergic reaction. For example, the status of case 14 may indicate whether nasal spray 16 is disposed in case 14, location of case 14, whether case 14 is open or closed, and / or charge level of case 14.

[0044] System 12 can provide notifications to the patient related to the status of case 14. For example, system 12 can provide the patient with a location notification indicating that case 14 is located outside of a specified range relative to patient. The location notification may assure the patient that case 14 can be effectively retrieved in an event of an emergency Page 5 of 33P13650PC00allergic reaction. Further, the location notification may prevent the patient from misplacing case and / or instances of theft.

[0045] Case 14 has a speaker 18 that can produce a sound so that the patient can locate case 14. Further, case 14 has an identifier 20 such as, for example, a near-field communication (NFC) that can be used to identify the patient as owner of case 14.

[0046] System 12 can provide notifications to the patient related to nasal spray 16. For example, system 12 can provide patient with a medication notification indicating that the patient should obtain another nasal spray. The medication notification may assure the patient that case 14 has adequate nasal spray stored in case 14 such as, for example, nasal spray that is non-expired and contains a dose ready for administration.

[0047] System 12 can provide communications to emergency contacts of the patient based on information indicating that the patient has experienced an emergency allergic reaction. The emergency contacts may include any contacts designated by patient such as, for example, emergency dispatch (e.g., 911), a family member, and the like. The communications may indicate the patient has experienced an allergic reaction, along with any other suitable information such as, for example, a location of patient. The communications to emergency contacts of the patient may reduce delays in contacting emergency contacts in an event of an emergency allergic reaction.

[0048] System 12 can provide guidance information to the patient based on information indicating that the patient has experienced an emergency allergic reaction. For example, guidance information may indicate a procedure for administering nasal spray 16 and / or directions to a hospital located nearest to patient.

[0049] System 12 can prompt the patient to provide allergic reaction information to system 12 based on information indicating that the patient has experienced an emergency allergic reaction. For example, system 12 may prompt the patient to answer one or more questions related to symptoms, severity, and / or triggers experienced by patient. System 12 may share this allergic reaction information with one or more other users in environment 10 such as, for example, a healthcare provider of the patient so that communicating accurate and timely allergic reaction information may be improved.

[0050] System 12 can provide educational information to the patient that may prepare the patient in an event of an emergency allergic reaction. The educational information may indicate how to properly administer nasal spray 16, best practices for handling an emergency Page 6 of 33P13650PC00allergic reaction, and / or response guidelines for handling an emergency allergic reaction. The patient obtaining educational information may allow the patient to be better prepared for an emergency allergic reaction, may improve confidence of the patient administering nasal spray, and / or may reduce errors during allergic reactions.

[0051] The educational information may include tutorials having text, video and / or interactive content. For example, a tutorial may instruct the patient to participate in hands-on training using a training device such as, for example, in a U.S. provisional patent application titled

[0052] "TRAINING DEVICE FOR MEDICAL NASAL APPLICATORS," filed Dec. 31 , 2024, bearing application number US63 / 704975, which is hereby incorporated by reference in its entirety. The tutorials may also instruct the patient how to use and reset the training device for future training purposes.

[0053] Alternatively or additionally, system 12 can provide one or more caregivers of the patient in environment 10 with information indicating the status of case 14, notifications related to the status of case 14, notifications related to nasal spray 16, and / or educational information.

[0054] Caregivers may include, for example, a parent, a teacher, a school professional, a camp counselor, and / or a babysitter of the patient. Caregivers may be designated by a manager of patient, such as a parent or guardian of patient, and stored in settings of system 12.

[0055] Referring to FIG. 1 , environment 10 has a computing device 22 that may be used by patient. For example, computing device 22 may be a smartphone or smartwatch. Patient computing device 22 can communicate with case 14 over a network 24 such as, for example, a personal area network (e.g., Bluetooth network), a wireless local area network (e.g., a WiFi network), and the like. Case 14 may provide status information to patient computing device 22 via network 24. The status information may indicate whether nasal spray 16 is disposed in case 14, location of case 14, open (or closed) status of case 14, connection of case 14 to network 24 / computing device 22, and / or charge level of case 14. Patient computing device 22 may provide information to the patient such as, for example, the status of case 14, the notifications to the patient related to the status of case 14, the notifications to the patient related to nasal spray 16, and / or the educational information based on the status information.

[0056] Referring to FIG. 2, case 14 includes a plurality of sensors 26 that can produce sensor information, and a controller 28 communicatively coupled to one or more of sensors 26.Page 7 of 33P13650PC00

[0057] Controller 28 can communicate the status information to patient computing device 22 based on the sensor information. Controller 28 is implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware.

[0058] Sensors 26 include a pressure sensor 30 that can produce pressure sensor information for indicating whether nasal spray 16 is disposed in case 14. Pressure sensor 30 may include any suitable type of pressure sensor such as, for example, a piezoelectric sensor, a capacitive pressure sensor, and the like.

[0059] Case 14 has a housing 32 that defines a divot 34 for holding nasal spray 16, and pressure sensor 30 may be coupled to divot 34. Pressure sensor 30 may produce pressure sensor information in response to detecting a change in pressure. For example, pressure sensor 30 may detect a change in pressure when nasal spray 16 is removed from divot 34, and / or may produce pressure sensor information indicating nasal spray 16 is not disposed in case 14 based on the detected change in pressure. In another example, pressure sensor 30 may continuously measure pressure and produce pressure sensor information indicating whether nasal spray 16 is disposed in case 14. (In addition, (or, more preferably, instead), pressure sensor 30 (or another type of sensor) may detect the presence or absence of the distal tip of the plunger of nasal spray, but without actual confirmation of whether the nasal spray 16 cannister is in the case, or not. The presence of the distal tip of the plunger indicates “dose readiness” but does not confirm or deny the presence of whether nasal spray 16, itself, is present in the case 14.)

[0060] Housing 32 may define another divot 34 for another nasal spray 16 similar to respective divot 34 and nasal spray 16. Two nasal sprays 16 may be stored in case 14 so that patient is prepared for a severe allergic reaction emergency where two doses need to be administered and / or two persons are simultaneously experiencing emergency allergic reactions. Case 14 may also have another pressure sensor 30 similar to pressure sensor 30 that can indicate whether second nasal spray 16 is disposed in case 14. Overall, any equipment and functionality associated with one divot 34 may be duplicated in the second divot 14.

[0061] Sensors 26 of case 14 include a location sensor 36 that can produce location information for indicating a location of case 14. Location sensor 36 may include any suitable type of location sensor such as, for example, a global positioning system (GPS) sensor, a tracking device (e.g., Life360 Tile, Apple AirTag), and the like.Page 8 of 33P13650PC00

[0062] Case 14 includes a battery 37 that is disposed in case 14 and can power case 14. Battery 37 may include any combination of one or more rechargeable energy storage devices such as, for example, a lithium-based battery, a capacitor, or even a fuel cell that allows for many cycles of energizing and de-energizing the energy storage device.

[0063] Case 14 may have one or more charging ports for charging battery 37. For example, case 14 may include a Universal Serial Bus (USB) Type-C port so that an electrical connector compatible with USB Type-C ports can transfer power from an external power source (e.g., utility grid power source) to battery 37.

[0064] Sensors 26 include a battery sensor 38 that can produce battery sensor information indicating a charge level of battery 37. Battery sensor 38 may include any suitable type of battery sensor such as, for example, a voltage sensor. Battery sensor 38 may produce battery sensor information in response to determining a voltage of battery 37 is below a specified threshold. In another example, battery sensor 38 may continuously measure voltage and produce battery sensor information indicating whether nasal spray 16 is disposed in case 14.

[0065] Case 14 has one or more light sources 39 such as, for example, light-emitting diodes (LED) that can indicate a charge level of battery 37. For example, light sources 39 may include a first LED that is activated when charge level of battery 37 is depleted, a second LED that is activated when charge level of battery 37 is low, and a third LED green that is activated when charge level of battery 37 is full.

[0066] Controller 28 of case 14 may be communicatively coupled to light sources 39 and can cause one of the light sources 39 to be activated based on battery sensor information obtained from battery sensor 38. Controller 28 is communicatively coupled to speaker 18 and can cause speaker 18 to produce a sound.

[0067] Referring to FIG. 3, patient computing device 22 has a controller 40 that can obtain status information from case controller 28 via network 24. Alternatively or additionally, computing device controller 28 may obtain status information from one or more of sensors 26 via another network. Computing device controller 40 is implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Patient computing device 22 may include one or more operating systems such as, for example, Apple iOS, Android, and the like. Patient computing device 22 has a software application ("app") 42 compatible with operating system 12 that may be executed by computing device controller 40 so that patient can manage case 14 via app 42. For example, app 42 may be a computer Page 9 of 33P13650PC00application (e.g., a macOS application, a Linux application, Windows application), a mobile application (e.g., IOS application, Android application), and / or a web browser (e.g., Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Apple Safari, Opera).

[0068] Patient computing device 22 has a user interface 44 that is communicatively coupled to computing device controller 40 and allows patient to interact with app 42 for managing case 14. App 42 can provide user interface information to user interface 44 so that user interface 44 can provide output information to patient such as, for example, the status of case 14, the notifications to the patient related to the status of case 14, the notifications to the patient related to nasal spray 16, and / or the educational information as discussed previously.

[0069] User interface 44 may have one or more output devices 46 that can provide output information. For example, user interface 44 may have a screen (e.g., a computer monitor, a touchscreen, projected display) having one or more display devices such as, for example, a touchscreen, LED (light-emitting diode), liquid crystal display (LCD), organic LED (OLED), a CRT (cathode ray tube), mini-LED, and / or a micro-LED. As such, output information provided by screen may be in the form of displays. In another example, user interface 44 may have a speaker. As such, output information provided by speaker may be in the form of sounds.

[0070] App 42 can provide a variety of experiences to patient computing device 22 executing app 42. For example, app 42 can cause user interface 44 to present a display based on settings of system 12 that may be designated by patient, such as a specified color theme. In another example, app 42 can cause patient computing device 22 to provide notifications based on settings of system 12 that may be designated by patient.

[0071] App 42 may continuously monitor location of case 14 based on location information in status information from case 14. For example, app 42 can cause user interface 44 to indicate location of case 14. However, if location information indicates case 14 is located outside of a specified range relative to patient, app 42 can cause user interface 44 to indicate an alert that location of case 14 is no longer known. For example, patient computing device 22 and location sensor 36 may have an established connection over network 24. In response to a lost connection between patient computing device 22 and location sensor 36, app 42 may determine no location is found. App 42 may also send information to case 14 that causes speaker 18 of case 14 to produce a sound in response to no location of case 14 being identified.Page 10 of 33P13650PC00

[0072] App 42 can monitor expiration dates of nasal sprays 16 and send notifications as expiration dates approach. Further, app 42 can send notifications to replace nasal sprays 16 such as, for example, after they have been administered.

[0073] App 42 can allow for purchases of replacement nasal sprays 16 through app 42. For example, app 42 may have an integrated pharmacy connection. In another example, app 42 may be able to locate nearby pharmacies.

[0074] Patient computing device 22 has a memory 48 that can store information related to case 14, nasal sprays 16, and / or patient. Memory 48 may have one or more non-transitory computer- readable mediums such as, for example, non-volatile memories (e.g., flash memory, hard disk drive, solid-state drive, read-only memory, secure digital card) and / or volatile memories (e.g., random access memory (RAM), synchronous dynamic RAM, dynamic RAM, cache memory).

[0075] Memory 48 may store emergency contacts, allergic reaction information, guidance information, educational information, caregivers of patient, designated manager of patient, and / or settings as discussed above. In yet another example, memory 48 can store one or more healthcare providers or medical professionals of patient, event logs of allergic reactions, and / or medical history. Medical history may be integrated with allergic reaction information.

[0076] App 42 can cause emergency contacts to be contacted based on settings stored in memory 48. For example, settings may indicate that emergency contacts should be automatically contacted upon app 42 obtaining information that indicates nasal spray 16 is not disposed in case 14, or if no ready-dose is detected in the case 14. (As noted earlier, no ready-dose state may be detected by way of a sensor that only detects the presence or absence of a distal tip of nasal spray 16, such that a “used” nasal spray 16 may be present in the case 14 with a retracted plunger - such that the distal tip of the plunger is not detected. Meanwhile the empty container of nasal spray 16 may still be present in the case 14; in which case the app 42 may alert that there is no available dose or no “ready-dose” detected in the case 14. By the same token, if the nasal spray 16 is not in the case 14 at all, likewise, no distal tip of the retracted plunger will be detected. In this embodiment, it is not the presence or absence of the container of nasal spray 16 that is relevant, it is whether or not a “readydose” is detected because of the presence of the distal tip of the plunger.)

[0077] In another example, settings may indicate that app 42 should be semi-automatically contacted by first providing a prompt via user interface 44 that requests patient to confirm via Page 11 of 33P13650PC00user interface 44 whether emergency allergic reaction has occurred in response to obtaining information that indicates nasal spray 16 is not disposed in case 14, or no-ready dose of nasal spray 16 is detected in the case. Then, if patient provides input information indicating an emergency allergic reaction has occurred, app 42 can cause emergency contacts to be contacted.

[0078] App 42 can prompt the patient to provide allergic reaction information to patient computing device 22 based on settings stored in memory 48. For example, app 42 may prompt the patient to provide allergic reaction information by causing user interface 44 to display an artificial intelligence or machine learning (AI / ML) enabled avatar that can conduct an interview with the patient and follow a post-event algorithm to capture the user input information. In another example, app 42 may use native keyboard inputs to create the report.

[0079] App 42 can cause any suitable medical data of the patient to be shared with appropriate users based on settings stored in memory 48. For example, patient medical data may be shared with professionals, manager, and / or caregivers.

[0080] Case 14 may have an account identifier for registering case 14 with app 42. For example, account identifier may include a Quick Response (QR) code or serial number registration. App 42 may create a user account associated with patient and case 14 based on account identifier and / or any other suitable information.

[0081] User interface 44 has one or more input controls 50 that can obtain user input information such as, for example, touchscreens, keyboards, keypads, microphones, mouses, and / or cameras.

[0082] Patient may interact with input controls 50 to provide input information such as, for example, to indicate settings, emergency contacts, caregivers and the like.

[0083] The designated caregivers and / or manager may also use computing devices that can execute app 42 such as, for example, smartphones, desktop computers, laptop computers, tablet computers, and the like. App 42 may create user accounts associated with respective caregivers and / or manager based on account identifier and / or any other suitable information. As such, multiple user accounts can be associated with case 14 based on account identifier so that all relevant caregivers can obtain adequate notifications. Users can also be associated with multiple cases in varying capacities - i.e. a user can be an admin of one case, an emergency contact on another, a member on another, etc.Page 12 of 33P13650PC00

[0084] Manager of patient may manage account permissions granted to caregivers' user accounts via manger's user account. For example, caregivers' user accounts may not be granted permission to access sensitive medical information of patient. Caregivers' user accounts may only be granted permission to obtain status of case 14, notifications related to the status of case 14, and / or notifications related to nasal spray 16.

[0085] User accounts of the patient, caregiver, and / or manager may have multiple account identifiers associated with respective cases. For example, the patient may have multiple cases stored in different locations such as, for example, at school, at cottage, at home, at camp, and the like. Cases may have respective account identifiers for registration with app 42, and may be named via app 42 such as, for example, "School Case", "Cottage Case", "Home Case", "Camp Case". Patient and manager of patient may be able to manage all cases of patient via their respective user accounts. Caregivers may only be able to manage and / or monitor certain cases based on permissions granted by manager. For example, user account associated with school nurse may only be able to monitor "School Case", user account associated with camp counsellor may only be able to monitor "Camp Case", and the like.

[0086] Patient's user account may opt in to join a community support group including a group of user accounts. If a user account included in community support group is in an emergency where medication is missing or expired, a "Distress Call" with the user’s real-time location can be broadcast to nearby users associated with other user accounts in community support group who may assist by sharing their medication supply.

[0087] App 42 can cause patient computing device 22 to produce a notification in response to a user computing device scanning identifier 20 (e.g., NFC tag) of case 14. For example, the computing device may have an NFC device and can scan NFC identifier 20. This may improve locating owner of case 14.

[0088] App 42 may provide allergy translation capability that can assist patient in foreign environments by generating translated messages detailing their allergy, anaphylactic condition, and / or whether they are having an emergency anaphylactic reaction. This may enhance preparedness of patient when travelling abroad to foreign countries and / or dealing with someone who does not speak their native language.

[0089] Account information and / or any other information stored on memory 48 may additionally or alternatively be stored in one or more memories of a server system. The one Page 13 of 33P13650PC00or more memories of server system may include one or more memories and / or storage devices that can be any type of non-transitory computer readable mediums such as, for example, one or more non- volatile memories (e.g., flash memory, a hard disk drive (HDD), a solid-state drive (SSD)) and / or volatile memories (e.g., Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM)).

[0090] The server system may include a server computing device (e.g., a hardware server, a cloud-based server, a web server, an application server, a proxy server, a network server, a laptop computer, a desktop computer) that may host a website (e.g., a web application) so that the patient computing device 22 and / or any other user computing device executing app 42 can manage case 14.

[0091] The server system may communicate with the user computing devices via a network that has any combination of wired and / or wireless networks such as, for example, one or more local area networks (LANs), wide area networks (WANs), cellular or mobile networks, and / or the Internet.

[0092] App 42 may be built with end-to-end encryption and adhere to relevant data privacy regulations (e.g., HIPAA, GDPR) for ensuring sensitive medical information remains secure.

[0093] Further, although examples of environment 10 is shown in FIGS. 1-3, one or more of the elements illustrated in FIGS. 1-3 may be combined, divided, re-arranged, omitted, and / or implemented in any other way. For example, system 12 may be adapted for managing other medication such as, for example, epinephrine auto-injectors, glucose tablets, and the like.

[0094] Further, environment 10 shown in FIGS. 1-3 may include one or more elements in addition to and / or instead of the elements shown in FIGS. 1 -3, and / or may include more than one of the elements shown in FIGS. 1-3.

[0095] Accordingly, the system described herein has a case and a computing device. The case can store emergency medication. The case has sensors that can monitor a status of the case such as, for example, whether the emergency medication is disposed in the case, a location of the case, and / or a charge level of the case. The case can be in communication with the computing device such as, for example, over a Bluetooth network so that the computing device can obtain the status information from the case. The computing device may provide notifications related to the emergency medication and / or case based on the status information so that patient may be assured that case is in a location where patient can effectively retrieve case in an event of an emergency and case has usable emergency Page 14 of 33P13650PC00medication. These notifications may also be provided to other users such as, for example, caregivers of patient. Further, communications can be automatically or semi-automatically to emergency contacts if computing device determines user has experienced an allergic reaction.

[0096] Controller 40 may be implemented by one or more computing devices in addition to or instead of the patient computing device 22 such as, for example, hardware servers, cloudbased servers, web servers, application servers, proxy servers, and / or network servers. Further, controller 40 may be distributed across computing devices at one or more different network locations (e.g., a peer-to-peer network environment, a client-server network environment).

[0097] App 42 may be implemented as computer-readable instructions that may be executed by controller 40. The computer-readable instructions may be included in software stored on one or more non-transitory computer-readable mediums associated with the controller 40, such as the memory 48, in which information is stored for any duration.

[0098] The computer-readable instructions may be downloaded to controller 40 from a software distribution platform (e.g., Apple App Store, Google Play Store, Microsoft Store). The computer- readable instructions may be stored in one or more formats such as, for example, an un- compressed format, a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, and / or a packaged format. For example, the computer-readable instructions may be fragmented and stored on one or more non-transitory computer-readable mediums located at the same or different locations of a network or collection of networks (e.g., in the cloud, in edge devices).

[0099] The computer-readable instructions may be one or more programs and / or one or more portions of programs for execution by one or more computing devices (e.g., the controller 40). The computer-readable instructions may be in a non-executable state such that additional steps are required to make them executable by a computing device. Additional steps may include installation, modification, decryption, decompression, compilation, providing a library, configuration (e.g., settings stored), etc. Accordingly, the one or more non-transitory computer- readable mediums may include one or more machine-readable instructions regardless of the particular format, language, and / or or state of the machine-readable instructions.Page 15 of 33P13650PC00

[0100] Controllers 28, 40 are implemented as one or more devices such as, for example, programmable processors (e.g., a field programmable gate array, a programmable logic controller), microprocessors (e.g., a central processing unit, a multi-core processor, a crypto processor, a digital signal processor, a graphics processing unit), microcomputers (e.g., an electronic control unit), microcontrollers, central processing units, state machines, and / or circuits (e.g., an analog circuit, a logic circuit, a crypto circuit, an application specific integrated circuit).

[0101] Figure 4 shows a flowchart depicting a method 400 for managing medication. Method 400 can be implemented on case 14, making use of patient computing device 22 as indicated, or a variant thereon. The blocks of method 400 need not be performed in the exact sequence shown and / or some blocks may be performed in parallel. Thus method 400 can also be varied.

[0102] Block 404 comprises initialization. In one example, the case 14 powers the controller 28 and executes a bootstrap routine to (i) load configuration parameters from local memory (e.g., alert thresholds, geofence definitions, notification policies), (ii) establish one or more communication links with the patient computing device 22 and / or a server (e.g., Bluetooth pairing, Wi-Fi association, authenticated session keys, or as will be discussed below, management engine 504 of Figure 5), and / or (iii) perform device self-tests including battery measurement, case open / closed switch, sensor sanity checks, and indicator verification (e.g., LED blink test and speaker tone). Initialization can additionally include time synchronization, selection of a sampling cadence, and registration of one or more event handlers (e.g., battery-low, link-loss, presence-change, case open / closed status, plunger position). In another example, the case 14 loads profile data for multiple medication wells (e.g., left / right positions) and associates each well with metadata such as medication type, lot, and expiration.

[0103] Block 408 comprises acquiring sensor data. In one example, controller 28 obtains, in a continuous or periodic manner, one or more of: battery sensor 38 voltage or state-of-charge; location sensor 36 information (e.g., Global Navigation Satellite System (GNSS) fix, network-derived location, or proximity data); presence or load information from a pressure sensor 30 mechanically coupled to a well; lid / open state (e.g., a magnetic or optical switch); inertial data (e.g., a 3-axis accelerometer); and, in some embodiments, a tag or identifier associated with a medication or trainer unit (e.g., near field communication (NFC),Page 16 of 33P13650PC00radio frequency identification (RFID), optical code, or magnetic key). The acquired measurements can be time-stamped, filtered (e.g., digital low-pass filtering, debouncing), and fused to form a current sensor vector. Historical data may be retained to compute deltas (e.g., ^pressure, A Received Signal Strength Indicator (RSSI) useful for change detection.

[0104] Block 412 comprises determining whether a battery level satisfies a threshold. In one example, controller 28 compares a measured or estimated state-of-charge against one or more thresholds (e.g., “low” and “critical”), optionally using hysteresis to avoid oscillation. In another example, the controller computes a predicted remaining operating time based on recent current draw and duty cycle and evaluates the prediction against a time-to-empty threshold (e.g., less than N hours). If the battery level does not satisfy the threshold, flow proceeds to block 416 for exception handling; otherwise, method 400 proceeds to block 420. In some implementations, the threshold is adaptive based on ambient temperature, expected use window (e.g., school hours), or whether the case 14 is currently charging.

[0105] Block 420 comprises determining whether the case 14 is within range. In one example, “in range” is satisfied if a proximity metric between the case 14 and the patient computing device 22 exceeds a value (e.g., Bluetooth RSSI above a level or a maintained encrypted session). In another example, “in range” is satisfied by geofencing rules that compare the location sensor 36 output to a stored safe region (e.g., home, school, camp) with an age-of-fix constraint. In another example, “in range” is satisfied by geofencing rules that compare the location sensor 36 with the management engine 504 of Figure 5. Link quality, last-contact time, and motion state can be considered to suppress transient false alarms. If the case 14 is determined to be out of range, flow proceeds to block 416 for exception handling; otherwise, method 400 proceeds to block 424.

[0106] Block 424 comprises determining whether a dose is present. In one example, the pressure sensor 30 provides a load signature that, after filtering, indicates whether a medication unit suitable for administration is seated in a well. In another example, dose presence (or availability) is determined from a combination of inputs, such as pressure / load, a lid / open event, and a tag read (e.g., a tag encoding “trainer” versus “live” status) to compute a readiness value for each well. Implementations for multiple wells can evaluate each position independently and declare an overall “dose present” state if at least one well satisfies readiness criteria including, optionally, non-expiration. If dose presence is not satisfied, flow proceeds to block 416 for exception handling; otherwise, method 400 proceeds to block 428.Page 17 of 33P13650PC00

[0107] Block 428 comprises a ready state. In one example, controller 28 maintains a normal operating state with reduced power consumption, periodic heartbeats to the patient computing device 22 (and / or management engine 504), and optional indicator behavior (e.g., a brief green LED blink upon user interaction). The patient computing device 22 may display a status summary and perform background checks (e.g., expiration countdowns) while the case remains ready. Method 400 can return from block 428 to block 408 on a timer tick, on receipt of an external request (e.g., status poll), or on a local interrupt (e.g., lid motion or significant movement).

[0108] In another example, determining whether a dose is present can further (or alternatively) include detecting a plunger position or displacement of the medication unit. For instance, where the medication unit is nasal spray 16, then the central plunger of nasal spray 16 may have an extended position indicating dose readiness, and a retracted position indicating that a dose is not ready. In some embodiments, the absence of detection of the plunger simply means a dose is not ready, but whether or not an empty medication unit is still present in the case 14 is unknown. The case 14 may thus include a mechanical, optical, or magnetic plunger sensor positioned to detect the axial position of a movable plunger within the medication unit. The plunger sensor can produce displacement data indicative of whether the medication unit is unused, partially discharged, or fully discharged. In one implementation, a reflective optical element or Hall-effect sensor is aligned with the plunger travel path and produces a signal that varies with plunger motion. The controller 28 can interpret this signal as a “dose spent” or “dose available” condition. In another example, the controller 28 can monitor changes in pressure or load concurrently with plunger displacement to confirm that a discharge event has occurred. This dual verification can reduce false negatives caused by vibration or temperature variation. Accordingly, the plunger detection subsystem provides an additional input to the readiness computation, allowing method 400 to more reliably distinguish between an intact, usable medication unit and one that has been partially or fully administered.

[0109] In another variant, the medication unit may be a training unit configured to simulate the geometry and operation of a live medication unit but without containing an active dose. (See, for example, "TRAINING DEVICE FOR MEDICAL NASAL APPLICATORS," filed Dec. 31, 2024, bearing application number US63 / 704975). In this configuration, no dose is considered present even when the training unit is inserted in the case 14 and its plunger or Page 18 of 33P13650PC00actuator is extended. The training unit can include one or more electrical, magnetic, or mechanical identifiers — for example, a coded resistor, magnetic insert, optical marker, or tag — that can be sensed by the controller 28. The controller 28 can interpret the identifier to distinguish the training unit from a live medication unit, and can accordingly suppress or replace any “dose readiness” indication with a “training unit installed” indication. In some embodiments, the controller 28 can further modify user feedback (e.g., LED color or app notification) to reflect that the system is in a training or non-dosing mode, thereby preventing confusion between training and emergency operation.

[0110] Block 416 comprises exception handling. It is to be understood that Figure 4 shows a simplified flowchart with a single block for all exception handling scenarios, but it is to be understood that multiple different exception handling routines respective to their preceding block is contemplated. In the present example, exception handling includes a unified routine that branches according to the triggering condition from block 412, block 420, or block 424. For a battery exception, the routine can generate a first notification (e.g., “Low Battery”) and optionally command an indicator pattern or sound, apply throttling / backoff, and provide charging guidance. For an out-of-range exception, the routine can log the last known location, attempt reconnection, optionally command the speaker 18 to emit a locator tone, and present recovery steps on the patient computing device 22. For a dose-absence condition, the routine can determine, for example, whether a trainer unit is installed or whether a removal or displacement event has occurred based on the sensor vector, and then issue a readiness alert with instructions to restore a usable medication unit. In some embodiments, exception handling may escalate to designated contacts or caregivers subject to stored policies, may record audit entries with timestamps, and may clear the exception automatically upon remediation, after which method 400 returns to block 408. Referring to FIG. 5, a multiunit medication management system 500 includes a plurality of cases 14-1 ... 14-p, each associated with a local account 148-1 ... 148-p and a corresponding user 144-1 ... 144-p. Each local account 148-x resides on a respective case 14-x and identifies the user 144-x authorized to operate that case. A plurality of computing devices 22-1 ... 22-o are used by supervisory users 128-1 ... 128-o, such as parents, caregivers, or managers. Each computing device 22-x hosts an application interface 132-x, which pairs the supervisory user 128-x and the device 22-x with one or more local accounts 148-x and cases 14-x for monitoring, configuration, and notification purposes.Page 19 of 33P13650PC00

[0111] Each case 14-x communicates through a data network 24 with a management engine 504, which maintains a corresponding account record 154-x for that case. The account records 154-1 ... 154-s collectively store telemetry and status data, including battery level, location information, dose readiness, and event history for each associated case. The management engine 504 can be implemented by one or more server computing devices configured to (i) receive telemetry and status information from cases 14-1 ... 14-p, (ii) normalize, store, and associate such data with account records 154-1 ... 154-s, (iii) apply policies and rulesets to determine system actions (for example, generate alerts, initiate guidance workflows, or schedule maintenance checks), and / or (iv) distribute resulting outputs to corresponding supervisory computing devices 22-1 ... 22-o or external systems. The management engine 504 may further maintain organizational hierarchies, enforce permissions, and provide audit logging for regulatory compliance.

[0112] Supervisory users 128-1 ... 128-0 interact with the management system via application interfaces 132-1 ... 132-o, which can display the operational state of linked cases 14-1 ... 14-p, receive notifications, and return acknowledgments or updated settings to the management engine 504. The relationship between each supervisory user 128-x and the corresponding case 14-x is thus mediated through the pairing between the supervisory user’s account 132-x and one or more local case accounts 148-x. In certain implementations, a single supervisory user 128-x can monitor multiple local accounts 148-x, while each case 14-x remains associated with a unique local account 148-x belonging to its primary user 144-x.

[0113] Accordingly, while method 400 primarily refers to the operation of an individual case 14, the same operational and communication framework can extend across multiple cases and supervisory hierarchies. Case-level data 148-x is synchronized with account records 154-x on the management engine 504, and the management engine 504 distributes notifications, analytics, or policy updates to the supervisory computing devices 22-1 ... 22-o as appropriate.

[0114] Referring to FIG. 6, method 600 illustrates example operation of the management engine 504. The method begins at block 604, where the management engine 504 receives telemetry from one or more cases 14-1 ... 14-p. Telemetry can include battery data, temperature, positional information, dose-readiness state, and event logs such as lid openings or exception flags. The received data may be securely transmitted via network 24 and authenticated against the corresponding account record 154-x.Page 20 of 33P13650PC00

[0115] At block 608, the management engine 504 normalizes and stores the telemetry. Normalization may include timestamp alignment, unit conversion, and mapping to standardized data fields so that different firmware versions or device models can be compared consistently. The normalized data are written to the corresponding account record 154-x, forming a longitudinal history that can be retrieved for audit, analytics, or alert generation.

[0116] At block 612, the management engine 504 evaluates the telemetry against stored policy and rulesets. Policies may define thresholds for acceptable battery level, allowable distance between case and user device, temperature ranges for medication stability, or expiry-date intervals. Rulesets can include hierarchical or conditional logic — for example, escalating a “low battery” alert to a caregiver account if the user has not acknowledged a prior notification within a defined period. The evaluation produces one or more action candidates representing potential system responses.

[0117] At block 616, the management engine 504 generates actions based on the evaluated results. Actions can include producing notifications, initiating workflow scripts (e.g., refill reminders or guidance messages), logging compliance events, or transmitting anonymized summaries for analytics. Each action is associated with the corresponding user, case, and supervisory account, and may be distributed through push notification, SMS, email, or secure web-dashboard channels.

[0118] Decision block 620 determines whether the telemetry originates from a group deployment, such as a clinic, school, or family network where multiple cases 14-1 ... 14-p are logically associated. If not, the method loops to block 604. If yes, flow proceeds to block 624.

[0119] At block 624, the management engine 504 analyzes telemetry across the group. For example, group analysis may compute aggregate statistics such as average temperature stability, frequency of low-battery conditions, or rate of training-unit detection within a population of cases. The analysis can identify outliers or environmental correlations (for example, detecting that cases stored in certain regions or buildings experience elevated temperature drift). In some embodiments, the management engine 504 can compare these patterns against reference data or environmental sources (for example, ambient temperature forecasts or storage-condition advisories) to detect systemic risk conditions.

[0120] At block 628, the management engine 504 optionally updates one or more policies based on the group analysis or external data. For instance, if telemetry across a Page 21 of 33P13650PC00cohort indicates that medications consistently operate safely at slightly higher temperatures, the engine 504 may adjust the upper temperature threshold accordingly or issue a software update that revises local alert parameters. In another example, if group telemetry reveals increased battery drain correlated with a particular firmware configuration, the engine 504 may propagate a corrective policy or software patch to affected cases. Policy updates may be rule-based, human-approved, or data-driven using adaptive learning techniques that refine thresholds over time based on verified outcomes. This adaptive refinement provides a mechanism for the management engine 504 to improve reliability and reduce false alerts without manual recalibration.

[0121] Method 600 then returns to block 604 for continued telemetry collection and policy enforcement, providing a closed feedback loop between individual devices, group analytics, and centralized management. Accordingly, the management engine 504 functions not merely as a data repository but as an adaptive orchestration layer that governs distributed medication-readiness systems at scale.

[0122] In some embodiments, the adaptive policy updates described in connection with block 628 can be applied selectively within the hierarchical account structure shown in FIG. 5. For example, where supervisory users 128-x administer multiple local accounts 148-x through paired interfaces 132-x, the management engine 504 may distribute revised policies only to those cases 14-x meeting defined eligibility criteria, such as device model, firmware version, or operating environment. Group-level policy adjustments can thus propagate downward to subordinate accounts while preserving role-based permissions and audit trails. Conversely, insights or configuration changes initiated by an individual user or caregiver may be surfaced upward for optional adoption by supervisory users or organizational accounts 154-1 ... 154-s. This bidirectional propagation allows both top-down coordination and bottom-up learning across distributed deployments while maintaining user privacy and data partitioning.

[0123] Referring now to FIG. 7, the container of nasal spray 16 is illustrated in two conditions, each showing the plunger 70 at a different axial position. The plunger 70 includes a distal tip 74, and the container further defines a dosage storage chamber 78. In the lefthand view of FIG. 7, the plunger 70 is in an extended-position E, corresponding to a state in which the dosage storage chamber 78 holds a full dose. In the right-hand view, the plungerPage 22 of 33P13650PC0070 is in a retracted-position R, corresponding to a state in which the dosage storage chamber 78 is empty.

[0124] As described above, the case 14 may incorporate a sensor positioned to detect the distal tip 74 only when the plunger 70 is in the extended-position E. Accordingly, when the sensor does not detect distal tip 74, this may represent either (i) the plunger 70 being in the retracted-position R, or (ii) the nasal spray 16 not being present in the case 14. In certain embodiments, this approach is preferred because it allows the case 14 to report only whether a ready dose is present — by inferring a full dosage storage chamber 78 from detection of distal tip 74 — without determining whether the nasal spray 16 itself is physically present within the case 14.

[0125] While the specific embodiments herein discuss nasal spray 16, it is to be understood that nasal spray 16 is one nonlimited example of a medication unit. As used herein, the term medication unit refers to any device configured to deliver a dose of medication and having a movable plunger or actuator that transitions between an extended position corresponding to a dose-ready state and a retracted position corresponding to a nonready or dose-spent state. The medication unit may include, by way of example only and not limitation, an epinephrine nasal spray, an epinephrine auto-injector, a decongestant nasal applicator, or any other plunger-based dispenser suitable for storing and administering a therapeutic dose. Further, although examples herein describe a plunger-type nasal spray as the medication unit, any medication unit employing an actuator movable between respective dose-ready and non-ready positions may be used, including but not limited to devices with pump actuators, lever actuators, twist-actuated dose selectors, spring-loaded injectors, or cartridge-based displacement mechanisms. Thus, the epinephrine nasal spray 16 and its plunger, described herein constitutes one such embodiment of a medication unit.

[0126] As noted, certain embodiments may incorporate machine-learning or data-driven intelligence functions that operate in conjunction with case 14, application 42, and management engine 504. In such embodiments, telemetry and user-interaction data may be collected from one or more sources, including but not limited to: case-level data (e.g., location patterns, case-open events, battery state, dose-readiness events, and device-health metrics), app-level behavior (e.g., training frequency, completion patterns, ecosystem interactions, caregiver invitations, and user-engagement signals), and allergic-reaction reports (e.g., trigger context, symptoms, time-to-epinephrine, case accessibility, caregiver Page 23 of 33P13650PC00involvement, and clinical outcomes). These data sources may form an inputs layer for one or more machine-learning models.

[0127] In some embodiments, the management system may apply such models to produce individualized insights, including but not limited to: readiness scoring based on carrying consistency, device condition, training recency, and exposure to higher-risk locations; behavioral-pattern detection such as identification of declining engagement, practice decay, unintended case openings, or long periods without interaction; predictive medication-management models that forecast when a user will require a refill or predict deterioration of device readiness; and training-related models that evaluate practice frequency, user confidence, hesitation patterns, and correlations between training behavior and real-world response times. The models may also detect discrepancies between trainerunit usage and live-dose usage, or patterns that indicate mishandling or confusion in routine interactions.

[0128] In other embodiments, machine-learning may generate insights related to allergic-reaction events. Such insights may include identification of trigger patterns, environmental factors, common reaction contexts, correlations between symptoms and delayed epinephrine administration, hesitation predictors, event-severity predictors, and relationships between caregiver availability and clinical outcomes. Time-to-treatment analytics may be derived from symptom-onset timestamps and dose-administration timestamps, enabling assessment of dosing accuracy, response delays, and repeat-event patterns. The models may further identify seasonal, demographic, or context-based clusters of risk.

[0129] The system may additionally implement caregiver-ecosystem analytics, wherein machine-learning models evaluate the responsiveness, engagement, or training status of caregivers or other designated users. Examples include identifying which caregivers respond fastest during emergencies, which caregivers rarely engage, and which combinations of caregivers yield improved safety outcomes. These insights may support household-level modeling, school-based deployments, camp environments, sports organizations, or other multi-caregiver structures.

[0130] In some embodiments, supervisory, institutional, or enterprise-level deployments may utilize group-level intelligence models. Such models may compute institutional training completeness, caregiver coverage, readiness distribution across an Page 24 of 33P13650PC00organization, or readiness-risk indices. Additional models may produce population-level analytics derived from aggregated and anonymized data, including adherence rates, medication-carrying frequency, expiration patterns, case-charging behavior, real-world trigger distributions, discrepancies between expected and observed severe-reaction patterns, and seasonality of allergic-reaction clusters.

[0131] In yet other embodiments, natural-language or machine-learning models, including large-language-model variants, may be trained or tuned on datasets derived from reaction narratives, user-behavior patterns, case telemetry, caregiver-interaction logs, and readiness trajectories. Such models may generate structured summaries, personalized coaching messages, debrief recommendations following an allergic reaction, clinician-facing reports, or institutional dashboards. These models may further support smart prompts, predictive nudges, or adaptive behavioral guidance based on learned patterns of risk, confidence decline, or reduced carrying consistency.

[0132] Accordingly, machine learning may function as an optional intelligence layer that synthesizes telemetry, user behavior, caregiver network data, and reaction-event information to produce insights, predictions, classifications, coaching, and population analyses. Any combination or subset of the foregoing may be used in various embodiments to enhance device-level operation, user-level feedback, caregiver- 1 eve I coordination, or organizational-level reporting, while maintaining or supplementing the deterministic sensorbased readiness functions described herein. While certain embodiments have been discussed, it is to be understood that combinations, subsets, and / or variations of those embodiments are contemplated. For example, the case 14 may include additional sensors or subsystems suited to different environmental or operational contexts. In one variation, a temperature sensor can monitor the ambient or internal temperature of the case and generate alerts if the temperature of the medication exceeds or falls below a specified threshold. In another variation, the case 14 may include a thermal control element, such as a Peltier device or heater, to maintain the medication within a safe temperature range under extreme environmental conditions. The patient computing device 22 may display live temperature readings and visual indicators when thresholds are exceeded.

[0133] In some embodiments, the hierarchical structure of users and accounts illustrated in FIG. 5 supports multi-tenant or organizational deployments. For example, the management engine 504 can partition account records 154-1 ... 154-s into groups Page 25 of 33P13650PC00corresponding to schools, clinics, or employer programs, each administered by one or more supervisory users 128-x through their paired interfaces 132-x. Within such a deployment, each organization can maintain its own policy set, access control lists, and analytics dashboards while remaining logically isolated from other tenants. This architecture enables scalable management of numerous cases 14-1 ... 14-p and users 144-1 ... 144-p under shared infrastructure, facilitating coordinated oversight and reporting without compromising individual data privacy or control.

[0134] In another variation, the case 14 can incorporate a third-party tracker cavity configured to receive a tracking accessory such as an Apple AirTag™ or other compatible location tag, optionally shielded or exposed through an RF-transparent window. In subsequent embodiments, a fully integrated GNSS receiver may replace the accessory slot to provide autonomous tracking capability without a separate device.

[0135] The system 12 may further support a configurable tether radius defining the maximum allowable distance between the case 14 and the patient computing device 22 before an out-of-range alert is issued. This threshold may be adjustable by the user or a caregiver, such as within a default radius of approximately ten meters, and may include an opt-in mode for multiple caregivers or parents to receive proximity notifications.

[0136] In yet another variation, the case 14 may include a lid or access sensor — for example, a magnetic, optical, or mechanical switch — that detects when the case has been opened or closed. The controller 28 can generate corresponding notifications through app 42 to record access events, improve safe-handling awareness, or indicate possible misuse. The housing 32 may further include a quick-release mechanism for rapid access in emergencies and may be constructed of impact-resistant or water-resistant materials, optionally meeting an ingress-protection rating.

[0137] Power management embodiments may include additional configurations of battery 37 and charging circuitry. In one example, the case 14 may function as a power-bank capable of providing charge to an external device such as a smartphone through the USB-C port. Visual indicators such as LEDs 39 may follow a color scheme (for example, red, orange, green) to convey depletion, low, or full-charge states, respectively.

[0138] Alternate embodiments further include enhanced dose-readiness detection and training modes. For example, a training unit can be identified not only by an encoded tag but also by a magnetic identifier or other distinctive mechanical signature. In training mode, the Page 26 of 33P13650PC00case 14 may include a force or pressure sensor that measures the force applied to the plunger during simulated use and provides app-based coaching feedback to reach a target breakthrough force representative of a live dose event.

[0139] The notification and communication architecture may likewise vary. In one embodiment, alerts are provided through native push notifications, while in another embodiment, the management engine 504 can deliver SMS or email notifications to designated recipients, such as caregivers or school personnel. Notification delivery can be prioritized by user role (for example, manager, caregiver, secondary user) and can observe user-defined quiet periods or schedules.

[0140] In another embodiment, app 42 may interface with a web-based dashboard hosted by management engine 504, through which a provisioning applet can register cases 14, bind digital certificates, and synchronize case and user data across platforms. Additional conveniences may include a voice interface, allowing a user to activate app 42 or query readiness states through a natural-language prompt (for example, “Hey EpiSure, do I have two ready doses?”). The case identifier 20 may also support find-owner functionality, such that scanning the identifier or an AirTag link can trigger a secure message or “return-to-owner” notification.

[0141] Community and assistance features may likewise vary. In one example, a “Distress Call” broadcast can transmit anonymized location data to other nearby authorized users to solicit assistance. In another, a reduced “Beta-mode” implementation may display only the count or proximity of nearby compatible cases. Additional embodiments may include a two-way SOS channel that opens a live voice or text session with emergency responders or caregivers after an alert is confirmed, with ongoing location sharing through management engine 504.

[0142] Wearable integrations are also contemplated. In one embodiment, a smartwatch or other wearable device detects physiological stress indicators (for example, elevated heart rate or motion patterns) and triggers a prompt to verify readiness or locate the case 14. Alternative form factors are contemplated as well, including a phone-attachment variant wherein the case forms part of or attaches to a mobile phone, optionally drawing or supplying charge to the phone battery. Further form factor considerations can include customizing the case to a particular model of smart phone.Page 27 of 33P13650PC00

[0143] Across any or all embodiments, the management engine 504 may serve as a centralized cloud platform aggregating de-identified event data, generating analytics for caregiver or clinician dashboards, and supporting future educational and predictive-care initiatives. The engine may employ any suitable data-processing architecture, encryption scheme, or policy logic to manage and distribute case information securely.

[0144] A person skilled in the art will appreciate that the present specification offers certain technical advantages over the prior art. For example, conventional medication storage devices may monitor only limited parameters such as temperature or expiration, but fail to integrate real-time readiness assessment, user proximity, and multi-party notification workflows within a unified control framework. The present management system provides a distributed sensing and communication architecture that continuously or periodically evaluates medication readiness — including battery, presence, plunger displacement, and case-separation metrics — without user intervention. This improves reliability of emergency medication availability compared with prior devices that rely on manual checks or singleparameter sensing.

[0145] Another advantage is that the system integrates dose readiness verification at the mechanical level through coordinated pressure and plunger sensing, allowing it to discriminate between (i) missing medication, (ii) inserted but expended medication, and (iii) a valid live dose. This determination is performed autonomously, producing machine-verifiable readiness data rather than user-dependent input. Such multi-sensor fusion reduces false positives and enables higher confidence in readiness reporting — a technical improvement in device-state determination and error handling.

[0146] In certain embodiments, dose readiness is verified solely by sensing a position or displacement state of a medication unit plunger, without relying on load, presence, or other auxiliary case sensors. By asserting “ready” only upon detecting a plunger state within a predefined readiness window, the system provides a positive-assertion scheme that defaults to “not ready / unknown” in the absence of a qualifying plunger signal. This architecture simplifies the sensing stack and associated firmware (fewer channels to poll, fewer fusion rules), reduces points of failure and calibration burden, lowers power consumption, and improves electromagnetic and mechanical robustness by eliminating fragile load pathways. It also avoids false positives inherent in mere “device present” detection, where an inserted but expended unit or an inert surrogate could otherwise be misinterpreted as usable. The Page 28 of 33P13650PC00result is machine-verifiable readiness derived from a single, mechanically meaningful state transition, implemented with a deterministic thresholding routine and a monotonic state machine that enhances traceability for safety audits. Counter to conventional approaches that add sensors to improve confidence, this design achieves higher reliability and safer failure modes by removing nonessential modalities and permitting a strict readiness assertion only when the plunger state alone evidences a valid live dose.

[0147] Further, the management system introduces training-mode identification within the same hardware and logic stack used for live medication, using electrical, magnetic, or optical identifiers associated with training units. This enables the same control and feedback pathways (case sensors, app logic, notifications) to operate in a distinct “training” mode, improving user education and reducing confusion between real and simulated use. This integration of training and live monitoring in a single intelligent case represents a novel architecture for safety-critical medical handling systems.

[0148] At the system level, the invention further provides a multi-tier communication and decision engine — embodied by the management engine 504 — that performs data normalization, rules-based event handling, and secure distribution of alerts and logs to multiple user roles (e.g., patient, caregiver, clinician). This enables network-wide coordination without duplicating device-side complexity, offering scalability and policy enforcement across distributed users and cases. Prior art systems typically relied on local device logic or single-user pairing; the present approach decentralizes computation while maintaining low-latency status exchange between the case and its users.

[0149] Additional technical advantages include (i) reduced latency and improved reliability in emergency notifications through redundant channel selection (Bluetooth, cellular, Wi-Fi, or SMS), (ii) enhanced fault tolerance through automated exception handling and selftest routines, and (iii) secure interoperability with third-party systems via standardized interfaces and encryption protocols. Collectively, these improvements provide a comprehensive readiness assurance framework that transforms passive medication holders into intelligent, network-aware devices capable of real-time situational response, thereby addressing technical and human-factors limitations inherent in prior medication management solutions. Connection relationships between elements are described herein using various terms, such as "coupled", "cooperate", "disposed", and the like. As used herein, connectionPage 29 of 33P13650PC00relationships can be direct relationships and / or indirect relationships where one or more intervening elements are between the first and second elements.

[0150] Communications between elements are described herein using various terms, such as "communicate", "provide", "obtain", "communicatively coupled", etc. As used herein, communications can be direct communications and / or indirect communications through one or more intermediary elements. Further, communications can be constant communication and / or selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and / or one-time events.

[0151] It should be understood that "including", "comprising", and "having" (and all other forms, such as tenses) are used herein to be open-ended terms. Thus, whenever a claim recites any form of "include", "comprise", or "have" (e.g., comprises, includes, has, comprising, including, having) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim.

[0152] As used herein, singular references (e.g., "a", "an", "first", "second") do not exclude a plurality. The term "a" or "an" entity refers to one or more of that entity. The terms "a" (or "an"), "one or more", and "at least one" can be used interchangeably. The term "and / or" when used in a form such as, for example, A, B, and / or C refers to any combination or subset of A, B, C such as (1 ) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C.

[0153] Changes and modifications in the specifically described examples can be carried out without departing from the principles of the present disclosure which is intended to be limited only by the scope of the appended claims, as interpreted according to the principles of patent law including the doctrine of equivalents.Page 30 of 33P13650PC00

Claims

1. CLAIMS1. A management system for medication, said system comprising:a case configured to support a medication unit of a user, said medication unit having a plunger movable between a retracted position and an extended position,a sensor disposed in said case and positioned to detect a state of said plunger, said sensor configured to generate sensor information indicative of whether said plunger is in a doseready position, anda computing device configured to communicate with said case, said computing device being configured to provide status information to a user based on said sensor information, wherein said status information indicates a dose-ready state when said plunger is detected in said dose-ready position and a not-ready state when said plunger is not detected in said dose-ready position.

2. The management system of claim 1 , wherein said sensor comprises an optical, magnetic, or mechanical displacement sensor configured to detect an axial position of said plunger.

3. The management system of any preceding claim, wherein said computing device is configured to determine said dose-ready state based solely on said sensor information without reliance on pressure, weight, or load measurements.

4. The management system of any preceding claim, wherein said computing device is configured to execute a deterministic thresholding routine that transitions from a not-ready state to a dose-ready state only upon detection of a plunger signal exceeding a predefined displacement threshold.

5. The management system of claim 4, wherein said computing device is further configured to maintain said dose-ready state until detection of a monotonic change in said plunger signal corresponding to a dose discharge event.Page 31 of 33P13650PC006. The management system of any preceding claim, wherein said computing device is configured to default to a not-ready state in the absence of a qualifying plunger signal.

7. The management system of any preceding claim, wherein said sensor comprises a Hall-effect sensor aligned with said plunger, said Hall-effect sensor generating said sensor information in response to motion of a magnetic element coupled to said plunger.

8. The management system of any preceding claim, wherein said sensor comprises a reflective optical sensor positioned to detect movement of an optical feature disposed on said plunger.

9. The management system of any preceding claim, wherein said computing device is configured to display a visual indicator or provide an audible notification representing said dose-ready state.

10. The management system of any preceding claim, wherein said case further comprises a controller configured to filter said sensor information to reduce transient noise and to provide filtered data to said computing device for determination of said dose-ready state.

11. The management system of any preceding claim further comprising a management engine for group administration of a plurality of cases.

12. A case according to any preceding claim.

13. A computing device according to any one of claims 1 -12.

14. The computing device according to claim 13 wherein the computing device has multiple accounts associated with a plurality of cases.

15. A management engine computing device according to any one of claims 1 -12.Page 32 of 33P13650PC00

Images