Patent Description:
Further details are provided in the dependent claims.

As noted, emergency callers requesting assistance related to a public safety incident may make emergency calls using a <NUM> system. In current <NUM> systems, emergency calls are terminated at a public safety answering point (PSAP). Call takers at the PSAP answer and process the calls. For example, a call taker may ascertain the identity and location of the emergency caller, gather information from the caller about the incident, and dispatch appropriate services to respond to the incident. Call takers may also prioritize emergency calls and responses based on the nature of the incidents and information received from the callers. Call takers relay information received from emergency callers to in-field first responders (for example, firefighters, police officers, and paramedics), who may use the information to respond to the incident.

Public safety incident response is most effective when communications relating to the response is received quickly and by the relevant personnel responding to an incident. For example, information regarding the identity of a criminal suspect (provided by a caller who witnessed the crime) should be promptly provided to one of the police officers investigating the crime. However, PSAPs may be overloaded with emergency calls, resulting in information being delayed or not received at all. Additionally, transcribing, prioritizing, and relaying of information by call takers can be inefficient and may introduce errors into the information. The increased prevalence of community policing initiatives, which generate more information, and thus more load on the PSAP and call takers, exacerbates these problems. Furthermore, community policing and other software applications ("apps") allow the public to submit information that is not integrated into the <NUM> workflow, which results in a more disjointed information flow and presents difficulties and more opportunity for introducing errors as information from disparate sources must be integrated.

In-field first responders waiting on delayed information may contact the call takers requesting further information, resulting in wasted use of network resources and further delays in the processing of emergency calls as call takers handle the requests. Errors introduced into the information may result in too many, too few, or the wrong resources being dispatched, or may otherwise hinder the first responders' response to the public safety incident. As noted, the in-field first responders that are on duty near or responding to public safety incidents are equipped with portable communications devices (for example, smart telephones and two-way radios) capable of receiving emergency calls.

To address, among other things, these problems, systems and methods are provided herein for selectively routing emergency calls to a public safety answering points or the portable communications devices of the in-field first responders. Embodiments described herein provide, among other things, a call routing computing device. The call routing computing device is disposed between the traditional <NUM> call routing systems, the public safety answering point, and the portable communications devices of the in-field first responders. The call routing computing device determines, based on contextual information relating to the emergency caller, public safety incidents, and in-field first responders, whether to bypass the PSAP and route an emergency call directly to the portable communications device of an appropriate in-field first responder.

Among other things, using such embodiments, emergency callers may bypass the PSAP and be connected directly to a relevant in-field first responder. Emergency calls may bypass the PSAP based on, among other things, a status or capacity of the PSAP, the subject matter of the emergency call, or an ongoing public safety incident status. For example, when the PSAP is overloaded with call volume, emergency calls may be routed to public safety personnel already deployed near the emergency caller's location. In another example, an emergency caller may have information relating to an active field investigation and be connected directly to personnel performing the investigation. In another example, an emergency caller may be directly connected to in-field first responders because that caller has already been in contact with the in-field first responders about an ongoing public safety incident.

Using such embodiments, emergency calls that bypass the PSAP may be automatically associated (for example, using information submitted by the emergency caller) with an existing incident record (for example, in a computer aided dispatch system) or with a new incident record created for the call. Emergency calls rerouted to in-field first responders, though bypassing the PSAP, are still visible to call takers and other PSAP personnel. Call takers are still able to join the emergency call, redirect the call back to the PSAP, communicate with the in-field first responder directly (that is, outside of the emergency call), associate the call with an incident (or modify an automated association), and review an ongoing transcription of the emergency call.

Embodiments described herein, by automatically routing relevant calls to in-field first responders, improve the overall response to public safety incidents. This improvement, in turn, leads to more reliable collection and distribution of emergency response information, more efficient use of computer aided dispatch systems, more efficient use of public safety communications networks and their respective computing resources, and the reservation of resources for response to public safety incidents, among other benefits.

One example embodiment provides a method for routing an emergency call between a public safety answering point and in-field first responders. The method includes determining, at a call routing computing device, one or both of an identity of an emergency caller and a location of the emergency caller. The method includes retrieving, by the call routing computing device, based on the one or both of the identity and the location of the emergency caller, active incident information from one or more incident records databases associated with the PSAP, the active incident information identifying one or more active incidents associated with the one or both of the identity and the location of the emergency caller. The method includes identifying, by the call routing computing device, one or both of identities and locations of one or more in-field first responders associated with the one or more active incidents. The method includes comparing the one or both of the identity and the location of the emergency caller to the one or both of the identities and the locations of the one or more in-field first responders associated with the one or more active incidents. The method includes, when a match is found based on the comparison, routing, by the call routing computing device, the emergency call to one of the matching in-field first responders and not to the PSAP or to a call-taking terminal at the PSAP. The method includes, when a match is not found based on the comparison, routing, by the call routing computing device, the emergency call to the PSAP or to the call-taking terminal at the PSAP and not to any of the one or more in-field first responders.

Another example embodiment provides a call routing computing device communicatively coupled between an emergency caller communications device initiating an emergency call and a call-taking terminal at a public safety answering point. The device includes a communication interface and an electronic processor communicatively coupled to the communication interface. The electronic processor is configured to receive, via the communication interface, the emergency call. The electronic processor is configured to, prior to connecting the emergency call to the call-taking terminal at the PSAP, determine one or both of an identity of an emergency caller associated with the emergency caller communications device and a location of the emergency caller. The electronic processor is configured to retrieve, via the communication interface and based on the one or both of the identity and the location of the emergency caller, active incident information from one or more incident records databases associated with the PSAP, the active incident information identifying one or more active incidents associated with the one or both of the identity and the location of the emergency caller. The electronic processor is configured to identify one or both of identities and locations of one or more in-field first responders associated with the one or more active incidents. The electronic processor is configured to compare the one or both of the identity and the location of the emergency caller to the one or both of the identities and the locations of the one or more in-field first responders associated with the one or more active incidents. The electronic processor is configured to, when a match is found based on the comparison, route, via the communication interface, the emergency call to one of the matching in-field first responders and not to the PSAP or to the call-taking terminal at the PSAP. The electronic processor is configured to, when a match is not found based on the comparison, route, via the communication interface, the emergency call to the PSAP or to the call-taking terminal at the PSAP and not to any of the one or more in-field first responders.

