An iot device configuration data security storage and migration method and system

Abstract

The application discloses a kind of Internet of Things equipment configuration data security storage and migration method and system, and is related to Internet of Things equipment configuration technical field.The method comprises: when a storage card is inserted into unconfigured Internet of Things equipment, Internet of Things equipment obtains identity token file to storage card, if identity token file is not obtained, first binding and identity token generation process are executed, and identity token file is requested to obtain to cloud end;Cloud end database uniquely binds token ID, the unique identifier of Internet of Things equipment and current timestamp, and records the binding relationship of storage card and Internet of Things equipment, for verification and dynamic management;If identity token file is obtained, configuration data offline migration process is executed.The application provides a kind of Internet of Things equipment configuration data security storage and migration method and system, by binding the core configuration data of Internet of Things equipment with storage card, and combining cloud end management mechanism, reduce the after-sales service cost of manufacturer and the waiting time of user.

Description

Technical Field

[0001] This invention relates to the field of IoT device configuration technology, and in particular to a method and system for secure storage and migration of IoT device configuration data. Background Technology

[0002] In traditional IoT devices, especially smart home gateways and smart intercom terminals, critical data such as network configuration, sub-device pairing information, user permissions, and automation scenarios are typically written directly into the device's internal memory. This design has revealed numerous technical flaws and user pain points in practical applications.

[0003] First, there's the issue of data vulnerability. If the device hardware fails due to unexpected malfunctions, physical damage, or natural aging, all data stored internally will become inaccessible and unrecoverable. This not only means users will need to spend significant time and effort resetting each sub-device and automation scenario, but it can also lead to the permanent loss of user data, severely impacting the user experience.

[0004] Secondly, there are difficulties in migration and upgrades. When users need to replace old equipment or upgrade to a new generation of products, they have to configure all the information from scratch because the internal data cannot be exported. This high migration cost is a huge obstacle preventing users from replacing their equipment and also increases the burden of after-sales service.

[0005] In addition, there are data security risks. If the device's internal storage is not strictly encrypted and access controlled, configuration data may be illegally accessed, copied, or even tampered with. This not only threatens user privacy and security but may also lead to security vulnerabilities in the entire system that can be exploited by criminals.

[0006] Finally, there is the issue of illegal copying. Current technology lacks effective anti-copying mechanisms. Once the internal storage data of a device is maliciously obtained, criminals can easily clone the device, build counterfeit systems, or exercise illegal control, which poses serious security risks and economic losses to both manufacturers and users. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a method and system for secure storage and migration of configuration data of Internet of Things (IoT) devices. By binding the core configuration data of IoT devices to a memory card and combining it with a cloud-based dynamic management mechanism, the after-sales service costs of manufacturers and the waiting time of users are reduced.

[0008] In a first aspect, the present invention provides a method for secure storage and migration of configuration data for Internet of Things (IoT) devices, comprising: When a memory card is inserted into an unconfigured IoT device, the IoT device requests an identity token file from the memory card. If no identity token file is obtained, the device performs the initial binding and identity token generation process. If an identity token file is obtained, the device performs the offline migration process for configuration data. Initial binding and identity token writing process: The IoT device sends a request with a unique identifier to the cloud; after receiving the request, the cloud platform generates a dynamic and unique identity token file and sends it to the IoT device. The identity token file contains a unique token ID, a key for data encryption, and a status flag marked "inactive"; the IoT device writes the identity token file to a storage card, then uses the key in the identity token file to encrypt all configuration data before writing it to the storage card, and reports the token ID on the storage card to the cloud. The cloud database uniquely binds the token ID, the IoT device's unique identifier, and the current timestamp, and records the binding relationship between the storage card and the IoT device for verification and dynamic management. Configuration data offline migration process: When the IoT device is offline, read the identity token file in the storage card, verify the integrity of the identity token file, and check whether the status flag is "inactive". After the verification is successful, use the key in the identity token file to decrypt and load the encrypted configuration data in the storage card.

