An emergency help data processing method, a help terminal and a system

Abstract

The application discloses an emergency help data processing method, a help terminal and a system, and belongs to the technical field of data processing, and specifically comprises the following steps: a cloud server receives a help request carried by a help terminal and comprising position information, background audio information before help triggering and live audio and video data stream, determines a target terminal according to the position information, sends the background audio information to the target terminal as a verification basis, and establishes an audio and video forwarding channel for multiple terminals in response to confirmation signaling; meanwhile, the cloud server distinguishes the data reporting interruption of the help terminal according to heartbeat signaling, low power signaling and password shutdown signaling, judges that the help terminal is abnormally disconnected and pushes an early warning notification when the heartbeat is interrupted and still not recovered after buffering and waiting, and no normal stop running signaling is received before the interruption, so that the help terminal is distinguished from normal shutdown and temporary disconnection.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to an emergency assistance data processing method, assistance terminal, and system. Background Technology

[0002] With the widespread adoption of wearable devices and mobile terminals, device-based emergency assistance functions have become increasingly common. Existing solutions typically send a distress signal to a pre-connected emergency contact terminal or social assistance organization after the user triggers the request, allowing the recipient to initiate rescue efforts. However, such solutions still face several unresolved technical challenges at the data processing level.

[0003] One long-overlooked technical problem is that existing solutions only handle interruptions in data reporting from the requesting client in a single way, failing to differentiate the cause of the interruption at the data level. The requesting client may stop reporting data to the server due to normal shutdown (e.g., automatic shutdown due to battery depletion or user-initiated shutdown) or damage caused by external forces (e.g., malicious removal or destruction). In scenarios where the person seeking help is physically assaulted or the requesting client is forcibly damaged, data reporting will suddenly cease. Existing solutions, unable to distinguish between this interruption and normal shutdown or temporary loss of connection due to entering a communication dead zone, often treat it as a normal disconnection, thus missing the opportunity to trigger timely rescue in high-risk situations where the requesting client has been damaged.

[0004] In addition, the existing solution has the following shortcomings in data processing: First, there is a lack of verifiable data between the recipient of the help request and the person making the request. The recipient can only receive one help request, making it difficult to judge the authenticity of the help request based on objective data. Second, most of the help request related data is transmitted point-to-point from the help requesting end to a single receiving terminal, lacking a data channel that allows multiple receiving terminals to simultaneously obtain and interact with real-time data from the scene. Third, for accidental triggering of help requests by the help requesting end locally, there is a lack of a data-level processing mechanism that allows users to cancel the request and utilize the user's response status.

[0005] Therefore, how to make a differentiated judgment on the interruption of data reporting from the requesting party at the data processing level, especially to identify abnormal disconnection caused by damage to the requesting party and trigger timely processing, while providing verifiable data evidence for the recipient and establishing a real-time data channel for multiple terminals, is a technical problem that the existing technology has not yet solved. Summary of the Invention

[0006] The purpose of this invention is to provide an emergency help data processing method, help terminal, and system, to solve the following technical problems: How to make a differentiated judgment on the interruption of data reporting from the help-seeking end at the data processing level, especially to identify abnormal disconnection caused by damage to the help-seeking end and trigger timely processing, while providing verifiable data evidence for the recipient and establishing a real-time data channel for multiple terminals.

[0007] The objective of this invention can be achieved through the following technical solutions: An emergency assistance data processing method, applied to a cloud server, wherein the cloud server performs a differentiated determination of data reporting interruptions from the assistance terminal: During normal operation, the assistance terminal sends heartbeat signals at a set period; when entering low-power mode due to battery level below a set threshold, it sends a low-power signal; and before stopping operation due to receiving a shutdown password, it sends a password shutdown signal. Upon detecting an interruption in the heartbeat signal, the cloud server enters a buffer wait; if the heartbeat signal is received again within a set buffer period, the determination is lifted and normal monitoring resumes; if the heartbeat signal is not received again within the buffer period, and neither the low-power signal nor the password shutdown signal was received before the heartbeat signal interruption, the assistance terminal is determined to have an abnormal disconnection, and a pending confirmation warning notification carrying the last reported location information of the assistance terminal is pushed to the terminal corresponding to the emergency contact pre-bound to the assistance terminal; the cloud server further determines the abnormal disconnection. The determination of disconnection is based on the absence of the low battery signaling and the password shutdown signaling, and is made by inferring the cause of the interruption of the heartbeat signaling in reverse. It does not require the receipt of a notification signal indicating damage from the requesting terminal, thus classifying the situation where the requesting terminal has been damaged by external force and has not sent the aforementioned two types of signaling as an abnormal disconnection. After determining an abnormal disconnection, the cloud server only sends the pending confirmation warning notification to the terminal corresponding to the emergency contact without automatically alerting the public alarm system. Whether to further escalate is determined by the terminal corresponding to the emergency contact. If the requesting terminal has uploaded background audio information before the heartbeat signaling interruption due to a preliminary local assessment of suspected damage, the pending confirmation warning notification also carries the background audio information stored by the cloud server. This background audio information is not sent to other terminals before the abnormal disconnection is determined. The method further includes: The system receives a request for help from a client. The request carries the location information of the client, background audio information of a set duration prior to the trigger time, extracted by the client from a continuous audio data stream it collects, and on-site audio and video data streams collected in real time by the client.

