Patent Description:
<CIT> discloses an emergency call load handling system in a call network featuring an interactive voice response (IVR) unit associated with a switching apparatus. Calls may be diverted to this unit during special conditions, such as emergencies or disasters, when calls to certain destinations experience a sudden increase. Call diversion occurs based on factors like call destination or pre-programmed triggers, such as call load thresholds. The IVR unit may negotiate with callers for priority call routing and play pre-recorded messages. Low priority calls are typically directed to fire stations, hospitals, government emergency handling centers, etc. Real-time rule amendments may occur via data network connections between call centers and the involved SCPs.

<CIT> discusses a system for managing chat automation, comprising a processor and memory coupled to it. The memory stores instructions that, when executed by the processor, enable it to receive interaction requests and information from end user devices, select automated chat profiles based on this information, route requests to corresponding automated chat resources, monitor chat sessions, detect trigger events, and transition sessions to contact center resources in response to detected triggers.

<CIT> describes systems and methods for handling calls placed on hold. Upon receiving a call from a caller at a public safety access point, an Artificial Intelligence (AI) bot monitors the context associated with the call and may determine, based on this context, whether the call should be taken off hold.

In the accompanying figures similar or the same reference numerals may be repeated to indicate corresponding or analogous elements. These figures, together with the detailed description, below are incorporated in and form part of the specification and serve to further illustrate various embodiments of concepts that include the claimed invention, and to explain various principles and advantages of those embodiments.

Public-Safety Answering Point (PSAP) operation may include multiple human users in multiple roles, such as call takers, dispatchers (e.g., for one or more types of first responders such as police officers, fire fighters, emergency medical technicians, etc.), supervisors, and the like. In extreme situations of critically low staffing or unusually high call and/or incident volume, or both (as may occur during a natural disaster, a major public-safety incident, etc.), a PSAP may need to continue operation with significantly reduced staffing. Hence, there exists a need for an improved technical method, device, and system for transitioning a public-safety answering point to an automated review mode.

In particular, provided herein is a PSAP device, which may initially operate in a manual mode, in which calls are routed to human users, and, in particular, to communication devices operated by human users, for manual incident data entry by the human users, among other possibilities such as manual call answering and/or manual text answering, and the like. Due to a natural disaster, a major public safety incident, a staffing issue, among other possibilities, a number of the calls may exceed an ability of the human users to handle the calls; similarly, a number of incidents to be handled may exceed an ability of the human users to handle the incidents. Such conditions, among other possibilities where a number of calls may exceed an ability of the human users to handle the calls, are referred to herein as overload conditions. The PSAP device may be generally configured to detect such an overload condition and, in response, transition from the manual mode to an automated review mode, in which at least a portion of the calls are routed to one or more bots (e.g., automated call answer engines and/or bot engines, and the like) for automated incident data entry. In such an automated review mode, incident indicators, parsed from the calls, by the one or more bots, are rendered at a display screen for review by a human user, such as one of the human users that were initially answering calls in the manual mode; hence, a role of such a human user may also transition from a manual role, in which the human answers calls, to a bot supervisor role in which the human user reviews and/or manually corrects information determined by a bot (e.g., and which may include entering information which a bot does not detect). In particular, the PSAP device may detect in that a bot-generated particular incident indicator meets a low confidence condition and the PSAP device may change a rendered characteristic of the bot-generated particular incident indicator to indicate that the human user is to review, and possibly intervene, for example to manually correct information determined by a bot (e.g., and which may include entering information which a bot does not determine). Hence, the PSAP device may assign confidence levels to bot-determined information which indicate accuracy of entries (e.g., and/or lack of an entry) of a bot.

An aspect of the specification provides a method comprising: operating a public-safety answering point (PSAP) device in a manual mode, in which calls are routed to human users for manual incident data entry; detecting, at the PSAP device, an overload condition, in which a number of the calls exceeds an ability of the human users to handle the calls; in response to detecting the overload condition, transitioning the PSAP device from the manual mode to an automated review mode, in which: the calls are routed to one or more bots for automated incident data entry; and incident indicators, parsed from the calls by the one or more bots, are rendered at a display screen for review by a human user; and in response to detecting that a bot-generated particular incident indicator meets a low confidence condition, changing, via the PSAP device, a rendered characteristic of the bot-generated particular incident indicator to indicate that the human user is to intervene.

Another aspect of the specification provides a public-safety answering point (PSAP) device comprising: a communication unit; and a controller communicatively coupled to the communication unit, the controller configured to: operate in a manual mode, in which calls, received via the communication unit, are routed to human users for manual incident data entry; detect an overload condition, in which a number of the calls exceeds an ability of the human users to handle the calls; in response to detecting the overload condition, transition from the manual mode to an automated review mode, in which: the calls are routed, via the communication unit, to one or more bots for automated incident data entry; and incident indicators, parsed from the calls by the one or more bots, are rendered at a display screen for review by a human user; and in response to detecting that a bot-generated particular incident indicator meets a low confidence condition, change a rendered characteristic of the bot-generated particular incident indicator to indicate that the human user is to intervene.

Example embodiments are herein described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to example embodiments. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a special purpose and unique machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. The methods and processes set forth herein need not, in some embodiments, be performed in the exact sequence as shown and likewise various blocks may be performed in parallel rather than in sequence. Accordingly, the elements of methods and processes are referred to herein as "blocks" rather than "steps.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions, which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus that may be on or off-premises, or may be accessed via the cloud in any of a software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (IaaS) architecture so as to cause a series of operational blocks to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions, which execute on the computer or other programmable apparatus provide blocks for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. It is contemplated that any part of any aspect or embodiment discussed in this specification can be implemented or combined with any part of any other aspect or embodiment discussed in this specification.

Further advantages and features consistent with this disclosure will be set forth in the following detailed description, with reference to the drawings.

Attention is directed to <FIG>, which depicts an example system <NUM> for transitioning a public-safety answering point to an automated review mode. The various components of the system <NUM> are in communication via any suitable combination of wired and/or wireless communication links, and communication links between components of the system <NUM> are depicted in <FIG>, and throughout the present specification, as double-ended arrows between respective components; the communication links may include any suitable combination of wireless and/or wired links and/or wireless and/or wired communication networks.

Herein, reference will be made to engines, such as automated call-answer engines and/or bot engines, which may be understood to refer to hardware, and/or a combination of hardware and software (e.g., a combination of hardware and software includes software hosted at hardware such that the software, when executed by the hardware, transforms the hardware into a special purpose hardware, such as a software module that is stored at a processor-readable memory implemented or interpreted by a processor), or hardware and software hosted at hardware and/or implemented as a system-on-chip architecture and the like.

The system <NUM> comprises a public-safety answering point (PSAP) device <NUM>, which is interchangeably referred to hereafter as the device <NUM>. The device <NUM>, is generally configured to receive calls reporting incidents, such as public-safety incidents, and the like, on behalf of a PSAP, such as a <NUM>-<NUM>-<NUM> call-center, and the like.

For example, as depicted, an integer number of "N" calls <NUM>-<NUM>. <NUM>-N, received from calling devices <NUM>-<NUM>. <NUM>-N, are being received at the device <NUM>. The calls <NUM>-<NUM>. <NUM>-N are interchangeably referred to hereafter, collectively, as the calls <NUM>, and, generically and/or individually, as a call <NUM>; this convention will be used elsewhere in the present specification. For example, the calling devices <NUM>-<NUM>. <NUM>-N are interchangeably referred to hereafter, collectively, as the calling devices <NUM> and, generically and/or individually, as a calling device <NUM>.

As depicted, the calling devices <NUM> may comprise mobile devices, but the calling devices <NUM> may comprise any suitable communication device for making a call <NUM> to the device <NUM> including, but not limited to, the depicted mobile devices, public switched telephone network (PSTN) telephones, laptops, personal computers, and the like. Furthermore, a call <NUM> may occur via any suitable wireless or wired network and may include, but are not limited to, mobile phone calls, PSTN calls, Internet Protocol (IP) calls, calls made using applications, and the like.

However, in other examples a call <NUM> may be in a format other than a phone call, such as a text message, a short message service (SMS) message, multimedia messaging service (MMS) messages, video calls, and the like.

In particular, a user of a calling device <NUM> may initiate a call <NUM> using a number (e.g., "<NUM>") for the PSAP, for example to report an incident. The device <NUM> automatically receives and/or answers the call <NUM> thereby causing a communication link between the device <NUM> and a calling device <NUM> to be generated using any suitable combination of wired and/or wireless networks.

