A mobile phone file backup method and system based on intelligent hardware

Abstract

The present invention discloses a mobile phone file backup method and system based on intelligent hardware. The present invention comprises the following steps: the intelligent hardware receives device connection information sent by a mobile terminal device, responds to a binding request, and completes binding with the mobile terminal device; establishes an encrypted communication tunnel with the mobile terminal device based on preset encryption rules, and performs encryption and decryption processing on file storage instructions subsequently sent by the mobile terminal device; receives file storage instructions sent by the mobile terminal device, stores content of different types of file information based on preset storage rules combined with file access frequency and sensitivity level, and dynamically adjusts the storage location; obtains file query instructions, processes the file query instructions based on preset storage rules and different types of file query rules, and generates file query information; and sends file backup instructions to a cloud service device based on preset upload rules to realize cross-platform file backup.

Description

Technical Field

[0001] The present invention relates to the technical field of multimodal data processing, and in particular to a mobile phone file backup method and system based on intelligent hardware. Background Art

[0002] Existing mobile phone file backup technology has obvious limitations in many aspects. At the file storage management level, existing technologies lack intelligent storage strategies. On the one hand, targeted storage arrangements are not made for files of different types, sizes, sensitivity levels, and access frequencies. For example, large files and small files are treated equally, without considering the time-consuming transmission and large storage space occupied by large files, resulting in low backup efficiency and waste of storage resources. For sensitive files, no special encrypted storage method is adopted, which exposes sensitive information to greater security risks. On the other hand, existing technologies lack flexibility and intelligence in the dynamic adjustment of storage locations. Once a file is stored in a certain location, it is rarely dynamically optimized based on changes in its usage frequency and sensitivity level, making it impossible to achieve efficient use of storage resources.

[0003] Existing technologies for cross-platform backup have numerous shortcomings. When it comes to backing up mobile phone files to multiple cloud platforms, there's a lack of comprehensive consideration of the specific characteristics of each cloud platform. Different cloud platforms differ significantly in storage costs, encryption mechanisms, and geographical node distribution, but existing backup technologies often fail to fully leverage these differences to select the optimal cloud platform for different file types. This can lead to issues during the backup process, such as excessively high storage costs, insufficient data security, and slow file transfer speeds due to geographical node restrictions.

[0004] When it comes to document search and retrieval, traditional keyword-matching methods are no longer able to meet users' growing needs. This approach simply compares the textual content of documents and fails to understand their semantic meaning. For example, when a user searches for "smart hardware-related information," if the keyword "smart hardware" doesn't directly appear in the document, even if the document's content is closely related to smart hardware, it will not be retrieved. This results in the omission of a large number of useful documents, reducing query accuracy and efficiency. Summary of the Invention

[0005] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0006] A mobile phone file backup method based on intelligent hardware is applied to intelligent hardware, comprising: receiving device connection information sent by a mobile terminal device, and responding to a binding request to complete the binding with the mobile terminal device; establishing an encrypted communication tunnel with the mobile terminal device based on a preset encryption rule, and performing encryption and decryption processing on the file storage instructions subsequently sent by the mobile terminal device; receiving the file storage instruction sent by the mobile terminal device, storing the content of different types of file information based on the preset storage rule in combination with the file access frequency and sensitivity level, and dynamically adjusting the storage location, wherein the preset storage rule is used to characterize the storage processing of files based on the file diversion rule, Key documents are stored in multiple copies and shards, and a parity check algorithm is used to ensure data recovery in the event of a single point of failure; file query instructions are obtained, and the file query instructions are processed based on preset storage rules and different types of file query rules to generate file query information. Among them, different types of file query rules include building semantic vector indexes for document files, extracting visual features and audio features for images and videos respectively, supporting similarity retrieval based on sample images and voice clips, integrating file creation time, modifier, and sensitivity level data, and providing a multi-condition combination query interface; file backup instructions are sent to cloud service devices based on preset upload rules to achieve cross-platform file backup.

[0007] A mobile phone file backup system based on intelligent hardware includes: a mobile terminal device sends ultrasonic coding information containing a mobile terminal device identifier to a target edge device through an APP to discover and bind the target edge device in the same local area network; an encrypted communication tunnel is established with the target edge device based on preset encryption rules, and file storage instructions subsequently sent to the target edge device are encrypted and decrypted; file storage instructions including pictures, videos, and documents are sent to the target edge device, so that the target edge device stores content of different types of file information based on preset storage rules; the file storage instructions sent by the mobile terminal device are received by the intelligent hardware, and content of different types of file information is stored based on preset storage rules, wherein the preset storage rules are used to characterize storage processing of files based on file diversion rules; a file query instruction is received, and the file query instruction is processed based on the preset storage rules to generate file query information; a file backup instruction is sent to a cloud service device based on preset upload rules to realize cross-platform file backup.

[0008] The beneficial effects are as follows: The present invention provides a mobile phone file backup method based on intelligent hardware, intelligent file diversion and dynamic storage management, and dynamically adjusts storage strategies based on file type, size, sensitivity level, and access frequency: sensitive files are stored locally with encryption, and automatic cloud upload is prohibited; media files are stored locally before being uploaded to the cloud during off-peak hours, optimizing network resources; documents are uploaded in real time or at night based on size, and the storage location is dynamically adjusted based on access frequency (for example, high-frequency files are stored on SSDs, and low-frequency sensitive files are encrypted and stored on HDDs). This achieves refined allocation of storage resources, balancing security, efficiency, and cost. For example, large files can be uploaded at night to avoid occupying office bandwidth, and high-frequency files can be stored on high-speed media to improve access speed.

[0009] Cross-platform intelligent backup and dynamic scheduling dynamically generate upload strategies based on file attributes (type, size, sensitivity level) and cloud platform characteristics (storage cost, encryption mechanism, and regional nodes). By comparing multiple platforms and using range analysis to determine the optimal upload target (e.g., prioritizing enterprise-grade encrypted cloud drives for sensitive files), upload priorities are dynamically adjusted based on real-time network bandwidth and cloud service load (prioritizing high-frequency files and staggering large file uploads). This enables intelligent scheduling of cross-platform backups, balancing compliance (e.g., ensuring data remains within the country), cost optimization (selecting low-cost cloud drives), and transfer efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A flowchart of a mobile phone file backup method based on intelligent hardware provided by an embodiment of the present invention when applied to an edge device;

[0011] Figure 2 A schematic diagram of a module of a mobile phone file backup system based on intelligent hardware provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0012] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention and are not intended to limit the present invention. Figure 1 To describe the mobile phone file backup system and implementation method based on smart hardware according to the exemplary embodiment of this application. In one embodiment, this application also proposes a mobile phone file backup method based on smart hardware. Figure 1 As shown:

[0013] In an embodiment of the present application, a mobile phone file backup method based on smart hardware is applied to smart hardware, such as Figure 1 As shown:

[0014] S101, receiving device connection information sent by a mobile terminal device, and responding to a binding request to complete binding with the mobile terminal device.