[0009] Furthermore, after the offline migration process of the configuration data, a network activation process is also included: after the IoT device is connected to the network, it reports the token ID and its own unique identifier to the cloud; the cloud updates the status flag of the identity token file to "activated" and permanently binds it to the new IoT device, while marking the binding relationship of the old IoT device as invalid; then the cloud generates a new identity token file in an "inactive" state and sends it to the IoT device.

[0010] Furthermore, the method also includes a data synchronization process: when a user configures the device through a mobile application, the IoT device writes the new configuration data and cloud timestamp to the storage card and synchronizes it to the cloud database.

[0011] Furthermore, the method also includes a timestamp comparison process: when an IoT device connects to the cloud, the cloud compares the latest timestamp on the storage card with the latest timestamp recorded in the cloud database; if they match, the cloud provides normal service; if they do not match, the unique identifier of the IoT device is obtained, and it is determined whether the token ID and the unique identifier of the IoT device are consistent with the binding relationship of the storage. If they match, the intelligent conflict handling process is initiated; if they do not match, it is further determined whether the IoT device it is bound to is online. If it is offline, the data recovery process is initiated; if it is online, the card is identified as illegally copied, the cloud refuses its service and issues an alarm.

[0012] Furthermore, the intelligent conflict handling process includes: sending a notification to the user's App, obtaining user confirmation and authorization in the App, writing the latest configuration data and identity token file to the current storage card in the cloud, and rebinding the token ID, the unique identifier of the IoT device, and the current timestamp.

[0013] Secondly, this invention provides a secure storage and migration system for IoT device configuration data, comprising: an IoT device with a removable memory card, a memory card, and a cloud; core configuration data is stored only on the memory card; the IoT device, memory card, and cloud are used to execute the following process: When a memory card is inserted into an unconfigured IoT device, the IoT device requests an identity token file from the memory card. If no identity token file is obtained, the device performs the initial binding and identity token generation process. If an identity token file is obtained, the device performs the offline migration process for configuration data. Initial binding and identity token writing process: The IoT device sends a request with a unique identifier to the cloud; after receiving the request, the cloud platform generates a dynamic and unique identity token file and sends it to the IoT device. The identity token file contains a unique token ID, a key for data encryption, and a status flag marked "inactive"; the IoT device writes the identity token file to a storage card, then uses the key in the identity token file to encrypt all configuration data before writing it to the storage card, and reports the token ID on the storage card to the cloud. The cloud database uniquely binds the token ID, the IoT device's unique identifier, and the current timestamp, and records the binding relationship between the storage card and the IoT device for verification and dynamic management. Configuration data offline migration process: When the IoT device is offline, read the identity token file in the storage card, verify the integrity of the identity token file, and check whether the status flag is "inactive". After the verification is successful, use the key in the identity token file to decrypt and load the encrypted configuration data in the storage card.

[0014] Furthermore, after the offline migration process of the configuration data, a network activation process is also included: after the IoT device is connected to the network, it reports the token ID and its own unique identifier to the cloud; the cloud updates the status flag of the identity token file to "activated" and permanently binds it to the new IoT device, while marking the binding relationship of the old IoT device as invalid; then the cloud generates a new identity token file in an "inactive" state and sends it to the IoT device.

[0015] Furthermore, the IoT device is also used to perform a data synchronization process: when a user configures the device through a mobile application, the IoT device writes the new configuration data and cloud timestamp to the storage card and synchronizes it to the cloud database.

[0016] Furthermore, the cloud is also used to perform a timestamp comparison process: when an IoT device connects to the cloud, the cloud compares the latest timestamp on the storage card with the latest timestamp recorded in the cloud database; if they match, the cloud provides services normally; if they do not match, the cloud obtains the unique identifier of the IoT device and determines whether the token ID and the unique identifier of the IoT device are consistent with the binding relationship of the storage; if they match, the intelligent conflict handling process is initiated; if they do not match, the cloud further determines whether the IoT device it is bound to is online; if it is offline, the cloud initiates a data recovery process; if it is online, the card is identified as illegally copied, the cloud refuses its service and issues an alarm.

[0017] Furthermore, the intelligent conflict handling process includes: sending a notification to the user's App, obtaining user confirmation and authorization in the App, writing the latest configuration data and identity token file to the current storage card in the cloud, and rebinding the token ID, the unique identifier of the IoT device, and the current timestamp.

