Alert notification system

CROSS REFERENCE TO RELATED APPLICATIONS

0001This application is a divisional of U.S. application Ser. No. 09/503,141, filed Feb. 11, 2000, now U.S. Pat. No. 6,816,878 now allowed, which is hereby incorporated by reference herein in its entirety.

FIELD OF THE INVENTION

0002The present invention relates to the delivery of emergency information to persons needing to be notified of such information.

BACKGROUND OF THE INVENTION

0003Populations are increasing throughout the United States and globally. Population concentration increases the impact of localized emergencies such as weather, chemical spills, floods, etc., and thus increases the importance of notifying the public of emergency conditions in a timely manner.

0004Emergency services and public safety organizations have established technological systems that help to identify and communicate emergency situations. For example, emergencies may be centrally reported via 911 telephone communication systems, and disseminated via radio, satellite or Internet communications. Prediction methodologies have improved early detection of pending threats, particularly weather related threats such as tornadoes and floods, and communications networks have expanded to assist in the dissemination of this information. According to the National Weather Service (NWS) report “Reinventing Goals for 2000 Status—March 1999”, the NWS requested $42.1 million in FY2000 for it's Natural Disaster Reduction Initiative (NDRI 2000) to continue to modernize and improve lead-times for severe weather events and expand the number of NOAA Weather Radio (NWR) stations. Forecasting and detection technologies, coupled with almost real-time distribution networks, have improved the average lead-time for severe weather events dramatically. Statistically, the NWS reports lead-time detections for thunderstorm events are currently 17.9 minutes. This is an improvement of 43% over the pre-modernization lead-time detection of 12.5 minutes for thunderstorms. Likewise, the improved tornado lead-time detection average is currently 11.0 minutes; improved by 162% over the pre-modernization lead-time average of 4.2 minutes. Furthermore, flash flood detections currently stand at 52 minutes of lead-time with an astounding improvement of 491%. Substantial increases in lead-time detection should contribute to more effective notification and ultimately more lives saved.

0005Although these improvements have provided greater accuracy and lead time in severe weather notifications, such notifications do not seem to be adequately communicated to citizens. Preliminary data as of Jul. 13, 1999 for the year 1999, shows that 99% of the total fatalities for tornadoes occurred during tornado watches. Statistics for 1998 similarly show 85% of all fatalities also occurred during tornado watches. Many of these fatalities could have been avoided if the persons involved had sought adequate shelter. This clearly indicates that there is a weakness in the existing infrastructure for notifying citizens of severe weather conditions. A review of this infrastructure and its shortfalls is thus in order.

0006Currently, the National Weather Service (NWS) collects and disseminates near real-time weather data to help identify and distribute alerts, watches and weather warnings for specific geographical regions around-the-clock over various distribution networks. For the cost of essential down link equipment, virtually anyone may receive nearly all this information at no charge. However, identifying what information is personally relevant does require the continuous sorting and digestion of the entire data stream 24 hours a day and seven days per week. Practically speaking, many individuals just have no need for the entire data stream. They just need to know when an emergency pertains to them specifically, no matter where they are and no matter what time of day. For this, people rely on local media organizations and government organizations to monitor and provide notification should an emergency occur. Many public and private entities currently receive this data stream, then parcel, process, categorize and sometimes enhance this information to rebroadcast over various distribution networks so local citizenry, populations and private industry may be alerted or informed. Nevertheless, the typical citizen must rely upon the vigilance of public and private media broadcasters to constantly monitor this data stream and get “the word out” in time of emergency.

0007To help provide additional insurance and improve the likelihood for notification, individuals can purchase a NOAA Weather Radio (NWR) receiver. NOAA Weather Radio (NWR) is a service of the National Oceanic and Atmospheric Administration (NOAA) of the U.S. Department of Commerce. As the “Voice of the National Weather Service”, it provides continuous broadcasts of the current weather information as well as hazardous local environmental conditions. Furthermore, a NWR receiver can detect codes in a NWR broadcast indicative of hazardous weather conditions, and respond by producing a special alarm signal that is separate from normal playback of weather broadcasts.

0008Most NOAA weather stations broadcast 24 hours a day, but NWR coverage is limited by nature and design to an area within 40 miles of the transmitter. Those living in cities surrounded by large buildings and those in mountain valleys with standard receivers get little or no reception at considerably less than 40 miles. As of February 1998, approximately 70 to 80 percent of the U.S. population are capable of receiving NOAA Weather Radio broadcasts. Most recently, as a result of the “Gore Initiative”, there has been 99 new NWR stations put into operation and funding is being sought for 100 new stations to ultimately achieve a 95% population coverage in each state. Thus, ultimately the system will leave at least 5% of the population unable to hear broadcasts or weather alerts.

0009Of course, the 95% coverage figure quoted in the previous paragraph, assumes that everyone within the coverage area of a NOAA Weather Radio transmitter has purchased a NWR receiver and will always have it turned on. Unfortunately, many people that actually own a NOAA Weather Radio often leave it unattended and unmonitored. There are several reasons for this, ranging from misuse of the equipment to discomfort with leaving any household appliance continuously on. Perhaps the most pernicious problem is that weather broadcasts must cover a relatively large area and so many of the alert signals transmitted by those broadcasts will be irrelevant to a large percentage of the listening population. For example, flood or tornado warnings are typically applicable only to listeners in a subsection of a particular county, while the remaining listeners are not in substantial danger. Unfortunately, however, all citizens that are tuned to the weather broadcast will hear the alert signal for every localized emergency. This results in the situation not unlike the fable of the Boy Who Cried Wolf, in which citizens decide that the warnings are not normally relevant, and either ignore them or turn their NWS receiver off. Most particularly, citizens often do not place a NWS receiver in their bedroom, because they would rather not be disturbed at night unless there is a certain life-threatening emergency. This perhaps explains why tornadoes and floods that occur at night are often the most deadly, because citizens do not receive emergency notifications.

0010Local municipalities have sometimes utilized civil defense siren systems to sound loud audible alerts in time of emergency to help capture the attention of urban residents. However, the sounding of an emergency siren can be confusing, requiring the notification recipient to seek additional information. The siren could mean a severe weather emergency, a chemical spill, volcanic eruption, a monthly system test or any other condition that local government decides to note (such as a “noon whistle”). Many citizens will, as a consequence, ignore such sirens rather than invest the time to determine their meaning. Furthermore, under the best conditions, the effectiveness of a siren is dependent upon proximity to the siren. Citizens that live near to the siren, live in poorly sound-insulated buildings, have normal hearing and/or are light sleepers, are much more likely to be notified of emergencies than citizens that live far from the siren, live in quiet buildings, are hearing impaired and/or are sound sleepers. As a consequence, it has been found that many people sleep right through nighttime siren alerts, and many severe weather fatalities are attributable to people just not hearing a siren. Further diminishing this system's effectiveness, many siren systems are over 50 years old and plagued with maintenance problems. Furthermore, sirens evidence spotty urban population coverage due to urban expansion that has outgrown system capacity.

0011Similar problems of notifying citizenry arise in non-weather related emergencies. For example, when there is a chemical spill or explosive threat, appropriate emergency services are dispatched to attempt to mitigate the impact to human health or property. Often, the full scope of the emergency can not be ascertained until emergency crews actually arrive at the scene. If the emergency has the potential to escalate and endanger more lives and other communities, emergency organizations must again rely on broadcasting for notification.

0012The United States Environmental Protection Agency (U.S. EPA) requires companies to develop Risk Management Program (RMP) plans. The required RMP plans describe chemical risks at industrial sites and the programs these facilities use to prevent accidental releases and minimize the impact on human health in the unlikely event that a release should occur. When applicable, the RMP includes air dispersion modeling to determine the potential off-site consequences of a release. Some HAZMAT (Hazardous Materials) vehicles also contain portable computers loaded with software to calculate and plot air dispersion modeling on an area map to accurately define impacted areas. These tools assist the identification and mitigation planning for fire departments and emergency responders during hazardous chemical releases. However, in order for these agencies to take appropriate actions, including ordering evacuation or sheltering-in-place, the agency must be able to achieve prompt community notification. Unfortunately, community notice of evacuation and sheltering-in-place, can only be achieved by broadcast notification and/or door to door notification. However, as noted above, broadcasting requires the attention of local citizenry, and furthermore, door-to-door notification is time consuming and potentially dangerous to emergency personnel.

0013As has been shown, current reliance upon local media and supplemental NWR broadcasts are insufficiently effective in notifying individuals when danger threatens life or property. Citizens must always have their TV on and they must be watching; or their radio must be turned on and they must be listening for a broadcast alert to be effective. There is thus a compelling need for an alert notification system that is designed to always be available whenever the need arises, a notification system that can not be turned off (short of termination of service). This system should not require the notification recipient purchase any additional equipment and the system should deliver an alert signal with which we have all been instinctively trained to respond. It is also important that the alert notification system have the ability to pinpoint, calculate and define dynamically all recipients with respect to their notification requirements then systematically notify those individuals (and only those individuals) within those defined geographic locations. The system must provide the notification quickly and accurately, with the ability to track the progress of the notification process and provide scenario resolution status until the notification scenario is completed or until the alert has expired.

SUMMARY OF THE INVENTION

0014The invention described in this patent application satisfies these fundamental needs. The invention builds from the recognition that virtually every office and home already includes a communication device that meets the above-stated requirements: it is always turned on, it produces a recognizable alert signal upon remote command, and citizens have been trained to respond to this signal under all circumstances. The device is the telephone. Utilizing principles of the present invention, anyone near to a telephone (including a wired or cellular telephone) can be notified of an emergency or alert that directly threatens or is of interest to him or her.

0015Although the specific embodiment of the invention described below is primarily directed to delivery of warnings via telephone, principles of the present invention are equally applicable to the use of other communications devices which may eventually become as popular as the telephone, such as computer networks, pagers, or other devices.

0016According to principles of the present invention, warnings such as weather or other emergency condition notifications, are provided to interested individuals by selecting from a database, communications identifiers (e.g., telephone/pager/facsimile numbers, computer network addresses such as Internet e-mail addresses or IP addresses), establishing communication connections using the identifiers, and then delivering an appropriate warning via the connection, which may or may not include information about where to find additional information.

