A mobile terminal electronic data protection method

Abstract

The application relates to the technical field of electronic data security processing, and discloses a mobile terminal electronic data protection method; when data is collected, time, equipment identification and position are synchronously acquired, a hash digest is calculated and is bound with encryption, a verification mark is generated, and a permission-free public verification entrance is provided; a unified collection interface is provided, seamless switching of video recording, audio recording, photographing and scanning is supported; in a high-safety mode, data is fragmented, encrypted and uploaded to the cloud for solidification, plaintext is not left in the local, and the plaintext is stored in a digital security safe; according to a native application or a small program platform, collection is adaptively adjusted, native application lock screen background audio recording and small program foreground keep-alive degradation are adopted; human face and password double verification are required for accessing the safe; abnormality is monitored in real time to trigger early warning, an independent one-key emergency help is provided, cloud data is permanently inalterable after abnormal disconnection; built-in AI fraud prevention identification is adopted to grade and identify suspicious content and link evidence storage and protection; and the application realizes cross-platform, full-link and high-trust mobile terminal electronic data protection.

Description

Technical Field

[0001] This invention relates to the field of electronic data security processing technology, specifically a method for protecting electronic data on mobile devices. Background Technology

[0002] With the widespread adoption of mobile devices, the demand for the collection, storage, and verification of electronic data in personal and commercial scenarios continues to rise, especially in scenarios involving personal safety, property protection, and dispute evidence collection. This places extremely high demands on the credibility, security, and continuity of electronic data collection. However, existing electronic data processing and security solutions suffer from numerous intractable technical shortcomings, as detailed below: Insufficient security of electronic data storage: After collection, electronic data is mostly stored in plaintext form locally with only simple encryption. It is easily tampered with, deleted, or lost. There is a lack of real-time protection mechanism that fixes data as it is collected. The original integrity and authenticity of the data cannot be effectively traced. It only realizes the function of data storage without full-process anti-tampering protection.

[0003] Data traceability relies on a single basis: the data collection process only records the core content itself and does not strongly bind the data content with multi-dimensional information such as time, unique device identifier, and geographical location. The data traceability relies on a single basis, and even if storage is completed, it is difficult to serve as a valid and credible credential. Moreover, existing hash verification tools only realize single data digest calculation and have not formed a complete and credible evidence storage link after multi-dimensional binding.

[0004] The verification threshold is too high: The data verification process has an extremely high threshold, requiring a dedicated account, paid permissions, or an internal closed system to complete the verification. Third parties cannot quickly and conveniently conduct data validity verification. The verification process is cumbersome and has very poor universality, failing to meet the needs for open and convenient verification.

[0005] The data collection mode is fragmented and lacks continuity: mobile terminal data collection mode is fragmented. Functions such as video recording, audio recording, and photo taking require switching to independent interfaces. The interface layout and core business logic cannot be reused, making the operation cumbersome and the adaptability poor. At the same time, due to the limitations of the terminal system and the running platform, the background data collection in the screen-locked and screen-off state of native applications is complex and consumes too much power. Lightweight mini-programs cannot achieve continuous background data collection at all. Locking the screen or switching to the background will cause the data collection to be interrupted, and the continuity of data recording cannot be guaranteed.

[0006] High-security data lacks independent isolation and control: In high-security scenarios, there is no dedicated digital security vault to achieve independent isolation and control of data. High-security data is stored together with ordinary data, which is prone to unauthorized access. Moreover, there are no mandatory fixed protection rules in the cloud, and data can be deleted or modified at will, lacking legal-level fixed protection.

[0007] Data is easily lost and untraceable under abnormal conditions: When the terminal experiences abnormal conditions such as network disconnection, forced exit of application, shutdown or uninstallation, the high-security data already collected has no permanent protection mechanism, making it extremely easy for data to be lost or tampered with. In addition, there is no location synchronization and retention mechanism under abnormal conditions, making it impossible to carry out security traceability afterwards.

[0008] The early warning and protection mechanisms are limited: the existing security solutions only have a single reminder mechanism, and there is no two-way independent and linked protection mechanism for passive abnormal intelligent early warning and active emergency assistance from users. The functions are incomplete and cannot take into account both passive risk monitoring and active emergency rescue scenarios. At the same time, data access only uses a single verification method, which makes the risk of unauthorized access extremely high.

[0009] Lack of linkage between anti-fraud and evidence preservation: In response to high-incidence risks such as telecom fraud and AI deepfake fraud, there is a lack of proactive and universally applicable risk identification and evidence preservation linkage mechanisms. It is impossible to intelligently analyze and classify fraud features in voice, text, and images. Anti-fraud identification, evidence preservation, risk warning, and emergency assistance are completely disconnected, failing to form a full-link protection, and users' property and information security cannot be effectively guaranteed.

[0010] Currently, existing technologies commonly include single hash evidence storage, ordinary audio and video capture, and basic anti-fraud identification. However, no solution can simultaneously achieve real-time multi-dimensional binding and solidification of electronic data, permissionless public verification, cross-platform adaptive collection, closed-loop management of digital security vaults, two-way emergency protection, and AI anti-fraud evidence storage linkage. This cannot meet the needs of highly reliable, highly secure, and all-scenario electronic data collection, storage, and security protection in mobile scenarios. Summary of the Invention

[0011] To address the shortcomings of existing technologies, this invention provides a method for protecting electronic data on mobile devices, thereby resolving the problems described in the background.

