One-button emergency calling and positioning service method and system

Abstract

The invention discloses a one-button emergency help-seeking and positioning service method and system, and relates to the technical field of positioning services, an original help-seeking data set is formed after an abnormal packet is removed, dynamic information is circularly and complementarily collected during the duration of a help-seeking session, and all newly added data are continuously written into the original help-seeking data set. The cloud emergency platform executes feature engineering in an original help data set in real time, extracts risk situation evolution description indexes, converts extracted features into time sequence vectors, generates risk evolution trajectories and inputs the risk evolution trajectories into a pre-trained deep neural network model, and the deep neural network model outputs a risk discrimination result in real time. An adaptive redundancy policy is executed when a risk condition is triggered. According to the service system, a full-link closed-loop architecture of secure communication establishment, real-time data perception, intelligent risk identification and linkage rescue scheduling is realized, and the basic communication robustness and the transmission security level of the system are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of location service technology, specifically to a one-click emergency assistance and location service method and system. Background Technology

[0002] With the acceleration of urbanization and the fast pace of society, the public has an increasing demand for efficient, accurate, and convenient channels for seeking help when encountering emergencies (such as personal accidents, natural disasters, and public security incidents). The service system is an emergency response platform that integrates modern communication technology, geolocation services, and artificial intelligence response mechanisms.

[0003] The existing technology has the following drawbacks: Existing systems lack proactive identification mechanisms and redundant protection strategies when facing deteriorating communication environments (such as channel interference, weak equipment signals, and location drift). They cannot dynamically adjust the assistance path or improve fault tolerance based on changes in risk, which greatly reduces the robustness and practicality of the overall system. In terms of risk warning and rescue escalation mechanisms, the industry currently lacks intelligent and predictive models. Assistance dispatch often relies on fixed rules or manual judgment, which is inefficient, has limited coverage, and is difficult to adapt to complex and ever-changing real-world emergency scenarios.

[0004] Based on this, the present invention proposes a one-click emergency assistance and location service method and system, realizing a closed-loop architecture of the entire link from secure communication establishment → real-time data perception → intelligent risk identification → coordinated rescue dispatch, effectively improving the basic communication robustness and transmission security level of the system. Summary of the Invention

[0005] The purpose of this invention is to provide a one-click emergency assistance and location service method and system to address the shortcomings in the prior art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a one-click emergency assistance and location service method, the service method comprising the following steps: The user terminal establishes multiple communication links with the cloud emergency platform and generates a session ID. When the user sends an emergency signal, the user terminal uploads the original help request data to the cloud emergency platform. User terminals and cloud-based emergency platforms exchange data formats and transmission fingerprints through channels, and form the original help dataset after removing abnormal packets. Dynamic information is continuously collected during the duration of the help request session, and all newly added data is continuously written into the original help request dataset. The cloud-based emergency response platform performs feature engineering in real time on the original request for help dataset to extract indicators describing the evolution of the risk situation; The extracted features are converted into time series vectors and the resulting risk evolution trajectory is input into a pre-trained deep neural network model. The deep neural network model outputs risk discrimination results in real time and executes an adaptive redundancy strategy when a risk condition is triggered.

[0007] Preferably, the extracted features are converted into time series vectors and used to generate risk evolution trajectories, which are then input into a pre-trained deep neural network model. The deep neural network model outputs risk discrimination results in real time, including the following steps: The values ​​of each type of feature in the feature set are subjected to a sliding window operation within N time windows. An exponential decay weighting mechanism is introduced to emphasize the impact of recent data while preserving the structural outline of historical information. For non-stationary signal features, Fast Fourier Transform is used to perform frequency domain transformation on the signal features within the sliding window to extract the main frequency component and spectral energy distribution features; The multidimensional features within each time window are reconstructed into time series vectors with a unified structure. The time series vectors are then concatenated in chronological order to form a risk evolution trajectory matrix. The risk evolution trajectory is input into a pre-trained deep neural network model, which outputs the probability of communication link failure, the probability of risk escalation, and the recommended level of rescue.

[0008] Preferably, the deep neural network model processing logic is as follows: The LSTM structure is responsible for encoding the hidden state information at each time step in the trajectory and preserving the temporal dependencies in the historical input; The Attention module assigns weights to the output of each time step to identify key time slices that influence risk trends. The weighted feature sequences are mapped using a fully connected method to output a risk discrimination result set.

[0009] Preferably, the user terminal and the cloud-based emergency platform exchange data formats and transmission fingerprints through a channel, and after removing abnormal packets, form the original distress data set, including the following steps: Each uploaded data frame is unpacked and its fields are mapped based on a predefined data interface protocol. For each data frame, call the field validation function to match the required options and formats in the protocol definition field by field, mark all missing fields or fields whose types do not match the preset template, and if the proportion of missing fields exceeds the threshold or key information fields are missing, mark the data frame as unprocessable and discard it. Parse the protocol version and transmission policy fields from the data frame and match them with the protocol version of the terminal registered in the current session. If the version numbers are inconsistent or the signature mechanism used is incompatible with the platform's current support, the data frame will not participate in the construction of the formal dataset and will be recorded in the version exception log for auditing. By performing differential comparison between the local clock and the terminal timestamp, and by verifying the SM3 digest value and MAC signature attached to the verification field, it is determined whether the ciphertext has been tampered with or damaged during transmission. The data frames that pass the verification are then aggregated to form the original help request dataset.

[0010] Preferably, the local clock and the terminal timestamp are compared differentially, and the judgment logic is as follows: Calculate the difference between the timestamp uploaded by the terminal and the current clock on the platform; If the absolute time difference exceeds the acceptable range, it is marked as a time drift anomaly; If multiple data frames are out of order, the out-of-order data will be temporarily cached and the logical order will be restored based on the timestamp; If the time drift exceeds the synchronization window, the merging of the data sequence will be aborted.