[0015] In one implementation, the mobile terminal sends device connection information. Specifically, the mobile app transmits an ultrasonic code containing the device's unique identifier through a speaker. The code consists of "device ID + timestamp + check digit." The device ID is the phone's IMEI number (e.g., 861234567890123), the timestamp records the time of transmission (e.g., 202506301530), and the check digit is used to verify the integrity of the information (e.g., EF). Within the same local area network, the phone continuously transmits ultrasonic signals at 500 millisecond intervals for 30 seconds until a response is received from the intelligent hardware, ensuring device discovery in a network-free environment.

[0016] Smart hardware (such as Yunbao) receives ultrasonic signals through a microphone, filters high-frequency sound waves (above 20kHz), and decodes them using signal processing techniques to obtain the device ID, timestamp, and check digit. Yunbao performs an integrity check on the decoded information: it uses the same algorithm to calculate the checksum of the device ID and timestamp and compares it with the received check digit (e.g., EF). If the timestamp is older than 5 minutes or the check fails, the request is ignored. After Yunbao confirms the legitimacy of the information, it notifies the user of successful reception through a flashing LED (e.g., three blue flashes) and an audible beep. It also generates a temporary binding key (e.g., CBK_20250630_1530). This temporary key is generated according to the "binding type_date_hour, minute, and second" rule and is valid for only one minute and can be used once to prevent replay attacks from unauthorized devices.

[0017] After receiving the CloudBox response signal, the mobile app verifies the format and validity period of the temporary key. CloudBox then stores the phone's device information locally, creating a binding mapping between the phone's IMEI and CloudBox's MAC address (for example, 861234567890123 is bound to 00:11:22:33:44:55). Once binding is complete, the device automatically switches to Wi-Fi Direct mode (for example, if the SSID is "CloudBox_001122") to ensure the stability and efficiency of subsequent file transfers. Ultrasonic communication is independent of the network and is suitable for disconnected or weak network environments (such as conference rooms and underground spaces). The timestamp is protected against timeouts, the check digit is tamper-proof, and the temporary key is protected against hijacking, ensuring the security of the binding process. LED light and sound notifications, along with an optional physical binding button, prevent accidental operation.

[0018] S102: establishing an encrypted communication tunnel with the mobile terminal device based on a preset encryption rule, and performing encryption and decryption processing on the file storage instruction subsequently sent by the mobile terminal device.

[0019] In one implementation, the device identification information sent by the mobile terminal and the public key from an asymmetric key pair generated by intelligent hardware are obtained. The mobile terminal (e.g., a mobile phone) sends the device identification information (e.g., the IMEI number "861234567890123") to the intelligent hardware (e.g., Yunbao). Simultaneously, the intelligent hardware generates an asymmetric key pair (a public key PU and a private key PR) and sends the public key PU to the mobile terminal. After completing ultrasonic binding, the mobile app automatically sends the device IMEI to Yunbao. Yunbao then generates an RSA asymmetric key pair (with a 2048-bit public key) and returns the public key to the mobile phone.

[0020] Authentication is performed based on device identification information and the public key. Successful authentication triggers the key negotiation process. Intelligent hardware performs authentication based on device identification information and the public key (for example, verifying the legitimacy of the IMEI and the binding relationship between the public key and the device). Successful authentication triggers the symmetric key negotiation process. Yunbao queries the local binding mapping table to confirm that "861234567890123" has been legally bound and that the public key matches the device. It then sends a "verification passed" signal to the phone, initiating key negotiation.

[0021] The intelligent hardware generates a symmetric key pair, writes the public key to the mobile device, and securely stores the private key in the intelligent hardware. The intelligent hardware generates a symmetric key (such as the AES-256 key "K_20250701") and writes the public key to the mobile device. The private key is encrypted and stored in the intelligent hardware (for example, in a security chip). Yunbao generates an AES symmetric key pair, writes the public key "PK_AES" to the mobile app's secure sandbox, and stores the private key "SK_AES" in a hardware encryption module (HSM) to prevent leakage.

[0022] Symmetric keys are encrypted and transmitted using an asymmetric encryption algorithm, establishing a secure data transmission channel between mobile devices and intelligent hardware. Symmetric keys are encrypted using an asymmetric encryption algorithm (such as RSA) to establish a secure transmission channel between mobile devices and intelligent hardware. Yunbao encrypts the AES key "K_20250701" using the phone's public key PU, generating the ciphertext "E(PU,K_20250701)" and sending it to the phone. The phone decrypts the ciphertext using its private key PR to obtain the symmetric key K.

[0023] The symmetric key is used to encrypt and decrypt subsequent file storage instructions sent by the mobile terminal, ensuring data transmission security. File storage instructions sent by the mobile terminal (such as "Upload a picture to Yunbao") are encrypted and decrypted using the symmetric key to ensure transmission security. To upload a sensitive document, the mobile phone encrypts the instruction "STORE_FILE:confidential.doc" using the AES key K, generating the ciphertext "ENC(K,STORE_FILE:confidential.doc)". Yunbao then decrypts the received ciphertext using K and executes the storage operation.

[0024] Asymmetric encryption ensures secure key transmission, while symmetric encryption improves the efficiency of large-scale data encryption and decryption. Smart hardware private keys are stored on a secure chip, minimizing the risk of key leakage and meeting financial-grade encryption standards. Symmetric keys can be renegotiated for each session, preventing security risks caused by long-term use of the same key.

[0025] S103, receiving a file storage instruction sent by the mobile terminal device, storing content of different types of file information based on preset storage rules combined with file access frequency and sensitivity level, and dynamically adjusting the storage location.

[0026] In one embodiment, a file storage instruction sent by a mobile terminal device is received and parsed for file type, size, and sensitivity level. Smart hardware (such as Yunbao) receives the file storage instruction sent by the mobile terminal device through an encrypted communication tunnel. The instruction contains the following key information: basic file attributes used to identify the file name, type (e.g., document, image, video), and size (in MB or GB). For example, "conference report.doc" belongs to the document category and is 20MB in size. Sensitivity levels are set by the user or automatically identified by the system and are categorized as "normal," "internal," and "confidential." Files marked "confidential" require priority security. The storage mode (e.g., immediate storage, idle upload) and target location (local, Yunbao, or a third-party cloud drive) are specified. Yunbao decodes the instruction using its built-in parser, extracting the file type, size, and sensitivity level. For example, when a mobile app sends a command such as "Store file: meeting report.doc, size 20MB, sensitivity level: confidential," Yunbao will recognize the file as a small document requiring priority encryption and trigger the corresponding storage policy.

[0027] The user selects "Upload File" in the mobile app, marks "Conference Report.doc" as "Confidential" and clicks "Store Now". The mobile phone sends instructions to Yunbao through an encrypted tunnel, and Yunbao performs subsequent storage operations after completing the analysis. The mobile app generates instructions based on the file attributes, including the file type (document), size (20MB), sensitivity level (confidential) and storage requirements (local encryption + real-time upload to the enterprise cloud disk), and encrypts the instruction content with a symmetric key. The instruction is sent to Yunbao via WiFi direct connection. After receiving it, Yunbao decrypts it with the symmetric key to obtain the complete instruction information. Yunbao parses the file and finds that it is a 20MB confidential document. According to the preset rules, it determines that the document size is less than 50MB and can be uploaded in real time; the sensitivity level is "confidential" and it must first be encrypted and stored locally (such as AES-256 encryption) before being synchronized to a designated cloud disk (such as TAO cloud disk).

