System and method for ai-assisted emergency response

Abstract

The present disclosure relates to a computer-implemented method and system for AI- Assisted Emergency Response in automated emergency services systems wherein a real-time analysis of an active emergency call is performed, comprising: - implementing real-time speech-to-text conversion of an acoustic signal of the active emergency call; - performing, concurrently with the active emergency call, classification of an incident with confidence scoring of the active emergency call after being transcribed, assigning the incident to at least one category from a set of predefined categories; - dynamically generating sequences of questions for a caller tailored to specific incident characteristics; - suggesting specific questions that a call-taker should ask the caller; and - dynamically updating the questions as call-taker receives answers from the caller.

Description

[0001] System and Method for AI-Assisted Emergency Response

[0002] DESCRIPTION

[0003] TECHNICAL FIELD

[0004] The present disclosure relates to the field of emergency response systems and, more particularly, to automated emergency services with Real-Time Incident Analysis and Dynamic Resource Dispatch.

[0005] More specifically, but not exclusively, this disclosure relates to systems and methods for autonomous emergency call handling and dispatch optimisation, using real-time artificial intelligence analysis, including real-time incident classification during an active call and generation of specific dispatch recommendations and tactical briefings.

[0006] BACKGROUND OF THE DISCLOSURE

[0007] Conventional emergency response systems suffer from three fundamental technical deficiencies that limit their effectiveness in modern emergency response scenarios.

[0008] First, existing call-taker systems rely predominantly on static protocol cards and manual decision-making without real-time automated analysis of incoming emergency calls. Call-takers must manually classify incidents, recall appropriate questioning protocols from memory or reference materials, and transcribe information into computer-aided dispatch systems without intelligent assistance that adapt dynamically to the evolving information landscape of an active emergency call.

[0009] This reliance on human memory and static reference materials results in inconsistent information gathering, missed critical questions, extended call durations, and variable quality of incident documentation that depends heavily on individual calltaker experience and training levels.

[0010] Second, conventional dispatch systems employ simplistic, post-call dispatch logic that typically assigns the closest available unit to an incident sequentially upon call termination, without dynamically analysing incident-specific resource requirements or integrating real-time traffic data into routing decisions concurrently with the call, even on PSAP using a common reception-dispatch unified configuration. Such systems fail to consider whether the closest unit possesses the specialized equipment, personnel qualifications, or vehicle characteristics necessary for the specific incident type.

[0011] For example, a cardiac arrest incident may require an advanced life support ambulance with defibrillation capability and paramedic -level personnel, yet a closest- unit dispatch algorithm may assign a basic life support unit lacking these critical capabilities. Similarly, conventional systems fail to account for real-time traffic conditions, road closures, and dynamic routing factors that significantly impact actual response times, resulting in suboptimal resource allocation and delayed emergency response.

[0012] NVSOO IBWO / MAB This sequential workflow fails to capitalize on the information revealed progressively during an active call, missing opportunities for parallel processing wherein dispatch resource analysis could proceed concurrently with call-taking activities, thereby eliminating dispatch delay and enabling immediate resource deployment upon call completion.

[0013] There exists a long-felt need in the emergency response field for an autonomous Al assisted comprehensive system that provides real-time intelligent assistance to calltakers through automated speech analysis and dynamic protocol generation, optimises dispatch decisions through context-aware resource matching and traffic- integrated routing, and achieves parallel processing of call intelligence and dispatch optimisation to eliminate latency in emergency response activation.

[0014] SUMMARY OF THE DISCLOSURE

[0015] The solution idea on the basis of the present disclosure makes use of a group of independent modules, each usable either standalone or in integration.

[0016] In an integrated configuration, the modules continuously exchange incident intelligence during an active call to enable contextual dispatch optimisation in parallel with call data collection, optimisation eliminating sequential processing latency.

[0017] Therefore, the present disclosure solves the known art deficiencies through a multimodule emergency response system comprising independent yet integrable system modules, each delivering standalone technical value while achieving synergistic effects when deployed in combination.

[0018] According to an aspect of some embodiments of the disclosed subject matter there is provided a computer-implemented method for AI-Assisted Emergency Response in automated emergency services systems wherein a real-time analysis of an active emergency call is performed, comprising:

[0019] - implementing real-time speech-to-text conversion of an acoustic signal;

[0020] - performing a concurrent incident classification with confidence scoring of the incoming and transcribed active emergency call, assigning the incident to at least one category from a set of predefined categories;

[0021] - dynamically generating sequences of questions for a caller tailored to specific incident characteristics;

[0022] - suggesting specific questions that a call-taker should ask the caller; and

[0023] - dynamically updating the questions as call-taker receives answer from the caller.

[0024] Advantageously, the above method further includes:

[0025] - determining an incident severity level;

[0026] - continuously updating the severity level as new information is received from the text transcript;

[0027] NVSOO IBWO / MAB - calculating a priority score based on the severity level and confidence score; and

[0028] - providing the priority score to a dispatch queue management system.

[0029] Moreover, the step of performing concurrent incident classification is continuously executed in a parallel processing pipeline, enabling simultaneous dispatch resource optimisation without waiting for the active call to end.

[0030] Furthermore, questions addressing critical mandatory information fields are ranked higher than questions addressing supplementary information, ensuring that essential information is collected first and that dispatch can proceed even if the call is prematurely terminated.

[0031] According to an aspect of some embodiments of the disclosed subject matter there is provided a system for continuous analysis of incidents during active calls, comprising:

[0032] - a processing module configured to operate during an active call in progress,

[0033] - a speech-to-text conversion unit configured to perform real-time transcription of audio content of the active call producing a text transcript,

[0034] - a classification unit configured to perform concurrently with the active call incident classification based on the text transcript assigning the incident to at least one category from a plurality of predefined categories,

[0035] - a confidence score generator associated with the classification unit configured to calculate a confidence score for each assigned category,

[0036] - a severity evaluator configured to determine the severity level of the incident and to update the severity level continuously as new information is received from the text transcript, and

[0037] - a priority score calculator configured to calculate a priority score based on the severity level and the confidence score, and an integration interface configured to provide the priority score to a dispatch queue management system.

[0038] A further aspect of the present disclosure relates to a computer-implemented method for optimising the dispatch of incident response resources, comprising:

[0039] - storing, in a tactical database, a plurality of resource records, each resource record comprising selected multidimensional attributes from a group including available equipment, assigned personnel, vehicle type, and current operational status;

[0040] - receiving incident data relating to an incident;

[0041] - determining incident-specific resource requirements based on the received incident data;

[0042] - acquiring real-time traffic data;

[0043] NVSOO IBWO / MAB - calculating, for each resource of the plurality of resources, a traffic-aware estimated time of arrival (ETA) to an incident location;

[0044] - evaluating a plurality of candidate resources based on the incident-specific resource requirements, the multidimensional attributes, and the traffic-aware ETAs;

[0045] - selecting, using a multi-factor optimisation engine, at least one optimal resource for coordinated dispatch;

[0046] - automatically generating a tactical briefing comprising information relating to the incident and the selected resource; and

[0047] - transmitting the tactical briefing through a plurality of communication channels.

[0048] The first independent system module, designated hereinafter as the Real-Time Call Intelligence System, provides automated real-time analysis of emergency calls and generates dynamic, context-aware questioning protocols that adapt to the evolving information landscape of an active emergency call.

[0049] When the first and second modules are integrated to form the Integrated Bidirectional Emergency Response System the combined system establishes a parallel processing pipeline wherein call intelligence analysis and dispatch resource optimisation proceed concurrently during an active emergency call, eliminating sequential dispatch latency and enabling immediate resource deployment upon call completion.

[0050] The integrated system further implements bidirectional intelligence flow wherein classification updates from the call intelligence engine dynamically narrow the resource search space in the dispatch optimisation engine, location extraction immediately enables route calculation, and severity updates trigger resource quantity adjustments, creating a unified intelligence model that exceeds the sum of the independent module capabilities.

[0051] Finally, the present invention further provides a resilient emergency communication channel that functions when voice networks fail; significantly reducing false emergency reports through advanced fraud detection; improving response times by automating incident classification and resource recommendation and supporting faster dispatch handling through automated validation and structured incident packaging; enhancing situational awareness for responders through authenticated multimedia evidence; enabling safe reporting in dangerous situations where voice calls are impossible; integrating seamlessly with existing emergency infrastructure without requiring replacement of legacy systems; supporting dispatch adaptation as incident details evolve; and, in some embodiments, enabling improvement of system performance using historical outcome analysis.

