Smart card and number management method thereof, Internet of Things equipment and storage medium

Abstract

The invention relates to the technical field of Internet of Things equipment, and discloses a smart card and a number management method thereof, Internet of Things equipment and a storage medium, the method is applied to an eSIM chip with a plurality of built-in Profiles, a seed number uniquely bound with the Internet of Things equipment is preset in the eSIM chip, and the method comprises the following steps: in response to a startup instruction of the Internet of Things equipment, starting the seed number in the eSIM chip, starting the seed number in the eSIM chip, and starting the eSIM chip; establishing communication connection with an equipment management platform based on the seed number, and waiting for a notification sent by the equipment management platform; if an equipment management notification sent by the equipment management platform is received, executing a corresponding first equipment management task based on the seed number, and after the execution of the first equipment management task is completed, switching the seed number to the user number to complete equipment startup; and if a normal startup notification sent by the equipment management platform is received, switching the seed number to the user number to complete equipment startup. According to the invention, the problem of unclear traffic affiliation in an Internet of Things scene can be effectively solved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) device technology, and in particular to a smart card and its number management method, IoT device and storage medium. Background Technology

[0002] With the rapid development of IoT technology, smart wearable devices, trackers, remote monitoring terminals, and other IoT devices are widely used in fields such as personal health, asset management, and industrial monitoring. These devices typically rely on cellular networks for internet communication, and traditional solutions often involve users purchasing their own SIM cards or data plans to access the network.

[0003] However, in existing technical solutions, system maintenance communication traffic generated during normal device operation (such as heartbeat packet reporting, firmware update downloads, status synchronization, etc.) is often downloaded or transmitted through user accounts, with the related traffic costs borne by the user. This results in users having to pay extra for background management traffic even when they are not actively using the device's functions, creating a hidden cost burden. Users generally believe that such maintenance traffic should fall within the scope of basic device services and are unwilling to pay for it, leading to a decline in user experience or even service interruption.

[0004] Furthermore, due to the lack of an effective mechanism for distinguishing communication identities, devices cannot independently complete device management tasks (such as firmware updates, configuration distribution, status reporting, and data backup) without user intervention. Some manufacturers have attempted to separate different types of data streams by configuring dedicated APNs (Access Point Names), but this solution relies on operator support, is complex to deploy, and has high supply chain coordination costs. Other solutions rely on application-layer traffic classification or manual switching of network modes, which suffers from high device load, cumbersome operation, and poor real-time performance.

[0005] Therefore, existing IoT devices have obvious shortcomings in number management and traffic allocation: on the one hand, they cannot effectively isolate system maintenance traffic from user business traffic, resulting in unclear pricing responsibilities; on the other hand, they lack automated and seamless back-end communication mechanisms, making it difficult to balance user experience and device maintainability. Summary of the Invention

[0006] In view of this, embodiments of this application provide a smart card number management method, a smart card, an IoT device, and a computer-readable storage medium. By pre-setting a seed number uniquely bound to the device, seamless device management without user traffic involvement is achieved during the power-on phase. This not only ensures the manufacturer's full lifecycle control over the device but also avoids users paying for background maintenance traffic, effectively solving the problem of unclear traffic ownership in IoT scenarios.

[0007] In a first aspect, embodiments of this application provide a smart card number management method, applied to an eSIM chip with multiple built-in profiles, wherein the eSIM chip has a seed number pre-set that is uniquely bound to an IoT device, and the method includes: In response to the power-on command of the IoT device, the seed number in the eSIM chip is activated, a communication connection is established with the device management platform based on the seed number, and the device waits for a notification sent by the device management platform. If a device management notification is received from the device management platform, the corresponding first device management task is executed based on the seed number. After the first device management task is completed, the seed number is switched to the user number to complete the device power-on. If a normal power-on notification is received from the device management platform, the seed number is switched to the user number to complete the device power-on.