As depicted, the system <NUM> further comprises an integer number of "M" communication devices <NUM>-<NUM>. <NUM>-M (e.g., communication devices <NUM> and/or a communication device <NUM>) in communication with the device <NUM> via respective communication links. The communication devices <NUM> are operated by respective human users <NUM>-<NUM>. <NUM>-M (e.g., human users <NUM> and/or a human user <NUM>).

As depicted, the communication device <NUM> may comprise respective display screens <NUM>-<NUM>. <NUM>-M (e.g., display screens <NUM> and/or a display screen <NUM>) and one or more respective input devices <NUM>-<NUM>. <NUM>-M (e.g., input devices <NUM> and/or an input device <NUM>) such as keyboards (e.g., as depicted), pointing devices, and the like.

The communication devices <NUM> are further understood to comprise components for communicating with users of the calling devices <NUM> on the calls <NUM>, such as speakers and/or microphones and the like (e.g., which may be provided, as depicted, as headsets worn by the human users <NUM>). While not depicted, the communication devices <NUM> may optionally comprise cameras for communicating with users of the calling devices <NUM> on the calls <NUM>.

In particular examples, the communication devices <NUM> may comprise dispatch terminals, personal computers, laptop computers, and/or the like, to which the device <NUM> may route a call <NUM>, for example as represented by dashed double ended arrows between the calls <NUM> and communication links to the communication devices <NUM>. In some examples, a communication device <NUM> may be physically located at a PSAP facility, while in other example a communication device <NUM> may be physically located at a remote location such as a home, and the like, of an associated human user <NUM> (e.g., in a work-from-home scenario).

Regardless, a human user <NUM> may answer a call <NUM> at a communication device <NUM>. Such human users <NUM> may be in a call-taker role (e.g., such as a <NUM>-<NUM>-<NUM> call-takers and the like), however some of the human users <NUM> may be in supervisor role and/or a dispatcher role (e.g., to dispatch public-safety units to incidents, and the like) and/or some of the human users <NUM> may perform more than one role.

Hereafter, while calls <NUM> are described as being routed to the human users <NUM> for manual incident data entry, it is understood that such routing is to the communication devices <NUM>, and the like.

In particular, in <FIG>, it is understood that the device <NUM> is operating in a manual mode, in which calls are routed to the human users <NUM> for manual incident data entry. For example, as depicted, the device <NUM> and/or the communication device <NUM>-<NUM> is controlling the display screen <NUM>-<NUM> to provide (e.g., at least partially) a manual incident data entry mechanism <NUM> in conjunction with routing the call <NUM>-<NUM> to the communication device <NUM>-<NUM>. The manual incident data entry mechanism <NUM> includes various fields <NUM>, at which data may be manually entered via the human user <NUM>-<NUM> operating the input device <NUM>-<NUM>. As depicted, some of the fields <NUM> may be automatically filled in by the PSAP device <NUM>, such as an automatically assigned incident number, a phone number of the calling device <NUM>-<NUM>, and the like. However, other fields <NUM>, such as an incident "Type" field, an incident "Status" field, a public safety unit (PSU) assignment (PSU Assign. ) field, in incident "Address" field, and the like, are understood to be manually filled in via the human user <NUM>-<NUM> operating the input device <NUM>-<NUM> as the human user <NUM>-<NUM> is talking to a user (not depicted) of the calling device <NUM>-<NUM> on the call <NUM>-<NUM>. In some examples, the incident "Address" field may also be automatically determined, for example when the device <NUM> is implementing an enhanced <NUM> system, and the like, and/or an automatic location identification system and the like, and/or when a phone company and/or calling application (e.g., at a calling device <NUM>) provides location information (e.g., as metadata on a call <NUM>) that includes the address, and the like.

The information provided in the fields <NUM> may be referred to as incident indicators, which indicate information regarding an incident being reported via a call <NUM>. In the manual mode, at least a portion of such incident indicators are determined and/or parsed from a call <NUM> by a human user <NUM>, entered into the fields <NUM> via an input device <NUM>, and rendered at a respective display screen <NUM>. Furthermore, in the manual mode, a human user <NUM> is understood to handle a single call <NUM> at any given time. While not depicted, the mechanism <NUM> may include a free-form notes field and/or an incident narrative field and/or an incident description field, such that free-form manual text entry may be provided therein, for example by the human user <NUM>.

While a similar manual incident data entry mechanism is not depicted at the display screen <NUM>-M, such a manual incident data entry mechanism is understood to be provided at any of the display screens <NUM> when a call <NUM> is routed to a respective human user <NUM>.

An "N" number of calls <NUM> and calling devices <NUM> are depicted in <FIG>, which may be any suitable number, and which may vary over time, for example as incidents (e.g., public safety incidents), and the like, occur. Similarly, an "M" number of human users <NUM> (e.g., and communication devices <NUM>) are depicted in <FIG>, which may be any suitable number, and which may vary over time, for example as the human users <NUM> come onto a shift, or leave a shift, and the like. Ideally, there are a suitable number of "M" human users <NUM> that can handle the "N" number of calls <NUM>. In some of these examples, when the number of calls <NUM> exceeds the number of human users <NUM>, a portion of the calls <NUM> may be answered at the device <NUM>, and placed into a queue (not depicted) at the device <NUM> to wait for an available human user <NUM>.

However, in some examples, one or more overload conditions may occur at the device <NUM>. In particular, an overload condition may occur when a number "N" of the calls <NUM> exceeds an ability of the human users <NUM> to handle the calls <NUM>. Such an overload condition may occur, for example, when a natural disaster occurs and/or when a major public safety incident occurs, among other possibilities, and/or when the number "M" of the human users <NUM> is reduced due to sickness, the natural disaster (e.g., some of the human users <NUM> may not be able to make it to the PSAP and/or may have communications cut off to their communication devices <NUM> due to the natural disaster) and the like.

In some examples, an overload condition may comprise the number "N" of calls <NUM> being greater than the number "M" of human users <NUM>. In other examples, an overload condition may comprise the number "N" of calls <NUM> being greater than the number "M" of human users <NUM> by a given amount, for example, <NUM>% higher, <NUM>% higher, <NUM>% higher, among other possibilities. In further examples, an overload condition may comprise a queue at the device <NUM> including a given number of the calls <NUM>. In yet further examples, an overload condition may comprise a wait time of a queue at the device <NUM> being above a threshold wait time (e.g., a wait time being understood to a time period between a call <NUM> being automatically answered at the device <NUM> and placed in a queue, and the call <NUM> being routed to a human user <NUM>). However, any suitable overload condition, in which a number of the calls <NUM> exceeds an ability of the human users <NUM> to handle the calls <NUM>, is within the scope of the present specification. For example, an overload condition may include a number of the actions and/or work items to be performed as a result of the calls <NUM> may exceed an ability of the human users <NUM> to handle; such actions and/or work items may include, but is not limited to, determining for each of the calls <NUM> an incident type, a PSU to be dispatched, and the like, as well as populating the fields <NUM>, dispatching a PSU, and the like.

As will be explained in further detail below, when an overload condition is detected at the device <NUM>, the device <NUM> may transition from the manual mode to an automated review mode, in which the calls <NUM>, and/or at least a portion of the calls <NUM>, are routed to one or more bots <NUM> for automated incident data entry. In particular, the one or more bots <NUM> (interchangeably referred to hereafter collectively as the bots <NUM> and generically/individually as a bot <NUM>), may comprise automated call answer engines and/or bot engines, and the like, which are configured to answer the calls <NUM> and "talk" to users of the calling devices <NUM> such that incident indicators are parsed from the calls <NUM> by the one or more bots <NUM> and rendered at a display screen <NUM> for review by a human user <NUM>.

For example, a bot <NUM> may include, and/or have access to, a speech-to-text engine, and the like, which converts speech, on a call <NUM>, to text, for example to generate a transcript of the call <NUM>; from such text and/or such a transcript, incident indicators such as an incident type, and the like, may be determined by a bot <NUM>. However, transcripts of calls <NUM>, as described herein, may alternatively (and/or additionally) include, but are not limited to, text to <NUM>-<NUM>-<NUM> transcripts (e.g., a transcript of a text and/or message based call <NUM>). Such a bot <NUM> may then assign an appropriate PSU to an associated incident; for example, a law-related incident may have a police PSU assigned to the associated incident, a fire-related incident may have a firefighter PSU assigned to the associated incident, a medical-related incident may have an emergency medical technician (EMT) PSU assigned to the associated incident, and the like.

Such incident indicators determined by a bot <NUM> may be referred to as a bot-generated incident indicator.