[0012] To achieve the above objectives, the present invention provides the following technical solution: a method for protecting electronic data on a mobile device, comprising: When collecting electronic data on a mobile terminal, time information, device unique identifier information, and real-time geographic location information are collected simultaneously. A hash digest value is calculated in real time for the collected electronic data. The hash digest value is then associated and bound with the time information, device unique identifier information, and geographic location information and stored in an encrypted manner. The associated hash digest value and multi-dimensional information are then synchronously uploaded to a cloud server for backup. Preferably, the electronic data includes at least one of the following: audio recording data, video recording data, image data, document data, screen operation trajectory data, and scanned PDF data.

[0013] A unique verification identifier is generated based on the associated binding data backed up in the cloud, and a public verification entry point that requires no login, no payment, and no registration is established for external verification. Preferably, after receiving the verification identifier, the public verification entry automatically retrieves the corresponding evidence data and outputs standardized verification information. The standardized verification information includes data integrity results, time validity results, device validity results, and location validity results, and supports exporting it as a standard format document.

[0014] It provides a unified data acquisition interface, supports dynamic and seamless switching between multiple data acquisition modes such as video recording, audio recording, photo taking, and scanning, and reuses a unified interface layout and core business logic. When the high-security protection mode is activated, the electronic data collected is encrypted in real time and uploaded to the cloud server. Once received by the cloud, the data is immediately fixed. The local terminal does not generate any accessible plaintext data files and stores the data in a dedicated digital security vault. Preferably, the storage area of ​​the digital security safe is differentiated and isolated according to the operating platform: The native mobile application platform uses a system-level independent encrypted storage space to achieve physical isolation; The lightweight mini-program platform uses in-application logically isolated storage areas to achieve logical isolation.

[0015] The acquisition mode is adaptively adjusted according to the operating status and operating platform type of the mobile terminal. The operating platform includes native mobile applications and lightweight mini-programs. Preferably, the adaptive adjustment of the acquisition mode specifically includes: on the native mobile application platform, when the terminal screen is locked, turned off, or there is no manual operation, stopping video acquisition and starting the background audio acquisition service to keep the process alive; on the lightweight mini-program platform, when the mini-program is detected to enter the background or lock the screen, generating a foreground keep-alive prompt and downgrading to the foreground-only audio acquisition mode.

[0016] After receiving uploaded data under high-security protection mode, the cloud server executes a preset protection period rule, during which only append writing is supported. Preferably, the mandatory protection period is a fixed duration preset by the cloud. During the protection period, only data appending is supported, and deletion, overwriting, and modification operations are not supported.

[0017] When users access data in the digital security vault, they must complete a dual verification process involving both biometric identity verification and digital access control. Preferably, the biometric identity verification is facial liveness verification, and the digital permission verification is a custom digital password verification. The two verifications are executed sequentially, and if either verification fails, the data access request is directly rejected.

[0018] It monitors the abnormal operating status of terminals and digital security vaults in real time. When an anomaly is detected, it automatically triggers an intelligent anomaly warning and uploads the terminal's real-time geographical location to the cloud. At the same time, it pushes a notification to the preset emergency contacts. It also sets up a user-initiated emergency assistance mechanism independent of the anomaly warning. After being triggered with one click, it sends a request for help and real-time location to the emergency contacts and simultaneously locks all data in the digital security vault. Preferably, the abnormal operating state includes at least one of the following: application forced exit, abnormal network disconnection, device shutdown, continuous authentication failure, and unauthorized access attempt.

[0019] When a mobile terminal experiences a network outage, is forcibly terminated, is powered off, or has its application uninstalled, the uploaded data received by the cloud and the data in the digital security vault will remain permanently in a fixed state that cannot be deleted or modified. The AI-powered fraud risk assessment identifies fraud risk characteristics in suspicious content and outputs only medium or high risk levels and their corresponding probabilities. All data and judgment results from the entire assessment process are stored synchronously in a digital security vault. In high-risk situations, abnormal warnings are automatically triggered or users can trigger emergency assistance with one click.

[0020] Preferably, the AI-based fraud risk assessment specifically includes: supporting three methods for submitting suspicious content: voice repetition recording, hands-free audio transcription, and image upload; performing AI semantic analysis and image forgery feature recognition based on a preset fraud risk feature database; synchronously collecting operation trajectory, device information, and geographical location information during the assessment process, and linking them with the risk assessment results; not making a judgment when information is insufficient and prompting for supplementary information or consultation with others.

[0021] Preferably, it also includes: sorting multiple evidence records under the same identifier in chronological order according to the time of collection, and matching the behavioral data and location data of each record to automatically generate a structured evidence chain package.

[0022] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention abandons the traditional approach of single hash verification and realizes strong binding of electronic data with multi-dimensional information such as time, device and location, as well as real-time hash encryption, which eliminates data tampering and forgery from the source. Combined with an access-free public verification entry, it not only solves the problem of high threshold of traditional verification, but also forms a complete and reliable evidence storage link, which is different from existing hash evidence tools on the market.

[0023] 2. This invention adopts a cross-platform adaptive collection mechanism to achieve differentiated collection protection based on the permission differences between native applications and mini-programs: On the native application platform, it solves the pain point of collection interruption when the screen is locked or in the background, as well as the problems of high power consumption and poor compatibility when collecting data in the background; on the mini-program platform, it solves the pain point of collection interruption in the foreground, taking into account the needs of dual-platform use, and has significant technological progress.

