System and method for mobile personal emergency response

[0001] 1. Technical Field

[0002] The present disclosure relates to a system and method for providing an emergency response. In particular, this disclosure relates to a system and method for permitting a user to activate an emergency application in a mobile device so as to provide user data and location data to a dispatch center.

[0003] 2. Background

[0004] Most, if not all locations in the United States are serviced by a corresponding 911 call center. The 911 call center maybe accessed via a land line or a mobile telephone. Typical 911 call centers are effective when responding to emergency calls received from land lines (PSTS—public service telephone system). The telephone number is easily obtained based on the caller-ID system, and the physical address of the owner of that landline is quickly determined based on ownership records.

[0005] However, the location process is much more time-consuming if the emergency call is received from a mobile telephone. Typical 911 call centers or answering points do not have the ability to directly receive or otherwise determine the GPS location coordinates from a mobile device. For rapid determination of location using a mobile device, the person in contact with the 911 call center must verbally provide his or her location, typically using street address.

[0006] If a 911 call center receives an emergency call from a mobile telephone and the caller does not know his or her location, or for example cannot speak, about 30 minutes may lapse before the 911 center is able to determine an accurate location of the user based on cell tower data and other information obtained in conjunction with the cellular carrier. Although per FCC regulations, the 911 center is required to be able to determine the telephone number of the mobile caller, and obtain a coarse location to within 300 meters in a six minute period of time, such a coarse location will no doubt make it difficult to for the authorities to find the caller and timely provide aid or assistance. Further, a person using a mobile phone in an emergency situation may not be able to dial the three digits for a variety of reasons, such as visual impairment, psychological or emotional stress, and the like.

[0007] A mobile personal emergency response system includes a security fob configured to be manually activated, and wirelessly transmit an emergency alert signal when activated. A mobile device contains an emergency application, which is responsive to the emergency alert signal. Upon receipt of the emergency alert signal, the emergency application obtains user profile data corresponding to the mobile device, obtains GPS location coordinates of the mobile device, and wirelessly transmits the user profile data and GPS location coordinates to a dispatch center. A location database is accessed by the dispatch center and provides an identity of a selected public service answering point corresponding to the received GPS location coordinates. A dispatcher of the dispatch center contacts the selected public service answering point and provides the user profile data and a location of the mobile device.

[0017] It is desirable to provide a system the method that permits a user in an emergency situation to quickly and easily contact a 911 call center and be able to provide the 911 call center with personnel with data about the caller and the caller's location even if the caller is impaired or is not aware of his or her physical location at the time of the call.

[0018] FIG. 1 illustrates a block diagram for a system for mobile personal emergency response 100, while FIG. 2 shows a remote activation device, such as fob 104. As an overview, a user 108 has ready access to the fob 104, which may be conveniently attached to a key chain. When the user 108 activates the fob 104, where such activation is defined as a user event 112, the fob 104 transmits an emergency alert signal 114, preferably using BLUETOOTH protocol. The emergency alert signal 114 is received by the user's mobile device 116, such as a smartphone. The smartphone may support any standard operating system, such as Android, IOS, Windows, and the like. The smartphone preferably includes a GPS subsystem and supports downloadable and/or native application processing.

[0019] The mobile device 116 has been previously downloaded with an emergency application 120, and is responsive to the emergency alert signal 114, and becomes activated. When activated, the mobile device 116 obtains certain user profile data, and the GPS location coordinates of the mobile device 116, and transmits the user data and coordinates to a selected dispatch center 124 of a group of one or more dispatch centers 124a. The dispatch center 124 is coupled to a backend server 128, which preferably is remotely located relative to the dispatch center 124, or alternatively may be located within the dispatch center 124. Based on the received GPS location coordinates, the dispatch center 124 may access a location database 132, such as a 911 location database, to obtain an identity of a selected public service answering point (PSAP) 136, such as a 911 PSAP, corresponding to the received GPS location coordinates. This insures that the PSAP 136 closest to the location of user 108, meaning the location of the user's mobile device 116, is identified. In one embodiment, a computer aided dispatch system (CADS) 140 may access the 911 location database 132 to selected the appropriate 911 PSAP 136. The dispatch center 124 is preferable is supervised or staffed by one or more human operators or dispatchers 144.