[0008] In an optional implementation, the method further includes: if the IoT device enters a maintenance state, the eSIM chip, in response to a device maintenance notification sent by the IoT device, switches the user number to the seed number, establishes a communication connection with the device management platform based on the seed number, and executes a second device management service; The maintenance status refers to the IoT device not detecting any user operation or function call events within a preset time period.

[0009] In an optional implementation, the second device management service is an incremental data compression and upload service; the step of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically includes: The eSIM chip compresses the service data calculated by the IoT device using a differential algorithm and then uploads it to the device management platform.

[0010] In an optional implementation, the second device management service is an encrypted command service; the step of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically includes: The eSIM chip decrypts the encrypted command packet sent by the device management platform and forwarded by the IoT device using a pre-negotiated session key to obtain command data, and completes the download or update of services based on the command data.

[0011] In an optional implementation, the second device management service is an abnormal status alarm service; the step of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically includes: The eSIM chip receives an abnormal status alarm notification sent by the IoT device and performs emergency backup of critical data based on the seed number.

[0012] In an optional implementation, the method further includes: if the IoT device enters a preset emergency state, the eSIM chip responds to the emergency notification sent by the IoT device by switching the user number to the seed number, establishing a communication connection with the device management platform based on the seed number, and sending an emergency command to the device management platform to perform data erasure or device locking operations; wherein, the emergency state includes one or more of the following: a forced disassembly event, an illegal SIM card removal event, and a risk of leakage of sensitive user data.

[0013] In an optional implementation, the method further includes: when the IoT device is powered on for the first time, executing a two-way authentication process between the IoT device and the device management platform; The two-way authentication process includes: The IoT device initiates a secure communication request to the device management platform so that the device management platform can send platform identity credentials. The IoT device verifies the platform's identity credentials based on a pre-set root of trust. After the device management platform verifies the identity, the IoT device sends its device identity credentials to the device management platform. Once the device management platform verifies the device identity credentials based on a pre-set trust mechanism, the two-way identity authentication is successful. The IoT device establishes an encrypted communication channel with the device management platform and performs data communication based on the encrypted communication channel.

[0014] Secondly, embodiments of this application provide a smart card, including a multi-profile storage module for storing at least two communication numbers; the communication numbers include the aforementioned seed number and user number.

[0015] Thirdly, embodiments of this application provide an Internet of Things (IoT) device, including a processor, an eSIM chip, and a memory; The memory stores computer programs; The eSIM chip is used to store a preset seed number and a dynamically configured user number; The processor is used to execute the computer program to implement the smart card number management method described above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed on a processor, implements the aforementioned smart card number management method.

[0017] The embodiments of this application have the following beneficial effects: This application pre-installs a seed number uniquely bound to the IoT device in the eSIM chip, and prioritizes using this seed number to establish a communication connection with the device management platform when the device is powered on, thereby achieving controllable access during the device startup phase. This solution enables the device to complete the inspection and execution of system-level management tasks without the user's awareness, avoiding the data traffic fee disputes and user experience degradation issues caused by using user numbers for background communication in traditional technologies. By establishing a manufacturer-led management channel during the power-on initialization phase, it ensures that the device can obtain necessary updates and configuration information in a timely manner, thereby improving the timeliness and reliability of device management. At the same time, after completing necessary operations, it automatically switches to the user number, ensuring the normal operation of user services, effectively isolating the management process from the usage process, and improving the system's security and maintainability. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This paper illustrates a first flowchart of a smart card number management method according to an embodiment of this application. Figure 2 A second flowchart of the smart card number management method according to an embodiment of this application is shown. Detailed Implementation

[0020] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0021] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0023] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0024] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0025] The following examples illustrate the smart card number management method.

[0026] Figure 1 A schematic flowchart of a smart card number management method according to an embodiment of this application is shown. Exemplarily, this smart card number management method is applied to an eSIM chip with multiple built-in profiles, the eSIM chip having a pre-set seed number uniquely bound to an IoT device.