[0024] 3. This invention creates a fully closed-loop management system for digital security vaults, achieving physical and logical isolation across different platforms. Combined with dual-verification access, automatic locking in case of anomalies, one-click emergency freezing, and cloud-based mandatory protection period functions, it forms a complete high-security data protection link. There is no similar complete solution in the existing technology, demonstrating its strong originality.

[0025] 4. This invention constructs a two-way independent linkage mechanism between system anomaly early warning and user-initiated assistance, achieving full coverage of passive monitoring and active rescue. It simultaneously completes location uploading, data locking, and notification solidification, and permanently protects the data in the event of abnormal connection loss, completely solving the problems of single protection and easy data loss in existing solutions.

[0026] 5. This invention achieves integrated linkage of AI anti-fraud identification, credible evidence storage, and emergency protection. The entire identification process is evidence-storaged, and high-risk situations are automatically triggered for protection. Only the effective risk level is output to avoid misjudgment. It is suitable for use by all people and fills the gap in the existing technology where anti-fraud and evidence storage are separated.

[0027] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0028] Figure 1 This is a flowchart of the overall method of the present invention; Figure 2 This is a system module architecture diagram of the present invention; Figure 3 This is a flowchart illustrating the high-security protection mode and fragmented upload process of the present invention; Figure 4 This is a comparison chart of the adaptive acquisition modes of the present invention; Figure 5 This is a flowchart illustrating the access and dual verification process for the digital security safe of this invention. Figure 6 This is a flowchart illustrating the linkage between abnormal warning and proactive emergency assistance in this invention. Figure 7 This is a flowchart illustrating the AI-based fraud risk assessment process according to an embodiment of the present invention. Figure 8This is a flowchart illustrating the generation process of the structured evidence storage chain in an embodiment of the present invention. Detailed Implementation

[0029] Please see Figure 1-8 This invention discloses a mobile electronic data protection method. The following detailed description of the method, along with specific technical implementation details, provides a complete and clear overview. Those skilled in the art can implement this invention on different mobile operating systems (including but not limited to Android and iOS) and lightweight mini-program platforms (including but not limited to mini-programs from various apps) without creative effort, based on the technical solutions described in this embodiment. This embodiment uses a complete electronic data collection, storage, protection, and verification process as an example for illustration.

[0030] I. System Overall Architecture and Module Division The mobile electronic data protection system implementing this method is deployed on a mobile terminal (smartphone or tablet) and a cloud server. The mobile terminal includes the following functional modules: a multi-source synchronous acquisition module, a hash calculation and encryption module, a verification identifier generation and entry point setup module, a unified acquisition and mode switching module, a local proxy sub-module for the real-time cloud high-security protection module, a terminal status adaptive acquisition module, a local access interface for the digital security vault management module, a dual security verification module, a local monitoring unit for the abnormal status monitoring and intelligent early warning module, a proactive emergency assistance module, and a local acquisition unit for the AI ​​anti-fraud risk identification module. The cloud server includes: verification data storage service, high-security data storage service, mandatory protection period management service, abnormal early warning notification service, emergency assistance relay service, AI anti-fraud risk identification cloud inference service, public verification entry point web service, and structured evidence chain generation service.

[0031] The data flow between the above modules is as follows: the multi-source synchronous acquisition module acquires the original electronic data and multi-dimensional metadata, passes it to the hash calculation and encryption module to generate a hash digest and encrypt it; the encrypted data and metadata are synchronously uploaded to the cloud verification data storage service, and simultaneously, in high-security mode, they are fragmented and encrypted by the real-time cloud high-security protection module before being uploaded to the high-security data storage service; the digital security safe management module maintains data indexes and isolated storage areas in the cloud and locally respectively; the anomaly monitoring module and the proactive emergency assistance module independently monitor the system status and user commands, triggering corresponding cloud services; the AI ​​anti-fraud identification module sends the collected suspicious content to the cloud inference service, and after returning the risk level, it links the safe storage and early warning assistance modules. The specific execution process is described below in the order of the method steps.

[0032] II. Specific Implementation Steps: Step 1: Synchronous Collection of Multi-Source Data and Hash Binding Encryption 1. Data Acquisition Trigger and Multi-Source Information Acquisition After opening the unified data acquisition interface on their mobile device, users select video recording, audio recording, photo taking, or scanning mode and begin data acquisition. The multi-source synchronous acquisition module immediately performs the following operations: 1) Electronic Data Acquisition: Depending on the selected mode, the system calls the underlying APIs of the operating system to obtain the raw data stream. For example, in recording mode, audio is captured in Pulse Code Modulation (PCM) format using AudioRecord (Android audio recording class) or AVAudioRecorder (iOS audio recording class), with a sampling rate of 44.1kHz, a bit depth of 16bit, and mono; in video recording mode, H.264 encoded video streams are captured using Camera2 or AVCaptureSession; in photo capture mode, JPEG format images are captured; and in scanning mode, continuous frame acquisition and stitching are used to generate a PDF document.

