Patent Grant
10909830
People often require help from other people in emergency situations. People living on their own may be fine most of the time, but an accident or condition (unexpected or otherwise) may render them in need of help. People can and do encounter unknown and/or risky situations, which can result in a person finding themselves in a dangerous or precarious situation from which they need extracting by, or assistance from, other people.
For example, elderly people with health conditions who live on their own may need to be able to seek immediate assistance from a remote person when they experience a health-related incident, accidentally fall or get injured. One popular solution to this problem is the emergence of personal emergency alert systems. Existing emergency alert systems generally consist of a wearable or wall-mounted emergency alert device that includes a simple user interface such as a button or voice-activated switch that automatically calls an emergency monitoring service upon activation via the user interface. The emergency monitoring service typically provides two-way communication between the person activating the emergency alert device and a human operator that can speak to the person to assess what emergency services, if any, need to be dispatched to the person. For example, if a person is having a health-related problem, the operator may connect the person to a health provider or dispatch an ambulance to the person's location. Such devices may be connected via a cellular connection, via WiFi using voice-over-IP, or via a landline. Because such devices need to be active all the time, and allow for 2-way communication, they also to be connected to a power outlet or require frequent battery recharging and/or replacement.
As another example, with the rise in popularity of Internet-based matchmaking and dating apps, people often venture out alone with other people who they may not know. On the occasion that such a person finds his or herself in a situation that feels or is unsafe, that person may want to be able to alert another person to come extract them from the situation or otherwise provide help. While most people are now armed with mobile phones, the unsafe situation that a person may be in may prevent that person from calling or texting someone using their mobile phone. For example, the person may not be in a location with adequate cellular coverage, or the mobile phone battery may be out of charge. As further example, in the situation of an abductor or assailant, the person's mobile phone may be removed from its owner's access.
Accordingly, existing personal emergency alert systems often fail just when they are most needed.
The problems inherent in prior art personal emergency systems are solved by the novel system, method and device for monitoring and notifying emergency contacts of a personal emergency described herein. Such system includes a personal emergency alert device that is kept in accessible proximity to a user, and a personal emergency alert notification service available via a communications network. The personal emergency alert device monitors and detects the occurrence of an emergency activation event proximal to the user. When the personal emergency alert device detects an occurrence of such emergency activation event, it transmits an emergency alert message via the communications network to the remote personal emergency alert notification service. Upon receipt of the emergency alert message from the personal emergency alert device, the personal emergency alert notification service generates an emergency alert message and transmits an emergency alert event notification message to pre-designated emergency notification recipient(s). The personal emergency alert device periodically obtains the device geolocation and transmits the geolocation to the personal emergency alert notification service to allow the geolocation of the device (and presumably the user) to be tracked following the activation event.
In an embodiment, the system includes a personal emergency alert device comprising a cellular modem, a geolocation module arranged to obtain geolocation information representative of a geolocation of the device (for example, a GPS receiver), a sensor arranged to detect an activation event and to generate an activation signal upon detection of the activation event, a controller in electrical communication with the sensor, the cellular modem, and the geolocation module, and a power switch that switchably connects a power source to the controller, the sensor, the cellular modem, and the geolocation module to place the device into a power-on state. In operation, when the personal emergency alert device is placed into the power-on state, the controller instructs the cellular modem to establish radio access network bearers to create a data tunnel between the device and a packet data network through which the device can communicate with a personal emergency alert notification service accessible via the packet data network. The personal emergency alert device then goes into a low power mode until activated by an activation signal generated by the sensor upon occurrence of the activation event. Once activated, the controller repeatedly performs an operation of (a) instructing the geolocation module to obtain device geolocation information, (b) formulating an alert message comprising the obtained geolocation information, and (c) instructing the cellular modem to transmit the alert message to the personal emergency alert notification service via the data tunnel, the controller halting the repeated performance of the operation only when the device runs out of power. Alternatively, the device can be deactivated by an independent source other than the user or device itself, such as one of the designated notification recipients, contacting the personal emergency alert notification service, sending a valid deactivation code to the service, whereby the personal emergency alert notification service may then instruct the device to deactivate itself.
A more complete appreciation of this invention, and many of the advantages thereof, will be readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:
Various embodiments are described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the appended claims.
Referring now to
Communications network(s) 10 may be any network or combination of networks that enables the transmission of an alert from PEAD 2 to PEANS 3, and further that enables PEANS 3 to transmit a notification message to the electronic device(s) 5a, 5b, 5c, 5d, 5e of the designated notification recipient(s) 4b, 4c, 4d, 4e associated with the PEAD 2. In various embodiments, the communications network 10 may comprise one or more, or a combination of, wireless and/or wired networks, such as but not limited to Wide Area Networks (WANs), Local Area Networks (LANs), Wireless LANs (WLANs), Low Power WANs (LPWANs), 3G, 4G and 5G cellular networks, Wi-Fi networks, satellite networks, wireless mesh networks (for example using a Zigbee standard protocol), Bluetooth, unlicensed RF network (e.g., 433 MHz unlicensed spectrum), etc.), and may thereby require use of, and (if required) translation between, various transport protocols, including by way of example and not limitation, TCP, TCP/IP, IP, Ethernet, Zigbee, Bluetooth, etc. In a preferred embodiment, the network(s) 10 is implemented, at least in part, as a LPWAN such as a 3GPP Long Term Evolution (LTE) CAT-M1 (or other enhanced Machine-Type Communication (eMTC) protocol, a Narrow-Band Internet of Things (NB-loT) protocol, or an Extended coverage GSM IoT (EC-GSM-IoT) protocol, as the communication link between PEAD 2 and PEANS 3.
Controller 21 may be a microprocessor, a computer processing unit (CPU), a microcontroller unit (MCU), or custom application specific integrated circuit (ASIC), or other integrated circuit (IC), or non-integrated circuitry. Controller 21 is electrically coupled to (directly or indirectly), or has embedded therein, computer memory 22. Controller 21 may include several integrated devices; alternatively, peripheral devices can be connected to controller 21. For example, the controller 21 may have one or more internal timers or clocks (not shown) integrated into the controller 21 itself. Alternatively, PEAD 2 may include one or more timer ICs connected to the controller 21 via external pins. The timer(s) may be used in some embodiments to send wakeup commands to controller 21 to wake it up from PSM. The timer can be connected to an interrupt input of the controller 21. Upon expiration of the timer, the controller is interrupted and executes an interrupt service routine that causes the controller to exit PSM to perform periodic diagnostics or perform other functions. In an embodiment, the PEAD 20 may be wakened from PSM if PEAD 2 detects an activation event or if a predefined amount of time passes between times connecting to the subscriber network 10. This activity is called the “heartbeat” of the PEAD 2.
Computer memory 22 comprises computer readable storage media, preferably in the form of one or more, or any combination, of Programmable Read-Only Memory (PROM, EPROM, EEPROM, flash EPROM), and/or Random Access Memory (RAM, DRAM, SRAM, SDRAM, etc.). Memory 22 stores program instructions executable by the controller 21 to perform one or more operative steps for implementing various aspects of the invention. The computer memory 22 further stores data which may be used by the controller 21 in its operations. The computer memory 22 may be integrated or embedded within the integrated circuit (IC) implementing the controller 21 or may be standalone memory IC(s) electrically coupled to the controller 21 via one or more busses.
The computer memory 22 stores program instructions and data. Memory 22 may store a unique device serial number (SN). Battery supply 27 is electrically coupled to, and supplies power to, all the electronic components of the PEAD 20. Battery supply 27 may be controlled by a power switch 28.
Communications module 23 is electronic circuitry typically fabricated in the form of an integrated circuit (IC) that contains the hardware and control functions for implementing the RF communication. In particular, a typical communications module 23 contains a controller/CPU, integrated computer memory, signal encoding/decoding circuitry, a power amplifier, and a baseband processor which includes multiplexing/demultiplexing, channel selection, carrier generation, and modulation circuitry. In an embodiment, the communications module 23 is a cellular modem responsive to telephone Attention (AT) commands for controlling the modem, and converts digital messages into RF transmission signal suitable for the network on which it is transmitted. In an embodiment, where the communications module 23 is implemented to connect to an LTE or LTE-M cellular network, the communications module 23 is a cellular modem configured to transmit signals on the antenna 23a according to 3G, 4G, 5G, or CAT-M1 or NB-loT protocol. Where the cellular modem is implemented to connect to a GSM network, it is configured to transmit signals on the antenna 23a according to a GSM or EC-GSM-loT protocol. Communications module 23 may further be configured to receive RF signals carrying messages from PEANS 3 via network 10 (
Communications module 23 adheres to a predetermined transmission protocol stack based on the protocol used for communicating with the cellular service to which the PEAD 2 subscribes. As is required generally for cellular modems that need to deliver messages from a mobile device through a cellular network to a packet data network (e.g. the Internet), communications module 23 includes circuitry and programming to encode an emergency alert message generated by the controller 21, encapsulate the encoded message into one or more packets, and perform the signal processing required to adhere to the data transmission scheme(s) recognized and used by the cellular network 110 for data uplink (from PEAD 2 to cellular network) and data downlink (from cellular network to PEAD 2). For example, where network 10 comprises an LTE-M enabled cellular network, the cellular modem preferably is capable of packetizing data in accordance with TCP/IP or UDP protocol, and includes hardware that transmits packet data according to a SC-FDMA, 15 KHz tone spacing, Turbo Code, 16 QAM modulation scheme, and receives data based on OFDMA, 15 KHz tone spacing, Turbo Code, 16 QAM modulation scheme. Other types of cellular networks use different modulation schemes implemented in accordance with the standards promulgated by worldwide organizations such as 3GPP, IEEE, and GSMA. Such alternative networks may alternatively be used as the gateway connection to a packet-switched data network (such as the Internet) for subsequent transmission of alert messages to PEANS 123.
Activation condition sensor(s) 26 (shown as 26a, 26b) comprise one or more sensors 26a, 26b that sense one or more alert activation conditions. For example, a manual activation sensor 26a may comprise a button or switch that a user can press or set to activate the personal emergency alert device 20 to generate an activation signal. In such embodiment, the manual activation 26a generates an output signal on at least one output port. The output port may be a pin, pad, wire, or connected trace on a PCB board. The state of the output signal represents an activation status of the sensor 26a. In an embodiment, the manual activation sensor 26a is implemented with a push-button switch. The activation status corresponds to an activation state when the push-button switch set to a first position (e.g., pressed down), and corresponds to a non-activated state when the push-button switch set to a second position (e.g., not pressed down). In a non-limiting illustrative embodiment, the manual activation sensor 26a is implemented using push-button switch; however, it is to be understood that other types of electronic and/or electromechanical switches may also be used without departing from the scope of the invention.
In another example, a voice-activation sensor 26b comprises a microphone. Microphone 26b detects sound (including voice) and passes signal data representing such detected sound to signal processor 29. Signal processor 29 processes incoming signal data, converts it to voice/sound data signature(s) in a known format, and compares such data signature(s) to predefined trigger signature(s) (stored in memory 22). (Alternatively, the controller 21 can perform the comparison). For example, in an embodiment, the PEAD 20 may be configured to store data signatures of prerecorded trigger words (e.g., “help” or “activate”, etc.) spoken by the user, converted to a digital signature, and stored as predefined trigger signature(s) in computer memory 22. Other examples of predefined trigger signatures that may be stored in computer memory 22 may include signatures generated from sound alarms (such as fire or smoke alarms) or any other digital signature that can be generated from signals picked by a microphone.
While
The PEAD 20 may comprise any number of activation condition sensors 26. While sensors 26a, 26b are illustrated for purposes of example, the PEAD 20 may additionally or alternatively include any one or more of a temperature sensor, a humidity sensor, a water level sensor, a motion sensor, a PIR sensor, a smoke sensor, a gaseous fume sensor, a CO2 sensor, and so on. When an activation condition sensor 26 senses or is otherwise set to an activation state, the sensor 26 (and associated signal processing circuitry 29) signals the controller 21. The controller may perform further processing to determine whether to send an alert message to PEANS 3 via the communications module 23, or may bypass further processing and directly send an alert message to PEANS 3 via the communications module 23. In embodiments, activation sensor(s) 26 may comprise Micro-Electro-Mechanical Systems (MEMS) comprising microfabricated miniaturized electro-mechanical elements (on the order of micro, femto and nano-meters) that by design consume very low power.
The PEAD 20 further comprises a geolocation module 24. In an embodiment, the geolocation module comprises a GPS module that includes a GPS receiver that receives signals from a Global Positioning System. The GPS module further includes a processor that converts received GPS signals into digital GPS geolocation coordinates. A log of the GPS coordinates over time may be stored in computer memory 22. Generally, as discussed below, the geolocation module 24 is not enabled unless and until instructed by the controller 21 based on detection of an activation condition at one of the sensors 26. The GPS module 24 may be implemented as a separate integrated circuit (“chip”), or could be embedded within the cellular modem chip 23. For example, as discussed in further detail hereinafter, the Quectel BG96 Cat.M1/NB1 & EGPRS Module optionally includes a GPS receiver and GPS processing circuitry for receiving GPS data from the Global Positioning Satellite System (GPSS).
Structurally, controller 21 is electrically coupled to receive a signal from each sensor 26 and/or its corresponding processing circuitry (such as signal processor 29). In an embodiment, the controller 21 is a microprocessor or microcontroller capable of receiving interrupt signals and processing interrupt service routines. In such embodiment, the controller 21 is coupled, directly or indirectly, to receive and process one or more activation signal(s) generated by the sensor(s) 26 and executes hardware logic or program instructions based on the received sensor activation signal(s). For example, in the case where a sensor 26 is a manual activation sensor 26a, the sensor 26a generates on a sensor output port a signal representing an activation status of the sensor. In an embodiment, the controller 21 comprises a microprocessor that is capable of processing an interrupt received on an interrupt input port (e.g, a pin or pad of the microprocessor). The output port of sensor 26a is electrically coupled (directly or indirectly) to an interrupt input port of the controller 21, and the signal present on the output port of manual activation sensor 26a serves as an interrupt signal to controller 21. When the button is pressed (or switch set to the position corresponding to an activation state), sensor 26a generates the signal corresponding to the activation state, thereby triggering an interrupt at controller 21.
In a similar manner, the signal processor 29 may generate an activation signal on an output pin or port that is electrically coupled to an interrupt input of the controller 21. The signal processor activation signal may be generated upon detection of a signature match between a predefined trigger signature and a digital signature it generates from signals it receives from the microphone 26b. Thus, when a user 4a speaks or otherwise vocalizes an activation word (such as “help!”), such activation condition is received by the microphone 26a, and processed into a digital signature by signal processor 29. The signal processor 29 (or controller 21) compares the newly processed digital signature with pre-stored activation signatures. If signature of the spoken activation word matches a pre-stored activation signature, the signal processor 29 (or controller 21) generates an activation signal on an output port. The output port is electrically coupled to a controller interrupt port, triggering an interrupt at controller 21.
Controller 21 executes one or more service routine(s) corresponding to the interrupt(s). In an embodiment, the interrupt service routine(s) includes program instructions executable by the controller 21 to formulate an alert message and send commands to the communications module 23 to transmit the alert message indicating the activation condition present at the personal emergency alert device 2. The interrupt service routine also includes program instructions executable by the controller 21 to activate the geolocation module 24 and begin collecting geolocation information, such as GPS coordinates, and periodically transmit the collected geolocation information to the emergency alert notification service 3. The controller 21 may send the GPS coordinate data along with each alert message. In an alternative embodiment, the controller 21 may be programmed to track the GPS coordinate data, determine whether the PEAD 20 has moved from a previous location, and then track the GPS coordinate data, and transmit the GPS coordinate data on a programmed time basis.
Once readied for operation, the PEAD 2 retrieves first location information (such as current GPS coordinates) (step 33) and formulates and transmits an alert message including location information to the PEANS 3 (step 34). In an embodiment, the PEAD 2 then sets a timer to a predefined time interval (step 38), and waits for the timer to expire (step 39). When the timer expires, the PEAD 2 repeats steps 33-39, collecting and transmitting PEAD location information at timed intervals. In an embodiment, the PEAD 2 is designed to disallow turning off the alert/location transmissions to the PEANS 3 once the PEAD 2 is activated. This ensures that the location of the PEAD 2 (and location of a user 4a having the PEAD 2 on their person) will continue to be sent to the PEANS 3 until the battery supply 27 can no longer supply sufficient energy to support the PEAD 2. This prevents turning off of the PEAD 2 by the user 4a (or another person having physical access to the PEAD 2) in situations where the user 4a is under duress (such as when someone else is forcing user 4a to deactivate the PEAD 2).
In an alternative embodiment, once PEAD 2 is activated, the PEAD 2 can only be deactivated by an independent source (not the PEAD 2) sending a predefined deactivation code to PEANS 3. In this case, PEAD 2 listens for a deactivation code (step 35), and if a deactivation code is received (step 36), PEAD 2 automatically deactivates itself by powering down, or putting itself in sleep mode or PSM (step 37.
With reference to
Notification recipients can take action based on the information received in the emergency alert message. For example, notification recipients may be, or can call, emergency service providers (e.g., 911 services, police, fire, EMT and/or other services, etc.). Notification recipients may also attempt to call the user 4a in the hope that the user 4a has a mobile phone capable of receiving a call. (Of course, such action may not be prudent if the user is under duress and used the PEAD 2 to inform others that the user 2 is in trouble but cannot risk using their mobile phone).
Notification recipients can track the location of the user 4a (or technically the location of the PEAD 2), through periodic timed notification messages transmitted by the PEAD 2, and may themselves, or may direct someone else, to physically go to the location indicated by the PEAD 2 in order to provide assistance to the user 4a.
Deactivation
Occasionally a PEAD 2 may be activated accidentally or the emergency situation is resolved and the user 4a no longer needs physical help. In such situations, it may be desirable to allow deactivation of the PEAD 2. In an embodiment, the transmissions by the PEAD 2 may be deactivated by an independent party. In an embodiment, PEANS 3 must receive a valid deactivation code from an independent source (i.e., not the PEAD 2, and preferably not the user 4a). Preferably, the deactivation code is known only by the notification recipients and/or other 3rd party agencies (such as emergency services) (“authorized parties”). The authorized parties may or may not include user 4a. As an additional line of security, “authorized parties” would not include user 4a. Authorized parties can send the deactivation code to PEANS 3 to deactivate the PEAD 2. The deactivation code is preferably used only when the individual or entity deactivating the PEAD 2 knows or is informed that the user 4a is safe (preferably through personal knowledge or a trusted source). In an embodiment, PEANS 3 provides one or more application programming interfaces (APIs) through which it receives messages from authorized parties. For example, PEANS 3 may provide an API for receiving SMS text messages containing a deactivation code. As further example, PEANS 3 may provide an API for receiving email messages containing a deactivation code. In yet a further example, PEANS 3 may provide an API for receiving a deactivation code from an authorized party via an app executing on the authorized party's electronic device (e.g., a mobile phone, tablet, computer).
Returning to
Upon determination of a valid deactivation code (step 46), PEANS 3 may take further action. In an embodiment, given a valid deactivation code PEANS 3 simply sends a deactivation instruction to the PEAD 2 (step 48a). In an embodiment, as described in detail hereinafter, the notification service 40 can only communicate with the PEAD 2 if and when the PEAD 2 connects to the notification service 40. Accordingly, in such embodiment, PEANS 3 sends deactivation instructions to the PEAD 2 on the next connection by the PEAD 2 to PEANS 3. In an alternative embodiment, once activated (step 31) and readied for operation (step 32), the PEAD 2 remains connected to PEANS 3 until it either receives deactivation instructions from PEANS 3 or runs out of battery life. In such embodiment, PEANS 3 can transmit deactivation instructions to the PEAD 2 on demand since, once activated, the PEAD 2 is always connected to PEANS 3.
In an alternative embodiment, PEANS 3 provides a secondary emergency notification feature that allows the user 4a to notify PEANS 3 that the emergency notification message sent by the PEAD 2 is a true emergency request (in the guise of a deactivation request) or a true deactivation request. To this end, the user 4a may send an authorized party deactivation message to PEANS 3 via an independent electronic device other than the PEAD 2. In this embodiment, the deactivation code may indicate that the message is either a true deactivation request or a true emergency request. The code corresponding to a true emergency request is preferably known only by the user 4a (and optionally to other authorized users) and is stored with or is accessible by PEANS 3. Preferably, the user interface through which user 4a enters the code equating to the true emergency request (the “true emergency code”) is identical to the user interface through which the user 4a enters the code equating to a true deactivation request (the “true deactivation code”). In this way, the user 4a can enter a true emergency code under the guise of entering a deactivation code in the situation where the user 4a is under duress (e.g., an assailant is watching the user 4a enter the code). In implementation, PEANS 3 validates the deactivation code (step 46) and determines whether the validated deactivation code is a true deactivation code or to an true emergency code (step 47). If the deactivation code is a true deactivation code, PEANS 3 transmits deactivation instruction(s) to the PEAD 2 (step 48a) and optionally transmits a deactivation verification message to the authorized party (either to all authorized parties or only to the particular authorized party who sent the deactivation message to PEANS 3) (step 49). If, on the other hand, the deactivation code is a true emergency code, PEANS 3 does not transmit deactivation instruction(s) to the PEAD 2 (step 48b) and optionally transmits a verified emergency message to the notification recipients (preferably not including the user 4a) (step 49). PEANS 3 also optionally sends a dummy (i.e., a “fake”) deactivation verification message to the user 4a or authorized party who initiated the authorized party deactivation message (step 49b) to make it appear that the PEAD 2 has been deactivated, when in fact the PEAD 2 has not been deactivated.
In preferred embodiments, PEAD 2 is (1) portable and (2) operates even in remote locations that may not have access to power and/or (reliable) WiFi for accessing the Internet 120. To this end, (1) power to PEAD 2 is supplied from a battery supply (or optionally a standalone power source such as a solar power supply) (allowing for portability), (2) PEAD 2 is implemented using low power components and power saving methodologies (maximizing battery life), and (3) PEAD 2 accesses the Internet 120 to communicate with personal emergency alert notification service 123 using a Low Power Wide Area Network (LPWAN) to support long-lasting battery life (also maximizing battery life). The result is a long-lasting low-power personal emergency alert system that allows a PEAD 2 to be worn, carried on one's person, and/or installed in accessible proximity to a user 4a in a multitude of different environments, including in remote locations and deep within buildings.
PEANS 123 stores registration information in a database 123a. The registration information stored in database 123a includes the PEAD identifier, along with corresponding notification recipient and corresponding delivery service information. In an embodiment, database 123a stores the device ID of each registered PEAD 2, along with, for each device ID, one or more electronic device delivery addresses of notification recipients and corresponding indications of electronic delivery services which are to be used to deliver a notification to the corresponding respective delivery addresses. Such schema allows one or more notification recipients to be notified via various notification delivery mechanisms. For example, for a given registered PEAD 2, a notification message may be sent to one or more recipients via their respective chosen notification delivery service (e.g., email, SMS text, in-app push notification, etc.) so that they can receive notification via their respective preferred technology.
For example, for a given registered PEAD 2, the device may be configured such that a notification is delivered via email to a particular notification recipient's email address, via SMS text to a recipient's mobile phone number, and to a recipient's app executing on the recipient's smart phone (addressed via the smart phone number or email address). A different registered PEAD 2 (not shown) having a different device ID may be configured such that a notification is delivered, for example, only via SMS text to a different recipient's mobile phone number. The described registration schema contemplates the ability to allow different registered devices to be individually configured such that notification recipient information and preferences can be specified on a device-by-device basis—that is, on a per PEAD basis. In embodiments, users of the personal emergency alert notification service 123 can select the notification delivery service(s) and corresponding notification recipients to be notified by the service, via a web-enabled app, a website portal or API. While it is contemplated that the notification service 123 supports user-configurable notification preferences, it is also within the scope of the invention that the notification delivery service(s) and notification recipients are predetermined by an administrator, and enterprise-level entity or other entity.
In operation, PEAD 2 may be activated per previous discussion. In system 100, PEAD 2 connects through a Low-Power Cellular Network 110 (shown as an LTE-M network) to the Internet 120, to send an emergency alert message to PEANS 123. PEANS 123 is connected to the Internet 123 by way of an Internet-enabled PEANS server 122. PEANS server 122 passes received emergency alert messages originating from PEAD 2 to PEANS 123. PEANS 123 parses and decodes each received emergency alert message, validates the message, and for valid messages, generates and sends an emergency notification message to designated notification recipient(s) associated with the PEAD 2. PEANS 123 may send such emergency alert message via pre-designated notification delivery services 125, 127, 129 associated with each respective notification recipient(s). In an embodiment, the notification service(s) comprise Internet-enabled services, such as an email service 125, an SMS text service 127, and an app push notification service 129. Such services connect to the Internet via servers 124, 126, 128, respectively, which route the emergency notification message(s) to one or more electronic device(s) 5a, 5b, 5c, 5d, 5e of designated notification recipients 4b, 4c, 4d, 4e. The messages may be routed through the Internet to another network, such as a cellular network, a WiFi network, a LAN, etc. to reach the intended destination (i.e., an electronic device 5 capable of receiving the notification message(s) via the corresponding delivery service(s).
In system 100 PEAD 2 AND Notification Service 123 communicate via a combination of networks, including a cellular network 110 and Packet Data Network 120 (such as the Internet). Preferably, the cellular network 110 is a Low Power Wide Area Network (LPWAN) that supports low-complexity, deep-coverage devices. Without limitation, exemplary LPWANs include LTE-M (including CAT-M1), NB-IOT and EC-GSM-IOT cellular networks.
LTE-M (also known as LTE CAT-M1) is a Third Generation Partnership Project (3GPP) standards-based LPWAN technology, having a maximum channel bandwidth of 1.4 MHz, a maximum data rate of 1 Mbit/s, and operates in either full or half duplex mode (i.e., can transmit and receive simultaneously in full duplex mode, or can only transmit or receive at any given time in half duplex mode). NB-loT (also known as CAT-NB1 or CAT-M2) is also a 3GPP standards-based LPWAN technology, having a maximum channel bandwidth of 180 kHz, a maximum data rate of 250 Kbit/s, and operates only in a half duplex mode. In another alternative implementation, the cellular network could be implemented according to the EC-GSM (or Extended Coverage Global System for Mobile, also called EC-GSM-IOT) is a Global System for Mobile Communications Association (GSMA) standards-based LPWAN technology which also operates in the licensed spectrum (on the 900 MHz and 1.8 GHz frequency bands) and implements EC-GSM protocols utilizing the existing GSM networks and GSM cellular to Internet infrastructure. Table 1 summarizes some of the main specifications for each of the LTE CAT-M1, CAT-NB1 and EC-GSM-IoT standards.
The particular type of cellular network that may be used for transmission of an alert message between a given PEAD 2 and the Notification service 123 may depend on various factors, including availability of a given type of cellular network in the geographical region where the PEAD module is installed, whether the PEAD module is authorized to access an available cellular network, how much data and how quickly such data needs to be transmitted to the PEANS, etc.
It is to be noted that commercial networks implemented in accordance with any of the LTE CAT-M1, CAT-NB1 and EC-GSM-IoT standards operate in the licensed spectrum of the radio-frequency spectrum (meaning that the frequency bands on which they operate are regulated by governmental regulatory bodies). Operation within the licensed spectrum requires operators to obtain a license or permit from a regulatory authority and to adhere to a set of technical, operational and behavioral rules, having the effect of potentially offering a higher quality of service (QOS) for delivery of communications between the PEAD 2 and the notification service 123 than may otherwise be obtained using networks operating in the unlicensed spectrum. It may therefore be advantageous to use such an available cellular network to communicate PEAD module alert messages from the PEAD 2 to the Notification service 123. However, it is to be understood that in other embodiments, it may be suitable or advantageous to use a LPWA network operating in an unlicensed frequency band of the radiofrequency spectrum. Examples of such networks may include, but are not limited to, LoRa, SigFox, etc. Furthermore, while a preferred embodiment of the PEAD module is battery powered and therefore to conserve power connects to the Notification Service via a LPWAN, in alternative embodiments where power consumption is not at issue for the PEAD module, the PEAD module may be implemented using a transmission module that allows it to transmit its alert messages via any wireless or wired network (including, but not limited to, LPWANs, LANs, WANs, WiFi Access Points, etc.) using an appropriate corresponding transmission protocol. For example, if the PEAD module is not positioned in a remote location and has access to a Wi-Fi Access Point, the PEAD module could be configured to include a WiFi transmission module and to send its alert messages to the Notification Service by connecting to the Internet via a local WiFi Access Point. Similarly, if WiFi is not available but a cellular service (that is not an LPWAN) is available, the PEAD 2 could include transmission module that can communicate with the available cellular service (which may not be an LPWAN) and could then transmit its alert messages via that cellular service.
In a preferred embodiment shown in
The E-UTRAN includes a network of cellular sites 111 (shown as 111a, 111b) providing areas of network coverage arranged in geographical “cells” across areas of Earth. Each cellular site includes at least one antenna mounted on a cell tower, which is designed to transmit and/or receive signals on a designated LTE-M frequency band. Within a given cell, transmitted signals adhere to minimum signal strength specifications so as to cover at least the entire area of the geographical cell. In practice, each cellular tower has multiple antennas sending and receiving over multiple LTE/LTE-M frequency bands, and each antenna is tuned to receive and/or transmit signals on various frequencies and in different directions. Each antenna is connected by wire or fiber optic cable to a base station (which in the LTE/LTE-M RAN is referred to as an Evolved Node B, eNodeB, or eNB).
The base station, or eNB, is the primary interface for connecting subscribing user equipment devices (UEs) to other devices and services serviced by the particular LTE/LTE-M network service provider (often called the “carrier”, such as commercial providers Verizon, AT&T, etc.). The base station is also the primary interface for connecting subscribing devices via networks of other providers (such as routing calls to UEs who subscribe to a different carrier than the sending UE, and to devices, machines and services on other networks (such as other RANs, packet switched and packet data networks). The eNB manages the radio interface between user equipment (UE) devices (such as mobile and/or remote LTE and LTE-M enabled devices) and the core network (referred to as the Evolved Packet Core (EPC)) which connects and routes messages between remote UEs subscribing to the LTE/LTE-M cellular network and UEs and other devices on networks of other carriers or packet data networks such as the Internet.
Radio access network (RAN) 118 provides connection between LTE-enabled devices and the core network 119. The core network 119, or EPC, is an all-IP (Internet Protocol) network that manages the interconnection of calls and data flow between devices connected to the RAN 118, to one another and to other networks 130 and/or packet data networks (PDNs) 120 and resources connected to the core network 119. The core network 119 forms the central control of the cellular network 110. Among other functions, core network 119 manages authentication of user equipment (UE) (such as PEAD 2 and other UE such as cellular enabled mobile devices) requesting access to cellular network 110, voice/data call and message control/switching/routing, allocating resources to meet subscriber quality of service levels, and setting up data traffic tunnels (known as bearers) between authenticated UEs to packet data network (PDN) gateways 115 for transfer of user traffic between UEs and PDNs (such as the Internet 120).
In the LTE/LTE-M network, the core network (EPC) 119 includes a Mobility Management Entity (MME) 112, a Home Subscriber Server (HSS) 113, a Serving Gateway (S-GW) 114, a Packet Data Network Gateway (P-GW) 115. The MME 112 operates as the main control entity for the LTE radio access network (E-UTRAN) (which, in an LTE/LTE-M network, implements the RAN 118). The MME 112, with the assistance of a UE-connecting eNB 111, and a Home Subscriber Server (HSS) 113 that hosts network subscriber information, manages authentication of devices requesting access to the network 110. The MME 112 also manages control plane (Non-Access Stratum (NAS)) signaling, including mobility management, session management, and setup of tunnels, or “bearers” that carry user plane traffic. The MME 112 communicates with eNBs 111a, 111b, (and others not shown) in the radio access network 118 via the LTE S1-MME interface, while eNBs communicate with UEs via the LTE-Uu interface. When a UE requests access to the network, the eNB with greatest signal strength (usually the eNB nearest the requesting UE), along with both the UE and the MME serving the eNB, coordinate with each other to perform mutual authentication. In LTE networks, both LTE-enabled UEs and the LTE network follow well-known pre-defined LTE authentication protocols to ensure, from the UE's point of view, that the UE is accessing the network it thinks it is accessing and, from the network's point of view, that the UE has authorization to access the network and is who the UE says it is. The communication interfaces and protocols for LTE-M, including among others the LTE-UU, LTE-S1, LTE-S5 and SGi interfaces, are specified and published by 3rd Generation Partnership Project (3GPP), available at www.3gpp.org.
When PEAD 2 is authenticated, the MME 112 sets up an IP connection (or “session”) between the PEAD 2 and a particular Packet Data Network (PDN) through which PEANS 123 is accessible. Profile information associated with the authenticated PEAD 2 is accessible through the Home Subscriber Server 113 (and/or a Profile Repository (not shown)), which stores default PDN IP address associated with the PEAD 2. The PEAD 2 can also specify a specific IP address during the access request. The MME 112 determines the IP address of the PDN of the PEAD 2 requesting connection, using the default IP address from the PEAD 2 profile information or from PEAD 2 request information. The PEAD 2 can have either a static IP address or may be dynamically assigned an IP address using standard Dynamic Host Configuration Protocol (DHCP) or other dynamic IP address allocation protocols. The session identifies the connection endpoint IP addresses, namely the IP address of the PEAD 2 and the IP address of the PDN (also called the Access Point Name (APN)) through which the PEAD 2 wishes to connect (presumably to use services).
In conjunction with setting up the session, the MME 112 also sets up a default Evolved Packet System (EPS) bearer, which is a tunnel through which IP packets are transferred through the LTE network 110 between the PEAD 2 and a PDN gateway (P-GW) that serves the destination PDN. With reference to
LTE/LTE-M networks are all-IP networks, meaning that all user traffic is delivered by way of Internet Protocol (IP) packets. When an LTE-enabled UE, such as PEAD 2 connects to the network, it is assigned an IP address, a session is set up, and data traffic bearers are set up between the UE device and a PDN gateway P-GW. The IP address assigned to the PEAD 2 remains valid and the bearers remain connected until the device is detached from the network. That is, the session remains valid until the PEAD 2 is detached from the network. In the network system of
Another group 33 of bits 31 corresponds to encoded alert information, which comprises a plurality of bits having values that may be encoded to represent one or more event(s) corresponding to one or more respective monitored event occurrences at PEAD 2. For example, alert information group 33 may include a bit S1 corresponding to a first sensor monitoring the occurrence of a first event, a second bit S2 corresponding to a second sensor monitoring the occurrence of a second event, and so on, monitoring up to n events. As a non-limiting example, the alert group 33 may comprise one or more individual bits corresponding to detected events including, without limitation: a push-button activation event, a voice-activation event, and a Low Battery event. The alert group 33 may comprise different and/or additional bits to represent various other detected events and/or change in states(s) of additional monitored activation conditions. In a more further detailed example, and with reference to
In the message payload 30, another group 34 of bits 31 corresponds to encoded status information. For example, a bit B may represent the state of a battery low condition, while a bit T may represent an alert trigger state indicating whether or not an activation condition was detected by one or more sensors. Further in the message payload 30, a group 35 of bits 31 may correspond to encoded control information. In the illustrative embodiment, control bits may be used to hold the connection open between the PEAD module 300 and PEANS 123 in order to perform certain maintenance actions or actions that require 2-way cooperation with and/or acknowledgement between the PEAD module 300 and Notification Service 123. For example, again by way of illustration and not limitation, the Control group 34 may comprise a bit R which indicates to the Notification Service that the PEAD module 300 has been reset. The Control group 34 may further comprise a bit F indicating that the device has been formatted or updated with new firmware.
Referring again to
Preferably, the PEANS 123 provides an Application Programming Interface (API) by which client devices access the PEANS 123. In an embodiment, the hosting computer system instantiates an instance of the PEANS 123 upon receipt of a proper API call to the PEANS 123. In other words, when a web browser or other software or another system generates a Uniform Resource Locator (URL) request containing the correct IP address of the hosting computer, along with the correct path to the directory containing the executable of the PEANS 123, and the API call is formatted correctly and contains valid parameters, the PEANS server automatically instantiates an instance of the PEANS 123.
In the system of
With regard to the batteries, in an embodiment, the main power source of PEAD 2/20 comprises battery supply 27 (see
As mentioned above, PEAD 2 minimizes power consumption through use of low/very low/ultra low power components. By way of example and not limitation, and referring to
PEAD 2 minimizes power consumption through use of power saving techniques. Several PEAD 20 components (such as controller 21, signal processor 29, communications module 23 and geolocation module 24) are capable of being placed in a power saving mode (PSM), whereby certain high(er)-power consumption features of components are shut down and/or placed in a sleep mode when placed in PSM. For example, the communications module 23 turns off power to the antenna 23a when in PSM. The selection of the communications module 23 must of course consider the network over which alert messages are to be transmitted to ensure that the communications module 23 is capable of transmitting according to the protocol required by the selected network.
Power efficiency and conservation may be further achieved through power-saving communication methodologies. For example, a PEAD 20 may not connect to the network at all until it is activated. In implementations that do require PEAD 20 to check in (in order to verify that the PEAD 20 is still operational), PEAD 2 may check in to the network/notification service based on infrequent intervals. Once activated, it is generally desirable to maintain a connection to PEANS; however, further power conservation may be achieved by placing components in PSM between geolocation capture intervals.
PEAD 2 implements a LPWAN communication protocol to communicate to cellular base stations and passing of emergency alert messages to Internet-enabled notification service. For example, in the ille PEAD 2 implements LTE-CAT-M1 protocol to communicate with the cellular network 110 for further routing to Internet-enabled Notification Service 123. LTE-CAT-M1 specifies a transmission signal strength of 23 dBm.
Once the communications module 23 is ready to transmit and/or receive, the controller 23 obtains the device identifier (step 213). In an embodiment, the device identifier comprises the serial number of the PEAD 2. In alternative embodiments, the device ID may comprise alternative and/or additional identification information, such as but not limited to the ICCID, and the IMEI of the PEAD 2 (or components thereof). In an embodiment, the ICCID is integrated into the SIM 25, and the controller 23 instructs the communications module 23 to access the SIM 25 to obtain the ICCID of the SIM 25 (step 213a). In an embodiment, the IMEI is programmed into an Electrically-Erasable Programmable Read-Only Memory (EEPROM) embedded in the communications module 23, and the controller 23 issues a command to the communications module 23 to obtain it (step 213a). In an embodiment, the manufacturer of the PEAD 20 issues a unique serial number for each PEAD module at the time of manufacture, and stores it in a Programmable Read-Only Memory (PROM) or other memory 22, accessible and accessed by the controller 21 (step 213b).
Once the device ID is obtained, the controller 21 then instructs the communications module 23 to connect to the subscriber cellular network 110 (
Once connected to the cellular network, the controller 21 then activates the geolocation module (step 215), if it is not automatically self-activated at power up. The controller monitors the geolocation module (step 216) to determine when it is ready for use. In an embodiment, the geolocation module is a Global Positioning Signal (GPS) transceiver that includes an output port, pin or pad on through which it indicates is “ready” status. Once the geolocation is ready for use, controller 21 then obtains the current geolocation information of the PEAD 2 (step 217), for example by sending a request to the GPS transceiver. Controller 21 then generates an alert message and instructs the cellular modem 23 to transmit the alert message to PEANS 3 (step 218). In an embodiment, controller 21 sends a sequence of AT send commands to the cellular modem 23 (step 218). Controller then sets (or resets) a timer (step 219) to wait a predefined time interval, waits until the timer expires (step 219a, and then repeats steps 217-219a until the battery level depletes.
In an embodiment, controller 21 may utilize power saving techniques by basing a controller interrupt input on the output of the timer. In this embodiment, when the controller 21 sets the timer (step 219), it places itself and the RF module(s) into a power saving mode (PSM) (step 291b). Then, when the timer expires, it generates an output signal that is connected to an interrupt input on the controller 21. When the timer generates an interrupt of the controller 21 upon expiration of the timer (step 219a), the controller 21 exits PSM (step 219c) and wakes up the RF module(s) (step 291d).
Encode/decode module 302 (and specifically the decoder portion, or “decoder,” 302a of encode/decode module 302) decodes messages received from remote PEAD modules 5 that are routed to it from PEAD 2 through the Internet 120 (for example, from the P-GW 115 (
The encode/decode module 302 (and specifically the encode portion, or “encoder”, 302b of the encode/decode module 302) also encodes messages and data to be sent from PEANS 300 to the PEAD 2. Specifically, the encoder 302b encodes into a packet payload information that is to be transmitted from the Notification Service to the PEAD 2. The encoder 302b formats the packet payload in a format that is decodable by the PEAD 2, and then encapsulates the packet payload into one or more IP packets for routing to the PEAD 2 via the Internet 120 and cellular network 110.
The central control module 301 operates as the central controller for PEANS 300 and offers one or more Application Programming Interface(s) (APIs) to allow other modules, services and devices connected to the Internet 120 to communicate with PEANS 300.
Admin Module 303 may provide code management tools which allow an administrator to manage app and firmware versions, and deployment of app and/or firmware upgrades to electronic devices 5 and/or PEADs2. In an embodiment, Admin Module 303 may be configured to allow a vendor or manufacturer of a device that incorporates PEAD 2 to keep track of firmware versions of its respective devices in the field, and control deployment of firmware upgrades to such devices.
The code database 306 comprises computer-readable storage memory and stores one or more versions of firmware for the PEADs 2, one or more versions of apps for the App Store(s) 308, and other administrative data, program data, and information. For example, the code database 306 may include app code and various versions thereof of an app 311a that may be downloaded to an app store 308 and made available to subscribers to PEANS 300. For example, PEANS 300 may make available one or more apps such as an iOS app for Apple devices such as iPhones and iPads, and an Android app for Google Android devices. These apps may be made available through the Apple store or Google Play store. A subscriber may download an available app 311a from one of the stores 308 The apps may be downloaded and installed by an end user from one of the Apple store of the Google Play store to their end user electronic device 5. The app 311a communicates with PEANS 300 using conventional app technology such as made available through the electronic device operating system (such as iOS or Android).
Admin Module 303 may also provide tools to allow an administrator to access profiles, account information and/or subscriber records of subscribers of the PEANS 300. These tools may include graphical user interfaces, controls and/or methods for setting up subscriber accounts, creating subscriber records, and adding, activating, modifying, and/or removing subscriber profiles, subscriber accounts, and/or subscriber records. For example, Admin Module 303 may include a Customer Support tool (not shown) that allows a customer service representative to assist subscribers of the personal emergency alert notification service, including allowing such customer service representative to add, remove, and/or modify information contained in a subscriber record 360 (
Generally at least one record 360 is stored for each PEAD 2 monitored by the PEANS 300. A typical subscriber database 305 will store thousands of PEADs or hundreds of thousands of PEADs or more records, corresponding to unique PEAD modules 2.
Referring again to
Control Module 301 provides an API through which user apps 311a can communicate with PEANS 300 and configure their user profile, notification recipient information, and the operational settings for their registered PEAD 2. Users connect to PEANS 300 through the app 311a running on their local device 5, which connects to the Internet directly through WiFi, a LAN (via Ethernet), and/or indirectly through a cellular or other network 130. Communication between the app 311a and control module 301 are routed using conventional TCP/IP over the Internet 120 and/or cellular networks. The app 311a provides prompts radio buttons and/or other graphical user interface (GUI) widgets/controls to allow the user to configure settings for the PEAD 2 and for operation of PEANS 300 relative to the particular PEAD 2. As an example, the app 311a may provide a GUI displaying a slider that allows a user to set the level of sensitivity of a sensor on the PEAD 2. Changing the sensitivity level changes the sensitivity level of a sensor to a type of event and may result in more or fewer activation conditions sent to the PEAD module controller based on the sensitivity setting.
When a user or owner of a PEAD 2 subscribes to PEANS 300, the user enters the subscriber information, including subscriber details such as contact information, notification recipient information including delivery service handles and associated delivery services to use to notify notification recipients, and payment information. During registration with PEANS 300, the user may be required to submit a payment for subscribing to the services. Accordingly, PEANS 300 may also include a Payment Module 304. The Payment Module 304 may either manage payment from a subscriber directly, or may handle communication with a 3rd-party payment processing system 307 to process payments.
Control module 301 is configured to receive an alert message (e.g., an IP packet containing the message payload 30 (
In an embodiment, the Encoder/Decoder module 302 in
Generally, PEAD 2 only contacts PEANS 300 for one of two reasons: (1) to alert the PEANS 300 of the occurrence of an emergency event at the PEAD 2, or, in an optional embodiment, (2) to check in with PEANS 300 to indicate that the PEAD 2 is still functioning and connected (also referred to herein as the “heartbeat” function).
As illustrated in
On the PEANS 300 side, PEANS receives and decodes the alert message from PEAD 2 (step 405). PEANS notifies the notification recipients (step 406). If the alert message indicates the battery is low (step 407), PEANS updates the Unit_battery bit 373 in the database record corresponding to the sourcing PEAD 2 to reflect the low battery condition (step 408), and optionally notifies the notification recipients (step 409). If the alert message indicates an emergency alert message, (step 410), PEANS 300 checks the Unit_Deactivate bit 385 in the database record corresponding to the sourcing PEAD 2 to see if the PEAD 2 should be deactivated (for example, in the situation that PEANS 300 received a valid deactivation code, per
PEAD 2 receives either an ACK or Deactivate command (step 414). In either case, PEAD 2 closes the connection to PEANS 3 (step 415). If the response is a Deactivate command, PEAD 2 reinitializes the PEAD 2 to reset it and thereby deactivate its present emergency alert status.
Hub Embodiment
It will be appreciated that a more expansive AED tracking system can be implemented using a hub concept.
PEAD 500 also includes a local area transceiver 509, such as but not limited to a 433 MHz transceiver, equipped with an antenna 510. Transciever 509 listens, using antenna 510, for signals x-mitted via sensor antenna(s) 5221, 522b, 522m from remote sensors 521a, 521b, 521m (collectively 521) (
In an embodiment, transceiver 509 comprises a 433 MHz transceiver that listens for messages sent from remote sensor devices 521 (or, as discussed in connection with
Optionally, PEAD 500 itself may include one or more sensors 506a, 506b, 506n (collectively 506) that sense, and/or sense and process, one or more predefined conditions in the environment 520 and alert the controller 501 upon detection of such predefined condition(s). Sensors 506 may be directly electrically coupled to the controller 501. For example, each of sensors 506 may have a corresponding alert output that electrically connects, directly or indirectly through additional circuitry, to one or more interrupt ports of the controller 501. Corresponding interrupt service routines within the program code of the controller 501 (which may be stored in memory 502) implement control logic for processing the alert, decoding the alert (if necessary), determining whether to send an alert message to an external Notification Service (such as PEANS 300) in cooperation with the cellular modem 503 over a cellular network such as a low-power wide area network (LPWAN). In an embodiment, no sensors 506 exist on board the PEAD hub 500, as indicated by the dashed lines in
As discussed previously, any of the PEADs 20, 540 or PEAD hub 500 may include a geolocation module in order to track the location of the respective PEAD/hub. Such geolocation modules may be implemented with a Global Navigation Satellite System (GNSS) receiver (and processor) such as one capable of acquiring and processing signals from the Global Positioning System (GPS), GLONASS, Galileo, Beidou and other regional satellite navigation systems. The GNSS receiver determines a geolocation of the PEAD/hub using time signals transmitted from satellites 522 via satellite radio waves along a line of sight. In an embodiment, the GNSS receiver is integrated into the same integrated circuit chip as the cellular modem. For example, in embodiments where a PEAD 20 or hub 500 sends messages to PEANS over a cellular network 110 using a cellular modem, the cellular modem and GNSS Receiver may be implemented using a Quectel BG96, as detailed previously.
In embodiments, the respective controllers 21, 501, 541 of PEAD/hub 20, 500, 540 may turn on the GNSS receiver periodically to acquire the current position of the PEAD/hub 20, 500, 540. In embodiments, when an alert message is formulated and sent to PEANS 123, the PEAD/hub controller 21, 501, 541 obtains the current (or most recent) geo-spatial (also referred elsewhere herein as “geolocation”) position of the PEAD/hub as acquired by the GNSS Receiver, and includes the current (or most recent) location coordinates in the payload of the alert message that it sends to PEANS 123. PEANS 123 may use the geo-spatial position coordinates as data input to its control logic. Alternatively, PEANS 123 may include the geo-spatial position coordinates in its message to notification recipients.
As previously mentioned, an important consideration in the implementation of the PEAD module or PEAD and other system elements may be the limited power supply available for powering the PEAD/hub due to its stand-alone battery power supply. In order to maximize the life of the PEAD/hub in the field, the PEAD/hub may be configured to implement several additional power saving features. In an embodiment, the PEAD/hub controller 21, 501, 541 is programmed to determine whether, and how often, to send an alert message to the PEANS 123 when a given activation sensor 26, 506, 521, 546 is triggered. For example, in an embodiment, a controller may be programmed to send an alert message to the PEANS every time such controller receives notification that a given sensor is triggered. However, for situations where the same sensor continuously triggers due to the same trigger condition over a certain period of time, repeated alert messages that provide no additional information may be generated. To conserve battery power, in an embodiment, such controller may be programmed not to send an alert message to PEANS 123 if it has already sent an alert message within a programmed amount of time. Such controller may further be programmed to change the rate at which it sends alert messages. For example, when such controller receives an alert message from a given activation sensor, it may immediately send an alert message to PEANS 123. Upon receipt of a second alert message gend by the same activation sensor within a given period of time from the first alert message, such controller may delay sending another alert message to PEANS 123 until a certain amount of time has passed and the condition still exists, and/or may gradually increase the delay in sending additional alert messages if it continues to receive alert signals that appear to be a result of the same condition.
Determination of whether to send an alert to PEANS 123 may vary depending on the purpose and application of use of the PEAD/hub 20, 540, 500. In an embodiment, a PEAD/hub controller sends an alert message for every alert generated by an activations sensor. In an embodiment, such controller sends an alert upon the satisfaction of one or more additional conditions (for example, a certain amount of time must pass before sending a next alert). In an embodiment, once an alert is sent, if the sensed condition continues without cease for a certain duration of time, the controller sends only one or a small few alerts. If the sensed condition ceases, in an embodiment, the controller may send another alert indicating cessation of the sensed condition. In general, the controller may be programmed to send as many or few alert messages to the PEANS as meets the requirements of the application and purpose for which the PEAD system is installed. For example, it may be sufficient to alert the PEANS only once upon receipt of a first alert by an activation sensor and then ignore further alerts. In a different application, it may be better to require a set number of alerts from a given activation sensor before alerting the PEANS. In yet another application, it may be desired, once an alert message has been sent to the PEANS, to send an alert upon cessation of the condition that caused the alert. In accordance with the invention, many different scenarios in the alerting scheme are feasible and contemplated for use with the PEAD, and any exemplary embodiments described herein are not intended to be limiting.
In an embodiment, upon receiving an alert message, the PEANS decodes the alert and extracts the device identifier and alert code and/or other message information from the alert message. Depending on the specific alert code and/or other message information, the PEANS may determine whether to send a notification message to the notification recipients associated with the PEAD/hub. In an embodiment, the PEANS sends a notification message to all notification recipients for every alert message it receives from the PEAD/hub. In an alternative embodiment, the PEANS may process the alert code and send a notification message only under certain conditions. For example, if the PEANS determines it has received an identical alert code within a predetermined time period before the receipt of the present alert code, it may be programmed to ignore the later-received alert message from the PEAD/hub until the predetermined time period has passed. Alternatively, the PEANS may continue to send alert notification messages to the notification recipient(s) upon receipt of repeat alert notifications from the PEAD/hub, but the controller may increase, or gradually increase, the time between sending notification messages to the notification recipients. In this way, notification recipients will not be overwhelmed with notification messages that alert to the same ongoing condition.
It will be appreciated that personal emergency alert systems and technologies, in particular the PEAD, PEAD hub and Notification Service (PEANS), may be implemented and used to alert and notify of many difft types of personal emergencies. By way of example and not limitation, in an embodiment, an activation sensor, and the basis on which a personal emergency alert condition may be based, may comprise one, or a combination of, the following sensors: an accelerometer, a microphone, a passive infrared (PIR) sensor, a reed switch, a camera, a liquid level sensor, a charge sensor, a load sensor, a voltage sensor, a resistance sensor, a capacitance sensor, a thermo sensor, a temperature sensor, a humidity sensor, a flex sensor, a pressure sensor, a chemical composition sensor, a light sensor, a UV Index sensor, a sound sensor, a wind sensor, a positioning sensor, a moisture sensor, etc. In an embodiment, such as discussed in connection with
The mapping service discussed in connection with
Another advantage of the systems discussed herein, and in particular with respect to the PEAD system with external sensors as discussed in connection with
It will further be appreciated that although the preferred embodiment uses an LPWAN over which to transmit alert messages, in other embodiments, the PEAD module and/or PEAD may additionally or instead be equipped with a WiFi modem to transmit the messages to the nearest WiFi access port and from there onto the Internet to the Notification Service.
PEAD Housing and/or Integration with Other Items
In an embodiment, the insulating pull-bat 702 is the method of activation, and once removed, the PEAD 2 begins alert transmission(s). While not shown, personal emergency alert device 2 may also include a push-button switch and may be designed such that once the PEAD 2 is turned on (for example, by removing the pull-tab 702), a user requiring emergency assistance need only push the push-button switch to generate the activate the PEAD to send an alert message to the personal emergency alert notification service (PEANS) and start tracking the geolocation of the device 2.
In certain situations the PEAD 2 is most effective for its purpose if its presence and location is easily noticed and/or known by the user(s) it is intended to serve. For example, a PEAD 2 may be installed in living environment of people who may require more attentive care (including independent living environments, nursing homes, assisted living environments), in hospitals, office buildings, public buildings, day care centers, community centers, prisons, elevators, trains, public/private transport vehicles, etc.), When used for such situations, the housing 700 of the PEAD 2 is preferably conspicuous so that the user 4a or other people who are requesting assistance on the user's behalf easily notice the presence and location of the PEAD 2. Housing 700 (i.e., the package or container that the electronics of the PEAD 2 are contained within) may be made conspicuous through one or more, or a combination of, housing size, color, lighting, signage, etc. Additionally, such situations may call for a very simple user interface. In an embodiment, the user interface is a simple push button to activate the device.
Other situations may call for less conspicuous PEAD housing 700. For example, when the PEAD 2 is used as an emergency call device by people who may be more vulnerable circumstances (e.g., elderly people living independently), the PEAD 2 may be worn on the user's person such as a necklace or bracelet (see personal emergency alert device 2 on user 4a in
Those of skill in the art will appreciate that aspects of the invented device, system and methods described and illustrated herein may be implemented in software, firmware or hardware, or any suitable combination thereof, including by way of a computer or microprocessor process in which instructions are executed, the instructions being stored for execution on a computer-readable medium and being executed by any suitable instruction-processing CPU, microprocessor, FPGA, or other hardware. Alternative embodiments are contemplated, however, and are within the spirit and scope of the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5671362 | Cowe et al. | Sep 1997 | A |
| 6011967 | Wieck | Jan 2000 | A |
| 6281799 | Lake et al. | Aug 2001 | B1 |
| 6291568 | Lussey | Sep 2001 | B1 |
| 6313748 | Lake | Nov 2001 | B1 |
| 6415544 | Leyerle et al. | Jul 2002 | B1 |
| 6445301 | Farrell et al. | Sep 2002 | B1 |
| 6508031 | Johnson et al. | Jan 2003 | B1 |
| 6574912 | Johnson | Jun 2003 | B1 |
| 6631258 | Chow | Oct 2003 | B1 |
| 6792395 | Roberts | Sep 2004 | B2 |
| 6864789 | Wolfe | Mar 2005 | B2 |
| 6914529 | Barber et al. | Jul 2005 | B2 |
| 6937156 | Gardner, Jr. et al. | Aug 2005 | B2 |
| 7002481 | Crane et al. | Feb 2006 | B1 |
| 7026942 | Cristofori et al. | Apr 2006 | B2 |
| 7076211 | Donner et al. | Jul 2006 | B2 |
| 7212129 | Barber et al. | May 2007 | B2 |
| 7233781 | Hunter et al. | Jun 2007 | B2 |
| 7260378 | Holland | Aug 2007 | B2 |
| 7262702 | Barber et al. | Aug 2007 | B2 |
| 7313476 | Nichols | Dec 2007 | B2 |
| 7342504 | Crane et al. | Mar 2008 | B2 |
| 7375629 | Moyer | May 2008 | B1 |
| 7412225 | Islam | Aug 2008 | B2 |
| 7453355 | Bergstrom | Nov 2008 | B2 |
| 7616942 | Karl | Nov 2009 | B2 |
| 7626508 | Kosuge et al. | Dec 2009 | B2 |
| 7656300 | Rønnau | Feb 2010 | B2 |
| 7715887 | Cloutier et al. | May 2010 | B2 |
| 7768413 | Kosuge et al. | Aug 2010 | B2 |
| 7952485 | Schechter et al. | May 2011 | B2 |
| 7983654 | Shelton | Jul 2011 | B2 |
| 8044796 | Carr, Sr. | Oct 2011 | B1 |
| 8378789 | Moore | Feb 2013 | B2 |
| 8412147 | Hunter et al. | Apr 2013 | B2 |
| 8515386 | Hasenfang | Aug 2013 | B2 |
| 8520589 | Bhatt et al. | Aug 2013 | B2 |
| 8521192 | Ahlgren | Aug 2013 | B2 |
| 8599010 | Bose et al. | Dec 2013 | B2 |
| 8646204 | Chiu | Feb 2014 | B2 |
| 8676377 | Siegel et al. | Mar 2014 | B2 |
| 8711785 | Gholmieh | Apr 2014 | B2 |
| 8797168 | Tolley et al. | Aug 2014 | B2 |
| 8830071 | Borth et al. | Sep 2014 | B2 |
| 9015987 | Moran et al. | Apr 2015 | B2 |
| 9026147 | Galvin et al. | May 2015 | B2 |
| 9070268 | Monacos et al. | Jun 2015 | B2 |
| 9159211 | O'Brien et al. | Oct 2015 | B2 |
| 9188679 | Hamada | Nov 2015 | B2 |
| 9196148 | Hutz | Nov 2015 | B1 |
| 9226481 | Paripati | Jan 2016 | B1 |
| 9265001 | Tannenbaum et al. | Feb 2016 | B1 |
| 9341014 | Oshima et al. | May 2016 | B2 |
| 9380775 | Frojmovics | Jul 2016 | B2 |
| 9439412 | Kittelson | Sep 2016 | B2 |
| 9439995 | Conroy et al. | Sep 2016 | B2 |
| 9442594 | Graham et al. | Sep 2016 | B2 |
| 9460448 | Felgate | Oct 2016 | B2 |
| 9510582 | David et al. | Dec 2016 | B2 |
| 9534958 | Lhamon et al. | Jan 2017 | B1 |
| 9542835 | Borth et al. | Jan 2017 | B2 |
| 9547973 | Hutz | Jan 2017 | B1 |
| 9613521 | Hunter et al. | Apr 2017 | B2 |
| 9652975 | Riley | May 2017 | B1 |
| 9674652 | Ranki | Jun 2017 | B2 |
| 9740921 | McClure et al. | Aug 2017 | B2 |
| 9750239 | Vilinskis et al. | Sep 2017 | B2 |
| 9767230 | Kimchi et al. | Sep 2017 | B2 |
| 9786153 | London | Oct 2017 | B2 |
| 9799207 | Tavares | Oct 2017 | B1 |
| 9911095 | Mashburn et al. | Mar 2018 | B2 |
| 9986313 | Schwarzkopf et al. | May 2018 | B2 |
| 10026300 | Hutz | Jul 2018 | B1 |
| 10049341 | Jones et al. | Aug 2018 | B2 |
| 10079903 | Cunico et al. | Sep 2018 | B1 |
| 10085438 | Dismang | Oct 2018 | B1 |
| 10111079 | Baldree | Oct 2018 | B2 |
| 10111416 | Rich et al. | Oct 2018 | B2 |
| 10127797 | Probin | Nov 2018 | B2 |
| 10152035 | Reid et al. | Dec 2018 | B2 |
| 10157372 | Brailovskiy et al. | Dec 2018 | B2 |
| 10169587 | Nix | Jan 2019 | B1 |
| 10192194 | Bernhardt et al. | Jan 2019 | B2 |
| 10325241 | Haimi | Jun 2019 | B2 |
| 10489743 | Aepli | Nov 2019 | B2 |
| 20010033230 | Barber et al. | Oct 2001 | A1 |
| 20030058097 | Saltzstein et al. | Mar 2003 | A1 |
| 20030213161 | Gardner et al. | Nov 2003 | A1 |
| 20040090329 | Hitt | May 2004 | A1 |
| 20040100394 | Hitt | May 2004 | A1 |
| 20040203879 | Gardner | Oct 2004 | A1 |
| 20050014482 | Holland | Jan 2005 | A1 |
| 20050151653 | Chan et al. | Jul 2005 | A1 |
| 20050162279 | Marshall et al. | Jul 2005 | A1 |
| 20060240853 | Donner et al. | Oct 2006 | A1 |
| 20070030156 | Schlager et al. | Feb 2007 | A1 |
| 20070032830 | Bowers | Feb 2007 | A1 |
| 20070254626 | Ahlgren | Nov 2007 | A1 |
| 20080055094 | Barber et al. | Mar 2008 | A1 |
| 20080204253 | Cottee et al. | Aug 2008 | A1 |
| 20080210153 | Alvarado | Sep 2008 | A1 |
| 20080234592 | Lim | Sep 2008 | A1 |
| 20080258910 | Stapleford | Oct 2008 | A1 |
| 20090189807 | Scalisi | Jul 2009 | A1 |
| 20090260276 | Kirsch et al. | Oct 2009 | A1 |
| 20090315767 | Scalisi | Dec 2009 | A1 |
| 20100134301 | Borth et al. | Jun 2010 | A1 |
| 20100148956 | Song et al. | Jun 2010 | A1 |
| 20100176954 | Alvarado | Jul 2010 | A1 |
| 20100283610 | Wetzel et al. | Nov 2010 | A1 |
| 20110102257 | Spyropoulos | May 2011 | A1 |
| 20110109460 | Lloyd et al. | May 2011 | A1 |
| 20110230160 | Felgate | Sep 2011 | A1 |
| 20110242043 | Yarvis et al. | Oct 2011 | A1 |
| 20110312286 | Lin et al. | Dec 2011 | A1 |
| 20120149312 | Velusamy | Jun 2012 | A1 |
| 20120235860 | Ghazarian | Sep 2012 | A1 |
| 20120245969 | Campbell | Sep 2012 | A1 |
| 20130162443 | Oppenheimer et al. | Jun 2013 | A1 |
| 20130208575 | Sammut | Aug 2013 | A1 |
| 20140071276 | Seifer et al. | Mar 2014 | A1 |
| 20140085084 | Ghazarian | Mar 2014 | A1 |
| 20140085100 | Rich et al. | Mar 2014 | A1 |
| 20140087762 | Galvin et al. | Mar 2014 | A1 |
| 20140106677 | Altman | Apr 2014 | A1 |
| 20140118135 | O'Brien et al. | May 2014 | A1 |
| 20140253377 | Scalisi | Sep 2014 | A1 |
| 20140323079 | Paolini | Oct 2014 | A1 |
| 20150065167 | Scalisi | Mar 2015 | A1 |
| 20150120083 | Gurovich | Apr 2015 | A1 |
| 20150215732 | Ranki | Jul 2015 | A1 |
| 20150290392 | Henderson | Oct 2015 | A1 |
| 20150351336 | Gilbert et al. | Dec 2015 | A1 |
| 20160018800 | Gettings | Jan 2016 | A1 |
| 20160048798 | Meyer et al. | Feb 2016 | A1 |
| 20160086475 | Rich et al. | Mar 2016 | A1 |
| 20160192865 | Datta et al. | Jul 2016 | A1 |
| 20160202078 | Scalisi | Jul 2016 | A1 |
| 20160240074 | Probin et al. | Aug 2016 | A1 |
| 20160269533 | Taylor et al. | Sep 2016 | A1 |
| 20160371952 | Felgate | Dec 2016 | A1 |
| 20160379176 | Brailovskiy et al. | Dec 2016 | A1 |
| 20170035042 | Ben-Dashan et al. | Feb 2017 | A1 |
| 20170111128 | Hammerschmidt et al. | Apr 2017 | A1 |
| 20170112116 | Ji et al. | Apr 2017 | A1 |
| 20170140632 | Klein et al. | May 2017 | A1 |
| 20170208426 | Komoni et al. | Jul 2017 | A1 |
| 20170215381 | Shen et al. | Aug 2017 | A1 |
| 20170231214 | Vaisblat et al. | Aug 2017 | A1 |
| 20170231215 | Barton | Aug 2017 | A1 |
| 20170318796 | Vaisblat et al. | Nov 2017 | A1 |
| 20170360026 | Zirkle et al. | Dec 2017 | A1 |
| 20170374437 | Schwarzkopf et al. | Dec 2017 | A1 |
| 20180006719 | Cress et al. | Jan 2018 | A1 |
| 20180033289 | Lee | Feb 2018 | A1 |
| 20180075596 | Fryshman | Mar 2018 | A1 |
| 20180096581 | Daly, Jr. | Apr 2018 | A1 |
| 20180190084 | Mandlakazi | Jul 2018 | A1 |
| 20180199172 | Boily et al. | Jul 2018 | A1 |
| 20180199306 | Edge | Jul 2018 | A1 |
| 20180199565 | Zosimadis | Jul 2018 | A1 |
| 20180217228 | Edge | Aug 2018 | A1 |
| 20180249696 | Daly, Jr. et al. | Sep 2018 | A1 |
| 20180254905 | Chun | Sep 2018 | A1 |
| 20180279603 | Madl et al. | Oct 2018 | A1 |
| 20180295831 | Reid et al. | Oct 2018 | A1 |
| 20180299842 | Reid et al. | Oct 2018 | A1 |
| 20180301918 | Lupo | Oct 2018 | A1 |
| 20180322454 | Komoni | Nov 2018 | A1 |
| 20180338681 | Scherer et al. | Nov 2018 | A1 |
| 20180350227 | Komoni | Dec 2018 | A1 |
| 20190037829 | Laut et al. | Feb 2019 | A1 |
| 20190078930 | Ravulapati | Mar 2019 | A1 |
| 20190096058 | Fryshman | Mar 2019 | A1 |
| 20190111272 | Hochhalter | Apr 2019 | A1 |
| 20190121302 | Reid et al. | Apr 2019 | A1 |
| 20190141295 | Lazar | May 2019 | A1 |
| 20190197864 | Hui | Jun 2019 | A1 |
| 20190200597 | Borth et al. | Jul 2019 | A1 |
| 20190230148 | Borlik | Jul 2019 | A1 |
| 20190385438 | Cholhan | Dec 2019 | A1 |
| 20200005626 | Triventi et al. | Jan 2020 | A1 |
| 20200029550 | Koziar et al. | Jan 2020 | A1 |
| 20200045932 | Knight et al. | Feb 2020 | A1 |
| 20200134812 | Fryshman | Apr 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2619212 | Sep 2008 | CA |
| 2814940 | Apr 2012 | CA |
| 2920216 | Aug 2016 | CA |
| 102413553 | Apr 2012 | CN |
| 102457932 | May 2012 | CN |
| 203799486 | Aug 2014 | CN |
| 105894760 | Aug 2016 | CN |
| 3059719 | Aug 2016 | EP |
| 3013141 | Sep 2019 | EP |
| 2691531 | Nov 2018 | ES |
| 179998 | May 2018 | RU |
| 0226033 | Apr 2002 | WO |
| 2002100170 | Oct 2003 | WO |
| 2007094974 | Aug 2007 | WO |
| 2008064033 | May 2008 | WO |
| 2010030346 | Mar 2010 | WO |
| 2017004701 | Jan 2017 | WO |
| 2017011916 | Jan 2017 | WO |
| 2017171281 | Oct 2017 | WO |
| 2018145880 | Aug 2018 | WO |
| 2019157536 | Aug 2019 | WO |
| 2019168855 | Sep 2019 | WO |
| Entry |
|---|
| Lloret et al., “A Wireless Sensor Network Deployment for Rural and Forest Fire Detection and Verification”, Sensors 2009, Oct. 30, 2009, pp. 8722-8747, vol. 9, MDPI AG, Basel, Switzerland. |
| Mekki et al., “A comparative study of LPWAN technologies for large-scale IoT deployment”, ICT Express, Mar. 2019, pp. 1-7, vol. 5, Issue 1, Korean Institute of Communications and Information Sciences (KICS), production and hosting by Elsevier B.V., https://www.sciencedirect.com/science/article/pii/S2405959517302953?via%3Dihub. |
| Petric et al., “Measurements, Performance and Analysis of LoRa FABIAN, a real-world implementation of LPWAn”, Personal, Indoor, and Mobile Radio Communications (PIMRC), 2016 IEEE 27th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications, Sep. 2016, Valencia, Spain. , https://hal-imt.archives-ouvertes.fr/hal-01331966. |
| Son et al., “A Design and Implementation of Forest-Fires Surveillance System based on Wireless Sensor Networks for South Korea Mountains”, International Journal of Computer Science and Network Security, Sep. 2006, pp. 124-130, vol. 6 No. 9B, IJCSNS.org, Seoul, Korea. |
| Tim Urban, Everything You Should Know About Sound, Wait But Why, Mar. 9, 2019, https://waitbutwhy.com/2016/03/sound.html. |
| Yousef et al. “A low-cost LoRaWAN testbed for IoT: Implementation and measurements.” Internet of Things (WF-IoT), 2018 IEEE 4th World Forum on. IEEE, 2018. |
| Number | Date | Country | |
|---|---|---|---|
| 62716899 | Aug 2018 | US | |
| 62716896 | Aug 2018 | US | |
| 62716901 | Aug 2018 | US | |
| 62841452 | May 2019 | US | |
| 62582508 | Nov 2017 | US | |
| 62752284 | Oct 2018 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16183732 | Nov 2018 | US |
| Child | 16537522 | US |