[0008] The location information is compared with the location information reported by each of the multiple candidate terminals, and at least one target terminal is determined from the multiple candidate terminals based on the comparison results. The background audio information is sent to the target terminal as data for the target terminal to verify the danger. In response to the confirmation signal for receiving help sent back by the target terminal, a live audio and video data stream forwarding channel is established from the help-seeking terminal through the cloud server to the target terminal. The live audio and video data stream and the interactive messages of each terminal are forwarded synchronously to multiple terminals associated with the forwarding channel, and the terminal corresponding to the emergency contact pre-bound by the help-seeking terminal is connected to the forwarding channel. The help request is generated by the help-seeking terminal after detecting the triggering condition and outputting a confirmation prompt to the user; the help-seeking terminal distinguishes between three responses to the confirmation prompt: cancellation, confirmation, and no interaction within a set time period: cancellation cancels the current help request; confirmation initiates the help request; and no interaction initiates the help request and adds reason information to the information pushed to the terminal corresponding to the emergency contact and the target terminal. The reason information indicates the reason why the user did not respond to the confirmation prompt and the cause of this passive triggering. Furthermore, the background audio information is released before the on-site audio and video data stream; the target terminal does not have the permission to obtain the on-site audio and video data stream before accessing the forwarding channel, and only obtains the permission to obtain the on-site audio and video data stream after accessing the forwarding channel via the confirmation signal; the unreleased data is encrypted and stored locally on the requesting terminal.

[0009] Furthermore, determining at least one target terminal from the multiple candidate terminals includes: calculating the movement speed of the requesting terminal based on the position change of the requesting terminal before and after the request is triggered, calculating the estimated arrival time of each candidate terminal in combination with map data, and determining the candidate terminal whose movement speed is within a set range and whose estimated arrival time meets the set conditions as the target terminal; the calculation of the movement speed does not depend on the persistent storage of user movement characteristics.

[0010] Furthermore, when the background audio information is passively triggered by the help-seeking terminal detecting abnormal physiological parameters, it also includes a sequence of physiological parameter data collected within the set duration prior to the help-seeking triggering time; the abnormal physiological parameters are determined by the help-seeking terminal through a secondary confirmation method.

[0011] Furthermore, when the help-seeking terminal detects that its own battery level is below a set threshold, it enters a low-battery mode. In the low-battery mode, the help-seeking terminal retains the functions of collecting background audio information and triggering help requests, while stopping or downgrading other functions: when the help-seeking terminal has a display screen, the display screen only shows the low-battery mode prompt and does not respond to other control operations; when a help request is triggered in the low-battery mode, the help-seeking terminal takes pictures at set time intervals and uploads the audio recorded within the same time interval to replace continuous audio and video collection, and uploads the battery information accordingly; before the help-seeking terminal stops operating due to depleted battery, it uploads the last set duration data segment of the continuous audio data stream and the current location information to the cloud server.

[0012] The second technical solution adopted in this invention is an emergency assistance terminal, comprising a communication unit, a triggering unit, and a status sensing unit; The communication unit is configured to send heartbeat signals to the cloud server at a set period when the help terminal is running normally, send low power signals when entering low power mode due to the power being lower than a set threshold, and send password shutdown signals before stopping operation upon receiving the shutdown password. The triggering unit is configured to output a confirmation prompt to the user after detecting the triggering condition, and to distinguish between three responses of the user to the confirmation prompt: cancellation operation, confirmation operation, and no interaction within a set time period. For the no interaction, a help request is initiated with a higher help confidence level than the confirmation operation, and the information pushed to the recipient by the cloud server is attached with information indicating the reason for the user's lack of response. The state sensing unit is configured to, when it detects an impact exceeding a set threshold and its own state becomes abnormal within a set time window after the impact, initially determine that it has been damaged locally and automatically upload locally stored background audio information, current location information and state sensing data. Furthermore, the help terminal is configured not to send the low battery signaling and the password shutdown signaling when it stops operating due to abnormal conditions such as impact or disassembly status. Thus, when it is damaged by external force, it stops sending heartbeat signaling without sending the above two types of signaling.

[0013] The third technical solution adopted in this invention is an emergency assistance data processing system, including an assistance terminal, a cloud server, and multiple candidate terminals; the assistance terminal is configured to collect and upload location information, background audio information segments, and on-site audio and video data streams, and periodically send heartbeat signals and send corresponding status signals before normal shutdown; the cloud server is configured to execute the above method; the candidate terminals are configured to report location information, receive background audio information, send back confirmation signals, and access the forwarding channel.