[0033] 2) Time Information Synchronization Acquisition: At the moment of acquisition startup, the Coordinated Universal Time (UTC) timestamp is obtained from the mobile terminal's system clock, accurate to milliseconds. Let the acquisition start time be... Alternatively, use Date().timeIntervalSince1970*1000 (iOS) to simultaneously record the end time of data collection. For streaming data (audio and video recordings), the timestamp of each frame or data block is used as the basis, but for the sake of simplifying evidence preservation, the start and end time intervals are used.

[0034] 3) Device Unique Identifier Information Collection: Obtain the terminal's immutable hardware identifier. On the Android platform, the Android ID (Settings.Secure.ANDROID_ID) is used preferentially. If it cannot be obtained due to permission restrictions, a 64-bit pseudo-unique identifier generated by combining the MAC address (obfuscated by key hash) with the device serial number is used. On the iOS platform, identifierForVendor is used. Simultaneously, the device model string (e.g., "iPhone14,2" or "SM-S918B") and operating system version (e.g., "Android 13" or "iOS 16.4") are collected. All device information is concatenated into a string. .

[0035] 4) Real-time geographic location information acquisition: The system's location service is invoked, prioritizing the use of Global Positioning System (GPS) sensors to obtain longitude, latitude, altitude, and height accuracy (HPE) estimates. If GPS signals are unavailable, positioning is based on Wi-Fi or cellular networks. Let the acquired geographic location coordinates be... ,in Longitude (-180 to 180). The latitude (-90 to 90) is recorded, along with the positioning timestamp. And the location method (e.g., "gps" or "network"). Combine the coordinates and location method into a string. .

[0036] 5) Screen Operation Trajectory Data Acquisition: When the user selects "Screen Recording" mode or the system automatically starts recording in high-security mode, the module obtains the screen content frame sequence by calling the operating system's screen capture API (MediaProjection for Android, ReplayKit for iOS). Simultaneously, it registers an AccessibilityService or gesture listener to collect the user's touch coordinates, swipe trajectories, key press sequences, and other operation events. The screen content frames are compressed using H.264 encoding, and the operation event sequences are recorded in JSON format with timestamps. Both together constitute the screen operation trajectory data. This data undergoes hash calculations and multi-dimensional information binding in the same way as audio and video data.

[0037] 2. Real-time hash digest calculation The hash calculation and encryption module performs block hash calculations on the collected raw binary stream of electronic data. Let the total length of the raw data be... Bytes. To balance real-time performance and integrity, a combination of sliding window hashing and final overall hashing is used: For streaming data (audio recording, video recording), each collection For each data block, immediately calculate its SHA-256 (Secure Hash Algorithm 256-bit) hash value:

[0038] in Each It is a 256-bit binary string, which is 64 bytes long when converted to a hexadecimal string.

[0039] Once the data collection is complete, calculate the final hash value of the entire dataset:

[0040] At the same time, after concatenating all the block hashes in order, the hash is calculated again to obtain the block chain hash:

[0041] in This indicates string concatenation.

[0042] The final data hash digest value used for binding is taken as follows: and The combination, namely This allows for simultaneous support of overall integrity verification and segmented retransmission verification.

[0043] 3. Multi-dimensional information association, binding, and encrypted storage The collected multidimensional information and hash digest values ​​are concatenated into a structured string according to a predefined format. :

[0044] in The capture mode is identified (0 = audio recording, 1 = video recording, 2 = photo taking, 3 = scanning, 4 = screen recording). Then, the symmetric encryption algorithm AES-256-GCM (Advanced Encryption Standard 256-bit Galois / counter mode) is used to... Perform encryption. Set the encryption key. Generated through negotiation with the server during user login (based on a TLS session), or using a one-time session key in high-security mode. Encryption process:

[0045] in Initialize a 12-byte random vector. It is encrypted. An authentication tag is also generated to prevent tampering. Finally, , , And a local encrypted cache of the original electronic data (the original data encrypted using the same key) is stored in the mobile terminal's private storage directory. Meanwhile, , , Non-sensitive metadata (excluding raw data) is also synchronously uploaded to the cloud for verification data storage services.

[0046] Step 2: Verification Identifier Generation and Access-Free Public Verification Entry After receiving the encrypted binding data C and its auxiliary information, the cloud server generates a globally unique verification identifier, evidenceId, for each evidence record. The evidenceId uses a standardized globally unique ID rule: "uppercase prefix + 17-bit UTC precise timestamp (YYYYMMDDHHmmssSSS) + 6-bit zero-padded random number." The default prefix is ​​EVI, for example: EVI202604182005301234567890. This ID rule supports compatibility with hundreds of millions of data entries, format validity verification, and reverse extraction of generation time, ensuring the global uniqueness and traceability of the ID across different platforms.

[0047] The system builds an independent web service, providing a public verification portal that requires no login, no payment, and no registration. This portal accepts HTTP GET requests. At the same time, the mini-program generates an additional mini-program code bound to the evidenceId, which users can scan with WeChat to directly access the verification page without manually entering the link.

[0048] Any third party (without any identity credentials) can access the verification portal via a link or QR code. The backend service queries the database based on the evidenceId, retrieves the corresponding encrypted C, IV, and Tag, and decrypts them using the same session key Ksession as the stored string to obtain the original structured string M. Then, it extracts Tstart, Tend, DeviceID, GeoInfo, Hfinal, and Mode from M. The verification process automatically performs the following four checks: 1) Data integrity verification: Based on the original data length and block hash recorded at the time of notarization, recalculate the hash value of the currently provided electronic data (if a third party has uploaded a data file to be verified), or directly compare whether the notarized Hfinal is consistent with the hash extracted from the cloud.