[0011] Preferably, when a user sends an emergency signal, the user terminal uploads the original distress data to the cloud emergency platform, including the following steps: The logic for fusing and calculating location data from different sources is as follows: GNSS positioning is used as the primary input source, and basic weights are assigned to it. Based on historical signal-to-noise ratio trends, a time decay factor is introduced into Wi-FiRTT data to control its weight fluctuations within a short time window; Zero bias correction and cumulative drift removal are performed on the displacement data calculated by the IMU, and are only used as short-term enhancement compensation terms; The fused positioning coordinates are generated by weighted averaging, and a confidence score is attached as a measure of the reliability of the positioning coordinates. The collected data is standardized and boundary value detected to remove outliers and extract characteristic parameters such as the rate of change of acceleration and the rate of change of rotation angle as a preliminary basis for judging sudden changes in user behavior. If the user authorizes, the system calls the local or bound health device interface to extract physiological parameters. All collected data fields are structured and encapsulated locally to form the original help request data structure, which is then encrypted during the encrypted transmission process. The system uses the SM3 digest function to generate a verification value and binds a message authentication code.

[0012] Preferably, the encrypted transmission process involves encryption, including the following steps: Serialize the structure; Using the symmetric key negotiated in the current session as the encryption key, the SM4 algorithm is used to perform encrypted block operations on the serialized data. The original data digest is generated using the SM3 digest algorithm and appended to the ciphertext; The MAC is calculated using the shared key to pair the ciphertext and digest, and then appended to the final message as a message authentication field. The generated encrypted message packets constitute a distress data frame and are sent to the cloud platform through the current communication link.

[0013] Preferably, the user terminal establishes multiple communication links with the cloud-based emergency platform and generates a session ID, including the following steps: The user terminal generates a temporary public-private key pair, sends the public key to the cloud emergency platform using the SM2 protocol, and receives the authentication signature and negotiation parameters returned by the cloud emergency platform; Both parties negotiated and derived a symmetric key through ECDH, and then all communication content was encrypted using SM4, supplemented by SM3 digest function for message integrity verification; After a successful handshake, the cloud-based emergency platform generates a session identifier that is bound to the current terminal session. This session identifier is embedded in the header of all subsequent data packets and is used as a data association identifier.

[0014] Preferably, after a successful handshake, the cloud-based emergency platform generates a session identifier bound to the current terminal session. The generation logic is as follows: The device identifier, timestamp, and handshake key digest are concatenated to form the initial input string; Use the SM3 digest function to hash the input string; The summary results are mixed with a random factor, and a double hash operation is performed. The hash result is truncated to a portion of its length and used as the Session-ID to identify the context of this session.

[0015] This application also provides a one-click emergency assistance and location service system, including an initialization module, a dataset generation module, a feature engineering execution module, and an adaptive adjustment module; Initialization module: Used to establish multiple communication links between user terminals and cloud emergency platforms and generate session IDs. When a user sends an emergency signal, the user terminal uploads the original help request data to the cloud emergency platform. Dataset generation module: The user terminal and the cloud emergency platform exchange data formats and transmission fingerprints through the channel, and form the original help dataset after removing abnormal packets; Feature engineering execution module: During the duration of the help request session, dynamic information is collected cyclically. All new data is continuously written into the original help request dataset. The cloud emergency platform performs feature engineering in real time on the original help request dataset to extract indicators that describe the evolution of the risk situation. Adaptive adjustment module: The extracted features are converted into time series vectors and the risk evolution trajectory is generated and input into the pre-trained deep neural network model. The deep neural network model outputs the risk discrimination result in real time and executes the adaptive redundancy strategy when the risk condition is triggered.

[0016] The technical effects and advantages provided by the present invention in the above technical solution are as follows: This invention facilitates data format and transmission fingerprint exchange between a user terminal and a cloud-based emergency platform via a channel. After removing abnormal packets, an original request-for-help dataset is formed. Dynamic information is continuously collected during the request-for-help session, and all new data is continuously written into the original dataset. The cloud-based emergency platform performs feature engineering in real-time on the original dataset, extracting indicators describing the evolution of risk situations. The extracted features are converted into time-series vectors, generating risk evolution trajectories which are then input into a pre-trained deep neural network model. The deep neural network model outputs risk assessment results in real-time, and an adaptive redundancy strategy is executed when risk conditions are triggered. This service system achieves a closed-loop architecture across the entire chain, from secure communication establishment to real-time data perception, intelligent risk identification, and coordinated rescue dispatch. It effectively overcomes key problems of traditional request-for-help systems, such as single-point failures in communication, weak static response mechanisms, insufficient intelligence, and poor anti-interference capabilities, significantly improving the system's basic communication robustness and transmission security level. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0018] Figure 1 This is a flowchart of the present invention.

[0019] Figure 2 This is a diagram of the architecture of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0021] Example 1: Please refer to Figure 1 As shown in this embodiment, the one-click emergency assistance and location service method includes the following steps: User terminals (such as mobile phones, wearable devices, or vehicle systems) first establish multiple communication links with the cloud-based emergency platform simultaneously, including cellular mobile networks, Wi-Fi, and GNSS satellite positioning, and generate a unique session ID through national cryptographic SSL sessions. This step lays a secure and reliable foundation for subsequent data encryption, synchronization, and retransmission, and ensures that backup pathways are available even if a single path is blocked.

[0022] When a user sends an emergency signal (by pressing the physical help button or saying a wake-up word), the terminal immediately and synchronously collects high-precision positioning coordinates, the status of various sensors (acceleration, direction, environmental noise), and the user-authorized health / physiological parameters, and then encrypts and uploads this raw help data to the cloud emergency platform in one go using national cryptographic algorithms.

