Method and system for migrating eSIM number

Abstract

This application provides a method and system for migrating eSIM numbers, comprising: a service management portal sending a migration request for a target eSIM number to an operator's backend system; the operator's backend system identifying whether the target eSIM number corresponding to the target number identifier is in a migrateable state; when the operator's backend system identifies that it is in a migrateable state, it performs a service locking operation on the original configuration file corresponding to the target number identifier, generates a temporary configuration file, and sends it to the service management portal; the service management portal writes the received temporary configuration file into a blank SIM card to migrate the communication services of the target eSIM number to the blank SIM card. In this method, the virtual eSIM communication rights bound to the original terminal can be transferred to a pluggable physical carrier, thereby improving the convenience and flexibility of eSIM services, and further enhancing the continuity of eSIM services and user experience.

Description

Technical Field

[0001] This application relates to the field of eSIM technology, and in particular to a method and system for migrating eSIM numbers. Background Technology

[0002] With the evolution of mobile communication technology, embedded SIM (eSIM) has been widely used in mobile terminals and IoT terminals due to its high integration and remote configuration advantages. However, in special scenarios such as hardware failure of terminal equipment, return for repair, or temporary network troubleshooting of IoT devices, users often have an urgent need to quickly migrate the target eSIM number bound to the original device to other carriers to maintain the continuity of communication services.

[0003] Unlike traditional physical SIM cards, which can be migrated simply by hot-swapping, eSIM profiles are typically strictly bound to specific terminal hardware. Current technology usually only allows migration by reapplying for a new profile on a backup device or by canceling the number and re-issuing the eSIM. This method is not only limited by operator restrictions on the number of profile downloads, but also cumbersome and irreversible, lacking a security mechanism to temporarily materialize virtual eSIM benefits onto a physical card. Furthermore, simple remote reconfiguration struggles to verify the original terminal's online status in real-time and enforce service lock during migration, easily leading to authentication conflicts and number theft risks when the original device is repaired or misoperated. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method and system for migrating eSIM numbers, which can transfer the virtual eSIM communication rights bound to the original terminal to a pluggable physical carrier, thereby improving the convenience and flexibility of eSIM services, and further improving the continuity of eSIM services and user experience.

[0005] In a first aspect, the present invention provides a method for migrating eSIM numbers, applied to an eSIM number migration system, the eSIM number migration system including a service management portal, an operator backend system and a blank SIM card respectively connected to the service management portal; the method includes: The business management portal will send a migration request for the target eSIM number to the operator's backend system; the migration request includes the target number identifier corresponding to the target eSIM number and the SIM card identifier corresponding to the blank SIM card.

[0006] The operator's backend system identifies whether the target eSIM number is in a transferable state based on the received target number identifier.

[0007] When the operator's backend system identifies that the target eSIM number is in a transferable state, it performs a service lock operation on the original configuration file corresponding to the target number identifier, generates a temporary configuration file that matches the target number identifier and the SIM card identifier, and sends the temporary configuration file to the service management portal.

[0008] The service management portal writes the received temporary configuration file to a blank SIM card to migrate the communication services of the target eSIM number to the blank SIM card.

[0009] In an optional implementation, the step of the operator's backend system identifying whether the target eSIM number is in a transferable state based on the received target number identifier includes: The operator's backend system queries the service subscription information corresponding to the target number identifier, identifies whether the target number identifier has eSIM service permissions, and obtains the operating status of the original eSIM terminal corresponding to the target number identifier.

[0010] If the operator's backend system identifies that the target number identifier has eSIM service permissions and the original eSIM terminal is offline, it determines that the target eSIM number corresponding to the target number identifier is in a transferable state.

[0011] In an optional implementation, the step of the operator's backend system performing a service locking operation on the original configuration file corresponding to the target number identifier includes: The operator's backend system sends a service suspension command to the mobile communication core network, so that the mobile communication core network marks the IMSI status corresponding to the target number identifier as a service suspension status.

[0012] And / or, the operator's back-end system sends a maintenance mode command to the original eSIM terminal corresponding to the target number identifier through a preset push channel; when the original eSIM terminal is online via Wi-Fi, the original eSIM terminal responds to the maintenance mode command and controls the internal eSIM chip to enter a restricted state.

[0013] In an optional implementation, the step of the operator's backend system generating a temporary configuration file that matches the target number identifier and the SIM card identifier, and sending the temporary configuration file to the service management portal, includes: The operator's back-end system generates an initial temporary configuration file containing a preset validity period based on the business data corresponding to the target number identifier.

[0014] The operator's backend system encrypts the initial temporary configuration file based on the preset key information corresponding to the SIM card identifier, thus obtaining the temporary configuration file.

[0015] The operator's back-end system sends the temporary configuration file to the business management portal through a preset encrypted channel.

[0016] In an optional implementation, the eSIM number migration system also includes an intermediary device through which the service management portal is connected to a blank SIM card.

[0017] The steps by which the business management portal writes the received temporary configuration file to a blank SIM card include: The business management portal generates a write command based on the temporary configuration file and sends the write command to the intermediary device, so that the intermediary device writes the temporary configuration file to the blank SIM card through the preset SIM card channel.

[0018] The business management portal receives the write success confirmation information returned by the intermediary device and generates activation confirmation information based on the write success confirmation information.

[0019] The business management portal will send activation confirmation information to the operator's back-end system, so that the operator's back-end system will disable the original configuration file and perform activation operation on the temporary configuration file that has been written to the blank SIM card.

[0020] In an optional implementation, the eSIM number migration system further includes an intermediary device; when the original eSIM terminal corresponding to the target number identifier is a mobile terminal, the service management portal is an operator application running on the terminal device; the terminal device is connected to the intermediary device; the operator application is connected to a blank SIM card through the intermediary device.

[0021] Before the business management portal sends the migration request for the target eSIM number to the operator's back-end system, the method also includes: The operator application receives the first login request sent by the user and verifies the first login request based on the first preset verification rule to obtain the first verification result.

[0022] If the first verification result is successful, the operator application logs into the operator account corresponding to the first login request and displays the service function menu to the user.

[0023] The operator application responds to the user's triggered action for the temporary number migration function in the service function menu by establishing a communication connection with the intermediary device.

[0024] In an optional implementation, the first login request includes a target number identifier; the step of the service management portal sending a migration request for the target eSIM number to the operator's backend system includes: The operator application sends a read command to the intermediary device to receive the SIM card identifier returned by the intermediary device; the SIM card identifier is read by the intermediary device from a blank SIM card in response to the read command.

[0025] The operator application obtains the current branch information and generates a migration request based on the SIM card identifier, target number identifier, and current branch information.

[0026] The carrier application sends the migration request to the carrier's backend system through a pre-set encrypted channel.

[0027] In an optional implementation, before the operator's backend system performs a service locking operation on the original configuration file corresponding to the target number identifier when it identifies that the target eSIM number is in a transferable state, the method further includes: The operator's backend system determines whether the SIM card identifier belongs to the preset certified device list and whether the current outlet information belongs to the preset legitimate after-sales outlet list.

[0028] If the operator's backend system determines that the SIM card identifier belongs to the preset certified device list and the current outlet information belongs to the preset legitimate after-sales outlet list, a service lock operation will be triggered.

[0029] In an optional implementation, the eSIM number migration system further includes an intermediary device; when the original eSIM terminal corresponding to the target number identifier is an IoT terminal, the service management portal is a management platform that communicates with the terminal device; the terminal device is connected to the intermediary device; and the management platform is connected to a blank SIM card through the intermediary device.

[0030] Before the business management portal sends the migration request for the target eSIM number to the operator's back-end system, the method also includes: The management platform receives a second login request from the user and verifies the second login request based on the second preset verification rules to obtain a second verification result.

[0031] If the second verification result is successful, the management platform logs into the enterprise account corresponding to the second login request and displays the device management interface to the user.

[0032] The management platform responds to the user's selection of a target IoT device in the device management interface and the triggering of the temporary number migration function by generating a secondary authentication request and sending the secondary authentication request to the preset verification platform; wherein, the target IoT device corresponds to the target number identifier.

[0033] When the management platform receives the third verification result returned by the preset verification platform, and the third verification result is a successful verification, it establishes a communication connection with the intermediary device.

[0034] In an optional implementation, the step of the service management portal sending a migration request for the target eSIM number to the operator's back-end system includes: The management platform sends a read command to the intermediary device to receive the SIM card identifier returned by the intermediary device; the SIM card identifier is read by the intermediary device from the blank SIM card in response to the read command.

[0035] The management platform obtains the target number identifier corresponding to the target IoT device, and generates a migration request based on the SIM card identifier, the target number identifier, and the device identifier corresponding to the target IoT device.

[0036] The management platform sends the migration request to the operator's back-end system through a pre-set encrypted channel.

[0037] In an optional implementation, before the operator's backend system performs a service locking operation on the original configuration file corresponding to the target number identifier when it identifies that the target eSIM number is in a transferable state, the method further includes: The operator's backend system determines whether the enterprise account has the operation permission for the target IoT device, whether the device status of the target IoT device meets the preset migration conditions, and whether the migration request conforms to the preset enterprise policy; the preset migration conditions are offline status or maintainable status; the preset enterprise policy includes at least one of the device usage scope policy and migration duration policy.

[0038] If the operator's backend system determines that the enterprise account has the necessary operating permissions, the device status meets the preset migration conditions, and the migration request complies with the preset enterprise policy, a service lockout operation will be triggered.

[0039] Secondly, the present invention provides an eSIM number migration system, including a service management portal, an operator back-end system and a blank SIM card respectively connected to the service management portal.

[0040] The business management portal is used to send migration requests for a target eSIM number to the operator's backend system; the migration request includes the target number identifier corresponding to the target eSIM number and the SIM card identifier corresponding to the blank SIM card.

[0041] The operator's backend system is used to identify whether a target eSIM number is in a transferable state based on the received target number identifier.

[0042] The operator's backend system is used to perform a service lock operation on the original configuration file corresponding to the target number identifier when it is identified that the target eSIM number is in a transferable state, generate a temporary configuration file that matches the target number identifier and SIM card identifier, and send the temporary configuration file to the service management portal.

[0043] The service management portal is used to write the received temporary configuration file to a blank SIM card, so as to migrate the communication services of the target eSIM number to the blank SIM card.