[0018] The technical solution provided in this embodiment of the invention innovatively binds the core configuration data of IoT devices to a storage card and combines it with a cloud-based dynamic management mechanism, significantly solving several pain points in the prior art and bringing the following outstanding beneficial effects: 1. Reduced After-Sales and Maintenance Costs: By decoupling configuration data from the IoT device hardware, the memory card becomes an independent and hot-swappable data and identity carrier. When an IoT device needs to be replaced due to hardware failure, users do not need to wait for professional technicians to provide on-site service or perform complex device reconfiguration. Users only need to purchase a new device of the same series, insert the memory card, and complete the seamless migration and recovery of data. This "plug-and-play" model simplifies the device replacement process from a technical issue to a simple physical operation, significantly reducing manufacturers' after-sales service costs and users' waiting time.

[0019] 2. Instant Recovery in Offline Mode: Another significant advantage of this invention is that the new device can load configuration data via the storage card even when completely offline. This is crucial for scenarios with unstable or no network connectivity. Even in environments without network access, users can restore normal system operation by replacing the gateway, ensuring service continuity and reliability.

[0020] 3. Enhanced User Experience and Data Security: Traditional device failures often lead to data loss, causing significant inconvenience. This invention securely backs up core data locally on a storage card, ensuring data integrity even if the device is completely damaged, providing users with unprecedented peace of mind. Furthermore, through a cloud-based timestamp verification mechanism, this invention intelligently identifies illegally copied cards or outdated backup cards, guiding users to authorize or recover data, effectively preventing malicious cloning and data conflicts, and ensuring the uniqueness and security of user data.

[0021] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0023] Figure 1 This is a flowchart illustrating the overall process of the method in Embodiment 1 of the present invention. Figure 2 This is a schematic diagram of the system architecture in Embodiment 1 of the present invention; Figure 3 This is a flowchart of the initial configuration and identity token writing process in Embodiment 1 of the present invention; Figure 4 This is a flowchart of offline migration and online activation in Embodiment 1 of the present invention; Figure 5 This is a flowchart of data synchronization and conflict resolution based on timestamps in Embodiment 1 of the present invention; Figure 6 This is a flowchart illustrating the dynamic switching of the TF card and the update of the cloud binding relationship in Embodiment 1 of the present invention. Figure 7 This is a schematic diagram of the system structure in Embodiment 2 of the present invention. Detailed Implementation

[0024] This invention provides a method and system for secure storage and migration of IoT device configuration data. By binding the core configuration data of IoT devices to a memory card and combining it with a cloud-based dynamic management mechanism, it reduces the after-sales service costs for manufacturers and the waiting time for users.

[0025] The overall concept of the technical solutions in the embodiments of the present invention is as follows: By decoupling the core configuration data of IoT devices from the devices themselves and instead using a memory card as the sole, hot-swappable data and identity carrier, this fundamentally changes the traditional hardware-dependent model, shifting the responsibility of data storage to the user and greatly simplifying device management and after-sales processes.

[0026] Specifically, when a user receives a new IoT device (such as a smart gateway), no complex configuration is required. All critical information, including network settings, a list of paired sub-devices, user permissions, and automation scenarios, is securely stored on a memory card (such as a TF card). When the old gateway fails, the user simply needs to remove the TF card and insert it into the new gateway. The new gateway can then read the data from the card and seamlessly load the configuration, achieving a "plug and play" effect, even when completely offline.

[0027] To address the issues of unauthorized copying and data consistency, this invention introduces a robust cloud management mechanism. Each memory card is bound to a dynamically generated "identity token" in the cloud. During daily use, IoT devices continuously write the latest data (such as new devices, scenarios, etc.) to the memory card and synchronize timestamped records to the cloud. By comparing the timestamps on the memory card with its own records, the cloud can accurately determine whether the currently used card is the latest and most valid one. If an outdated backup card or an unauthorized copied card is detected connecting to the network, the system will not directly reject it but will initiate a user guidance process, prompting the user to authenticate and synchronize data, thereby ensuring that only the latest, authorized devices can function properly.