[0023] The terminal and platform exchange data formats and transmission fingerprints through the classic channel. Packets with missing fields, inconsistent protocol versions, or abnormal timestamps are immediately removed. Only help data with consistent format, synchronized timing, and passed integrity verification are retained to form the first batch of "raw help datasets".

[0024] During the duration of the help request session, the system cyclically collects dynamic information such as signal strength, location drift, and surrounding network availability at fixed time intervals (e.g., every 1 second). All new data is continuously written into the "raw help request dataset" after denoising and standardization, enabling the platform to obtain a rolling updated stream of raw data.

[0025] The platform performs feature engineering in real time on the original data set of requests for help, extracting indicators that can describe the evolution of risk situation, such as the rate of decrease in location signal-to-noise ratio, sudden increase in motion acceleration, high pressure index of voice emotion, and sudden change in network latency, providing a refined but information-rich feature set for subsequent quantification and decision-making.

[0026] The extracted features are converted into time series vectors and quantified using methods such as sliding window averaging, exponential decay, or Fourier transform to generate a "risk evolution trajectory." This records both the current instantaneous risk and preserves historical trends, laying a data foundation for intelligent model judgment.

[0027] The risk evolution trajectory is fed into a pre-trained deep neural network model (e.g., an architecture that combines LSTM and Attention), and the model outputs in real time the probability of communication link failure, the probability of risk escalation, and the suggested rescue level.

[0028] When the probability of communication link failure exceeds the failure probability threshold or the probability of risk escalation exceeds the escalation probability threshold, the system immediately executes an adaptive redundancy strategy: automatically switches to the suboptimal network channel and enables forward error correction (FEC), repeatedly broadcasts help packets to multiple city-level emergency call centers; at the same time, it expands the notification scope to family members, local volunteers and nearby police cars, pushes high-frequency locations to the command screen, and, if necessary, links drones or street light cameras to achieve continuous reachability, rescue capability and traceability in scenarios of channel interference or risk deterioration.

[0029] Please see Figure 2 As shown, the one-click emergency assistance and location service system described in this embodiment includes an initialization module, a dataset generation module, a feature engineering execution module, and an adaptive adjustment module; Initialization module: Used to establish multiple communication links between user terminal and cloud emergency platform and generate session ID. When user sends an emergency signal, user terminal uploads raw help data to cloud emergency platform. The established multiple communication links are sent to dataset generation module, feature engineering execution module and adaptive adjustment module. Data set generation module: The user terminal and the cloud emergency platform exchange data formats and transmission fingerprints through the channel, and after removing abnormal packets, the original help request dataset is formed. The original help request dataset is sent to the feature engineering execution module. Feature engineering execution module: Dynamic information is continuously collected during the duration of the help request session. All new data is continuously written into the original help request dataset. The cloud emergency platform performs feature engineering in real time in the original help request dataset to extract indicators describing the evolution of the risk situation. The extracted features are then sent to the adaptive adjustment module. Adaptive adjustment module: The extracted features are converted into time series vectors and the risk evolution trajectory is generated and input into the pre-trained deep neural network model. The deep neural network model outputs the risk discrimination result in real time and executes the adaptive redundancy strategy when the risk condition is triggered.

[0030] This application establishes a data format and transmission fingerprint exchange between the user terminal and the cloud-based emergency platform via a channel. After removing abnormal packets, an original request for help dataset is formed. Dynamic information is continuously collected during the request for help session, and all new data is continuously written into the original dataset. The cloud-based emergency platform performs feature engineering in real time on the original dataset, extracting indicators describing the evolution of the risk situation. The extracted features are converted into time-series vectors and used to generate risk evolution trajectories, which are then input into a pre-trained deep neural network model. The deep neural network model outputs risk assessment results in real time, and an adaptive redundancy strategy is executed when risk conditions are triggered. This service system achieves a closed-loop architecture across the entire chain, from secure communication establishment to real-time data perception, intelligent risk identification, and coordinated rescue dispatch. It effectively overcomes key problems of traditional request for help systems, such as single-point failures in communication, weak static response mechanisms, insufficient intelligence, and poor anti-interference capabilities, effectively improving the system's basic communication robustness and transmission security level.

[0031] User terminals (such as mobile phones, wearable devices, or vehicle systems) first establish multiple communication links with the cloud-based emergency platform simultaneously, including cellular mobile networks, Wi-Fi, and GNSS satellite positioning, and generate a unique session ID through national cryptographic SSL sessions. This step lays a secure and reliable foundation for subsequent data encryption, synchronization, and retransmission, and ensures that backup pathways are available even if a single path is blocked.

[0032] In this method, after the user terminal (e.g., mobile phone, wearable device, or vehicle system) is powered on, it automatically initiates a multi-channel initialization process, establishing multiple independent but parallel communication links with the cloud-based emergency service platform to ensure high availability and resilience in complex or constrained environments. Specifically, this initialization process includes the synchronous connection configuration and verification of cellular mobile networks (such as LTE, 5G NR), Wi-Fi channels (including home LANs or public hotspots), and GNSS satellite positioning links (such as BeiDou, GPS, GLONASS). This "multi-link aggregation access mechanism" can be automatically scheduled through the underlying network abstraction module, enabling the terminal to automatically select the optimal path or switch paths when network resource status changes dynamically, thus ensuring connection continuity and stability.