[0052] Features and advantages of the present disclosure will be disclosed with reference to the enclosed drawings relating to an indicative and a non-limiting implementation example.

[0053] BRIEF DESCRIPTION OF THE DRAWINGS

[0054] NVSOO IBWO / MAB FIG. 1 shows a schematic view of an integrated system for AI-Assisted Emergency Response with Real-Time Incident Analysis and Dynamic Resource Dispatch according to the present disclosure;

[0055] FIG. 2 is a more detailed schematic view of a first system module incorporated into the integrated system of FIG. 1;

[0056] FIG. 3 is a more detailed schematic view of a second system module incorporated into the integrated system of FIG. 1;

[0057] FIG. 4 is schematic flow chart of a method for AI-Assisted Emergency Response with Real-Time Incident Analysis and Dynamic Resource Dispatch according to the present disclosure;

[0058] FIG. 5 is a diagram illustrating a bidirectional communication maintenance module between an emergency reporter and a dispatcher according to an embodiment of the present invention;

[0059] FIG. 6 is a flow chart illustrating a method for internet -based emergency reporting according to an embodiment of the present invention.

[0060] DETAILED DESCRIPTION

[0061] The present disclosure relates to a computer-implemented method for AI-Assisted Emergency Response with Real-Time Incident Analysis and Dynamic Resource Dispatch.

[0062] The disclosure further relates to an integrated system for implementing the above method.

[0063] The integrated system 100 of the present disclosure includes independent yet integrable system modules 1 and 2, each delivering standalone technical value while achieving synergistic effects when deployed in combination.

[0064] The independent system modules can operate standalone or integrated, as schematically shown in FIG. 1.

[0065] The modularity of the configured structure allows for stand-alone operation, with each module accepting inputs consistent with its functions (e.g., audio and dialogue for module 1, or manually entered incident data for module 2), as well as integrated operation, with modules cooperating through a shared data model and bidirectional intelligence flow during the active call.

[0066] Module 1

[0067] Independent system module 1 is named hereinafter Real-Time Call Intelligence System module 1.

[0068] The fundamental features of the first system module 1 are the following:

[0069] • Continuous speech-to-text processing during an active emergency call

[0070] NVSOO IBWO / MAB • Real-time incident classification with confidence scoring

[0071] • Dynamic SOP-driven question generation based on information gaps

[0072] • Contextual, adaptive prompting for call-takers

[0073] • Live structured incident summary generation

[0074] Standalone value: module 1 improves call quality and consistency without modifying dispatch systems.

[0075] This module offers many advantages over the prior art solutions and in particular:

[0076] 1) Context-aware dispatch optimisation with parallel processing;

[0077] 2) Bidirectional feedback loop during active incidents

[0078] In other words, the Real-Time Call Intelligence System module 1 comprises four principal functional subsystems that operate in concert to provide automated realtime analysis and intelligent assistance during active emergency calls. This system operates independently of dispatch functions and delivers standalone value through improved call-taker performance, standardized information gathering, and enhanced incident documentation quality.

[0079] The module 1 components may be summarized as including and capable of handling the following aspects:

[0080] Method for real-time dynamic question generation during emergency calls based on Al incident classification and SOP requirements;

[0081] System for tracking information gaps during emergency calls and prioritizing next- best questions to pose to the caller;

[0082] Algorithm for contextual prompt delivery that adapts to call-taker behaviour and incident evolution; and

[0083] Data structure representing incident classification confidence with associated mandatory information requirements.

[0084] Let’s now see in more detail the structure and functions of the first system module 1. Module 1 components or subsystems are the following:

[0085] Analysis Processing Module

[0086] The first principal subsystem of the Real-Time Call Intelligence System module 1 is the Continuous Incident Analysis Processing Module, designated by reference numeral 20, which performs automated real-time analysis of an active emergency call, continuously updating incident classification and severity assessment as new information is revealed during the call conversation.

[0087] NVSOO IBWO / MAB The Continuous Incident Analysis Processing Module 20 operates on the audio stream of an active emergency call, designated by reference numeral 25, which represents the real-time voice communication between a caller reporting an emergency and a call-taker receiving and documenting the emergency report.

[0088] The Continuous Incident Analysis Processing Module 20 implements real-time speech-to-text conversion that transforms the acoustic signal of the active emergency call 25 into textual transcription with minimal latency, typically on the order of one to three seconds, such that the textual representation of spoken words becomes available for analysis while the conversation continues.

[0089] This speech-to-text conversion employs automatic speech recognition technology, identified by block 27, executing continuously in a parallel processing pipeline alongside the call-taker’s live interaction. The conversion is adapted specifically for emergency call audio characteristics, including high emotional stress in caller voices, background noise from emergency scenes, multiple overlapping speakers, and domain-specific emergency terminology.

[0090] The speech-to-text conversion phase produces a continuously growing transcript that captures both caller utterances and call-taker questions and responses, enabling analysis of the complete conversational context rather than isolated utterances.

[0091] A concurrent incident classification routine 30 with confidence scoring builds upon the real-time speech-to-text conversion. This phase generates or populates a database portion 32 including classified and scored utterances.

[0092] The Continuous Incident Analysis Processing Module 20 performs concurrent incident classification with confidence scoring, identified in the drawings by a software routine with reference numeral 30, which analyses the continuously growing transcript to determine the most probable incident type and assigns a numerical confidence score representing the system’s certainty in the classification determination.

[0093] The incident classification routine 30 with confidence scoring operates continuously throughout the whole duration of the active emergency call 25, updating classification predictions and confidence scores as each new utterance adds information to the conversational context.

[0094] This continuous updating characteristic distinguishes the present system from conventional systems that perform classification only once at the beginning of a call based on limited initial information.

[0095] The incident classification with confidence scoring 30 categorizes emergency calls across multiple predefined incident categories that align with the organisational structure of emergency response agencies and the resource types available for dispatch.

[0096] These categories included in database portion 32 assigns different scores or values to different emergencies, for instance: medical emergencies encompass incidents involving injury, illness, or medical distress requiring medical personnel and

[0097] NVSOO IBWO / MAB ambulance resources; fire incidents encompass structure fires, vehicle fires, wildland fires, and other incidents involving uncontrolled combustion requiring firefighting resources; law enforcement situations encompass crimes in progress, suspicious activity, domestic disturbances, and other incidents requiring police personnel; traffic accidents encompass vehicle collisions on roadways requiring medical, fire, and police resources depending on severity and circumstances.

[0098] The Continuous Incident Analysis Processing Module 20 further implements continuous updating of severity assessments, identified by block 37, which evaluates the seriousness and urgency of the reported incident based on factors including immediate threat to life, number of people affected, presence of hazards, and time criticality.

[0099] The severity assessments are continuously updated as new information emerges during the active emergency call 25, enabling the system to recognize when an initially low-severity incident escalates to high severity, for example when a caller initially reporting a minor vehicle accident subsequently mentions that a passenger is now unconscious, or when a caller reporting smoke discovers flames spreading rapidly.

[0100] The severity assessments phase 37 employs rule-based logic combined with trained machine learning models, such as natural language processing (NLP) transformer models, configured to continuously parse the expanding text transcript. These models identify and extract semantic severity indicators, such as mentions of unconsciousness, difficulty breathing, severe bleeding, weapons, multiple victims, trapped persons, rapidly spreading fire, building collapse, or other critical factors - and dynamically adjust the incident severity score in real-time as the conversational context evolves.

[0101] The severity assessment generates a categorical severity level, such as low, medium, high, or critical, and may also generate a numerical severity score on a continuous scale. This phase is identified in the drawings by a software routine with reference numeral 40.

[0102] The severity assessments phase 37 directly informs dispatch priority and resource allocation decisions, ensuring that the most serious incidents receive the fastest response and the most capable resources. This is identified in the drawings by a database portion 42 that is continuously updated and linked to the previous database portion 32.

[0103] Complementing the severity assessments phase 37, the Continuous Incident Analysis Processing Module 20 generates priority scores for dispatch queue management, designated by reference numeral 45, which represents the relative urgency of the current incident compared to other pending incidents awaiting dispatch.