[0028] If Yunbao discovers that key fields such as the file type or sensitivity level are missing during parsing, an error message will be returned to the phone, requiring the complete command to be resent. If the user's sensitivity level conflicts with the system's automatic recognition result (e.g., a file contains sensitive words but the user marked it as "normal"), Yunbao will prompt the user to confirm the level, thus preventing security vulnerabilities. Regardless of the phone brand or model, as long as the app follows a unified command format (such as JSON or binary protocol), Yunbao can correctly parse it, ensuring compatibility across different devices.

[0029] The parsed file type and size directly determine the storage method. For example, a 20MB document triggers "local encryption + real-time upload," while a 500MB video triggers "local temporary storage + nightly cloud upload." The sensitivity level determines encryption strength and access control. Confidential-level files are encrypted locally but access is restricted to authorized users only, and require secondary encryption when uploaded to the cloud. Storage media space is allocated in advance based on file size. For example, small files are preferentially stored in Yunbao's high-speed SSDs, while large files are allocated to HDDs or distributed storage clusters to avoid storage bottlenecks.

[0030] Simultaneously analyze file attributes, security levels, and operational instructions to provide data support for refined storage management, avoiding the inefficiencies associated with "one-size-fits-all" storage. Small files are processed in real time, large files are transferred at off-peak times, and sensitive files are prioritized for encryption, optimizing the user experience while ensuring data security. Analysis results are linked to pre-set rules, allowing flexible adjustment of storage policies (such as adding new cloud drive types or modifying size thresholds) based on business needs to adapt to different application scenarios.

[0031] File storage methods are determined based on preset storage rules, taking into account file access frequency and sensitivity levels. Preset storage rules are a multi-tiered set of policies based on file attributes (type, size, sensitivity level) and usage characteristics (access frequency). These rules are typically configured by system administrators or users. Core dimensions include: File type: Differentiating between documents, images, and videos. For example, documents are prioritized for real-time synchronization, while videos are prioritized for local temporary storage. File size: Setting thresholds (such as 50MB or 1GB) to distinguish between small and large files. Small files are processed in real time, while large files are transferred during idle time. Sensitivity: Classified by "Normal - Internal - Confidential - Top Secret." Higher sensitivity levels prioritize local encrypted storage and impose more restrictions on cloud uploads. Access frequency: Based on how often a file is accessed (such as daily, weekly, or monthly), high-frequency files are prioritized for storage on high-speed media, while low-frequency files can be archived to lower-cost storage.

[0032] Specifically, Rule A states: "Confidential-level files (regardless of type or size) must first be encrypted and stored locally and uploaded only to the company's designated secure cloud drive." Rule B: "Document files <50MB are uploaded to TAO Cloud Drive in real time, and ≥50MB are uploaded to Baidu Cloud Drive at night." Rule C: "Non-sensitive images accessed ≥3 times daily are stored in Yunbao SSD high-speed storage, and videos accessed <1 time per month are encrypted and stored on local HDDs."

[0033] Taking "confidential-level document, size 20MB" as an example, the core steps of policy matching are as follows: file attribute extraction, obtaining the file type (document), size (20MB), sensitivity level (confidential) and historical access frequency (such as once a week) through instruction parsing. Rule priority matching, the system searches for rules according to the preset priority (sensitivity level > file type > file size > access frequency), and gives priority to matching rules related to "confidential-level files". Confirming that the sensitivity level is "confidential" triggers rule A: must be stored locally encrypted. Confirming that the file type is "document" and the size is 20MB<50MB, triggers rule B: can be uploaded to TAO Cloud Disk in real time. Integrate the matching results of multiple rules to generate a composite policy: "local encrypted storage + real-time upload to TAO Cloud Disk".

[0034] In one implementation, the uploaded file information is as follows: a meeting report .doc (document type, 20MB), manually marked as "confidential" by the user, and historically accessed once per week by the project leader. Preset rules are configured as follows: Confidential documents must be locally encrypted and synchronized to a secure enterprise cloud drive (TAO Cloud Drive). Documents smaller than 50MB can be uploaded in real time; those larger than 50MB must be uploaded at night, when the network is idle.

