US20120009894A1 - Collaborative incident alert system for mobile devices - Google Patents
Collaborative incident alert system for mobile devices Download PDFInfo
- Publication number
- US20120009894A1 US20120009894A1 US13/237,888 US201113237888A US2012009894A1 US 20120009894 A1 US20120009894 A1 US 20120009894A1 US 201113237888 A US201113237888 A US 201113237888A US 2012009894 A1 US2012009894 A1 US 2012009894A1
- Authority
- US
- United States
- Prior art keywords
- user
- incident
- reports
- database
- incidents
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 53
- 230000000737 periodic effect Effects 0.000 claims abstract description 5
- 230000004044 response Effects 0.000 claims description 10
- 230000002123 temporal effect Effects 0.000 claims 2
- 230000008569 process Effects 0.000 abstract description 32
- 238000004891 communication Methods 0.000 description 8
- 238000011156 evaluation Methods 0.000 description 8
- 238000004458 analytical method Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000036541 health Effects 0.000 description 3
- 208000010125 myocardial infarction Diseases 0.000 description 3
- 208000027418 Wounds and injury Diseases 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000006378 damage Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 208000014674 injury Diseases 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 206010039203 Road traffic accident Diseases 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000009429 distress Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 230000001755 vocal effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/029—Location-based management or tracking services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
Definitions
- This invention relates generally to a system for mobile phone users to collaboratively report and be alerted of emergencies or hazards and to have the opportunity to respond and assist when possible. More particularly, the invention relates to a collaborative system that allows users of Internet-enabled mobile phones equipped with global positioning technology to communicate with a server to report and receive emergency and hazard information. The system can also be configured to coordinate users to provide the fastest possible assistance in emergency situations.
- Mobile phones are becoming an integral part of every day life for most citizens in the US and other countries.
- Third Generation (3G) wireless technologies and competition are rapidly expanding the features and capabilities offered by these devices to include wireless Internet access, Global Positioning System (GPS), picture transmission and video transmission.
- GPS Global Positioning System
- Mobile phones can also provide a speed dial for emergency calls to 911.
- Current systems do not offer the capability for a plurality of users to collaborate to identify an emergency or hazard situation and to alert other users in the same geographic area to give them the opportunity to provide assistance for the emergency or to avoid the identified hazard.
- the present invention seeks to address the aforementioned limitations in the prior technology in addition to providing previously unavailable advantages and conveniences.
- An incident alert system enables a plurality of users to participate in a collaborative process whereby they can report, be alerted of, and respond to or avoid incidents such as emergencies or hazards.
- a user uses a networked mobile device with geo-positioning capability, such as a mobile phone, to communicate with a server to report incidents, such as emergencies or hazards, and to inquire about potential incidents of interest based on the user's current geographic position.
- the alert system significantly opens the opportunities for individuals to be Good Samaritans by informing others of hazards or by responding to urgent requests for assistance by others in need.
- Hazards are preferably any incident about which users might want to share information with other users.
- Hazards can include, for example, road conditions (such as ice, snow, police activity or traffic) or weather conditions (such as thunderstorms or tornadoes) that users may want to avoid.
- Emergencies are preferably incidents that involve a need of immediate assistance and can include, for example, health conditions (such as heart attacks or critical injuries) or crimes in progress (e.g. rape, abduction or robbery).
- An alert of an emergency that is sent to a user is preferably accompanied by a request for assistance. The user receiving the emergency alert can be given the opportunity respond to the system indicating that he will assist.
- a software program can display a selection menu in the mobile phone listing predefined types of incidents. A user's selection made from this menu is transmitted to the server accompanied by the current position of the user/mobile phone. The server then gathers reports of incidents sent by users of the system in a reports database.
- a user's mobile phone is preferably configured to automatically submit periodic inquiries to the server.
- the system queries the reports database to identify reports of potential interest to the inquiring user.
- a zone of interest can be specified for each user.
- the user's zone of interest can be expressed as a set of database query parameters defining which reports of emergencies or hazards may be of interest to the user. These parameters can be simple, such as a radius of 5 miles or a 10 minute drive from the current location of the user, or can involve complex conditions that need to be met. These parameters can also take into account what types of incidents the user wants to be informed of (e.g. inform of tornadoes but not thunderstorms).
- the system provides an interface, such as a web site, that allows each user to specify certain preferences based upon which the parameters of the user's zone of interest are determined.
- the system analyzes the reports received from the reports database to determine whether to alert the inquiring user of a potential incident of interest to the user.
- the analysis includes a comparison of the number of reports produced by the query to a threshold number of reports required in order to alert the user.
- the analysis of the reports can take into consideration, for example, the amount of time elapsed since each report and/or the distance between the reporting user and the inquiring user in determining whether to alert the inquiring user of the incident.
- the system maintains a database of individual incidents that have been identified.
- This incident database is preferably maintained in addition to or instead of the database of incident reports.
- the incidents recorded in the incident database are preferably indicative of actual or confirmed incidents as opposed to the reports in the reports database, which may not have been confirmed, and which may include multiple reports for any single incident.
- the incident database can be populated using many techniques. In one technique, a representative from a “911” emergency call center can enter a record of an incident into the incident database. A representative of a weather service can manually enter a record relating to a critical atmospheric event—such as a tornado or thunderstorm. In another technique, reports of incidents by users of the system can be analyzed and/or processed to identify individual incidents, which can then be entered into the incident database.
- This analysis or processing can be performed by human or automatically and it preferably takes into consideration whether two or more reports of an incident relate to the same actual incident.
- all reports of incidents of certain types e.g. rape, robbery, or tornado
- a time and geographic location are logged for each incident. Incidents in the incident database are preferably removed or closed after the passage of time or after the receipt of some indication that the incident has been resolved or no longer exists.
- the incident database can be queried using the user's zone of interest in the same manner as described above with respect to the reports database. Incidents that fall within the user's zone of interest (e.g. based on time and geographic location of the incident) are reported to the inquiring user. Certain types of incidents (e.g. hurricanes, thunderstorms, tsunamis) can be entered into the incident database to cover a geographic area, rather than just a point. To account for these cases, the database query can be configured to further identify incidents where the geographic coverage of the incident intersects with the geographic scope of the inquiring user's zone of interest.
- incidents that fall within the user's zone of interest e.g. based on time and geographic location of the incident
- Certain types of incidents e.g. hurricanes, thunderstorms, tsunamis
- the database query can be configured to further identify incidents where the geographic coverage of the incident intersects with the geographic scope of the inquiring user's zone of interest.
- the system keeps track of the latest transmitted position (and optionally a predicted current position) of a user based on one or more of the user's prior inquiries.
- This information can be stored in a user position database.
- the system can query the user position database to identify users who may want to be informed of this incident and/or who may be able to assist in an emergency. In this manner, in time-critical situations, the system can communicate a message (e.g. by text message or telephone call) to the mobile phone of a user in advance of the user's submitting an inquiry.
- FIG. 1 is an overview illustration of an alert system in accordance with in one embodiment of the invention.
- FIG. 2 shows a functional block diagram of one embodiment of the alert system.
- FIG. 3 illustrates one process by which an incident report can be handled by the system.
- FIG. 4 illustrates a process for responding to a user's inquiry about reports of incidents within the user's zone of interest.
- FIG. 5 illustrates a process for populating an incident database based on incident reports received from users.
- FIG. 6 illustrates a process for querying the incident database in response to a user inquiry.
- an alert system 102 includes a server 104 that receives reports 114 from and responds to inquiries 115 from a plurality of users' networked mobile phones 110 .
- the reports and inquiries preferably relate to incidents such as emergencies or hazards which may be of interest to users of the system.
- Incidents can be any situation or condition of which users of the system might want to be informed.
- Hazards can include, for example, road conditions (such as ice, snow, police activity or traffic) or weather conditions (such as thunderstorms or tornadoes) that users may want to avoid.
- Emergencies are preferably incidents that involve a need of immediate assistance and can include, for example, health conditions (such as heart attacks or critical injuries) or crimes in progress (e.g. rape, abduction or robbery).
- An incident could also be a general request for assistance by a user in distress (e.g. request for assistance due to an automobile breakdown).
- the mobile phones 110 preferably include geo-positioning capability such as GPS and connectivity to a communications network, such as the Internet via, for example, a wireless Internet communication link 112 .
- Geo-positioning capability can be provided in-part or wholly through a communications network that supports a mobile phone. For example, proximity to mobile phone towers based on signal strength, signal delay, and triangulation techniques can be used to locate a user. Indeed, any techniques, such as those proposed and implemented to comply with the U.S. Federal Communications Commission's e911 initiative, can be used for geo-location purposes in accordance with the present invention.
- a user uses his mobile phone 110 to transmit a report 114 of the incident, preferably accompanied by the current position of the user/mobile phone, to the server 104 through the communication link 112 .
- the server gathers reports of incidents sent by users of the system in a reports database as will be discussed below.
- a software program can display a selection menu on the mobile phone listing predefined types of incidents. A user's selection made from this menu is then transmitted to the server 104 .
- the predefined types of incidents can include, for example, various types of hazards, emergencies, or general (non-emergency) requests for assistance.
- Inquiries are preferably performed automatically by each user's activated mobile phone.
- the phone preferably sends periodic inquiries to the alert system 102 through the communication link 112 to find out if there is any incident which may be of interest to the user.
- the server 104 transmits incident alerts 116 to the mobile phones 110 of those users that may be interested in an incident through the communication link 112 .
- An alert transmitted by the server 104 preferably includes the nature or type of the incident and optionally its location.
- An alert of an emergency that is sent to a user can also be accompanied by a request that the receiving user assist in the emergency (e.g. as a Good Samaritan).
- the system Upon receipt of an inquiry from a user, the system queries a database to identify incidents (or incident reports) of potential interest to the inquiring user.
- a zone of interest is preferably specified for each user.
- a user's zone of interest is a zone within which reports or occurrences of incidents or hazards may be of interest to the user.
- a user's zone of interest can be expressed as a set of database query parameters defining which incidents may be of interest to the user and based upon which a database is queried for reports of potential interest to the user.
- a user's zone of interest can be a geographic area and time range referenced to the current geographic position of the user and the current time.
- the extent of the geographic area (or range) can be, for example, a circular area centered on the user's present location.
- the radius of the area can be expressed, for example, by a unit of length (e.g., within 5 kilometer) or by the time to cover the geographic distance (e.g. within 5 minutes drive).
- the extent of the time range can be, for example, a time segment starting a number of minutes prior to the current time (e.g. within the past 15 minutes) and extending to the present time.
- the number of minutes can be selected by the user or by the system, optionally based on user preferences.
- the geographic area and time ranges are combined in a database query to retrieve all reports falling within both the geographic area and time ranges.
- a zone of interest can be defined to include requirements in addition to or instead of geographic area and time.
- a zone of interest can be configured to include only reports of incidents of a certain type (e.g. traffic hazards). Further, it may be the case that a user doesn't want to be alerted of certain types of incidents or that the user is unable or unwilling to assist in certain types of emergencies. In these cases, the user's zone of interest for these types of incidents can be set to return a null set from a database query or to skip the database query altogether.
- a zone of interest may also be defined dynamically, on-the-fly, possibly based on contextual factors relating to the user's present environment. For example, a geographic area of a user's zone of interest can be adjusted dynamically to expand as the user moves from a more densely populated area to a less densely populated area.
- a zone of interest for a user traveling along a highway can be configured to include a narrow geographic band covering the highway ahead of the user.
- a zone of interest can be dynamically adjusted (e.g. by expanding or contracting time segment or geographic area) so that the zone would cover a relatively constant number of prior inquiries from other users. In this manner, the number of “eyes” watching for incidents of interest to a user is maintained at a relatively constant level within the user's zone of interest.
- a user and/or the system may define more than one zone of interest for each user where each zone of interest is associated with a different type of incident.
- a user may define a zone of interest for traffic conditions whereby the distance is 15 miles from the position of the inquiry and the time segment is the 30 minute segment preceding the time of inquiry.
- a user may also define a zone of interest for providing assistance in response to an emergency.
- a medical doctor may define a zone of interest for providing assistance in identified emergencies within a 10 minute drive from the doctor's current location.
- velocity and direction of travel of each reporting user can be stored in the reports and inquiries database 202 .
- a user's zone of interest can be further defined to include only reports received from users with a similar velocity and direction of travel. Additional analysis can be performed using map data to configure a zone of interest to include only reports from users traveling on the same road as the inquiring user. The zone of interest in this case can also be configured to include only reports received from users traveling in the same direction as the inquiring user.
- FIG. 2 shows a block diagram in accordance with one embodiment of the alert system 102 .
- the server 104 is configured to communicate with user mobile phones 110 and various other components of the system 102 and the server preferably executes the main processes of the system 102 .
- the system 102 preferably also includes a reports and inquiries database 202 configured to store reports of incidents as well as records of prior user inquiries.
- the system 102 can also include an incident database 204 configured to track individual incidents that have been identified.
- This incident database 204 is preferably maintained in addition to or instead of the reports database 202 .
- the incidents recorded in the incident database are preferably indicative of actual or confirmed incidents as opposed to the reports in the reports database, which may not have been confirmed, and which may include multiple reports for any single incident.
- the incident database can be populated using many automated and/or manual techniques. In one technique, a representative from a “911” emergency call center can enter a record of an incident into the incident database.
- a representative of a weather service can manually enter a record relating to a critical atmospheric event—such as a tornado or thunderstorm.
- reports of incidents by users of the system can be analyzed and/or processed to identify individual incidents, which can then be entered into the incident database.
- This analysis or processing can be performed by human or automatically and it preferably takes into consideration whether two or more reports of an incident relate to the same actual incident.
- all reports of incidents of certain types e.g. rape, robbery, tornado
- a time and geographic location are logged for each incident. Incidents in the incident database are preferably removed or closed after the passage of time or after the receipt of some indication that the incident has been resolved or no longer exists.
- the system 102 preferably includes a user profile database 206 configured to store user preferences.
- the alert system 102 preferably also hosts a web site 208 that allows users to set their preferences in the user profile database 206 .
- User preferences can include information upon which a user's zone of interest can be based, such as: a radius of distance from the user for identifying incidents of interest; a time window prior to a current time for identifying incidents of interest; a listing of incident types of interest; and a listing of incident types that are not of interest to the user. These preferences can be specified in detail for each of multiple types of incidents.
- the preferences can include the user's profession or area of expertise, which can enable the system to identify relevant users for responding to certain emergencies.
- a doctor or an emergency medical technician could be selected from available users to respond to a critical health condition.
- a user can express his area of expertise for assisting in an emergency implicitly by setting his preferences so that he is notified only of emergencies that are relevant to his area of expertise.
- the system and/or users preferably set zones of interest to include only emergency types for which users are willing and able to assist.
- the user profile database 206 is preferably configured to store an association between each user and his mobile device. Alternatively, the user profile database 206 can be configured to store preferences in association with individual mobile devices. As will be understood by one skilled in the art, for the purpose of this description, the concept of a user and of a user's mobile device can be used interchangeably.
- the system can also be configured to store a history of each user's location in a user position database 212 .
- This history can be used, for example, to predict a user's location between inquiries or to predict a user's velocity and direction of travel. A user's last location or a predicted location can be used in the case that an urgent request for assistance needs to be sent to users in a certain geographic area without having to wait for users' next inquiries.
- the position history can be stored in the user profile database 206 , in which case, the user profile database can serve a dual purpose as a position database.
- the system includes an incident evaluation module 210 configured to identify incidents and/or determine specific needs for assistance by users in response to reported emergencies or requests for assistance.
- the incident evaluation module populates and/or updates the incident database 210 with information about identified incidents.
- the incident evaluation module can execute an automated process that determines assistance needs, preferably by emergency type, or it can be a partly or wholly manual operation.
- the incident evaluation module 210 tracks which and/or how many users have responded to a request for assistance indicating that they will assist so that only a sufficient number of users actually respond to the emergency. Once a sufficient number of indications are received, the system can discontinue sending further emergency reports and/or requests for assistance.
- the incident evaluation module 210 compiles all reported information about each incident and attempts to determine what services and resources are needed to address it. As part of its function, the incident evaluation module 210 can analyze and identify the various independent reports the alert system 102 may receive about the same emergency or hazard. This analysis can rely upon the reported location of the incident, the time-stamp of the report, the type of emergency or hazard, and any additional information that might be provided by each reporting user, such as pictures and messages, to determine if any two reports relate to the same incident. Using this information, the incident evaluation module 210 preferably updates the incident database 204 to reflect the various incident reports submitted by different users as part of the same incident record. In addition, the incident evaluation module 210 can update current the state of resolution of each incident while actions are undertaken to address it.
- FIG. 3 illustrates one process 300 by which an incident report can be handled by the system 102 .
- the user transmits a report of an incident to the server 104 from a mobile phone 110 .
- the user identifies a type of incident to report from a menu of available types.
- a multilevel menu system can be used to guide the user to a selection which identifies the type of emergency or hazard the user needs to report.
- the available types of incidents can include, for example, general types such as: traffic hazard; weather condition; emergency; and request for assistance.
- the types can also include, for example, specific types such as: traffic accident; icy roads; tornado; thunderstorm; and heart attack.
- the user's mobile phone 110 adds the user's present geographic location to the report.
- a communications system that supports the mobile phone's connectivity can provide the geographic location.
- the alert system can support a voice report via the user's mobile phone.
- the alert system can prompt the user to verbally describe on the mobile phone the observed emergency or hazard.
- This verbal description can be translated into text by a speech recognition engine.
- a natural language understanding software program or alternatively a human operator, can interpret the text or voice message to identify the type of emergency or hazard.
- the server 104 receives the report of the incident and the user's location.
- the server 104 preferably determines additional contextual information related to the report and/or user, such as, for example: the time of the report, the user's direction/speed of travel, and the user's identity/user ID. In one embodiment, this additional contextual information can be determined and provided by the user and/or the user's mobile phone.
- the incident report and the contextual information are stored in the reports and inquiries database 202 .
- FIG. 4 illustrates a process 400 by which the system 102 can respond to a user's inquiry about reports of incidents within the user's zone of interest.
- the process 400 queries the reports and inquiries database 202 in response to the user's inquiry to retrieve reports of potential interest to the user.
- the reports are then analyzed to determine a score indicative of a likelihood of existence of an actual incident. If a score meets a certain threshold level, then the user can be notified of a possible or likely incident.
- the process 400 is performed repeatedly, on a periodic basis, such as every 15 seconds or every minute in response to repeated user inquiries.
- the frequency of repetition can remain constant, for example, based on a user preference/selection or based on system-optimized settings.
- the frequency of repetition can be dynamically varied, and preferably initiated by inquiries from the user's mobile phone, based on one or more factors, such as, for example, the velocity of the user or the frequency or density of inquiries by other users proximate the inquiring user.
- the alert system 102 receives a user's inquiry, which preferably includes the user's geographic location.
- the user's inquiry may also include additional parameters, such as, for example: user velocity and direction of travel. These additional parameters can alternatively be determined by the system, for example, by analyzing prior queries/reports from the user.
- the inquiry can consist only of a reporting of the user's position, which the system can treat as an implied inquiry.
- the user's inquiry is optionally logged into the reports and inquiries database 202 .
- Logging the inquiry into the reports and inquiries database 202 enables additional data about the user to be determined for future inquiries (e.g. velocity and direction of travel).
- logging user inquiries also enables the system to make subsequent determinations of overall user inquiry frequency and density based on the logs of multiple users' inquiries.
- the position of the user is also logged in the user position database 212 . This information can be useful to calculate the direction and speed of movement of the user and provides information based upon which the future location of the user can be predicted.
- the inquiring user's zone of interest is determined or identified, preferably in the form of query parameters that can be used to query the reports and inquiries database 202 .
- the user's zone of interest can be static or can be dynamically determined preferably based on parameters of the user's inquiry.
- the zone of interest can be based upon information provided by the user (which may be stored in the profiles database 206 ), information determined from the user's context (location, velocity, time), or other information.
- the user's zone of interest can be expanded or contracted in inverse proportion to the overall density or frequency of user queries proximate the user's location.
- the user's zone of interest can be dynamically adjusted so that it includes a relatively constant number of inquiries by other users. By adjusting the zone of interest in this manner, the number of other users from which reports are effectively monitored remains relatively constant.
- the reports and inquiries database 202 is queried, using the zone of interest parameters, to retrieve emergency and hazard reports and optionally any prior user inquiries within the user's zone of interest.
- the inquiring user's own reports and inquiries are excluded from the results of the query, so that the user's own reports do not factor into his own subsequent inquiries.
- the user's zone of interest can be generic to all types of incidents.
- the following step 405 is intended to handle an embodiment where one zone of interest is applied to all types of incidents and then the resulting reports are grouped by type and analyzed.
- the reports produced by the query are organized by type into separate groups.
- the groups correspond to the different types of reports supported by the selection menu from which users can select the desired type when reporting incidents. In this manner, separate types of reports can be analyzed separately.
- the remaining steps of this process, 406 through 409 are preferably executed for each separate group of reports.
- a user's zone of interest can be specified separately for each type of incident.
- the prior step 405 can be skipped, but the whole process 400 is preferably performed for each type of incident in response to each user inquiry.
- a score is computed based on the reports in the group, any associated contextual information provided by the user, and optionally on any prior user inquiries retrieved from the reports and inquiries database 202 .
- the score is preferably configured to be indicative of the likelihood that an actual incident of interest to the user has an active status. Many different calculations can yield such a score as illustrated in the following examples:
- the computation of the score can be based on individual characteristics of each report in the group. For example, the score can be based on the amount of time elapsed between the current time and the time of each report in the group. The score can also be based on the distance between the inquiring user and the reporting user for each report. In this manner, reports that occurred further in the past or farther away from the inquiring user can be given decreased weight or emphasis and reports occurring closer in time or distance can be given greater emphasis.
- One formula could include a factor in a denominator based on a sum of differences of distance and time.
- the computed score is analyzed to determine if it exceeds a threshold level. If the score exceeds the threshold, an incident alert is reported to the inquiring user at a step 408 .
- the threshold level can be selected or adjusted by the user (e.g. through the web site 208 or through the phone 110 ), by the system, or by a combination of both, preferably based on testing and/or experience for a particular implementation of the system. Different threshold levels can also be selected for each type of incident.
- the alert sent to the inquiring user preferably includes the type of incident that caused the alert.
- the alert can include the score itself or a value based on the score.
- the receiving user's mobile device is preferably configured to produce a perceptible signal (e.g. audible, visual, or vibration) in response to the alert to notify the user.
- the signal produced by the mobile phone can be varied based on the score, for example, so that higher scores produce more notable signals.
- step 407 If, at the step 407 , the score does not exceed the threshold, the process continues with step 409 , in which case the inquiry is ignored and/or no incident alert is reported to the inquiring user.
- FIG. 5 illustrates a process 500 for populating the incident database 204 based on incident reports received from users.
- the process 500 preferably follows step 303 of the process 300 and can be performed in addition to or instead of step 304 depending on whether an incident database 204 is used.
- the incident report is analyzed to determine whether it is a type of incident that is to be entered into the incident database 204 . In one embodiment, only emergencies or critical hazards are entered.
- the report is checked against existing incidents already in the incident database 204 to determine if the report relates to a previously identified incident. Whether a new report is for the same incident as a prior report can be based on factors such as proximity of location, proximity of time of report, and type of incident, for example. If the new report is a duplicate of an existing one, then the existing record in the database 204 can be updated. Otherwise, at a step 503 , a new record is created in the incident database for the reported incident.
- the system can query the user position database 212 to identify users who may want to be informed of the incident and/or who may be able to assist in an emergency at a step 504 .
- the system can communicate a message (e.g. by text message or telephone call) to the mobile phone of a user independently of the user submitting an inquiry.
- the system can identify an actual or estimated position of each identified user based on the user's position history in the user position database 212 .
- the system can also identify a geographic area associated with the incident so that any users whose estimated positions fall within the area are included in the query results.
- the zone of interest of each identified user is applied to the newly identified incident.
- the user can be alerted at a step 505 .
- the database query can be configured to identify incidents where the geographic coverage of the incident intersects with the geographic scope of the inquiring user's zone of interest.
- An alert of an emergency that is sent to a user can also be accompanied by a request that the receiving user assist in the emergency.
- the user receiving the emergency alert can be given the opportunity respond to the system indicating that he will assist.
- a user's preferences can be set to indicate that the user will only be willing to travel a certain distance to respond to an emergency.
- the user's zone of interest for a type of emergency can be configured to include only emergencies located within the specified distance of the user's actual or predicted location.
- FIG. 6 illustrates a process 600 for querying the incident database in response to a user inquiry.
- the process 600 preferably follows step 403 of the process 400 and can be performed in addition to or instead of steps 404 - 409 of the process 400 depending on whether an incident database 204 is used.
- the incident database is queried, at a step 601 , using the user's zone of interest in the same manner as described above with respect to the reports database in the process 400 .
- the system 102 identifies incidents that fall within the user's zone of interest (e.g. based on time and geographic location of the incident).
- the identified incidents are reported to the inquiring user.
- certain types of incidents can be entered into the incident database 204 to cover or define a geographic area (and/or a time period), rather than just a point.
- the database query can be configured to further identify incidents where the geographic coverage of the incident intersects with the geographic scope of the inquiring user's zone of interest.
Abstract
An incident alert system enables a plurality of users to participate in a collaborative process to report and be alerted of incidents such as emergencies or hazards. A user uses a networked mobile phone with geo-positioning capability to communicate with a server to report incidents and to inquire about potential incidents of interest based on the user's current geographic position. Reports of incidents are transmitted to the server accompanied by the current position of the user/mobile phone. A user's mobile phone is preferably configured to automatically submit periodic inquiries to the server based on the user's location. Upon receipt of an inquiry from a user, the system queries a database to identify reports of potential interest to the inquiring user. The system analyzes the reports to determine whether to alert the inquiring user of a potential incident of interest.
Description
- This application is a continuation of U.S. application Ser. No. 11/133,829, filed May 20, 2005, now U.S. Pat. No. 8,024,330, which claims the benefit of U.S. Provisional Application No. 60/573,398, filed on May 20, 2004, all of which are hereby incorporated by reference.
- This invention relates generally to a system for mobile phone users to collaboratively report and be alerted of emergencies or hazards and to have the opportunity to respond and assist when possible. More particularly, the invention relates to a collaborative system that allows users of Internet-enabled mobile phones equipped with global positioning technology to communicate with a server to report and receive emergency and hazard information. The system can also be configured to coordinate users to provide the fastest possible assistance in emergency situations.
- Mobile phones are becoming an integral part of every day life for most citizens in the US and other countries. At the same time, Third Generation (3G) wireless technologies and competition are rapidly expanding the features and capabilities offered by these devices to include wireless Internet access, Global Positioning System (GPS), picture transmission and video transmission. Mobile phones can also provide a speed dial for emergency calls to 911. Current systems, however, do not offer the capability for a plurality of users to collaborate to identify an emergency or hazard situation and to alert other users in the same geographic area to give them the opportunity to provide assistance for the emergency or to avoid the identified hazard.
- The present invention seeks to address the aforementioned limitations in the prior technology in addition to providing previously unavailable advantages and conveniences.
- An incident alert system enables a plurality of users to participate in a collaborative process whereby they can report, be alerted of, and respond to or avoid incidents such as emergencies or hazards. A user uses a networked mobile device with geo-positioning capability, such as a mobile phone, to communicate with a server to report incidents, such as emergencies or hazards, and to inquire about potential incidents of interest based on the user's current geographic position. By facilitating information sharing based on users' geographic locations, the alert system significantly opens the opportunities for individuals to be Good Samaritans by informing others of hazards or by responding to urgent requests for assistance by others in need.
- Hazards are preferably any incident about which users might want to share information with other users. Hazards can include, for example, road conditions (such as ice, snow, police activity or traffic) or weather conditions (such as thunderstorms or tornadoes) that users may want to avoid. Emergencies are preferably incidents that involve a need of immediate assistance and can include, for example, health conditions (such as heart attacks or critical injuries) or crimes in progress (e.g. rape, abduction or robbery). An alert of an emergency that is sent to a user is preferably accompanied by a request for assistance. The user receiving the emergency alert can be given the opportunity respond to the system indicating that he will assist.
- In order to report an incident, a software program can display a selection menu in the mobile phone listing predefined types of incidents. A user's selection made from this menu is transmitted to the server accompanied by the current position of the user/mobile phone. The server then gathers reports of incidents sent by users of the system in a reports database.
- A user's mobile phone is preferably configured to automatically submit periodic inquiries to the server. Upon receipt of an inquiry from a user, the system queries the reports database to identify reports of potential interest to the inquiring user. To provide criteria by which the server can query the database to identify reports of potential interest, a zone of interest can be specified for each user. The user's zone of interest can be expressed as a set of database query parameters defining which reports of emergencies or hazards may be of interest to the user. These parameters can be simple, such as a radius of 5 miles or a 10 minute drive from the current location of the user, or can involve complex conditions that need to be met. These parameters can also take into account what types of incidents the user wants to be informed of (e.g. inform of tornadoes but not thunderstorms). Preferably, the system provides an interface, such as a web site, that allows each user to specify certain preferences based upon which the parameters of the user's zone of interest are determined.
- The system analyzes the reports received from the reports database to determine whether to alert the inquiring user of a potential incident of interest to the user. In one embodiment, the analysis includes a comparison of the number of reports produced by the query to a threshold number of reports required in order to alert the user. In another embodiment, the analysis of the reports can take into consideration, for example, the amount of time elapsed since each report and/or the distance between the reporting user and the inquiring user in determining whether to alert the inquiring user of the incident.
- In one embodiment of this invention, the system maintains a database of individual incidents that have been identified. This incident database is preferably maintained in addition to or instead of the database of incident reports. The incidents recorded in the incident database are preferably indicative of actual or confirmed incidents as opposed to the reports in the reports database, which may not have been confirmed, and which may include multiple reports for any single incident. The incident database can be populated using many techniques. In one technique, a representative from a “911” emergency call center can enter a record of an incident into the incident database. A representative of a weather service can manually enter a record relating to a critical atmospheric event—such as a tornado or thunderstorm. In another technique, reports of incidents by users of the system can be analyzed and/or processed to identify individual incidents, which can then be entered into the incident database. This analysis or processing can be performed by human or automatically and it preferably takes into consideration whether two or more reports of an incident relate to the same actual incident. In another technique, all reports of incidents of certain types (e.g. rape, robbery, or tornado) are entered into the incident database as separate incidents. Preferably, a time and geographic location are logged for each incident. Incidents in the incident database are preferably removed or closed after the passage of time or after the receipt of some indication that the incident has been resolved or no longer exists.
- When a user submits an inquiry, the incident database can be queried using the user's zone of interest in the same manner as described above with respect to the reports database. Incidents that fall within the user's zone of interest (e.g. based on time and geographic location of the incident) are reported to the inquiring user. Certain types of incidents (e.g. hurricanes, thunderstorms, tsunamis) can be entered into the incident database to cover a geographic area, rather than just a point. To account for these cases, the database query can be configured to further identify incidents where the geographic coverage of the incident intersects with the geographic scope of the inquiring user's zone of interest.
- In accordance with one embodiment, the system keeps track of the latest transmitted position (and optionally a predicted current position) of a user based on one or more of the user's prior inquiries. This information can be stored in a user position database. Once a new emergency or hazard is identified, the system can query the user position database to identify users who may want to be informed of this incident and/or who may be able to assist in an emergency. In this manner, in time-critical situations, the system can communicate a message (e.g. by text message or telephone call) to the mobile phone of a user in advance of the user's submitting an inquiry.
- Further aspects of this invention will become apparent in the Detailed Description, which contains the following Sections:
-
-
FIG. 1 is an overview illustration of an alert system in accordance with in one embodiment of the invention. -
FIG. 2 shows a functional block diagram of one embodiment of the alert system. -
FIG. 3 illustrates one process by which an incident report can be handled by the system. -
FIG. 4 illustrates a process for responding to a user's inquiry about reports of incidents within the user's zone of interest. -
FIG. 5 illustrates a process for populating an incident database based on incident reports received from users. -
FIG. 6 illustrates a process for querying the incident database in response to a user inquiry. - In the following description, reference is made to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific embodiments or processes in which the invention may be practiced. Where possible, the same reference numbers are used throughout the drawings to refer to the same or like components. In some instances, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention, however, may be practiced without the specific details or with certain alternative equivalent devices and methods to those described herein. In other instances, well-known methods and devices have not been described in detail so as not to unnecessarily obscure aspects of the present invention.
- As shown in
FIG. 1 , analert system 102 includes aserver 104 that receivesreports 114 from and responds toinquiries 115 from a plurality of users' networkedmobile phones 110. The reports and inquiries preferably relate to incidents such as emergencies or hazards which may be of interest to users of the system. Incidents can be any situation or condition of which users of the system might want to be informed. Hazards can include, for example, road conditions (such as ice, snow, police activity or traffic) or weather conditions (such as thunderstorms or tornadoes) that users may want to avoid. Emergencies are preferably incidents that involve a need of immediate assistance and can include, for example, health conditions (such as heart attacks or critical injuries) or crimes in progress (e.g. rape, abduction or robbery). An incident could also be a general request for assistance by a user in distress (e.g. request for assistance due to an automobile breakdown). - The
mobile phones 110 preferably include geo-positioning capability such as GPS and connectivity to a communications network, such as the Internet via, for example, a wirelessInternet communication link 112. It will be understood that although the present description refers tomobile phones 110, any networked mobile communication device can be used. Geo-positioning capability can be provided in-part or wholly through a communications network that supports a mobile phone. For example, proximity to mobile phone towers based on signal strength, signal delay, and triangulation techniques can be used to locate a user. Indeed, any techniques, such as those proposed and implemented to comply with the U.S. Federal Communications Commission's e911 initiative, can be used for geo-location purposes in accordance with the present invention. - In order to report an incident, a user uses his
mobile phone 110 to transmit areport 114 of the incident, preferably accompanied by the current position of the user/mobile phone, to theserver 104 through thecommunication link 112. The server gathers reports of incidents sent by users of the system in a reports database as will be discussed below. - To facilitate a user's reporting of an incident using the
phone 110, a software program can display a selection menu on the mobile phone listing predefined types of incidents. A user's selection made from this menu is then transmitted to theserver 104. The predefined types of incidents can include, for example, various types of hazards, emergencies, or general (non-emergency) requests for assistance. - Inquiries are preferably performed automatically by each user's activated mobile phone. The phone preferably sends periodic inquiries to the
alert system 102 through thecommunication link 112 to find out if there is any incident which may be of interest to the user. In response to inquiries, theserver 104 transmits incident alerts 116 to themobile phones 110 of those users that may be interested in an incident through thecommunication link 112. An alert transmitted by theserver 104 preferably includes the nature or type of the incident and optionally its location. An alert of an emergency that is sent to a user can also be accompanied by a request that the receiving user assist in the emergency (e.g. as a Good Samaritan). - Upon receipt of an inquiry from a user, the system queries a database to identify incidents (or incident reports) of potential interest to the inquiring user. To provide criteria by which the server can query a database, a zone of interest is preferably specified for each user. A user's zone of interest is a zone within which reports or occurrences of incidents or hazards may be of interest to the user.
- A user's zone of interest can be expressed as a set of database query parameters defining which incidents may be of interest to the user and based upon which a database is queried for reports of potential interest to the user. For example, a user's zone of interest can be a geographic area and time range referenced to the current geographic position of the user and the current time. The extent of the geographic area (or range) can be, for example, a circular area centered on the user's present location. The radius of the area can be expressed, for example, by a unit of length (e.g., within 5 kilometer) or by the time to cover the geographic distance (e.g. within 5 minutes drive). The extent of the time range can be, for example, a time segment starting a number of minutes prior to the current time (e.g. within the past 15 minutes) and extending to the present time. The number of minutes can be selected by the user or by the system, optionally based on user preferences. The geographic area and time ranges are combined in a database query to retrieve all reports falling within both the geographic area and time ranges.
- A zone of interest can be defined to include requirements in addition to or instead of geographic area and time. For example a zone of interest can be configured to include only reports of incidents of a certain type (e.g. traffic hazards). Further, it may be the case that a user doesn't want to be alerted of certain types of incidents or that the user is unable or unwilling to assist in certain types of emergencies. In these cases, the user's zone of interest for these types of incidents can be set to return a null set from a database query or to skip the database query altogether.
- A zone of interest may also be defined dynamically, on-the-fly, possibly based on contextual factors relating to the user's present environment. For example, a geographic area of a user's zone of interest can be adjusted dynamically to expand as the user moves from a more densely populated area to a less densely populated area. In one embodiment, a zone of interest for a user traveling along a highway can be configured to include a narrow geographic band covering the highway ahead of the user. In one embodiment, a zone of interest can be dynamically adjusted (e.g. by expanding or contracting time segment or geographic area) so that the zone would cover a relatively constant number of prior inquiries from other users. In this manner, the number of “eyes” watching for incidents of interest to a user is maintained at a relatively constant level within the user's zone of interest.
- A user and/or the system may define more than one zone of interest for each user where each zone of interest is associated with a different type of incident. For example, a user may define a zone of interest for traffic conditions whereby the distance is 15 miles from the position of the inquiry and the time segment is the 30 minute segment preceding the time of inquiry. Alternatively, a user may also define a zone of interest for providing assistance in response to an emergency. For example, a medical doctor may define a zone of interest for providing assistance in identified emergencies within a 10 minute drive from the doctor's current location.
- In one embodiment, velocity and direction of travel of each reporting user can be stored in the reports and
inquiries database 202. In this configuration, a user's zone of interest can be further defined to include only reports received from users with a similar velocity and direction of travel. Additional analysis can be performed using map data to configure a zone of interest to include only reports from users traveling on the same road as the inquiring user. The zone of interest in this case can also be configured to include only reports received from users traveling in the same direction as the inquiring user. -
FIG. 2 shows a block diagram in accordance with one embodiment of thealert system 102. Theserver 104 is configured to communicate with usermobile phones 110 and various other components of thesystem 102 and the server preferably executes the main processes of thesystem 102. Thesystem 102 preferably also includes a reports andinquiries database 202 configured to store reports of incidents as well as records of prior user inquiries. - The
system 102 can also include anincident database 204 configured to track individual incidents that have been identified. Thisincident database 204 is preferably maintained in addition to or instead of thereports database 202. The incidents recorded in the incident database are preferably indicative of actual or confirmed incidents as opposed to the reports in the reports database, which may not have been confirmed, and which may include multiple reports for any single incident. The incident database can be populated using many automated and/or manual techniques. In one technique, a representative from a “911” emergency call center can enter a record of an incident into the incident database. A representative of a weather service can manually enter a record relating to a critical atmospheric event—such as a tornado or thunderstorm. In another technique, reports of incidents by users of the system can be analyzed and/or processed to identify individual incidents, which can then be entered into the incident database. This analysis or processing can be performed by human or automatically and it preferably takes into consideration whether two or more reports of an incident relate to the same actual incident. In another technique, all reports of incidents of certain types (e.g. rape, robbery, tornado) are entered into the incident database. Preferably, a time and geographic location are logged for each incident. Incidents in the incident database are preferably removed or closed after the passage of time or after the receipt of some indication that the incident has been resolved or no longer exists. - The
system 102 preferably includes auser profile database 206 configured to store user preferences. Thealert system 102 preferably also hosts aweb site 208 that allows users to set their preferences in theuser profile database 206. User preferences can include information upon which a user's zone of interest can be based, such as: a radius of distance from the user for identifying incidents of interest; a time window prior to a current time for identifying incidents of interest; a listing of incident types of interest; and a listing of incident types that are not of interest to the user. These preferences can be specified in detail for each of multiple types of incidents. The preferences can include the user's profession or area of expertise, which can enable the system to identify relevant users for responding to certain emergencies. For example, a doctor or an emergency medical technician could be selected from available users to respond to a critical health condition. In one embodiment, a user can express his area of expertise for assisting in an emergency implicitly by setting his preferences so that he is notified only of emergencies that are relevant to his area of expertise. In order to identify users to assist in emergencies, the system and/or users preferably set zones of interest to include only emergency types for which users are willing and able to assist. - The
user profile database 206 is preferably configured to store an association between each user and his mobile device. Alternatively, theuser profile database 206 can be configured to store preferences in association with individual mobile devices. As will be understood by one skilled in the art, for the purpose of this description, the concept of a user and of a user's mobile device can be used interchangeably. - In accordance with one embodiment, the system can also be configured to store a history of each user's location in a
user position database 212. This history can be used, for example, to predict a user's location between inquiries or to predict a user's velocity and direction of travel. A user's last location or a predicted location can be used in the case that an urgent request for assistance needs to be sent to users in a certain geographic area without having to wait for users' next inquiries. In an alternative embodiment, the position history can be stored in theuser profile database 206, in which case, the user profile database can serve a dual purpose as a position database. - In one embodiment, the system includes an
incident evaluation module 210 configured to identify incidents and/or determine specific needs for assistance by users in response to reported emergencies or requests for assistance. Preferably, the incident evaluation module populates and/or updates theincident database 210 with information about identified incidents. The incident evaluation module can execute an automated process that determines assistance needs, preferably by emergency type, or it can be a partly or wholly manual operation. Preferably, theincident evaluation module 210 tracks which and/or how many users have responded to a request for assistance indicating that they will assist so that only a sufficient number of users actually respond to the emergency. Once a sufficient number of indications are received, the system can discontinue sending further emergency reports and/or requests for assistance. - In one embodiment, the
incident evaluation module 210 compiles all reported information about each incident and attempts to determine what services and resources are needed to address it. As part of its function, theincident evaluation module 210 can analyze and identify the various independent reports thealert system 102 may receive about the same emergency or hazard. This analysis can rely upon the reported location of the incident, the time-stamp of the report, the type of emergency or hazard, and any additional information that might be provided by each reporting user, such as pictures and messages, to determine if any two reports relate to the same incident. Using this information, theincident evaluation module 210 preferably updates theincident database 204 to reflect the various incident reports submitted by different users as part of the same incident record. In addition, theincident evaluation module 210 can update current the state of resolution of each incident while actions are undertaken to address it. -
FIG. 3 illustrates oneprocess 300 by which an incident report can be handled by thesystem 102. At astep 301, the user transmits a report of an incident to theserver 104 from amobile phone 110. Preferably, the user identifies a type of incident to report from a menu of available types. In one embodiment, a multilevel menu system can be used to guide the user to a selection which identifies the type of emergency or hazard the user needs to report. The available types of incidents can include, for example, general types such as: traffic hazard; weather condition; emergency; and request for assistance. The types can also include, for example, specific types such as: traffic accident; icy roads; tornado; thunderstorm; and heart attack. - Preferably, the user's
mobile phone 110 adds the user's present geographic location to the report. Alternatively, a communications system that supports the mobile phone's connectivity can provide the geographic location. - Optionally, the alert system can support a voice report via the user's mobile phone. Under this option, the alert system can prompt the user to verbally describe on the mobile phone the observed emergency or hazard. This verbal description can be translated into text by a speech recognition engine. A natural language understanding software program, or alternatively a human operator, can interpret the text or voice message to identify the type of emergency or hazard.
- At a
step 302, theserver 104 receives the report of the incident and the user's location. At astep 303, theserver 104 preferably determines additional contextual information related to the report and/or user, such as, for example: the time of the report, the user's direction/speed of travel, and the user's identity/user ID. In one embodiment, this additional contextual information can be determined and provided by the user and/or the user's mobile phone. At astep 304 the incident report and the contextual information are stored in the reports andinquiries database 202. -
FIG. 4 illustrates aprocess 400 by which thesystem 102 can respond to a user's inquiry about reports of incidents within the user's zone of interest. Theprocess 400 queries the reports andinquiries database 202 in response to the user's inquiry to retrieve reports of potential interest to the user. The reports are then analyzed to determine a score indicative of a likelihood of existence of an actual incident. If a score meets a certain threshold level, then the user can be notified of a possible or likely incident. - Preferably, the
process 400 is performed repeatedly, on a periodic basis, such as every 15 seconds or every minute in response to repeated user inquiries. In this manner, recently received reports can be considered in responding to the user's inquiry. The frequency of repetition can remain constant, for example, based on a user preference/selection or based on system-optimized settings. Alternatively the frequency of repetition can be dynamically varied, and preferably initiated by inquiries from the user's mobile phone, based on one or more factors, such as, for example, the velocity of the user or the frequency or density of inquiries by other users proximate the inquiring user. - At a
step 401, thealert system 102, receives a user's inquiry, which preferably includes the user's geographic location. The user's inquiry may also include additional parameters, such as, for example: user velocity and direction of travel. These additional parameters can alternatively be determined by the system, for example, by analyzing prior queries/reports from the user. In one embodiment, the inquiry can consist only of a reporting of the user's position, which the system can treat as an implied inquiry. - At a
step 402, the user's inquiry is optionally logged into the reports andinquiries database 202. Logging the inquiry into the reports andinquiries database 202 enables additional data about the user to be determined for future inquiries (e.g. velocity and direction of travel). In addition, logging user inquiries also enables the system to make subsequent determinations of overall user inquiry frequency and density based on the logs of multiple users' inquiries. In one embodiment, the position of the user is also logged in theuser position database 212. This information can be useful to calculate the direction and speed of movement of the user and provides information based upon which the future location of the user can be predicted. - At a
step 403, the inquiring user's zone of interest is determined or identified, preferably in the form of query parameters that can be used to query the reports andinquiries database 202. The user's zone of interest, as discussed above, can be static or can be dynamically determined preferably based on parameters of the user's inquiry. The zone of interest can be based upon information provided by the user (which may be stored in the profiles database 206), information determined from the user's context (location, velocity, time), or other information. - In one embodiment, as stated previously, the user's zone of interest can be expanded or contracted in inverse proportion to the overall density or frequency of user queries proximate the user's location. Alternatively the user's zone of interest can be dynamically adjusted so that it includes a relatively constant number of inquiries by other users. By adjusting the zone of interest in this manner, the number of other users from which reports are effectively monitored remains relatively constant.
- At a
step 404, the reports andinquiries database 202 is queried, using the zone of interest parameters, to retrieve emergency and hazard reports and optionally any prior user inquiries within the user's zone of interest. Preferably, the inquiring user's own reports and inquiries are excluded from the results of the query, so that the user's own reports do not factor into his own subsequent inquiries. - In accordance with one embodiment, the user's zone of interest can be generic to all types of incidents. The following
step 405 is intended to handle an embodiment where one zone of interest is applied to all types of incidents and then the resulting reports are grouped by type and analyzed. - At the
step 405, the reports produced by the query are organized by type into separate groups. Preferably, the groups correspond to the different types of reports supported by the selection menu from which users can select the desired type when reporting incidents. In this manner, separate types of reports can be analyzed separately. The remaining steps of this process, 406 through 409, are preferably executed for each separate group of reports. - In another embodiment, a user's zone of interest can be specified separately for each type of incident. In this case, the
prior step 405 can be skipped, but thewhole process 400 is preferably performed for each type of incident in response to each user inquiry. - At a
step 406, for each group or type of incident, a score is computed based on the reports in the group, any associated contextual information provided by the user, and optionally on any prior user inquiries retrieved from the reports andinquiries database 202. The score is preferably configured to be indicative of the likelihood that an actual incident of interest to the user has an active status. Many different calculations can yield such a score as illustrated in the following examples: -
- In one embodiment, the computation of the score can be based on individual characteristics of each report in the group. For example, the score can be based on the amount of time elapsed between the current time and the time of each report in the group. The score can also be based on the distance between the inquiring user and the reporting user for each report. In this manner, reports that occurred further in the past or farther away from the inquiring user can be given decreased weight or emphasis and reports occurring closer in time or distance can be given greater emphasis. One formula could include a factor in a denominator based on a sum of differences of distance and time.
- At a
step 407, the computed score is analyzed to determine if it exceeds a threshold level. If the score exceeds the threshold, an incident alert is reported to the inquiring user at astep 408. The threshold level can be selected or adjusted by the user (e.g. through theweb site 208 or through the phone 110), by the system, or by a combination of both, preferably based on testing and/or experience for a particular implementation of the system. Different threshold levels can also be selected for each type of incident. - The alert sent to the inquiring user preferably includes the type of incident that caused the alert. In addition, the alert can include the score itself or a value based on the score. The receiving user's mobile device is preferably configured to produce a perceptible signal (e.g. audible, visual, or vibration) in response to the alert to notify the user. The signal produced by the mobile phone can be varied based on the score, for example, so that higher scores produce more notable signals.
- If, at the
step 407, the score does not exceed the threshold, the process continues withstep 409, in which case the inquiry is ignored and/or no incident alert is reported to the inquiring user. -
FIG. 5 illustrates aprocess 500 for populating theincident database 204 based on incident reports received from users. Theprocess 500 preferably follows step 303 of theprocess 300 and can be performed in addition to or instead ofstep 304 depending on whether anincident database 204 is used. At anoptional step 501 the incident report is analyzed to determine whether it is a type of incident that is to be entered into theincident database 204. In one embodiment, only emergencies or critical hazards are entered. At anoptional step 502, the report is checked against existing incidents already in theincident database 204 to determine if the report relates to a previously identified incident. Whether a new report is for the same incident as a prior report can be based on factors such as proximity of location, proximity of time of report, and type of incident, for example. If the new report is a duplicate of an existing one, then the existing record in thedatabase 204 can be updated. Otherwise, at astep 503, a new record is created in the incident database for the reported incident. - Once a new emergency or hazard is identified at the
step 503, the system can query theuser position database 212 to identify users who may want to be informed of the incident and/or who may be able to assist in an emergency at astep 504. In this manner, in time-critical situations, the system can communicate a message (e.g. by text message or telephone call) to the mobile phone of a user independently of the user submitting an inquiry. In performing the query, the system can identify an actual or estimated position of each identified user based on the user's position history in theuser position database 212. The system can also identify a geographic area associated with the incident so that any users whose estimated positions fall within the area are included in the query results. - In one embodiment, the zone of interest of each identified user, based on the user's actual or estimated position, is applied to the newly identified incident. When the incident falls within a user's zone of interest, the user can be alerted at a
step 505. In one embodiment, the database query can be configured to identify incidents where the geographic coverage of the incident intersects with the geographic scope of the inquiring user's zone of interest. - An alert of an emergency that is sent to a user can also be accompanied by a request that the receiving user assist in the emergency. In this case, the user receiving the emergency alert can be given the opportunity respond to the system indicating that he will assist.
- A user's preferences can be set to indicate that the user will only be willing to travel a certain distance to respond to an emergency. In this case, the user's zone of interest for a type of emergency can be configured to include only emergencies located within the specified distance of the user's actual or predicted location.
-
FIG. 6 illustrates aprocess 600 for querying the incident database in response to a user inquiry. Theprocess 600 preferably follows step 403 of theprocess 400 and can be performed in addition to or instead of steps 404-409 of theprocess 400 depending on whether anincident database 204 is used. When a user submits an inquiry, the incident database is queried, at astep 601, using the user's zone of interest in the same manner as described above with respect to the reports database in theprocess 400. At astep 602, thesystem 102 identifies incidents that fall within the user's zone of interest (e.g. based on time and geographic location of the incident). At astep 603, the identified incidents are reported to the inquiring user. - In accordance with one embodiment, certain types of incidents (e.g. hurricanes, thunderstorms, tsunamis) can be entered into the
incident database 204 to cover or define a geographic area (and/or a time period), rather than just a point. To account for these cases, the database query can be configured to further identify incidents where the geographic coverage of the incident intersects with the geographic scope of the inquiring user's zone of interest. - While certain preferred embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention. Other embodiments that are apparent to those of ordinary skill in the art, including embodiments that do not provide all of the features and advantages set forth herein, are also within the scope of this invention. Further, it is to be understood that this invention is not limited to the specific construction and arrangements shown and described since various modifications or changes may occur to those of ordinary skill in the art without departing from the spirit and scope of the invention. Accordingly, the scope of the invention is defined by the claims that follow.
Claims (8)
1. A method for sending alerts of incidents based on geographic position and time, the method comprising:
receiving a plurality of reports of position transmitted from a plurality of networked mobile devices, wherein each report of position is one of a sequence of automatic and periodic reports of position transmitted by one of the plurality of networked mobile devices;
storing each report of position in a database in association with an identifier of the transmitting networked mobile device and a time;
identifying an incident;
identifying a geographic position associated with the incident;
identifying a geographic range related to the identified geographic position;
identifying a temporal range related to a present time;
in response to the identification of the incident, querying the database based on the geographic range and the temporal range to identify one or more networked mobile devices; and
sending an alert of the incident to the one or more identified networked mobile devices.
2. The method of claim 1 , wherein querying the database comprises estimating a present position of a networked mobile device based upon a plurality of positions previously reported by the networked mobile device.
3. The method of claim 2 , wherein querying the database further comprises identifying a geographic range related to the estimated present position.
4. The method of claim 1 , wherein the reports of position comprise inquiries.
5. The method of claim 1 , wherein each incident can be: an emergency, a hazard, or a request for assistance.
6. The method of claim 1 , wherein the incident is identified based upon a report of the incident received from a networked mobile device subsequent to and separate from receiving the plurality of reports of position.
7. The method of claim 1 , wherein the incident is identified based on a phone call placed to an emergency call center.
8. The method of claim 1 , wherein the database is queried further based on a zone of interest associated with at least one of the plurality of networked mobile devices.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/237,888 US20120009894A1 (en) | 2004-05-20 | 2011-09-20 | Collaborative incident alert system for mobile devices |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US57339804P | 2004-05-20 | 2004-05-20 | |
US11/133,829 US8024330B1 (en) | 2004-05-20 | 2005-05-20 | Collaborative incident alert system for mobile devices |
US13/237,888 US20120009894A1 (en) | 2004-05-20 | 2011-09-20 | Collaborative incident alert system for mobile devices |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/133,829 Continuation US8024330B1 (en) | 2004-05-20 | 2005-05-20 | Collaborative incident alert system for mobile devices |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120009894A1 true US20120009894A1 (en) | 2012-01-12 |
Family
ID=44587146
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/133,829 Expired - Fee Related US8024330B1 (en) | 2004-05-20 | 2005-05-20 | Collaborative incident alert system for mobile devices |
US13/237,888 Abandoned US20120009894A1 (en) | 2004-05-20 | 2011-09-20 | Collaborative incident alert system for mobile devices |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/133,829 Expired - Fee Related US8024330B1 (en) | 2004-05-20 | 2005-05-20 | Collaborative incident alert system for mobile devices |
Country Status (1)
Country | Link |
---|---|
US (2) | US8024330B1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130311538A1 (en) * | 2012-05-18 | 2013-11-21 | Heartspring, Inc. | Computer program, method, and system for collecting and analyzing data for special needs children |
WO2014107266A1 (en) * | 2012-12-07 | 2014-07-10 | Robert Salinas | Location based augmented reality on mobile devices |
US20150281928A1 (en) * | 2014-04-01 | 2015-10-01 | West Corporation | System and method for flexibly sending commercial mobile alert system messages (cmas) and earthquake and tsunami warning system (ewts) alert messages |
US20160134385A1 (en) * | 2013-03-15 | 2016-05-12 | Sorenson Communications, Inc. | Methods and apparatuses for emergency notifications to the hearing impaired |
CN106781572A (en) * | 2017-01-16 | 2017-05-31 | 青岛海信网络科技股份有限公司 | A kind of method and device of guidance information issue |
WO2020140247A1 (en) * | 2019-01-04 | 2020-07-09 | Microsoft Technology Licensing, Llc | Automatic notification of data changes |
EP3232413B1 (en) * | 2016-04-15 | 2021-11-24 | Volvo Car Corporation | Method and system for enabling a vehicle occupant to report a hazard associated with the surroundings of the vehicle |
WO2023224600A1 (en) * | 2022-05-17 | 2023-11-23 | Rakuten Mobile, Inc. | Location determining method and system for implementing |
Families Citing this family (53)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7603432B2 (en) * | 2005-06-06 | 2009-10-13 | Aa, Llc | Locality based alert method and apparatus |
EP1904989B1 (en) * | 2005-06-21 | 2021-12-29 | Centralert Corporation | Integrated alert system |
US8661029B1 (en) | 2006-11-02 | 2014-02-25 | Google Inc. | Modifying search result ranking based on implicit user feedback |
US9110975B1 (en) | 2006-11-02 | 2015-08-18 | Google Inc. | Search result inputs using variant generalized queries |
US8938463B1 (en) | 2007-03-12 | 2015-01-20 | Google Inc. | Modifying search result ranking based on implicit user feedback and a model of presentation bias |
US8694374B1 (en) | 2007-03-14 | 2014-04-08 | Google Inc. | Detecting click spam |
US9092510B1 (en) | 2007-04-30 | 2015-07-28 | Google Inc. | Modifying search result ranking based on a temporal element of user feedback |
US9224147B2 (en) * | 2007-07-16 | 2015-12-29 | Hector Franco | Customer service management system |
US8694511B1 (en) | 2007-08-20 | 2014-04-08 | Google Inc. | Modifying search result ranking based on populations |
US8909655B1 (en) | 2007-10-11 | 2014-12-09 | Google Inc. | Time based ranking |
US9183744B2 (en) * | 2008-01-29 | 2015-11-10 | Here Global B.V. | Method for providing images of traffic incidents |
US9826344B2 (en) * | 2008-03-28 | 2017-11-21 | At&T Mobility Ii Llc | Systems and methods for determining previous occupation in or proximate to an alert area |
US8396865B1 (en) | 2008-12-10 | 2013-03-12 | Google Inc. | Sharing search engine relevance data between corpora |
US9424407B2 (en) * | 2008-12-30 | 2016-08-23 | International Business Machines Corporation | Weak password support in a multi-user environment |
US9009146B1 (en) | 2009-04-08 | 2015-04-14 | Google Inc. | Ranking search results based on similar queries |
US8447760B1 (en) | 2009-07-20 | 2013-05-21 | Google Inc. | Generating a related set of documents for an initial set of documents |
US8498974B1 (en) | 2009-08-31 | 2013-07-30 | Google Inc. | Refining search results |
US8972391B1 (en) | 2009-10-02 | 2015-03-03 | Google Inc. | Recent interest based relevance scoring |
US8874555B1 (en) | 2009-11-20 | 2014-10-28 | Google Inc. | Modifying scoring data based on historical changes |
US8615514B1 (en) | 2010-02-03 | 2013-12-24 | Google Inc. | Evaluating website properties by partitioning user feedback |
US8924379B1 (en) * | 2010-03-05 | 2014-12-30 | Google Inc. | Temporal-based score adjustments |
US8959093B1 (en) | 2010-03-15 | 2015-02-17 | Google Inc. | Ranking search results based on anchors |
US9623119B1 (en) | 2010-06-29 | 2017-04-18 | Google Inc. | Accentuating search results |
US8832083B1 (en) | 2010-07-23 | 2014-09-09 | Google Inc. | Combining user feedback |
US9338124B2 (en) | 2010-10-05 | 2016-05-10 | VNP Software, Inc. | Electronic messaging systems |
US20120260194A1 (en) * | 2010-11-19 | 2012-10-11 | James Lehr Kennedy | User configurable universal interface for managing utility services |
US9002867B1 (en) | 2010-12-30 | 2015-04-07 | Google Inc. | Modifying ranking data based on document changes |
EP2782412B1 (en) * | 2011-11-14 | 2018-01-03 | Ntt Docomo, Inc. | Determining the carriage of a vehicle in which a wireless terminal is located |
CN102884816B (en) * | 2011-12-30 | 2015-05-27 | 华为技术有限公司 | Help-seeking method, apparatus, and system based on location-based service |
US9014660B2 (en) | 2012-01-29 | 2015-04-21 | Livesafe, Inc. | Mobile alert reporting and monitoring systems and methods |
US9147336B2 (en) * | 2012-02-29 | 2015-09-29 | Verizon Patent And Licensing Inc. | Method and system for generating emergency notifications based on aggregate event data |
US20130275324A1 (en) | 2012-04-13 | 2013-10-17 | Trapeze Software Ulc | System and method for configurable deployment of transit agency content |
US9031779B2 (en) * | 2012-05-30 | 2015-05-12 | Toyota Motor Engineering & Manufacturing North America, Inc. | System and method for hazard detection and sharing |
US9418354B2 (en) * | 2013-03-27 | 2016-08-16 | International Business Machines Corporation | Facilitating user incident reports |
US9183499B1 (en) | 2013-04-19 | 2015-11-10 | Google Inc. | Evaluating quality based on neighbor features |
CN103593390B (en) * | 2013-08-22 | 2018-04-24 | 小米科技有限责任公司 | A kind of method, apparatus and equipment of multimedia messages identification |
US20150098553A1 (en) * | 2013-10-07 | 2015-04-09 | David F. Bonitati | System And Method For Providing Alerts |
US10861071B2 (en) | 2013-12-05 | 2020-12-08 | Knowmadics, Inc. | Crowd-sourced computer-implemented methods and systems of collecting requested data |
US9807183B2 (en) | 2013-12-05 | 2017-10-31 | Knowmadics, Inc. | System and server for analyzing and integrating data collected by an electronic device |
US9870697B2 (en) | 2013-12-17 | 2018-01-16 | At&T Mobility Ii Llc | Method, computer-readable storage device and apparatus for providing a collaborative standalone area monitor |
US9607502B1 (en) * | 2014-01-28 | 2017-03-28 | Swiftreach Networks, Inc. | Real-time incident control and site management |
US9934249B2 (en) * | 2014-06-03 | 2018-04-03 | Conduent Business Machines Services, Llc | Systems and methods for context-aware and personalized access to visualizations of road events |
US10559038B1 (en) | 2014-07-30 | 2020-02-11 | Allstate Insurance Company | Mobile service provider and insurance systems |
GB2535734B (en) * | 2015-02-25 | 2020-04-22 | Lone Worker Solutions Ltd | Virtual perimeter system and method |
EP3295658A4 (en) * | 2015-05-11 | 2019-05-01 | Parthiban Munusamy | Portable personal emergency alert system and associated methods |
US9786171B2 (en) | 2016-01-26 | 2017-10-10 | Toyota Motor Engineering & Manufacturing North America, Inc. | Systems and methods for detecting and distributing hazard data by a vehicle |
US20170345112A1 (en) * | 2016-05-25 | 2017-11-30 | Tyco Fire & Security Gmbh | Dynamic Threat Analysis Engine for Mobile Users |
US10810695B2 (en) * | 2016-12-31 | 2020-10-20 | Ava Information Systems Gmbh | Methods and systems for security tracking and generating alerts |
EP3721402A4 (en) | 2017-12-05 | 2021-08-04 | Rapidsos Inc. | Social media content for emergency management |
US10692359B2 (en) | 2018-04-23 | 2020-06-23 | Green Line Business Group | Witness request and alert notification and tracking system |
US10699122B2 (en) | 2018-09-27 | 2020-06-30 | International Busines Machines Corporation | Alerting a hyper focused device user to engage audience |
AU2020287175A1 (en) * | 2019-06-07 | 2022-01-27 | Intergraph Corporation | Data sharing control methods and systems |
US11568983B2 (en) | 2019-09-19 | 2023-01-31 | International Business Machines Corporation | Triage via machine learning of individuals associated with an event |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020164999A1 (en) * | 2000-06-07 | 2002-11-07 | Johnson William J. | System and method for proactive content delivery by situational location |
US6862524B1 (en) * | 2001-07-03 | 2005-03-01 | At Road, Inc. | Using location data to determine traffic and route information |
US7098787B2 (en) * | 2003-05-29 | 2006-08-29 | Intel Corporation | System and method for signaling emergency responses |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE69916482T2 (en) | 1998-10-14 | 2005-03-24 | Siemens Vdo Automotive Corp., Auburn Hills | DRIVER INFORMATION SYSTEM |
US6615130B2 (en) * | 2000-03-17 | 2003-09-02 | Makor Issues And Rights Ltd. | Real time vehicle guidance and traffic forecasting system |
US6577946B2 (en) * | 2001-07-10 | 2003-06-10 | Makor Issues And Rights Ltd. | Traffic information gathering via cellular phone networks for intelligent transportation systems |
US6885874B2 (en) | 2001-11-27 | 2005-04-26 | Motorola, Inc. | Group location and route sharing system for communication units in a trunked communication system |
US6882837B2 (en) * | 2002-01-23 | 2005-04-19 | Dennis Sunga Fernandez | Local emergency alert for cell-phone users |
US7792273B2 (en) | 2003-09-15 | 2010-09-07 | Accenture Global Services Gmbh | Remote media call center |
-
2005
- 2005-05-20 US US11/133,829 patent/US8024330B1/en not_active Expired - Fee Related
-
2011
- 2011-09-20 US US13/237,888 patent/US20120009894A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020164999A1 (en) * | 2000-06-07 | 2002-11-07 | Johnson William J. | System and method for proactive content delivery by situational location |
US6862524B1 (en) * | 2001-07-03 | 2005-03-01 | At Road, Inc. | Using location data to determine traffic and route information |
US7098787B2 (en) * | 2003-05-29 | 2006-08-29 | Intel Corporation | System and method for signaling emergency responses |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130311538A1 (en) * | 2012-05-18 | 2013-11-21 | Heartspring, Inc. | Computer program, method, and system for collecting and analyzing data for special needs children |
US8812588B2 (en) * | 2012-05-18 | 2014-08-19 | Heartspring, Inc. | Computer program, method, and system for collecting and analyzing data for special needs children |
WO2014107266A1 (en) * | 2012-12-07 | 2014-07-10 | Robert Salinas | Location based augmented reality on mobile devices |
US20160134385A1 (en) * | 2013-03-15 | 2016-05-12 | Sorenson Communications, Inc. | Methods and apparatuses for emergency notifications to the hearing impaired |
US9673923B2 (en) * | 2013-03-15 | 2017-06-06 | Sorenson Ip Holdings, Llc | Methods and apparatuses for emergency notifications to the hearing impaired |
US20150281928A1 (en) * | 2014-04-01 | 2015-10-01 | West Corporation | System and method for flexibly sending commercial mobile alert system messages (cmas) and earthquake and tsunami warning system (ewts) alert messages |
EP3232413B1 (en) * | 2016-04-15 | 2021-11-24 | Volvo Car Corporation | Method and system for enabling a vehicle occupant to report a hazard associated with the surroundings of the vehicle |
CN106781572A (en) * | 2017-01-16 | 2017-05-31 | 青岛海信网络科技股份有限公司 | A kind of method and device of guidance information issue |
WO2020140247A1 (en) * | 2019-01-04 | 2020-07-09 | Microsoft Technology Licensing, Llc | Automatic notification of data changes |
WO2023224600A1 (en) * | 2022-05-17 | 2023-11-23 | Rakuten Mobile, Inc. | Location determining method and system for implementing |
Also Published As
Publication number | Publication date |
---|---|
US8024330B1 (en) | 2011-09-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8024330B1 (en) | Collaborative incident alert system for mobile devices | |
US20220180734A1 (en) | Traffic portal enquiry and alert system | |
US11864082B2 (en) | Systems and methods for delivering and supporting digital requests for emergency service | |
EP3048820B1 (en) | Method and device for predicting position of mobile user | |
US6862524B1 (en) | Using location data to determine traffic and route information | |
US7911360B2 (en) | Method and system for vehicular communications and information reporting | |
US7010424B2 (en) | Methods and systems for reporting automotive traffic conditions in response to user-specific requests | |
US9400190B2 (en) | Real-time traffic condition measurement using network transmission data | |
US9135624B2 (en) | User-centric traffic enquiry and alert system | |
US8229462B2 (en) | Method and system for providing assistance resource progress information along a route | |
US8437958B2 (en) | Method and system for providing wireless connection conditions along a navigation route | |
US20110071880A1 (en) | Location-based Emergency Response System and Method | |
US9449507B2 (en) | Traffic profiling and road conditions-based trip time computing system with localized and cooperative assessment | |
US9196149B2 (en) | Mobile device alert generation system and method | |
US20080033644A1 (en) | Navigation Routing System Having Environmentally Triggered Routing | |
US20090309742A1 (en) | Disaster alert display (dad) emergency and natural disaster warning system that automatically detects if people are caught in an emergency or disaster, determines if they are ok, and notifies their emergency contacts | |
US20030060211A1 (en) | Location-based information retrieval system for wireless communication device | |
EP1249140A1 (en) | System and method for attaching an advertisement to an sms message for wireless transmission | |
US7577732B2 (en) | Information distribution service providing system | |
US9792809B2 (en) | Bio-threat alert system | |
CN113420054A (en) | Information statistical method, server, client and storage medium | |
CN112040417A (en) | Audio marking method and device, electronic equipment and storage medium | |
JP4410099B2 (en) | Path search method | |
JP2005529387A5 (en) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |