An intelligent emergency call method and system

Abstract

This invention discloses an intelligent emergency call method and system, applicable to any user group in an emergency situation, including the elderly, women living alone, and patients with chronic diseases. It can run on various smart terminals such as smartphones, smartwatches, and smart bracelets. After a user triggers the call with one click, the system uses a multi-round cyclic dialing strategy to dial multiple emergency contacts sequentially, with subsequent rounds only dialing those who did not answer. Accurate answer determination is achieved by obtaining the actual call duration (zero indicates no answer). Simultaneously, it automatically integrates the GPS reverse geocoding address with the user's health record into a structured emergency call notification message and sends it. The entire process includes voice guidance, and all interactive nodes employ a countdown default continuation mechanism to ensure the process is not interrupted due to user inability to operate. This invention solves the three major defects of existing technologies: slow response, frequent misjudgments, and incomplete information. The entire process is triggered with one click and executed automatically.

Description

Technical Field

[0001] This invention relates to the fields of mobile communication and emergency rescue technology, specifically to an intelligent emergency call method and system deployed on a smart terminal. This method, upon triggering an emergency call by a user, automatically executes multi-contact, multi-round cyclic dialing, precise answer determination based on actual call duration, and pushes an integrated emergency call notification message combining location and health information. The entire process includes voice guidance, delivering complete emergency information to the rescuer in the shortest possible time. This invention is applicable to any user group that may be in an emergency situation, including the elderly, women living alone, outdoor adventurers, and patients with chronic diseases. This invention can run on any smart terminal device with call and notification capabilities, such as smartphones, tablets, smartwatches, smart bracelets, and in-vehicle terminals, and can also be implemented as a dedicated emergency call hardware device. Background Technology

[0002] With the increasing prominence of emergency assistance needs among various vulnerable groups in modern society, the reliability, information integrity, and dialing efficiency of one-click emergency call technology have become pressing technical issues that need to be addressed. Elderly people (especially those living alone or in empty nests) may be unable to perform complex operations due to falls, acute illnesses, or loss of consciousness; women living alone need to quickly and discreetly trigger emergency calls when facing threats to their personal safety; patients with chronic illnesses need to simultaneously transmit crucial medical information such as their medical history to rescuers when their condition suddenly worsens; and groups engaging in outdoor adventures or traveling alone also require reliable location tracking and the ability to notify multiple contacts when encountering accidents. The common needs of these groups are: simple triggering, reliable calls, complete information, and rapid contact response.

[0003] The existing technical solutions have the following three core defects:

[0004] Existing one-button alarm devices typically only dial a single preset number, and the distress call fails if the other party does not answer. These devices lack the ability to simultaneously transmit the user's real-time location, chronic medical history, current medication list, and other health information to the rescuer. Furthermore, users must carry additional hardware, which is prone to issues such as forgetting to use it or insufficient charging, thus limiting reliability.

[0005] The emergency call functions built into mainstream smartphones (including emergency dialing on Android and SOS on iOS) have the following shortcomings: First, they only support dialing a single public emergency number (such as 120 or 110), which consumes public rescue resources when they are scarce; second, they lack the ability to automatically dial multiple private emergency contacts; third, they do not have the ability to integrate user health records, current medications, and precise location information into the emergency call notification and send it automatically; and fourth, there is no automatic redial mechanism when the other party does not answer.

[0006] The technical shortcomings of existing emergency call applications are concentrated in the following three aspects: First, the dialing efficiency is low: the common strategy is to "exhaustively dial one person at a time"—contact A is dialed repeatedly to the maximum number of times before contact B is dialed. When there are multiple emergency contacts, the contacts at the back of the queue have to wait a long time (e.g., if there are 3 contacts, each dialing 3 times, each time taking about 1 minute, contact C has to wait about 6 minutes) before receiving the first call notification, which seriously delays the rescue response time.

[0007] Secondly, the call answering determination is inaccurate: Existing technology uses the duration of the call as the basis for answering judgment—if the terminal's busy call lasts for more than a preset threshold (usually 30-40 seconds), it is considered that the other party has answered. However, the busy call state of a smart terminal is triggered the moment an outbound call is initiated, and its timing includes the complete ringing waiting time. Since the ringing timeout duration varies significantly among different operators (ranging from 25 to 65 seconds), this method will misjudge a large number of unanswered calls that "automatically hang up after ringing timeout" as answered, causing the automatic redial mechanism to fail to trigger correctly.

[0008] Third, the distress call information is incomplete: the existing solution lacks the ability to integrate, automatically arrange and push the user's health record (chronic disease history, current medication list, recent vital sign record) with real-time GPS location information to the rescuer, so that the rescuer cannot understand the complete health status of the person being rescued before arriving at the scene, which affects the efficiency of rescue decision-making.

[0009] In summary, existing technologies have significant shortcomings in three key dimensions: dialing efficiency, accuracy of call answering, and completeness of distress information, necessitating a new technical solution to address these issues. Summary of the Invention

[0010] I. The technical problem solved by this invention This invention addresses the three core deficiencies of the aforementioned background technology by providing an intelligent emergency call method and system, aiming to solve: (1) The problem of low dialing efficiency in scenarios with multiple contacts; (2) The problem of inaccurate answer determination method based on the duration of busy call status; (3) The problem of missing health records and accurate location information in distress calls. Technical solution

