Cross-carrier esim profile migration method and system

Abstract

The application provides a cross-operator eSIM profile migration method and system, comprising: receiving a profile migration request sent by a user terminal; verifying the profile migration request based on a smart contract, and sending a release notification to a source operator node after verification; receiving release confirmation information and data addressing credentials returned by the source operator node; sending a download notification carrying the data addressing credentials to a target operator node, so that the target operator node downloads and decrypts encrypted configuration data based on the data addressing credentials; receiving reception confirmation information returned by the target operator node, and updating the ownership state of the target profile. The method can reduce the dependence on centralized servers by uniformly processing the profile migration process based on the smart contract by the migration management module, thereby improving the collaborative credibility and state update reliability of cross-operator migration, and further reducing the risk of single point failure, data tampering and difficult traceability of migration history.

Description

Technical Field

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

[0002] With the continuous evolution of communication technologies, eSIM (embedded SIM) technology has been widely used in various smart terminal devices due to its highly integrated characteristics. In practical use, users often need to migrate their eSIM profiles across different operators due to reasons such as network service quality or tariffs. Achieving efficient and secure cross-network transfer of profiles has become a core key to ensuring the continuity of communication services and user experience.

[0003] Existing technologies primarily coordinate the transmission of configuration files between source operators, target operators, and terminals by deploying centralized servers. However, such centralized migration solutions not only pose a significant risk of single point of failure, but also make the complete configuration file data highly vulnerable to illegal interception or tampering during server-intermediate transmission. Furthermore, traditional cross-operator migrations typically require multiple independent centralized business systems to establish complex bilateral trust relationships and interface connections, resulting in low efficiency in multi-party collaboration. Additionally, the data flow throughout the migration process is opaque, and historical records are difficult to trace and prevent tampering.

[0004] In summary, existing technologies struggle to eliminate reliance on centralized intermediaries while ensuring data security, collaborative efficiency, and reliable traceability of migration history during cross-carrier configuration file migration. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a method and system for cross-carrier eSIM profile migration. By having the migration management module uniformly handle the profile migration process based on smart contracts, the dependence on centralized servers can be reduced, thereby improving the collaborative reliability and state update reliability of cross-carrier migration, and thus reducing the risks of single point of failure, data tampering, and difficulty in tracing migration history.

[0006] In a first aspect, the present invention provides a cross-carrier eSIM profile migration method, applied to a migration management module in a blockchain network; the migration management module is implemented based on a smart contract deployed on the blockchain network; the blockchain network also includes a source carrier node and a target carrier node, which are respectively used to call the smart contract to interact with the migration management module on-chain; the method includes: Receive a configuration file migration request sent by a user terminal; wherein the configuration file migration request includes the identification information of the target configuration file.

[0007] The configuration file migration request is verified based on a smart contract, and a release notification is sent to the source operator node after successful verification.

[0008] Receive release confirmation information and data addressing credentials returned by the source operator node; the data addressing credentials are used by the target operator node to obtain the encrypted configuration data corresponding to the target configuration file.

[0009] Send a download notification carrying data addressing credentials to the target operator node, so that the target operator node can download and decrypt the encrypted configuration data based on the data addressing credentials.

[0010] Receive the acceptance confirmation information returned by the target operator node and update the ownership status of the target configuration file.

[0011] In an optional implementation, before the step of receiving a configuration file migration request sent by a user terminal, the method further includes: Receive configuration file registration request sent by the source operator node; wherein, the configuration file registration request includes the feature information, user identification information and operator identification information of the configuration file to be registered.

[0012] Based on the configuration file registration request, generate the identification information corresponding to the configuration file to be registered.

[0013] The correspondence between the identification information, user identification information, and operator identification information of the configuration file to be registered is recorded in the blockchain network.

[0014] In an optional implementation, the configuration file migration request may also include the target carrier identifier, the target device identifier, and user authorization information.

[0015] The steps for verifying the configuration file migration request based on a smart contract, and sending a release notification to the source operator node after successful verification, include: Based on the identification information of the target configuration file, query the ownership status and migration status of the target configuration file in the blockchain network.

[0016] Based on the user's authorization information, verify whether the user terminal has migration permissions for the target configuration file.

[0017] Based on the target operator's identifier, identify the target operator's node and verify whether the target operator's node meets the preset operator conditions.

[0018] If the ownership status, migration status, migration permissions, and target operator node all meet the preset migration conditions, the configuration file migration request is confirmed to have passed verification.

[0019] Based on the identification information and ownership status of the target configuration file, determine the source operator node that currently holds the target configuration file.

[0020] Generate the migration service identifier corresponding to the configuration file migration request.

[0021] Write the target configuration file's identifier, target operator identifier, target device identifier, and migration service identifier into the blockchain network.

[0022] Send a release notification to the source operator node, carrying the identification information of the target configuration file and the migration service identifier.

[0023] In an optional implementation, the encrypted configuration data is the data obtained by the source operator node encrypting the configuration data corresponding to the target configuration file based on the public key information corresponding to the target operator node.

[0024] The steps for receiving the release confirmation information and data addressing credentials returned by the source operator node include: Receive release confirmation information returned by the source operator node based on the release notification.

[0025] Receive data addressing credentials submitted by the source operator node; wherein the data addressing credentials include at least one of storage address, content hash, download address or data access credentials.

[0026] Verify that the release confirmation message matches the source operator node.

[0027] If the release confirmation information matches the source operator node, obtain the node identifier corresponding to the target operator node.

[0028] Associate the target configuration file's identifier information, the node identifier corresponding to the target operator's node, the data addressing certificate, and the release confirmation information.

[0029] The associated record is written to the blockchain network as a release record.

[0030] In an optional implementation, the confirmation information received includes target operator confirmation information, new profile summary information, and binding status information.

[0031] The steps for receiving the confirmation message returned by the target operator node include: Receive the target operator confirmation information returned by the target operator node based on the download notification.

[0032] Receive new configuration file summary information and binding status information submitted by the target operator node; wherein, the new configuration file summary information is used to characterize the new configuration file generated by the target operator node based on the configuration data obtained after decrypting the encrypted configuration data, and the binding status information is used to characterize the binding result between the new configuration file and the target device corresponding to the target device identifier.

[0033] Verify that the target operator's confirmation information matches the target operator's node.

[0034] If the target operator's confirmation information matches the target operator's node, the new configuration file summary information and binding status information will be recorded to the blockchain network.

[0035] In an optional implementation, the step of updating the ownership status of the target configuration file includes: Determine whether the release confirmation message returned by the source operator node and the reception confirmation message returned by the target operator node have been received.

[0036] If a release confirmation message and a receipt confirmation message have been received, update the ownership status between the target configuration file and the source operator node to the released status.

[0037] Update the ownership status between the target configuration file or a new configuration file generated based on the target configuration file and the target operator node to the received status.

[0038] Update the migration status of the target configuration file to "migrated".

[0039] In an optional implementation, the blockchain network may also include a custodian node.

[0040] After updating the ownership status of the target configuration file, the method also includes: Generate the migration history corresponding to the target configuration file; wherein, the migration history includes at least one of the following: configuration file migration request, release confirmation information, data addressing certificate, download notification, receipt confirmation information, and ownership status update result.

[0041] The migration history is written to the blockchain network.

[0042] In response to a query request initiated by the regulatory node, the migration history is read from the blockchain network and returned to the regulatory node so that the regulatory node can audit the migration history.

[0043] In an optional implementation, after the step of updating the ownership status of the target configuration file, the method further includes: Send a migration completion notification to the user terminal.

[0044] Receive activation confirmation information returned by the user terminal.

[0045] Receive status update information returned by the target operator node.

[0046] Upon receiving activation confirmation and status update information, the activation status of the target configuration file or a new configuration file generated based on the target configuration file is updated to "activated".

[0047] In an optional implementation, after the step of updating the activation status of the target configuration file or a new configuration file generated based on the target configuration file to an activated state, the method further includes: Based on the release confirmation information, the receipt confirmation information, and the activation status, determine whether the preset settlement conditions are met.

[0048] Under the condition that the preset settlement conditions are met, settlement information between the source operator node and the target operator node is generated.

[0049] Based on the settlement information, perform migration settlement processing between the source operator node and the target operator node.

[0050] The settlement status corresponding to the migration settlement process is recorded to the blockchain network.

[0051] Secondly, the present invention provides a cross-carrier eSIM profile migration system, including a blockchain network and a user terminal connected by communication; the blockchain network includes a migration management module, a source carrier node, a target carrier node, and a monitoring node, wherein the migration management module is implemented based on a smart contract deployed on the blockchain network; the source carrier node and the target carrier node are respectively used to call the smart contract to interact with the migration management module on the chain; the monitoring node is used to audit the migration history in the blockchain network; the migration management module is used to execute the method as described in any of the foregoing embodiments.

[0052] This application provides a method and system for cross-carrier eSIM profile migration. By entrusting the cross-carrier eSIM profile migration process to a migration management module in a blockchain network, which executes the process uniformly based on smart contracts, the receiving of the profile migration request, verification of the migration request, release confirmation by the source operator node, transmission of data addressing credentials, downloading and decrypting of encrypted configuration data by the target operator node, receipt confirmation, and updating of ownership status form an on-chain closed-loop process. This makes the migration collaboration between the source operator node, the target operator node, and the user terminal more reliable, efficient, and automated. By triggering the source operator node to release the profile only after verification, the authorization credibility of the migration request and the accuracy of the migration operation can be improved. By using data addressing credentials for the target operator node to obtain encrypted configuration data, the security and controllability of the configuration data flow process can be improved. By updating the ownership status of the target profile only after the target operator node returns receipt confirmation information, the consistency of the status between profile release, reception, and ownership change can be improved. By recording and driving the above interaction process through the blockchain network and smart contracts, the transparency, reliability, and anti-tampering capability of the cross-carrier eSIM profile migration process can be improved, thereby enhancing the security, reliability, and collaborative efficiency of cross-carrier profile migration.

[0053] 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.

[0054] 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

[0055] 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.

[0056] Figure 1 A schematic diagram of a cross-carrier eSIM profile migration system provided in an embodiment of this application; Figure 2 This is a schematic diagram of a smart contract provided in an embodiment of this application; Figure 3 A flowchart illustrating the cross-carrier eSIM profile migration method provided in this application embodiment; Figure 4 A flowchart illustrating the process of uploading the configuration file to be registered to the blockchain, as provided in this application embodiment; Figure 5 A flowchart of a release notification sending method provided in an embodiment of this application; Figure 6 A flowchart illustrating the method for receiving release confirmation information and data addressing credentials provided in this application embodiment; Figure 7 A flowchart of the confirmation information receiving method provided in the embodiments of this application; Figure 8 A flowchart illustrating the ownership status update method provided in this application embodiment.

[0057] Icons: 1-Blockchain network; 2-User terminal; 11-Migration management module; 12-Source operator node; 13-Target operator node; 14-Regulatory node. Detailed Implementation

[0058] 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.

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

[0060] In eSIM profile migration scenarios across operators, existing technologies typically rely on a centralized migration server as an intermediary to coordinate profile transfer and state synchronization between the source operator, the target operator, and the user terminal. While this approach enables profile migration, the migration process depends on a single centralized node. If the centralized migration server fails, becomes congested, or is attacked, the profile migration process is easily interrupted, preventing the user terminal from completing the operator switch in a timely manner and affecting the continuity of communication services.

[0061] Meanwhile, existing centralized migration methods require configuration file-related data or configuration file transmission information to be relayed through a centralized migration server, resulting in a long data flow path. Furthermore, the migration status between the source operator, target operator, and user terminal is typically recorded and maintained by a centralized system. This method is prone to issues such as unauthorized data interception, tampering, or inconsistent status records, especially in cross-operator scenarios. Different operators need to establish bilateral trust relationships and interface connections, leading to a complex migration process and low collaboration efficiency. Moreover, existing migration processes lack a unified and reliable recording mechanism for operations such as request initiation, source operator release, target operator reception, and configuration file ownership changes. This makes it difficult to trace and prevent tampering of the entire migration process in the event of subsequent disputes or regulatory audits.

[0062] Based on this, this application provides a method and system for cross-carrier eSIM profile migration. By setting up a migration management module in a blockchain network and implementing the migration management module based on smart contracts deployed on the blockchain network, the verification of profile migration requests, release of source operator nodes, transmission of data addressing credentials, reception by target operator nodes, and updating of target profile ownership status can all be processed on-chain based on smart contracts. Therefore, this application does not require a centralized migration server to mediate and coordinate the cross-carrier migration process, reducing the impact of single points of failure on the migration process and improving the automation and collaborative efficiency of the migration process.

[0063] Furthermore, in this application, the source operator node can return release confirmation information and data addressing credentials. The target operator node can obtain encrypted configuration data corresponding to the target configuration file based on the data addressing credentials and return reception confirmation information upon completion of reception. After receiving the reception confirmation information, the migration management module updates the ownership status of the target configuration file, establishing a correspondence between configuration file release, configuration data acquisition, target operator reception, and ownership status change. This improves the security of configuration data flow during cross-operator migration, the accuracy of migration status updates, and the reliability of ownership changes.