Another example embodiment provides a system for routing an emergency call between a public safety answering point and in-field first responders. The system includes a display, a transceiver, and an electronic processor communicatively coupled to the display and the transceiver. The electronic processor is configured to generate a graphical user interface including a primary window and a secondary window. The primary window includes a map, and a plurality of auto-routed emergency caller indicators overlaid on the map, wherein each of the plurality of auto-routed emergency caller indicators is associated with one of a plurality of active auto-routed emergency calls. The secondary window includes a collapsible list of call cards, wherein each of the call cards is associated with one of the plurality of active auto-routed emergency calls. Each of the plurality of call cards displays at least one selected from the group consisting of an emergency caller identifier, an emergency caller location, an in-field first responder identifier, an in-field first responder location, an incident identifier, and an incident location. Each of the plurality of call cards includes at least one selected from the group consisting of a call join graphical control, a call redirect graphical control, a PTT graphical control, a view transcription graphical control, an incident associate graphical control, and an incident disassociate graphical control. The electronic processor is configured to control the display to present the graphical user interface.

For ease of description, some or all of the example devices and systems presented herein are illustrated with a single example of each of their component parts. Some examples may not describe or illustrate all components of the devices and systems. Other example embodiments may include more or fewer of each of the illustrated components, may combine some components, or may include additional or alternative components.

<FIG> illustrates an example public safety communications system <NUM>. <FIG> shows one example of a networked configuration, in which embodiments may be implemented. Other configurations are possible. In the example shown, the system <NUM> includes a call routing computing device <NUM>, a <NUM> call routing system <NUM>, and a public safety answering point (PSAP) <NUM>. It should be understood that the system <NUM> is provided as one example and, in some embodiments, the system <NUM> may include fewer or additional components. As would be understood by one skilled in the art, <FIG> is a simplified diagram. Networks are more complex than the schematic elements depicted in <FIG>.

The call routing computing device <NUM>, <NUM> call routing system <NUM>, and PSAP <NUM> are communicatively coupled to one another via a communications network <NUM>. The communications network <NUM> is a communications network including wireless connections, wired connections, or combinations of both. The communications network <NUM> may be implemented using a wide area network, for example, the Internet (including public and private IP networks), a Long Term Evolution (LTE) network, a Global System for Mobile Communications (or Groupe Spécial Mobile (GSM)) network, a Code Division Multiple Access (CDMA) network, an Evolution-Data Optimized (EV-DO) network, an Enhanced Data Rates for Global Evolution (EDGE) network, a <NUM> network, a <NUM> network, <NUM> network and one or more local area networks, for example, a Bluetooth™ network or Wi-Fi network, and combinations or derivatives thereof.

The call routing computing device <NUM>, described more particularly with respect to <FIG>, is communicatively coupled to the <NUM> call routing system <NUM> and the PSAP <NUM>. As illustrated in <FIG>, in some embodiments, the call routing computing device <NUM> is its own device or system, located apart from the <NUM> call routing system <NUM> and the PSAP <NUM>. In alternative embodiments, the <NUM> call routing system <NUM> may be co-located with or integrated into the <NUM> call routing system or the PSAP <NUM>.

As described in detail herein, the call routing computing device <NUM> is configured to receive emergency calls from the <NUM> call routing system <NUM>, and selectively route the calls between the PSAP <NUM> and in field first responders (for example, to a portable communications device <NUM> of a first responder <NUM>). For example, an emergency caller <NUM> (that is, a citizen or other non-first responder) encountering an incident <NUM> may place an emergency call (for example, by dialing <NUM>-<NUM>-<NUM>) using an emergency caller communications device <NUM>.

In some embodiments, the emergency caller communications device <NUM> is a portable communications device including hardware and software configured to communicate via the cellular network <NUM>. The emergency caller communications device <NUM> may be, for example, a smart telephone, a mobile two-way radio, a smart watch, a laptop computer, a tablet computer, or another similar device capable of operating as described herein.

The cellular network <NUM> may operate according to an industry standard cellular protocol, for example, the Long Term Evolution (LTE) (including LTE-Advanced or LTE-Advanced Pro compliant with, for example, the 3GPP TS <NUM> specification series), or the <NUM> standard (including a network architecture compliant with, for example, the 3GPP TS <NUM> specification series and a new radio (NR) air interface compliant with the 3GPP TS <NUM> specification series), among other possibilities, and over which, among other things, an open mobile alliance (OMA) push to talk (PTT) over cellular (OMA-PoC), a voice over IP (VoIP), or a PTT over IP (PoIP) application may be implemented.