[0014] The beneficial effects of this invention are: First, by distinguishing between the presence and absence of heartbeat signaling and normal shutdown signaling, combined with buffering and waiting, the cloud server can differentiate between abnormal disconnections caused by external damage to the requesting terminal and normal shutdowns or temporary disconnections. This allows for timely triggering of tiered warnings even in high-risk situations where the requesting terminal is damaged, solving the problem of existing solutions being unable to identify damage to the requesting terminal. Second, by sending background audio information prior to the request trigger to the target terminal, the receiver is provided with objective data to verify the authenticity of the emergency. Third, by establishing a live audio and video data stream forwarding channel for multiple terminals, the synchronous acquisition and interaction of real-time live data across multiple terminals is achieved. Fourth, by identifying the lack of user interaction with confirmation prompts as a high-risk situation where the device may be inoperable, the information pushed to the receiver includes explanations of the reasons for the user's lack of response and the passive triggering, enabling the receiver to understand the nature of the emergency and make a more urgent judgment even when the person requesting help is unable to express themselves. Fifth, the distinguishing determination does not rely on the requesting end actively sending any signal indicating its damage, but rather infers the damage based on the absence of a normal shutdown signal. Therefore, even if the requesting end is damaged by an instantaneous external force and stops operating before completing the corresponding determination and wireless transmission, the damage is still accurately identified due to the absence of a normal shutdown signal, overcoming the omissions in instantaneous damage situations that rely on the requesting end actively sending a damage notification signal. Sixth, the initial judgment of suspected damage on the requesting end's local end and the abnormal disconnection judgment of the cloud server are interconnected and complementary: the local initial judgment uploads the background audio information before the device is completely destroyed, and the cloud server retains the background audio information before the damage. The abnormal disconnection judgment in the cloud confirms the damage based on the missing signal after the device has no communication capability and releases the retained background audio information as an alarm. The combination of the two allows the system to preserve evidence at the scene and trigger an early warning after the device is instantly destroyed, without continuously transmitting sensitive data to protect privacy. This synergistic effect cannot be achieved by any of the above methods alone. Attached Figure Description

[0015] The invention will now be further described with reference to the accompanying drawings.

[0016] Figure 1 This is a flowchart of an emergency help data processing method according to the present invention; Figure 2 This is a schematic diagram of the structure of an emergency help data processing system according to the present invention; Figure 3 This is a flowchart illustrating the distinguishing determination process for interrupted data reporting at the help terminal in this invention. Figure 4 This is a flowchart of the local initial assessment and distress call link when the help terminal of this invention is damaged.

[0017] Explanation of reference numerals in the attached figures: 10. Help Terminal; 11. Audio / Video Acquisition Unit; 12. Positioning Unit; 13. Triggering Unit; 14. Communication Unit; 15. Power Management Unit; 16. Physiological Monitoring Unit; 17. Status Sensing Unit (including accelerometer, gyroscope, and skin contact detection device, etc.); 20. Cloud Server; 21. Location Comparison Unit; 22. Target Screening Unit; 23. Data Forwarding Unit; 24. Record Storage Unit; 25. Status Monitoring Unit; 30. Candidate Terminal; 31. Location Reporting Unit; 32. Verification Feedback Unit; 40. Forwarding Channel; 41. Terminal corresponding to the emergency contact. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1: An emergency help data processing method applied to a cloud server, such as... Figure 1 As shown, it includes the following steps.

[0020] Step S1: Periodic reporting of data and formation of background audio information. The help-seeking device is a portable device carried by the user; in this embodiment, it is a safety watch, but in other embodiments, it can be a wearable device that can detect the user's physiological parameters. The help-seeking device obtains location information via the Global Navigation Satellite System and mobile communication base stations, and uploads the location information along with heartbeat signaling in a data packet to the cloud server at a set reporting period (30 seconds in this embodiment, which can be dynamically adjusted according to power consumption). This allows the cloud server to obtain the real-time location of the help-seeking device and to grasp its online status based on the heartbeat signaling. During operation, the help-seeking device continuously collects audio to form a continuous audio data stream, but only temporarily stores the most recently set duration of audio data locally in a rolling over manner, without continuously uploading the continuous audio data stream to the cloud server. This minimizes the transmission of sensitive data while ensuring traceability and protecting user data security. When a help request is triggered, the help-seeking device extracts the data segment of 30 seconds prior to the trigger time from the continuous audio data stream as background audio information.

[0021] Step S2 involves triggering a help request, handling false triggers, and generating the help request. The generation of the help request includes both active and passive methods. In the active method, the help request is generated in response to an active help operation performed via a button or gesture. In the passive method, the help request is automatically generated when the user's physiological parameters are detected to be abnormal, or when the impact or disassembly status of the device meets abnormal conditions. To reduce false triggers, the help request device outputs a confirmation prompt to the user before generating the help request. The confirmation prompt can be sent via at least one of vibration, sound, or screen display. The help request device distinguishes between three user responses to the confirmation prompt: if the user cancels the request within a set cancellation time, it is determined to be a false trigger and the help request is cancelled; if the user confirms the request, the help process is executed according to the confidence level corresponding to the confirmation; if the user neither cancels nor confirms the confirmation prompt within the set time, and the help request device detects no user operation on the device, it is determined to be no interaction, and a higher help confidence level is assigned to the no interaction than the confirmation operation, and the help process continues according to the higher confidence level. The rationale is as follows: when a user is unable to operate the device due to high-risk situations such as unconsciousness or being controlled, this manifests precisely as a lack of interaction with the confirmation prompt. Therefore, the lack of interaction is used as a basis for increasing the confidence level of the request for help, rather than as a timeout degradation. After the request for help is confirmed and executed, the requesting terminal collects the on-site audio and video data stream and encapsulates the background audio information, the on-site audio and video data stream, and the current location information into a request for help, which is then uploaded to the cloud server. It should be noted that in this embodiment, the lack of interaction is identified as a request for help confidence level higher than that of the confirmation operation, rather than as a timeout degradation or cancellation; and this higher confidence level is not an abstract marker, but rather a technical process that triggers a determination: based on this, a request for help is initiated, and the information uploaded by the requesting terminal to the cloud server includes information indicating the reason why the user did not respond to the confirmation prompt, further indicating the cause of this passive trigger when it is passively triggered. Therefore, the help-seeking end transforms the objective situation of the user's lack of response to confirmation, which indicates that their operational capabilities are limited, into data that can be used by downstream processing (including the verification and response of the target terminal and the terminal corresponding to the emergency contact). This allows the recipient to judge the nature of the danger and make a more urgent response based on the cause information when the person seeking help is unable to express themselves, thereby achieving the corresponding technical effect.