[0028] This memory card-centric design allows users to switch between multiple gateways at any time. The cloud always recognizes only "which device has a memory card inserted and is online," dynamically updating its binding relationship to ensure data uniqueness and security. This not only greatly reduces reliance on technical personnel for after-sales maintenance but also gives users absolute control over their own data, truly realizing the core concept of "local backup and instant switching." Example 1

[0029] This embodiment provides a method for secure storage and migration of configuration data for Internet of Things (IoT) devices, such as... Figure 1 As shown, including; When a memory card is inserted into an unconfigured IoT device, the IoT device requests an identity token file from the memory card. If no identity token file is obtained, the device performs the initial binding and identity token generation process. If an identity token file is obtained, the device performs the offline migration process for configuration data. S1. Initial Binding and Identity Token Writing Process: The IoT device sends a request with a unique identifier to the cloud; after receiving the request, the cloud platform generates a dynamic and unique identity token file and sends it to the IoT device. The identity token file contains a unique token ID, a key for data encryption, and a status flag marked "inactive"; the IoT device writes the identity token file to the storage card, then uses the key in the identity token file to encrypt all configuration data and writes it to the storage card, and reports the token ID on the storage card to the cloud. The cloud database uniquely binds the token ID, the IoT device's unique identifier, and the current timestamp, and records the binding relationship between the storage card and the IoT device for verification and dynamic management. S2. Configuration data offline migration process: When the IoT device is offline, read the identity token file in the storage card, verify the integrity of the identity token file, and check whether the status flag is "inactive". After the verification is successful, use the key in the identity token file to decrypt and load the encrypted configuration data in the storage card.

[0030] By decoupling configuration data from IoT device hardware, the memory card becomes an independent and hot-swappable data and identity carrier. When a gateway needs to be replaced due to hardware failure, users don't need to wait for on-site service or perform complex device reconfiguration. They simply purchase a new device of the same series, insert the memory card, and seamlessly migrate and restore the data. The new device can load configuration data via the memory card even when completely offline, without requiring an internet connection, restoring all configurations of the old device and achieving seamless takeover. This is crucial for scenarios with unstable or no network connectivity. Even in environments without a network, users can restore normal system operation by replacing the device, ensuring service continuity and reliability.

[0031] Preferably, after the offline migration process of the configuration data, a network activation process is also included: after the IoT device is connected to the network, it reports the token ID and its own unique identifier to the cloud; the cloud updates the status flag of the identity token file to "activated" and permanently binds it to the new IoT device, while marking the binding relationship of the old IoT device as invalid; then the cloud generates a new identity token file in an "inactive" state and sends it to the IoT device for use when the device is replaced next time.

[0032] Preferably, the method further includes: 1. Data Synchronization Process: When a user configures the device via a mobile application, the IoT device writes the new configuration data and a cloud timestamp to the storage card and synchronizes it to the cloud database. When the IoT device connects to the network, it compares the latest timestamp on the TF card with the latest timestamp recorded in the cloud database in real time. This timestamp-based data synchronization mechanism ensures data consistency and effectively prevents unauthorized copying.

[0033] 2. Timestamp Comparison Process: When an IoT device connects to the cloud, the cloud compares the latest timestamp on the storage card with the latest timestamp recorded in the cloud database. If they match, it indicates that the device is using the latest configuration data, and the cloud provides normal service. If they do not match, the cloud obtains the IoT device's unique identifier and checks whether the token ID matches the IoT device's unique identifier and the storage binding relationship. If they match, it indicates that the storage card is legitimate but the data is outdated, and the intelligent conflict handling process is initiated. If they do not match, the cloud further checks whether the IoT device bound to the token ID is online. If it is online, the storage card is identified as illegally copied, the cloud refuses its service, and issues an alert. If it is offline, it is determined to be a data recovery scenario after storage card damage, and the data recovery process is initiated. The cloud sends a prompt to the user's app and provides data recovery options. After user authorization, the cloud will synchronize the latest cloud data to this backup card and write a new identity token file, binding it as a new legitimate identity card. The cloud backend will only recognize the IoT device currently connected to the network and inserting the storage card as a valid device, and dynamically update its binding relationship.