An emergency call placed via the cellular network is routed to the <NUM> call routing system <NUM>. In <FIG>, the <NUM> call routing system <NUM> represents the hardware and telecommunications infrastructure of a <NUM> system. The <NUM> call routing system <NUM> may include aspects of an Enhanced <NUM> (E911) system, a Next Generation <NUM> (NG911) system, or both. The <NUM> call routing system <NUM> operates to receive emergency calls placed by, among others, subscribers of the cellular network <NUM> and route those calls to a public safety answering point (for example, the PSAP <NUM>). The <NUM> call routing system <NUM> chooses a PSAP for an emergency call based on the caller's current location (for example, as determined using a geolocation system contained in the emergency caller communications device <NUM>). Embodiments described herein are not limited in their application to emergency calls placed via cellular networks and may apply to emergency calls placed using landlines (e.g., the public switched telephone network, IP phones, and the like) or through other means. In some embodiments, emergency calls may be placed automatically by, among other things, an IoT device.

An emergency call placed by the emergency caller communications device <NUM> and routed to the PSAP <NUM> through the <NUM> call routing system <NUM> is intercepted prior to connection with the PSAP <NUM> by the call routing computing device. As described in greater detail herein, the call routing computing device <NUM> receives incident-related context information and routes the emergency call based on the context information. For example, the location <NUM> of the incident <NUM>, an identity of the emergency caller <NUM>, an incident identifier, or other information may be used to match the emergency caller to the first responder <NUM>. In such instances, the call routing computing device <NUM> routes the emergency call to the portable communications device <NUM> of the first responder <NUM>, rather than connecting the emergency call to the PSAP <NUM>.

The PSAP <NUM> includes a dispatch computer <NUM>, a database <NUM>, and a call-taking terminal <NUM>. The dispatch computer <NUM>, database <NUM>, and call-taking terminal <NUM> are communicatively coupled using one or more wired and/or wireless networks (not shown). A call taker <NUM> interacts with the call-taking terminal <NUM> to answer communications, including emergency calls, received at the PSAP <NUM> and access and modify data stored in the database <NUM>. The PSAP <NUM> performs computer aided dispatch (CAD) operations for law enforcement and other emergency services. Computer aided dispatch operations are known and will not be described in detail.

Communications received at the PSAP <NUM> include voice communications, for example, emergency calls received via the cellular network <NUM>, the <NUM> call routing system <NUM>, and the call routing computing device <NUM>. In some embodiments, the PSAP <NUM> sends and receives other types of voice communications, including, for example, two-way radio communications, using other communications networks (not shown). Communications received at the PSAP <NUM> may also include data communications, including, for example, short message service (SMS) messages and multimedia message service (MMS) messages (collectively referred to herein as "text messages"), email messages, pages, instant messages, and the like.

The dispatch computer <NUM> includes, among other things, a processor (for example, a microprocessor or another suitable programmable device), a memory (i.e., a computer-readable storage medium), an input/output interface (not shown), and various other hardware and software components for performing computer aided dispatch, call control, and other operations at a PSAP.

The dispatch computer <NUM> is communicatively coupled to the call-taking terminal <NUM>, which includes one or more input devices, output devices, or input and output devices including, for example, one or more displays, keyboards, keypads, mice, joysticks, touchscreens, speakers, microphones, and headsets. The dispatch computer <NUM> receives input from and provides output (including emergency calls) to the call taker <NUM> through the call-taking terminal <NUM>. The dispatch computer <NUM> and the call-taking terminal <NUM> are capable of controlling call handling hardware and software (not shown) to originate and terminate voice calls (for example, emergency calls), text message communications, and other forms of electronic communication either alone, or by interfacing with network equipment (not shown) in the communications network <NUM> and other communications networks.

The dispatch computer <NUM> is communicatively coupled to, and writes data to and from, the database <NUM>. As illustrated in <FIG>, the database <NUM> may be a database housed on a suitable database server communicatively coupled to and accessible by the dispatch computer <NUM> and the call routing computing device <NUM>. In alternative embodiments, the database <NUM> may be part of a cloud-based database system (for example, a data warehouse) external to the system <NUM> and accessible by components of the system <NUM> over one or more wired or wireless networks. In some embodiments, all or part of the database <NUM> may be locally stored on the dispatch computer <NUM>.

For example, the dispatch computer <NUM> may use data stored in the database <NUM> and received from members of the public and first responders (for example, the emergency caller <NUM> and the first responder <NUM>), and other sources to dispatch in-field first responders and other personnel to respond to incidents. In some embodiments the database <NUM> electronically stores incident data, responder data, and call data.

Incident data refers to incident records for public safety incidents. An incident record is a data structure within the database <NUM>, which contains information regarding a public safety incident, stored in a particular sequence and format. In some embodiments, the database <NUM> stores the incident data in a computer aided dispatch (CAD) incident database. As used herein, the terms "incident" and "public safety incident" refer to situations requiring the attention of one or more public safety agencies to protect the public and keep the public safe. In one example, an incident is a crime in progress, such as a bank robbery. In other examples, an incident is the response to a call for service, for example, responding to a traffic accident, searching for a suspect, locating a missing person, responding to a fire, responding to a medical emergency, investigating a past incident, and the like. The incident data for a given incident includes an incident type (for example, a crime, a fire, a medical emergency, a natural disaster, a traffic stop, and the like), an incident identifier (for example, a unique alphanumeric code that identifies the incident record within a computer-aided dispatch system), call identifiers identifying emergency and non-emergency calls received related to the incident, and the like.

Examples of responder data include responder identifiers (for example, name, rank, agency, assignment, and the like), an active incident assignment for a responder, a responder role (for example, identifying a supervisory role or an area of operation overall or within the incident), a responder location, responder equipment data (for example, model, configuration, and responder assignment information for portable communications devices).

Call data includes data for calls, including emergency calls, routed to the PSAP <NUM> or to in-field first responders in lieu of the PSAP <NUM>. Examples of call data include a call identifier (for example, a unique alphanumeric code that identifies the call record within a computer-aided dispatch system), an incident assignment associating the call with an incident, a location from which the call was placed, a caller identifier identifying the caller that placed the call, and the like.