0017In one disclosed embodiment, persons are selected in accordance with the physical location of the threat. To provide geographically-based notifications, the system registers the physical location for every communications identifier, based upon (among other possibilities) a county, city, area code, exchange, zip code, and/or global positioning coordinates (GPS). The degree of specificity used depends upon the specificity of the alert to a particular population or location. For example, storms will move with a particular trajectory and speed. A hazardous chemical fire will release a toxic cloud that will follow prevailing winds. The threat of a gas main explosion may require the evacuation notification with a specific mileage radius around one GPS coordinate or street address.

0018While the specific embodiment of the invention described below is primarily directed to geographically-based selection of communications identifiers, based upon identification of atmospheric conditions such as weather, toxic releases or other air quality conditions, principles of the present invention are equally applicable to delivering other kinds of warnings. For example, warnings of school closures, traffic conditions and other closures, interruptions or schedule changes can also be provided to interested parties in accordance with principles of the present invention. In such cases, the information registered for each communication identifier is sufficient to determine whether that identifier should be warned of a particular event, and when such an event occurs, and appropriate warning is delivered.

0019This system will thus “intelligently” provide notification to selected populations of citizens in a short period of time, based on specific criteria such as the location or type of situation, or the current or predicted movements of a threat. Furthermore, unlike the unsuccessful systems of the past, this system will track the notification process and call recipient responses, so it can then repeatedly attempt to notify all persons or locations until a response is registered, or the emergency expires or terminates based on a specific escalation scenario. This system can target specific locations or specific individuals, or both, based on the type of alert that is being generated. The system tracks every notification, re-contacts failed attempts, automatically executes a specific execution scenario dependent upon the alert requirements and delivers specific emergency information. Importantly, the system leaves uninterested citizens undisturbed, thus avoiding a “Boy Who Cried Wolf” problem.

0020The above and other objects and advantages of the present invention shall be made apparent from the accompanying drawings and the description thereof.

BRIEF DESCRIPTION OF THE DRAWING

0021The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with a general description of the invention given above, and the detailed description of the embodiments given below, serve to explain the principles of the invention.

0022<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of a system in accordance with principles of the present invention, having facilities for detecting alert conditions and distributing alert notifications.

0023<figref idref="DRAWINGS">FIG. 2</figref> is a sample text file from EMWIN Data Stream.

0024<figref idref="DRAWINGS">FIG. 3</figref> is an illustration of the database tables used by the system of <figref idref="DRAWINGS">FIG. 1</figref>, and <figref idref="DRAWINGS">FIGS. 3A through 3C</figref> are detailed illustrations of each of the tables in the database.

0025<figref idref="DRAWINGS">FIG. 4A</figref> is a flow chart of the operations of the Notification Parsing System in accordance with principles of the present invention;

0026<figref idref="DRAWINGS">FIG. 4B</figref> is a flow chart of the operations of the IVR Administrative System in accordance with principles of the present invention;

0027<figref idref="DRAWINGS">FIG. 4C</figref> is a flow chart of the operations of the IVR Subscriber Registration System in accordance with principles of the present invention;

0028<figref idref="DRAWINGS">FIG. 4D</figref> is a flow chart of the operations of the Web Server Administrative System in accordance with principles of the present invention;

0029<figref idref="DRAWINGS">FIG. 4E</figref> is a flow chart of the operations of the Web Subscriber Registration System in accordance with principles of the present invention;

0030<figref idref="DRAWINGS">FIG. 4F</figref> is a flow chart of the operations of the Database Query System in accordance with principles of the present invention;

0031<figref idref="DRAWINGS">FIG. 4G</figref> is a flow chart of the operations of the Web Server in accordance with principles of the present invention;

0032<figref idref="DRAWINGS">FIG. 4H</figref> is a flow chart of the operations of the Switch Host in accordance with principles of the present invention;

0033<figref idref="DRAWINGS">FIG. 5A</figref> is an illustration of a Static Area Notification scenario, and <figref idref="DRAWINGS">FIG. 5B</figref> is an illustration of specific operations performed by the Database Query System in handling this scenario;

0034<figref idref="DRAWINGS">FIG. 6A</figref> is an illustration of Radius Notification scenario, and <figref idref="DRAWINGS">FIG. 6B</figref> is an illustration of specific operations performed by the Database Query System in handling this scenario;

0035<figref idref="DRAWINGS">FIG. 7A</figref> is an illustration of Vector Notification scenario, and <figref idref="DRAWINGS">FIG. 7B</figref> is an illustration of specific operations performed by the Database Query System in handling this scenario;

0036<figref idref="DRAWINGS">FIG. 8A</figref> is an illustration of a Shoreline Notification scenario, and <figref idref="DRAWINGS">FIG. 8B</figref> is an illustration of specific operations performed by the Database Query System in handling this scenario;

0037<figref idref="DRAWINGS">FIG. 9A</figref> is an illustration of a River or Flood Plane Notification scenario and <figref idref="DRAWINGS">FIG. 9B</figref> is an illustration of specific operations performed by the Database Query System in handling this scenario;

0038<figref idref="DRAWINGS">FIG. 10A</figref> is an illustration of a Wind Dispersion Notification scenario and <figref idref="DRAWINGS">FIG. 10B</figref> is an illustration of specific operations performed by the Database Query System in handling this scenario.

0039<figref idref="DRAWINGS">FIG. 11</figref> is an illustration of specific operations performed by the Database Query System in handling a School/Organization alert.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

0040<figref idref="DRAWINGS">FIG. 1</figref> illustrates an alert notification system in accordance with the principles of the present invention. At the core of alert notification system <b>100</b> is a network of computers connected via computer network connection <b>102</b>.

0041The computers on network <b>102</b> include a database server <b>104</b> for storing a database of information detailed below in connection with <figref idref="DRAWINGS">FIGS. 3</figref>, <b>3</b>A, <b>3</b>B and <b>3</b>C. This database is utilized by other systems on network <b>102</b> to evaluate alerts and to deliver alert notifications to appropriate persons.

0042Connected to database server <b>104</b> via network <b>102</b> are three additional computers. The first computer system is a Notification Parsing System <b>106</b>, which is connected to a receiver <b>108</b> that receives continuous data feeds from a satellite <b>109</b> and/or is connected to a radio receiver (e.g., an FM receiver <b>110</b>) that receives continuous data feeds from a radio transmitter <b>111</b>. Notification parsing system <b>106</b> may be programmed to evaluate notifications delivered by any one of a variety of organizations via any one of a variety of communications mechanisms. For example, in addition to satellite and radio broadcasts, NPS <b>106</b> may also receive information via Internet dissemination. In the following description of an embodiment of the present invention, NPS <b>106</b> is responsible for receiving National Weather Service EMWIN data streams reporting weather conditions and other critical information. As further data streams become available via satellite, radio or Internet media, these additional data streams may be parsed by NPS <b>106</b> in a manner analogous to that described below.

0043Computer network <b>102</b> is also connected to a database query system <b>112</b>. Database query system <b>112</b> interacts with database server <b>104</b> in response to messages received from other computers, to evaluate alert conditions and determine appropriate recipients of alert information. Database query system <b>112</b> receives data packets from notification parsing system <b>106</b> and from a web server <b>114</b> connected to the Internet <b>115</b>, and from an IVR system <b>116</b> that can be contacted from remote telephones <b>117</b>. These data packets take the form shown in Table I.

0044<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="63pt" align="center" /><colspec colname="3" colwidth="56pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" rowsep="1">TABLE I</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Field Name</entry><entry>Size</entry><entry>Format</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Notification Event</entry><entry>9</entry><entry>Numeric</entry></row><row><entry /><entry>Notification ID</entry><entry>4</entry><entry>Numeric</entry></row><row><entry /><entry>Priority Level</entry><entry>2</entry><entry>Numeric</entry></row><row><entry /><entry>State</entry><entry>2</entry><entry>Character</entry></row><row><entry /><entry>County</entry><entry>3</entry><entry>Numeric</entry></row><row><entry /><entry>City</entry><entry>3</entry><entry>Numeric</entry></row><row><entry /><entry>Zip Code</entry><entry>9</entry><entry>Numeric</entry></row><row><entry /><entry>Expiration Time</entry><entry>8</entry><entry>Time</entry></row><row><entry /><entry>Expiration Date</entry><entry>8</entry><entry>Date</entry></row><row><entry /><entry>Location Zip Code</entry><entry>9</entry><entry>Numeric</entry></row><row><entry /><entry>Location Latitude</entry><entry>9</entry><entry>Float</entry></row><row><entry /><entry>Location Longitude</entry><entry>9</entry><entry>Float</entry></row><row><entry /><entry>Radius</entry><entry>3</entry><entry>Numeric</entry></row><row><entry /><entry>GPS Coordinates</entry><entry>9</entry><entry>Numeric</entry></row><row><entry /><entry>Heading</entry><entry>3</entry><entry>Numeric</entry></row><row><entry /><entry>Speed</entry><entry>3</entry><entry>Numeric</entry></row><row><entry /><entry>Timeframe</entry><entry>3</entry><entry>Numeric</entry></row><row><entry /><entry>Bands</entry><entry>2</entry><entry>Numeric</entry></row><row><entry /><entry>School/Organization ID</entry><entry>9</entry><entry>Numeric</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0045As seen in Table I, data packets include a variety of fields each for identifying particular information. Notification event is a nine byte field holding a numeric value indicating the type of notification that is being delivered. Notification ID is a four byte field holding a numeric value uniquely identifying the notification so that it can be distinguished from others of the same type. Each notification event, therefore, can be uniquely identified and tracked through archived information, as discussed further below. Priority level is a two byte field storing a numeric value indicating the priority of the notification. All notifications will include notification event, notification ID and priority level values. Furthermore, all alerts will include an expiration time value in an expiration time field, stored as an eight byte time formatted value. Furthermore, all alerts will include an expiration date stored in an expiration date field, stored as an eight byte date formatted value.

0046The additional fields shown in Table I, are used to specifically identify the location or circumstances of the alert, and may not all be used in any given alert. A State field includes two bytes of characters, providing a state code for the location of the event. A County field includes a three byte numeric value identifying a particular county. A City field includes a three byte numeric value identifying a city, and a Zip code field includes a nine byte numeric value identifying a zip code. An alert relating to a specific geographic location, such as a static area alert, will include one of a state, county, city or zip code value which will geographically reference the static area to which the alert applies.

