NZ751884A - A dead device medic alert relay - Google Patents

Abstract

The present invention relates generally to a wearable emergency device. In particular, the present invention is a wearable networked medic alert device and system whereby both the user’s interaction with the device and the device itself is subject to a deadman’s switch vigilance whereby a non-event and lack of response by either the user or the device will trigger the alert. The device works in conjunction with an automatic programmable interface (API), communications network and reliability circuit providing a systematic relay for reliable monitoring of both user’s activities and the device itself.

Description

APPLICATION NEW ZEALAND PATENT TITLE: A DEAD DEVICE MEDIC ALERT RELAY INVENTOR: JOHN HOOKWAY FIELD OF THE INVENTION The present invention generally relates to wearable emergency devices.

These devices alert others at distant locations of an emergency for the person wearing the device. In particular, the invention is targeted towards people who are living relatively independently; who live with some freedom of movement and activity.

Another use case within the same broad field is for people living alone or a lone user suffering a misadventure and consequently needing aid or supplies to avert a medical condition. The call for help (the “signal”) may be to a doctor, caretaker, friends and family (hereafter “receivers”). Such devices generally require the user to be conscious and free of medical conditions affecting the nervous system, such as Parkinson’s and Alzheimer’s.

BACKGROUND OF THE INVENTION Discussion of Prior Art A patent search conducted showed several patented inventions which are related to the art.

The concept of an emergency wearable device is not new. There is an already published patent application which described the same. For instance, a variety of communication devices are available; for example, a telephone, beeper or dedicated devices that relayed a signal for help. However, users might be incapacitated and physically unable to operate a device.

Further, there is a problem inherent in leaving independently-minded people to ask for help. Some people are not in a position to assess their own medical condition and illness, which breeds a lack of action and willpower. Some people will not ask for help, and insist on waiting for definitive conclusions and completely true evidence that the condition warrants asking for help before taking a position, by which time it might be too late.

There is a partial solution to these problems by using a “fall detector” that will autonomously signal for help when a wearable device detects that the user has fallen over. However, this is relevant only to selected incidents of emergency, where there is an antecedent action required to trigger the alert. For example, it does not cater to someone losing consciousness while lying in bed.

A problem with such devices is that they can fail for inadvertent reasons; for example, the batteries on a mobile phone or any device might go flat, or for other reasons the device might stop working. The challenge then lies in making the device and the user’s operation of the device failsafe.

The narrowing of the parameters about what can fail centers on the following: a) The user’s capability b) The working condition of the device There are vigilant solutions where these problem areas are circumvented by personal monitoring.

There are a variety of devices for monitoring the medical condition of a patient, as observed in hospitals with visual display units. However, these devices and displays tend to be specific to a particular environment and condition, and ideally operate in a tightly controlled environment. They are not suitable for the quest for independent living. Outside a controlled environment, these tools might lead to human failure and the abandonment of due process.

There are portable solutions that resemble monitoring with the kind of detail that a hospital provides, in the form of a wearable harness. For example, the US Patent Pub No. US 2012/0112903A1, but these solutions have disadvantages in the sense that they might not suit some users’ sense of comfort and everyday practicality when showering, sleeping, etc.

The Australian Redcross organisation operates a “Telecross” service whereby volunteers provide a personal good morning call to a list of recipients to ensure that they are alive and okay. However, this is a labour and time-intensive process. This level of vigilance suggests a need to deduce a solution in logic.

BRIEF SUMMARY OF THE INVENTION The present invention generally relates to wearable emergency devices.

Looking outside the medical field and focusing on the field of engineering, a “dead man's switch” is designed to be activated whenever the user is incapacitated; a variant of this theme is a dead man's vigilance device where the user is required to go through timed intervals. These solutions will be seen as relevant to the current invention because they address the problem of the user being incapacitated and a "non-event" triggering a signal.

However, this solution does not directly address the problem of the device becoming inoperative for any reason. The solution to this problem is found by applying the same principle of a dead man's vigilance to the device itself.

In this scenario, there are several wearable devices being looked at. Each user and their individual wearable device is centrally monitored to ensure they have the fitness for the given purpose. If they do not, it sets off an alarm to indicate this.

Therefore, the vigilance of the user is subordinated to the vigilance of his or her device. If there is no response from the user or their wearable device, it triggers a signal and then emergency messages are sent. In other words, either an unresponsive user or an unresponsive device will trigger an emergency signal. This approach is good for when the user is too incapable of disarming the device, or if the device is not responding. That way, a signal can be sent to indicate this.

Essentially, the invention’s propositional logic is of double negation, a proposition is equivalent to the falsehood of its negation: A ≡ ~ (~A) where ≡ expresses logical equivalence, and ~ expresses negation.