[0104] The priority scores block 45 integrates multiple factors including the severity assessments 37, the incident classification 42, temporal factors such as how long the incident has been pending, resource availability, and policy-based priority rules established by the emergency response agency. The temporal pendency of the incident

[0105] NVSOO IBWO / MAB is information provided directly by the processing module 20 through its connections to blocks 27 and 37.

[0106] For example, cardiac arrest medical emergencies typically receive maximum priority scores in block 45 due to the time-critical nature of cardiac resuscitation, while noninjury traffic accidents with no hazards may receive lower priority scores even if reported earlier. The priority scores block 45 enable intelligent dispatch queue management wherein the dispatch system selects the next incident for resource assignment based on priority scoring rather than simple first-in-first-out queue logic, ensuring that the most urgent emergencies receive response resources first even when call volume is high and multiple incidents are pending simultaneously.

[0107] The Continuous Incident Analysis Processing Module 20 operates continuously throughout the duration of the active emergency call 25, processing each new utterance as it is converted from speech to text, updating incident classification with confidence scoring 27, revising the severity assessments 37, and recalculating the priority scores 45 in real-time.

[0108] This continuous updating characteristic enables the system to track incident evolution, recognize escalation or de-escalation, and ensure that the most current and accurate incident intelligence is available to support dispatch decisions at the moment the call concludes. The continuous nature of the analysis also enables early dispatch decisions for unambiguous high-severity incidents, wherein response resources may be deployed before the call-taker has completed information gathering, reducing overall response time for the most critical emergencies.

[0109] Dynamic Protocol Generator 50

[0110] The second principal subsystem of the Real-Time Call Intelligence System 20 is the Dynamic Protocol Generator 50, which maps incident classifications to appropriate questioning protocols and dynamically generates prioritized sequences of questions tailored to the specific incident characteristics and information gaps present at each moment during the active emergency call 25.

[0111] The Dynamic Protocol Generator 50 operates in real-time, continuously analysing the current state of information collection obtained from block 45 and generating recommendations for the next most valuable question to ask to the caller, thereby providing intelligent guidance to the call-taker that adapts to the actual course of the conversation rather than following a rigid predetermined script.

[0112] The Dynamic Protocol Generator 50 maintains mappings between each incident type, as determined by the incident classification with confidence scoring 27, and jurisdiction-specific Standard Operating Procedures, as traceable in a memory bank designated by reference numeral 60, which defines the information requirements, questioning sequences, and dispatch protocols established by the emergency response agency for each category of emergency incident.

[0113] The Standard Operating Procedures contained in the memory bank 60 vary across jurisdictions based on local policies, available resources, geographic characteristics,

[0114] NVSOO IBWO / MAB and legal requirements. The Dynamic Protocol Generator 50 accommodates this variation by maintaining dynamically updatable protocol data structures that electronically map customized jurisdictional requirements to the Al-generated incident classifications. The Standard Operating Procedures for medical emergencies may, for example, specify that call-takers must determine the patient’s consciousness level, breathing status, presence of severe bleeding, and medical history, while the Standard Operating Procedures for fire incidents may specify that call-takers must determine whether persons are trapped, the size and location of the fire, and the type of structure involved.

[0115] Module 1 identifies mandatory information fields for each incident classification reported in the database 32.

[0116] Building upon the Standard Operating Procedures of memory bank 60, the Dynamic Protocol Generator 50 identifies mandatory information fields, designated by reference numeral 70, which represent specific data elements that must be collected for that particular incident type before dispatch can proceed or before the call can be concluded.

[0117] The mandatory information fields 70 are defined within the Standard Operating Procedures of memory bank 60 and typically include incident location, incident type, severity indicators, number of persons involved, and specific hazards present.

[0118] The identification of mandatory information fields 70 enables the system to distinguish between critical information that must be collected and supplementary information that is valuable but not essential, ensuring that call-takers prioritize the most important questions when call duration must be minimized due to caller stress, language barriers, or high call volume.

[0119] The Dynamic Protocol Generator 50 continuously tracks collected versus missing data points, this phase is performed in block 80 coupled to the Generator 50, by comparing the information that has been explicitly stated or implicitly revealed during the active emergency call 25 against the complete set of mandatory information fields 70 and supplementary information fields defined in the Standard Operating Procedures 60 for the current incident classification 27.

[0120] The tracking of collected versus missing data points employs natural language understanding (NLU) techniques, such as entity extraction and intent recognition algorithms, to populate structured data fields from the unstructured conversational transcript. This allows for the system to recognize when a caller’s spontaneous utterance provides information corresponding to a mandatory data field, automatically fulfilling that requirement without requiring the call-taker to explicitly prompt for it.

[0121] For example, if a caller spontaneously states “my father is unconscious,” the system recognizes that the consciousness level data field has been collected with the value “unconscious” even without a direct question about consciousness. Conversely, the tracking of collected versus missing data points identifies information gaps data 80

[0122] NVSOO IBWO / MAB where mandatory information fields 70 remain uncollected, flagging these gaps for prioritized questioning.

[0123] Generator 50 generates ranked list of next-best questions based on information gaps data 80 for current incident type.

[0124] Based on the identification of information gaps data 80, which represents the set of all mandatory information fields 70 and valuable supplementary fields that have not yet been collected as determined by the tracking of collected versus missing data points, the Dynamic Protocol Generator 50 generates a ranked list of next-best questions to submit to the caller which represent an ordered sequence of specific questions that the call-taker should ask next to efficiently fill the most important information gaps data 80 and advance the call toward completion.

[0125] The ranked list of next-best questions is dynamically generated and continuously updated by the Al algorithm as each answer is received and processed, such that the system adapts in real-time to the actual information flow rather than following a static predetermined sequence. The feedback loop structure of module 1 shown in FIG. 2 is configured to allow this dynamical generation of specific questions.

[0126] Probability of classification refinement.

[0127] The ranking logic that determines the order of questions in the ranked list of next- best questions considers multiple factors to optimise information gathering efficiency and call quality.

[0128] The first ranking factor is the probability of classification refinement, which represents the likelihood that asking a particular question will provide information that increases the confidence score of incident classification 27 or resolves ambiguity between competing classification hypotheses.

[0129] Questions with high probability of classification refinement are prioritized when the current confidence score of incident classification 27 is below a threshold value, such as 70%, indicating that the system is uncertain about the type of incident and that clarifying the classification should take precedence over collecting detailed information for a potentially incorrect classification.

[0130] For example, if the system is uncertain whether an incident is a medical emergency involving allergic reaction or a law enforcement situation involving poisoning, questions about whether a crime is suspected or whether the patient has known allergies would have high probability of classification refinement and would be prioritized in the ranked list of next-best questions.

[0131] However, the logic of the Al algorithm allows performing critical versus supplementary information prioritization.

[0132] A second ranking factor is critical versus supplementary prioritization, which distinguishes between questions addressing mandatory information fields 70 that are essential for dispatch versus questions addressing supplementary information that enhances situational awareness but is not strictly required. Questions addressing

[0133] NVSOO IBWO / MAB critical mandatory information fields 70 are ranked higher than questions addressing supplementary information, ensuring that essential information is collected first and that dispatch can proceed even if the call is prematurely terminated or the caller.

[0134] Call duration and urgency considerations.

[0135] This step allows computing also the call duration.

[0136] The Dynamic Protocol Generator 50 is coupled to a Contextual Prompt Delivery Interface 90 that presents next suggested question to call-taker in real-time.

[0137] Thanks to the feedback loop structure and configuration, module 1 updates dynamically as call-taker receives answers from the caller; highlights critical missing information, provides context for why each question matters, adapts if call-taker asks different questions (doesn’t rigidly enforce sequence) .

[0138] The structure of module 1 is completed by a Structured Incident Summary Generator 15 that is entitled to issue reporting memos or digital information for the system users or for the other system modules, for instance system module 2 if present in the whole integrated system 100.

[0139] More particularly, this generator 15 extracts key data points into standardized format; provides information about incident type and sub-type classification as well as location with precision level. Further reports relate to involved parties (caller, victim, suspect, witness), timeline of events, resources needed, special hazards or considerations, severity and priority scores.

[0140] Module 1 previously disclosed obtains various advantages, for instance it can be operated in a standalone configuration even if incorporated into existing PSAP systems; it improves call-taker consistency and information gathering, reduces missed critical questions, accelerates call-taker training, standardizes incident documentation and can be deployed without changing dispatch systems.

[0141] Module 2