[0011] This invention employs a multi-round cyclic dialing strategy to replace the existing exhaustive dialing method. The specific steps of the multi-round cyclic dialing strategy are as follows: Round 1: Make one call to each of the contacts in the preset emergency contact list, the dialing method including sequential dialing or concurrent dialing; Round N (N≥2): Only initiate dialing for contacts who were determined not to answer in the previous N-1 rounds; Stop when any of the following conditions are met: (a) all contacts have answered; (b) the preset maximum number of rounds has been completed.

[0012] A preset waiting interval is set between two adjacent rounds. By taking advantage of the fact that continuous calls within a short period of time can break through the limitations of the Do Not Disturb (DND) mode of smart terminals, the arrival rate of emergency calls is improved.

[0013] After each call ends, this invention queries the call history data maintained by the smart terminal's operating system to read the call duration recorded by the operating system, and uses the call duration as the basis for determining whether to answer the call. When the operating system records a call duration of zero, it determines that the other party did not answer the call; When the operating system records a call duration greater than zero, it determines that the other party has answered and the call has ended.

[0014] The technical basis for the above determination method is that the call history data of the smart terminal operating system only calculates the actual call duration from the time the other party answers to the end of the call, and does not include the ringing waiting time from the time the outbound call is initiated until the other party answers or the call is automatically disconnected. Therefore, for unanswered calls that are automatically disconnected after the ringing timeout, the operating system records the call duration as zero, regardless of the difference in ringing timeout duration between operators.

[0015] Furthermore, when call history data query is unavailable (e.g., due to unauthorized access or system malfunction), the present invention automatically downgrades to a conservative threshold determination method based on the duration of the busy call status. The conservative threshold is not less than 90 seconds, preferably ranging from 90 to 120 seconds, which is higher than the threshold setting of the prior art, in order to reduce the risk of misjudgment and ensure the basic availability of the system when call history data cannot be accessed.

[0016] When a distress call is triggered, this invention automatically performs the following information collection and integration operations in parallel: (1) Obtain the current GPS coordinates of the smart terminal and call the reverse geocoding service to convert the coordinates into readable address text containing province, city, district and street; (2) Extract the user's chronic disease history list, current medication list, and most recent vital sign record (including blood pressure, blood sugar, heart rate and recording time) from the data storage; the data storage can be local storage, cloud storage or a hybrid local and cloud storage, and the present invention does not limit the storage architecture; (3) Arrange the above address information, health record information, user basic information (name, age, gender), and symptom description (if any) into a distress call message content according to a preset structured template; (4) Automatically send the above-mentioned distress notification message to all emergency contacts during the call process. The distress notification message can be sent in at least one of the following ways: Short Message Service (SMS), mobile application push notification, instant messaging; when sent via Short Message Service and the message text length exceeds the character limit of a single SMS message, it is automatically sent in segments.

[0017] The operation of sending an emergency notification message to a contact who has answered the call can be performed during the call or after the call ends; the present invention does not limit the timing of the sending. Beneficial effects

[0018] (1) The multi-round cyclic dialing strategy ensures that all emergency contacts can receive a call notification in the first round. Compared with exhaustive dialing, the waiting time for the last contact to receive the first call is reduced by 1−1 / M (M is the maximum number of rounds). When M=2, it is reduced by 50%, and when M=3, it is reduced by about 67%, which significantly improves the speed of rescue response.

[0019] (2) The answering method based on the call duration recorded in the operating system call history data significantly reduces the probability of misjudgment caused by the difference in the ringing timeout duration of the operator compared with the answering method based on the duration of the busy call state, and fundamentally ensures the correct triggering of the redial mechanism.

[0020] (3) The automatic integration of health records and location information allows rescuers to obtain the complete health background of the person being rescued at the same time as receiving a call or distress notification, without requiring any additional operation from the user, and with zero operational burden throughout the process.

[0021] (4) The entire emergency call process only requires one trigger operation. Subsequent dialing, retrying, and notification sending are all executed automatically, and the entire process is accompanied by voice prompts, making it suitable for users with limited cognitive abilities or under high pressure and tension.

[0022] (5) This invention can be used in various smart terminal forms such as smartphones, tablets, smartwatches, smart bracelets, and vehicle terminals, and can also be deployed in the form of dedicated emergency call hardware devices, thus having wide applicability.

[0023] (6) When the emergency contact list is empty or all contacts do not answer, the system will automatically guide the user to dial the preset backup number (including public emergency number or other emergency rescue number), and, provided that local communication policies allow, attempt to send a distress text message after the call ends, forming a complete rescue link of "private contacts first + backup number protection", avoiding the extreme situation where the distress call fails completely due to all private contacts not responding.

[0024] (7) All interactive nodes in the distress call process that require user confirmation adopt a countdown default continuation mechanism. When the user does not respond due to loss of consciousness or inability to operate, the system will automatically continue execution according to the option most conducive to rescue, so as to ensure that the process is not interrupted due to waiting for user input to the greatest extent. Attached Figure Description

[0025] Figure 1 This is a diagram of the overall system architecture of the present invention.

[0026] Figure 2 This is a flowchart of the multi-contact, multi-round cyclic dialing strategy of the present invention.

[0027] Figure 3 This is a flowchart illustrating the call answering determination process based on operating system call history data, as described in this invention.

[0028] Figure 4 This is a flowchart illustrating the content structure and generation process of the distress call notification message of the present invention.