[0033] After the aforementioned multi-link access is completed, the terminal immediately initiates a handshake request to the cloud platform, establishing an encrypted communication session through the "National Cryptographic SSL Protocol Stack." This protocol stack employs SM series algorithms (including SM2 asymmetric key exchange, SM3 digest function, and SM4 symmetric encryption) that comply with national cryptographic management regulations to achieve session key negotiation, authentication, and encryption of transmitted content. During the handshake phase, the terminal first generates a temporary public-private key pair, sends the public key to the platform using the SM2 protocol, and receives the authentication signature and negotiation parameters returned by the platform. Both parties negotiate and derive a symmetric key through ECDH, and subsequently, all communication content is encrypted using SM4, supplemented by SM3 digest function for message integrity verification.

[0034] Once the handshake is successful, the platform generates a unique session identifier (SessionID) bound to the current terminal session. This identifier is generated based on the unique device identifiers of the participating entities (such as IMEI, MAC address, etc.), the session start timestamp, the asymmetric key digests of both parties in the handshake, and a high-entropy random factor. The generation logic is as follows: First, the device identifier, timestamp, and handshake key digest are concatenated into an initial input string; the SM3 digest function is used to hash this input string; the digest result is mixed with a random factor and a second hash operation is performed; a portion of the hash result is truncated as the Session-ID to identify the context of this session.

[0035] The Session-ID is then embedded in the header of all subsequent data packets and used as a data association identifier to support packet retransmission, out-of-order reordering, and multipath consistency verification, ensuring that the system can still correctly identify and process asynchronously transmitted data blocks in weak network environments.

[0036] In addition, during initialization, the terminal periodically evaluates the current quality of each link, including link latency, packet loss rate, jitter, and bandwidth utilization. The evaluation mechanism employs a weighted moving average strategy, giving higher weight to latency fluctuations to more sensitively detect network fluctuations and enable rapid switching. This link health evaluation score will be continuously updated and used to guide the redundancy distribution and optimization strategies of links in subsequent communication processes.

[0037] In summary, this step not only completes the multi-link communication configuration and key negotiation between the terminal and the platform, but also lays a secure and reliable foundation for subsequent encrypted data transmission, link switching control, and retransmission recovery mechanisms through a series of structured encrypted session management mechanisms and dynamic link quality assessment strategies. This approach greatly enhances the system's fault tolerance and practicality in high-risk and complex environments, and is an important preliminary step in building a highly accessible emergency communication system.

[0038] When a user sends an emergency signal (by pressing the physical help button or saying a wake-up word), the terminal immediately and synchronously collects high-precision positioning coordinates, the status of various sensors (acceleration, direction, environmental noise), and the user-authorized health / physiological parameters, and then encrypts and uploads this raw help data to the cloud emergency platform in one go using national cryptographic algorithms.

[0039] When a user issues an emergency signal (such as pressing a physical help button or triggering a voice command via a wake word), the terminal device immediately enters a high-priority emergency data collection and reporting process. This process is designed to collect the user's surrounding spatiotemporal state information and their own state parameters simultaneously with a millisecond-level response speed, and transmits the data encrypted using national cryptographic algorithms to ensure the timeliness, integrity, and confidentiality of the data, ensuring the platform can make rapid judgments based on real-time and effective contextual awareness.

[0040] First, the terminal activates the high-precision sensor modules related to positioning via a local system call. This positioning data includes not only standard GNSS coordinate information (latitude, longitude, altitude, and timestamp), but also Wi-Fi RTT (Round Trip Time) ranging data, cellular base station triangulation reference points, and short-term displacement increments calculated based on an inertial navigation (IMU) model. To improve the spatial resolution and stability of the positioning results, the system performs fusion calculations on positioning data from different sources. This calculation follows a weighted sliding fusion model, and its processing logic is as follows: GNSS positioning is used as the main input source and assigned basic weights. Based on historical signal-to-noise ratio trends, a time decay factor is introduced into Wi-FiRTT data to control its weight fluctuations within short time windows. Zero bias correction and cumulative drift removal are performed on IMU-estimated displacement data, which are only used as short-term enhancement compensation terms. Finally, fused positioning coordinates are generated by weighted averaging, and a confidence score is attached as a measure of the reliability of the positioning coordinates.

[0041] Secondly, while collecting positioning data, the terminal also initiates a set of sensor data acquisition processes in parallel, covering three-axis acceleration, gyroscope angular velocity, magnetometer directional field strength, ambient light, and noise levels. Data from each type of sensor is sampled at a fixed period (e.g., 20ms), and a sliding window of 3-5 consecutive periods is retained to ensure that the system captures trends in state changes rather than isolated values. The system standardizes the collected data and performs boundary value detection, removing outliers and extracting second-order derivative characteristic parameters such as the jerk rate of acceleration and the yaw rate of rotation, serving as a preliminary basis for judging sudden changes in user behavior.

[0042] After collecting data on the external environment and movement status, if authorized by the user, the system further calls the local or bound health device interface to extract basic physiological parameters such as current heart rate, blood oxygen saturation, skin temperature, or blood pressure. This data is typically obtained synchronously with peripherals (such as smart bracelets and smartwatches) via Bluetooth. The platform performs synchronous correction for sampling time delays to ensure that physiological data and sensor data are within the same timestamp domain.

[0043] All collected data fields are locally structured and encapsulated to form a standard "raw help request data structure". This structure includes the following core fields: location information, sensor status, user health status, sampling timestamp, data source label, sampling confidence label, device ID, and current session identifier (SessionID). This structure then enters the encrypted transmission process, where it is encrypted using the national standard SM4 symmetric encryption algorithm, and a checksum is generated using the SM3 digest function and bound to a message authentication code (MAC). The processing logic of the entire encryption process is as follows: The structure is serialized (e.g., in JSON or TLV format); using the symmetric key negotiated in the current session as the encryption key, the serialized data is encrypted using the SM4 algorithm; the original data digest is generated using the SM3 digest algorithm and appended to the ciphertext; the MAC is calculated using the shared key on the ciphertext and digest and appended to the final message as a message authentication field; the generated encrypted message packet constitutes a "help data frame" and is sent to the cloud platform through the highest quality communication link currently available.