[0020] The CADS 140 may be part of the backend server 128, or may be separate and remote from the backend server 128. Preferably, the backend server 128 and the CADS 140 are cloud-based systems remotely located from the dispatch center 124, but alternatively, in some embodiments, may be physically located in the dispatch center 124. The backend server 128 and/or associated memory storage may be leased from or operated by an external provider, such as Microsoft, Google, or Amazon.

[0021] Once the appropriate 911 PSAP 136 has been identified, the dispatcher 144 or operator physically located in the dispatch center 124 then contacts that selected 911 PSAP 136 and provides personnel at the 911 PSAP (the 911 dispatcher) with the user profile data and a location of the user 108. The 911 PSAP 136 is staffed with members of the 911 system. The 911 dispatcher 144 at the 911 PSAP 136 then contacts the local police or other municipal authority 146 and provides the corresponding information so that such local authorities may render assistance to the user 108.

[0022] Turning now to FIG. 2, the fob 104 may be formed of plastic or other suitable material, and includes an activation button 204 and a protective cover 208 to prevent inadvertent depression of the button when closed. Preferably, the fob 104 wirelessly communicates with the mobile device 116 using BLUETOOTH protocol, however, any suitable wireless protocol maybe it used. When the user 108 activates the fob 104, and the user profile data and GPS location coordinates are sent by the emergency application 120 and are received by the dispatch center 124, the emergency application 120 causes either the fob 104 and/or the mobile device 116 itself to briefly vibrate to provide feedback to notify that user 108 that the emergency signal has been processed and help will be on the way. Receipt of the emergency signal by the mobile device 116 essentially “wakes-up” the emergency application 120 even if the emergency application 120 is not executing in the background.

[0023] An LED indicator 212 on the fob 104 may also be illuminated. The LED indicator may provide multiple indications based on color. For example, one color may indicate a low battery condition of the fob 104, and another color may indicate that the fob 104 has moved out of range from the mobile device 116 such that it has become “unpaired” with the mobile device 116. Yet another color may indicate that the fob 104 has moved back into proximity with the mobile device 116 and has again become paired with the mobile device 116. Preferably, the fob 104 is paired with one mobile device 116.

[0024] FIG. 3 is a detailed block diagram of the system for the mobile personal emergency response 100. The system includes a hosted website component 304, an analytics component 308, a subscription hosting component 312, the backend server 128, the dispatch center 124, and the mobile device 116. The hosted website provides the interactive webpages 320 and links that permits users to obtain the services of the system for mobile personal emergency response 100. Users may order a paid subscription (monitoring) service via the website component 304, and may order the fob 104 for delivery to the user 108 via an ordering component 324. The user 108 may also handle all aspects of his or her account management through an account management component 328 accessible via the website component 304. A help and support component 332 also provides the user 108 with the ability to obtain answers to questions and interact with customer support.

[0025] The user 108 may use the hosted website component 304 to enter user profile data into the system. Alternatively, the user 108 may enter such data using the mobile device 116. The user profile data may include the information that is typically contained in the user's drivers license, such as a photograph of the user, name, address, height, weight, gender, hair color, eye color, ethnicity, optional medical contact phone number, optional medical condition alerts, and the like. Preferably, the user profile data is stored in the backend server 128. Alternatively, the user profile data may also be stored in mobile device 116.

[0026] Regardless of where such data is stored, the data entry and formatting for storage of such data may be provided by an application referred to as Parse 342, which provides a simple and easy to use interface. Parse 342 is a commercially available application that may be executed by the backend server 128, or a portion thereof may be executed by the mobile device 116. The Parse application 342 is commercially available for a fee at https://parse.com. The Parse application 342 on the mobile device 116 may connect to and communicate with the corresponding Parse application 342 running on the backend server 128. The Parse application 342 provides database management, data storage management, and communication between the mobile device 116 and the backend server 128.

[0027] In one embodiment, the subscription hosting component 312 may be separate and apart from the hosted website component 304, and is preferably cloud-based. The subscription hosting component 312 may be operated by a separate entity that specializes in account management processes and the handling of automated and reoccurring billing and collection of subscriber fees through credit card. The subscription hosting component 312 may further provide a billing component 350 and an account component 354.