However, a bot <NUM> may make errors in determining one or more incident indicators and/or a bot <NUM> may fail to determine an incident indicator. For example, a bot <NUM> may not be able to determine an incident type as a user of a calling device <NUM> may be slurring their words, which may not be properly converted to text, and/or a user of a calling device <NUM> may be using code words to report an incident that are not understood by a bot <NUM> (e.g., such as "pizza" to covertly report domestic violence on a <NUM> call, and the like). As such, in these examples, an incident type may not be determined; alternatively, an incident type may be determined, but a PSU assignment may be delayed and/or may be pending until a more accurate determination of an incident type occurs (e.g., which may lead to an incident status of "Pending", as opposed to "Active", which occurs when a PSU is assigned to an incident).

Similarly, a bot <NUM> may incorrectly assign a PSU to an incident, for example due to an incorrect determination of an incident type, and the like. In a particular example, a caller on a call <NUM> may be excited and mention a minor fire (e.g., a campfire), which lead to an injury and a bot <NUM> may assign a firefighter PSU to the incident when an EMT PSU may be more appropriate. In some of these examples, a bot <NUM> may initially assign an incident type of "Fire" to the incident, but later change the incident type to "Injury", and the like, and change a PSU assignment from a firefighter PSU to an EMT PSU. In yet further examples, a bot <NUM> may change an incident type more than once.

Any of these situations may indicate that incident indicators determined (or not) by a bot <NUM> for a call <NUM> may not be accurate, among other possibilities. For example, continuing with the example above, a bot <NUM> may correctly determine that an incident is a "Fire" incident type, but may not correctly determine a type of FIRE PSU to assign to the incident. For example, a "Fire" incident type may include a structure fire incident (e.g., a fire at a building), forest fire incident, a car fire incident, among other possibilities, which may respectively require different types of FIRE PSUs; for example, one FIRE PSU may include a pumper truck, while another FIRE PSU may include a ladder truck, while yet another FIRE PSU may include a specially equipped hazardous materials truck (e.g. for cleaning up hazardous materials) and/or team with special skills and/or training (e.g. related to hazardous materials), some of which may be appropriate for some fire incident types, but not appropriate for other fire incident types. For example, a FIRE PSU may include a ladder truck may not be appropriate for a forest fire incident type. Hence, while a given incident type for a call <NUM> might be quickly determined by a bot <NUM>, the bot <NUM> may not quickly determine a type of PSU to dispatch, and/or may change (e.g., and/or continuously change) from PSU type to another, which may lead to delays in determining incident indicators and hence may also lead to delays in responding to an incident. However, any suitable situation, that may indicate that incident indicators determined, or not determined, by a bot <NUM> for a call <NUM> may not be accurate, is within the scope of the present specification.

As such, the device <NUM> assigns confidence levels to incident indicators associated with a call <NUM> answered by a bot <NUM>. Such confidence levels indicate an accuracy and/or confidence that a given incident indicator is accurate.

In a particular example, incident indicators for a call <NUM>, which are not determined by a bot <NUM> may be assigned a null value and may be automatically assigned a relatively low and/or zero confidence level.

In another example, a bot <NUM> changing an incident indicator once, or more than once, may lead to a relatively low confidence level. For example, a bot <NUM> may change an incident type once, or more than once, as a caller on a call <NUM> may first mention a fire, then an injury, then a police-related incident, and the like. Similarly, a bot <NUM> may change a PSU assignment once, or more than once, as a caller on a call <NUM> mentions different information. Each situation may result in a relatively low confidence level for an incident type and/or a PSU assignment determined by a bot <NUM>.

In yet a further example, an incident status being "Pending" for a given period of time may lead to a relatively low confidence level.

Such confidence levels may be determined via numerical algorithms while in other examples such confidence levels may be determined via machine learning algorithms, as described in more detail below.

In some examples, a confidence level may be provided in form of a percentage value that ranges from <NUM>% to <NUM>%, however a confidence level may be provided in any suitable format.

The device <NUM> may compare a confidence level of a bot-generated particular incident indicator to a low confidence condition to determine whether the bot-generated particular incident indicator meets the low confidence condition. In some examples, the low confidence condition may comprise a threshold confidence level, below which a confidence level is understood to indicate inaccuracy of an associated bot-generated particular incident indicator. Such a threshold confidence level may, for example, be a confidence level of <NUM>%, <NUM>%, <NUM>%, among other possibilities. Such a low confidence condition may further be specific to an associated incident indicator; for example, incident type incident indicators may have a threshold confidence level of <NUM>%, while status incident indicators may have a threshold confidence level of <NUM>%.

In such an automated review mode, a human user <NUM> may be concurrently provided with incident indicators for a plurality of the calls <NUM> (and/or for one or more calls <NUM>), at a respective display screen <NUM> (e.g., of a respective communication device <NUM>) so that the human user <NUM> can review the incident indicators and intervene in some appropriate manner as describe hereafter.

In particular, the device <NUM>, in response to detecting that a bot-generated particular incident indicator meets a low confidence condition, may change a rendered characteristic of the bot-generated particular incident indicator at the respective display screen <NUM> to indicate that the human user <NUM> should, and/or may need to, intervene. For example, an incident type incident indicator, associated with a call <NUM>, and which is determined (or not) by a bot <NUM>, that meets a low confidence condition may be changed to particular color and/or font, and/or may be depicted in a box, and/or highlighted in any suitable manner at a display screen <NUM>, to indicate and/or visually indicate that the incident type incident indicator has met a low confidence condition. Furthermore, the rendered characteristic of the bot-generated particular incident indicator that is changed at the respective display screen <NUM>, to indicate that the human user <NUM> should, and/or may need to, intervene, may change to indicate a particular confidence level. For example, a bot-generated particular incident indicator that has a confidence level of <NUM>%, may be changed to a first color (e.g. yellow), while a bot-generated particular incident indicator that has a confidence level of <NUM>%, may be changed to a second color (e.g. red), among other possibilities. Put another way, a rendered characteristic of the bot-generated particular incident indicator may be changed according to confidence intervals (e.g. a confidence level of a bot-generated particular incident indicator in a confidence interval of <NUM>% to <NUM>% may cause the rendered characteristic to be "yellow", whereas a confidence level of a bot-generated particular incident indicator in a confidence interval of below <NUM>% may cause the rendered characteristic to be "red", and the like). As such, the human user <NUM> may manually assign and/or change an incident type associated with the call <NUM>. However, the human user <NUM> may manually assign and/or change any suitable bot-generated incident indicator.

In conjunction with manually assigning and/or changing in incident indicator for a call <NUM>, the human user <NUM> may be provided with one or more user-operable input mechanisms, such as electronic buttons and/or menu options, and the like, for reviewing a transcript of the call <NUM> and/or reviewing a geographic map of a region associated with the call <NUM> and/or reviewing details of an incident (e.g., one or more of which may be rendered at an associated display screen <NUM>).

Similarly, in conjunction with manually assigning and/or changing an incident indicator for a call <NUM>, a human user <NUM> may be provided with one or more user-operable input mechanisms for one or more of: reviewing audio of the call <NUM>; and/or connecting to the on-going call <NUM> (e.g., to talk to a caller); and/or connecting to a PSU assigned to an associated incident; and the like. Such one or more user-operable input mechanisms may include, but are not limited to, electronic buttons and/or menu options, and the like. Furthermore, reviewing audio of the call <NUM> and/or connecting to the on-going call <NUM> and/or connecting to a PSU may occur via a speaker and/or microphone (e.g. as appropriate) associated with a communication device <NUM> (e.g., a headset worn by the human user <NUM>). Hence, in some of these examples, the device <NUM> (e.g., and/or a bot <NUM>) may cause audio of a call <NUM> to be recorded and/or the device <NUM> is understood to include components for connecting a communication device <NUM> to call <NUM> and/or to a communication device of a PSU (not depicted).

Attention is next directed to <FIG>, which depicts a schematic block diagram of an example of the device <NUM>. In general, the device <NUM> may comprise one or more servers and/or one or more cloud computing devices, and the like, configured to communicate with the calling devices <NUM> and the communication devices <NUM>. However, the device <NUM> may comprise a computing device such as a personal computer and/or a laptop computer, and the like. In some examples, the device <NUM> may be combined with one or more of communication devices <NUM>. The device <NUM> may be located at a PSAP, and the like, and/or remote from a PSAP, and the like. Similarly, the device <NUM> may be located at a same facility (e.g., a PSAP) as one or more of the communication devices <NUM>, and the like, and/or the device <NUM> and one or more of the communication devices <NUM> may be remote from each other.

As depicted, the device <NUM> comprises: a communication unit <NUM>, a processing unit <NUM>, a Random-Access Memory (RAM) <NUM>, one or more wireless transceivers <NUM> (which may be optional), one or more wired and/or wireless input/output (I/O) interfaces <NUM>, a combined modulator/demodulator <NUM>, a code Read Only Memory (ROM) <NUM>, a common data and address bus <NUM>, a controller <NUM>, and a static memory <NUM> storing at least one application <NUM>. Hereafter, the at least one application <NUM> will be interchangeably referred to as the application <NUM>. Furthermore, while the memories <NUM>, <NUM> are depicted as having a particular structure and/or configuration, (e.g., separate RAM <NUM> and ROM <NUM>), memory of the device <NUM> may have any suitable structure and/or configuration.