[0142] Let’s now consider the structure and functioning of the other independent system module 2 named Context-Aware Emergency Dispatch Optimisation whose outcome data improves both call-taking and dispatch.

[0143] Module 2 may be defined as a dispatch optimisation system that intelligently matches incidents with response resources based on specific incident requirements, real-time traffic conditions and multidimensional resource characteristics. Key features include multidimensional tactical database (equipment, personnel, vehicles, status), analysis of incident-specific resource requirements, traffic-aware ETA computation, multifactor optimisation for coordinated multi-unit dispatch, and automated generation of tactical briefings with multi-channel delivery.

[0144] Module 2 will be described hereinafter as independent of call-taking and capable of receiving manually entered data, delivering value through improved dispatch appropriateness, reduced response times, and better resource utilization.

[0145] NVSOO IBWO / MAB The module 2 components may be summarized as including the following aspects:

[0146] It relates generally to an emergency response dispatch system, and more particularly to intelligent resource allocation system that optimise emergency response unit selection and routing based on multi-dimensional resource capabilities, incidentspecific requirements, and real-time environmental conditions.

[0147] Module 2 allows implementing the method of the present disclosure for multi-factor emergency dispatch optimisation considering incident requirements, resource capabilities, equipment inventory, personnel qualifications, vehicle constraints, and real-time traffic.

[0148] In more general terms, module 2 includes system blocks for matching tactical resources to incident-specific requirements using multi-dimensional resource database.

[0149] Module 2 runs an algorithm for cascading resource selection requiring multiple coordinated response force types and hosts a data structure representing multidimensional emergency resource capabilities for optimisation

[0150] Module 2 solves drawbacks of traditional emergency dispatch systems that suffer from several critical limitations that compromise response effectiveness and resource utilization efficiency.

[0151] The fundamental features of the second system module 2 are the following:

[0152] Multi-dimensional tactical resource database (equipment, personnel, vehicles, status)

[0153] • Incident-specific resource requirement analysis

[0154] • Real-time traffic-aware ETA computation

[0155] • Multi-factor optimisation for coordinated multi-unit dispatch

[0156] • Automated tactical briefing generation and multi-channel delivery

[0157] It can operate independently from Al call-taking module 1 using manually entered incident data.

[0158] Let’s now see in more detail the structure and functions of the second system module 2.

[0159] System module 2 comprises a multi-dimensional tactical resource database 210 that maintains comprehensive real-time capability profiles for each response unit within an emergency response network.

[0160] The database 210 continuously tracks multiple independent capability dimensions including: precise real-time geographic location with continuous GPS coordinate updating; detailed equipment inventory cataloging all significant apparatus, tools, medical devices, and specialized equipment aboard each vehicle; personnel qualification matrices documenting medical training levels, specialized certifications, tactical capabilities, and relevant skills of personnel currently staffing each unit;

[0161] NVSOO IBWO / MAB vehicle characteristic specifications including vehicle type classification, terrain capability, patient or equipment capacity, and special features; and dynamic availability status reflecting current operational state and estimated time to availability for units currently engaged.

[0162] An incident-specific resource requirement analyser 220 is provided that processes incident characteristics to generate detailed required resource profiles. The analyser 220 applies rule-based logic and classification algorithms to incident type, severity indicators, environmental factors, and reported hazards to determine: specific equipment categories required for effective incident management; minimum personnel qualification levels necessary for appropriate care or intervention; vehicle capability requirements based on scene access considerations and operational needs; and quantity of resources needed based on incident scale and complexity.

[0163] This analyser 220 receives inputs from an output of module 1 or, as an alternative, receives manual inputs.

[0164] A real-time traffic and routing integration layer or block 230 is provided that continuously interfaces with external traffic data sources and routing calculation services. The features of this layer 230 will be disclosed in more detail later.

[0165] The integration layer 230 obtains current traffic flow data, road closure information, weather condition data, and other relevant environmental factors, and calculates dynamic estimated times of arrival for all potential responding units accounting for current traffic conditions, road network constraints, emergency vehicle routing capabilities, weather impacts on travel speed, and time-of-day traffic patterns.

[0166] A multi-factor optimisation algorithm 240 is provided that integrates incident requirements, resource capabilities, and routing intelligence to generate optimised resource recommendations.

[0167] The optimisation algorithm 240 filters the resource database 210 to identify candidate units that satisfy incident-specific requirements for equipment, personnel qualifications, and vehicle capabilities; calculates traffic-aware ETAs for all qualifying candidate units; applies sophisticated optimisation criteria including response time minimization, multi-unit coordination for synchronized arrivals, geographic resource distribution balancing to maintain coverage, and specialization-to-incident matching to optimise capability alignment; and generates a ranked recommendation list with supporting rationale for each recommended unit.

[0168] Moreover, cascading resource logic 250 is provided for complex incidents requiring multiple specialized resource types. The cascading logic 250 determines optimal combinations of fire, medical, law enforcement, and specialized resources based on incident requirements; coordinates appropriate arrival sequences to ensure scene security precedes vulnerable resource deployment; manages resource staging locations for secondary and supporting units; and applies automated escalation protocols that add resources based on incident development.

[0169] An automated dispatch briefing generator block 260 is provided that creates structured tactical briefings for dispatched units.

[0170] NVSOO IBWO / MAB The briefing generator 260 synthesizes incident data, location intelligence, and tactical recommendations into comprehensive mission briefings containing: incident summaries with classification, severity, key facts, and identified hazards; location intelligence including precise coordinates, address information, access considerations, and landmarks; tactical recommendations covering approach routes, scene safety considerations, equipment preparation actions, and immediate priorities upon arrival; and resource coordination details identifying other responding units, their ETAs, and command structure.

[0171] A multi-channel dispatch delivery system 270 is provided that transmits generated tactical briefings through multiple communication pathways including mobile data applications, SMS messaging, radio system integration, in-vehicle computer systems, and wearable device notifications, ensuring reliable delivery across diverse technological platforms and providing redundancy against individual channel failures.

[0172] According to yet another aspect of the disclosure, the system module 2 may operate independently of incident intake and call analysis processes of module 1, accepting incident data from traditional manual call-taking operations, automated call analysis systems, or direct manual input, thereby providing standalone value for resource optimisation regardless of the methodology employed for obtaining incident information.

[0173] The system module 2 provides numerous technical advantages over conventional dispatch approaches including: improved resource matching through systematic alignment of unit capabilities with incident requirements; reduced response times through traffic-aware routing and optimal unit selection; enhanced scene safety through structured tactical briefings that prepare responders for anticipated hazards; improved multi-resource coordination through synchronized dispatch and staging management; more efficient utilization of specialized resources through capabilitybased matching; and maintained geographic coverage through distribution-aware optimisation that prevents resource concentration.

[0174] The following detailed description presents preferred but not limiting embodiments of the intelligent emergency resource allocation and dispatch optimisation system module 2. The description proceeds through the major functional components of the system architecture, explaining the data structures, algorithms, integration mechanisms, and operational logic that enable sophisticated multi-dimensional dispatch optimisation.

[0175] The Multi-Dimensional Tactical Resource Database 210

[0176] The foundation of the intelligent dispatch optimisation system is a comprehensive multi-dimensional tactical resource database that maintains detailed real-time capability profiles for each response unit within the emergency response network. Unlike conventional CAD systems that typically track only basic unit identifiers, current assignment status, and static station locations, the multi-dimensional resource database captures and continuously updates multiple independent

[0177] NVSOO IBWO / MAB capability dimensions that collectively define each unit’s operational capabilities and current state.

[0178] In other words, the multidimensional tactical database 210 maintains real-time capability profiles for each response unit in an emergency network. There are database portions with independent dimensions that are assigned to: real-time geographical location with continuous updating of GPS coordinates; inventory of equipment on board; matrix of personnel qualifications; vehicle specifications; and dynamic availability status with estimated time to return to availability for engaged units.

[0179] For instance, inside the database management system there is a location data module 215 that maintains precise real-time geographic positioning information for each response unit, enabling accurate distance calculations, route planning, and positioning awareness.

[0180] The system module 2 continuously receives GPS coordinate updates from mobile data terminals, automatic vehicle location (AVL) systems, or smartphone applications carried by response personnel. GPS coordinates are stored as latitude and longitude decimal degree values with precision of at least six decimal places (approximately 0.1 meter resolution) to enable precise location determination. Update frequency is configurable based on operational requirements and data transmission constraints, with typical implementations employing update intervals between 5 and 30 seconds for moving vehicles and extended intervals (60-300 seconds) for stationary units.