[0044] Throughout the process, the system logs the time cost of each data collection action for subsequent performance evaluation and optimization of abnormal retransmission. Through this process, the terminal can quickly construct a spatiotemporally synchronized, state-complete, and securely verifiable emergency assistance data unit, providing a solid data foundation for the cloud platform to respond instantly and make intelligent judgments in extreme emergencies. This design not only enhances the security level of data transmission but also ensures high stability and response accuracy even in complex environments such as network fluctuations and device interference.

[0045] The terminal and platform exchange data formats and transmission fingerprints through the classic channel. Packets with missing fields, inconsistent protocol versions, or abnormal timestamps are immediately removed. Only help data with consistent format, synchronized timing, and passed integrity verification are retained to form the first batch of "raw help datasets".

[0046] After the user terminal completes the encrypted upload of emergency data, the cloud-based emergency platform receives the encrypted data frame and immediately enters the format verification and transmission fingerprint consistency verification stage. The core purpose of this stage is to ensure that the received data conforms to the platform's processing standards in terms of structure, version, timing, and integrity, avoiding misjudgments or system anomalies caused by data distortion, duplication, contamination, or illegal tampering. This process ultimately forms the first batch of stable and reliable "raw help datasets" that can be used for modeling and decision analysis.

[0047] First, the platform's receiving end initiates the data packet structure parsing module, unpacking and mapping the fields of each uploaded data frame based on a predefined data interface protocol (such as TLV structure or JSON field specifications). During unpacking, the system checks the existence and data type accuracy of all core fields according to the protocol template bound to the current session ID. For example, the positioning field should include longitude, latitude, altitude, and timestamp; the sensor field should include three-axis vector values ​​and corresponding sampling frequency labels; and the health parameter field should include metadata such as data source, measurement unit, and error boundaries. After structure parsing, the system immediately executes the field integrity verification logic. Its processing logic is as follows: For each data frame, the field validation function is called to match the required options and formats in the protocol definition field by field; all missing fields or fields whose types do not match the preset template are marked; if the proportion of missing fields exceeds the threshold (e.g., 30%), or key information fields are missing (e.g., location timestamp, session ID, etc.), the data frame is marked as "unprocessable" and discarded; other minor missing cases are included in the abnormal cache area and will be restored later by data completion or redundant frame comparison.

[0048] Following the structural verification, the platform initiates a protocol version and context consistency verification module. This module primarily compares the protocol consistency between the terminal and the platform, including fields such as data protocol version number, terminal firmware version, and encryption signature policy. The processing logic is as follows: parse the protocol version and transmission policy fields from the data frame; perform a consistency match with the terminal protocol version registered in the current session; if the version number is inconsistent, or the signature mechanism used is incompatible with the platform's current support, the data frame will not participate in the formal dataset construction and can be recorded in the version anomaly log for auditing.

[0049] The next step is timestamp verification and time sequence synchronization, which is the core step in ensuring the composability and timeliness of the help request data sequence. The platform uses the local clock and the terminal timestamp for differential comparison, applying the following judgment logic: The system calculates the difference between the timestamp uploaded by the terminal and the current clock on the platform. If the absolute time difference exceeds the acceptable range (e.g., ±5 seconds), it is marked as "time drift anomaly". If multiple data frames are out of order, the system will temporarily cache the out-of-order data and attempt to restore the logical order based on the timestamp through the reordering module. If the time drift exceeds the synchronization window (e.g., severe drift of 3 consecutive frames), the system will stop merging the data sequence to prevent time inconsistency from polluting the analysis process.

[0050] After completing the above structure, protocol, and time verifications, the data frame also needs to undergo integrity verification and signature authentication. The system verifies whether the ciphertext has been tampered with or corrupted during transmission by checking the SM3 digest value and MAC signature attached to the verification field. The verification process is as follows: After decrypting the data frame, recalculate the digest; compare the recalculated digest with the original digest field; if they do not match, the data frame is determined to have been tampered with or corrupted during transmission and is immediately discarded; otherwise, it enters the final data buffer pool and is marked as a "valid frame".

[0051] All valid data frames that pass the above verification are aggregated to form the first batch of "raw distress request datasets." This dataset is a valid distress request information sequence that is structurally complete, protocol consistent, time-synchronized, and has passed integrity authentication. It is a crucial foundation for subsequent risk modeling, situation identification, and route decision-making. Through this mechanism, the system effectively shields itself from interference from unreliable links, illegal terminals, and data sources with corrupted formats, greatly improving the accuracy and stability of the platform's response to emergency events and laying a solid foundation of trust for the entire intelligent rescue closed-loop process.

[0052] During the duration of the help request session, the system cyclically collects dynamic information such as signal strength, location drift, and surrounding network availability at fixed time intervals (e.g., every 1 second). All new data, after denoising and standardization, is continuously written into the "raw help request dataset," enabling the platform to obtain a continuously updated raw data stream. The platform performs feature engineering in real time on the raw help request dataset to extract indicators that can describe the evolution of the risk situation, such as the rate of decrease in location signal-to-noise ratio, sudden increases in motion acceleration, high-pressure index of voice emotion, and sudden changes in network latency, providing a refined but information-rich feature set for subsequent quantification and decision-making.

[0053] During the duration of a help request session, in addition to periodically collecting dynamic data and updating the rolling dataset, the system continuously runs a risk feature extraction module on the cloud platform. This module performs real-time feature engineering on the ever-growing "raw help request dataset," extracting key feature indicators that sensitively reflect the evolution of the risk situation. This process is a crucial foundation for the system to achieve proactive prediction, risk warning, and intelligent decision-making. Its goal is to efficiently construct a low-dimensional, highly expressive feature set from a large amount of raw data, thereby improving the accuracy of subsequent modeling and the system's response speed.