[0027] The seed ID is an independent communication profile pre-written into the secure area of ​​the eSIM chip during the manufacturing process by the device manufacturer. It contains complete network access configuration information (such as IMSI, authentication key Ki, carrier code, APN parameters, etc.). This seed ID is strongly bound to the device's unique hardware identifier (such as device serial number SN, chip ID), and is unchangeable and uncopyable. It is also associated by default with a manufacturer-specific Access Point Name (APN) for direct connection to the device management platform. The user ID, on the other hand, can be written into the same eSIM chip remotely (such as the SM-DP+ protocol) to carry traffic for user-initiated services (such as audio and video calls, application data interactions, etc.).

[0028] The smart card number management method includes the following steps S110-S130: Step S110: In response to the power-on command of the IoT device, the seed number in the eSIM chip is enabled, a communication connection is established with the device management platform based on the seed number, and the device management platform is waited for a notification.

[0029] As an example, when an IoT device receives a power-on command triggered by a user (such as pressing the power button, connecting to external power, or activating via a wake-up signal), the device initiates a system initialization process and sends a command to the built-in eSIM chip to activate a preset seed number. After successful seed number activation, the eSIM chip, based on the seed number, initiates a connection request to the device management platform using a preset server address (URL). This connection is used to transmit device status information and receive management commands; the resulting data traffic is billed based on the seed number and is not included in the user's billing account.

[0030] After the connection is established, the device enters a listening state, maintaining a long connection or periodic heartbeat mechanism with the device management platform, waiting for notification messages from the platform. These notification messages include two types: (1) Device management notification: Indicates that there are management tasks to be performed on the device, such as firmware upgrade, configuration update, remote diagnosis, etc.; (2) Normal power-on notification: Confirms that no background tasks need to be performed at present, allowing the device to directly enter the user mode.

[0031] At this stage, the device has not yet activated the user number, and all communication is completed through the seed number. This ensures that even if the user has not activated the service or the user number is configured abnormally, the device can still maintain basic communication capabilities with the management platform, thus ensuring the manageability of the device.

[0032] In this embodiment, the IoT device automatically prioritizes starting the seed number each time it is powered on, without user intervention. This method enables the device to complete interaction with the device management platform before powering on, thereby achieving device management and providing time for seamless execution of device management tasks.

[0033] If a device management notification is received from the device management platform, step S120 is executed, the corresponding first device management task is executed based on the seed number, and after the first device management task is completed, the seed number is switched to the user number to complete the device power-on.

[0034] For example, if the device management platform detects that the IoT device has a first device management task to be executed (such as new firmware release, security patch update, personalized configuration distribution, remote diagnostic command, etc.), it sends a device management notification to the IoT device, which includes, but is not limited to, information such as task type, resource URL, and expected execution time window.

[0035] Upon receiving the notification, the device immediately downloads the relevant service content through the data channel corresponding to the seed number. Since the traffic cost for this channel is borne by the device manufacturer (isolated through targeted APN billing), no user authorization or awareness is required.

[0036] All primary device management tasks are performed before the operating system completes startup, specifically during the system kernel initialization phase. At this time, the user interface has not yet loaded, and the user has not yet begun operating the device, thus avoiding any interference with normal use. After the primary device management tasks are completed, the device sends a command to the eSIM chip to switch the currently used communication number from the seed number to the subscriber number. The switching process is controlled by the internal logic of the eSIM module and does not involve user interaction, nor does it require redialing or network restart.

[0037] After the switch is complete, the device continues with the subsequent boot process (such as starting the operating system, loading applications, and displaying the welcome screen), and finally enters normal use.

[0038] If a normal power-on notification is received from the device management platform, proceed to step S130 to switch the seed number to the user number and complete the device power-on.

[0039] In this step, if the device management platform verifies that the device does not need to perform any first device management tasks, it will return a normal power-on notification to the device.