[0028] In one embodiment, the subscription hosting component 312 may be provided by “Chargify,” which may provide remote hosting, and is commercially available for a fee at www.Chargify.com. The subscription hosting component 312 may also provide user account management component to permit the user 108 to create, update, and modify billing information, and personal information, such as the user profile data. In turn, the subscription hosting component 312 may store all such information in the backend server 128 for each user 108 via the Parser application. Various processors and computer systems may execute software to power the hosted website component 304, the subscription hosting component 312, and the backend server 128. Alternatively, in one embodiment, the subscription hosting component 312, and hosted website component 304 maybe consolidated and incorporated into the backend server 128 for centralized management.

[0029] The analytics component 308 may be incorporated into the hosted website component 304 or may be separate and apart therefrom. The analytics component 308 may use commercially available applications, such as SharePoint or Office 365 available from Microsoft Corporation. Such applications permit the owner or operator of the system for mobile personal emergency response 100 to evaluate performance and profitability of the system. Such applications as an operations tool for the developer, and provide project management for developing and improving the system.

[0030] FIG. 4 is a flowchart illustrating an exemplary operational process 400 of the system for mobile personal emergency response 100 according to one embodiment. After the emergency application 120 is activated by the fob (402), the emergency application 120 (even if screen is locked (404)) transmits the GPS location coordinates to the dispatch center (408). This includes latitude, longitude, and altitude (412). Additionally, a dispatchable address is transmitted. Because the dispatch center 124 is in communication with the backend server 128 and the CADS 140, the CADS 140 automatically provides a dispatchable address corresponding to the GPS location coordinates. The emergency application 120 then preferably obtains the user profile data either from the backend server 128 or alternatively, from local storage in the mobile device 116, and transmits the user profile data to the dispatch center (416).

[0031] Receipt of the user profile data and GPS location data constitutes a received alert (420). There may be more than one alert received or processed by the dispatch center 124 at one time. The received alert maybe prioritized based on various factors, such as user identity, location, and the like. The dispatcher 144 at the dispatch center 124 then selects the highest priority alert and calls the user's mobile device (422). The user's telephone number is then dialed automatically (426). If the user 108 does not answer (428), a true emergency is presumed, and the dispatcher 144 alerts the closest 911 PSAP 136. The system preferably auto-dials the PSAP. The user profile data and location data is provided to the personnel at the 911 PSAP 136 (432). The dispatcher 144 of the dispatch center 124 may provide the 911 public service answering point personnel with a physical location of the user, a physical address of the user, or the GPS location coordinates corresponding to the user (436). The call is then ended or handed off to the 911 PSAP personnel (438).

[0032] If the user 108 does answer the call from the dispatcher 144 in the dispatch center (440), the dispatcher 144 determines if the user 108 requires police or ambulance assistance (442). If the response is yes (444), the dispatcher 144 alerts the closest 911 PSAP 136 and provides the user profile data and location data to the personnel at the 911 PSAP 136. The dispatcher 144 of the dispatch center 124 may provide the 911 public service answering point personnel with a physical location of the user 108, a physical address of the user 108, or the GPS location coordinates corresponding to the user (448), as described above. The call is then ended or handed off to the 911 PSAP personnel (450).

[0033] If the user 108 indicates to the dispatcher 144 that he or she does not require police or ambulance assistance (442), the dispatcher 144 then verifies whether the user 108 is under duress and requests a password from the user (454). If the password is correct (458), the dispatcher 144 assumes a false alarm condition and this disables the alarm (460), and the call is ended. If the password given is incorrect (464), it is assumed that the user 108 is under duress, and the dispatcher 144 alerts the closest 911 PSAP 136 (466). The system preferably auto-dials the PSAP. The user profile data and location data are provided to the personnel at the 911 PSAP 136 (468). The call is then ended or handed off to the 911 PSAP personnel (470).

[0034] If the user 108 indicates to the dispatcher 144 that he or she does not require police or ambulance assistance (442), the user 108 may alternatively indicate that he or she is in a cautionary or possibly dangerous situation and feels uneasy (472), but does not yet want to involve the police. In such a situation, the dispatcher 144 will remain in verbal communication with the user (474). If the cautionary situation abates (476), the dispatcher 144 verifies the user password (478), and performs the process described above with respect to receiving either a correct password (480, 481) or an incorrect password (482), in which case, the system preferably auto-dials the PSAP.

