Configuration file migration method and related device

Abstract

The invention provides a configuration file migration method and related device.The method comprises the steps that first equipment displays a first interface, the first interface comprises a first phone number of second equipment, first input of a user for migrating the first phone number to the first equipment is received, and then a first request is sent to a cloud server, the first request is used for requesting to migrate the first phone number to the first device; the cloud server sends the verification code to the first device; and the first device downloads the configuration file corresponding to the first telephone number from the operator server by using the verification code. According to the method and the device, the user can complete the migration operation on the migrated target device (namely the first device) without depending on the migrated source device (namely the second device), so that the migration limitation and the user operation are greatly reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a configuration file migration method and related apparatus. Background Technology

[0002] In the field of mobile communications, one common mobile communication access scheme is the user authentication access scheme based on the subscriber identity module (SIM). The common implementation involves the user inserting a SIM card into the SIM card slot of a mobile communication device such as a mobile phone or tablet. The mobile communication device then uses the inserted SIM card to perform authentication (also known as authorization) with the communication service provider. Once authentication is successful, the mobile communication device is allowed to access the mobile communication network.

[0003] With the development of mobile communication technology, an embedded SIM (eSIM) solution has been proposed based on the SIM card solution. The eSIM solution embeds the traditional SIM card directly into the chip of the electronic device, rather than adding it as a separate removable component, eliminating the need for users to insert a physical SIM card. This solution allows users greater flexibility in choosing operators and the ability to rewrite new phone numbers into the eSIM module of their electronic devices.

[0004] In some migration scenarios, users can "migrate" the card information of a physical SIM card or eSIM from device A to another device B. Device A can be called the source device, and device B can be called the target device. For example, device A is the user's old phone, and device B is the user's new phone. Currently, to achieve the above "migration," both the source and target devices need to be powered on and logged into the same account, both devices need to be connected to a Wi-Fi network, both devices need to be unlocked and operable, and the user needs to perform the migration-related operations multiple times. The migration has many restrictions and is cumbersome for users. Summary of the Invention

[0005] This application discloses a configuration file migration method and related apparatus, which enables users to complete the migration operation on the target device without relying on the source device, greatly reducing migration restrictions and user operations, and effectively improving the user experience.

[0006] In one aspect, this application provides a communication system including a first device and a cloud server. The first device displays a first interface including one or more phone numbers (including the first phone number) from a second device, and receives a first input from a user requesting the migration of the first phone number to the first device. The first device, in response to the first input, sends a first request to the cloud server requesting the migration of the first phone number to the first device. The cloud server sends a verification code to the first device based on the first request. The first device uses the verification code to download a configuration file corresponding to the first phone number from an operator server (e.g., a mobile network operator, MNO). The second device is the source device for migrating the first phone number, and the first device is the target device for migrating the first phone number; for example, the first device is the user's new mobile phone, and the second device is the user's old mobile phone. The migration of the first phone number can be the migration of a configuration file (profile) corresponding to the first phone number.

[0007] In some examples, the first phone number is the phone number of the Physical Subscriber Identity Module (pSIM) in the second device. Therefore, when the second device uses the first phone number for communication, it registers with the network through the pSIM of the first phone number. In this case, the configuration file corresponding to the first phone number is generated and sent to the first device by the operator server after the first device sends a request to the operator server. In other examples, the first phone number is the phone number of the Embedded Subscriber Identity Module (eSIM) in the second device. The second device can store the configuration file corresponding to the first phone number generated and sent by the operator server in the eSIM module. Therefore, when the second device uses the first phone number for communication, it registers with the network through the configuration file of the first phone number in the eSIM module. In this case, the configuration file corresponding to the first phone number is sent to the first device by the operator server after the first device sends a request to the operator server.

[0008] In some examples, the cloud server is an application server that provides services to a first network application on a first device. For example, the first interface is the interface of the first network application. Optionally, the cloud server may also be an application server that provides services to a first network application on a second device.

[0009] In the above system, users can complete the migration operation in a closed loop on the first device, which is the target device, without relying on the second device, which is the source device. For example, the second device does not need to be intact, online in real time, transmit proof data, or be user operable. This greatly reduces the restrictions on migration. Users also do not need to perform migration-related operations multiple times on the first and second devices, reducing user operations and thus effectively improving the usability of the migration function and the user experience.

[0010] In one possible implementation, the first device sends a second request to an operator server (e.g., authentication server ES) before receiving the first input from the user to migrate a first phone number to the first device, and then receives a first response from the operator server (e.g., authentication server ES). The second request carries the first phone number, and the first response indicates successful processing of the second request. The cloud server receives a verification code from the operator server (e.g., authentication server ES) after the first device sends the second request to the operator server, and then sends the verification code to the first device. For example, the first response is sent to the first device after the operator server sends the verification code to the cloud server.

[0011] In the above system, if the operator server is unsure whether the first device is a trusted device, it can send a verification code to a trusted cloud server based on a second request. If the first device is a trusted device of the cloud server, it will receive the verification code sent by the cloud server. Therefore, even if the first device (target device) does not obtain migration proof data from the second device (source device) and send it to the operator server, it can still obtain the verification code from the operator server through the cloud server. This ensures security while achieving a migration process independent of the source device.

[0012] In one possible implementation, the cloud server sends a third request to the carrier server (e.g., authentication server ES) before receiving the verification code from the carrier server. It then receives a first access token (AccessToken) from the carrier server (e.g., authentication, authorization, and accounting server AAA), which enables secure communication between the cloud server and the carrier server. The cloud server receives first encrypted information (i.e., encrypted information obtained by encrypting the verification code using the first access token) from the carrier server, decrypts the first encrypted information using the first access token to obtain the verification code, and then sends the verification code to the first device.

[0013] In the aforementioned system, cloud servers and carrier servers can communicate using the first access token, further enhancing security.

[0014] In one possible implementation, the first device is used to log in to a first account and receive one or more phone numbers corresponding to the first account from the cloud server before displaying the first interface, and then display one or more phone numbers corresponding to the first account on the first interface, wherein the one or more phone numbers corresponding to the first account include one or more phone numbers of the second device that has logged in to the first account.

[0015] In the above system, the first device can obtain the phone number of the second device through the cloud server and display it on the first interface for the user to select the phone number to migrate. This can also be understood as realizing the synchronization of the phone number through the first account, without the need for the first device and the second device to interact with each other to obtain the phone number of the second device. Therefore, the synchronization of the phone number does not depend on the source device, further reducing the restrictions on migration and improving the user experience.

[0016] In one possible implementation, the cloud server is configured to receive a first temporary token (TemporaryToken) sent by a second device before sending one or more phone numbers corresponding to a first account to a first device, and based on the first temporary token, send a fourth request (e.g., an instruction to request a phone number) to an operator server (e.g., authentication server ES), and then receive a second phone number of the second device from the operator server, wherein the fourth request carries the first temporary token, and the one or more phone numbers of the second device include the second phone number, and the second phone number includes the first phone number. Optionally, the communication system further includes a second device configured to send a fifth request (e.g., an instruction to request a temporary token) to the operator server (e.g., authentication server ES), then receive the first temporary token sent by the operator server, and send the first temporary token to the cloud server.

[0017] In the aforementioned system, if the second device is intact and network-enabled, it can obtain a first temporary token from the operator's server and send it to the cloud server. The cloud server can then retrieve and store the second device's phone number from the operator's server based on this first temporary token. Therefore, when users subsequently use the first device, they do not need to rely on the second device; they can directly obtain the second device's phone number from the cloud server that has already stored it, resulting in a better user experience.

[0018] In one possible implementation, the first device sends a sixth request to the operator server (e.g., authentication server ES), the sixth request carrying a verification code. If the operator server (e.g., authentication server ES) verifies the verification code carried in the sixth request, the first device receives an authentication token (AuthToken) sent by the operator server, and then uses the authentication token to download the configuration file corresponding to the first phone number from the operator server. For example, all requests sent by the first device to the operator server can carry the authentication token. The operator server can verify the identity of the first device by verifying the authentication token, and thus choose whether to respond to the first device.

[0019] In the aforementioned system, the first device can obtain an authentication token from the operator's server based on a verification code. This authentication token enables secure communication between the first device and the operator's server. The token can be security information issued by the operator's server that conforms to the communication method between the two devices (e.g., HTTPS). This allows the operator's server to directly verify the authentication token based on the current communication method, eliminating the need to authenticate the first device's identity information (verification code, identification information, etc.) each time, thus ensuring security while accelerating processing speed.

[0020] In one possible implementation, the first device is used to send a seventh request (e.g., for requesting eligibility verification and / or for requesting management of subscription relationships) to an operator server (e.g., an authentication server ES). The seventh request carries an authentication token. If the operator server verifies the authentication token carried in the seventh request, the device receives first address information sent by the operator server and then downloads the configuration file corresponding to the first phone number from the configuration file server corresponding to the first address information.

[0021] In the above system, the carrier server may include a server for verifying the identity of the first device (e.g., an authentication server ES) and a configuration file server for managing configuration files. Only when the authentication server ES successfully authenticates the first device will it send the address information of the configuration file server to the first device, allowing the first device to download the required configuration file from the configuration file server, instead of the configuration file server directly distributing the configuration file. Therefore, the carrier server can distribute the processing and storage load across different servers and improve the security of the configuration files.

[0022] In one possible implementation, the first device sends an eighth request (e.g., a request to manage subscription relationships, such as the seventh request mentioned above) to an operator server (e.g., an authentication server ES). This eighth request carries an authentication token. The operator server verifies the authentication token carried in the eighth request. When the authentication token verification is successful (e.g., in an operator business operation support management system BOSS), it deactivates the subscription relationship of the first phone number corresponding to the second device, and also activates the subscription relationship of the first phone number corresponding to the first device. The activated subscription relationship of the first phone number enables network registration via the first phone number. Therefore, after deactivating the subscription relationship of the first phone number corresponding to the second device, the second device cannot register via the first phone number; after activating the subscription relationship of the first phone number corresponding to the first device, the first device can register via the first phone number.

[0023] In the above system, the operator's server can deactivate the subscription relationship of the first phone number corresponding to the second device, preventing the second device from registering on the network through the first phone number. This prevents other people from using the second phone number to make purchases if the second device is lost, effectively protecting user rights and improving user experience.

[0024] In one possible implementation, before receiving the first input from a user to migrate a first phone number to the first device, the first device displays one or more phone numbers from a second device in a first area of ​​a first interface. This first area is used to display phone numbers from devices other than the first device. In this case, the second area of ​​the first interface displayed by the first device does not include the first phone number; the second area may include other phone numbers from the first device or not include any phone numbers. Alternatively, after downloading the configuration file corresponding to the first phone number from the operator's server using a verification code, the first device displays the first phone number of the first device in the second area of ​​the first interface. In this case, the first area of ​​the first interface displayed by the first device does not include the first phone number; the first area may include other phone numbers or not include any phone numbers.

[0025] In the above system, before the first phone number of the second device is migrated to the first device, the first device can display the first phone number in the first area of ​​the first interface used to display the first phone number of other devices. After the first phone number of the second device is migrated to the first device, the first device can display the first phone number in the second area of ​​the first interface used to display the first phone number of its own device, so that users can intuitively see the migration of the first phone number through the first device.

[0026] In one possible implementation, the communication system further includes a second device. The second device is configured to display one or more phone numbers (including the first phone number) of the second device in a third area of ​​a second interface before the first device receives a first input from a user to migrate a first phone number to the first device. The third area is used to display the phone numbers of the second device. At this time, a fourth area of ​​the second interface displayed by the second device does not include the first phone number; the fourth area may include other phone numbers or not include any phone numbers. Alternatively, the fourth area may be used to display phone numbers of other devices besides the second device. After the first device downloads the configuration file corresponding to the first phone number from the operator's server using a verification code, the second device displays the first phone number in the fourth area of ​​the second interface. In this case, the third area of ​​the second interface displayed by the second device does not include the first phone number; the third area may include other phone numbers of the second device or not include any phone numbers.

[0027] In the above system, before the first phone number of the second device is migrated to the first device, the second device can display the first phone number in the third area of ​​the second interface. After the first phone number of the second device is migrated to the first device, the second device can display the first phone number in the fourth area of ​​the second interface, allowing the user to intuitively see the migration of the first phone number through the second device.

[0028] Secondly, this application provides a profile migration method applied to a first device. The method includes: displaying a first interface including one or more phone numbers (including the first phone number) of a second device, and receiving a first input from a user requesting the migration of the first phone number to the first device; responding to the first input, sending a first request to a cloud server, the first request requesting the migration of the first phone number to the first device; receiving a verification code sent by the cloud server based on the first request; and then using the verification code to download the profile corresponding to the first phone number from an operator server (e.g., a mobile network operator, MNO). Wherein, the second device is the source device for migrating the first phone number, and the first device is the target device for migrating the first phone number; for example, the first device is the user's new mobile phone, and the second device is the user's old mobile phone. The migration of the first phone number can be the migration of the profile corresponding to the first phone number.

[0029] In some examples, the first phone number is the phone number of the Physical Subscriber Identity Module (pSIM) in the second device. Therefore, when the second device uses the first phone number for communication, it registers with the network through the pSIM of the first phone number. In this case, the configuration file corresponding to the first phone number is generated and sent to the first device by the operator server after the first device sends a request to the operator server. In other examples, the first phone number is the phone number of the Embedded Subscriber Identity Module (eSIM) in the second device. The second device can store the configuration file corresponding to the first phone number generated and sent by the operator server in the eSIM module. Therefore, when the second device uses the first phone number for communication, it registers with the network through the configuration file of the first phone number in the eSIM module. In this case, the configuration file corresponding to the first phone number is sent to the first device by the operator server after the first device sends a request to the operator server.

[0030] In some examples, the cloud server is an application server that provides services to a first network application on a first device. For example, the first interface is the interface of the first network application. Optionally, the cloud server may also be an application server that provides services to a first network application on a second device.

[0031] In the above method, users can complete the migration operation in a closed loop on the first device, which is the target device, without relying on the second device, which is the source device. For example, the second device does not need to be intact, online in real time, transmit proof data, or be user operable, which greatly reduces the restrictions on migration. Users also do not need to perform migration-related operations multiple times on the first and second devices, reducing user operations and thus effectively improving the usability of the migration function and the user experience.

[0032] In one possible implementation, the method further includes: after receiving the user's first input to migrate a first phone number to a first device, sending a second request to an operator server (e.g., authentication server ES), and then receiving a first response from the operator server (e.g., authentication server ES), wherein the second request carries the first phone number, and the first response indicates successful processing of the second request. The verification code is received by the cloud server from the operator server, for example, after the first device sends the second request. For instance, the first response is sent by the operator server to the cloud server and then to the first device.

[0033] In the above method, if the operator server is unsure whether the first device is a trusted device, it can send a verification code to a trusted cloud server based on a second request. If the first device is a trusted device of the cloud server, it will receive the verification code sent by the cloud server. Therefore, even if the first device (target device) does not obtain migration proof data from the second device (source device) and send it to the operator server, it can still obtain the verification code from the operator server through the cloud server. This ensures security while achieving a migration process independent of the source device.

[0034] In one possible implementation, the method further includes: before displaying the first interface, the first device logs into a first account and receives one or more phone numbers corresponding to the first account from the cloud server, and then displays one or more phone numbers corresponding to the first account on the first interface, wherein the one or more phone numbers corresponding to the first account include one or more phone numbers of the second device that has logged into the first account.

[0035] In the above method, the first device can obtain the phone number of the second device through the cloud server and display it on the first interface for the user to select the phone number to migrate. This can also be understood as realizing the synchronization of the phone number through the first account, without the need for the first device and the second device to interact with each other to obtain the phone number of the second device. Therefore, the synchronization of the phone number does not depend on the source device, further reducing the restrictions on migration and improving the user experience.

[0036] In one possible implementation, the first device uses a verification code to download the configuration file corresponding to the first phone number from the operator's server. This includes: sending a third request to the operator's server (e.g., authentication server ES), the third request carrying a verification code; and, if the operator's server (e.g., authentication server ES) verifies the verification code carried in the third request, receiving an authentication token (AuthToken) sent by the operator's server, and then using the authentication token to download the configuration file corresponding to the first phone number from the operator's server. For example, all requests sent by the first device to the operator's server can carry the authentication token, and the operator's server can verify the identity of the first device by verifying the authentication token, thereby choosing whether to respond to the first device.