[0064] Furthermore, since the migration management module is implemented based on smart contracts in the blockchain network, key interaction information and state changes during the migration process can be written into the blockchain network, forming a reliable migration record. Supervisory nodes can read and audit the migration history based on the blockchain network, thereby improving the transparency and traceability of the migration process and reducing the risk of configuration files being illegally migrated, reused, or migration responsibility being difficult to determine.

[0065] To facilitate understanding of this embodiment, the embodiments of this application will be described in detail below.

[0066] This application provides a cross-carrier eSIM profile migration system, referring to... Figure 1 The cross-carrier eSIM profile migration system provided in this application includes a blockchain network 1 and a user terminal 2 connected by communication. The blockchain network 1 includes a migration management module 11, a source carrier node 12, a target carrier node 13, and a monitoring node 14. The migration management module 11 is implemented based on a smart contract deployed on the blockchain network 1. The source carrier node 12 and the target carrier node 13 are respectively used to call the smart contract to interact with the migration management module 11 on the chain. The monitoring node 14 is used to audit the migration history in the blockchain network 1. The migration management module 11 is used to execute the cross-carrier eSIM profile migration method.

[0067] Here, user terminal 2 is a terminal device held and used by the user. User terminal 2 can be a smartphone, tablet, wearable device, vehicle terminal, IoT terminal, or other electronic device supporting eSIM functionality. User terminal 2 is communicatively connected to blockchain network 1 and is used to send a configuration file migration request to migration management module 11. The configuration file migration request includes the identification information of the target configuration file. In one embodiment, the configuration file migration request also includes the target operator identifier, the target device identifier, and user authorization information. The target device identifier can be the EID (Embedded General-Purpose Integrated Circuit Card Identifier) ​​of the target device. The user authorization information can be the user's digital signature. After user terminal 2 signs the configuration file migration request using the user's private key, it sends the signed configuration file migration request to blockchain network 1, enabling migration management module 11 to verify the authenticity and authorization validity of the configuration file migration request based on a smart contract.

[0068] Blockchain Network 1 is a distributed network jointly maintained by multiple participating nodes. Blockchain Network 1 is used to carry smart contracts, configuration file state information, migration service identifiers, release records, reception records, ownership status, activation status, settlement status, and migration history. Data in Blockchain Network 1 is maintained through a consensus mechanism, ensuring that on-chain records are tamper-proof and traceable. Blockchain Network 1 can be a consortium blockchain network or other types of blockchain networks that meet the needs of trusted collaboration among operators. On-chain interactions in Blockchain Network 1 include at least one of transaction invocation, event triggering, state reading, state writing, and record querying.

[0069] The migration management module 11 is a functional module in blockchain network 1 used to manage the cross-carrier migration process of configuration files. The migration management module 11 is implemented based on smart contracts deployed on blockchain network 1. The smart contracts include a migration management contract and an ownership registration contract. The migration management contract handles configuration file migration requests, verifies migration conditions, triggers the release of the source carrier node 12, triggers the reception of the target carrier node 13, records the migration status, and completes the migration process control. The ownership registration contract registers the configuration file's identification information, user identification information, carrier identification information, and the configuration file's ownership status, and updates the configuration file's ownership status after the migration is completed. The migration management contract and the ownership registration contract can be implemented as different functional logics within the same smart contract, or they can be implemented collaboratively as multiple smart contracts deployed on blockchain network 1.

[0070] Reference Figure 2 The smart contract logic corresponding to the migration management module 11 includes a configuration file registration interface, a migration request interface, a release confirmation interface, a receive confirmation interface, an ownership status update interface, and a migration history query interface. The configuration file registration interface is used by the source operator node 12 to submit configuration file registration requests and to generate the configuration file's identification information and record the correspondence between the configuration file's identification information, user identification information, and operator identification information. The migration request interface receives configuration file migration requests submitted by user terminal 2 and verifies the migration request based on user authorization information, the ownership status of the target configuration file, the migration status of the target configuration file, and the legality of the target operator node 13. The release confirmation interface is used by the source operator node 12 to submit release confirmation information and data addressing credentials, and to associate and record the release confirmation information and data addressing credentials to the blockchain network 1. The receive confirmation interface is used by the target operator node 13 to submit receive confirmation information, new configuration file summary information, and binding status information. The ownership status update interface updates the ownership status and migration status of the target configuration file when both the release confirmation information and the receive confirmation information meet the requirements. The migration history query interface is used to respond to query requests initiated by supervisory node 14, read migration history records from blockchain network 1, and return the migration history records to supervisory node 14.

[0071] Source operator node 12 is a node formed after the operator currently holding the target configuration file connects to blockchain network 1. Source operator node 12 invokes a smart contract to receive a release notification sent by migration management module 11, and after completing the release confirmation at the business level, returns release confirmation information and a data addressing credential to migration management module 11. The release confirmation information indicates that source operator node 12 has agreed to release the target configuration file. The data addressing credential is used by target operator node 13 to obtain the encrypted configuration data corresponding to the target configuration file. The data addressing credential may include at least one of a storage address, content hash, download address, or data access credential. Source operator node 12 also encrypts the configuration data corresponding to the target configuration file based on the public key information corresponding to target operator node 13, obtaining encrypted configuration data. Encrypted configuration data prevents the configuration data corresponding to the target configuration file from being exposed in plaintext during cross-operator transfers, thereby improving the security of configuration data transmission and storage.

[0072] The target operator node 13 is a node formed after the operator to which the user intends to migrate accesses the blockchain network 1. The target operator node 13 invokes a smart contract to receive a download notification sent by the migration management module 11 and obtains the encrypted configuration data corresponding to the target configuration file based on the data addressing credential carried in the download notification. The target operator node 13 also decrypts the encrypted configuration data based on its private key information, obtains the configuration data, and generates a new configuration file based on the decrypted configuration data. The target operator node 13 further binds the new configuration file to the target device corresponding to the target device identifier and returns a receipt confirmation message to the migration management module 11. The receipt confirmation message includes target operator confirmation information, a new configuration file digest, and binding status information. The new configuration file digest represents the new configuration file generated by the target operator node 13. The binding status information represents the binding result between the new configuration file and the target device.

[0073] Supervisory node 14 is used to audit the migration history in blockchain network 1. After connecting to blockchain network 1, supervisory node 14 can initiate query requests to migration management module 11. Migration management module 11 responds to the query requests initiated by supervisory node 14, reads the migration history from blockchain network 1, and returns the migration history to supervisory node 14. The migration history includes at least one of the following: configuration file migration request, release confirmation information, data addressing credential, download notification, receipt confirmation information, and ownership status update results. Supervisory node 14 audits the configuration file migration process based on the migration history to determine whether the request initiation, source operator release, target operator reception, ownership status update, activation status update, and settlement status records during the configuration file migration process are complete and reliable.

[0074] In one implementation, after receiving the release notification, the source operator node 12 encrypts the configuration data corresponding to the target configuration file to obtain encrypted configuration data, and stores the encrypted configuration data in a storage location accessible to the target operator node 13. The storage location can be a distributed storage system, the storage system corresponding to the source operator node 12, an operator-side data server, or other storage systems capable of providing data access. The source operator node 12 generates a data addressing credential based on the storage location of the encrypted configuration data and returns the data addressing credential to the migration management module 11. The data addressing credential includes at least one of a storage address, content hash, download address, or data access credential. The migration management module 11 does not need to store the complete encrypted configuration data in the blockchain network 1, but instead associates the data addressing credential with the identification information of the target configuration file, enabling the target operator node 13 to obtain the encrypted configuration data based on the data addressing credential.

[0075] After receiving the download notification carrying the data addressing credential, target operator node 13 accesses the corresponding storage location based on the credential and downloads the encrypted configuration data. Target operator node 13 decrypts the encrypted configuration data using its private key information to obtain the configuration data, and generates a new configuration file based on the decrypted configuration data. In this way, the actual storage of the encrypted configuration data is separated from the on-chain migration status record. Blockchain network 1 is mainly used to record the data addressing credential, migration status, and ownership status, which can reduce the storage pressure and privacy risks caused by directly uploading the complete configuration data to the chain while ensuring the trustworthiness and traceability of the migration process.

[0076] Source operator node 12 and target operator node 13 are merely role nodes within a single configuration file migration process. For example, for the same operator node 12, in one migration operation, operator node 12 can act as source operator node 12; in another migration operation, operator node 12 can also act as target operator node 13. The roles of source operator node 12 and target operator node 13 are determined by the identification information of the target configuration file in the configuration file migration request, the target operator identifier, and the ownership status recorded in blockchain network 1. The migration management module 11 determines the source operator node 12 currently holding the target configuration file based on the identification information and ownership status of the target configuration file. The migration management module 11 determines the target operator node 13 based on the target operator identifier.

[0077] During system operation, user terminal 2 sends a configuration file migration request to migration management module 11. Migration management module 11 verifies the configuration file migration request based on a smart contract. Upon successful verification, migration management module 11 sends a release notification to source operator node 12. Source operator node 12 returns release confirmation information and a data addressing credential based on the release notification. Migration management module 11 then sends a download notification carrying the data addressing credential to target operator node 13. Target operator node 13 downloads and decrypts the encrypted configuration data based on the data addressing credential, and returns a receipt confirmation to migration management module 11 after completing the generation of the new configuration file and binding to the target device. Upon receiving the receipt confirmation, migration management module 11 updates the ownership status of the target configuration file. This process, completed through migration management module 11 and smart contracts within blockchain network 1, enables cross-operator configuration file migration between user terminal 2, source operator node 12, and target operator node 13 without relying on a centralized server.

[0078] In one implementation, the migration management module 11 is further configured to send a migration completion notification to the user terminal 2 after the ownership status of the target configuration file is updated. Upon receiving the migration completion notification, the user terminal 2 can initiate a new configuration file download request to the target operator node 13 via the LPA (Local Configuration File Assistant), and complete the installation and activation of the new configuration file within the user terminal 2's secure area. After activation, the user terminal 2 returns activation confirmation information to the migration management module 11. The target operator node 13 can also return status update information to the migration management module 11. Upon receiving the activation confirmation information and status update information, the migration management module 11 updates the activation status of the target configuration file or a new configuration file generated based on the target configuration file to an activated state.

[0079] In one implementation, the migration management module 11 is further configured to, after the activation state is updated to an activated state, determine whether preset settlement conditions are met based on the release confirmation information, the reception confirmation information, and the activation state. If the preset settlement conditions are met, the migration management module 11 generates settlement information between the source operator node 12 and the target operator node 13, and performs migration settlement processing between the source operator node 12 and the target operator node 13 based on the settlement information. The migration management module 11 records the settlement state corresponding to the migration settlement processing to the blockchain network 1. The settlement processing can be implemented based on token transfers in the blockchain network 1, or it can be completed by an off-chain settlement system after the settlement result is recorded on the blockchain network 1.

[0080] The cross-carrier eSIM profile migration system provided in this application establishes a collaborative relationship based on a blockchain network between a migration management module, source carrier nodes, target carrier nodes, a monitoring node, and user terminals. The migration management module is responsible for migration process control and status updates; the source carrier node is responsible for releasing the target profile and providing encrypted configuration data; the target carrier node is responsible for acquiring encrypted configuration data, generating new profiles, and confirming binding; the monitoring node is responsible for migration history auditing; and the user terminal is responsible for initiating migration requests and activating new profiles. This application reduces reliance on centralized servers and improves data security, collaborative efficiency, status consistency, and the trustworthiness and traceability of migration history during the cross-carrier profile migration process.

[0081] Based on this, this application provides a cross-carrier eSIM profile migration method, applied to a migration management module in a blockchain network; the migration management module is implemented based on a smart contract deployed on the blockchain network; the blockchain network also includes a source carrier node and a target carrier node, which are used to call the smart contract to interact with the migration management module on the chain.

[0082] Reference Figure 3 The cross-carrier eSIM profile migration method provided in this application includes: Step S101: Receive a configuration file migration request sent by the user terminal; wherein the configuration file migration request includes the identification information of the target configuration file.

[0083] Here, the user terminal is a terminal device that supports eSIM functionality. The user terminal can respond to cross-carrier migration operations initiated by the user, generate a configuration file migration request, and send the configuration file migration request to the migration management module.

[0084] The target profile's identification information is used to uniquely identify the eSIM profile to be migrated. This identification information can be a profile identifier, service identifier, profile hash value, on-chain digital asset certificate, profile registration number, or a unique identifier generated by a smart contract. Upon receiving a profile migration request, the migration management module, based on the target profile's identification information, determines the registration information, user identifier, operator identifier, ownership status, and migration status associated with the target profile in the blockchain network.