As shown in <FIG>, the device <NUM> includes the communication unit <NUM> communicatively coupled to the common data and address bus <NUM> of the processing unit <NUM>; hence, processing unit <NUM> and/or the controller <NUM> is understood to be communicatively coupled to the communication unit <NUM>.

The processing unit <NUM> may include the code Read Only Memory (ROM) <NUM> coupled to the common data and address bus <NUM> for storing data for initializing system components. The processing unit <NUM> may further include the controller <NUM> coupled, by the common data and address bus <NUM>, to the Random-Access Memory <NUM> and the static memory <NUM>.

The communication unit <NUM> may include one or more wired and/or wireless input/output (I/O) interfaces <NUM> that are configurable to communicate with other components of the system <NUM>. For example, the communication unit <NUM> may include one or more transceivers <NUM> and/or wireless transceivers for communicating with other suitable components of the system <NUM>. Hence, the one or more transceivers <NUM> may be adapted for communication with one or more communication links and/or communication networks used to communicate with the other components of the system <NUM>. For example, the one or more transceivers <NUM> may be adapted for communication with one or more of the Internet, a digital mobile radio (DMR) network, a Project <NUM> (P25) network, a terrestrial trunked radio (TETRA) network, a Bluetooth network, a Wi-Fi network, for example operating in accordance with an IEEE <NUM> standard (e.g., <NUM>. 11a, <NUM>. 11b, <NUM>), an LTE (Long-Term Evolution) network and/or other types of GSM (Global System for Mobile communications) and/or 3GPP (<NUM>rd Generation Partnership Project) networks, a <NUM> network (e.g., a network architecture compliant with, for example, the 3GPP TS <NUM> specification series and/or a new radio (NR) air interface compliant with the 3GPP TS <NUM> specification series) standard), a Worldwide Interoperability for Microwave Access (WiMAX) network, for example operating in accordance with an IEEE <NUM> standard, and/or another similar type of wireless network. Hence, the one or more transceivers <NUM> may include, but are not limited to, a cell phone transceiver, a DMR transceiver, P25 transceiver, a TETRA transceiver, a 3GPP transceiver, an LTE transceiver, a GSM transceiver, a <NUM> transceiver, a Bluetooth transceiver, a Wi-Fi transceiver, a WiMAX transceiver, and/or another similar type of wireless transceiver configurable to communicate via a wireless radio network.

The communication unit <NUM> may further include one or more wireline transceivers <NUM>, such as an Ethernet transceiver, a USB (Universal Serial Bus) transceiver, or similar transceiver configurable to communicate via a twisted pair wire, a coaxial cable, a fiber-optic link, or a similar physical connection to a wireline network. The transceiver <NUM> may also be coupled to a combined modulator/demodulator <NUM>.

The controller <NUM> may include ports (e.g., hardware ports) for coupling to other suitable hardware components of the system <NUM>.

The controller <NUM> may include one or more logic circuits, one or more processors, one or more microprocessors, and/or the controller <NUM> may include one or more ASIC (application-specific integrated circuits) and one or more FPGA (field-programmable gate arrays), and/or another electronic device. In some examples, the controller <NUM> and/or the device <NUM> is not a generic controller and/or a generic device, but a device specifically configured to implement functionality for transitioning a public-safety answering point to an automated review mode. For example, in some examples, the device <NUM> and/or the controller <NUM> specifically comprises a computer executable engine configured to implement functionality for transitioning a public-safety answering point to an automated review mode.

The static memory <NUM> comprises a non-transitory machine readable medium that stores machine readable instructions to implement one or more programs or applications. Example machine readable media include a non-volatile storage unit (e.g., Erasable Electronic Programmable Read Only Memory ("EEPROM"), Flash Memory) and/or a volatile storage unit (e.g., random-access memory ("RAM")). In the example of <FIG>, programming instructions (e.g., machine readable instructions) that implement the functional teachings of the device <NUM> as described herein are maintained, persistently, at the memory <NUM> and used by the controller <NUM>, which makes appropriate utilization of volatile storage during the execution of such programming instructions.

In particular, the memory <NUM> stores instructions corresponding to the at least one application <NUM> that, when executed by the controller <NUM>, enables the controller <NUM> to implement functionality for transitioning a public-safety answering point to an automated review mode, including but not limited to, the blocks of the process set forth in <FIG>.

Furthermore, as depicted, the memory <NUM> stores one or more overload conditions <NUM>, which may be used to determine whether to transition the PSAP device <NUM> from the manual mode to the automated review mode, as described herein. Alternatively, and/or in addition, the one or more overload conditions <NUM> may be incorporated into the application <NUM>.

Furthermore, as depicted, the memory <NUM> stores one or more low confidence conditions <NUM>, which may be used to determine when a rendered characteristic of a bot-generated particular incident indicator is to be changed to indicate that a human user <NUM> should, and/or may need to, intervene, as described herein. Alternatively, and/or in addition, the one or more low confidence conditions <NUM> may be incorporated into the application <NUM>.

As depicted, the memory <NUM> further stores one or more bot modules <NUM>, which, when implemented by the controller <NUM>, may cause at least a portion of the controller <NUM> to be transformed into one or more automated call-answer engines and/or one or more bot engines to implement the one or more bots <NUM>.

While not depicted, the memory <NUM> may further store one or more of a text-to-speech module, a speech-to-text module, an audio recording module, and the like, for respectively: converting text to speech (e.g., so that a bot <NUM> may "talk" on a call <NUM>); converting speech to text (e.g., to generate a transcript of a call <NUM>); and recording audio of a call <NUM>. However, as depicted, such modules are understood to be components of the application <NUM> and/or the one or more bot modules <NUM>.

In illustrated examples, when the controller <NUM> executes the one or more applications <NUM>, the controller <NUM> is enabled to: operate a public-safety answering point (PSAP) device (e.g., the device <NUM>) in a manual mode, in which calls are routed to human users for manual incident data entry; detect an overload condition, in which a number of the calls exceeds an ability of the human users to handle the calls; in response to detecting the overload condition, transition the PSAP device from the manual mode to an automated review mode, in which: the calls are routed to one or more bots for automated incident data entry; and incident indicators, parsed from the calls by the one or more bots, are rendered at a display screen for review by a human user; and in response to detecting that a bot-generated particular incident indicator meets a low confidence condition, change a rendered characteristic of the bot-generated particular incident indicator to indicate that the human user should, and/or may need to, intervene.

The application <NUM> may include programmatic algorithms, and the like, to implement functionality as described herein, which may include, but is not limited to, one or more programmatic algorithms.

Alternatively, and/or in addition to programmatic algorithms, the application <NUM> may include one or more machine learning algorithms to implement functionality as described herein, and which may include, but is not limited to, a machine learning algorithm. The one or more machine learning models and/or algorithms of the application <NUM> may include, but are not limited to: a deep-learning based algorithm; a neural network; a generalized linear regression algorithm; a random forest algorithm; a support vector machine algorithm; a gradient boosting regression algorithm; a decision tree algorithm; a generalized additive model; evolutionary programming algorithms; Bayesian inference algorithms, reinforcement learning algorithms, and the like. However, generalized linear regression algorithms, random forest algorithms, support vector machine algorithms, gradient boosting regression algorithms, decision tree algorithms, generalized additive models, and the like may be preferred over neural network algorithms, deep learning algorithms, evolutionary programming algorithms, and the like, in some public-safety environments. Any suitable machine learning algorithm and/or deep learning algorithm and/or neural network, and the like, is within the scope of the present specification.

In examples where the application <NUM> includes one or more machine learning algorithms, the device <NUM> may be operated in a learning mode to "teach" the one or more machine learning algorithms to determine when an overload condition <NUM> occurs at the device <NUM>. Similarly, in such a learning mode, the one or more machine learning algorithms may be taught to determine when a bot-generated incident indicator meets a low confidence condition <NUM>.

While the components of the devices <NUM>, <NUM>, are not described in detail, it is understood that components of such devices may be similar to the components of the device <NUM>, but adapted for respective functionality thereof as described herein.

Attention is now directed to <FIG>, which depicts a flowchart representative of a process <NUM> for transitioning a public-safety answering point to an automated review mode. The operations of the process <NUM> of <FIG> correspond to machine readable instructions that are executed by the device <NUM>, and specifically the controller <NUM> of the device <NUM>. In the illustrated example, the instructions represented by the blocks of <FIG> are stored at the memory <NUM> for example, as the application <NUM>. The process <NUM> of <FIG> is one way in which the controller <NUM> and/or the device <NUM> and/or the system <NUM> may be configured. Furthermore, the following discussion of the process <NUM> of <FIG> will lead to a further understanding of the system <NUM>, and its various components.