[0037] In the above method, the first device can obtain an authentication token from the operator's server based on a verification code. This authentication token can be used to enable secure communication between the first device and the operator's server. The authentication token can be security information issued by the operator's server that conforms to the communication method between the first device and the operator's server (e.g., HTTPS communication). In this way, the operator's server can subsequently directly verify the authentication token based on the current communication method, without needing to authenticate the first device's identity information such as the verification code and identification information each time, thus ensuring security while speeding up processing.

[0038] In one possible implementation, the first device uses an authentication token to download the configuration file corresponding to the first phone number from the operator server, including: sending a fourth request (e.g., for requesting eligibility verification and / or for requesting management of subscription relationships) to the operator server (e.g., authentication server ES), the fourth request carrying the authentication token, and, if the operator server verifies the authentication token carried in the fourth request, receiving the first address information sent by the operator server, and then downloading the configuration file corresponding to the first phone number from the configuration file server corresponding to the first address information.

[0039] In the above method, the carrier server may include a server for verifying the identity of the first device (e.g., an authentication server ES) and a configuration file server for managing configuration files. Only when the authentication server ES successfully authenticates the first device will it send the address information of the configuration file server to the first device, allowing the first device to download the required configuration file from the configuration file server, instead of the configuration file server directly distributing the configuration file. Therefore, the carrier server can distribute the processing and storage load across different servers, and the security of the configuration file is improved.

[0040] In one possible implementation, the method further includes: the first device sending a fifth request (e.g., for requesting management of subscription relationships, such as the fourth request mentioned above) to an operator server (e.g., authentication server ES). The fifth request carries an authentication token. When the operator server (e.g., operator business operation support management system BOSS) verifies the authentication token carried in the fifth request, it activates the subscription relationship of the first phone number corresponding to the second device, and also activates the subscription relationship of the first phone number corresponding to the first device. The activated subscription relationship of the first phone number is used to enable network registration via the first phone number. Therefore, after deactivating the subscription relationship of the first phone number corresponding to the second device, the second device cannot register via the first phone number; after activating the subscription relationship of the first phone number corresponding to the first device, the first device can register via the first phone number.

[0041] In the above method, the operator's server can deactivate the subscription relationship of the first phone number corresponding to the second device, preventing the second device from registering on the network through the first phone number. This avoids other people using the second phone number to make purchases if the second device is lost, effectively protecting user rights and improving user experience.

[0042] In one possible implementation, the first device displays a first interface, including: displaying one or more phone numbers of a second device in a first area of ​​the first interface; the first area is used to display phone numbers of other devices besides the first device; in this case, a second area of ​​the first interface displayed by the first device does not include the first phone number, the second area may include other phone numbers of the first device or not include any phone numbers, and the second area is used to display the phone number of the first device. The method further includes: after the first device downloads the configuration file corresponding to the first phone number from the operator's server using a verification code, displaying the first phone number of the first device in the second area of ​​the first interface; in this case, the first area of ​​the first interface displayed by the first device does not include the first phone number, the first area may include other phone numbers or not include any phone numbers.

[0043] In the above method, before the first phone number of the second device is migrated to the first device, the first device can display the first phone number in the first area of ​​the first interface used to display other devices. After the first phone number of the second device is migrated to the first device, the first device can display the first phone number in the second area of ​​the first interface used to display its own phone number, so that the user can intuitively see the migration of the first phone number through the first device.

[0044] In one possible implementation, the method further includes: after the first device receives the verification code sent by the cloud server, displaying a second interface, the second interface including an input box and a first notification, the first notification including the verification code; and then receiving a second input from the user, in which the user enters the verification code in the input box. In response to the second input, the first device uses the verification code to download the configuration file corresponding to the first phone number from the operator's server. For example, the input box is an input box in a first network application, and the first notification is a notification from another application besides the first network application; this can be understood as receiving the verification code sent by the cloud server through another application. In another possible implementation, if the first device receives the verification code sent by the cloud server through the first network application, then after receiving the verification code, it uses the verification code to download the configuration file corresponding to the first phone number from the operator's server.

[0045] In the above method, the first device allows the user to perceive the verification code, and the user enters the verification code to trigger the download of the configuration file, thereby allowing the user to intuitively experience and participate in the migration process, and improving the user experience.

[0046] In one possible implementation, the above method further includes: after downloading the configuration file corresponding to the first phone number from the operator's server using a verification code, displaying a third interface, the third interface including the first phone number of the first device, and receiving a third input from the user to enable the first phone number; and then, in response to the third input, registering on the network using the configuration file corresponding to the first phone number.

[0047] In the above method, the first device can respond to user input and register on the network using the configuration file corresponding to the first successfully migrated phone number, allowing the user to use the first successfully migrated phone number normally.

[0048] Thirdly, this application provides a configuration file migration method applied to a cloud server. The method includes: receiving a first request sent by a first device, the first request requesting the migration of a first phone number from a second device to the first device; and then sending a verification code to the first device, the verification code being used by the first device to download the configuration file corresponding to the first phone number from an operator server (e.g., a mobile network operator MNO). Here, the second device is the source device for migrating the first phone number, and the first device is the target device for migrating the first phone number; for example, the first device is the user's new mobile phone, and the second device is the user's old mobile phone. The migration of the first phone number can be the migration of the configuration file (profile) corresponding to the first phone number.

[0049] In some examples, the first phone number is the phone number of the Physical Subscriber Identity Module (pSIM) in the second device. Therefore, when the second device uses the first phone number for communication, it registers with the network through the pSIM of the first phone number. In this case, the configuration file corresponding to the first phone number is generated and sent to the first device by the operator server after the first device sends a request to the operator server. In other examples, the first phone number is the phone number of the Embedded Subscriber Identity Module (eSIM) in the second device. The second device can store the configuration file corresponding to the first phone number generated and sent by the operator server in the eSIM module. Therefore, when the second device uses the first phone number for communication, it registers with the network through the configuration file of the first phone number in the eSIM module. In this case, the configuration file corresponding to the first phone number is sent to the first device by the operator server after the first device sends a request to the operator server.

[0050] In some examples, the cloud server is an application server that provides services to a first network application on a first device. For example, the first interface is the interface of the first network application. Optionally, the cloud server may also be an application server that provides services to a first network application on a second device.

[0051] In the above method, the first device, acting as the target device, can obtain a verification code from a cloud server and use the verification code to download the configuration file of the first phone number of the source device from the operator's server. Therefore, users can complete the migration operation in a closed loop on the first device, acting as the target device, without relying on the second device, acting as the source device. For example, the second device does not need to be intact, online in real time, transmit proof data, or be user-operable, which greatly reduces the limitations of migration. Users also do not need to perform migration-related operations multiple times on the first and second devices, reducing user operations and effectively improving the usability of the migration function and the user experience.

[0052] In one possible implementation, the above method further includes: the cloud server receiving a verification code sent by the operator's server before sending the verification code to the first device.

[0053] In the above method, the carrier server can send a verification code to a trusted cloud server even if it is unsure whether the first device is a trusted device. If the first device is a trusted device of the cloud server, it will receive the verification code sent by the cloud server. Therefore, even if the first device (target device) does not obtain migration proof data from the second device (source device) and send it to the carrier server, it can still obtain the verification code from the carrier server through the cloud server. This ensures security while achieving a migration process independent of the source device.

[0054] In one possible implementation, the method further includes: before receiving the verification code sent by the carrier server, the cloud server sends a second request to the carrier server (e.g., authentication server ES), and then receives a first access token (AccessToken) sent by the carrier server (e.g., authentication, authorization, and accounting server AAA). The first access token is used to enable secure communication between the cloud server and the carrier server. The cloud server receives first encrypted information (i.e., encrypted information obtained by encrypting the verification code using the first access token) sent by the carrier server, decrypts the first encrypted information using the first access token to obtain the verification code, and then sends the verification code to the first device.

[0055] In the above method, the cloud server and the carrier server can communicate using the first access token, further improving security.

[0056] In one possible implementation, the above method further includes: before receiving the first request sent by the first device, when the first device logs into the first account, the cloud server sends one or more phone numbers corresponding to the first account to the first device, wherein the one or more phone numbers corresponding to the first account include one or more phone numbers of a second device that has logged into the first account, and the one or more phone numbers corresponding to the first account are used for display on the first device.

[0057] In the above method, the first device can obtain the phone number of the second device through the cloud server and display it on the first interface for the user to select the phone number to migrate. This can also be understood as realizing the synchronization of the phone number through the first account, without the need for the first device and the second device to interact with each other to obtain the phone number of the second device. Therefore, the synchronization of the phone number does not depend on the source device, further reducing the restrictions on migration and improving the user experience.

[0058] In one possible implementation, the above method further includes: before sending one or more phone numbers corresponding to the first account to the first device, the cloud server receives a first temporary token (TemporaryToken) sent by the second device, and sends a third request (e.g., an instruction to request a phone number) to the operator server (e.g., authentication server ES) based on the first temporary token, and then receives a second phone number of the second device sent by the operator server, wherein the third request carries the first temporary token, the one or more phone numbers of the second device include the second phone number, and the second phone number includes the first phone number.

[0059] In the above method, if the second device is intact and can be connected to the network, the cloud server can receive the first temporary token sent by the second device and obtain and store the second device's phone number from the operator's server based on the first temporary token. Therefore, when users use the first device later, they do not need to rely on the second device and can directly obtain the second device's phone number through the cloud server that has stored the second device's phone number, resulting in a good user experience.

[0060] Fourthly, this application provides an electronic device, including a transceiver, a processor, and a memory; the memory is used to store a computer program, and the processor calls the computer program to execute the configuration file migration method provided in the second aspect and any implementation thereof.

[0061] Fifthly, this application provides a cloud server, including a transceiver, a processor, and a memory; the memory is used to store a computer program, and the processor calls the computer program to execute the configuration file migration method provided in the third aspect and any implementation thereof.

[0062] Sixthly, this application provides a computer storage medium storing a computer program, which, when executed by a processor, is used to implement the configuration file migration method provided in the second aspect and any implementation thereof.

[0063] In a seventh aspect, this application provides a computer storage medium storing a computer program, which, when executed by a processor, is used to implement the configuration file migration method provided in the third aspect and any implementation thereof.

[0064] Eighthly, this application provides a computer program product, including a computer program that, when the computer program is run on a processor, implements the configuration file migration method provided by the second aspect and any implementation thereof.

[0065] Ninthly, this application provides a computer program product, including a computer program that, when the computer program runs on a processor, implements the configuration file migration method provided by the third aspect and any implementation thereof.

[0066] In a tenth aspect, this application provides a chip system including a processing circuit and an interface circuit. The interface circuit is used to receive code instructions and transmit them to the processing circuit. The processing circuit is used to execute the code instructions to perform the configuration file migration method provided in the second aspect and any implementation thereof.

[0067] In one aspect, this application provides a chip system including a processing circuit and an interface circuit. The interface circuit is used to receive code instructions and transmit them to the processing circuit. The processing circuit is used to execute the code instructions to perform the configuration file migration method provided in the third aspect and any implementation thereof.

[0068] In a twelfth aspect, this application provides an electronic device that includes the methods or apparatus described in any aspect or embodiment of this application. The electronic device is, for example, a chip.

[0069] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single implementation. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one implementation. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this application do not necessarily refer to the same implementation. Furthermore, the technical features, technical solutions, and beneficial effects described in this application can be combined in any suitable manner. Those skilled in the art will understand that this application can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular implementation. In other implementations, additional technical features and beneficial effects may be identified in specific implementations that do not embody all implementations. Attached Figure Description

[0070] The following describes the accompanying drawings used in this application.

[0071] Figure 1 This is a schematic diagram of the hardware structure of an electronic device provided in this application;

[0072] Figure 2 This is a schematic diagram of the architecture of a communication system provided in this application;

[0073] Figure 3 This is a schematic diagram of the architecture of another communication system provided in this application;

[0074] Figures 4A-4K These are schematic diagrams of some user interfaces provided in this application;

[0075] Figure 5 This is a flowchart illustrating a configuration file migration method provided in this application;

[0076] Figure 6 This is a flowchart illustrating yet another configuration file migration method provided in this application;

[0077] Figure 7 This is a flowchart illustrating yet another configuration file migration method provided in this application;

[0078] Figure 8 This is a flowchart illustrating another configuration file migration method provided in this application. Detailed Implementation

[0079] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments of this application and is not intended to limit this application.

[0080] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0081] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0082] Figure 1 This is a schematic diagram of the hardware structure of an electronic device 100 provided in an embodiment of this application.

[0083] like Figure 1As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and an embedded subscriber identity module (eSIM) module 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0084] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0085] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0086] The processor 110 may also include a memory for storing instructions and data. In one embodiment, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0087] In one embodiment, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM interface, and / or a universal serial bus (USB) interface, etc.

[0088] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging implementations, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging implementations, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device 100 via the power management module 141.

[0089] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In another embodiment, the power management module 141 can also be located within the processor 110. In yet another embodiment, the power management module 141 and the charging management module 140 can be housed in the same device.

[0090] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0091] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. When an antenna covers multiple communication frequency bands for different communication methods, it can be called a cooperative antenna. For an explanation of cooperative antennas, please refer to the descriptions of antenna cooperative situations one, two, and three above. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In another embodiment, the antenna can be used in conjunction with a tuning switch.

[0092] The mobile communication module 150 can provide wireless communication solutions for applications on the electronic device 100, including second-generation (2G), third-generation (3G), fourth-generation (4G), fifth-generation (5G), and sixth-generation (6G) mobile communication technologies. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In one embodiment, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In another embodiment, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0093] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through audio devices (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In one embodiment, the modem processor may be a separate device. In another embodiment, the modem processor may be independent of the processor 110 and housed within the same device as the mobile communication module 150 or other functional modules.

[0094] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), and SparkLink Alliance-standard wireless communication technologies (such as SLE and SLB). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0095] In one embodiment, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0096] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0097] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In one embodiment, electronic device 100 may include N displays screens 194, where N is a positive integer greater than 1.

[0098] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0099] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye. The ISP can also perform algorithmic optimization on image noise, brightness, etc. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In one embodiment, the ISP can be set in the camera 193.

[0100] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In one embodiment, electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0101] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0102] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0103] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0104] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0105] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0106] Electronic device 100 can implement audio functions through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor. Electronic device 100 can also implement audio functions through connected Bluetooth devices, such as music playback and recording.

[0107] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In one embodiment, the audio module 170 can be located in the processor 110, or some functional modules of the audio module 170 can be located in the processor 110.

[0108] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0109] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0110] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. Electronic device 100 may have at least one microphone 170C. In another embodiment, electronic device 100 may have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In yet another embodiment, electronic device 100 may have three, four, or more microphones 170C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, among other functions.

[0111] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In one embodiment, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In one embodiment, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0112] The gyroscope sensor 180B can be used to determine the motion posture of the electronic device 100. The barometric pressure sensor 180C is used to measure air pressure. The magnetic sensor 180D includes a Hall effect sensor. The accelerometer sensor 180E can detect the magnitude of the acceleration of the electronic device 100 in various directions (generally three axes). The distance sensor 180F is used to measure distance. The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. The LED may be an infrared LED. The ambient light sensor 180L is used to sense ambient light intensity. The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can utilize the collected fingerprint characteristics to achieve fingerprint unlocking, accessing application locks, fingerprint photography, fingerprint answering of calls, etc. The temperature sensor 180J is used to detect temperature. The bone conduction sensor 180M can acquire vibration signals.

[0113] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In another embodiment, touch sensor 180K can also be located on the surface of electronic device 100, in a different position than display screen 194.

[0114] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100. Motor 191 can generate vibration prompts. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc.

[0115] The eSIM module 195 can be embedded in the electronic device 100, for example, in a non-removable form, such as by embedding it inside the motherboard of the electronic device 100. It can replace a physical subscriber identity module (SIM) card (i.e., a physical SIM, pSIM) for interaction between the electronic device 100 and the network, enabling functions such as calls and data communication. However, the eSIM module 195 is generally much smaller. Unlike a physical SIM card, the eSIM module 195 allows for easy switching of phone numbers or changing of operators because the information on the eSIM module 195 is rewritable. The eSIM module 195 can be remotely configured via over-the-air (OTA) technology, enabling the downloading, activation, deactivation, and deletion of profiles.

[0116] eSIM module 195 can store one or more profiles. A profile can include card information for one or more non-physical SIM cards (referred to as eSIMs). For ease of explanation, this embodiment uses the example of a profile including the card information of one eSIM. Any two profiles in eSIM module 195 can correspond to the same operator or different operators. For example, after a user signs up with operator A through electronic device 100, operator A issues eSIM1 corresponding to operator A to electronic device 100. That is, electronic device 100 can download profile1 (including the card information of eSIM1) corresponding to operator A from operator A's profile server. After a user signs up with operator B through electronic device 100, operator B issues eSIM2 corresponding to operator B to electronic device 100. That is, electronic device 100 can download profile2 (including the card information of eSIM2) corresponding to operator B from operator B's profile server.

