Profile migration method and related apparatus
By working together with cloud servers and carrier servers, the target device can complete the migration of SIM card or eSIM card information without relying on the source device. This solves the problem of cumbersome operation in existing technologies, realizes a safe and efficient migration process, and improves the user experience.
Patent Information
- Application Number
- PCT/CN2025/120615
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-09-13
- Filing Date
- 2025-09-11
- Publication Date
- 2026-03-19
AI Technical Summary
During the migration of SIM card or eSIM card information, existing technologies require both the source and target devices to be powered on, logged into the same account, and registered on the network simultaneously. This process is cumbersome for users, has many restrictions, and results in a poor user experience.
By working together with cloud servers and carrier servers, the target device can migrate SIM card or eSIM card information without relying on the source device. It uses verification codes and authentication tokens to achieve secure communication and download configuration files, reducing the number of steps required by the user.
It simplifies the migration process, reduces reliance on the source device, improves user experience and the usability of migration functions, and ensures security and user rights.
Smart Images

Figure CN2025120615_19032026_PF_FP_ABST
Abstract
Description
Configuration file migration method and related device
[0001] The present application claims priority to the Chinese patent application No. 202411289677.1, filed on September 13, 2024, with the State Intellectual Property Office of China, and entitled "Configuration file migration method and related device", the whole content of which is incorporated herein by reference. TECHNICAL FIELD
[0002] The present application relates to the technical field of computer, in particular to a configuration file migration method and related device. BACKGROUND
[0003] In the field of mobile communication, one of the common mobile communication access schemes is a subscriber identity module (SIM) based user identity authentication access scheme. The common implementation is that a user inserts a SIM card into a SIM card slot of a mobile communication device such as a mobile phone or a tablet computer, and the mobile communication device performs legality authentication (which can be referred to as authentication) at a communication service provider through the inserted SIM card. After the authentication is passed, the mobile communication device is allowed to access the mobile communication network.
[0004] With the development of mobile communication technology, an embedded SIM (eSIM) scheme is proposed on the basis of the SIM card scheme. The eSIM scheme is to directly embed the traditional SIM card into the chip of an electronic device, instead of adding it to the device as an independent removable component. The user does not need to insert a physical SIM card. This scheme will allow users to have more flexible choices of operators and to re-write new numbers in the eSIM module of the electronic device.
[0005] In some migration scenarios, a user can "migrate" the card information of a physical SIM card or an eSIM on a device A to another device B. The device A can be referred to as a source device, and the device B can be referred to as a target device. For example, the device A is an old mobile phone of the user, and the device B is a new mobile phone of the user. Currently, to implement the above "migration", the source device and the target device need to be powered on and logged in to the same account at the same time, the source device and the target device need to be camped on a network or connected to a wireless fidelity (Wi-Fi) network at the same time, the source device and the target device need to be unlocked and operable, and the user needs to perform multiple operations related to the migration. The migration has many restrictions and the user's operation is tedious. SUMMARY
[0006] The application discloses a configuration file migration method and related device, which can enable a user to complete a migration operation on a target device without relying on a source device, greatly reducing migration restrictions and user operations, and effectively improving user experience.
[0007] In a first aspect, the application provides a communication system comprising a first device and a cloud server, wherein the first device is configured to display a first interface, the first interface comprising one or more phone numbers of a second device (including a first phone number), and receive a first input of a user migrating the first phone number to the first device; the first device is configured to send a first request to the cloud server in response to the first input, the first request being used to request migration of the first phone number to the first device; the cloud server is configured to send a verification code to the first device based on the first request; and the first device is configured to use the verification code to download a profile corresponding to the first phone number from an operator server (e.g., a mobile network operator, MNO). Wherein the second device is a source device for migrating the first phone number, and the first device is a target device for migrating the first phone number, for example, the first device is a new phone of the user, and the second device is an old phone of the user. The migration of the first phone number can be the migration of a profile corresponding to the first phone number.
[0008] In some examples, the first phone number is the phone number of a physical subscriber identity module (pSIM) in the second device, so that when the second device communicates using the first phone number, it is through the pSIM of the first phone number to camp on the network, and thus the profile corresponding to the first phone number is generated by the operator server and sent to the first device after the first device sends a request to the operator server. In other examples, the first phone number is the phone number of an embedded subscriber identity module (eSIM) in the second device, and the second device can store the profile corresponding to the first phone number generated by the operator server and sent to the first device in the eSIM module, so that when the second device communicates using the first phone number, it is through the profile of the first phone number in the eSIM module to camp on the network, and thus the profile corresponding to the first phone number is generated by the operator server and sent to the first device after the first device sends a request to the operator server.
[0009] In some examples, the cloud server is an application server that provides services for a first network application in the first device. For example, the first interface is an interface of the first network application. Optionally, the cloud server is also an application server that provides services for a first network application in the second device.
[0010] In the system, the user can complete the migration operation in a closed loop on the first device as the target device without relying on the second device as the source device, for example, without the second device being intact, online in real time, transmitting proof data, user operability, etc., greatly reducing the limitations of migration, and the user does not need to perform related operations of migration on the first device and the second device multiple times, reducing user operations, thereby effectively improving the usability of the migration function and the user experience.
[0011] In a possible implementation, the first device is configured to send a second request to the operator server (e.g., the authentication server ES) before receiving the first input of the user migrating the first phone number to the first device, and then receive a first response sent by the operator server (e.g., the authentication server ES), the second request carrying the first phone number, and the first response indicating that the second request is successfully processed. The cloud server is configured to receive the verification code sent by the operator server (e.g., the authentication server ES) after the first device sends the second request to the operator server, and send the verification code to the first device. For example, the first response is sent by the operator server to the first device after the operator server sends the verification code to the cloud server.
[0012] In the system, the operator server can send the verification code to the trusted cloud server based on the second request without determining that the first device is a trusted device. If the first device is a device trusted by the cloud server, the verification code sent by the cloud server will be received. Therefore, even if the first device (target device) does not obtain the proof data for migration from the second device (source device) and send it to the operator server, the verification code can be obtained from the cloud server to the operator server. Thus, while ensuring security, the migration process is achieved without relying on the source device.
[0013] In a possible implementation, the cloud server is configured to send a third request to the operator server (e.g., the authentication server ES) before receiving the verification code sent by the operator server, and then receive a first access token AccessToken sent by the operator server (e.g., the authentication, authorization, and accounting AAA server), the first access token being used to realize secure communication between the cloud server and the operator server. The cloud server is configured to receive the first encrypted information (i.e., the encrypted information obtained by encrypting the verification code by the first access token) sent by the operator server, and decrypt the first encrypted information using the first access token to obtain the verification code, and then send the verification code to the first device.
[0014] In the system, the cloud server and the operator server can communicate using the first access token, further improving security.
[0015] In a possible implementation, the first device is configured to log in the first account before displaying the first interface, receive one or more phone numbers corresponding to the first account sent by the cloud server, and then display the one or more phone numbers corresponding to the first account in the first interface, where 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 the first account.
[0016] In the system, the first device can obtain the phone numbers of the second device through the cloud server and display the phone numbers on the first interface for the user to select the phone number to be migrated. It can also be understood that the phone numbers are synchronized through the first account, and the first device and the second device do not need to interact with each other to obtain the phone numbers of the second device. Therefore, the synchronization of the phone numbers does not need to rely on the source device, further reducing the migration restrictions and improving the user experience.
[0017] In a possible implementation, the cloud server is configured to receive a first temporary token TemporaryToken sent by the second device before sending the one or more phone numbers corresponding to the first account to the first device, send a fourth request (for example, a request for obtaining a phone number) to an operator server (for example, an authentication server ES) based on the first temporary token, and then receive a second phone number of the second device sent by the operator server, where 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. Optionally, the communication system further includes the second device, which is configured to send a fifth request (for example, a request for obtaining a temporary token) to the operator server (for example, the authentication server ES), receive the first temporary token sent by the operator server, and send the first temporary token to the cloud server.
[0018] In the system, when the second device is intact and can be connected to the network, the first temporary token can be obtained from the operator server and sent to the cloud server. In this way, the cloud server can obtain and store the phone numbers of the second device from the operator server based on the first temporary token. Therefore, when the user uses the first device later, the user can obtain the phone numbers of the second device from the cloud server that has stored the phone numbers of the second device without relying on the second device, and the user experience is good.
[0019] In a possible implementation, the first device is configured to send a sixth request to the operator server (e.g., the authentication server ES), the sixth request carrying the verification code, and, in a case where the operator server (e.g., the authentication server ES) verifies the verification code carried in the sixth request successfully, receive an authentication token AuthToken sent by the operator server, and then use the authentication token to download the configuration file corresponding to the first phone number from the operator server. For example, the request sent by the first device to the operator server can carry the authentication token, and the operator server can verify the identity of the first device by verifying the authentication token, so as to determine whether to respond to the first device.
[0020] In the system, the first device can obtain the authentication token from the operator server based on the verification code. The authentication token can be used to implement secure communication between the first device and the operator server. The authentication token can be security information issued by the operator server and conforming to the communication mode (e.g., the communication mode of the Hypertext Transfer Protocol HTTPS) between the first device and the operator server. In this way, the operator server can subsequently verify the authentication token based on the current communication mode directly, without authenticating the identity information of the first device such as the verification code and the identification information each time, thereby accelerating the processing speed while ensuring security.
[0021] In a possible implementation, the first device is configured to send a seventh request (e.g., a request for qualification examination and / or a request for managing a subscription relationship) to the operator server (e.g., the authentication server ES), the seventh request carrying the authentication token, and, in a case where the operator server verifies the authentication token carried in the seventh request successfully, receive first address information sent by the operator server, and then download the configuration file corresponding to the first phone number from the configuration file server corresponding to the first address information.
[0022] In the system, the operator server can include a server (e.g., the authentication server ES) configured to verify the identity of the first device and a configuration file server configured to manage the configuration file. When the authentication server ES verifies the identity of the first device successfully, the first device is sent the address information of the configuration file server, so that the first device downloads the required configuration file from the configuration file server, instead of the configuration file being issued directly by the configuration file server. Therefore, the operator server can distribute the processing pressure and the storage pressure through different servers, and improve the security of the configuration file.
[0023] In a possible implementation, the first device is configured to send an eighth request (e.g., for requesting management of a subscription relationship, e.g., the seventh request described above) to a carrier server (e.g., an authentication server ES), and the eighth request carries an authentication token. The carrier server is configured to verify the authentication token carried in the eighth request, and when the authentication token is verified, a (e.g., carrier business operation support management system BOSS) 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 subscription relationship of the first phone number in the activated state is used to implement camping on the network through the first phone number. Therefore, after the subscription relationship of the first phone number corresponding to the second device is deactivated, the second device cannot camp on the network through the first phone number, and after the subscription relationship of the first phone number corresponding to the first device is activated, the first device can camp on the network through the first phone number.
[0024] In the system described above, the carrier server can deactivate the subscription relationship of the first phone number corresponding to the second device, so that the second device cannot camp on the network through the first phone number, and avoid the case that the second device is lost and other people use the second device to consume through the second phone number, effectively guaranteeing the user rights and improving the user experience.
[0025] In a possible implementation, the first device is configured to display one or more phone numbers of the second device in a first area in a first interface before receiving a first input of the user for migrating the first phone number to the first device. The first area is configured to display phone numbers of devices other than the first device. At this time, a second area in the first interface displayed by the first device does not include the first phone number, and the second area includes other phone numbers of the first device or does not include any phone number. The second area is configured to display phone numbers of the first device. After the first device downloads a configuration file corresponding to the first phone number from the carrier server using the verification code, the first device displays the first phone number of the first device in the second area in the first interface. At this time, the first area in the first interface displayed by the first device does not include the first phone number, and the first area includes other phone numbers or does not include any phone number.
[0026] In the system described above, 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 in the first interface for displaying phone numbers 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 in the first interface for displaying phone numbers of the device, so that the user can intuitively see the migration of the first phone number through the first device.
[0027] In a 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 in a second interface before the first device receives the first input of the user migrating the first phone number to the first device, the third area is configured to display the phone numbers of the second device, at this time, a fourth area in the second interface displayed by the second device does not include the first phone number, the fourth area includes other phone numbers or does not include phone numbers, and the fourth area is configured to display the phone numbers of other devices except the second device. The second device is configured to display the first phone number in the fourth area in the second interface after the first device downloads the configuration file corresponding to the first phone number from the operator server using the verification code, at this time, the third area in the second interface displayed by the second device does not include the first phone number, and the third area includes other phone numbers of the second device or does not include phone numbers.
[0028] In the 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 a third area in a second interface for displaying the device, and 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 a fourth area in the second interface for displaying other devices, so that the user can intuitively see the migration of the first phone number through the second device.
[0029] In a second aspect, the present application provides a configuration file migration method, applied to a first device, the method comprising: displaying a first interface, the first interface including one or more phone numbers (including a first phone number) of a second device, and receiving a first input of a user migrating the first phone number to the first device; in response to the first input, sending a first request to a cloud server, the first request being used to request to migrate 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 a configuration file corresponding to the first phone number from an operator server (for example, a mobile network operator MNO). Wherein the second device is a source device of migrating the first phone number, and the first device is a target device of migrating the first phone number, for example, the first device is a new phone of the user, and the second device is an old phone of the user. The migration of the first phone number can be the migration of a configuration file (profile) corresponding to the first phone number.
[0030] In some examples, the first phone number is a phone number of a physical subscriber identity module (pSIM) in the second device, and thus the second device uses the pSIM of the first phone number to camp on a network when the second device communicates using the first phone number. In this case, the profile corresponding to the first phone number is generated by the operator server and sent to the first device after the first device sends the request to the operator server. In other examples, the first phone number is a phone number of an embedded subscriber identity module (eSIM) in the second device. The second device can store the profile corresponding to the first phone number in the eSIM module, and thus the second device uses the profile of the first phone number in the eSIM module to camp on a network when the second device communicates using the first phone number. In this case, the profile corresponding to the first phone number is generated by the operator server and sent to the first device after the first device sends the request to the operator server.
[0031] In some examples, the cloud server is an application server that provides services for the first network application in the first device. For example, the first interface is an interface of the first network application. Optionally, the cloud server is also an application server that provides services for the first network application in the second device.
[0032] In the above method, the user can complete the migration operation in a closed loop on the first device as the target device without relying on the second device as the source device, for example, without the second device being intact, online in real time, transmitting proof data, and being user-operable, greatly reducing the limitations of migration. The user also does not need to perform related operations of migration on the first device and the second device multiple times, reducing user operations, and thus effectively improving the usability of the migration function and the user experience.
[0033] In a possible implementation, the above method further includes: after receiving the first input of the user to migrate the first phone number to the first device, sending a second request to an operator server (e.g., an authentication server ES), and then receiving a first response sent by the operator server (e.g., the authentication server ES), the second request carrying the first phone number, and the first response indicating that the second request is successfully processed. The above verification code is received by the cloud server from the operator server, for example, received by the cloud server from the operator server after the first device sends the second request. For example, the first response is sent by the operator server to the first device after the operator server sends the verification code to the cloud server.
[0034] In the above method, the operator server can send the verification code to the trusted cloud server based on the second request without determining that the first device is a trusted device. If the first device is a trusted device of the cloud server, the first device can receive the verification code sent by the cloud server. Therefore, even if the first device (target device) does not obtain the migration proof data from the second device (source device) and send it to the operator server, the first device can obtain the verification code from the cloud server to the operator server. Thus, while ensuring security, the migration process is independent of the source device.
[0035] In a possible implementation, the above method further includes that before displaying the first interface, the first device logs in the first account and receives one or more phone numbers corresponding to the first account sent by the cloud server, and then displays the one or more phone numbers corresponding to the first account in 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 the first account.
[0036] 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 for migration. It can also be understood that the phone number is synchronized through the first account, and the first device and the second device do not need to interact with each other to obtain the phone number of the second device. Therefore, the synchronization of the phone number does not need to rely on the source device, further reducing the migration restrictions and improving the user experience.
[0037] In a possible implementation, the first device downloads the configuration file corresponding to the first phone number from the operator server using the verification code, including: sending a third request to the operator server (for example, the authentication server ES), the third request carrying the verification code, and in the case that the operator server (for example, the authentication server ES) verifies the verification code carried by the third request, receiving the authentication token AuthToken sent by the operator server, and then using the authentication token to download the configuration file corresponding to the first phone number from the operator server. For example, the request sent by the first device to the operator server can carry the authentication token, and the operator server can verify the identity of the first device by verifying the authentication token, so as to select whether to respond to the first device.
[0038] In the method, the first device can obtain an authentication token from the operator server based on the verification code, the authentication token can be used to realize secure communication between the first device and the operator server, and the authentication token can be security information issued by the operator server and conforming to the communication mode (for example, the communication mode of the HyperText Transfer Protocol HTTPS) between the first device and the operator server. In this way, the operator server can subsequently verify the authentication token based on the current communication mode, without the need to authenticate the identity information of the first device such as the verification code and the identification information each time, thereby accelerating the processing speed while ensuring security.
[0039] In a possible implementation, the first device downloads the configuration file corresponding to the first phone number from the operator server using the authentication token, including: sending a fourth request (for example, a request for qualification review and / or a request for management of a subscription relationship) to the operator server (for example, an authentication server ES), the fourth request carrying the authentication token, and in a case where the authentication token carried by the fourth request is verified by the operator server, receiving first address information sent by the operator server, and then downloading the configuration file corresponding to the first phone number from a configuration file server corresponding to the first address information.
[0040] In the method, the operator server can include a server (for example, an authentication server ES) for verifying the identity of the first device and a configuration file server for managing the configuration file. When the authentication server ES verifies the identity of the first device, the first device is sent address information of the configuration file server, so that the first device downloads the required configuration file from the configuration file server, instead of directly issuing the configuration file by the configuration file server. Therefore, the operator server can distribute the processing pressure and storage pressure through different servers, and improve the security of the configuration file.
[0041] In a possible implementation, the method further includes: the first device sends a fifth request (for example, a request for management of a subscription relationship, for example, the fourth request described above) to the operator server (for example, an authentication server ES), the fifth request carrying the authentication token, and the fifth request is used for the operator server (for example, an operator business operation support management system BOSS) to deactivate the subscription relationship of the first phone number corresponding to the second device and activate the subscription relationship of the first phone number corresponding to the first device when the authentication token carried by the fifth request is verified. The subscription relationship of the first phone number in the activated state is used to realize camping on the network through the first phone number. Therefore, after the subscription relationship of the first phone number corresponding to the second device is deactivated, the second device cannot camp on the network through the first phone number, and after the subscription relationship of the first phone number corresponding to the first device is activated, the first device can camp on the network through the first phone number.
[0042] In the above method, the operator server can deactivate the subscription relationship of the first phone number corresponding to the second device, so that the second device cannot access the network through the first phone number, and other personnel cannot use the second phone number through the second device for consumption in the case of loss of the second device, thereby effectively guaranteeing the user rights and improving the user experience.
[0043] In a possible implementation, the first device displays the first interface, including: displaying one or more phone numbers of the second device in a first area in the first interface, the first area being used to display the phone numbers of the devices other than the first device, at this time, a second area in the first interface displayed by the first device does not include the first phone number, and the second area includes other phone numbers of the first device or does not include the phone numbers, the second area being used to display the phone numbers of the first device. The above method further includes: after the first device downloads the configuration file corresponding to the first phone number from the operator server using the verification code, displaying the first phone number of the first device in the second area in the first interface, at this time, the first area in the first interface displayed by the first device does not include the first phone number, and the first area includes other phone numbers or does not include the phone numbers.
[0044] 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 in the first interface used to display the other devices, and 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 in the first interface used to display the device, so that the user can intuitively see the migration of the first phone number through the first device.
[0045] In a possible implementation, the above 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 of the user inputting the verification code in the input box. The first device downloads the configuration file corresponding to the first phone number from the operator server using the verification code in response to the second input. For example, the input box is an input box in the first network application, and the first notification is a notification of an application other than the first network application, which can be understood as receiving the verification code sent by the cloud server through the other application. In another possible implementation, the first device receives the verification code sent by the cloud server through the first network application, and then downloads the configuration file corresponding to the first phone number from the operator server using the verification code after receiving the verification code.
[0046] In the above method, the first device can make the user perceive the verification code, and input the verification code to trigger the downloading of the configuration file, so as to make the user intuitively feel and participate in the migration process, thereby improving the user experience.
[0047] In a possible implementation, the method further includes: after downloading the configuration file corresponding to the first phone number from the operator server using the verification code, displaying a third interface, the third interface including the first phone number of the first device, and receiving a third input of the user activating the first phone number; and then, in response to the third input, performing network camping through the configuration file corresponding to the first phone number.
[0048] In the method, the first device can perform network camping through the configuration file corresponding to the first phone number that is successfully migrated in response to the user input, so that the user can normally use the first phone number that is successfully migrated.
[0049] In a third aspect, the present application provides a configuration file migration method applied to a cloud server, the method including: receiving a first request sent by a first device, the first request being used to request migration of a first phone number of a second device to the first device; and then sending a verification code to the first device, the verification code being used for the first device to download a configuration file corresponding to the first phone number from an operator server (for example, a mobile network operator MNO). The second device is a source device of the first phone number to be migrated, and the first device is a target device of the first phone number to be migrated, for example, the first device is a new phone of a user, and the second device is an old phone of the user. Migration of the first phone number can be migration of a configuration file (profile) corresponding to the first phone number.
[0050] In some examples, the first phone number is a phone number of a physical subscriber identity module pSIM in the second device, so that when the second device communicates using the first phone number, the second device performs network camping through the pSIM of the first phone number. In this way, the configuration file corresponding to the first phone number is generated by the operator server and delivered to the first device after the first device sends a request to the operator server. In other examples, the first phone number is a phone number of an embedded subscriber identity module eSIM in the second device, and the second device can store the configuration file corresponding to the first phone number generated by the operator server and delivered to the second device in the eSIM module. Therefore, when the second device communicates using the first phone number, the second device performs network camping through the configuration file of the first phone number in the eSIM module. In this way, the configuration file corresponding to the first phone number is generated by the operator server and delivered to the first device after the first device sends a request to the operator server.
[0051] In some examples, the cloud server is an application server that provides services for a first network application in the first device. For example, the first interface is an interface of the first network application. Optionally, the cloud server is also an application server that provides services for a first network application in the second device.
[0052] In the method, the first device as the target device can obtain the verification code through the cloud server, and download the configuration file of the first phone number of the source device from the operator server using the verification code. Therefore, the user can complete the migration operation on the first device as the target device in a closed loop without relying on the second device as the source device, for example, without the second device being intact, online in real time, transmitting proof data, user operability, etc., greatly reducing the limitations of migration, and the user does not need to perform related operations of migration on the first device and the second device multiple times, reducing user operations, thereby effectively improving the usability and user experience of the migration function.
[0053] In a possible implementation, the method further includes that the cloud server receives the verification code sent by the operator server before sending the verification code to the first device.
[0054] In the method, the operator server can send the verification code to the trusted cloud server in the case that the first device is not determined to be a trusted device. If the first device is a trusted device of the cloud server, the verification code sent by the cloud server will be received. Therefore, even if the first device (target device) does not obtain the proof data of migration from the second device (source device) and send it to the operator server, the verification code can be obtained from the operator server through the cloud server. Thus, while ensuring security, the migration process is realized without relying on the source device.
[0055] In a possible implementation, the method further includes that the cloud server sends a second request to the operator server (for example, an authentication server ES) before receiving the verification code sent by the operator server, and then receives a first access token AccessToken sent by the operator server (for example, an authentication, authorization and accounting AAA server), the first access token is used to realize secure communication between the cloud server and the operator server. The cloud server receives the first encrypted information (that is, the encrypted information obtained by encrypting the verification code through the first access token) sent by the operator server, and 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.
[0056] In the method, the cloud server and the operator server can communicate using the first access token, further improving security.
[0057] In a possible implementation, the method further includes that the cloud server sends one or more phone numbers corresponding to the first account to the first device when the first device logs in the first account before receiving the first request sent by 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 that has logged in the first account, and the one or more phone numbers corresponding to the first account are used for the first device to display.
[0058] 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 be migrated. It can also be understood that the synchronization of the phone number is realized through the first account, and the first device and the second device do not need to interact with each other to obtain the phone number of the second device. Therefore, the synchronization of the phone number does not need to rely on the source device, further reducing the limitation of migration and improving the user experience.
[0059] In a possible implementation, the above method further includes: before the cloud server sends the one or more phone numbers corresponding to the first account to the first device, receiving the first temporary token TemporaryToken sent by the second device, and sending a third request (for example, a request indicating that the phone number is obtained) to the operator server (for example, the authentication server ES) based on the first temporary token, and then receiving the 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.
[0060] In the above method, when 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 phone number of the second device from the operator server based on the first temporary token. Therefore, when the user uses the first device later, the user can directly obtain the phone number of the second device through the cloud server which has stored the phone number of the second device, without relying on the second device, and the user experience is good.
[0061] In a fourth aspect, the present 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 is used to call the computer program and execute the configuration file migration method provided by the second aspect and any one of the implementation manners of the second aspect.
[0062] In a fifth aspect, the present 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 is used to call the computer program and execute the configuration file migration method provided by the third aspect and any one of the implementation manners of the third aspect.
[0063] In a sixth aspect, the present application provides a computer storage medium, which stores a computer program, and when the computer program is executed by a processor, the computer program is used to implement the configuration file migration method provided by the second aspect and any one of the implementation manners of the second aspect.
[0064] In a seventh aspect, the present application provides a computer storage medium, storing a computer program, which when executed by a processor, is configured to implement the configuration file migration method in the third aspect and any of the implementation manners of the third aspect.
[0065] In an eighth aspect, the present application provides a computer program product, comprising a computer program, which when executed on a processor, is configured to implement the configuration file migration method in the second aspect and any of the implementation manners of the second aspect.
[0066] In a ninth aspect, the present application provides a computer program product, comprising a computer program, which when executed on a processor, is configured to implement the configuration file migration method in the third aspect and any of the implementation manners of the third aspect.
[0067] In a tenth aspect, the present application provides a chip system, comprising a processing circuit and an interface circuit, the interface circuit is configured to receive code instructions and transmit the code instructions to the processing circuit, and the processing circuit is configured to execute the code instructions to implement the configuration file migration method in the second aspect and any of the implementation manners of the second aspect.
[0068] In an eleventh aspect, the present application provides a chip system, comprising a processing circuit and an interface circuit, the interface circuit is configured to receive code instructions and transmit the code instructions to the processing circuit, and the processing circuit is configured to execute the code instructions to implement the configuration file migration method in the third aspect and any of the implementation manners of the third aspect.
[0069] In a twelfth aspect, the present application provides an electronic device, which comprises the method or device described in any aspect or implementation manner of the present application. The electronic device is, for example, a chip.
[0070] It should be understood that the description of technical features, technical solutions, advantages or similar language in the present application does not imply that all features and advantages can be realized in any single implementation. On the contrary, it can be understood that the description of a feature or advantage means that the specific technical feature, technical solution or advantage is included in at least one implementation. Therefore, the description of technical features, technical solutions or advantages in the present application does not necessarily refer to the same implementation. Furthermore, the technical features, technical solutions and advantages described in the present application can be combined in any appropriate manner. Those skilled in the art will understand that the present application can be implemented without one or more specific technical features, technical solutions or advantages of a particular implementation. In other implementations, additional technical features and advantages can be identified in specific implementations that do not embody all implementations. BRIEF DESCRIPTION OF DRAWINGS
[0071] The following describes the drawings used in the present application.
[0072] FIG. 1 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the disclosure;
[0073] FIG. 2 is a schematic diagram of an architecture of a communication system according to an embodiment of the disclosure;
[0074] FIG. 3 is a schematic diagram of an architecture of a communication system according to an embodiment of the disclosure;
[0075] FIGS. 4A-4K are schematic diagrams of some user interfaces according to an embodiment of the disclosure;
[0076] FIG. 5 is a schematic diagram of a configuration file migration method according to an embodiment of the disclosure;
[0077] FIG. 6 is a schematic diagram of a configuration file migration method according to an embodiment of the disclosure;
[0078] FIG. 7 is a schematic diagram of a configuration file migration method according to an embodiment of the disclosure;
[0079] FIG. 8 is a schematic diagram of a configuration file migration method according to an embodiment of the disclosure. DETAILED DESCRIPTION
[0080] The technical solutions in the embodiments of the disclosure will be described below with reference to the drawings. The terms used in the implementation manner part of the embodiments of the disclosure are only used to explain the specific embodiments of the disclosure, and are not intended to limit the disclosure.
[0081] In the description of the embodiments of the disclosure, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B; "and / or" in the text only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which means that there are three cases of A alone, A and B together, and B alone. In addition, in the description of the embodiments of the disclosure, "multiple" means two or more than two.
[0082] Hereinafter, the terms "first" and "second" are only used for description purposes, and cannot be understood as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more features, and in the description of the embodiments of the disclosure, unless otherwise specified, the meaning of "multiple" is two or more than two.
[0083] FIG. 1 is a schematic diagram of a hardware structure of an electronic device 100 according to an embodiment of the disclosure.
[0084] As shown in FIG. 1, the electronic device 100 can 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, a key 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 can include a pressure sensor 180A, a gyro sensor 180B, a barometric sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light 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.
[0085] The processor 110 can include one or more processing units, for example: the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units can be independent devices, or can be integrated in one or more processors.
[0086] The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions.
[0087] The memory in the processor 110 can also be provided for storing instructions and data. In an implementation, the memory in the processor 110 is a cache memory. The memory can save instructions or data that have just been used or are repeatedly used by the processor 110. If the processor 110 needs to use the instructions or data again, it can be directly called from the memory. This avoids repeated access and reduces the waiting time of the processor 110, thereby improving the efficiency of the system.
[0088] In an implementation, the processor 110 can include one or more interfaces. The interfaces can 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.
[0089] The charging management module 140 is configured to receive charging input from a charger. The charger can be a wireless charger or a wired charger. In some implementations of wired charging, the charging management module 140 can receive charging input from a wired charger through the USB interface 130. In some implementations of wireless charging, the charging management module 140 can receive wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 can charge the battery 142 and supply power to the electronic device 100 through the power management module 141.
[0090] The power management module 141 is configured to connect 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 to supply power to the processor 110, the internal memory 121, the display 194, the camera 193, and the wireless communication module 160, etc. The power management module 141 can also be configured to monitor parameters such as battery capacity, battery cycle count, battery health status (leakage, impedance), etc. In another implementation, the power management module 141 can also be disposed in the processor 110. In another implementation, the power management module 141 and the charging management module 140 can also be disposed in the same device.
[0091] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, and a baseband processor, etc.
[0092] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. When an antenna covers multiple communication frequency bands of different communication modes, the antenna can be referred to as a mutual antenna, and the mutual antenna can be described with reference to the above-mentioned mutual antenna cases 1, 2, and 3. Different antennas can also be multiplexed to improve the utilization rate of the antennas. For example, antenna 1 can be multiplexed as a diversity antenna of a wireless local area network. In another embodiment, the antennas can be used in combination with a tuning switch.
[0093] Mobile communication module 150 can provide a solution for wireless communication including second generation (2G) / third generation (3G) / fourth-generation (4G) / fifth generation (5G) / sixth generation (6G) and the like applied to electronic device 100. Mobile communication module 150 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), and the like. Mobile communication module 150 can receive electromagnetic waves by antenna 1, and perform filtering, amplification, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to a modem processor for demodulation. Mobile communication module 150 can also amplify signals modulated by the modem processor and radiate the signals as electromagnetic waves through antenna 1. In an embodiment, at least part of the functional modules of mobile communication module 150 can be disposed in processor 110. In an embodiment, at least part of the functional modules of mobile communication module 150 and at least part of the modules of processor 110 can be disposed in the same device.
[0094] The modem can include a modulator and a demodulator. The modulator is used to modulate a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate a received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to a baseband processor for processing. The low-frequency baseband signal processed by the baseband processor is transmitted to an application processor. The application processor outputs a sound signal through an audio device (not limited to speaker 170A, microphone 170B, and the like), or displays an image or a video through display screen 194. In an embodiment, the modem can be a separate device. In another embodiment, the modem can be independent of processor 110, and disposed in the same device as mobile communication module 150 or other functional modules.
[0095] The wireless communication module 160 can provide a solution for wireless communication including wireless local area networks (WLAN) (e.g., wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), sparklink alliance specification-based wireless communication technology (e.g., SLE, SLB), etc. applied to the electronic device 100. The wireless communication module 160 can be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives an electromagnetic wave via the antenna 2, frequency-modulates and filters the electromagnetic wave signal, and transmits the processed signal to the processor 110. The wireless communication module 160 can also receive a signal to be transmitted from the processor 110, frequency-modulate it, amplify it, and radiate it as an electromagnetic wave via the antenna 2.
[0096] In one embodiment, the antenna 1 and the mobile communication module 150 of the electronic device 100 are coupled, and the antenna 2 and the wireless communication module 160 are coupled, so that the electronic device 100 can communicate with a network and other devices through wireless communication technology. The wireless communication technology can 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 technology, etc. The GNSS can include a global positioning system (GPS), a global navigation satellite system (GLONASS), a beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and / or a satellite based augmentation systems (SBAS).
[0097] The electronic device 100 implements a display function through a GPU, a display screen 194, and an application processor, etc. The GPU is a microprocessor for image processing, which is connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 can include one or more GPUs, which execute program instructions to generate or change display information.
[0098] The display screen 194 is configured to display images, videos, and the like. The 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 flex light-emitting diode (FLED), a Miniled, a MicroLed, a Micro-oLed, a quantum dot light emitting diodes (QLED), or the like. In an embodiment, the electronic device 100 can include N display screens 194, where N is a positive integer greater than 1.
[0099] The electronic device 100 can implement the photographing function through the ISP, the camera 193, the video codec, the GPU, the display screen 194, and the application processor.
[0100] The ISP is configured to process the data fed back by the camera 193. For example, when taking a photo, the shutter is opened, the light is transmitted to the camera photosensitive element through the lens, the light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing to convert it into an image visible to the naked eye. The ISP can also optimize the algorithm for the noise and brightness of the image. The ISP can also optimize the exposure and color temperature of the shooting scene. In an embodiment, the ISP can be arranged in the camera 193.
[0101] The camera 193 is configured to capture still images or videos. An object generates an optical image through a lens and projects it onto a photosensitive element. 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 transmitted to the ISP to convert it into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In an embodiment, the electronic device 100 can include one or N cameras 193, where N is a positive integer greater than 1.
[0102] The digital signal processor is used to process digital signals, in addition to being able to process digital image signals, it can also process other digital signals. For example, when the electronic device 100 selects a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy, etc.
[0103] The video codec is used to compress or decompress digital video. The electronic device 100 can support one or more video codecs. In this way, the electronic device 100 can play or record videos in multiple encoding formats, such as: moving picture experts group (MPEG) 1, MPEG 2, MPEG 3, MPEG 4, etc.
[0104] The NPU is a neural-network (NN) calculation processor, which can quickly process input information by drawing on the structure of a biological neural network, such as drawing on the transmission mode between human brain neurons, and can also constantly self-learn. Through the NPU, the electronic device 100 can realize intelligent cognition applications such as image recognition, face recognition, voice recognition, text understanding, etc.
[0105] The external memory 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 memory interface 120 to realize data storage functions. For example, music, video, etc. Files are saved in the external memory card.
[0106] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.), etc. The data storage area can store data created during the use of the electronic device 100 (such as audio data, a phonebook, etc.), etc. In addition, the internal memory 121 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various function applications and data processing of the electronic device 100 by running instructions stored in the internal memory 121 and / or instructions stored in the memory arranged in the processor.
[0107] The electronic device 100 can implement an audio function through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone interface 170D, and an application processor, etc. The electronic device 100 can also implement an audio function through a connected Bluetooth device. For example, music play, voice recording, etc.
[0108] The audio module 170 is used to convert digital audio information into an analog audio signal output, and also used to convert an analog audio input into a digital audio signal. The audio module 170 can also be used to encode and decode an audio signal. In an embodiment, the audio module 170 can be disposed in the processor 110, or part of the functions of the audio module 170 can be disposed in the processor 110.
[0109] The speaker 170A, also called "loudspeaker", is used to convert an audio electrical signal into a sound signal. The electronic device 100 can listen to music or listen to a hands-free call through the speaker 170A.
[0110] The receiver 170B, also called "earpiece", is used to convert an audio electrical signal into a sound signal. When the electronic device 100 answers a call or a voice message, the receiver 170B can be held close to the ear to listen to the voice.
[0111] The microphone 170C, also called "microphone", "sound transducer", is used to convert a sound signal into an electrical signal. When making a call or sending a voice message, the user can speak into the microphone 170C close to the mouth to input a sound signal into the microphone 170C. The electronic device 100 can be provided with at least one microphone 170C. In another embodiment, the electronic device 100 can be provided with two microphones 170C, in addition to collecting a sound signal, it can also implement a noise reduction function. In another embodiment, the electronic device 100 can also be provided with three, four or more microphones 170C, in addition to collecting a sound signal, noise reduction, it can also identify the source of the sound, implement a directional recording function, etc.
[0112] The pressure sensor 180A is configured to sense a pressure signal and convert the pressure signal into an electrical signal. In an embodiment, the pressure sensor 180A can be disposed on the display screen 194. The pressure sensor 180A can be of various types, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, etc. The capacitive pressure sensor can include at least two parallel plates of conductive material. When a force is applied to the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the pressure based on the change in capacitance. When a touch operation is applied to the display screen 194, the electronic device 100 detects the intensity of the touch operation based on the pressure sensor 180A. The electronic device 100 can also calculate the location of the touch based on the detection signal of the pressure sensor 180A. In an embodiment, touch operations applied to the same touch location but with different touch operation intensities can correspond to different operation instructions. For example, when a touch operation with an intensity less than a first pressure threshold is applied to a short message application icon, an instruction to view short messages is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the short message application icon, an instruction to create a new short message is executed.
[0113] The gyroscope sensor 180B can be configured to determine the motion posture of the electronic device 100. The barometric sensor 180C is configured to measure air pressure. The magnetic sensor 180D includes a Hall sensor. The acceleration sensor 180E can detect the magnitude of acceleration of the electronic device 100 in various directions (typically three axes). The distance sensor 180F is configured to measure distance. The proximity light sensor 180G can include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode can be an infrared light emitting diode. The ambient light sensor 180L is configured to sense ambient light brightness. The fingerprint sensor 180H is configured to acquire a fingerprint. The electronic device 100 can use the acquired fingerprint characteristics to implement fingerprint unlocking, access application locking, fingerprint photographing, fingerprint answering a call, etc. The temperature sensor 180J is configured to detect temperature. The bone conduction sensor 180M can acquire a vibration signal.
[0114] The touch sensor 180K is also referred to as a "touch device". The touch sensor 180K can be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 together form a touch screen, also referred to as a "touch panel". The touch sensor 180K is configured to detect a touch operation applied thereto or in the vicinity thereof. The touch sensor 180K 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 the display screen 194. In another embodiment, the touch sensor 180K can also be disposed on the surface of the electronic device 100, at a location different from that of the display screen 194.
[0115] The keys 190 include a power-on key, a volume key, and the like. The keys 190 can be mechanical keys. They can also be touch keys. The electronic device 100 can receive key inputs and generate key signal inputs related to user settings and function control of the electronic device 100. The motor 191 can generate a vibration prompt. The indicator 192 can be an indicator light that can be used to indicate a charging state, a power change, and can also be used to indicate a message, a missed call, a notification, and the like.
[0116] The eSIM module 195 can be embedded in the electronic device 100, for example, in a non-pluggable form installed in the electronic device 100, for example, embedded inside the mainboard of the electronic device 100. It can replace a physical SIM card (i.e., a physical SIM (pSIM)) for the electronic device 100 to interact with a network to implement functions such as calling and data communication, but the size of the eSIM module 195 is generally much smaller. Unlike a physical SIM card, the eSIM module 195 can switch numbers or change operators at will because the information on the eSIM module 195 can be rewritten. The eSIM module 195 can be remotely configured by over-the-air technology (OTA) to implement profile downloading, activation, deactivation, and deletion, and the like.
[0117] The eSIM module 195 can store one or more profiles. A profile includes card information of one or more non-physical SIM cards (which can be referred to as eSIMs). For ease of illustration, an embodiment of the present application takes a profile including card information of one eSIM as an example for illustration. Among them, any two profiles in the eSIM module 195 can correspond to the same operator or different operators. For example, after the user signs a contract with operator A through the electronic device 100, operator A issues an eSIM1 corresponding to operator A to the electronic device 100, that is, the electronic device 100 can download a profile1 corresponding to operator A (including card information of the eSIM1) from the profile server of operator A. After the user signs a contract with operator B through the electronic device 100, operator B issues an eSIM2 corresponding to operator B to the electronic device 100, that is, the electronic device 100 can download a profile2 corresponding to operator B (including card information of the eSIM2) from the profile server of operator B.
[0118] In some embodiments of the present application, the electronic device 100 can activate at least one profile in the eSIM module 195, and camp on the network through the activated profile. For example, the electronic device 100 can perform legality authentication (which can be referred to as authentication) at the corresponding operator through the activated profile, and after the authentication is passed, the electronic device 100 is allowed to access the mobile communication network.
[0119] The hardware structure of the electronic device 200 and the like in the embodiments of the present application can also be the hardware structure shown in FIG. 1.
[0120] It should be understood that the electronic device shown in the embodiments of the present application is only an example, and the electronic device can have more or fewer components than those shown in the above embodiments, can combine two or more components, or can have a different component configuration. The various components shown in the figure 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, the electronic device 200 can not only include the eSIM module 195 shown in FIG. 1, but also include a SIM card interface for connecting one or more pSIMs. The pSIM can be inserted into or pulled out of the SIM card interface to realize contact and separation with the electronic device 200. The pSIM can include, but is not limited to, a Nano SIM card, a Micro SIM card, a SIM card, and the like.
[0121] FIG. 2 is a schematic diagram of an architecture of a communication system 10 according to an embodiment of the present application.
[0122] As shown in FIG. 2, the communication system 10 can include an electronic device 100, an electronic device 200, a cloud server 300, and a mobile network operator (MNO) 400. The MNO 400 can include an entitlement server (ES) 410, a business & operation support system (BOSS) 420, a profile server 430, an authentication authorization accounting (AAA) server 440, and a home subscriber server (HSS) 450.
[0123] The ES 410 can be configured to perform identity authentication. The BOSS 420 can be configured to implement management of a subscription relationship of a profile, where, after any electronic device downloads a profile corresponding to the MNO 400, if the BOSS 420 configures the electronic device with a subscription relationship of the profile, the electronic device can use the profile to implement network camping, and if the BOSS 420 does not configure the electronic device with the subscription relationship of the profile, the electronic device cannot use the profile to implement network camping. The profile server 430 can be configured to provide a download service of a profile corresponding to the MNO 400, for example, the profile 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 be configured to provide services such as authentication, authorization, and charging, for example, the AAA server 440 can include multiple servers such as an MNO authentication server, where the MNO authentication server is configured to provide authentication services, and other servers are configured to provide services such as authorization and charging. The HSS 450 can be configured to provide services such as identity authentication, location query, and service authorization.
[0124] In the embodiments of the present application, the electronic device 100 can be any one of a mobile phone, a tablet computer, a handheld computer, a desktop computer, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), and a smart large screen, a smart sound box, and the like smart home device, a smart bracelet, a smart watch, smart glasses, and the like wearable device, an augmented reality (AR), a virtual reality (VR), a mixed reality (MR), and the like extended reality (XR) device, a vehicle-mounted device or a smart city device, and the like. The electronic device 200 is similar to the electronic device 100, and will not be described again.
[0125] In some embodiments of the present application, the cloud server 300 can provide an application service for a first network application, and the electronic device 100 / electronic device 200 installed with the first network application can access the cloud server 300 and perform data interaction with the cloud server 300.
[0126] In some embodiments of the present application, the electronic device 100 / electronic device 200 can connect one or more pSIMs, for example, the user purchases a pSIM corresponding to the MNO 400 and inserts the pSIM into the SIM card interface of the electronic device 200. In some embodiments of the present application, after the electronic device 100 / electronic device 200 and the MNO 400 sign a contract, the MNO 400 can issue a corresponding eSIM to the electronic device 100 / electronic device 200, that is, the electronic device 100 / electronic device 200 can download the profile (including the card information of the eSIM corresponding to the MNO 400) from the profile server 430 in the MNO 400 and store it in the eSIM module.
[0127] In the migration scenario of the embodiment example of the present application, the user can "migrate" the card information of the pSIM / eSIM in the electronic device 200 to the electronic device 100. Among them, the electronic device 200 can be referred to as a source device, and the electronic device 100 can be referred to as a target device, for example, the electronic device 200 is the user's old phone, and the electronic device 100 is the user's new phone. It can be understood that the above "migration" of the card information of the pSIM / eSIM in the electronic device 200 to the electronic device 100 is from the perspective of the user. In a specific implementation, the electronic device 100 as the target device can not obtain the card information of the migrated pSIM / eSIM from the electronic device 200, but obtain the card information of the migrated pSIM / eSIM from the MNO corresponding to the migrated pSIM / eSIM. The following takes the MNO 400 corresponding to the migrated pSIM / eSIM as an example to illustrate the migration scenario.
[0128] In some examples, the pSIM in the electronic device 200 can be purchased by the user at the offline point of the MNO 400. In the migration scenario of "migrating" the card information of the pSIM in the electronic device 200 to the electronic device 100, the profile server 430 in the MNO 400 can generate a profile corresponding to the migrated pSIM (including the card information of the migrated pSIM), and the electronic device 100 as the target device can download the profile from the profile server 430.
[0129] In some examples, the profile (including the card information of the eSIM) in the eSIM module of the electronic device 200 can be downloaded by the electronic device 200 from the profile server 430 in the MNO 400. In the migration scenario, the user migrates the card information of the eSIM in the electronic device 200 to the electronic device 100, and the electronic device 100 as the target device can download the profile corresponding to the migrated eSIM (including the card information of the migrated eSIM) from the profile server 430 in the MNO 400. The profile downloaded by the electronic device 100 can be the same as the profile in the eSIM module of the electronic device 200.
[0130] Not limited to the above examples, in other examples, the user can also migrate the card information of the virtual SIM (vSIM) in the electronic device 200 to the electronic device 100, in which case the electronic device as the target device can download the card information corresponding to the vSIM from the MNO. The embodiments of the present application do not limit the type of SIM migrated.
[0131] It can be understood that in the migration scenario, regardless of the type of SIM migrated, it is the card information of the SIM that is migrated. For the sake of convenience, the card information of one SIM is packaged into one profile for example, and therefore the migration in the embodiments of the present application is profile migration.
[0132] Currently, in the profile migration process, the source device needs to generate relevant attestation data in real time, such as an integrated circuit card identifier (ICCID) (for example, for identifying an eSIM module), an embedded universal integrated circuit card (UICC) identifier (EID) (for example, for identifying a profile in an eSIM module), a transfer access token, a trust flag, an authentication and key agreement (AKA) token, an expiration time of the AKA token, a scope, a uniform resource locator (URL) of a server, a device name, and the like. The source device also needs to upload these relevant attestation data to the cloud in real time, and the target device needs to obtain these relevant attestation data from the cloud in real time and transmit them to the ES 410 in the corresponding MNO (taking the MNO 400 as an example for illustration) for authentication. After the authentication is passed, the ES 410 and the BOSS 420 are synchronized, the BOSS 420 implements configuration change of the subscription relationship (that is, changes the configuration device of the subscription relationship corresponding to the profile from the source device to the target device), and the websheet server (not shown) in the MNO 400 calls back the system interface of the target device to enable the target device to download the profile. Moreover, the profile migration process needs to meet the following conditions: the source device and the target device are powered on at the same time and log in to the same account, the source device and the target device are simultaneously camped on a network or connected to a wireless fidelity (Wi-Fi) network, the source device and the target device are both unlocked and operable, and the user needs to perform multiple operations related to migration (such as clicking a confirmation control and the like) on the source device and the target device. Therefore, the current profile migration process is strongly dependent on the source device, and needs the source device to be intact, online in real time, transmit attestation data, and be operable by the user. Moreover, the target device and the websheet server need to customize the system interface (for example) callback configuration. The migration is limited in many ways, and the user needs to perform tedious synchronization operations, and the usability is not high.
[0133] The embodiment of the present application provides a configuration file migration method, which can be applied to the communication system 10. The embodiment of the present application can realize profile migration (taking the example of migrating the profile corresponding to the pSIM / eSIM in the electronic device 200 to the electronic device 100) through the cloud server 300. In the profile migration process, the electronic device 100 as the target device can interact with the cloud server 300 and the MNO 400 to obtain a one time password (OTP). The OTP can also be referred to as a verification code. The electronic device 100 can interact with the MNO 400 through the OTP to download the profile corresponding to the pSIM / eSIM in the electronic device 200 from the MNO 400. For example, the electronic device 100 can initiate qualification review to the ES 410 in the MNO 400 through the OTP, and after the qualification review is passed, the electronic device 100 can download the profile from the profile server 430. After the qualification review is passed, the BOSS 420 in the MNO 400 can realize configuration change of the subscription relationship (that is, changing the configuration device of the subscription relationship corresponding to the profile from the source device to the target device). Therefore, the user can safely complete the migration operation on the target device in a closed loop, and no longer depends on the source device, and does not need to customize the target device and the MNO, greatly reduces the limitation of migration, and does not need the user to perform a tedious synchronization operation, effectively improves the availability and user experience.
[0134] In some embodiments of the present application, before the profile migration, the electronic device 200 can interact with the MNO 400, the electronic device 200 can interact with the cloud server 300, and the cloud server 300 can interact with the MNO 400, so that the cloud server 300 obtains the mobile station international subscriber directory number (MSISDN) (hereinafter can be referred to as a telephone number or a number) of the pSIM / eSIM in the electronic device 200 from the MNO 400. Subsequently, the electronic device 100 can log in the same account as the electronic device 200 (for example, log in the same account in the first network application), and access the cloud server 300 to obtain the telephone number of the pSIM / eSIM in the electronic device 200. In this way, the user can view the telephone number of the pSIM / eSIM on the electronic device 200 through the electronic device 100, so as to select the telephone number to be migrated. Therefore, the embodiment of the present application does not need to interact between the source device and the target device, and can realize synchronization of the telephone number by means of the cloud server 300.
[0135] FIG. 3 is a schematic diagram of another communication system 10 according to an embodiment of the present application.
[0136] As shown in FIG. 3, the communication system 10 can include an electronic device 100, an electronic device 200, a cloud server 300, and an MNO 400. The MNO 400 can include an ES 410, a BOSS 420, a profile server 430, an AAA server 440, and an HSS 450. The related descriptions are similar to those of FIG. 2, and are not repeated here.
[0137] As shown in FIG. 3, the architecture of the electronic device 100 can include a processor 101, a mobile communication module 102, and an eSIM module 103. The processor 101 can include an application layer, a framework layer, a radio interface layer (RIL), and an attention (AT) command.
[0138] The application layer can include one or more application programs, such as the first network application and the eSIM user experience (UX) shown in FIG. 3. The eSIM UX can be used to implement the user experience related to eSIM (for example, to implement a language user interface (LUI)). The eSIM UX can be a standalone application program, or can be integrated into other application programs, such as the first network application. The application program in the embodiments of the present application can also be replaced by a mini program, an atomic service, or other forms of software.
[0139] The framework layer provides an application programming interface (API) and a programming framework for the application programs of the application layer. The framework layer can include some predefined functions. For example, as shown in FIG. 3, the framework layer can include a first network service, a first standard library, a local profile assistant (LPA) service, and a phone manager, etc. Among them, 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 (for example, the mobile communication module 102) in the electronic device 100 except the processor 101. The first standard library, for example but not limited to, is a static library of the glotal systen for mobile conmunications association (GSMA) TS.43ES specification, which, for example, provides some pre-compiled functions that provide implementations of 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 implement management of profiles in the eSIM module 103, such as downloading, activating, deactivating, and deleting, etc. The LPA service can obtain operation events of the profiles from the eSIM UX of the application layer, and manage the profiles in the eSIM module 103 according to the obtained operation events. The phone manager can be used to provide communication functions of the electronic device 100, such as management of call states (including call connection, call hang-up, etc.).
[0140] The RIL and the AT command can be used to implement communication between the upper layer services (such as the application layer and the framework layer) and the communication modules (such as the mobile communication module 102), the RIL can be understood as an intermediate layer of communication, and the AT command can be understood as an instruction of communication.
[0141] 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. The description of the eSIM module 103 can refer to the description of the eSIM module 195 in FIG. 1. In some embodiments of the present application, the mobile communication module 102 and the eSIM module 103 can communicate through a standard protocol (for example, an international organization for standardization (ISO) standard). In some embodiments of the present application, the upper layer service such as the application layer and the framework layer can communicate between the mobile communication module 102 and the eSIM module 103, for example, the LPA service communicates between the mobile communication module 102 and the eSIM module 103, so as to implement the management of the profile in the eSIM module 103.
[0142] In some embodiments of the present 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, so as to implement the user service such as call and network access.
[0143] The architecture of the electronic device 200 can include a processor 201, a mobile communication module 202 and an eSIM module 203, and the architecture of the electronic device 200 is similar to that of the electronic device 100, which will not be repeated. The architecture of the electronic device 100 and the electronic device 200 shown in FIG. 3 is only for example, and should not be construed as limitation.
[0144] As shown in FIG. 3, the cloud server 300 can include an authentication system, a synchronization system and an order management system, etc. Among them, the authentication system can be used to obtain an access token (AccessToken), and the AccessToken can be used to implement reliable communication between the cloud server 300 and the MNO 400. The synchronization system can be used to obtain and synchronize the phone number, for example, the phone number of the electronic device 200 is obtained when the electronic device 200 logs in account 1, and the phone number of the electronic device 200 is synchronized to the electronic device 100 when the electronic device 100 logs in account 1, which can be understood as implementing the synchronization of the phone number between the same account and different devices. The order management system is used to manage the package order corresponding to the phone number, for example, to obtain and synchronize the package order.
[0145] In the profile migration scenario shown in the embodiments of the present application (taking the example of migrating the profile corresponding to the pSIM / eSIM in the electronic device 200 to the electronic device 100), before the profile migration, the cloud server 300 can obtain the phone number of the pSIM / eSIM in the electronic device 200 as the source device, and specific examples can be referred to steps 1-4 shown in FIG. 3. And in the profile migration process, the phone number of the pSIM / eSIM in the electronic device 200 can be synchronized to the electronic device 100 as the target device through the cloud server 300, and specific examples can be referred to step 5 shown in FIG. 3, and the electronic device 100 can also download the profile corresponding to the pSIM / eSIM in the electronic device 200 from the MNO 400 through the cloud server 300, and specific examples can be referred to steps 6-8 shown in FIG. 3.
[0146] As shown in step 1 of FIG. 3, the electronic device 200 obtains an authentication token (AuthToken) 1 from the MNO 400. Wherein, when the electronic device 200 includes the pSIM / eSIM corresponding to the MNO 400, the electronic device 200 can interact with the MNO 400 to perform authentication and key agreement (AKA) authentication (such as extensible authentication protocol-AKA (EAP-AKA)). After the AKA authentication, the MNO 400 can issue an authentication token (AuthToken) 1 to the electronic device 200. For example, the electronic device 200 calls the first standard library to implement the AKA authentication with the MNO 400.
[0147] As shown in step 2 of FIG. 3, the electronic device 200 obtains a new temporary token (NewTemporaryToken) from the MNO 400 based on the AuthToken 1. Wherein, the electronic device 200 can interact with the MNO 400 based on the AuthToken 1 and receive the NewTemporaryToken sent by the MNO 400. For example, the first network service of the electronic device 200 obtains the NewTemporaryToken from the MNO 400.
[0148] As shown in step 3 of FIG. 3, the electronic device 200 sends the NewTemporaryToken to the cloud server 300. For example, the electronic device 200 installs a first network application, the cloud server 300 is a server providing services for the first network application, and the first network application of the electronic device 200 sends the NewTemporaryToken to the cloud server 300.
[0149] As shown in step 4 of FIG. 3, the cloud server 300 obtains the phone number from the MNO 400 based on the NewTemporaryToken. Among them, the cloud server 300 obtains the AccessToken from the MNO 400. The cloud server 300 can interact with the MNO 400 based on the NewTemporaryToken and the AccessToken, and receive the phone number of the electronic device 200 sent by the MNO 400 (which can be the phone number of the pSIM / eSIM corresponding to the MNO 400 in the electronic device 200).
[0150] Not limited to the above examples, in other examples, when the electronic device 200 further includes pSIM / eSIM corresponding to other MNOs, steps 1 to 4 described above can be performed for other MNOs (MNO 400 in them is replaced by other MNOs) to make the cloud server 300 obtain the phone numbers of all pSIM / eSIMs in the electronic device 200.
[0151] As shown in step 5 of FIG. 3, when the user logs in account 1 in the first network application of the electronic device 100, the cloud server 300 can send the phone number corresponding to the account 1 to the first network application of the electronic device 100. Among them, the account 1 can be the account logged in the first network application of the electronic device 200, and when the user logs in the account 1 in the first network application of the electronic device 100, the cloud server 300 can synchronize the phone number corresponding to the account 1 to the first network application of the electronic device 100. The phone number corresponding to the account 1 can include the phone number of the electronic device 200, and the phone number of the electronic device 200 can include the phone number obtained in step 3. The electronic device 100 can display the phone number corresponding to the account 1 in the first network application.
[0152] As shown in step 6 of FIG. 3, when the user selects the migrated phone number 1 in the first network application of the electronic device 100, the electronic device 100 can obtain the OTP from the MNO 400 through the cloud server 300. Among them, the migrated phone number 1 selected by the user can be the phone number of the pSIM / eSIM in the electronic device 200. The electronic device 100 can interact with the cloud server 300, the electronic device 100 can interact with the MNO 400, the cloud server 300 can interact with the MNO 400 based on the Access Token, and the MNO 400 can issue the OTP to the electronic device 100 through the cloud server 300.
[0153] As shown in step 7 of FIG. 3, the electronic device 100 performs qualification based on the OTP. Among them, the electronic device 100 can interact with the MNO 400 based on the OTP, so that the MNO 400 performs qualification on the electronic device 100. After the qualification is passed, the MNO 400 allows the electronic device 100 to download the profile, for example, after the qualification is passed, the MNO 400 issues download information to the electronic device 100, and the download information can include the address information of the profile server 430. After the qualification is passed, the BOSS 420 in the MNO 400 can migrate the configuration of the subscription relationship of the phone number 1 to the electronic device 100, for example, deactivate the configuration of the subscription relationship of the phone number 1 corresponding to the electronic device 200, and activate the configuration of the subscription relationship of the phone number 1 corresponding to the electronic device 100.
[0154] As shown in step 8 of FIG. 3, the electronic device 100 downloads the profile from the MNO 400. Among them, the electronic device 100 can download the profile corresponding to the phone number 1 from the profile server 430 in the MNO 400, so as to realize the migration of the profile corresponding to the pSIM / eSIM in the electronic device 200 to the electronic device 100.
[0155] It can be understood that in different profile migration processes, the OTP obtained by the target device can be different, for example, the OTP obtained by different target devices is different, the OTP corresponding to different source devices is different, the OTP corresponding to different migration numbers is different, the OTP obtained at different times is different, and the like. It can be understood as "one-time password", so the security is high.
[0156] The communication between the electronic device 100 and the cloud server 300 and the MNO 400 can be implemented through a first standard library, and the communication between the electronic device 200 and the cloud server 300 and the MNO 400 can also be implemented through the first standard library. The first standard library can be, but is not limited to, a library of a standard specification such as TS.43ES specification, so that the embodiments of the present application can be compatible with the standard specification, and the application scenarios are more extensive.
[0157] In some embodiments of the present application, the cloud server 300 can be understood as a mobile virtual network operator (MVNO). The MVNO can refer to an operator that does not need to apply for spectrum or build a network, but wholesales network capacity from an MNO and provides mobile communication services to users using its own brand. Optionally, the cloud server 300 can provide application services for a first network application, and the first network application can provide services of the MVNO to the user. The docking between the cloud server 300 and the MNO 400 can be understood as docking between operators.
[0158] Not limited to the above examples, in another example, the user can also select to migrate a telephone number corresponding to another MNO, so that the above steps 6 to 8 can be performed for the other MNO (in which the MNO 400 is replaced by the other MNO) to enable the electronic device 100 to download the profile corresponding to the telephone number selected by the user to migrate.
[0159] It can be understood that the forms and quantities of the electronic device 100, the electronic device 200, the cloud server 300 and the MNO 400 shown in FIGS. 2 and 3 are only for example. For example, the source device of the profile migration can be more, and the user can select to migrate the profile corresponding to the pSIM / eSIM on one or more source devices. For example, the target device of the profile migration can also be more. For example, the migrated profile can be more and can belong to different MNOs, so the MNOs can be more, and the embodiments of the present application do not limit this.
[0160] Next, the application scenarios of the profile migration and the user interfaces in the application scenarios are exemplarily introduced.
[0161] FIGS. 4A-4K are schematic diagrams of some user interfaces provided by the embodiments of the present application.
[0162] As shown in FIG. 4A, the electronic device 100 (target device) can display a user interface 410 of the first network application. In some examples, the user interface 410 can be displayed by the electronic device 100 in response to a user operation of the application icon of the first network application in the home page of the electronic device 100, for example, the user operation is a touch operation (such as a click operation).
[0163] As shown in FIG. 4A, the user interface 410 can include a status bar 411 at the top, a search bar 412, a recommendation list 413, a showcase bar 414, a trip bar 415, and a menu bar 416 at the bottom. The status bar 411 can include a signal identifier 411A of the pSIM / eSIM, a power level, and time information, where the signal identifier 411A can represent that the electronic device 100 is not currently connected to a mobile communication network. In some embodiments of the present application, the provider of the first network application can purchase a seed card from the operator, and can provide the seed card to the user of the first network application, so that the user can normally use the first network application without connecting to other networks (e.g., in a "no network" scenario perceived by the user), i.e., the cost of the seed card is purchased in advance by the provider of the first network application, without the need for the user to purchase. The electronic device 100 installed with the first network application can download or preinstall the profile of the seed card in the eSIM module. Therefore, although the signal identifier 411A indicates that the electronic device 100 is not currently connected to a mobile communication network, when the electronic device 100 runs the first network application, the profile of the seed card in the eSIM module can be used for network access, so that the user interface of the first network application can be normally displayed.
[0164] The search bar 412 is used to search for the required destination traffic package. The recommendation list 413 is used to recommend traffic packages for different destinations. The showcase bar 414 is used to display one or more contents, such as to display summary information of the "outbound Internet guide", and to view detailed information of the "outbound Internet guide". The trip bar 415 is used to view relevant information of the user's trip, such as the purchased traffic package. The menu bar 416 can include a "recommendation" control 416A and a "my" control 416B, where the "recommendation" control 416A is in a selected state, representing that the user interface 410 currently displays the page corresponding to the "recommendation" control 416A. The "my" control 416B can be used to trigger the display of the user's information, such as the purchase order, the collection, the settings, etc. The user can purchase the required destination traffic package through the first network application, and the user can enable the purchased traffic package to access the Internet.
[0165] The user can log in account 1 in the first network application of the electronic device 100 (target device), for example, log in account 1 through the user interface 420 shown in FIG. 4B. Account 1 can be an account that the user has logged in in the first network application of the electronic device 200 (source device). The user interface 420 can be displayed based on a series of operations performed by the user on the user interface 410 and the like of the first network application. In some examples, the electronic device 100 can display a trip interface in response to a user operation (e.g., a click operation) acting on the trip bar 415 in the user interface 410. In the case where no account is logged in, the trip interface can display a control for logging in an account. The electronic device 100 can display the user interface 420 shown in FIG. 4B in response to a user operation (e.g., a click operation) acting on the control for logging in an account. In other examples, the electronic device 100 can display a “my” interface in response to a user operation (e.g., a click operation) acting on the “my” control 416B in the user interface 410. In the case where no account is logged in, the “my” interface can display a control for logging in an account. The electronic device 100 can display the user interface 420 shown in FIG. 4B in response to a user operation (e.g., a click operation) acting on the control for logging in an account.
[0166] As shown in FIG. 4B, the user interface 420 can include a status bar 421 at the top, an input box 422 for logging in an account, an input box 423 for an account password, a login control 424, a control for registering an account, a control for logging in in other ways, and the like. The status bar 421 is similar to the status bar 411 in the user interface 410 shown in FIG. 4A, and will not be described again.
[0167] After the user logs in account 1 in the first network application of the electronic device 100 (target device), the user can view the traffic package corresponding to account 1. FIG. 4C exemplarily shows a user interface 430 of the first network application after logging in account 1. The user interface 430 can include a status bar 431 at the top, an account name 1 of account 1, an order control 433, and a menu bar 434 at the bottom, and the like. The status bar 431 is similar to the status bar 411 in the user interface 410 shown in FIG. 4A, and will not be described again. The menu bar 434 is similar to the menu bar 416 in the user interface 410 shown in FIG. 4A, but the “my” control in the menu bar 434 is in a selected state, indicating that the user interface 430 currently displays the page corresponding to the “my” control. The electronic device 100 can display the traffic package corresponding to account 1, for example, the user interface 440 shown in FIG. 4D, in response to a user operation (e.g., a click operation) acting on the order control 433 in the user interface 430.
[0168] As shown in FIG. 4D, the user interface 440 can include a status bar 441 at the top and orders of account 1. The status bar 441 is similar to the status bar 411 in the user interface 410 shown in FIG. 4A and will not be repeated here. The orders of account 1 can include a traffic package of account 1 and other orders. The traffic package of account 1 shown in the user interface 440 can include a traffic package of a phone number on the current device (i.e., the electronic device 100) (e.g., a traffic package 442 of a phone number 11) and a traffic package of a phone number on another device. Taking the electronic device 200 as an example of the other device with a device name of device A, the traffic package of a phone number on the other device includes, for example, a traffic package 443 of a phone number 22 and a traffic package 444 of a phone number 33.
[0169] The user can enable or disable the traffic package of any phone number on the current device in the first network application of the electronic device 100. In some examples, the traffic package 442 of the phone number 11 on the electronic device 100 can include a switch control 442A that can be used to enable or disable the traffic package 442 of the phone number 11 on the electronic device 100, and the user interface 440 takes the traffic package 442 of the phone number 11 as a disabled state (e.g., the switch control 442A displays the character “enable”) as an example.
[0170] The user can migrate a phone number on the other device to the current device in the first network application of the electronic device 100, so as to use the traffic package of the phone number on the other device on the current device. In some examples, the traffic package 443 of the phone number 22 on the device A (i.e., the electronic device 200) can include a migration-in control 443A, and the traffic package 444 of the phone number 33 can also include a migration-in control 444A. The migration-in control 443A can be used to “migrate” the pSIM / eSIM corresponding to the phone number 22 on the electronic device 200 to the electronic device 100. The migration-in control 444A can be used to “migrate” the pSIM / eSIM corresponding to the phone number 33 on the electronic device 200 to the electronic device 100.
[0171] When the traffic plan of the account 1 in the first network application of the electronic device 100 (target device) is in the state shown by the user interface 440 of FIG. 4D, the traffic plan of the account 1 in the first network application of the electronic device 200 (source device) can be in the state shown by the user interface 450 of FIG. 4E. The user interface 450 can include a status bar 451 at the top and the traffic plan of the account 1, and the traffic plan of the account 1 shown by the user interface 450 can include: the traffic plan of the phone number on the device (i.e., the electronic device 200), such as the traffic plan 452 of the phone number 22 and the traffic plan 453 of the phone number 33. The user interface 450 is illustrated by taking the traffic plan 452 of the phone number 22 as the enabled state (for example, the switch control 452A displays the character “off”) and the traffic plan 453 of the phone number 33 as the disabled state (for example, the switch control 453A displays the character “enable”) as an example. Therefore, the electronic device 100 can access the mobile communication network through the pSIM / eSIM corresponding to the phone number 22, at this time, the signal identification 451A of the mobile communication network in the status bar 451 can represent the signal quality of the accessed mobile communication network, for example, it represents that the currently accessed is a fourth-generation (4G) network with a signal strength of 4 bars (i.e., full bars).
[0172] Next, an example is described in which a user selects to migrate phone number 22 on electronic device 200 to electronic device 100 in a first network application on electronic device 100. In the following example, it is assumed that electronic device 200 is already using a traffic package for phone number 22. In response to a user operation (e.g., a tap operation) on migration-in control 443A in user interface 440 shown in FIG. 4D, electronic device 100 can display user interface 460 shown in FIG. 4F. User interface 460 can include status bar 461 and prompt box 462. Status bar 461 is similar to status bar 411 in user interface 410 shown in FIG. 4A and is not described again. Prompt box 462 can include prompt information “Phone number 22 being transferred is currently used on device A in your account. Please confirm whether to migrate in and enable”, confirmation control 462A, and cancel control 462B. Confirmation control 462A can be used to confirm the migration, and cancel control 462B can be used to cancel the migration. In response to a user operation (e.g., a tap operation) on confirmation control 462A in user interface 460, electronic device 100 can display a verification interface for the migration, for example, user interface 470 shown in FIG. 4G. User interface 470 can include message bar 471 and prompt box 472. In the following example, message bar 471 can be used to display a verification code received by electronic device 100, which can be an OTP issued by the MNO corresponding to phone number 22 for the migration. Electronic device 100 can receive the verification code through an application such as, but not limited to, a short message application or a first network application of the system. Prompt box 472 can include input box 472A for the verification code, confirmation control 472B, and cancel control 472C. The user can manually enter the verification code in message bar 471 into input box 472A in prompt box 472, or electronic device 100 can automatically enter the verification code in message bar 471 into input box 472A in prompt box 472. Confirmation control 472B can be used to trigger the migration to continue. Cancel control 472C can be used to cancel the migration. In response to a user operation (e.g., a tap operation) on confirmation control 472B, electronic device 100 can continue the migration, display user interface 480 shown in FIG. 4H during the migration, and then display user interface 490 shown in FIG. 4I.
[0173] The user interface 480 shown in FIG. 4H is similar to the user interface 440 shown in FIG. 4D, but in the user interface 480, the traffic package of the phone number on the present device (i.e., the electronic device 100) includes not only the traffic package 442 of the phone number 11, but also the traffic package 443 of the phone number 22 migrated from the electronic device 200, while the traffic package of the phone number on the electronic device 200 (device name: device A) includes the traffic package 444 of the phone number 33. The traffic package 443 shown in the user interface 480 does not include the migration-in control 443A, but includes a loading control 443B, which can represent that the traffic package 443 of the phone number 22 is currently being migrated and enabled.
[0174] The user interface 490 shown in FIG. 4I is similar to the user interface 480 shown in FIG. 4H, but in the user interface 490, the traffic package 443 of the phone number 22 does not include the loading control 443B, but includes a switch control 443C, which can be used to enable or disable the traffic package 443 of the phone number 22. The traffic package 443 in the user interface 490 is in an enabled state (e.g., the switch control 443C displays the character “off”), so the electronic device 100 can access the mobile communication network through the pSIM / eSIM corresponding to the phone number 22, at this time, the signal identifier 491A of the mobile communication network in the status bar 491 shown in the user interface 490 can represent the signal quality of the accessed mobile communication network, for example, representing that the currently accessed is a 4G network with a signal strength of 4 bars (i.e., full bars).
[0175] When the traffic package of the account 1 in the first network application of the electronic device 100 (target device) is in the state shown in the user interface 480 shown in FIG. 4H, the traffic package of the account 1 in the first network application of the electronic device 200 (source device) can be in the state shown in the user interface 500 shown in FIG. 4J. The user interface 500 shown in FIG. 4J is similar to the user interface 450 shown in FIG. 4E, but in the user interface 500, the signal identifier 501A of the mobile communication network in the status bar 501 can represent that the electronic device 100 is currently not accessing the mobile communication network. The user interface 500 can also include a prompt information 502 of “loading”, representing that the order information is currently being refreshed and loaded. The switch control 452A included in the traffic package 452 of the phone number 22 and the switch control 453A included in the traffic package 453 of the phone number 33 in the user interface 500 are in an unavailable state (e.g., displayed in gray), so they cannot be operated. It can be understood that although the signal identifier 501A indicates that the electronic device 100 is currently not accessing the mobile communication network, the electronic device 100 can use the profile of the seed card in the eSIM module to access the network, so as to refresh and load the order information. The order information after refreshing and loading can be referred to the user interface 510 shown in FIG. 4K.
[0176] When the traffic plan of the account 1 in the first network application of the electronic device 100 (target device) is in the state shown in the user interface 490 of FIG. 4I, the traffic plan of the account 1 in the first network application of the electronic device 200 (source device) can be in the state shown in the user interface 510 of FIG. 4K. The user interface 510 shown in FIG. 4K is similar to the user interface 450 shown in FIG. 4E, but in the user interface 510, the signal identifier 511A of the mobile communication network in the status bar 511 can represent that the electronic device 100 is currently not connected to the mobile communication network. Also, in the user interface 510, the traffic plan of the phone number on the device (i.e., the electronic device 200) includes only the traffic plan 453 of the phone number 33, and the traffic plan 452 of the phone number 22 is the traffic plan of the phone number on the other device (i.e., the electronic device 100 with the device name as device B) other than the device. The traffic plan 452 does not include the on-off control 452A, but includes the migration-in control 452B, which can be used to "migrate" the pSIM / eSIM corresponding to the phone number 22 on the electronic device 100 to the electronic device 200.
[0177] The application scenarios of the above examples are described by taking the traffic plan of the phone number with the migration enabled by default as an example. In some other examples, the traffic plan of the phone number with the migration can be disabled by default, and the user can select whether to enable the traffic plan of the phone number with the migration after the migration is successful. In some other examples, the user can be prompted during the migration, and whether to enable the traffic plan of the phone number with the migration can be selected according to the user response. The embodiments of the present application are not limited in this regard.
[0178] In the application scenarios of the above examples, the electronic device 100 can prompt the user whether to migrate through the prompt box 462 in the user interface 460 shown in FIG. 4F. In some other examples, the user can not be prompted, and the user can be directly defaulted to confirm the migration. The embodiments of the present application are not limited in this regard.
[0179] In the application scenarios of the above examples, the electronic device 100 can display the OTP to the user in the form of a verification code through the user interface 470 shown in FIG. 4G, and let the user input. In some other examples, the user can not be displayed, and the user can not be required to input. After the electronic device 100 receives the OTP, the migration can be automatically performed. The embodiments of the present application are not limited in this regard.
[0180] The application scenarios of the above examples are described by taking the device of the login account 1 as the electronic device 100 and the electronic device 200, and in a specific implementation, there can be more devices logging in the account 1, and therefore, the traffic package of the account 1 displayed by the electronic device 100 can include the traffic package of the phone number on more devices, and the user can select to migrate the traffic package of the phone number on one or more devices.
[0181] The application scenarios of the above examples are described by taking the phone number in the electronic device 200 as an example to be synchronized to the electronic device 100, and therefore, the traffic package of the account 1 in the first network application displayed by the electronic device 200 in the above examples only shows the traffic package of the phone number on the electronic device 200. For example, the cloud server 300 does not obtain the phone number in the electronic device 100, and therefore, cannot synchronize the phone number in the electronic device 100 to the electronic device 200. In some other examples, the phone number in the electronic device 100 can also be synchronized to the electronic device 200, and in this case, the traffic package of the account 1 in the first network application displayed by the electronic device 200 can also include the traffic package of the phone number on the electronic device 100, and the user can also select to migrate the traffic package of the phone number on the electronic device 100 on the electronic device 200, and the embodiments of the present application are not limited thereto.
[0182] In the application scenarios of the above examples, the user can view the information of the phone number on the 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, but the present application is not limited thereto, and in some other examples, the viewing of the phone number and the migration can also be implemented in the settings application of the system (for example, by using the SIM card management function in the settings application), and the embodiments of the present application are not limited to the specific implementation location of the viewing of the phone number and the migration.
[0183] The user interface is not limited to the above examples, and in some other examples, the signal identifier of the mobile communication network in the user interface can also be the signal identifier of the operator in the current location, indicating that the mobile communication network corresponding to the operator is not accessed, and the embodiments of the present application are not limited thereto.
[0184] Next, the implementation process of the profile migration method provided by the embodiments of the present application is exemplarily introduced. The embodiments of the present application are described by taking the migration of the profile corresponding to the pSIM / eSIM in the electronic device 200 (source device) to the electronic device 100 (target device) as an example.
[0185] First, the implementation process of the electronic device 200 obtaining AuthToken1 (i.e., step 1 shown in FIG. 3) from the MNO 400 before the profile migration is exemplarily introduced by using FIG. 5.
[0186] FIG. 5 is a flow diagram of a configuration file migration method according to an embodiment of the present application. The method can be applied to the electronic device 200 and the MNO 400 in the communication system 10 shown in FIG. 2. The method can also be applied to the electronic device 200 and the MNO 400 in the communication system 10 shown in FIG. 3. The method can include, but is not limited to, the following steps:
[0187] S101: The electronic device 200 sends a configuration request to the ES 410 in the MNO 400.
[0188] S102: The ES 410 in the MNO 400 sends a challenge request to the AAA server 440 in the MNO 400.
[0189] S103: The AAA server 440 in the MNO 400 requests the HSS 450 in the MNO 400 to obtain an authentication vector (AV).
[0190] S104: The HSS 450 sends the AV to the AAA server 440.
[0191] In some embodiments of the present application, the electronic device 200 can initiate an AKA authentication with the MNO 400 to obtain an AuthTokenl. The AuthTokenl can be used to encrypt and protect the communication between the electronic device 200 and the MNO 400. The AKA authentication can provide a secure user identity verification and key agreement mechanism to protect the communication in a wireless network such as a mobile communication network. The electronic device 200 can initiate the AKA authentication by sending a configuration request to the ES 410 (i.e., performing S101). The configuration request can carry the information of the pSIM / eSIM corresponding to the MNO 400 in the electronic device 200, such as the user identifier (e.g., international mobile subscriber identity (IMSI)) and the key (e.g., key identifier (Ki) and / or authentication key OPC) in the card information of the pSIM / eSIM.
[0192] In some embodiments of the present application, the ES 410 can send a challenge request to the AAA server 440 according to the configuration request sent by the electronic device 200 (i.e., performing S102). The AAA server 440 can request the HSS 450 to obtain an AV according to the challenge request (i.e., performing S103). The HSS 450 can generate the AV and send the generated AV to the AAA server 440 (i.e., performing S104). The AV can be used for key agreement, such as the key agreement process based on the AV described in the following S105-S110.
[0193] In some examples, the AV is a quintuple vector. The AV can include the following five vectors: a random challenge (RAND), an authentication token (AUTN), an expected response (XRES), a cipher key (CK), and an integrity key (IK).
[0194] S105: The AAA server 440 obtains an authentication token (AUTH) 1 and a message authentication code 1 (MAC 1) according to the AV.
[0195] In some embodiments of the present application, the AUTH 1 can be the AUTH in the AV. The MAC 1 can be generated according to a key (such as Ki) of the pSIM / eSIM in the electronic device 200, the RAND, and the AUTH in the AV.
[0196] S106: The AAA server 440 sends the AUTH 1 and the MAC 1 to the electronic device 200 through the ES 410.
[0197] The AAA server 440 can send the AUTH 1 and the MAC 1 to the ES 410, and the ES 410 can send the AUTH 1 and the MAC 1 to the electronic device 200. In some embodiments of the present application, the AAA server 440 can also send the RAND in the AV to the electronic device 200 through the ES 410.
[0198] S107: The electronic device 200 checks the AUTH 1 and the MAC 1, and generates a response (RES) and a MAC 2.
[0199] In some embodiments of the present application, the electronic device 200 can calculate the MAC 2 according to a key (such as Ki) of the pSIM / eSIM corresponding to the MNO 400 in the electronic device 200, the received AUTH 1, and the RAND, and check whether the calculated MAC 2 and the received MAC 1 are the same. When the MAC 2 and the MAC 1 are the same, the electronic device 200 can determine that the check is successful, and therefore, the electronic device 200 can generate the RES according to the key (such as Ki) of the pSIM / eSIM corresponding to the MNO 400 in the electronic device 200 and the received RAND. FIG. 5 illustrates the case where the check is successful. However, the present application is not limited thereto. In another example, when the MAC 2 and the MAC 1 are not the same, the electronic device 200 can determine that the check fails, and therefore, the electronic device 200 can not generate the RES, and can not perform the subsequent process.
[0200] S108: The electronic device 200 sends the RES and the MAC2 to the AAA server 440 through the ES 410.
[0201] In some embodiments of the present application, the electronic device 200 can send the RES and the MAC2 to the ES 410, and the ES 410 can send the RES and the MAC2 to the AAA server 440.
[0202] S109: The AAA server 440 checks the RES and the MAC2, and generates the AuthTokenl when the check is successful.
[0203] In some embodiments of the present application, the AAA server 440 can check whether the received RES and the XRES in the AV are the same. When the RES and the XRES are the same, the electronic device 200 can determine that the check is successful. When the RES and the XRES are different, the electronic device 200 can determine that the check fails. Optionally, the AAA server 440 can also check whether the received MAC2 and the MAC1 are the same. When the MAC2 and the MAC1 are the same, and the RES and the XRES are the same, the electronic device 200 can determine that the check is successful. When the MAC2 and the MAC1 are different, and / or the RES and the XRES are different, the electronic device 200 can determine that the check fails. When the check is successful, the AAA server 440 can generate the key AuthTokenl obtained in this negotiation process.
[0204] S110: The AAA server 440 sends the AuthTokenl to the electronic device 200 through the ES 410.
[0205] In some embodiments of the present application, the AAA server 440 can send the AuthTokenl to the ES 410, and the ES 410 can send the AuthTokenl to the electronic device 200.
[0206] In some embodiments of the present application, the AAA server 440 sends a success response (for example, EAP-Success) of the AKA authentication to the electronic device 200 through the ES 410. The success response can carry the AuthTokenl. The electronic device 200 can determine that the AKA authentication is successful according to the success response.
[0207] The flow shown in FIG. 5 is only for example, and the flow of other implementation manners can refer to the implementation flow of the current AKA or other authentication protocol. The embodiments of the present application do not limit the specific manner of the electronic device 200 obtaining the AuthTokenl from the MNO 400.
[0208] The implementation process of the cloud server 300 obtaining the phone number of the pSIM / eSIM in the electronic device 200 (source device) before profile migration (i.e., steps 2-4 in FIG. 3) is exemplarily introduced below by means of FIG. 6.
[0209] FIG. 6 is a flow diagram of another profile migration method provided by an embodiment of the present application. The method can be applied to the electronic device 200, the cloud server 300 and the MNO 400 in the communication system 10 shown in FIG. 2. The method can also be applied to the electronic device 200, the cloud server 300 and the MNO 400 in the communication system 10 shown in FIG. 3. The method can include but is not limited to the following steps:
[0210] S201: The first network application in the electronic device 200 sends a token request (for obtaining a temporary token, carrying AuthToken1) to the ES 410 in the MNO 400.
[0211] S202: The ES 410 sends a token response (carrying a new temporary token (NewTemporaryToken)) to the first network application in the electronic device 200.
[0212] In some embodiments of the present application, before the flow shown in FIG. 6 (i.e., before S201), the electronic device 200 can obtain AuthToken1 from the MNO 400. In some examples, the electronic device 200 can perform AKA authentication with the MNO 400, and in the case of successful AKA authentication, the electronic device 200 can receive AuthToken1 issued by the MNO 400. For specific implementation examples, refer to the flow shown in FIG. 5.
[0213] In some embodiments of the present application, the token request and the token response can be request messages and response messages in a hypertext transfer protocol (HTTP) or a hypertext transfer protocol secure (HTTPS) protocol, etc. Among them, the request message in the HTTP / HTTPS can be used for a client (for example, the first network application) to request data from a server (for example, the MNO 400), and the response message can be used for the server to return corresponding data to the client. For example, the token request can be a GET request or a POST request in the HTTP / HTTPS.
[0214] In some embodiments of the present application, the token request can carry operation information, which can indicate the operation requested by the first network application in the electronic device 200, that is, indicate that the first network application requests to acquire a temporary token (TemporaryToken). In some embodiments of the present application, the token request can carry identification information, which can be the identification of the pSIM / eSIM corresponding to the MNO 400 in the electronic device 200, such as an international mobile equipment identity (IMEI). Alternatively, the identification information can also be the identification of the first network application in the electronic device 200, such as a universally unique identifier (UUID). In some embodiments of the present application, the token request can carry a token, which can be AuthToken1.
[0215] In some examples, the token request can be the following GET request / POST request: GET / POST ap2009,operation=AcquireTemporaryToken,terminal_id= <imeisim> or <uuidapp>,token= <authtoken1>The operation is operation information carried by the token request, and the value of the operation is AcquireTemporaryToken, indicating that the first network application requests to acquire a temporary token. The terminal identifier (terminal_id) is identification information carried by the token request, and the value of the terminal_id is IMEIsim, which is the IMEI of the pSIM / eSIM corresponding to the MNO 400 in the electronic device 200. Alternatively, the value of the terminal_id is UUIDapp, which is the UUID of the first network application in the electronic device 200. The token is a token carried by the token request, and the value of the token is AuthToken1.
[0216] In some embodiments of the present application, the token response can carry a status code, which can be a status code in HTTP / HTTPS, and the status code can indicate the response status of the token request. In some embodiments of the present application, the token response can carry a TemporaryToken, which can be a NewTemporaryToken. Optionally, the token response can also carry the Expiry of the TemporaryToken. Optionally, the token response can also carry the Operation Targets of the TemporaryToken, which can indicate the operations that can be implemented by the TemporaryToken.
[0217] In some examples, the token response can be a response of 200 OK, TemporaryToken=NewTemporaryToken, TemporaryTokenExpiry=NewTemporaryTokenExpiry, OperationTargets=GetPhoneNumber. In the response, 200 OK is a status code carried in the token response, indicating that the token request has been successfully processed. TemporaryToken is a TemporaryToken carried in the token response, and the value of TemporaryToken is NewTemporaryToken. TemporaryTokenExpiry is the validity period of the TemporaryToken carried in the token response, and the value of TemporaryTokenExpiry is NewTemporaryTokenExpiry, which is the validity period of NewTemporaryToken. OperationTargets is the operation target of the TemporaryToken carried in the token response, and the value of OperationTargets is GetPhoneNumber, indicating that the operation that can be implemented by the TemporaryToken is to obtain a phone number.
[0218] S203: The first network application in the electronic device 200 sends a token message (carrying NewTemporaryToken) to the cloud server 300.
[0219] In some embodiments of the present application, the token message can be a message in a protocol such as HTTP / HTTPS. For example, the first network application can send the token message to the cloud server 300 through an HTTP / HTTPS channel between the first network application and the cloud server 300.
[0220] In some embodiments of the present application, the token message can carry a TemporaryToken, which can be the NewTemporaryToken obtained by the first network application from the token response described above. Optionally, the token message can also carry the validity period (Expiry) of the TemporaryToken. Optionally, the token message can also carry the operation target (Operation Targets) of the TemporaryToken, which can indicate the operation requested by the first network application in the electronic device 200 based on the TemporaryToken. For example, the operation target carried by the token message can be determined according to the operation target carried by the token response, such as being the same as the operation target carried by the token response.
[0221] In some examples, the token message can be a message carrying a status code 200 OK, a TemporaryToken NewTemporaryToken, a TemporaryTokenExpiry NewTemporaryTokenExpiry, and an OperationTargets GetPhoneNumber. The status code 200 OK represents that the NewTemporaryToken is sent successfully. The TemporaryToken carried in the token message is the NewTemporaryToken. The TemporaryTokenExpiry carried in the token message is the valid period of the NewTemporaryToken, i.e., the NewTemporaryTokenExpiry. The OperationTargets carried in the token message is the GetPhoneNumber, indicating that the first network application requests to obtain the phone number based on the TemporaryToken in the token message.
[0222] S204: The cloud server 300 sends an access request message to the ES 410 in the MNO 400.
[0223] S205: The AAA server 440 in the MNO 400 sends an access token (AccessToken) 1 to the cloud server 300.
[0224] In some embodiments of the present application, the access request message can be used to request to obtain the AccessToken.
[0225] In some embodiments of the present application, after the ES 410 receives the access request message sent by the cloud server 300, the ES 410 can synchronously send the access request message to the AAA server 440, so that the AAA server 440 sends the AccessToken 1 to the cloud server 300.
[0226] In some embodiments of the present application, the access request message can carry a client identification (client_id) and a client password (client_secret) of the cloud server 300 accessing the MNO 400. The ES 410 can send the client_id and the client_secret to the AAA server 440 for authentication. If the authentication is passed, the AAA server 440 can send an AccessToken1 to the cloud server 300. If the authentication is not passed, the AAA server 440 can not send an AccessToken to the cloud server 300.
[0227] S206: The cloud server 300 sends a number request (for obtaining a phone number, carrying a NewTemporaryToken and an AccessToken1) to the ES 410 in the MNO 400.
[0228] In some embodiments of the present application, the number request can be a request message in a protocol such as HTTP / HTTPS. In some embodiments of the present application, the number request can carry identification information of the requesting end, which can be a UUID in the cloud server 300, for example, a UUID of the first network application corresponding to the cloud server 300. In some embodiments of the present application, the number request can carry operation information, which can indicate the operation requested by the cloud server 300, i.e., indicate that the cloud server 300 requests to obtain a phone number. In some embodiments of the present application, the number request can carry an AccessToken, which can be the AccessToken1. In some embodiments of the present application, the number request can carry a TemporaryToken, which can be the NewTemporaryToken.
[0229] In some examples, the number request can be the following GET request / POST request: GET / POST ap2014,requester_id= <uuid1>, AccessToken = <accesstoken1>, operation = GetPhoneNumber, TemporaryToken = NewTemporaryToken. The requester_id is identification information of the requester carried by the number request, the value of the requester_id is UUID1, and UUID1 is the UUID of the first network application. The AccessToken is the AccessToken carried by the number request, the value of the AccessToken is AccessToken1. The operation is operation information carried by the number request, the value of the operation is GetPhoneNumber, indicating that the cloud server 300 requests to obtain the phone number. The TemporaryToken is the TemporaryToken carried by the number request, the value of the TemporaryToken is NewTemporaryToken.
[0230] In some embodiments of the present application, after the cloud server 300 receives the token message sent by the electronic device 200, the cloud server 300 can generate and send a number request according to the NewTemporaryToken carried by the token message, and optionally the validity period of the NewTemporaryToken and the operation target. The cloud server 300 can send the number request before the validity period of the NewTemporaryToken. The cloud server 300 can determine the operation information in the number request according to the operation target of the NewTemporaryToken.
[0231] In some embodiments of the present application, the cloud server 300 can obtain the AccessToken1 from the MNO 400 before sending the number request, that is, S204-S205 are performed before S206. However, the order of any one of S204-S205 and S201-S203 is not limited.
[0232] S207: The ES 410 in the MNO 400 verifies whether the AccessToken1 is valid through the AAA server 440.
[0233] S208: The ES 410 in the MNO 400 verifies the NewTemporaryToken.
[0234] In some embodiments of the present application, after ES 410 receives the number request, ES 410 can verify whether the AccessTokenl carried by the number request is valid through AAA server 440. Also, after ES 410 receives the number request, ES 410 can verify whether the NewTemporaryToken carried by the number request is a NewTemporaryToken previously issued. Optionally, ES 410 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 by the token response). Optionally, ES 410 can also verify whether the operation information carried by the number request matches the operation target of the NewTemporaryToken (i.e. the operation target of the NewTemporaryToken carried by the token response). When the AccessTokenl is valid and the NewTemporaryToken passes the verification, MNO 400 can issue at least one phone number corresponding to the NewTemporaryToken to cloud server 300, i.e. perform S209-S210. When the AccessTokenl is invalid and / or the NewTemporaryToken fails the verification, MNO 400 can not issue the phone number to cloud server 300.
[0235] wherein the NewTemporaryToken passing the verification includes: the NewTemporaryToken carried by the number request is a NewTemporaryToken previously issued, optionally and the time of the number request does not exceed the validity period of the NewTemporaryToken, optionally and the operation information carried by the number request matches (e.g. is identical to) the operation target of the NewTemporaryToken.
[0236] S209: ES 410 in MNO 400 sends a number query request to BOSS 420.
[0237] S210: BOSS 420 in MNO 400 sends at least one phone number to cloud server 300 through ES 410.
[0238] In some embodiments of the present application, when the ES 410 successfully verifies the AccessToken1 and the NewTemporaryToken carried by the number request, the ES 410 can send a number query request to the BOSS 420. The BOSS 420 can query at least one telephone number corresponding to the NewTemporaryToken from a plurality of telephone numbers corresponding to the MNO 400 according to the number query request, and send the at least one telephone number to the cloud server 300 through the ES 410. The telephone number corresponding to the NewTemporaryToken is the telephone number of the pSIM / eSIM (corresponding to the MNO 400) in the electronic device 200 to which the MNO 400 issues the NewTemporaryToken.
[0239] In some embodiments of the present application, the at least one telephone number sent by the ES 410 to the cloud server 300 can be encrypted by the AccessToken1. After receiving the encrypted telephone number sent by the ES 410, the cloud server 300 can decrypt the encrypted telephone number using the AccessToken1 to obtain the at least one telephone number corresponding to the NewTemporaryToken.
[0240] S201-S202 in FIG. 6 correspond to step 2 in FIG. 3. S203 in FIG. 6 corresponds to step 3 in FIG. 3. S204-S205 in FIG. 6 correspond to the cloud server 300 obtaining the AccessToken from the MNO 400 in FIG. 3. S206-S210 in FIG. 6 correspond to step 4 in FIG. 3.
[0241] Next, the implementation process of the profile migration process (i.e., steps 5-8 in FIG. 3) will be described by way of example with reference to FIG. 7.
[0242] FIG. 7 is a flowchart of another profile migration method according to an embodiment of the present application. The method can be applied to the electronic device 100, the cloud server 300, and the MNO 400 in the communication system 10 shown in FIG. 2. The method can also be applied to the electronic device 100, the cloud server 300, and the MNO 400 in the communication system 10 shown in FIG. 3. The method can include, but is not limited to, the following steps:
[0243] S301: When the first network application in the electronic device 100 logs in the account 1, the cloud server 300 sends the telephone number (including the telephone number of the electronic device 200) corresponding to the account 1 to the first network application.
[0244] S302: The first network application in the electronic device 100 displays the telephone number corresponding to the account 1.
[0245] In some embodiments of the present application, before the flow shown in FIG. 7 (i.e., before S301), the cloud server 300 can obtain the phone number corresponding to the account 1. The phone number corresponding to the account 1 can include the phone number of the pSIM / eSIM in the electronic device that has logged in the account 1 before S301. Wherein the electronic device 200 has logged in the account 1, the cloud server 300 can obtain the phone number of the pSIM / eSIM in the electronic device 200, and the specific implementation example can be referred to the flow shown in FIG. 6.
[0246] In some embodiments of the present application, the first network application can detect the operation of the user logging in the account in the first network application, for example, the user can log in the account through the user interface 420 shown in FIG. 4B. The first network application can obtain the account 1 and the corresponding password input by the user according to the above operation. The first network application can send a login request to the cloud server 300, and the login request can carry the account 1 and the corresponding password input by the user. The cloud server 300 can authenticate the account 1 and the corresponding password carried by the login request, and send the authentication result (such as authentication success or authentication failure) to the first network application. When the authentication result is authentication success, the cloud server 300 can send the phone number corresponding to the account 1 to the first network application.
[0247] In some embodiments of the present application, the electronic device 100 can display the phone number corresponding to the account 1 sent by the cloud server 300, and can display the phone number of the pSIM / eSIM in the electronic device 100, for example, display the user interface 440 shown in FIG. 4D. Wherein the phone number corresponding to the account 1 sent by the cloud server 300 includes the phone number of the pSIM / eSIM in the other electronic device (logged in the account 1) other than the electronic device 100.
[0248] S303: The first network application in the electronic device 100 receives the user input of migrating the phone number 1 of the electronic device 200 to the electronic device 100.
[0249] In some embodiments of the present application, the first network application can receive the user input of migrating the phone number 1 of the electronic device 200 to the electronic device 100, and determine that the profile corresponding to the phone number 1 needs to be obtained (also can be understood as migrating the profile corresponding to the phone number 1 in the electronic device 200 to the electronic device 100) according to the user input, so S304 can be executed. Wherein the phone number 1 can be the phone number of the pSIM / eSIM corresponding to the MNO 400 in the electronic device 200.
[0250] In some examples, the first network application receiving the user input of migrating the phone number 1 of the electronic device 200 to the electronic device 100 includes that the electronic device 100 can receive a user operation acting on a migration-in control 443A in the user interface 440 shown in FIG. 4D, and display the user interface 460 shown in FIG. 4F in response to the user operation; then, the electronic device 100 can receive a user operation acting on a confirmation control 462A in the user interface 460. Wherein the phone number 22 of the electronic device 200 corresponding to the migration-in control 443A is the phone number 1 selected by the user for migration.
[0251] S304: The first network application in the electronic device 100 sends a migration request (carrying the phone number 1) to the cloud server 300.
[0252] In some embodiments of the present application, the migration request can be used to request to migrate the phone number 1 in the electronic device 200 to the electronic device 100. Without limitation, the migration request can also be used to request to obtain / migrate the profile corresponding to the phone number 1. In some embodiments of the present application, after the cloud server 300 receives the migration request sent by the electronic device 100, the cloud server 300 can send the OTP to the electronic device 100 after subsequently receiving the OTP sent by the MNO, which can be referred to S307-S310 below.
[0253] In some embodiments of the present application, the migration request can be a message in the HTTP / HTTPS protocol. For example, the first network application can send the migration request to the cloud server 300 through the HTTP / HTTPS channel between the first network application and the cloud server 300.
[0254] S305: The cloud server 300 sends an access request message to the ES 410 in the MNO 400.
[0255] S306: The AAA server 440 in the MNO 400 sends an access token (AccessToken) 2 to the cloud server 300.
[0256] S305-S306 of FIG. 7 and S204-S205 of FIG. 6 are similar, and will not be described again.
[0257] S305-S306 of FIG. 7 are optional steps. In some embodiments of the present application, after receiving the migration request sent by the first network application in the electronic device 100, the cloud server 300 can obtain the AccessToken2 (i.e., perform S305-S306) from the MNO 400, for use in performing subsequent steps (e.g., S310). In this case, S204-S205 of FIG. 6 and S305-S306 of FIG. 7 can be obtaining AccessToken processes performed at different times, and therefore, the AccessToken1 and the AccessToken2 can be the same or different. In some other embodiments of the present application, after receiving the migration request sent by the first network application in the electronic device 100, the cloud server 300 can not obtain the AccessToken from the MNO 400, i.e., S305-S306 is not performed. The cloud server 300 can use the AccessToken2 obtained from the MNO 400 previously to perform subsequent steps (e.g., S310). For example, the AccessToken2 is the AccessToken1 described above, and the process in which the cloud server 300 obtains the AccessToken2 from the MNO 400 previously is S204-S205 of FIG. 6.
[0258] S307: The first network application in the electronic device 100 sends an OTP request (carrying the phone number 1) to the ES 410 in the MNO 400.
[0259] S308: The ES 410 in the MNO 400 sends the encrypted information (i.e., obtained by encrypting the OTP1 by the AccessToken2) to the cloud server 300.
[0260] S309: The ES 410 in the MNO 400 sends an OTP response to the first network application in the electronic device 100.
[0261] S310: The cloud server 300 decrypts the encrypted information using the AccessToken2 to obtain the OTP1.
[0262] S311: The cloud server 300 sends the OTP1 to the first network application in the electronic device 100.
[0263] In some embodiments of the present application, the OTP request can be used to request to obtain an OTP. The OTP response can be a response message returned according to the OTP request. In some embodiments of the present application, the OTP request and the OTP response can be a request message and a response message in an HTTP / HTTPS protocol, etc. The OTP can also be referred to as a verification code.
[0264] In some embodiments of the present application, the OTP request can carry identification information, which can be the identification (e.g. IMEI) of the pSIM / eSIM (e.g. corresponding to MNO 400) in the electronic device 100, or the identification (e.g. UUID) of the first network application in the electronic device 100. In some embodiments of the present application, the OTP request can carry the phone number selected by the user for migration, i.e. the phone number 1.
[0265] In some examples, the OTP request can be the following GET request / POST request: GET / POST ap2009,terminal_id= <imeisim> or <uuidapp>, msisdn = <msisdnsubs>The terminal_id is identification information carried by the OTP request, and the terminal_id takes the value of IMEIsim, which is the IMEI of the pSIM / eSIM in the electronic device 100. Alternatively, the terminal_id takes the value of UUIDapp, which is the UUID of the first network application in the electronic device 100. The msisdn is the phone number selected by the user for migration, and the msisdn takes the value of MSISDNsubs, which is the phone number 1.
[0266] In some embodiments of the present application, the OTP response can carry a status code, which can be a status code in HTTP / HTTPS, and the status code can indicate the response status of the OTP request. When the ES 410 sends the encrypted information to the cloud server 300 after receiving the OTP request, the ES 410 can send the OTP response to the first network application in the electronic device 100, and the status code in the OTP response can indicate that the OTP request is successfully processed, or the data (i.e., OTP1) requested by the OTP request has been returned, for example, the status code is "200 OK" at this time. Alternatively, the OTP response can also carry data (cookie) stored on the local terminal, so that the electronic device 100 can subsequently initiate a request to the ES 410 based on the cookie. The OTP1 can also be referred to as a verification code 1.
[0267] In some embodiments of the present application, after the cloud server 300 receives the encrypted information sent by the ES 410, the cloud server 300 can use the AccessToken2 to decrypt the encrypted information to obtain the OTP1. Then, the cloud server 300 can send the OTP1 to the first network application in the electronic device 100 that sends the migration request, for example, through the HTTP / HTTPS channel.
[0268] It can be understood that after the MNO 400 receives the OTP request (carrying the phone number 1) sent by the electronic device 100, since the MNO 400 only knows that the phone number 1 is the phone number of the electronic device 200, it cannot determine whether the electronic device 100 is trustworthy. Therefore, the MNO 400 will send the OTP1 to the trusted cloud server 300. If the electronic device 100 receives the OTP1 sent by the cloud server 300, the electronic device 100 is a trusted device, and if the electronic device 100 cannot receive the OTP1 sent by the cloud server 300, the electronic device 100 is not a trusted device. It can also be understood that if the electronic device 100 is a trusted device, the electronic device 100 will receive the OTP1 sent by the cloud server 300, and if the electronic device 100 is not a trusted device, the electronic device 100 cannot receive the OTP1 sent by the cloud server 300.
[0269] In some embodiments of the present application, after the electronic device 100 receives the OTP1 sent by the cloud server 300, the electronic device 100 can display a notification, which can be used to prompt the user that the OTP1 has been received, and the notification can include the OTP1. In addition, the first network application in the electronic device 100 can display an input box for the user to input the OTP1. For specific examples, refer to the user interface 470 shown in FIG. 4G. When the first network application detects the OTP1 input by the user based on the input box, the first network application can perform the eligibility review for migration based on the OTP1, that is, execute S311. Not limited to this, in another embodiment of the present application, the electronic device 100 can also directly perform the eligibility review for migration based on the OTP1.
[0270] In some examples, when the electronic device 100 receives the OTP1 sent by the cloud server 300 through an application other than the first network application (such as a short message), a corresponding notification can be displayed, and an input box (for inputting the OTP1) is displayed through the first network application. Among them, the OTP1 can be input by the user in the input box, or the electronic device 100 can automatically input the OTP1 in the input box after recognizing the OTP1. In another example, when the electronic device 100 receives the OTP1 sent by the cloud server 300 through the first network application, the notification and the input box can not be displayed, but the first network application can directly perform the eligibility review for migration based on the OTP1.
[0271] Wherein, the execution order of S309 and S310-S311 is not limited.
[0272] S312: The first network application in the electronic device 100 sends a verification request (carrying the OTP1) to the ES 410 in the MNO 400.
[0273] S313: The ES 410 in the MNO 400 verifies the OTP1, and obtains the AuthToken2 in the case that the OTP1 is verified.
[0274] S314: The ES 410 in the MNO 400 sends a verification response (carrying the AuthToken2) to the first network application in the electronic device 100.
[0275] In some embodiments of the present application, the verification request and the verification response can be a request message and a response message in the HTTP / HTTPS protocol, etc.
[0276] In some embodiments of the present application, the verification request can carry the OTP, which can be the above-mentioned OTP1. In some examples, the OTP request can be the following GET request / POST request: GET / POST ap2009, OTP= <otp1> , <cookie>The value of the OTP carried by the OTP request is OTP1, and the Cookie carried by the OTP request is the Cookie carried in the above-mentioned OTP response.
[0277] In some embodiments of the present application, when the ES 410 passes the verification of OTP1, the verification response can carry the AuthToken2 obtained by the ES 410. When the ES 410 fails the verification of OTP1, the ES 410 can not obtain the AuthToken2. In some embodiments of the present application, the verification response can carry a status code, which can be a status code in HTTP / HTTPS, and the status code can indicate the response status of the verification request. In some examples, when the ES 410 passes the verification of OTP1, the verification response can be represented as the following response: 200 OK, AuthToken2. Wherein 200 OK is the status code carried by the verification response, indicating that the verification request has been successfully processed.
[0278] In some embodiments of the present application, when the ES 410 passes the verification of OTP1, the ES 410 can request the AAA server 440 to obtain the AuthToken. The AAA server 440 can generate the AuthToken2 and return it to the ES 410. The ES 410 can send the AuthToken2 to the first network application in the electronic device 100.
[0279] In some embodiments of the present application, after the MNO 400 issues the AuthToken2 to the electronic device 100, the MNO 400 and the electronic device 100 can implement subsequent communication based on the AuthToken2. In some examples, the request message (such as the following eligibility review request and management subscription request) sent by the electronic device 100 to the ES 410 carries the AuthToken2, and the ES 410 can verify the AuthToken2 carried by the request message, and process the request of the electronic device 100 after passing the verification.
[0280] S315: The first network application in the electronic device 100 sends an eligibility review request (carrying the AuthToken2) to the ES 410 in the MNO 400.
[0281] S316: The ES 410 in the MNO 400 sends an eligibility review response (indicating that the eligibility with migration) to the first network application in the electronic device 100.
[0282] In some embodiments of the present application, the eligibility review request and the eligibility review response can be a request message and a response message in HTTP / HTTPS and the like, respectively.
[0283] In some embodiments of the present application, the eligibility check request can carry operation information, which can indicate the operation requested by the first network application in the electronic device 100, i.e., indicate that the first network application requests Check Eligibility. In some embodiments of the present application, the eligibility check request can carry identification information, which can be the identification (e.g., IMEI) of the pSIM / eSIM (e.g., corresponding to the MNO 400) in the electronic device 100, or the identification (e.g., UUID) of the first network application in the electronic device 100. In some embodiments of the present application, the eligibility check request can carry a token, which can be AuthToken2.
[0284] In some examples, the eligibility check request can be the following GET request / POST request: GET / POST ap2009, operation = CheckEligibility, terminal_id = IMEI, token = AuthToken2 <imeinew> or <uuidapp>,token= <authtoken2>. Wherein, the operation is operation information carried by the eligibility check request, the value of the operation is CheckEligibility, indicating that the operation requested by the first network application in the electronic device 100 is eligibility check. The terminal_id is identification information carried by the eligibility check request, the value of the terminal_id is IMEIsim, and the IMEIsim is the IMEI of the pSIM / eSIM in the electronic device 100. Alternatively, the value of the terminal_id is UUIDapp, and the UUIDapp is the UUID of the first network application in the electronic device 100. The value of the token is AuthToken2.
[0285] In some embodiments of the present application, the eligibility check response can carry a status code, which can be a status code in HTTP / HTTPS, and the status code can indicate the response status of the eligibility check request. In some embodiments of the present application, the eligibility check response can carry primary device status information, and the primary device status information can indicate whether the electronic device 100 has the eligibility of migration, i.e., indicate the eligibility check result.
[0286] In some embodiments of the present application, the ES 410 can determine whether the AuthToken2 carried by the eligibility check request is the AuthToken2 issued before. When the determination result is yes, the ES 410 passes the AuthToken2 verification, and when the determination result is no, the ES 410 fails the AuthToken2 verification. Wherein, when the ES 410 passes the AuthToken2 verification, the ES 410 can determine that the electronic device 100 has the eligibility of migrating the phone number 1. In this case, the primary device status information carried by the eligibility check response can indicate that the electronic device 100 has the eligibility of migration. FIG. 7 illustrates an example in which the primary device status information carried by the eligibility check response indicates that the electronic device 100 has the eligibility of migration. In some examples, when the ES 410 passes the AuthToken2 verification, the eligibility check response can be the following response: 200 OK, PrimaryDeviceStatus = ENABLED. Wherein, 200 OK is the status code carried by the eligibility check response, indicating that the eligibility check request has been successfully processed. The primary device status information carried by the eligibility check response is PrimaryDeviceStatus, and the value of the primary device status information is ENABLED, indicating that the electronic device 100 has the eligibility of migration.
[0287] In some embodiments of the present application, when the ES 410 fails to verify the AuthToken2, the ES 410 can determine that the electronic device 100 is not eligible to migrate the phone number 1. In some examples, when the ES 410 fails to verify the AuthToken2, the value of the PrimaryDeviceStatus carried in the eligibility check response is DISABLED, indicating that the electronic device 100 is not eligible to migrate.
[0288] S317: The first network application in the electronic device 100 sends a manage subscription request (carrying AuthToken2) to the ES 410 in the MNO 400.
[0289] S318: The ES 410 in the MNO 400 instructs the BOSS 420 to migrate the subscription relationship of the phone number 1.
[0290] S319: The BOSS 420 in the MNO 400 deactivates the subscription relationship of the electronic device 200 and activates the subscription relationship of the electronic device 100.
[0291] S320: The ES 410 in the MNO 400 sends a manage subscription response (carrying download information) to the first network application in the electronic device 100.
[0292] In some embodiments of the present application, the manage subscription request and the manage subscription response can be a request message and a response message in a protocol such as HTTP / HTTPS, respectively.
[0293] In some embodiments of the present application, the manage subscription request can carry operation information, which can indicate the operation requested by the first network application in the electronic device 100, i.e., indicating that the first network application requests to manage subscription (Manage Subscription). Optionally, the manage subscription request can carry the type corresponding to the operation information. In some embodiments of the present application, the manage subscription request can carry identification information, which can be the identification (e.g., IMEI) of the pSIM / eSIM (e.g., corresponding to the MNO 400) in the electronic device 100, or the identification (e.g., UUID) of the first network application in the electronic device 100. In some embodiments of the present application, the manage subscription request can carry a token, which can be AuthToken2.
[0294] In some examples, the manage subscription request can be the following GET request / POST request: GET / POST ap2009,operation=ManageSubscription,operation_type=3-TRANSFER,terminal_id= <imeinew> or <uuidapp>,token= <authtoken2>The operation is operation information carried by the management subscription request, and the value of the operation is ManageSubscription, indicating that the operation requested by the first network application in the electronic device 100 is management subscription. The operation_type is the type of operation information carried by the management subscription request, and the value of the operation_type is 3-TRANSFER, indicating that the type of the subscription relationship requested by the first network application in the electronic device 100 to manage is the third transfer type. The terminal_id is identification information carried by the management subscription request, and the value of the terminal_id is IMEIsim, which is the IMEI of the pSIM / eSIM in the electronic device 100. Alternatively, the value of the terminal_id is UUIDapp, which is the UUID of the first network application in the electronic device 100. The value of the token is AuthToken2.
[0295] In some embodiments of the present application, after the ES 410 receives the management subscription request sent by the electronic device 100, if the ES 410 passes the AuthToken2 verification, the ES 410 can instruct the BOSS 420 to migrate the subscription relationship of the phone number 1, that is, to migrate the configuration of the subscription relationship of the phone number 1 to the electronic device 100. For example, the ES 410 can send the identification (Subscription ID) of the subscription relationship of the phone number 1 to the BOSS 420. Therefore, the BOSS 420 can deactivate the configuration of the subscription relationship of the phone number 1 corresponding to the electronic device 200 and activate the configuration of the subscription relationship of the phone number 1 corresponding to the electronic device 100 under the instruction of the ES 410. After the ES 410 instructs the BOSS 420 to migrate the subscription relationship of the phone number 1, the ES 410 can send a management subscription response to the first network application in the electronic device 100. After deactivating the configuration of the subscription relationship of the phone number 1 corresponding to the electronic device 200, the electronic device 200 cannot realize network camping through the phone number 1. In some other embodiments of the present application, when the ES 410 does not pass the AuthToken2 verification, the ES 410 can not instruct the BOSS 420 to migrate the subscription relationship of the phone number 1.
[0296] In some embodiments of the present application, the management subscription response can carry result information of managing the subscription relationship, which can indicate whether the electronic device 100 is allowed to download the profile corresponding to the phone number 1. In some embodiments of the present application, the management subscription response can carry download information, which can include address information 1 of the profile server 430, and optionally, related information such as a key and a certificate index. For example, when the MNO 400 allows the electronic device 100 to download the profile corresponding to the phone number 1, the management subscription response can carry the download information. In some embodiments of the present application, the management subscription response can carry a status code, which can be a status code in HTTP / HTTPS, and the status code can indicate the response status of the management subscription request.
[0297] In some examples, the management subscription response can be a response of 200 OK, SubscriptionResult = 2-DOWNLOAD PROFILE, DownloadInfo = [ProfileActivationCode = 1234567890, ProfileAddress = http: / / www.example.com / profiles / 1234567890, ProfileKey = 1234567890, ProfileCertificateIndex = 1]. <activationcode>]. Wherein, 200 OK is a status code carried in the management subscription response, representing that the management subscription request has been successfully processed. The subscription result (SubscriptionResult) is the result information of the management subscription relationship carried in the management subscription response, and the value of the SubscriptionResult can be 2-download profile (DOWNLOAD PROFILE), representing that the electronic device 100 is allowed to download the profile corresponding to the phone number 1. The download information (DownloadInfo) can include a profile activation code (ProfileActivationCode), and the value of the ProfileActivationCode is an activation code (ActivationCode). The ActivationCode can include address information 1 of the profile server 430.
[0298] S321: The first network application in the electronic device 100 obtains the address information 1 of the profile server 430 according to the download information.
[0299] S322: The first network application in the electronic device 100 sends a download request to the profile server 430 corresponding to the address information 1.
[0300] S323: The profile server 430 in the MNO 400 sends the profile corresponding to the phone number 1 to the first network application in the electronic device 100.
[0301] In some embodiments of the present application, after the electronic device 100 receives the profile corresponding to the phone number 1, the profile can be stored in the eSIM module. Subsequently, the electronic device 100 can use the profile corresponding to the phone number 1 in the eSIM module to perform network access, such as user services of calling and surfing the Internet, etc.
[0302] In some embodiments of the present application, the first network application in the electronic device 100 can access the address information 1 obtained according to the download information, i.e. send a download request (for example, a request in HTTP / HTTPS, such as a GET request / POST request) to the configuration file server 430 corresponding to the address information 1 to request downloading the profile. The configuration file server 430 can send the profile corresponding to the phone number 1 to the first network application in the electronic device 100 according to the download request. In some examples, the configuration file server 430 can determine that the electronic device 100 needs to download the profile of the phone number 1 according to the OTP 1 / AuthToken 2 sent by the electronic device 100, and thus send the profile corresponding to the phone number 1 to the first network application of the electronic device 100. It can be understood that the MNO 400 records the correspondence between the OTP 1 / AuthToken 2 and the phone number 1, wherein the correspondence between the OTP 1 and the phone number 1 can be obtained according to the OTP request sent by the electronic device 100, and the correspondence between the AuthToken 2 and the phone number 1 can be obtained according to the OTP request and the qualification examination (S312-S314) sent by the electronic device 100.
[0303] In some embodiments of the present application, the first network application in the electronic device 100 can display a user interface after downloading the profile corresponding to the phone number 1 (i.e. after S322), wherein the phone number 1 in the user interface is the phone number of the electronic device 100, for example, the user interface 480 shown in FIG. 4H or the user interface 490 shown in FIG. 4I. Not limited to this, in another embodiment, the first network application in the electronic device 100 can also display the above-mentioned user interface after the qualification examination is passed (i.e. after S316). In another embodiment, the first network application in the electronic device 100 can also display the above-mentioned user interface after receiving the management subscription response (i.e. after S320).
[0304] In some embodiments of the present application, the cloud server 300 or the MNO 400 can synchronize the state information of the configuration of the subscription relationship of the phone number 1 to the electronic device 200 (the source device), i.e. synchronize to the electronic device 200 (the source device) that the configuration of the subscription relationship of the phone number 1 has been migrated to other devices. Therefore, the electronic device 200 can display prompt information that the phone number 1 is not available, for example, the user interface 500 shown in FIG. 4J and the user interface 510 shown in FIG. 4K. Optionally, the electronic device 200 can also delete the profile corresponding to the phone number 1.
[0305] Among them, the profile can store at least one of the following types of card data: international mobile subscriber identity (IMSI) (for example, which can be used for authentication), key identifier (Ki) (for example, which can be used for authentication), authentication key OPC (OPC is a key calculated according to Ki and operator variant algorithm configuration field (OP)), (for example, which can be used for authentication), hash value, integrate circuit card identity (ICCID), administrative data (AD), broadcast control channel (BCCH), forbidden public land mobile network (PLMN) (forbidden PLMN, FPLMN), location information (LOCI), packet switched location information (PSLOCI), general packet radio service (GPRS) location information (the GPRS location information, LOCIGPRS), user controlled PLMN selector with access technology (PLMNWACT), access control 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), initialisation values for hyperframe number (IVHF), and the like.STARTHFN), a maximum value of start (THRESHOLD), short message service parameters (SMSP), a short message status (SMSS).
[0306] Correspondingly, S301-S302 of FIG. 7 correspond to step 5 of FIG. 3. S303-S310 of FIG. 7 correspond to step 6 of FIG. 3. S311-S316 of FIG. 7 correspond to step 7 of FIG. 3. S317-S322 of FIG. 7 correspond to step 8 of FIG. 3.
[0307] Not limited to the above embodiment, in another embodiment of the present application, the subscription relationship of the electronic device 200 can also not be deactivated in S319, and therefore the electronic device 100 and the electronic device 200 can both be configured with the subscription relationship of the phone number 1, which can be understood as "one number with multiple terminals".
[0308] Not limited to the above embodiment, in another embodiment of the present application, S315-S316 can also not be performed, and S317 can be directly performed, and in another embodiment of the present application, the qualification examination request and the management subscription request can be implemented by one request, and the qualification examination response and the management subscription response can be implemented by one response.
[0309] In the above method, in the profile migration process, the user can complete the migration operation in a closed loop and safely on the electronic device 100 (target device), the electronic device 100 can be connected to the cloud server 300 and the MNO 400, the cloud server 300 and the MNO 400 can be connected (which can be understood as "cloud-cloud connection"), and the electronic device 100, the cloud server 300 and the MNO 400 do not need to be connected to the electronic device 200, and therefore the profile migration process does not depend on the real-time online, intact, transmission of related information and execution of confirmation operation of the electronic device 200, and therefore the profile migration process can be implemented even if the electronic device 200 is unavailable (for example, lost, not with the user, failure, etc.).
[0310] Furthermore, the synchronization of the phone number can be implemented by means of the account 1 logged in by the first network application, that is, the information synchronization of the electronic device 200 (source device) and the electronic device 100 (target device) is implemented by the cloud server 300, for example, the phone number of the electronic device 200 (source device) is synchronized to the electronic device 100 (target device), and for example, the state information of the configuration of the subscription relationship of the phone number 1 is synchronized to the electronic device 200 (source device).
[0311] Not limited to the above embodiments, in some embodiments of the present application, the cloud server 300 can also not obtain the phone number of the electronic device 200 from the MNO 400, but directly send the phone number to the cloud server 300 by the electronic device 200.
[0312] Not limited to the above embodiments, in some embodiments of the present application, when the reliable transmission is implemented between the cloud server 300 and the MNO 400 based on the Access Token, the transmitted data can not be encrypted using the Access Token, but the Access Token and the data can be transmitted at the same time. After the cloud server 300 / MNO 400 receives the data sent by the opposite end, the Access Token received at the same time can be verified first. If the verification is passed, it is determined that the current received data is reliable data. The present application does not limit this embodiment.
[0313] Not limited to the above embodiments, in some embodiments of the present application, the cloud server 300 and the MNO 400 can also not communicate through the Access Token.
[0314] FIG. 8 is a flow diagram of another configuration file migration method according to an embodiment of the present application.
[0315] The method shown in FIG. 8 can be applied to a communication system, which can include a first device, a cloud server, an operator server, and optionally a second device. Wherein the communication system can be the communication system 10 shown in FIG. 2 and / or FIG. 3, the first device can be the electronic device 100 in the communication system 10, the cloud server can be the cloud server 300 in the communication system 10, the operator server can be the MNO 400 in the communication system 10, and the second device can be the electronic device 200 in the communication system 10.
[0316] The method shown in FIG. 8 can include but is not limited to the following steps:
[0317] S401: The first device displays a first interface (including a first phone number of a second device).
[0318] In some embodiments of the present 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.
[0319] In some embodiments of the present application, the first device logs in the first account before S401, and receives one or more phone numbers corresponding to the first account sent by the cloud server. Since the second device is a device that has logged in 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 in the first interface. For specific implementation examples, see S301-S302 of FIG. 7, where the first account is Account 1 in S301-S302 of FIG. 7.
[0320] In some embodiments of the present application, before S401, the method shown in FIG. 8 further includes that the cloud server receives a first temporary token sent by the second device. For specific implementation examples, see S203 of FIG. 6, where the first temporary token is NewTemporaryToken in S203 of FIG. 6. Then, the cloud server sends a fourth request (carrying the first temporary token) to the operator server, and receives a second phone number of the second device (belonging to the one or more phone numbers of the second device described above) sent by the operator server based on the fourth request. The second phone number can include the first phone number described above. Optionally, before the cloud server sends the fourth request to the operator server, the cloud server can first obtain a second access token from the operator server. For specific implementation examples, see S204-S205 of FIG. 6, where the second access token is AccessToken1 in S204-S205 of FIG. 6. In this way, the fourth request can carry the second access token obtained above. For specific implementation examples of the above process, see S206-S210 of FIG. 6, where the fourth request is Number Request in S206-S210 of FIG. 6, and the second phone number is at least one phone number in S206-S210 of FIG. 6.
[0321] In some embodiments of the present application, before the cloud server receives the first temporary token sent by the second device, the second device can send a fifth request to the operator server, and receive the first temporary token sent by the operator server based on the fifth request. For specific implementation examples, see S201-S202 of FIG. 6, where the fifth request is Token Request in S201-S202 of FIG. 6.
[0322] S402: The first device receives a first input of the user migrating the first phone number to the first device.
[0323] In some embodiments of the present application, the first device can receive a first input acting on the first phone number in the first interface, and determine to migrate the first phone number of the second device to the first device according to the first input. For specific implementation examples of S402, see S303 of FIG. 7, where the first phone number is Phone Number 1 in S303 of FIG. 7.
[0324] S403: The first device sends a first request (for requesting migrating the first phone number to the first device) to the cloud server.
[0325] In some embodiments of the present application, the first device can send the first request to the cloud server in response to the first input. Wherein, the implementation example of S403 can be referred to S304 of FIG. 7, and the first request is the migration request in S304 of FIG. 7.
[0326] S404: The first device sends a second request (carrying the first phone number) to the operator server.
[0327] In some embodiments of the present application, the first device can send the second request to the operator server in response to the first input. Wherein, the implementation example of S404 can be referred to S307 of FIG. 7, and the second request is the OTP request in S307 of FIG. 7.
[0328] S405: The operator server sends a verification code to the cloud server.
[0329] In some embodiments of the present application, the operator server can send the verification code to the cloud server in response to the second request. Wherein, the implementation example of S405 can be referred to S308 of FIG. 7, and the verification code is OTP1 in S308 of FIG. 7.
[0330] S406: The operator server sends a first response (indicating that the second request is successfully processed) to the first device.
[0331] In some embodiments of the present application, after the operator server sends the verification code to the cloud server, the operator server can send the first response to the first device to indicate that the second request is successfully processed. Wherein, the implementation example of S406 can be referred to S309 of FIG. 7, and the first response is the OTP response in S309 of FIG. 7.
[0332] S407: The cloud server sends the verification code to the first device.
[0333] In some embodiments of the present application, the cloud server can send the verification code to the first device after receiving the verification code. Wherein, the implementation example of S407 can be referred to S311 of FIG. 7, and the verification code is OTP1 in S308 of FIG. 7.
[0334] In some embodiments of the present application, before S405, the method shown in FIG. 8 further includes: the cloud server sends a third request to the operator server, receives the first access token sent by the operator server based on the first request, and specific implementation examples can be referred to S305-S306 of FIG. 7. The first access token is AccessToken2 in S305-S306 of FIG. 7. In this way, in S405, the operator server can send the first encrypted information (i.e., obtained by encrypting the verification code by the first access token) to the cloud server, and implementation examples can be referred to S308 of FIG. 7. The first encrypted information is the encrypted information in S308 of FIG. 7. In S407, the cloud server can decrypt the first encrypted information using the first access token to obtain the verification code, and send the verification code to the first device, and implementation examples can be referred to S310-S311 of FIG. 7. The verification code is OTP1 in S310-S311 of FIG. 7.
[0335] S408: The first device downloads the configuration file corresponding to the first phone number from the operator server using the verification code.
[0336] In some embodiments of the present application, the first device sends a sixth request (carrying the verification code) to the operator server, and receives the authentication token sent by the operator server in the case that the verification code is verified by the operator server. Specific implementation examples can be referred to S312-S314 of FIG. 7. The sixth request is the verification request in S312-S314 of FIG. 7. The authentication token is AuthToken2 in S312-S314 of FIG. 7. Then, the first device can download the configuration file corresponding to the first phone number from the operator server using the authentication token.
[0337] In some embodiments of the present application, the first device downloads the configuration file corresponding to the first phone number from the operator server using the authentication token, which can include: the first device sends a seventh request (carrying the authentication token) to the operator server, and receives the first address information sent by the operator server in the case that the authentication token is verified by the operator server. Then, the first device can download the configuration file (profile) corresponding to the first phone number from the configuration file server corresponding to the first address information. Specific implementation examples can be referred to S315-S322 of FIG. 7. The seventh request is the eligibility review request or the management subscription request in S315-S322 of FIG. 7. The first address information is address information 1 in S315-S322 of FIG. 7. The configuration file server corresponding to the first address information is the configuration file server 430 shown in FIG. 7.
[0338] In some embodiments of the present application, the first device can request the operator server to migrate the subscription relationship of the first phone number using the authentication token, for example, implemented in S408. Illustratively, the first device can send an eighth request (carrying the authentication token) to the operator server, the operator server can verify the authentication token carried by the eighth request, and when the authentication token is verified, deactivate the subscription relationship of the first phone number corresponding to the second device and activate the subscription relationship of the first phone number corresponding to the first device. It can be understood that the activated subscription relationship of the first phone number is used to implement the network camping through the first phone number, therefore, after the subscription relationship of the first phone number corresponding to the second device is deactivated, the second device cannot camp on the network through the first phone number, and after the subscription relationship of the first phone number corresponding to the first device is activated, the first device can camp on the network through the first phone number. The specific implementation example of the above example process can be referred to S317-S319 of FIG. 7, and the eighth request is the management subscription request of S317-S319 of FIG. 7.
[0339] In some embodiments of the present application, in S401, the first device can display one or more phone numbers of the second device in a first area in the first interface, the first area being used to display phone numbers of devices other than the first device, at this time, the first area in the first interface displayed by the first device does not include the first phone number, and the second area can include other phone numbers of the first device or no phone number, the second area being used to display phone numbers of the first device. Examples of the first interface displayed by the first device at this time can refer to the user interface 440 shown in FIG. 4D, wherein the upper half area of the user interface 440 can be the second area, and the lower half area can be the first area, the second area of the user interface 440 can include the traffic package 442 of the phone number 11 of the first device (i.e., the electronic device 100), and the first area of the user interface 440 can include the traffic package 443 of the phone number 22 (i.e., the first phone number) of the second device (i.e., the electronic device 200) and the traffic package 444 of the phone number 33 of the second device. After S408, the first device can display the first phone number of the first device in the second area in the first interface, at this time, the first area in the first interface displayed by the first device does not include the first phone number, and the first area can include other phone numbers or no phone number. Examples of the first interface displayed by the first device at this time can refer to the user interface 490 shown in FIG. 4I, wherein the upper half area of the user interface 490 can be the second area, and the lower half area can be the first area, the second area of the user interface 490 can include the traffic package 442 of the phone number 11 of the first device (i.e., the electronic device 100) and the traffic package 443 of the phone number 22 (i.e., the first phone number) of the first device, and the first area of the user interface 440 can include the traffic package 444 of the phone number 33 of the second device (i.e., the electronic device 200).
[0340] In some embodiments of the present application, before S402, the second device can display one or more phone numbers of the second device (including the first phone number) 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 can include other phone numbers or no phone numbers, and the fourth area is used to display the phone numbers of other devices other than the second device. Examples of the second interface displayed by the second device at this time can refer to the user interface 450 shown in FIG. 4E, the upper half area of the user interface 450 can be the third area, and the lower half area can be the fourth area, the third area of the user interface 450 can include the traffic package 452 of the phone number 22 (i.e., the first phone number) of the second device (i.e., the electronic device 200) and the traffic package 453 of the phone number 33 of the second device, and the fourth area of the user interface 450 can not include the phone numbers. After S408, the second device can display the first phone number in the fourth area of the second interface, at this time, the third area of the second interface displayed by the second device does not include the first phone number, and the third area can include other phone numbers of the second device or no phone numbers. Examples of the second interface displayed by the second device at this time can refer to the user interface 510 shown in FIG. 4K, the upper half area of the user interface 510 can be the third area, and the lower half area can be the fourth area, the third area of the user interface 510 can include the traffic package 453 of the phone number 33 of the second device (i.e., the electronic device 200), and the fourth area of the user interface 510 can include the traffic package 452 of the phone number 22 (i.e., the first phone number) of the first device (i.e., the electronic device 100).
[0341] In some embodiments of the present application, the method shown in FIG. 8 further includes that after the first device receives the verification code sent by the cloud server, the first device displays a user interface including an input box and a first notification, the first notification includes the verification code, and specific examples can refer to the user interface 470 shown in FIG. 4G, the input box is the input box 472A in the user interface 470, and the first notification is the content displayed in the message bar 471 of the user interface 470. Then, the first device can receive the user input of the user inputting the verification code in the input box, and in response to the user input, use the verification code to download the configuration file corresponding to the first phone number from the operator server (i.e., perform S408). In some other embodiments of the present application, the first device can also automatically input the verification code in 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 server. In some other embodiments of the present application, the first device can also not display the input box and the first notification, and directly use the verification code to download the configuration file corresponding to the first phone number from the operator server. Specific descriptions can refer to the description of the first device receiving OTP1 in S311 of FIG. 7.
[0342] In some embodiments of the present application, the first device can use the obtained configuration file corresponding to the first phone number to perform network access. In some examples, the method shown in FIG. 8 further includes: after S408, the first device displays a user interface including the first phone number of the first device, and receives a user input of a user enabling the first phone number, and then performs network access through the configuration file corresponding to the first phone number in response to the third input. For example, the user interface 490 shown in FIG. 4I is a user interface after the first phone number is enabled, the first phone number is the phone number 22 in the user interface 490, and the above-mentioned user input of the user enabling the first phone number can be a user operation (such as a click operation) on an enabling control (such as the switch control 443C in the traffic package 443 of the phone number 22 shown in the user interface 490, but at this time it can display "enable") in the user interface in which the first phone number is not enabled.
[0343] Embodiments of the present application also provide an electronic device, including a transceiver, a processor and a memory, the memory is used to store a computer program, and the processor is used to call the computer program to execute the steps performed by the electronic device 100.
[0344] Embodiments of the present application also provide an electronic device, including a transceiver, a processor and a memory, the memory is used to store a computer program, and the processor is used to call the computer program to execute the steps performed by the electronic device 200.
[0345] Embodiments of the present application also provide a cloud server, including a transceiver, a processor and a memory, the memory is used to store a computer program, and the processor is used to call the computer program to execute the steps performed by the cloud server 300.
[0346] Embodiments of the present application also provide an operator server, including a transceiver, a processor and a memory, the memory is used to store a computer program, and the processor is used to call the computer program to execute the steps performed by the MNO 400.
[0347] Embodiments of the present application also provide a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the steps performed by the electronic device 100 in the above-mentioned various method embodiments.
[0348] Embodiments of the present application also provide a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the steps performed by the electronic device 200 in the above-mentioned various method embodiments.
[0349] The embodiment of the present application further provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to realize the steps performed by the cloud server 300 in the method embodiments.
[0350] The embodiment of the present application further provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to realize the steps performed by the MNO 400 in the method embodiments.
[0351] The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is run on a computer, the computer can realize the steps performed by the electronic device 100 in the method embodiments.
[0352] The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is run on a computer, the computer can realize the steps performed by the electronic device 200 in the method embodiments.
[0353] The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is run on a computer, the computer can realize the steps performed by the cloud server 300 in the method embodiments.
[0354] The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is run on a computer, the computer can realize the steps performed by the MNO 400 in the method embodiments.
[0355] The embodiment of the present application further provides a chip system, which includes a processing circuit and an interface circuit, the interface circuit is used to receive code instructions and transmit the code instructions to the processing circuit, and the processing circuit is used to run the code instructions so that the chip system realizes the steps performed by the electronic device 100 in any method embodiment of the present application. The chip system can be a single chip or a chip module composed of multiple chips.
[0356] The embodiment of the present application further provides a chip system, which includes a processing circuit and an interface circuit, the interface circuit is used to receive code instructions and transmit the code instructions to the processing circuit, and the processing circuit is used to run the code instructions so that the chip system realizes the steps performed by the electronic device 200 in any method embodiment of the present application. The chip system can be a single chip or a chip module composed of multiple chips.
[0357] The embodiment of the present application further provides a chip system, the chip system comprising a processing circuit interface circuit, the interface circuit is used for receiving code instructions and transmitting to the processing circuit, the processing circuit is used for running the code instructions so that the chip system realizes the steps executed by the cloud server 300 in any method embodiment of the present application. Wherein, the chip system can be a single chip, or a chip module composed of multiple chips.
[0358] The embodiment of the present application further provides a chip system, the chip system comprising a processing circuit interface circuit, the interface circuit is used for receiving code instructions and transmitting to the processing circuit, the processing circuit is used for running the code instructions so that the chip system realizes the steps executed by the MNO 400 in any method embodiment of the present application. Wherein, the chip system can be a single chip, or a chip module composed of multiple chips.
[0359] The above-described and above-embodied embodiments are only used to illustrate the technical solutions of the present application, rather than limit the same; although the foregoing embodiments of the present application are described in detail, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.< / activationcode> < / uuidapp> < / imeinew> < / uuidapp> < / imeinew> < / cookie> < / otp1> < / msisdnsubs> < / uuidapp> < / imeisim> < / uuidapp> < / imeisim>
Claims
1. A communication system, characterized by The first device and a cloud server are included, wherein, The first device is configured to display a first interface, the first interface including one or more phone numbers of a second device, the one or more phone numbers of the second device including a first phone number; The first device is configured to receive a first input of a user migrating 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 migrating the first phone number to the first device; The cloud server is configured to send a verification code to the first device; The first device is configured to download a configuration file corresponding to the first phone number from an operator server using the verification code.
2. The communication system of claim 1, wherein, The first device is configured to, after receiving the first input of the user migrating the first phone number to the first device, send a second request to the operator server, receive a first response sent by the operator server, wherein the second request carries the first phone number, and the first response indicates that the second request is processed successfully; The cloud server is configured to, after the first device sends the second request to the operator server, receive the verification code sent by the operator server, and send the verification code to the first device.
3. The communication system of claim 2, wherein, The cloud server is configured to, before receiving the verification code sent by the operator server, send a third request to the operator server, and receive a 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 of any of claims 1-3, wherein The first device is configured to, before displaying the first interface, log in a first account, 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 the one or more phone numbers of the second device, and the second device is a device that has logged in the first account.
5. The communication system of claim 4 wherein, The cloud server is configured to, before the first device receives the one or more phone numbers corresponding to the first account sent by the cloud server, receive a first temporary token sent by the second device, 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 of claim 5 wherein, The second device is further included, and the second device is configured 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 of any of claims 1-6, wherein 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 download a configuration file corresponding to the first phone number from the operator server by using the authentication token.
8. The communication system of claim 7 wherein, The first device is configured to send a seventh request to the operator server, and the seventh request carries 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 a configuration file corresponding to the first phone number from a configuration file server corresponding to the first address information.
9. The communication system of claim 7 or 8, characterized by The method further comprises the operator server, wherein The first device is configured to send an eighth request to the operator server, and the eighth request carries the authentication token. The operator server is configured to verify the authentication token carried in the eighth request, and when the authentication token is verified, deactivate a subscription relationship of the first phone number corresponding to the second device, and activate a subscription relationship of the first phone number corresponding to the first device. The activated subscription relationship of the first phone number is used to realize camping on a network through the first phone number.
10. The communication system of any of claims 1-9, wherein, The method further comprises the second device, wherein The first device is configured to display one or more phone numbers of the second device in a first area in the first interface before receiving a first input of the user migrating the first phone number to the first device, and the first area is used to display phone numbers of devices other than the first device. The first device is configured to display the first phone number in a second area in the first interface after downloading the configuration file corresponding to the first phone number from the operator server by using the verification code, and 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 in a second interface before the first input of the user migrating the first phone number to the first device is received by the first device, and the third area is used to display the phone number of the second device. The second device is configured to display the first phone number in a fourth area in the second interface after downloading the configuration file corresponding to the first phone number from the operator server by using the verification code, and the fourth area is used to display the phone number of the device other than the second device.
11. A configuration file migration method applied to a first device, characterized in that, The method comprises: displaying a first interface, the first interface comprising one or more phone numbers of a second device, the one or more phone numbers of the second device comprising a first phone number; receiving a first input of a user migrating the first phone number to the first device; sending a first request to a cloud server, the first request being used to request migrating the first phone number to the first device; receiving a verification code sent by the cloud server; downloading a configuration file corresponding to the first phone number from an operator server by using the verification code.
12. The method of claim 11, wherein, Further comprising: after the receiving the first input of the receiving user migrating the first phone number to the first device, sending a second request to the operator server, the second request carrying the first phone number; receiving a first response sent by the operator server, the first response indicating that the second request is processed successfully, and the verification code is received by the cloud server from the operator server.
13. The method of claim 11 or 12, wherein, Further comprising: before the displaying the first interface, logging in a first account, and receiving 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 a second device, and the second device is a device that has logged in the first account.
14. The method according to any one of claims 11 to 13, wherein, The using the verification code to download the configuration file corresponding to the first phone number from the operator server comprises: sending a third request to the operator server, the third request carrying the verification code; in the case that the verification code is verified by the operator server, receiving an authentication token sent by the operator server; using the authentication token to download the configuration file corresponding to the first phone number from the operator server.
15. The method of claim 14, wherein, The using the authentication token to download the configuration file corresponding to the first phone number from the operator server comprises: sending a fourth request to the operator server, the fourth request carrying the authentication token; in the case that the authentication token is verified by the operator server, receiving first address information sent by the operator server; downloading the configuration file corresponding to the first phone number from the configuration file server corresponding to the first address information.
16. The method of claim 14 or 15, wherein, Further comprising: sending a fifth request to the operator server, wherein the fifth request carries the authentication token, the fifth request is used for the operator server to deactivate the subscription relationship of the first phone number corresponding to the second device, and activate the subscription relationship of the first phone number corresponding to the first device, and the subscription relationship of the first phone number in the activated state is used to realize the network staying through the first phone number.
17. The method of any one of claims 11-16, wherein, The displaying the first interface comprises: displaying the one or more phone numbers of the second device in a first area in the first interface, and the first area is used to display the phone numbers of other devices except the first device; The method further comprises: after the using the verification code to download the configuration file corresponding to the first phone number from the operator server, displaying the first phone number in a second area in the first interface, and the second area is used to display the phone number of the first device.
18. The method of any one of claims 11-17, wherein, Further comprising: after the receiving the verification code sent by the cloud server, displaying a second interface, the second interface comprising an input box and a first notification, and the first notification comprising the verification code; receiving a second input of the user inputting the verification code in the input box; The using the verification code to download the configuration file corresponding to the first phone number from the operator server comprises: In response to the second input, downloading, from the operator server, a configuration file corresponding to the first phone number using the verification code.
19. The method of any one of claims 11-18, wherein, Further comprising: After the downloading, from the operator server, of the configuration file corresponding to the first phone number using the verification code, displaying a third interface, the third interface including the first phone number of the first device; Receiving a third input of a user enabling the first phone number; In response to the third input, performing network access through 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 comprises: Receiving a first request sent by a first device, the first request being used to request migration of a first phone number of a second device to the first device; Sending a verification code to the first device, the verification code being used for the first device to download a configuration file corresponding to the first phone number from an operator server.
21. The method of claim 20, wherein, Further comprising: Before the sending of the verification code to the first device, receiving the verification code sent by the operator server.
22. The method of claim 21, wherein, Further comprising: Before the receiving of the verification code sent by the operator server, sending a second request to the operator server; Receiving a first access token sent by the operator server; The receiving of the verification code sent by the operator server comprises: Receiving first encrypted information sent by the operator server; Decrypting the first encrypted information using the first access token to obtain the verification code.
23. The method of any one of claims 20-22, wherein, Further comprising: Before the receiving of the first request sent by the first device, when the first device logs in a first account, sending 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 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 in the first account.
24. The method of claim 23, wherein, Further comprising: Before the sending of the one or more phone numbers corresponding to the first account to the first device, receiving a first temporary token sent by the second device; Sending a third request to the operator server, the third request carrying the first temporary token; Receiving a second phone number of the second device sent by the operator server, wherein 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.
25. An electronic device, comprising: A transceiver, a processor, and a memory, the memory being used to store a computer program, and the processor being used to invoke the computer program and execute the method according to any one of claims 11-19.
26. A cloud server, characterized by A transceiver, a processor, and a memory, the memory being used to store a computer program, and the processor being used to invoke the computer program and execute the method according to any one of claims 20-24.
27. A computer storage medium, comprising, The computer storage medium stores a computer program, and the computer program is executed by a processor to implement the method according to any one of claims 11-19.
28. A computer storage medium, comprising, The computer storage medium stores a computer program, which, when executed by a processor, is configured to implement the method of any one of claims 20-24.
29. A computer program product, characterised in that, The computer program product, when executed on the processor, is configured to implement the method of any one of claims 11-19.
30. A computer program product, characterised in that, The computer program product, when executed on the processor, is configured to implement the method of any one of claims 20-24.
31. A chip system, characterized by The computer program product, when executed on the processor, is configured to implement the method of any one of claims 20-24.
32. A chip system, characterized by The computer program product, when executed on the processor, is configured to implement the method of any one of claims 20-24. The computer program product, when executed on the processor, is configured to implement the method of any one of claims 20-24.
Citation Information
Patent Citations
Method, device and system for migration from SIM card to euicc
CN108029011A
Code number transfer system, method and device, electronic equipment and storage medium
CN110839234A
User identification number migration method and device, terminal and storage medium
CN111163455A
Payment card migration method and device, electronic equipment, server and medium
CN112801655A
Methods, Systems and Applications for Porting Telephone Numbers on Wireless Devices
US20160198034A1