Patent Publication Number: US-9906930-B2

Title: System and method for mobile personal emergency response

Description:
BACKGROUND 
     1. Technical Field 
     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. 
     2. Background 
     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. 
     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. 
     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. 
     SUMMARY 
     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. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The system may be better understood with reference to the following drawings and the description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles disclosed. Moreover, in the figures, like-referenced numerals designate corresponding parts throughout the different views. 
         FIG. 1  is a block diagram of an exemplary system for mobile personal emergency response according to one embodiment. 
         FIG. 2  is an illustration of a fob according to one embodiment. 
         FIG. 3  is a detailed block diagram of the system for mobile personal emergency response of  FIG. 1 . 
         FIG. 4  is a flowchart illustrating an exemplary operational alert and response process of the system for mobile personal emergency response according to one embodiment. 
         FIG. 5  is a flowchart illustrating an exemplary subscription process of the system for mobile personal emergency response according to one embodiment. 
         FIG. 6  shows various data fields used to populate user account and user subscription data structures according to one embodiment. 
         FIG. 7  illustrates a screen image of the user profile and location data received by the dispatch center according to one embodiment. 
         FIG. 8  is a block diagram of an exemplary computer system or server, such as the backend server or other computer system, according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     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&#39;s location even if the caller is impaired or is not aware of his or her physical location at the time of the call. 
       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&#39;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. 
     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  124   a . 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&#39;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 . 
     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. 
     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 . 
     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. 
     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 . 
       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. 
     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&#39;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 . 
     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 . 
     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 . 
     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. 
     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. 
       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 ). 
     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&#39;s mobile device ( 422 ). The user&#39;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 ). 
     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 ). 
     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 ). 
     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. 
     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. 
       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&#39;s mobile telephone number ( 510 ). If the user&#39;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 ). 
     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 ). 
     If the user&#39;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&#39;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 ). 
       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. 
       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. 
     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 . 
     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&#39;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. 
     In some embodiments, once an alert is received, the audio and video capabilities of the user&#39;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. 
       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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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.