[0117] In some embodiments of this application, electronic device 100 can activate at least one profile in eSIM module 195 and register on the network through the activated profile. For example, electronic device 100 can perform legitimacy authentication (also known as authorization) at the corresponding operator through the activated profile. After successful authentication, electronic device 100 is allowed to access the mobile communication network.

[0118] The hardware structure of the electronic device 200 and other electronic devices in the embodiments of this application can also be... Figure 1 The hardware structure shown.

[0119] It should be understood that the electronic device shown in the embodiments of this application is merely an example, and the electronic device may have more or fewer components than those shown in the above embodiments, may combine two or more components, or may have different component configurations. The various components shown in the figures can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits. For example, electronic device 200 may include not only... Figure 1 The eSIM module 195 shown may also include a SIM card interface for connecting one or more pSIMs. The pSIM can be inserted into or removed from the SIM card interface to make contact with and detach from the electronic device 200. The pSIM may include, but is not limited to, Nano SIM cards, Micro SIM cards, and SIM cards.

[0120] Figure 2 This is a schematic diagram of the architecture of a communication system 10 provided in an embodiment of this application.

[0121] like Figure 2 As shown, the communication system 10 may include electronic device 100, electronic device 200, cloud server 300, and mobile network operator (MNO) 400. MNO 400 may include an entitlement server (ES) 410, a business and operation support system (BOSS) 420, a configuration file server 430, an authentication, authorization, and accounting (AAA) server 440, and a home subscriber server (HSS) 450.

[0122] The ES410 can be used for identity authentication. The BOSS420 can manage profile subscription relationships. After any electronic device downloads the profile corresponding to the MNO400, if the BOSS420 has configured a subscription relationship for that profile for the electronic device, the electronic device can use that profile to establish network access. If the BOSS420 has not configured a subscription relationship for that profile for the electronic device, the electronic device cannot use that profile to establish network access. The configuration file server 430 can provide the download service for the profile corresponding to the MNO400. For example, the configuration file server 430 can be a subscription manager-data preparation server (SM-DP) or a subscription manager-data preparation plus server (SM-DP+). The AAA server 440 can provide authentication, authorization, and accounting services. For example, the AAA server 440 can include multiple servers such as the MNO authorization server (MNO). The MNO authorization server provides authentication services, while other servers provide authorization and accounting services. HSS450 can be used to provide services such as identity authentication, location lookup, and business authorization.

[0123] In this embodiment, electronic device 100 can be any of the following: mobile phone, tablet computer, handheld computer, desktop computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), smart home devices such as smart screens and smart speakers, wearable devices such as smart bracelets, smartwatches, and smart glasses, extended reality (XR) devices such as augmented reality (AR), virtual reality (VR), and mixed reality (MR), in-vehicle devices, or smart city devices, etc. Electronic device 200 is similar to electronic device 100 and will not be described in detail.

[0124] In some embodiments of this application, the cloud server 300 can provide application services for the first network application, and the electronic device 100 / 200 with the first network application installed can access the cloud server 300 and interact with the cloud server 300.

[0125] In some embodiments of this application, electronic device 100 / 200 can connect to one or more pSIMs. For example, a user purchases a pSIM corresponding to MNO400 and inserts the pSIM into the SIM card interface of electronic device 200. In some embodiments of this application, after electronic device 100 / 200 and MNO400 sign up, MNO400 can issue a corresponding eSIM to electronic device 100 / 200. That is, electronic device 100 / 200 can download a profile (including the card information of the eSIM corresponding to MNO400) from the configuration file server 430 in MNO400 and store it in the eSIM module.

[0126] In the migration scenario illustrated in this application embodiment, a user can "migrate" the pSIM / eSIM card information from electronic device 200 to electronic device 100. Electronic device 200 can be referred to as the source device, and electronic device 100 as the target device. For example, electronic device 200 might be the user's old mobile phone, and electronic device 100 might be the user's new mobile phone. It is understood that the above-described "migration" of the pSIM / eSIM card information from electronic device 200 to electronic device 100 is from the user's perspective. In actual implementation, electronic device 100, as the target device, may not obtain the migrated pSIM / eSIM card information from electronic device 200, but rather from the MNO corresponding to the migrated pSIM / eSIM. The migration scenario is illustrated below using MNO400 as an example.

[0127] In some examples, the pSIM in electronic device 200 may be purchased by the user at an offline outlet corresponding to MNO400. In a migration scenario where the user "migrates" the card information of the pSIM in electronic device 200 to electronic device 100, the configuration file server 430 in MNO400 can generate a profile corresponding to the migrated pSIM (including the card information of the migrated pSIM), and electronic device 100, as the target device, can download the profile from the configuration file server 430.

[0128] In some examples, the profile (including the eSIM card information) in the eSIM module of electronic device 200 can be downloaded by electronic device 200 from the configuration file server 430 in MNO400. In a migration scenario where a user "migrates" the eSIM card information from electronic device 200 to electronic device 100, electronic device 100, as the target device, can download the profile (including the migrated eSIM card information) corresponding to the eSIM from the configuration file server 430 in MNO400. The profile downloaded by electronic device 100 can be the same as the profile in the eSIM module of electronic device 200.

[0129] Not limited to the above examples, in other examples, users can also "migrate" the card information of the virtual SIM (vSIM) in electronic device 200 to electronic device 100. In this case, the electronic device as the target device can download the card information corresponding to the vSIM from the MNO. The embodiments of this application do not limit the type of SIM to be migrated.

[0130] It is understandable that in the migration scenario, regardless of the type of SIM being migrated, the SIM card information is being migrated. For ease of explanation, we will take the example of packaging the card information of a SIM card into a profile. Therefore, the migration in this application embodiment is a profile migration.

[0131] Currently, during profile migration, the source device needs to generate relevant supporting data in real time, such as the Integrated Circuit Card Identifier (ICCID) (e.g., used to identify the eSIM module), the Embedded UICCidentifier (EID) (e.g., used to identify the profile in the eSIM module), the Transfer Access Token, the Trust Flag, the Authentication and Key Agreement (AKA) Token, the AKA Token's Expiration Time, Scope, the Server's Uniform Resource Locator (URL), and the Device Name. The source device also needs to upload this supporting data to the cloud in real time. The target device then retrieves this supporting data from the cloud in real time and passes it through to the ES410 in the corresponding MNO (using MNO400 as an example) for authentication. After successful authentication, the ES410 and BOSS420 synchronize. The BOSS420 then changes the subscription configuration (changing the configuration device corresponding to the profile from the source device to the target device). The websheet server (not shown) in the MNO400 calls back the target device's system interface to allow the target device to download the profile. Furthermore, the profile migration process requires the following conditions to be met: both the source and target devices must be powered on and logged into the same account simultaneously; both devices must be connected to a Wi-Fi network simultaneously; both devices must be unlocked and operable; and the user must perform multiple migration-related operations on both devices (e.g., clicking confirmation controls). Therefore, the current profile migration process heavily relies on the source device, requiring it to be intact, online in real-time, transmitting proof data, and operable by the user. Additionally, the target device and websheet server require customized system interface (e.g., callback) configurations. The migration process has many limitations, requires users to perform cumbersome synchronization operations, and has low availability.

[0132] This application provides a profile migration method applicable to a communication system 10. This application embodiment utilizes a cloud server 300 to migrate profiles (taking the migration of the pSIM / eSIM profile from electronic device 200 to electronic device 100 as an example). During the profile migration process, electronic device 100, as the target device, can interact with the cloud server 300 and MNO400 to obtain a one-time password (OTP). The OTP can also be referred to as a verification code. Electronic device 100 can interact with the MNO400 via the OTP to download the pSIM / eSIM profile from the MNO400. For example, electronic device 100 can initiate a qualification review to ES410 in the MNO400 via the OTP. After successful qualification review, electronic device 100 can download the profile from the profile server 430. After successful qualification review, BOSS420 in the MNO400 can perform a subscription relationship configuration change (i.e., change the configuration device of the subscription relationship corresponding to the profile from the source device to the target device). Therefore, users can complete the migration operation securely and in a closed loop on the target device, no longer relying on the source device, and without requiring customization of the target device and MNO. This greatly reduces the limitations of migration, eliminates the need for users to perform cumbersome synchronization operations, and effectively improves usability and user experience.

[0133] In some embodiments of this application, before profile migration, electronic device 200 can interact with MNO400, cloud server 300, and MNO400, allowing cloud server 300 to obtain the user's mobile phone number (MSISDN, hereinafter referred to as phone number) of the pSIM / eSIM in electronic device 200 from MNO400. Subsequently, electronic device 100 can log in with the same account as electronic device 200 (e.g., the same account in the first network application) and access cloud server 300 to obtain the pSIM / eSIM phone number in electronic device 200. This allows the user to view the pSIM / eSIM phone number on electronic device 200 through electronic device 100 and select the phone number to migrate. Therefore, embodiments of this application do not require data interaction between the source and target devices; phone number synchronization can be achieved using cloud server 300.

[0134] Figure 3This is a schematic diagram of the architecture of another communication system 10 provided in the embodiments of this application.

[0135] like Figure 3 As shown, the communication system 10 may include electronic device 100, electronic device 200, cloud server 300, and MNO400. MNO400 may include ES410, BOSS420, configuration file server 430, AAA server 440, and HSS450. Related descriptions and... Figure 2 Similarly, I will not elaborate further.

[0136] like Figure 3 As shown, the architecture of electronic device 100 may include processor 101, mobile communication module 102, and eSIM module 103. Processor 101 may include an application layer, a framework layer, a radio interface layer (RIL), and attention (AT) commands.

[0137] The application layer can include one or more applications, such as Figure 3 The first network application and eSIM user experience (UX) shown can be used to implement eSIM-related user experiences (e.g., implementing a language user interface (LUI)). The eSIM UX can be a standalone application or integrated into other applications, such as the first network application. The application in this embodiment can also be replaced with other forms of software such as applets or atomic services.

[0138] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The framework layer can include some predefined functions. For example... Figure 3As shown, the framework layer may include a first network service, a first standard library, a local profile assistant (LPA) service, and a phone manager, etc. The first network service can be called by the first network application. The first network service can be used to implement communication between the first network application and other modules in the electronic device 100 besides the processor 101 (e.g., mobile communication module 102). The first standard library is, for example, but not limited to, a static library of the GSMA TS.43ES specification. This static library provides, for example, some pre-compiled functions that provide implementations of the interfaces defined in the GSMA TS.43ES specification. The first standard library can be called by the first network service. The LPA service can be used to manage profiles in the eSIM module 103, such as downloading, activating, deactivating, and deleting. The LPA service can obtain user operation events related to profiles from the application layer eSIM UX and manage profiles in the eSIM module 103 based on the obtained operation events. A phone manager can be used to provide communication functions for electronic devices 100, such as managing call status (including connection, hang-up, etc.).

[0139] RIL and AT commands can be used to enable communication between upper-layer services such as the application layer and framework layer and communication modules such as the mobile communication module 102. RIL can be understood as the middle layer of communication, and AT commands can be understood as communication instructions.

[0140] The mobile communication module 102 can be used to implement the mobile communication function of the electronic device 100. For example, the mobile communication module 102 includes a modem. A description of the eSIM module 103 can be found here. Figure 1 Description of eSIM module 195. In some embodiments of this application, mobile communication module 102 and eSIM module 103 can communicate via standard protocols (e.g., International Organization for Standardization (ISO) standards). In some embodiments of this application, upper-layer services such as application layer and framework layer can communicate with eSIM module 103 through mobile communication module 102. For example, LPA service communicates with eSIM module 103 through mobile communication module 102 to manage profiles in eSIM module 103.

[0141] In some embodiments of this application, any one of the profiles in the eSIM module 103 of the electronic device 100 can be activated, and the electronic device 100 can communicate with the Internet through the activated profile to realize user services such as making calls and accessing the Internet.

[0142] The architecture of electronic device 200 may include processor 201, mobile communication module 202 and eSIM module 203. The architecture of electronic device 200 is similar to that of electronic device 100, and will not be described in detail here. Figure 3 The architectures of electronic devices 100 and 200 shown are for illustrative purposes only and should not be construed as limiting.

[0143] like Figure 3 As shown, cloud server 300 may include an authentication system, a synchronization system, and an order management system. The authentication system is used to obtain an access token, which enables reliable communication between cloud server 300 and MNO400. The synchronization system is used to obtain and synchronize phone numbers. For example, when electronic device 200 logs into account 1, it obtains the phone number of electronic device 200. When electronic device 100 logs into account 1, it synchronizes the phone number of electronic device 200 to electronic device 100. This can be understood as synchronizing phone numbers between different devices under the same account. The order management system is used to manage package orders corresponding to phone numbers, such as obtaining and synchronizing package orders.

[0144] In the profile migration scenario shown in this application embodiment (taking the migration of the pSIM / eSIM profile in electronic device 200 to electronic device 100 as an example), before the profile migration, the cloud server 300 can obtain the phone number of the pSIM / eSIM in the source device electronic device 200. For a specific example, please refer to [link to example]. Figure 3 Steps 1-4 are shown. Furthermore, during the profile migration process, the pSIM / eSIM phone number in electronic device 200 can be synchronized from cloud server 300 to electronic device 100 (the target device). See the example below for details. Figure 3 Step 5 shown can also be implemented via cloud server 300 to allow electronic device 100 to download the pSIM / eSIM profile from electronic device 200 to MNO400. For a specific example, please refer to [link / reference needed]. Figure 3 Steps 6-8 are shown.

[0145] like Figure 3In step 1, as shown, electronic device 200 obtains an authentication token (AuthToken)1 from MNO400. When electronic device 200 includes a pSIM / eSIM corresponding to MNO400, it can interact with MNO400 to perform authentication and key agreement (AKA) authentication (e.g., Extensible Authentication Protocol-AKA, EAP-AKA). After successful AKA authentication, MNO400 can issue the authentication token (AuthToken)1 to electronic device 200. For example, electronic device 200 can call a first standard library implementation to perform AKA authentication with MNO400.

[0146] like Figure 3 In step 2, as shown, electronic device 200 obtains a new temporary token (NewTemporaryToken) from MNO400 based on AuthToken1. Electronic device 200 can interact with MNO400 based on AuthToken1 and receive the NewTemporaryToken sent by MNO400. For example, the first network service of electronic device 200 obtains the NewTemporaryToken from MNO400.

[0147] like Figure 3 In step 3 shown, electronic device 200 sends a NewTemporaryToken to cloud server 300. For example, electronic device 200 has a first network application installed, and cloud server 300 is a server that provides services for the first network application. The first network application of electronic device 200 sends a NewTemporaryToken to cloud server 300.

[0148] like Figure 3 In step 4, as shown, cloud server 300 obtains the phone number from MNO400 based on the NewTemporaryToken. Specifically, cloud server 300 obtains the AccessToken from MNO400. Cloud server 300 can then interact with MNO400 based on the NewTemporaryToken and AccessToken, and receive the phone number of electronic device 200 sent by MNO400 (specifically, the pSIM / eSIM phone number corresponding to MNO400 in electronic device 200).

[0149] Not limited to the above examples, in other examples, when the electronic device 200 also includes pSIM / eSIM corresponding to other MNOs, steps 1 to 4 above can be performed for the other MNOs (where MNO400 is replaced by other MNOs) so that the cloud server 300 can obtain the phone numbers of all pSIM / eSIMs in the electronic device 200.

[0150] like Figure 3 In step 5, when a user logs in to account 1 in the first network application of electronic device 100, cloud server 300 can send the phone number corresponding to account 1 to the first network application of electronic device 100. Account 1 can be the account used to log in to the first network application on electronic device 200. When a user logs in to account 1 in the first network application of electronic device 100, cloud server 300 can synchronize the phone number corresponding to account 1 to the first network application of electronic device 100. The phone number corresponding to account 1 can include the phone number of electronic device 200, which can include the phone number obtained in step 3. Electronic device 100 can display the phone number corresponding to account 1 in the first network application.

[0151] like Figure 3 In step 6, when the user selects the phone number 1 to be migrated in the first network application of electronic device 100, electronic device 100 can obtain an OTP from MNO400 through cloud server 300. The phone number 1 selected by the user to be migrated can be the pSIM / eSIM phone number in electronic device 200. Electronic device 100 can interact with cloud server 300 and MNO400. Cloud server 300 can interact with MNO400 based on AccessToken, and MNO400 can issue an OTP to electronic device 100 through cloud server 300.