The process <NUM> of <FIG> need not be performed in the exact sequence as shown and likewise various blocks may be performed in parallel rather than in sequence. Accordingly, as previously mentioned, the elements of process <NUM> are referred to herein as "blocks" rather than "steps. " The process <NUM> of <FIG> may be implemented on variations of the system <NUM> of <FIG>, as well.

Furthermore, it is understood that the controller <NUM> and/or the device <NUM> may implement the process <NUM> via the application <NUM> as a process different from, but in conjunction with, implementation of the bot modules <NUM> and/or the bots <NUM> (e.g. the application <NUM> and/or the process <NUM> may comprise an application and/or process for supervising the bots <NUM>). However, in other examples, aspects of the bots <NUM> may be integrated with the process <NUM>.

At a block <NUM>, the controller <NUM> and/or the device <NUM>, operates in a manual mode and/or substantially manual mode, in which the calls <NUM> (e.g., received via the communication unit <NUM>) are routed to the human users <NUM> for at least some portion of manual incident data entry. The manual mode and/or substantially manual mode may, in some examples, be aided by some automated entry. Such a manual mode and/or substantially manual mode is as described above (e.g., and is depicted) with respect to <FIG>. Hereafter, references to a manual mode is understood to include a substantially manual mode, among other possibilities.

At a block <NUM>, the controller <NUM> and/or the device <NUM> detects whether an overload condition <NUM> occurs. As has already been described, an overload condition <NUM> occurs when a number of the calls <NUM> exceeds an ability of the human users <NUM> to handle the calls <NUM>. Hence, the device <NUM> is understood to monitor the number "N" of the calls <NUM>, the number "M" of human users <NUM> and/or communication device <NUM>, a call queue, a wait time of the call queue, and the like, to determine whether an overload condition <NUM> occurs.

When no overload condition <NUM> occurs (e.g., a "NO" decision at the block <NUM>), the controller <NUM> and/or the device <NUM> continues to operate in the manual mode at the block <NUM>.

However, in response to detecting an overload condition <NUM> (e.g., a "YES" decision at the block <NUM>), at a block <NUM>, the controller <NUM> and/or the device <NUM> transitions from the manual mode to an automated review mode, in which: the calls <NUM> are routed (e.g., via the communication unit <NUM>) to one or more bots <NUM> for (e.g. substantially) automated incident data entry; and incident indicators, parsed from the calls <NUM> by the one or more bots <NUM>, are rendered at a display screen <NUM> for review by a human user <NUM>. An example of such routing is described below with respect to <FIG>. It is understood that the automated review mode, described herein may be entirely automated, or initially automated with some manual review or entry only where the automated entry cannot be completed and/or the automated entry is completed with a bot-generated particular incident indicator meeting a low confidence condition <NUM> a low confidence, among other possibilities. Hence, put another way, the automated incident data entry described herein may include substantially automated incident data entry (though not all data entry may be entirely automated).

As understood herein, the term "parsed" may indicate that a bot <NUM> analyzes and/or parses text of a call <NUM>, for example as generated using a speech-to-text module, to determine respective incident indicators; however, the term "parsed" may indicate that a bot <NUM> determines incident indicators associated with call <NUM> in any suitable manner.

In some examples, a human user <NUM>, for example in a supervisor role, may be provided (e.g., at a respective display screen <NUM> of a respective communication device <NUM>) with options to approve the transition to the automated review mode; in such examples, the transition to the automated review mode may not occur until approved by a human user <NUM>, for example via operation of a respective input deice <NUM>.

Alternatively, and/or in addition, the human users <NUM> may be provided with a visual and/or audible notification (e.g., at a respective display screen <NUM> and/or speaker), that a transition to the automated review mode is going to occur. Such human users <NUM> who are presently engaged in a call <NUM> in the manual mode may be provided with an option to finish such a call <NUM>, or transition the call <NUM> to a bot <NUM> in the automated review mode.

Similarly, any calls <NUM> that are in a queue at the device <NUM> may be routed to a bot <NUM>.

At a block <NUM>, the controller <NUM> and/or the device <NUM> determines whether or not a bot-generated particular incident indicator meets a low confidence condition <NUM>.

The block <NUM> may hence include the controller <NUM> and/or the device <NUM> assigning respective confidence levels to bot-generated incident indicators and comparing such confidence levels to threshold confidence levels of the one or more low confidence conditions <NUM>, as described herein.

Any suitable scheme may be used to assign respective confidence levels to bot-generated incident indicators. For example, as has already been described, confidence levels may be based on a number of times a value of bot-generated incident indicators changes (e.g., such as an incident type), with the confidence level decreasing as a number of times a bot-generated incident indicators changes increases. However, confidence levels may be based on a transcript, and the like, of a call <NUM>, with words and/or sentences that lead to bot-generated incident indicators being evaluated using natural language processing algorithms (e.g., which may be provided as modules of the application <NUM>, and the like); hence, in these examples, a confidence level of a bot-generated incident indicator may be generated via such natural language processing algorithms. For example, certain words and/or phrases of the transcript, and the like, may be assigned a confidence level using such natural language processing algorithms to indicate whether a speech-to-text conversion of such words and/or phrases is accurate; for example, inaccuracies may be due to slurred speech of caller on a call <NUM>, and the like. Similarly, certain words may raise or lower the confidence level, and certain combinations of words may raise or lower the confidence level, of one or more bot-generated incident indicators, for example as the call <NUM> progresses. Put another way, the confidence level may change as the call <NUM> progresses.

In other examples, a confidence level may be generated based on whether, or not, an address of a caller on a call <NUM> may be determined; for example, when an enhanced <NUM> system, and/or an automatic location identification system and the like fails to provide an address and/or provides only a general area of the call <NUM> (e.g., such as cell area), and/or a caller on a call <NUM> fails to provide an address, a relatively low and/or zero confidence level may be assigned to an address.

However, a confidence level for a bot-generated incident indicator may be determined in any suitable manner, such that the confidence level is indicative of an estimated accuracy of the bot-generated incident indicator. As previously mentioned, a confidence level may be provided in form of a percentage value that ranges from <NUM>% to <NUM>%. Similarly, a low confidence condition <NUM> may comprise a threshold confidence level provided in the form of a percentage value, such as <NUM>%, <NUM>%, <NUM>%, among other possibilities; in these examples, a confidence level meeting a low confidence condition <NUM> may comprise a percentage value of a confidence level being less than (e.g., or equal to), a percentage value of a threshold confidence level of low confidence condition <NUM>.

However a confidence level and/or a low confidence condition <NUM> may be provided in any suitable format.

In particular examples, a confidence level may not be assigned to a bot-generated particular incident indicator. Rather, a low confidence condition <NUM> may be provided in the form of a machine learning classifier, a neural network layer, and the like, and the controller <NUM> and/or the device <NUM> may determine whether or not a bot-generated particular incident indicator meets a low confidence condition <NUM> using such a machine learning classifier, neural network layer, and the like.

In some examples, a bot-generated particular incident indicator, which meets (e.g., or does not meet) a low confidence condition <NUM> may comprises one or more of: an incident type of an incident associated with a call <NUM> answered by the one or more bots <NUM>; a status of the incident; a public-safety unit assignment to the incident; an address of the incident; amongst other possibilities. Indeed, any suitable incident indicator is within the scope of the present specification.

When a bot-generated particular incident indicator does not meet a low confidence condition <NUM> (e.g., a "NO" decision at the block <NUM>), the controller <NUM> and/or the device <NUM> continues to monitor bot-generated particular incident indicators at the block <NUM> to determine whether a bot-generated particular incident indicator meets a low confidence condition <NUM>.

However, in response to detecting that a bot-generated particular incident indicator meets a low confidence condition <NUM> (e.g., a "YES" decision at the block <NUM>), at block <NUM>, the controller <NUM> and/or the device <NUM> changes a rendered characteristic of the bot-generated particular incident indicator to indicate, and/or visually indicate, that a human user <NUM> should, and/or may need to, intervene, for example to manually assign and/or change the suitable bot-generated incident indicator.

A rendered characteristic of the bot-generated particular incident indicator that may be changed to indicate that a human user <NUM> should, and/or may need to, intervene, may include one or more of a color, a font, a size, a graphical indication, and the like, of the bot-generated particular incident indicator. In a particular example, described below with respect to <FIG>, a box, and the like, may be placed around a bot-generated particular incident indicator to indicate that a bot-generated particular incident indicator meets a low confidence condition <NUM>; alternatively the box, and/or another rendered characteristic of the bot-generated particular incident indicator may be changed according to confidence intervals, as described above.