[0040] Upon receiving the notification, the device does not need to download or update data; it directly triggers the eSIM chip to switch the communication number from the seed number to the subscriber number. Afterward, the device uses the subscriber number to access the public network and begins to handle user-initiated service traffic (such as logging into social applications and playing online music). The entire process requires no user intervention and does not affect the normal startup of the device.

[0041] It should be noted that regardless of whether the first device management task is executed, the device prioritizes using the seed number each time it is powered on to check for any pending tasks, thus ensuring that the device is always under control. The two-way authentication process is only enforced once upon the device's first power-on; subsequent power-ons can reuse the verified identity context, improving connection efficiency.

[0042] This embodiment, by pre-setting a seed number in the eSIM chip, can complete system-level task processing before the user is aware of it, and determine the number switching strategy based on the task processing results, thereby achieving the organic unity of traffic separation, cost control and security management.

[0043] In some implementations, the method further includes: if the IoT device enters maintenance mode, the eSIM chip responds to the device maintenance notification sent by the IoT device by switching the user number to a seed number, establishing a communication connection with the device management platform based on the seed number, and executing a second device management service.

[0044] The maintenance state refers to the IoT device not detecting any user operation or function call events within a preset time period. For example, in a smart wearable device, if there is no touch input, motion sensing, or application call behavior for 60 consecutive seconds, the device is determined to be in an idle or dormant state and is ready to perform background maintenance tasks; in a tracker device, if there is no location update request or remote query command for 5 consecutive minutes, the device is determined to be in an idle or dormant state and is ready to perform background maintenance tasks.

[0045] Once the above conditions are met, the device generates and sends a device maintenance notification to the eSIM chip, triggering a switch from the subscriber number to the seed number. This switchover process does not require restarting the network module; it is completed autonomously by the eSIM's internal Profile management logic. The entire process is seamless for the user and does not affect running applications or background services.

[0046] After the switchover is complete, the device re-establishes a secure communication connection with the device management platform using the seed number. Since the traffic costs incurred through this channel are borne by the device manufacturer, a series of system-level maintenance tasks, collectively referred to as the second device management service, can be performed without increasing the user's burden. The specific implementation methods vary depending on the task type, as described below.

[0047] If the second device management service is an incremental data compression and upload service; the steps of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically include: the eSIM chip compressing the service data calculated by the IoT device through a differential algorithm and uploading it to the device management platform.

[0048] As an example, when the second device's management service involves incremental data compression and uploading, the device first identifies critical business data in local storage that has not yet been synchronized to the cloud. To reduce transmission overhead, differential algorithms (such as rsync, Bsdiff, etc.) are used to calculate the incremental changes relative to the latest version on the server.

[0049] For example, in health management devices, only newly added heart rate records, sleep scores, or step counts within the past 24 hours are extracted; in environmental monitoring devices, only temperature and humidity sampling points updated since the last synchronization are uploaded. The system can then efficiently compress the differential results (using algorithms such as GZIP or Zstandard) to form a small data packet, which is then uploaded to the device management platform via a seed channel. The platform receives the packet, decompresses it, and merges it into the original dataset, completing data synchronization. This method reduces communication frequency and bandwidth usage, making it particularly suitable for resource-constrained scenarios such as Low Power Wide Area Networks (LPWANs), while avoiding the privacy risks and increased storage costs associated with frequent full-data uploads.

[0050] If the second device management service is an encrypted command service; the steps of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically include: the eSIM chip forwarding the encrypted command packet sent by the device management platform based on the IoT device, decrypting the encrypted command packet using a pre-negotiated session key to obtain command data, and completing the download or update of the service based on the command data.

[0051] For example, when the second device management service involves encrypted command processing, the device management platform can proactively push encrypted command packets to the device to trigger firmware differential upgrades, configuration parameter adjustments, or remote diagnostic commands. These encrypted command packets are encrypted using a pre-negotiated session key (such as AES-GCM mode) before transmission to ensure confidentiality and integrity. Upon receiving the command packet, the device's main control unit forwards it to the eSIM chip or secure element (SE) for decryption and verification.