[0022] Step S3, Target Terminal Determination. The cloud server loads map data and compares the location information of the requesting terminal with the location information reported in real time by multiple candidate terminals. In this embodiment, the cloud server further calculates the movement speed of the requesting terminal based on the position change of the requesting terminal before and after the request is triggered: taking the coordinates of the last reported location of the requesting terminal and the coordinates at the time of request triggering, calculating the distance between the two points according to geographical coordinates and dividing by the time difference, to obtain the movement speed before the request is triggered; and within a buffer period (e.g., ten seconds) set after the request is triggered, taking the coordinates at the time of request triggering and the coordinates of the latest reported location within the buffer period after the request is triggered to calculate the movement speed after the request is triggered. Based on this, the cloud server determines whether the requesting terminal is in a moving state and its speed value, and determines the candidate terminal whose movement speed is commensurate with that of the requesting terminal (the speed difference is within a set range) and whose expected arrival time is less than a set threshold as the target terminal. Thus, when the requesting terminal is in a moving state (e.g., located on a moving vehicle), it prioritizes matching candidate terminals with the same corresponding movement speed, avoiding matching stationary candidate terminals that are difficult to actually reach. The calculation of movement speed is based solely on real-time location data and does not persistently store user movement characteristics, thus protecting privacy. In contrast, the nearest-needle dispatch method, which relies solely on the distance between the candidate terminal and the incident location or the estimated arrival time, makes it difficult for the selected stationary candidate terminal to actually reach the person seeking help when the requesting terminal is in motion (e.g., on a moving vehicle). This embodiment, in addition to the estimated arrival time, further introduces a screening condition that the difference between the movement speed of the requesting terminal and the candidate terminal falls within a set range. This prioritizes matching candidate terminals whose movement state is commensurate with that of the requesting terminal, ensuring that the selected target terminal remains actually reachable even when the requesting terminal is continuously moving. This solves the problem of easily selecting candidate terminals that are difficult to actually reach when the requesting terminal is in motion.

[0023] Step S4: Background audio information delivery and verification. The cloud server delivers background audio information to the target terminal as data for the target terminal to verify the emergency. The target terminal displays this background audio information: when the emergency request is actively triggered, it displays the audio of the 30 seconds prior to the trigger; when the emergency request is passively triggered by abnormal physiological parameters, in addition to the audio, it also displays the physiological parameter data sequence (e.g., heart rate data sequence) for that period, so that the person being helped can verify that the emergency request was indeed triggered by a physiological abnormality. In this step, the target terminal has not yet connected to the forwarding channel, so it does not have permission to obtain the on-site audio and video data stream, but can only obtain the background audio information used as the verification basis, thereby realizing the hierarchical release of sensitive data according to the emergency request process and authorization status. After verification, the target terminal sends the corresponding signaling of the verification result back to the cloud server.

[0024] Step S5: Establishment of the forwarding channel and synchronization of data across multiple terminals. In response to the confirmation signal from the target terminal indicating receipt of the request for help, the cloud server establishes a forwarding channel for the on-site audio and video data stream from the requesting terminal to the target terminal via the cloud server. From this point onward, the target terminal accessing the forwarding channel gains access to the on-site audio and video data stream. The cloud server synchronously forwards the on-site audio and video data stream and interactive messages generated by each terminal to multiple associated terminals via the forwarding channel, enabling the multiple connected terminals to synchronously acquire real-time on-site data and interact with each other. When the requesting terminal has a screen, it displays the interactive messages. The cloud server also connects the terminals corresponding to the emergency contacts pre-bound to the requesting terminal (two in this embodiment) to the forwarding channel, allowing the emergency contacts to acquire real-time on-site data and know the location of the requesting terminal via the forwarding channel. The cloud server records events of each terminal accessing and exiting the forwarding channel. If no confirmation signal indicating receipt of the request for help is received within a set time after the background audio information is sent, the cloud server determines the next target terminal and repeats step S4.

[0025] Step S6: Storage and sealing of records. The cloud server stores background audio information, on-site audio and video data streams, location information, and channel event records during the request for help process. After the request for help ends, the above records are sealed and can only be unsealed and viewed with authorization (e.g., when requested by the public security authorities or the parties involved). Audio data temporarily stored locally on the requesting terminal using a rolling over method remains encrypted and stored locally without being released unless released.

[0026] Example 2: Differentiating determination of interrupted data reporting from the help-seeking end, such as Figure 3 As shown. This embodiment can be implemented in conjunction with Embodiment 1.