[0035] Sensitivity priority is prioritized. Because the file is classified as "Confidential," the system first enforces Rule A: Regardless of file size, it must be stored locally on Yunbao with AES-256 encryption to prevent the risk of leaks during cloud transmission. The file size requirement is adjusted to 20MB < 50MB, meeting the real-time upload requirement of Rule B. Therefore, after local encryption, the encrypted copy is immediately synchronized to TAO Cloud Drive (the company's designated secure cloud drive). Access frequency is optimized. Because the file is accessed only once a week (medium frequency), local storage is automatically allocated to Yunbao's high-speed SSD area to ensure efficient read access each time, while also ensuring that encrypted storage meets security requirements.

[0036] The system allows administrators to modify rules (e.g., adjust the real-time document upload threshold from 50MB to 100MB) or add new rules (e.g., "video files must be compressed before upload") through the backend, with matching logic taking effect immediately. When multiple rules conflict (e.g., Rule A requires "confidential documents not to be uploaded," while Rule B requires "small documents to be uploaded in real time"), the system will prioritize Rule A (sensitivity level > file size), effectively prohibiting uploads. Users can manually override pre-set rules, for example, by forcing "confidential documents" to be stored locally only and not uploaded to any cloud storage. The system will then record the custom policy and prioritize its execution.

[0037] Policy matching results directly influence storage media selection. For example, "Local Encrypted Storage" corresponds to Yunbao's encrypted HDD or security chip, while "Real-time Upload to TAO Cloud Disk" corresponds to the API call between Yunbao and TAO Cloud Disk. Real-time upload policies consume current network bandwidth, and the system dynamically adjusts the upload rate based on bandwidth utilization (for example, reducing it to 50KB / s when bandwidth is insufficient) to avoid impacting other services. For large, infrequently accessed files (such as 1GB historical videos with a normal sensitivity level), the policy might match "Local Temporary Storage + Nightly Upload to a Low-Cost Cloud Disk (such as the standard version of Baidu Cloud Disk)" to reduce storage costs.

[0038] By combining multi-dimensional rules, we implement a "one policy for each category" and "one policy for each file" storage solution, minimizing resource waste. Sensitivity levels prioritize data security, while file size and access frequency optimize storage efficiency to meet enterprise-level data management needs. The rule system supports on-demand expansion (such as the addition of "cross-border transfer compliance" rules) to adapt to the data storage compliance requirements of different industries (finance, healthcare, and education).

[0039] Sensitive files are stored locally with encryption. Media files are stored locally before being uploaded to the cloud at your leisure. Documents are uploaded to designated cloud drives in real time or overnight, depending on their size. Storage policies are divided into three categories based on file type, sensitivity level, and size, each with targeted storage logic and security mechanisms. For sensitive files, local encryption is prioritized, and cloud uploads are strictly controlled. Files containing sensitive information (such as contracts and confidential reports) are mandatory for highly encrypted storage locally on smart hardware (Yunbao) to avoid cloud transmission and storage risks. The encryption algorithm uses industry standards such as AES-256, and the keys are generated and managed by the Yunbao security chip and are not uploaded to any cloud. Upload control prohibits automatic uploads to third-party cloud drives unless the user manually authorizes and passes secondary authentication (such as fingerprint + password). If sharing is required, it must be transmitted separately through an encrypted tunnel, and the recipient must have the corresponding permissions.

[0040] Application scenarios such as private customer files and core enterprise technical data in the financial industry must meet compliance requirements for data not leaving the local storage location. Media files are temporarily stored locally and transferred to the cloud during off-peak hours to optimize network resources. The storage logic is as follows: Media files such as images and videos are typically large (e.g., GB-sized videos). Direct upload consumes significant real-time network bandwidth. Therefore, they are first stored in Yunbao's local cache (e.g., a high-speed SSD or HDD) and automatically transferred to the cloud during off-peak hours (e.g., 11:00 PM to 6:00 AM), minimizing the impact on daily network usage. Format optimization (e.g., video compression and lossless image scaling) is automatically performed before upload to reduce data transfer volume. Resumable downloads are supported: if the network is interrupted during an upload, the upload resumes from the point where it was interrupted, avoiding duplicate uploads.

[0041] When the application scenario is a corporate press conference video, high-definition photos taken during travel, etc., users want to back up but do not urgently need real-time synchronization. Document files are dynamically scheduled by size to balance real-time performance and efficiency. Set a file size threshold (such as 50MB). Documents smaller than the threshold are uploaded to the designated cloud drive in real time to facilitate cross-device synchronization; documents larger than the threshold are queued and uploaded when network bandwidth is sufficient at night to avoid affecting other real-time businesses (such as video conferencing and online office). Select the target cloud drive based on the document type and usage scenario. For example: internal corporate documents are uploaded to a private cloud drive (such as TAO Cloud Drive) first to ensure security; cross-team collaborative documents are uploaded to a public cloud drive (such as Baidu Cloud Drive, Dropbox) to facilitate shared editing. When the application scenario is daily meeting minutes (small documents), real-time synchronization ensures that team members have immediate access. Large project reports (such as a 100MB PPT) are uploaded at night to avoid occupying network resources during working hours.

[0042] For the sensitive contract document "Confidentiality Agreement.pdf," Type = Document, Size = 2MB, Sensitivity = High (Confidential), Access Frequency = Once per month (only for the Legal Department). After receiving the file, Yunbao encrypts it locally using the AES-256 algorithm, generating an encrypted copy (.encrypted format). The encrypted copy is stored on Yunbao's encrypted HDD partition, accessible only to authorized users (such as the Legal Affairs Director). The system does not generate any cloud upload tasks. If users wish to share, they must manually select "Encrypted Transfer" in the Yunbao app to a designated email address or internal system. A triple mechanism of local encryption, access control, and disabling automatic uploads prevents the leakage of sensitive information.

[0043] For the video file "Product Launch.mp4," type = video, size = 500MB, sensitivity level = normal, and access frequency = twice a week (for marketing department review), the video file is first stored in Yunbao's local SSD cache to ensure read speed during frequent recent access. When the system detects the current time at 23:00 (during network downtime), it automatically initiates an upload task and transfers the video to the "Enterprise Video" folder on Baidu Cloud. After the upload is complete, Yunbao retains a local copy. Subsequent user access will prioritize reading from the local directory, reducing cloud data usage. Off-peak uploads avoid daytime office network congestion, while local caching ensures efficiency for frequent access.

[0044] For a small document like "Meeting Minutes.doc," type = Document, size = 10MB, sensitivity level = Normal, and access frequency = 3 times per day (for team members), the document is uploaded to the "Meeting Minutes" folder on TAO Cloud Drive in real time, allowing simultaneous viewing across multiple devices (mobile, computer, and tablet). Yunbao also stores an unencrypted copy locally on the high-speed SSD. Due to frequent access, local access is prioritized to increase opening speed. Each time the document is modified, incremental synchronization is automatically triggered, uploading only the modified portion to reduce data usage. Real-time synchronization ensures that team members have the latest version, while local caching and cloud backup ensure both efficiency and disaster recovery.

[0045] The following allocation is made for storage media: sensitive files: encrypted and stored in Yunbao's dedicated security chip or HDD encrypted partition, isolating ordinary users from access; frequently accessed files (such as small documents, recent media files): stored in the SSD high-speed area to improve read and write speeds; low-frequency large files (such as historical videos): stored in HDD or distributed storage clusters to reduce hardware costs.

[0046] Network resources are scheduled accordingly. For real-time uploads, bandwidth usage is limited to 30% of the total bandwidth to avoid impacting other network applications. For off-peak uploads, bandwidth usage can exceed 80% to fully utilize nighttime network resources. Yunbao monitors local storage capacity in real time. When remaining space falls below 20%, it automatically cleans up infrequently accessed, non-sensitive files (such as standard videos from six months ago) or triggers a cloud archiving mechanism to migrate files to low-cost cloud storage (such as Baidu Cloud).

[0047] During a persistent network failure, if media files haven't been uploaded to the cloud for more than 72 hours, the system will send a reminder to the user and prioritize backlogged tasks after the network is restored. If the system detects that sensitive files have been mistakenly uploaded to a public cloud disk, it immediately triggers an automatic deletion mechanism, logs the operation, and sends an alert to the administrator. Yunbao has built-in RAID-like redundancy mechanisms (such as multi-replica shard storage with parity checking). If local storage media is damaged, data can be restored from other replicas or cloud backups (only for uploaded non-sensitive files).

[0048] This application offers the following technical advantages: tiered security management, local encryption of sensitive files combined with strict upload controls, and dynamic scheduling of common files, meeting storage requirements at varying security levels. Efficient resource utilization, off-peak uploads reduce network pressure, and on-demand storage media allocation (SSD / HDD / security chip) balances performance and cost. An optimized user experience, real-time synchronization ensures efficient collaboration, local caching speeds up high-frequency file access, and automated processes reduce manual intervention.

[0049] Dynamically adjust storage locations based on file access frequency and sensitivity level. Highly accessed non-sensitive files are stored in high-speed storage areas, while infrequently accessed sensitive files are encrypted and stored locally. Storage location adjustment is driven by "file access frequency" and "sensitivity level," combining storage media characteristics (speed, capacity, and security) to optimize resource allocation. The specific logic is as follows: High-frequency files (accessed ≥1 time per day) are prioritized for storage on high-speed SSDs (solid-state drives), leveraging their low latency and high read and write speeds to reduce user wait times for opening files. Medium-frequency files (accessed 1-3 times per week) are stored on standard HDDs (mechanical hard drives) or a hybrid SSD area, balancing read speed and storage cost. Low-frequency files (accessed ≤1 time per month) are stored on low-cost HDDs or archived to cloud-based cold storage, freeing up local high-speed storage resources.

[0050] For highly sensitive files (Confidential / Top Secret), regardless of access frequency, they are encrypted and stored locally on a hard drive or secure chip, reducing exposure risks from network transmission and high-speed storage. For low- and medium-sensitivity files (Normal / Internal), storage locations are dynamically adjusted based on access frequency, with high-frequency files stored on SSDs and low-frequency files stored on HDDs or the cloud. For the optimized storage location of "Meeting Minutes.doc," the file attributes are as follows: Sensitivity = Normal, Access Frequency = 3 times per day (High Frequency), Size = 10MB, and Type = Document.

[0051] When first uploaded, because it is a normal document and its size is less than 50MB, it is stored in the TAO cloud disk according to the "real-time document upload" policy, and a copy is retained in the normal storage area of ​​Yunbao's local HDD. The system detects that the file has been accessed ≥3 times per day for 7 consecutive days and is determined to be a "high-frequency non-sensitive file," triggering the storage location adjustment process: an unencrypted copy of the file is created in the Yunbao SSD high-speed area; the local index is updated to direct access requests to the SSD copy, and the original HDD copy is marked as "backup"; subsequent user accesses are read directly from the SSD, increasing the read speed from the HDD's ~100MB / s to the SSD's ~500MB / s, reducing the opening time by approximately 80%. If the file's access frequency drops to less than once per week, the system automatically migrates the SSD copy back to the HDD, freeing up high-speed storage resources for new, high-frequency files.

[0052] For the fixed storage location policy for "Confidentiality Agreement.pdf," the file attributes are Sensitivity Level = Confidential, Access Frequency = Once every six months (Low Frequency), Size = 2MB, and Type = Document. Upon initial receipt, the file is encrypted using AES-256 according to the "Local Encryption of Sensitive Files" policy and stored in the encrypted partition of Yunbao's local HDD. Upload to the cloud is prohibited. The system periodically scans the encrypted partition (e.g., monthly) to verify file integrity but does not adjust the storage location. These reasons are: the high sensitivity level prohibits migration to a non-encrypted SSD; and the low access frequency eliminates the need to occupy high-speed storage resources. Security enhancements: The encrypted HDD partition is equipped with dual permission control (user password + Yunbao management key). Each access requires secondary verification via fingerprint + password, ensuring continued security even if the storage location remains unchanged.

[0053] Yunbao's backend records file access logs (access time, frequency, and user identity) in real time, and combines them with sensitivity level labels to form a file feature database. File access frequencies are scanned regularly (e.g., at 02:00 daily) and compared to preset thresholds (e.g., ≥1 time per day is considered high frequency), while also checking whether the sensitivity level has changed. High-frequency non-sensitive files: migrate from HDD / cloud to local SSD, and remain unencrypted during copying (because they are non-sensitive); low-frequency sensitive files: maintain local encrypted HDD storage, and if access is required, temporarily load them into memory for processing, and do not reside on the SSD. After adjustment, the file index table is updated to ensure that user access requests point to the new storage location, and refresh the local cache (such as the operating system file cache) to avoid access delays.

[0054] Critical documents (such as financial statements and core code) are stored in multiple replicas and shards, and parity algorithms are used to generate checksum data to ensure data recovery in the event of a single point of failure. For example, the critical document "2025 Annual Financial Report.xlsx" is sharded into three data blocks (D1, D2, and D3), and a parity block P (the checksum of D1+D2+D3) is generated. If the D2 storage medium is damaged, data can be reconstructed from D1, D3, and P to ensure data integrity.

[0055] S104: Obtain a file query instruction, process the file query instruction based on preset storage rules and different types of file query rules, and generate file query information.

[0056] In one embodiment, a file query instruction is received, query keywords, time range, and file type are parsed, and the file storage location is located in combination with preset storage rules. File metadata and content features are extracted to generate a raw data set containing query dimensions and file features. A file query instruction is received from a user, keywords (such as "smart hardware"), time range (such as "June 2025"), and file type (such as document / image) are parsed, and the file storage location (local / cloud disk) is located in combination with preset storage rules. File metadata (creation time, modifier) ​​and content features are extracted to generate a raw data set.

[0057] When a user searches for "Smart Hardware Conference Documents, June 2025" on the mobile app, the system analyzes the keywords "smart hardware" and "conference", the time range "2025-06 to 2025-06", and the file type "document", locates the document storage areas of Yunbao local and TAO cloud disk, and extracts the metadata of the relevant files (such as the creation time "2025-06-15" and the modifier "Zhang San") and content features.

[0058] A semantic vector index is constructed for document files using the BERT model, calculating the cosine similarity between query keywords and document semantics. BERT (Bidirectional Encoder Representations from Transformers), a pre-trained language model, learns deep semantic representations of text through a bidirectional Transformer architecture, capturing the semantic associations between words in context. In document query scenarios, its core functions include: semantic vectorization, converting document text and query keywords into high-dimensional semantic vectors, where each dimension represents a semantic feature (such as topic, sentiment, or entity relationship); contextual understanding, resolving polysemy issues (e.g., "smart hardware" may refer to "consumer-grade devices" or "industrial-grade solutions" in different documents), and accurately locating semantic meaning through context.

[0059] Taking "Smart Hardware Development Report.doc" as an example, the specific steps are as follows: text preprocessing, removing punctuation and special characters in the document, splitting the text into word sequences (such as "smart hardware / development / report / ..."); dividing long documents into blocks (such as 500 words per block) to avoid the single vector dimension being too high. The preprocessed text is input into the pre-trained BERT model, and the model outputs the context vector representation of each word (such as the vector of "smart hardware" will integrate the semantic information of the words before and after it); all word vectors in the document are pooled (such as taking the average) to generate the semantic vector of the entire document [0.8, 0.3, 0.5...]. The document semantic vector is associated with the file metadata (file name, creation time, modifier, etc.), stored in a vector database (such as Milvus), and a fast retrieval index is established.

[0060] The same preprocessing and BERT inference are performed on the query keywords entered by the user (such as "smart hardware conference") to generate the query vector [0.9, 0.2, 0.4...]. Cosine similarity measures the semantic relevance by calculating the cosine value of the angle between two vectors. The formula is: The dot product of the document vector and the query vector is , the vector moduli are and , the final similarity is 0.98 / (0.99×1.0)≈0.99. Set a similarity threshold (such as 0.7), and documents above the threshold are judged as "highly relevant" and included in the candidate result set.

[0061] In one embodiment, the user queries for "smart hardware conference-related documents", and the target document is "smart hardware development report.doc", which contains the chapter "2025 Smart Hardware Industry Conference Summary". The model has a semantic understanding function, which is specifically reflected in keyword expansion: "conference" does not appear directly in the document, but BERT infers the semantic association between "development report" and "conference" through the context (such as "industry conference summary" and "participating companies"). Semantic generalization: The query term "smart hardware" and the "smart hardware industry" in the document are recognized by BERT as the same semantic category, and the vector representations are highly similar. Noise filtering: If there are irrelevant paragraphs such as "smart watch hardware parameters" in the document, BERT will weaken the impact of noise through the overall semantic vector and focus on the core topic.

[0062] When document content is modified, only the semantic vectors for the changed parts are regenerated, avoiding a full index rebuild and improving efficiency. Hierarchical indexing involves storing semantic vectors for frequently accessed documents in memory to accelerate queries, while storing vectors for less frequently accessed documents in SSDs to reduce hardware costs. Principal component analysis (PCA) reduces high-dimensional semantic vectors (e.g., 768 dimensions) to 128 dimensions, reducing computational complexity while preserving key semantic features.

[0063] Visual features including color histograms and HOG are extracted from images, while MFCC audio features and dynamic visual features are extracted from videos. A similarity mapping relationship is established between sample features and stored files, and multiple features are integrated to form a cross-modal index matrix. The BERT model is used to construct a semantic vector index for documents, calculating the cosine similarity between query keywords and document semantics to screen for highly relevant documents. For example, for the document "Smart Hardware Development Report.doc," the BERT model generates semantic vectors [0.8, 0.3, 0.5...], while the query keyword "Smart Hardware Conference" generates vectors [0.9, 0.2, 0.4...]. The calculated cosine similarity is 0.85, indicating a highly relevant document.

[0064] The system integrates file metadata and content features, generates multi-condition combination filtering logic based on preset query rules, and uses a prefix hashing algorithm to narrow the search scope. Frequently accessed files are prioritized from the in-memory index, while less frequently accessed files are retrieved from the distributed SSD index, forming a preliminary set of candidate files. Visual features such as color histograms and HOG (Histogram of Oriented Gradients) are extracted from images; MFCC (Mel-Frequency Cepstral Coefficients) audio features and dynamic visual features are extracted from videos. A similarity mapping is established between the sample and the stored files, which are then integrated into a cross-modal index matrix. Specifically, a user uploads a photo of a conference as a query sample. The system extracts its color histogram (dominantly blue) and HOG features (character outlines). These are then compared with the features of the stored file "2025-06-15ConferencePhoto.jpg." The similarity reaches 0.78, and the file is included in the candidate set.

[0065] The system integrates metadata (time, modification person) with content features, generating combined filtering logic based on pre-set rules (e.g., "June 2025 + Zhang San + smart hardware"). Prefix hashing is used to narrow the search scope, retrieving high-frequency files from the in-memory index and low-frequency files from the distributed SSD to form a preliminary candidate set. Specifically, the combination of "June 2025 + Zhang San created + document" uses prefix hashing to quickly locate documents with the file hash prefix "202506_zhangsan_." The frequently accessed "meeting minutes.doc" is directly retrieved from the in-memory index, while the low-frequency "technical plan.pdf" is retrieved from the SSD, resulting in a preliminary selection of five candidate files.

[0066] The candidate file set is semantically revalidated, and images and videos are filtered again based on the scene description and timestamp. The user's historical query preferences are incorporated to dynamically adjust the search weights, generating an optimized subset of query results. The candidate files are semantically revalidated (e.g., document keyword contextual relevance). Images and videos are filtered again based on the scene description (e.g., "seaside meeting") and timestamp. The user's historical query preferences (e.g., users often prioritize viewing Zhang San's documents) are used to adjust the weights, generating an optimized subset. For example, after revalidation of the candidate file "Smart Hardware Seminar Record.doc," the keyword "smart hardware" appears in the appendix rather than the main text, reducing its relevance. Taking into account the user's historical preference (often viewing Zhang San's documents), "Zhang San - Smart Hardware Conference Summary.doc" (similarity 0.92) and "Conference Photo.jpg" (scene match) are ultimately retained.

[0067] Sensitive files in the query results are dynamically watermarked, sensitive fields are automatically desensitized, and query information is structured by file type, with similarity scores and metadata tags, resulting in interactive file query results. Dynamic watermarks (including user ID and query time) are added to sensitive files, sensitive fields are desensitized (for example, an ID number is displayed as "110101********1234"), and output is structured by document / image / video, with similarity scores and metadata tags. In the query results, "Financial Report.doc" is a sensitive file, and the output automatically adds the watermark "User1234-2025-07-01." The amount field "¥1000000" is desensitized to "¥100****." The structured display is as follows: Document: Zhang San - Smart Hardware Conference Summary.doc (similarity 0.92, 2025-06-15); Image: Conference Scene.jpg (similarity 0.78, 2025-06-15, scene matching).

[0068] S105: Send a file backup instruction to the cloud service device based on the preset upload rule to achieve cross-platform file backup.

[0069] In one embodiment, a file backup instruction is received, the file type, size, sensitivity level, and access frequency are analyzed, and combined with preset upload rules, the cloud service device's storage capacity, bandwidth utilization, and SLA level parameters are extracted to generate an upload task feature set that includes file diversion rules and cloud platform adaptation strategies. Preset upload rules include selecting different upload times based on file size. A file backup instruction is received, the file attributes (type, size, sensitivity level, access frequency) are analyzed, and combined with preset upload rules (such as nighttime upload of large files), cloud service device parameters (storage capacity, bandwidth utilization, SLA level) are extracted to generate a task feature set that includes diversion rules and cloud platform adaptation strategies.

[0070] A user triggers the "Backup Financial Report" command, and the file is "2025 Financial Report.xlsx" (Document Class, 200MB, High Sensitivity, Accessed Once a Week). After analyzing the file, the system uses the default rule (files >50MB must be uploaded at night) to determine the TAO Cloud Disk's storage capacity (10TB remaining) and bandwidth utilization (currently 20%), generating the task signature: "Sensitive Large Document → Upload to TAO Cloud Disk at Night, Encrypted Transmission."

[0071] By comparing the storage costs, encryption mechanisms, and regional node distribution of cloud services across multiple platforms, and combining factors related to file transfer efficiency and security identified through range analysis, we determined upload targets for different file types and generated platform-specific cross-device transfer mappings. We also compared the storage costs, encryption mechanisms, and regional nodes of multiple platforms, including Baidu Cloud Disk and Dropbox. Through range analysis, we identified key factors influencing transfer efficiency and security, matched file types with optimal cloud platforms, and generated a cross-device transfer mapping. The comparison revealed that TAO Cloud Disk offered enterprise-grade encryption (AES-256), high storage costs, and a large number of domestic nodes; Baidu Cloud Disk offered standard encryption, low costs, and average bandwidth stability; and Dropbox offered good cross-border transfer compliance but the highest storage costs. Because the file was a "sensitive financial report" and the user was located in China, range analysis revealed that "encryption level" and "regional compliance" were key factors. Therefore, TAO Cloud Disk was selected as the upload target, generating a mapping: "Sensitive documents → TAO Cloud Disk, standard documents → Baidu Cloud Disk."

[0072] The transmission mapping relationship is compared with the preset cloud platform storage standard feature library, and the error verification data including network delay and bandwidth fluctuation is combined to generate the compliance deviation assessment result of the upload task. The transmission mapping is compared with the preset cloud platform storage standard (such as TAO cloud disk requires files ≤500MB), and the compliance deviation of the upload task is evaluated by combining error data such as network delay and bandwidth fluctuation. The TAO cloud disk standard requires "single file ≤500MB", and the current file of 200MB meets the requirement, but recent LAN bandwidth fluctuations are detected (average bandwidth at night is 10MB / s). The upload is expected to take 15 minutes (the compliance threshold is 30 minutes), and the deviation assessment is generated: "Compliant, the impact of network fluctuations is acceptable."

[0073] Based on the real-time bandwidth of the edge device's local area network (LAN) and the load of cloud service devices, the network quality heatmap weight distribution is used to weight the compliance deviation assessment results. This prioritizes the upload of frequently accessed files and triggers a nighttime idle bandwidth scheduling policy for large files. This generates a cross-platform upload execution vector that integrates network status and file priority. Based on real-time network bandwidth and cloud service load, the network quality heatmap is used to adjust the compliance deviation weights, prioritizing the upload of frequently accessed files and triggering nighttime scheduling for large files. This generates an execution vector that integrates network status and file priority. Detecting that the current LAN bandwidth is only 5MB / s (peak daytime office hours), and that "financial reports" are infrequently accessed files, the system lowers their upload priority, triggering an upload at night (11:00 PM) when bandwidth is idle. Simultaneously, the frequently accessed "meeting minutes.doc" (10MB) is prioritized for upload, using the current bandwidth. This generates the execution vector: "200MB financial report → upload to TAO Cloud Disk at 11:00 PM, 10MB minutes → upload immediately."

[0074] The upload task execution results are normalized, and combined with dynamic synchronization efficiency, a cross-platform backup status parameter set containing the platform correlation coefficient, transmission success rate, and abnormality alarm threshold is generated to dynamically optimize the file synchronization strategy between smart hardware and multi-cloud disks. Upload results (such as transmission time and integrity verification) are normalized, and combined with synchronization efficiency, status parameters containing the platform correlation coefficient, transmission success rate, and abnormality threshold are generated to optimize the synchronization strategy. For example, the "Financial Report" was successfully uploaded at night, taking 12 minutes (success rate 100%), with a TAO cloud disk correlation coefficient of 0.9 (high adaptability). The system records the abnormal threshold as "a single upload failure exceeding 3 times triggers an alarm." A status parameter set is generated for subsequent strategy optimization (such as adjusting the large file upload threshold to 300MB).

[0075] like Figure 2As shown, a mobile phone file backup system based on intelligent hardware includes: a mobile terminal device sends ultrasonic coding information containing the mobile terminal device identification to a target edge device through an APP to discover and bind the target edge device in the same local area network; based on preset encryption rules, an encrypted communication tunnel is established with the target edge device, and file storage instructions subsequently sent to the target edge device are encrypted and decrypted; file storage instructions including pictures, videos, and documents are sent to the target edge device, so that the target edge device stores content of different types of file information based on preset storage rules;

[0076] The intelligent hardware receives the file storage instructions sent by the mobile terminal device, and stores the content of different types of file information based on preset storage rules, where the preset storage rules are used to represent the storage processing of files based on file diversion rules; receives the file query instructions, processes the file query instructions based on the preset storage rules, and generates file query information; sends the file backup instructions to the cloud service device based on the preset upload rules to realize cross-platform file backup.

[0077] This solution's innovation lies in combining asymmetric encryption (such as RSA) with symmetric encryption (such as AES). Intelligent hardware generates an asymmetric key pair, uses the public key to transmit the symmetric key, and then uses the symmetric key to encrypt the actual data, balancing encryption security and transmission efficiency. Asymmetric encryption ensures secure key transmission, while symmetric encryption speeds up large file encryption and decryption. It complies with TLS protocol standards and meets financial-grade data security requirements.

[0078] Intelligent file diversion and dynamic storage management dynamically adjust storage policies based on file type, size, sensitivity level, and access frequency: Sensitive files are encrypted and stored locally, prohibiting automatic cloud upload; media files are stored locally before being uploaded to the cloud during downtime to optimize network resources; documents are uploaded in real time or overnight based on size, and storage locations are dynamically adjusted based on access frequency (e.g., frequently accessed files are stored on SSDs, while less frequently accessed sensitive files are encrypted and stored on HDDs). This enables refined allocation of storage resources, balancing security, efficiency, and cost. For example, large files can be uploaded overnight to avoid consuming office bandwidth, while frequently accessed files can be stored on high-speed media to improve access speed.

[0079] Multi-copy shard storage and parity fault tolerance: Multiple copies of critical documents are stored in shards. A parity algorithm generates redundant checksum data. In the event of a single point of failure, data can be rebuilt using other shards and checksums to ensure data integrity. This software algorithm achieves enterprise-level data fault tolerance without relying on RAID hardware, reducing hardware costs and making it suitable for backing up critical data such as financial statements and core code.

[0080] Cross-platform intelligent backup and dynamic scheduling dynamically generate upload strategies based on file attributes (type, size, sensitivity level) and cloud platform characteristics (storage cost, encryption mechanism, and regional nodes). By comparing multiple platforms and using range analysis to determine the optimal upload target (e.g., prioritizing enterprise-grade encrypted cloud drives for sensitive files), upload priorities are dynamically adjusted based on real-time network bandwidth and cloud service load (prioritizing high-frequency files and staggering large file uploads). This enables intelligent scheduling of cross-platform backups, balancing compliance (e.g., ensuring data remains within the country), cost optimization (selecting low-cost cloud drives), and transfer efficiency.

[0081] Multimodal file query and semantic retrieval utilizes the BERT model to construct a semantic vector index, supporting cosine similarity calculations between keywords and document semantics, addressing the semantic ambiguity inherent in traditional keyword matching. Image / video querying extracts color histograms, HOG visual features, and MFCC audio features, supporting sample-based similarity retrieval. The system integrates file metadata (date, modification person, sensitivity level) with content features to provide a multi-dimensional filtering interface. This upgrades from "keyword matching" to "semantic understanding." For example, a query for "smart hardware conference" can now link to semantically related documents that don't directly contain the term "conference," improving search accuracy and efficiency.

[0082] Security enhancements and dynamic optimization mechanisms automatically add dynamic watermarks and desensitize fields to sensitive files in query results to prevent data leaks. After an upload task is executed, status parameters are generated, including platform correlation coefficients and transfer success rates, and synchronization strategies are dynamically optimized (such as adjusting upload thresholds and cloud disk priorities). This forms a closed-loop management system for "storage-query-backup," continuously optimizing system performance and security to adapt to changing business scenarios.

[0083] The cross-device file ecosystem supports file transfer and sharing between mobile phones and smart hardware, and between smart hardware and multi-platform cloud storage, creating a flexible cross-device backup ecosystem. For example, Yunbao can synchronize files to TAO Cloud Disk, Baidu Cloud Disk, and other platforms, achieving "one-time backup, multi-device sharing." This breaks down device and platform barriers, improves team collaboration efficiency, and meets enterprise-level cross-platform data management needs.

[0084] An electronic device includes a first processor; and a memory for storing executable instructions of the first processor; wherein the first processor is configured to execute any one of the mobile phone file backup methods based on smart hardware by executing the executable instructions.

[0085] A computing device comprises a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to execute any one of the mobile phone file backup methods based on intelligent hardware.

[0086] The methods and / or embodiments in the embodiments of the present application can be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the method shown in the flowchart. When the computer program is executed by a processing unit, the above-mentioned functions defined in the method of the present application are performed.

[0087] It should be noted that the computer-readable medium described in this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, a computer-readable medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0088] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0089] It will be apparent to those skilled in the art that the present application is not limited to the details of the exemplary embodiments described above, and that the present application can be implemented in other specific forms without departing from the spirit or essential characteristics of the present application. Therefore, the embodiments should be considered in all respects as illustrative and non-restrictive, and the scope of the present application is defined by the appended claims rather than the foregoing description, and all variations that come within the meaning and range of equivalents of the claims are intended to be embraced herein.

Claims

1. A mobile phone file backup method based on intelligent hardware, applied to intelligent hardware, characterized in that: include: Receive the device connection information sent by the mobile terminal device, respond to the binding request, and complete the binding with the mobile terminal device; Establish an encrypted communication tunnel with the mobile terminal device based on preset encryption rules, and encrypt and decrypt the file storage instructions sent by the subsequent mobile terminal device; Receive file storage instructions sent by mobile terminal devices, store different types of file information based on preset storage rules combined with file access frequency and sensitivity level, and dynamically adjust storage locations. The preset storage rules are used to represent the storage processing of files based on file diversion rules, store multiple copies of key documents in shards, and ensure data recovery in the event of a single point of failure through a parity check algorithm; Obtain file query instructions, process the file query instructions based on preset storage rules and different types of file query rules, and generate file query information, including receiving file query instructions, parsing query keywords, time range, file type, locating file storage location in combination with preset storage rules, extracting file metadata and content features, and generating a set of original data containing query dimensions and file features; constructing a semantic vector index for document-type files through the BERT model, and calculating the cosine similarity between query keywords and document semantics; extracting visual features including color histograms and HOG for images, and extracting MFCC audio features and dynamic visual features for videos, establishing a similarity mapping relationship between sample features and stored files, and integrating multiple types of features to form a cross-modal index matrix; integrating file metadata and content features, generating multi-condition combination screening logic based on preset query rules, and narrowing down the search through the prefix hash algorithm. Scope, high-frequency access files are preferentially obtained from the memory index, and low-frequency files are retrieved from the distributed SSD index to form a preliminary candidate file set; the candidate file set is semantically verified twice, and pictures and videos are filtered twice in combination with the shooting scene description and timestamp. The user's historical query preferences are introduced to dynamically adjust the retrieval weight to generate an optimized query result subset; sensitive files in the query results are dynamically watermarked, sensitive fields are automatically desensitized, and query information is output structured by file type, with similarity scores and metadata tags to form the final interactive file query results. Among them, the query rules for different types of files include building a semantic vector index for document-type files, extracting visual features and audio features for pictures and videos respectively, supporting similarity retrieval based on sample pictures and voice clips, integrating file creation time, modifier, and sensitivity level data, and providing a multi-condition combination query interface; Send file backup instructions to cloud service devices based on preset upload rules to achieve cross-platform file backup.

2. The method for backing up mobile phone files based on intelligent hardware according to claim 1, characterized in that: Establishing an encrypted communication tunnel with the mobile terminal device based on preset encryption rules, and performing encryption and decryption processing on the file storage instructions subsequently sent by the mobile terminal device, including: Obtain the device identification information sent by the mobile terminal device and the public key in the asymmetric key pair generated by the intelligent hardware; Authentication is performed based on device identification information and public key, and the key negotiation process is triggered after verification is successful; The smart hardware generates a symmetric key pair, writes the public key into the mobile terminal device, and the private key is securely stored by the smart hardware; Symmetric keys are encrypted and transmitted through asymmetric encryption algorithms, thereby building a secure data transmission channel between mobile terminal devices and smart hardware; The symmetric key is used to encrypt and decrypt the file storage instructions sent by subsequent mobile terminal devices to ensure the security of data transmission.

3. The method for backing up mobile phone files based on intelligent hardware according to claim 2, characterized in that: Receive file storage instructions sent by mobile terminal devices, store different types of file information based on preset storage rules combined with file access frequency and sensitivity level, and dynamically adjust storage locations, including: Receive file storage instructions sent by mobile terminal devices and analyze file type, size and sensitivity level information; Determine the file storage method based on preset storage rules, combined with file access frequency and sensitivity level; Sensitive files are stored locally with encryption, media files are stored locally first and then uploaded to the cloud at leisure, and documents can be uploaded to designated cloud disks in real time or at night according to size; Dynamically adjust storage locations based on file access frequency and sensitivity level. Highly accessed non-sensitive files are stored in high-speed storage areas, while infrequently accessed sensitive files are encrypted and stored locally. Key documents are stored in multiple copies and shards, and verification data is generated through a parity algorithm to ensure data recovery in the event of a single point of failure.

4. The method for backing up mobile phone files based on intelligent hardware according to claim 1, characterized in that: Send file backup instructions to cloud service devices based on preset upload rules to achieve cross-platform file backup, including: Receive file backup instructions, analyze file type, size, sensitivity level, and access frequency, and, based on preset upload rules, extract cloud service device storage capacity, bandwidth utilization, and SLA level parameters to generate an upload task feature set that includes file diversion rules and cloud platform adaptation strategies. Preset upload rules include selecting different upload times based on file size. Compare the storage costs, encryption mechanisms, and regional node distribution of cloud services across multiple platforms. Combined with the factors related to file transfer efficiency and security identified through range analysis, determine the upload targets for different file types, and generate cross-device transfer mappings with platform differences. Compare the transmission mapping relationship with the preset cloud platform storage standard feature library, and combine it with error verification data including network delay and bandwidth fluctuation to generate the compliance deviation assessment result of the upload task; Based on the real-time bandwidth of the local area network where the edge device is located and the load of the cloud service device, the network quality heat map weight distribution is used to make a weighted adjustment to the compliance deviation assessment results. This increases the upload priority of frequently accessed files and triggers the nighttime idle bandwidth scheduling policy for large files. This generates a cross-platform upload execution vector that integrates network status and file priority. The upload task execution results are normalized, and combined with the dynamic synchronization efficiency to generate a cross-platform backup status parameter set including the platform correlation coefficient, transmission success rate and abnormal alarm threshold, to complete the dynamic optimization of the file synchronization strategy between smart hardware and multi-cloud disks.

5. A mobile phone file backup system based on intelligent hardware, used to execute the method according to any one of claims 1 to 4, characterized in that: include: The mobile terminal device sends ultrasonic coded information containing the mobile terminal device's identification to the target edge device through the APP to discover and bind the target edge device in the same local area network; based on the preset encryption rules, an encrypted communication tunnel is established with the target edge device to encrypt and decrypt the file storage instructions subsequently sent to the target edge device; file storage instructions including pictures, videos, and documents are sent to the target edge device, so that the target edge device can store different types of file information based on the preset storage rules; The intelligent hardware receives the file storage instructions sent by the mobile terminal device, and stores the content of different types of file information based on preset storage rules, where the preset storage rules are used to represent the storage processing of files based on file diversion rules; receives the file query instructions, processes the file query instructions based on the preset storage rules, and generates file query information; sends the file backup instructions to the cloud service device based on the preset upload rules to realize cross-platform file backup.

6. An electronic device, characterized in that: include: a first processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the method of any one of claims 1 to 4 by executing the executable instructions.

7. A computing device comprising a memory for storing computer program instructions and a second processor for executing the computer program instructions, wherein: When the computer program instructions are executed by the second processor, the device is triggered to execute the method according to any one of claims 1 to 4.

Images