[0152] like Figure 3 Step 7, as shown, involves electronic device 100 performing eligibility verification based on OTP. Electronic device 100 can interact with MNO400 via OTP, allowing MNO400 to perform eligibility verification. Upon successful verification, MNO400 allows electronic device 100 to download a profile. For example, after successful verification, MNO400 sends download information to electronic device 100, which may include the address information of configuration file server 430. After successful verification, BOSS420 in MNO400 can migrate the subscription configuration of phone number 1 to electronic device 100. For example, it can deactivate the subscription configuration of phone number 1 corresponding to electronic device 200 and activate the subscription configuration of phone number 1 corresponding to electronic device 100.

[0153] like Figure 3 In step 8, as shown, electronic device 100 downloads the profile from MNO400. Specifically, electronic device 100 can download the profile corresponding to phone number 1 from the configuration file server 430 in MNO400, thereby migrating the pSIM / eSIM profile in electronic device 200 to electronic device 100.

[0154] It is understandable that the OTP obtained by the target device may differ during the migration process of different profiles. For example, different target devices may obtain different OTPs, different source devices may have different OTPs, different migration numbers may have different OTPs, and different OTPs may be obtained at different times, etc. This can be understood as "one-time password," thus providing a high level of security.

[0155] The communication between the aforementioned electronic device 100 and the cloud server 300 and MNO400 can be achieved through the first standard library, as can the communication between the aforementioned electronic device 200 and the cloud server 300 and MNO400. The first standard library can be, but is not limited to, libraries of standard specifications such as TS.43ES. Therefore, the embodiments of this application are compatible with standard specifications and have a wider range of application scenarios.

[0156] In some embodiments of this application, the cloud server 300 can be understood as a mobile virtual network operator (MVNO). An MVNO can refer to an operator that does not need to apply for spectrum or build its own network, but instead wholesales network capacity from an MNO and provides mobile communication services to users under its own brand. Optionally, the cloud server 300 can provide application services for a first network application, which can provide MVNO services to users. The aforementioned connection between the cloud server 300 and the MNO 400 can be understood as an inter-operator connection.

[0157] Not limited to the above examples, in other examples, users may also choose to migrate the phone number corresponding to other MNOs. Therefore, steps 6 to 8 above can be performed for other MNOs (where MNO400 is replaced with other MNOs) so that electronic device 100 can download the profile corresponding to the phone number selected by the user for migration.

[0158] Understandable, Figure 2 and Figure 3The form and number of electronic devices 100, 200, cloud server 300, and MNO 400 shown are for illustrative purposes only. For example, there can be more source devices for profile migration, and the user can choose to migrate profiles corresponding to pSIM / eSIM on one or more source devices. For example, there can also be more target devices for profile migration. For example, there can be more profiles being migrated and they can belong to different MNOs; therefore, there can be more MNOs, which is not limited in this embodiment.

[0159] The following section provides examples of application scenarios for profile migration and the user interface within those scenarios.

[0160] Figures 4A-4K These are schematic diagrams of some user interfaces provided in the embodiments of this application.

[0161] like Figure 4A As shown, electronic device 100 (target device) can display user interface 410 of a first web application. In some examples, user interface 410 may be displayed by electronic device 100 in response to a user action performed on the application icon of the first web application on the home page of electronic device 100, for example, a touch action (such as a click action).

[0162] like Figure 4A As shown, the user interface 410 may include a status bar 411 at the top, a search bar 412, a recommendation list 413, a display bar 414, a trip bar 415, and a menu bar 416 at the bottom. The status bar 411 may include a pSIM / eSIM signal identifier 411A, battery level, and time information, wherein the signal identifier 411A indicates that the electronic device 100 is not currently connected to a mobile communication network. In some embodiments of this application, the provider of the first network application may purchase a seed card from an operator and provide the seed card to the user of the first network application, allowing the user to use the first network application normally even when not connected to other networks (e.g., in a user-perceived "no network" scenario). That is, the seed card's cost is pre-purchased by the provider of the first network application and does not need to be purchased by the user. The electronic device 100 with the first network application installed may download or pre-install the seed card's profile in the eSIM module. Therefore, although signal identifier 411A indicates that electronic device 100 is not currently connected to a mobile communication network, when electronic device 100 is running the first network application, it can use the profile of the seed card in the eSIM module to register on the network, thereby displaying the user interface of the first network application normally.

[0163] The search bar 412 is used to search for data plans for the desired destination. The recommendation list 413 is used to recommend data plans for different destinations. The display bar 414 is used to display one or more items, such as a summary of the "Outbound Internet Access Guide," and to view detailed information about the "Outbound Internet Access Guide." The itinerary bar 415 is used to view information related to the user's itinerary, such as purchased data plans. The menu bar 416 may include a "Recommended" control 416A and a "My" control 416B, where the "Recommended" control 416A is selected, indicating that the user interface 410 is currently displaying the page corresponding to the "Recommended" control 416A. The "My" control 416B can be used to trigger the display of user information, such as purchased data plans, order history, favorites, settings, etc. Users can purchase data plans for their desired destinations through the first network application, and users can activate purchased data plans to access the internet.

[0164] Users can log in to account 1 in the first network application of electronic device 100 (target device), for example through... Figure 4B The user interface 420 shown is for logging in account 1. Account 1 can be an account that the user has logged into in the first network application of the electronic device 200 (source device). The user interface 420 can be displayed after the user performs a series of operations based on the user interface of the first network application, such as user interface 410. In some examples, the electronic device 100 can display a schedule interface in response to a user operation (e.g., a click operation) on the schedule bar 415 in the user interface 410. If no account is logged in, the schedule interface can display controls for logging in. The electronic device 100 can display... Figure 4B The user interface 420 is shown. In other examples, the electronic device 100 may display the "My" interface in response to a user action (e.g., a click) performed on the "My" control 416B in the user interface 410. If no account is logged in, the "My" interface may display controls for logging in. The electronic device 100 may display... Figure 4B The user interface shown is 420.

[0165] like Figure 4B As shown, the user interface 420 may include a status bar 421 at the top, a login account input box 422, a username and password input box 423, a login control 424, a registration account control, and controls for other login methods. The status bar 421 and... Figure 4A The status bar 411 in the user interface 410 shown is similar and will not be described again.

[0166] After logging into account 1 in the first network application of electronic device 100 (target device), the user can view the data plan corresponding to account 1. Figure 4C An exemplary user interface 430 of a first web application after logging in with account 1 is shown. User interface 430 may include a status bar 431 at the top, account name 1 for account 1, order controls 433, and a menu bar 434 at the bottom, etc. Figure 4A The status bar 411 in the user interface 410 shown is similar and will not be described again. Menu bar 434 and... Figure 4A The menu bar 416 in the user interface 410 is similar, but the "My" control in the menu bar 434 is selected, indicating that the user interface 430 is currently displaying the page corresponding to the "My" control. The electronic device 100 can respond to user actions (e.g., clicks) applied to the order control 433 in the user interface 430, displaying the data plan corresponding to account 1, for example... Figure 4D The user interface shown is 440.

[0167] like Figure 4D As shown, the user interface 440 may include a status bar 441 at the top and the order for account 1. The status bar 441 and Figure 4A The status bar 411 in the user interface 410 shown is similar and will not be described again. Orders for account 1 can include data plans for account 1 and other orders. The data plans for account 1 shown in user interface 440 can include: data plans for phone numbers on this device (i.e., electronic device 100) (e.g., data plan 442 for phone number 11), and data plans for phone numbers on other devices. Taking electronic device 200 with the device name Device A as an example, data plans for phone numbers on other devices would include, for example, data plans for phone numbers 22 (443) and 33 (444).

[0168] Users can enable or disable data plans for any phone number on the device in the first network application of the electronic device 100. In some examples, the data plan 442 for phone number 11 on the electronic device 100 may include a switch control 442A, which can be used to enable or disable the data plan 442 for phone number 11 on the electronic device 100. The user interface 440 is illustrated with the data plan 442 for phone number 11 being in a disabled state (e.g., the switch control 442A displays the character "enabled").

[0169] Users can migrate phone numbers from other devices to this device in the first network application of electronic device 100, thereby using the data plans of the phone numbers on other devices on this device. In some examples, the data plan 443 for phone number 22 on device A (i.e., electronic device 200) may include a migration control 443A, and the data plan 444 for phone number 33 may also include a migration control 444A. The migration control 443A can be used to "migrate" the pSIM / eSIM corresponding to phone number 22 on electronic device 200 to electronic device 100. The migration control 444A can be used to "migrate" the pSIM / eSIM corresponding to phone number 33 on electronic device 200 to electronic device 100.

[0170] The data plan for account 1 in the first network application of electronic device 100 (target device) is... Figure 4D When the user interface 440 shows the status, the data plan for account 1 in the first network application of electronic device 200 (source device) can be... Figure 4E The user interface 450 shown illustrates the status. The user interface 450 may include a status bar 451 at the top and the data plan for account 1. The data plan for account 1 shown in the user interface 450 may include data plans for phone numbers on this device (i.e., electronic device 200), such as data plan 452 for phone number 22 and data plan 453 for phone number 33. The user interface 450 is illustrated with an example where data plan 452 for phone number 22 is enabled (e.g., the toggle control 452A displays the character "OFF") and data plan 453 for phone number 33 is disabled (e.g., the toggle control 453A displays the character "Enabled"). Therefore, electronic device 100 can access the mobile communication network via the pSIM / eSIM corresponding to phone number 22. In this case, the signal indicator 451A of the mobile communication network in the status bar 451 can represent the signal quality of the accessed mobile communication network, for example, indicating that the current access is to a fourth-generation (4G) mobile communication technology network with four signal bars (i.e., full bars).

[0171] The following explanation uses the example of a user selecting to migrate phone number 22 from electronic device 200 to electronic device 100 in the first network application of electronic device 100. Specifically, the explanation assumes that electronic device 200 has already activated / is currently using a data plan for phone number 22. Electronic device 100 can respond to actions... Figure 4D User actions (e.g., click actions) of the inbound control 443A in the user interface 440 shown are displayed. Figure 4F The user interface 460 is shown. User interface 460 may include a status bar 461 and a tooltip 462. The status bar 461 and... Figure 4AThe status bar 411 in the user interface 410 shown is similar and will not be described again. The prompt box 462 may include the prompt message "The transmitted phone number 22 is currently on device A under your account. Please confirm whether to migrate and enable it," a confirmation control 462A, and a cancellation control 462B. The confirmation control 462A can be used to confirm the migration, and the cancellation control 462B can be used to cancel the migration. The electronic device 100 may respond to a user operation (e.g., a click operation) acting on the confirmation control 462A in the user interface 460 by displaying a migration verification interface, such as displaying... Figure 4G The user interface 470 is shown. The user interface 470 may include a message bar 471 and a prompt box 472. The message bar 471 can be used to display a verification code received by the electronic device 100. This verification code may be an OTP issued by the MNO corresponding to the migrated phone number 22. The electronic device 100 receives this verification code, for example, but not limited to, through a system SMS application or a first network application. The prompt box 472 may include a verification code input box 472A, a confirmation control 472B, and a cancellation control 472C. The user can manually input the verification code from the message bar 471 into the input box 472A in the prompt box 472, or the electronic device 100 can automatically input the verification code from the message bar 471 into the input box 472A in the prompt box 472. The confirmation control 472B can be used to trigger the continuation of the migration. The cancellation control 472C can be used to cancel the migration. The electronic device 100 can continue the migration in response to a user operation (e.g., a click) applied to the confirmation control 472B. During the migration process, the following can be displayed: Figure 4H The user interface 480 shown can then be displayed. Figure 4I The user interface shown is 490.

[0172] Figure 4H The user interface 480 shown and Figure 4D The user interface 440 shown is similar, but in user interface 480, the data plans for the phone numbers on this device (i.e., electronic device 100) include not only data plan 442 for phone number 11, but also data plan 443 for phone number 22 migrated from electronic device 200. The data plans for the phone numbers on electronic device 200 (device name: Device A) include data plan 444 for phone number 33. Data plan 443 shown in user interface 480 does not include a migration control 443A, but instead includes a loading control 443B, which indicates that data plan 443 for phone number 22 is currently being migrated and enabled.

[0173] Figure 4I The user interface 490 shown is... Figure 4HThe user interface 480 is similar, but in user interface 490, the data plan 443 for phone number 22 does not include a loading control 443B, but instead includes a switch control 443C, which can be used to enable or disable the data plan 443 for phone number 22. The data plan 443 in user interface 490 is enabled (e.g., the switch control 443C displays the character "OFF"). Therefore, electronic device 100 can access the mobile communication network via the pSIM / eSIM corresponding to phone number 22. At this time, the signal indicator 491A of the mobile communication network in the status bar 491 shown in user interface 490 can represent the signal quality of the accessed mobile communication network, for example, indicating that the current access is to a 4G network with 4 signal bars (i.e., full bars).

[0174] The data plan for account 1 in the first network application of electronic device 100 (target device) is... Figure 4H When the user interface 480 shows the status, the data plan for account 1 in the first network application of electronic device 200 (source device) can be... Figure 4J The user interface 500 shown is displaying the status. Figure 4J The user interface 500 shown and Figure 4E The user interface 450 shown is similar, but in user interface 500, the mobile network signal indicator 501A in the status bar 501 indicates that the electronic device 100 is not currently connected to a mobile network. User interface 500 may also include a "Loading" message 502, indicating that order information is currently being refreshed and loaded. The toggle control 452A for the data plan 452 of phone number 22 and the toggle control 453A for the data plan 453 of phone number 33 in user interface 500 are unavailable (e.g., grayed out) and therefore cannot be operated. It is understood that although the signal indicator 501A indicates that the electronic device 100 is not currently connected to a mobile network, the electronic device 100 can use the seed card profile in the eSIM module to register on the network, thereby refreshing and loading order information. The refreshed and loaded order information can be found in [link to relevant documentation]. Figure 4K The user interface 510 shown.

[0175] The data plan for account 1 in the first network application of electronic device 100 (target device) is... Figure 4I When the user interface 490 shows the status, the data plan for account 1 in the first network application of electronic device 200 (source device) can be... Figure 4K The user interface 510 shown is displaying the status. Figure 4K The user interface 510 shown is... Figure 4EThe user interface 450 shown is similar, but in user interface 510, the mobile network signal identifier 511A in the status bar 511 indicates that electronic device 100 is not currently connected to a mobile network. Furthermore, in user interface 510, the data plan for the phone number on this device (i.e., electronic device 200) only includes data plan 453 for phone number 33, while data plan 452 for phone number 22 is the data plan for the phone number on another device (i.e., electronic device 100 with device name B). Data plan 452 does not include a toggle control 452A, but instead includes a migration control 452B, which can be used to "migrate" the pSIM / eSIM corresponding to phone number 22 on electronic device 100 to electronic device 200.

[0176] The above example illustrates the application scenario using the default enabled data plan for the migrated phone number. In other examples, the data plan for the migrated phone number may not be enabled by default, and the user can choose whether to enable the data plan for the migrated phone number after the migration is successful. In other examples, the user may be prompted during the migration process and choose whether to enable the data plan for the migrated phone number based on the user's response. This application embodiment does not limit this.

[0177] In the application scenario described above, electronic device 100 can... Figure 4F The user interface 460 shown in the figure prompts the user whether to perform the migration. In some other examples, the user may not be prompted and the user may be directly confirmed to perform the migration. This application embodiment does not limit this.

[0178] In the application scenario described above, electronic device 100 can... Figure 4G The user interface 470 shown presents the OTP to the user as a verification code, allowing the user to input it. In other examples, it may not be presented to the user, and no user input is required. The electronic device 100 can automatically migrate after receiving the OTP. This application embodiment does not limit this.

[0179] The above example uses electronic devices 100 and 200 as examples to illustrate the application scenario of logging into account 1. In a specific implementation, more devices can log into account 1. Therefore, the data plan for account 1 displayed on electronic device 100 can include data plans for phone numbers on more devices. Users can choose to migrate data plans for phone numbers on one or more devices.

[0180] The above example illustrates the application scenario of synchronizing a phone number from electronic device 200 to electronic device 100. Therefore, in the example above, the data plan for account 1 in the first network application displayed on electronic device 200 only shows the data plan for the phone number on electronic device 200. For example, if cloud server 300 does not obtain the phone number from electronic device 100, it cannot synchronize the phone number from electronic device 100 to electronic device 200. In other examples, the phone number from electronic device 100 can also be synchronized to electronic device 200. In this case, the data plan for account 1 in the first network application displayed on electronic device 200 may also include the data plan for the phone number on electronic device 100, and the user can also select to migrate the data plan for the phone number on electronic device 100 on electronic device 200. This application embodiment does not limit this.