Let A = an armed alert Then, the user not disarming an alert ≡ not (not arming alert) ≡ An armed alert Similar logic is used in respect to the operation of the device. If it does not respond to a remotely controlled check, then an alert is sent.

The invention envisages multiple wearable devices but one central monitoring system. This works similarly to a telephone network that encompasses one network but many individual telephones. The invention is based on the use of multiple devices and the benefits of large-scale application which justify the thoroughness and reliability of central monitoring.

In this process, the reliability checks of all the individual devices are externalized to a centralized monitoring mechanism that provides vigilant reliability checks on all individual devices within a specific geographic region.

The need for external monitoring infers the need for 3 broad logical components, each of which covers a large number and wide range of subjects. These include: a) An automatic programmable interface (API) to check the device. b) A Communications Network to interconnect the API from a server to the device and a secondary communications channel.

As the reliability of all individual devices is subordinated to the reliability of an API and a Communications Network, this infers the need for a reliability circuit. c) Reliability Circuit The three components, or their equivalents, are a continuation of the logic of the invention (as opposed to being auxiliary business logic). Therefore, a good reason exists to consider these components as being integral to the invention.

BRIEF DESCRIPTION OF THE DRAWINGS A clear understanding of the key features of the invention summarized above may be had by reference to the appended drawings and diagrams/flow charts, which illustrate the method and system of the invention, although it will be understood that such diagrams/flow charts depict preferred embodiments of the invention and, therefore, are not to be considered as limiting its scope with regard to other embodiments which the invention is capable of contemplating. Accordingly: Figure 1 shows a problem to be addressed with many medic alert devices.

There is no signal sent from an unresponsive user because the user is not in a state to operate the device.

Figure. 2 shows a device sending a signal from an unresponsive user using a countdown timer.

Figure. 3 shows a user disarming a device so that the signal is not sent from the device.

Figure. 4 shows consequences of an unresponsive device, the user and receivers are notified.

Figure. 5 shows a signal from a device transmitted via a server to receivers with important information such as GPS location and heart rate.

Figure. 6 is a schematic flow diagram that outlines the steps in a flow of data in the communications network.

DETAILED DESCRIPTION OF THE INVENTION Unless otherwise defined, all terms (including technical terms) used herein have the same meaning as commonly understood by one having an ordinary skill in the art to which the invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

In describing the invention, it will be understood that a number of techniques are disclosed. Each of these has individual benefits and each can also be used in conjunction with one or more, or in some cases all, of the other disclosed techniques. Accordingly, for the sake of clarity, this description will refrain from repeating possible combination in an unnecessary fashion. Nevertheless, the specifications and claim/s should be read with the understanding that such combinations are entirely within the scope of the invention and the claim/s.

The present disclosure is to be considered as an exemplification of the invention and is not intended to limit the invention.

The invention in particular is a wearable emergency device.

A: Device and User Operations The device works in conjunction with an automatic programmable interface (API), communications network and reliability circuit providing a systematic relay for reliable monitoring of both user’s activities and the device itself.

Figure 1 shows a problem to be addressed with many medic alert devices, no signal is sent from an unresponsive user. User (31), is in an unresponsive state and does not press the button to activate and send a signal from the device (33).

In contrast to the above scenario, Figure 2 shows the device sending a signal as a result of a lack of response from the user. In the drawing, the user (31) is incapable and lying down and does not press the button (32) to disarm the device (33) by the end of the countdown period (34). And in consequence, a signal (36) is sent at the end of the countdown period. In the preferable embodiment of the invention the device is wearable.

A signal is sent from the device at a predetermined time unless the user disarms the alarm within a given warning time. If the timer period is allowed to expire, a visual and audible warning is given by the device. If the user fails to acknowledge the warning, then the signal is sent.

Figure. 3 shows a user disarming a device so that the signal is not sent from the device. In the drawing, the user (31) presses a button (32) on the device (33) within a countdown period (34). And in consequence of this action, NO signal (35) is sent.

The device item is wearable or mobile with independent wireless internet facilities and includes: a) A display which is a countdown timer warning and b) An easy means to disarm the watch’s emergency transmission with one or two swipes or a press of a button. c) The user can also manually send a signal. d) The device can transmit information relevant to the user’s condition, including the presence of heart beat, GPS location and relevant medical information. e) The device optionally provides telephonic means for direct voice to voice communications with the user and wireless transmitter capable of sending a wireless alert.

The device comprises of the following: a) Microphone b) Video camera; c) Transceiver d) Screen e) Speaker f) Power Source g) Heart Rate Sensor h) GPS Unit i) Memory j) Logic Board / CPU k) Memory (RAM and ROM) l) SIM card m) Antenna n) Buzzer / Alarm The precise circuitry and functional interrelation between the device components are subject to many modifications and variations that will be apparent to those of ordinary skill in the art.

