NZ751884B2 - A dead device medic alert relay - Google Patents
A dead device medic alert relay Download PDFInfo
- Publication number
- NZ751884B2 NZ751884B2 NZ751884A NZ75188419A NZ751884B2 NZ 751884 B2 NZ751884 B2 NZ 751884B2 NZ 751884 A NZ751884 A NZ 751884A NZ 75188419 A NZ75188419 A NZ 75188419A NZ 751884 B2 NZ751884 B2 NZ 751884B2
- Authority
- NZ
- New Zealand
- Prior art keywords
- user
- smartwatch
- api
- receivers
- alert
- Prior art date
Links
- 241000219823 Medicago Species 0.000 title abstract description 6
- 230000004044 response Effects 0.000 claims abstract description 8
- 230000003993 interaction Effects 0.000 claims abstract 13
- 230000005540 biological transmission Effects 0.000 claims description 7
- 230000000007 visual effect Effects 0.000 claims description 5
- 230000001702 transmitter Effects 0.000 claims description 2
- 230000000694 effects Effects 0.000 abstract description 7
- 238000000034 method Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000006399 behavior Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000006011 modification reaction Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 1
- 229910003460 diamond Inorganic materials 0.000 description 1
- 239000010432 diamond Substances 0.000 description 1
- 201000010099 disease Diseases 0.000 description 1
- 230000003203 everyday Effects 0.000 description 1
- 210000000653 nervous system Anatomy 0.000 description 1
- 238000004353 relayed correlation spectroscopy Methods 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
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. 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.
Publications (1)
Publication Number | Publication Date |
---|---|
NZ751884B2 true NZ751884B2 (en) | 2021-01-06 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10475331B2 (en) | Monitoring activity of an individual | |
US7589637B2 (en) | Monitoring activity of an individual | |
US8803688B2 (en) | System and method responsive to an event detected at a glucose monitoring device | |
CA2971575C (en) | System and method for monitoring a person | |
CN107683501B (en) | System and method for active monitoring of a person | |
JP2014229199A (en) | Fall reporting system and program for the same | |
KR20180106583A (en) | Care device and care system for the old and the infrim | |
EP3471050A1 (en) | Device, method, and system for monitoring monitored person | |
US10304310B2 (en) | Check-in service on a personal help button | |
AU2018101088A4 (en) | Dead device medic alert relay | |
NZ751884B2 (en) | A dead device medic alert relay | |
NZ751884A (en) | A dead device medic alert relay | |
KR102368158B1 (en) | Safety management system for the elderly living alone | |
JP7442761B2 (en) | Medical alarm relay device for incapacitated people | |
JP6135832B1 (en) | Monitored person monitoring system, operation method of monitored person monitoring system, and central processing unit of monitored person monitoring system | |
US20240169818A1 (en) | Emergency alert systems and methods based on motion detection | |
Raffaeli et al. | Improved solution to monitor people with dementia and support care providers | |
CZ2019814A3 (en) | Security monitoring system especially for seniors and the method carried out on it | |
CZ33866U1 (en) | Security monitoring system especially for seniors | |
EP3284072A2 (en) | System and method for monitoring a person | |
CZ2015857A3 (en) | An activity detector for monitoring people using the electronic security system - EZS |