Emergency call processing system, emergency call processing method, and program

Abstract

This invention provides an emergency call processing system, method, and program that can appropriately update the priority (rank, etc.) of emergency call records registered in the database, taking into account subsequent factors such as information obtained after reception, thereby enabling appropriate management of the priority of emergency calls. [Solution] Upon receiving an emergency call, the system obtains the content of the call and registers the corresponding call record in the database. At the time of receipt, a rank indicating priority (score and deadline as needed) is determined based on the content of the call and registered in the call record. After registration, an event update process is executed to identify the target call record when additional information such as location information, free-form text, or re-calls is obtained, recalculate the score based on the additional information, and update the rank. Furthermore, a periodic update process can be performed at predetermined intervals to calculate the remaining time and update the rank according to threshold conditions.

Description

[Technical Field]

[0001] The present invention relates to a technology for processing the content of emergency calls received, and more specifically, to an emergency call processing system, an emergency call processing method, and a program for causing a computer to execute the same, which register emergency call information as emergency call records in a database and manage the priority of said emergency call records. [Background technology]

[0002] In recent years, technologies have been proposed to receive emergency reports related to disasters, accidents, sudden illnesses, etc., and to prioritize responses based on the content of the reports and present them to the relevant parties (operators, response teams, etc.). For example, a configuration is known that organizes the content of the reports as predetermined information and registers it in a database, and then calculates and displays predetermined indicators (priority, etc.) for the report information registered in the database, thereby supporting decision-making regarding responses (see Patent Document 1).