[0085] In one implementation, the configuration file migration request further includes a target operator identifier, a target device identifier, and user authorization information. The target operator identifier is used to determine the target operator node the user wishes to migrate to. The target device identifier is used to determine the target device that the new configuration file needs to be bound to after migration. The target device identifier can be the EID of the target device. The user authorization information can be a user digital signature, a user authorization token, or a user certificate. The user digital signature is data obtained by the user terminal signing the data to be signed using the user's private key. The data to be signed includes at least one of the following: the identifier information of the target configuration file, the target operator identifier, the target device identifier, and the user identifier information. The user terminal signs the data to be signed using its private key, enabling the migration management module to verify the authenticity of the configuration file migration request source and the lack of tampering with its content based on the user's public key, and to confirm that the user terminal has migration authorization for the target configuration file.

[0086] In one implementation, the configuration file migration request may further include a request timestamp, a random number, a migration scenario identifier, a source operator identifier, target device capability information, or user service information. The request timestamp and random number are used to prevent replay attacks. The migration scenario identifier is used to distinguish between individual user number portability migration, bulk migration of IoT devices, temporary configuration file migration, or cross-border eSIM service migration. User service information is used to assist source and target operator nodes in performing service verification.

[0087] Step S102: Verify the configuration file migration request based on the smart contract. After successful verification, send a release notification to the source operator node.

[0088] Here, after receiving a configuration file migration request, the migration management module invokes a smart contract to execute migration verification logic, verifying the configuration file migration request. The migration verification logic includes at least one of authentication, permission verification, status verification, and target operator verification. Authentication confirms that the configuration file migration request was initiated by a legitimate user terminal. Permission verification confirms that the user terminal has migration permissions for the target configuration file. Status verification confirms that the target configuration file is in a migration-allowed state, such as not being in a migrated state, a frozen state, a deregistered state, or an abnormally locked state. Target operator verification confirms that the target operator node meets preset operator conditions, such as the target operator node being connected to the blockchain network, the target operator node having service permissions to receive eSIM configuration files, and the operator identifier corresponding to the target operator node being legitimate and valid.

[0089] In one implementation, the migration management module queries the ownership and migration status of the target configuration file based on its identification information, verifies the user terminal's migration permissions based on user authorization information, determines the target operator node based on the target operator identifier, and verifies whether the target operator node meets preset operator conditions. If the ownership status, migration status, migration permissions, and target operator node all meet the preset migration conditions, the migration management module determines that the configuration file migration request has been verified.

[0090] After the configuration file migration request is verified, the migration management module determines the operator node currently holding the target configuration file based on its identification information and ownership status, and designates this operator node as the source operator node. The migration management module generates a migration service identifier corresponding to the configuration file migration request and writes the target configuration file's identification information, the target operator's identifier, the target device's identifier, and the migration service identifier into the blockchain network. The migration service identifier is used to identify the same migration service during subsequent processes such as release confirmation, data addressing credential submission, notification download, confirmation receipt, and ownership status update.

[0091] A release notification is used to inform the source operator node to prepare for the release of the target configuration file. The release notification can be sent via smart contract events, on-chain transaction messages, off-chain notification messages, or interface messages between the blockchain network and the operator's business system. The release notification may include at least one of the following: the target configuration file's identification information, the migration service identifier, the target operator identifier, the target device identifier, the target operator node's public key information, release conditions, and the release deadline. Upon receiving the release notification, the source operator node can perform business review of the target configuration file, release confirmation, configuration data encryption, and data addressing credential generation based on the release notification.

[0092] If the configuration file migration request fails verification, the migration management module rejects the request and records the reason for the failure to the blockchain network. Reasons for failure include invalid user authorization, the target configuration file not existing, the target configuration file's state not allowing migration, an illegitimate target operator node, or an illegitimate target device identifier.

[0093] Step S103: Receive release confirmation information and data addressing credentials returned by the source operator node; wherein, the data addressing credentials are used by the target operator node to obtain encrypted configuration data corresponding to the target configuration file.

[0094] Here, the release confirmation process includes verifying the migration service identifier, verifying the identifier information of the target configuration file, confirming whether the target configuration file can be released, generating release confirmation information, obtaining the public key information corresponding to the target operator node, encrypting the configuration data corresponding to the target configuration file, and generating data addressing credentials.

[0095] The release confirmation message indicates that the source operator node has completed the release confirmation for the target configuration file. The release confirmation message may include the source operator node identifier, the target configuration file's identifier, the migration service identifier, the release status, the release time, and the source operator node signature or release confirmation digest. The source operator node signature proves that the release confirmation message was issued by the source operator node and prevents the release confirmation message from being tampered with.

[0096] The encrypted configuration data is obtained by encrypting the configuration data corresponding to the target configuration file using the source operator node. In one implementation, the source operator node performs asymmetric encryption on the configuration data corresponding to the target configuration file based on the public key information of the target operator node, obtaining encrypted configuration data. The target operator node then decrypts the encrypted configuration data using its private key information. Therefore, only the target operator node can decrypt the encrypted configuration data, improving the security of configuration data during cross-operator transfers. In another implementation, the source operator node can encrypt the configuration data based on a session key and then encrypt the session key using the public key information of the target operator node, enabling the target operator node to first decrypt the session key and then decrypt the encrypted configuration data based on the session key.

[0097] After generating encrypted configuration data, the source operator node stores the encrypted configuration data in a storage location accessible to the target operator node. This storage location can be a distributed storage system, the storage system corresponding to the source operator node, an operator-side data server, or a storage system capable of providing data access. The source operator node generates a data addressing credential based on the storage location of the encrypted configuration data and returns the data addressing credential to the migration management module. The data addressing credential can include at least one of the following: storage address, content hash, download address, or data access credential. The data addressing credential may also include an access validity period, data digest, access permission information, or encrypted data version information.

[0098] After receiving the release confirmation information and data addressing credential from the source operator node, the migration management module verifies the release confirmation information. The module verifies whether the release confirmation information matches the source operator node, whether the migration service identifier in the release confirmation information matches the migration service identifier corresponding to the configuration file migration request, and whether the data addressing credential is associated with the identifier information of the target configuration file. Upon successful verification, the migration management module associates the identifier information of the target configuration file, the node identifier corresponding to the target operator node, the data addressing credential, and the release confirmation information, and writes the associated record as a release record to the blockchain network. Therefore, the blockchain network does not need to store the complete encrypted configuration data; instead, it records the data addressing credential and release record, reducing the storage pressure and privacy risks associated with directly uploading the complete configuration data to the blockchain.

[0099] Step S104: Send a download notification carrying a data addressing credential to the target operator node so that the target operator node can download and decrypt the encrypted configuration data based on the data addressing credential.

[0100] Here, after receiving the release confirmation information and data addressing credential, and writing the release record, the migration management module sends a download notification carrying the data addressing credential to the target operator node. The download notification is used to notify the target operator node to obtain the encrypted configuration data corresponding to the target configuration file. The download notification can be sent via smart contract events, on-chain transaction messages, off-chain notification messages, or interface messages between the blockchain network and the target operator's business system.

[0101] The download notification may include at least one of the following: target configuration file identification information, migration service identifier, data addressing credential, source operator node identifier, target device identifier, encrypted configuration data digest, access validity period, and binding requirements. Upon receiving the download notification, the target operator node accesses the corresponding storage location based on the data addressing credential and downloads the encrypted configuration data. After downloading the encrypted configuration data, the target operator node can perform integrity verification on the downloaded encrypted configuration data based on the encrypted configuration data digest in the download notification or the content hash in the data addressing credential. If the integrity verification passes, the target operator node decrypts the encrypted configuration data based on its corresponding private key information to obtain the configuration data.

[0102] The target operator node generates a new configuration file based on the decrypted configuration data and binds the new configuration file to the target device corresponding to the target device identifier. In one implementation, the new configuration file retains the user's original mobile phone number MSISDN (Mobile International Subscriber Number). In another implementation, the new configuration file can generate new service parameters according to the target operator node's service rules. After completing the generation of the new configuration file and binding to the target device, the target operator node generates a receipt confirmation message and returns the receipt confirmation message to the migration management module.

[0103] In the event of a download or decryption failure, the target operator node can return a reception failure message to the migration management module. This message may include the reason for the failure, the time of failure, the migration service identifier, and the target operator node's signature. The migration management module can update the migration status based on this message or trigger the source operator node to resubmit the data addressing credentials.

[0104] Step S105: Receive the acceptance confirmation information returned by the target operator node and update the ownership status of the target configuration file.

[0105] Here, the migration management module receives a reception confirmation message from the target operator node. This confirmation message indicates that the target operator node has received the encrypted configuration data corresponding to the target configuration file, completed the decryption process, or completed the generation of a new configuration file and binding it to the target device. The confirmation message may include at least one of the following: target operator confirmation information, new configuration file summary information, binding status information, target operator node signature, migration service identifier, and reception time. The new configuration file summary information indicates that the target operator node has generated a new configuration file based on the decrypted configuration data. The binding status information indicates the binding result between the new configuration file and the target device corresponding to the target device identifier.

[0106] After receiving the confirmation message, the migration management module verifies it. The module verifies whether the target operator's confirmation message matches the target operator's node, whether the migration service identifier in the confirmation message matches the migration service identifier corresponding to the configuration file migration request, whether the confirmation message corresponds to the release confirmation message and data addressing credential, and whether the binding status information indicates successful binding. After all verifications are successful, the migration management module records the new configuration file summary information and binding status information to the blockchain network.

[0107] After confirming that it has received release confirmation information from the source operator node and reception confirmation information from the target operator node, the migration management module updates the ownership status of the target configuration file. The migration management module updates the ownership status between the target configuration file and the source operator node to a released state, updates the ownership status between the target configuration file or a new configuration file generated based on the target configuration file and the target operator node to a received state, and updates the migration status of the target configuration file to a migrated state. In one implementation, the migration management module can also invalidate the original configuration file identifier associated with the source operator node and generate a new configuration file identifier representing the new configuration file, binding the new configuration file identifier to the target operator node, user identifier information, and target device identifier.

[0108] In one implementation, after updating the ownership status of the target configuration file, the migration management module generates a migration history record corresponding to the target configuration file and writes the migration history record to the blockchain network. The migration history record may include at least one of the following: configuration file migration request, release confirmation information, data addressing credentials, download notification, receipt confirmation information, and ownership status update result. The migration management module can also respond to query requests initiated by the supervisory node, read the migration history record from the blockchain network, and return the migration history record to the supervisory node so that the supervisory node can audit the migration history record.

[0109] In one implementation, after updating the ownership status of the target configuration file, the migration management module sends a migration completion notification to the user terminal. Upon receiving the notification, the user terminal can request to download the new configuration file from the target operator node and complete its installation and activation within the user terminal's secure area. After activation, the user terminal returns activation confirmation information to the migration management module. The target operator node can also return status update information to the migration management module. Upon receiving both the activation confirmation and status update information, the migration management module updates the activation status of the target configuration file or a new configuration file generated based on it to "activated."

[0110] In one implementation, after the activation status is updated to "activated," the migration management module determines whether preset settlement conditions are met based on release confirmation information, reception confirmation information, and the activation status. If the preset settlement conditions are met, the migration management module generates settlement information between the source operator node and the target operator node, and performs migration settlement processing between the source operator node and the target operator node based on the settlement information. Migration settlement processing can be implemented based on token transfers within the blockchain network, or it can be completed by an off-chain settlement system after the settlement result is recorded on the blockchain network. The migration management module records the settlement status corresponding to the migration settlement processing on the blockchain network.

[0111] In this embodiment, the migration management module, based on a smart contract, links the configuration file migration request verification, source operator node release, data addressing credential transfer, target operator node download and decryption of encrypted configuration data, receipt confirmation, and ownership status update into a closed-loop on-chain process. This method reduces reliance on centralized servers and improves the collaborative efficiency, configuration data security, status update reliability, and migration history trustworthiness and traceability during cross-operator eSIM configuration file migration.

[0112] In an optional implementation, refer to Figure 4 Before step S101, the method further includes the following steps S201-S203.

[0113] Step S201: Receive a configuration file registration request sent by the source operator node; wherein, the configuration file registration request includes the feature information, user identification information and operator identification information of the configuration file to be registered.

[0114] Here, the source operator node sends a configuration file registration request to the migration management module when the configuration file is in the initial activation, initial binding, or pre-migration registration phase. The source operator node is the operator node currently responsible for providing the service for the configuration file to be registered. The configuration file registration request is used to request the migration management module to establish an on-chain registration record for the configuration file to be registered in the blockchain network.

[0115] The characteristic information of the configuration file to be registered is used to characterize the attributes of the configuration file itself. This characteristic information may include at least one of the following: configuration file hash value, configuration file digest value, configuration file version information, configuration file type, configuration file status, business operation identifier, configuration file generation time, configuration file validity period, or service capability information corresponding to the configuration file. The configuration file hash value or configuration file digest value is used to characterize the configuration file to be registered without disclosing the complete configuration file data, thus avoiding privacy leaks and on-chain storage pressure caused by directly writing the complete configuration file data to the blockchain network.