The call taker <NUM> may be a dispatcher trained to handle incident communications. For example, within a next generation <NUM> system, the call taker <NUM> may be a public safety dispatcher trained to handle emergency communications. As noted above, these communications can include voice communications (for example, voice calls) and data communications (for example, text messages, email messages, pages, and the like). Based on the received communications, the call taker <NUM> may manually dispatch the appropriate services to handle incidents reported by individuals. Alternatively, or in addition, the dispatch computer <NUM> may be configured to automatically dispatch appropriate services. The dispatch computer <NUM> and the call-taking terminal <NUM> may also receive data input from the call taker <NUM>, which is saved to the database <NUM>. Generally, regardless of how or when an individual communicates with the PSAP <NUM> about an incident, information about the communication is stored in the database <NUM>.

<FIG> schematically illustrates one embodiment of the call routing computing device <NUM>. In the example illustrated, the call routing computing device <NUM> includes an electronic processor <NUM>, a memory <NUM>, a communication interface <NUM>, and an input/output interface <NUM>. The electronic processor <NUM>, the memory <NUM>, the communication interface <NUM>, and the input/output interface <NUM> communicate over one or more control and/or data buses (for example, a communication bus <NUM>). In some embodiments, the call routing computing device <NUM> is a computer server. <FIG> illustrates only one example embodiment of a call routing computing device <NUM>. The call routing computing device <NUM> may include fewer or additional components and may perform functions other than those explicitly described herein.

In some embodiments, the electronic processor <NUM> is implemented as a microprocessor with separate memory, for example, the memory <NUM>. In other embodiments, the electronic processor <NUM> may be implemented as a microcontroller (with memory <NUM> on the same chip). In other embodiments, the electronic processor <NUM> may be implemented using multiple processors. In addition, the electronic processor <NUM> may be implemented partially or entirely as, for example, a field-programmable gate array (FPGA), and application specific integrated circuit (ASIC), and the like and the memory <NUM> may not be needed or be modified accordingly. In the example illustrated, the memory <NUM> includes non-transitory, computer-readable memory that stores instructions that are received and executed by the electronic processor <NUM> to carry out functionality of the call routing computing device <NUM> described herein. The memory <NUM> may include, for example, a program storage area and a data storage area. The program storage area and the data storage area may include combinations of different types of memory, for example, read-only memory and random-access memory. In the embodiment illustrated, the memory <NUM> stores, among other things, incident information <NUM> (for example, incident records retrieved from the database <NUM>) and context information <NUM> (for example, as received from the emergency caller <NUM>).

The communication interface <NUM> sends and receives communications to and from the call routing computing device <NUM> and other components of the system <NUM>.

The input/output interface <NUM> may include one or more input mechanisms (for example, a touch screen, a keypad, buttons, knobs, and the like), one or more output mechanisms (for example, a display, a printer, a speaker, and the like), or a combination thereof. The input/output interface <NUM> receives input from input devices actuated by a user and provides output to output devices with which the user interacts. In some embodiments, as an alternative or in addition to managing inputs and outputs through the input/output interface <NUM>, the call routing computing device <NUM> may receive user input, provide user output, or both by communicating with an external device, for example, a console computer (for example, the call-taking terminal <NUM>), over a wired or wireless connection.

In some embodiments, the call routing computing device <NUM> uses one or more machine learning methods to analyze data to selectively route emergency calls (as described herein). Machine learning generally refers to the ability of a computer program to learn without being explicitly programmed. In some embodiments, a computer program (for example, a learning engine) is configured to construct an algorithm based on inputs. Supervised learning involves presenting a computer program with example inputs and their desired outputs. The computer program is configured to learn a general rule that maps the inputs to the outputs from the training data it receives. Example machine learning engines include decision tree learning, association rule learning, artificial neural networks, classifiers, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity and metric learning, sparse dictionary learning, and genetic algorithms. Using these approaches, a computer program can ingest, parse, and understand data and progressively refine algorithms for data analytics.

In some embodiments, one or more of the dispatch computer <NUM> and the call-taking terminal <NUM>, although having distinct functions and capabilities, include systems or devices having a similar general component configuration as the call routing computing device <NUM>, in that they each include a respective electronic processor, memory, communication interface, and input/output interface coupled by at least one communication bus.

<FIG> illustrates an example of the portable communications device <NUM> in more detail. In some of the embodiments described herein, the portable communications device <NUM> is a smart telephone. However, in alternative embodiments, the portable communications device <NUM> may be a cellular telephone, a smart watch, a tablet computer, a personal digital assistant (PDA), a portable radio, a converged device (including both land-mobile radio and cellular components), or other device that includes or is capable of being coupled to a network modem or components to enable wireless network communications (such as an amplifier, antenna, etc.) on cellular, land mobile, or other wireless communications networks.

In the embodiment illustrated, the portable communications device <NUM> is a wireless communications device, which includes an electronic processor <NUM>, a memory <NUM>, an input/output interface <NUM>, a baseband processor <NUM>, a transceiver <NUM>, an antenna <NUM>, microphone <NUM>, a loudspeaker <NUM>, and a display <NUM>. The illustrated components, along with other various modules and components are coupled to each other by or through one or more control and/or data buses that enable communication therebetween (for example, a communication bus <NUM>). In some embodiments, the portable communications device <NUM> includes fewer or additional components in configurations different from that illustrated in <FIG>.