[0049] 2) Time validity verification: Determine whether Tstart and Tend are within a reasonable range (e.g., no later than the current time and no earlier than 1970), and verify whether the timestamp is issued by a trusted time source (in this embodiment, the server receiving time and the built-in timestamp of evidenceId are used for dual-dimensional verification).

[0050] 3) Device validity verification: Check whether the DeviceID format is correct. The native application can optionally match it with the device manufacturer's registration database, while the mini-program verifies whether the binding relationship between DeviceID and user openid is valid; at the same time, it verifies the validity of the evidenceId format.

[0051] 4) Location validity verification: Verify whether the latitude and longitude in GeoInfo are within the geographic feasible region (e.g., not in obviously abnormal locations such as the center of the ocean).

[0052] The final output is a standardized verification result, returned in JSON format, containing the fields: integrity (pass / fail), time_valid, device_valid, and location_valid. It also supports exporting to PDF or XML documents, and the output format is completely consistent between native applications and mini-programs.

[0053] Step 3: Unified data collection interface and dynamic switching between multiple modes The unified acquisition and mode switching module implements a single Activity / ViewController on the mobile device, containing a preview view (SurfaceView / PreviewView) and a set of mode switching buttons. All modes reuse the same recording control logic (start, pause, stop, re-record) and parameter setting interface (resolution, bitrate, sampling rate). When the user clicks the "Record" button, the module internally reconfigures the camera and microphone parameters; clicking "Record Audio" disables the camera preview but continues audio acquisition; clicking "Take Photo" temporarily switches to high-resolution still capture; clicking "Scan" enables continuous frame capture and automatically generates a PDF using an edge detection algorithm. When the "Screen Recording" button is clicked, the system requests screen capture permission (prompted upon first use), and after authorization, begins recording screen content and operation events, storing them in the / screenrecords / directory. The switching process does not destroy the current interface; it only changes the underlying data acquisition pipeline, achieving flicker-free switching. Storage paths are differentiated according to mode: video files are saved to the / videos / subdirectory, audio recordings to / audios / , photos to / images / , and scanned PDFs to / documents / .

[0054] Step 4: High-security protection mode and real-time sharding encryption for cloud deployment Users can manually enable "High Security Protection Mode". Once enabled, the real-time cloud-based high security protection module will initiate the following process: 1. Real-time sharding: The raw data stream accumulates... The data (or time slices of 2 seconds, whichever is smaller) is used as a slice. .

[0055] 2. Independent Encryption: Each shard uses a temporarily generated random key. (256-bit) Encrypted using AES-256-GCM to obtain the ciphertext. Then use the server's (Rivest-Shamir-Adleman asymmetric encryption algorithm) public key (2048 bits) encryption get .

[0056] 3. Upload and save: [This will...] and Together, they are uploaded to a high-security cloud data storage service. Upon receiving the fragment, the cloud immediately writes it to persistent storage (such as distributed object storage) and returns the fragment sequence number and confirmation message. Upon receiving confirmation, the local terminal immediately deletes the plaintext and temporary encryption key of the fragment, ensuring that no inaccessible plaintext data files remain locally. It is important to clarify that in high-security mode, all collected data is uploaded to the cloud in real time via this method and stored in a dedicated digital security vault in the cloud. The mobile terminal only retains necessary encrypted fragment metadata for resuming interrupted downloads, and this metadata cannot be directly parsed into the original content by any regular application interface, thus achieving physical-level security isolation of "no plaintext locally, independent cloud management."