[0181] Beyond static position storage the location module 215 calculates velocity vectors from sequential position updates, determining current speed and direction of travel. Velocity vector data enables predictive positioning that estimates future unit locations based on current movement patterns, improving ETA accuracy for units already in motion when new incidents occur. For example, a unit currently traveling at 45 mph in a northbound direction can be projected forward along its current trajectory to estimate its position at the time a new incident is received, providing more accurate initial distance calculations than static position alone would provide.

[0182] For units not currently tracked via active GPS (such as off-duty personnel or vehicles in maintenance status), the system module database 210 maintains station or base location coordinates representing the last known or default location. When units transition to available status from these locations, the system uses the base location as the initial position for routing calculations until active GPS tracking resumes.

[0183] Location module 215 implements geofencing capabilities that automatically trigger status updates when units cross defined geographic boundaries. Geofences are established around incident scenes, station locations, hospital facilities, and other relevant locations. When a unit’s GPS position crosses a geofence boundary, the system automatically triggers appropriate status transitions. For example, when a responding unit’s position crosses the geofence, boundary surrounding an incident scene (typically defined as a 50-100 meter radius circle centred on the incident coordinates), the system automatically updates the unit’s status from “En Route” to “On Scene” and records the arrival timestamp. Similarly, when a unit departs its

[0184] NVSOO IBWO / MAB station (crossing the station geofence boundary), the system automatically updates status to reflect the departure and begins tracking response travel time.

[0185] The system further maintains historical position data for configurable retention periods (typically 30-90 days), enabling pattern analysis and predictive availability modelling. Historical data analysis identifies common travel patterns, typical duty locations, and routine positioning that can inform predictive models. For example, analysis may reveal that certain units frequently operate in specific geographic zones during particular times of day, information that can be incorporated into availability predictions and resource distribution assessments.

[0186] A database equipment inventory portion catalogues the specific apparatus, tools, medical devices, and specialized equipment available aboard each response vehicle. Equipment inventory directly determines a unit’s capability to perform specific operational tasks and manage particular incident types.

[0187] Medical equipment is categorized according to hierarchical capability levels that correspond to scope -of- practice frameworks and treatment protocols, for instance:

[0188] Basic First Aid Equipment: Entry-level medical supplies including bandages and wound dressings of various sizes, splinting materials for extremity immobilization, supplemental oxygen delivery systems with various flow rates and delivery devices (nasal cannula, non-rebreather masks), basic airway management devices (oral and nasal airways, bag-valve-mask devices), bleeding control supplies (tourniquets, haemostatic dressings), spinal immobilization equipment (cervical collars, backboards) , and patient assessment tools (blood pressure cuffs, stethoscopes, pulse oximeters, thermometers). Basic first aid equipment enables initial patient stabilization and supportive care but does not support advanced interventions.

[0189] Advanced Life Support (ALS) Equipment: Higher-capability medical equipment enabling advanced interventions including cardiac monitors with defibrillation and external pacing capabilities, 12 -lead ECG acquisition for cardiac diagnosis, advanced airway management devices (endotracheal tubes, supraglottic airways, video laryngoscopy, surgical airway supplies), intravenous access supplies and a comprehensive formulary of emergency medications (cardiac drugs, analgesics, sedatives, paralytics, antiarrhythmics), capnography for ventilation monitoring, and automated CPR devices. ALS equipment enables definitive emergency treatment for life-threatening conditions including cardiac arrest, respiratory failure, and shock states.

[0190] Critical Care Equipment: The highest level of pre-hospital medical capability including mechanical ventilators with advanced modes and monitoring, multiple-channel infusion pumps for precise medication delivery, blood product storage and administration capability, point-of-care laboratory testing devices.

[0191] These detailed descriptions serve to illustrate that the equipment inventory directly affects the unit’s operational capacity to manage specific types of events. In line with the lists in the multidimensional tactical database, the inventory may also include specialized tools and specific medical devices, while the personnel qualifications

[0192] NVSOO IBWO / MAB matrix documents training and certifications; and vehicle characteristics describe type and capacity, affecting scene access and transport capacity.

[0193] As previously disclosed, module 2 comprises an incident-specific resource requirements analyser 220 that is as an algorithm that processes incident characteristics to generate required resource profiles. This analyser 220 applies rulebased logic and classification algorithms to incident type, severity indicators, environmental factors and reported hazards to determine required equipment categories, minimum personnel qualification levels, vehicle capacity requirements and resource quantities based on scale and complexity.

[0194] For instance, in case of medical incidents here are the possible resources to be put on field:

[0195] Cardiac arrest — > ALS ambulance with defibrillator, paramedic minimum

[0196] Severe trauma — > Doctor-equipped ambulance preferred

[0197] Multiple casualties — > Calculate number of ambulances needed

[0198] Paediatric emergency — > Unit with paediatric equipment and training

[0199] Fire Incidents:

[0200] Structure fire — > Firefighters with SCBA, ladder truck if multi-story, water supply

[0201] Vehicle fire — > Engine company sufficient, hazmat if electric vehicle

[0202] Wildfire — > Wildland firefighting equipment, air support possible

[0203] High-rise fire — > Specialized ladder equipment, additional personnel

[0204] Law Enforcement:

[0205] Armed suspect — > Armed tactical units only

[0206] Domestic violence — > Units trained in crisis intervention

[0207] Hostage situation — > Specialized negotiation and tactical teams

[0208] Mental health crisis — > Crisis intervention team (CIT) certified officers

[0209] Traffic Accidents:

[0210] Road blockage — > 2 -wheel motorcycles can navigate through stopped traffic

[0211] Highway accident — > Units that can safely access highway

[0212] Extraction needed — > Heavy rescue with extrication tools

[0213] Hazmat involvement — > Hazmat-certified units

[0214] Environmental Constraints:

[0215] NVSOO IBWO / MAB Flooding — > Water rescues capable units

[0216] Mountain / wilderness — > Off-road capable vehicles, possibly air support

[0217] Dense urban — > Small, manoeuvrable vehicles

[0218] Confined space — > Specialized technical rescue

[0219] The above description serves to link the analysis performed by analyser 220 to the objective of improving the appropriateness of dispatch with respect to a purely geographical criterion and integrates with the subsequent ETA and optimisation blocks. As a result, the analyser 220 operates as a generator of constraints and preferences, based on incidental characteristics and implemented policies / criteria, which are then applied to the set of available resources to identify suitable combinations.

[0220] Module 2 includes a traffic and routing integration layer 230 that calculates dynamic ETAs for potentially responding units, based on current traffic conditions and other environmental factors already mentioned. This layer interfaces with live traffic data APIs (Google Maps, Waze, local traffic systems) or with external traffic data sources and routing calculation services, obtaining information on traffic, road closures, weather conditions and other relevant factors. It also describes route optimisation considering current conditions, road closures or construction, routing capacity for emergency vehicles, weather impacts on speed, and traffic patterns related to the time of day.

[0221] The use of traffic-aware ETA is then employed by the multi-factor optimisation algorithm 240 to compare candidates and generate recommended rankings.

[0222] The multi-factor optimisation algorithm 240 integrates incident requirements, resource capabilities and routing intelligence to generate optimised recommendations. The required resource profile is determined according to a predetermined logical sequence; filtering the database to units that meet equipment requirements, personnel qualifications, and vehicle type for scene access; calculating traffic-aware ETA for qualified units; applying optimisation criteria including minimizing response time, multi-unit coordination for synchronized arrivals, balancing geographical coverage, and matching specialization to the case; generating a recommended list sorted with supporting rationale.

[0223] This structure implies that the result is not a single output, but rather an ordered set of recommendations, accompanied by reasons associated with each suggested unit. The coverage balancing component is a concentration prevention and geographical coverage maintenance, while the multi-unit coordination component is a preference for units with similar ETAs when coordinated arrival is required.

[0224] The set of factors may be considered a “sophisticated optimisation criteria”, with the aim of aligning capacity and requirements and reducing response times.

[0225] Module 2 also includes a cascading resource logic block 250 for complex incidents requiring multiple types of resources. This logic block 250 is provided for determining