[0029] Figure 5 This is a sequence diagram of the overall system call of the present invention.

[0030] Figure 6 This is a schematic diagram of the cross-platform deployment architecture of the present invention.

[0031] Figure 7 This is a schematic diagram of the countdown interactive state transition of the present invention.

[0032] Figure 8 This is a schematic diagram of the cloud-based collaborative deployment architecture of the present invention. Detailed Implementation

[0033] Implementation Method 1: Multi-Contact, Multi-Round Cyclic Dialing Strategy See Figure 1 , Figure 2 The rotary dialing module of the present invention obtains an emergency contact list from the user database, with a maximum number of rounds of M (preferably M=3) and an interval of T seconds between adjacent rounds (preferably T=5 seconds).

[0034] During initialization, all contacts are marked as "not answered". In the first round, the system initiates outbound calls to each contact. These calls can be made sequentially (calling each contact one by one) or concurrently (calling multiple contacts simultaneously and then connecting them sequentially, for example, using VoIP capabilities; this can also be achieved in scenarios with limited cellular resources). After each call, the answer determination module (see Implementation Method 2) determines the answer status. The answerer immediately enters the call processing flow, while those who did not answer remain in the candidate list for subsequent rounds. After the first round, if there are still unanswered contacts and the maximum number of rounds has not been reached, the system waits T seconds before starting the second round, only re-calling the unanswered contacts, and so on.

[0035] When a contact answers the call, the user speaks directly with that contact. After the call ends, the system automatically sends an SOS notification message to that contact (see Implementation Method 3 for details).

[0036] When a contact is initially identified as not answering, the system immediately sends them an SOS notification message to ensure they are aware of the emergency as soon as possible, increasing the likelihood of them calling back. If the contact still does not answer in subsequent rounds, the notification will not be sent again. After all rounds have been completed, the system performs a fallback check to ensure that all unanswered contacts have received the SOS notification message.

[0037] Furthermore, during any outbound call, the user can actively end the current call by hanging up on the SOS interface. Upon detecting the user's active hang-up, the system immediately sends an SOS notification message to that contact (if it hasn't been sent yet), and then automatically proceeds to the next contact's dialing process, requiring no additional user intervention. This mechanism allows users to proactively skip the current contact while waiting for the other party to answer, accelerating the overall progress of the dialing process.

[0038] In the above process, when any contact answers the call in any round, the system will provide the user (if conscious) with a confirmation option on whether to continue calling the other unanswered contacts. If there is no response after a timeout, the call will automatically continue, in order to deal with the scenario where the user has already received help from the contact who answered the call.

[0039] In the aforementioned multi-round cyclic dialing process, this invention also supports the user's ability to actively hang up the current outbound call and quickly transfer to the next contact. The specific implementation is as follows: When an outbound call is in progress (including the ringing waiting phase and the call in progress phase), if the system detects that the user has actively triggered a hang-up operation (including clicking the hang-up button on the interface or pressing the physical hang-up button), the system will perform the following steps: The first step is to immediately terminate the current outbound call; The second step is to mark the current contact's answering status as "not answered" and immediately send a distress notification message to them (if this is the first time the contact has been determined to be not answered in this distress call process, a notification will be sent; if a notification has been sent before, it will not be sent again). Third, without waiting for any additional user action, the system automatically moves on to the next contact to be dialed and continues the dialing process for the current or subsequent rounds.

[0040] The aforementioned proactive hang-up and rapid transfer mechanism complements the countdown default continue mechanism: the countdown default continue mechanism ensures that the process is not interrupted when the user is unable to operate, while the proactive hang-up and rapid transfer mechanism ensures that the user can actively accelerate the emergency call process when the user is conscious and capable of operating. Together, they cover the complete range of user operation states in emergency situations.

[0041] The notification sending logic after a user actively hangs up is consistent with the notification sending logic after a normal missed call: ensuring that skipped contacts can still be notified of the emergency call event through the emergency call notification message, and that no contact's notification is missed due to the user actively hanging up.

[0042] See Figure 2 In the flowchart, the "User actively hangs up" branch node and the "Ring timeout automatic hang-up" node are listed side by side and merge into the answer determination process, fully presenting three call end paths: ① The call ends naturally after the other party answers; ② The system automatically hangs up after the ring timeout; ③ The user actively hangs up.

[0043] Implementation Method 2: Call Answering Determination Based on Operating System Call History Data See Figure 3 The call answering determination process of this invention is as follows: Step 1: Monitor call status events on the smart terminal. When a busy call event is detected, record the outbound call initiation timestamp and start the longest call timeout timer (preferably 120 seconds) to prevent a single call from indefinitely occupying the emergency call process.

[0044] Step 2: When a call end event is detected, cancel the timeout timer and wait for a preset delay (preferably 2000 milliseconds) to ensure that the smart terminal operating system completes the writing of call history data.

[0045] Step 3: Call the native layer interface to query the call duration field of the most recent outbound call record in the call history data of the smart terminal operating system. In the Android system, the call duration field corresponds to CallLog.Calls.DURATION; in the iOS system, due to the permission restrictions on third-party applications accessing system call records, an application-layer call status callback can be used to record the actual call duration to replace the operating system call history data query, achieving an equivalent answer determination function; in other operating system platforms, the field recording the actual call duration in the platform's call history data can be used, or an equivalent implementation method can be used to record the actual call duration through an application-layer call status callback. During the query, the last 8 digits of the target number are used for matching, and a time window of 5 minutes before the query time is used for filtering to ensure that the match is the outbound call record triggered by this SOS call.