[0034] The intelligent conflict handling process includes: sending a notification to the user's App, obtaining user confirmation and authorization in the App, writing the latest configuration data and identity token file to the current storage card in the cloud, and rebinding the token ID, the unique identifier of the IoT device, and the current timestamp.

[0035] Through a cloud-based timestamp verification mechanism, the system can intelligently identify illegally copied cards or outdated backup cards and guide users to authorize or restore data, effectively preventing malicious cloning and data conflicts and ensuring the uniqueness and security of user data.

[0036] In one specific embodiment, the method for secure storage and migration of configuration data in IoT devices based on memory cards is implemented through the collaborative work of a smart gateway, a TF card, a cloud server, and a user mobile application (App), such as... Figure 2 As shown, the implementation process in different application scenarios includes: I. Initial Binding and Identity Token Generation When a new TF card is inserted into an unconfigured gateway for the first time, the gateway starts up and attempts to connect to the cloud server. For example... Figure 3 As shown, this process is completed through the following steps: The gateway sends a request for its unique identifier (such as a MAC address) to the cloud server.

[0037] After receiving the request, the cloud platform generates a dynamic and unique identity token file (named token.dat). This file contains a unique token ID (UUID), a one-time key for data encryption, and a status flag marked "inactive".

[0038] The cloud sends the identity token file to the smart gateway.

[0039] The gateway writes the file to the root directory of the TF card and uses the key in the file to encrypt all configuration data (such as Wi-Fi credentials, sub-device pairing information, scene settings, etc.) before storing them on the TF card.

[0040] Simultaneously, the gateway reports the token ID on the TF card to the cloud. The cloud database uniquely binds this token ID, the gateway MAC address, and the current timestamp, and records the initial correspondence between the TF card and the gateway.

[0041] Scenario 1: Gateway failure, replacement with a new gateway (implemented in offline mode) This scenario aims to address the issue of gateway hardware failure causing devices to become unusable.

[0042] The user removes the TF card from the damaged old gateway, inserts it into a new, unconfigured gateway of the same model, and performs the offline migration and online activation process, such as... Figure 4 As shown.

[0043] After the new gateway starts up, it first reads the TF card in a completely offline state. The gateway firmware will recognize the token.dat file in the root directory of the TF card.

[0044] The gateway's built-in offline verification algorithm checks the integrity and format of the token.dat file and reads its "inactive" status.

[0045] Once verification is successful, the new gateway will use the key in token.dat to decrypt and load the encrypted configuration data on the TF card. This process does not require an internet connection, and the gateway can restore all the configurations of the old gateway, achieving seamless takeover.

[0046] Once the new gateway is connected to the network, it will automatically report its token ID and its new identifier to the cloud. The cloud system will update the token status to "activated" and permanently bind it to the new gateway, while marking the binding relationship with the old gateway as invalid. Subsequently, the cloud will generate a new "inactive" token for the card and the new gateway, ready for use the next time the gateway is changed.

[0047] Implementation Scenario 2: Data Synchronization and Conflict Resolution This embodiment ensures data consistency and effectively prevents unauthorized copying through a timestamp-based data synchronization mechanism. The timestamp-based data synchronization and conflict resolution process is as follows: Figure 5 As shown.

[0048] In daily use, whenever a user performs device operations through the mobile application (such as adding a device, changing scene settings, adjusting the alarm clock, etc.), the gateway will write the new configuration data to the TF card.

[0049] Each write operation will synchronize a latest cloud timestamp to the TF card and then synchronize that timestamp to the cloud database.

[0050] When the gateway connects to the network, it compares the latest timestamp on the TF card with the latest timestamp recorded in the cloud database in real time.

[0051] Scenario 1 (Normal Data Synchronization): If the timestamp on the TF card is consistent with or updated in the cloud, it indicates that the current device is using the latest configuration data and the cloud is providing normal services.

[0052] Scenario 2 (Data Conflict): If the timestamp in the cloud is updated, it indicates that a card (possibly another TF card or backup card) was online and wrote updated data. In this case, the cloud has reason to believe that the data on this card is outdated. The cloud will not directly refuse service, but will initiate an intelligent conflict handling process: The cloud will send a notification to the user's app: "Your TF card data has expired. Do you want to switch and sync the latest data?" Only after the user confirms and authorizes on the App will the cloud write the latest configuration data and token file to the current TF card and rebind the gateway as a valid device.