[0052] After successful decryption, the device parses the original command data and performs corresponding operations based on the command content. Examples include: downloading and silently installing lightweight OTA patches, updating the Wi-Fi whitelist, DNS server addresses or power-saving policies, starting a self-test program and sending back diagnostic logs. Because these operations are all performed through a seed number controlled by the manufacturer, they are not affected by the user's data plan status, and the device can still maintain basic manageability even if the user has not activated cellular service.

[0053] If the second device management service is an abnormal status alarm service; the steps to establish a communication connection with the device management platform based on the seed number and execute the second device management service specifically include: the eSIM chip receiving the abnormal status alarm notification sent by the IoT device, and performing emergency backup of key data based on the seed number.

[0054] For example, when the second device management service is an abnormal status alarm, it is applicable to situations where the device detects potential faults or operational risks. Typical scenarios include low battery, sensor malfunction, and communication interruption warnings.

[0055] Taking low-battery emergency backup as an example: When the device's battery level drops below a preset threshold (e.g., 10%), the main control unit immediately generates an abnormal status alarm notification and notifies the eSIM chip to force a switch to the seed number. Subsequently, the device uses the remaining power to encrypt and upload key data (such as the most recent health measurement result, last location coordinates, and unuploaded operation logs) to the device management platform via the seed number channel.

[0056] This method can proactively upload critical data before the device is about to lose power, effectively reducing the risk of permanent loss of local data due to sudden power outages, thereby effectively improving the timeliness and reliability of data backup.

[0057] In some implementations, the method further includes: if the IoT device enters a preset emergency state, the eSIM chip responds to the emergency notification sent by the IoT device, switches the user number to a seed number, establishes a communication connection with the device management platform based on the seed number, and sends an emergency command to the device management platform to perform data erasure or device locking operations.

[0058] It is understandable that when an IoT device enters a preset emergency state, the eSIM chip responds to the emergency notification sent by the device, immediately switches the currently used user number to a preset seed number, and establishes a communication connection with the device management platform based on the seed number, sending emergency commands to the platform to trigger remote data erasure or device locking operations, thereby preventing the leakage of sensitive information or the illegal use of the device.

[0059] Emergency status refers to abnormal physical or logical events that may endanger device security or user privacy, including but not limited to one or more of the following situations: forced disassembly events (the device casing is forcibly opened or internal sensors detect unauthorized physical intrusion), illegal SIM card removal events (the original eSIM profile is illegally canceled, replaced, or an attempt to insert an external SIM card is detected), and risks of leakage of sensitive user data (the system detects unauthorized access behavior, abnormal network requests, jailbreak / root status, or multiple consecutive incorrect authentication attempts).

[0060] The device incorporates multiple sensing and judgment mechanisms to identify the aforementioned emergency states. For example, it monitors the integrity of the casing through microswitches or Hall sensors, monitors eSIM configuration change logs through a security chip, detects operating system integrity and permission anomalies through a Trusted Execution Environment (TEE) or Secure Element (SE), or combines AI models to analyze user operation behavior patterns and identify abnormal login or usage scenarios.

[0061] Once any emergency condition is triggered, the device immediately generates an emergency notification and sends it to the eSIM chip, instructing it to forcibly switch communication numbers. At this time, regardless of whether the device is currently in use, its battery level, or its network connection status, the seed number is activated first.

[0062] Because the seed ID is uniquely bound to the device hardware and associated with a dedicated APN channel, even if the user ID has been deactivated or the service has been suspended, the device can still establish a secure communication link with the device management platform through this independent path. After the connection is established, the device proactively reports metadata such as the type of emergency event, the timestamp of the event, the last location coordinates, and the device's operating status, and attaches a digital signature to the message to verify the authenticity of the source.