[0044] This application provides an eSIM number migration method and system. Through collaborative interaction between the service management portal and the operator's backend system, after recognizing that the eSIM number is in a migrateable state and forcibly performing a service lock operation on the original configuration file, a temporary configuration file that strictly matches the blank SIM card identifier is generated and written to the physical carrier. This securely and temporarily transfers the virtual eSIM communication rights that were originally strongly bound to specific terminal hardware to a pluggable physical SIM card. This application not only effectively solves the communication interruption problem caused by the inability to physically transfer numbers in eSIM terminal scenarios such as hardware failure, maintenance, or emergency testing, achieving seamless continuity of user communication services, but also ensures the uniqueness of the same subscription on the network side through the backend-side active locking and targeted matching mechanism, reducing the risk of authentication conflicts or number theft caused by the unexpected online of the original device, thus balancing the flexibility and high security of eSIM service management.

[0045] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0046] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0048] Figure 1 A flowchart illustrating the eSIM number migration method provided in this application embodiment; Figure 2 A flowchart of a transferable state identification method provided in an embodiment of this application; Figure 3 A flowchart illustrating a temporary configuration file processing method provided in this application embodiment; Figure 4 Flowchart of the temporary configuration file writing method provided in this application embodiment; Figure 5 This is a schematic diagram of an eSIM number migration system provided in an embodiment of this application; Figure 6 This is a schematic diagram of another eSIM number migration system provided in an embodiment of this application.

[0049] Icons: 1-Business Management Portal; 2-Operator Backend System; 3-Blank SIM Card; 4-Intermediary Equipment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] To help those skilled in the art better understand this application, a brief introduction to its application scenarios and design concepts is provided.

[0052] Specifically, with the development of embedded SIM (eSIM / eUICC) and GSMA remote SIM configuration architectures (such as SM... DP+, SM With the widespread application of SIM cards (such as DS and LPA), the form factor of terminals is rapidly shifting from traditional removable SIM cards to eSIM cards. Although eSIM terminals have significant advantages in device integration, waterproof and dustproof design, security, and user digital experience, they face more complex technical challenges than traditional physical SIM cards in scenarios that require short-term or temporary number migration, such as returning the terminal to the factory for repair, temporary device borrowing, cross-regional travel for device replacement, or temporary use of testing equipment.

[0053] In traditional environments, users can complete number migration simply by removing the physical SIM card and inserting it into a backup device—a straightforward, instantaneous, and fully reversible process. However, eSIM profiles are strongly bound to terminal hardware and cannot be directly transferred physically. Current technologies typically require either re-applying for and downloading a new eSIM profile on the backup device or setting up network-side call forwarding to address such needs. These methods have significant limitations. Firstly, due to subscription uniqueness principles and operator risk control policies, frequent remote downloads are often restricted and cumbersome. Secondly, simple call forwarding cannot resolve the continuity issues of data services, application binding, and identity authentication, and it's difficult to ensure the original device's security during migration, potentially leading to authentication conflicts or key leaks when both SIM cards are online.

[0054] Based on this, this application provides a method and system for migrating eSIM numbers. A request is initiated through the service management portal, and the operator's backend system strictly locks the original eSIM terminal's service. While ensuring the original device cannot access the network, a temporary configuration file matching the blank SIM card identifier is generated and written to the physical card. This application not only temporarily materializes the non-removable eSIM rights, allowing users to seamlessly continue communication services on a backup terminal using a blank SIM card during device repair, solving the problem of eSIM's lack of physical flexibility and achieving zero service interruption, but also reduces the risk of authentication conflicts or number theft caused by the original device being repaired or mistakenly put online through a backend system. This enhances the security of personal user devices and IoT devices while ensuring subscription uniqueness and network security.

[0055] This application provides a method for migrating eSIM numbers, applied to an eSIM number migration system. The eSIM number migration system includes a service management portal, an operator backend system and a blank SIM card that are respectively connected to the service management portal.

[0056] Here, the business management portal refers to the client used to initiate migration services, interact with users, and connect to the backend system. In practical applications, the business management portal can take various forms depending on the user. For individual users, it can be a carrier app, mini-program, or self-service terminal software running on mobile terminals such as smartphones and tablets. For enterprises or IoT users, it can be an IoT device management platform (web portal) or enterprise-level management software running on PCs, industrial handheld PDAs, or servers.

[0057] The operator's back-end system refers to the set of servers deployed on the operator's network side, responsible for handling eSIM data generation, user authentication, business logic judgment, and network signaling control. It typically includes, but is not limited to, SM-DP+ (Subscription Management Data Preparation System), Home Subscriber Server (HSS / HLR), service support system, and related encryption / decryption servers.

[0058] A blank SIM card is a physical card that has a basic file structure pre-installed but has not yet written with specific communication service data (profile). Blank SIM cards can be standard-sized pluggable SIM cards (such as Nano SIM and Micro SIM), have the ability to be repeatedly read and written or written once, and each blank SIM card has a unique chip serial number (ICCID) or other hardware identifier, used as a temporary carrier during migration.

[0059] Reference Figure 1 The eSIM number migration method provided in this application includes: In step S101, the service management portal sends a migration request for the target eSIM number to the operator's backend system; the migration request includes the target number identifier corresponding to the target eSIM number and the SIM card identifier corresponding to the blank SIM card.

[0060] In this scenario for individual users, the user logs into the operator's app installed on a spare phone and selects either "eSIM Failure Migration" or "Temporary Number Retrieval" from the function menu. The target number identifier can be the MSISDN (Mobile Station International Subscriber Directory Number) linked to the user's login account, or it can be a number manually entered by the user for the device being repaired. For the identifier of a blank SIM card (SIM card identifier), the user can obtain it by scanning the barcode or QR code on the back of the blank SIM card using the app's camera, automatically reading it through a card reader connected to the terminal, or manually entering the numbers on the card.

[0061] In IoT scenarios, enterprise administrators log into their enterprise accounts through a web-based business management portal and select one or more IoT devices that have malfunctioned or require testing on the device list page. The business management portal automatically extracts the device ID (such as IMEI (International Mobile Subscriber Identity) or EID) of the selected devices and converts it into the corresponding target number identifier (such as IMSI or MSISDN). The administrator then maps and binds a batch of scanned or entered blank SIM card identifiers to the target devices one-to-one, generating a batch migration request containing multiple sets of data.

[0062] To ensure secure transmission, the business management portal encrypts the request data using a pre-installed public key certificate before sending the migration request, and then transmits it to the operator's backend system via a secure transmission channel such as HTTPS (Hypertext Transfer Protocol Secure). In addition, the migration request can also include a timestamp, the geographical location information of the request initiation location (base station cell ID or GPS coordinates), and the operator's digital signature for backend risk control auditing.

[0063] In step S102, the operator's backend system identifies whether the target eSIM number is in a transferable state based on the received target number identifier.

[0064] Here, after receiving the request, the operator's backend system will perform verification from multiple dimensions. First, there is a business-level verification, which checks whether the account corresponding to the target number is in arrears, suspended but retained, or canceled, confirms whether it has eSIM service permissions and whether it has signed a temporary migration agreement.

[0065] Secondly, there is verification at the device status level. The operator's backend system will query the online status of the original eSIM terminal through the core network.

[0066] In a preferred embodiment, the system determines that the device is transferable only when the original eSIM terminal is offline (i.e., unable to connect to the base station). This typically corresponds to scenarios where the device hardware is damaged or the battery is depleted. In another embodiment, if the original terminal is still online (e.g., only the screen is damaged but communication is normal), the operator's backend system may return a "requires unbinding" or "requires secondary confirmation" prompt to prevent malicious number grabbing.

[0067] For IoT scenarios, the identification process also includes policy verification. The operator's backend system checks whether the enterprise account that initiated the request has the permission to operate on the specific device, and whether the migration behavior of the device complies with the preset policy (for example, some high-security cameras may be prohibited from migration, or restricted to being migrated only to blank SIM cards in specific number ranges).

[0068] In step S103, when the operator's backend system recognizes that the target eSIM number is in a transferable state, it performs a service lock operation on the original configuration file corresponding to the target number identifier, generates a temporary configuration file that matches the target number identifier and the SIM card identifier, and sends the temporary configuration file to the service management portal.

[0069] Here, due to the special nature of eSIM, the original device may regain functionality at some point in the future (e.g., after repair and power-on). To prevent authentication conflicts caused by the original device and the migrated blank SIM card accessing the network simultaneously, the operator's backend system must lock it on the network side or the terminal side.

[0070] Specifically, the operator's backend system sends an instruction to the mobile communication core network to mark the original IMSI status as "service suspended" or "lost," so that the original eSIM chip cannot register with the network even if it is powered on; or, the operator's backend system sends a special OTA instruction (such as a maintenance mode instruction) to the original device. If the original device can still receive instructions, its local profile will be forcibly disabled.

[0071] The operator's backend system generates a new Profile data packet based on the target number's subscription data (including IMSI, authentication key Ki, OPC, etc.). To accommodate temporary migration, this Profile can be set to have an expiration period (e.g., 7 days, 30 days), automatically expiring after that. The generation process uses the key corresponding to the SIM card identifier carried in the request for encryption, ensuring that this generated temporary configuration file can only be written to the specified blank SIM card and cannot be intercepted and written to other cards.

[0072] In step S104, the service management portal writes the received temporary configuration file to the blank SIM card to migrate the communication services of the target eSIM number to the blank SIM card.

[0073] Here, after receiving the encrypted temporary configuration file, the business management portal interacts with the blank SIM card through a physical interface.

[0074] The interaction method depends on the hardware environment. If the business management portal is running on an Android handheld terminal with a SIM card slot, it can directly call the underlying Modem (baseband modem) through the system API (interface) to write APDU (Application Protocol Data Unit) instructions to the blank SIM card in the card slot.

[0075] If the business management portal runs on a PC or a regular mobile phone, it can connect to an external card reader (intermediary device) via Bluetooth, USB (Universal Serial Bus), or NFC (Near Field Communication) to pass data through and write it to a blank SIM card inserted in the card reader.

[0076] The writing process follows the standard SIM card application download or profile installation procedure. After writing is complete, the blank SIM card will have the same communication capabilities as the original eSIM (same number, plan, and IP whitelist permissions).

[0077] In a preferred embodiment, after the writing operation is completed, the service management portal generates an activation confirmation message and returns it to the operator's backend system. Only after receiving the confirmation message will the operator's backend system officially activate the communication service of the new card on the mobile communication core network side and remove certain network layer restrictions on the number (such as redirecting the route to the new SIM card), thus completing the smooth migration of the entire service. At this point, the user can insert the written physical SIM card into any universal spare mobile phone or device to restore communication services.

[0078] In an optional implementation, refer to Figure 2 Step S102 includes the following steps S201-S202.

[0079] In step S201, the operator's backend system queries the service subscription information corresponding to the target number identifier, identifies whether the target number identifier has eSIM service permissions, and obtains the operating status of the original eSIM terminal corresponding to the target number identifier.

[0080] Here, when the operator's backend system receives a migration request, it first accesses the business support system based on the target number identifier (such as the mobile number's MSISDN). The operator's backend system retrieves the user's subscription records to verify whether the user is currently in a normal online status, ruling out anomalies such as overdue payments, suspension of service for number retention, or cancellation. Based on this, the operator's backend system further verifies whether the number has activated eSIM service and whether it has subscribed to or been authorized to use the "temporary number migration" value-added service. For enterprise customers, it also verifies whether the enterprise account's annual service agreement includes this benefit.