[0027] During normal operation, the help terminal 10 sends heartbeat signals to the cloud server 20 via the communication unit 14 at a set period (30 seconds in this embodiment, adjustable according to power consumption). The status monitoring unit 25 of the cloud server 20 maintains the online status of the help terminal 10 based on the heartbeat signals. Normal shutdown of the help terminal 10 includes only two scenarios, both of which send corresponding status signals to the cloud server 20 before shutdown: First, when the power is depleted, the power management unit 15 causes the help terminal 10 to enter a low-power mode when the power level is below a set threshold (15% of the remaining power in this embodiment), and sends a low-power signal to the cloud server 20 during this stage. Second, when the user actively shuts down, the help terminal 10 is configured to only shut down upon receiving the correct shutdown password, and sends a password shutdown signal to the cloud server 20 before shutting down. The status monitoring unit 25 records and marks these two types of status signals as the basis for normal shutdown of the help terminal.

[0028] The status monitoring unit 25 continuously monitors the heartbeat signaling of the help terminal 10. In one embodiment, the status monitoring unit 25 maintains a recent signaling record for each help terminal 10, recording the time of its most recent heartbeat signaling reception, and a flag indicating whether a low battery signaling or password shutdown signaling had been received before that time. If no new heartbeat signaling is received after a set judgment tolerance (e.g., two heartbeat cycles) since the most recent heartbeat signaling reception time, the status monitoring unit 25 determines that the heartbeat signaling is interrupted and starts a buffer timer.

[0029] The buffer wait is used to eliminate false judgments caused by temporary interruption of the communication link: if a heartbeat signal is received again within the set buffer time (two minutes in this embodiment, which is adjustable), the status monitoring unit 25 clears the buffer timer and resets the current judgment, and identifies it as a temporary interruption of the communication link (e.g., the help-seeking end enters a signal blind zone), and does not trigger an early warning.

[0030] When no heartbeat signal is received again after the buffer period expires, the status monitoring unit 25 reads the flag bit in the most recent signaling record: if neither a low battery signal nor a password shutdown signal was received before the interruption, the help terminal 10 is determined to be abnormally disconnected. Since the help terminal 10 is configured to directly stop operating and not send the above two types of normal stop operation signaling when it detects that it has been subjected to an impact or that its disassembly status meets abnormal conditions, the situation where the help terminal 10 is damaged by external force will manifest as "sudden interruption of heartbeat, and no normal stop operation signaling before the interruption", thus being accurately determined as an abnormal disconnection, distinguishing it from normal shutdown (with corresponding signaling before the interruption) and temporary disconnection (heartbeat resumes during the buffer period). The abnormal disconnection includes, but is not limited to: the help terminal being forcibly destroyed, dismantled, or stolen and discarded by the perpetrator, causing it to suddenly stop reporting data without any normal stop operation signaling. The distinguishing determination defines abnormal connection loss based on technical conditions (heartbeat interruption, buffer not restored, and no normal stop operation signaling before the interruption). Therefore, all of the above situations are covered by this determination, and there is no need to distinguish their specific causes one by one.

[0031] Upon determining an abnormal disconnection, the cloud server 20 does not directly alert the public alarm system. Instead, it pushes a pre-confirmation warning notification to the terminals 41 corresponding to the two emergency contacts pre-bound to the help-seeking terminal 10. This notification carries the location information last reported by the help-seeking terminal 10 and the most recently collected background audio information. The cloud server 20 performs subsequent processing based on the confirmation signal returned by the terminal 41 corresponding to the emergency contact; whether to further escalate the processing is determined by the emergency contact, and the cloud server 20 does not automatically escalate. Setting up two terminals 41 corresponding to two emergency contacts improves the reliability of receiving a confirmation signal even if one fails to respond in time, while avoiding false alarms and resource consumption caused by directly accessing public alarm resources without confirmation.

[0032] Example 3: An emergency assistance data processing system, such as Figure 2 As shown, it includes a help terminal 10, a cloud server 20, and multiple candidate terminals 30.

[0033] In this embodiment, the help-seeking device 10 is a safety watch, including an audio / video acquisition unit 11, a positioning unit 12, a triggering unit 13, a communication unit 14, a power management unit 15, and a physiological monitoring unit 16. The audio / video acquisition unit 11 is used to acquire continuous audio data streams, extract background audio information from them, and acquire on-site audio / video data streams after a help-seeking event is triggered. The positioning unit 12 obtains the location information of the help-seeking device 10 via a global navigation satellite system and a mobile communication base station. The triggering unit 13 is used to respond to active help-seeking operations, abnormal physiological parameters, or abnormal impact or disassembly status to trigger a help-seeking event, and executes the confirmation prompt and no-interaction judgment. The communication unit 14 is used to upload data packets and help-seeking requests, periodically send heartbeat signals, and send low-battery signals or password shutdown signals before normal shutdown. The power management unit 15 is used to put the help-seeking device 10 into low-battery mode when the battery level is below a set threshold, and upload the last set duration of audio data and current location information before the battery is exhausted. The physiological monitoring unit 16 is used to collect physiological parameters and perform secondary confirmation. The distress signal terminal 10 also includes a state sensing unit 17, which includes an inertial sensor (such as an accelerometer) for detecting the impact amount and a state detection device (such as a gyroscope, skin contact detection device, etc.) for detecting the wearing or posture state. It is used to make a preliminary judgment on suspected damage locally. For its specific structure and function, please refer to Embodiment 4. In other embodiments, the distress signal terminal 10 can also be a wearable device capable of detecting physiological parameters.