[0181] In the above example application scenario, users can view phone number information on this device and other devices in the first network application, and can select the phone number to be migrated and trigger the migration in the first network application. However, this is not the only example. In other examples, it can also be implemented in the system settings application (e.g., through the SIM card management function in the settings application). This application embodiment does not limit the specific implementation location of viewing phone numbers and performing migration.

[0182] Not limited to the user interface in the above examples, in other examples, the signal identifier of the mobile communication network in the user interface may also be the signal identifier of the operator of the current location, indicating that the user is not connected to the mobile communication network corresponding to that operator. This application embodiment does not limit this.

[0183] The implementation process of the configuration file migration method provided in this application embodiment is described below by way of example. This application embodiment takes the migration of the pSIM / eSIM profile in electronic device 200 (source device) to electronic device 100 (target device) as an example for illustration.

[0184] Firstly, through Figure 5 An example describes how electronic device 200 obtains AuthToken1 (i.e., AuthToken1) from MNO400 before profile migration. Figure 3 The implementation process of step 1) shown.

[0185] Figure 5 This is a flowchart illustrating a configuration file migration method provided in an embodiment of this application. This method can be applied to... Figure 2 The electronic devices 200 and MNO400 in the communication system 10 shown. This method can also be applied to... Figure 3 The communication system 10 shown includes electronic devices 200 and MNO400. The method may include, but is not limited to, the following steps:

[0186] S101: Electronic device 200 sends a configuration request to ES410 in MNO400.

[0187] S102: ES410 in MNO400 sends a challenge request to AAA server 440 in MNO400.

[0188] S103: AAA server 440 in MNO400 requests the authentication vector (AV) from HSS450 in MNO400.

[0189] S104: HSS450 sends AV to AAA server 440.

[0190] In some embodiments of this application, electronic device 200 can initiate AKA authentication with MNO400 to obtain AuthToken1. AuthToken1 can be used to encrypt and protect communication between electronic device 200 and MNO400. AKA authentication can provide a secure user authentication and key negotiation mechanism to protect communication in wireless networks such as mobile communication networks. Specifically, electronic device 200 can initiate AKA authentication by sending a configuration request to ES410 (i.e., executing S101). The configuration request can carry information about the pSIM / eSIM corresponding to MNO400 in electronic device 200, such as the user identifier (e.g., International Mobile Subscriber Identity (IMSI)) and key (e.g., authentication key (Ki) and / or authentication key OPC) from the pSIM / eSIM card information.

[0191] In some embodiments of this application, ES410 can send a challenge request to AAA server 440 based on the configuration request sent by electronic device 200 (i.e., execute S102). AAA server 440 can request AV from HSS450 based on the challenge request (i.e., execute S103). HSS450 can generate AV and send the generated AV to AAA server 440 (i.e., execute S104). The AV can be used for key negotiation; for example, S105-S110 below describes a key negotiation process based on AV.

[0192] In some examples, AV is a quintuple vector. AV can include the following five vectors: random challenge (RAND), authentication token (AUTN), expected response (XRES), cipher key (CK), and integrity key (IK).

[0193] S105: AAA server 440 obtains authentication token (AUTH) 1 and message authentication code (message authentication code) 1 based on AV.

[0194] In some embodiments of this application, AUTH1 may be AUTH in AV. MAC1 may be generated based on the pSIM / eSIM key (such as Ki) sent by electronic device 200, RAND in AV, and AUTH.

[0195] S106: AAA server 440 sends AUTH1 and MAC1 to electronic device 200 via ES410.

[0196] Specifically, the AAA server 440 can send AUTH1 and MAC1 to the ES410, and the ES410 can send AUTH1 and MAC1 to the electronic device 200. In some embodiments of this application, the AAA server 440 can also send RAND from AV to the electronic device 200 via the ES410.

[0197] S107: Electronic device 200 verifies AUTH1 and MAC1 and generates a response (RES) and MAC2.

[0198] In some embodiments of this application, the electronic device 200 can calculate MAC2 based on the pSIM / eSIM key (e.g., Ki) corresponding to MNO400 in the electronic device 200, the received AUTH1, and RAND, and verify whether the calculated MAC2 is the same as the received MAC1. When MAC2 and MAC1 are the same, the electronic device 200 can determine that the verification is successful. Therefore, the electronic device 200 can generate RES based on the pSIM / eSIM key (e.g., Ki) corresponding to MNO400 in the electronic device 200 and the received RAND. Figure 5 The following explanation uses a successful verification as an example. However, it is not limited to this; in other examples, when MAC2 and MAC1 are different, electronic device 200 can determine that the verification failed, and therefore may not generate a RES or execute subsequent procedures.

[0199] S108: Electronic device 200 sends RES and MAC2 to AAA server 440 via ES410.

[0200] Among them, electronic device 200 can send RES and MAC2 to ES410, and ES410 can send RES and MAC2 to AAA server 440.

[0201] S109: AAA server 440 verifies RES and MAC2, and generates AuthToken1 upon successful verification.

[0202] In some embodiments of this application, the AAA server 440 can verify whether the received RES and XRES in AV are the same. When RES and XRES are the same, the electronic device 200 can determine that the verification is successful; when RES and XRES are different, the electronic device 200 can determine that the verification has failed. Optionally, the AAA server 440 can also verify whether the received MAC2 and MAC1 are the same. When MAC2 and MAC1 are the same, and RES and XRES are the same, the electronic device 200 can determine that the verification is successful. When MAC2 and MAC1 are different, and / or RES and XRES are different, the electronic device 200 can determine that the verification has failed. When the verification is successful, the AAA server 440 can generate the key AuthToken1 obtained in this negotiation process.

[0203] S110: AAA server 440 sends AuthToken1 to electronic device 200 via ES410.

[0204] Among them, AAA server 440 can send AuthToken1 to ES410, and ES410 can send AuthToken1 to electronic device 200.

[0205] In some embodiments of this application, the AAA server 440 sends an AKA authentication success response (e.g., EAP-Success) to the electronic device 200 via ES410. This success response may carry AuthToken1. The electronic device 200 can determine that the AKA authentication was successful based on the success response.

[0206] Figure 5 The process shown is for illustrative purposes only. For other implementation examples, please refer to the implementation process of AKA or other authentication protocols. This application embodiment does not limit the specific method by which the electronic device 200 obtains AuthToken1 from MNO400.

[0207] The following is through Figure 6This example demonstrates how cloud server 300 obtains the pSIM / eSIM phone number from electronic device 200 (source device) before profile migration. Figure 3 The implementation process of steps 2-4 is shown below.

[0208] Figure 6 This is a flowchart illustrating another configuration file migration method provided in this application embodiment. This method can be applied to... Figure 2 The communication system 10 shown includes electronic device 200, cloud server 300, and MNO400. This method can also be applied to... Figure 3 The communication system 10 shown includes electronic device 200, cloud server 300, and MNO400. The method may include, but is not limited to, the following steps:

[0209] S201: The first network application in electronic device 200 sends a token request (to obtain a temporary token, carrying AuthToken1) to ES410 in MNO400.

[0210] S202: ES410 sends a token response (carrying a new temporary token) to the first network application in electronic device 200.

[0211] In some embodiments of this application, Figure 6 Before the illustrated process (i.e., before S201), electronic device 200 can obtain AuthToken1 from MNO400. In some examples, electronic device 200 can perform AKA authentication with MNO400, and if AKA authentication is successful, electronic device 200 can receive AuthToken1 issued by MNO400. See the specific implementation example for details. Figure 5 The process is shown below.

[0212] In some embodiments of this application, the token request and token response can be request and response messages in protocols such as Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). Specifically, the HTTP / HTTPS request message can be used by a client (e.g., the first network application) to request data from a server (e.g., MNO400), and the response message can be used by the server to return corresponding data to the client. For example, the token request can be a GET request or a POST request in HTTP / HTTPS.

[0213] In some embodiments of this application, the token request may carry operation information, which may instruct the first network application in the electronic device 200 to request an operation, i.e., instruct the first network application to request a temporary token. In some embodiments of this application, the token request may carry identification information, which may be the identifier of the pSIM / eSIM corresponding to the MNO400 in the electronic device 200, such as the International Mobile Equipment Identity (IMEI). Alternatively, the identification information may also be the identifier of the first network application in the electronic device 200, such as a universally unique identifier (UUID). In some embodiments of this application, the token request may carry a token, which may be AuthToken1.

[0214] In some examples, a token request can be a GET / POST request like this: GET / POST ap2009,operation=AcquireTemporaryToken,terminal_id= <imeisim> or <uuidapp>,token= <authtoken1>The token request includes the following information: `operation` contains the operation information carried in the token request, and its value is `AcquireTemporaryToken`, instructing the first network application to request a temporary token. `terminal_id` contains the identification information carried in the token request, and its value is `IMEIsim`, where `IMEIsim` is the IMEI of the pSIM / eSIM corresponding to the MNO400 in electronic device 200. Alternatively, `terminal_id` can be `UUIDapp`, where `UUIDapp` is the UUID of the first network application in electronic device 200. `token` is the token carried in the token request, and its value is `AuthToken1`.

[0215] In some embodiments of this application, the token response may carry a status code, which can be an HTTP / HTTPS status code indicating the response status to the token request. In some embodiments of this application, the token response may carry a TemporaryToken, which can be a NewTemporaryToken. Optionally, the token response may also carry the expiry date of the TemporaryToken. Optionally, the token response may also carry the Operation Targets of the TemporaryToken, which indicate the operations that the TemporaryToken can be used to perform.

[0216] In some examples, the token response can be the following: 200 OK, TemporaryToken = NewTemporaryToken, TemporaryTokenExpiry = NewTemporaryTokenExpiry, OperationTargets = GetPhoneNumber. Here, 200 OK is the status code carried in the token response, indicating that the token request has been successfully processed. TemporaryToken is the TemporaryToken carried in the token response, and its value is NewTemporaryToken. TemporaryTokenExpiry is the expiration date of the TemporaryToken carried in the token response, and its value is NewTemporaryTokenExpiry, which represents the expiration date of the NewTemporaryToken. OperationTargets is the operation target of the TemporaryToken carried in the token response, and its value is GetPhoneNumber, indicating that the TemporaryToken can be used to perform the operation of obtaining a phone number.

[0217] S203: The first network application in electronic device 200 sends a token message (carrying NewTemporaryToken) to cloud server 300.

[0218] In some embodiments of this application, the token message can be a message in a protocol such as HTTP / HTTPS. For example, a first network application can send a token message to the cloud server 300 through an HTTP / HTTPS channel between the first network application and the cloud server 300.

[0219] In some embodiments of this application, the token message may carry a TemporaryToken, which may be a NewTemporaryToken obtained by the first network application from the aforementioned token response. Optionally, the token message may also carry the expiry date of the TemporaryToken. Optionally, the token message may also carry the Operation Targets of the TemporaryToken, which may instruct the first network application in the electronic device 200 to perform an operation requested based on the TemporaryToken. For example, the Operation Targets carried in the token message may be determined according to the Operation Targets carried in the aforementioned token response, such as the two being the same.

[0220] In some examples, the token message can be the following: 200 OK, TemporaryToken = NewTemporaryToken, TemporaryTokenExpiry = NewTemporaryTokenExpiry, OperationTargets = GetPhoneNumber. Here, 200 OK is the status code carried in the token message, for example, indicating successful sending of NewTemporaryToken. TemporaryToken is the TemporaryToken carried in the token message, and its value is NewTemporaryToken. TemporaryTokenExpiry is the expiration date of the TemporaryToken carried in the token message, and its value is NewTemporaryTokenExpiry (i.e., the expiration date of NewTemporaryToken). OperationTargets is the operation target carried in the token message, and its value is GetPhoneNumber, instructing the first network application to request a phone number based on the TemporaryToken in the token message.

[0221] S204: Cloud server 300 sends an access request message to ES410 in MNO400.

[0222] S205: AAA server 440 in MNO400 sends an access token 1 to cloud server 300.

[0223] In some embodiments of this application, the access request message can be used to request to obtain an AccessToken.

[0224] In some embodiments of this application, after receiving the access request message sent by the cloud server 300, the ES410 can synchronously send it to the AAA server 440, so that the AAA server 440 sends AccessToken1 to the cloud server 300.

[0225] In some embodiments of this application, the access request message may carry the client identifier (client_id) and client password (client_secret) for the cloud server 300 to access the MNO400. The ES410 may send the client_id and client_secret to the AAA server 440 for authentication. If the authentication is successful, the AAA server 440 may send AccessToken1 to the cloud server 300; if the authentication fails, the AAA server 440 may choose not to send AccessToken1 to the cloud server 300.

[0226] S206: Cloud server 300 sends a number request to ES410 in MNO400 (to obtain the phone number, carrying NewTemporaryToken and AccessToken1).

[0227] In some embodiments of this application, the number request can be a request message in protocols such as HTTP / HTTPS. In some embodiments of this application, the number request can carry identification information of the requesting party, which can be a UUID in the cloud server 300, such as the UUID of the first network application corresponding to the cloud server 300. In some embodiments of this application, the number request can carry operation information, which can instruct the cloud server 300 to request an operation, i.e., instruct the cloud server 300 to request a phone number. In some embodiments of this application, the number request can carry an AccessToken, which can be AccessToken1. In some embodiments of this application, the number request can carry a TemporaryToken, which can be NewTemporaryToken.

[0228] In some examples, a number request can be a GET / POST request like this: GET / POST ap2014,requester_id= <uuid1>,AccessToken= <accesstoken1>The configuration is as follows: operation = GetPhoneNumber, TemporaryToken = NewTemporaryToken. Here, requester_id is the identifier of the requesting party carried in the number request; its value is UUID1, where UUID1 is the UUID of the first network application. AccessToken is the AccessToken carried in the number request; its value is AccessToken1. operation contains the operation information carried in the number request; operation is set to GetPhoneNumber, instructing the cloud server to request the phone number via a 300 hotline. TemporaryToken is the TemporaryToken carried in the number request; its value is NewTemporaryToken.

[0229] In some embodiments of this application, after receiving a token message from the electronic device 200, the cloud server 300 can generate and send a number request based on the NewTemporaryToken carried in the token message, the optional expiration date of the NewTemporaryToken, and the operation target. The cloud server 300 may send the number request before the expiration date of the NewTemporaryToken. The cloud server 300 can determine the operation information in the number request based on the operation target of the NewTemporaryToken.

[0230] In some embodiments of this application, the cloud server 300 may obtain AccessToken1 from MNO400 before sending a number request, that is, execute S204-S205 before S206. However, the order of any of the steps in S204-S205 and S201-S203 is not limited.

[0231] S207: ES410 in MNO400 verifies the validity of AccessToken1 through AAA server 440.

[0232] S208: ES410 verification of NewTemporaryToken in MNO400.

[0233] In some embodiments of this application, after receiving a number request, ES410 can verify the validity of AccessToken1 carried in the number request through AAA server 440. Furthermore, after receiving a number request, ES410 can independently verify whether the NewTemporaryToken carried in the number request is a previously issued NewTemporaryToken. Optionally, ES410 can also verify whether the time of receiving the number request exceeds the validity period of the NewTemporaryToken (i.e., the validity period of the NewTemporaryToken carried in the token response). Optionally, ES410 can also verify whether the operation information carried in the number request matches the operation target of the NewTemporaryToken (i.e., the operation target of the NewTemporaryToken carried in the token response). When AccessToken1 is valid and the NewTemporaryToken verification is successful, MNO400 can send at least one phone number corresponding to the NewTemporaryToken to cloud server 300, i.e., execute S209-S210. When AccessToken1 is invalid and / or the NewTemporaryToken verification fails, MNO400 may not send a phone number to cloud server 300.

[0234] The verification of NewTemporaryToken includes: the NewTemporaryToken carried in the number request is a previously issued NewTemporaryToken; optionally, the time of the number request does not exceed the validity period of the NewTemporaryToken; and optionally, the operation information carried in the number request matches (e.g., the same) the operation target of the NewTemporaryToken.

[0235] S209: ES410 in MNO400 sends a number lookup request to BOSS420.

[0236] S210: BOSS420 in MNO400 sends at least one phone number to cloud server 300 via ES410.