[0081] Meanwhile, to determine the necessity and security of the migration, the operator's backend system needs to obtain the terminal's real-time status. The operator's backend system will send a status query command to the Home Subscriber Server (HSS) or Home Location Register (HLR) in the mobile communication core network. The mobile communication core network, based on the International Mobile Subscriber Identity (IMSI) associated with the target number, retrieves the user's registration information on the network side, including but not limited to the current attachment status, last active time, last registered location area information, and paging response status.

[0082] Step S202: If the operator's backend system recognizes that the target number identifier has eSIM service permissions and the original eSIM terminal is offline, it determines that the target eSIM number corresponding to the target number identifier is in a transferable state.

[0083] Here, the operator's backend system will only determine that the number is currently in a transferable state when the service subscription information shows that the user has the operation permission and the original eSIM terminal status reported by the mobile communication core network is offline (for example, the mobile communication core network shows that the user has not updated the location information for a long time, or does not respond to the paging command, or is clearly marked as Detached).

[0084] In real-world applications, users typically request to migrate their profile to a physical card due to hardware failures in the original device (such as motherboard damage or inability to power on) or battery depletion. These situations manifest as the device being offline on the network side. By confirming the device is offline, it can be inferred that the user's migration request is based on a genuine device failure and not malicious copying or theft.

[0085] By adding dual verification of business permissions and terminal online status before generating temporary configuration files, the source of migration risks can be effectively controlled. Verifying business permissions ensures that only legitimate subscribers can use the service, preventing unauthorized operations. Verifying the original terminal's offline status uses objective data from the network side to corroborate claims of user equipment failure or inaccessibility, minimizing the risk of authentication conflicts arising from forced migration when the original device is still in normal use, thus ensuring the secure flow of communication services.

[0086] In optional implementations, to prevent the risk of dual-SIM conflict when the original device and the new SIM card simultaneously access the network during or after the migration process, service locking can be performed via network-side locking, terminal-side locking, or a combination of both, depending on the actual application scenario. Step S103, where the operator's backend system performs a service locking operation on the original configuration file corresponding to the target number identifier, includes: Method 1: Network-side locking.

[0087] The operator's backend system sends a service suspension command to the mobile communication core network, so that the mobile communication core network marks the IMSI status corresponding to the target number identifier as a service suspension status.

[0088] Here, the operator's backend system sends a service suspension instruction to the mobile communication core network, so that the mobile communication core network marks the International Mobile Subscriber Identity (IMSI) status corresponding to the target number identifier as suspended.

[0089] Specifically, when the operator's backend system determines that migration is necessary, it sends a status change request to the Home Subscriber Server (HSS) or Home Location Register (HLR) in the core network through a standard interface (such as the Sh interface or SOAP interface). The status change request instructs the core network to suspend the authentication or location update functions of the IMSI. Once the core network marks the IMSI as "suspended" or "lost," even if the original eSIM terminal subsequently restores its hardware functions and attempts to initiate a network registration request, the mobile communication core network will directly reject the access request, cutting off the original device's communication capabilities at the source of the operator's network. This is a fundamental means of ensuring subscription uniqueness.

[0090] Method 2: Terminal-side locking.

[0091] The operator's backend system sends a maintenance mode command to the original eSIM terminal corresponding to the target number identifier through a preset push channel; when the original eSIM terminal is online via Wi-Fi, it responds to the maintenance mode command and controls the internal eSIM chip to enter a restricted state.

[0092] In this real-world scenario, the original eSIM terminal might simply be experiencing a cellular communication module malfunction, or the user might be connected to the network at home via Wi-Fi. To prevent the device from accidentally attempting to connect to the cellular network during the repair process, the operator's backend system will issue a "repair mode" or "service suspension" command using a pre-defined internet push channel (such as system-level push services like APNs (Access Point Names) or FCM (Firebase Cloud Push), or a long-connection channel established by the operator's app).

[0093] When the original eSIM terminal receives this instruction via Wi-Fi, the terminal's operating system layer or Local Configuration Assistant (LPA) parses the instruction and performs local management operations on the eSIM chip (eUICC). Controlling the eSIM chip to enter a restricted state can specifically include: calling the disable interface to set the target profile to disabled, or disabling the SIM card's communication stack at the operating system level, or locking the cellular network switch on the device screen and displaying a message "Number has been migrated to a temporary card." This method allows the terminal to proactively stop attempting to initiate cellular network connections, reducing unnecessary signaling interactions.

[0094] Method 3: Coordinated locking between the network side and the terminal side.

[0095] In a preferred embodiment, the operator's backend system can simultaneously execute both Method 1 and Method 2 locking mechanisms. On one hand, it marks the IMSI as paused on the core network side to ensure absolute network security; on the other hand, it attempts to send instructions to the terminal via the internet channel. If the terminal is currently online (in a Wi-Fi environment), local locking is immediately executed. If the terminal is completely offline (e.g., powered off), security is ensured solely by network-side locking. This collaborative mechanism minimizes authentication conflicts caused by accidental operation (e.g., accidental power-on) of the original device during maintenance, ensuring that the eSIM number is unique and exclusive on the physical card.

[0096] In an optional implementation, refer to Figure 3 In step S103, the operator's backend system generates a temporary configuration file that matches the target number identifier and the SIM card identifier, and sends the temporary configuration file to the business management portal, including the following steps S301-S303.

[0097] In step S301, the operator's back-end system generates an initial temporary configuration file containing a preset validity period based on the business data corresponding to the target number identifier.

[0098] Here, when it is determined that a target eSIM number needs to be migrated, the operator's back-end system first extracts the core business data corresponding to the target number identifier from the Business Support System (BSS). This business data includes, but is not limited to: International Mobile Subscriber Identity (IMSI), Authentication Key (Ki / K), Operator Configuration Parameters (OPc), Access Point Name (APN) configuration, and Service Level Agreement (QoS) parameters.

[0099] The initial temporary configuration file encapsulates a preset expiration policy. The expiration policy can be based on time limits (e.g., set to 7 days, 15 days, or 30 days to match typical device maintenance cycles) or on event limits (e.g., limiting cumulative data usage or call duration).

[0100] In one specific implementation, the operator's backend system embeds a monitoring applet (Java Card app) into the initial temporary configuration file. This app runs automatically after the SIM card is powered on. Once it detects that the current system time has exceeded a preset validity period, it will automatically disable the card's communication functions or delete the configuration file, thereby achieving self-destructive security management and preventing the temporary card from being used illegally for an extended period. Furthermore, the initial temporary configuration file can also be configured to include only basic communication functions (such as voice and basic data only), blocking international roaming or high-value-added services to further reduce risk.

[0101] In step S302, the operator's backend system encrypts the initial temporary configuration file based on the preset key information corresponding to the SIM card identifier to obtain the temporary configuration file.

[0102] Here, a blank SIM card has a specific transmission key or security domain key written into it at the factory. This key information corresponds one-to-one with its unique SIM card identifier (such as ICCID or chip serial number) and is pre-stored in the operator's key management center. The operator's back-end system retrieves the preset key information corresponding to that specific blank SIM card based on the received SIM card identifier.

[0103] Subsequently, the operator's backend system uses this preset key information to encrypt and encapsulate the initial temporary configuration file. This encryption typically employs a symmetric encryption algorithm (such as AES (Advanced Encryption Standard)) to transform generic profile data into ciphertext data packets locked by a specific key. After this processing, the resulting temporary configuration file forms a strict hardware binding relationship with the blank SIM card. This means that even if the temporary configuration file is intercepted by a hacker during transmission, or mistakenly transmitted to another SIM card or device, the data cannot be parsed or installed due to the lack of the corresponding decryption key, thus effectively preventing the profile from being cloned or stolen.

[0104] In step S303, the operator's back-end system sends the temporary configuration file to the business management portal through a preset encrypted channel.

[0105] To ensure data security during public network transmission, a pre-defined encrypted channel is established between the operator's backend system and the business management portal. This encrypted channel is typically based on a high-strength transport layer security protocol (such as TLS 1.2 / 1.3 or HTTPS) or uses a dedicated VPN tunnel. The operator's backend system sends the generated encrypted temporary configuration file to the requesting business management portal through this channel. During transmission, data packets can also be accompanied by a digital signature, allowing the business management portal or subsequent intermediary devices to verify the integrity and authenticity of the data, ensuring that the data ultimately written to the blank SIM card is indeed legally issued by the operator and has not been tampered with.

[0106] In an optional implementation, the eSIM number migration system also includes an intermediary device through which the service management portal is connected to a blank SIM card.

[0107] Here, the device running the business management portal (such as a desktop computer, an industrial tablet without a SIM card slot, or a regular mobile phone used by maintenance personnel) may not have the hardware capability to directly read and write blank SIM cards. In this case, the eSIM number migration system also includes an intermediary device, through which the business management portal connects to the blank SIM card to establish a data transmission channel.