[0034] The cloud server 20 includes a location comparison unit 21, a target filtering unit 22, a data forwarding unit 23, a record storage unit 24, and a status monitoring unit 25. The location comparison unit 21 is used to load map data and compare the location of the help-seeking terminal 10 with the locations reported by each candidate terminal 30; the target screening unit 22 is used to calculate the movement speed of the help-seeking terminal 10 and the estimated arrival time of each candidate terminal 30, and determine the candidate terminal 30 with a similar movement speed and an estimated arrival time as the target terminal; the data forwarding unit 23 is used to establish a forwarding channel 40, synchronously forward the on-site audio and video data stream and interactive messages to multiple terminals associated with it, connect the terminal 41 corresponding to the emergency contact to the forwarding channel 40, and implement the hierarchical release of background audio information before the on-site audio and video data stream; the candidate terminal 30 does not have the right to obtain on-site audio and video before accessing the forwarding channel, only the confirmed target terminal among them accesses the channel 40 and receives the on-site stream in parallel with the emergency contact terminal 41; the record storage unit 24 is used to store and seal relevant records after the help-seeking ends; the status monitoring unit 25 is used to monitor heartbeat signaling, record and mark low battery signaling and password shutdown signaling, and perform the distinguishing determination accordingly.

[0035] The candidate terminal 30 is a mobile phone with a corresponding application installed, including a location reporting unit 31 and a verification feedback unit 32. The location reporting unit 31 is used to report the location information and movement speed of the candidate terminal 30 in real time through background location collection; the verification feedback unit 32 is used to present background audio information and send back the confirmation signal corresponding to the verification result to the cloud server 20. The help terminal 10, the cloud server 20, the multiple candidate terminals 30 and the terminal 41 corresponding to the emergency contact are connected through a communication network, and data is sent, received, forwarded, and its status monitored and processed in accordance with the methods described in Embodiments 1 and 2.

[0036] Example 4: Initial local assessment of damage to the help-seeking terminal, emergency transmission of background audio information, and the distress call link, such as... Figure 4 As shown, it can be implemented in conjunction with the aforementioned embodiments.

[0037] The help-seeking terminal 10 is equipped with a state sensing unit 17, which includes an inertial sensor (such as an accelerometer) for detecting impact and a state detection device (such as a gyroscope, skin contact detection device, etc.) for detecting wearing or posture status. The help-seeking terminal 10 uses the state sensing unit 17 to make a preliminary judgment on suspected damage locally: when the accelerometer detects an impact exceeding a set threshold, and a sensor interruption occurs within a set time window after the impact, the local preliminary judgment is that damage is suspected; the sensor interruption includes at least one of the following: abnormal interruption of posture data detected by the gyroscope and detection by the skin contact detection device of the help-seeking terminal detaching from the body, which can be replaced or supplemented by the communication unit 14 detecting whether the network registration status has been abnormally cut off. This local preliminary judgment is completed by the help-seeking terminal 10 itself, with low computational load, fast response, and low dependence on the cloud.

[0038] Upon initial local detection of suspected sabotage, the help-seeking terminal 10 immediately uploads its locally stored background audio information, along with its current location information and data collected by the status sensing unit 17, to the cloud server 20. Thus, even if the help-seeking terminal 10 is subsequently further damaged or loses its communication capability, the cloud server 20 has already obtained the last background audio information collected by the help-seeking terminal 10 before the damage, thereby solving the problem of background audio information being difficult to deliver to the cloud in a timely manner when the help-seeking terminal is damaged, provided that audio is not continuously uploaded under normal circumstances to protect privacy. The cloud server 20 retains the uploaded background audio information but does not send it to candidate terminal 30 or other terminals before confirming the danger, thus balancing privacy and data security. When the help terminal 10 subsequently stops operating due to external damage, causing it to stop sending heartbeat signals without sending low battery and password shutdown signals, and fails to recover after buffering, and is determined by the status monitoring unit 25 to be an abnormal disconnection, the cloud server 20 immediately sends the retained background audio information, along with the location information last reported by the help terminal 10, to the terminal 41 corresponding to the emergency contact, along with the pending confirmation warning notification, as background evidence for the emergency contact to verify the danger. Thus, the local initial judgment of abnormality (uploading and retaining background audio information first) and the cloud-based judgment of abnormal disconnection (releasing the background audio information as a warning after confirming device damage) are interconnected, forming a processing link from local initial judgment to cloud confirmation, and then to notification to the emergency contact. As can be seen from the above, the abnormal disconnection determination adopted in this embodiment does not rely on the requesting end successfully sending a notification signal indicating that it has been disassembled or damaged to the cloud server 20. Instead, it uses the absence of normal shutdown signaling as a criterion for reverse inference. The scheme that relies on the requesting end to actively send a damage notification signal has its own insurmountable blind spot: when the requesting end suffers instantaneous and severe external damage, it often stops operating before the determination and wireless transmission of the notification signal are completed. As a result, the cloud does not receive any damage notification and can only treat the sudden interruption as a normal disconnection and miss the detection. In this embodiment, the help terminal 10 is configured not to send low power signaling and password shutdown signaling when it stops running due to an impact or disassembly meeting abnormal conditions. The cloud server 20 can identify abnormal disconnection based solely on the judgment of the missing signaling: "heartbeat interruption, buffer period not recovered, and no normal stop operation signaling received before the interruption". Therefore, even if the help terminal 10 is instantly destroyed and does not have time to calculate or send any information, the damage is still accurately identified due to the lack of normal stop operation signaling, thus overcoming the above-mentioned blind spot.Furthermore, the initial assessment of suspected damage on the local side and the abnormal disconnection detection on the cloud side are interconnected and complementary, producing a synergistic effect that is difficult to achieve by a single method: the initial assessment on the local side uploads the background audio information before the device is completely destroyed, and the cloud retains the background audio information before the destruction, resolving the contradiction of the difficulty in timely delivery of evidence in the event of damage due to the usual non-continuous transmission of audio (to protect privacy); the abnormal disconnection detection on the cloud, after the device has no communication capability, confirms the damage based solely on the lack of signaling and releases the retained background audio information as an alarm. The combination of the two enables this system to simultaneously achieve the two conflicting goals of "neither continuously transmitting sensitive data, nor destroying the device instantly, but preserving on-site evidence and triggering an early warning," an effect that cannot be achieved by either of the above methods alone.