Furthermore, in some examples, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation an action is implemented, which assists a human user <NUM> in determining how to assign and/or change the suitable bot-generated incident indicator.

For example, such a user-operable input mechanism may include an electronic button, a menu option and/or various selectable options provided in response to a hover event at the bot-generated incident indicator (e.g., when a pointing device is used to hover at and/or select the bot-generated incident indicator).

In some of these examples, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation, a transcript of a call <NUM> associated with the bot-generated particular incident indicator is rendered at a display screen <NUM>, the call <NUM> being conducted by the one or more bots <NUM>.

In other examples, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation, audio of at least a portion of a call <NUM> associated with the bot-generated particular incident indicator is played at a speaker (e.g., at a headset and the like, the call <NUM> being conducted by the one or more bots <NUM>). In some examples, the portion of a call <NUM> that is played at the speaker may comprise a portion of the call <NUM> that is used to determine whether a bot-generated particular incident indicator meets a low confidence condition <NUM>, and/or the portion of a call <NUM> that is played at the speaker may comprise a portion of the call <NUM> that caused a bot-generated particular incident indicator to meet a low confidence condition <NUM>.

In some of these examples, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation, available details of an incident of a call <NUM> associated with the bot-generated particular incident indicator is rendered at a display screen <NUM>, the call <NUM> being conducted by the one or more bots <NUM>.

In yet further examples, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation, a human user <NUM> is connected, and/or audibly connected, to an ongoing call <NUM> associated with the bot-generated particular incident indicator, the ongoing call having been initially answered by the one or more bots <NUM>. Such connections to an ongoing call <NUM> may include connecting to an ongoing voice call and/or connections to an ongoing message-based call (e.g., SMS message calls and/or MMS message calls and/or video calls, and the like).

In yet further examples, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation, a human user <NUM> is connected, and/or audibly connected, to a PSU assigned to an incident associated with a call <NUM>, the call <NUM> being conducted by the one or more bots <NUM>. Such a connection may alternatively, and/or additionally, include connecting to a PSU using message-based calls.

In yet further examples, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation, a geographic map is rendered at a display screen <NUM>, the geographic map including at least one location related to a call <NUM> associated with the bot-generated particular incident indicator.

Indeed, any suitable information, in any suitable format, may be provided to a human user <NUM>, which may assist the human user <NUM> in determining a more accurate value for a bot-generated particular incident indicator, which may be assigned and/or changed by the human user <NUM>, for example, from a bot-generated value (e.g., which may include a null value) to a manually-received value.

Hence, the process <NUM> may include the controller <NUM> and/or the device <NUM> providing a user-operable input mechanism, in which, responsive to activation, input is received at an input device <NUM> to change the bot-generated particular incident indicator from a bot-generated value to a manually-received value.

In particular, the process <NUM> may include the controller <NUM> and/or the device <NUM>: receiving, at an input device <NUM>, input associated with the bot-generated particular incident indicator; and in response to receiving the input, activating a user-operable input mechanism to change the bot-generated particular incident indicator from one or more of a null value and a bot-generated value to a manually-received value.

In this manner, a human user <NUM> may change and/or update a bot-generated particular incident indicator.

In a particular example, a bot-generated particular incident indicator may comprise an indeterminate value, such as a null value, as described above. The process <NUM> may hence include the controller <NUM> and/or the device <NUM>: providing a user-operable input mechanism, in which, responsive to activation, input is received at an input device to change the bot-generated particular incident indicator from the indeterminate value to a manually-received value, for example determined by a human user <NUM> and provided by the human user <NUM> via an input device <NUM>, and the like.

The controller <NUM> and/or the device <NUM> may continue to monitor bot-generated particular incident indicators at the block <NUM> to determine whether a bot-generated particular incident indicator meets a low confidence condition <NUM>.

While not depicted, the controller <NUM> and/or the device <NUM> may continue to implement the block <NUM> concurrently with the block <NUM>, the block <NUM> and/or the block <NUM> and, in response to detecting that an overload condition <NUM> is no longer occurring (e.g., a "NO" decision at the block <NUM>), the controller <NUM> and/or the device <NUM> may transition back to the manual mode at the block <NUM>. Such a transition may occur upon approval by a supervisor (e.g., via a respective display screen <NUM> and input device <NUM>), and furthermore human users <NUM> reviewing bot-generated incident indicator may be provided with a notification that a transition to the manual mode is to occur (e.g., via respective display screens <NUM>).

It is further understood that in the manual mode, a human user <NUM> may typically handle a single call. In the automated review mode, incident indicators provided at a display screen <NUM>, may be associated with one or more of a plurality of the calls <NUM> and a plurality of incidents, such that a human user <NUM> reviews the incident indicators for one or more of the plurality of the calls <NUM> and the plurality of incidents at any given time, typically without speaking to any one caller in the calls <NUM> (e.g. unless a user-operable input mechanism is actuated). In particular, a portion of a plurality of calls <NUM> may be for a same incident, and/or a portion of a plurality of calls <NUM> may be for a different incidents.

It is further understood that <FIG> provides an example of the block <NUM> of the process <NUM>. Attention is next directed to <FIG>, <FIG>, <FIG>, and <FIG> which provide examples of the block <NUM>, the block <NUM>, the block <NUM> and the block <NUM> of the process <NUM>.

In particular, attention is next directed to <FIG>, which is substantially similar to <FIG>, with like components having like numbers. However, in <FIG>, the one or more of the communication devices <NUM> may have gone offline, for example, as indicated by an indicator <NUM> at a communication link between the device <NUM> and the communication device <NUM>-M. It is understood, however, in the example of <FIG> that at least the communication device <NUM>-<NUM> remains online.

As such, a number of the calls <NUM> is determined by the device <NUM> to exceeds an ability of the (e.g., remaining) human users <NUM> to handle the calls <NUM>, and the device <NUM> hence detects (e.g., a "YES" decision at the block <NUM> of the process <NUM>), an overload condition <NUM>, as shown by an indicator <NUM>.

As also depicted in <FIG>, the device <NUM> transitions (e.g., at the block <NUM> of the process <NUM>) from the manual mode shown in <FIG>, to an automated review mode, in which the calls <NUM> are routed <NUM> to one or more of the bots <NUM>.

As also depicted in <FIG>, the display screen <NUM>-<NUM> of the communication device <NUM>-<NUM> is controlled to provide a call status monitor <NUM>, at which incident indicators parsed from the calls <NUM> by the one or more bots <NUM>, are for review by the human user <NUM>-<NUM>. Such a call status monitor <NUM>, as well as the block <NUM> and the block <NUM>, are described with respect to <FIG>, <FIG> and <FIG>.

In particular, an example of the call status monitor <NUM> is depicted in more detail in <FIG>, which is labelled a "Universal Status Monitor" in <FIG>. It is understood in <FIG> that while the call status monitor <NUM> is depicted without the display screen <NUM>-<NUM>, the call status monitor <NUM> is rendered at the display screen <NUM>-<NUM> and fields thereof are populated via the device <NUM> and/or the bots <NUM>.

For example, with reference to <FIG>, the call status monitor <NUM> may be provided in a tabular format, in which each row corresponds to a different call <NUM> answered by a bot <NUM>. Columns of the call status monitor <NUM> may correspond to a particular incident indicator. Similar to the mechanism <NUM>, a portion of the incident indicators may be automatically assigned and/or determined, such as an incident number (e.g., "Incident #") and/or a phone number. In particular, a call <NUM> is understood to be associated with an incident and an incident number may be assigned to call <NUM> by the device <NUM> and/or a bot <NUM>. It is understood that, in <FIG>, <FIG> and <FIG>, the incident numbers of the calls <NUM> do not typically change.

However, another portion of the incident indicators are understood to be parsed and/or determined from the calls <NUM> by the one or more bots <NUM> for review by the human user <NUM>-<NUM>. Such incident indicators, as depicted, may include, but are not limited to:.

However, any other suitable incident indicators and/or other information may be provided at the call status monitor <NUM>. For example, as depicted, a timer (e.g., "Timer") is also provided indicating a length of a call <NUM> with a bot <NUM>, as well as a phone status (e.g., "Phone Status") indicating whether a call <NUM> is in progress (e.g., "In progress"), ended (e.g., "Released") or in a format other than a phone call (e.g., "SMS"), and the like.

While not depicted, yet further information may be provided at the call status monitor <NUM> including, but not limited to, a unit status of a PSU assigned to an incident (e.g., indicating whether a PSU is assigned, en-route and/or on-scene), an acknowledgement unit status of the PSU assigned to an incident (e.g., indicating whether or not an assigned PSU has acknowledged an assignment), and the like.