[0035] If the cautionary situation does not abate (484), the situation may evolve into a true alert situation. In this case, dispatcher 144 alerts the closest 911 PSAP 136 (486). The system preferably auto-dials the PSAP. The user profile data and location data are provided to the personnel at the 911 PSAP (488), and the process described above with respect to contact with the 911 PSAP personnel is performed.

[0036] FIG. 5 is a flowchart illustrating an exemplary subscription process 500 of the system for mobile personal emergency response 100 according to one embodiment. The user 108 first purchases a subscription (502) and downloads the emergency application 120 to his or her mobile device (506), which requests authorization from the user 108 to validate the user's mobile telephone number (510). If the user's mobile telephone number does not match the existing account (514), either a new account is activated (518) or the user 108 indicate that the user 108 received a new mobile telephone number (522). If a new activation is selected (518), the user enters the new mobile telephone number (526), which is in synchronized with the backend server (530). The user profile and then created by entering the required data (534).

[0037] If the user 108 indicates that a new mobile telephone number exists (522), the user 108 is requested to enter the old telephone number (540), which is then verified (542). If the account corresponding to the old telephone number matches the existing account shown in the backend server (546), then the user profile associated with the old telephone number is restored (550), and the account is synchronized with the backend server (554).

[0038] If the user's old telephone number does not match an existing account (558), the user 108 is requested to either try again (560) or is given the option to call technical support (562). The user 108 is then returned to view the main menu (566). If the user's telephone number does match the existing account (570), the user data profile is restored (574), the data is synchronized with the backend server (578).

[0039] FIG. 6 shows various data fields used to populate user account and user subscription data structures. Preferably, the subscription hosting component 312 (the Chargify component) handles populating the data fields in the figures and saving such data to the backend server 128. The various data fields correspond to user account information, user notifications, user subscription plans, shipping information, program association, program identifiers, and account reoccurrence.

[0040] FIG. 7 is an illustrating screen image of the user profile data and location data received by the dispatch center 124. The image may contain a photograph of the user 702, name 704, closest known address 706, height 708, weight 710, gender 720, hair color 722, mobile telephone number 724. Also included is the location of the user, which may be in the form of GPS coordinates, such as longitude, latitude, and altitude 730. The location of the user 108 is also displayed on a street or local map 740, if available. Such a street map view may be generated using commercially available providers, such as GOOGLE Maps and the like.

[0041] In accordance with several embodiments described above, the dispatcher 144 at the dispatch center 124 verbally provides the user account profile data and dispatchable address to the 911 PSAP 136 because existing 911 PSAP centers are not equipped to receive digital data directly from an external source. However, it is anticipated that at some future date, 911 PSAP centers may be upgraded to be able to directly receive multimedia information and digital data from the dispatch center 124, such as the user profile data and the GPS location coordinates. When such an improved 911 system is available, the dispatcher 144 may be able to facilitate the direct transfer of the received user profile and GPS location coordinates to the selected 911 center. However, until such upgraded 911 centers exist, the dispatcher 144 preferably contacts the selected 911 center and verbally (or perhaps by email) provides the user profile data and the location of user 108.

[0042] In some embodiments, two or more dispatch centers may be provide, where the emergency application 120 may transmit the user profile data and GPS location coordinates corresponding to the respective mobile device, to a selected one of the two or more dispatch centers. Selection of the dispatch center may be based on geographical proximity to the user's mobile device or maybe based on available resources at a particular dispatch center. For example, if one dispatch center is handling a heavy call volume, the alert and data may be sent instead to an alternate dispatch center.

[0043] In some embodiments, once an alert is received, the audio and video capabilities of the user's mobile device may be activated. The audio and video captured maybe stored in the mobile device and/or maybe transmitted in real-time to the dispatch center 124. Further, the map location shown in FIG. 7 may be updated in real-time to show the changing position of the user 108, along with an updated dispatchable address or closest location indicator. Such updated information but also be forwarded to the selected 911 PSAP 136. Also note that the specific number of “911” may be any number that may be designated as part of emergency-type services.