[0237] In some embodiments of this application, when the ES410 successfully verifies the AccessToken1 and NewTemporaryToken carried in the number request, it can send a Phone Number Query Request to the BOSS420. The BOSS420 can then query at least one phone number corresponding to the NewTemporaryToken from among multiple numbers corresponding to the MNO400 based on the number query request, and send this at least one phone number to the cloud server 300 via the ES410. The phone number corresponding to the NewTemporaryToken is the pSIM / eSIM (corresponding to the MNO400) phone number in the electronic device 200 that issued the NewTemporaryToken to the MNO400.

[0238] In some embodiments of this application, at least one phone number sent by ES410 to cloud server 300 may be encrypted using AccessToken1. After receiving the encrypted phone number sent by ES410, cloud server 300 can decrypt it using AccessToken1 to obtain at least one phone number corresponding to NewTemporaryToken.

[0239] in, Figure 6 S201-S202 and shown Figure 3 This corresponds to step 2 shown. Figure 6 S203 and shown Figure 3 This corresponds to step 3 shown. Figure 6 S204-S205 and shown Figure 3 The cloud server 300 shown obtains the corresponding AccessToken from MNO400. Figure 6 S206-S210 and shown Figure 3 This corresponds to step 4 shown.

[0240] Next, through Figure 7 An example of the profile migration process (i.e.) Figure 3 The implementation process of steps 5-8 is shown.

[0241] Figure 7 This is a flowchart illustrating another configuration file migration method provided in this application embodiment. This method can be applied to... Figure 2 The communication system 10 shown includes electronic device 100, cloud server 300, and MNO400. This method can also be applied to... Figure 3 The communication system 10 shown includes electronic device 100, cloud server 300, and MNO400. The method may include, but is not limited to, the following steps:

[0242] S301: When the first network application in electronic device 100 logs in to account 1, cloud server 300 sends the phone number corresponding to account 1 (including the phone number of electronic device 200) to the first network application.

[0243] S302: The first network application in electronic device 100 displays the phone number corresponding to account 1.

[0244] In some embodiments of this application, Figure 7 Before the process shown (i.e., before S301), cloud server 300 can obtain the phone number corresponding to account 1. The phone number corresponding to account 1 can include the pSIM / eSIM phone number of the electronic device that logged into account 1 before S301. Specifically, if electronic device 200 has logged into account 1, cloud server 300 can obtain the pSIM / eSIM phone number from electronic device 200. For a detailed implementation example, please refer to [link to implementation example]. Figure 6 The process is shown below.

[0245] In some embodiments of this application, the first network application can detect the user's login operation in the first network application, for example, the user can... Figure 4B The user interface 420 shown represents a login account. The first network application can obtain the user-inputted account 1 and corresponding password based on the above operations. The first network application can send a login request to the cloud server 300, which can carry the user-inputted account 1 and corresponding password. The cloud server 300 can authenticate the account 1 and corresponding password carried in the login request and send the authentication result (e.g., authentication successful or authentication failed) to the first network application. When the authentication result is successful, the cloud server 300 can send the phone number corresponding to account 1 to the first network application.

[0246] In some embodiments of this application, the electronic device 100 can display the phone number corresponding to account 1 sent by the cloud server 300, and can also display the phone number of the pSIM / eSIM in the electronic device 100, for example, displaying Figure 4D The user interface 440 shown. The phone number sent by the cloud server 300 corresponding to account 1 includes the pSIM / eSIM phone number from other electronic devices (logged into account 1) besides electronic device 100.

[0247] S303: The first network application in electronic device 100 receives the telephone number 1 of electronic device 200 as user input to electronic device 100.

[0248] In some embodiments of this application, the first network application can receive user input to migrate the phone number 1 of electronic device 200 to electronic device 100, and determine, based on the user input, that the profile corresponding to phone number 1 needs to be obtained (which can also be understood as migrating the profile corresponding to phone number 1 in electronic device 200 to electronic device 100), and therefore can execute the following S304. Here, phone number 1 can be the pSIM / eSIM phone number corresponding to MNO400 in electronic device 200.

[0249] In some examples, the first network application receiving user input from the mobile electronic device 200 via telephone number 1 to the mobile electronic device 100 includes: the mobile electronic device 100 can receive input from the mobile electronic device 200 via... Figure 4D The user operation of the import control 443A in the user interface 440 is shown, and the display is shown in response to the user operation. Figure 4F The user interface 460 is shown; then, the electronic device 100 can receive user operations applied to the confirmation control 462A in the user interface 460. The telephone number 22 of the electronic device 200 corresponding to the migration control 443A is the telephone number 1 selected by the user for migration.

[0250] S304: The first network application in electronic device 100 sends a migration request (carrying telephone number 1) to cloud server 300.

[0251] In some embodiments of this application, a migration request can be used to request the migration of telephone number 1 from electronic device 200 to electronic device 100. However, the migration request is not limited to this; it can also be used to request the retrieval / migration of the profile corresponding to telephone number 1. In some embodiments of this application, after receiving a migration request from electronic device 100, cloud server 300 can subsequently send an OTP sent by MNO to electronic device 100, as detailed in S307-S310 below.

[0252] In some embodiments of this application, the migration request can be a message in a protocol such as HTTP / HTTPS. For example, a first network application can send a migration request to the cloud server 300 through an HTTP / HTTPS channel between the first network application and the cloud server 300.

[0253] S305: Cloud server 300 sends an access request message to ES410 in MNO400.

[0254] S306: AAA server 440 in MNO400 sends an access token 2 to cloud server 300.

[0255] Figure 7 S305-S306 and Figure 6 Similar to S204-S205, they will not be described in detail here.

[0256] Figure 7 Steps S305-S306 are optional. In some embodiments of this application, after the cloud server 300 receives a migration request from the first network application in the electronic device 100, it can obtain AccessToken2 from the MNO400 (i.e., execute S305-S306) for use in executing subsequent steps (e.g., S310). In this case, Figure 6 S204-S205 and Figure 7 S305-S306 can be processes for obtaining AccessToken executed at different times; therefore, AccessToken1 and AccessToken2 can be the same or different. In some other embodiments of this application, after receiving a migration request from the first network application in the electronic device 100, the cloud server 300 may not obtain AccessToken from MNO400, i.e., it may not execute S305-S306. The cloud server 300 can use AccessToken2 previously obtained from MNO400 to execute subsequent steps (e.g., S310). For example, AccessToken2 is the same as AccessToken1 mentioned above, and the process by which the cloud server 300 previously obtained AccessToken2 from MNO400 is... Figure 6 S204-S205.

[0257] S307: The first network application in electronic device 100 sends an OTP request (carrying telephone number 1) to ES410 in MNO400.

[0258] S308: ES410 in MNO400 sends encrypted information to cloud server 300 (i.e., obtained by encrypting OTP1 through AccessToken2).

[0259] S309: ES410 in MNO400 sends an OTP response to the first network application in electronic device 100.

[0260] S310: Cloud server 300 uses AccessToken2 to decrypt the encrypted information to obtain OTP1.

[0261] S311: Cloud server 300 sends OTP1 to the first network application in electronic device 100.

[0262] In some embodiments of this application, an OTP request can be used to request and obtain OTP. An OTP response can be a response message returned based on the OTP request. In some embodiments of this application, the OTP request and OTP response can be request and response messages in protocols such as HTTP / HTTPS, respectively. OTP can also be referred to as a verification code.

[0263] In some embodiments of this application, the OTP request may carry identification information, which may be the identifier of the pSIM / eSIM (e.g., corresponding to MNO400) in the electronic device 100 (e.g., IMEI), or the identifier of the first network application in the electronic device 100 (e.g., UUID). In some embodiments of this application, the OTP request may carry the phone number that the user chooses to migrate, i.e., phone number 1.

[0264] In some examples, an OTP request can be a GET / POST request like this: GET / POST ap2009,terminal_id= <imeisim> or <uuidapp>,msisdn= <msisdnsubs>Wherein, terminal_id is the identification information carried in the OTP request, and the value of terminal_id is IMEIsim, where IMEIsim is the IMEI of the pSIM / eSIM in electronic device 100. Alternatively, terminal_id can be valued as UUIDapp, where UUIDapp is the UUID of the first network application in electronic device 100. msisdn is the user-selected migration phone number carried in the OTP request, and the value of msisdn is MSISDNsubs, where MSISDNsubs is the phone number 1.

[0265] In some embodiments of this application, the OTP response may carry a status code, which can be an HTTP / HTTPS status code indicating the response status to the OTP request. Specifically, when the ES410 sends encrypted information to the cloud server 300 after receiving an OTP request, the ES410 may send an OTP response to the first network application in the electronic device 100. The status code in this OTP response may indicate successful processing of the OTP request, or it may indicate that the data requested by the OTP request (i.e., OTP1) has been returned; for example, the status code in this case is "200 OK". Optionally, the OTP response may also carry data (cookies) stored on the local terminal, so that the electronic device 100 can subsequently initiate requests to the ES410 based on the cookies. OTP1 can also be referred to as verification code 1.

[0266] In some embodiments of this application, after receiving the encrypted information sent by ES410, the cloud server 300 can use AccessToken2 to decrypt the encrypted information to obtain OTP1. Then, the cloud server 300 can send OTP1 to the first network application in the electronic device 100 that sent the migration request, for example, via an HTTP / HTTPS channel.

[0267] Understandably, after MNO400 receives the OTP request (carrying phone number 1) from electronic device 100, since MNO400 only knows that phone number 1 belongs to electronic device 200 and cannot determine whether electronic device 100 is trustworthy, MNO400 will send OTP1 to the trusted cloud server 300. If electronic device 100 receives OTP1 from cloud server 300, then electronic device 100 is a trusted device; if electronic device 100 cannot receive OTP1 from cloud server 300, then electronic device 100 is not a trusted device. Alternatively, it can be understood that if electronic device 100 is a trusted device, it will receive OTP1 from cloud server 300; if electronic device 100 is not a trusted device, it will not receive OTP1 from cloud server 300.

[0268] In some embodiments of this application, after receiving OTP1 sent by cloud server 300, electronic device 100 can display a notification to inform the user that OTP1 has been received. This notification may include OTP1. Furthermore, a first network application in electronic device 100 can display an input box for the user to input OTP1. See specific examples for details. Figure 4G The user interface 470 is shown. When the first network application detects OTP1 entered by the user based on the input box, the first network application can perform a migration eligibility check based on OTP1, i.e., execute S311. Not limited to this, in some other embodiments of this application, the electronic device 100 can also directly perform a migration eligibility check based on OTP1.

[0269] In some examples, when electronic device 100 receives OTP1 sent by cloud server 300 through an application other than the first network application (e.g., SMS), a corresponding notification can be displayed, and an input box (for entering OTP1) can be displayed through the first network application. The user can enter OTP1 into the input box, or electronic device 100 can automatically enter OTP1 after recognizing it. In other examples, when electronic device 100 receives OTP1 sent by cloud server 300 through the first network application, no notification or input box may be displayed; instead, the first network application directly performs migration eligibility verification based on OTP1.

[0270] The execution order of S309 and S310-S311 is not limited.

[0271] S312: The first network application in electronic device 100 sends an authentication request (carrying OTP1) to ES410 in MNO400.

[0272] S313: ES410 in MNO400 verifies OTP1 and obtains AuthToken2 if OTP1 is verified successfully.

[0273] S314: ES410 in MNO400 sends an authentication response (carrying AuthToken2) to the first network application in electronic device 100.

[0274] In some embodiments of this application, the verification request and verification response can be request messages and response messages in protocols such as HTTP / HTTPS.

[0275] In some embodiments of this application, the verification request may carry an OTP, which may be the OTP1 obtained above. In some examples, the OTP request may be a GET / POST request like the following: GET / POST ap2009,OTP= <otp1> , <cookie>The OTP value carried in the OTP request is OTP1, and the Cookie carried in the OTP request is the Cookie carried in the OTP response mentioned above.

[0276] In some embodiments of this application, when ES410 successfully verifies OTP1, the verification response may carry the AuthToken2 obtained by ES410. When ES410 fails to verify OTP1, ES410 may not need to obtain AuthToken2. In some embodiments of this application, the verification response may carry a status code, which can be an HTTP / HTTPS status code indicating the response status to the verification request. In some examples, when ES410 successfully verifies OTP1, the verification response may be represented as: 200 OK, AuthToken2. Here, 200 OK is the status code carried in the verification response, indicating that the verification request has been successfully processed.

[0277] In some embodiments of this application, when ES410 successfully verifies OTP1, ES410 can request AuthToken from AAA server 440. AAA server 440 can generate AuthToken2 and return it to ES410. ES410 can then send AuthToken2 to the first network application in electronic device 100.

[0278] In some embodiments of this application, after the MNO400 sends AuthToken2 to the electronic device 100, the MNO400 and the electronic device 100 can communicate subsequently based on AuthToken2. In some examples, the request messages sent by the electronic device 100 to the ES410 (such as the following qualification request and management subscription request) all carry AuthToken2. The ES410 can verify the AuthToken2 carried in the request message, and process the request from the electronic device 100 only after successful verification.

[0279] S315: The first network application in electronic device 100 sends an authentication request (carrying AuthToken2) to ES410 in MNO400.

[0280] S316: ES410 in MNO400 sends a qualification review response (indicating eligibility for migration) to the first network application in electronic device 100.

[0281] In some embodiments of this application, the qualification review request and qualification review response can be request messages and response messages in protocols such as HTTP / HTTPS.

[0282] In some embodiments of this application, the eligibility request may carry operation information, which may instruct the first network application in the electronic device 100 to request an operation, i.e., instruct the first network application to request eligibility (CheckEligibility). In some embodiments of this application, the eligibility request may carry identification information, which may be the identifier of the pSIM / eSIM (e.g., corresponding to MNO400) in the electronic device 100 (e.g., IMEI), or the identifier of the first network application in the electronic device 100 (e.g., UUID). In some embodiments of this application, the eligibility request may carry a token, which may be AuthToken2.

[0283] In some examples, the eligibility request can be a GET / POST request like this: GET / POST ap2009,operation=CheckEligibility,terminal_id= <imeinew> or <uuidapp>,token= <authtoken2>Here, `operation` is the operation information carried in the eligibility verification request, and its value is `CheckEligibility`, indicating that the operation requested by the first network application in electronic device 100 is eligibility verification. `terminal_id` is the identification information carried in the eligibility verification request, and its value is `IMEIsim`, where `IMEIsim` is the IMEI of the pSIM / eSIM in electronic device 100. Alternatively, `terminal_id` can be `UUIDapp`, where `UUIDapp` is the UUID of the first network application in electronic device 100. `token` is `AuthToken2`.

[0284] In some embodiments of this application, the qualification review response may carry a status code, which can be an HTTP / HTTPS status code indicating the response status to the qualification review request. In some embodiments of this application, the qualification review response may carry primary device status information, which can indicate whether the electronic device 100 is eligible for migration, i.e., indicate the qualification review result.

[0285] In some embodiments of this application, ES410 can determine whether the AuthToken2 carried in the eligibility review request is the previously issued AuthToken2. When the determination result is yes, ES410 verifies AuthToken2 successfully; when the determination result is no, ES410 fails to verify AuthToken2. Wherein, when ES410 verifies AuthToken2 successfully, ES410 can determine that electronic device 100 is eligible to migrate phone number 1. In this case, the master device status information carried in the eligibility review response can indicate that electronic device 100 is eligible for migration. Figure 7 The following example illustrates the eligibility verification process, where the primary device status information carried in the eligibility verification response indicates that electronic device 100 is eligible for migration. In some examples, when the ES410 successfully verifies AuthToken2, the eligibility verification response can be as follows: 200 OK, PrimaryDeviceStatus = ENABLED. Here, 200 OK is the status code carried in the eligibility verification response, indicating that the eligibility verification request has been successfully processed. PrimaryDeviceStatus is the primary device status information carried in the eligibility verification response; its value is ENABLED, indicating that electronic device 100 is eligible for migration.

[0286] In other embodiments of this application, when ES410 fails to verify AuthToken2, ES410 can determine that electronic device 100 is not eligible to migrate phone number 1. In some examples, when ES410 fails to verify AuthToken2, the PrimaryDeviceStatus carried in the eligibility review response is set to DISABLED, indicating that electronic device 100 is not eligible to migrate.

[0287] S317: The first network application in electronic device 100 sends a management subscription request (carrying AuthToken2) to ES410 in MNO400.

[0288] S318: ES410 in MNO400 instructs BOSS420 to migrate the subscription relationship of telephone number 1.

[0289] S319: BOSS420 in MNO400 activates the subscription relationship of electronic device 200 and activates the subscription relationship of electronic device 100.

[0290] S320: ES410 in MNO400 sends a management subscription response (carrying download information) to the first network application in electronic device 100.

