[MBW]

This describes an architecture that proactively alerts BB users to cautionary conditions specific to both time and place, and is a call to all party to develop relevant standards to speed implementation.

ALERT SOURCES.

I have soken to Homeland Security, National Weather Service, NOAA and other agencies about this. The National Weather Service issues storm alert polygons, "hard code" mapped to their weather radio broadcast networked. Third parties like AccuWeather significantly enhance that data - adding things like alerts to specific allergens - and make it available against more traditional latitude/longitude queries. States tend to aggregate warnings for things like Amber Alerts, escaped prisoners, road/bridge out, school lock-downs, school/business closings related to weather, etc. Agency-direct or third-party-enhanced alert servers are easy and quite inexpensive to implement if they can respond to a geographically specific query with standard strings identifying any current alert, its intensity (or severity), its expiration time and pointers to additional IP-accessible information (images or text or audio). The list of authorized alert sources must necessarily be limited, but this schema can be somewhat broadened to include coded military base personnel recalls or vounteer fire call-ups, for example.

TOWER MIDDLEWARE

Some limited list of alerting servers would be quickly overwhelmed if they had to be directly addressed by each handset, but in the architecture recommended here, they are instead addressed by existing LBS hardware in the cell towers (I spoke with them at CTIA to determine their availability and the near-zero cost of implementation). Each of these boxes would be programmed to send standardized (a standard for which is needed)latitude/longitude/radius-of-coverage/authority-authentication query strings to its current list of primary & backup alerting servers. This box also takes responsibility for pushing or responding to polling requests from handsets within its footprint.

IN THE HANDSET

When you're driving into a tornado, zero visibility, a hole in the road, a collapsed bridge and an armed shoot-out all at the same time, you may not want to pause to read an alert in a text message. The handset alerting application needs to be able to immediately respond to the arrival of an alert with both audible (or vibratory - perhaps the Morse letter W) & visual cues. It may be appropriate to announce the alert using stored speech snippets. It would certainly be appropriate to create a unique color pattern on the LED and to change a desktop icon. It would also be nice to expand the speech recognition vocabulary to be able to get more information over audio hands-free. The alerting application would also have to be configurable so that users can choose which alerts they want to get, and enter access codes for advanced alerts that not everybody should get (like those volunteer fire call-ups). The application should also allow click-through to additional information like Amber Alert photos/info. It might optionally allow alert relays to a limited list of others - meaning Mom and Dad can no if one of the kids is entering a danger zone.

OTHER CONSIDERATIONS

The US Government has some priorities. One is to make sure that such a system is ultimately (2-3 years after launch) available to every cell phone user. One is to make sure that such a system does not compromise a user's privacy. One is to make sure that a user has to opt in to any received alert.

WHAT YOU CAN DO

The first step is a need for standard query-response strings as described above. Those can be de facto rather than de juris (in other words, they can be deployed before the IEEE meets to bless them).

The second step is the implicit pressure of a great hue and cry in support of Danger Zone push alerts. Tell your carrier. Tell your elected officials. Tell handset builders (I'm already on RIM about this; feel free to join me). Tell the news media. Tell emergency responders and emergency assistance organizations.

The third step - for LBS-relevant handset application developers - is to work on dormant code that can be woven in now for activation later to add such alerts as extensions to the application capabilities.

My work on this uncovered two unnecessary inhibitors.

One is political. This is being stalled in committees as different forces jockey for position in claiming the fathership of the program.

One is short-sightedness. The involved forces so far have been trying to solve this in one jump, and it's ghastly to think of any one server farm trying to respond to every handset everywhere; the two-step architecture we're proposing here could let a state alerting agency, for example, handle all of its query-response traffic on something like a desktop PC server on a T1 line.

The public has not been pressuring anybody because the public has no awareness of what they're missing.

Please help fix that.