[0063] Subsequently, the device sends an emergency command to the device management platform, requesting the execution of one or more of the following safety actions: 1. Sensitive Data Erasure: Clears highly sensitive information such as user passwords, biometric templates, historical data, and encryption keys from local storage; 2. Remote Device Locking: Prevents the device from restarting core functional modules (such as communication, positioning, and data acquisition), entering a black screen and locked state; 3. Self-Destruct Mode Activation: For high-security devices, it can trigger the security chip to perform irreversible data destruction operations (such as melting the power supply circuit of the storage area).

[0064] After receiving an emergency command and completing identity verification, the device management platform returns a confirmation response. Upon receiving confirmation, the device immediately executes the corresponding operation and sends the execution result back to the platform for filing, forming a complete security audit log. Specifically, in certain extreme cases (such as an impending power outage or signal interruption), the system can upload the last location information and event summary immediately after switching back to the seed number, achieving "last-minute heartbeat" data preservation and greatly improving device tracking and post-incident accountability capabilities. Furthermore, to prevent accidental triggering that renders the device unusable for legitimate users, this embodiment also supports a tiered response strategy. For example: only logging and issuing a warning upon initial detection of suspicious behavior; initiating the data erasure process only after multiple consecutive anomaly determinations; and supporting remote revocation of emergency commands via trusted accounts (such as bound mobile phones or administrator accounts).

[0065] It is understood that this embodiment constructs a rapid-response, independent, and reliable device security protection system by introducing an emergency communication channel based on a seed number. Even in the event of device loss, network outage, or physical attack, critical command transmission can still be completed using a dedicated number controlled by the manufacturer, achieving remote data protection and asset management.

[0066] In some implementations, the method further includes: when the IoT device is powered on for the first time, performing a two-way authentication process between the IoT device and the device management platform. This process aims to ensure the authenticity and trustworthiness of the identities of both communicating parties, preventing forged devices from accessing the platform or illegal servers from inducing devices to disclose sensitive information, thereby ensuring the security and integrity of subsequent data transmission.

[0067] like Figure 2 As shown, the two-way authentication process includes steps S210-S250: In step S210, the IoT device initiates a secure communication request to the device management platform so that the device management platform can send platform identity credentials.

[0068] For example, after the IoT device completes hardware initialization and successfully activates the seed number, the main control unit initiates a secure communication request to the device management platform via a pre-configured Uniform Resource Locator (URL). This request is sent based on the HTTPS protocol and uses the dedicated APN associated with the seed number for network routing. This request does not carry any user identity information or business data; it is merely a signaling trigger action to establish a secure connection. Upon receiving the request, the platform responds by returning its platform identity credentials, namely a server digital certificate issued by a trusted Certificate Authority (CA), which includes, but is not limited to, information such as the platform domain name, public key, validity period, and issuer.

[0069] In step S220, the IoT device verifies the platform identity credentials based on a pre-set root of trust.

[0070] For example, upon receiving the platform's identity credentials, the device initiates a local verification mechanism. Verification is based on a pre-installed root of trust, typically one or more root CA certificates, stored in the secure area of ​​the eSIM chip or Secure Element (SE), and cannot be modified or deleted externally. The verification process includes, but is not limited to: checking whether the server certificate was directly issued by the pre-installed root of trust CA or indirectly trusted through a valid certificate chain; verifying the validity of the certificate signature; confirming that the certificate has not expired and is within its valid timeframe; verifying that the domain name field in the certificate matches the preset server URL; or querying the Certificate Revocation List (CRL) or confirming that the certificate has not been revoked via the OCSP protocol.

[0071] If any of the above verification items fail, the device will immediately terminate the connection process and record a security event log; only when all verifications pass will the device management platform be deemed legitimate and proceed to the next step.

[0072] Step S230: After the device management platform verifies the identity, the IoT device sends its device identity certificate to the device management platform.