The electronic processor <NUM> obtains and provides information (for example, from the memory <NUM> and/or the input/output interface <NUM>), and processes the information by executing one or more software instructions or modules, capable of being stored, for example, in a random access memory ("RAM") area of the memory <NUM> or a read only memory ("ROM") of the memory <NUM> or another non-transitory computer readable medium (not shown). The software can include firmware, one or more applications, program data, filters, rules, one or more program modules, and other executable instructions. The electronic processor <NUM> is configured to retrieve from the memory <NUM> and execute, among other things, software related to the control processes and methods described herein (for example, the call routing software <NUM>). For example, in the embodiment illustrated, the electronic processor <NUM> executes, among other things, location data <NUM>.

The memory <NUM> can include one or more non-transitory computer-readable media and includes a program storage area and a data storage area. The program storage area and the data storage area can include combinations of different types of memory, as described herein. In the embodiment illustrated, the memory <NUM> stores, among other things, an activation code (described in detail herein).

The input/output interface <NUM> is configured to receive input and to provide system output. The input/output interface <NUM> obtains information and signals from, and provides information and signals to, (for example, over one or more wired and/or wireless connections) devices both internal and external to the portable communications device <NUM>.

The electronic processor <NUM> is configured to control the baseband processor <NUM> and the transceiver <NUM> to transmit and receive radio frequency signals (for example, encoded with audio) to and from the portable communications device <NUM>. The baseband processor <NUM> encodes and decodes digital data (including digitized audio signals) sent and received by the transceiver <NUM>. The transceiver <NUM> transmits and receives radio signals to and from, for example, the communications network <NUM> (or another wireless network) using the antenna <NUM>. The electronic processor <NUM>, the baseband processor <NUM>, and the transceiver <NUM> may include various digital and analog components (for example, digital signal processors, high band filters, low band filters, and the like), which for brevity are not described herein and which may be implemented in hardware, software, or a combination of both. In some embodiments, the transceiver <NUM> includes a combined transmitter-receiver component. In other embodiments, the transceiver <NUM> includes separate transmitter and receiver components.

The microphone <NUM> is a transducer capable of sensing sound, converting the sound to electrical signals, and transmitting the electrical signals to the electronic processor <NUM>. The electronic processor <NUM> processes the electrical signals received from the microphone <NUM> to produce an audio signal, which may be transmitted to other devices via the transceiver <NUM>. The loudspeaker <NUM> is a transducer for reproducing sound from electrical signals (for example, generated from a received audio signal) received from the electronic processor <NUM>. The microphone <NUM> and the loudspeaker <NUM> support both audible and inaudible frequencies. In some embodiments, the microphone <NUM>, the loudspeaker <NUM>, or both may be integrated in a single housing with the other components (for example, in a portable hand-held radio). In some embodiments, the microphone <NUM>, the loudspeaker <NUM>, or both are present in an accessory device (for example, a remote speaker microphone (RSM)) connected via a wired or wireless connection to the portable communications device <NUM>.

The display <NUM> is a suitable display, for example, a liquid crystal display (LCD) touch screen, or an organic light-emitting diode (OLED) touch screen. In some embodiments, the portable communications device <NUM> implements a graphical user interface (GUI) (for example, generated by the electronic processor <NUM>, from instructions and data stored in the memory <NUM>, and presented on the display <NUM>), that enables a user to interact with the portable communications device <NUM>.

In some embodiments, the emergency caller communications device <NUM>, although having distinct functions and capabilities, includes hardware and software having a similar configuration as the portable communications device <NUM>.

As noted, terminating and processing all emergency calls at a PSAP may lead to inaccuracies being introduced into reported information, delayed incident response, and overuse of network and computing resources. To mitigate these problems, the call routing computing device <NUM> selectively routes some emergency calls directly to in-field first responders, bypassing the PSAP <NUM>. In one example embodiment, the call routing computing device <NUM> includes in the memory <NUM> call routing software <NUM>, which, when executed, performs an example method <NUM> for selectively routing emergency calls (illustrated in <FIG>). Although the method <NUM> is described in conjunction with the system <NUM> as described herein, the method <NUM> may be used with other systems and devices. In addition, the method <NUM> may be modified or performed differently than the specific example provided.

As an example, the method <NUM> is described as being performed by the call routing computing device <NUM> and, in particular, the electronic processor <NUM>. In some embodiments, the electronic processor <NUM> includes multiple electronic processors included in the call routing computing device <NUM> that perform all or a portion of the method <NUM>. Further, in some embodiments, the call routing computing device <NUM> is a distributed controller in which processors of multiple devices cooperate to form the call routing computing device <NUM> and perform its functionality. In some embodiments, portions of the method <NUM> may be performed by other devices, including for example, the portable communications device <NUM>, the dispatch computer <NUM>, and the call-taking terminal <NUM>. It should be understood that, while the method <NUM> is described in terms of a single emergency caller communications device <NUM>, a single call-taking terminal <NUM>, and a single portable communications device <NUM>, in some embodiments, the method <NUM> is applicable to combinations of one or more emergency caller communications devices, portable communications devices, dispatch computers and call-taking terminals.

At block <NUM>, the electronic processor <NUM> receives an emergency call. For example, the communication interface <NUM> receives an emergency call from the <NUM> call routing system <NUM> with routing instructions or data indicating that the call is to be terminated at the PSAP <NUM>. Prior to connecting the emergency call to the call-taking terminal <NUM> or more generally to the PSAP <NUM>, the electronic processor <NUM> (at blocks <NUM>-<NUM>) determines whether to connect the emergency call as intended by the <NUM> call routing system or route the emergency call to an in-field first responder.

At block <NUM>, the electronic processor <NUM> determines one or both of an identity of the emergency caller and a location of the emergency caller. For example, the electronic processor <NUM> may receive a location for the emergency caller <NUM> from the cellular network <NUM>. In some embodiments, the emergency caller communications device <NUM> may transmit context information, including a location for and identity of the emergency caller <NUM>, to the call routing computing device <NUM>. In some embodiments, the emergency caller communications device <NUM> may embed the context information as part of the emergency call (for example, using an NG911 or other suitable protocol). In some embodiments, the emergency caller communications device <NUM> may transmit the context information, directly or indirectly, to the call routing computing device <NUM> outside of the emergency call.