[0108] Intermediate devices refer to external hardware devices with smart card reading and writing capabilities, such as Bluetooth SIM card readers, USB contact smart card readers, or NFC contactless card readers. Before the migration operation begins, the user or maintenance personnel physically insert a blank SIM card into the card slot of the intermediate device and establish a connection between the intermediate device and the terminal running the business management portal via wired (e.g., USB data cable) or wireless (e.g., Bluetooth, Wi-Fi, NFC) means.

[0109] Reference Figure 4 Step S104 includes the following steps S401-S403.

[0110] In step S401, the business management portal generates a write instruction based on the temporary configuration file and sends the write instruction to the intermediary device, so that the intermediary device writes the temporary configuration file to the blank SIM card through the preset SIM card channel.

[0111] Here, when the business management portal receives the encrypted temporary configuration file (Profile data packet) from the operator's backend system, it does not decrypt it locally. Instead, it encapsulates it into an application protocol data unit instruction set conforming to the smart card transmission specification. The business management portal then sends these write instructions containing Profile data to the intermediary device via its communication link (e.g., a Bluetooth pass-through channel). The intermediary device acts as a transparent transmission mechanism, writing the instruction stream sequentially into the security domain of the blank SIM card through a pre-defined card-to-device channel (i.e., the physical circuitry between the card reader and the SIM card contacts). During this process, the operating system inside the blank SIM card uses a pre-set key to decrypt and verify the integrity of the written data, ensuring that the data has not been tampered with.

[0112] In step S402, the business management portal receives the write success confirmation information returned by the intermediary device and generates activation confirmation information based on the write success confirmation information.

[0113] Here, during the writing process, the intermediary device provides real-time feedback on the execution result of the blank SIM card. Once the temporary configuration file is completely written to the blank SIM card and the card verification passes, the blank SIM card returns a success status word. The intermediary device parses this as a successful write confirmation and reports it to the service management portal. Upon receiving this confirmation, the service management portal confirms that the physical data migration is complete and then generates an activation confirmation message containing the blank SIM card identifier, migration task ID, and write completion status code. This ensures that subsequent service switching is only triggered when the physical card is truly ready, preventing network outages caused by a failed card write but the service already switched over.

[0114] In step S403, the service management portal sends activation confirmation information to the operator's backend system, so that the operator's backend system disables the original configuration file and performs activation operation on the temporary configuration file that has been written to the blank SIM card.

[0115] Here, the operator's backend system officially marks the original configuration file status in the original eSIM terminal as "invalid" or "replaced" in the database, and releases the previous temporary lock on the number on the core network side (such as releasing IMSI suspension). However, the routing mapping relationship has changed at this time. Next, the operator's backend system performs an activation operation on the temporary configuration file written to the blank SIM card. This includes updating the authentication parameters corresponding to the number in the Home Location Register / HSS to match the data in the blank SIM card, and granting network access permissions. After completion, the blank SIM card has network access capability, and users can insert it into a spare terminal to use communication services normally, realizing a complete service transition from virtual eSIM to physical SIM card.

[0116] In an optional implementation, the eSIM number migration system further includes an intermediary device; when the original eSIM terminal corresponding to the target number identifier is a mobile terminal, the service management portal is an operator application running on the terminal device; the terminal device is connected to the intermediary device; the operator application is connected to a blank SIM card through the intermediary device.

[0117] This section provides a detailed explanation of the login and connection steps before the migration process is initiated by the business management portal (i.e., the operator application) in a personal mobile terminal scenario. This embodiment mainly addresses the scenario where ordinary individual users perform self-service number migration using a backup mobile terminal (terminal device) in conjunction with an external card reader (intermediary device) when their original eSIM terminal (such as a mobile phone) malfunctions.

[0118] Before step S101, the method further includes the following steps S501-S503.

[0119] In step S501, the operator application receives the first login request sent by the user and verifies the first login request based on the first preset verification rule to obtain the first verification result.

[0120] Here, when a user needs to initiate a migration on a backup terminal, they first need to open the operator's app installed on that terminal device. To ensure the legitimacy of the operator, the app will require the user to log in, i.e., send an initial login request.

[0121] The first login request refers to the login operation for a personal operator account. Users can trigger this request in several ways, such as entering the original eSIM number (target number identifier) ​​and obtaining an SMS verification code; or logging in with an account and password; or, if the backup terminal also has a SIM card from the same operator installed, the "one-click login with local number" function can be used.

[0122] The first preset verification rule refers to the authentication logic that operators use for individual users. The app sends the credentials submitted by the user to the unified authentication center in the operator's backend system. The operator's backend system verifies the validity of the credentials (such as whether the verification code is correct and whether the account exists). To improve security, the first preset verification rule may also include biometric recognition (such as calling the face recognition or fingerprint recognition interface of the terminal device) or liveness detection to ensure that the operator is the account holder and prevent others from stealing the account for malicious migration.

[0123] In step S502, if the first verification result is successful, the operator application logs into the operator account corresponding to the first login request and displays the service function menu to the user.

[0124] Here, after the operator's backend system returns a successful verification result, the operator's application completes account login and enters the main interface of the app or a specific service processing interface. At this time, the app displays a service function menu containing various service options to the user. To help users quickly find the migration entry point, the service function menu will include prominent function entries (icons or buttons) such as "eSIM Temporary Migration," "Fault Assistance," "Repair Mode," or "Physical Card Writing."

[0125] In one embodiment, if the system detects that an eSIM device bound to the account has recently been offline (possibly damaged), the APP can also proactively pop up a window on the homepage to prompt the user whether they need to apply for a temporary migration service.

[0126] In step S503, the operator application responds to the user's triggered operation for the temporary number migration function in the service function menu and establishes a communication connection with the intermediary device.

[0127] Here, when the user clicks the above function entry (triggering the operation), the operator application begins to initialize the migration environment. Since mobile terminals such as smartphones usually do not have the ability to directly write SIM cards, an external intermediary device (i.e., a blank SIM card reader / writer) needs to be connected.

[0128] The process of establishing a communication connection depends on the interface type of the intermediary device: If the intermediary device is a Bluetooth card reader, the operator application will call the terminal device's Bluetooth module to scan for nearby Bluetooth Low Energy devices, match the preset device name (such as "eSIM_Writer"), and prompt the user to pair and connect.

[0129] If the intermediary device is a USB card reader (connected via an OTG adapter), the carrier application will listen for USB port insertion events and request access permissions to the USB device.

[0130] If the intermediary device supports NFC communication, the application will prompt the user to place the blank SIM card against the NFC sensing area on the back of the phone (at this time, the phone itself is a special form of both a terminal device and an intermediary device).

[0131] Once the connection is successfully established, the carrier application will usually display a message on the interface indicating "Card reader connected" or "Please insert a blank SIM card," thus preparing the hardware for subsequent reading of card information and writing to the profile.

[0132] In an optional implementation, the first login request includes a target number identifier. Here, the user logs in using the mobile phone number (or associated account) that needs to be migrated, and the system defaults to the current operation targeting the eSIM number corresponding to that login account.

[0133] Step S101 includes the following steps S601-S603.

[0134] In step S601, the operator application sends a read command to the intermediary device to receive the SIM card identifier returned by the intermediary device; wherein, the SIM card identifier is read by the intermediary device from the blank SIM card in response to the read command.

[0135] Here, after the carrier application establishes a connection with the intermediary device (such as a Bluetooth card reader), the carrier application will automatically trigger or prompt the user to click the "Read New Card" button to initiate the reading process. The carrier application sends standard smart card reading commands (such as the GET DATA or SELECT commands in APDU commands) to the intermediary device via Bluetooth or USB. After receiving the command, the intermediary device powers on and resets the blank SIM card inserted into the card slot, accesses the card's basic files, and reads the unique hardware identifier stored in the card. The SIM card identifier is usually the Integrated Circuit Card Identifier (ICCID) or the chip serial number. The intermediary device returns the read identifier data to the carrier application. During this process, the carrier application also performs format verification on the read data to ensure that the inserted card is a valid blank card that conforms to the carrier's specifications, and not a damaged card or a card from another carrier.

[0136] In step S602, the operator application obtains the current branch information and generates a migration request based on the SIM card identifier, the target number identifier, and the current branch information.

[0137] Here, the carrier application begins assembling the service request message to send to the backend. In addition to the obtained SIM card identifier and the target number identifier (such as MSISDN) determined during login, the application will also automatically obtain the current branch information.

[0138] For individual self-service scenarios, the current service point information can be the geographical coordinates obtained by the terminal device through GPS or base station positioning, or the authorized service point code obtained by the user by scanning the service point's exclusive QR code.