[0073] As an example, after verifying the platform's legitimacy, the device proactively sends its device identity certificate back to the device management platform. This certificate is a device certificate pre-written into the eSIM or security chip at the time of manufacture, containing the device's unique identifier (such as IMSI hash, SN serial number), public key, validity period, and issuing CA information.

[0074] The certificate is issued by a trusted CA commissioned by the device manufacturer, or issued by an internal CA within a private PKI system and pre-installed in the device. During transmission, the device certificate is embedded as a client certificate in the client certificate message of the TLS handshake phase and is automatically transmitted along with the communication process.

[0075] Step S240: After the device management platform verifies the device identity credentials based on the preset trust mechanism, the two-way identity authentication is successful.

[0076] For example, after receiving the device identity credential, the device management platform verifies the device's legitimacy. This legitimacy verification includes: verifying the signature validity of the device certificate using the corresponding root CA certificate; checking if the certificate is valid; confirming that the certificate is not on a device blacklist or revocation list; and optionally, comparing whether the device serial number bound to the certificate is registered in the system and in a normal status. If the verification passes, the platform returns a successful authentication response to the device, indicating that two-way authentication is complete. At this point, both parties have confirmed that the other is a legitimate entity, possessing the basic conditions for establishing a high-security level of communication.

[0077] In step S250, an encrypted communication channel is established between the IoT device and the device management platform, and data communication is performed based on the encrypted communication channel.

[0078] After successful two-way authentication, the device and the device management platform negotiate and generate a session key based on the TLS protocol (such as TLS 1.2 or TLS 1.3) and establish an end-to-end encrypted communication channel. AEAD-type encryption algorithms (such as AES-256-GCM) are preferred to simultaneously ensure data confidentiality, integrity, and replay resistance.

[0079] Subsequently, all data transmitted through the seed channel (such as device fingerprint reporting, firmware download, configuration updates, emergency command interaction, etc.) is encapsulated and decrypted through this encrypted channel to eliminate the risk of man-in-the-middle attacks, eavesdropping, or tampering.

[0080] It should be noted that this two-way authentication process is only enforced once when the device is first powered on. During subsequent power-ups, the device can quickly resume communication based on the verified identity context without repeating the complete authentication process, thus balancing security and connection efficiency.

[0081] In addition, during the device's lifecycle, if a certificate expires, a key is leaked, or the platform changes, a new certificate can be remotely pushed through a secure channel and re-authentication can be triggered to ensure long-term security and controllability.

[0082] This embodiment achieves effective separation of device system management traffic and user service traffic by pre-setting a unique seed number bound to the IoT device in the eSIM chip and combining it with a dynamically configured user number. The seed number is dedicated to maintenance communications such as firmware upgrades, status reporting, configuration updates, and data backups. Related traffic costs are borne by the device manufacturer, avoiding user payment for unintentionally generated background traffic and solving the problem of unreasonable cost sharing in existing technologies, thereby improving user experience. During each power-on initialization or when entering sleep maintenance mode, the device can automatically switch to the seed number to establish a connection with the device management platform, seamlessly completing the task and switching back to the user number. The entire process requires no user intervention, achieving transparency and automation of background maintenance. Furthermore, in emergency scenarios such as low battery, unauthorized disassembly, or SIM card removal, the device can forcibly activate the seed number channel to upload critical data or perform remote locking and sensitive data erasure, effectively ensuring data security and privacy protection.

[0083] This application also provides a smart card suitable for number management in IoT devices. The smart card includes a multi-profile storage module for storing at least two independent communication profiles, specifically a seed number and a user number. The seed number is pre-installed in the secure area of ​​the eSIM chip during production and uniquely bound to the device hardware identifier for device management communications. The user number is dynamically downloaded via remote configuration (such as the SM-DP+ protocol) and is used to carry user-initiated service traffic. The multi-profile storage module supports rapid switching between different network configurations, ensuring that the device can select the appropriate number for communication based on its operating status, achieving traffic separation and secure control, and improving device management efficiency and data security.