[0116] User identification information is used to identify the user corresponding to the configuration file to be registered. User identification information can be the user's public key, user account address, user identity digest, user service number, or a de-identified user identifier. The user's public key is used to subsequently verify the user's authorization information in the configuration file migration request sent by the user terminal. Carrier identification information is used to identify the carrier currently holding the configuration file to be registered. Carrier identification information can be the carrier node identifier, carrier service code, carrier on-chain address, or carrier certificate identifier. After receiving the configuration file registration request, the migration management module can determine the source carrier node initiating the registration based on the carrier identification information.

[0117] In one implementation, the configuration file registration request may also carry the source operator node signature. After receiving the configuration file registration request, the migration management module first verifies whether the source operator node signature corresponds to the source operator node. Only after successful verification will the subsequent identification information generation steps be executed. Based on this, the migration management module can confirm the credibility of the configuration file registration request source, reducing the risk of unauthorized nodes forging registration requests.

[0118] Step S202: Based on the configuration file registration request, generate the identification information corresponding to the configuration file to be registered.

[0119] Here, the migration management module generates identification information corresponding to the configuration file to be registered based on the feature information, user identification information, and operator identification information of the configuration file to be registered in the configuration file registration request. This identification information is used to uniquely identify the configuration file to be registered in the blockchain network and serves as the identification information of the target configuration file in the configuration file migration request.

[0120] In one implementation, the migration management module generates identification information corresponding to the configuration file to be registered by calling the registration interface in the smart contract. The registration interface can generate unique identification information based on the configuration file hash value, user public key, operator identification information, business operation identifier, and on-chain transaction information. This identification information can serve as an on-chain digital asset certificate for the configuration file to be registered, representing the registration object and ownership object of the configuration file in the blockchain network.

[0121] In another implementation, the identification information corresponding to the configuration file to be registered can be generated based on a preset numbering rule. The preset numbering rule combines operator identification information, configuration file digest value, registration time, and a random number, and obtains the identification information through hashing. By introducing the registration time and a random number, the probability of duplicate identification information between different configuration files can be reduced. By introducing the configuration file digest value, a stable association can be formed between the identification information and the configuration file to be registered.

[0122] After generating the identification information corresponding to the configuration file to be registered, the migration management module can set the initial migration status of the configuration file to "not migrated" and the initial ownership status to either belong to the source operator node or to the service relationship between the user and the source operator node. When a user terminal subsequently initiates a migration, the migration management module queries the initial registration record, ownership status, and migration status based on the identification information of the target configuration file.

[0123] Step S203: Record the correspondence between the identification information, user identification information and operator identification information corresponding to the configuration file to be registered to the blockchain network.

[0124] Here, the migration management module writes the correspondence between the identifier information, user identifier information, and operator identifier information corresponding to the configuration file to be registered into the blockchain network. This correspondence represents the on-chain binding relationship between the configuration file to be registered and the user and current operator. After the correspondence is written into the blockchain network, the migration management module can determine the user and source operator node currently corresponding to the target configuration file based on the records in the blockchain network.

[0125] In one implementation, the migration management module also associates one or more of the following characteristics of the configuration file to be registered, registration time, registration transaction identifier, source operator node signature, initial ownership status, and initial migration status with the identifier information corresponding to the configuration file to be registered and records them on the blockchain network. The registration transaction identifier is used to mark this registration operation. The source operator node signature is used to prove that the registration record was initiated by the source operator node. The initial ownership status is used to characterize the ownership relationship of the configuration file to be registered after registration. The initial migration status is used to characterize whether the configuration file to be registered has undergone cross-operator migration.

[0126] In one implementation, the smart contracts deployed in the blockchain network include a migration management contract and an ownership registration contract. The migration management module records the correspondence between the identifier information, user identifier information, and operator identifier information corresponding to the configuration file to be registered through the ownership registration contract. During subsequent migration processes, the migration management contract reads the registration records in the ownership registration contract and performs configuration file migration request verification, source operator node determination, target operator node determination, and ownership status update based on the registration records. The migration management contract and the ownership registration contract can be deployed separately or implemented as different functional logic within the same smart contract.

[0127] In an optional implementation, the configuration file migration request may also include the target carrier identifier, the target device identifier, and user authorization information.

[0128] Here, the target carrier identifier indicates the carrier the user wishes to migrate to. The target device identifier indicates the user terminal or target device that needs to be bound after the new profile migration is complete. User authorization information proves that the user terminal has the authority to initiate this migration. User authorization information can be a user digital signature, a user authorization token, or a user certificate.

[0129] Reference Figure 5 Step S102 includes the following steps S301-S308.

[0130] Step S301: Based on the identification information of the target configuration file, query the ownership status and migration status of the target configuration file in the blockchain network.

[0131] Here, after receiving a configuration file migration request, the migration management module queries the blockchain network for the corresponding on-chain registration record based on the target configuration file's identification information. The on-chain registration record includes the target configuration file's identification information, user identification information, operator identification information, ownership status, and migration status. The target configuration file's ownership status indicates which operator node the target configuration file currently belongs to, or whether it is currently held by the source operator node, received by the target operator node, released, or migrated. The target configuration file's migration status indicates whether cross-operator migration is currently permitted, such as not migrated, migrating, migrated, frozen, canceled, or abnormally locked.

[0132] The migration management module determines the current operator node corresponding to the target configuration file by querying the ownership status. It also determines whether the target configuration file has already been migrated or is currently in the migration process by querying the migration status. If the target configuration file has no on-chain registration record, the migration management module determines that the configuration file migration request does not meet the verification conditions. If the target configuration file is already in a migrated, frozen, deregistered, or abnormally locked state, the migration management module determines that the target configuration file does not meet the migration conditions.

[0133] Step S302: Based on the user authorization information, verify whether the user terminal has migration permissions for the target configuration file.

[0134] Here, the migration management module verifies whether the user terminal has migration permissions based on the user authorization information in the configuration file migration request. When the user authorization information is a user digital signature, the migration management module verifies the user digital signature based on the user's public key or user account address recorded in the blockchain network. After successful verification, the migration management module confirms that the configuration file migration request was initiated by a legitimate user terminal and confirms that the configuration file migration request has not been tampered with during transmission.

[0135] In one implementation, the migration management module compares the user identifier corresponding to the user authorization information with the user identifier information registered in the target configuration file chain. If they match, the migration management module determines that the user terminal has migration permissions for the target configuration file. If they do not match, the migration management module determines that the user terminal does not have migration permissions for the target configuration file.

[0136] In another implementation, user authorization information includes the authorization validity period, request timestamp, and random number. The migration management module verifies the authorization validity period, request timestamp, and random number to prevent expired authorizations or duplicate requests from being reused. Thus, the migration management module can reduce the risk of forged migration requests, replayed migration requests, or unauthorized users initiating migrations.

[0137] Step S303: Determine the target operator node based on the target operator identifier, and verify whether the target operator node meets the preset operator conditions.

[0138] Here, the migration management module queries the corresponding operator node registration information in the blockchain network based on the target operator identifier in the migration request in the configuration file, and determines the target operator node for this migration. The operator node registration information may include the operator node identifier, the operator's on-chain address, the operator's certificate identifier, the operator's public key information, business permission information, and node status information.

[0139] After the migration management module identifies the target operator node, it verifies whether the target operator node meets the preset operator conditions.

[0140] The preset operator conditions may include: (1) the target operator node has been connected to the blockchain network; (2) the target operator node has the service permission to receive eSIM configuration files; (3) the operator certificate corresponding to the target operator node is in a valid state; (4) the target operator node is not in a suspended service state or an abnormal state; (5) the target operator node can provide public key information for encrypting configuration data; (6) the target operator node supports the device type or service type corresponding to the target device identifier.

[0141] In one implementation, the migration management module further verifies whether the target operator node can provide configuration file services to the target device based on the target device identifier. When the target device identifier is the target device's EID, the migration management module can match the EID with the device range or service policies supported by the target operator node. Through this verification process, the migration management module can avoid migrating the target configuration file to operator nodes that do not have the ability to receive it or are not qualified to provide the service.

[0142] Step S304: If the ownership status, migration status, migration permissions, and target operator node all meet the preset migration conditions, the configuration file migration request is verified as successful.

[0143] Here, the preset migration conditions include: the target configuration file's ownership status is valid; the target configuration file's migration status allows migration; the user terminal has migration permissions; and the target operator node meets the preset operator conditions. When all verification results meet the preset migration conditions, the migration management module determines that the configuration file migration request has been verified successfully.

[0144] In one implementation, a valid ownership status means that the target configuration file has been registered on-chain and currently belongs to a source operator node. A migration status that allows migration means that the target configuration file is in a non-migration state or a state that allows initiating migration. Valid migration permissions mean that the user authorization information has been verified and the user identifier corresponding to the user authorization information matches the user identifier information in the target configuration file registration record. A target operator node that meets preset operator conditions means that the target operator node is legal, valid, and has the ability to receive configuration files.

[0145] If any verification result fails to meet the preset migration conditions, the migration management module will no longer send a release notification to the source operator node. The migration management module can generate verification failure records and write them to the blockchain network. Verification failure records may include the target configuration file's identification information, the reason for the verification failure, the request time, and the user terminal identifier.

[0146] Step S305: Determine the source operator node currently holding the target configuration file based on the identification information and ownership status of the target configuration file.

[0147] Here, after the configuration file migration request is verified, the migration management module determines the operator node currently holding the target configuration file based on its identification information and ownership status, and designates this operator node as the source operator node. The source operator node is the node that needs to release the target configuration file during this migration process.

[0148] In one implementation, the migration management module reads the on-chain registration record corresponding to the target configuration file based on the identification information of the target configuration file, and determines the source operator node based on the operator identification information in the on-chain registration record.

[0149] In another implementation, the migration management module determines the source operator node based on the operator's on-chain address recorded in the current ownership state of the target configuration file. If there is an inconsistency between the on-chain registration record and the ownership state record, the migration management module can pause the migration process and generate a status anomaly record. This approach reduces the migration risks caused by erroneous releases, duplicate releases, or inconsistencies in status.

[0150] Step S306: Generate the migration service identifier corresponding to the configuration file migration request.

[0151] Here, the migration management module generates a migration service identifier for this configuration file migration request. The migration service identifier is used throughout the same migration process for request verification, release notification, release confirmation, data addressing credential submission, download notification, receipt confirmation, ownership status update, migration history, and settlement status recording.

[0152] The migration service identifier can be generated based on the identifier information in the target configuration file, the target operator identifier, the target device identifier, the user identifier, the request time, a random number, and on-chain transaction information. The migration management module can generate the migration service identifier through hash processing, numbering rules, or internal smart contract counting. After the migration service identifier is generated, both the source operator node and the target operator node will carry the migration service identifier when subsequently returning release confirmation information, data addressing credentials, and receiving confirmation information. The migration management module associates on-chain interaction records within the same migration process based on the migration service identifier, avoiding record confusion between different migration processes.

[0153] Step S307: Write the target configuration file's identification information, target operator identification, target device identification, and migration service identification into the blockchain network.

[0154] Here, the migration management module writes the basic information of this migration process into the blockchain network. This basic information includes the target configuration file's identifier, the target operator's identifier, the target device's identifier, and the migration service identifier. The target configuration file's identifier is used to identify the migration target. The target operator's identifier is used to identify the destination party. The target device's identifier is used to identify the new device that needs to be bound after the migration. The migration service identifier is used to mark this migration process.

[0155] In one implementation, the migration management module also writes a summary of the user authorization information, the time the configuration file migration request was received, the request verification result, the source operator node identifier, and the target operator node identifier into the blockchain network. The summary of the user authorization information is used to preserve authorization credentials without exposing the complete authorization data. The request verification result indicates that the configuration file migration request has been verified by the smart contract. The source operator node identifier and the target operator node identifier are used to identify the two nodes involved in this migration process.

[0156] Step S308: Send a release notification carrying the identification information of the target configuration file and the migration service identifier to the source operator node.

[0157] Here, the release notification carries the identification information of the target configuration file and the migration service identifier. The target configuration file identification information is used to enable the source operator node to determine the configuration file that needs to be released. The migration service identifier is used to enable the source operator node to associate the release confirmation information, data addressing credentials, and subsequent service processing results with this migration process.

[0158] In one implementation, the release notification may also carry the target operator identifier, target device identifier, public key information of the target operator node, release conditions, release deadline, and smart contract event identifier. The public key information of the target operator node is used to enable the source operator node to encrypt the configuration data corresponding to the target configuration file. The release deadline limits the time range within which the source operator node completes the release confirmation. The smart contract event identifier enables the source operator node to listen for release events in the blockchain network and execute local business processing based on the release events.

[0159] Release notifications can be sent via smart contract events in the blockchain network, on-chain transaction messages, or interface messages between the blockchain network and the operator's business system. Upon receiving the release notification, the source operator node performs business-level release confirmation on the target configuration file, encrypts the configuration data corresponding to the target configuration file based on the public key information of the target operator node, generates encrypted configuration data, and returns release confirmation information and data addressing credentials to the migration management module.

[0160] In this embodiment, the migration management module verifies the target configuration file status, user migration permissions, and target operator node conditions before triggering the release of the target configuration file by the source operator node, and writes the basic information of this migration process into the blockchain network. This process improves the credibility of configuration file migration requests and the controllability of the migration process, reducing the risks of unauthorized migration, erroneous release, and inconsistencies in cross-operator collaborative states.