Yet further information provided at the call status monitor <NUM> may include, but is not limited to, whether or not a call-taker, such as a human user <NUM>, has also been engaged in a call <NUM>, whether or not a dispatcher, such as a human user <NUM>, has also been engaged in a call <NUM>, and the like. Indeed, such examples illustrate that, while as depicted in <FIG>, the communication device <NUM>-<NUM> has transitioned to an automated review mode, and the human user <NUM>-<NUM> has transitioned from a manual call-taker role to a bot supervisor role, in which the human user <NUM>-<NUM> reviews and/or manually corrects information determined by a bot <NUM>; other human users <NUM>, operating other communication devices <NUM>, may continue to manually answer calls <NUM> and/or dispatch PSUs to incidents. However, in other examples, as described herein, one or more of the communication devices <NUM> may not have gone offline, but the number of calls <NUM> may lead to an overload condition <NUM>, in which all the communication device <NUM> are in an automated review mode, and all the human users <NUM> are transitioned to bot supervisor roles.

As also depicted in <FIG>, it is understood that the device <NUM> has determined (e.g., a "YES" decision occurs at the block <NUM> of the process <NUM>) that various bot-generated particular incident indicators meet one or more of the low confidence conditions <NUM>. As such, the device <NUM> changes a rendered characteristic of the various bot-generated particular incident indicator to indicate that the human user <NUM>-<NUM> should, and/or may need to, intervene.

For example, as depicted bot-generated incident indicators <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> (e.g., the indicators <NUM> and/or an indicator <NUM>) are rendered with boxes surrounding them, which indicate that such indicators <NUM> may require intervention by the human user <NUM>-<NUM>. Furthermore, the indicators <NUM>-<NUM>, <NUM>-<NUM> are provided as question marks, indicating that null values and/or indeterminate values have been assigned by a bot <NUM>, for example, as a bot <NUM> may not have been able to determine accurate (and/or any) values thereof. For example, for the indicator <NUM>-<NUM>, an incident type was not determined, and for the indicator <NUM>-<NUM>, an address was not determined; hence the indicators <NUM>-<NUM>, <NUM>-<NUM> meet a low confidence condition <NUM> associated with a bot <NUM> not being able to determine a value thereof.

In contrast, a bot <NUM> determined values for the indicators <NUM>-<NUM>, <NUM>-<NUM>, such as, respectively, an incident type and an assigned PSU identifier; however, the device <NUM> has determined that values for the indicators <NUM>-<NUM>, <NUM>-<NUM> meet a low confidence condition <NUM>. For example, the incident type of the indicator <NUM>-<NUM>, which presently is for an accident, may not be accurate and/or the assigned PSU of the indicator <NUM>-<NUM>, which presently is for a firefighter PSU, may not be accurate.

Similarly, the indicator <NUM>-<NUM> has a determine value of "Pending", which may indicate that a PSU unit has not been assigned to an associated incident, and a PSU unit, which a bot <NUM> attempted to assign to the associated incident may not be responding to the assignment; a delay in the assignment of a PSU may also be indicated by the associated time (e.g., the associated call <NUM> has been in progress for <NUM> minutes and <NUM> seconds).

It is further noted that the calls <NUM> of the call status monitor <NUM> are organized according to the indicators <NUM>. For example, calls <NUM> associated with the indicators <NUM>-<NUM>, <NUM>-<NUM> having null values, and the like are in a first group and labelled as requiring "Action", with a number "<NUM>" of the calls <NUM> also indicated; in particular, an "Action" is understood to be required as, without a determined incident type and/or a determined address, an appropriate PSU cannot be assigned to an associated incident and/or dispatched to an associated incident. Hence, in some examples, such as for the calls <NUM> associated with the indicators <NUM>-<NUM>, <NUM>-<NUM>, a response to an incident may not proceed until low confidence issues are resolved.

Similarly, calls <NUM> associated with the indicators <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> having determined values that meet a low confidence condition <NUM> are in a second group and labelled as requiring "Attention", with a number "<NUM>" of the calls <NUM> also indicated; in particular, "Attention" may be required by a human user <NUM> to better determine values for the indicators <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>. However, in contrast to the calls <NUM> associated with the indicators <NUM>-<NUM>, <NUM>-<NUM>, PSUs may be dispatched to the calls <NUM> associated with the indicators <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> as incident types and addresses, etc., are determined, though such PSUs may be dispatched erroneously and/or may not acknowledge such an assignment. Hence, in some examples, such as for the calls <NUM> associated with the indicators <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, a response to an incident may proceed without resolving low confidence issues, however information stored and/or provided at the PSAP device <NUM>, and/ or to a PSU, may not be entirely accurate as a result.

Similar, the call status monitor <NUM> also indicates calls <NUM> for which no indicators meet a low confidence condition <NUM>, for example labeled as "Other", along with a number "<NUM>" of such calls <NUM>, which may indicate that, for such calls <NUM>, no user attention or action may be required and/or suggested, and hence a response to an incident may proceed for such calls <NUM> (e.g., without intervention by a human user <NUM>).

As will next be explained, the human user <NUM>-<NUM> may operate the input device <NUM>-<NUM> to select an indicator <NUM>, which may cause one or more a transcript and/or audio of an associated call <NUM> to be provided, and/or which may cause a geographic map associated with a location of a call <NUM> to be provided, and/or which may cause details of an incident to be provided, and/or which may allow the human user <NUM> to connected, and/or audibly connected, to an ongoing call <NUM> and/or connect to an assigned PSU. For example, as depicted, a cursor <NUM> may be used to select and/or hover at an indicator <NUM> (e.g., as depicted, the indicator <NUM>-<NUM>); such a hover event may correspond to a user-operable input mechanism, which may be activated (e.g., upon "clicking" a point device controlling the cursor <NUM>), to activate an associated action, and/or to change and/or assign a value of an indicator, and the like.

For example, attention is next directed to <FIG>, which depicts various actions that may occur at the call status monitor <NUM> upon activation of a user-operable input mechanism by the human user <NUM>-<NUM>, for example a "click" on an indicator <NUM> using a pointing device controlling the cursor <NUM> and the like, though such actions may alternatively occur via electronic buttons, a menu, a voice command, and the like. For example, as depicted, various dialogue boxes <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> (e.g., dialogue boxes <NUM> and/or a dialogue box <NUM>) are depicted, each associated with a respective indicator <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>. <FIG> is further described with respect to <FIG>, which shows the call status monitor <NUM> after the human user <NUM>-<NUM> has assigned values to the indicator <NUM>-<NUM>, <NUM>-<NUM>, and/or changed the indicators <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>.

In particular, when a user-operable input mechanism associated with the indicator <NUM>-<NUM> is selected, a dialogue box <NUM>-<NUM> is rendered at the display screen <NUM>-<NUM> showing a transcript of an associated call <NUM>. The transcript indicates that a caller says the word "Pizza", which may be a code word for domestic violence. Hence, the human user <NUM>-<NUM> may change the indicator <NUM>-<NUM> to indicate an incident type of domestic violence (e.g., "DV"), as shown in <FIG>.

Similarly, when a user-operable input mechanism associated with the indicator <NUM>-<NUM> is selected, a dialogue box <NUM>-<NUM> is rendered at the display screen <NUM>-<NUM> showing a geographic map of an area and/or location of an associated call <NUM>. As depicted, the geographic map shows a cell of the associated call <NUM> and indicates a major intersection of <NUM>st and Main (e.g., which may be streets). Hence, the human user <NUM>-<NUM> may change the indicator <NUM>-<NUM> to indicate an address of <NUM>st and Main, as shown in <FIG>. In some examples, with reference back to <FIG>, the geographic map may be provided at the dialogue box <NUM>-<NUM> with an option to expand the geographic map.

Similarly, when a user-operable input mechanism associated with the indicator <NUM>-<NUM> is selected, a dialogue box <NUM>-<NUM> is rendered at the display screen <NUM>-<NUM> that includes an electronic button (e.g., the depicted triangle) that, when actuated, plays recorded audio of the associated call <NUM>. Hence, the human user <NUM>-<NUM> may activate the electronic button and listen to the audio; however, in this example, with reference to <FIG>, the human user <NUM>-<NUM> does not change the incident type of an accident, but rather may confirm (e.g., via any suitable input mechanism), that the incident type of the indicator <NUM>-<NUM> is accurate, thereby removing the box from the indicator <NUM>-<NUM> without otherwise changing the indicator <NUM>-<NUM>. Hence, in some examples, a human user <NUM> may confirm that an incident indicator, that was determined to meet a low confidence condition <NUM>, has been accurately determined by a bot <NUM>.