[0046] Step 4: Determine the call status based on the query results: if the call duration is zero, it is determined that the call was not answered; if the call duration is greater than zero, it is determined that the call was answered.

[0047] Step 5 (Degradation Path) If Step 3 returns an invalid value due to lack of permission to read call history data or system abnormality, it will be downgraded to a conservative duration determination: Starting from the outbound call initiation timestamp, calculate the duration of the busy call status; if the duration is not less than 90 seconds (preferred range 90 to 120 seconds), it will be determined as answered; otherwise, it will be determined as not answered.

[0048] Implementation Method 3: Automatic Generation and Sending of Emergency Notification Messages See Figure 4 In this embodiment, location information acquisition and health record data reading are performed in parallel. Both are started immediately after the distress call is triggered, and there is no sequential dependency, so as to minimize the total time spent on information collection.

[0049] When an emergency call is triggered, the system performs location tracking and health record retrieval in parallel.

[0050] The positioning module obtains the current coordinates through the GPS sensor of the smart terminal, and calls the reverse geocoding interface (preferably calling the online map service API) to convert the coordinates into a complete text address containing the province, city, district, street and house number; if the GPS acquisition times out (preferably timeout threshold of 5 seconds), it will downgrade to using the most recent cached coordinates.

[0051] The health record module queries the current user's chronic disease history list, medication list, and most recent vital sign record from the data storage (in this embodiment, a cloud database is used as an example; the data storage can also be local storage or a hybrid local and cloud storage). If the query fails, the corresponding field is filled with a null value without blocking the main process.

[0052] The content of the distress call notification message should be assembled according to the following structural template: user name and age, trigger time, symptom description (if any), location address, chronic medical history, medication list, recent vital signs (blood pressure / blood sugar / heart rate and recording time), and explanatory text.

[0053] After assembly, the system sends a distress call message to all emergency contacts using at least one of the following methods. If the message fails to be sent, it logs the message and continues processing the next contact without interrupting the main call flow: Method 1 (Short Message Service): This method calls the short message sending interface provided by the smart terminal operating system to send a short message to the emergency contact's mobile phone number. When the message text length exceeds the character limit for a single SMS message, the segmented sending interface is automatically invoked. In the Android system, the short message sending interface corresponds to SmsManager.sendTextMessage or SmsManager.sendMultipartTextMessage; in the iOS system, it corresponds to the short message sending capability provided by the MessageUI framework; and in other operating system platforms, it corresponds to the short message sending interface provided by that platform.

[0054] Method 2 (Mobile Application Push Notification): A push notification is sent from the server to the emergency contact's associated application. The push notification contains the same structured SOS message content as a text message. In this embodiment, the push notification is implemented by the cloud server calling a push service interface (such as Firebase Cloud Messaging or other push services).

[0055] Method 3 (Instant Messaging): This method involves connecting to an instant messaging platform via an interface to send a message containing a distress call to the emergency contact's instant messaging account. In this implementation, the instant messaging message is sent via a cloud server calling the instant messaging platform's open interface. This instant messaging method requires the emergency contact to pre-bind their instant messaging account, serving as a supplementary sending channel to SMS services and push notifications, and is used in combination with other sending methods to improve the reliability of distress call delivery.

[0056] The above three sending methods can be used individually or in combination to improve the reliability of the arrival of distress notifications.

[0057] Implementation Method 4: Overall System Call Flow See Figure 5 The system workflow of this invention is as follows: (1) The user clicks the emergency call trigger button; (2) The system voice prompt says "We are organizing your distress call details"; (3) Parallel acquisition by the system: current GPS location + health record data; (4) Obtain the list of emergency contacts; if the list is empty, the system will prompt the user to add a contact and pop up a temporary contact information entry interface to wait for the user's operation; if the user successfully adds at least one contact, the updated list will be used to continue to step (5); if the user gives up filling in the information, the system will jump directly to step (8). (5) Enter the main loop of multi-round cyclic dialing (see Implementation Method 1 for details). After each call in the loop, the answer determination is performed (Implementation Method 2). (6) When a contact answers, the user speaks directly with the contact and sends an emergency notification message after the call ends (Implementation Method 3); when a contact is first determined not to answer, an emergency notification message is immediately sent to that contact. If the contact still does not answer in subsequent rounds, the message will not be sent again; during any outbound call, the user can actively hang up the current call, and the system will then send an emergency notification message to that contact and automatically transfer the call to the next contact. (7) After all rounds are completed, a fallback check is performed to ensure that all unanswered contacts have received the distress call notification message; if at least one contact has been identified as answering during the entire dialing process, proceed directly to step (10); if none of the contacts have been identified as answering during all rounds, proceed to step (8). (8) Backup number guidance dialing: The system sends a confirmation prompt to the user whether to dial the preset backup number and sets a countdown (preferably 15 to 30 seconds), asking the user whether they need to dial the preset backup number (in this embodiment, the public emergency number 120 is used as an example, and the preset backup number can also be the platform customer service hotline or other emergency rescue number); if the user confirms to dial or there is no response after the countdown ends, the system calls the dialing interface of the smart terminal operating system and pre-fills the preset backup number, waiting for the user to manually dial within the preset time (preferably 60 seconds); if the user explicitly refuses to dial, the system jumps to step (10). (9) If the user dials the preset backup number and the other party answers, the system waits for the call to end naturally. Subject to local communication policies and operator rules allowing the sending of SMS messages to the number, the system attempts to send an SOS SMS containing the user's location information and health record information to the preset backup number via SMS service. Failure to send the message or failure to send it due to policy restrictions will not block the subsequent process. If the user does not dial the number or the other party does not answer within the preset waiting time, the system will prompt the user to seek other assistance and record the log. (10) The process is completed, the call log is displayed, and the system returns to standby mode.