[0291] In some embodiments of this application, the management subscription request and management subscription response can be request messages and response messages in protocols such as HTTP / HTTPS, respectively.

[0292] In some embodiments of this application, the management subscription request may carry operation information, which may instruct the first network application in the electronic device 100 to request an operation, i.e., instruct the first network application to request a management subscription. Optionally, the management subscription request may carry the type corresponding to the operation information. In some embodiments of this application, the management subscription request may carry identification information, which may be the identifier of the pSIM / eSIM (e.g., corresponding to MNO400) in the electronic device 100 (e.g., IMEI), or the identifier of the first network application in the electronic device 100 (e.g., UUID). In some embodiments of this application, the management subscription request may carry a token, which may be AuthToken2.

[0293] In some examples, a management subscription request can be a GET / POST request like this: GET / POST ap2009,operation=ManageSubscription,operation_type=3-TRANSFER,terminal_id= <imeinew> or <uuidapp>,token= <authtoken2>Here, `operation` represents the operation information carried in the management subscription request, with a value of `ManageSubscription`, indicating that the operation requested by the first network application in electronic device 100 is a management subscription. `operation_type` represents the type of operation information carried in the management subscription request, with a value of `3-TRANSFER`, indicating that the subscription relationship managed by the first network application in electronic device 100 is of the third transmission type. `terminal_id` represents the identification information carried in the management subscription request, with a value of `IMEIsim`, where `IMEIsim` is the IMEI of the pSIM / eSIM in electronic device 100. Alternatively, `terminal_id` can be a value of `UUIDapp`, where `UUIDapp` is the UUID of the first network application in electronic device 100. `token` is a value of `AuthToken2`.

[0294] In some embodiments of this application, after receiving a management subscription request from electronic device 100, if ES410 verifies AuthToken2 successfully, it can instruct BOSS420 to migrate the subscription relationship of phone number 1, that is, to migrate the configuration of the subscription relationship of phone number 1 to electronic device 100. For example, ES410 can send the identifier of the subscription relationship of phone number 1 (Subscription ID) to BOSS420. Therefore, BOSS420 can, under the instruction of ES410, deactivate the configuration of the subscription relationship of phone number 1 corresponding to electronic device 200, and activate the configuration of the subscription relationship of phone number 1 corresponding to electronic device 100. After instructing BOSS420 to migrate the subscription relationship of phone number 1, ES410 can send a management subscription response to the first network application in electronic device 100. After deactivating the configuration of the subscription relationship of phone number 1 corresponding to electronic device 200, electronic device 200 cannot establish a network presence through phone number 1. In other embodiments of this application, when ES410 fails to verify AuthToken2, ES410 may not instruct BOSS420 to migrate the subscription relationship of phone number 1.

[0295] In some embodiments of this application, the management subscription response may carry result information of the management subscription relationship, which may indicate whether electronic device 100 is allowed to download the profile corresponding to phone number 1. In some embodiments of this application, the management subscription response may carry download information, which may include the address information 1 of the configuration file server 430, and optionally may also include related information such as keys and certificate indexes. For example, when MNO 400 allows electronic device 100 to download the profile corresponding to phone number 1, the management subscription response may carry download information. In some embodiments of this application, the management subscription response may carry a status code, which may be an HTTP / HTTPS status code indicating the response status to the management subscription request.

[0296] In some examples, the management subscription response can be the following: 200 OK, SubscriptionResult = 2 - DOWNLOAD PROFILE, DownloadInfo = [ProfileActivationCode = <activationcode>The 200 OK status code in the management subscription response indicates that the management subscription request has been successfully processed. The SubscriptionResult is the result information of the management subscription relationship carried in the management subscription response. The value of SubscriptionResult can be 2 - Download Profile, indicating that electronic device 100 is allowed to download the profile corresponding to phone number 1. DownloadInfo may include the ProfileActivationCode, which is an activation code (ActivationCode). ActivationCode may include the address information of the configuration file server 430.

[0297] S321: The first network application in electronic device 100 obtains the address information 1 of configuration file server 430 based on the downloaded information.

[0298] S322: The first network application in electronic device 100 sends a download request to the configuration file server 430 corresponding to address information 1.

[0299] S323: The configuration file server 430 in MNO400 sends the profile corresponding to telephone number 1 to the first network application in electronic device 100.

[0300] In some embodiments of this application, after receiving the profile corresponding to telephone number 1, the electronic device 100 can store it in the eSIM module. Subsequently, the electronic device 100 can use the profile corresponding to telephone number 1 in the eSIM module to register on the network, for example, to conduct user services such as making calls and accessing the internet.

[0301] In some embodiments of this application, the first network application in the electronic device 100 can access address information 1 obtained from the download information, that is, send a download request (e.g., a request in HTTP / HTTPS protocols, such as a GET request / POST request) to the profile server 430 corresponding to address information 1. The profile server 430 can send the profile corresponding to phone number 1 to the first network application in the electronic device 100 according to the download request. In some examples, the profile server 430 can determine that the electronic device 100 needs to download the profile of phone number 1 based on the OTP1 / AuthToken2 sent by the electronic device 100, and then send the profile corresponding to phone number 1 to the first network application of the electronic device 100. It can be understood that the MNO400 records the correspondence between OTP1 / AuthToken2 and phone number 1, wherein the correspondence between OTP1 and phone number 1 can be obtained based on the OTP request sent by the electronic device 100, and the correspondence between AuthToken2 and phone number 1 can be obtained based on the OTP request sent by the electronic device 100 and the qualification verification (S312-S314).

[0302] In some embodiments of this application, the first network application in the electronic device 100 can display a corresponding user interface after downloading the profile corresponding to the phone number 1 (i.e., after S322). The phone number 1 in this user interface is the phone number of the electronic device 100, for example, displaying... Figure 4H The user interface shown is 480 or Figure 4I The user interface 490 is shown. However, it is not limited to this; in other embodiments, the first network application in the electronic device 100 may also display the aforementioned user interface after the qualification review is passed (i.e., after S316). In other embodiments, the first network application in the electronic device 100 may also display the aforementioned user interface after receiving the management subscription response (i.e., after S320).

[0303] In some embodiments of this application, the cloud server 300 or MNO400 can synchronize the status information of the subscription relationship configuration of telephone number 1 to the electronic device 200 (source device), that is, synchronize the configuration of the subscription relationship of telephone number 1 to the electronic device 200 (source device) after it has been migrated to other devices. Therefore, the electronic device 200 can display a prompt message indicating that telephone number 1 is unavailable, for example... Figure 4J The user interface 500 shown and Figure 4K The user interface 510 is shown. Optionally, the electronic device 200 can also delete the profile corresponding to phone number 1.

[0304] The profile can store at least one of the following types of card data: International Mobile Subscriber Identity (IMSI) (e.g., for authentication), Key Identifier (Ki) (e.g., for authentication), Authentication Key OPC (OPC is a key calculated based on Ki and the operator variant algorithm configuration field (OP)) (e.g., for authentication), Hash value, Integrated Circuit Card Identity (ICCID), Administrative Data (AD), Broadcast Control Channel (BCCH), Forbidden PLMN (FPLMN), Location Information (LOCI), Packet-Switched Location Information (PSLOCI), GPRS Location Information (LOCIGPRS), User-Controlled PLMN Selector with Access Technology (PLMNWACT), and Access Control Level (LCL). The table lists the following PLMN parameters: class (ACC), enabled services table (EST), higher priority PLMN search period (HPPLMN), equivalent home PLMN (EHPLMN), universal subscriber identity module (USIM) service table (UST), network parameters (NETPAR), and initialization values ​​for hyperframe number.STARTHFN), maximum value of start (THRESHOLD), short message service parameters (SMSP), and short message status (SMSS).

[0305] in, Figure 7 S301-S302 and Figure 3 This corresponds to step 5 shown. Figure 7 S303-S310 and Figure 3 The step 6 shown corresponds to this. Figure 7 S311-S316 and Figure 3 The step 7 shown corresponds to this. Figure 7 S317-S322 and Figure 3 The step shown corresponds to step 8.

[0306] Not limited to the above embodiments, in some other embodiments of this application, the subscription relationship of electronic device 200 may not be activated in S319. Therefore, both electronic device 100 and electronic device 200 can be configured with the subscription relationship of telephone number 1, which can be understood as "one number for multiple terminals".

[0307] Not limited to the above embodiments, in some other embodiments of this application, S315-S316 may be omitted and S317 may be executed directly. In some other embodiments of this application, the qualification review request and management subscription request may also be implemented by a single request, and the qualification review response and management subscription response may also be implemented by a single response.

[0308] In the above method, during the profile migration process, the user can complete the migration operation securely and in a closed loop on electronic device 100 (target device). Electronic device 100 can interface with cloud server 300 and MNO400, and cloud server 300 and MNO400 can interface with each other (which can be understood as "cloud-to-cloud interface"). Electronic device 100, cloud server 300 and MNO400 do not need to interface with electronic device 200. Therefore, the profile migration process does not depend on electronic device 200 being online in real time, intact, transmitting relevant information and performing confirmation operations. In this way, even if electronic device 200 is unavailable (e.g. lost, not with the user, malfunctioning, etc.), the profile migration process can still be achieved.

[0309] Furthermore, phone number synchronization can be achieved through account 1 logged in by the first network application, that is, information synchronization between electronic device 200 (source device) and electronic device 100 (target device) can be achieved through cloud server 300, such as synchronizing the phone number of electronic device 200 (source device) to electronic device 100 (target device), such as synchronizing the status information of the subscription relationship configuration of phone number 1 to electronic device 200 (source device).

[0310] Not limited to the above embodiments, in some other embodiments of this application, the cloud server 300 may not obtain the phone number of the electronic device 200 from the MNO400, but the electronic device 200 may directly send the phone number to the cloud server 300.

[0311] Not limited to the above embodiments, in other embodiments of this application, when reliable transmission between cloud server 300 and MNO400 is achieved based on AccessToken, the transmitted data may not be encrypted using AccessToken; instead, AccessToken and data may be transmitted simultaneously. After receiving data sent by the other end, cloud server 300 / MNO400 can first verify the simultaneously received AccessToken. If the verification is successful, the currently received data is determined to be reliable data. This application does not limit this aspect.

[0312] Not limited to the above embodiments, in some other embodiments of this application, the cloud server 300 and MNO400 may also communicate without AccessToken.

[0313] Figure 8 This is a flowchart illustrating another configuration file migration method provided in this application embodiment.

[0314] Figure 8 The method shown can be applied to a communication system, which may include a first device, a cloud server, and an operator server, and optionally a second device. The communication system can be... Figure 2 and / or Figure 3 The communication system 10 shown can be further divided into two devices: the first device can be an electronic device 100 in the communication system 10, the cloud server can be a cloud server 300 in the communication system 10, the operator server can be an MNO400 in the communication system 10, and the second device can be an electronic device 200 in the communication system 10.

[0315] Figure 8 The method shown may include, but is not limited to, the following steps:

[0316] S401: The first device displays the first interface (including the first phone number of the second device).

[0317] In some embodiments of this application, the first interface includes one or more phone numbers of the second device, and the one or more phone numbers of the second device include the first phone number.

[0318] In some embodiments of this application, the first device logs into a first account before step S401 and receives one or more phone numbers corresponding to the first account from the cloud server. Since the second device is a device that has logged into the first account, the one or more phone numbers corresponding to the first account include one or more phone numbers of the second device. The first device can display the one or more phone numbers corresponding to the first account on a first interface. For specific implementation examples, please refer to [link to implementation details]. Figure 7 S301-S302, of which the first account is Figure 7 Account 1 in S301-S302.

[0319] In some embodiments of this application, prior to S401, Figure 8 The method also includes: the cloud server receiving a first temporary token sent by the second device; see the example implementation for details. Figure 6 S203, the first temporary token is Figure 6 The cloud server then sends a fourth request (carrying the first temporary token) to the operator server and receives a second phone number (one or more phone numbers belonging to the second device) from the operator server based on the fourth request. The second phone number may include the first phone number. Optionally, before sending the fourth request to the operator server, the cloud server may first obtain a second access token from the operator server. For a specific implementation example, please refer to [link to implementation example]. Figure 6 S204-S205, the second access token is Figure 6 AccessToken1 in S204-S205. Thus, the fourth request can carry the second access token obtained above. For a detailed implementation example of the above process, please refer to... Figure 6 S206-S210, the fourth request is Figure 6 The number request in S206-S210, the second telephone number is Figure 6 At least one telephone number from S206-S210.

[0320] In some embodiments of this application, before the cloud server receives the first temporary token sent by the second device, the second device may send a fifth request to the operator server and receive the first temporary token sent by the operator server based on the fifth request. Specific implementation examples can be found in [link to relevant documentation]. Figure 6 S201-S202, the fifth request is Figure 6 Token requests in S201-S202.

[0321] S402: The first device receives the first input from the user to migrate the first phone number to the first device.

[0322] In some embodiments of this application, the first device can receive a first input acting on a first phone number in a first interface, and determine, based on the first input, to migrate the first phone number of the second device to the first device. An implementation example of S402 can be found here. Figure 7 S303, the first phone number is Figure 7 Phone number 1 in S303.

[0323] S403: The first device sends a first request to the cloud server (to request the migration of the first phone number to the first device).

[0324] In some embodiments of this application, the first device may send a first request to the cloud server in response to a first input. An implementation example of S403 can be found here. Figure 7 S304, the first request is Figure 7 The migration request in S304.

[0325] S404: The first device sends a second request (carrying the first phone number) to the operator's server.

[0326] In some embodiments of this application, the first device may, in response to the first input, send a second request to the operator server. An implementation example of S404 can be found here. Figure 7 S307, the second request is Figure 7 OTP requests in S307.

[0327] S405: The carrier's server sends a verification code to the cloud server.

[0328] In some embodiments of this application, the operator server may send a verification code to the cloud server in response to a second request. An implementation example of S405 can be found here. Figure 7 S308, verification code is Figure 7 OTP1 in S308.

[0329] S406: The operator server sends a first response to the first device (indicating successful processing of the second request).

[0330] In some embodiments of this application, after the operator server sends a verification code to the cloud server, it can send a first response to the second request to the first device to indicate that the second request has been successfully processed. An implementation example of S406 can be found here. Figure 7 The S309, first response is Figure 7 The OTP response in S309.

[0331] S407: The cloud server sends a verification code to the first device.

[0332] In some embodiments of this application, after receiving the verification code, the cloud server can send the verification code to the first device. An implementation example of S407 can be found here. Figure 7 The S311 verification code is Figure 7 OTP1 in S308.

[0333] In some embodiments of this application, prior to S405, Figure 8 The method also includes: the cloud server sending a third request to the operator server and receiving a first access token sent by the operator server based on the first request. For a specific implementation example, please refer to [link to implementation details]. Figure 7 S305-S306, the first access token is Figure 7 AccessToken2 in S305-S306. Thus, in S405, the operator server can send the first encrypted information (i.e., obtained through the encrypted verification code of the first access token) to the cloud server. See the example for implementation details. Figure 7 The first encrypted information of S308 is Figure 7 The encrypted information in S308. In S407, the cloud server can use the first access token to decrypt the first encrypted information to obtain a verification code, and then send the verification code to the first device. See the example for implementation details. Figure 7 The verification code for S310-S311 is... Figure 7 OTP1 in S310-S311.

[0334] S408: The first device uses a verification code to download the configuration file corresponding to the first phone number from the operator's server.

[0335] In some embodiments of this application, the first device sends a sixth request (carrying a verification code) to the operator server, and receives an authentication token sent by the operator server if the verification code is verified successfully. Specific implementation examples can be found in [link to relevant documentation]. Figure 7 S312-S314, the sixth request is Figure 7 The authentication request in S312-S314 uses the authentication token as... Figure 7 The AuthToken2 in S312-S314. Then, the first device can use the authentication token to download the configuration file corresponding to the first phone number from the operator's server.

[0336] In some embodiments of this application, the first device uses an authentication token to download the profile corresponding to the first phone number from the operator server. This may include: the first device sending a seventh request (carrying the authentication token) to the operator server, and receiving first address information sent by the operator server if the operator server verifies the authentication token successfully. Then, the first device can download the profile corresponding to the first phone number from the profile server corresponding to the first address information. For specific implementation examples, please refer to... Figure 7 S315-S322, the seventh request is Figure 7 In the qualification review request or management subscription request in S315-S322, the first address information is... Figure 7 Address information 1 in S315-S322, the configuration file server corresponding to the first address information is Figure 7 The configuration file shown is for server 430.