[0226] NVSOO IBWO / MAB optimal combinations of fire, medical, law enforcement and specialized resources based on requirements, coordinating arrival sequences (e.g., scene security before deploying vulnerable resources) , managing staging locations for secondary units and applying escalation protocols that add resources based on the development of the incident.

[0227] For instance, in case of complex incidents requiring multiple resource types, the assigned resources could be the following:

[0228] Fire with injuries — > Firefighters + ambulances, coordinate arrival

[0229] Armed robbery in progress — > Armed police + ambulance on standby at safe distance

[0230] Multi-vehicle accident with fire — > Firefighters + multiple ambulances + police for traffic control + heavy rescue if needed

[0231] Building collapse — > Fire / rescue + multiple ambulances + hazmat + utilities + structural engineer

[0232] These examples are just provided to illustrate the intent of the cascade logic: not only to select individual units but to compose coordinated groups and define delivery and staging methods based on security, complexity, and development.

[0233] Module 2 includes also the automated dispatch briefing generator 260 that creates a structured tactical briefing for dispatched units.

[0234] We may list the following possible content: incident summary with classification and severity, key facts, number and type of patients / victims and hazards; location intelligence with coordinates, address, access considerations and landmarks; tactical recommendations on suggested routes, scene safety, equipment to prepare and immediate priorities upon arrival; and resource coordination details including other deployed resources, ETA, command structure and communication channels.

[0235] The briefing, as described, summarizes accident data and recommendations in a format intended for operational use in the field. It is consistent with the database 210 and with selection / optimisation of analyser 220, in the sense that it uses location and hazard data and integrates with the idea of coordinated multi-unit dispatch through ETA indication and command structure.

[0236] System creates structured mission brief containing at least: incident summary with classification and severity, key facts extracted from call analysis, number and type of patients / victims, scene hazards identified, location intelligence with precise coordinates, address and cross-streets, access considerations, nearby landmarks; tactical recommendations, suggested approach route, scene safety considerations, equipment to prepare “en route”, actions to perform immediately upon arrival, coordination requirements with other units, expected arrival times, command structure and communication channels.

[0237] Finally, module 2 includes a multi-channel briefing delivery system 270 that transmits briefings through multiple pathways, including mobile data applications

[0238] NVSOO IBWO / MAB (preferred), SMS / text (backup), integration with radio voice dispatch, in-vehicle computer systems, and wearable notifications.

[0239] This function is aimed at ensuring delivery reliability across different platforms and redundancy with respect to single channel failures.

[0240] It should be noted that this component can be part of module 2, which can also operate with manual input. In this way, the dispatch system does not necessarily depend on a call intelligence system but can receive the incident and produce recommendations and briefings, delivering them across multiple channels.

[0241] Let’s now consider the structure and functioning of another independent system module named Integrated Bidirectional Emergency Response System that may be considered an optional parallel pipeline and dispatch readiness at the end of the call.

[0242] Module 3

[0243] This integrated bidirectional system may be described as an architecture that, compared to sequential flows, simultaneously initiates call intelligence analysis and dispatch optimisation at the start of the call.

[0244] In other words, this further module implements a method where different stages of a process are executed concurrently across multiple devices, such as different layers of module 1 and module 2 to form a pipeline.

[0245] During the call, a bidirectional flow of intelligence is achieved: classification updates narrow the resource search space; location extraction enables ETA calculation; severity updates influence resource quantities. At call completion, recommendations are ready without delay between call end and dispatch decision, with dispatch execution described as “one-click”.

[0246] The system implements a “parallel processing” that produces as technical effect the elimination of dispatch latency attributed to the sequential architecture of known systems and the enabling of immediate resource deployment at call completion.

[0247] Furthermore, the integration achieves a ‘unified intelligence model’ and a result that ‘exceeds the sum’ of the capabilities of the independent modules 1 and 2, thanks to real-time interactions between classification, location, severity, and dispatch decisions.

[0248] To implement these features the parallel processing module employs two functionally independent software engines that we may identify as a call intelligence engine and a dispatch engine which could be coupled to one of the previously disclosed modules 1 or 2 to obtain a shared data model.

[0249] FIG. 5 illustrates the bidirectional communication maintenance module connecting an emergency reporter, the system, and a dispatch center. Communication is bidirectional and persistent, as indicated by the arrows.

[0250] NVSOO IBWO / MAB Reporter unit 301 initiates a report via a communication app. Upon receipt, the intelligent interactive validation module 302 automatically sends validation questions or evidence requests 303. The reporter unit 301 provides a reply 304.

[0251] Simultaneously, validated data forms a structured incident report 305 presented to a dispatcher 306. The dispatcher 306 can actively communicate with the reporter unit 301 via an integrated bidirectional messaging interface 307, sending status updates & safety instructions 308, or requesting real-time intelligence updates 309.

[0252] Reporter unit 301, receiving these, can provide an ongoing situational update 310. This loop continues throughout the response, transforming the reporter into an active tactical asset.

[0253] The shared data model is configured as a sort of unified structure consumed by both engines. It includes classification fields with real-time updates, sub -classification, confidence score and probability alternatives; location fields with coordinates, precision level and access information; severity assessment; derived resource requirements; timeline; and special considerations.

[0254] This structure is the basis for the consistent use of the same data throughout the incident cycle, from call to resolution, contributing to a “single incident record’.

[0255] Within this structure, the whole system 100 specifically links: the classification produced by the call intelligence engine and used by the dispatch engine; the location extracted from the call intelligence engine and used for ETA and routing; severity generated and used for resource quantities; and special considerations to inform tactics.

[0256] As a result, the data model acts as an internal interface between conversational analysis and dispatch optimisation, supporting incremental updates during the call.

[0257] The integrated system of further optional module is configured for tracking outcomes to improve both engines. The following strands are described: response time analysis comparing predicted and actual ETAs and identifying inaccuracies; resource adequacy tracking to assess the sufficiency and appropriateness of resources and additional on-scene requests; call quality assessment on classification accuracy and critical information gathering; and machine learning enhancement using historical data to improve classification algorithms, resource requirement prediction, and question prioritisation logic.

[0258] This part defines a closed loop between input (call and dispatch) and output (operational results) , making it clear that outcome data is reused to refine models and logic.

[0259] In this manner, the system of the present disclosure is not limited to producing recommendations at the moment, but maintains a mechanism of continuous learning / refinement, while remaining within the scope of what is stated (without introducing additional parameters).

[0260] NVSOO IBWO / MAB Let’s consider for example an operational use case, an emergency call is received by a call-taker; the system simultaneously initiates conversation analysis and resource optimisation in module 1.

[0261] During the call, the continuous analysis module 1 produces speech-to-text and updates the incident classification with a confidence score, as well as severity assessment and priority scores.

[0262] The dynamic protocol generator 50 applies SOPs and identifies mandatory information fields, then compares what has been collected with what is missing and generates a ranked list of “next-best” questions, which are presented to the call-taker via a contextual prompt interface 90.

[0263] In parallel, the dispatch engine of the optional module uses incident requirements and the multidimensional dynamic resource database to filter units and calculate traffic-aware ETAs specific to the resource’s vehicle type, applying multi-factor optimisation and, if necessary, cascade logic for multi-resource combinations.

[0264] During the call, when the location is extracted and structured, it enables route and ETA calculation; when the severity is updated, it can determine adjustments in the quantity or type of resources; when the classification becomes more certain, it narrows the search space.

[0265] At the end of the call, recommendations are ready and a tactical briefing can be generated and transmitted via multiple channels 270, including mobile data applications and backup channels. The incident is documented in a structured summary and a unified record, and outcomes can be tracked for continuous improvement according to the feedback loop previously described.

[0266] The system and method of the present disclosure are applicable in automated emergency services contexts and in emergency communication centres that handle calls and dispatch resources.

[0267] The Real-Time Call Intelligence System can be deployed in operations centres without modifications to existing dispatch systems, as it operates independently of dispatch functions and provides value through greater consistency in information acquisition, reduction of missed critical questions, acceleration of training, and standardisation of incident documentation. This profile makes Module 1 applicable as an incremental component in existing operational infrastructures.

[0268] The Context-Aware Emergency Dispatch Optimisation System can operate independently of call-taking, receiving incident data entered manually from traditional systems. This feature makes Module 2 industrially adoptable even in organisations that do not intend to immediately modify the call reception phase but wish to improve dispatch appropriateness, reduce response times through traffic- aware ETAs, and optimise resource utilisation by matching capacity and requirements.