[0058] Implementation Method 5: Cross-Platform Deployment Architecture See Figure 6 The cross-platform deployment architecture of the present invention is divided into three layers from top to bottom: core function layer 601, platform adaptation layer 608, and external dependency layer 615.

[0059] The core functional layer 601 contains all the business logic modules of this invention, including: a distress call triggering module 602, an information collection module 603, a round-call module 604, a call answering determination module 605, a voice broadcast module 606, and a notification sending module 607. The voice broadcast module 606 is responsible for outputting voice prompts and status announcements to the user at each key stage of the distress call process, throughout the entire process. The above modules implement business logic in a platform-independent manner, adapting to different smart terminals through the native interfaces provided by each platform in the platform adaptation layer 608.

[0060] Platform adaptation layer 608 includes adaptation implementations for the following target platforms: Android platform 609: Call history query interface 609a obtains the call duration recorded by the operating system through the Android system's CallLog.Calls.DURATION field; SMS sending interface 609b sends SMS messages through SmsManager.sendTextMessage or SmsManager.sendMultipartTextMessage; Audio output interface 609c configures the system-level audio channel through AudioAttributes to achieve voice playback; Call initiation interface 609d initiates outbound calls through Intent.ACTION_CALL or TelecomManager.

[0061] iOS Platform 610: Call Duration Recording Interface 610a records the actual call duration through application-layer call status callbacks, replacing the operating system's call history data query and achieving an equivalent answer determination function; SMS Sending Interface 610b sends SMS messages through the MessageUI framework; Audio Session Configuration Interface 610c configures the system-level audio channel through the iOS audio session mechanism; Call Initiation Interface 610d initiates outbound calls through the tel: URL Scheme or CallKit framework.

[0062] Smartwatch / Smart Bracelet Platform 611: The smart terminal has a built-in call module, positioning module, notification sending module, and processor. It implements a complete emergency call process by running the program of this invention. The call history query interface 611a performs answer determination through the call history data interface provided by the platform operating system; if the platform does not support independent call functionality, it communicates with the paired smartphone through the paired phone proxy interface 611b, whereby the paired smartphone performs the call history data query and returns the result. Triggering methods 611c include physical button operation, touchscreen operation, or voice wake-up command. The built-in hardware module 611d includes a call module, a positioning module, and a notification sending module.

[0063] Vehicle-mounted terminal platform 612: The vehicle-mounted terminal has a built-in call module, positioning module, and audio output module, and realizes a complete emergency call process by running the program of this invention. The call history query interface 612a performs call answering determination through the call history data interface provided by the vehicle operating system; the message / notification sending interface 612b sends an emergency call notification to the emergency contact through the message sending capability of the vehicle platform; the audio output interface 612c outputs voice prompts through the vehicle audio system; the triggering method 612d includes operation of physical buttons on the steering wheel or voice wake-up commands.

[0064] Dedicated emergency call hardware device 613: The device includes a processor 613a, a communication module 613b, a positioning module 613c, a notification sending module 613d, and a storage module 613e. The storage module stores a computer program that implements the method of the present invention, which is called and executed by the processor. The triggering method 613f is physical button operation.

[0065] HarmonyOS Platform 614: Call History Query Interface 614a retrieves call duration records from the operating system through the call record query interface provided by the HarmonyOS system; SMS Sending Interface 614b sends SMS messages through the SMS sending interface of the HarmonyOS system; Audio Output Interface 614c configures system-level audio channels through the HarmonyOS audio framework; Call Initiation Interface 614d initiates outbound calls through the call initiation interface of the HarmonyOS system.

[0066] The external dependency layer 615 includes external services and system capabilities that the aforementioned platforms commonly rely on during runtime, including: reverse geocoding service 616, used to convert GPS coordinates into readable address text containing province, city, district, and street; cloud data storage 617, used to store user health records and emergency contact data; push service 618 (such as Firebase CloudMessaging), used to send SOS notifications to the emergency contact's associated application via push notification channels; instant messaging interface 619, used to send SOS messages via instant messaging channels; local data storage 620, used to cache user data to support data access in offline scenarios; TTS engine 621, used to convert text into speech output to achieve voice broadcast function; and GPS / location service 622, used to obtain the current geographic coordinates of the smart terminal.

[0067] Implementation Method Six: Voice Broadcast Module The voice broadcast module 606 of this invention runs through the entire emergency call process, providing voice prompts and status updates to the user at each key stage. Its key implementation points are as follows: (i) Speech Synthesis Invocation: The speech broadcast module invokes the built-in Text-to-Speech (TTS) engine of the smart terminal or the TTS engine 621 of the external dependency layer to convert the preset text template into a speech stream and output it. The preset text template includes, but is not limited to: emergency call process initiation prompt, contact call status broadcast, answer / missed call result notification, process completion / abnormal prompt. The speech rate and volume can be configured according to user preferences, with a medium speech rate and a relatively large volume preferred to ensure perceptibility for elderly users and users with hearing impairments.