[0139] For offline repair shops authorized by operators, the work terminals used by repair personnel (with the enterprise version of the operator's application installed) are pre-loaded with the unique channel code of the outlet.

[0140] By incorporating current branch information, the operator's backend system can subsequently determine whether the migration operation occurred in a legitimate area or authorized physical location, thereby preventing unauthorized operations from other locations or remote attacks by malicious actors. The operator's application encapsulates the above data, along with anti-replay parameters such as request timestamps and random numbers, into a complete migration request data packet according to a predefined JSON or XML format.

[0141] In step S603, the operator application sends the migration request to the operator's backend system through a preset encrypted channel.

[0142] Here, to prevent sensitive data (especially target numbers and SIM card ICCIDs) from being eavesdropped on or tampered with during transmission over public networks, the carrier application does not send plaintext requests directly. The application layer invokes a secure transmission protocol to establish a connection with the carrier's backend system.

[0143] In one feasible implementation, the carrier application may also use a pre-installed public key certificate within the app to perform asymmetric encryption on the entire migration request data packet, or use a dynamically negotiated session key for symmetric encryption. The encrypted migration request is then sent to the API gateway of the carrier's backend system, awaiting further verification and processing by the carrier's backend system.

[0144] In an optional implementation, when the operator's backend system identifies that the target eSIM number is in a transferable state, before the step of performing a service locking operation on the original configuration file corresponding to the target number identifier in step S103, the method further includes the following steps S701-S702.

[0145] In step S701, the operator's backend system determines whether the SIM card identifier belongs to the preset certified device list and whether the current outlet information belongs to the preset legitimate after-sales outlet list.

[0146] Here, when the operator's backend system receives the encrypted migration request and completes the decryption, it first parses out the blank SIM card identifier (such as ICCID) and the current branch information (such as channel code or geographical coordinates) contained therein.

[0147] To verify the legitimacy of a blank SIM card, the operator's backend system accesses its internal number resource management database. The pre-set authentication device list refers to a set of dedicated blank card number ranges pre-assigned by the operator to authorized service outlets or for special emergency recovery services. The operator's backend system searches for the SIM card identifier in this list and further verifies whether the card's current status in the system is "idle" or "ready for pre-activation." This check effectively prevents sensitive eSIM migration operations from being performed using cards not issued by the operator, reported lost cards, cards already in use, or ordinary cards not designated for their intended purpose.

[0148] Meanwhile, to verify the compliance of the operating location, the operator's backend system accesses the channel management database. The pre-set list of authorized after-sales service outlets includes information on all physical stores officially authorized by the operator and possessing eSIM repair and migration qualifications (including store ID, authorized IP address range, registered geofence range, etc.). The operator's backend system matches and verifies the current outlet information in the request. For example, if the outlet information is GPS coordinates, the operator's backend system will determine whether the coordinates fall within the authorized outlet's geofence. If the outlet information is a channel ID, the operator's backend will verify the validity of the ID and whether the channel has eSIM migration service permissions.

[0149] Step S702: If the operator's backend system determines that the SIM card identifier belongs to the preset certified device list and the current outlet information belongs to the preset legitimate after-sales outlet list, a service lock operation is triggered.

[0150] Here, the security verification will only pass if the blank SIM card is a legitimate dedicated card and the operation is initiated at a legitimate authorized outlet.

[0151] Once the verification is successful, the operator's backend system considers the migration request to be trustworthy and compliant, and then enters the core business processing flow, which triggers the service lock operation of the original configuration file corresponding to the target number identifier (such as sending an IMSI pause command or maintenance mode command), and continues the subsequent temporary configuration file generation process.

[0152] If any of the above conditions are not met (for example, a SIM card that has not been registered in the database is used, or the IP address that initiated the request is displayed in an unauthorized area), the operator's backend system will immediately reject the migration request, return an error code (such as "illegal card" or "unauthorized area"), and record a security alarm log for subsequent auditing and tracing.

[0153] In a specific implementation where a user goes to an authorized offline repair center of an operator to repair a faulty eSIM device and temporarily migrate their number, the eSIM number migration system includes: the user's faulty mobile phone (i.e., the original eSIM terminal corresponding to the target number identifier), a handheld tablet computer used by the repair center staff (i.e., the terminal device, on which the "Operator After-Sales Assistant" APP, which serves as a business management portal, is installed), a portable Bluetooth card reader (i.e., the intermediary device), and a blank operator-specific SIM card that has not been written with any data.

[0154] Suppose user Zhang San's eSIM phone cannot be turned on due to a motherboard failure, and he goes to an authorized service center to request that communication be maintained during the repair process.

[0155] First, the repairman opened the "Carrier After-Sales Assistant" APP (carrier application) on a handheld tablet. The staff entered the faulty mobile phone number provided by Zhang San (target number identifier) ​​and requested Zhang San to provide identification. Zhang San provided his account password or a dynamic verification code received through a backup contact method, which constituted the "first login request".

[0156] After receiving the request, the app performs local or online verification based on the "first preset verification rule". This verification rule not only verifies the correctness of the password / verification code, but may also include facial recognition (using the tablet's camera to compare Zhang San's appearance with the ID photo stored in the background) to achieve financial-grade real-name authentication standards.

[0157] Once the "First Verification Result" shows successful verification, the app logs into Zhang San's carrier account and displays the service function menu. The repair technician clicks the "Repair Spare SIM Card Creation" or "Temporary Number Migration" icon in the menu (triggering an operation). At this point, the app scans and connects to the Bluetooth card reader that is already enabled on the desktop via the tablet's Bluetooth interface, establishing a communication connection and preparing for hardware interaction.

[0158] After the connection is established, the maintenance personnel insert a dedicated blank SIM card into the card slot of the Bluetooth card reader.

[0159] The app automatically or after manual confirmation sends APDU reading commands (such as SELECT and GET DATA) to the card reader. The card reader responds to the commands, reads the ICCID (i.e., SIM card identifier) ​​of the blank SIM card, and returns it to the app via Bluetooth.

[0160] Next, the app automatically obtains the current outlet information. In this embodiment, the app simultaneously reads the tablet's GPS location coordinates and calls the locally configured "channel store code". The app packages the obtained blank SIM card ICCID, Zhang San's target mobile phone number, and the current outlet information including GPS and store code.

[0161] Subsequently, the APP uses the pre-installed SSL / TLS certificate to establish an HTTPS encrypted channel with the operator's backend system and sends the packaged data as a "migration request" to the backend.

[0162] After receiving the request, the operator's backend system does not immediately execute the migration, but first performs strict environment and carrier verification.

[0163] The operator's backend system first extracts the ICCID and queries its internal "whitelist resource library" (a list of pre-defined certified devices). The operator's system then verifies whether the blank SIM card is a dedicated card segment allocated to this repair outlet for after-sales service. If the card is a regular card purchased from a roadside stall, or if its status shows "dead," the verification fails.

[0164] Meanwhile, the operator's backend system parses the outlet information. The operator's backend system compares whether the reported GPS coordinates are within the geofence area registered for the store code, and whether the store code belongs to a valid merchant in the "preset list of legal after-sales outlets".

[0165] Only when it is confirmed that "the card is a legitimate dedicated card" and "the operation location is a legitimate authorized outlet" will the operator's backend system determine that the environment is secure, thereby triggering subsequent core operations. This involves sending a command to the core network to suspend the IMSI service of the original faulty phone (service lock operation) and beginning to generate an encrypted temporary configuration file for the blank SIM card.

[0166] As can be seen from the above embodiments, this application can be adapted to offline repair scenarios. Through the cooperation of the APP, card reader and backend, the eSIM service can be temporarily transferred to the physical card in a safe and compliant manner without the original mobile phone being turned on. This not only makes it convenient for users, but also prevents illegal operations by service outlets or remote attacks by black market operators through a dual whitelist mechanism.

[0167] In an optional implementation, the eSIM number migration system further includes an intermediary device; when the original eSIM terminal corresponding to the target number identifier is an IoT terminal, the service management portal is a management platform that communicates with the terminal device; the terminal device is connected to the intermediary device; and the management platform is connected to a blank SIM card through the intermediary device.

[0168] Here, for enterprise users (such as logistics companies, car manufacturers, or industrial IoT operators) facing malfunctions of deployed IoT terminals (such as vending machines, vehicle T-Boxes, and remote sensors), a high-security number migration operation is performed through an enterprise management platform in conjunction with intermediary equipment.

[0169] In this scenario, the business management portal is specifically manifested as a management platform that communicates with and connects to terminal devices. These terminal devices typically refer to desktop computers, laptops, or dedicated industrial control terminals used by enterprise administrators; the management platform is an enterprise-level web management system or dedicated client software running on these devices. Intermediary devices (such as batch card writers or single-card readers) are physically connected to the administrator's terminal device and are used to read and write blank SIM cards.

[0170] Before step S101, the method further includes the following steps S801-S804.

[0171] In step S801, the management platform receives the second login request sent by the user and verifies the second login request based on the second preset verification rule to obtain the second verification result.

[0172] Here, the enterprise administrator opens the management platform login interface on the terminal device and enters the enterprise account credentials (such as enterprise ID, administrator account, and password). This constitutes a second login request. The management platform backend or the integrated Unified Identity Authentication (IAM) system verifies the login based on the second preset verification rules. Unlike the verification for individual users, the second preset verification rules typically include: verifying whether the account is valid, verifying whether the login IP address belongs to the enterprise's whitelist network segment, and verifying whether the account has the role permissions for "device maintenance" or "SIM card management". Only when all conditions are met will a successful second verification result be generated.

[0173] Step S802: If the second verification result is successful, the management platform logs into the enterprise account corresponding to the second login request and displays the device management interface to the user.

[0174] Here, after the administrator successfully logs in, the management platform enters the main interface, namely the device management interface. The device management interface typically displays the status information of thousands of IoT devices under the enterprise's name in the form of a list or map. The interface includes the device's unique identifier (Device ID / EID), associated identification number (MSISDN / IMSI), online / offline status, signal strength, and geographical location. The administrator can quickly locate the specific device that reported a fault using the search bar.

[0175] In step S803, the management platform responds to the user's selection of the target IoT device in the device management interface and the triggering of the temporary number migration function by generating a secondary authentication request and sending the secondary authentication request to the preset verification platform; wherein, the target IoT device corresponds to the target number identifier.

[0176] Here, when an administrator selects the faulty target IoT device in the list and clicks the "Emergency Migration" or "Faulty Card Replacement" button, considering that IoT devices often involve core enterprise assets or critical data transmission, the hardware connection will not be initiated immediately. Instead, a risk control process for highly sensitive operations will be triggered. The management platform will pop up a secondary authentication window, requiring the administrator to further confirm their identity.

[0177] At this point, the management platform generates a two-factor authentication request and sends it to a pre-set authentication platform. This platform can be the operator's security authentication server or an internal advanced authentication system within the enterprise.

[0178] The specific forms of secondary verification may include: sending a dynamic verification code to the super administrator's mobile phone number reserved by the enterprise, requiring the insertion of a USB key (U-shield) for digital signature by the administrator, or initiating a "multi-party authorization approval" request through the enterprise's instant messaging software, in order to prevent hackers from maliciously migrating enterprise device numbers on a large scale after ordinary administrator accounts are stolen.

[0179] In step S804, when the management platform receives the third verification result returned by the preset verification platform and the third verification result is a successful verification, it establishes a communication connection with the intermediary device.

[0180] Here, the management platform only unlocks the underlying hardware access permissions after the preset verification platform returns a third verification result of "verification passed" (e.g., super administrator has approved, or U-shield verification is successful). At this time, the management platform initializes the communication link with the external intermediary device (card reader) through the terminal device's USB or serial port interface. It may display a message on the interface saying "Authentication passed, please insert a blank SIM card," and prepare to proceed with the subsequent process of reading the card number and sending the migration request.

[0181] In an optional implementation, step S101 includes the following steps S901-S903.

[0182] In step S901, the management platform sends a read command to the intermediary device to receive the SIM card identifier returned by the intermediary device; wherein, the SIM card identifier is read by the intermediary device from the blank SIM card in response to the read command.

[0183] Here, the management platform sends read commands to the intermediary device via USB, serial port, or LAN connection. In large-scale IoT operation and maintenance scenarios, the intermediary device may be an industrial-grade reader / writer supporting concurrent operation across multiple card slots, or an automated card-issuing robot. The commands sent by the management platform can be one-time single-card read commands or polling batch read commands. The intermediary device responds to the commands, resets the blank SIM card in the card slot, and reads its Integrated Circuit Card Identifier (ICCID) as the SIM card identifier. After reading, the intermediary device sends one or more SIM card identifiers back to the management platform. Upon receiving the identifiers, the management platform typically verifies them in its local database to confirm whether these cards belong to the company's pre-purchased and recorded inventory of legitimate blank card resources, preventing the use of cards that are not company assets.

[0184] In step S902, the management platform obtains the target number identifier corresponding to the target IoT device, and generates a migration request based on the SIM card identifier, the target number identifier, and the device identifier corresponding to the target IoT device.

[0185] Here, the management platform first retrieves the core communication parameters bound to the target IoT device from the background asset database based on the target IoT device selected by the administrator on the interface. These parameters include the target number identifier (such as MSISDN or IMSI) and the device's unique hardware device identifier (such as International Mobile Equipment Identity (IMEI) or Embedded Universal Integrated Circuit Card Identifier (EID)).

[0186] In enterprise asset management, phone numbers are attached to devices. Adding device identifiers to migration requests allows the operator's backend system to verify whether the number truly belongs to that specific hardware device during subsequent processing, thus preventing the number from being mistakenly migrated to an unrelated business context.

[0187] The management platform binds the read blank SIM card identifier with the retrieved target number identifier and device identifier one by one. For batch operations, the platform generates a list containing multiple mapping relationships (e.g., Device A - Number A - New Card A; Device B - Number B - New Card B). Subsequently, the platform encapsulates this data into a migration request message (such as XML or JSON format) conforming to the operator's B2B interface specifications, and includes the company's timestamp, request serial number, and operator ID in the message.

[0188] In step S903, the management platform sends the migration request to the operator's backend system through a preset encrypted channel.

[0189] Here, considering that IoT enterprise customers typically have deep system integrations with operators, the pre-configured encrypted channel usually refers to a higher level of security connection method. For example, the management platform can communicate with the operator's backend system through a leased line based on IPSec VPN, an MPLS leased line, or an API gateway configured with mutual SSL / TLS authentication (Mutual TLS). The management platform uses the enterprise's private key to digitally sign the generated migration request and sends it to the operator's backend system through this encrypted channel.

[0190] In an optional implementation, when the operator's backend system identifies that the target eSIM number is in a transferable state, before the step of performing a service locking operation on the original configuration file corresponding to the target number identifier in step S103, the method further includes the following steps S1001-S1002.

[0191] In step S1001, the operator's backend system determines whether the enterprise account has the operation permission for the target IoT device, whether the device status of the target IoT device meets the preset migration conditions, and whether the migration request conforms to the preset enterprise policy; the preset migration conditions are offline status or maintainable status; the preset enterprise policy includes at least one of the device usage scope policy and migration duration policy.

[0192] Here, after receiving the migration request, the operator's backend system performs the following three levels of verification in sequence.

[0193] First, permission ownership verification. The operator's backend system queries the business support database to verify whether a legitimate binding relationship exists between the enterprise account initiating the request and the target IoT device in the request. It checks whether the device belongs to the enterprise account and whether the account currently has the permission to perform SIM card lifecycle management for that specific device. This prevents Company A's administrator from mistakenly or maliciously operating Company B's devices, or prevents ordinary maintenance accounts with only viewing permissions from performing high-risk migration operations.

[0194] Second, device status verification. Check whether the real-time status of the target IoT device meets the preset migration conditions. The preset migration conditions include offline status or maintainable status.

[0195] Offline status usually refers to the core network side showing that the device has detached or has not had a heartbeat for a long time.

[0196] The maintainable status is a logic unique to IoT scenarios. In one feasible embodiment, although the device's network connection is normal, the device itself may report a fault code or enter maintenance mode through the service channel. The operator's backend system obtains this service status by connecting to the enterprise's IoT connection management platform. Migration is only allowed when the device is indeed in a fault or maintenance state, preventing the forced migration of numbers from devices that are providing services normally, thus avoiding service interruption.

[0197] Third, policy compliance verification. Check whether this migration request complies with the preset enterprise policies. The preset enterprise policies specifically include at least one of the device usage scope policy and migration duration policy.

[0198] Device Usage Scope Policy: The operator's backend system verifies the type of card reader device or geographical location where the blank SIM card is located. For example, enterprise policies may stipulate that "numbers from vending machines can only be migrated to dedicated handheld test terminals, not to general mobile phones," or "number migration can only be carried out within authorized factory campuses (based on base station cells or IP fences)." This control is achieved by comparing the SIM card identification attributes or outlet information in the request.

[0199] Migration Duration Policy: The operator's backend system checks whether the requested migration duration is within the threshold allowed by the company. For example, if the company stipulates that maintenance testing should not exceed 48 hours, a request for a 30-day validity period will be considered a violation. In addition, the operator's backend system will also check whether the cumulative number of migrations for the device in the current month exceeds the limit, triggering a risk control circuit breaker.

[0200] Step S1002: If the operator's backend system determines that the enterprise account has operating permissions, the device status meets the preset migration conditions, and the migration request conforms to the preset enterprise policy, a service lockout operation is triggered.

[0201] Here, the operator's backend system only considers the migration request legal, secure, and compliant with corporate management standards when all three dimensions of verification—permissions, status, and policy—pass. Only then will the service locking process for the original configuration file (such as suspending the IMSI service) be formally triggered, and the subsequent temporary configuration file generation steps continue.

[0202] Conversely, if any condition is not met (e.g., the device is in normal online working condition, or the area to be migrated exceeds the enterprise's permitted scope), the operator's backend system will immediately reject the migration request, return a specific error reason code (such as "Error code: E003 - Device online migration prohibited"), and send an alarm notification to the enterprise administrator, thereby ensuring the strict control and secure operation of IoT connected assets.

[0203] In a specific implementation plan for emergency repair and temporary migration of communication services for equipment failure in a smart vending machine operator, the eSIM number migration system includes: a smart vending machine offline due to a communication module failure (i.e., the original eSIM terminal corresponding to the target number identifier, which is an IoT terminal); an industrial laptop computer used by the enterprise's maintenance engineer (i.e., the terminal device, on which the "Enterprise IoT Asset Management Platform" runs as a business management portal); a multi-card reader / writer connected to the laptop's USB port (i.e., an intermediary device); and a blank SIM card that the enterprise has pre-purchased and entered into its database.

[0204] Suppose that maintenance engineer Li Si goes to a shopping mall to repair an offline vending machine with the serial number "VM-2024-88".

[0205] First, Li Si opened the "Enterprise IoT Asset Management Platform" on his laptop. Li Si entered his employee ID and static password and sent a "second login request". The platform backend verified the login based on "second preset verification rules" (such as verifying whether the account belongs to the "on-site maintenance group" and whether the current IP address is within a legitimate VPN network segment).

[0206] When the "Second Verification Result" passed, Li Si successfully logged into his enterprise account, and the platform displayed the device management interface to him. Li Si searched for and selected the faulty device "VM-2024-88" on the map or in the list, and found that the device's heartbeat status was "offline". Li Si clicked the "Emergency Migration / Temporary Takeover" button on the device details page (triggering the operation).

[0207] Considering that IoT cards involve corporate funding pools and are prone to misuse, the platform will not directly initiate the card writing process. Instead, it will generate a "secondary authentication request" and send it to a pre-set verification platform. The verification platform will then send an approval SMS to Li Si's department head or send a signature request to the hardware U-shield linked to Li Si.

[0208] Only after Li Si inserts the USB key and completes the verification, or after the supervisor replies "agree," will the verification platform return a "third verification result" indicating successful verification. At this point, the management platform unlocks the underlying USB port permissions and initializes the communication connection with the reader.

[0209] Li Si inserted a blank SIM card into the card slot of the reader.

[0210] The management platform automatically sends a read command to the reader and receives the ICCID (SIM card identifier) ​​of the blank SIM card returned by the reader.

[0211] Next, the management platform automatically retrieves the file data of the faulty vending machine "VM-2024-88" from the backend database, obtains its bound IoT private network number (target number identifier, such as 14xxxxxxxxx) and the vending machine's hardware serial number (IMEI, i.e., device identifier).

[0212] The management platform strongly binds the above three sets of data (new card ICCID, original number MSISDN, and original device IMEI) and generates a migration request. The inclusion of a "device identifier" ensures that the number can only be used for maintenance services on this specific vending machine, or to prove in subsequent audits that the number has been borrowed by this device.

[0213] Subsequently, the management platform uses the IPSec VPN leased line (pre-encrypted channel) established between the enterprise and the operator to send the migration request with the enterprise's digital signature to the operator's back-end system.

[0214] After receiving the request, the operator's backend system performs multi-dimensional risk control verification specific to the Internet of Things: Permission verification: The system verifies whether the corporate account of "XX Vending Machine Operation Company" has the permission to write cards to the number "14xxxxxxxxx", and whether Li Si's sub-account has the right to perform this operation.

[0215] Status Verification: The system queries the core network and confirms that the original IMSI corresponding to "VM-2024-88" has indeed had no data transmission for 4 consecutive hours (meeting the preset migration conditions for "offline status"). If the device is online, the system will suspect that this is malicious misuse of the number and thus reject the request.

[0216] Policy Verification: The system checks the migration duration requested in the request. Assume the enterprise policy stipulates that temporary repair cards cannot be valid for more than 24 hours (migration duration policy) and can only be activated within the cell range of the base station where the shopping mall is located (equipment usage range policy). The system will compare the request parameters with these preset policies.

[0217] If all the above conditions (permissions, status, and policies) are met, the operator's backend system determines that the operation is compliant. Subsequently, a service lock operation is triggered, sending a command to the core network to forcibly mark the IMSI of the vending machine's built-in eSIM as suspended, preventing sudden reconnection from causing billing chaos. Simultaneously, a temporary configuration file, valid for only 24 hours and bound to the blank card's ICCID, is generated and encrypted, and sent to Li Si's management platform.

[0218] After receiving the document, Li Si writes it onto a blank card and inserts it into the vending machine's spare external card slot (or connects it to the vending machine using a test 4G router). The vending machine then regains internet access, and Li Si can begin remote diagnostics or restocking data synchronization. The entire process ensures business recovery while strictly preventing the company's IoT cards from being stolen and used on personal mobile phones to watch videos or other violations.

[0219] Based on the above embodiments, this application provides an eSIM number migration system, referring to... Figure 5 The present application provides an eSIM number migration system, which includes a service management portal 1, an operator back-end system 2 and a blank SIM card 3 that are respectively connected to the service management portal 1.

[0220] The business management portal 1 is used to send migration requests for a target eSIM number to the operator's back-end system 2; the migration request includes the target number identifier corresponding to the target eSIM number and the SIM card identifier corresponding to the blank SIM card 3.

[0221] Operator backend system 2 is used to identify whether the target eSIM number is in a transferable state based on the received target number identifier.

[0222] The operator's backend system 2 is used to perform a service lock operation on the original configuration file corresponding to the target number identifier when the target eSIM number is identified as being in a transferable state, generate a temporary configuration file that matches the target number identifier and SIM card identifier, and send the temporary configuration file to the business management portal 1.

[0223] The service management portal 1 is used to write the received temporary configuration file to the blank SIM card 3 in order to migrate the communication services of the target eSIM number to the blank SIM card 3.

[0224] Here, Business Management Portal 1 is used to provide a human-computer interaction interface and execute the control logic of local devices. Depending on the application scenario, Business Management Portal 1 can take different physical forms.

[0225] In the context of individual users, the business management portal 1 is specifically manifested as an application running on a mobile terminal (such as a smartphone or tablet). The mobile terminal has a processor, memory, and wireless communication module, and the application integrates a user authentication module, a device status detection module, and a smart card read / write driver module.

[0226] In IoT or enterprise-level application scenarios, the business management portal 1 is specifically manifested as a management platform (web-based or client software) deployed on a server or dedicated industrial control computer. The management platform has batch data processing capabilities, enterprise-level access control functions, and interface driver capabilities for external hardware devices.

[0227] The business management portal 1 is configured to: receive migration instructions from users through the user interface; collect the target number identifier (such as mobile phone number or device ID) corresponding to the target eSIM number and the SIM card identifier (such as ICCID) of the blank SIM card 3; encapsulate and encrypt the above information; generate a migration request and send it to the operator's backend system 2 through the network; and receive the encrypted data packet returned by the operator's backend system 2 and call the underlying read / write interface to write it into the physical card.

[0228] The operator backend system 2 is the core server-side component of the system, deployed on the network side of the mobile communication operator. Physically, it typically consists of multiple servers or server clusters, and logically includes the Business Support System (BSS), Home Subscriber Server (HSS / HLR), and Subscription Management Data Preparation Platform (SM-DP+).

[0229] The business support system module stores users' contract information and is responsible for verifying the legitimacy of accounts and business permissions.

[0230] The Home Subscriber Server module is used to manage the location information and status of mobile users in the core network, and has the ability to issue instructions to the core network to modify the IMSI status (such as suspending service).

[0231] The subscription management data preparation platform module is the core encryption machine for generating eSIM profiles, and it has the ability to generate GSMA-compliant profile data packets, manage keys, and transmit securely via encrypted channels.

[0232] The operator's backend system 2 is configured to: upon receiving a migration request, link the aforementioned internal modules to identify whether the target eSIM number is in a migration-ready state (such as verifying permissions and device offline status); upon confirming migration readiness, trigger service locking logic to block communication of the original device, and generate a temporary configuration file for targeted binding based on the unique identifier of the blank SIM card 3, and encrypt and send it back to the business management portal 1.

[0233] Blank SIM Card 3 is the physical carrier component of the system, specifically a Universal Integrated Circuit Card (UICC) conforming to the ISO / IEC 7816 standard and relevant GSMA specifications. This blank SIM Card 3 has a pre-installed security domain (ISD-P) and transmission key, but is not initially written with a specific communication service profile. The card possesses a unique hardware serial number (ICCID), used for one-to-one security binding with the generated temporary profile during the migration process.

[0234] Furthermore, referring to Figure 6In order to achieve a physical connection between the business management portal 1 and the blank SIM card 3, the eSIM number migration system may also include an intermediary device 4.

[0235] When the business management portal 1 runs on a terminal that does not have direct card insertion capability (such as a regular PC or a mobile phone with unauthorized card slot access), the intermediary device 4 acts as an external smart card reader / writer, connecting to the terminal device where the business management portal 1 is located via a Universal Serial Bus (USB), Bluetooth, or Near Field Communication (NFC) interface. The intermediary device 4 internally includes a card-machine channel circuit, used to transmit APDU commands issued by the business management portal 1 to the blank SIM card 3, and to feed back the card processing results to the business management portal 1.

[0236] In IoT batch processing scenarios, the intermediary device 4 can also be an industrial-grade card writing device or an automated card issuing machine with multi-slot concurrent read and write capabilities.

[0237] In an optional implementation, the operator's backend system 2 is also used to query the service subscription information corresponding to the target number identifier, identify whether the target number identifier has eSIM service permissions, and obtain the operating status of the original eSIM terminal corresponding to the target number identifier.

[0238] If the operator's backend system 2 identifies that the target number identifier has eSIM service permissions and the original eSIM terminal is offline, it determines that the target eSIM number corresponding to the target number identifier is in a transferable state.

[0239] In an optional implementation, the operator backend system 2 is further configured to send a service suspension instruction to the mobile communication core network, so that the mobile communication core network marks the IMSI status corresponding to the target number identifier as a service suspension status.

[0240] And / or, the operator's back-end system 2 is also used to send a maintenance mode command to the original eSIM terminal corresponding to the target number identifier through a preset push channel; when the original eSIM terminal is online via the wireless local area network, the original eSIM terminal responds to the maintenance mode command and controls the internal eSIM chip to enter a restricted state.

[0241] In an optional implementation, the operator's back-end system 2 is also used to generate an initial temporary configuration file containing a preset validity period based on the business data corresponding to the target number identifier.

[0242] The operator's backend system 2 is also used to encrypt the initial temporary configuration file based on the preset key information corresponding to the SIM card identifier, so as to obtain a temporary configuration file.

[0243] The operator's back-end system 2 is also used to send temporary configuration files to the business management portal 1 through a preset encrypted channel.

[0244] In an optional implementation, refer to Figure 6 The eSIM number migration system also includes an intermediary device 4, through which the business management portal 1 is connected to the blank SIM card 3.

[0245] The business management portal 1 is also used to generate a write command based on the temporary configuration file and send the write command to the intermediary device 4 so that the intermediary device 4 can write the temporary configuration file to the blank SIM card 3 through the preset SIM card channel.

[0246] The business management portal 1 is also used to receive write success confirmation information returned by the intermediary device 4, and generate activation confirmation information based on the write success confirmation information.

[0247] The business management portal 1 is also used to send activation confirmation information to the operator's back-end system 2, so that the operator's back-end system 2 disables the original configuration file and performs activation operation on the temporary configuration file that has been written to the blank SIM card 3.

[0248] In an optional implementation, the eSIM number migration system further includes an intermediary device 4; when the original eSIM terminal corresponding to the target number identifier is a mobile terminal, the service management portal 1 is an operator application running on the terminal device; the terminal device is connected to the intermediary device 4; the operator application is connected to the blank SIM card 3 through the intermediary device 4.

[0249] The operator application is also used to receive the first login request sent by the user, and to verify the first login request based on the first preset verification rule to obtain the first verification result.

[0250] If the first verification result is successful, the operator application logs into the operator account corresponding to the first login request and displays the service function menu to the user.

[0251] The operator application is also used to establish a communication connection with the intermediary device 4 in response to the user's triggered operation for the temporary number migration function in the service function menu.

[0252] In an optional implementation, the first login request includes a target number identifier.

[0253] The operator application is also used to send a read command to the intermediary device 4 to receive the SIM card identifier returned by the intermediary device 4; wherein the SIM card identifier is read by the intermediary device 4 from the blank SIM card 3 in response to the read command.

[0254] The operator application is also used to obtain current branch information and generate migration requests based on SIM card identifier, target number identifier, and current branch information.

[0255] The carrier application is also used to send migration requests to the carrier's backend system 2 through a preset encrypted channel.

[0256] In an optional implementation, when the operator's back-end system 2 identifies that the target eSIM number is in a transferable state, the operator's back-end system 2 is also used to determine whether the SIM card identifier belongs to the preset certified device list and whether the current outlet information belongs to the preset legitimate after-sales outlet list.

[0257] If the operator's backend system 2 determines that the SIM card identifier belongs to the preset certified device list and the current outlet information belongs to the preset legitimate after-sales outlet list, a service lock operation will be triggered.

[0258] In an optional implementation, the eSIM number migration system further includes an intermediary device 4; when the original eSIM terminal corresponding to the target number identifier is an IoT terminal, the service management portal 1 is a management platform that communicates with the terminal device; the terminal device is connected to the intermediary device 4; the management platform is connected to the blank SIM card 3 through the intermediary device 4.

[0259] The management platform is also used to receive a second login request sent by the user, and to verify the second login request based on the second preset verification rules to obtain a second verification result.

[0260] If the second verification result is successful, the management platform logs into the enterprise account corresponding to the second login request and displays the device management interface to the user.

[0261] The management platform is also used to generate a secondary authentication request in response to the user's selection of a target IoT device in the device management interface and the triggering of the temporary number migration function, and send the secondary authentication request to the preset verification platform; wherein, the target IoT device corresponds to the target number identifier.

[0262] When the management platform receives the third verification result returned by the preset verification platform and the third verification result is a successful verification, it establishes a communication connection with the intermediary device 4.

[0263] In an optional implementation, the management platform is further configured to send a read command to the intermediary device 4 to receive a SIM card identifier returned by the intermediary device 4; wherein the SIM card identifier is read by the intermediary device 4 from the blank SIM card 3 in response to the read command.

[0264] The management platform is also used to obtain the target number identifier corresponding to the target IoT device, and generate a migration request based on the SIM card identifier, the target number identifier, and the device identifier corresponding to the target IoT device.

[0265] The management platform is also used to send migration requests to the operator's back-end system 2 through a preset encrypted channel.

[0266] In an optional implementation, the operator backend system 2 is further used to determine whether the enterprise account has the operation permission for the target IoT device, whether the device status of the target IoT device meets the preset migration conditions, and whether the migration request conforms to the preset enterprise policy; the preset migration conditions are offline status or maintainable status; the preset enterprise policy includes at least one of the device usage scope policy and the migration duration policy.

[0267] If the operator's backend system 2 determines that the enterprise account has the operation permission, the device status meets the preset migration conditions, and the migration request conforms to the preset enterprise policy, a service lock operation will be triggered.

[0268] The computer program product provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0269] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0270] Furthermore, in the description of the embodiments of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0271] If the aforementioned functions are implemented as software functional units 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 portion 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 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. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0272] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0273] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