[0054] First, the platform divides newly written data into time windows through task scheduling. Typically, a fixed-length sliding window (e.g., the most recent 5 seconds or 10 data frames) is used as the analysis unit to ensure that the extracted features have temporal continuity and event relevance. Each window unit contains multiple standardized data vector fields, including RSSI, SNR, triaxial acceleration, GNSS confidence score, network jitter index, and audio input signal strength. The window settings support adjustable overlap (e.g., 50% cross-coverage) to improve the frequency and stability of feature updates.

[0055] Next, the platform executes a multi-dimensional dynamic rate of change calculation algorithm. For example, when processing the location signal-to-noise ratio (SNR), to monitor whether the user has entered a weak signal area or a shielded environment, the platform not only calculates the absolute value of the SNR in the current frame, but also calculates the slope of this value's change within the current window (i.e., the "SNR decrease rate"). Its processing logic is as follows: Extract the signal-to-noise ratio sequence from the current time window; perform a linear fit after sorting by time to obtain the fitting slope; if the slope is negative and the absolute value exceeds the warning threshold, it is marked as the "increased risk of signal degradation" feature; at the same time, output the maximum drop and standard deviation of the sequence as auxiliary features.

[0056] Similarly, in motion behavior feature extraction, the platform calculates the rate of change of the vector magnitude of triaxial acceleration (i.e., acceleration intensity) to identify sudden falls, jumps, rapid movements, and other behavioral states. The processing logic includes: calculating the first derivative of all acceleration vector magnitude values ​​within the sliding window; if the derivative exceeds a certain threshold and is accompanied by a change in direction (e.g., from horizontal to vertical), it is judged as an "acceleration surge event"; when the event occurs, the surge magnitude, duration, and gradient changes before and after are recorded and written into the feature set as feature triples.

[0057] Regarding network communication characteristics, the platform focuses on the abrupt changes in end-to-end network latency and jitter behavior. The system continuously monitors RTT (Round-Trip Time) and Packet Delay Variation (PDV), calculating their maximum variation magnitude and average abrupt change frequency within each window. These characteristics can be used to identify instability risks in network links, and the processing logic is as follows: Extract all RTT samples in the current window; perform pairwise difference on consecutive samples to calculate the change amplitude sequence; if the average difference value exceeds twice the mean of the dynamic baseline, or the maximum fluctuation exceeds the upper limit threshold, mark it as a "network latency mutation event"; encode the average rate of change, the maximum single-frame fluctuation value, and the mutation frequency into a feature subset.

[0058] Furthermore, if a user uses a voice channel in their request for help, the platform will also access the audio stream and execute an emotional stress index extraction algorithm. This algorithm analyzes whether there are obvious anxiety, fear, or distress signals in the speech by combining acoustic features (such as sound intensity fluctuations, speech rate, and pitch change frequency) with a deep emotion recognition model (such as a CNN-BiLSTM network based on convolutional spectrograms). Its processing logic is as follows: a short-time Fourier transform is performed on the speech to obtain a spectrogram; features such as the rate of sound intensity change, speech rate abrupt changes, and spectral energy distribution shifts are extracted; these features are input into a pre-trained emotion recognition model, and an emotional stress score is output; if the score exceeds a warning threshold, a "voice emotional stress index" is output as a psychological state feature.

[0059] All extracted features will be written into the "Feature Set" in the current analysis window in a structured format. Each feature in the set will have a timestamp, data source label, risk weight coefficient, and standardization flag, ensuring that it can be directly used by subsequent time series modeling, deep discrimination, and rescue decision-making modules. At the same time, the platform will perform redundancy checks and sample screening on the feature set, removing redundant features with no information gain or multicollinearity, maintaining the sparsity and discriminative power of the set.

[0060] Through this series of meticulous feature engineering processes, the platform not only enhances its sensitivity to the evolving trends of requests for assistance, but also provides high-quality decision-making support for subsequent risk trajectory modeling and rescue level assessment. This feature construction mechanism, which dynamically extracts and integrates multimodal information from continuous data and performs time-series modeling, is a key supporting means for the system to achieve intelligent response and reliable early warning.

[0061] The extracted features are converted into time series vectors and quantified using methods such as sliding window averaging, exponential decay, or Fourier transform to generate a "risk evolution trajectory." This records both the current instantaneous risk and preserves historical trends, laying a data foundation for intelligent model judgment. The risk evolution trajectory is input into a pre-trained deep neural network model (such as an architecture that integrates LSTM and Attention), and the model outputs in real time the probability of communication link failure, the probability of risk escalation, and the suggested rescue level.

[0062] After the system completes the construction of the feature set, the platform enters the feature sequence quantization and risk evolution modeling stage. The core task of this stage is to compress and reconstruct the original high-dimensional discrete feature vectors in the time domain to generate a "risk evolution trajectory" with a unified form and clear semantics, so as to capture the continuous evolution pattern of the help-seeking event in the time dimension and provide a standardized vector sequence that meets the input requirements for the downstream deep learning model.

[0063] First, the platform employs a sliding window statistical aggregation mechanism to compress the time series data for each feature dimension. In this process, the system performs a sliding window operation on the values ​​of each feature class (e.g., location signal-to-noise ratio change rate, acceleration abrupt change amplitude, speech emotion index, etc.) within the most recent N time windows. The processing logic is as follows: Set the sliding window length (e.g., 10 seconds) and step size (e.g., 1 second), and construct a time sliding window index; calculate the mean, variance, maximum, and minimum values ​​for the feature value set within each sliding window; if the feature exhibits a trend (e.g., a continuously decreasing signal-to-noise ratio), additionally calculate the first derivative as a rate of change indicator; concatenate these statistical values ​​and the derivative to form the feature vector of the window, creating an input unit with temporal context.