[0068] (ii) Audio Priority Configuration: The voice broadcast module configures audio output to a system-level navigation / accessibility priority. In the Android system, the audio purpose attribute is set via AudioAttributes.USAGE_ASSISTANCE_NAVIGATION_GUIDANCE, allowing voice broadcast to coexist with call audio without being interrupted by ordinary media audio; in the iOS system, the same effect is achieved by configuring the audio session category to AVAudioSessionCategoryPlayback or the corresponding mixing mode.

[0069] (III) Forced output in silent mode: The voice broadcast module detects the current audio mode of the smart terminal. When the device is in silent mode or do not disturb mode, the voice broadcast module automatically calls the system interface to switch the audio output stream to a forced audible channel (such as by setting the audio stream type to ringtone stream or alarm clock stream), ensuring that the key voice prompts in the emergency call process are not silenced due to the user accidentally touching the mute switch or the left-in do not disturb mode setting, and ensuring that users with limited cognitive abilities can receive all voice guidance in emergency situations.

[0070] Implementation Method 7: Countdown Default Continue Mechanism See Figure 7 This invention employs a "countdown default continuation" mechanism for all interactive nodes requiring user confirmation during the emergency call process. The general process is as follows: when an interactive event is triggered (701), the system broadcasts a confirmation prompt and starts a countdown (702); during the countdown, it checks whether a clear response has been received from the user (703); if a user response is received, the user-specified operation is executed (704); if no response is received by the end of the countdown (705), a preset default operation (the option most beneficial to rescue) is executed; after the operation is completed, the subsequent process continues (706). Specific application scenarios include: Scenario 1 707: After a contact answers, the system asks whether to continue dialing other unanswered contacts (see Implementation Method 1), sets a countdown (preferably 15 to 30 seconds), and automatically continues dialing if there is no response after the timeout.

[0071] Scenario 2 708: After all contacts have not answered, the system asks whether to dial the preset backup number (see step 8 of implementation method 4), sets a countdown (preferably 15 to 30 seconds), and automatically redirects to the dialing interface if there is no response after the timeout.

[0072] Scenario 3 709: Initial confirmation phase after a distress call is triggered (if an accidental touch protection mechanism is in place), set a countdown (preferably 5 to 10 seconds), and if there is no response after the timeout, the distress call process will start automatically.

[0073] The design intent of the above mechanism is that when a user is unable to interact with the smart terminal due to loss of consciousness, physical exhaustion, panic, or other reasons, the emergency call process will not be indefinitely blocked while waiting for user input. Instead, it will automatically continue execution according to the default option most conducive to rescue, maximizing the success rate of the emergency call. All countdown interaction nodes are equipped with voice countdown prompts from the voice broadcast module 606, enabling users to perceive the current process status while still conscious and to actively intervene when necessary.

[0074] Implementation Method 8: Cloud-based Collaborative Deployment Architecture See Figure 8 In addition to the local execution mode on the terminal, this invention also supports a cloud-based collaborative execution mode. In the cloud-based collaborative mode, after receiving a distress call trigger command, the smart terminal 801 reports the distress call event and user identifier to the cloud server 806 via the distress call trigger and event reporting module 802. The cloud server 806 performs all or part of the following functions: reads user health record information from cloud data storage via the health record data reading module 807; obtains the user's preset emergency contact list via the emergency contact list acquisition module 808; arranges the health record and location information into a structured distress call notification via the distress call notification message generation module 809; and sends the distress call notification to the emergency contact terminal 811 via push service, instant messaging, or SMS via the multi-channel message sending module 810. The smart terminal 801 is still responsible for local call initiation 803 and answer determination 804. The call reaches the emergency contact terminal 811 via the telephone network 812, and the answer determination result is synchronized to the cloud server 806. The voice broadcast module 805 always runs locally on the smart terminal 801 and does not rely on a cloud connection.

[0075] The advantages of the cloud-based collaborative mode are: when the network bandwidth of the smart terminal is limited (such as in a weak network environment), the cloud server 806 can use a stable network connection to complete message sending; when the storage or computing power of the smart terminal used by the user is limited (such as in a low-end smartwatch), the cloud server 806 can share the data processing tasks. The two modes of local execution on the terminal and cloud-based collaborative execution can be automatically switched according to the network status or pre-configured by the user.

[0076] Implementation Method Nine: Extended Technical Features The system architecture of this invention can be further extended to support the following advanced features, reserving interfaces for subsequent technology iterations: (i) Multi-device linkage triggering: When a user simultaneously holds multiple smart terminals (such as smartphones and smartwatches) with the program of this invention installed, after any terminal triggers an emergency call, it can notify the other terminals to enter the emergency call state simultaneously via Bluetooth, local area network or cloud. The terminal with the strongest communication capability will take the lead in executing the call initiation process, and the other terminals will serve as redundant channels for sending notifications.

[0077] (ii) Automatic triggering based on abnormal vital signs: When a health monitoring device (such as a smart bracelet or blood pressure monitor) with a data interface with the system of the present invention detects a preset abnormality in the user's vital signs (such as a sudden drop in heart rate below a set threshold or a fall detection sensor triggering), it can send an automatic triggering command to the system of the present invention, and start the complete emergency call process without the user having to operate manually.