[0161] In an optional implementation, the encrypted configuration data is the data obtained by the source operator node encrypting the configuration data corresponding to the target configuration file based on the public key information corresponding to the target operator node.

[0162] Reference Figure 6 Step S103 includes the following steps S401-S406.

[0163] Step S401: Receive release confirmation information returned by the source operator node based on the release notification.

[0164] Here, after receiving the release notification from the migration management module, the source operator node determines the target configuration file to be released in this migration process based on the identifier information of the target configuration file and the migration service identifier carried in the release notification. The source operator node performs a business-level release confirmation of the target configuration file. The business-level release confirmation includes verifying whether the target configuration file exists, whether the target configuration file is currently held by the source operator node, whether the target configuration file is allowed to be released, whether the migration service identifier is valid, and whether the target operator node corresponds to the target operator identifier in the release notification.

[0165] After the source operator node completes the release confirmation, it generates release confirmation information and returns it to the migration management module. The release confirmation information indicates that the source operator node agrees to perform the release operation on the target configuration file. The release confirmation information may include at least one of the following: source operator node identifier, target configuration file identifier, migration service identifier, release status, release time, source operator node signature, and release confirmation digest. The source operator node signature proves that the release confirmation information was generated by the source operator node, and the release confirmation digest is used to verify the content of the release confirmation information.

[0166] In one implementation, before returning the release confirmation information, the source operator node encrypts the configuration data corresponding to the target configuration file based on the public key information of the target operator node, obtaining encrypted configuration data. After encryption using the public key information of the target operator node, only the target operator node holding the corresponding private key information can decrypt the encrypted configuration data, thereby reducing the risk of unauthorized reading of the configuration data during cross-operator transfers.

[0167] Step S402: Receive data addressing credentials submitted by the source operator node; wherein, the data addressing credentials include at least one of storage address, content hash, download address, or data access credentials.

[0168] Here, after the source operator node generates encrypted configuration data, it stores the encrypted configuration data in a storage location accessible to the target operator node, and generates a data addressing credential based on the storage location of the encrypted configuration data. The data addressing credential is used to instruct the target operator node to retrieve the encrypted configuration data. The storage location can be a distributed storage system, the storage system corresponding to the source operator node, an operator-side data server, or a storage system capable of providing data access.

[0169] Data addressing credentials include at least one of the following: storage address, content hash, download address, or data access credential. The storage address identifies the storage location of the encrypted configuration data. The content hash verifies the integrity of the encrypted configuration data; after downloading the encrypted configuration data, the target operator node can determine whether the data has been tampered with based on the content hash. The download address allows the target operator node to initiate a download request. Data access credentials restrict the target operator node's access permissions to the encrypted configuration data. Data access credentials may include an access token, access key, access validity period, or access control information.

[0170] In one implementation, the release confirmation message and data addressing credential are submitted to the migration management module by the source operator node in the same on-chain call. In another implementation, the source operator node first submits the release confirmation message, and then submits the data addressing credential after the encrypted configuration data is generated and stored. The migration management module associates the release confirmation message and data addressing credential with the same migration process based on the migration service identifier.

[0171] Step S403: Verify whether the release confirmation information matches the source operator node.

[0172] Here, after receiving the release confirmation information, the migration management module verifies it. The module verifies whether the release confirmation information was sent by the source operator node and whether it matches the target configuration file and migration service identifier in this migration process.

[0173] In one implementation, the release confirmation information includes the source operator node signature. The migration management module verifies the source operator node signature based on the public key information corresponding to the source operator node recorded in the blockchain network. After successful verification, the migration management module confirms that the release confirmation information originates from the source operator node. The migration management module can also verify whether the source operator node identifier in the release confirmation information matches the determined source operator node, whether the identifier information of the target configuration file in the release confirmation information matches the identifier information of the target configuration file in the configuration file migration request, and whether the migration service identifier in the release confirmation information matches the generated migration service identifier.

[0174] In one implementation, the migration management module also checks the release status and release time in the release confirmation information. The release status indicates that the source operator node has completed the release confirmation. The release time is used to determine whether the release confirmation information was returned within a preset valid time range. If the source of the release confirmation information does not match, the migration service identifier is inconsistent, or the release status is abnormal, the migration management module determines that the release confirmation information verification has failed and suspends sending download notifications to the target operator node. The migration management module can write the verification failure reason into the blockchain network for subsequent auditing.

[0175] Step S404: If the release confirmation information matches the source operator node, obtain the node identifier corresponding to the target operator node.

[0176] Here, when the release confirmation information matches the source operator node, the migration management module obtains the node identifier corresponding to the target operator node based on the target operator identifier corresponding to this configuration file migration request. The node identifier corresponding to the target operator node is used to clearly identify the recipient of the encrypted configuration data in the release record, and is also used to send download notifications to the target operator node subsequently.

[0177] The node identifier corresponding to the target operator node can be the on-chain address of the target operator node in the blockchain network, the target operator node number, the target operator node certificate identifier, or the target operator node public key digest. The migration management module can read the node identifier corresponding to the target operator node from the operator node registration record in the blockchain network, or it can determine the node identifier corresponding to the target operator node based on the mapping relationship between the target operator identifier and the target operator node registration information.

[0178] In one implementation, when the migration management module obtains the node identifier corresponding to the target operator node, it also simultaneously reads the public key information or public key digest corresponding to the target operator node. The public key information corresponding to the target operator node is used to verify its consistency with the public key information used by the source operator node when generating encrypted configuration data. If the public key information is inconsistent, the migration management module generates an error message and suspends the subsequent download notification sending process.

[0179] Step S405: Associate the identification information of the target configuration file, the node identifier corresponding to the target operator node, the data addressing certificate, and the release confirmation information.

[0180] Here, the migration management module associates the target configuration file's identifier, the node identifier corresponding to the target operator node, the data addressing credential, and the release confirmation information to form a release record corresponding to this migration process. The target configuration file's identifier indicates the release target. The node identifier corresponding to the target operator node indicates the receiving target. The data addressing credential indicates the method for obtaining the encrypted configuration data. The release confirmation information proves that the source operator node has confirmed the release of the target configuration file.

[0181] In one implementation, the migration management module also associates the migration service identifier, source operator node identifier, release time, data digest, access validity period, release status, and verification result. The migration service identifier is used to associate the release record with the configuration file migration request, download notification, received confirmation information, and ownership status update result. The source operator node identifier identifies the releasing party. The data digest verifies the integrity of the encrypted configuration data. The access validity period limits the time range within which the target operator node can obtain the encrypted configuration data. The verification result records whether the release confirmation information has been verified successfully.

[0182] Step S406: Write the associated record as a release record into the blockchain network.

[0183] Here, the migration management module writes the associated record as a release record to the blockchain network. After the release record is written to the blockchain network, it becomes the on-chain state record in this configuration file migration process. The release record serves to prove that the source operator node has completed the release confirmation for the target configuration file and has provided data addressing credentials for the target operator node to obtain the encrypted configuration data.

[0184] The release record may include at least one of the following: target configuration file identifier, migration service identifier, source operator node identifier, node identifier corresponding to the target operator node, release confirmation information, data addressing credential, data digest, release status, release time, and on-chain transaction identifier. The on-chain transaction identifier is used to mark the transaction in which the release record is written to the blockchain network. After the release record is written to the blockchain network, the migration management module sends a download notification carrying the data addressing credential to the target operator node based on the release record.

[0185] In one implementation, when the release record is written to the blockchain network, the blockchain network does not write the complete encrypted configuration data, but instead writes a data addressing credential, a data digest, and state information. The target operator node retrieves the encrypted configuration data from the corresponding storage location based on the data addressing credential. Therefore, the storage of the complete configuration data is separated from the on-chain state record, which reduces the on-chain storage burden and improves the privacy protection of the configuration data.

[0186] In this embodiment, the migration management module can record the release confirmation process of the source operator node on the blockchain and reliably transmit the method for obtaining encrypted configuration data to the subsequent receiving process. This process establishes a verifiable correspondence between the source operator node releasing the target configuration file, the target operator node obtaining the encrypted configuration data, and the migration management module updating the migration status, which helps improve data security, state consistency, and traceability of the cross-operator eSIM configuration file migration process.

[0187] In an optional implementation, the confirmation information received includes target operator confirmation information, new profile summary information, and binding status information.

[0188] Here, the confirmation message is used to prove that the target operator node has obtained the encrypted configuration data according to the download notification and has completed the receiving process such as decryption, new configuration file generation, and target device binding.

[0189] Reference Figure 7 In step S105, the target operator node returns a confirmation message, which includes the following steps S501-S504.

[0190] Step S501: Receive the target operator confirmation information returned by the target operator node based on the download notification.

[0191] Here, after receiving the download notification from the migration management module, the target operator node retrieves the encrypted configuration data based on the data addressing credentials carried in the download notification. After completing the download, integrity verification, or preparation for receiving the encrypted configuration data, the target operator node returns target operator confirmation information to the migration management module. This confirmation information indicates that the target operator node has responded to the download notification and confirmed its participation in the receiving process corresponding to the target configuration file.

[0192] The target operator confirmation information includes at least one of the following: target operator node identifier, migration service identifier, target configuration file identifier, reception status, reception time, target operator node signature, and confirmation message digest. The target operator node identifier identifies the node sending the target operator confirmation information. The migration service identifier associates the target operator confirmation information with this configuration file migration process. The target configuration file identifier indicates the configuration file object received by the target operator node. The reception status indicates that the target operator node has received the download notification, obtained the encrypted configuration data, or completed reception preparation. The target operator node signature proves that the target operator confirmation information was generated by the target operator node and prevents tampering with the target operator confirmation information.

[0193] In one implementation, the target operator node accesses the storage location corresponding to the encrypted configuration data based on data addressing credentials, and performs integrity verification on the downloaded encrypted configuration data according to the content hash or data digest. Upon successful integrity verification, the target operator node generates target operator confirmation information.

[0194] In another implementation, the target operator node first returns target operator confirmation information, and then performs encrypted configuration data download and decryption processing. The migration management module associates the target operator confirmation information with the download notification, release record, and configuration file migration request based on the migration service identifier.

[0195] Step S502: Receive new configuration file summary information and binding status information submitted by the target operator node; wherein, the new configuration file summary information is used to characterize the new configuration file generated by the target operator node based on the configuration data obtained after decrypting the encrypted configuration data, and the binding status information is used to characterize the binding result between the new configuration file and the target device corresponding to the target device identifier.

[0196] Here, the target operator node uses its private key to decrypt the encrypted configuration data, obtaining the configuration data. Based on the decrypted configuration data, the target operator node generates a new configuration file and binds it to the target device corresponding to the target device identifier. The target device identifier can be the target device's EID. After completing the new configuration file generation and target device binding, the target operator node submits a summary of the new configuration file and binding status information to the migration management module.

[0197] The new configuration file summary information is used to characterize the new configuration file without exposing the complete new configuration file data. The new configuration file summary information may include at least one of the following: new configuration file hash value, new configuration file summary value, new configuration file version information, new configuration file generation time, new configuration file identifier, or receiving credentials generated by the target operator node.

[0198] Binding status information is used to characterize the binding result between the new configuration file and the target device. Binding status information may include at least one of the following: target device identifier, binding success status, binding time, target operator node signature, binding service number, or binding result summary. When the binding status information is "binding successful," the migration management module can confirm that the target operator node has established a correspondence between the new configuration file and the target device. When the binding status information is "binding failed," the binding status information may include the reason for the failure, such as target device identifier mismatch, target device not supporting the new configuration file, decryption failure, or service verification failure.

[0199] In one implementation, the target operator node retains the user's original MSISDN when generating the new configuration file, allowing the user to continue using their original communication number after cross-operator migration. In another implementation, the target operator node configures new service parameters for the new configuration file according to its own service rules and binds the new configuration file to the target device corresponding to the target device identifier. After completing the generation and binding of the new configuration file, the target operator node submits the new configuration file summary information and binding status information to the migration management module, without needing to write the complete new configuration file data to the blockchain network.

[0200] Step S503: Verify whether the target operator confirmation information matches the target operator node.

[0201] Here, the migration management module verifies the target operator confirmation information. The module verifies whether the target operator confirmation information was issued by the target operator node and whether it matches the target operator node, target configuration file, and migration service identifier in this migration process.

[0202] In one implementation, the target operator confirmation information includes the target operator node signature. The migration management module verifies the target operator node signature based on the public key information corresponding to the target operator node recorded in the blockchain network. After successful verification, the migration management module confirms that the target operator confirmation information originates from the target operator node. The migration management module can also verify whether the target operator node identifier in the target operator confirmation information corresponds to the target operator identifier in the configuration file migration request, whether the migration service identifier in the target operator confirmation information is consistent with the current migration service identifier, and whether the identifier information of the target configuration file in the target operator confirmation information is consistent with the identifier information of the target configuration file in the configuration file migration request.