[0057] 4. Cloud-based mandatory protection period: All uploaded fragments are associated with the same evidence storage record. The cloud-based mandatory protection period management service sets an end time for the protection period of this record. ,in A fixed duration is preset (e.g., 15 days). During the protection period, no API call (including the user's own) is allowed to perform deletion, overwrite, or modification operations; only appending new shards is permitted. After the protection period ends, the data is converted to normal storage, but the immutable hash chain is still retained.

[0058] Step 5: Adaptive Acquisition Mode (Native Application vs. Mini Program) The terminal status adaptive acquisition module monitors the terminal's operating status (foreground / background, screen on / off, user operation) and operating platform type in real time. Specific execution logic is platform-specific: 1. Native mobile application platforms (Android / iOS) When the application is detected to be in the background or the screen is locked, the module calls the onPause or UIApplicationDidEnterBackground callback to immediately stop video capture (releasing camera resources). At the same time, it starts a foreground service (Android) or configures and activates a background audio session (iOS: configure the audio value of UIBackgroundModes in Info.plist, and use the setCategory:withOptions: method of AVAudioSession to set the category to AVAudioSessionCategoryPlayAndRecord and activate it). Through this background audio session (iOS), the system is declared to have an audio background mode, so as to minimize the probability of the application being suspended by the system after entering the background and prevent the system from recycling it.

[0059] The service continuously captures microphone audio and strives to ensure uninterrupted recording while adhering to the background operation policies of each mobile operating system, using WakeLock (Android) or keeping the background audio session active (iOS).

[0060] Audio data continues to be uploaded to the cloud in the aforementioned segmented and encrypted manner to ensure uninterrupted recording. Power consumption optimization: Only the minimum hardware modules required for audio acquisition (audio codec, network) are retained, and screen rendering and high-frequency GPS updates are disabled (reduced to once every 5 minutes).

[0061] When the application returns to the foreground or the screen is unlocked, video capture and high-frequency GPS positioning are automatically resumed.

[0062] 2. Lightweight mini-program platforms (WeChat mini-programs, etc.) Mini programs cannot run continuously in the background. When the onHide event is detected (the mini program switches to the background) or the user locks the screen, the module immediately generates a native keep-alive prompt at the top of the interface (via showModal or a custom toast), informing the user that "the capture has been downgraded to foreground-only audio mode, please do not switch applications." At the same time, the automatic downgrade capture strategy is implemented: all video and image capture is stopped, only the recording function is retained, and the recording is only valid while the mini program is in the foreground.

[0063] If the mini-program is killed by the system, the uploaded data segments are already stored in the cloud, and the unuploaded segments will be temporarily stored locally until the user is prompted to resume uploading the next time the mini-program is launched. When the mini-program returns to the foreground, it will automatically restore the original capture mode (such as video recording or photo taking) and attempt to upload the incomplete segments.

[0064] This adaptive mechanism ensures maximum data collection continuity for both platforms under their respective permission restrictions, and the differentiated descriptions fully reflect actual technical capabilities.

[0065] Step 6: Independent isolation and dual verification of the digital security safe The digital security vault management module maintains an independent logical container for each user in the cloud. Data within this container (all audio recordings, videos, photos, documents, AI-generated records, etc., generated under high-security protection mode) is isolated through the following methods: Native application platform: A system-level encrypted storage space (Android's EncryptedFile or iOS's DataProtection level of NSFileProtectionComplete) is used locally on the device, physically isolated from the regular application data directory. A separate access policy is set for the corresponding storage bucket in the cloud, allowing only specific API calls from the vault module.

[0066] Mini Program Platform: No plaintext data is stored locally; all safe data resides solely in the cloud, with logical isolation achieved through database row-level access control. Each data record carries a user ID and a safe tag `is_safe=1`, which is automatically filtered out by regular queries.

[0067] Furthermore, none of the data within this safe deposit box supports any form of automatic classification, transfer, or organization. Users must manually extract, classify, and organize the data through a dedicated interface. Each manual operation is recorded in an operation log to ensure the controllability and audit traceability of data management.

[0068] The dual security verification module is responsible for controlling user access to the data inside the safe. When a user requests to view the data, the following sequential process is executed: Biometric identity verification: This involves calling the mobile terminal's face recognition API (Android's BiometricManager, iOS's LocalAuthentication's LAPolicyDeviceOwnerAuthenticationWithBiometrics). The user must face the camera to complete a liveness detection (requiring actions such as blinking and head turning). A temporary token is generated upon successful verification. Valid for 30 seconds.

[0069] Numerical authentication: The user enters a pre-set 6-digit numeric password (or a more complex custom numeric string). The front end compares the password with a password hash stored on the server (hash-salted using PBKDF2). Upon successful matching, a password is generated. .

[0070] Two-factor authentication successful: The backend returns the decryption key for the vault data only when both tokens are valid and associated with the same session, allowing the user to view the plaintext data. Access is denied immediately if either authentication fails, and the number of failed attempts is recorded. An exception lock is triggered after 5 consecutive failures (see step eight).

[0071] Step 7: Abnormal Status Monitoring, Intelligent Early Warning, and Proactive Emergency Assistance 1. Definition and monitoring of abnormal states The abnormal status monitoring and intelligent early warning module runs continuously in the background of the mobile terminal, monitoring the following events: Forced application exit: Listen for onStop or UIApplicationWillTerminate and send a heartbeat to the server before exiting; if the server does not receive a heartbeat for 10 consecutive seconds, it is considered an abnormal exit.

[0072] Network Abnormal Disconnection: Monitors network connectivity status via NetworkCallback and is triggered when switching from Wi-Fi / cellular to no network.

[0073] Device shutdown: Register a shutdown broadcast (Android's ACTION_SHUTDOWN). iOS cannot listen to it directly, but it can be inferred from the last heartbeat time.

[0074] Continuous authentication failures: The number of failed double verifications is recorded locally, and triggering occurs when the number reaches 5.

[0075] Unauthorized access attempt: A Vault API call from an unknown device or IP was detected.

[0076] 2. Intelligent Early Warning Process for Anomalies When any of the above anomalies is detected, the module will automatically execute: 1) Location synchronization and retention: Immediately access GPS to obtain the current real-time geographical location. The event data, along with its timestamp, is uploaded to the cloud-based exception event table and permanently stored, never to be deleted.

[0077] 2) Alert Notification Push: Send alert messages to the user's preset emergency contacts (mobile phone number or email address) via cloud push service (such as Firebase Cloud Messaging). The message reads: "Your contact [username]'s mobile electronic data protection system detected an abnormal status [abnormality type] at [time], last location: [latitude and longitude link]." 3) Data protection: If the anomaly type is "continuous verification failure" or "unauthorized access", the digital security vault will be automatically locked, prohibiting any data access until the user passes a higher level of verification (such as customer service intervention).

[0078] 3. User-initiated emergency assistance mechanism Independent of anomaly alerts, users can click the "SOS Emergency Help" button with one click on the data collection interface or the safe interface. After the proactive emergency help module responds: Send a distress message immediately: Send a map link containing a preset distress text (such as "I am in danger and need help") and your real-time location to all emergency contacts.