[0003] However, in emergency calls, the situation is likely to change after the initial reception, and the content of the call may become more specific or change due to additional free-form descriptions, location information, or subsequent calls from the same caller. Furthermore, even with the same call content, the urgency may increase over time, and the priority of response may need to be re-evaluated. On the other hand, some conventional configurations handle call information based on the priority calculated at the time of database registration, and do not adequately consider the operation of dynamically updating the priority after registration. [Prior art documents] [Patent Documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2024-111634 [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] In the conventional technology described above (see, for example, Patent Document 1), after registering the notification information in the database, the priority calculated based on the information at the time of initial reception is used as is. As a result, there is a risk that information obtained after the initial reception (e.g., location information, free-form text, information based on subsequent notifications from the same sender, etc.) and changes in circumstances due to various subsequent factors that may occur after the registration of the notification information may not be reflected in the priority in a timely manner. This may lead to the priority becoming fixed in relation to the actual situation, resulting in delays in response and inefficient resource allocation.

[0006] The present invention has been made in view of the above circumstances, and aims to provide an emergency call processing system, an emergency call processing method, and a program that can appropriately update the priority (rank, etc.) of emergency call records registered in a database, taking into account subsequent factors such as information acquired after reception, and that can appropriately manage the priority of emergency calls. [Means for solving the problem]

[0007] To solve the above problems, an emergency call processing system according to one aspect of the present invention comprises a call receiving unit that receives an emergency call and acquires the content of the call, and a database that generates and stores a call record corresponding to the content of the call. The call record can hold at least a rank indicating the priority of the call. Furthermore, the system includes an initial priority determination unit that determines a rank based on the content of the call and registers it in the call record when the call is received for the first time.

[0008] The priority initial determination unit can generate information (or the text that forms the basis of such information, etc.) that is automatically structured into predetermined items by predetermined analysis processing or a trained model, based on the text of the speech recognition result for the call audio acquired as the content of the emergency call and / or the input information received by IVR.

[0009] The priority initial determination unit can then determine the rank using a trained model based on the structured information (or the text on which the information is based), and register the determined rank in the notification record. If necessary, information supplemented or modified by operator input may be included in the input. Furthermore, the notification content (information acquired at the time of initial notification reception) may include information obtained by automatically structuring input information (e.g., voice input or DTMF signal input, etc.) received by the Interactive Voice Response (IVR) through the analysis process or the trained model.

[0010] In a characteristic aspect of the present invention, after a notification record has been registered in the database, a priority update unit (event update function) is provided that, upon obtaining additional information regarding the emergency notification, identifies the target notification record corresponding to the additional information and updates the rank of the target notification record. This allows for the appropriate updating of the priority (rank, etc.) to reflect the information obtained after the initial reception, even if the content of the notification becomes more specific or changes after the initial reception.

[0011] Here, the additional information may include at least one of location information and free-form text, and even if location information cannot be obtained, free-form text may be obtained. In addition, the notification record may be assigned a notification ID to identify the notification record. The target notification record may be identified based on the notification ID obtained in association with the additional information, or on the identification information associated with the notification ID. Furthermore, the acquisition route for the additional information may include, for example, receiving location information or free-form text (or both) through an input form displayed on the caller's terminal based on link information sent to the caller's terminal when the notification is received. Furthermore, the acquired information (location information, free-form text, re-notification content, etc.) may be automatically structured by a trained model or a predetermined analysis process and then added to the database in association with the notification record. Location information (including estimated location and address information) provided by telecommunications carriers, etc. in connection with the emergency call may be acquired and associated with the notification record by a call session identifier, communication ID, notification ID, or caller information, etc. Furthermore, more accurate location information or location information after movement may be additionally acquired from an input form, etc.

[0012] Furthermore, consent information indicating whether or not consent has been given for the transmission of location information during a call session may be obtained. If consent has not been given, an input form may be provided that disables the function of acquiring or transmitting location information, and additional information such as free-form text may be accepted. By updating the event based on the additional information received through the input form, it will be possible to update the rank to reflect the information received even if consent for location information cannot be obtained.

[0013] In another aspect of the present invention, the notification record may hold a score, which is a numerical value separate from the rank, in addition to the rank. The score may be calculated based on the content of the notification at the time of initial reception and registered in the notification record, and may be recalculated based on additional information when the event is updated. Furthermore, the ranks may be divided into a first rank group that is subject to urgency assessment and a second rank group that is not subject to urgency assessment, and when calculating or recalculating the score, an urgency parameter based on information about remaining time may be taken into account only if the rank belongs to the first rank group, and the urgency parameter may not be taken into account if the rank belongs to the second rank group.

[0014] Furthermore, in one aspect of the present invention, the priority initial determination unit may set a deadline, which is the time limit, as information regarding the remaining time, in accordance with the determined rank and the information regarding the urgency of the emergency call, and register the said deadline in the call record.

[0015] Furthermore, in yet another aspect of the present invention, the notification record may hold a deadline, which is the due time, as information regarding the remaining time. The remaining time may be calculated based on the difference between the current time and the deadline. If the rank is updated to a higher rank in an event update, the deadline may be reset by adding a predetermined time corresponding to the updated rank to the current time at the time of the rank update. Moreover, even if the notification record does not hold a deadline, if the rank is updated to a rank where a deadline should be set due to a rank update based on additional information, a new deadline may be set.

[0016] In addition, in another aspect of the present invention, the priority update unit may further include a periodic update function that updates the ranks of a plurality of reported records registered in the database at a predetermined period after the reported record is registered in the database. In the periodic update, for the reported record that holds the deadline, the remaining time may be calculated based on the difference between the current time and the deadline, and when the remaining time falls below a predetermined threshold, the process of updating the rank to a higher rank may be included. Thereby, in addition to the event update based on the received information, the change in urgency associated with the passage of time can be reflected in the rank.

[0017] Furthermore, in another aspect of the present invention, the second and subsequent emergency reports from the same reporting terminal are incorporated as additional information, the database is searched based on the sender information included in the emergency report, the target reported record is identified, the content of the second and subsequent emergency reports is recorded as additional information of the target reported record, and event update may be executed based on the additional information.

[0018] Also, in one aspect of the present invention, it may further include a notification unit that transmits a message or makes an automatic voice call to the reporting terminal according to a change in the processing status or response status of the reported record. For example, when the phone number of the reporting terminal is a mobile phone number, a message may be sent, and when the message sending fails, an automatic voice call may be made. Furthermore, it may be configured to include a switching control unit that activates the connection from the in-house switch to the automatic voice response according to the operation of the staff based on predetermined conditions such as the line congestion status.

[0019] Furthermore, the present invention can also be understood as an emergency reporting processing method executed by a computer corresponding to each aspect as the above system. This method includes receiving an emergency report, registering information related to the emergency report in the database as a reported record, registering a rank in the reported record based on the reported content, after the reported record is registered in the database, identifying the target reported record契机として追加情報の取得を契機として対象通報レコードを特定し、当該対象通報レコードのランクを更新するイベント更新工程を含み得る.

[0020] Further, the present invention can also be provided as a program for causing a computer to execute emergency notification processing including the above event update.

Advantages of the Invention

[0021] According to the present invention, even after registering the notification information as a notification record in the database, the target notification record can be specified based on the acquisition of additional information regarding the emergency notification, and the rank of the target notification record can be updated. Therefore, it is possible to suppress the fixation of the priority based on the information at the first reception time, and to appropriately maintain and manage the priority (such as rank) for the emergency notification by reflecting the information obtained after the reception.

[0022] Also, according to one aspect of the present invention, since it is possible to incorporate location information and / or free description, notifications from the same sender terminal after the second time, etc. as additional information, even for an emergency notification where the situation is likely to be concretized and fluctuated after the first reception, the change in the notification content can be reflected in the priority update. In particular, by adopting a mode of acquiring additional information via an input form (link information) or a mode of specifying the target notification record by database search based on the sender information, it is possible to efficiently link the information collection after reception and the update of the notification record.

[0023] Furthermore, according to one aspect of the present invention, since the rank can be determined by a learned model with the notification content including free description as input at the time of initial registration and / or event update, even when the diversity of the notification content is high, it is possible to stably perform priority determination based on certain criteria.

[0024] Furthermore, according to one aspect of the present invention, since a score can be stored in addition to the rank in the notification record, even for multiple notification cases classified into the same rank, it is possible to identify cases with relatively higher priority within the same rank by sorting or prioritizing them based on the score. Moreover, since the score can be recalculated based on additional information, the numerical indicators that serve as the basis for updating priority (rank, etc.) can be updated at any time, contributing to improved accuracy of priority management. In addition, by adopting an approach that incorporates an urgency parameter based on remaining time into the score for rank groups subject to urgency assessment, it becomes possible to calculate priority that balances the seriousness of the situation and the time urgency.

[0025] In addition, according to one aspect of the present invention, a deadline can be set according to the rank, and a new deadline can be set or reset when updating to a higher rank in event updates, thus enabling consistent operation of priority updates and remaining time management. Furthermore, in an aspect that uses periodic updates that calculate the remaining time at predetermined intervals and update the rank according to threshold conditions, the increasing urgency due to the passage of time can be reflected in the priority even if no additional information is acquired.

[0026] Furthermore, in configurations that include a notification function that sends messages or makes automated voice calls in response to changes in processing or response status, and a function that switches from PBX to IVR based on predetermined conditions, it is possible to ensure a means of contacting the caller while supporting stable response even under operational constraints such as line congestion.

[0027] In particular, according to the present invention, not only can the priority of reported cases be updated to reflect additional information and the passage of time acquired after reception, but if a configuration is adopted in which location information is acquired as latitude and longitude, the location can be displayed on a map and understood, and furthermore, a list of reported cases can be sorted and presented based on the updated priority (rank / score), so that cases that should be addressed as a priority can be continuously and quickly identified.

[0028] As described above, the present invention enables the appropriate updating of the priority for emergency calls, reflecting subsequent factors such as information acquired after reception, thereby contributing to the acceleration and optimization of emergency call processing and the improvement of operational efficiency.

[0029] Furthermore, Patent Document 1 does not describe at all a specific configuration for identifying target notification records based on additional information obtained after the registration of notification records or the passage of time, and for updating the priority (rank, etc.) of said target notification records, as in the present invention. [Brief explanation of the drawing]

[0030] [Figure 1] This is a block diagram showing the overall configuration of an emergency call processing system according to one embodiment of the present invention. [Figure 2] This block diagram shows an example of the functional configuration of priority management in the priority initial determination unit and the priority update unit. [Figure 3] This figure shows an example of the data structure of notification records and additional information stored in the database. [Figure 4] This flowchart shows an example of the processing procedure from receiving a new emergency call to generating and storing the call record. [Figure 5] This flowchart shows an example of a processing procedure for updating the priority stored in the notification record in response to events such as the acquisition of additional information. [Figure 6] This flowchart shows an example of a processing procedure that updates the priority stored in the notification record through periodic processing performed at predetermined intervals. [Figure 7] This flowchart shows an example of the procedure for obtaining additional information via a link sent to the whistleblower. [Figure 8] This flowchart shows an example of the processing procedure using existing reporting records when a second report is made. [Figure 9] This flowchart shows an example of the processing procedure when sending notifications triggered by priority updates or similar events. [Figure 10] This flowchart shows an example of the processing procedure for calculating a score based on the reported information. [Modes for carrying out the invention]

[0031] Hereinafter, one embodiment of the present invention will be described in detail with reference to the drawings. Note that the following description is merely an example of how to embody the present invention, and the technical scope of the present invention is not limited to these embodiments.

[0032] <1. Overall System Configuration (Figure 1)> As shown in Figure 1, the emergency call processing system according to the present invention (hereinafter also referred to as "this system") comprises at least a caller terminal 20, a private branch exchange (PBX) 30, an interactive voice response (IVR) 31, an operator terminal 40, a switching control unit 57, a management server 50, and a database 55. Furthermore, this system may include a notification unit 56 (additional function), an external linkage system 58, etc. The database 55 may be built into the management server 50, or it may be provided separately so as to be able to communicate with the management server 50. The PBX, IVR, and management server are not limited to the same location and the same device, but may be distributed on any network, including the cloud.

[0033] The caller terminal 20 is a communication terminal such as a mobile phone, smartphone, or landline telephone, and is used to make emergency calls. Emergency calls from the caller terminal 20 are made, for example, by voice call, and at least caller information 59 (e.g., telephone number) may be transmitted when the call is initiated.

[0034] Emergency calls are received by the management server 50 via the exchange 30. The exchange 30 controls the connection of normal voice calls and may have a function to switch the connection with the automatic voice response device 31 as needed. For example, the exchange 30 may reflect a setting to direct the call to the IVR 31 based on instructions from the switching control unit 57. Note that the switching method for directing the call to the IVR 31 is not limited to switching by the private branch exchange 30, but may be implemented by other methods such as network control by the telecommunications carrier. The IVR 31 has functions such as automatic response, guidance playback, and input reception, and can be implemented in a known configuration. Input information received by the IVR 31 (e.g., voice input, DTMF signal input, etc.) may be used in cooperation with the management server 50 for call reception processing and may be taken up by the management server 50 as call content and / or additional information.

[0035] The switching control unit 57 is a control unit for executing route control to the exchange 30 (for example, PBX → IVR activation), and the operator terminal 40 is a terminal for staff to perform such switching operations. For example, the switching control unit 57 can cause the exchange 30 to change its settings to activate IVR 31 when predetermined conditions (such as line congestion) are met and a staff member performs a switching operation through the operator terminal 40. This allows the system to operate in a manner that combines normal voice call reception with automated responses. In other words, whether the call reception route is primarily voice call or primarily IVR, the management server 50 can centrally execute call reception processing and call record management.

[0036] The management server 50 is an information processing device that constitutes the core of this system, and internally houses various functional units such as a notification reception unit 51, a priority initial determination unit 53, and a priority update unit 54. The notification reception unit 51 receives emergency calls and manages call sessions, and also acquires caller information 59 obtained in conjunction with the notification from the caller terminal 20.

[0037] Furthermore, the notification reception unit 51 acquires the notification content. The notification content may include, for example, the speech recognition result (text) of the call audio or the input information received by the IVR 31 (voice input, DTMF signal input, etc.), which has been automatically structured into predetermined items by the AI ​​(or the text that forms the basis of such structuring). It may also include items that have been supplemented or modified by operator input as needed. Free-form text and location information obtained from input forms, etc., after the notification is received are treated as additional information, as described later, and can be stored in association with the notification case. Hereinafter, "notification content" refers to information that is automatically structured into predetermined items by the AI ​​based on the information acquired at the time of the initial emergency notification (for example, the speech recognition result of the call audio, the input information received by the IVR 31, etc.), and used to generate the notification record (or the text that forms the basis of such structuring), and "additional information" refers to information that can be automatically structured by the AI ​​and added to the notification record based on information acquired after the notification record has been registered in the database (for example, location information or free-form text accompanied by acquisition routes such as input forms, re-notifications, employee inputs, etc.). Furthermore, in the context of this invention, the content of subsequent emergency calls from the same caller's terminal may be treated as "additional information" to an existing call.

[0038] Database 55 is a storage device that stores information about reported cases as report records. The management server 50 stores, updates, and retrieves report records from database 55, and continuously manages the status of reported cases.

[0039] In particular, since the sender information 59 can be used as a search key for cases, as shown in Figure 1, the sender information 59 is not only entered into the management server 50, but can also be used to search the database 55 (for example, identifying existing cases when a re-notification is made).

[0040] The priority initial determination unit 53 initially determines the priority of the reported case based on the content of the report at the time of receipt. Here, "priority" includes at least a rank as a tier value. Furthermore, in the best mode of this embodiment, in addition to the rank, a score, which is a numerical indicator, is also calculated, and both the rank and score are managed as a report record. In addition to the trained model 531 that determines the rank, the priority initial determination unit 53 also includes (optionally) a score calculation unit 532 and a deadline setting unit 533, and can set a deadline according to the rank and / or time urgency information and register it in the report record.

[0041] On the other hand, as a variation, priority may be represented only by rank, omitting the score. In other words, rank is the basic representation of priority, and score can be added as a supplementary numerical representation.

[0042] The priority update unit 54 is a functional unit that updates the priority of a report case after the report record has been registered in the database 55. The priority update unit 54 includes an event update function 541 that updates the priority when additional information is acquired. In addition, it may include a periodic update function 542 as an additional function that updates the priority of multiple records (for example, report records with deadlines set) at predetermined intervals. In the following description, as an example, a configuration in which periodic updates are used in combination with event updates will also be described.

[0043] The event update function 541 incorporates additional information such as location information, free-text descriptions, and repeat notifications from the same sender's terminal obtained from input forms, etc., identifies the target notification record, and performs update processing. The periodic update function 542 can reflect the increasing urgency due to the passage of time in the priority, based on the deadline and remaining time described later. In addition to updating the rank, the priority update unit 54 recalculates and updates the score in best mode, and resets the deadline according to the updated rank as needed.

[0044] The notification unit 56 is a functional unit that, as an additional function, notifies the caller terminal 20, etc., in response to triggers such as changes in the processing status or response status of a reported case, changes in priority, or the arrival of a deadline. Notifications can be made, for example, by sending a message (SMS, etc.) or by making an automated voice call (return call). The external linkage system 58 is an information system separate from this system 10 (for example, a command / reception system in various organizations such as fire departments, police, and local governments), and may be connected to send and receive predetermined information (shared information based on public access classification, etc.) related to the reported case as needed. Note that the external linkage system 58 may also include existing systems within the same organization, as long as they are configured separately from this system 10.

[0045] With the above configuration, this system can handle everything from receiving reports to determining initial priorities, storing report records, updating priorities to reflect additional information and the passage of time acquired after reception, and providing notifications and external integration as needed.

[0046] <2. Rank Determination (Figure 2) and Rank System (Examples A-E)> The trained model 531 is an example for estimating priority from the content of the notification, and can be implemented using any training model or analysis model (including analysis processing) that a person skilled in the art would deem appropriate. As shown in Figure 2, the priority initial determination unit 53 receives the content of the notification obtained at the time of notification reception as input and determines the rank using the trained model 531.

[0047] The trained model 531 considers the words and context included in the report, the progression and danger of the situation, and expressions indicating the possibility of human harm, and outputs a rank that should be assigned to the reported case. The trained model 531 can be configured as, for example, a classifier or a language model, and the specific type of model is not limited, but they all have in common that they take the report content as input and perform an inference process to obtain a rank as output.

[0048] Here, specific examples of input information to the trained model 531 include: (i) the text of the speech recognition result for the call audio; (ii) choices, numbers, and phrases obtained through IVR input (voice input or DTMF input); (iii) items structured by operator input; (iv) free-form text obtained after receiving the call; (v) location information (latitude and longitude, address, landmarks, etc.); and (vi) other supplementary information such as the time of the call and the originating region. These may be used individually or combined and structured as a single input.

[0049] In initial priority determination (Figure 4), the trained model 531 can determine the rank based on the content of the report obtained at least at the time of report reception, whereas in event updates (Figure 5), the trained model 531 may re-evaluate the rank using the latest information, including additional information, as input.

[0050] The trained model 531 can be generated, for example, by training it with historical data of past emergency call cases as training data. The training data may consist of a set of training samples that include at least (a) the content of the call (or features extracted and structured from the content of the call) and (b) the correct label (rank) associated with the call case.

[0051] One example of a method for assigning the aforementioned correct label (rank) is to assign one of the ranks A to E (or A to D, etc.) based on the priority ultimately determined by the operator or dispatcher for the reported incident, or the results of the response to the reported incident (e.g., whether a dispatch decision was necessary, the time until the response began, the severity determined afterward, etc.). For example, one could adopt criteria such as assigning rank A to incidents where there is an imminent threat to life and immediate response is required, rank B to incidents where a response is strongly required within a certain time, rank C to incidents of moderate urgency requiring response, rank D to incidents of relatively low urgency, and rank E to incidents that should be put on hold due to false alarms or insufficient information.

[0052] In addition to the above (i) to (vi), examples of input information (explanatory variables) for training data may include the presence or absence of dangerous vocabulary extracted from the report text (including speech recognition results and free-text descriptions), the presence or absence of negative expressions, expressions indicating the number of people, whether or not there were injuries, the severity of the injuries, and whether or not there were people requiring special consideration, as well as expressions indicating the type and location of the accident and the urgency of the situation. These can be expressed as numerical features, categorical features, and / or textual features.

[0053] An example of the training procedure for the trained model 531 is as follows: (1) the training data is divided into training data, validation data, and evaluation data; (2) the notification content text is converted into a predetermined representation (e.g., n-gram, word embedding, document embedding, etc.), and structured items are converted into a predetermined format (e.g., one-hot coding, normalization, etc.) to generate input features; (3) the model is trained as a multi-class classifier; (4) hyperparameters are adjusted based on evaluation metrics for the validation data (e.g., precision, recall, F-score, confusion matrix, or missed rate of a predetermined rank (e.g., rank A or B, etc.)); and (5) the model that satisfies the predetermined performance on the evaluation data is confirmed as the trained model.

[0054] Specific examples of the pre-trained model 531 include any classification model such as logistic regression, support vector machine, random forest, gradient boosting decision tree, and neural networks (RNN, CNN, Transformer, etc.). In any case, the system can receive the input features as input, calculate a score (probability or likelihood, etc.) corresponding to each rank as output, and perform an inference process that outputs a rank based on that score.

[0055] Furthermore, the method for determining the inference result (rank) of the trained model 531 is not limited to outputting the rank of the highest score. A threshold judgment for predetermined ranks may also be employed (for example, assigning rank A if the score corresponding to rank A is equal to or greater than a predetermined threshold, and selecting the highest score from other ranks if it is not). This allows for adjustments to be made according to operational requirements, such as suppressing the oversight of predetermined ranks (rank A, etc.).

[0056] Furthermore, the trained model 531 may be retrained and updated at predetermined intervals (e.g., daily, weekly, monthly, etc.) or when a predetermined number of reports have been accumulated, using new report case data accumulated during operation (e.g., rank corrected by the operator, severity determined afterward, whether or not a report has been resubmitted, etc.). When updating, the model may be version-controlled (version assigned), and if the evaluation indicator does not meet predetermined criteria, it may be configured to revert to the previous version.

[0057] Furthermore, the priority initial determination unit 53 may, instead of using the trained model 531, calculate a score based on a scoring rule and weighting for predetermined items or features extracted from the notification content as a predetermined analysis process, and determine the rank by fitting the score to a predetermined threshold or interval. Alternatively, even when using the trained model 531, if the confidence level of the model is below a predetermined threshold, or if there is insufficient input information, the system may switch to the results obtained from the aforementioned analysis process, or integrate the results of both to determine the final rank.

[0058] Furthermore, the features provided to the trained model 531 (input features) may include predetermined features extracted from the content of the report (for example, the speech recognition result text of the call audio, information based on IVR input, and items supplemented or modified by operator input as needed). Examples of feature extraction may include the results of matching with a dictionary or rule related to words indicating danger or urgency (e.g., a dangerous word dictionary), the presence or absence of negative expressions ("not," "not doing," etc.), expressions related to the number of people, whether or not there are injuries, severity, age group, etc., expressions related to the type of location, and expressions related to temporal urgency ("right now," "from ~ minutes ago," "within ~ hours," etc.).

[0059] The features described above can be expressed as numerical features, categorical features, and / or text features. For example, the text of the report may be converted into representations such as n-grams, word embeddings, or document embeddings, or it may be structured as slots corresponding to predetermined items such as accident type, number of injured, risk factors, location, and time urgency. By using these input features, the trained model 531 can stably perform inference based on predetermined criteria, even when there is a high diversity in the content of the report.

[0060] To clarify the entity that determines priority in this embodiment, it is defined as follows: The trained model 531 receives the notification content as input and outputs a rank (level value) to be assigned to the notification case. On the other hand, the score calculation unit 532 calculates a score, which is a numerical index representing priority, based on predetermined parameters extracted from the notification content, etc. The calculation of the score is optional, and depending on the operational settings, a configuration can be adopted in which priority is managed only by rank and score calculation is omitted.

[0061] A rank is a discrete value that expresses priority in stages, and can be represented in five stages, for example, A to E. An example of a rank is shown below, but this is just one example adopted by the operating entity, and the number of stages and names may be changed. Importantly, ranks are hierarchical values, with higher ranks indicating higher priority.

[0062] <Table 1: Examples of Ranks> A: Top priority (e.g., life-threatening situations, extremely urgent) B: Priority (Urgent and requires immediate attention within a certain timeframe) C: Caution advised (not necessarily an immediate life-threatening situation, but action is recommended) D: Requires observation (Not urgent, but action will be considered depending on the situation) E: Other (may include false reports or cases that are not deemed urgent)

[0063] In this embodiment, the trained model 531 determines which of the above ranks it belongs to based on the content of the report at the time of receipt. Here, the rank functions as basic information for broadly classifying how to handle the reported case. For example, a case classified as "A" may be treated as a case requiring immediate attention, and a case classified as "B" may be treated as a case requiring response within a certain time. Note that the rank may be updated due to changes in the content of the report or the passage of time, so the initial determination result is not a fixed value and can be re-evaluated by the priority update unit 54 described later.

[0064] As shown in Figure 2, the priority initial determination unit 53 determines a rank based on the notification content input by the trained model 531, and then the deadline setting unit 533 can set a deadline (deadline time) according to that rank. The deadline setting may be performed in such a way that the remaining time calculated as the difference between the deadline time (deadline) and the current time can be handled consistently in subsequent priority updates and monitoring processes. Here, the classification (notation) is a display format that fits the calculated remaining time into a predetermined range. Specifically, if the trained model 531 outputs rank A, the case is considered to require immediate attention, and "0.5h (30 minutes or less)" is uniquely applied as the classification (notation) for the remaining time, and the deadline time corresponding to 30 minutes or less based on the notification reception time (t0) is set.

[0065] On the other hand, if the trained model 531 outputs rank B, it is determined that the case does not necessarily indicate an immediate life-threatening situation, but requires immediate action within a certain timeframe. Based on the hearing information (questions and answers) acquired during the call, the initial priority determination unit 53 selects one of the following as the remaining time category (indication): "1h," "2h," or "3h," and sets the deadline corresponding to the selected category.

[0066] The information gathered here includes questions and answers regarding the urgency of the situation that can be used to set deadlines, which are obtained by the call reception unit 51 (or operator) during the call. Typically, these can be condensed into questions such as "When did the symptoms (event) begin?", "Is the current condition worsening?", "In what timeframe could the danger become apparent?", and "What disadvantages can be expected if rescue is delayed?". Examples of questions include "When did you start having difficulty breathing?", "Has your level of consciousness changed?", "Is the water level rising, and how fast?", "In how many minutes (hours) will it become difficult to evacuate?", and "How much time do you think there is before the fire spreads?".

[0067] Furthermore, as an example of a conversation, if the caller states, "My chest hurts, but it's calming down a bit. It might get worse within an hour," then the remaining time category (notation) can be set as "1h (more than 30 minutes to less than 1 hour)" to establish a deadline.

[0068] On the other hand, if the caller states, "It's flooded, but I'm holding on to the first floor for now. It might reach the floor in about two hours," then "2h (more than one hour but less than or equal to two hours)" can be selected. Furthermore, if they state, "The water level has already risen, and I won't be able to evacuate within 30 minutes," then the time urgency is extremely high, and the rank can be updated to rank A through a re-evaluation by the priority initial determination unit 53 (or priority update unit 54). In this case, 0.5h is applied as the remaining time category (notation) corresponding to rank A, and a deadline can be set. This allows the rank to be maintained as a discrete classification by the trained model 531, while for cases classified as rank B, the deadline can be set in stages within the range of 1h / 2h / 3h based on the hearing information, and in cases of extremely high time urgency, a re-evaluation to rank A and the application of 0.5h become possible. This enables operation consistent with the remaining time monitoring and update decisions in the subsequent priority update unit 54.

[0069] Furthermore, if the rank is updated during the priority update process described later, the priority update unit 54 may reset the deadline (remaining time category (notation)) according to the updated rank. For example, if the rank rises from B to A due to the update, the 0.5h category is applied based on the current time at that point, and the deadline is reset. Similarly, if the rank rises from C to B, one of 1h / 2h / 3h is selected and reset based on the hearing information, etc. The selection of the remaining time category (notation) is not limited to operator input, but may also be automatically determined by a trained model, etc., based on the analysis results of the hearing information.

[0070] <3. Score positioning and calculation method (Figure 2)> Next, let's discuss scores. Scores are a different concept from ranks; while ranks are discrete categories, scores represent priority as numerical values. Therefore, scores allow for ordering within the same rank and can serve as an operational auxiliary indicator as an evaluation value that takes multiple factors into account.

[0071] In this embodiment, as the best mode, the priority initial determination unit 53 calculates a score in addition to determining the rank, and stores both the rank and the score in the notification record. The score can be used for ordering within the same rank, and depending on the embodiment, it may also be used as an aid in rank determination, such as correcting the rank as needed based on the calculated score (however, priority is represented at least as a rank).

[0072] As shown in Figure 2, the priority initial determination unit 53 may include a score calculation unit 532. The score calculation unit 532 extracts predetermined parameters from the report content and calculates a score based on the extracted parameters. Here, parameters may include, for example, the number of injured persons, the number of seriously injured persons, the presence and number of persons requiring special consideration, the degree of hazard factors (fire, flood, collapse, etc.), the number of times the report was repeated, and words indicating changes in the situation at the scene. The score can be calculated by adding or subtracting points from these parameters by setting coefficients (weights) and upper limits, and then summing them up.

[0073] One example of a scoring system is to add points representing the scale of human casualties, the severity of injuries, and the presence of vulnerable individuals. For example, if the number of injured is extracted, points are added based on "number of injured × predetermined coefficient," and if the number of seriously injured is extracted, points are added using a larger coefficient than that for the number of injured. Similarly, points are added for vulnerable individuals using a predetermined coefficient.

[0074] Furthermore, by adding points according to the degree of risk factors (low, medium, high, etc.), the type of accident and environmental hazard can be reflected. In addition, by adopting a system that deducts points according to the uncertainty of the report (insufficient information, etc.), it is possible to suppress overestimation of cases with ambiguous information. These coefficients, upper limits, and stage thresholds are examples and will be designed appropriately according to operational policies and statistical validity.

[0075] Another example involves assigning a base score that maps the rank to a numerical value (for example, A being the highest and E being the lowest), and then adding points based on historical information such as the number of reports. Thus, scores can be used to assist in determining the rank, but they differ fundamentally in that the rank itself is a discrete classification, while the score is a numerical evaluation that quantitatively reflects multiple factors.

[0076] Furthermore, in this embodiment, an element based on "remaining time" (urgency) can be incorporated into the score calculation. In this case, the time urgency can be reflected numerically by using a function (e.g., stepped scoring, linear scoring, coefficient multiplication, etc.) that increases the score as the remaining time decreases. However, it is important to distinguish between the calculation itself (difference) and the classification for display and judgment (notation) when explaining how to handle remaining time, so the definition of remaining time will be described next.

[0077] In this embodiment, the application of the urgency assessment (correction based on remaining time) may be switched depending on the rank group. Specifically, for the first rank group, which includes ranks A and B, an urgency parameter based on remaining time (or deadline) may be added to the score, while for the second rank group, which includes ranks C, D, and E, the urgency parameter may not be added. This allows the time urgency to be reflected in the score only for cases subject to severity assessment, enabling appropriate operational prioritization. The composition of the first and second rank groups (which ranks are included) can be changed as appropriate according to the operational policy.

[0078] <4. Deadline and Remaining Time (Latest Definitions for Calculation and Classification)> In this embodiment, a deadline can be associated with a reported case. A deadline can be set for cases that need to be addressed within a certain time (e.g., rank A or B), and by managing the remaining time until the deadline, the urgency associated with the passage of time can be reflected in priority updates, etc. In this specification, "information regarding remaining time" may include at least a deadline as the due date, and may include the remaining time R calculated from the deadline as necessary. now This may include the classification (notation) thereof.

[0079] D is the deadline, and t is the current time. now , remaining time R now Therefore, the remaining time is calculated using R now =Dt now This is done by the difference between the current time and the deadline. In other words, the remaining time is the "difference between the current time and the deadline," and the direction of the sign is consistent by subtracting the current time from the deadline. As an initial setting, if the time of notification receipt is t0 and the initial remaining time is R0, the deadline can be set as D = t0 + R0.

[0080] On the other hand, in this embodiment, the calculated remaining time R now(Continuous values) can be converted into categories (notations) suitable for display and determination. The definitions of the categories (notations) are as follows. That is, 0.5h means "30 minutes or less", 1h means "more than 30 minutes to 1 hour or less", 2h means "more than 1 hour to 2 hours or less", 3h means "more than 2 hours", and it is a category without an upper limit representing the remaining time over 2 hours. Here, the boundary conditions are that exactly 30 minutes is included in 0.5h, exactly 1 hour is included in 1h, and exactly 2 hours is included in 2h. The category (notation) can be used not only as a display format but also for determining whether an update is required (threshold determination or category change determination). Note that "0.5h", "2h", and "3h" in this specification are "names of display categories" and do not respectively mean exactly 0.5 hours, 2 hours, and 3 hours. However, in the deadline setting, a predetermined time (operation setting value) associated with each category is used.

[0081] As a specific example, when the reporting reception time t0 = 10:00 and it is determined to be rank B and the initial remaining time R0 = 2 hours is set, the deadline D is 12:00. At this time, at 11:05, since R now = 12:00 - 11:05 = 55 minutes, the category (notation) is "1h", and for example, the rank can remain B. On the other hand, at 11:35, since R now = 12:00 - 11:35 = 25 minutes, the category (notation) becomes "0.5h", and if certain conditions are met, the rank can be updated from B to A (for example, based on the fact that the category (notation) has become "0.5h" or the remaining time R now has become 30 minutes or less). This update may be performed by threshold determination in the periodic update process described later, or by event update processing triggered by the acquisition of additional information. In the periodic update, for each extracted reporting record, the current time t now is used to calculate R now and based on the result, it is determined whether an update is required.

[0082] <5. Database Configuration and Reporting Record (Figure 3)> As shown in Figure 3, the database 55 may include a report case table (report record) 551, an additional information table 552, and an extension table group 553. The report case table 551 stores a report ID that uniquely identifies the report case, rank, caller information (telephone number, etc.), consent information (with / without consent), etc. The consent information may be linked to the report case.

[0083] Furthermore, in the best mode, the report table 551 can store a score. If a configuration is adopted that sets a deadline, the report table 551 can store the deadline (due time). Here, in the modified version where only rank is used as priority, the score column may be omitted or treated as blank.

[0084] The additional information table 552 is associated with each record (report ID) in the report case table 551 in a one-to-many relationship, allowing it to hold multiple additional information records in chronological order. The additional information table 552 stores additional information such as location information and free-form text, using the report ID as a foreign key. The additional information table 552 can also store the "acquisition date and time" and "acquisition route" of the additional information. This allows for clear distinction and management in the database between the report content acquired at the time of initial reception (information acquired by the report reception unit 51 and used to generate the report record) and the additional information acquired after registration (information stored along with the acquisition date and time and acquisition route).

[0085] This allows for the chronological management of multiple pieces of additional information acquired after receiving a report for the same incident, and the priority update unit 54 can refer to the content and acquisition order of the additional information when updating the event. Acquisition routes may include, for example, input forms, re-reports, and staff input, and by combining this with consent information, it is possible to control whether location information can be acquired and the branching of the displayed screen.

[0086] The extended table group 553 is a set of tables provided as an extension example independent of the basic configuration, and can store, for example, disclosure classification, cause classification, resource management information, etc. The disclosure classification can be used to control the scope of sharing to the external linkage system 58. In addition, an event identifier (event ID, integrated ID, etc.) may be stored in the report record or the extended table group 553 to determine whether the reported cases relate to the same event (same incident, same location, etc.) and to associate multiple report records that are determined to be the same as the same event. The assignment or association of the event identifier may be performed, for example, based on location information, report content, transmission time (time window), transmission area, operator designation, etc.

[0087] Furthermore, if a configuration is adopted in which resource management information is stored in the extended table group 553, the management server 50 (or operator terminal 40) may be equipped with a function to extract and display applicable report cases by referring to the resource management information and the report record.

[0088] For example, resource management information may include the operational status of vehicles or personnel (on call / on standby, etc.), the presence or absence of equipment, and the assigned area. The function for extracting respondable cases extracts reported cases for which resources matching these conditions exist, and can filter and display them in the report list display function. Furthermore, by sorting and presenting the extraction results based on the aforementioned rank or score, it is possible to quickly identify reported cases that should be prioritized for response using available resources.

[0089] Furthermore, the criteria for extracting cases that can be handled (e.g., area matching, presence or absence of necessary equipment, distance threshold, etc.) can be changed through operational settings, and the map display function may overlay the locations of available resources with the locations of reported cases.

[0090] Resource management information can be used to manage resource status, such as vehicles and personnel. When combined with map displays and priority displays, operators can gain a comprehensive understanding of the location and priority of a case, as well as the status of available resources, making it easier to make appropriate decisions. Even if these display functions (map displays, priority displays, etc.) do not directly contribute to the core functions of case management, they can support rapid decision-making in operation, ultimately contributing to reducing response delays and optimizing resource allocation.

[0091] As described above, in this embodiment, the rank is determined by the learned model 531 at the time of notification reception, a score can be calculated as the best mode, and the management of the deadline and remaining time can be combined. The notification record is stored in the database 55 and can be updated by the priority update unit 54 according to additional information acquired after reception and the passage of time. This enables priority management that reflects changes in the situation, without being fixed to the priority at the time of notification reception.

[0092] The management server 50 (or operator terminal 40) may be equipped with a notification list display function that displays a list of multiple notification records registered in the database 55. The notification list display function may, for example, sort and display notification records in descending order of rank (e.g., A→B→C→D→E), and within the same rank, sort and display them in descending order of score.

[0093] Furthermore, if the rank or score of a report record is updated by event update processing (Figure 5) or periodic update processing (Figure 6), the report list display function may update the display order based on the update result, and reposition the report cases with increased priority to the top of the list. This allows operators to continuously grasp the priority of report cases, which changes over time or as additional information is acquired, through the list display. If multiple report records are associated with the same event identifier, the report list display function may use the highest rank (and / or highest score) among the group of report records belonging to that event identifier as the priority of the event, and display them in a list on an event-by-event basis, or determine the display order of the events. This allows events whose high priority is determined by subsequent reports to be displayed higher in the list, even if there are previously registered low-priority reports.

[0094] Furthermore, the sorting keys in the list display are not limited to rank and score; they may also be set in combination with deadline or remaining time, number of resubmissions, publication category, etc. For example, the system may be configured to redraw the list of reports and automatically update the display order upon completion of event update processing or periodic update processing.

[0095] <6. Report reception processing and initial priority determination processing (Figure 4)> Referring to Figure 4, the notification reception process and initial priority determination process (including the generation and storage of notification records) in this system will be explained. Figure 4 shows an example of a series of processes performed collaboratively by the caller terminal 20, the management server 50 (notification reception unit 51, initial priority determination unit 53, etc.), and the database 55.

[0096] First, an emergency call is transmitted from the caller terminal 20 (S401). The emergency call is received by the management server 50 via the exchange 30, etc., and the management server 50 starts processing the call. Specifically, the call receiving unit 51 receives the incoming call and performs session management such as establishing and maintaining the call session (S402).

[0097] Next, the call receiving unit 51 acquires caller information 59 (e.g., telephone number, etc.) that may be sent along with the call (S403). Subsequently, the call receiving unit 51 acquires the content of the call (S404). The content of the call may include, for example, the speech recognition result (text) of the call audio, or information (or the text, etc. that forms the basis of such structuring) that has been automatically structured into predetermined items by AI based on input information received by the IVR 31 (voice input, DTMF signal input, etc.). It may also include items that have been supplemented or modified by operator input as necessary. Free text and location information acquired from the input form described later may be acquired as additional information and stored in association with the call case.

[0098] Next, the priority initial determination unit 53 takes the acquired notification content as input and determines the rank (priority level value) to be assigned to the notification case using the trained model 531 (S405). Here, the rank is given as a level value from A to E, for example, and becomes basic information that determines how the notification case will be handled in subsequent processing.

[0099] Next, the priority initial determination unit 53 determines whether or not to calculate a score (S406). This determination of whether or not to calculate a score may be made based on, for example, the operational settings (rank-only operation / score-based operation, etc.). In best mode, a configuration in which a score is calculated can be adopted in principle, and the priority initial determination unit 53 may calculate a score using the score calculation unit 532 based on predetermined parameters (at least some of them) extracted from the report content (S407).

[0100] On the other hand, as an alternative, if the operational policy is to manage priority solely by rank, it may be determined that score calculation is not necessary, and the score calculation process (S407) may be omitted. Thus, score calculation is not necessarily required and can be flexibly selected depending on the embodiment and operational conditions. In either case (whether S407 is executed or omitted), the process may proceed to the subsequent deadline setting process (S408) (see Figure 4).

[0101] Next, the priority initial determination unit 53 sets a deadline (due time) using the deadline setting unit 533 as necessary (S408). Whether or not a deadline needs to be set can be determined at least based on the rank of the reported case. If no deadline is set, this process (S408) can be omitted and the process can proceed to generating the report record (S409).

[0102] For example, if the trained model 531 determines the rank to be A, 0.5h is uniquely applied as the remaining time category (notation), and a deadline (D=t0+T0.5h (e.g., 30 minutes)) is set based on the time the notification was received (t0).

[0103] Furthermore, if the case is determined to be rank B, the call reception unit 51 (or operator) will select one of the following remaining time categories (indicated): 1h, 2h, or 3h, based on the hearing information (questions and answers) obtained during the call, and set a deadline according to the selected category.

[0104] On the other hand, for cases of rank C or lower, a configuration may be adopted in which no deadline is set at the initial acceptance stage, in which case the deadline setting process (S408) may be omitted. Even if a configuration is adopted in which no deadline is set at the initial acceptance stage, if the rank is updated to a higher rank by the priority update process described later, the priority update unit 54 may set a new deadline according to the updated rank.

[0105] Next, the management server 50 generates a notification record based on the information obtained through the above process (S409). The generated notification record may include at least a notification ID, rank, and caller information 59, and in best mode may further include a score (optional) and a deadline (optional).

[0106] Next, the management server 50 stores the generated notification record in the database 55 (S410). This allows the notification case to be uniquely identified and managed in the database 55, and thereafter it can be used for additional information acquired after reception and priority update processing triggered by the passage of time (see Figures 5 and 6). Finally, once the storage of the notification record is complete, the notification reception process is terminated as reception complete (S411).

[0107] <7. Event update processing flow (Figure 5)> Next, referring to Figure 5, we will explain the event update process that updates the priority of a reported case based on additional information obtained after reception. Figure 5 shows an example of the processing flow executed by the priority update unit 54 (particularly the event update function 541) of the management server 50.

[0108] First, the event update process is initiated when additional information (information after the reporting record is registered) related to the reported case is obtained (S501). Triggers for obtaining additional information may include, for example, information submission from an input form, a re-report from the whistleblower terminal 20, or additional input by an employee.

[0109] Next, the priority update unit 54 identifies the target notification record based on the acquired additional information (S502). This identification may be performed using, for example, the notification ID (or identification information associated with the notification ID), the caller information 59, or a combination thereof. If the target notification record cannot be identified, the additional information may be treated as a new notification, and the process may proceed to the new notification acceptance process shown in Figure 4.

[0110] Once the target notification record is identified, the priority update unit 54 retrieves the target notification record from the database 55 (S503). This retrieval may include notification record information, including at least the current rank (and score, deadline, etc., if necessary).

[0111] Next, the priority update unit 54 determines whether or not to recalculate the score (S504). Whether or not this recalculation is necessary can be switched by the operational settings.

[0112] If the score is to be recalculated (S504: Yes), the priority update unit 54 recalculates the score based on the latest information, including the report content (information obtained at the time of initial reception) and additional information (S505). On the other hand, in modified versions that do not use a score, S504 and S505 may be omitted.

[0113] Next, the priority update unit 54 determines whether or not it is necessary to update the rank based on the content of the additional information and the score recalculated as needed (S506).

[0114] If it is determined that a rank update is not necessary (S506: No), the rank will remain unchanged. Even in this case, if the score is recalculated, only the score may be updated.

[0115] On the other hand, if it is determined that a rank update is necessary (S506: Yes), the priority update unit 54 determines the updated rank (this may be included in the update decision within S506). The determination of the updated rank may be performed by re-evaluation using the trained model 531, or by a combination of the score and predetermined rules.

[0116] Next, the priority update unit 54 performs deadline processing as needed (S507). For example, if the updated rank is A, a configuration can be adopted in which the remaining time is reset by applying 0.5h (30 minutes or less) as the remaining time category (notation) based on the current time at that point.

[0117] Furthermore, if the updated rank is B and the notification record does not have a deadline, one of the remaining time categories (notation) of 1h, 2h, or 3h (for example, selected based on operational settings or acquired information) may be applied, and a new deadline may be set. If the updated rank is a rank that does not require a deadline setting, processing S507 may be omitted.

[0118] Subsequently, the priority update unit 54 updates and stores the notification record in the database 55, including the updated rank, the updated score (in best mode), and, if necessary, the updated deadline (S508).

[0119] Furthermore, in this embodiment, the updated notification record (or the update result) may be distributed to the operator terminal 40, etc., and used for updating the display order of the notification list display, displaying warnings, etc. (S509).

[0120] Through the above processing, additional information acquired after reception is reflected in the priority (rank and score) and deadline of the reported case. This allows the system to achieve dynamic priority management that reflects changes in the situation, rather than being fixed to the priority at the time of initial reception. The additional information acquired in the input form processing and re-reporting processing shown in Figures 7 and 8 can all be processed by referring to this event update processing flow (Figure 5).

[0121] <8. Periodic Update Processing Flow (Figure 6)> Next, with reference to Figure 6, the periodic update process, which is executed at predetermined intervals, will be described. Figure 6 shows an example of the processing flow executed by the priority update unit 54 (particularly the periodic update function 542) of the management server 50. The periodic update process may be executed to reflect the increasing urgency over time in the priority, even if no additional information is acquired after reception.

[0122] The periodic update process is initiated, for example, at predetermined intervals (every few minutes, every few tens of minutes, etc.) (S601). The trigger for initiation can be implemented by a timer interrupt, etc., and the interval is set appropriately according to the operational policy.

[0123] First, the priority update unit 54 extracts from the notification records stored in the database 55 multiple notification records that have deadlines set, which are subject to periodic updates (S602). Here, notification records with deadlines set are, for example, notification records in which the deadline field is not blank (a valid value is stored).

[0124] Next, the priority update unit 54 selects one record to be processed from the extracted target notification records (S603).

[0125] Next, (optionally), the priority update unit 54 may recalculate the score based on the latest information, including the remaining time (S603a). This recalculation can be omitted depending on the operational settings.

[0126] Next, the priority update unit 54 calculates the remaining time R based on the difference between the deadline D set in the notification record and the current time two. now Calculate (S604). Remaining time R now This is calculated from the deadline D to the current time t. now By subtracting, for example, R now =Dt now It is calculated by [this method].

[0127] Next, the priority update unit 54 calculates the remaining time R now Determine whether the (or category (notation)) satisfies the predetermined conditions (S605). The predetermined conditions are, for example, that the remaining time falls below a predetermined threshold, or that the category (notation) of the remaining time transitions to a predetermined category. For example, for a notification record of rank B, the calculated remaining time R now The predetermined condition is that the duration is 30 minutes or less (or the category (notation) becomes "0.5h"), and the system may be configured to update the rank from B to A when the predetermined condition is met.

[0128] If it is determined that the predetermined conditions are met (S605: Yes), the priority update unit 54 updates the rank of the notification record to a higher rank (S606). On the other hand, if it is determined that the predetermined conditions are not met (S605: No), the rank may not be updated, and the processing target may be moved to the next notification record.

[0129] If the rank is updated to a higher rank, the priority update unit 54 may perform deadline processing as necessary (S607). For example, if the rank is updated from B to A, a configuration can be adopted in which the deadline is reset by applying a 0.5h (30 minutes or less) category based on the current time at that time. If the updated rank is a rank that does not require deadline setting, S607 may be omitted.

[0130] Subsequently, the priority update unit 54 updates and stores the notification record in the database 55, including the updated rank, the updated score (in best mode), and, if necessary, the updated deadline (S608).

[0131] The above process can be repeated for multiple target notification records.

[0132] As described above, the periodic update process allows the system to grasp the urgency of a request based on the remaining time (or category / notation) even if no additional information is obtained after it has been received, and to update the rank and deadline as needed. This enables the system to achieve continuous priority management that takes into account changes in circumstances and time constraints.

[0133] <9. Input Form Processing (Figure 7)> Next, referring to Figure 7, we will explain the input form processing using the input form displayed on the caller terminal 20 after the call is received. Figure 7 shows an example of input form processing performed collaboratively by the caller terminal 20, the management server 50, and the database 55.

[0134] First, after the notification is received, the notification reception unit 51 (including the link transmission unit) sends link information (e.g., a URL) to the caller terminal 20, which will take it to an input form for entering additional information (S701). The caller terminal 20 receives the link information and accesses the link (S702).

[0135] The management server 50 detects access to a link (S703) and obtains a notification ID (or identification information associated with the notification ID) based on the link parameters contained in the link information (S704). The link parameters may include difficult-to-guess tokens, one-time values, expiration date information, etc., and can be used for access authentication (prevention of impersonation).

[0136] Next, the management server 50 checks the consent information indicating whether or not consent has been given to transmitting location information during the call session, and determines whether or not consent has been given to transmitting location information (S705).

[0137] If consent is given to transmit location information (S705: Yes), the input form will display a free-text input field as well as a location information transmission button (S707a). Location information may be acquired and transmitted to the management server 50 depending on the operator's actions (S708a). On the other hand, if consent is not given (S705: No), the input form will only display a free-text input field (S707b).

[0138] The informant enters additional information in free text format into the input form (S709). This free text may include, for example, changes in symptoms, surrounding circumstances, the extent of the damage, and the progression of the danger.

[0139] Upon the send operation by the informant, additional information including free-form text (and location information if necessary) is sent to the management server 50 (S710), and the management server 50 receives the additional information (S711).

[0140] Next, the management server 50 identifies the target notification record based on the notification ID (or notification ID) (S712), and records the additional information associated with the notification record (S713).

[0141] Subsequently, the management server 50 may update the notification record to reflect the results of recording the additional information (S714). This may include, for example, registering the additional information in the additional information table 552, updating the notification record to include the last update time, or adding metadata necessary for the update process.

[0142] Once the acquisition and recording of additional information is complete, the management server 50 hands over the additional information to the event update process (S715). That is, the additional information acquired through the input form processing is processed by referring to the event update process flow shown in Figure 5, and score recalculation, rank update, deadline processing, etc. may be performed as needed.

[0143] In this embodiment, the location information may include at least latitude and longitude coordinate information (for example, latitude and longitude based on GNSS). The management server 50 (or operator terminal 40) may be equipped with a map display function (map display unit) that displays the location of the reported case on a map based on the latitude and longitude stored in the report record or the additional information table 552.

[0144] The map display function can, for example, display location information linked to a call ID as a marker on a map, and depending on the selection of the marker, display information about the call, such as the content of the call, rank, score, deadline, and remaining time. This allows operators to understand the location of the call based on coordinates and make a response decision in conjunction with the priority and urgency of the call.

[0145] Furthermore, if a configuration is adopted in which location information is obtained based on consent, in cases where the consent information indicates no consent, the latitude and longitude may not be registered. In such cases, the map display function will show the location as undetermined, and additional information such as free-form text can be used to assist in making a decision on how to respond.

[0146] <10. Re-notification process (Figure 8)> Next, referring to Figure 8, we will explain the re-notification process when an emergency call is made again from the same caller terminal 20. Figure 8 shows an example of the re-notification process flow executed by the management server 50.

[0147] First, when a new emergency call (re-call) is sent from the caller terminal 20 (S801), the management server 50 receives the call and starts the call reception process. The call reception unit 51 receives the incoming call and performs session management such as establishing and maintaining the call session (S802).

[0148] Next, the notification reception unit 51 acquires caller information 59 (e.g., telephone number, etc.) that may be sent in conjunction with the re-notification (S803). Subsequently, the management server 50 searches the database 55 based on the acquired caller information 59 and determines whether or not an existing notification record corresponding to the caller information 59 exists (S804). In the search for existing records, the system may be configured to narrow down candidates based on status information such as unhandled / in processing, the most recent reception time (time window), etc. Here, the case of determining whether or not an existing notification record corresponding to the caller information 59 exists is given as an example, but it is not limited to this. For example, even if an existing notification record corresponding to the caller information 59 is not found, an existing notification record may be identified based on identification information associated with the notification ID, link parameters of the input form, operator designation, etc., and the re-notification may be linked to the existing case and handled accordingly.

[0149] If no existing report record exists (S805: No), the re-report will be treated as a new report, and the system will transition to the new report acceptance processing flow shown in Figure 4 (S806).

[0150] On the other hand, if an existing notification record exists (S805: Yes), the management server 50 treats the re-notification as additional information for the existing notification case (S807). Specifically, it may acquire information obtained at the time of the re-notification (e.g., text of the speech recognition result of the call audio), the time of dispatch, or supplementary information obtained during the call as additional information.

[0151] Next, the management server 50 stores the re-notification information, which will be treated as additional information, in association with the target notification record (S808). This storage can be done, for example, by registering the acquisition date and time, acquisition route (re-notification), and information acquired at the time of re-notification in the additional information table 552, using the notification ID as a foreign key.

[0152] Next, the management server 50 may (optionally) recalculate the score based on the latest information, including the re-notification (S809).

[0153] Subsequently, the management server 50 passes the additional information obtained through the re-notification to the event update process (S810). That is, the additional information obtained through the re-notification is processed by referring to the event update process flow shown in Figure 5, and rank updates, deadline processing, notification record updates, etc. may be performed as needed (for example, storing the update results: S811).

[0154] <11. Notification Processing (Figure 9)> Next, with reference to Figure 9, the notification process for reported cases will be explained. Figure 9 shows an example of the notification processing flow executed by the notification unit 56 of the management server 50. Notification processing can be implemented as an additional function and is executed in response to changes in the status or priority of reported cases.

[0155] First, the notification process is initiated when a predetermined trigger occurs (S901). Notification triggers may include, for example, an update to the rank of a reported case, the meeting of predetermined criteria for the score, the arrival of a deadline, or a change in the response status.

[0156] Next, the notification unit 56 retrieves the relevant report record from the database 55 (S902). This retrieval may include information necessary for determining whether notification is required and generating notification content, such as notification destination information, rank, response status, disclosure category, and consent information for the whistleblower terminal 20.

[0157] Next, the notification unit 56 determines whether or not it is necessary to issue a notification based on the trigger and the contents of the notification record (S903).

[0158] If it is determined that notification is necessary (S903: Yes), the notification unit 56 may select a notification method (S904). The selection of a notification method may be, for example, by sending a message to the caller terminal 20 (SMS, etc.), making an automated voice call (return call), or a combination thereof. S904 is an optional step and may be omitted, fixing the system to a predetermined notification method.

[0159] Next, the notification unit 56 generates a notification message (or voice guidance content) to be used for notification (S905). The notification message may include, for example, the status of receipt of the report, the status of the response, changes in priority, warnings, etc., and the content may be controlled based on the disclosure category and consent information.

[0160] Next, the notification unit 56 sends a notification based on the generated notification message (S906). For example, if the phone number included in the caller information 59 is a mobile phone number, the notification unit may select and execute message sending (e.g., SMS) as the notification method. On the other hand, if it is determined from the transmission results that the message transmission failed, the notification method can be switched to automatic voice dialing (Return Call) and a call can be made to the caller terminal 20.

[0161] Furthermore, the notification unit 56 may optionally obtain the result of the transmitted notification (S907). The notification result may include, for example, the success / failure of message transmission, whether or not there was a response to voice transmission, etc.

[0162] If a configuration is adopted to acquire notification results, the notification unit 56 stores the acquired notification results in association with the reported case (S908). For example, by recording the notification results in a report record or the extended table group 553, they can be used for subsequent operational decisions and history management.

[0163] <12. Score calculation process (Figure 10)> Figure 10 is a flowchart showing an example of the processing procedure by which the management server 50 (priority initial determination unit 53 / priority update unit 54) calculates the score of a reported case. The score calculation process will be explained below with reference to Figure 10.

[0164] When the management server 50 (priority initial determination unit 53 / priority update unit 54) starts the score calculation process (start), it first retrieves the notification record from the database 55 (S1001). In retrieving the notification record (S1001), information about the notification case, including the content of the notification, sender information, and past scores, may be obtained.

[0165] Next, the management server 50 (priority initial determination unit 53 / priority update unit 54) extracts parameters for score calculation (S1002). These parameters may include, for example, the content of the report, location information, whether a re-report was made, and the elapsed time.

[0166] Next, the management server 50 (priority initial determination unit 53 / priority update unit 54) calculates a base score based on predefined criteria (S1003). Here, the base score may be calculated based on point-assigning rules corresponding to, for example, words indicating danger and urgency included in the report content, the scale of human casualties, risk factors, etc.

[0167] Next, the management server 50 (priority initial determination unit 53 / priority update unit 54) determines whether or not additional adjustments are necessary for the base score (S1004). If no additional adjustments are necessary in S1004 (No), the management server 50 (priority initial determination unit 53 / priority update unit 54) confirms the base score as the final score (S1006).

[0168] On the other hand, if additional correction is required in S1004 (Yes), the management server 50 (priority initial determination unit 53 / priority update unit 54) may perform optional corrections such as correction based on re-notification (S1005a), correction based on location information (S1005b), and / or correction based on elapsed time (S1005c). For example, corrections such as adding points if the number of re-notifications based on the same caller information exceeds a predetermined number (S1005a), adding points if the location information falls within a dangerous area, etc. (S1005b), and corrections that reflect urgency according to the elapsed time since notification was received, or (at least if belonging to the first rank group) the remaining time (S1005c) may be adopted. Whether or not these corrections are adopted and the amount of correction may be changed according to the operational settings. Note that these S1005a to S1005c are optional steps and may be omitted according to the operational settings, as shown by the dashed lines in Figure 10.

[0169] Subsequently, the management server 50 (priority initial determination unit 53 / priority update unit 54) confirms the corrected score as the final score (S1006).

[0170] Finally, the management server 50 (priority initial determination unit 53 / priority update unit 54) outputs the final determined score and passes it on to the rank determination process or update process (S1007).

[0171] The base score (S1003) and final score (S1006) calculated in Figure 10 can be used, for example, in the priority determination / update processes shown in Figure 4 (initial priority determination process), Figure 5 (event update process), and Figure 6 (periodic update process). Based on the above, a base score is calculated for each reported case based on the report content, and then, if necessary, corrections are made to reflect re-reporting, location information, elapsed time, etc., before the score is finalized and ready for subsequent processing (end).

[0172] Each of the processes described above (such as notification reception processing, initial priority determination processing, event update processing, periodic update processing, and notification processing) can be implemented as a program to be executed by a computer. Such a program can be provided by recording it on a computer-readable recording medium, or it can be distributed via a communication line. [Explanation of symbols]

[0173] 20... Informant's terminal 30…Exchange (PBX) 31…Interactive Voice Response (IVR) 40…Operator terminal 50…Management Server 51...Reporting Department 53…Priority initial determination section 531... Pre-trained model 532...Score calculation unit 533... Deadline setting section 54...Priority update section 541...Event update function 542…Regular update function 55... Database 551... Report Case Table (Report Record) 552... Additional Information Table 553... Extended Tables 56…Notification section 57…Switching control unit 58…External Integration System 59... Caller information D... Deadline (deadline time) t0...Time of notification reception t now …Current time R0...Initial remaining time R now …Remaining time S401~S411... Report reception processing / initial priority determination processing (report record generation and storage) S501~S508...Event update processing S601~S608...Regular update processing S701~S715... Input form processing S801~S811...Re-reporting process S901~S908...Notification processing S1001~S1007...Score calculation process

Claims

1. The emergency call reception department receives emergency calls and retrieves the content of those calls, A database that stores information related to the aforementioned emergency call as a call record, A priority initial determination unit determines a rank indicating the priority of the emergency call based on the content of the emergency call and registers it in the call record, A priority update unit that updates the rank of the notification record registered in the database, Equipped with, The priority update unit, after the notification record has been registered in the database, identifies the target notification record when it obtains additional information regarding the emergency notification, and executes an event update process to update the rank of the target notification record. The emergency call processing system is characterized in that the priority initial determination unit generates information that is automatically structured into predetermined items or the text that forms the basis of such structuring, based on the text of the speech recognition result of the call audio and / or input information received by IVR, which are acquired as the content of the emergency call, through predetermined analysis processing, determines the rank using a trained model with the generated information or text as input, and registers the determined rank in the call record.

2. In the emergency call processing system according to Claim 1, The emergency call processing system is characterized in that the priority initial determination unit sets a deadline, which is the time limit, as information regarding the remaining time, according to the determined rank and the information regarding the urgency of the emergency call obtained, and registers the said deadline in the call record.

3. In the emergency call processing system according to claim 1, The emergency call processing system is characterized in that the aforementioned additional information includes at least one of location information and free-form text.

4. A call receiving unit that receives emergency calls and obtains the content of the calls, A database that stores information related to the aforementioned emergency call as a call record, A priority initial determination unit determines a rank indicating the priority of the emergency call based on the content of the emergency call and registers it in the call record, A priority update unit that updates the rank of the notification record registered in the database, Equipped with, The priority update unit, after the notification record has been registered in the database, identifies the target notification record when it obtains additional information regarding the emergency notification, and executes an event update process to update the rank of the target notification record. The aforementioned reporting receiving unit has a link transmitting unit that transmits link information to an input form for inputting the aforementioned additional information to the reporting terminal. The emergency notification processing system is characterized in that the priority update unit executes the event update process based on the additional information received through the input form.

5. In the emergency call processing system according to Claim 4, The aforementioned notification receiving unit or priority updating unit obtains consent information indicating whether or not consent has been given to the transmission of location information during the call session. If the consent information indicates no consent, the input form is provided as a form that accepts input of additional information, including free text, with the function for acquiring or transmitting location information disabled. The emergency notification processing system is characterized in that the priority update unit executes the event update process based on the additional information received through the input form.

6. A call receiving unit that receives emergency calls and obtains the content of the calls, A database that stores information related to the aforementioned emergency call as a call record, A priority initial determination unit determines a rank indicating the priority of the emergency call based on the content of the emergency call and registers it in the call record, A priority update unit that updates the rank of the notification record registered in the database, Equipped with, The priority update unit, after the notification record has been registered in the database, identifies the target notification record when it obtains additional information regarding the emergency notification, and executes an event update process to update the rank of the target notification record. The notification record includes, in addition to the rank, a score which is a numerical value separate from the rank and is used for ordering within the same rank. The priority initial determination unit calculates the score based on the content of the emergency call and registers it in the call record. The priority update unit is characterized in that, in the event update process, it recalculates the score based on the additional information.

7. In the emergency call processing system according to Claim 6, The priority initial determination unit and / or the priority update unit holds setting information indicating a first rank group including ranks subject to urgency assessment and a second rank group including ranks not subject to urgency assessment. The notification record includes, as information regarding the remaining time, at least the deadline time, An emergency call processing system characterized in that, when the priority initial determination unit and / or the priority update unit calculate or recalculate the score, if the rank held in the call record prior to the calculation or recalculation belongs to the first rank group, it takes into account an urgency parameter based on the remaining time information, and if the rank held in the call record belongs to the second rank group, it does not take into account the urgency parameter.

8. A call receiving unit that receives emergency calls and obtains the content of the calls, A database that stores information related to the aforementioned emergency call as a call record, A priority initial determination unit determines a rank indicating the priority of the emergency call based on the content of the emergency call and registers it in the call record, A priority update unit that updates the rank of the notification record registered in the database, Equipped with, The priority update unit, after the notification record has been registered in the database, identifies the target notification record when it obtains additional information regarding the emergency notification, and executes an event update process to update the rank of the target notification record. The notification record includes information about the remaining time, including a deadline which is the due time to be registered in the notification record, which is set according to the rank. The priority update unit is characterized by calculating the remaining time, which represents the remaining time until the deadline, based on the difference between the current time and the deadline.

9. In the emergency call processing system according to claim 8, The priority update unit further performs a periodic update process to update the rank of multiple notification records registered in the database at predetermined intervals after the notification record has been registered in the database. The emergency notification processing system is characterized in that the periodic update process includes, when the notification record includes a deadline, a process that calculates the remaining time based on the difference between the current time and the deadline, and updates the rank to a higher rank when the calculated remaining time falls below a predetermined threshold.

10. A call receiving unit that receives emergency calls and obtains the content of the calls, A database that stores information related to the aforementioned emergency call as a call record, A priority initial determination unit determines a rank indicating the priority of the emergency call based on the content of the emergency call and registers it in the call record, A priority update unit that updates the rank of the notification record registered in the database, Equipped with, The priority update unit, after the notification record has been registered in the database, identifies the target notification record when it obtains additional information regarding the emergency notification, and executes an event update process to update the rank of the target notification record. An emergency call processing system further comprising a notification unit that sends a message or makes an automated voice call to the caller's terminal in response to changes in the processing status or response status of the aforementioned call record.

11. In the emergency call processing system according to claim 10, The emergency call processing system is characterized in that the notification unit sends the message to the caller terminal if the caller terminal's telephone number is a mobile phone number, and makes an automated voice call to the caller terminal if the message transmission fails.

12. A notification reception unit that receives emergency calls and obtains the content of the calls, A database that stores information related to the aforementioned emergency call as a call record, A priority initial determination unit determines a rank indicating the priority of the emergency call based on the content of the emergency call and registers it in the call record, A priority update unit that updates the rank of the notification record registered in the database, Equipped with, The priority update unit, after the notification record has been registered in the database, identifies the target notification record when it obtains additional information regarding the emergency notification, and executes an event update process to update the rank of the target notification record. An emergency call processing system further comprising a switching control unit that, when the network congestion status meets predetermined conditions, receives operational input from an employee and, in response to said operational input, causes the on-premises exchange to change settings to enable connection to the automated voice response system.

13. A notification reception unit that receives emergency calls and obtains the content of the calls, A database that stores information related to the aforementioned emergency call as a call record, A priority initial determination unit determines a rank indicating the priority of the emergency call based on the content of the emergency call and registers it in the call record, A priority update unit that updates the rank of the notification record registered in the database, Equipped with, The priority update unit, after the notification record has been registered in the database, identifies the target notification record when it obtains additional information regarding the emergency notification, and executes an event update process to update the rank of the target notification record. The emergency call processing system is characterized in that, when the priority update unit receives a second or subsequent emergency call from the same caller terminal as additional information, it searches the database based on the caller information included in the emergency call, identifies the target call record, records the content of the second or subsequent emergency call as additional information for the target call record, and performs the event update process to update the rank of the target call record based on the additional information.

14. A computer-based emergency call processing method, The process of receiving emergency calls, A process to generate information that is automatically structured into predetermined items or the text that forms the basis of such structuring, based on the text of the speech recognition result of the call audio obtained as the content of the emergency call and / or the input information received by IVR, through a predetermined analysis process, The process involves using the generated information or text as input to determine a rank indicating the priority of the emergency call using a trained model, The process of registering the information relating to the emergency call in the database as a call record including the rank, After the notification record is registered in the database, an event update process is performed to identify the target notification record based on the acquisition of additional information and to update the rank of the target notification record. An emergency call processing method characterized by including the following.

15. On the computer, We accept emergency calls. Based on the text of the speech recognition result for the call audio obtained as the content of the emergency call and / or the input information received by IVR, a predetermined analysis process generates information that is automatically structured into predetermined items or the text that forms the basis of such structuring. The trained model uses the generated information or text as input to determine a rank indicating the priority of the emergency call. The information regarding the aforementioned emergency call is registered in the database as a call record including the rank, A program for causing a target notification record to be identified and its rank updated after the notification record has been registered in the database, triggered by the acquisition of additional information.

Images