[0203] In one implementation, the migration management module also performs a consistency check on the new configuration file summary information and the binding status information. The migration management module checks whether the new configuration file summary information corresponds to the received result submitted by the target operator node, whether the binding status information corresponds to the target device identifier, and whether the binding status information indicates successful binding. If the target operator confirmation information does not match the target operator node, or if there are inconsistencies between the migration service identifier, the identifier information of the target configuration file, and the target device identifier, the migration management module determines that the verification of the received confirmation information has failed and suspends the subsequent ownership status update process. The migration management module can write the reason for the verification failure to the blockchain network for subsequent auditing.

[0204] Step S504: If the target operator's confirmation information matches the target operator's node, record the new configuration file summary information and binding status information to the blockchain network.

[0205] Here, after confirming that the target operator's confirmation information matches the target operator's node, the migration management module records the new configuration file summary information and binding status information to the blockchain network. The migration management module can associate the new configuration file summary information, binding status information, target operator node identifier, migration service identifier, target configuration file identifier information, and reception time, and write the associated record as a reception record to the blockchain network.

[0206] The reception record serves as proof that the target operator node has completed the reception process corresponding to this migration procedure. The reception record may include at least one of the following: target operator confirmation information, new configuration file summary information, binding status information, target operator node signature, reception time, target device identifier, and on-chain transaction identifier. The on-chain transaction identifier is used to mark the transaction in which the reception record is written to the blockchain network. After the reception record is written to the blockchain network, the migration management module can determine whether the source operator node's release and the target operator node's reception have both been completed based on the reception and release records, and accordingly execute an update to the ownership status of the target configuration file.

[0207] In one implementation, the blockchain network only records the new configuration file summary and binding status information, not the complete new configuration file data. The complete new configuration file data is stored by the target operator node or the corresponding business system, and is downloaded, installed, and activated by the user terminal through the target operator node. Based on this, the blockchain network is used to store trusted summaries and status records, while the operator's business system is used to store the configuration file entity data, thus balancing the traceability of the migration process with the security of the configuration file data.

[0208] This application embodiment uses a migration management module to confirm that the target operator node has completed the reception of encrypted configuration data, the generation of a new configuration file, and the binding of the target device. The module writes the reception result of the target operator node into the blockchain network, making the reception behavior of the target operator node, the digest of the new configuration file, and the binding result of the target device a trusted record. This is beneficial for the migration management module to accurately update the ownership status of the target configuration file and improve the consistency and traceability of the status during the cross-operator eSIM configuration file migration process.

[0209] In an optional implementation, refer to Figure 8 In step S105, the ownership status of the target configuration file is updated, including the following steps S601-S604.

[0210] Step S601: Determine whether the release confirmation information returned by the source operator node and the reception confirmation information returned by the target operator node have been received.

[0211] Here, the migration management module queries the on-chain records corresponding to the current migration process based on the migration service identifier, and determines whether the current migration process has met the conditions for updating the ownership status. The on-chain records include the request record corresponding to the configuration file migration request, the release confirmation information returned by the source operator node, the reception confirmation information returned by the target operator node, the release record, the reception record, and the data addressing credential. The migration management module associates these records with the same migration process based on the migration service identifier, preventing the mixing of confirmation information from different migration processes.

[0212] The release confirmation message proves that the source operator node has agreed to release the target configuration file and has provided data addressing credentials. The reception confirmation message proves that the target operator node has obtained the encrypted configuration data based on the data addressing credentials and completed the reception process. In one implementation, the reception confirmation message also includes new configuration file digest information and binding status information. When determining whether the reception confirmation message has been received, the migration management module can also determine whether the binding status information indicates that the new configuration file has been successfully bound to the target device corresponding to the target device identifier.

[0213] In one implementation, when determining whether release confirmation information and reception confirmation information have been received, the migration management module also verifies whether both release confirmation information and reception confirmation information match the same migration business identifier and the same target configuration file identifier. If any information in the release confirmation information or reception confirmation information is missing, fails verification, or does not match the current migration process, the migration management module does not perform ownership status update. The migration management module can maintain the migration status of the target configuration file as "migration in progress," or record the status as "waiting for confirmation," "reception failure," or "release failure," facilitating subsequent re-triggering, manual processing, or regulatory auditing.

[0214] Step S602: If a release confirmation message and a receipt confirmation message have been received, update the ownership status between the target configuration file and the source operator node to the released status.

[0215] Here, after the migration management module confirms that both the release confirmation information and the receipt confirmation information have been received and verified, the migration management module updates the ownership status between the target configuration file and the source operator node. The released status indicates that the source operator node is no longer the current holder of the target configuration file, and the source operator node has fulfilled its obligation to release the target configuration file in this migration process.

[0216] In one implementation, the migration management module updates the ownership status between the target configuration file and the source operator node from held, active service, or not released to released. The migration management module can also set the original configuration file identifier on the source operator node side to invalid, frozen, or migration completed status to prevent the source operator node from continuing to provide configuration file services to user terminals based on the original configuration file identifier. Therefore, the migration management module can reduce the risk of configuration files being reused or repeatedly migrated.

[0217] In one implementation, the migration management module also records the release status update time, release confirmation message digest, source operator node identifier, and migration service identifier to the blockchain network.

[0218] Step S603: Update the ownership status between the target configuration file or a new configuration file generated based on the target configuration file and the target operator node to the received status.

[0219] Here, the migration management module updates the ownership status between the target configuration file or new configuration file and the target operator node based on the receipt confirmation information returned by the target operator node. The received status indicates that the target operator node has completed the reception and processing of the encrypted configuration data and has the on-chain state foundation to provide new configuration file services to the target device.

[0220] In one implementation, after the target operator node generates a new configuration file based on the encrypted configuration data corresponding to the target configuration file, the migration management module updates the ownership status between the new configuration file and the target operator node to "received." The migration management module can also generate new identification information corresponding to the new configuration file based on the new configuration file's summary information, and associate the new identification information, the target operator node identifier, the user identifier, and the target device identifier in a record. Thus, after the migration is complete, the service object is transferred from the original target configuration file to the new configuration file, and the on-chain records reflect the correspondence between the new configuration file and the target operator node.

[0221] In another implementation, the target configuration file does not generate new on-chain identification information during the migration process. The migration management module directly updates the ownership status between the target configuration file and the target operator node to the "received" status. This method of not generating new on-chain identification information and directly updating the ownership status to "received" is suitable for scenarios where the on-chain identification information of the target configuration file remains consistent before and after the migration, and only the operator ownership status corresponding to the target configuration file changes.

[0222] In one implementation, the migration management module also records the received status update time, received confirmation message digest, new configuration file digest information, binding status information, target operator node identifier, and migration service identifier to the blockchain network. This is used to prove that the target operator node has completed the receiving process and to provide a basis for subsequent activation confirmation, migration history generation, and migration settlement processing.

[0223] Step S604: Update the migration status of the target configuration file to the migrated status.

[0224] Here, the migration management module updates the migration status of the target configuration file to "migrated". The "migrated" status indicates that the ownership change in this cross-carrier migration process has been completed, the target configuration file has been migrated from the source carrier node, and a reception result has been generated on the target carrier node.

[0225] In one implementation, the migration management module updates the migration status of the target configuration file from "not migrated" or "in migration" to "migrated." The migration management module can also record the migration completion time, migration service identifier, source operator node identifier, target operator node identifier, ownership status update result, and on-chain transaction identifier. The migration completion time characterizes the point in time when the migration status change is completed. The on-chain transaction identifier marks the blockchain transaction corresponding to the migration status update operation.

[0226] In one implementation, after the migration status is updated to "migrated," the migration management module can also trigger a migration completion event. The migration completion event notifies the user terminal, source operator node, target operator node, or monitoring node that the ownership status update for this migration process has been completed. Upon receiving the migration completion event, the user terminal can continue with the download, installation, and activation of the new configuration file. The monitoring node can audit the configuration file migration process based on the migration completion event and on-chain state records.

[0227] In this embodiment, after the release confirmation information and the reception confirmation information both meet the requirements, the migration management module updates the ownership status of the source operator node and the target operator node respectively, and updates the migration status of the target configuration file to the migrated status. This creates a clear state linkage relationship between the release of the source operator node, the reception of the target operator node, and the completion of the migration of the target configuration file, which can improve the consistency of the status, the reliability of the ownership transfer, and the traceability of the migration results during the cross-operator eSIM configuration file migration process.

[0228] In an optional implementation, the blockchain network may also include a custodian node.

[0229] Here, oversight nodes are used to query and audit the configuration file migration process recorded in the blockchain network. Oversight nodes typically do not directly participate in configuration file release, encrypted configuration data download, configuration file reception, or ownership status updates. Instead, after the migration process is complete, they verify the completeness of the migration process, the continuity of state changes, and the consistency of confirmation information between the source and target operator nodes based on the migration history formed in the blockchain network. By introducing oversight nodes, the configuration file migration process no longer relies solely on the local records stored by the source operator node, target operator node, or centralized business system, but can be traced based on a unified record within the blockchain network.

[0230] After updating the ownership status of the target configuration file in step S105, the method further includes the following steps S701-S703.

[0231] Step S701: Generate the migration history corresponding to the target configuration file; wherein, the migration history includes at least one of the following: configuration file migration request, release confirmation information, data addressing certificate, download notification, receipt confirmation information, and ownership status update result.

[0232] Here, after updating the ownership status of the target configuration file, the migration management module generates a migration history record corresponding to the target configuration file based on the on-chain interaction information and state change information generated during this migration process. The migration history record is used to represent the process from the user terminal initiating a migration request, to the source operator node confirming the release, to the target operator node confirming the acceptance, and finally the completion of the ownership status update.

[0233] The configuration file migration request records the starting information of this migration process. It includes the target configuration file's identifier, target operator identifier, target device identifier, user authorization information summary, request time, and migration service identifier. The release confirmation information records the source operator node's confirmation of the target configuration file's release. This includes the source operator node identifier, release status, release time, source operator node signature, and migration service identifier. The data addressing credential records the addressing basis for the target operator node to obtain encrypted configuration data. This includes at least one of the following: storage address, content hash, download address, or data access credential. The download notification records the process of the migration management module sending a notification to the target operator node to obtain encrypted configuration data. The reception confirmation information records the target operator node's confirmation of receiving encrypted configuration data, generating a new configuration file, and binding to the target device. The ownership status update result records changes in ownership status between the target configuration file and the source operator node, changes in ownership status between the target configuration file or the new configuration file and the target operator node, and changes in the target configuration file's migration status.

[0234] In one implementation, the migration history may further include at least one of the following: migration service identifier, source operator node identifier, target operator node identifier, target device identifier, migration start time, migration completion time, release record, reception record, activation status, settlement status, and on-chain transaction identifier. The migration service identifier is used to associate multiple stages in the same migration process. The on-chain transaction identifier is used to locate the corresponding write transaction in the blockchain network.

[0235] In one implementation, the migration history does not record complete configuration data, nor does it record complete new configuration file data. Instead, it records a configuration file summary, data addressing credentials, status information, and confirmation information. Thus, the blockchain network can provide trusted traceability while avoiding the direct exposure of complete configuration data on the chain.

[0236] Step S702: Write the migration history into the blockchain network.

[0237] Here, the migration management module writes the migration history into the blockchain network. After the migration history is written into the blockchain network, the blockchain network maintains the migration history based on a consensus mechanism, making the migration history tamper-proof, verifiable, and traceable.

[0238] In one implementation, the migration management module uses the migration business identifier as an index to write the migration history record to the blockchain network. The monitoring node can then query all records corresponding to this migration process based on the migration business identifier. In another implementation, the migration management module uses the target configuration file's identification information as an index to record multiple migration records related to the target configuration file in chronological order on the blockchain network. Based on this, the monitoring node can query the complete historical trajectory of the target configuration file from initial registration to multiple migrations.

[0239] In one implementation, when the migration management module writes the migration history to the blockchain network, it can also perform digest processing on the migration history and store the digest processing result in association with the migration history. The digest processing result is used for subsequent verification of whether the migration history has changed. If any key field in the migration history is tampered with, the digest processing result will change, and the monitoring node can detect anomalies based on the digest processing result.

[0240] In one implementation, after the migration history is written to the blockchain network, the migration management module can also generate a write completion event corresponding to the migration history. The write completion event is used to notify the monitoring node or query terminal that the migration process has resulted in a queryable on-chain record. The write completion event can carry the target configuration file's identification information, the migration business identifier, and the on-chain transaction identifier for easy querying and location.

[0241] In step S703, in response to the query request initiated by the supervisory node, the migration history is read from the blockchain network and returned to the supervisory node so that the supervisory node can audit the migration history.

[0242] Here, when the supervisory node needs to verify the migration process of the target configuration file, it initiates a query request to the migration management module. The query request may carry the identifier information of the target configuration file, the migration service identifier, the user identifier information summary, the source operator node identifier, the target operator node identifier, or the query time range. After receiving the query request, the migration management module reads the corresponding migration history from the blockchain network according to the query conditions carried in the query request and returns the migration history to the supervisory node.