B: Communications Network In Figure 5, a signal from a device is transmitted via a server to receivers with important information such as GPS location and heart rate. A signal is sent (36) from a device (33) to a server (51) and re-transmitted (52) to multiple receivers (49).

The message includes heart rate information (56), GPS location (57), audit log (58) and medical information (59).

The device exists within a communications network comprising: a) The device b) Secondary communications channel, i.e. telephone c) Server — A computer for storing and sending data over the internet d) Settings dashboard (an internet web application) e) Internet, telephone and SMS messaging System f) Receiver(s) — a listing of message recipients and their electronic addresses g) API — An automatic programmable interface that operates in the background Summary of Transmissions Ultimately, messages or signals transmit: a) From sender to server, b) From server to receiver c) From server to secondary communications channel (when the device is unresponsive).

API monitoring information goes to and from the server and the device More Detailed Explanation of the Communications Network. a) The device: The device sends information to the server and indicates a responsive state and sends signals in the event of no response from the user. b) Secondary communications channel — If one device is not working then the API will communicate this concern to the user on a Secondary communications channel, for example a voice message on a mobile phone to point out the lack of responsiveness of the device. c) The server stores information from the API and transmits messages to receivers with GPS location data and heartbeat rate along with preloaded medical information.

The server provides load balancing to ensure access to a backup server. d) The device works in conjunction with a dashboard for configuring the device and its transmission. The portal for configuration comprising means for configuring. i) The receivers’ electronic addresses ii) The package of information to be accompanied by the emergency signal iii) The characteristics of the deployment of the signal of the device, for example when the signal is to be sent, how often, duration of the warning time and so on. e) Internet, telephone and SMS messaging System: these are commonly available internet services, which the signals and messages are transmitted upon. f) Receiver(s) — a listing of message recipients and their communication addresses, email addresses and text and telephone numbers.

C: An Automatic Programmable Interface (API) All the components of the communications network is interconnected with an API, an automatic programmable interface. The API works in the background and is programmed with unambiguous specification, an algorithm for automated reasoning tasks, or a set of rules. For example, when to take action by way of sending messages.

Figure 4, shows an automatic program (41) that communications wirelessly (42) with the device (33) to check if the device (44) is responsive. In this case the device is NOT responsive (45) due to a hardware malfunction and its memory failed. The automatic program communicates (46) to a secondary device (47) and if there is no response from the secondary device then it transmits (48) a message to multiple receivers (49).

Essentially, the API functions to a) Sign into and out of the device and confirms that it is responsive. b) Gather information from the devices, such as user activity on the device, device activity, heart beat and GPS location information. The API detects and alerts vital signs that fall outside of pre-set parameters. c) Create and stores an audit log of activity. d) Works in conjunction with an intelligent rule based program system to conduct automated reasoning tasks to follow through with communications. The API can communicate with a user’s personal digital assistant. e) The API provides access to a web portal that comprises a settings panel for configuring user preferences for example timing of alarms to be disabled and their properties, who and how to contact in the event of a signal and medical information.

The best way to monitor the API: The best way to use the API system is to provide for personal monitoring of the API by reducing all data where possible to a single aggregate metric, being an emergency level calculated from a plurality of metrics based on data received from the various sensors of the device and the automated reasoning of the API. The aggregate metric is displayed on a colour-coded logarithmic scale and is accompanied by alarms.

D: Reliability Circuit Figure 6 shows a schematic flow diagram outlining the steps in a flow of data in the communications network. The flowchart shows the core items of automated reasoning being the diamond shaped decision boxes. Box (61) shows the device being checked via the API to ensure it’s in good working order, this happens continuously throughout the day. In the event of the device not being OK then it is rechecked (62) and failing a response the user is notified on the phone (63) and unless there is an answer receivers are notified. Otherwise, a countdown begins (64) and unless the user responds the receivers are notified.

To ensure reliability, multiple parallel channels are used with redundancy where ever feasible. For example, multiple device signals, to multiple servers, communicating on multiple communication channels (text, phone and email) to multiple recipients and so on.

Other reliability measures, and which form part of a Continuous Improvement System include the following: a) Expected behaviours are modelled against actual behaviour (for example, comparing the reconfigured warning times entered into the dashboard against the actual warning times etc.). b) Secondary communication devices are used for the benefit of communicating any faults to the user and optionally, to receivers. c) Secondary notifications are sent to the user as well as some receivers when the device settings are changed. d) The device is continuously checked by the API on a regular basis to provide an early warning system.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed, modifications and variations that will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The terminology used herein was chosen to best explain the principles of the embodiment, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

The flowcharts and drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or drawing may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s).

Industrial Applicability In respect of industrial applicability, a current solution used by many users requiring medic alerts is to rely on a telephone service, for example from friends and family or the Red Cross ” telecross” service mentioned in the background of the application. Within industry, it appears that alternatives present more problems than solutions because of their technical complexity, reliability or other concerns regarding applicability. The present invention has industrial applicability because it is too easy to operate as the user does not have to do anything to send the signal. A dead user could send a signal on a broken device. The invention can be produced using standardised parts and operating processes understood by those of ordinary skill in the art.