At block <NUM>, the electronic processor <NUM> retrieves (for example, via the communication interface <NUM>) active incident information from one or more incident records databases associated with the PSAP <NUM> (for example, stored in the database <NUM>). For example, the electronic processor <NUM> may transmit a query to the database <NUM> requesting records that match the identity or the location of the emergency caller, or both. In some embodiments, the database <NUM> returns active incident information identifying one or more active incidents associated with the identity of the emergency caller, the location of the emergency caller, or both. For example, the database <NUM> may return information including an incident identifier for the incident <NUM> (see <FIG>), the incident location <NUM>, and identities and locations for in-field first responders associated with the incident (for example, the first responder <NUM>).

At block <NUM>, the electronic processor <NUM> identifies the identities, the locations, or both of one or more in-field first responders associated with the one or more active incidents. For example, the electronic processor <NUM> may extract from the data returned by the database <NUM> (at block <NUM>) the name and location of the first responder <NUM>, who is responding to the incident <NUM>.

At block <NUM>, the electronic processor <NUM> compares the one or both of the identity and the location of the emergency caller to the one or both of the identities and the locations of the one or more in-field first responders associated with the one or more active incidents to match, if possible, the emergency caller with an in-field first responder.

In some embodiments, the electronic processor <NUM> finds a match based on the comparison when the retrieved active incident information identifies a previous contact between the identity of the emergency caller and the identity of one of the one or more in-field first responders associated with the one or more active incidents. In some embodiments, a previous contact may include a stored indication of a prior voice or media call between the identity of the emergency caller and the identity of the one of the one or more in-field first responders in the retrieved active incident information (for example, in the incident record for the incident <NUM>). For example, the incident record for incident <NUM> may indicate that the emergency caller <NUM> has telephoned or exchanged text messages with the first responder <NUM> before in relation to the incident <NUM>. In another example, the incident record for incident <NUM> may indicate that the emergency caller <NUM> is mentioned in a report on the incident <NUM> drafted by the first responder <NUM>.

In some embodiments, the electronic processor <NUM> finds a match based on the comparison when the location of the emergency caller is within a distance threshold of one or more of the locations of the one or more in-field first responders. In another example, emergency caller <NUM> and the first responder <NUM> may be within a threshold distance of one another, regardless of their distances from the incident.

In some embodiments, the electronic processor <NUM> finds a match based on the comparison when the location of the emergency caller and one or more of the locations of the one or more in-field first responders are within a same incident location as identified in the retrieved active incident information. For example, the location for the emergency caller <NUM> and the location for the first responder <NUM> may both be within the boundaries of a geofence around the location <NUM> for the incident <NUM>.

In some embodiments, a match is based on a set of policies defined by the public safety agencies served by the PSAP. A policy is defined by the factors that go into determining a match, and a relative importance (for example, a weight) for each of the listed factors. Factors may include the locations of the incident, callers, and first responders; the age of a prior incident (for example, how much time has passed between a prior related incident and the current incident); first responder availability, and PSAP call volume.

Regardless of how a match is determined, at block <NUM>, when a match is found based on the comparison, the electronic processor <NUM> (at block <NUM>) routes (for example, via the communication interface <NUM>), the emergency call to one of the matching in-field first responders, rather than routing the emergency call to the PSAP or to the call-taking terminal at the PSAP. For example, the call routing computing device <NUM> may include hardware and software for connecting the emergency call directly to the portable communications device <NUM> of the first responder <NUM>.

In some embodiments, multiple matches may be determined. For example, both an identity-based match and a location-based match may be made, each to a different first responder. In such embodiments, the call routing computing device <NUM> will assign priorities to the matches, and route the call based on the priority of the match. For example, the call routing computing device <NUM> may route the emergency call to the highest priority match first and route to the next highest priority match if the highest priority match does not answer. In some embodiments, when a call routed based on the priority of the match goes unanswered, the call is re-routed to the PSAP or to the call-taking terminal at the PSAP.

In some embodiments, a default option sets priorities. For example, a match based on identity (e.g., a prior contact between the emergency caller and the in-field first responder) may be assigned the highest priority. In some embodiments, priority is assigned to matches based on preferences in policies provided by public safety agencies.

In some embodiments, when multiple matches of the same type are determined, the call routing computing device <NUM> assigns priorities to the matches based on the type of match. For example, where multiple identity-based matches are determined, factors such as the most recent correspondence may be used to rank the matches. In some embodiments, incident metadata may be used. For example, when an incident has multiple in-field first responders available, a preferred responder may be identified for the incident (e.g., an incident commander or other supervisor). In another example, where multiple location-based matches are determined, the matches may be ranked by distance (e.g., between the emergency caller and the in-field first responder). In some embodiments, the location-based matches may be ranked based on which in-field first responder can most quickly arrive at the location of the incident or the emergency caller.

In some embodiments, multiple matches are displayed on the call-taking terminal <NUM>, which allows the call taker <NUM> to override the routing a choose the in-field first responder or take the call directly. For example, the call taker <NUM> may override the chosen match by specifying an alternative or by indicating that the selection is not viable, in which case the call routing computing device <NUM> automatically chooses another in-field first responder (for example, the match with the next highest priority compared to the match marked as not viable by the call taker <NUM>).