[0053] Scenario 3: TF card damaged, restore using backup card This scenario aims to solve the problem of how to recover data using a previous backup card or a new card after a TF card is damaged.

[0054] If a user discovers that their TF card is damaged, they can use a local backup card (e.g., a copy previously backed up to their computer) or a brand new TF card.

[0055] The user inserts the backup card into the gateway. After the gateway loads the old data locally, once connected to the network, the cloud will compare the timestamps to determine that the card's data is outdated.

[0056] The cloud will determine if the previously bound gateway is online. If it is online, the card is considered illegally copied, and the cloud will refuse its service and issue an alert. If the previously bound gateway is offline, the cloud will determine it to be a data recovery scenario after the TF card has been damaged.

[0057] The cloud sends a notification to the user's app and provides data recovery options.

[0058] After user authorization, the cloud will synchronize the latest cloud data to this backup card and write a new identity token file, binding it as a new legitimate identity card. If the user refuses, local data will be preserved, and the user's refusal will be recorded.

[0059] II. Cloud Updates and Gateway Switching The core of this invention lies in the fact that the TF card is a unique authorization key. The cloud backend will only recognize the gateway to which the current TF card is inserted and connected to the network as a valid device, and will dynamically update its binding relationship. For example... Figure 6 As shown, when a user switches the TF card between different gateways, the cloud will switch the binding relationship to the gateway that first reports its online status, and at the same time invalidate the cloud authorization of the previously bound gateway.

[0060] Based on the same inventive concept, this application also provides a system corresponding to the method in Embodiment 1, as detailed in Embodiment 2. Example 2

[0061] This embodiment provides a secure storage and migration system for IoT device configuration data, such as... Figure 7 As shown, it includes: an IoT device with a removable memory card, the memory card, and the cloud, and also needs to work in conjunction with a user's mobile application (App); core configuration data is stored only on the memory card; the IoT device, memory card, and cloud are used to execute the following processes: When a memory card is inserted into an unconfigured IoT device, the IoT device requests an identity token file from the memory card. If no identity token file is obtained, the device performs the initial binding and identity token generation process. If an identity token file is obtained, the device performs the offline migration process for configuration data. Initial binding and identity token writing process: The IoT device sends a request with a unique identifier to the cloud; after receiving the request, the cloud platform generates a dynamic and unique identity token file and sends it to the IoT device. The identity token file contains a unique token ID, a key for data encryption, and a status flag marked "inactive"; the IoT device writes the identity token file to a storage card, then uses the key in the identity token file to encrypt all configuration data before writing it to the storage card, and reports the token ID on the storage card to the cloud. The cloud database uniquely binds the token ID, the IoT device's unique identifier, and the current timestamp, and records the binding relationship between the storage card and the IoT device for verification and dynamic management. Configuration data offline migration process: When the IoT device is offline, read the identity token file in the storage card, verify the integrity of the identity token file, and check whether the status flag is "inactive". After the verification is successful, use the key in the identity token file to decrypt and load the encrypted configuration data in the storage card.

[0062] Furthermore, after the offline migration process of the configuration data, a network activation process is also included: after the IoT device is connected to the network, it reports the token ID and its own unique identifier to the cloud; the cloud updates the status flag of the identity token file to "activated" and permanently binds it to the new IoT device, while marking the binding relationship of the old IoT device as invalid; then the cloud generates a new identity token file in an "inactive" state and sends it to the IoT device.

[0063] Furthermore, the IoT device is also used to perform a data synchronization process: when a user configures the device through a mobile application, the IoT device writes the new configuration data and cloud timestamp to the storage card and synchronizes it to the cloud database.