[0079] Synchronously lock the safe: Call the cloud API to set the status field of the current user's safe to locked=true, all read and write operations are denied, and only appending exception logs is allowed.

[0080] Notification Permanent: All data related to this request for assistance (trigger time, location, lock record) will be permanently stored in the cloud and cannot be modified or deleted.

[0081] The notifications and location data generated by both mechanisms are stored in a separate "protection log" table, which is protected by the same immutability as a safe.

[0082] Step 8: Permanent Protection Against Abnormal Disconnections When a mobile terminal experiences a network outage, application forced exit, device shutdown, or application uninstallation, the uploaded data already received in the cloud and the data in the digital security vault will automatically fall under the management scope of the permanent protection module for abnormal disconnection. This module sets a flag `permanent_protection=true` for each data record in the database. Once set, any data operation (including administrators) will be unable to perform `DELETE` or `UPDATE`, allowing only `SELECT`. Even if the user subsequently logs back in or restores the network, this data cannot be deleted or modified. This permanent protection differs from a mandatory protection period: a mandatory protection period is temporary and immutable over time, while abnormal disconnection protection is absolutely immutable without time limits, suitable for critical evidence that has been uploaded but whose collection process was abnormally interrupted.

[0083] Step 9: AI-powered fraud risk assessment process The AI-powered anti-fraud risk identification module offers three methods for submitting suspicious content: Voice repetition recording: The user repeats the suspicious conversation content into the microphone, and the system records 3 to 30 seconds of audio.

[0084] Hands-free recording and transcription: The user plays an existing suspicious recording file, the system extracts the audio and automatically calls the speech recognition (ASR) engine to transcribe it into text.

[0085] Image Upload: Users can upload suspicious screenshots or photos (such as forged transfer vouchers or facial images).

[0086] 1. Risk Feature Extraction For the text (transcribed result): Calculate the TF-IDF (Term Frequency-Inverse Document Frequency) vector and input it into the Transformer-based fraud semantic classification model. The model outputs the fraud probability. The model training data includes corpora of fraudulent statements related to impersonating law enforcement officials, "pig butchering" scams, and fake investments.

[0087] For images: Use a pre-trained deep forgery detection model (such as the EfficientNet-B4 architecture) to extract forgery traces and output the forgery probability. .

[0088] 2. Risk classification and determination Based on the comprehensive multimodal characteristics, the final risk level R is determined by the following formula:

[0089] in and The probability values ​​are for text and image, respectively; if only one modality is submitted, the probability of that modality is taken. When information is insufficient (e.g., speech-to-text failure, image without valid content), the model outputs "Unable to determine" and prompts the user to provide additional information or consult others.

[0090] 3. Full evidence preservation and collaborative process throughout the identification process The following data were collected simultaneously during the assessment process and linked to the risk assessment results: Operation trajectory: user submission time, submission method (voice / recording / image), IP address, device fingerprint.

[0091] Device information: Same as step 1 for triggering data acquisition and multi-source information acquisition. .

[0092] Geographic location information: Same as step 1 for triggering data collection and acquiring multi-source information. .

[0093] Link these metadata with risk levels probability value The original suspicious content (encrypted) is stored together with the data in the user's cloud database, and an independent verification identifier is generated (sharing the same verification entry point as ordinary evidence storage). If a high-risk condition is identified, the module automatically triggers an intelligent anomaly warning (in the same intelligent anomaly warning process) and displays a one-click emergency help button to the user (in the same user-initiated emergency help mechanism). Users can also actively click for help, achieving integrated linkage between anti-fraud identification, trusted evidence storage, and emergency protection.

[0094] Step 10: Generation of Structured Evidence Storage Chain Packet For multiple evidence records associated with the same verification identifier (such as audio recordings, photos, and AI identification results generated successively during an emergency request for help), the structured evidence chain generation service performs the following operations in the cloud: Time sequence sorting: based on each record Sort the fields in ascending order to get the sequence. .

[0095] Behavior and location association matching: Behavioral data here includes, but is not limited to, the collection mode of each evidence record (audio / video / photo), AI identification operations, keyframe summaries of screen operation trajectories, and user-triggered help / warning events; the system will calculate the time difference between two adjacent records. And the Euclidean distance of the geographical location (converting latitude and longitude to meters). Simultaneously, semantic matching is performed on the behavior types of the preceding and following records. For example, if the preceding record is a "screen recording" record and the following record is an "AI image upload identification" record, and the two are strongly correlated in terms of time and location, then they are determined to be a continuous behavior chain under the same risk event; that is, if Seconds and If the number of meters is equal, it is determined to be a continuous chain of behaviors; otherwise, it is marked as a behavior interruption.

[0096] Generate a chain of evidence: Package all records and their relationships into a single JSON structure containing fields such as chain_id, records (each record includes verification identifier, time, location, hash, risk level, etc.), and links (the spatiotemporal relationships between adjacent records). This chain can be exported as a whole as PDF or XML, and the overall hash of the chain can be signed using a digital signature (such as Ed25519) to ensure its integrity and credibility after export.

[0097] III. Summary of Implementation Examples The above fully elucidates the specific implementation of this invention, from multi-source data collection, hash binding, permission-free verification, unified interface, high-security fragmented uploading, adaptive platform collection, digital safe isolation and dual verification, anomaly warning and proactive assistance, permanent protection against abnormal connection drops, AI-powered anti-fraud full-process identification, to the generation of structured evidence storage chain packages. All steps can be deployed in software form on current mainstream mobile terminals and cloud servers, requiring no special hardware, and feasible solutions conforming to their respective permission models are provided for native applications and mini-program platforms.

