U.S. patent application number 13/150725 was filed with the patent office on 2012-12-06 for system and method for communicating emergency information through messaging.
This patent application is currently assigned to EMBARQ HOLDINGS COMPANY, LLC. Invention is credited to Amar Ray.
Application Number | 20120309340 13/150725 |
Document ID | / |
Family ID | 47262045 |
Filed Date | 2012-12-06 |
United States Patent
Application |
20120309340 |
Kind Code |
A1 |
Ray; Amar |
December 6, 2012 |
SYSTEM AND METHOD FOR COMMUNICATING EMERGENCY INFORMATION THROUGH
MESSAGING
Abstract
A system and method for communicating emergency messages. An
emergency message is communicated wirelessly from a sending party
is received. Location information associated with the sending party
is determined. An emergency system associated with the sending
party is determined utilizing the location information. A
communication session is established with the emergency system. The
emergency message is converted to an audio message in response to
the communication session being established. The audio message is
communicated to the emergency system in response to the
communication session being established.
Inventors: |
Ray; Amar; (Shawnee,
KS) |
Assignee: |
EMBARQ HOLDINGS COMPANY,
LLC
|
Family ID: |
47262045 |
Appl. No.: |
13/150725 |
Filed: |
June 1, 2011 |
Current U.S.
Class: |
455/404.2 ;
455/404.1 |
Current CPC
Class: |
H04W 4/029 20180201;
H04W 76/50 20180201; H04W 4/12 20130101; H04L 51/066 20130101; H04W
4/90 20180201; H04W 4/02 20130101; H04L 12/1895 20130101; H04M
1/72538 20130101; H04W 4/18 20130101; H04M 1/72552 20130101 |
Class at
Publication: |
455/404.2 ;
455/404.1 |
International
Class: |
H04W 4/22 20090101
H04W004/22 |
Claims
1. A method for communicating emergency messages, the method
comprising: receiving an emergency message communicated wirelessly
from a sending party; determining location information associated
with the sending party; determining an emergency system associated
with the sending party utilizing the location information;
establishing a communications session with the emergency system;
converting the emergency message to an audio message in response to
establishing the communications session; and communicating the
audio message to the emergency system in response to the
communication session being established.
2. The method according to claim 1, wherein the emergency message
is a text message, and wherein the communications session is
performed utilizing a SIP format.
3. The method according to claim 2, further comprising: determining
a message is the emergency message; sending a message to the
emergency system indicating that the message was originally a text
message.
4. The method according to claim 3, wherein the determining is
performed utilizing an identifier for the receiving party.
5. The method according to claim 1, wherein the location
information is global positioning information including a latitude
and longitude determined by a wireless device utilized by the
sending party.
6. The method according to claim 1, wherein the location
information is wireless triangulation information determined by a
wireless device utilized by the sending party.
7. The method according to claim 2, further comprising: sending a
message received through the emergency system to the receiving
party.
8. The method according to claim 7, wherein the sending comprises:
converting speech from emergency personnel into one or more text
messages that are communicated to the receiving party.
9. The method according to claim 1, further comprising:
automatically sending a confirmation message to the sending party
indicating the emergency message has been received in response to
the emergency system receiving the audio message; and automatically
sending a message to the sending party indicating the emergency
message has not been received in response to failure to establish
the communication session.
10. The method according to claim 7, wherein the message is one or
more text messages, the one or more text messages comply with
applicable character limitations.
11. A system for communicating emergency text messages, the system
comprising: a wireless network operable to receive text messages
from a plurality of wireless devices including a sending party; a
conversion device in communication with the wireless network
operable to receive the text messages, identify a text message as
an emergency message, establish a communications session with an
emergency system, and convert the emergency message to an audio
message in response to establishing the communications session; and
the emergency system in communication with the conversion device,
the emergency system plays the audio message received from the
conversion device to emergency personnel.
12. The system according to claim 11, further comprising: one or
more databases operable to determine the emergency system
corresponding to a location of the sending party for establishing
the communication session with the emergency system and determine a
location of the sending party utilizing location information in the
emergency message associate location information for the sending
party with the emergency message.
13. The system according to claim 11, wherein the conversion device
sends a confirmation message indicating that the text message was
received by the emergency personnel, wherein the conversion device
sends a message to the emergency system indicating that the
emergency message was originally the text message, and wherein the
conversion device converts a response message from the emergency
personnel to one or more text messages according to character
limitations.
14. The system according to claim 11, wherein the communication
session includes a call to play the audio content, and wherein a
portion of the communications session is performed utilizing the
SIP format.
15. The system according to claim 11, wherein the emergency system
includes legacy systems for processing 911 calls.
16. A conversion device for emergency communications comprising: a
processor for executing a set of instructions; and a memory for
storing the set of instructions, wherein the set of instructions
are executed to: receive an emergency message communicated
wirelessly from a sending party; establish a communications session
with an emergency system in response to determining the emergency
system is associated with the sending party utilizing the location
information; convert the emergency message to an audio message in
response to establishing the communication session; and communicate
the audio message to the emergency system in response to the
communication session being established.
17. The conversion device according to claim 16, wherein the
emergency system is associated with the sending party in response
to the emergency system covering an area corresponding to the
location information.
18. The conversion device according to claim 16, wherein the
emergency system is associated with the sending party in response
to an identifier indicating the receiving party in the emergency
message.
19. The conversion device according to claim 18, wherein the
emergency message is a text message, wherein the conversion device
determines the text message is an emergency message utilizing the
identifier.
20. The conversion device according to claim 16, wherein the set of
instructions are further executed to: automatically send a
confirmation message to the sending party indicating the emergency
message has been received in response to the emergency system
receiving the audio message; automatically send a message to the
sending party indicating the emergency message has not been
received in response to failure to establish the communication
session; and convert a response message from emergency personnel
received from the emergency system to one or more text messages
according to character limitations.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is related to U.S. patent
application Ser. No. 12/257,574 that was filed Oct. 24, 2008 and
which is hereby incorporated by reference in it entirety.
BACKGROUND
[0002] The use of and development of communications has grown
nearly exponentially in recent years. The growth is fueled by
larger networks with more reliable protocols and better
communications hardware available to service providers and
consumers. In particular, many younger individuals use wireless
message and other new forms of communication almost exclusively.
Emergency services as well as the associated networks, systems,
protocols, and devices have struggled to keep pace with this rapid
development. As a result, emergency services are mostly limited to
traditional forms of communication and have failed to keep pace
with the younger generation and new technologies.
SUMMARY
[0003] One embodiment includes a system and method for
communicating emergency messages. An emergency message may be
communicated wirelessly from a sending party is received. Location
information associated with the sending party may be determined. An
emergency system associated with the sending party may be
determined utilizing the location information. A communication
session may be established with the emergency system. The emergency
message may be converted to an audio message in response to the
communication session being established. The audio message may be
communicated to the emergency system in response to the
communication session being established.
[0004] Another embodiment includes a system for communicating
emergency text messages. The system may include a wireless network
operable to receive text messages from a number of wireless devices
including a sending party. The system may also include a conversion
device in communication with the wireless network operable to
receive the text messages, identify a text message as an emergency
message, establish a communications session with an emergency
system, and convert the emergency message to an audio message in
response to the communication session being established. The
emergency system may be in communication with the conversion
device. The emergency system may play the audio message received
from the conversion device to emergency personnel.
[0005] Yet another embodiment includes a conversion device for
emergency communications. The conversion device may include a
processor for executing a set of instructions and a memory for
storing the set of instructions. The set of instructions may be
executed to receive an emergency message communicated wirelessly
from a sending party, establishing a communications session with an
emergency system in response to determining the emergency system is
associated with the sending party utilizing the location
information, convert the emergency message to an audio message in
response to the communication session being established, and
communicate the audio message to the emergency system in response
to the communication session being established.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] Illustrative embodiments of the present invention are
described in detail below with reference to the attached drawing
figures, which are incorporated by reference herein and
wherein:
[0007] FIG. 1 is a pictorial representation of a communications
environment in accordance with an illustrative embodiment;
[0008] FIG. 2 is a vector diagram for emergency communications in
accordance with an illustrative embodiment; and
[0009] FIG. 3 is a flowchart of a process for communicating
emergency messages in accordance with an illustrative embodiment;
and
[0010] FIG. 4 is a flowchart of a process for communicating return
messages to a sending party in accordance with an illustrative
embodiment.
DETAILED DESCRIPTION OF THE DRAWINGS
[0011] The illustrative embodiments provide a system and method for
providing emergency services and communications through messaging.
An emergency message, such as a text message to 911, is identified
and communicated to a conversion device. The message is converted
into an audio message once the communications session or path is
determined. Location information sent with the original message is
utilized to determine a nearest or most appropriate emergency
service access point, system, and personnel as well as the exact or
approximate location of the person sending the emergency message.
The audio message may be played to emergency service personnel as
if the message were a traditional 911 call. The message may also be
transmitted, displayed, or otherwise communicated via email, text,
or other interface to the systems and devices accessible by the
emergency service personnel.
[0012] As a result, the emergency service personnel are notified of
an emergency through a message and existing emergency service
communications, networks, standards, and protocols may be utilized
with little modification. Confirmation and response messages may be
sent back to the sending party to provide confirmation that the
message was received, provide emergency instructions, or to provide
other information that may be needed by the sending party. The
described systems and methods may function with legacy systems,
networks, gateways, and components to facilitate emergency text
messages without a complete modification or replacement of
emergency systems. The systems and methods described may utilize
any of the systems, standards, and protocols of the National
Emergency Number Association (NENA) and Next Generation 911
(NG911), such as NENA-i3 which are herein incorporated by
reference.
[0013] FIG. 1 is a pictorial representation of a communications
environment 100 in accordance with an illustrative embodiment. The
communications environment may 100 include any number of devices,
networks, systems, and connections an example of which are
illustrated in FIG. 1. In one embodiment, the illustrative
embodiments may utilized the legacy 911 calling systems, emergency
service internet protocol network, and corresponding procedures
with minor modifications or additions to achieve emergency
communications as described. The communications environment 100 is
one embodiment of all or portion of an emergency service internet
protocol network (ESINet). The communications environment 100 may
include legacy networks including wireless and wireline
communications components configured for 911 communications as well
as more advanced Internet protocol (IP) components.
[0014] In one embodiment, the communications environment 100 may
include a wireless device 102, a cell site 104, a mobile switching
center (MSC) 106, an originating Short Messaging Service Controller
(SMSC) 108, a SMSC router 110, a database 112, an SS7 clearing
house 114, an SS7 network 116, an SMSC terminal 118, a Public
Safety Answering Position (PSAP) 120, an legacy public safety
answering position gateway (LPG) 122, an Emergency Service Routing
Proxy (ESRP) 124, a Network Gateway (NG) Public Safety Answering
Position 126, a Border Control Function (BCF) 128, a Legacy Network
Gateway (LNG) 130, a conversion device 132, a database 134, a
location information server (LIS) 136, and a Geo Information Server
(GIS) 138.
[0015] The SS7 clearing house 114 and the SS7 network 116 may be
utilized for standard emergency communications, voice
communications, and text communications between different parties.
The illustrative embodiments provide the benefit of working with
standard communications systems and emergency communications
systems without requiring expensive or overly burdensome network
renovations and protocol updates.
[0016] The illustrative embodiments may be performed for a message
sent wirelessly. In one embodiment, the message is a text message
with text content. In other embodiments, the message may be an
audio, video, chat, or other message recorded or streamed in real
time with the content of the message varying accordingly.
[0017] The wireless device 102 is a communications or computing
device enabled for wireless communications. The systems,
components, and devices of the communications environment 100 may
communicate utilizing any number of wireless and hardwired
communications mediums, standards, and protocols known in the art.
For example, the wireless device 102 may communicate with the cell
tower 104 utilizing any number of cellular and data standards, such
as CDMA, EV-DO, GSM, GRSM, WiMax, 4G, and other existing or
developing standards and protocols. The other components may
communicate through networks and connections, such as Ethernet
networks communicating through fiber optics.
[0018] In addition, the components of the communications
environment 100 may be incorporated in one or more devices,
programs, applications, or devices. For example, the roles of
various devices may be implemented by hardwired digital logic,
programmable gate arrays, or based on the execution of software
that is stored in one or more memories and executed by one or more
processors. In addition, each of the devices of the communications
environment 100 may include processing elements, memories, caches,
motherboards, communications and peripheral interfaces, busses,
logic, and other components that are not specifically shown or
described, but that are known in the art.
[0019] The wireless device 102 may execute an application or
operating system that is operable to implement specific steps,
instructions, or features in response to identifying a text message
as an emergency message. In one embodiment, the wireless device
enters an emergency mode in response to an identifier, such as
"911", "emergency", or "help" being entered as the recipient of the
call. In particular, the wireless device 102 may identify the
message as an emergency message with the wireless device then
providing the MSC 106 with location information including the
content of the message. The location information may be determined
utilizing global positioning information (GPS) obtained by the
wireless device, utilizing wireless triangulation, or other
location determination methodologies. In one embodiment, the
location information may include a latitude and longitude. In
another embodiment, the location information may include an address
if known.
[0020] In another embodiment, the MSC 106, originating SMSC or
conversion device 132 may identify the message as an emergency
message and associate location information with the emergency
message. The user information including the call back number of the
caller (calling, sending, or originating party), the location
information, and content of the message may be communicated from
the MSC 106 to the legacy network gateway 130 via the originating
SMSC 108 the SMSC router 110 and the conversion device 132. In one
embodiment, the user information is an automatic number
identification (ANI) and the original location information that is
received by the legacy network gateway 130.
[0021] The conversion device 132 may be an audio multi-purpose
conversion box (MPCB) that converts the text or other content to
audio content that may be played, displayed, or otherwise
communicated to a user or emergency service personnel and vice
versa. In one embodiment, the conversion device 132 may only
perform the conversion or play the converted message once a
communications session or path is established with the appropriate
PSAP, such as PSAP 120. The conversion device 132 may convert or
process data to a local media as may be appropriate or required for
public safety related cases, such as emergency communications
related to evacuations or mass notifications.
[0022] In some situations, the conversion device 132 may be unable
to establish a communications session with a PSAP, such as PSAP
120. It is possible in some worst case scenarios that a whole
region of PSAPs may be unavailable, non-functionally, or unstaffed
due to particular emergencies, such as earthquakes, hurricanes,
power outages, or other natural or man-made disasters. If the
conversion device 132 determines no PSAPs are available based on
communications with the ESRP, the conversion device 132 may send a
message to the wireless device 102 indicating that the message was
not delivered. The determination that the PSAPs are not available
may be made in response to a confirmation of an off-hook message
not being received from the PSAP, inability to establish a
communications session, or other potential issue.
[0023] In one embodiment, the conversion device 132 may convert
texting abbreviations, symbols, or slang to the equivalent
language. The conversion device 132 may access one or more
databases or logic engines to translate or make a best guess of the
intended language. For example, "pls" would be converted to
"please", "hry" may be converted to "hurry", and "ASAP" may be
converted to "as soon as possible." Signal initiating protocol
(SIP) may be utilized to complete a call from the conversion device
132 to the PSAP 126. For example, the message may not be delivered
to the PSAP 126 until the SIP signaling is completed with the PSAP
going off-hook to initiate a communications session and receive a
call from the conversion device 132. The PSAPs 126 and 120
represent IP or analog systems.
[0024] The conversion device 132 may also send the automatic number
identification and location information to the database 134. The
database 134 may communicate with or be integrated with the
location information server 136. In one embodiment, the conversion
device 132 may receive a location value indicating the exact
location of the wireless device 102, such that a query or look up
in the database 134 and the location information server 136 is not
required. As a result, the location value may be passed along by
the conversion device 132 and the legacy network gateway to the
ESRP 124 for selection of an appropriate PSAP and other
communications routing. In another embodiment, the location
information server 136 may determine the exact address or other
location information associated with the originally received
location information.
[0025] In one embodiment, the database 134 may communicate with
third party devices, web portals, or enterprise solutions to
manually or automatically determine the location information
associated with the user. In one embodiment, the database 134 may
communicate with a validation database updated through a portal or
other automated solution to retrieve applicable location
information.
[0026] The conversion device 132 may send an automatic number
identification to the legacy network gateway 130. The conversion
device 13 may also send the unformatted location information or any
other type of identification that may be utilized to identify the
sending party and perform a location query from the required for
the location query by the ESRP 124. The conversion device 132 may
also be enabled to format communications to an IP or SIP format.
For example, the conversion device 132 may communicate the ANI
utilizing the SIP format to the legacy network gateway 130. Any
number of other formats may also be utilized for communications
within the communications environment 100.
[0027] The legacy network gateway 130 may be a signaling and media
interconnection point between callers in legacy wire-line/wireless
originating networks and the emergency architecture (e.g. i3, i4)
so that PSAPs are enabled to receive emergency calls from legacy
networks. Although, not shown, the legacy network gateway 130 may
also communicate with a DMS, ISDN, class 5 or proxy switches or
other similar communications devices and systems. The legacy
network gateway 130 may pass the automatic number identification to
the emergency service routing proxy 124 through the border control
function 128. The border control function 128 may provide a secure
entry into an emergency service internet protocol network. The
border control function 128 may incorporate firewall, admission
control, and session and media anchoring and well as security
mechanisms to prevent deliberate or malicious attacks on PSAPs or
other entities contained in the communications environment 100.
[0028] The emergency service routing proxy 124 may be a functional
component, such as a SIP proxy server that selects the next hop
routing within the ESINet based on location and policy. In one
embodiment, there is an emergency service routing proxy on the edge
of the ESINet and potentially at the entrance to a next generation
PSAP. There may also be any number of intermediate emergency
service routing proxies between endpoints. The emergency service
routing proxy 124 may query the location information server 136 for
location information based on the automatic number identification
and retrieve the location information (e.g. an address
corresponding to the sending party) back in return. In one
embodiment, the location information server 136 has the address or
location information prepared beforehand based on the communication
from the conversion device 132.
[0029] The emergency service routing proxy 124 may also obtain
routing information from the emergency call routing function (ECRF)
of the geo information server 138 using the location to service
translation (LoST) protocol. The emergency service routing proxy
124 may route the call to the appropriate PSAP using the emergency
call routing function, location validation function, (LVF), and
LoST. The conversion from TDM PSAP to IP PSAP may take some time.
During the transition period, the emergency service routing proxy
124 may deliver 911 traffic to the existing TDM PSAPs through the
legacy PSAP gateway 122. The emergency service routing proxy 124
may also deliver the IP-911 traffic to the IP host client through
appropriate network connections (e.g. ESINet). The legacy PSAP
gateway 122 may also be a IDM gateway which represents a PSAP
gateway for a legacy PSAP that uses TDM signaling rather than IP.
The legacy PSAP gateway 122 may eventually be replaced during
ESINet upgrades to a carrier or PSAP based on the configuration of
the ESINet.
[0030] The PSAP 126 may obtain the location information of the user
(e.g. 911 caller) in any number of ways including: from the ESRP
124 in PIDF format, from a query to the location information server
136 based on the uniform resource identifier (URI) to obtain the
location of the calling party, and from a query to the geo
information server 138.
[0031] The location information server 136 is a functional entity
that provides locations of endpoints. A location information server
136 may provide location-by-reference or location-by-value in geo
or civic forms. The location information server 136 may be queried
by an endpoint for its own location or by another entity of the
location of an endpoint. The location information server 136 may
receive a unique identifier that represents the endpoint, such as
an IP address, circuit identification or MAC address and returns
the location (value or reference) associated with the identifier.
The location information server 136 may also provide a
dereferencing service by exchanging a location reference for a
location value.
[0032] One or more of the devices of the communications environment
100 may utilize a location validation function to ensure that a
civic address retrieved by the database 134 or location information
server 134 is valid. The location validation function supports
validation of addresses against a geospatial database. The location
information server 136 and the database 134 may be located inside
the local emergency network or outside the emergency network of the
communications environment 100. The communication between the ESRP
124 and the location information server 136 may occur through
ESINet or through the existing ALI communicating network via an
appropriate gateway and firewall system.
[0033] The emergency call routing function supports calls and
associated data being relayed or transferred between states and
across the country. The emergency call routing function may utilize
standards of service, management, resources, and functionality to
ensure that emergency services are available uniformly. In one
embodiment, the emergency call routing function receives location
information (i.e. civic address or geo-coordinates) as input and
uses this information to provide a Uniform Resource Identifier
(URI) that may be used to route an emergency call toward the PSAP
corresponding to the calling party's location. Depending on the
identity and credentials of the component, entity, or individual
requesting the routing information, the response may identify the
PSAP, or emergency service routing proxy that acts on behalf of the
PSAP to provide final routing to the PSAP itself. The same database
that is used to route a call to the correct PSAP may also be used
to subsequently route the call to the correct responder (e.g. to
support selective transfer capabilities).
[0034] The emergency service routing proxy 124 may send the
location information in a Presence Information Data Format-Location
Object (PIDF-LO) encapsulated in a session initiation protocol
(SIP) packet utilizing routing information received from the
emergency call routing function to the PSAP 126. The PSAP 126 may
unbundle the SIP packet to retrieve the location information and
format the location information. For example, the SIP packet may
convert latitude and longitude information into a location address.
The location information may also be obtained by accessing the Geo
Information Server 138 using the LoST protocol.
[0035] If the PSAP 126 utilizes TDM (e.g. legacy gateway) the
legacy PSAP gateway 122 converts from the SIP format to Central
Automatic Message Accounting (CAMA) before delivering the message
to the PSAP 120. Upon the SIP signaling being established between
the conversion device 132 and the PSAP 120, the conversion device
132 may send the audio message to the PSAP 120. The conversion
device 132 may send a confirmation message to the wireless device
102 indicating that the emergency message was sent and received. In
one embodiment, the confirmation message is a text message.
Alternatively, the confirmation message may be a phone call, email,
or displayed message that is sent and displayed through an
application, program or instructions utilized or synchronized
between the conversion device 132 and the wireless device 102. The
conversion device 132 may also send a message to the PSAP 120
indicating the original message was created by the wireless device
102 utilizing text messaging.
[0036] The PSAP 120 may reply with an audio message that is
automatically generated or received from emergency personnel. In
one embodiment, the response message is sent via RTP traffic as far
as the legacy network gateway 130. The legacy network gateway 130
may convert the traffic to TDM format (e.g. CAMA) before sending
the response message to the conversion device 132. The conversion
device 132 may convert the audio to text before sending the
response message to the wireless device 102 and corresponding
sending party in one or more messages. The conversion device 132
may partition the response message according to the protocol and
standard limitations as well as industry practices (i.e. a maximum
of 160 characters). The illustrative embodiments may utilize known
emergency communications processes for further initiating, setting
up, and tearing down a communication session.
[0037] FIG. 2 is a vector diagram for emergency communications in
accordance with an illustrative embodiment. The process of FIG. 2
may be implemented by the communications environment 100 of FIG. 1.
The process of FIG. 2 may be implemented between a protocol
interworking function (PIF) 202, emergency call routing function
(ECRF) 204, an network interworking function (NIF) 206, a location
interworking function (LIF) 208, a legacy Automatic Location
Identification (ALI) 210, and a public safety answering point
(PSAP) 212. In one embodiment, the process of FIG. 2 may be
implemented in the communications environment 100 of FIG. 1.
[0038] The process may begin with the protocol interworking
function 202 sending an invite to the network interworking function
206 (step 214). The protocol interworking function 202 may
represent a legacy network gateway. The network interworking
function 206 may represent an application server or ESRP within a
data center or other facility. A confirmation message is sent back
from the network interworking function 206 to the protocol
interworking function 202 (step 216) and the protocol interworking
function 202 then responds with an acknowledgement (step 218).
[0039] As a result, a real-time transport session is established
between the protocol interworking function 202 and network
interworking function 206 (step 220). Next, the network
interworking function 206 sends the automatic number identification
to the location interworking function 208 (step 222) and the
location interworking function 208 send the automatic number
identification to the legacy Automatic Location Identification 210
(step 224). The location interworking function 208 may represent a
function performed by an application server of the ESRP that is
responsible for making a query to the location information server
and receiving back the location information. The legacy Automatic
Location Identification 210 sends the automatic location
identification to the location interworking function 208 (step
226). The location interworking function 208 sends a PIDF to the
network interworking function 206 (step 228). The network
interworking function 206 submits a LoST query to the emergency
call routing function 204 (step 230). The emergency call routing
function 204 fulfills the query and responds with the LoST response
to the network interworking function 206 (step 232).
[0040] Next, the network interworking function 206 sends an
invitation to a public safety answering point (212). The public
safety answering point 212 represents a public safety answering
point applicable to the user address. A confirmation message is
sent back from the public safety answering point 212 to the network
interworking function 206 (step 216) and the network interworking
function 206 then responds with an acknowledgement to the public
safety answering point 212 (step 236). As a result, an RTP session
is established between the network interworking function 206 and
the public safety answering point 212 to communicate the message as
well as the location information.
[0041] FIG. 3 is a flowchart of a process for communicating
emergency messages in accordance with an illustrative embodiment.
The process of FIGS. 3 and 4 may be implemented by a communications
system or environment. The process may begin by identifying a
message from a sending party as an emergency message (step 302).
The message may be identified as an emergency message based on the
designated recipient, number, or other identifier. For example,
common recipients for a text message may include 911, fire, police,
medical emergency, search and rescue, coast guard, and so forth. In
one embodiment, the emergency service systems and personnel may be
pre-programmed into the wireless device as part of the
functionality of the phone or based on a legal requirement.
[0042] Next, the system determines location information associated
with the sending party (step 304). In one embodiment, a location
information server/database may be accessed by a component of the
system, such as an emergency services routing proxy, to determine
an address of the user. The location information server may utilize
original location information received in the message or determined
by a MSC. In one embodiment, the location information may
automatically be included or embedded in the message in response to
a wireless device determining the message is an emergency message.
For example, a cell phone may utilize GPS, wireless triangulation,
or proximity detection to determine exact or approximate location
information which may include a specific address. In another
embodiment, subsequent messages, confirmations, or details are
streamed from the wireless device indicating the location. If a
location of the sending party is unknown and not easily determined,
a last known location may be listed or sent indicating that was the
last known address.
[0043] Next, the system determines emergency service systems and
personnel corresponding to a location of the sending party from the
location information (step 306). In one embodiment, the location
information may be utilized to determine the nearest responding
party. The responding party may be indicated by designated
boundaries, maps, and other thresholds that the location
information is mapped to or compared against. In some cases, a
particular type of emergency or situation may mean that a
particular emergency service system and personnel are notified. For
example, if the sending party is in a wilderness area, the message
may be routed to the nearest search and rescue department rather
than the local police or fire department. Keywords or a designated
recipient may be utilized to determine where and how the emergency
message is routed and the applicable system and personnel for
receiving the emergency message. For example, the term "fire" may
ensure that the emergency message is routed to the nearest fire
department, the term "gun" and an indicate "police" recipient may
ensure that the message to the nearest police department.
[0044] Next, the system sends a message to the emergency service
systems an personnel indicating the original message was created
from a text message (step 308). The message may be an email, call,
displayed message, or other indicator that indicates the original
message was a text message. The message of step 318 may be utilized
to reassure the emergency personnel as to why an automated message
is being received. Otherwise, the emergency service personnel may
think the real emergency message was a fake.
[0045] Next, the system establishes a call with the corresponding
emergency service system and personnel (step 310). The call or
communications of the flowchart of FIG. 3 may involve establishing
a communications path, real-time protocol, session initiation
protocol, automatic number identification, CAMA, LoST, and other
applicable systems and protocols. The call or communications
path/session may be generated such that traditional 911 emergency
calling systems may be utilized. During step 312, the audio message
including the content of the emergency message and the location
information may be sent to the designated emergency service system
and personnel (e.g. PSAP).
[0046] Next, the system converts the emergency message to an audio
message (step 312). The audio message may utilize a text-to-voice
conversion process or engine. The audio message may include the
content from the original message as well as the location
information. The conversion may utilized a database to convert
abbreviations, acronyms, slang, or other languages to a language
used by emergency service personnel. In an alternative embodiment,
the system may convert the emergency message to the audio message
ahead of time so that the message may be immediately played to the
emergency service system and personnel once the call/session is
established.
[0047] FIG. 4 is a flowchart of a process for communicating return
messages to a sending party in accordance with an illustrative
embodiment. The process of FIGS. 3 and 4 may occur sequentially or
may partially overlap. The process of FIG. 4 may begin by receiving
emergency communications during a communication session with a
conversion device (step 402). During step 402, an audio file of a
converted message, such as a text message, may be played,
displayed, recorded, or otherwise communicated to the emergency
service system and personnel. The communication session may be a
call RTP session or other end-to-end or intermediate
communications.
[0048] Next, the system sends a confirmation message to the sending
party indicating the emergency message was received by the
emergency services system and personnel (step 404). The message may
be displayed to the sending party's device to reassure the person
experiencing or observing the message that the message was
received. For example, the confirmation message may be a text
message indicating the system or personnel responding to the
emergency, location, contact information, and time and date the
emergency message received the original message.
[0049] Next, the system sends content from the emergency service
system and personnel as a response message to the sending party
(step 406). In one embodiment, the response message is an audio
response (i.e. voice communications from a 911 operator) that is
converted to a text message. Alternatively, the emergency service
system may utilize a text message system available through a
computing or communications device integrated with the emergency
service system to send the message. The phone number and applicable
domain for the service provider may be utilized to send an email
that is converted into a text message (i.e. phone number
@vtext.com, @tmomail.com,
[0050] Next, the system determines whether the response message is
more than 160 characters (step 408). The threshold or level of step
408 may represent any number applicable to a particular type of
communication, standard, or messaging. Texting or communications
standards or protocols may set limits on the number of characters,
information, or format that may be included into the message. The
system formats the content to the applicable messaging standard,
format, and capacity.
[0051] If the response message does not exceed the 160 characters,
the system sends the single response message (step 410). The
message may include instructions for dealing with the emergency,
information about the emergency response, requests for additional
details, or other communication information common for emergency
response situations.
[0052] If the response message exceeds the limitations of the
message protocol, the system divides the response message into two
or more messages (step 412). For example, some messages are limited
to 160 characters and therefore multiple messages may be required
to send the verbal or text content. For example, a 200 character
message may be broken into a first message of 160 characters and a
second message of 40 characters.
[0053] Next, the systems sends the two or messages (step 414). The
two or more messages may be sent simultaneously or with a slight
delay between and according to the applicable messaging
protocol.
[0054] The previous detailed description is of a small number of
embodiments for implementing the invention and is not intended to
be limiting in scope. The following claims set forth a number of
the embodiments of the invention disclosed with greater
particularity.
* * * * *