[0064] Furthermore, the cloud is also used to perform a timestamp comparison process: when an IoT device connects to the cloud, the cloud compares the latest timestamp on the storage card with the latest timestamp recorded in the cloud database; if they match, the cloud provides services normally; if they do not match, the cloud obtains the unique identifier of the IoT device and determines whether the token ID and the unique identifier of the IoT device are consistent with the binding relationship of the storage; if they match, the intelligent conflict handling process is initiated; if they do not match, the cloud further determines whether the IoT device it is bound to is online; if it is offline, the cloud initiates a data recovery process; if it is online, the card is identified as illegally copied, the cloud refuses its service and issues an alarm.

[0065] Furthermore, the intelligent conflict handling process includes: sending a notification to the user's App, obtaining user confirmation and authorization in the App, writing the latest configuration data and identity token file to the current storage card in the cloud, and rebinding the token ID, the unique identifier of the IoT device, and the current timestamp.

[0066] Since the system described in Embodiment 2 of this invention is a system used to implement the method of Embodiment 1 of this invention, those skilled in the art can understand the specific structure and variations of this system based on the method described in Embodiment 1 of this invention, and therefore will not be repeated here. All systems used in the method of Embodiment 1 of this invention fall within the scope of protection of this invention.

[0067] The technical solution provided in this embodiment of the invention innovatively binds the core configuration data of IoT devices to a storage card and combines it with a cloud-based dynamic management mechanism, significantly solving several pain points in the prior art and bringing the following outstanding beneficial effects: 1. Reduced After-Sales and Maintenance Costs: By decoupling configuration data from the IoT device hardware, the memory card becomes an independent and hot-swappable data and identity carrier. When an IoT device needs to be replaced due to hardware failure, users do not need to wait for professional technicians to provide on-site service or perform complex device reconfiguration. Users only need to purchase a new device of the same series, insert the memory card, and complete the seamless migration and recovery of data. This "plug-and-play" model simplifies the device replacement process from a technical issue to a simple physical operation, significantly reducing manufacturers' after-sales service costs and users' waiting time.

[0068] 2. Instant Recovery in Offline Mode: Another significant advantage of this invention is that the new device can load configuration data via the storage card even when completely offline. This is crucial for scenarios with unstable or no network connectivity. Even in environments without network access, users can restore normal system operation by replacing the gateway, ensuring service continuity and reliability.

[0069] 3. Enhanced User Experience and Data Security: Traditional device failures often lead to data loss, causing significant inconvenience. This invention securely backs up core data locally on a storage card, ensuring data integrity even if the device is completely damaged, providing users with unprecedented peace of mind. Furthermore, through a cloud-based timestamp verification mechanism, this invention intelligently identifies illegally copied cards or outdated backup cards, guiding users to authorize or recover data, effectively preventing malicious cloning and data conflicts, and ensuring the uniqueness and security of user data.

[0070] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0071] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0072] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0073] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0074] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for secure storage and migration of configuration data for Internet of Things (IoT) devices, characterized in that, include: When a memory card is inserted into an unconfigured IoT device, the IoT device requests an identity token file from the memory card. If the identity token file is not obtained, the initial binding and identity token generation process is executed. If the identity token file is obtained, the offline migration process for configuration data will be executed. Initial binding and identity token writing process: The IoT device sends a request with a unique identifier to the cloud; After receiving the request, the cloud platform generates a dynamic and unique identity token file and sends it to the IoT device. The identity token file contains a unique token ID, a key for data encryption, and a status flag marked "inactive". The IoT device writes the identity token file to the storage card, then uses the key in the identity token file to encrypt all configuration data before writing it to the storage card, and reports the token ID on the storage card to the cloud. The cloud database uniquely binds the token ID, the IoT device's unique identifier, and the current timestamp, and records the binding relationship between the storage card and the IoT device for verification and dynamic management. Configure the offline data migration process: When the IoT device is offline, read the identity token file in the storage card, verify the integrity of the identity token file, and check whether the status flag is "inactive". After successful verification, the encrypted configuration data in the memory card is decrypted and loaded using the key in the identity token file.

2. The method according to claim 1, characterized in that, Following the offline migration process of the configuration data, there is also a network activation process: after the IoT device is connected to the network, it reports the token ID and its own unique identifier to the cloud; the cloud updates the status flag of the identity token file to "activated" and permanently binds it to the new IoT device, while marking the binding relationship of the old IoT device as invalid. The cloud then generates a new "inactive" identity token file and sends it to the IoT device.