0047Radius alert events are identified by reference to a specific geographic location and radius surrounding that location. For these events, a latitude and longitude will be stored in a location latitude field and a location longitude field, both of which carry nine byte floating point numeric values. As an alternative to a latitude and longitude, a radius event may store global positioning system (GPS) coordinates as a nine byte numeric value in a GPS coordinates field. Radius events will also store a radius value in a radius field as a three byte numeric value.

0048Vector alerts identify an area to be alerted utilizing a vectorized description of the location of the condition. These alerts will identify a heading in three byte numeric heading field, a speed in three byte numeric speed field and a time frame in a three byte numeric time frame field. Furthermore, for the purposes of processing these alert conditions, vector related alerts will also identify a number of bands used in processing the alert; this number of bands will be stored as a two byte numeric value. Vector related alerts will also include location information, for example, one of a zip code, latitude and longitude or GPS coordinate value.

0049Shoreline or river related alert notifications will carry information similar to static area alert notifications, i.e., a state, county, city and zip code identity.

0050A last category of alert is a school/organization alert, used to notify students/parents of a school cancellation/emergency or analogously notify members of an organization of a cancellation/emergency or schedule change. To facilitate such alerts, a School/Organization ID field holds a nine byte numeric value identifying a school (or school district) or organization. A school or organization related alert will identify the subscribers needing notification, using the school/organization ID number stored in this field.

0051Alerts are received by database query system <b>112</b> through a variety of channels and take different forms. Weather related alerts including flood alerts and other alert conditions identified by the National Weather Service are provided by notification parsing system <b>106</b> to database query system <b>112</b>.

0052Referring to <figref idref="DRAWINGS">FIG. 2</figref>, it can be seen that a text file <b>118</b> produced from the EMWIN data stream includes a number of fields that can be readily parsed by notification parsing system <b>106</b>. The first line “WFUS1 KIWX 010238” is a “WMO” header that includes a 4-6 character product identifier, a 4 character source site code, and a GMT formatted 6-digit origination time. The subsequent lines of the EMWIN data stream include text information and codes, as well as, in some cases, graphic files and other data. Detailed information on the format of the EMWIN data streams is available from NOAA, e.g. from the URL http://www.nws.noaa.gov/oso/cominfo.shtml.