Claims

1. A method of migration of eSIM numbers, characterized by, A migration system for eSIM numbers, comprising a service management portal, an intermediary device, and an operator backend system and a blank SIM card respectively connected to the service management portal; The business management portal is connected to the blank SIM card via the intermediary device; the method includes: The service management portal sends a migration request for the target eSIM number to the operator's backend system; the migration request includes a target number identifier corresponding to the target eSIM number and a SIM card identifier corresponding to the blank SIM card; wherein, the SIM card identifier is read by the intermediary device from the blank SIM card; The operator's back-end system identifies whether the target eSIM number is in a transferable state based on the received target number identifier; When the operator's backend system identifies that the target eSIM number is in the migrateable state, it performs a service lock operation on the original configuration file corresponding to the target number identifier, generates a temporary configuration file that matches the target number identifier and the SIM card identifier, and sends the temporary configuration file to the service management portal. The service management portal writes the received temporary configuration file into the blank SIM card to migrate the communication services of the target eSIM number to the blank SIM card; The operator's backend system generates an initial temporary configuration file containing a preset validity period based on the business data corresponding to the target number identifier, and embeds a monitoring applet in the initial temporary configuration file; the operator's backend system encrypts the initial temporary configuration file based on the preset key information corresponding to the SIM card identifier to obtain the temporary configuration file; the monitoring applet is configured to run automatically after the blank SIM card is powered on, and when it detects that the current system time exceeds the preset validity period, it automatically disables the communication function on the blank SIM card or deletes the temporary configuration file; The business management portal generates an application protocol data unit instruction set based on the temporary configuration file, enabling the intermediary device to write the temporary configuration file containing the monitoring applet into the security domain of the blank SIM card through physical contacts, so as to migrate the communication services of the target eSIM number to the blank SIM card. 2.The eSIM number migration method of claim 1, wherein, The step of the operator's back-end system identifying whether the target eSIM number is in a transferable state based on the received target number identifier includes: The operator's backend system queries the service subscription information corresponding to the target number identifier, identifies whether the target number identifier has eSIM service permissions, and obtains the operating status of the original eSIM terminal corresponding to the target number identifier; If the operator's backend system recognizes that the target number identifier has the eSIM service permission and the original eSIM terminal is offline, it determines that the target eSIM number corresponding to the target number identifier is in the transferable state. 3.The eSIM number migration method of claim 1, wherein, The steps of the operator's backend system performing a service locking operation on the original configuration file corresponding to the target number identifier include: The operator's back-end system sends a service suspension instruction to the mobile communication core network, so that the mobile communication core network marks the IMSI status corresponding to the target number identifier as a service suspension status; And / or, The operator's backend system sends a maintenance mode command to the original eSIM terminal corresponding to the target number identifier through a preset push channel; when the original eSIM terminal is online via a wireless local area network, the original eSIM terminal responds to the maintenance mode command and controls the internal eSIM chip to enter a restricted state. 4.The eSIM number migration method of claim 1, wherein, The step of the operator's backend system generating a temporary configuration file that matches the target number identifier and the SIM card identifier, and sending the temporary configuration file to the service management portal, includes: The operator's backend system sends the temporary configuration file to the business management portal through a preset encrypted channel. 5.The eSIM number migration method of claim 1, wherein, The step of the business management portal writing the received temporary configuration file to the blank SIM card includes: The business management portal generates a write instruction based on the temporary configuration file and sends the write instruction to the intermediary device, so that the intermediary device writes the temporary configuration file to the blank SIM card through a preset SIM card channel; The business management portal receives the write success confirmation information returned by the intermediary device, and generates activation confirmation information based on the write success confirmation information; The business management portal sends the activation confirmation information to the operator's backend system, so that the operator's backend system disables the original configuration file and performs an activation operation on the temporary configuration file that has been written to the blank SIM card.