[0044] FIG. 8 is a high-level hardware block diagram of one embodiment of a computer system hardware embodiment, which may be part of or incorporated into the backend server 128, and which may perform some or all of the functions of some of the components, modules, and/or subsystems described above. Such a computer system 800 may be embodied as a system cooperating with computer hardware components and/or as computer-implemented methods and is shown in FIG. 8 as a high-level hardware block diagram of a system computer 800 that may be used to execute software or logic to implement the processing of the components, modules, and/or subsystems described above.

[0045] The computer 800 may be a personal computer and may include various hardware components, such as RAM 814, ROM 816, hard disk storage 818, cache memory 820, database storage 822, and the like (also referred to as “memory subsystem 826”). The computer 800 may include any suitable processing device 828, such as a computer, microprocessor, RISC processor (reduced instruction set computer), CISC processor (complex instruction set computer), mainframe computer, work station, single-chip computer, distributed processor, server, controller, micro-controller, discrete logic computer, and the like, as is known in the art. For example, the processing device 828 may be an Intel Pentium® microprocessor, x86 compatible microprocessor, or equivalent device, and may be incorporated into a server, a personal computer, or any suitable computing platform.

[0046] The memory subsystem 826 may include any suitable storage components, such as RAM, EPROM (electrically programmable ROM), flash memory, dynamic memory, static memory, FIFO (first-in, first-out) memory, LIFO (last-in, first-out) memory, circular memory, semiconductor memory, bubble memory, buffer memory, disk memory, optical memory, cache memory, and the like. Any suitable form of memory may be used, whether fixed storage on a magnetic medium, storage in a semiconductor device, or remote storage accessible through a communication link. A user or system interface 830 may be coupled to the computer system 800 and may include various input devices 836, such as switches selectable by the system manager and/or a keyboard. The user interface also may include suitable output devices 840, such as an LCD display, a CRT, various LED indicators, a printer, and/or a speech output device, as is known in the art.

[0047] To facilitate communication between the computer 800 and external sources or other components, modules, and subsystems, a communication interface 842 may be operatively coupled to the computer system 800. The communication interface 842 may be, for example, a local area network, such as an Ethernet network, intranet, Internet, or other suitable network 844. The communication interface 842 may also be connected to a public switched telephone network (PSTN) 846 or POTS (plain old telephone system), which may facilitate communication via the Internet 844. Any suitable commercially-available communication device or network may be used.

[0048] The logic, circuitry, and processing described above may be encoded or stored in a machine-readable or computer-readable medium such as a compact disc read only memory (CDROM), magnetic or optical disk, flash memory, random access memory (RAM) or read only memory (ROM), erasable programmable read only memory (EPROM) or other machine-readable medium as, for examples, instructions for execution by a processor, controller, or other processing device.

[0049] The medium may be implemented as any device that contains, stores, communicates, propagates, or transports executable instructions for use by or in connection with an instruction executable system, apparatus, or device. Alternatively or additionally, the logic may be implemented as analog or digital logic using hardware, such as one or more integrated circuits, or one or more processors executing instructions; or in software in an application programming interface (API) or in a Dynamic Link Library (DLL), functions available in a shared memory or defined as local or remote procedure calls; or as a combination of hardware and software.

[0050] In other implementations, the logic may be represented in a signal or a propagated-signal medium. For example, the instructions that implement the logic of any given program may take the form of an electronic, magnetic, optical, electromagnetic, infrared, or other type of signal. The systems described above may receive such a signal at a communication interface, such as an optical fiber interface, antenna, or other analog or digital signal interface, recover the instructions from the signal, store them in a machine-readable memory, and/or execute them with a processor.

[0051] The systems may include additional or different logic and may be implemented in many different ways. A processor may be implemented as a controller, microprocessor, microcontroller, application specific integrated circuit (ASIC), discrete logic, or a combination of other types of circuits or logic. Similarly, memories may be DRAM, SRAM, Flash, or other types of memory. Parameters (e.g., conditions and thresholds) and other data structures may be separately stored and managed, may be incorporated into a single memory or database, or may be logically and physically organized in many different ways. Programs and instructions may be parts of a single program, separate programs, or distributed across several memories and processors.

[0052] While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.