[0078] (III) Call history and backtracking: After each call process is completed, the system will persistently store the complete call log (including the dialing time of each contact, the answer judgment result, the notification sending status, and the call duration) in the local or cloud database for users or their families to review and backtrack afterward, providing data support for medical treatment and legal evidence collection.

Claims

1. A smart emergency call method, applied to a smart terminal or a system containing a smart terminal, characterized in that, Includes the following steps: (1) Receive the user's emergency call trigger command; (2) Perform information collection operations: obtain the current geographical location information of the smart terminal; read the user's health record information from the data storage; (3) Obtain the preset list of emergency contacts; (4) The emergency contact list is automatically dialed using a multi-round cyclic dialing strategy. The multi-round cyclic dialing strategy includes: first round: making an outbound call to each of the contacts in the emergency contact list once; subsequent rounds: making an outbound call only to the contacts that were determined not to answer in the previous round; and stopping dialing when the preset stop condition is met. (5) After each outbound call ends, the actual call duration from the time the other party answers to the end of the call is obtained by means of technical means that can distinguish between the ringing waiting time and the actual call duration. The actual call duration does not include the ringing waiting time from the time the outbound call is initiated until the other party answers or the call is automatically disconnected. When the actual call duration is zero, it is determined that the other party has not answered. When the actual call duration is greater than zero, it is determined that the other party has answered. (6) During the execution of the multi-round cyclic dialing strategy, a distress notification message containing the geographical location information and the health record information is sent to the contacts in the emergency contact list to ensure that each contact receives the distress notification message at least once in the process.

2. An intelligent emergency call system, operating on a smart terminal or a system containing a smart terminal, characterized in that, include: The distress call trigger module is configured to receive emergency distress call trigger commands from users. The information collection module is configured to perform the following operations in parallel after a distress call is triggered: obtain the current geographical location information of the smart terminal; Retrieves the user's health record information from the data storage; The round-call module is configured to use a multi-round cyclic dialing strategy to automatically dial a preset list of emergency contacts: in the first round, an outbound call is made to each of all contacts; in subsequent rounds, an outbound call is made only to the contacts that were determined not to answer in the previous round. The dialing will stop when the preset stop condition is met. The call answering determination module is configured to, after each outbound call ends, obtain the actual call duration from the time the other party answers to the end of the call using a technical means that can distinguish between the ringing waiting time and the actual call duration. The actual call duration does not include the ringing waiting time from the time the outbound call is initiated until the other party answers or the call is automatically disconnected. The module determines whether the other party has answered the call based on whether the actual call duration is zero. The notification sending module is configured to send a distress notification message containing geographical location information and health record information to the contacts in the emergency contact list during the execution of the multi-round cyclic dialing strategy, ensuring that each contact receives the distress notification message at least once in the process.

3. A smart emergency call method, applied to a smart terminal or a system containing a smart terminal, characterized in that, Includes the following steps: (1) Receive the user's emergency call trigger command; (2) Obtain the preset list of emergency contacts; (3) A multi-round cyclic dialing strategy is adopted to initiate automatic dialing for the contacts in the emergency contact list. The multi-round cyclic dialing strategy ensures that all contacts in the emergency contact list receive at least one outbound call in the first round, specifically including: the first round: initiating an outbound call for each of the contacts in the emergency contact list; each subsequent round: initiating an outbound call only for the contacts who were determined not to answer in the previous round; setting a preset waiting interval between adjacent rounds; stopping dialing when the preset stop condition is met. (4) After each outbound call ends, the actual call duration from the time the other party answers to the end of the call is obtained by means of technical means that can distinguish between the ringing waiting time and the actual call duration. The actual call duration does not include the ringing waiting time from the time the outbound call is initiated to the time the other party answers or the call is automatically disconnected. When the actual call duration is zero, it is determined that the other party has not answered. When the actual call duration is greater than zero, it is determined that the other party has answered. (5) Based on the answer determination result, send a distress notification message to the contacts in the emergency contact list to ensure that each contact receives the distress notification message at least once in the process.

4. The method according to claim 1 or the system according to claim 2, characterized in that, The method for obtaining the actual call duration includes: after each outbound call ends, waiting for a preset delay to ensure that the operating system completes data writing, then querying the call history data maintained by the smart terminal operating system, reading the call duration field of the record corresponding to the outbound call, and using the value of the call duration field as the actual call duration; when the call history data query is unavailable, the method is downgraded to calculating the duration of the busy call status starting from the time the outbound call was initiated; if the duration is not less than a preset conservative threshold, it is determined that the call has been answered; otherwise, it is determined that the call has not been answered; the conservative threshold is not less than 90 seconds.

5. The method or system according to claim 1, 2 or 3, characterized in that, During the execution of the multi-round cyclic dialing strategy, if a user initiates a hang-up operation while an outbound call is in progress, the system immediately sends the distress notification message to the current called contact and automatically transfers the call to the next contact to be dialed after the hang-up is completed. The notification sent by the active hang-up is automatically processed without any additional user intervention.

6. The method or system according to claim 1 or 2, characterized in that, In the multi-round cyclic dialing strategy, a preset waiting interval is set between two adjacent rounds of dialing, so that the same contact receives multiple consecutive calls in a short period of time, thereby increasing the probability of the call arriving in the do-not-disturb mode of the smart terminal. The waiting interval is 3 to 10 seconds.