0053Each EMWIN file includes prefix codes identifying a particular event that is the subject of the notification. As can be seen in <figref idref="DRAWINGS">FIG. 2</figref>, the notification code of TOR <b>120</b> in the second line of the file, is used to identify a tornado warning. Notification parsing system <b>106</b> identifies this product code and uses it to generate an appropriate packet utilizing the format of Table I. Notification parsing system <b>106</b> also parses the remainder of the text file to identify geographic locations. These may be coded using “Universal Generic Code”, e.g., including the county identifiers INC141 and INC099 (or the subsequent text <b>122</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>, which identify St. Joseph County and Marshall County in north central Indiana. County identifiers are coded using the Federal Information Processing Standard (FIPS 6-3), under which each county has a 3-digit identifier. The identified county information can be enhanced by parsing the subsequent text, which as shown at <b>122</b> indicates that the alert condition is specifically for southwestern St. Joseph County and extreme northwestern Marshall County.

0054Furthermore, notification parsing system <b>106</b> may identify heading information such as, at <b>124</b>, the text indicating that the tornado is moving northeast at 40 mph. The alert time and alert ending time information, available in GMT format (“010238” and “010305”), and in a text format, can be used to identify a time period for the alert. Notification parsing system <b>106</b> may also utilize the listing of affected towns at <b>126</b> to identify zip codes of those locations and thereby produce alert notifications based upon zip codes. Furthermore, the body of the NWS message may also be inserted into a facsimile message, sent as an electronic mail message, read via a computer-generated voice over the telephone, or forwarded to a text pager.

0055Table II, appearing below, summarizes the prefix codes utilized in EMWIN data streams and the meanings of those prefix codes. Each particular type of alert will be converted to alert messages if an appropriate type can be gleaned from one or a collection of EMWIN data stream segments.

0056<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE II</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Prefix</entry><entry>Name</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>AFD</entry><entry>Area Forecast Discussion</entry></row><row><entry /><entry>AIR</entry><entry>Upper Air (Data)</entry></row><row><entry /><entry>APT</entry><entry>Polar Orbiter Images</entry></row><row><entry /><entry>ASH</entry><entry>Volcanic/FIRE Warnings and reports</entry></row><row><entry /><entry>AWS</entry><entry>Area Weather Summary</entry></row><row><entry /><entry>CEM</entry><entry>Civil Emergency Message</entry></row><row><entry /><entry>CFW</entry><entry>Coastal Flood Warning</entry></row><row><entry /><entry>CHT</entry><entry>Charts DIFAX/WEFAX</entry></row><row><entry /><entry>CLI</entry><entry>Climate Reports</entry></row><row><entry /><entry>CMP</entry><entry>Composite Images(CMPALLUS.GIF)</entry></row><row><entry /><entry>CMP</entry><entry>Compressed Files (CMPMxxxx.ZAG)</entry></row><row><entry /><entry>CWF</entry><entry>Coastal Waters Forecast</entry></row><row><entry /><entry>DY1</entry><entry>Day One Convective Outlook</entry></row><row><entry /><entry>DY2</entry><entry>Day Two Convective Outlook</entry></row><row><entry /><entry>ELN</entry><entry>El ‘Nino images</entry></row><row><entry /><entry>EMA</entry><entry>Emergency manager activation msg.</entry></row><row><entry /><entry>EML</entry><entry>Email (wireless)</entry></row><row><entry /><entry>EPH</entry><entry>Ephemeris data for satellite orbits</entry></row><row><entry /><entry>EQR</entry><entry>Earthquake Data</entry></row><row><entry /><entry>ESF</entry><entry>Flood Potential</entry></row><row><entry /><entry>ESS</entry><entry>Water Supply Forecast</entry></row><row><entry /><entry>FAA</entry><entry>Aviation Reports (Pilot briefs)</entry></row><row><entry /><entry>FEE</entry><entry>Feedback to all users</entry></row><row><entry /><entry>FFW</entry><entry>Flash Flood Warning</entry></row><row><entry /><entry>FFA</entry><entry>Flash Flood Advisory</entry></row><row><entry /><entry>FFS</entry><entry>Flash Flood Statement</entry></row><row><entry /><entry>FLN</entry><entry>National Flood Summary</entry></row><row><entry /><entry>FLW</entry><entry>Flood Warning</entry></row><row><entry /><entry>FWF</entry><entry>Fire Weather Forecast</entry></row><row><entry /><entry>GLF</entry><entry>Great Lakes Forecast</entry></row><row><entry /><entry>GLO</entry><entry>Great Lake Outlook</entry></row><row><entry /><entry>GLS</entry><entry>Great Lakes Summary</entry></row><row><entry /><entry>GMS</entry><entry>GMS Satellite Images</entry></row><row><entry /><entry>GO9</entry><entry>GOES 9 Satellite Images</entry></row><row><entry /><entry>G10</entry><entry>GOES 10 Satellite Images</entry></row><row><entry /><entry>GPH</entry><entry>Graphic Files (AFOS Graphics)</entry></row><row><entry /><entry>HAA</entry><entry>Hurricane Probabilities Atlantic</entry></row><row><entry /><entry>HAD</entry><entry>Hurricane Discussion Atlantic</entry></row><row><entry /><entry>HAF</entry><entry>Hurricane Forecast Advisory Atlantic</entry></row><row><entry /><entry>HAM</entry><entry>Hurricane NCEP Model Comparison Atlantic</entry></row><row><entry /><entry>HAP</entry><entry>Hurricane Public Advisory Atlantic</entry></row><row><entry /><entry>HAS</entry><entry>Hurricane Monthly Summary Atlantic</entry></row><row><entry /><entry>HAT</entry><entry>NCEP Tropical Discussion Atlantic</entry></row><row><entry /><entry>HAW</entry><entry>Tropical Weather Outlook Atlantic</entry></row><row><entry /><entry>HEA</entry><entry>Hurricane Probabilities East Pacific</entry></row><row><entry /><entry>HED</entry><entry>Hurricane Discussion East Pacific</entry></row><row><entry /><entry>HEF</entry><entry>Hurricane Forecast Advisory East Pacific</entry></row><row><entry /><entry>HEM</entry><entry>Hurricane NCEP Model Comparison East Pacific</entry></row><row><entry /><entry>HEP</entry><entry>Hurricane Public Advisory East Pacific</entry></row><row><entry /><entry>HES</entry><entry>Hurricane Monthly Summary East Pacific</entry></row><row><entry /><entry>HET</entry><entry>NCEP Tropical Discussion East Pacific</entry></row><row><entry /><entry>HEW</entry><entry>Tropical Weather Outlook East Pacific</entry></row><row><entry /><entry>HFF</entry><entry>High Seas Forecast</entry></row><row><entry /><entry>HLS</entry><entry>Hurricane Local Statement</entry></row><row><entry /><entry>HNA</entry><entry>Hurricane Probabilities North Pacific</entry></row><row><entry /><entry>HND</entry><entry>Hurricane Discussion North Pacific</entry></row><row><entry /><entry>HNF</entry><entry>Hurricane Forecast Advisory North Pacific</entry></row><row><entry /><entry>HNM</entry><entry>Hurricane NCEP Model Comparison North Pacific</entry></row><row><entry /><entry>HNP</entry><entry>Hurricane Public Advisory North Pacific</entry></row><row><entry /><entry>HNS</entry><entry>Hurricane Monthly Summary North Pacific</entry></row><row><entry /><entry>HNT</entry><entry>NCEP Tropical Discussion North Pacific</entry></row><row><entry /><entry>HNW</entry><entry>Tropical Weather Outlook North Pacific</entry></row><row><entry /><entry>HSA</entry><entry>Hurricane Probabilities South Pacific</entry></row><row><entry /><entry>HSD</entry><entry>Hurricane Discussion South Pacific</entry></row><row><entry /><entry>HSF</entry><entry>Hurricane Forecast Advisory South Pacific</entry></row><row><entry /><entry>HSM</entry><entry>Hurricane NCEP Model Comparison South Pacific</entry></row><row><entry /><entry>HSP</entry><entry>Hurricane Public Advisory South Pacific</entry></row><row><entry /><entry>HST</entry><entry>NCEP Tropical Discussion South Pacific</entry></row><row><entry /><entry>HSS</entry><entry>Hurricane Monthly Summary South Pacific</entry></row><row><entry /><entry>HSW</entry><entry>Tropical Weather Outlook South Pacific</entry></row><row><entry /><entry>HWA</entry><entry>Hurricane Probabilities West Pacific</entry></row><row><entry /><entry>HWD</entry><entry>Hurricane Discussion West Pacific</entry></row><row><entry /><entry>HWF</entry><entry>Hurricane Forecast Advisory West Pacific</entry></row><row><entry /><entry>HWM</entry><entry>Hurricane NCEP Model Comparison West Pacific</entry></row><row><entry /><entry>HWP</entry><entry>Hurricane Public Advisory West Pacific</entry></row><row><entry /><entry>HWS</entry><entry>Hurricane Monthly Summary West Pacific</entry></row><row><entry /><entry>HWT</entry><entry>Hurricane NCEP Tropical Discussion West Pacific</entry></row><row><entry /><entry>HWU</entry><entry>Hazardous Weather Update</entry></row><row><entry /><entry>HWW</entry><entry>Tropical Weather Outlook West Pacific</entry></row><row><entry /><entry>HTM</entry><entry>HTML Documents</entry></row><row><entry /><entry>ICE</entry><entry>Ice Statement</entry></row><row><entry /><entry>IMG</entry><entry>General Images (IMGALLUS.GIF)</entry></row><row><entry /><entry>INT</entry><entry>International Overviews</entry></row><row><entry /><entry>LFP</entry><entry>Local Forecast</entry></row><row><entry /><entry>LGT</entry><entry>Lightning Images</entry></row><row><entry /><entry>LSH</entry><entry>Lake Shore Forecast</entry></row><row><entry /><entry>LSR</entry><entry>Local Storm Report</entry></row><row><entry /><entry>MET</entry><entry>Meteosat Images</entry></row><row><entry /><entry>MIS</entry><entry>Miscellaneous Products</entry></row><row><entry /><entry>MOD</entry><entry>Model Run Images</entry></row><row><entry /><entry>MWS</entry><entry>Marine Weather Statement</entry></row><row><entry /><entry>NAH</entry><entry>Agriculture Products (Intn'l/National)</entry></row><row><entry /><entry>NSH</entry><entry>Near Shore Forecast</entry></row><row><entry /><entry>NOW</entry><entry>NOWcasts (Short Term Forecast)</entry></row><row><entry /><entry>NPW</entry><entry>Non-precipitation Warning</entry></row><row><entry /><entry>NWX</entry><entry>National Weather Summary</entry></row><row><entry /><entry>OFF</entry><entry>Offshore Forecast</entry></row><row><entry /><entry>OMR</entry><entry>Other/Offshore Marine Reports</entry></row><row><entry /><entry>PAA</entry><entry>Pager Messages</entry></row><row><entry /><entry>PNS</entry><entry>Public Information Statements</entry></row><row><entry /><entry>PRO</entry><entry>Propagation Reports</entry></row><row><entry /><entry>PSR</entry><entry>Post Storm Report</entry></row><row><entry /><entry>RAD</entry><entry>Radar Images (RADALLUS.GIF)</entry></row><row><entry /><entry>REC</entry><entry>Recreation Forecasts</entry></row><row><entry /><entry>RER</entry><entry>Record Event Reports</entry></row><row><entry /><entry>RFW</entry><entry>Red Flag Warning (Fire Warning)</entry></row><row><entry /><entry>RVA</entry><entry>River Summary</entry></row><row><entry /><entry>RVR</entry><entry>River Forecast</entry></row><row><entry /><entry>RVS</entry><entry>River Statement</entry></row><row><entry /><entry>RWS</entry><entry>Regional Weather Summary</entry></row><row><entry /><entry>SAH</entry><entry>Surface Observations (Data)</entry></row><row><entry /><entry>SAO</entry><entry>SAORCMUS.TXT Contains RCM's</entry></row><row><entry /><entry>SAW</entry><entry>Selected Area Watches</entry></row><row><entry /><entry>SCS</entry><entry>Selected cities (scs11-scs14)</entry></row><row><entry /><entry>SEL</entry><entry>Watch areas</entry></row><row><entry /><entry>SES</entry><entry>Seismic/Earthquake Images</entry></row><row><entry /><entry>SFD</entry><entry>State Forecast Discussion</entry></row><row><entry /><entry>SFP</entry><entry>State Forecast</entry></row><row><entry /><entry>SHP</entry><entry>Live Ship Reports</entry></row><row><entry /><entry>SIX</entry><entry>Six to Ten day outlook</entry></row><row><entry /><entry>SLS</entry><entry>Areal update</entry></row><row><entry /><entry>SKY</entry><entry>SKYWARN Activation Message</entry></row><row><entry /><entry>SMW</entry><entry>Special Marine Warning</entry></row><row><entry /><entry>SPS</entry><entry>Special Weather Statement</entry></row><row><entry /><entry>STP</entry><entry>State Temp &amp; Precip Reports</entry></row><row><entry /><entry>SUM</entry><entry>State Weather Summary</entry></row><row><entry /><entry>SVR</entry><entry>Severe Thunderstorm Warning</entry></row><row><entry /><entry>SVS</entry><entry>Severe Weather Statement</entry></row><row><entry /><entry>SWO</entry><entry>Severe Weather Outlook</entry></row><row><entry /><entry>SWR</entry><entry>State Weather Roundup</entry></row><row><entry /><entry>SWX</entry><entry>Space Weather (solar activity)</entry></row><row><entry /><entry>SYS</entry><entry>System messages</entry></row><row><entry /><entry>TAF</entry><entry>Aviation Terminal Forecasts/airports</entry></row><row><entry /><entry>TID</entry><entry>Tide Data</entry></row><row><entry /><entry>TOR</entry><entry>Tornado Warning</entry></row><row><entry /><entry>TRK</entry><entry>Tracking Files (storm tracks)</entry></row><row><entry /><entry>TSU</entry><entry>Tsunami</entry></row><row><entry /><entry>TVL</entry><entry>Travelers Forecasts</entry></row><row><entry /><entry>UVI</entry><entry>National Ultra-Violet index</entry></row><row><entry /><entry>WSW</entry><entry>Winter Storm Warning</entry></row><row><entry /><entry>WWA</entry><entry>Weather Watch</entry></row><row><entry /><entry>ZFP</entry><entry>Zone Forecast</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0057Returning now to <figref idref="DRAWINGS">FIG. 1</figref>, in addition to the EMWIN system, alert conditions may also be identified by individuals authorized to initiate the delivery of alerts through the alert notification system <b>100</b>. Authorized individuals may include civil defense authorities in the case of civil emergencies, school administrators in the case of school related alerts, and managerial employees of business or community organizations that wish to utilize the system of <figref idref="DRAWINGS">FIG. 1</figref> via organization alerts.

0058Alerts initiated by these authorized individuals may be delivered to the system <b>100</b> via an interactive voice response system <b>116</b> which can be accessed via any telephone. Alerts may also be delivered via an Internet connection, for example using a World Wide Web browser connected via hypertext transfer protocol (HTTP). In this case, connections are made through the Internet to web server <b>114</b> to generate an alert message.

0059Alerts generated using web server <b>114</b> or IVR server <b>116</b> are delivered to database query system <b>112</b> through packets which are also formatted in accordance with Table I. Database query system <b>112</b> then identifies subscribers to be individually alerted, and then alert notifications are delivered to subscribers, via telephone, via facsimile, via electronic mail or via other electronic communications.

0060Telephone and facsimile alerts are delivered to subscribers through a switch host computer <b>130</b> and a host controllable switch <b>132</b>. Switch host computer <b>130</b> is connected to host controllable switch <b>132</b>. Switch <b>132</b> is a host controllable switch that interfaces with digital telephone lines <b>134</b> of a telecommunications carrier to permit outbound telephone calls to be generated at a high volume, to be delivered to subscribers to the system <b>100</b>. Outbound telephone calls from host controllable switch <b>132</b> are routed through the public switched telecommunications network <b>136</b> to telephones subscribed in system <b>100</b>, such as wired telephones at private homes and businesses, as well as cellular telephones. Outbound telephone calls from host controllable switch <b>132</b> may also connect to facsimile machines to deliver facsimile alert messages.

0061As can be seen in <figref idref="DRAWINGS">FIG. 1</figref>, switch host <b>130</b> and host controllable switch <b>32</b> can be utilized to handle multiple alerts from multiple locations simultaneously. As can been seen in <figref idref="DRAWINGS">FIG. 1</figref>, an evacuation alert using a radius pattern is being delivered to a region <b>140</b> in the state of Washington; simultaneously, an alert related to an earthquake warning is being delivered to a region <b>142</b> in the state of California; a radiation leak wind dispersion alert is being delivered to a region <b>144</b> in the state of Texas; a flood or high wave condition alert is being delivered to a shoreline region <b>146</b> in the state of Florida; a weather alert is being delivered to a region <b>148</b> in the state of Ohio; and a biohazard related alert is being delivered to a region <b>150</b> in upstate New York.

0062The system illustrated in <figref idref="DRAWINGS">FIG. 1</figref> is scalable such that any quantity of alerts to any geographic regions can be handled by simply enhancing the capacity of host controllable switch <b>132</b>. Such enhancement is within the knowledge of those of skill in the art of telephony. Accordingly, a nationwide or even global alert notification system can be implemented at a single geographic location using the principles of the present invention.

0063To ensure high reliability and robustness, in accordance with the principles of the present invention, the system <b>100</b> may be redundantly positioned at multiple geographical locations. Thus a second redundant real time tandem system <b>100</b>′ with an analogous configuration, may be located at a separate geographic location and connected via a point to point data connection <b>160</b> to the system <b>100</b> illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. Systems <b>100</b> and <b>100</b> are in continuous communication over point to point link <b>160</b> to insure that all alert notifications are received by both systems, and thereafter one system is tasked with handling each notification. The systems also continuously communicate to maintain synchronization of the databases handled by the respective database servers of the respective systems. In the event of a failure at one of the tandem systems, all existing requests for alert notification will be handled by the other system to insure that the alerts are delivered appropriately in spite of the network failure.

0064As noted above, telephone and facsimile communications are delivered to telephone and facsimile machines via host controllable switch <b>132</b>. Alert notifications may also be delivered via electronic mail or other Internet communication methodologies. In this case, the alert notification is handled by web server <b>114</b>. In such a scenario, database query system <b>112</b> instructs web server <b>114</b> to deliver the alert notification, and in response web server <b>114</b> connects via its Internet connection to the appropriate location to deliver the alert.

0065Table III, which appears below, illustrates the format of packets transferred from database query system <b>112</b> to switch host <b>130</b> and web server <b>114</b> to cause an alert to be delivered.

0066<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="77pt" align="center" /><colspec colname="3" colwidth="63pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" rowsep="1">TABLE III</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Field Name</entry><entry>Size</entry><entry>Format</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="77pt" align="char" char="." /><colspec colname="3" colwidth="63pt" align="left" /><tbody valign="top"><row><entry /><entry>Priority Level</entry><entry>2</entry><entry>Numeric</entry></row><row><entry /><entry>Notification Event</entry><entry>9</entry><entry>Numeric</entry></row><row><entry /><entry>Station ID</entry><entry>30</entry><entry>Character</entry></row><row><entry /><entry>Station ID Type</entry><entry>2</entry><entry>Numeric</entry></row><row><entry /><entry>Message ID 1</entry><entry>4</entry><entry>Numeric</entry></row><row><entry /><entry>Message ID 2</entry><entry>4</entry><entry>Numeric</entry></row><row><entry /><entry>Message ID 3</entry><entry>4</entry><entry>Numeric</entry></row><row><entry /><entry>Message ID 4</entry><entry>4</entry><entry>Numeric</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0067As seen in Table III, packets sent from database query system <b>112</b> include fields for specifically identifying the recipient of an alert and the type of the alert. The first field, “priority level” includes a two byte numeric value indicating a relative priority of the alert message. This value is derived from priorities assigned to alerts delivered to database query system <b>112</b> by notification parsing system <b>106</b> or web server/IVR system <b>114</b>, <b>116</b>. A second field, “notification event”, includes a nine byte numeric value having a numeric code for the type of alert that is being delivered. A third field, “station ID” includes a 30 byte character value that identifies the recipient of the alert notification. In the event that the alert is being delivered via telephone or facsimile, the station ID field will include a telephone number. In the event that the alert is being delivered via electronic mail or the Internet, the station ID will include an electronic mail address or a uniform resource location (URL) indicating where the alert is to be delivered. A “station ID type” field includes a two byte numeric value identifying the type of station ID that is provided in the preceding field. Thus alerts to telephones can be distinguished from alerts to facsimile machines, from alerts to electronic mail addresses and from alerts to other IP or similar computer network addresses.

0068After these fields are four message ID fields, each of which is a four byte numeric value. These fields contain a code for a message to be delivered to the subscriber/recipient of the alert. Multiple messages may be delivered simultaneously; to facilitate this, four message IDs may be supplied in single packet as illustrated in Table III. The message IDs may be an index usable by host controllable switch <b>132</b> to retrieve a voice message to be delivered via telephone, or may be an index to a prestored facsimile message to be delivered to a facsimile machine. In the case of alert notifications to be delivered to email or Internet addresses, each message ID will be an index to prestored text for the email message or prestored text or other actions to be performed at a web site or other resource accessible via the uniform resource locator.

0069Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, the databases utilized by the system of <figref idref="DRAWINGS">FIG. 1</figref> are generally illustrated. These databases are stored and managed by database server <b>104</b>. Notification parsing system <b>106</b> and database query system <b>112</b> retrieve data from these databases as needed to perform the functions discussed generally above and elaborated below.

0070Tables <b>170</b> and <b>172</b> managed by database server <b>104</b> are used by notification parsing system <b>106</b> in parsing EMWIN data streams from the National Weather Service. The notification parsing system <b>106</b> parses data received from these data feeds to identify text, graphic and image files. Each file is then processed to determine its file type. The file types listed in Table I are stored in notification table <b>170</b>.

0071The detailed format of notification table <b>170</b> is shown in <figref idref="DRAWINGS">FIG. 3A</figref>. Each record of the notification table <b>170</b> includes a product ID field <b>174</b> which is a three byte character value in the formats shown in Table I above. A second field <b>176</b> stores a two byte numeric value identifying a priority level for the product or event type represented by the record. A third field <b>178</b> stores a 4 byte numeric value providing a notification identifier associated with the product represented by the record. The notification identifier maps to one of the predefined notifications handled by the system, and is used when delivering a corresponding packet in the format illustrated in Table II from the notification parsing system to the database query system.

0072<figref idref="DRAWINGS">FIG. 3B</figref> illustrates a priority table <b>172</b> which provides specific information about priority levels identified in field <b>176</b> of the notification table <b>170</b>. Each record in the priority table <b>172</b> includes a priority level field <b>180</b> for storing a two byte numeric value identifying a priority level. Each priority table record includes a resource utilization field <b>182</b> for storing a percentage value indicating the amount of resources of the system that are to be consumed for an alert at the identified priority level. The resource utilization percentage identified in field <b>182</b> is used in determining the extent to which a given alert should be allowed to consume all of the computational resources of database query system <b>112</b> and/or switch host <b>130</b> and line capacity of host controlled switch <b>132</b>.

0073<figref idref="DRAWINGS">FIG. 3</figref> also illustrates a variety of subscriber related tables <b>184</b>, <b>186</b>, <b>188</b>, <b>190</b>, <b>192</b> and <b>194</b>. These tables are used to store information relating to subscribers to permit database query system <b>112</b> to identify specific subscribers to receive alert notifications in response to packets received from web server <b>114</b>, IVR system <b>116</b> or notification parsing system <b>106</b>.

0074Referring now to <figref idref="DRAWINGS">FIG. 3C</figref>, the schema of these tables <b>184</b>-<b>194</b> can be viewed in detail.

0075The subscriber information table <b>184</b> includes information regarding a subscriber that is useful for determining whether that subscriber should be notified of an alert condition. Each record in the subscriber information table <b>184</b> includes a field <b>200</b> providing a customer number or customer identifier for this subscriber. This unique identifier is used to link information about a subscriber in table <b>184</b> to information about the same subscriber in the other tables <b>186</b>, <b>188</b>, <b>190</b>, <b>192</b> and <b>194</b>. Subscriber information table <b>184</b> also includes extensive information regarding the subscriber to be used in contacting the subscriber. For example, a field <b>202</b> is used to store a telephone number or ANI used to contact the subscriber. A field <b>204</b> includes an electronic mail address for the subscriber. A field <b>206</b> includes an Internet, i.e., TCP/IP address for the subscriber. Typically a subscriber will have only one mode of contact, i.e., only one of the three fields <b>202</b>, <b>204</b> and <b>206</b> will include a value. However, a subscriber may also have multiple modes of contact registered (see table <b>192</b>, discussed below) in which case the appropriate mode of contact is chosen based upon the priority of the alert, the type of the alert or subscriber preferences.

0076Continuing on the subscriber information table <b>184</b>, the table includes fields for identifying information regarding the subscriber that can be used to determine whether the subscriber ought to be notified of a given alert condition. These fields include a field <b>208</b> for storing a postal zip code for the subscriber, a field <b>210</b> for storing the county identifier for the subscriber, a field <b>212</b> for storing a state identifier for the subscriber and a field <b>214</b> and a field <b>216</b> for identifying a latitude and longitude for the subscriber. Fields <b>208</b> through <b>216</b> identify at varying levels of specificity the geographic location of the subscriber so that the subscriber can be selected for receipt of a notice under the appropriate conditions. Other information may also be used to determine whether a subscriber should be contacted. For example, a school district name and a school organization ID are stored in fields <b>218</b> and <b>220</b> to affiliate the subscriber with a school or organization that may need to inform pupils or organization members of cancellations or changes utilizing the alert notification system of the present invention. A field <b>222</b> is used to store an elevation at the subscriber's location and a field <b>224</b> is used to store a flood zone code for the subscriber. These fields will be used to identify whether the subscriber is subject to alert notifications relating to floods or weather conditions that only affect certain elevations or flood zones. A field <b>226</b> may also be used to classify the location of the subscriber in other ways, for example nearness to open space or trees where wind damage may be more likely, or location within an office building at which shelter may be more difficult to find. A field <b>228</b> includes coding relating to the construction of any building associated with the subscriber. A field <b>230</b> is used to identify the number of levels in the building associated with the subscriber. Fields <b>228</b> and <b>230</b> can be used together to prioritize the danger to a subscriber arising from a weather condition or any other condition that may be more dangerous to some forms of building construction or some heights of buildings. A field <b>232</b> is used to generally classify any special needs of the subscriber that may be applicable in determining the priority to be given alerting the subscriber of conditions monitored by the system. These conditions may include the need to use a wheelchair or personal assistance to seek shelter in the basement of the subscriber's location. Fields <b>234</b>, <b>236</b>, <b>238</b> provide an indication of the number of persons potentially at risk at the location identified in the record. Field <b>234</b> provides a count of adults at that location, field <b>236</b> provides a count of the number of elderly persons in that location and field <b>238</b> provides a count of the number of children in that location. Alert notifications may be prioritized to reach the largest population of persons most rapidly or may be prioritized to reach locations where there are children or elderly citizens more rapidly in order to provide the required additional time to take shelter. Additional fields <b>240</b> and <b>242</b> are used to determine whether a subscriber should receive priority for atmospheric condition alerts, or is interested in such alerts at all. Field <b>240</b> indicates that a subscriber has a respiratory condition of the kind that would be affected by ozone alerts or other respiratory-related weather conditions that may adversely impact only those members of the population with respiratory conditions. A field <b>242</b> will be used to identify allergic conditions of persons at this subscriber location such that alert notifications may be provided to indicate the presence of allergens of a particular kind in the atmosphere. A field <b>244</b> indicates whether the subscriber location is capable of receiving broadcasts of weather or other alert information. The subscriber may be placed in a higher priority if the subscriber is not able to receive alert notifications via other broadcast media. The field may also indicate that the subscriber is, itself, a “broadcaster”, i.e., a party that relays alert information to further persons. A “broadcaster” is also provided with enhanced priority to assist in fulfilling broadcast responsibilities and to ensure the greatest number of persons are notified of the alert as soon as possible. Field <b>244</b> may also be used to “brand” the alert notification, e.g. by identifying a broadcast station that sponsors the delivery of the alert notification, so that subscribers develop goodwill for the sponsoring station and turn to that station for additional information. A field <b>246</b> indicates whether a basement is available at the subscriber location aiding and prioritizing subscribers who do not have access to sufficient shelter over other subscribers who do have access to sufficient shelter within their own homes. This, for example, would allow alerts to be delivered first to mobile home parks and other (high risk) areas that are particularly susceptible to other damage. A field <b>248</b> indicates whether the subscriber location has an answering machine and a field <b>250</b> indicates the ring count for the answering machine. These fields are used to avoid leaving a message on an answering machine or voice mail service if there is such a service in use at the subscriber's location. The ring count is used to ensure that the host controlled switch will disconnect prior to reaching the identified number of rings, so that the answering machine or voice mail system will not pick up the line. As a consequence, the subscriber's location will be called repeatedly until an answer is received, thus ensuring that the alert message is delivered to a person rather than to an answering machine or voice mail system.

0077The final two fields <b>252</b> and <b>254</b> are useful in managing the delivery of information to the subscriber. Specifically, field <b>252</b> stores the identifier for the last notification that was provided to the subscriber's location, and can be used as a confirmation that a notification was given to the subscriber with respect to that condition. A retry count found in field <b>254</b> is used to control the number of times a subscriber location is contacted to attempt to deliver emergency information. A subscriber may wish to set a retry count value based upon preference and knowledge of the subscriber's ability to consistently answer telephone calls during a known period of time.

0078The subscriber billing table <b>186</b> stores information used in invoicing a subscriber for services provided by the alert notification system. A field <b>260</b> in the subscriber billing table <b>186</b> is used to store a customer number, i.e., customer identifier for a subscriber to thereby relate the subscriber to the other tables illustrated in <figref idref="DRAWINGS">FIG. 3C</figref>. A subscriber billing table <b>186</b> provides information needed to appropriately bill a subscriber for services provided by the system. These fields include a field <b>262</b> for storing a first name, a field <b>264</b> for storing last name, fields <b>266</b> and <b>268</b> for storing two lines of physical addresses for the subscriber, a field <b>270</b> for a city, a field <b>272</b> for a state and a field <b>274</b> for a zip code. Additional fields are used to provide a billing address if needed for the subscriber including a field <b>276</b> for name, fields <b>278</b> and <b>280</b> for a billing address, a field <b>282</b> for a city, a field <b>284</b> for a state and a field <b>286</b> for a zip code. A field <b>288</b> identifies a billing method preferred by the subscriber, such as advance invoicing or alternatively automatic payments via credit card. A field <b>290</b> identifies the billing period preferred by the subscriber, such as weekly, monthly or annually. Discounts may be provided for prepayment of large subscription periods. Fields <b>292</b> and <b>294</b> identify starting and ending dates for service provided by the system during a current billing period. Fields <b>296</b> and <b>298</b> provide a credit card number and expiration date to be used in billing the subscriber. Fields <b>300</b>, <b>302</b>, <b>304</b> and <b>306</b> provide name and address information for a credit card to be used in billing the subscriber in advance via credit card. This information must be stored to insure payment by the credit card company for charges billed. Fields <b>308</b>, <b>310</b> and <b>312</b> store automated clearinghouse (ACH) information for the customer, which may be used to generate ACH transactions to automatically invoice the customer for payments for services provided by the system.

0079Subscriber census table <b>188</b> stores information relating to persons at the location identified in the subscriber information table <b>184</b>. Subscriber census table records include a field <b>320</b> for storing customer identifier to link the record to subscriber information in subscriber information table <b>184</b>. Subscriber census table <b>188</b> also includes fields <b>322</b> and <b>324</b> for storing a first and last name for a subscriber, and an age field <b>326</b> for storing an age of a subscriber. It will be appreciated that a given subscriber location may be inhabited by multiple persons in which case there are multiple subscriber census table <b>188</b> entries, one for each person, so that information about the multiple persons may be stored and retrieved and used to customize alerts. Furthermore, subscriber census information can be used to provide census data to emergency agencies via telephone, facsimile, e-mail, or other media. This information can facilitate rescue efforts and further define the impact of an emergency condition on local emergency response services. For example, in the case of an explosion, census information can be used to define population impact, aid in targeting the search for survivors, and defining an evacuation scale. For the case of a biohazardous condition, census information can aid in defining the amount of medical services that will be consumed in treating victims.

0080Subscriber notification preferences table <b>190</b> is used to identify preferences of a subscriber with respect to notifications by the system. A field <b>330</b> is used to store a customer identifier to link the preferences identified in table <b>190</b> in the subscriber information table <b>184</b>. Additional fields in the subscriber notification preferences table <b>190</b> include a field <b>332</b> for storing a notification type and fields <b>334</b> and <b>336</b> for identifying a start hour and minute and fields <b>338</b> and <b>340</b> for identifying an ending hour and minute. A record in subscriber notification preferences table <b>190</b> can be used to identify the hours during which an alert notification should be sent to a given subscriber location. Thus, a subscriber may request that atmospheric condition alerts that are not immediately hazardous, such as ozone alerts, not be notified to their home location during the nighttime when residents of the home will be sleeping and not traveling outdoors. It will be noted that each record in subscriber notification preferences table <b>190</b> relates to a particular notification type and a particular subscriber. Thus there may be multiple preference records in table <b>190</b> for a given subscriber, one record for each type of notification for which the subscriber has indicated preferences.

0081Subscriber alternate contact table <b>192</b> is used to provide additional contact information for subscribers. Each record in table <b>192</b> includes a field <b>350</b> for identifying a customer identifier to link the alternate contact information to the subscriber information table for the subscriber. Each record in the subscriber alternate contact table <b>192</b> includes fields <b>352</b>, <b>354</b> and <b>356</b> for identifying a telephone number or ANI, an email address and TCP/IP address. Through the use of alternate contact records in alternate contact table <b>192</b>, multiple contact points may be entered into the database for a given subscriber so that a subscriber may be contacted at, for example, multiple phone numbers at a given location or at a phone number and at a cellular telephone number, or at multiple email addresses.

0082Subscriber history table <b>194</b> is used to store historic information on alerts delivered to a subscriber for the purposes of auditing alerts, and potentially for billing subscribers on an alert basis. Each record in subscriber history table <b>194</b> includes a customer number (customer identifier) field <b>360</b> for linking the record to other subscriber information in the database. Each record also includes additional fields for providing historical information on a type of notification which was delivered or attempted to be delivered to the subscriber. This information includes a date and time stored in fields <b>362</b> and <b>364</b> and a type of notification stored in field <b>366</b>. A notification identifier which uniquely identifies the notification stored in field <b>266</b> is stored in field <b>368</b>. Field <b>370</b> provides a communications address used to attempt to notify the subscriber of the condition, and field <b>372</b> indicates whether the alert was successfully completed. It will be appreciated that a given subscriber may receive multiple alerts from the system over the passage time and therefore a subscriber will have multiple records that will appear in subscriber history table <b>194</b>, one for each alert or attempted alert to the subscriber that has been historically provided. It will also be appreciated that a subscriber history table record will be generated each time an alert is attempted to a subscriber and that record will be updated to indicate whether the attempt was successfully completed and the type identifier and communications addresses used in attempting the alert notification.

0083Referring now to <figref idref="DRAWINGS">FIG. 4A</figref>, the process for parsing EMWIN data feeds at the notification parsing system <b>106</b> can be explained in further detail. In a first step <b>400</b>, the data feeds from FM receiver <b>110</b> and/or satellite receiver <b>108</b> are initialized. Then in step <b>402</b>, notification parsing system <b>106</b> waits for data from the initialized data feed. When data is received, in step <b>404</b> the data is read until an END OF FILE code is reached. (An END OF FILE code can be seen in <figref idref="DRAWINGS">FIG. 2</figref> at the end of the textual information.) In a subsequent step <b>406</b>, the National Weather Service product ID for the feed is determined. This product ID can be seen at <b>120</b> in <figref idref="DRAWINGS">FIG. 2</figref>. In subsequent step <b>408</b> a database record is retrieved from the notification table <b>170</b> of <figref idref="DRAWINGS">FIG. 3A</figref> that has a product ID in field <b>174</b> matching the product ID of the received data. In step <b>410</b> it is determined whether a record exists in the notification table. If not, then in step <b>412</b> the received file is archived and the notification parsing system <b>106</b> returns to step <b>402</b> to wait for additional data.

0084If a record is found in step <b>410</b>, then in step <b>414</b> the received data file is parsed for the notification type and affected area. This will involve pattern matching and text parsing as discussed above with reference to <figref idref="DRAWINGS">FIG. 2</figref>. Subsequently, in step <b>416</b> the file is parsed for an expiration time, current location, heading and speed, if such information is available in the text file. After this information has been collected, in step <b>418</b> a data packet (having the format illustrated in Table I) is generated. All pertinent information that has been obtained from the data stream is included in the data packet. In step <b>420</b> the data packet is sent to the database query system <b>112</b>. Thereafter, in step <b>422</b>, it is determined whether the END OF FILE code has yet been reached. In some cases, multiple products may be compiled in the same text file. When this occurs, processing will return to step <b>414</b> to continue to parse the file for additional notifications. When the END OF FILE is reached in step <b>422</b>, processing returns to step <b>402</b> to wait for additional data.

0085Referring now to <figref idref="DRAWINGS">FIG. 4B</figref>, the processing performed by the IVR administrative system can be explained in further detail. In a first step <b>430</b>, IVR administrative system <b>116</b> waits for a call from a user. In step <b>432</b> a user dials into the IVR administrative system; in response step <b>434</b> the IVR administrative system receives the ANI or caller ID for the caller from the telephone network. In step <b>436</b> the caller is prompted to enter a login identifier and a password using touch tone keys on their touch tone telephone. In step <b>438</b> the ANI, login identifier and password collected in the proceeding steps are compared to those of authorized users of the system. If the ANI, login ID and password combination is not found, then in step <b>440</b> the caller is notified that access is denied, and the connection is terminated. If the caller is authorized, then in step <b>442</b> the caller's login ID is used to determine notification types that the caller is allowed to initiate. In step <b>444</b>, the caller is then prompted for a notification type. The caller will then provide, using DTMF (touch tone) telephone keys, a notification type number. In step <b>446</b> it is determined whether the entered notification type is one that is allowed for the caller. If so, then in step <b>448</b> the caller is prompted for relevant information needed to prepare an alert notification. This information may include a location code, a latitude and longitude, heading and speed information or other information that is relevant to the type of alert that is to be generated. In step <b>450</b> this information is built into a data packet conforming to the format of Table I. Then in step <b>452</b>, the packet is sent to the database query system <b>112</b> for use in generating alerts to the affected subscribers. Thereafter, in step <b>454</b> the caller is prompted for any additional notifications of affected areas, so that the caller may in rapid succession enter a number of alerts or identify a number of affected areas. If the caller, again using DTMF (touch tone) keys, indicates that there are additional notifications or affected areas, processing returns to step <b>444</b> to prompt the caller for those additional notifications. If the caller indicates that there are no more notifications or affected areas, or terminates the connection, then in step <b>456</b> the IVR administrative system <b>116</b> disconnects and then returns to step <b>430</b> to wait for another call.

0086Returning to step <b>446</b>, if the notification type entered by the caller is disallowed, processing continues from step <b>446</b> to step <b>458</b> in which the caller is notified that the caller has entered a disallowed notification type. Processing then continues to step <b>454</b> to permit the caller to enter a new notification if another is desired.

0087Referring now to <figref idref="DRAWINGS">FIG. 4C</figref>, the process performed by IVR subscriber registration system to enroll new subscribers can be described in greater detail. In a first step <b>460</b>, the IVR subscriber registration system waits for a call from a new subscriber. When a subscriber dials into the IVR subscriber registration system in step <b>462</b>, the IVR subscriber registration system responds in step <b>464</b> by receiving the ANI (caller ID) for the caller from the telephone network. Subsequently, the IVR subscriber registration system in step <b>466</b> prompts the caller for all the required information for subscriber information, and the caller delivers this information via DTMF or touch tone data entry. Thereafter, in step <b>468</b> a data packet conforming to Table I is built and submitted to database query system <b>112</b>. This data packet will cause database query system <b>112</b> to issue a test notification to the new subscriber. Thereafter, the IVR subscriber registration system disconnects in step <b>470</b> from and returns to step <b>460</b> to wait for a new call from another new subscriber.

0088Referring now to <figref idref="DRAWINGS">FIG. 4D</figref>, the process performed by web server <b>114</b> in receiving alert notifications can be more fully explained. In the first step <b>480</b>, web server <b>114</b> waits for an Internet connection. In step <b>482</b> a user connects to a web server <b>114</b>, typically using a hypertext transfer protocol (HTTP) application. In step <b>484</b>, web server <b>114</b> receives an Internet protocol (IP) address for the user from the Internet connection. In step <b>486</b>, the user is prompted to enter a login identifier and password via a hypertext markup language (HTML) form, otherwise known as a world wide web-based form. After the user has entered the requested information in step <b>488</b>, the IP address, login ID and password provided by the user are compared to those of authorized users. If this information does not match any authorized user, then in step <b>490</b> the user is notified (via a subsequent HTML page) that access is denied, and the connection to the user's computer is disconnected. If the connection is allowed, then in step <b>492</b> web server <b>114</b> determines the notification text that the user is permitted to create. In step <b>494</b> the user is prompted again, using the web based form, for a notification type. The provided notification type is then evaluated in step <b>496</b> to determine if it is a type allowed by the server for the user. If so, then in step <b>498</b>, additional web based forms are used to prompt the user for relevant information for the notification, such as geographic information, heading and speed information or other information discussed above. In step <b>500</b>, a data packet is generated (using the format of Table I) reflecting the indicated notification type and all provided information. In step <b>502</b> this packet is sent to the database query system <b>112</b>.

0089Returning to step <b>496</b>, if the identification type identified by the user in step <b>494</b> is not permitted to the user, then the user is notified in step <b>504</b> that this notification type is disallowed. After step <b>504</b> or step <b>502</b>, the user is prompted via web based HTML form, to indicate whether additional notifications or affected areas are to be entered. If there are additional areas or notifications, the user may indicate as such by clicking an appropriate area in the displayed form, in which case the user is returned to step <b>494</b> and prompted for another notification type. If the user indicates that no additional notifications or affected areas are needed, then in step <b>508</b> the connection to the user's computer is terminated.

0090Referring to <figref idref="DRAWINGS">FIG. 4E</figref>, the process for subscriber enrollment in the system via web server <b>114</b> can be understood in greater detail. In a first step <b>510</b>, web server <b>114</b> waits for an Internet connection to be made by a new subscriber. When a connection is made (step <b>512</b>), the IP address of the user is received from the Internet (step <b>514</b>) and (step <b>516</b>) the user is prompted to enter required information for subscription to the system utilizing a web based form. The information requested includes (as described with reference to <figref idref="DRAWINGS">FIG. 3C</figref>), home address information, billing information and other safety or alert preference information. After this information has been received and stored by web server <b>114</b>, a data packet (formatted in accordance with Table I) is created in step <b>518</b> and sent to the database query system <b>112</b>. This data packet causes database query system <b>112</b> to initiate a test notification to the newly enrolled subscriber. After this data packet has been set in step <b>518</b>, in step <b>520</b> the Internet connection to the user is disconnected and processing returns to step <b>510</b> to wait for another subscriber to connect to web server <b>114</b>.

0091Referring now to <figref idref="DRAWINGS">FIG. 4F</figref>, greater detail can be provided on the process performed by database query system <b>112</b> in response to data packets from notification parsing system <b>106</b>, web server <b>114</b> and IVR system <b>116</b>. In a first step <b>530</b>, database query system <b>112</b> waits for a data packet formatted in accordance with Table I from the notification parsing system <b>106</b>, IVR system <b>116</b> or web server <b>114</b>. When a packet is received (step <b>532</b>), the packet is evaluated and the type of notification it requests is evaluated. Based upon the type of notification, different actions are performed as explained below with reference to <figref idref="DRAWINGS">FIGS. 5 through 11</figref>. If the notification is a static area notification, then a static area process <b>534</b> is performed as is elaborated below with reference to <figref idref="DRAWINGS">FIGS. 5A and 5B</figref>. If the notification is a radius notification, then a radius process <b>536</b> is performed as elaborated below with reference to <figref idref="DRAWINGS">FIGS. 6A and 6B</figref>. If the notification is a vector notification, then a vector process <b>538</b> is performed as elaborated below with reference to <figref idref="DRAWINGS">FIGS. 7A and 7B</figref>. If the notification is a shoreline notification, then a shoreline process <b>540</b> is performed as described below with reference to <figref idref="DRAWINGS">FIGS. 8A and 8B</figref>. If the notification is a river notification, then a river process <b>542</b> is performed as described below with reference to <figref idref="DRAWINGS">FIGS. 9A and 9B</figref>. If the notification type is a wind dispersion notification, then a wind dispersion process <b>544</b> is performed as described below with reference to <figref idref="DRAWINGS">FIGS. 10A and 10B</figref>. If a school or organization-related alert notification is requested, then a school or organization alert process <b>546</b> is performed as described below with reference to <figref idref="DRAWINGS">FIG. 11</figref>.

0092The processes <b>534</b> through <b>546</b> result in generation of station identifiers to which alert notifications are to be directed. After these processes are complete (step <b>550</b>), a first of the selected station identifiers is selected, and in step <b>552</b> the type of the station identifier is evaluated. If in step <b>554</b> the station identifier is an email address, TCP/IP address, or Internet accessible pager, then in step <b>556</b> a data packet conforming to Table III above, and including the station identifier, is sent to web server <b>114</b> for ultimate delivery to the appropriate address. If in step <b>558</b> the station identifier is a telephone number or a numeric pager number, then in step <b>556</b> a data packet conforming to Table III above is sent to switch host <b>130</b> for subsequent delivery to the telephone or numeric pager number. Thereafter, in step <b>562</b> it is determined whether there is another station identifier that was previously identified in one of the processes <b>534</b> through <b>546</b>. If so, then in step <b>564</b> the next station identifier is selected and processing returns to step <b>552</b> to determine the type of the next station identifier. If in step <b>562</b>, there is no additional station identifiers, then in step <b>566</b> the received data packet which began the process is archived and processing returns to step <b>530</b> to wait for another data packet.

0093Referring now to <figref idref="DRAWINGS">FIG. 4G</figref>, the process performed by web server <b>114</b> in processing data packets received from the database query system <b>112</b> can be further explained. In a first step <b>570</b>, web server <b>114</b> receives data packets from the database query system <b>112</b>. Step <b>570</b> may be performed in background to other steps in <figref idref="DRAWINGS">FIG. 4G</figref> so that receipt data packets may continue while data packets are being processed.

0094When one or more data packets have been received for processing, in step <b>572</b>, the received data packets are evaluated to select the data packet having the highest priority level. This highest priority data packet is then used to generate an alert. The type of alert generated is based upon the station identifier provided in the data packet. If the data packet provides an email address (step <b>574</b>), then in step <b>576</b>, an email message is generated directed to that email address including a textual message describing the alert condition. The message is then sent (step <b>578</b>) and processing returns to step <b>572</b>. If the station identifier is a TCP/IP address (step <b>580</b>), then in step <b>582</b> web server <b>114</b> connects to this TCP/IP address and delivers a textual alert message in a manner that is appropriate to the Internet application in use. Then, in step <b>584</b>, the connection is disconnected and processing returns to step <b>572</b>. If the data packet selected includes an Internet address for a numeric pager service (step <b>586</b>), then in step <b>588</b> a connection is established to the pager service and the appropriate numeric code is delivered for the alert type identified by the data packet. In step <b>590</b> the connection to the page service is disconnected and processing returns to step <b>572</b>. If a data packet identifies address for an alpha numeric pager server (step <b>592</b>), then in step <b>594</b> a connection is established to the pager service and a textual alert is delivered to the pager service. Then in step <b>596</b>, the connection to the pager service is disconnected and the processing returns to step <b>572</b>.

0095Referring now to <figref idref="DRAWINGS">FIG. 4H</figref>, the process performed by the switch host <b>130</b> in response to data packets received from database query system <b>112</b> can be explained in further detail. As described above, data packets can be received from the database query system <b>112</b> in background so that the remaining steps of <figref idref="DRAWINGS">FIG. 4H</figref> can be performed as packets are continuously received. In a first step <b>602</b> the data packets that have been received are evaluated to select the data packet having the highest priority level. After a packet has been selected in step <b>604</b>, switch host <b>130</b> waits for an idle out dial channel in switch <b>132</b>. When an idle channel is available, in step <b>606</b> a command is sent to switch <b>132</b> to out dial to the station identifier identified in the selected packet. Subsequently, in step <b>608</b>, the switch will report the call status to the switch host as the call is performed. If the call is answered (step <b>610</b>), then in step <b>612</b> the switch host <b>130</b> delivers commands to switch <b>132</b> to play prerecorded messages corresponding to the alert type of the selected packet and then to hang up the established connection. If there is no answer or the dialed number is busy (step <b>614</b>), then the packet is marked for retry (step <b>616</b>). After either of step <b>612</b> or <b>616</b>, in step <b>618</b> a detailed call record is inserted in the subscriber history table <b>194</b> indicating the results of the call that was placed, i.e., whether the call was answered or not answered or busy. Processing then returns to step <b>602</b> to select another data packet for delivery to a subscriber.

0096Referring now to <figref idref="DRAWINGS">FIGS. 5A and 5B</figref>, the static area process can be described in greater detail. In the static area process, in step <b>620</b> database query system <b>112</b> retrieves all station identifiers of subscribers located in the area specified in the alert, which may be a state, county, city, zip code, or other definable region. Then in step <b>622</b> those station IDs are prioritized based upon the information registered for the subscriber. <figref idref="DRAWINGS">FIG. 5A</figref> illustrates exemplary counties and zip codes that may be utilized in a typical static area process.

0097Referring now to <figref idref="DRAWINGS">FIGS. 6A and 6B</figref>, the operation of a radius process <b>536</b> of the database query system <b>112</b> can be explained in further detail. In a radius process, in step <b>624</b> all station identifiers for subscribers within an identified range of a specific geographic point are retrieved. Then in step <b>626</b>, the retrieved station identifiers are prioritized based upon information registered by the subscribers. As seen in <figref idref="DRAWINGS">FIG. 6A</figref>, a radius routine will notify subscribers within one of a number of predefined circular regions and mileages <b>628</b> surrounding a specific geographic position, which may be identified by GPS coordinates, latitude and longitude, or even a zip code or postal address. In the case of a zip code, which have regions such as are shown in <figref idref="DRAWINGS">FIG. 6A</figref>, the geographic center of the zip code region will be used as the geographic position from which to compute the circular region <b>628</b>.

0098Referring now to <figref idref="DRAWINGS">FIGS. 7A and 7B</figref>, the operations of a vector process <b>539</b> performed by database query system <b>112</b> can be further explained. As seen in <figref idref="DRAWINGS">FIG. 7A</figref>, in this process the number of geographic locations is computed, and from these locations subscribers located within a radius of those locations are identified for notification of the alert condition. Each radial region <b>629</b> identified during this process is known as a “band” of geographic locations. The vector process is performed for a defined number of bands and a defined time frame.

0099A first step <b>630</b> in the vector process is to determine a mileage range that can be covered by the hazard (e.g., tornado) in the identified time frame based upon the identified forward speed. Then in step <b>632</b>, all station identifiers for subscribers that are within the calculated range of the identified geographic point are retrieved. In step <b>634</b> and step <b>636</b>, variables are initialized for later use in collecting additional station identifiers. Specifically in step <b>634</b>, a current geographic point is set to be the identified geographic point in the alert notification packet. In step <b>636</b>, the band number is initialized to a value of one.

0100In a subsequent loop of steps <b>638</b>, <b>640</b>, <b>642</b>, <b>644</b> and <b>646</b>, geographic regions are calculated, and then station IDs for subscribers within those geographic regions are identified. In a first step <b>638</b>, the geographic region is calculated based upon the current band number and current geographic point. This involves steps similar to those described above with reference to steps <b>630</b> and <b>632</b> in which a mileage range is computed and then station IDs for subscribers within that mileage range of the current geographic point are identified. After <b>638</b>, in step <b>640</b> all station identifiers that are not previously enqueued, that are within the geographic region identified in step <b>638</b> are enqueued. In step <b>642</b>, the current band number is incremented. And in step <b>644</b>, it is determined whether there are additional bands to be included in the vector routine. If so, then in step <b>646</b> a new current geographic point is computed based upon the existing geographic point and the heading, time frame and identified number of bands provided in the alert notification. This causes the center of subsequent regions to move along the heading identified by the alert notification. After step <b>646</b>, processing returns to step <b>638</b> to calculate a new geographic region and queue additional station identifiers.

0101After all bands have been completed, the processing proceeds from step <b>644</b> to step <b>648</b> in which the band number again is initialized to a value of one. Next, in step <b>650</b> station IDs identified in the current band number are prioritized based upon subscriber registered information. Thereafter, in step <b>652</b> it is determined whether there are more bands, and if so then in step <b>654</b> the band number is incremented. After all bands have been processed then the vector process is completed. These final steps <b>650</b>, <b>652</b> and <b>654</b> cause station identifiers to be prioritized such that those in the first band, which are nearest to the hazard or threat, are prioritized before those in subsequent bands.

0102Referring now to <figref idref="DRAWINGS">FIGS. 8A and 8B</figref>, the shoreline process <b>540</b> of the database query system <b>112</b> can be explored. In a first step <b>660</b>, all station identifiers within a given coastal area are retrieved. Then in step <b>662</b>, those station identifiers are prioritized based upon flood zone coding of the corresponding subscriber records. Then in step <b>664</b>, station identifiers are further prioritized based upon subscriber registered information. As seen in <figref idref="DRAWINGS">FIG. 8A</figref>, this process permits alert notifications to be delivered to multiple subscribers who are threatened by a coastal hazard such as a tidal wave, high seas or hurricane.

0103Referring now to <figref idref="DRAWINGS">FIGS. 9A and 9B</figref>, the river routine <b>542</b> of the database query system <b>112</b> can be elaborated. In the first step <b>670</b>, all station identifiers within given riverbank area are retrieved. Then in step <b>672</b>, those station identifiers are prioritized based upon flood zone code in the subscriber information. Subsequently, in step <b>674</b> those station identifiers are again prioritized based upon other registered information from subscribers. As seen in <figref idref="DRAWINGS">FIG. 9A</figref>, this process permits all subscribers within a flood plane or threatened by flooding in a river area to be advised of an emergency condition.

0104Referring now to <figref idref="DRAWINGS">FIGS. 10A and 10B</figref>, details of the wind dispersion process <b>544</b> of the database query system <b>112</b> can be elaborated. In this process, in the first step <b>680</b> a mileage range is computed, representing the range that a toxic release will cover in the identified time frame based upon the identified wind speed. Next, in step <b>682</b>, all station identifiers for subscribers within the calculated range of the identified geographic point are retrieved. In step <b>684</b> and step <b>686</b>, variables are initialized for a loop of steps <b>688</b>, <b>690</b>, <b>692</b>, <b>694</b> and <b>696</b> in which station identifiers are selected from those retrieved in step <b>682</b>. In step <b>684</b>, a current geographic point is initialized to be the geographic point identified in the alert notification packet. In step <b>686</b>, a band number is initialized to a value of one. Subsequently in step <b>688</b>, a geographic region is calculated based upon the current band number and the current geographic point. This calculation involves wind dispersion formulas known in the art which identify areas in which a release at a given point will be dispersed, given a current wind direction and speed. Subsequently, in step <b>690</b>, all station identifiers that have not been previously enqueued and that are within the identified geographic region are enqueued. Thereafter, in step <b>692</b> the current band number is incremented and in step <b>694</b> it is determined whether more bands are to be processed. If there are more bands to process, in step <b>696</b> a new current geographic point is computed from the previous geographic point, the identified wind speed, time frame and number of bands identified in the alert notification packet. Processing then returns to step <b>688</b> to complete another band.

0105After all bands have been processed, in step <b>698</b> the band number is again initialized to a value of one to permit prioritization through step <b>700</b>, <b>702</b> and <b>704</b>. In step <b>700</b>, all station identifiers for current band number are prioritized based upon subscriber registered information. In step <b>702</b>, it is determined whether there are additional bands. If so, in step <b>704</b> the current band number is incremented and processing returns to step <b>700</b> to prioritize station IDs for the new current band number. After all bands have been prioritized in this manner, processing is complete. These last three steps, <b>700</b>, <b>702</b> and <b>704</b> permit all station identifiers to be prioritized such that station identifiers identified in a given band nearer to the source of the toxic release are prioritized first and prior to station identifiers identified in additional bands.

0106Referring now to <figref idref="DRAWINGS">FIG. 11</figref>, details of the school or organization process <b>546</b> of the database query system <b>112</b> can be explained. In a first step <b>710</b>, the school or organization identifier of the alert notification is used to locate station identifiers for all subscribers that have registered a matching school or organization identifier. In a second step <b>712</b>, the retrieved station identifiers are prioritized based upon the subscribers' registered information and enqueued.

0107While the present invention has been illustrated by a description of various embodiments and while these embodiments have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art.

0108For example, the location information found in the subscriber information tables of <figref idref="DRAWINGS">FIG. 3C</figref> need not be static. Several organizations have recently proposed technologies for tracking the movement of communication equipment such as cellular telephones. Technologies of this kind are described in U.S. Pat. Nos. 5,945,944, 5,663,734, 5,781,156, 5,825,327, 5,831,574, 5,841,396, 5,812,087, 5,874,914 and 5,884,214, all of which are hereby incorporated herein by reference in their entirety.

0109Consistent with principles of the present invention, the above-referenced technology may be utilized to dynamically update location information found in the subscriber information tables of <figref idref="DRAWINGS">FIG. 3C</figref>, to reflect the current position of a subscriber's cellular phone or other wireless communication device. Then if the subscriber's communication device is within a threatened area that has been identified in the manner described above, the subscriber will receive an alert notification in the manner described above.

0110Mobile wireless devices that can be tracked for the purposes of providing alert notifications are not limited to cellular telephones, but could also include personal digital assistant (PDA) devices, or laptop or palmtop computers having wireless communications capabilities. Furthermore, alerts may be delivered to the mobile wireless device via technologies other than voice telephone, such as via paging services (voice or text), or via Internet or e-mail communications as noted above.

0111The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative example shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of applicant's general inventive concept.