6. The eSIM number migration method of claim 1, wherein, When the original eSIM terminal corresponding to the target number identifier is a mobile terminal, the service management portal is an operator application running on the terminal device; the terminal device is connected to the intermediary device; the operator application is connected to the blank SIM card through the intermediary device. Before the step of the business management portal sending a migration request for the target eSIM number to the operator's backend system, the method further includes: The operator application receives a first login request sent by the user and verifies the first login request based on a first preset verification rule to obtain a first verification result; If the first verification result is successful, the operator application logs into the operator account corresponding to the first login request and displays the service function menu to the user. The operator application, in response to the user's triggering operation for the temporary number migration function in the service function menu, establishes a communication connection with the intermediary device.

7. The eSIM number migration method of claim 6, wherein, The first login request includes the target number identifier; The steps by which the service management portal sends a migration request for the target eSIM number to the operator's back-end system include: The operator application sends a read command to the intermediary device to receive the SIM card identifier returned by the intermediary device; wherein, the SIM card identifier is read by the intermediary device from the blank SIM card in response to the read command; The operator application obtains the current branch information and generates the migration request based on the SIM card identifier, the target number identifier, and the current branch information; The operator application sends the migration request to the operator's backend system through a preset encrypted channel.

8. The eSIM number migration method of claim 7, wherein, Before the operator's backend system performs a service locking operation on the original configuration file corresponding to the target number identifier when it identifies that the target eSIM number is in the migrateable state, the method further includes: The operator's backend system determines whether the SIM card identifier belongs to the preset certified device list and whether the current outlet information belongs to the preset legitimate after-sales outlet list; If the operator's backend system determines that the SIM card identifier belongs to the preset certified device list and the current outlet information belongs to the preset legitimate after-sales outlet list, the service lock operation is triggered. 9.The eSIM number migration method of claim 1, wherein, When the original eSIM terminal corresponding to the target number identifier is an IoT terminal, the service management portal is a management platform that communicates with the terminal device; the terminal device is connected to the intermediary device; the management platform is connected to the blank SIM card through the intermediary device. Before the step of the business management portal sending a migration request for the target eSIM number to the operator's backend system, the method further includes: The management platform receives a second login request sent by the user and verifies the second login request based on a second preset verification rule to obtain a second verification result; If the second verification result is successful, the management platform logs into the enterprise account corresponding to the second login request and displays the device management interface to the user. In response to the user's selection of a target IoT device in the device management interface and the triggering of the temporary number migration function, the management platform generates a secondary authentication request and sends the secondary authentication request to a preset verification platform; wherein, the target IoT device corresponds to the target number identifier; When the management platform receives the third verification result returned by the preset verification platform, and the third verification result is a successful verification, it establishes a communication connection with the intermediary device.