7. The method or system according to claim 1 or 2, characterized in that, The distress call message includes at least a textual description of the current geographic location, and at least two of the following fields: user name, age, trigger time, description of user symptoms, list of chronic medical history, list of current medications, recent vital signs record, and user-defined emergency remarks; the textual description of the current geographic location is obtained by performing reverse geocoding on the GPS coordinates.

8. The method or system according to claim 1 or 2, characterized in that, The distress call notification message is sent via at least one of the following methods: SMS service, mobile application push notification, or instant messaging.

9. The method or system according to claim 1 or 2, characterized in that, In the information collection step or module, the geographic location acquisition has a timeout limit, and after the timeout, the most recent cached coordinates are used as a fallback; when the health record acquisition fails, the corresponding field is filled with a null value; the fault tolerance mechanism does not block the execution of the main call process.

10. The method or system according to claim 1 or 2, characterized in that, If a contact answers and completes the call during the round-calling process, and there are still unanswered contacts, the system will send a confirmation prompt to the user and set a countdown. If no stop command is received within the countdown, the system will continue to initiate subsequent round-calling for the remaining unanswered contacts.

11. The method or system according to claim 1 or 2, characterized in that, The health record information comes from a health management subsystem that has a data interface with this system. The health management subsystem supports at least the following functions: inputting and continuously updating the user's chronic disease history list and daily medication list. Vital signs data are recorded periodically in the form of timestamps, including at least three items: blood pressure, blood sugar, and heart rate. When an emergency call is triggered, the latest health record data is provided to the information collection module or information collection step for integration into the emergency call notification message. The health management subsystem and the emergency call system share the same user identity identifier to ensure a one-to-one correspondence between health record data and the user who triggered the emergency call.

12. The method or system according to claim 1 or 2, characterized in that, A single-call timeout timer is started simultaneously when each outbound call is initiated. When the duration of the busy call exceeds the preset limit, the outbound call is forcibly terminated and the call is entered into the answer determination process to prevent the overall dialing process from being blocked due to the long-term occupation of the single outbound call for special reasons. The preset limit is no more than 120 seconds.

13. The method or system according to claim 1 or 2, characterized in that, The emergency call trigger command is generated by at least one of the following methods: touch screen button operation, physical button operation, voice wake-up command, or automatic triggering after the sensor detects a preset abnormal event.

14. An emergency distress call device, characterized in that, It includes a processor, and a call module, a positioning module, a notification sending module, an audio output module, and a storage module connected to the processor; the storage module stores a computer program, which, when executed by the processor, implements the steps of the method of claim 1.

15. The method or system according to claim 1 or 2, characterized in that, It also includes a backup number guidance dialing step or module: when the emergency contact list is empty and the user has not successfully added a contact, or when all contacts have not been identified as answering in all rounds of the multi-round cyclic dialing, the system sends a confirmation prompt to the user whether to dial the preset backup number and sets a countdown. If the user confirms or there is no response after the countdown ends, the system calls the dialing interface of the smart terminal operating system and pre-fills the preset backup number, waiting for the user to dial it manually; the preset backup number includes public emergency numbers or other preset emergency rescue numbers; after the call ends, provided that local communication policies and operator rules allow, the system attempts to send a distress notification message containing the geographical location information and the health record information to the preset backup number via SMS service. Failure to send or failure to send due to policy restrictions will not block subsequent processes.

16. The method or system according to claim 15, characterized in that, After obtaining the emergency contact list, if the list is empty, the system provides a temporary contact entry interface to guide the user to add at least one emergency contact on-site. If the user successfully adds the contact, the subsequent multi-round dialing process will continue with the updated contact list; if the user abandons the addition, the backup number guided dialing step will be triggered or the emergency call process will end.

17. The method or system according to claim 1 or 2, characterized in that, The timing for sending the distress notification message includes: when a contact is determined to have answered, a distress notification message is sent to them after the call ends; when a contact is determined to have not answered for the first time, a distress notification message is sent to them immediately, and if the contact still does not answer in subsequent rounds, the message will not be sent again; after all rounds are completed, a fallback check is performed to ensure that all unanswered contacts have received the distress notification message.

18. The system according to claim 2, characterized in that, It also includes a voice broadcast module, which converts preset text into voice output through a text-to-speech engine and is configured to play it with system-level audio priority, so that the voice prompts can still be output even when the smart terminal is in silent mode or do not disturb mode.

19. The method or system according to claim 1 or 2, characterized in that, For each interactive node in the emergency call process that requires user confirmation, the system has a countdown mechanism. If no clear response instruction is received from the user before the countdown ends, the system will automatically continue the subsequent process according to the preset default options to ensure that the emergency call process is not interrupted when the user is unconscious or unable to operate.

20. The method or system according to claim 1 or 2, characterized in that, The method or system supports two deployment modes: local execution on the terminal and collaborative execution on the cloud. In the local execution mode, all steps are completed on the smart terminal. In the collaborative execution mode, the information collection operation and / or the generation and sending of the distress call notification message are performed by the cloud server, and the smart terminal and the cloud server collaborate to complete the distress call process through network communication.

21. The method or system according to claim 1 or 2, characterized in that, The health record information also includes user-defined emergency remarks, which are used to provide alternative personal health status or emergency description text when the user has not entered structured health data, and are integrated into the emergency call notification message.

22. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of claim 1.

Images