[0064] To enhance the retention of historical information from a distant period, the system also introduces an Exponential-Weighted-Smoothing (EWS) mechanism to emphasize the impact of recent data while preserving the structural outline of historical information. The processing logic is as follows: an exponential decay factor is set for the feature value at each time step; the current value is combined with the weighted value from the previous round during each update; a smooth vector sequence with temporal memory effect is obtained, enabling the model to give equal weight to both abrupt changes and trends.

[0065] Furthermore, for non-stationary signal features, such as speech tension curves or network latency jitter, the platform employs Fast Fourier Transform (FFT) to perform frequency domain transformation on the signal features within the sliding window, extracting the dominant frequency components and spectral energy distribution characteristics. These frequency domain metrics have proven effective for anomaly pattern detection and rapid fluctuation identification, particularly suitable for characterizing patterns in short-term high-risk states (such as intense motion or bursts of channel jitter).

[0066] Through the three types of temporal reconstruction techniques described above, the platform ultimately reconstructs the multidimensional features within each time window into time series vectors with a unified structure. These vectors are then concatenated in chronological order to form a "risk evolution trajectory" matrix. This trajectory not only preserves the contextual structure of instantaneous features but also effectively embeds state change trends, sudden feature responses, and long- and short-term dependency information, providing the model with a complete temporal expression.

[0067] Subsequently, the platform inputs the risk evolution trajectory into a pre-trained deep neural network model. This model integrates LSTM (Long Short-Term Memory) and attention mechanisms, possessing enhanced perception capabilities for long-range dependencies, key locations, and abrupt changes in the time series. Its internal processing logic is as follows: the LSTM structure is responsible for encoding the hidden state information of each time step in the trajectory, preserving the temporal dependencies in the historical input; the Attention module assigns weights to the output of each time step, identifying key time slices that influence the risk trend; the weighted feature sequence is then fully connected and mapped to output a risk discrimination result set.

[0068] The model's final output includes three main indicators: communication link failure probability, risk escalation probability, and suggested rescue level. Specifically: the communication link failure probability represents the likelihood of the link breaking or severely degrading within a certain time window; the risk escalation probability assesses whether the current user situation is trending towards a leap from mild to moderate / severe risk; and the suggested rescue level is output based on the model's internal strategy mapping, typically divided into multiple levels (e.g., 0-3) corresponding to platform dispatch strategies (e.g., notifying family members, triggering local emergency response, instructing the police system, etc.).

[0069] This phase of the design not only enhances the platform's ability to represent continuous temporal risks, but also achieves highly robust discrimination of various complex scenarios through the generalization capabilities of deep networks. This enables the system to possess real-time, intelligent, and dynamically adjustable risk identification capabilities, providing a solid predictive support foundation for downstream redundant scheduling and resource linkage. Through the quantification and discrimination of risk evolution trajectories, the platform achieves a closed-loop process from "data collection → behavior modeling → predictive output".

[0070] When the probability of communication link failure exceeds the failure probability threshold or the probability of risk escalation exceeds the escalation probability threshold, the system immediately executes an adaptive redundancy strategy: automatically switches to the suboptimal network channel and enables forward error correction (FEC), repeatedly broadcasts help packets to multiple city-level emergency call centers; at the same time, it expands the notification scope to family members, local volunteers and nearby police cars, pushes high-frequency locations to the command screen, and, if necessary, links drones or street light cameras to achieve continuous reachability, rescue capability and traceability in scenarios of channel interference or risk deterioration.

[0071] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0072] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A one-click emergency assistance and location service method, characterized in that: The service method includes the following steps: The user terminal establishes multiple communication links with the cloud emergency platform and generates a session ID. When the user sends an emergency signal, the user terminal uploads the original help request data to the cloud emergency platform. User terminals and cloud-based emergency platforms exchange data formats and transmission fingerprints through channels, and form the original help dataset after removing abnormal packets. Dynamic information is continuously collected during the duration of the help request session, and all newly added data is continuously written into the original help request dataset. The cloud-based emergency response platform performs feature engineering in real time on the original request for help dataset to extract indicators describing the evolution of the risk situation; The extracted features are converted into time series vectors and the resulting risk evolution trajectory is input into a pre-trained deep neural network model. The deep neural network model outputs risk discrimination results in real time and executes an adaptive redundancy strategy when a risk condition is triggered.

2. The one-click emergency assistance and location service method according to claim 1, characterized in that: The extracted features are converted into time series vectors and used to generate risk evolution trajectories, which are then input into a pre-trained deep neural network model. The deep neural network model outputs risk discrimination results in real time, including the following steps: The values ​​of each type of feature in the feature set are subjected to a sliding window operation within N time windows. An exponential decay weighting mechanism is introduced to emphasize the impact of recent data while preserving the structural outline of historical information. For non-stationary signal features, Fast Fourier Transform is used to perform frequency domain transformation on the signal features within the sliding window to extract the main frequency component and spectral energy distribution features; The multidimensional features within each time window are reconstructed into time series vectors with a unified structure. The time series vectors are then concatenated in chronological order to form a risk evolution trajectory matrix. The risk evolution trajectory is input into a pre-trained deep neural network model, which outputs the probability of communication link failure, the probability of risk escalation, and the recommended level of rescue.