10. The eSIM number migration method according to claim 9, characterized in that, The steps by which the service management portal sends a migration request for the target eSIM number to the operator's back-end system include: The management platform sends a read command to the intermediary device to receive the SIM card identifier returned by the intermediary device; wherein, the SIM card identifier is read by the intermediary device from the blank SIM card in response to the read command; The management platform obtains the target number identifier corresponding to the target IoT device, and generates the migration request based on the SIM card identifier, the target number identifier, and the device identifier corresponding to the target IoT device; The management platform sends the migration request to the operator's backend system through a preset encrypted channel.

11. The eSIM number migration method of claim 9, wherein, Before the operator's backend system performs a service locking operation on the original configuration file corresponding to the target number identifier when it identifies that the target eSIM number is in the migrateable state, the method further includes: The operator's backend system determines whether the enterprise account has operation permissions for the target IoT device, whether the device status of the target IoT device meets the preset migration conditions, and whether the migration request conforms to the preset enterprise policy; the preset migration conditions are offline status or maintainable status; the preset enterprise policy includes at least one of the device usage scope policy and migration duration policy; If the operator's backend system determines that the enterprise account has the operation permission, the device status meets the preset migration conditions, and the migration request conforms to the preset enterprise policy, the service lock operation is triggered.

12. A migration system of eSIM numbers, characterized by, It includes a business management portal, an intermediary device, and an operator's back-end system and a blank SIM card that are respectively connected to the business management portal in communication; the business management portal is connected to the blank SIM card through the intermediary device; The service management portal is used to send a migration request for a target eSIM number to the operator's backend system; the migration request includes a target number identifier corresponding to the target eSIM number and a SIM card identifier corresponding to the blank SIM card; wherein, the SIM card identifier is read by the intermediary device from the blank SIM card; The operator's back-end system is used to identify whether the target eSIM number is in a transferable state based on the received target number identifier; The operator's backend system is used to perform a service locking operation on the original configuration file corresponding to the target number identifier when it is identified that the target eSIM number is in the transferable state, generate a temporary configuration file that matches the target number identifier and the SIM card identifier, and send the temporary configuration file to the service management portal; The service management portal is used to write the received temporary configuration file into the blank SIM card, so as to migrate the communication services of the target eSIM number to the blank SIM card; The operator's backend system is further configured to generate an initial temporary configuration file containing a preset validity period and communication permissions lower than the original configuration file based on the business data corresponding to the target number identifier, and to embed a monitoring applet in the initial temporary configuration file; the operator's backend system is further configured to encrypt the initial temporary configuration file based on the preset key information corresponding to the SIM card identifier to obtain the temporary configuration file; the monitoring applet is configured to run automatically after the blank SIM card is powered on, and when it detects that the current system time exceeds the preset validity period, it automatically disables the communication function on the blank SIM card or deletes the temporary configuration file; The business management portal is also used to generate an application protocol data unit instruction set based on the temporary configuration file, so that the intermediary device can write the temporary configuration file containing the monitoring applet into the security domain of the blank SIM card through physical contacts, so as to migrate the communication services of the target eSIM number to the blank SIM card.

Images