[0084] This application also provides an Internet of Things (IoT) device, including a processor, an eSIM chip, and a memory; the memory stores a computer program; the eSIM chip stores a preset seed number and a dynamically configured user number; the processor executes the computer program to implement the above-described smart card number management method.

[0085] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0086] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). The memory stores computer programs, which the processor executes upon receiving execution instructions. The computer program used in the Internet of Things (IoT) device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, external hard drives, Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disks, or optical disks.

[0087] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0088] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0089] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for managing smart card numbers, characterized in that, The method, applied to an eSIM chip with multiple built-in profiles, wherein the eSIM chip has a pre-set seed number uniquely bound to an IoT device, includes: In response to the power-on command of the IoT device, the seed number in the eSIM chip is activated, a communication connection is established with the device management platform based on the seed number, and the device waits for a notification sent by the device management platform. If a device management notification is received from the device management platform, the corresponding first device management task is executed based on the seed number. After the first device management task is completed, the seed number is switched to the user number to complete the device power-on. If a normal power-on notification is received from the device management platform, the seed number is switched to the user number to complete the device power-on.

2. The smart card number management method according to claim 1, characterized in that, The method further includes: If the IoT device enters maintenance mode, the eSIM chip responds to the device maintenance notification sent by the IoT device, switches the user number to the seed number, establishes a communication connection with the device management platform based on the seed number, and executes the second device management service. The maintenance status refers to the IoT device not detecting any user operation or function call events within a preset time period.

3. The smart card number management method according to claim 2, characterized in that, The second device management service is an incremental data compression and upload service; The step of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically includes: The eSIM chip compresses the service data calculated by the IoT device using a differential algorithm and then uploads it to the device management platform.

4. The smart card number management method according to claim 2, characterized in that, The second device management service is an encrypted command service; The step of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically includes: The eSIM chip decrypts the encrypted command packet sent by the device management platform and forwarded by the IoT device using a pre-negotiated session key to obtain command data, and completes the download or update of services based on the command data.

5. The smart card number management method according to claim 2, characterized in that, The second device management service is the abnormal status alarm service; The step of establishing a communication connection with the device management platform based on the seed number and executing the second device management service specifically includes: The eSIM chip receives an abnormal status alarm notification sent by the IoT device and performs emergency backup of critical data based on the seed number.

6. The smart card number management method according to claim 1, characterized in that, The method further includes: if the IoT device enters a preset emergency state, the eSIM chip responds to the emergency notification sent by the IoT device, switches the user number to the seed number, establishes a communication connection with the device management platform based on the seed number, and sends an emergency command to the device management platform to perform data erasure or device locking operations. The emergency situations include one or more of the following: violent disassembly incidents, unauthorized SIM card removal incidents, and risks of leakage of sensitive user data.

7. The smart card number management method according to claim 1, characterized in that, The method further includes: when the IoT device is powered on for the first time, executing a two-way identity authentication process between the IoT device and the device management platform; The two-way authentication process includes: The IoT device initiates a secure communication request to the device management platform so that the device management platform can send platform identity credentials. The IoT device verifies the platform's identity credentials based on a pre-set root of trust. After the device management platform verifies the identity, the IoT device sends its device identity credentials to the device management platform. Once the device management platform verifies the device identity credentials based on a pre-set trust mechanism, the two-way identity authentication is successful. The IoT device establishes an encrypted communication channel with the device management platform and performs data communication based on the encrypted communication channel.

8. A smart card, characterized in that, It includes a multi-profile storage module for storing at least two communication numbers; the communication numbers include the seed number and user number as described in any one of claims 1-7.

9. An Internet of Things (IoT) device, characterized in that, The device includes a processor, an eSIM chip, and a memory; the memory stores a computer program; the eSIM chip stores a preset seed number and a dynamically configured user number; the processor executes the computer program to implement the smart card number management method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed on a processor, implements the smart card number management method according to any one of claims 1-7.

Images