[0243] In one implementation, the migration management module verifies whether the monitoring node has query permissions before responding to a query request. The migration management module determines whether the monitoring node has audit permissions based on the monitoring node identifier, monitoring node certificate, monitoring node signature, or on-chain authorization information. If the monitoring node passes verification, the migration management module returns the migration history corresponding to the query request. If the monitoring node fails verification, the migration management module refuses to return the migration history and records the reason for refusal to the blockchain network.

[0244] After receiving the migration history, the monitoring node audits the history. The audit includes: whether the configuration file migration request was initiated by a legitimate user terminal; whether the source operator node returned release confirmation information; whether the data addressing credentials have been associated with the target configuration file and the target operator node; whether the target operator node returned reception confirmation information; whether the ownership status update result is consistent with the release and reception confirmation information; and whether the migration status of the target configuration file has been updated to "migrated." The monitoring node can also use the migration history to determine if there are any anomalies such as duplicate migrations, illegal migrations, missing status information, inconsistencies between release and reception, or difficulty in confirming migration responsibility.

[0245] In one implementation, the monitoring node can also query the complete migration trajectory of the target configuration file based on its identification information. The complete migration trajectory includes the target configuration file's initial registration record, current migration history, and previous migration records. Based on this, the monitoring node can continuously audit the flow of the target configuration file between different operator nodes.

[0246] This application embodiment generates a migration history record after the ownership status of the target configuration file is updated through the migration management module, and writes the migration history record into the blockchain network. This enables regulatory nodes to audit the migration process based on the on-chain records, thereby improving the transparency, reliability, and traceability of the cross-carrier eSIM configuration file migration process and reducing the risks of tampering with the migration process, difficulty in confirming migration responsibility, and illegal transfer of configuration files.

[0247] In an optional implementation, after updating the ownership status of the target configuration file in step S105, the method further includes the following steps S801-S804.

[0248] Step S801: Send a migration completion notification to the user terminal.

[0249] Here, after the ownership status of the target configuration file is updated, the migration management module sends a migration completion notification to the user terminal. The migration completion notification informs the user terminal that the source operator node release process, the target operator node reception process, and the target configuration file ownership status update process have been completed, and the user terminal can continue to execute the new configuration file download, installation, or activation process.

[0250] The migration completion notification may include at least one of the following: target configuration file identification information, migration service identification, target operator identification, target device identification, new configuration file summary information, service address of the target operator node, activation guidance information, and migration completion time. The target configuration file identification information enables the user terminal to identify the migration target corresponding to this notification. The migration service identification is used by the user terminal to match the migration completion notification with the previously initiated configuration file migration request. The target operator identification indicates the service provider after the migration is completed. The new configuration file summary information enables the user terminal to verify whether the subsequently downloaded new configuration file is consistent with the received result submitted by the target operator node.

[0251] In one implementation, the migration completion notification is sent to the user terminal via a smart contract event in the blockchain network. After receiving the migration completion event, the user terminal initiates the local configuration file processing flow.

[0252] In another implementation, the migration completion notification is sent to the user terminal via an interface message between the blockchain network and the user terminal application. Upon receiving the migration completion notification, the user terminal initiates a new configuration file download request to the target operator node via the LPA, and then performs the installation and activation of the new configuration file within the user terminal's secure zone.

[0253] Step S802: Receive activation confirmation information returned by the user terminal.

[0254] Here, after the user terminal completes the installation and activation of the new configuration file, it returns activation confirmation information to the migration management module. The activation confirmation information indicates that the user terminal has completed the activation of the new configuration file. The activation confirmation information may include at least one of the following: migration service identifier, target configuration file identifier, new configuration file summary information, target device identifier, activation status, activation time, user terminal signature, and activation result summary.

[0255] In one implementation, after receiving the migration completion notification, the user terminal downloads a new configuration file from the target operator node via LPA. The user terminal installs the new configuration file into its secure area and activates it. After activation, the user terminal generates activation confirmation information and signs it based on its corresponding signature information. Upon receiving the activation confirmation information, the migration management module associates it with the current migration process based on the migration service identifier.

[0256] In one implementation, after receiving the activation confirmation information, the migration management module further verifies the activation confirmation information. The migration management module can verify whether the user terminal signature is valid, whether the target device identifier in the activation confirmation information matches the target device identifier in the configuration file migration request, and whether the new configuration file digest information matches the new configuration file digest information submitted by the target operator node. Based on this, the migration management module can confirm that the new configuration file activated on the user terminal side corresponds to the new configuration file received and generated by the target operator node.

[0257] Step S803: Receive status update information returned by the target operator node.

[0258] Here, after confirming that the user terminal has completed the download, installation, or activation of the new configuration file, the target operator node returns status update information to the migration management module. This status update information indicates that the target operator node has completed the new configuration file service activation, device binding update, or activation status synchronization. The status update information may include one or more of the following: target operator node identifier, migration service identifier, new configuration file summary information, target device identifier, service activation status, binding status, activation status, status update time, and target operator node signature.

[0259] In one implementation, after receiving a new configuration file download request initiated by a user terminal via LPA, the target operator node sends the new configuration file to the user terminal and records the binding relationship between the new configuration file and the target device identifier in the corresponding business system of the target operator node. After confirming that the new configuration file has been downloaded or activated, the target operator node returns status update information to the migration management module. Based on the status update information, the migration management module confirms that the new configuration file status on the target operator node side has been synchronized.

[0260] In one implementation, after receiving the status update information, the migration management module can further verify whether the target operator node signature is valid, whether the migration service identifier in the status update information is consistent with the current migration process, whether the target device identifier in the status update information is consistent with the target device identifier in the configuration file migration request, and whether the new configuration file digest information in the status update information is consistent with the new configuration file digest information in the received confirmation information. If the status update information verification fails, the migration management module can maintain the active state as pending confirmation and record the status exception information.

[0261] Step S804: Upon receiving activation confirmation information and status update information, update the activation status of the target configuration file or a new configuration file generated based on the target configuration file to the activated status.

[0262] Here, the migration management module identifies whether it has received activation confirmation information from the user terminal and status update information from the target operator node. If both activation confirmation information and status update information have been received, and both match the same migration service identifier, the same target device identifier, and the same new configuration file summary information, the migration management module updates the activation status of the target configuration file or the new configuration file generated based on the target configuration file to "activated".

[0263] In one implementation, when the new configuration file has new identification information in the blockchain network, the migration management module updates the activation status of the new configuration file to "activated" and records the new identification information, target operator node identifier, target device identifier, activation time, and migration service identifier in the blockchain network. In another implementation, when the target configuration file uses the same identification information before and after migration, the migration management module updates the activation status of the target configuration file to "activated" and records on the chain that the target operator node has become the current service provider for the target configuration file.

[0264] In one implementation, the migration management module also writes the activation status update result to the blockchain network. The activation status update result may include the activation status, activation confirmation message digest, status update message digest, activation status update time, target operator node identifier, target device identifier, and on-chain transaction identifier. The activation status update result serves as proof that both the user terminal and the target operator node have confirmed that the new configuration file is in a usable state, providing a basis for subsequent migration settlement processing, migration history auditing, and user service status queries.

[0265] If the migration management module only receives activation confirmation information but has not yet received status update information, the migration management module will record the activation status as either "terminal confirmed" or "pending operator confirmation."

[0266] This application embodiment further confirms the activation results of the new configuration files on the user terminal side and the target operator node side after the ownership status is updated through the migration management module, and updates the activation status to the activated status. This enables the cross-operator eSIM configuration file migration process to extend from the on-chain ownership status change to the confirmation of the actual usability status of the user terminal, thereby improving the completeness of the migration results, service continuity and the accuracy of status records.

[0267] In an optional implementation, after updating the activation status of the target configuration file or a new configuration file generated based on the target configuration file to an activated status in step S804, the method further includes the following steps S901-S904.

[0268] Step S901: Based on the release confirmation information, the receipt confirmation information, and the activation status, determine whether the preset settlement conditions are met.

[0269] Here, the migration management module reads the release confirmation information, receive confirmation information, and activation status based on the migration service identifier corresponding to this migration process, and determines whether the preset settlement conditions are met based on the above information. The release confirmation information indicates that the source operator node has completed the release confirmation of the target configuration file. The receive confirmation information indicates that the target operator node has completed the reception of encrypted configuration data, generation of the new configuration file, and binding to the target device. The activation status indicates that the target configuration file or a new configuration file generated based on the target configuration file has been activated on the user terminal side.

[0270] Preset settlement conditions may include: the release confirmation information has been returned and verified by the source operator node; the reception confirmation information has been returned and verified by the target operator node; the activation status of the target configuration file or new configuration file has been updated to the activated status; the release confirmation information, reception confirmation information, and activation status all correspond to the same migration service identifier; the correspondence between the identifier information of the target configuration file, the identifier of the target operator node, and the identifier of the target device is consistent; and the migration process is not in an abnormal, revoked, or disputed state.

[0271] In one implementation, the migration management module can further determine whether the migration completion time is within a preset settlement period, whether both the source operator node and the target operator node are eligible for settlement, and whether a migration history record has been generated for this migration process. If all the above determinations meet the preset requirements, the migration management module determines that the preset settlement conditions are met. If any of the following is missing: release confirmation information, receive confirmation information, or activation status; or if any of these does not match the service identifier for this migration, the migration management module will not trigger the migration settlement process and will maintain the settlement status as pending settlement or settlement conditions not met.

[0272] Step S902: If the preset settlement conditions are met, generate settlement information between the source operator node and the target operator node.

[0273] Here, after determining that the preset settlement conditions are met, the migration management module generates settlement information between the source operator node and the target operator node. This settlement information is used to characterize the cost settlement, rights transfer, or service clearing content corresponding to this cross-operator configuration file migration.

[0274] Settlement information may include one or more of the following: migration service identifier, target configuration file identifier, source operator node identifier, target operator node identifier, target device identifier, settlement amount, settlement direction, settlement basis, settlement time, settlement cycle, initial settlement status value, and settlement voucher summary. The settlement amount can be determined based on preset migration fee rules, inter-operator agreement rules, configuration file type, number of migrations, user service type, or migration scenario. The settlement direction indicates the flow of fees or rights between the source and target operator nodes. The settlement basis records the release confirmation information, receipt confirmation information, and activation status upon which this settlement depends.

[0275] In one implementation, the migration management module can automatically generate settlement information based on pre-defined settlement rules in the smart contract. These settlement rules may include fixed-amount rules, billing rules based on configuration file type, billing rules based on migration scenario, billing rules based on operator protocol parameters, or billing rules based on user service status. In another implementation, the migration management module can generate settlement information based on on-chain records and send the settlement information to an off-chain settlement system for subsequent clearing.

[0276] Step S903: Based on the settlement information, perform migration settlement processing between the source operator node and the target operator node.

[0277] Here, the migration management module performs migration settlement processing between the source operator node and the target operator node based on settlement information. This migration settlement processing is used to complete the transfer of fees, confirmation of rights, or generation of settlement vouchers corresponding to this configuration file migration.

[0278] In one implementation, migration settlement is executed automatically via smart contracts within the blockchain network. The smart contracts trigger on-chain asset or token transfers between the source and target operator nodes based on settlement information, generating corresponding on-chain transaction records to ensure consistency between the settlement process and migration status records, thereby reducing manual reconciliation and offline confirmation processes.

[0279] In another implementation, the migration management module generates a settlement instruction based on the settlement information and sends it to the off-chain settlement system. The off-chain settlement system then completes the fee clearing between the source operator node and the target operator node based on the settlement instruction. After receiving the settlement processing result returned by the off-chain settlement system, the migration management module associates the settlement processing result with the migration service identifier. This method is suitable for scenarios where existing clearing systems already exist between operators.

[0280] During the migration settlement process, the migration management module can verify the settlement information. Verification includes checking whether the settlement amount conforms to preset rules, whether the settlement direction is consistent with the migration relationship, whether both the source and target operator nodes are participating nodes in this migration process, and whether the settlement information has been reused. If the verification fails, the migration management module will not execute the settlement process and will generate settlement exception information.

[0281] Step S904: Record the settlement status corresponding to the migration settlement process to the blockchain network.

[0282] Here, the migration management module records the settlement status corresponding to the migration settlement process to the blockchain network. The settlement status is used to represent the execution result of this migration settlement process. The settlement status can include pending settlement, settlement in progress, settlement completed, settlement failed, or settlement abnormal.

[0283] In one implementation, the migration management module associates and records the migration service identifier, the identifier information of the target configuration file, the source operator node identifier, the target operator node identifier, settlement information, settlement processing result, settlement status, settlement completion time, and on-chain transaction identifier to the blockchain network. If the settlement processing is completed through on-chain asset transfer, the settlement status may also include the asset transfer transaction identifier or a summary of the asset transfer result. If the settlement processing is completed through an off-chain settlement system, the settlement status may also include a summary of the off-chain settlement certificate, the processing result returned by the off-chain settlement system, and the settlement confirmation time.