3. The one-click emergency assistance and location service method according to claim 2, characterized in that: The deep neural network model processing logic is as follows: The LSTM structure is responsible for encoding the hidden state information at each time step in the trajectory and preserving the temporal dependencies in the historical input. The Attention module assigns weights to the output of each time step to identify key time slices that influence risk trends. The weighted feature sequences are mapped using a fully connected method to output a risk discrimination result set.

4. The one-click emergency assistance and location service method according to claim 3, characterized in that: User terminals and cloud-based emergency platforms exchange data formats and transmission fingerprints via a channel, and after removing abnormal packets, form the original distress data set, including the following steps: Each uploaded data frame is unpacked and its fields are mapped based on a predefined data interface protocol. For each data frame, call the field validation function to match the required options and formats in the protocol definition field by field, mark all missing fields or fields whose types do not match the preset template, and if the proportion of missing fields exceeds the threshold or key information fields are missing, mark the data frame as unprocessable and discard it. Parse the protocol version and transmission policy fields from the data frame and match them with the protocol version of the terminal registered in the current session. If the version numbers are inconsistent or the signature mechanism used is incompatible with the platform's current support, the data frame will not participate in the construction of the formal dataset and will be recorded in the version exception log for auditing. By performing differential comparison between the local clock and the terminal timestamp, and by verifying the SM3 digest value and MAC signature attached to the verification field, it is determined whether the ciphertext has been tampered with or damaged during transmission. The data frames that pass the verification are then aggregated to form the original help request dataset.

5. The one-click emergency assistance and location service method according to claim 4, characterized in that: The comparison is performed using the local clock and the terminal timestamp, and the judgment logic is as follows: Calculate the difference between the timestamp uploaded by the terminal and the current clock on the platform; If the absolute time difference exceeds the acceptable range, it is marked as a time drift anomaly; If multiple data frames are out of order, the out-of-order data will be temporarily cached and the logical order will be restored based on the timestamp; If the time drift exceeds the synchronization window, the merging of the data sequence will be aborted.

6. The one-click emergency assistance and location service method according to claim 5, characterized in that: When a user sends an emergency signal, the user terminal uploads the raw distress data to the cloud emergency platform, including the following steps: The logic for fusing and calculating location data from different sources is as follows: GNSS positioning is used as the primary input source, and basic weights are assigned to it. Based on historical signal-to-noise ratio trends, a time decay factor is introduced into Wi-FiRTT data to control its weight fluctuations within a short time window; Zero bias correction and cumulative drift removal are performed on the displacement data calculated by the IMU, and are only used as short-term enhancement compensation terms; The fused positioning coordinates are generated by weighted averaging, and a confidence score is attached as a measure of the reliability of the positioning coordinates. The collected data is standardized and boundary value detected to remove outliers and extract characteristic parameters such as the rate of change of acceleration and the rate of change of rotation angle as a preliminary basis for judging sudden changes in user behavior. If the user authorizes, the system calls the local or bound health device interface to extract physiological parameters. All collected data fields are structured and encapsulated locally to form the original help request data structure, which is then encrypted during the encrypted transmission process. The system uses the SM3 digest function to generate a verification value and binds a message authentication code.

7. The one-click emergency assistance and location service method according to claim 6, characterized in that: The encrypted transmission process then proceeds to encrypt the data, including the following steps: Serialize the structure; Using the symmetric key negotiated in the current session as the encryption key, the SM4 algorithm is used to perform encrypted block operations on the serialized data. The original data digest is generated using the SM3 digest algorithm and appended to the ciphertext; The MAC is calculated using the shared key to pair the ciphertext and digest, and then appended to the final message as a message authentication field. The generated encrypted message packets constitute a distress data frame and are sent to the cloud platform through the current communication link.

8. The one-click emergency assistance and location service method according to claim 7, characterized in that: The user terminal establishes multiple communication links with the cloud-based emergency platform and generates a session ID, including the following steps: The user terminal generates a temporary public-private key pair, sends the public key to the cloud emergency platform using the SM2 protocol, and receives the authentication signature and negotiation parameters returned by the cloud emergency platform; Both parties negotiated and derived a symmetric key through ECDH, and then all communication content was encrypted using SM4, supplemented by SM3 digest function for message integrity verification; After a successful handshake, the cloud-based emergency platform generates a session identifier that is bound to the current terminal session. This session identifier is embedded in the header of all subsequent data packets and is used as a data association identifier.

9. The one-click emergency assistance and location service method according to claim 8, characterized in that: After a successful handshake, the cloud-based emergency platform generates a session identifier bound to the current terminal session. The generation logic is as follows: The device identifier, timestamp, and handshake key digest are concatenated to form the initial input string; Use the SM3 digest function to hash the input string; The summary results are mixed with a random factor, and a double hash operation is performed. The hash result is truncated to a portion of its length and used as the Session-ID to identify the context of this session.

10. A one-click emergency assistance and location service system, used to implement the service method according to any one of claims 1-9, characterized in that: It includes an initialization module, a dataset generation module, a feature engineering execution module, and an adaptive adjustment module; Initialization module: Used to establish multiple communication links between user terminals and cloud emergency platforms and generate session IDs. When a user sends an emergency signal, the user terminal uploads the original help request data to the cloud emergency platform. Dataset generation module: The user terminal and the cloud emergency platform exchange data formats and transmission fingerprints through the channel, and form the original help dataset after removing abnormal packets; Feature engineering execution module: During the duration of the help request session, dynamic information is continuously collected and all new data is continuously written into the original help request dataset. The cloud emergency platform performs feature engineering in real time on the original help request dataset to extract indicators that describe the evolution of the risk situation. Adaptive adjustment module: The extracted features are converted into time series vectors and the risk evolution trajectory is generated and input into the pre-trained deep neural network model. The deep neural network model outputs the risk discrimination result in real time and executes the adaptive redundancy strategy when the risk condition is triggered.

Images