[0269] The use of a multidimensional database 210 and structured tactical briefings with multi-channel delivery 270 provides an operational system that can be integrated with

[0270] NVSOO IBWO / MAB existing infrastructure, as described (including radio integration and in-vehicle computer systems).

[0271] In an integrated deployment, the Integrated Bidirectional Emergency Response System of the optional module is applicable where the elimination of latency between call end and dispatch is desired, thanks to parallel processing between call intelligence and dispatch optimisation and a shared data model that allows bidirectional exchange of updates during the call.

[0272] The previous disclosure links integration to zero-delay dispatch readiness, call completion and a unified incident record, as well as an outcome data-based feedback loop to improve classification performance, requirement prediction and routing. As a result, the system is industrially applicable as a modular architecture that supports both gradual adoption and integrated end-to-end implementations in the emergency response domain.

[0273] FIG. 6 is a flowchart illustrating further features of a computer-implemented method for internet-based emergency reporting according to an embodiment of the present invention. The method depicts the end-to-end automated process from report initiation to dispatch.

[0274] The process begins at step 401, where a user or reporter initiates an emergency report via an authenticated internet-based communication channel on a user device. The report comprises at least one of the following items: text, location data, and multimedia evidence.

[0275] In step 402, the report is received by an internet-based communication channel integration layer. This layer standardizes the data from diverse channels, extracting user identity, message content, and metadata.

[0276] An incident validation process 403 comprises steps 403a to 403d. In step 403a, a multi-modal incident validation engine performs linguistic and semantic analysis on the report text to detect emergency language, classify the incident type, and identify fraud linguistic patterns.

[0277] In step 403b, the engine performs multi-source cross-verification on the location data. It aggregates and compares location information from multiple independent sources (e.g., user-shared location, device GPS, multimedia metadata) and generates a location confidence score based on their consistency.

[0278] In step 403c, the engine performs authenticity verification and content analysis on multimedia evidence. This includes executing a reverse image search, analyzing metadata consistency, performing digital forensics, and using computer vision to identify emergency-relevant objects.

[0279] In step 403d, an integrated fraud detection algorithm calculates a real-time fraud risk score for the report based on a weighted multi-factor model (identity, linguistic, location, multimedia, behavioral factors), determining the subsequent processing path.

[0280] NVSOO IBWO / MAB Step 405 represents the optional operation of an intelligent interactive validation module. Based on preliminary analysis, it can dynamically generate validation questions or specific evidence requests, with user responses incorporated into the incident data record.

[0281] In step 406, upon report completion or when sufficient confidence is reached, the system generates a structured emergency incident report based on the validation results and collected evidence.

[0282] Finally, in step 407, the structured report is transmitted to a dispatcher or an external emergency dispatch system (e.g., a Computer-Aided Dispatch (CAD) system or an Emergency Operations Center (EOC)) via an API within an emergency dispatch integration pipeline, thereby completing the seamless integration from the internetbased report to actual response resources.

[0283] Example

[0284] Let’s consider a practical example wherein the optional module is integrated with the other modules 1 and 2 to form a whole integrated system 100 according to the present disclosure.

[0285] TIME: 00:00 EMERGENCY CALL RECEIVED

[0286] Call connects

[0287] The UNIFIED INCIDENT INTELLIGENCE DATA MODEL, that is shared by both engines forwards the call into the CALL INTELLIGENCE ENGINE of module 1 and in parallel to DISPATCH OPTIMISATION ENGINE of module 2.

[0288] TIME: 00: 15 (15 seconds into call)

[0289] CALL ENGINE STATUS: DISPATCH ENGINE STATUS:

[0290] Updates updates

[0291] Speech-to-text: “Help! Fire in my Incident classification: FIRE apartment building...” Confidence: 65% (preliminary)

[0292] Preliminary Classification: Resource search initiated:

[0293] FIRE (confidence 65%) Filtering fire units

[0294] Awaiting location for ETA calc

[0295] Prompting call-taker:

[0296] “ What floor is the fire on?” STATUS: Standby for location “Is anyone trapped?”

[0297] NVS001BWO / MAB TIME: 00:45 (45 seconds into call)

[0298] CALL ENGINE UPDATE: DISPATCH ENGINE UPDATE:

[0299] Location extracted: Location received!

[0300] “456 Oak Street, 3rd floor 40.7589° N, 73.9851° W

[0301] Classification refined: ETA calculations running:

[0302] STRUCTURE FIRE (confidence 85%) Engine- 5: 5 min

[0303] Multi- story building Engine-8: 6 min

[0304] Ladder- 2: 7 min

[0305] New information:

[0306] “People trapped on 3rd floor” RESOURCES UPDATED:

[0307] Added: Heavy Rescue

[0308] Severity: CRITICAL Added: 2* ALS Ambulances

[0309] Prompting call-taker: Optimisation in progress...

[0310] “How many people trapped?” Coordinating multi-unit arrival

[0311] “Is fire spreading?”

[0312] TIME: 01:30 (90 seconds into call)

[0313] CALL ENGINE STATUS: DISPATCH ENGINE STATUS:

[0314] Information gathering complete: DISPATCH PLAN READY:

[0315] Incident Summary Generated: Recommended Units:

[0316] - / Type: Structure fire 1. Engine-5 (ETA 5min) Location: 456 Oak St, 3rd floor 2. Engine-8 (ETA 6min)

[0317] - / Severity: Critical 3. Ladder-2 (ETA 7min)

[0318] - / Victims: 2 people trapped 4. Rescue- 1 (ETA 8min)

[0319] - / Hazards: Fire spreading up 5. Ambulance-7 (ETA 6min)

[0320] 6. Ambulance- 15 (ETA 9min)

[0321] Call-taker has all needed info 7. Battalion Chief-3 (ETA 6min)

[0322] NVS001BWO / MAB Ready to conclude call Tactical briefings generated

[0323] Ready for ONE-CLICK DISPATCH

[0324] TIME: 01:45 CALL ENDS

[0325] DISPATCHER INTERFACE dispatches to all units with a single click dispatch to all seven pre-selected and briefed units with one click.

[0326] TIME: 01:46 ALL UNITS DISPATCHED SIMULTANEOUSLY

[0327] With briefings delivered to all units via:

[0328] • Mobile data terminals

[0329] • Smartphones

[0330] • Radio

[0331] • Station alerting systems

[0332] To summarize this example:

[0333] TIME: 00:00 - Incoming Call received

[0334] | - ► Call Intelligence Engine analysing

[0335] I - ► Dispatch Engine preparing (IN PARALLEL)

[0336] TIME: 01:45 - Call ends

[0337] TIME: 01:46 - Units dispatched ◄ - 1 SECOND LATER!

[0338] TOTAL TIME FROM CALL TO DISPATCH: 1 minute 46 seconds

[0339] DELAY AFTER CALL COMPLETION: 1 second ◄ - 119 seconds saved if compared with other known sequential solutions.

[0340] CRITICAL ADVANTAGE: 2 -minute improvement in time-critical emergencies where minutes means lives.

[0341] Further Examples

[0342] Five further application examples are provided as follows.

[0343] First Example: Emergency Reporting During Natural Disasters with Voice Infrastructure Failure

[0344] NVS001BWO / MAB In a catastrophic event such as an earthquake or hurricane, traditional circuit- switched voice networks often suffer from physical damage or severe congestion. However, IP-based data connectivity, including local WiFi hotspots, cellular data (LTE / 5G), or Low Earth Orbit (LEO) satellite internet (e.g., Starlink), frequently remains functional. In this embodiment, a user in a disaster zone, unable to complete a voice call, initiates an emergency report via an authenticated messaging platform. The Gateway receives the data-only transmission and utilizes the multi-source location cross-validation system to pinpoint the survivor’s coordinates by correlating device GPS, WiFi positioning, and metadata from sent images, ensuring rescue teams are dispatched to the precise location despite the voice network blackout.

[0345] Second Example: Silent Reporting in High-Danger Situations

[0346] There are scenarios were speaking aloud would place the reporter in immediate peril, such as during a home invasion, a hostage situation, or an incident of domestic violence. In such cases, the system enables the victim to communicate silently through an internet-native messaging interface. Beyond passive receipt of text, the Gateway’s interactive validation system engages the user with discrete, dynamic questions (e.g., “Is the suspect armed?”, “Are you in a locked room?”). This allows for the collection of critical tactical intelligence without alerting the perpetrator, while the Al-assisted multi-modal engine validates the urgency of the situation based on the linguistic patterns of the chat.