In some embodiments, the call routing computing device <NUM> informs the emergency caller (for example, using a voice prompt) that the call is being routed to an in-field first responder familiar with the incident (for example, when a match is determined based on a prior contact). In some embodiments, the matching incident is identified to the emergency caller by listing an incident number. In some embodiments, the emergency caller is able confirm that they are calling about that incident (for example, using interactive voice response (IVR)). A confirmation (for example, speaking "yes" or pressing a specified touch tone digit) or no response from the emergency caller would be interpreted as acceptance, and the call would be routed to the matched in-field first responder as described herein. In some embodiments, where the match is determined based on location, the emergency caller may not be provided an opportunity to confirm or opt out of the automated call routing.

In some embodiments, the call routing computing device <NUM> transmits (for example, via the communication interface <NUM>), a call setup request message to a portable communications device associated with the one of the matching in-field first responders (for example, the portable communications device <NUM>). In some embodiments, as illustrated in <FIG>, the call setup request is presented to a user of the portable communications device <NUM> via a graphical user interface <NUM>. As illustrated in <FIG>, the graphical user interface <NUM> includes a map <NUM>, upon which is overlaid incident information. In the example embodiments illustrated, the call setup request message is presented in a popup window <NUM>, and the first responder has the option of denying the call using the deny button <NUM> or accepting the call using the accept button <NUM>. In some embodiments, when the first responder chooses the accept button <NUM>, the graphical user interface presents route information from the first responder's present location to the location of the incident or the emergency caller.

Returning to <FIG>, when the electronic processor <NUM> receives, (for example via the communication interface <NUM>), a call accept message from the portable communications device <NUM>, it connects the emergency call between the emergency caller communications device <NUM> and the portable communications device <NUM>.

When the electronic processor <NUM> receives, (for example via the communication interface <NUM>) in response to the call setup request message, a call denial message from the portable communications device <NUM>, the call routing computing device <NUM> connects the emergency call between the emergency caller communications device <NUM> and the PSAP <NUM>. Alternatively, in some embodiments, the call routing computing device <NUM> connects the emergency call between the emergency caller communications device <NUM> and the portable communications device of another available in field first responder who is available to receive emergency calls (for example, based on priorities assigned to the matches as described herein).

In some embodiments, the electronic processor <NUM> actively monitors or periodically determines the current call load at the PSAP <NUM>. When the call load at the PSAP <NUM> is below a threshold call load, and the PSAP <NUM> has sufficient capacity to handle the emergency call, and it may not be routed to in-field first responders. In some embodiments, when a match is found, the call routing computing device <NUM> only routes the emergency call to one of the matching in-field first responders when the call load at the PSAP <NUM> exceeds a threshold call load. In some embodiments, the call load threshold is adjusted during certain hours. For example, there may be time periods during which the in-field first responders are busier with patrol duties and ad hoc incident response (for example, during the evening hours on the weekends) and are therefore less able to take calls. Such time periods may be identified by the dispatch computer <NUM>, using historical data from the database <NUM>. During these time periods, the threshold call load may be increased to reduce automated routing of emergency calls to in-field first responders.

In some embodiments, when a match is found, the call routing computing device <NUM> only routes emergency calls to in-field first responders when one of the matching in-field first responders is identified in a stored database (for example, the database <NUM>) at the PSAP <NUM> as being available for receiving emergency calls. For example, some in-field first responders may be actively engaged in responding to other aspects of the incident and be marked in the database <NUM> as unavailable for calls.

In some embodiments, the call routing computing device receives additional incident-related context information from the emergency caller. For example, the context information may include relationship information indicating a relationship to one or more persons already identified in the active incident information. For example, the emergency caller may be related to a victim of or witness to the incident. In another example, the emergency caller may reside at the same address or work for the same employer as other callers or persons involved in the incident.

In another example, the context information may include additional descriptive information regarding one or more persons already identified in the active incident information. For example, the emergency caller may indicate in their call, or via another means, that they have more information about a victim of or witness to the incident.

In another example, the context information may include sensor information regarding one or more persons already identified in the active incident information. For example, the emergency caller may have video of the incident including images of a victim of or witness to the incident.

In such embodiments, when a match is found between the identity of the emergency caller and one or more identities of the one or more in-field first responders, the electronic processor <NUM> determines to which one of the matching in-field first responders the emergency call is routed based on the additional incident-related context information. For example, three in-field first responders may be matched to the emergency caller based on their locations. However, the call may be routed to one of three because that in-field first responder has interviewed a witness for which the caller has additional information.

In some embodiments, when a match is found (at block <NUM>), the call routing computing device <NUM> only routes emergency calls to in-field first responders when the match exceeds a quality threshold. In such embodiments, the call routing computing device <NUM> assigns a quality level to each match. In some embodiments, the quality level is a numerical value (for example, a percentage or a number assigned from a defined range) that indicates a level of certainty or confidence in the match. In such embodiments, the quality threshold is a numerical value that indicates a preferred level of certainty that must be reached before an emergency call with be automatically routed. For example, an exact match between an emergency caller phone number and a prior contact with an in-field first responder that occurred within the timeframe of the incident may result in a high (for example, <NUM>% on a <NUM>% scale) quality level. In another embodiment, an emergency caller who presents with only a last name that matches a last name from a prior contact that is older than <NUM> hours may result in a mid-range (for example, <NUM>% on a <NUM>% scale) quality level. In some embodiments, the call routing computing device <NUM> routes emergency calls to in-field first responders based on a quality threshold and another factor. For example, an emergency call may be routed to an in-field first responder only when the quality level exceeds a minimum threshold and the distance of the in-field first responder is within a determined range (for example, a five-minute response time).