3. The method according to claim 1, characterized in that, The method also includes a data synchronization process: when a user configures the device through a mobile application, the IoT device writes the new configuration data and cloud timestamp to the storage card and synchronizes it to the cloud database.

4. The method according to claim 3, characterized in that, The method also includes a timestamp comparison process: when an IoT device connects to the cloud, the cloud compares the latest timestamp on the storage card with the latest timestamp recorded in the cloud database; If they match, the cloud provides normal service; if they do not match, the unique identifier of the IoT device is obtained, and it is determined whether the token ID and the unique identifier of the IoT device are consistent with the binding relationship in the storage. If they match, the intelligent conflict handling process is initiated; if they do not match, it is further determined whether the IoT device it is bound to is online. If it is offline, the data recovery process is initiated; if it is online, the card is identified as illegally copied, the cloud refuses its service and issues an alarm.

5. The method according to claim 4, characterized in that, The intelligent conflict handling process includes: sending a notification to the user's App, obtaining user confirmation and authorization in the App, writing the latest configuration data and identity token file to the current storage card in the cloud, and rebinding the token ID, the unique identifier of the IoT device, and the current timestamp.

6. A system for secure storage and migration of configuration data for Internet of Things (IoT) devices, characterized in that, include: IoT devices with removable memory cards, memory cards, and the cloud; core configuration data is stored only on the memory card; The IoT device, memory card, and cloud are used to execute the following process: When a memory card is inserted into an unconfigured IoT device, the IoT device requests an identity token file from the memory card. If the identity token file is not obtained, the initial binding and identity token generation process is executed. If the identity token file is obtained, the offline migration process for configuration data will be executed. Initial binding and identity token writing process: The IoT device sends a request with a unique identifier to the cloud; After receiving the request, the cloud platform generates a dynamic and unique identity token file and sends it to the IoT device. The identity token file contains a unique token ID, a key for data encryption, and a status flag marked "inactive". The IoT device writes the identity token file to the storage card, then uses the key in the identity token file to encrypt all configuration data before writing it to the storage card, and reports the token ID on the storage card to the cloud. The cloud database uniquely binds the token ID, the IoT device's unique identifier, and the current timestamp, and records the binding relationship between the storage card and the IoT device for verification and dynamic management. Configure the offline data migration process: When the IoT device is offline, read the identity token file in the storage card, verify the integrity of the identity token file, and check whether the status flag is "inactive". After successful verification, the encrypted configuration data in the memory card is decrypted and loaded using the key in the identity token file.

7. The system according to claim 5, characterized in that, Following the offline migration process of the configuration data, there is also a network activation process: after the IoT device is connected to the network, it reports the token ID and its own unique identifier to the cloud; the cloud updates the status flag of the identity token file to "activated" and permanently binds it to the new IoT device, while marking the binding relationship of the old IoT device as invalid. The cloud then generates a new "inactive" identity token file and sends it to the IoT device.

8. The system according to claim 5, characterized in that, The IoT device is also used to perform a data synchronization process: when a user configures the device through a mobile application, the IoT device writes the new configuration data and cloud timestamp to the storage card and synchronizes it to the cloud database.

9. The system according to claim 8, characterized in that, The cloud is also used to perform a timestamp comparison process: when an IoT device connects to the cloud, the cloud compares the latest timestamp on the storage card with the latest timestamp recorded in the cloud database; if they match, the cloud provides normal service; if they do not match, the cloud obtains the unique identifier of the IoT device and determines whether the token ID and the unique identifier of the IoT device are consistent with the binding relationship of the storage; if they match, the intelligent conflict handling process is initiated; if they do not match, the cloud further determines whether the IoT device it is bound to is online; if it is offline, the cloud initiates a data recovery process; if it is online, the card is identified as illegally copied, the cloud refuses its service and issues an alarm.

10. The system according to claim 9, characterized in that, The intelligent conflict handling process includes: sending a notification to the user's App, obtaining user confirmation and authorization in the App, writing the latest configuration data and identity token file to the current storage card in the cloud, and rebinding the token ID, the unique identifier of the IoT device, and the current timestamp.

Images