Similarly, when a user-operable input mechanism associated with the indicator <NUM>-<NUM> is selected, a dialogue box <NUM>-<NUM> is rendered at the display screen <NUM>-<NUM> that includes an electronic button (e.g., the depicted triangle) that, when actuated, connects, and/or audibly connects, the human user <NUM> to an ongoing associated call <NUM> (and/or connects the human user <NUM> to an ongoing associated message based call <NUM>). Hence, the human user <NUM>-<NUM> may activate the electronic button and join the ongoing associated call <NUM> to talk to a caller and/or communicate with a caller via text messaging, and the like. For example, the human user <NUM>-<NUM> may determine, in conversation with the caller, that while an associated incident type has been determined by a bot <NUM> to be a fire (e.g., "FIRE"), with a firefighter PSU (e.g., "F001") assigned thereto, the incident type is really a medical emergency. As such, with reference to <FIG>, the human user <NUM>-<NUM> may change the associated incident type to a medical incident type (e.g., "MED") and assign an EMT PSU (e.g., "M001") to the call <NUM>. Such an example illustrates that while the device <NUM> may determine that a given bot-generated particular incident indicator for a call <NUM> meets a low confidence condition <NUM>, other incident indicators for the call <NUM> may be modified and/or changed and/or assigned by a human user <NUM>.

Similarly, when a user-operable input mechanism associated with the indicator <NUM>-<NUM> is selected, a dialogue box <NUM>-<NUM> is rendered at the display screen <NUM>-<NUM> showing details of an incident of an associated call <NUM>. For example, as depicted, the dialogue box <NUM>-<NUM> includes the incident number, an associated address, a PSU that a bot <NUM> has attempted to assign to the associated incident (e.g., "U237") along with a status of the PSU, which, as depicted, is not responding to the assignment. However, any suitable available incident information may be provided at the dialogue box <NUM>-<NUM>.

As depicted, the dialogue box <NUM>-<NUM> may optionally include electronic buttons for accessing a transcript, and/or audio of the associated call <NUM> (e.g., similar to the dialogue boxes <NUM>-<NUM>, <NUM>-<NUM>), a geographic map of a location of the associated call <NUM> (e.g., similar to the dialogue box <NUM>-<NUM>), and/or, as depicted, an electronic button for calling the assigned PSU. As the associated call <NUM> has ended, however, there is no electronic button for joining the associated call <NUM> (e.g., the phone status of the associated call is "Released); however, in examples where an associated call <NUM> is ongoing, the dialogue box <NUM>-<NUM> may include an electronic button for joining the associated call <NUM>. However, the various electronic buttons at the dialogue box <NUM>-<NUM> may be optional.

Regardless, the human user <NUM>-<NUM> may review and/or access information provided via the dialogue box <NUM>-<NUM>, and change the indicator <NUM>-<NUM> to assign another PSU (e.g., "U737") to the associated incident, as shown in <FIG>, which may acknowledge the assignment (e.g., and hence, in <FIG>, the status has changed to "Active").

As is also depicted in <FIG>, as the various indicators <NUM> that met a low confidence condition <NUM> were resolved, all the calls <NUM> are now categorized as "Other". However, as more calls <NUM> are received, and/or as associated incident indicators are determined to meet a low confidence condition <NUM> are determined, the device <NUM> updates the call status monitor <NUM> accordingly.

It is further understood that while specific indicators <NUM> were described with respect to the example of <FIG>, <FIG> and <FIG>, any suitable incident indicators are within the scope of the present specification, and furthermore the call status monitor <NUM>, and the like, may be adapted to include any suitable incident indicators. Furthermore, while not depicted in the example of <FIG>, <FIG> and <FIG>, the call status monitor <NUM> and/or the communication device <NUM>-<NUM> may include any suitable mechanism for reviewing any suitable incident indicators, and not just the specific indicators <NUM> that were determined to meet a low confidence condition <NUM>. For example, the call status monitor <NUM> and/or the communication device <NUM>-<NUM> may receive input at the input device <NUM>-<NUM> and/or a microphone via actuation of buttons, electronic buttons, pull-down menu options, and/or receipt of voice commands, and the like, to select an incident indicator to review, which may cause the communication device <NUM>-<NUM> to provide any suitable associated information, such as a transcript, recorded audio of a call <NUM>, a geographic map, and the like, similar to as described above, and/or cause a human user <NUM> to join a call <NUM> and/or a call to a PSU, as described above, among other possibilities (e.g. notes and/or comments associated with a call <NUM> and the like).

It is understood that while the call status monitor <NUM> of <FIG>, <FIG>, <FIG>, and <FIG> are described herein with respect to block <NUM> and block <NUM> of the process <NUM>, block <NUM> and block <NUM> of the process <NUM> may additionally, or alternatively be implemented, in some examples, entirely separate and independent of block <NUM>, block <NUM>, and block <NUM> of the process <NUM>. In particular, in some examples, block <NUM> and block <NUM> of the process <NUM> may be implemented in an automated environment that never, or rarely, operates in a manual mode, and never or rarely transitions to or from a manual mode of entry. Put another way, the call status monitor <NUM> of <FIG>, <FIG>, <FIG>, and <FIG> may be a default mode of operation of the PSA device <NUM>, with a transition to the manual mode depicted in <FIG> occurring never, or rarely.

As should be apparent from this detailed description above, the operations and functions of electronic computing devices described herein are sufficiently complex as to require their implementation on a computer system, and cannot be performed, as a practical matter, in the human mind. Electronic computing devices such as set forth herein are understood as requiring and providing speed and accuracy and complexity management that are not obtainable by human mental steps, in addition to the inherently digital nature of such operations (e.g., a human mind cannot interface directly with RAM or other digital storage, cannot transmit or receive electronic messages, electronically encoded video, electronically encoded audio, etc., and cannot detect an overload condition, in which a number of calls at a PSAP device exceeds an ability of the human users to handle the calls, and/or change, via the PSAP device, a rendered characteristic of a bot-generated particular incident indicator to indicate that a human user should, and/or may need to, intervene, among other features and functions set forth herein).

The invention is defined solely by the appended claims including any amendments made during the pendency of this application.

Moreover, in this document, relational terms such as 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 "one of", without a more limiting modifier such as "only one of", and when applied herein to two or more subsequently defined options such as "one of A and B" should be construed to mean an existence of any one of the options in the list alone (e.g., A alone or B alone) or any combination of two or more of the options in the list (e.g., A and B together).

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.

The terms "coupled", "coupling" or "connected" as used herein can have several different meanings depending on the context in which these terms are used. For example, the terms coupled, coupling, or connected can have a mechanical or electrical connotation. For example, as used herein, the terms coupled, coupling, or connected can indicate that two elements or devices are directly connected to one another or connected to one another through intermediate elements or devices via an electrical element, electrical signal or a mechanical element depending on the particular context.

Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Any suitable computer-usable or computer readable medium may be utilized. 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. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

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. For example, computer program code for carrying out operations of various example embodiments may be written in an object oriented programming language such as Java, Smalltalk, C++, Python, or the like. However, the computer program code for carrying out operations of various example embodiments may also be written in conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on a computer, partly on the computer, as a stand-alone software package, partly on the computer and partly on a remote computer or server or entirely on the remote computer or server. In the latter scenario, the remote computer or server may be connected to the computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Claim 1:
A method (<NUM>) comprising:
operating (<NUM>) a public-safety answering point, PSAP, device (<NUM>) in a manual mode, in which calls are routed to human users for manual incident data entry;
detecting (<NUM>), at the PSAP device (<NUM>), an overload condition (<NUM>), in which a number of the calls (<NUM>) exceeds an ability of the human users to handle the calls (<NUM>);
in response to detecting the overload condition (<NUM>), transitioning (<NUM>) the PSAP device (<NUM>) from the manual mode to an automated review mode, in which: the calls (<NUM>) are routed to one or more bots (<NUM>) for automated incident data entry; and incident indicators, parsed from the calls (<NUM>) by the one or more bots (<NUM>), are rendered at a display screen (<NUM>) for review by a human user;
in response to detecting (<NUM>) that a bot-generated particular incident indicator (<NUM>) meets a low confidence condition (<NUM>), changing (<NUM>), via the PSAP device (<NUM>), a rendered characteristic of the bot-generated particular incident indicator (<NUM>) at the display screen (<NUM>) to indicate that the human user is to intervene; and
in conjunction with changing the bot-generated particular incident indicator, providing, at the display screen (<NUM>) one or more associated user-operable input mechanisms which, when actuated, causes information of an incident associated with the bot-generated particular incident indicator to be rendered at the display screen, or played from a speaker, for manual review by the human user.