[0039] It should be noted that the multi-judgment and verification request process described in this section is based on the premise that the help-seeking terminal 10 still has communication capabilities (i.e., it has been initially judged locally as suspected of being damaged, but not completely destroyed). This process complements the abnormal disconnection judgment made by the cloud server 20 based solely on the absence of normal shutdown signaling when the help-seeking terminal 10 has lost communication capabilities. They are applicable to different situations, therefore, when the help-seeking terminal 10 is judged as having an abnormal disconnection, it is not required that it can still receive the verification request. After receiving the above data, the cloud server 20 performs multiple judgments, comprehensively considering at least two of the following to determine whether the situation is abnormal: the result of the abnormal disconnection judgment, the presence or absence of power-on / off related status signaling, physiological parameters such as heart rate, and battery information. When the cloud server 20 determines that the situation is abnormal, it sends a verification request to the help-seeking terminal 10, which then requests the user to enter a password for confirmation. If the user enters the correct password within a set time, the judgment is lifted, and normal monitoring is resumed. If the user does not enter a password within the set time, the help-seeking terminal 10 directly initiates an emergency call. The "requires password confirmation, and calls for help if there is no response" process, along with the mechanism in the independent claim that elevates the process if there is no interaction with the confirmation prompt, are both applications of the principle that the user's lack of response to confirmation indicates limited operability at different stages.

[0040] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. An emergency help terminal, characterized in that, It includes a communication unit, a triggering unit, and a state sensing unit, wherein: The communication unit is configured to send heartbeat signals to the cloud server at a set period when the help terminal is running normally, send low power signals to the cloud server when the help terminal enters low power mode due to the power being lower than a set threshold, and send a password shutdown signal to the cloud server before the help terminal receives the shutdown password and stops running. The triggering unit is configured to output a confirmation prompt to the user after detecting a triggering condition, and to distinguish between three responses to the confirmation prompt: cancellation, confirmation, and no interaction within a set time period. For cancellation, the current request for help is cancelled; for confirmation, a request for help is initiated according to the confidence level corresponding to the confirmation; for no interaction, a request for help is initiated at a higher confidence level than the confirmation, and the information uploaded by the requesting terminal to the cloud server includes information indicating the reason why the user did not respond to the confirmation prompt. The status sensing unit is configured to detect the impact amount received by the help-seeking terminal and its own status. When an impact amount exceeding a set threshold is detected and an abnormal status occurs within a set time window after the impact, the help-seeking terminal initially judges that it has been damaged locally and automatically uploads its locally stored background audio information, along with its current location information and the data collected by the status sensing unit, to the cloud server. The help terminal is configured to send the low power signal only when it enters low power mode due to the battery level being lower than a set threshold, and to send the power-off password signal only before it stops operating upon receiving the power-off password. Thus, when the help terminal stops operating due to external damage, it does not send the low power signal or the power-off password signal, so that the situation of the help terminal being damaged by external force manifests as stopping the sending of the heartbeat signal without sending the low power signal or the power-off password signal.

2. An emergency assistance terminal according to claim 1, characterized in that, The assistance device is a safety watch or a wearable device that can detect the user's physiological parameters.

3. An emergency assistance terminal according to claim 1, characterized in that, The state sensing unit includes an inertial sensor for detecting the impact amount and a state detection device for detecting the wearing state or posture state of the help-seeking device; the inertial sensor includes an accelerometer, and the state detection device includes at least one of a gyroscope and a skin contact detection device; the abnormal state includes at least one of the posture data abnormal interruption detected by the state detection device and the help-seeking device being removed from the wearing state.

4. An emergency assistance terminal according to claim 1, characterized in that, The triggering conditions include detecting abnormal user physiological parameters. The abnormal physiological parameters are determined by the help-seeking terminal after detecting that the physiological parameters exceed the set range, and after repeated detection within the set re-examination time. When the help-seeking is passively triggered by the abnormal physiological parameters, the cause information also includes information indicating the abnormal physiological parameters. The data uploaded to the cloud server also includes a sequence of physiological parameter data collected within the set time before the help-seeking triggering time.

5. An emergency assistance terminal according to claim 1, characterized in that, The help terminal is configured to respond to the verification request from the cloud server based on the uploaded data, requiring the user to enter a password. If the correct password is received within a set time, the current judgment is lifted. If no password is entered within the set time, the help call is initiated directly.