[0347] Third Example: Multimedia- Driven Medical Triage and Resource Allocation

[0348] Traditional emergency reporting often lacks the visual data necessary for accurate medical triage. In a medical emergency, a bystander can use the system to transmit high-definition video or photos of a patient’s symptoms (e.g., respiratory distress or physical trauma). The multimedia evidence authentication and content analysis module processes the visual data in real-time. For instance, by analyzing the patient’s breathing rate or skin pallor in a video, the Al engine can recommend a specific level of response, such as suggesting an Advanced Life Support (ALS) ambulance instead of a Basic Life Support (BLS) unit. This transforms unstructured visual evidence into actionable operational recommendations for the dispatcher.

[0349] Fourth Example: Mitigation of Fraudulent Reporting and Prank Calls

[0350] Text-based reporting systems are historically vulnerable to “swatting” or fraudulent reports due to a lack of authentication. The system of the present application addresses this by implementing a multi-factor fraud detection process. If a user submits a report of a major fire using a recycled image from the internet, the system’s reverse image search and digital forensics modules will immediately flag the media as non-original or manipulated. Furthermore, the system analyzes the reporter’s identity trust score and location feasibility (e.g., checking if the reported fire location matches the user’s IP geolocation). If the fraud risk score exceeds a specific threshold, the incident is flagged for secondary review, preventing the unnecessary diversion of emergency resources.

[0351] Fifth Example: Overcoming Language Barriers in International Emergencies

[0352] NVSOO IBWO / MAB In situations involving foreign tourists or non-native speakers, voice communication often fails due to language barriers. By utilizing an internet-native gateway, the system allows reporters to submit information in their native language via messaging platforms. The integration layer can utilize Natural Language Processing (NLP) to perform real-time translation of the text for the local emergency dispatcher.

[0353] Simultaneously, the dispatcher’s instructions can be translated back into the reporter’s language. This bidirectional, text -based communication ensures that lifesaving instructions — such as CPR guidance or evacuation routes — are accurately understood and followed regardless of the language spoken by the victim. All in all, the invention provides an authenticated internet-based emergency reporting gateway with multi-modal validation, multimedia authenticity verification, fraud detection, interactive evidence gathering, structured incident packaging, and dispatch-side integration.

[0354] NVSOO IBWO / MAB

Claims

CLAIMS1. A computer-implemented method for Al- Assisted Emergency Response in automated emergency services systems wherein a real-time analysis of an active emergency call is performed, comprising:- implementing real-time speech-to-text conversion of an acoustic signal of the active emergency call;- performing, concurrently with the active emergency call, classification of an incident with confidence scoring of the active emergency call after being transcribed, assigning the incident to at least one category from a set of predefined categories;- dynamically generating sequences of questions for a caller tailored to specific incident characteristics;- suggesting specific questions that a call-taker should ask the caller; and- dynamically updating the questions as call-taker receives answers from the caller.

2. The method according to claim 1, further including:- determining an incident severity level;- continuously updating the severity level as new information is received from the speech-to-text conversion;- calculating a priority score based on the severity level and confidence score; and- providing the priority score to a dispatch queue management system.

3. The method according to claim 1, wherein the step of performing, concurrently with the active emergency call, classification of an incident is continuously executed in a parallel processing pipeline, enabling simultaneous dispatch resource optimisation without waiting for the active emergency call to end.

4. The method according to claim 1, wherein questions addressing critical mandatory information fields are ranked higher than questions addressing supplementary information, ensuring that essential information is collected first and that dispatch can proceed even if the call is prematurely terminated.

5. A system for continuous analysis of incidents during active calls, comprising:- a processing module (20) configured to operate during an active call in progress,- a speech-to-text conversion unit configured to perform real-time transcription of audio content of the active call producing a text transcript,- a classification unit configured to perform concurrently with the active call incident classification based on the text transcript assigning the incident to at least one category from a plurality of predefined categories,NVSOO IBWO / MAB- a confidence score generator associated with the classification unit configured to calculate a confidence score for each assigned category,- a severity evaluator configured to determine a severity level of the incident and to update the severity level continuously as new information is received from the text transcript,- a priority score calculator configured to calculate a priority score based on the severity level and the confidence score, and an integration interface configured to provide the priority score to a dispatch queue management system.

6. The system according to claim 5, wherein the plurality of predefined categories comprises at least medical emergency, fire incident, law enforcement, and traffic accident.

7. A computer-implemented method for optimising the dispatch of incident response resources, comprising:- storing, in a tactical database, a plurality of resource records, each resource record comprising selected multidimensional attributes from a group including available equipment, assigned personnel, vehicle type, and current operational status;- receiving incident data relating to an incident;- determining incident-specific resource requirements based on the received incident data;- acquiring real-time traffic data;- calculating, for each resource of the plurality of resource records, a traffic-aware estimated time of arrival (ETA) to an incident location;- evaluating a plurality of candidate resources based on the incident-specific resource requirements, the multidimensional attributes, and the traffic-aware ETAs;- selecting, using a multi-factor optimisation engine, at least one optimal resource for coordinated dispatch;- automatically generating a tactical briefing comprising information relating to the incident and the selected resource;- transmitting the tactical briefing through a plurality of communication channels.

8. The method according to claim 7, wherein said receiving incident data also comprises receiving incident data by manual input independently of a call-taking system.

9. The method according to claim 7 wherein said plurality of communication channels includes at least two channels selected from a group consisting of text messages, push notifications, radio communications, and web interfaces.NVSOO IBWO / MAB10. A dispatch optimisation system for matching incident response resources, comprising:- a tactical database configured to store a plurality of resource records, each resource record comprising selected multidimensional attributes;- a requirements analysis module configured to receive incident data relating to an incident and determine incident-specific resource requirements based on the received incident data;- an estimated time of arrival (ETA) computation module configured to acquire realtime traffic data and calculate, for each of the plurality of resource records, a traffic- aware ETA to an incident location;- a multi-factor optimisation engine configured to evaluate a plurality of candidate resources based on the incident-specific resource requirements, multi-dimensional attributes, and traffic-aware ETAs, and select at least one optimal resource for coordinated dispatch;- a tactical briefing generator configured to automatically generate a tactical briefing comprising information relating to the incident and the selected resource and transmit the tactical briefing through a plurality of communication channels; wherein the requirements analysis module is configured to receive incident data via manual input independently of a call-taking system.

11. The dispatch optimisation system according to claim 10, wherein said selected multidimensional attributes are from a group including available equipment, assigned personnel, vehicle type, and current operational status.

12. The dispatch optimisation system according to claim 10, wherein said ETA calculation module is configured to dynamically update traffic-aware ETAs based on changes in real-time traffic data and vehicle type.

13. A computer-implemented method for internet-based emergency reporting, comprising: receiving, via an internet-based communication channel integration layer, an emergency report from a user device of a reporter via an authenticated internet -based communication channel, the report comprising at least one of text, location data, and multimedia evidence; performing, by a multi-modal incident validation engine, real-time multi-modal validation on the emergency report, including performing linguistic and semantic analysis on the text to classify an incident and detect fraud, performing multi-source cross-verification on the location data to generate a location confidence score, and performing authenticity verification and content analysis on the multimedia evidence; generating a structured emergency incident report based on validation results; andNVSOO IBWO / MABtransmitting the structured emergency incident report to a dispatcher or emergency dispatch system.

14. The method of claim 13, wherein performing multi-source cross-verification on the location data comprises aggregating and comparing at least two independent location sources selected from: a user-shared location, a device-based location, geotags from multimedia metadata, and location clues extracted from visual analysis of multimedia content.

15. A system for internet -based emergency reporting, comprising: an internet-based communication channel integration layer configured to receive emergency report data from a reporter through a plurality of authenticated internetbased communication channels; a computer-implemented multi-modal incident validation engine communicatively coupled to the integration layer and configured to perform real-time multi-modal validation and analysis on the report data to generate validation intelligence; an emergency dispatch integration pipeline configured to generate a structured emergency incident report based on the validation intelligence and to transmit the report to a dispatcher or emergency dispatch system; and a bidirectional communication maintenance module configured to maintain persistent bidirectional communication between the reporter and the dispatcher.NVSOO IBWO / MAB

Images