Therefore, it is reasonable to expect that the solution can be readily applied in the industry. Substantial contributions to existing solutions are sought because demographic trends mean age care costs impose an unsustainable economic burden on a variety of nations.

Claims (11)

1. A method for sending an alert to one or more receivers, comprising: connecting a smartwatch to a database on a server via an application program interface (API) to detect the smartwatch operability; periodically or continuously detecting a GPS location and a heart rate of a user using the smartwatch; the user setting a pre-set time into the smartwatch, wherein said pre-set time indicating when said user expects to be awake and responsive; the API transferring the pre-set time via a wireless module on the smartwatch to the database; detecting on the smartwatch, an interaction between the user and the smartwatch at the pre-set time and the API transferring details of the interaction to the database; periodically or continuously detecting a GPS location and a heart rate of the user using the smartwatch; the API transferring the GPS location and a heart rate of the user to the database; a non-Biometric user monitoring system that includes: wherein when the API detects a disconnection between the smartwatch and the server the API initiates sending an alert to the one or more receivers; wherein the lucidity and state of awareness of the user is tested at the pre-set time by detecting the interaction between the user and the smartwatch; wherein in response to the server detecting an absence of interaction between the user and the smartwatch at the pre-set time, the server initiates sending an alert to the one or more receivers; wherein the user can interrupt/cancel transmittal of an alert to the one or more receivers by a predetermined signal.

2. The method according to claim 1, wherein detecting the interaction between the user and the smartwatch at the pre-set time follows from the smartwatch's processor registering physically and mentally capable user actions on the smartwatch interface.

3. The method according to claim 1, wherein the pre-set time comprising: a time of day and a specific time interval.

4. The method according to claim 1, wherein the user setting a modality for interrupting and cancelling the transmittal of the alert to the one or more receivers via the smartwatch.

5. The method according to claim 1, wherein the user's interaction with the smartwatch comprising: sliding or pressing a button once or twice on said smartwatch.

6. The method according to claim 1, wherein an audit log stores the user interaction data, the heart rate data and the GPS position data.

7. The method according to claim 1, wherein the alert to the one or more receivers includes sending the GPS position data of the smartwatch and heart rate data of the user to the one or more receivers.

8. The method according to claim 1, wherein interrupting and cancelling the transmittal of alert to the one or more receivers and transferring the pre-set time from the smartwatch to a database on a server via the API comprises: inputting data onto the smartwatch that connects through the API to the server; inputting data onto a cloud-based user portal that connects through the API to the server.

9. The method according to claim 1, wherein the one or more receivers comprise one or more electronic addresses and communication devices.

10. An apparatus for sending an alert, comprising: a cloud-based server that comprises: a database, a scheduler and an application programming interface (API); one or more receivers comprises email and telephone numbers for text messages; a smartwatch comprises: a processor, one or more user interface controls, a wireless module, a GPS module, a heart rate sensor, and an audit log; the smartwatch processor detects user interaction with at least one of the one or more user interface controls, wherein said user interface controls are visual display interface and buttons on the smartwatch, and controls the smartwatch based on the detected user interaction and the wireless module transmits user interaction, GPS and heartrate data to the API wherein the GPS module provides GPS position data of the smartwatch, and the heart rate sensor provides heart rate data of a user; wherein the audit log stores the user interaction data, the heart rate data of the user and the GPS position data of the smartwatch; wherein the smartwatch visual display interface includes a means to enter a time of day to indicate when the user expects to be awake and responsive; and a specific time interval and stores said time values in the audit log; wherein the data in the audit log is transmitted via the wireless module and the API to the database; the smartwatch periodically transmits via the wireless module and the API and thereby updates the database with any changes to the pre-set time; wherein the API transmits an emergency alert to one or more receivers at the pre-set time that is stored in the database, said emergency alert comprises GPS position data of the smartwatch and the heart rate data of the user; wherein a specific interaction of the user with the smartwatch during the specific time interval is detected by the smartwatch processor and information thereby transmitted by the wireless transmitter to the API that cancels the transmission of the emergency alert to one or more receivers and thereby signals that the user is responsive; wherein the API checks for a transmission from the smartwatch at times dictated by the scheduler; wherein the server hosts scheduled tasks via an API configured to initiate the transmission of an alert sent from the server to the one or more receivers when there is an absence of transmission from the smartwatch at times dictated by the scheduler and thereby signal the inoperability of the smartwatch.

11. The apparatus claimed in claim 10, wherein a visual display interface for data input on a cloud-based user portal that connects to the database can receive the time of day and the specific time interval and store the said data into the database.