[0337] In some embodiments of this application, the first device can use an authentication token to request the migration of the subscription relationship of the first phone number from the operator server, as implemented in, for example, S408. Exemplarily, the first device can send an eighth request (carrying an authentication token) to the operator server. The operator server can verify the authentication token carried in the eighth request. When the authentication token verification is successful, the subscription relationship of the first phone number corresponding to the second device is deactivated, and the subscription relationship of the first phone number corresponding to the first device is activated. It is understood that the activated subscription relationship of the first phone number is used to enable network registration via the first phone number. Therefore, after deactivating the subscription relationship of the first phone number corresponding to the second device, the second device cannot register via the first phone number; after activating the subscription relationship of the first phone number corresponding to the first device, the first device can register via the first phone number. For a specific implementation example of the above example process, please refer to... Figure 7 S317-S319, the eighth request is Figure 7 S317-S319 heavy management subscription requests.

[0338] In some embodiments of this application, in S401, the first device may display one or more phone numbers of the second device in a first area of ​​the first interface. The first area is used to display phone numbers of devices other than the first device. In this case, the second area of ​​the first interface displayed by the first device does not include the first phone number; the second area may include other phone numbers of the first device or may not include any phone numbers. The second area is used to display the phone number of the first device. An example of the first interface displayed by the first device in this case can be found in [link to example]. Figure 4D The user interface 440 shown can have an upper half that can be a second area and a lower half that can be a first area. The second area of ​​the user interface 440 can include the data plan 442 of the phone number 11 of the first device (i.e., electronic device 100), and the first area of ​​the user interface 440 can include the data plan 443 of the phone number 22 (i.e., the first phone number) of the second device (i.e., electronic device 200) and the data plan 444 of the phone number 33 of the second device. After S408, the first device can display its first phone number in the second area of ​​the first interface. In this case, the first area of ​​the first interface displayed by the first device does not include the first phone number; the first area may include other phone numbers or not include any phone number. An example of the first interface displayed by the first device in this case can be found in [link to example]. Figure 4I The user interface 490 shown can have an upper half that can be a second area and a lower half that can be a first area. The second area of ​​the user interface 490 can include the data plan 442 of the phone number 11 of the first device (i.e., electronic device 100) and the data plan 443 of the phone number 22 (i.e., the first phone number) of the first device. The first area of ​​the user interface 490 can include the data plan 444 of the phone number 33 of the second device (i.e., electronic device 200).

[0339] In some embodiments of this application, prior to S402, the second device may display one or more phone numbers (including the first phone number) of the second device in a third area of ​​the second interface. The third area is used to display the phone numbers of the second device. At this time, the fourth area of ​​the second interface displayed by the second device does not include the first phone number; the fourth area may include other phone numbers or not include any phone numbers. The fourth area is used to display phone numbers of devices other than the second device. An example of the second interface displayed by the second device in this case can be found in [link to example]. Figure 4E The user interface 450 shown can have an upper half that can be a third area and a lower half that can be a fourth area. The third area of ​​the user interface 450 can include the data plan 452 of the phone number 22 (i.e., the first phone number) of the second device (i.e., electronic device 200) and the data plan 453 of the phone number 33 of the second device. The fourth area of ​​the user interface 450 may not include phone numbers. After S408, the second device can display the first phone number in the fourth area of ​​the second interface. In this case, the third area of ​​the second interface displayed by the second device does not include the first phone number; the third area may include other phone numbers of the second device or may not include phone numbers. An example of the second interface displayed by the second device in this case can be found in [reference needed]. Figure 4K The user interface 510 shown can have an upper half that can be a third area and a lower half that can be a fourth area. The third area of ​​the user interface 510 can include the data plan 453 of the phone number 33 of the second device (i.e., electronic device 200), and the fourth area of ​​the user interface 510 can include the data plan 452 of the phone number 22 (i.e., the first phone number) of the first device (i.e., electronic device 100).

[0340] In some embodiments of this application, Figure 8 The method also includes: after the first device receives the verification code sent by the cloud server, it displays a user interface including an input field and a first notification, the first notification including the verification code. See the example below for details. Figure 4G The user interface 470 shown includes input box 472A and the first notification displayed in message bar 471. The first device can then receive user input (a verification code) in the input box and, in response, download the configuration file corresponding to the first phone number from the operator's server using the verification code (i.e., execute S408). In other embodiments of this application, the first device can also automatically input the verification code from the first notification into the input box and use the verification code to download the configuration file corresponding to the first phone number from the operator's server. In other embodiments of this application, the first device can also directly download the configuration file corresponding to the first phone number from the operator's server without displaying the input box and the first notification. For detailed explanation, please refer to... Figure 7 Description of the first device receiving OTP1 in S311.

[0341] In some embodiments of this application, the first device can use the configuration file corresponding to the obtained first phone number to register on the network. In some examples, Figure 8 The method shown also includes: after S408, the first device displays a user interface including a first phone number of the first device, receives user input from the user to enable the first phone number, and then, in response to a third input, registers the device on the network through the configuration file corresponding to the first phone number. For example Figure 4I The user interface 490 shown is the user interface after the first phone number is enabled. The first phone number is the phone number 22 in the user interface 490. The user input for enabling the first phone number can be a user operation (e.g., a click operation) that acts on the enable control in the user interface where the first phone number is not enabled (e.g., the switch control 443C in the data plan 443 of the phone number 22 shown in the user interface 490, but "Enabled" can be displayed at this time).

[0342] This application also provides an electronic device, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls the computer program to execute the steps performed by the electronic device 100.

[0343] This application also provides an electronic device, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls the computer program to execute the steps performed by the electronic device 200 described above.

[0344] This application embodiment also provides a cloud server, including a transceiver, a processor, and a memory. The memory is used to store computer programs, and the processor calls the computer programs to execute the steps performed by the cloud server 300 described above.

[0345] This application also provides an operator server, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls the computer program to execute the steps performed by the MNO400 described above.

[0346] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by the electronic device 100 in the above-described method embodiments.

[0347] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by the electronic device 200 in the above-described method embodiments.

[0348] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by the cloud server 300 in the above-described method embodiments.

[0349] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by MNO400 in the above-described method embodiments.

[0350] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by the electronic device 100 in the above-described method embodiments.

[0351] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by the electronic device 200 in the above-described method embodiments.

[0352] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by the cloud server 300 in the above-described method embodiments.

[0353] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by MNO400 in the above-described method embodiments.

[0354] This application also provides a chip system, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by the electronic device 100 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0355] This application also provides a chip system, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by the electronic device 200 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0356] This application also provides a chip system, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by the cloud server 300 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0357] This application also provides a chip system, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by MNO400 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0358] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.< / activationcode> < / uuidapp> < / imeinew> < / uuidapp> < / imeinew> < / cookie> < / otp1> < / msisdnsubs> < / uuidapp> < / imeisim> < / uuidapp> < / imeisim>

Claims

1. A communication system, characterized in that, Including the primary equipment and cloud servers, among which, The first device is configured to display a first interface, the first interface including one or more phone numbers of the second device, the one or more phone numbers of the second device including the first phone number; The first device is configured to receive a first input from a user to migrate the first phone number to the first device; The first device is configured to send a first request to the cloud server, the first request being used to request the migration of the first phone number to the first device; The cloud server is used to send verification codes to the first device; The first device is used to download the configuration file corresponding to the first phone number from the operator's server using the verification code.

2. The communication system as described in claim 1, characterized in that, The first device is configured to, after receiving a first input from the user to migrate the first phone number to the first device, send a second request to the operator server and receive a first response from the operator server, wherein the second request carries the first phone number and the first response indicates that the second request was successfully processed; The cloud server is configured to receive the verification code sent by the operator server and send the verification code to the first device after the first device sends the second request to the operator server.

3. The communication system as described in claim 2, characterized in that, The cloud server is configured to send a third request to the operator server before receiving the verification code sent by the operator server, and to receive the first access token sent by the operator server. The cloud server is configured to receive first encrypted information sent by the operator server, decrypt the first encrypted information using the first access token to obtain the verification code, and send the verification code to the first device.

4. The communication system according to any one of claims 1-3, characterized in that, The first device is configured to log in to a first account before displaying the first interface, and receive one or more phone numbers corresponding to the first account sent by the cloud server, wherein the one or more phone numbers corresponding to the first account include one or more phone numbers of the second device, and the second device is a device that has logged in to the first account.

5. The communication system as described in claim 4, characterized in that, The cloud server is configured to receive a first temporary token sent by the second device before the first device receives one or more phone numbers corresponding to the first account sent by the cloud server, send a fourth request to the operator server, and receive a second phone number of the second device sent by the operator server, wherein the fourth request carries the first temporary token, the one or more phone numbers of the second device include the second phone number, and the second phone number includes the first phone number.

6. The communication system as described in claim 5, characterized in that, It also includes the second device, wherein the second device is used to send a fifth request to the operator server, receive the first temporary token sent by the operator server, and send the first temporary token to the cloud server.

7. The communication system according to any one of claims 1-6, characterized in that, The first device is configured to send a sixth request to the operator server, the sixth request carrying the verification code; The first device is configured to receive an authentication token sent by the operator server when the operator server verifies the verification code, and use the authentication token to download the configuration file corresponding to the first phone number from the operator server.

8. The communication system as described in claim 7, characterized in that, The first device is configured to send a seventh request to the operator server, the seventh request carrying the authentication token; The first device is configured to receive first address information sent by the operator server when the operator server verifies the authentication token, and download the configuration file corresponding to the first phone number from the configuration file server corresponding to the first address information.

9. The communication system as described in claim 7 or 8, characterized in that, It also includes the operator's server, wherein, The first device is configured to send an eighth request to the operator server, the eighth request carrying the authentication token; The operator server is used to verify the authentication token carried in the eighth request. When the authentication token is verified, it deactivates the subscription relationship of the first phone number corresponding to the second device and activates the subscription relationship of the first phone number corresponding to the first device. The activated subscription relationship of the first phone number is used to enable network registration through the first phone number.

10. The communication system according to any one of claims 1-9, characterized in that, It also includes the second device, wherein, The first device is configured to display one or more phone numbers of the second device in a first area of ​​the first interface before receiving the first input from the user to migrate the first phone number to the first device, wherein the first area is configured to display phone numbers of other devices besides the first device; The first device is configured to display the first phone number in a second area of ​​the first interface after the configuration file corresponding to the first phone number is downloaded from the operator server using the verification code; the second area is used to display the phone number of the first device. The second device is configured to display one or more phone numbers of the second device in a third area of ​​a second interface before the first device receives the first input from the user to migrate the first phone number to the first device, the third area being used to display the phone numbers of the second device; The second device is configured to display the first phone number in a fourth area of ​​the second interface after the configuration file corresponding to the first phone number is downloaded from the operator's server using the verification code. The fourth area is used to display phone numbers of other devices besides the second device.

11. A configuration file migration method, applied to a first device, characterized in that, The method includes: Display a first interface, the first interface including one or more phone numbers of the second device, the one or more phone numbers of the second device including the first phone number; Receive the first input from the user to migrate the first phone number to the first device; Send a first request to the cloud server, the first request being used to request the migration of the first phone number to the first device; Receive the verification code sent by the cloud server; Use the verification code to download the configuration file corresponding to the first phone number from the operator's server.

12. The method as described in claim 11, characterized in that, Also includes: After receiving the first input from the user to migrate the first phone number to the first device, a second request is sent to the operator server, the second request carrying the first phone number; The cloud server receives a first response from the operator's server, the first response indicating that the second request was successfully processed, and the verification code is received by the cloud server from the operator's server.

13. The method as described in claim 11 or 12, characterized in that, Also includes: Before the first interface is displayed, log in to the first account and receive one or more phone numbers corresponding to the first account sent by the cloud server. The one or more phone numbers corresponding to the first account include one or more phone numbers of the second device, which is a device that has logged in to the first account.

14. The method according to any one of claims 11-13, characterized in that, The step of using the verification code to download the configuration file corresponding to the first phone number from the operator's server includes: A third request is sent to the operator's server, the third request carrying the verification code; If the operator server verifies the verification code successfully, the system receives an authentication token sent by the operator server. The authentication token is used to download the configuration file corresponding to the first phone number from the operator's server.

15. The method as described in claim 14, characterized in that, The step of using the authentication token to download the configuration file corresponding to the first phone number from the operator's server includes: A fourth request is sent to the operator server, the fourth request carrying the authentication token; If the authentication token is successfully verified by the operator server, the first address information sent by the operator server shall be received. Download the configuration file corresponding to the first phone number from the configuration file server corresponding to the first address information.

16. The method as described in claim 14 or 15, characterized in that, Also includes: A fifth request is sent to the operator server, wherein the fifth request carries the authentication token, and the fifth request is used by the operator server to deactivate the subscription relationship of the first phone number corresponding to the second device, and to activate the subscription relationship of the first phone number corresponding to the first device. The activated subscription relationship of the first phone number is used to enable network registration through the first phone number.

17. The method according to any one of claims 11-16, characterized in that, The first interface for display includes: One or more phone numbers of the second device are displayed in a first area of ​​the first interface; the first area is used to display phone numbers of other devices besides the first device. The method further includes: After the configuration file corresponding to the first phone number is downloaded from the operator's server using the verification code, the first phone number is displayed in the second area of ​​the first interface. The second area is used to display the phone number of the first device.

18. The method according to any one of claims 11-17, characterized in that, Also includes: After receiving the verification code sent by the cloud server, a second interface is displayed. The second interface includes an input box and a first notification, the first notification including the verification code. Receive a second input from the user, in which the verification code is entered into the input box; The step of using the verification code to download the configuration file corresponding to the first phone number from the operator's server includes: In response to the second input, the configuration file corresponding to the first phone number is downloaded from the operator's server using the verification code.

19. The method according to any one of claims 11-18, characterized in that, Also includes: After the configuration file corresponding to the first phone number is downloaded from the operator's server using the verification code, a third interface is displayed, which includes the first phone number of the first device. Receive a third input from the user to enable the first phone number; In response to the third input, network registration is performed using the configuration file corresponding to the first phone number.

20. A configuration file migration method, applied to a cloud server, characterized in that, The method includes: Receive a first request sent by a first device, the first request being used to request the migration of a first phone number from a second device to the first device; A verification code is sent to the first device, and the verification code is used by the first device to download the configuration file corresponding to the first phone number from the operator's server.

21. The method as described in claim 20, characterized in that, Also includes: Before sending the verification code to the first device, the verification code is received from the operator's server.

22. The method as described in claim 21, characterized in that, Also includes: Before receiving the verification code sent by the operator server, a second request is sent to the operator server; Receive the first access token sent by the operator's server; Receiving the verification code sent by the operator's server includes: Receive the first encrypted information sent by the operator's server; The first access token is used to decrypt the first encrypted information to obtain the verification code.

23. The method according to any one of claims 20-22, characterized in that, Also includes: Before receiving the first request sent by the first device, when the first device logs into the first account, one or more phone numbers corresponding to the first account are sent to the first device, wherein the one or more phone numbers corresponding to the first account include one or more phone numbers of the second device, the one or more phone numbers of the second device include the first phone number, and the second device is a device that has logged into the first account.

24. The method as described in claim 23, characterized in that, Also includes: Before sending one or more phone numbers corresponding to the first account to the first device, receive the first temporary token sent by the second device; Send a third request to the operator server, the third request carrying the first temporary token; The second device receives a second phone number sent by the operator's server, wherein one or more phone numbers of the second device include the second phone number, and the second phone number includes the first phone number.

25. An electronic device, characterized in that, It includes a transceiver, a processor, and a memory, the memory being used to store a computer program, and the processor calling the computer program to perform the method as described in any one of claims 11-19.

26. A cloud server, characterized in that, It includes a transceiver, a processor, and a memory, the memory being used to store a computer program, and the processor calling the computer program to perform the method as described in any one of claims 20-24.

27. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, is used to implement the method as described in any one of claims 11-19.

28. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, is used to implement the method as described in any one of claims 20-24.

29. A computer program product, characterized in that, When the computer program product is run on a processor, it is used to implement the method as described in any one of claims 11-19.

30. A computer program product, characterized in that, When the computer program product is run on a processor, it is used to implement the method as described in any one of claims 20-24.

31. A chip system, characterized in that, It includes a processing circuit and an interface circuit, the interface circuit being used to receive code instructions and transmit them to the processing circuit, the processing circuit being used to execute the code instructions to perform the method as described in any one of claims 11-19.

32. A chip system, characterized in that, It includes a processing circuit and an interface circuit, the interface circuit being used to receive code instructions and transmit them to the processing circuit, the processing circuit being used to execute the code instructions to perform the method as described in any one of claims 20-24.

Images