In some embodiments, when a match is found (at block <NUM>) and the call is routed to an in-field first responder (at block <NUM>), the call routing computing device <NUM> provides (for example, via a separate link to the PSAP <NUM> from the call routing computing device <NUM>), voice and data for the emergency call to an operator console device (for example, the call-taking terminal <NUM>) at the PSAP <NUM>. In this way, even though the call is being handled by the in-field first responder, the audio and certain data for the call may still be monitored, interacted with, and stored by the PSAP <NUM>. For example, the dispatch computer <NUM> or call-taking terminal <NUM> may produce a text transcription from the call audio. In some embodiments, the call routing computing device <NUM> provides, with data for the emergency call, the identity of the emergency caller and the identity of the one of the matching in-field first responders to the operator console device. In some embodiments, the call routing computing device <NUM> stores the voice and data for the emergency call in the database <NUM>.

Finally, at block <NUM>, when a match is not found based on the comparison, the electronic processor <NUM> (at block <NUM>) routes (for example, via the communication interface <NUM>), the emergency call to the PSAP <NUM> or to the call-taking terminal <NUM> at the PSAP <NUM>, rather to any of the one or more in-field first responders.

As noted, in some embodiments, when the call is routed to an in-field first responder (at block <NUM>), the call routing computing device <NUM> provides voice and data for the emergency call to an operator console device (for example, the call-taking terminal <NUM>) at the PSAP <NUM>. <FIG> illustrates an example graphical user interface <NUM> generated for a call-taking terminal <NUM>, which allows the call taker <NUM> to monitor and interact with emergency calls that have been routed to in-field first responders. As illustrated in <FIG>, the graphical user interface <NUM> includes a primary window <NUM> including a map <NUM>, and a plurality of auto-routed emergency caller indicators (for example, indicators <NUM>, <NUM>) overlaid on the map <NUM>. Each of the plurality of auto-routed emergency caller indicators is associated with one of a plurality of active auto-routed emergency calls.

The graphical user interface <NUM> also includes a secondary window <NUM> including a collapsible list of call cards <NUM>. Each of the call cards <NUM> is associated with one of the plurality of active auto-routed emergency calls.

As illustrated, each of the plurality of call cards <NUM> displays at least one of an emergency caller identifier, an emergency caller location, an in-field first responder identifier, an in-field first responder location, an incident identifier, and an incident location.

Each of the plurality of call cards includes a number of graphical control elements. For example, the call join graphical control <NUM>, which enables the call taker <NUM> to join the emergency call already in progress between the emergency caller and the in-field first responder. Another example is the call redirect graphical control <NUM>, which redirects the call from the in-field first responder back to the PSAP <NUM>. Another example is the PTT graphical control <NUM>, which establishes a push-to-talk communication between the call-taking terminal <NUM> and a push-to-talk capable device associated with the in-field first responder. Another example is the view transcription graphical control <NUM>, which, when selected, displays (for example, in a popup window) a text transcript of the emergency call in progress. Another example is the incident associate graphical control <NUM>. When an emergency call has not yet been associated with an active incident, selecting this control allows the call taker <NUM> to choose an active incident, to which the call will be associated, or to create a new incident for the call. Another example is the incident disassociate graphical control <NUM>. When an emergency call has been associated with an active incident, selecting this control allows the call taker <NUM> to remove the association with the active incident. In some embodiments, selecting this control also prompts the call taker <NUM> to select another incident with which to associate the call.

Moreover in this document, relational terms for example, first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," "has", "having," "includes", "including," "contains", "containing" or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises. a", "includes. a", "contains. a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms "a" and "an" are defined as one or more unless explicitly stated otherwise herein. The terms "substantially," "essentially," "approximately," "about" or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within <NUM>%, in another embodiment within <NUM>%, in another embodiment within <NUM>% and in another embodiment within <NUM>%. The term "coupled" as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is "configured" in a certain way is configured in at least that way but may also be configured in ways that are not listed.

It should also be understood that although certain examples depict components as logically separate, such depiction is merely for illustrative purposes. In some embodiments, the illustrated components may be combined or divided into separate software, firmware and/or hardware. Regardless of how they are combined or divided, these components may be executed on the same computing device or may be distributed among different computing devices connected by one or more networks or other suitable communication means.

In addition, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (for example, comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

Claim 1:
A method for routing an emergency call between a public safety answering point, PSAP, (<NUM>) and in-field first responders (<NUM>), the method comprising:
determining, at a call routing computing device (<NUM>), one or both of an identity of an emergency caller (<NUM>) and a location of the emergency caller (<NUM>);
retrieving, by the call routing computing device (<NUM>), based on the one or both of the identity and the location of the emergency caller (<NUM>), active incident information from one or more incident records databases associated with the PSAP (<NUM>), the active incident information identifying one or more active incidents associated with the one or both of the identity and the location of the emergency caller (<NUM>);
identifying, by the call routing computing device (<NUM>), one or both of identities and locations of one or more in-field first responders (<NUM>) associated with the one or more active incidents;
determining a current call load at the PSAP (<NUM>);
comparing the one or both of the identity and the location of the emergency caller (<NUM>) to the one or both of the identities and the locations of the one or more in-field first responders (<NUM>) associated with the one or more active incidents, and:
when a match is found based on the comparison, routing, by the call routing computing device (<NUM>), the emergency call to one of the matching in-field first responders (<NUM>) and not to the PSAP (<NUM>) and not to a call-taking terminal (<NUM>) at the PSAP (<NUM>) only when the call load at the PSAP (<NUM>) exceeds a threshold call load; and
when a match is not found based on the comparison, routing, by the call routing computing device (<NUM>), the emergency call to the PSAP (<NUM>) or to the call-taking terminal (<NUM>) at the PSAP (<NUM>) and not to any of the one or more in-field first responders (<NUM>).