[0284] In the event of a settlement failure, the migration management module records the reason for the failure on the blockchain network. Reasons for settlement failure may include abnormal settlement amount, abnormal node account, insufficient on-chain asset balance, failure of the off-chain settlement system, failure to verify settlement information, or duplicate settlement requests. By recording the reasons for settlement failure, the source operator node, target operator node, and regulatory node can pinpoint the cause of the settlement anomaly based on the on-chain records.

[0285] In this embodiment, the migration management module performs migration settlement processing after the release confirmation, reception confirmation, and activation status all meet preset requirements, and records the settlement status to the blockchain network. This enables the service settlement in the cross-operator eSIM profile migration to be consistent with the migration process status, improves the automation, accuracy, and traceability of settlement processing between operators, and reduces the cost of manual reconciliation and the risk of settlement disputes after cross-operator migration.

[0286] In one specific embodiment, the cross-carrier eSIM profile migration method provided in this application is applied to the migration management module in a blockchain network. The following example illustrates how a user migrates a target profile from a first carrier to a second carrier on their mobile phone.

[0287] After the first operator connects to the blockchain network, it becomes the source operator node; after the second operator connects, it becomes the target operator node. The user's mobile phone serves as the user terminal. A migration management module is set up in the blockchain network, implemented based on smart contracts deployed on the blockchain. Both the source and target operator nodes invoke the smart contracts to interact with the migration management module on the blockchain.

[0288] Before a user initiates a migration, the source operator node first sends a configuration file registration request to the migration management module. The configuration file registration request includes the characteristic information of the configuration file to be registered, user identification information, and operator identification information. Based on the configuration file registration request, the migration management module generates identification information for the configuration file corresponding to the configuration file to be registered, and records the correspondence between the configuration file identification information, user identification information, and operator identification information to the blockchain network. Thus, an initial registration record of the target configuration file is formed in the blockchain network.

[0289] When a user needs to migrate from a first operator to a second operator, the user terminal generates a configuration file migration request and sends it to the migration management module. The configuration file migration request includes the target configuration file's identification information, the target operator's identifier, the target device's identifier, and the user's authorization information. The target device identifier is the target device's EID, and the user authorization information is a digital signature generated by the user terminal based on the user's private key.

[0290] Upon receiving a configuration file migration request, the migration management module verifies the request based on a smart contract. The module queries the ownership and migration status of the target configuration file based on its identification information, verifies whether the user terminal has migration permissions based on user authorization information, and determines the target operator node based on the target operator identifier, verifying whether the target operator node meets preset operator conditions. If the target configuration file is in a migration-allowed state, the user terminal has migration permissions, and the target operator node meets the receiving conditions, the migration management module determines that the configuration file migration request has been verified.

[0291] After the configuration file migration request is verified, the migration management module identifies the source operator node currently holding the target configuration file, generates a migration service identifier corresponding to this configuration file migration request, and writes the target configuration file identifier, target operator identifier, target device identifier, and migration service identifier into the blockchain network. Subsequently, the migration management module sends a release notification to the source operator node. The release notification carries the target configuration file identifier and the migration service identifier, instructing the source operator node to release the target configuration file.

[0292] Upon receiving the release notification, the source operator node confirms the release of the target configuration file and, based on the public key information corresponding to the target operator node, encrypts the configuration data corresponding to the target configuration file to obtain encrypted configuration data. The source operator node stores the encrypted configuration data in a distributed storage system and generates a data addressing credential based on the storage location of the encrypted configuration data. The source operator node returns the release confirmation information and the data addressing credential to the migration management module. The migration management module verifies the release confirmation information and, upon successful verification, associates the identifier information of the target configuration file, the node identifier corresponding to the target operator node, the data addressing credential, and the release confirmation information, writing the associated record as a release record into the blockchain network.

[0293] The migration management module sends a download notification carrying data addressing credentials to the target operator node. The target operator node downloads the encrypted configuration data based on the data addressing credentials and decrypts the encrypted configuration data using its corresponding private key information to obtain the configuration data. The target operator node generates a new configuration file based on the decrypted configuration data and binds the new configuration file to the target device corresponding to the target device identifier. In this embodiment, the new configuration file retains the user's original MSISDN. After completing the generation of the new configuration file and binding to the target device, the target operator node returns a receipt confirmation message to the migration management module. The receipt confirmation message includes target operator confirmation information, a summary of the new configuration file, and binding status information.

[0294] After receiving the confirmation message, the migration management module verifies the confirmation message from the target operator and, upon successful verification, records the new configuration file summary and binding status information to the blockchain network. After confirming that it has received both the release confirmation message from the source operator node and the reception confirmation message from the target operator node, the migration management module updates the ownership status of the target configuration file. Specifically, the migration management module updates the ownership status between the target configuration file and the source operator node to "released," updates the ownership status between the new configuration file generated based on the target configuration file and the target operator node to "received," and updates the migration status of the target configuration file to "migrated."

[0295] After completing the ownership status update, the migration management module generates the migration history corresponding to the target configuration file and writes it to the blockchain network. The migration history includes the configuration file migration request, release confirmation information, data addressing credentials, download notification, received confirmation information, and ownership status update results. When a supervisory node initiates a query request, the migration management module reads the migration history from the blockchain network and returns it to the supervisory node, enabling the supervisory node to audit the migration process of the target configuration file.

[0296] The migration management module sends a migration completion notification to the user terminal. Upon receiving the notification, the user terminal initiates a new configuration file download request to the target operator node via the LPA, and completes the installation and activation of the new configuration file within the user terminal's secure zone. After activation, the user terminal returns activation confirmation information to the migration management module. The target operator node returns status update information to the migration management module. Upon receiving both the activation confirmation and status update information, the migration management module updates the activation status of the new configuration file to "activated."

[0297] After the activation status of the new configuration file is updated to "activated," the migration management module determines whether the preset settlement conditions are met based on the release confirmation information, the reception confirmation information, and the activation status. If the preset settlement conditions are met, the migration management module generates settlement information between the source operator node and the target operator node, and executes the migration settlement process through a smart contract based on the settlement information. The migration management module records the settlement status corresponding to the migration settlement process to the blockchain network.

[0298] This embodiment establishes a complete closed loop encompassing configuration file registration, migration request verification, source operator node release, target operator node reception, ownership status update, migration history auditing, user terminal activation, and inter-operator settlement. The migration management module within the blockchain network provides unified management of the cross-operator migration process, eliminating reliance on centralized servers and improving data security, state consistency, collaborative efficiency, and the trustworthiness and traceability of the migration history during cross-operator eSIM configuration file migration.

[0299] 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.

[0300] 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.

[0301] 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.

[0302] 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.

[0303] 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.

[0304] 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 for migrating eSIM profiles across different carriers, characterized in that, A migration management module applied in a blockchain network; the migration management module is implemented based on smart contracts deployed on the blockchain network; the blockchain network further includes source operator nodes and target operator nodes, the source operator nodes and the target operator nodes being used to invoke the smart contracts to interact with the migration management module on-chain; the method includes: Receive a configuration file migration request sent by a user terminal; wherein the configuration file migration request includes the identification information of the target configuration file; The smart contract verifies the configuration file migration request, and after successful verification, a release notification is sent to the source operator node. The system receives release confirmation information and data addressing credentials returned by the source operator node; wherein, the data addressing credentials are used by the target operator node to obtain encrypted configuration data corresponding to the target configuration file. Send a download notification carrying the data addressing credential to the target operator node, so that the target operator node can download and decrypt the encrypted configuration data based on the data addressing credential; Receive the receipt confirmation information returned by the target operator node and update the ownership status of the target configuration file.

2. The cross-carrier eSIM profile migration method according to claim 1, characterized in that, Before the step of receiving the configuration file migration request sent by the user terminal, the method further includes: Receive a configuration file registration request sent by the source operator node; wherein the configuration file registration request includes the feature information, user identification information and operator identification information of the configuration file to be registered; Based on the configuration file registration request, generate the identification information corresponding to the configuration file to be registered; The correspondence between the identification information corresponding to the configuration file to be registered, the user identification information, and the operator identification information is recorded in the blockchain network.

3. The cross-carrier eSIM profile migration method according to claim 1, characterized in that, The configuration file migration request also includes the target operator identifier, the target device identifier, and user authorization information; The steps of verifying the configuration file migration request based on the smart contract, and sending a release notification to the source operator node after successful verification, include: Based on the identification information of the target configuration file, query the ownership status and migration status of the target configuration file in the blockchain network; Based on the user authorization information, verify whether the user terminal has migration permissions for the target configuration file; Based on the target operator identifier, determine the target operator node and verify whether the target operator node meets the preset operator conditions; If the ownership status, migration status, migration permissions, and target operator node all meet the preset migration conditions, the configuration file migration request is determined to have passed verification. Based on the identification information of the target configuration file and the ownership status, determine the source operator node that currently holds the target configuration file; Generate the migration service identifier corresponding to the configuration file migration request; The identification information of the target configuration file, the target operator identifier, the target device identifier, and the migration service identifier are written into the blockchain network; Send a release notification to the source operator node, carrying the identification information of the target configuration file and the migration service identifier.

4. The cross-carrier eSIM profile migration method according to claim 1, characterized in that, The encrypted configuration data is the data obtained by the source operator node encrypting the configuration data corresponding to the target configuration file based on the public key information corresponding to the target operator node; The step of receiving the release confirmation information and data addressing certificate returned by the source operator node includes: Receive release confirmation information returned by the source operator node based on the release notification; Receive data addressing credentials submitted by the source operator node; wherein the data addressing credentials include at least one of storage address, content hash, download address, or data access credentials; Verify that the release confirmation information matches the source operator node; If the release confirmation information matches the source operator node, obtain the node identifier corresponding to the target operator node; Associate the identification information of the target configuration file, the node identifier corresponding to the target operator node, the data addressing certificate, and the release confirmation information; The associated record is written to the blockchain network as a release record.

5. The cross-carrier eSIM profile migration method according to claim 1, characterized in that, The confirmation information received includes target operator confirmation information, new configuration file summary information, and binding status information; The step of receiving the reception confirmation information returned by the target operator node includes: Receive the target operator confirmation information returned by the target operator node based on the download notification; The system receives a new configuration file summary and binding status information submitted by the target operator node. The new configuration file summary is used to characterize the new configuration file generated by the target operator node based on the configuration data obtained after decrypting the encrypted configuration data. The binding status information is used to characterize the binding result between the new configuration file and the target device corresponding to the target device identifier. Verify whether the target operator confirmation information matches the target operator node; If the target operator confirmation information matches the target operator node, the new configuration file summary information and the binding status information are recorded in the blockchain network.

6. The cross-carrier eSIM profile migration method according to claim 1, characterized in that, The step of updating the ownership status of the target configuration file includes: Determine whether the release confirmation information returned by the source operator node and the reception confirmation information returned by the target operator node have been received; Upon receiving both the release confirmation information and the receipt confirmation information, the ownership status between the target configuration file and the source operator node is updated to a released status; Update the ownership status between the target configuration file or a new configuration file generated based on the target configuration file and the target operator node to the received status; Update the migration status of the target configuration file to "migrated".

7. The cross-carrier eSIM profile migration method according to claim 6, characterized in that, The blockchain network also includes regulatory nodes; After the step of updating the ownership status of the target configuration file, the method further includes: Generate a migration history record corresponding to the target configuration file; wherein, the migration history record includes at least one of the configuration file migration request, the release confirmation information, the data addressing credential, the download notification, the receipt confirmation information, and the ownership status update result; Write the migration history into the blockchain network; In response to a query request initiated by the regulatory node, the migration history is read from the blockchain network and returned to the regulatory node so that the regulatory node can audit the migration history.

8. The cross-carrier eSIM profile migration method according to claim 7, characterized in that, After the step of updating the ownership status of the target configuration file, the method further includes: Send a migration completion notification to the user terminal; Receive activation confirmation information returned by the user terminal; Receive the status update information returned by the target operator node; Upon receiving the activation confirmation information and the status update information, the activation status of the target configuration file or the new configuration file generated based on the target configuration file is updated to the activated status.

9. The cross-carrier eSIM profile migration method according to claim 8, characterized in that, After the step of updating the activation status of the target configuration file or a new configuration file generated based on the target configuration file to an activated state, the method further includes: Based on the release confirmation information, the receipt confirmation information, and the activation status, determine whether the preset settlement conditions are met; Under the condition that the preset settlement conditions are met, settlement information between the source operator node and the target operator node is generated; Based on the settlement information, perform migration settlement processing between the source operator node and the target operator node; The settlement status corresponding to the migration settlement process is recorded in the blockchain network.

10. A cross-carrier eSIM profile migration system, characterized in that, The system includes a blockchain network and user terminals for communication connections; the blockchain network includes a migration management module, source operator nodes, target operator nodes, and a monitoring node; the migration management module is implemented based on smart contracts deployed on the blockchain network; the source operator nodes and the target operator nodes are respectively used to invoke the smart contracts to interact with the migration management module on-chain; the monitoring node is used to audit the migration history records in the blockchain network. The migration management module is used to perform the method as described in any one of claims 1-9.

Images