6. An emergency help data processing method, applied to a cloud server, characterized in that, Includes the following steps: The system differentiates and determines when the data reporting interruption from the requesting client is interrupted: the cloud server receives heartbeat signals sent by the requesting client at a set period during normal operation, low-battery signals sent by the requesting client when it enters low-battery mode due to battery level below a set threshold, and password shutdown signals sent by the requesting client before it stops operating upon receiving the shutdown password; after detecting the interruption of the heartbeat signal, the cloud server enters a buffer wait, and the determination is lifted when the heartbeat signal is received again within a set buffer time; the requesting client is a mobile device carried by the user, and the buffer wait is used to exclude temporary loss of connection caused by the requesting client passing through a wireless signal dead zone; If the heartbeat signaling is not received again within the buffer period, and the low battery signaling and password shutdown signaling were not received before the heartbeat signaling was interrupted, the help-seeking terminal is determined to be abnormally disconnected. A pending confirmation warning notification carrying the last reported location information of the help-seeking terminal is pushed to the terminal corresponding to the emergency contact pre-bound to the help-seeking terminal. However, the cloud server does not automatically send an alarm to the public alarm system, but performs subsequent processing based on the confirmation signaling returned by the terminal corresponding to the emergency contact. The cloud server first uses the buffer to wait and eliminate temporary interruptions in the communication link, and then only sends the pending confirmation warning notification to the terminal corresponding to the emergency contact when an abnormal disconnection is determined, without sending it to the public alarm system. Whether the subsequent processing is further escalated is determined by the confirmation signaling returned by the terminal corresponding to the emergency contact, and the cloud server does not automatically escalate. The cloud server determines the abnormal disconnection based on the absence of the low battery signaling and the password shutdown signaling, and makes a reverse inference of the cause of the heartbeat signaling interruption. The determination is not based on the cloud server receiving a notification signal from the requesting terminal indicating that it has been disassembled or damaged. Therefore, if the requesting terminal stops operating due to an impact or disassembly that meets abnormal conditions, and thus fails to send the low battery signaling and the password shutdown signaling, resulting in the interruption of the heartbeat signaling, the cloud server determines this as an abnormal disconnection. If the client seeking assistance has uploaded background audio information due to a preliminary local assessment of suspected damage before the heartbeat signaling was interrupted, the pending confirmation warning notification also carries the background audio information stored by the cloud server; the background audio information is not sent to other terminals before the abnormal disconnection is determined.

7. The emergency assistance data processing method according to claim 6, characterized in that, Also includes: The system receives a request for help from the client, which carries the client's location information, background audio information of a set duration prior to the trigger time extracted by the client from the continuous audio data stream it collects, and the real-time audio and video data stream collected by the client. The location information is compared with the location information reported by each of the multiple candidate terminals, and at least one target terminal is determined from the multiple candidate terminals based on the comparison results. The background audio information is sent to the target terminal as data for the target terminal to verify the danger. In response to the confirmation signal for receiving help sent back by the target terminal, a live audio and video data stream forwarding channel is established from the help-seeking terminal through the cloud server to the target terminal. The live audio and video data stream and the interactive messages of each terminal are forwarded synchronously to multiple terminals associated with the forwarding channel, and the terminal corresponding to the emergency contact pre-bound by the help-seeking terminal is connected to the forwarding channel. The help request received by the cloud server is generated after the help-seeking terminal detects the triggering condition and outputs a confirmation prompt to the user, and distinguishes between three responses: cancellation, confirmation, and no interaction within a set time. In the case of no interaction, the help request carries information indicating the reason why the user did not respond to the confirmation prompt. The cloud server forwards the reason information along with the information it pushes to the terminal corresponding to the emergency contact and the target terminal, and when the triggering condition is passively triggered, the reason information further indicates the cause of this passive triggering.

8. The emergency help data processing method according to claim 7, characterized in that, The background audio information is released before the on-site audio and video data stream; the target terminal does not have the permission to obtain the on-site audio and video data stream before accessing the forwarding channel, and only obtains the permission to obtain the on-site audio and video data stream after accessing the forwarding channel via the confirmation signal; Unreleased data is encrypted and stored locally on the client side.

9. The emergency help data processing method according to claim 7, characterized in that, Determining at least one target terminal from the plurality of candidate terminals includes: calculating the movement speed of the requesting terminal based on the position change of the requesting terminal before and after the request is triggered, calculating the estimated arrival time of each candidate terminal in combination with map data, and determining the candidate terminal whose movement speed is within a set range and whose estimated arrival time meets the set conditions as the target terminal; the calculation of the movement speed does not depend on the persistent storage of user movement characteristics.

10. The emergency help data processing method according to claim 6, characterized in that, Also includes: After receiving background audio information, current location information, and data collected by the status sensor unit uploaded by the client seeking help after initially determining that the connection has been compromised locally, the cloud server performs multiple checks based on the abnormal disconnection determination result, the presence or absence of the low battery signaling and the password shutdown signaling, and at least two of the physiological parameters and battery information. If the determination is abnormal, the cloud server sends a verification request to the client seeking help.

11. An emergency assistance data processing system, comprising an assistance terminal, a cloud server, and multiple candidate terminals, characterized in that, The cloud server is configured to execute an emergency help data processing method according to any one of claims 6 to 10; The candidate terminal is configured to report location information, receive background audio information, send back confirmation signaling, and access the forwarding channel.

Images