Claims

1. A method for protecting electronic data on a mobile device, characterized in that, include: When collecting electronic data on a mobile terminal, time information, device unique identifier information, and real-time geographic location information are collected simultaneously. A hash digest value is calculated in real time for the collected electronic data. The hash digest value is then associated and bound with the time information, device unique identifier information, and geographic location information and stored in an encrypted manner. The associated hash digest value and multi-dimensional information are then synchronously uploaded to a cloud server for backup. A unique verification identifier is generated based on the associated binding data backed up in the cloud, and a public verification entry point that requires no login, no payment, and no registration is established for external verification. It provides a unified data acquisition interface, supports dynamic and seamless switching between multiple data acquisition modes such as video recording, audio recording, photo taking, and scanning, and reuses a unified interface layout and core business logic. When the high-security protection mode is activated, the electronic data collected is encrypted in real time and uploaded to the cloud server. Once received by the cloud, the data is immediately fixed. The local terminal does not generate any accessible plaintext data files and stores the data in a dedicated digital security vault. The acquisition mode is adaptively adjusted according to the operating status and operating platform type of the mobile terminal. The operating platform includes native mobile applications and lightweight mini-programs. After receiving uploaded data under high-security protection mode, the cloud server executes a preset protection period rule, during which only append writing is supported. When users access data in the digital security vault, they must complete a dual verification process involving both biometric identity verification and digital access control. Real-time monitoring of abnormal operating status of terminals and digital security vaults; when an abnormality is detected, automatic intelligent warning of abnormality is triggered, and the real-time geographical location of the terminal is uploaded to the cloud, while pushing notifications to preset emergency contacts; At the same time, a user-initiated emergency assistance mechanism, independent of abnormal warnings, is set up. Once triggered with one click, it sends assistance information and real-time location to emergency contacts and simultaneously locks all data in the digital security vault. When a mobile terminal experiences a network outage, is forcibly terminated, is powered off, or has its application uninstalled, the uploaded data received by the cloud and the data in the digital security vault will remain permanently in a fixed state that cannot be deleted or modified. The AI-powered fraud risk assessment identifies fraud risk characteristics in suspicious content and outputs only medium or high risk levels and their corresponding probabilities. All data and judgment results from the entire assessment process are stored synchronously in a digital security vault. In high-risk situations, abnormal warnings are automatically triggered or users can trigger emergency assistance with one click.

2. The mobile terminal electronic data protection method according to claim 1, characterized in that, The adaptive adjustment of the acquisition mode specifically includes: On native mobile application platforms, when the terminal is detected to be locked, screen off, or without human operation, video capture is stopped and a background audio capture service is started to keep the process alive. On the lightweight mini-program platform, when a mini-program is detected to be in the background or locked, a foreground keep-alive prompt is generated and the mode is downgraded to foreground-only audio capture mode.

3. The mobile terminal electronic data protection method according to claim 1, characterized in that, The storage areas of the digital security safe are differentiated and isolated based on the operating platform: The native mobile application platform uses a system-level independent encrypted storage space to achieve physical isolation; The lightweight mini-program platform uses in-application logically isolated storage areas to achieve logical isolation.

4. The mobile terminal electronic data protection method according to claim 1, characterized in that, The AI-based fraud risk assessment specifically includes: It supports three methods for submitting suspicious content: voice repetition recording, hands-free audio transcription, and image upload. Semantic analysis and image forgery feature recognition are performed based on a pre-defined fraud risk feature database; The identification process simultaneously collects operation trajectory, equipment information, and geographical location information, which are then linked and bound to the risk assessment results. If the information is insufficient, no judgment will be made and you will be prompted to provide additional information or consult others.

5. A method for protecting mobile electronic data according to claim 1, characterized in that, The abnormal operating states include at least one of the following: application forced exit, abnormal network disconnection, device shutdown, continuous authentication failure, and unauthorized access attempts.

6. The mobile terminal electronic data protection method according to claim 1, characterized in that, The mandatory protection period is a fixed duration preset by the cloud. During the protection period, only data appending is supported, and deletion, overwriting, and modification operations are not supported.

7. A method for protecting mobile electronic data according to claim 1, characterized in that, The biometric identity verification is a facial liveness verification, and the digital permission verification is a custom digital password verification. The two verifications are executed sequentially, and if either verification fails, the data access request is directly rejected.

8. A method for protecting mobile electronic data according to claim 1, characterized in that, Also includes: Multiple evidence records associated with the same identifier are sorted chronologically according to the time of collection, and the behavioral data and location data of each record are matched and associated to automatically generate a structured evidence chain.

9. A method for protecting mobile electronic data according to claim 1, characterized in that, The electronic data includes at least one of the following: audio recording data, video recording data, image data, document data, screen operation trajectory data, and scanned PDF data.

10. A method for protecting mobile electronic data according to claim 1, characterized in that, After receiving the verification identifier, the public verification portal automatically retrieves the corresponding stored evidence data and outputs standardized verification information. The standardized verification information includes data integrity results, time validity results, device validity results, and location validity results, and supports exporting it as a standard format document.

Images