Source device cross-platform eSIM profile delivery

Abstract

An apparatus configured to participate in an embedded subscriber identity module (eSIM) profile delivery process to deliver an eSIM profile from a source device executing a first operating system (OS) to a target device executing a second OS, the first operating system (OS) implementing a first protocol stack associated with eSIM profile delivery, the second OS implements a second protocol stack related to eSIM profile delivery, wherein the first protocol stack and the second protocol stack are different; processing a token for delivering the eSIM profile based on the signaling received from the authorization server; and generating a message including the token for transmission to the target device.

Description

Priority / Citation

[0001] This application claims priority to U.S. Provisional Application Serial No. 63 / 580,852, filed on September 6, 2023, entitled “Source Device Cross Platform eSIM Profile Transfer,” the entire contents of which are incorporated herein by reference. Background Technology

[0002] Existing implementations of embedded subscriber identity modules (eSIMs) in user equipment (UEs) have several areas for improvement. Users can switch their eSIMs between UEs operating on different operating systems (i.e., different platforms). While exchanging physical SIM cards between platforms is a straightforward process, exchanging eSIMs is not. Enhanced interoperability between the GSMA and manufacturer-specific protocol (MSP) eSIM implementations is needed in this area. Summary of the Invention

[0003] Some example implementations relate to an apparatus having processing circuitry configured to: participate in an embedded user identity module (eSIM) profile transfer process to transfer an eSIM profile from a source device executing a first operating system (OS) to a target device executing a second OS, the first OS implementing a first protocol stack associated with the eSIM profile transfer, and the second OS implementing a second protocol stack associated with the eSIM profile transfer, wherein the first protocol stack and the second protocol stack are different; process a token for transferring the eSIM profile based on signaling received from an authorization server; and generate a message including the token for sending to the target device.

[0004] Other example implementations relate to a method comprising: participating in an embedded user identity module (eSIM) profile transfer process to transfer an eSIM profile from a source device executing a first operating system (OS) to a target device executing a second OS, the first OS implementing a first protocol stack associated with the eSIM profile transfer, the second OS implementing a second protocol stack associated with the eSIM profile transfer, wherein the first protocol stack and the second protocol stack are different; processing a token for transferring the eSIM profile based on signaling received from an authorization server; and generating a message including the token for sending to the target device. Attached Figure Description

[0005] Figure 1 Example network layouts based on various example implementation schemes are shown.

[0006] Figure 2 Example UEs based on various example implementations are shown.

[0007] Figure 3 Example base stations based on various example implementation schemes are shown.

[0008] Figure 4 Example call flows for passing eSIM profiles are shown according to various example implementation schemes.

[0009] Figure 5 Example call flows for passing eSIM profiles using the GSMA process are shown according to various example implementations.

[0010] Figure 6 Example call flows for passing eSIM profiles using example MSP procedures are shown according to various example implementations.

[0011] Figure 7A illustrates a first example call flow for eSIM delivery using a dual-stack authorization server, according to various example implementation schemes.

[0012] Figure 7B illustrates a second example call flow for eSIM delivery using a dual-stack authorization server, based on various example implementation schemes.

[0013] Figure 8 An example call flow is shown for the eSIM profile delivery process using a signed binary large object (blob) according to various example implementations.

[0014] Figure 9 Example call flows are shown, including the process of binding a session token to the eSIM profile of the target device, according to various example implementations.

[0015] Figure 10 Example methods for client-side operations in the eSIM profile delivery process are shown according to various example implementations.

[0016] Figure 11 An example call flow is shown for an eSIM delivery process using a third-party application (3PA) installed on the source when the source and target have an active communication connection, according to various example implementations.

[0017] Figure 12 Example call flows are shown for the eSIM delivery process using the authorized API for 3PA installed on the source, according to various example implementations.

[0018] Figure 13A second example call flow is shown for the eSIM delivery process using the authorized API for 3PA installed on the source, according to various example implementations.

[0019] Figure 14 Example call flows for passing eSIM profiles when there is no communication connection between the source and the destination are shown according to various example implementations.

[0020] Figure 15 An example call flow is shown for the eSIM delivery process using the source's operating system (OS) when the source and target have active short-range communication connections, according to various example implementations.

[0021] Figure 16 Example call flows are shown for an eSIM delivery process that verifies delivery tokens based on the source and destination OS, according to various example implementations.

[0022] Figure 17 Example call flows are shown for passing eSIM profiles using the source and target OSs when there is no communication connection between the source and target, according to various example implementations.

[0023] Figure 18 Example call flows for cross-platform eSIM profile transfer from a source with GSMA OS to a target with MSP OS are shown according to various example implementations. Detailed Implementation

[0024] The example implementation can be further understood by referring to the following description and related figures, in which similar elements have the same reference numerals. The example implementation involves cross-platform eSIM profile delivery.

[0025] Example implementations are described with reference to user equipment (UE). However, references to the UE are provided for illustrative purposes only. The example implementations can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Specifically, the example implementations can be used with any electronic component that supports eSIM operation. Therefore, the UE described herein is used to represent any electronic component.

[0026] Example implementations are also described with reference to 5G New Radio (NR) networks. These example implementations can also be implemented in other types of networks, including but not limited to LTE networks, future evolutions of cellular protocols (e.g., 5G Advanced, 6G, etc.), or any other type of network. In some examples, the example UE will be considered to receive eSIM profiles and other information using a 5G network. However, the UE can receive eSIM profiles and other information via any wired or wireless network.

[0027] The example implementation is also described with reference to the Subscription Manager Data Preparation+ (SM-DP+) service, which is a network element (typically a server) that prepares, stores, and protects carrier profiles (including carrier credentials). However, the term SM-DP+ is merely illustrative, and other entities may refer to devices, components, or functions that perform the functionality of SM-DP+ as described herein using different terms.

[0028] Example implementations are also described with reference to "source" and "target". The term "source" can be the UE currently including the eSIM profile to be transferred. The term "target" can be the UE to which the eSIM profile is to be transferred.

[0029] Some example implementations of the example implementations are also described with reference to source and target devices with different operating systems (OS). Examples of OSes used for source and target devices include iOS released by Apple Inc., Android released by Google Inc., etc. However, the example implementations can be used by source and target devices operating on any OS.

[0030] Furthermore, in some example implementations, source and target devices with different OSes may implement different protocol stacks for eSIM profile delivery. For example, one OS may implement a standardized stack, while another OS may implement an MSP stack. In one example, the standardized stack may be the GSMA Permanent Reference Document TS.43 protocol stack, hereinafter referred to as the GSMA stack or TS.43 stack. However, example implementations may be used by source and / or target devices implementing other types of standardized stacks. References to GSMA OS, GSMA stack, TS.43 OS, or TS.43 stack refer to an OS that implements any type of standardized stack. Moreover, references to these terms do not imply that the OS is owned, distributed, or has any affiliation with the GSMA; they simply mean that the OS implements a GSMA-compliant stack for eSIM profile delivery.

[0031] The example implementations describe various dual-stack (e.g., GSMA and MSP) solutions for eSIM profile delivery. The example implementations illustrate various operations and logic related to conditional token delivery, platform signaling, random number generation, signed binary large objects, third-party applications (3PA), secure connection generation, and quick response (QR) based delivery mechanisms. Further details regarding these various implementations will be discussed below with respect to the various call flows described herein.

[0032] Figure 1 An example network arrangement 100 according to various example implementations is shown. Example network arrangement 100 includes two UEs, 110 and 112. UEs 110 and 112 can be any type of electronic component configured to communicate via a network, such as mobile phones, tablets, desktop computers, smartphones, phablets, embedded devices, wearable devices, Internet of Things (IoT) devices, etc. A real network arrangement may include any number of UEs used by any number of users. Figure 1 In the example, UE 112 may utilize a different operating system (OS) or eSIM protocol than UE 110, and may operate on a different cellular carrier than UE 110. UE 110 and UE 112 may also be directly associated with each other using short-range communication connections such as Bluetooth, Wi-Fi Direct, Near Field Communication (NFC), Cellular Side Link (SL), etc. Therefore, the examples of UE 110 and UE 112 are provided for illustrative purposes only.

[0033] UE 110 and UE 112 can be configured to communicate with one or more networks. In the example of network configuration 100, the network with which UE 110 and UE 112 can wirelessly communicate is a 5G NR radio access network (RAN) 120. UE 110 and UE 112 can also communicate with other types of networks, such as 5G cloud RAN, next-generation RAN (NG-RAN), legacy cellular networks, etc., and UE 110 and UE 112 can also communicate with the network via a wired connection. Referring to the example implementation, UE 110 and UE 112 can establish a connection with 5G NR RAN 120. Therefore, UE 110 and UE 112 can have a 5G NR chipset to communicate with NR RAN 120.

[0034] 5G NR RAN 120 can be part of a cellular network that can be deployed by a network operator (e.g., Verizon, AT&T, T-Mobile, etc.). RAN 120 can include cells or base stations configured to transmit and receive services from UEs equipped with appropriate cellular chipsets. In this example, 5G NR RAN 120 includes gNB 120A. However, the reference to gNB is provided merely for illustrative purposes, and any appropriate base station or cell can be deployed (e.g., Node B, eNodeB, HeNB, eNB, gNB, gNodeB, macro cell, micro cell, small cell, femtocell, etc.).

[0035] Any association procedure can be performed to connect UE 110 and UE 112 to 5G NR RAN 120. For example, as discussed above, 5G NR RAN 120 can be associated with a specific network operator where UE 110 and / or UE 112 and / or their user have protocol and credential information (e.g., stored on a SIM card or eSIM). Upon detecting the presence of 5G NR RAN 120, UE 110 and UE 112 can send corresponding credential information to associate with 5G NR RAN 120. More specifically, UE 110 and UE 112 can be associated with a specific cell (e.g., gNB 120A).

[0036] Network deployment 100 also includes a cellular core network 130, an Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 manages traffic flowing between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to UE 110 and UE 112 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to UE 110 and UE 112. The network services backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 can generally be described as a collection of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of UE 110 in communicating with various networks. In some example implementations, the network services backbone 160 may implement SM-DP+ and enabled servers as described below. However, SM-DP+ and the enable server are not required to reside on the network service backbone 160. SM-DP+ and the enable server can reside anywhere within the network deployment 100.

[0037] Figure 2 Example UE 110 according to various example implementations is shown. (Refer to...) Figure 1The network layout 100 is used to describe UE 110. UE 110 can represent any electronic device including UE 112 and can operate as a source or destination for eSIM profile transfer. UE 110 may include processor 205, memory layout 210, display device 215, input / output (I / O) device 220, transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, batteries providing limited power, data acquisition devices (such as cameras), ports for electrically connecting UE 110 to other electronic devices, sensors for detecting the status of UE 110, etc. Embedded universal integrated circuit card (eUICC) 240 may be a hardware component embedded in UE 110 and is configured to store multiple operator profiles (e.g., eSIM profiles).

[0038] Processor 205 can be configured to execute operating system 245 of UE 110. The operating system can be software that manages the basic functions of UE 110, including task scheduling, application execution, and peripheral control. Operating system 245 can manage the interface between the hardware and software of UE 110 and can provide a user interface to the user.

[0039] Processor 205 can be configured to execute multiple engines for UE 110. For example, an engine may include a cross-platform eSIM engine 235 for performing operations related to UE processing during inter-platform eSIM profile transfer. The cross-platform eSIM engine 235 can perform various operations when UE 110 operates as a target or source during eSIM profile transfer. These operations include, but are not limited to, token passing and associated binding, signaling platform type, random number generation, 3PA application protocol interface (API) processing, secure connection generation, and QR code generation. Each of these operations will be described in more detail below.

[0040] The engines referenced above, as applications (e.g., programs) executed by processor 205, are merely examples. The functionality associated with these engines can also be represented as separate, combined components of UE 110, or as modular components coupled to UE 110, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine can also be embodied as one or more separate applications. Furthermore, in some UEs, the functionality described for processor 205 is split between two or more processors, such as a baseband processor and an application processor. Example implementations can be implemented according to any of these or other configurations of the UE.

[0041] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by UE 110. Display device 215 may be a hardware component configured to display data to a user, while I / O device 220 may be a hardware component enabling a user to input data. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen).

[0042] Transceiver 225 may be a hardware component configured to establish a connection with 5G-NR RAN 120. Therefore, transceiver 225 may operate on a variety of different frequencies or channels (e.g., a continuous set of frequencies). Transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded using information used to implement any of the methods described herein. Processor 205 may be operatively coupled to transceiver 225 and configured to receive signals from and / or transmit signals to transceiver 225. Processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station in the network) for use in implementing any of the methods described herein.

[0043] Figure 3 An example authorization server 300 is illustrated according to various example implementations. The authorization server 300 may represent a network element implemented by an operator or a third party (e.g., the UE manufacturer) that performs various operations related to eSIM profile delivery, such as over-the-air configuration of the UE eSIM profile. In some examples, the authorization server 300 may be implemented in a server device, such as... Figure 3 The example illustrates this. In other examples, the authorization server 300 may be implemented in a distributed manner, such as in a cloud computing implementation, or as a network function.

[0044] The licensing server 300 may include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a network interface component (NIC) 320, and other components 325. Other components 325 may include, for example, audio input devices, audio output devices, batteries, data acquisition devices, ports for electrically connecting the licensing server 300 to other electronic devices and / or a power source, etc.

[0045] Processor 305 may be configured to execute multiple engines of the licensing server 300. For example, an engine may include a cross-platform eSIM engine 330 for performing operations related to transferring an eSIM profile from a source running on a first platform (e.g., a first type of OS) to a target running on a second platform (e.g., a second type of OS). Examples of these operations will be provided in more detail below.

[0046] The memory 310 may be a hardware component configured to store data related to operations performed by the SM-DP+ 300. The I / O device 315 may be a hardware component or port that enables a user to interact with the SM-DP+ 300.

[0047] NIC 320 may be a hardware component configured to exchange data directly or indirectly with UE 110, any other UE, or any other component in network arrangement 100. Because the SM-DP+ 300 typically resides within the network, NIC 320 may include a wired network interface, such as Ethernet or other wired type network interfaces. In some examples, NIC 320 may also include a radio interface and operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). Therefore, NIC 320 may include one or more components (e.g., radio components) to enable data exchange with various networks and UEs. NIC 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded using information from implementing any of the methods described herein. Processor 305 may be operatively coupled to NIC 320 and configured to receive signals from and / or transmit signals to NIC 320. The processor 305 can be configured to encode and / or decode signals (e.g., signaling from the UE) for use in implementing any of the methods described herein.

[0048] Figure 4 Example call flow 400 for delivering eSIM profiles is illustrated according to various example implementations. Call flow 400 is described as a high-level overview of several aspects of the example implementation. Further details will be provided regarding other call flows described below. Call flow 400 includes a source 402 and a destination 404. In call flow 400, source 402 may include a TS.43 protocol stack, and destination 404 may include an MSP stack for delivering eSIM profiles. UE 110 may be the source, and UE 112 may be the destination. However, this designation is arbitrary, and both UE 110 and UE 112 may be either the source or the destination. The source and destination may also have different operating systems. Both the source and destination include eUICC (e.g., substantially similar to eUICC 240). The protocol stack of the source or destination will be appropriately mentioned if relevant to a particular example implementation or call flow. Call flow 400 also includes an authorization server 406 and an SM-DP+ 408, both of which have been described above.

[0049] In 412, source 402 and destination 404 (e.g., via a secure tunnel) establish a secure connection for eSIM profile delivery. In 414, destination 404 sends a destination identifier to source 402. Additional examples of various types of destination identifiers are provided below. In 416, source 402 sends a token request to authorization server 406. Request 416 may also use a signed binary large object to indicate the platform type. Examples of different types of binary large objects are described in more detail below. In 418, authorization server 406 transmits a token response to source 402, including a delivery token. In 420, source 402 sends a delivery token to destination 404.

[0050] In step 422, target 404 uses the MSP to cancel the delivery token and informs the authorization server 406 that the delivery token has been canceled. The cancellation of the delivery token may include any actions performed by the authorization server 406 and target 404 and / or messages exchanged between the authorization server and the target to verify that target 404 has a valid delivery token and is authorized to receive the eSIM profile.

[0051] In step 426, the authorizing server 406 sends a prepare profile message to SM-DP+ 408. In step 428, SM-DP+ 408 prepares the eSIM profile. In step 430, SM-DP+ sends the eSIM profile to target 404. In step 432, target 404 installs the eSIM profile.

[0052] Figure 5 Example call flow 500 for delivering eSIM profiles using the GSMA process is shown according to various example implementations. Source 504, destination 502, and SM-DP+ 508 are substantially similar to the reference. Figure 4 The equivalent entity described. Authorization server 506 may also include an MNO backend capable of managing mobile network operator (MNO) network infrastructure and user management.

[0053] In step 510, source 504 performs a user authentication process with authorization server 506 via Extensible Authentication Protocol-Authentication and Key Negotiation (EAP-AKA). In step 512, authorization server 506 sends an authentication token to source 504. In step 514, source 506 sends a verification message to authorization server 506, including source 504's International Mobile Equipment Identity (IMEI) and the authentication token received in step 512.

[0054] In step 516, the authorizing server 506 sends a PrimaryAppEligibility=Enabled message to the source 504. In step 518, the source 504 sends a message to the authorizing server 506 to obtain a temporary token, including the authentication token. In step 520, the authorizing server 506 sends a temporary token to the source 504, including the expiration time of the temporary token.

[0055] In step 522, source 504 sends a temporary token to target 502, including other relevant information related to the eSIM profile transfer.

[0056] In 524, target 502 sends a management subscription (transmission) message to authorization server 506, including a temporary token and an old integrated circuit card identification code (ICCID), such as the ICCID of source 504's eUICC.

[0057] In 526, the authorization server 506 and SM-DP+ 508 perform the ES2+ profile subscription operation. The ES2+ profile subscription operation is a known operation used to subscribe to an eSIM profile for a specific eUICC, and will not be described further in this document.

[0058] In step 528, the authorization server 506 sends an activation code or push notification to the target 502 to activate the eSIM profile upon receiving it from SM-DP+ 508. In step 530, SM-DP+ 508 sends the eSIM profile to the target 502. In step 532, the target 502 installs and activates the eSIM profile.

[0059] Figure 6 Example call flow 600 for delivering eSIM profiles using a sample MSP procedure is shown according to various example implementations. The MSP procedure is only one example of an MSP procedure, and different manufacturers may have different MSP procedures. Target 602, source 604, authorization server 606, and SM-DP+ 608 are substantially similar to the reference. Figure 5 The equivalent entity described.

[0060] In step 610, source 604 performs the user authentication process with authorization server 606 via EAP-AKA. In step 612, source 604 and authorization server 606 perform eligibility checks for the eSIM profile passed to them.

[0061] In step 614, source 604 enables the user to confirm the eSIM profile transfer via a user interface. In step 616, source 604 sends a token request to the authorization server 606, including an indication that the user has confirmed the eSIM profile transfer.

[0062] In step 618, the authorizing server 606 verifies the token request 616. In step 620, the authorizing server 606 sends the delivery token to the source 604, including the expiration time of the delivery token.

[0063] In step 622, source 604 sends a transfer token to target 602, including other relevant information for eSIM transfer. In some example implementations, after step 622, the user can further verify the eSIM profile transfer by confirming it on target 602 via a user interface.

[0064] In step 624, target 602 sends a delivery request 624 to authorization server 606, including the delivery token. In step 626, authorization server 606 verifies request 624.

[0065] In step 628, the authorizing server 606 and SM-DP+ 608 perform the ES2+ profile subscription operation. In step 630, the authorizing server 606 sends eSIM download information to the target 602. In step 632, the target 602 and SM-DP+ 608 perform the profile download and installation operation.

[0066] The following example implementation describes a dual-stack granting server, such as a TS.43 stack and an MSP stack. The dual-stack granting server can perform operations for both TS.43 eSIM delivery and MSP eSIM delivery operations, for example, operations performed by granting server 506 (TS.43 stack) and granting server 606 (MSP stack). The following example call flow in Figures 7A and 7B describes eSIM profile delivery using a dual-stack granting server. SM-DP+ operations are not included in the following call flow because the call flow illustrates the interaction between the dual-stack granting server and the source and destination. However, during the eSIM profile delivery operation, the dual-stack granting server and SM-DP+ can still perform the ES2+ profile ordering operations described above at appropriate times.

[0067] Figure 7A illustrates a first example call flow 700 for eSIM delivery using a dual-stack authorization server according to various example implementations. Call flow 700 shows a source 704 implementing a TS.43 stack passing an eSIM profile to a target 702 implementing an MSP stack. The authorization server 706 may feature both a TS.43 stack 705 and an MSP stack 707.

[0068] In step 708, target 702 and source 704 establish a secure connection (e.g., via a secure tunnel) for eSIM profile transfer. In step 709, target 702 sends a target identifier to source 704, which may contain any information that can be used to identify target 702 during the eSIM profile transfer operation.

[0069] In 710, source 704 and authorizing server 706 (via TS.43 stack 705) perform the authentication process via EAP-AKA. In 712, source 704 and authorizing server 706 perform the process of obtaining a temporary token via TS.43 stack 705.

[0070] In operation 714, the TS.43 stack 705 of the authorizing server 706 sends a temporary token to the source 704. In operation 716, the TS.43 stack 705 of the authorizing server 706 sends token context information to the MSP stack 707 of the authorizing server 706. For example, operation 716 is an internal operation of the authorizing server 706.

[0071] In operation 718, source 704 transmits a temporary token to target 702. As described above, the temporary token is a construct of the TS.43 stack transfer operation, but target 702 is executing the MSP stack. Therefore, operation 718 may also include source 706 transmitting additional information related to the MSP stack, so that target 702 can use the temporary token.

[0072] In 720, the MSP stack 707 of target 702 and authorizing server 706 performs MSP-specific delivery operations, including transmitting a temporary token in the delivery token field. (See above reference.) Figure 6 As described in operation 624, the MSP stack can implement a delivery token for eSIM profile delivery. In this example, target 702 delivers a temporary token received from source 704 (e.g., a TS.43 eSIM profile delivery construct) in the delivery token field, instead of a temporary token. Dual-stack authorization server 706 will understand that the temporary token in the delivery token field is equivalent to the delivery token for the MSP eSIM delivery operation and will use that temporary token for the eSIM delivery operation.

[0073] In 722, the MSP stack 707 of the authorization server 706 sends eSIM configuration file download information to the target 702, similar to operation 630 described above.

[0074] Figure 7B illustrates a second example call flow 750 for eSIM delivery using a dual-stack authorization server, according to various example implementations. Call flow 750 shows a source 754 implementing an MSP stack delivering an eSIM profile to a target 752 implementing a TS.43 stack. The authorization server 706 may feature both a TS.43 stack 705 and an MSP stack 707, and may be the same authorization server 706 originating from call flow 700.

[0075] In 760, target 752 and source 754 establish a secure connection via a secure tunnel for eSIM profile transfer. In 762, target 752 sends a target identifier to source 754, such as any information that can be used to identify target 752 during the eSIM profile transfer operation.

[0076] In step 764, the MSP stack 707 of source 754 and authorizing server 706 performs the authentication process via EAP-AKA. In step 766, the MSP stack 707 of source 754 and authorizing server 706 performs an MSP-specific delivery operation. In step 768, the MSP stack 707 of authorizing server 706 sends a delivery token to source 754.

[0077] In 772, the MSP stack 707 of the authorizing server 706 sends token context information to the TS.43 stack 705 of the authorizing server 706. For example, operation 772 is an internal operation of the authorizing server 706.

[0078] In operation 770, source 754 sends a transfer token to target 752. As described above, the transfer token is a construct of the MSP stack transfer operation, but target 752 is executing the TS.43 stack. Therefore, operation 770 may also include source 754 transferring additional information related to the TS.43 stack, so target 752 can use the transfer token.

[0079] In 774, target 752 sends a management subscription (delivery) message to authorization server 706's TS.43 stack 705, including the delivery token in the temporary token field and the old ICCID, for example, the ICCID of source 754's eUICC. (See above reference.) Figure 5 As described in operation 624, the TS.43 stack can implement a temporary token for eSIM profile delivery. In this example, target 752 transmits a delivery token received from source 754 (e.g., a construct for MSP eSIM profile delivery) in the temporary token field, instead of a delivery token. Dual-stack authorization server 706 will understand that the delivery token in the temporary token field is equivalent to the temporary token for the TS.43 eSIM delivery operation and will use that delivery token for the eSIM delivery operation.

[0080] In 776, the TS.43 stack 705 of the authorization server 706 sends an activation code or push notification to the target 752 to activate the eSIM profile upon receiving it from SM-DP+, similar to the reference above. Figure 5 The described operation is 528.

[0081] As described above, some example implementations use binary large objects during the eSIM profile delivery process. A binary large object can be considered a server-side random number. Example methods for calculating server-side random numbers (e.g., binary large objects) are described in more detail below. Binary large objects can be used to provide protection against attacks, such as replay attacks.

[0082] Figure 8 An example call flow 800 for the delivery of eSIM profiles using signed binary large objects, according to various example implementations, is shown. The target 802, source 804, and authorizing server 806 are characterized by capabilities substantially similar to those of similar entities previously discussed in this disclosure, including authorizing servers with MNO backends. Figure 8 In this context, it doesn't matter which protocol stack the target 802 or source 804 uses, because the signed binary large object can be used with either the TS.43 stack or the MSP stack. Figure 8 In the example, source 804 can be considered to implement the TS.43 stack, and target 802 can be considered to implement the MSP stack for cross-platform eSIM profile passing from GSMA OS to MSP OS. Call flow 800 can be modified for the opposite cross-platform eSIM profile passing, for example, from MSP OS to GSMA OS.

[0083] Malicious actors could launch a replay attack during eSIM profile delivery. Call flow 800 utilizes server random numbers (e.g., binary large objects) to provide protection against such attacks. Additional source and destination information is used to notify the authorization server 806 of the cross-platform delivery. Using this information, the authorization server can embed the source platform type into a temporary token, as described in more detail below.

[0084] In step 808, target 802 sends a message to source 804 containing target 802's International Mobile Equipment Identity (IMEI) (IMEI_t), target 802's Embedded Identity Document (EID) (EID_t), and target 802's platform type (platform_t). The platform type can be the OS executed by target 802, such as GSMA OS, MSP OS, etc.

[0085] Operations 810-815 are similar to the reference. Figure 5 The corresponding operations described are 510-516, and will not be described again.

[0086] In step 816, source 804 and authorizing server 806 perform server random number calculation. In some example implementations, this calculation can be performed by hashing the authentication token, since both source 804 and authorizing server 806 possess this information at that point in the call flow 800. In other implementations, a new application programming interface (API) may be introduced, which includes information common to source 804 and authorizing server 806 that can be used to calculate the server random number. Although the operation is described as source 804 calculating the server random number, in some example implementations, source 804 may retrieve the server random number from authorizing server 806, rather than calculating the server random number via, for example, the new API.

[0087] In 817, source 817 computes one or both of two types of signature binary large objects. The first type of signature binary large object includes a server random number computed in 816, [IMEI_t, EID_t, platform_t] received in 808, [IMEI_s, EID_s, and Platform_s] from source 804, and user intent level (e.g., biometric information, password, etc.). When user authentication (e.g., biometric information, password, etc.) is successful, this first type of binary large object can be verified and signed by the operating system of source 804.

[0088] The second type of binary large object includes a server random number calculated in the 816 and the ICCID of the eSIM profile. This second type of binary large object can only be verified and signed by the eUICC of the source 804 if the ICCID is installed on the source 804.

[0089] In 818, source 804 sends a Request Temporary Token message to authorization server 806, which may include an authentication token and one or more signature binary large objects.

[0090] In 819, the authorization server 806 verifies the signed binary large object by checking the platform, EID, proof of the binary large object (e.g., a first-type binary large object), and user intent level (for a second-type binary large object). In 820, the authorization server 806 stores the IMEI_t and EID_t.

[0091] Authorization server 806 can fully satisfy the verification performed in 819. However, in some cases, authorization server 806 may have verified the information, but may not have fully satisfied the verification (for example, it may have verified enough information included in the signed binary large object to consider the request valid, but some incorrect information exists). Therefore, after 820, there are two different alternative solutions to handle these cases.

[0092] In the first alternative scenario (e.g., when the authorizing server 806 is completely satisfied with the verification result), in 822, the authorizing server 806 sends to the source 804 an encrypted temporary token that includes the expiration time of the temporary token and includes the identifier of the source platform (e.g., embed_platform_s).

[0093] In a second alternative scenario (e.g., when the authorizing server 806 is not entirely satisfied with the verification result), in step 824, the authorizing server 806 may request the source 804 to perform additional verification checks. For example, in step 824, the authorizing server 806 may send the URL of a separate authentication server to the source 804. The source 804 may then perform a fallback operation via the webpage associated with the URL to further verify its identity. If the further authentication of the source 804 is successful, the authorizing server 806 may then send the source 804 an encrypted temporary token including an expiration time and an identifier of the source platform (e.g., embedded_platform_s).

[0094] Figure 9 Example call flow 900, illustrating a process for transferring an eSIM profile by binding a session token to the target device, is shown according to various example implementations. Binding the session token to the IMEI or EID ensures that only the target 902 can download the prepared profile. The target 902, source 904, and authorization server 904 are essentially similar. Figure 8 The target, source, and authorization server are discussed in the example. Similarly, in this example, the cross-platform eSIM profile transfer is from GSMA OS to MSP OS, but call flow 900 can be modified for the reverse cross-platform eSIM profile transfer, for example, from MSP OS to GSMA OS. Additionally, call flow 900 can be modified after source 904 receives a temporary token from authorization server 906 (e.g., in...). Figure 5 Operation 520 or Figure 8 (After operation 822) it begins.

[0095] In step 910, source 904 sends a temporary token to destination 902, including an appended EID_t. In some examples, the EID_t may be provided in plaintext, but this is not required. For example, as mentioned above... Figure 8 As described in operation 808, when initiating the eSIM profile transfer with source 904, target 902 may have already transmitted its EID_t. In 912, target 902 verifies that the plaintext EID_t matches that of target 904.

[0096] In 916, target 902 sends a management subscription (delivery) message to authorization server 906, including a temporary token and an old integrated circuit card identification code (ICCID), such as the ICCID of source 904's eUICC, similar to... Figure 5 Operation 524. In this example implementation, the management subscription message may also include IMEI_t, EID_t, and platform_t, each of which has been described above.

[0097] In step 918, the authorizing server 906 verifies the temporary token. As described above, during call flow 800, the authorizing server 906 may have already obtained a signed binary large object containing various information from source 904. The authorizing server 906 can then use this information (e.g., platform / EID proof binary large object, user intent level) or other information to verify the temporary token.

[0098] In some example implementations (not shown), after 918, the authorization server 906 may request target 802 to perform the actions described above. Figure 8 The additional authentication check described in operation 824 is similar to an additional authentication check. For example, authorization server 906 may send the URL of a separate authentication server to target 902, which may then prompt the user to perform additional authentication on target 902.

[0099] In 920, the authorization server 906 and SM-DP+ 908 perform the ES2+ profile subscription process. In this example, during the ES2+ profile subscription process, the authorization server 906 can provide the EID_t and IMEI_t to the SM-DP+ 908. In 922, the SM-DP+ 908 binds the eSIM profile to the EID_t.

[0100] In step 924, the authorization server 908 sends an activation code or push notification to the target 902, indicating that the configuration file is ready for download. In step 926, the target 902 sends a configuration file download request message to SM-DP+ 908. In step 928, SM-DP+ authentication is included in the EID_t of the download request message.

[0101] When EID_t is successfully verified in 928, SM-DP+ 908 sends the eSIM profile package to target 902 in 930. In 932, target 902 installs the eSIM profile package.

[0102] The examples above describe various call flows for eSIM profile delivery from the perspective of the entire process (e.g., various interactions between the source, destination, authorization server, and SM-DP+). The following examples describe the methods and call flows for eSIM profile delivery from the client side (e.g., source and / or destination).

[0103] Figure 10 An example method 1000 for client-side operations during the eSIM profile delivery process, according to various example implementations, is shown. Method 1000 is about... Figures 11 to 17 These diagrams, used to describe various call flows, are all call flow diagrams. Method 1000 can generally describe the relationships between various call flows, and each of these call flows will be described in more detail below.

[0104] In 1002, the source determines whether the eSIM delivery operation is provided by a 3PA installed on the source or by a first party (e.g., using an OS installed on the source). Method 1000 will first describe the 3PA path.

[0105] In step 1004, the source determines whether a wireless connection exists between the source and the target (e.g., Wi-Fi, Bluetooth, NFC, Ultra-Wideband (UWB), etc.). If a wireless connection exists (i.e., it is present), the source proceeds to step 1006. Figure 11 The call flow. In 1006 Figure 11 After the call flow, the source can proceed to 1008 before the end. Figure 12 The call process or 1010 Figure 13 The call process.

[0106] If there is no wireless connection between the source and the target in 1004, the source proceeds to 1012. Figure 14 The call flow. In 1012 Figure 14 Following the call flow shown, the source proceeds to the end.

[0107] Returning to 1002, if the source is using a first-party (OS) level eSIM delivery operation method, the source proceeds to 1014. In 1014, the source determines whether there is a wireless connection (i.e., Wi-Fi, Bluetooth, NFC, etc.) between the source and the target.

[0108] If there is a wireless connection between the source and the target, the source will advance to 1016. Figure 15 The call flow then proceeds to 1018 before reaching the end. Figure 16 The call process.

[0109] If there is no wireless connection between the source and the target in 1014, the source proceeds to 1020. Figure 17 The call process.

[0110] Figure 11 Example call flow 1100 is shown according to various example implementations for an eSIM delivery process using a third-party application installed on the source when the source and target have an active short-range communication connection. Call flow 1100 illustrates a source 1102 including a 3PA 1104 and an OS 1105. For example, the 3PA 1104 could be an MNO application that a user can interact with to perform eSIM profile delivery. Call flow 1100 also includes a target 1106 with an OS 1107.

[0111] Source 1102 with 3PA 1104 and OS 1105 and target 1106 with OS 1107 in Figures 11 to 14 As shown in the image. It should be understood that... Figures 11 to 14 The call flow corresponds to Figure 10 The path to the "third-party app on the source" is shown.

[0112] Call flow 1100 involves scenarios where the source and target have active communication connections, for example, Figure 10 Method 1000 describes operation 1006. In the context of this call flow, the term "activity" includes targets and sources that can discover each other, for example, via NFC, Bluetooth notification processes, etc. Call flow 1100 illustrates the operations and logic related to establishing a secure tunnel for eSIM profile transfer.

[0113] In 1108, the 3PA 1104 on source 1102 and the OS 1107 on target 1106 perform a discovery operation via Wi-Fi (or any other means by which source 1102 and target 1106 discover each other). This discovery operation can utilize various means, such as proximity (e.g., NFC, Bluetooth, UWB), such as a camera scan operation using a displayed code or symbol containing information related to the eSIM profile transfer. Those skilled in the art will understand that the displayed camera code does not need to be a barcode or QR code, and various designs can be used to transmit eSIM transfer information.

[0114] Discovery operations may include a target or source sending a beacon that can be used by another device for identification purposes. Various types of device identifiers can be implemented for discovery operations. This may include a length field related to the length of the beacon; a tag field serving as a beacon indicator; a version field indicating the protocol version; a device type (DevType) field (ENUM, including enumerations such as smartphones, tablets, smartwatches, etc.); a platform field (ENUM, operating system name) indicating the platform type; and a role field (ENUM, source, target) including the role the device will perform during the eSIM delivery process. Those skilled in the art will understand that any combination of these identifiers may be used by the source or target in the beacon.

[0115] In 1110, OS 1107 of target 1106 generates a random Personal Identification Number (PIN), a PK / SK pair (public and private key pair), and displays the PIN to the user so that the user can enter the PIN into source 1102 at a later time. In 1111, target OS 1107 sends a SetupStart message to source 3PA 1104, including PK_t (e.g., the target public key). Following 1111, two alternative operation procedures are described.

[0116] In the first alternative scenario, 3PA 1104 proceeds from 1111 to 1112. In 1112, 3PA 1104 generates a PK / SK pair, receives a PIN from the user via user input (UI), and generates a session key. In 1114, 3PA 1104 sends a SetupVerify message to the target OS 1107, including the hashed PIN and PK_s. In 1116, the target OS 1107 verifies the hashed PIN and generates a session key.

[0117] Now we move to the second alternative. In step 1118, 3PA 1104 receives the PIN from the user via the UI and generates a symmetric key. In step 1120, 3PA 1104 sends a SetupVerify message to the target OS 1107, including the PIN and symmetric key. The PIN and symmetric key are encrypted using PK_t. In step 1122, the target OS 1107 verifies the PIN and retrieves the symmetric key.

[0118] Following either the first or second alternative solution, call flow 1100 proceeds to 1124. In 1124, the target OS 1107 sends encrypted information to the 3PA 1104 of the source 1102. This encrypted information can be used to establish a secure tunnel. This encrypted information may include, for example, EID_t, IMEI, Bluetooth MAC address, and a second PIN generated by the target 1106. After completing call flow 1100, a secure tunnel for eSIM profile transfer has been established between the source 1102 and the target 1106.

[0119] Figure 12 A first example call flow 1200 is shown for an eSIM delivery process using an authorized API for a 3PA mounted on a source, according to various example implementations. Call flow 1200 may be executed after a secure tunnel is established in call flow 1100, for example, Figure 10 Method 100, operation 1008.

[0120] In step 1208, 3PA 1104 retrieves associated phone numbers and plans from source OS 1105. Retrieval 1102 may also include other information, such as contacts from the contact list, associated contact photos, etc.

[0121] In call flow 1200, two alternative scenarios are presented for processing retrieved phone numbers, etc. In the first alternative scenario, at 1210, 3PA 1104 prompts the user to select data to migrate to target 1106, including one or more phone numbers from the UI of source 1102. In the second alternative scenario, at 1212, 3PA 1104 sends a list of phone numbers and MNO plans, along with other data such as contacts and contact photos, to target OS 1107. At 1214, the user can select the data to migrate from the UI of target 1106, for example, a subset of the displayed phone numbers and other data. At 1216, target OS 1107 transmits this selection to 3PA 1104.

[0122] In step 1218, 3PA 1104 sends a transfer token request API to OS 1105 of source 1102, including ICCID, EID_T, and IMEI_T. In step 1220, source OS 1105, using the transfer token request API, retrieves a transfer token from the associated authorization server and provides the transfer token to 3PA 1104. For example, see any of operations 418, 520, 620, 714, 768, or 822 described above. In step 1221, 3PA 1104 sends a transfer token to target OS 1107.

[0123] In step 1222, target OS 1107 revoks the delivery token from the authorization server and SM-DP+. For example, see any of operations 422, 524, 624, 720, 774, or 916 described above. In step 1223, target 1106 is then attached to the MNO network.

[0124] In step 1224, the target OS 1107 sends a delivery completion message to 3PA 1104. In step 1226, 3PA 1104 sends a delivery completion message to the source OS 1105. In step 1228, the source OS 1105 performs various post-delivery management operations, such as marking or removing the delivered eSIM profile. In step 1230, the source OS 1105 sends an OK / ACK message to 3PA 1104 indicating that the operations related to the delivery of the eSIM profile are complete.

[0125] Figure 13 A second example call flow 1300 is shown for an eSIM delivery process using an authorized API for a 3PA mounted on a source, according to various example implementations. Call flow 1300 may be executed after a secure tunnel is established in call flow 1100, for example, Figure 10 Method 1000 operates on 1010. For example... Figure 10 As shown, call flow 1300 can be an alternative to call flow 1200. Call flow 1300 protects the transmission token and provides selective access to the token based on the PIN entry and discovery process between source 1102 and destination 1106.

[0126] Operations 1308-1316 are similar to those described in reference call flow 1200 above and will not be described again.

[0127] In step 1318, 3PA 1104 sends an eSIM delivery request API to the source OS 1105. The information sent may include, for example, EID_t, IMEI, Bluetooth MAC address, a second PIN generated by the target 1106, etc. As described above, some or all of this information may have already been received in an encrypted message from the target OS 1107 in, for example, operation 1124.

[0128] In 1320, the source OS 1105 and the target OS 1107 can use, for example, Bluetooth and a second PIN to perform discovery operations. Different protocols can be used to perform discovery operations, and the second PIN is not required for discovery operations.

[0129] In step 1322, the source OS 1105, using the eSIM delivery request API, retrieves the delivery token from the associated authorization server. For example, see any of operations 418, 520, 620, 714, 768, or 822 described above. In step 1324, the source OS 1105 sends the delivery token to the target OS 1107.

[0130] In step 1326, target OS 1107 revoks the delivery tokens from the authorization server and SM-DP+. For example, see any of operations 422, 524, 624, 720, 774, or 916 described above. In step 1328, target 1106 is attached to the MNO network.

[0131] In step 1330, the target OS 1107 sends a delivery completion message to the source OS 1105. In step 1332, the source OS 1105 performs various post-delivery management operations, such as marking or removing the delivered eSIM profile. In step 1334, the source OS 1105 sends an OK / ACK message to 3PA1104 indicating that the operations related to the delivery of the eSIM profile are complete.

[0132] Figure 14 Example call flow 1400 for eSIM profile transfer when there is no communication connection between the source and the destination, according to various example implementations, is shown. Call flow 1400 follows... Figure 10 The 'non-existent' path shown after 1004 (i.e., no wireless connection between the source and the target) is used in call flow 1400 as a backup to replace the secure tunnel that is unavailable due to the lack of a communication connection between the source and the target.

[0133] In step 1402, the user can select the plan to be used for delivery on source 1102 or destination 1106. For the purposes of call flow 1400, the user can select source 1102 as the source device and destination 1106 as the destination device, but this is only an example. After step 1402, two alternative options are presented depending on whether source 1102 or destination 1106 is used to display the QR code.

[0134] In the first alternative, source 1102 displays a QR code (or a functionally equivalent) format. In 1406, 3PA 1104 of source 1102 displays the ICCID and / or carrier identifier in QR code format on the display of source 1102. In 1408, target 1106 uses a camera or other optical scanning device to scan the QR code.

[0135] In step 1410, target OS 1107 resolves the ICCID to identify the associated authorization server address. In step 1412, target OS 1107 communicates with the authorization server to retrieve eSIM delivery information. At step 1412, the user is prompted to authenticate the transaction on target 1106 (e.g., via PIN / password / biometrics).

[0136] In the second alternative, target 1106 displays a QR code (or a functionally equivalent) format. Following 1402, in 1414, target OS 1107 can display EID_t and IMEI_t in QR code format on the display of target 1106. In 1416, 3PA 1104 retrieves EID_t and IMEI_t by scanning the QR code displayed on target 1106 using a camera or other optical scanning device based on source 1102.

[0137] In step 1417, 3PA 1104 sends a delivery token, including ICCID, EID_t, and IMEI_t, to source OS 1105 via the QR request API. In step 1418, source OS 1105 retrieves a delivery token from the associated authorization server via the QR request API using the delivery token including ICCID, EID_t, and IMEI_t. For example, see any of operations 418, 520, 620, 714, 768, or 822 described above.

[0138] In step 1420, source OS 1105 uses the display of source 1102 to display the ICCID and delivery token in QR code format. In step 1422, target OS 1106 scans the ICCID and delivery token displayed via the QR code. In step 1424, target OS 1107 parses the scanned QR code ICCID to identify the associated authorization server address.

[0139] In 1426, the target OS 1107 revoks the delivery tokens from the authorization server and SM-DP+. For example, see any of the operations 422, 524, 624, 720, 774 or 916 described above.

[0140] Figures 15 to 17 It shows Figure 10 Method 1000's first-party path. Figures 15 to 17 The call flow illustrates source 1102 with OS 1105 and target 1106 with OS 1107. Unlike third-party apps on the source path, there is no 3PA in these examples because source OS 1105 is configured to perform all operations of source 1102 regarding the eSIM profile transfer process.

[0141] Figure 15Example call flow 1500 is shown, illustrating an eSIM delivery process using the source's operating system (OS) when the source and target have an active communication connection, according to various example implementations. Call flow 1500 illustrates the operations and logic associated with establishing a secure tunnel for eSIM profile delivery.

[0142] Call flow 1500 involves scenarios where the source and target have active communication connections, for example, Figure 10 Method 1000, Operation 1016. In the context of this call flow, the term "activity" includes targets and sources that can discover each other, for example, via NFC, Bluetooth notification processes, etc.

[0143] In 1508, the OS 1105 of source 1102 and the OS 1107 of target 1106 perform a discovery operation via Wi-Fi (or any other means by which source 1102 and target 1106 discover each other). This discovery operation can utilize various means, such as proximity (e.g., NFC, Bluetooth, UWB), such as a camera scan operation using a displayed code or symbol containing information related to the eSIM profile transfer. Those skilled in the art will understand that the displayed camera code does not need to be a barcode or QR code, and various designs can be used to transmit eSIM transfer information.

[0144] Discovery operations may include a source or target sending a beacon that can be used by another device for identification purposes. Various types of device identifiers can be implemented for discovery operations. This may include a length field related to the beacon's length; a tag field serving as a beacon indicator; a version field indicating the protocol version; a device type (DevType) field (ENUM, including enumerations such as smartphones, tablets, smartwatches, etc.); a platform field (ENUM, operating system name) indicating the platform type; and a role field (ENUM, source, target) including the role the device will perform during the eSIM delivery process. Any combination of these identifiers may be used by the source or target in the beacon.

[0145] In step 1510, target OS 1107 generates a random Personal Identification Number (PIN), a PK / SK pair (public and private key pair), and displays the PIN to the user so that the user can later enter the PIN into source OS 1102. In step 1511, target OS 1107 sends a setup start message to source OS 1105, including the PK_t (e.g., the target public key). Following step 1511, two alternative operation procedures are described.

[0146] In the first alternative scenario, source OS 1105 progresses from 1511 to 1512. In 1512, source OS 1105 generates a PK / SK pair, receives a PIN from the user via user input (UI), and generates a session key. In 1514, source OS 1105 sends a setup verification message to target OS 1107, including the hashed PIN and PK_s. In 1516, target OS 1107 verifies the hashed PIN and generates a session key.

[0147] Now we move to the second alternative scenario. In step 1518, the source OS 1105 receives the PIN from the user via the UI and generates a symmetric key. In step 1520, the source OS 1105 sends a setup verification message to the target OS 1107, including the PIN and symmetric key. The PIN and symmetric key are encrypted using PK_t. In step 1522, the target OS 1107 verifies the PIN and retrieves the symmetric key.

[0148] Following either the first or second alternative solution, call flow 1500 proceeds to 1524. In 1524, the target OS 1107 sends encrypted information to the source OS 1105, which can be used to establish a secure tunnel. This encrypted information may include, for example, EID_t, IMEI, Bluetooth MAC address, and a second PIN generated by the target OS 1106. After completing call flow 1500, a secure tunnel for eSIM profile transfer has been established between the source OS 1102 and the target OS 1106.

[0149] Figure 16 Example call flow 1600 is shown for an eSIM delivery process that verifies the delivery token based on the OS using the source and destination, according to various example implementations. Call flow 1600 can be executed after a secure tunnel is established in call flow 1500, for example, Figure 10 Method 1000 operation 1018.

[0150] Call flow 1600 presents two alternative scenarios for handling the migration of a phone number from source 1102 to target 1106. In the first alternative scenario, at 1610, source OS 1105 receives input from the user via the UI of source 1102, specifying the associated phone number and plan to be migrated to target 1106. The input may also identify other information, such as contacts from the contact list, associated contact photos, etc.

[0151] In the second alternative scenario, in step 1612, the source OS 1105 sends a list of phone numbers and MNO plans, along with other data such as contacts and contact photos, to the target OS 1107. In step 1614, the user can select the data to migrate on the UI of the target OS 1106. In step 1616, the target OS 1107 transmits this selection to the source OS 1105.

[0152] In 1618, the source OS 1105 and the target OS 1107 can use, for example, a Bluetooth MAC address and a second PIN (e.g., in...). Figure 15 The discovery operation is performed using information exchanged in operation 1524. Different protocols can be used to perform the discovery operation, and a second PIN is not required for the discovery operation.

[0153] In step 1620, the source OS 1105 retrieves the transfer token from the associated authorization server. For example, see any of operations 418, 520, 620, 714, 768, or 822 described above. In step 1622, the source OS 1105 sends the transfer token to the target OS 1107.

[0154] In step 1624, target OS 1107 revoks the delivery tokens from the authorization server and SM-DP+. For example, see any of operations 422, 524, 624, 720, 774, or 916 described above. In step 1628, target 1106 is attached to the MNO network.

[0155] In step 1630, the target OS 1107 sends a delivery completion message to the source OS 1105. In step 1632, the source OS 1105 performs various post-delivery management operations, such as marking or removing the delivered eSIM profile.

[0156] Figure 17 Example call flow 1700 is shown, based on various example implementations, for passing eSIM profiles using the source and target OSs when there is no communication connection between the source and target. Call flow 1700 follows... Figure 10 The 'non-existent' path shown after 1004 (i.e., no wireless connection between the source and the target) is used in call flow 1700 as a backup to replace the secure tunnel that is unavailable due to the lack of a communication connection between the source and the target.

[0157] In step 1702, the user can select the plan to be delivered on source 1102 or destination 1106. For the purposes of call flow 1400, the user can select source 1102 as the source device and destination 1106 as the destination device, but this is only an example. After step 1702, two alternative options are presented depending on whether source 1102 or destination 1106 is used to display the QR code.

[0158] In the first alternative, source 1102 displays a QR code (or a functionally equivalent) format. In 1706, OS 1105 of source 1102 displays the ICCID and / or carrier identifier in QR code format on the display of source 1102. In 1708, target 1106 uses a camera or other optical scanning device to scan the QR code.

[0159] In step 1710, target OS 1107 resolves the ICCID to identify the associated authorization server address. In step 1712, target OS 1107 communicates with the authorization server to retrieve eSIM delivery information. At step 1712, the user is prompted to authenticate the transaction on target 1106 (e.g., via PIN / password / biometrics).

[0160] In the second alternative, target 1106 displays a QR code (or a functionally equivalent) format. Following 1702, in 1714, target OS 1107 can display EID_t and IMEI_t in QR code format on the display of target 1106. In 1716, source OS 1105, based on source 1102, uses a camera or other optical scanning device to scan the QR code displayed on target 1106 to retrieve EID_t and IMEI_t.

[0161] In 1718, source OS 1105 retrieves the transfer token from the associated authorization server using the ICCID, EID_t, and IMEI_t. For example, see any of operations 418, 520, 620, 714, 768, or 822 described above.

[0162] In 1720, source OS 1105 uses the display of source 1102 to display the ICCID and delivery token in QR code format. In 1722, target OS 1106 scans the ICCID and delivery token displayed via the QR code. In 1724, target OS 1107 parses the scanned QR code ICCID to identify the associated authorization server address.

[0163] In 1726, the target OS 1107 revoks the delivery tokens from the authorization server and SM-DP+. For example, see any of operations 422, 524, 624, 720, 774, or 916 described above.

[0164] Figure 18 Example call flow 1800 for cross-platform eSIM profile transfer from a source with GSMA OS to a target with MSP OS, according to various example implementations, is shown. Call flow 1800 includes a target 1801 with a TS.43 stack 1802 and GSMA OS. Call flow 1800 also includes a source 1805 with MSP OS 1806. Finally, call flow 1800 also includes an MSP licensing server 1808.

[0165] In 1810, MSP OS 1806 performs setup operations for passing cellular-based eSIM profiles and displays a QR code containing the EID (e.g., IMEI).

[0166] In step 1812, the target 1801 scans the EID QR code using a camera or other optical scanning device controlled by GSMA OS 1804, triggering the cross-platform eSIM transfer process at GSMA OS 1804. In step 1814, GSMA OS 1804 sends a qualification check message to TS.43 stack 1802, including source and target device information. In step 1816, TS.43 stack 1802 performs a logical check with the operator's service support system (not shown) to determine whether eSIM profile transfer is permitted. In step 1818, if the check in step 1816 is successful, TS.43 stack 1802 sends an OK message to GSMA OS 1804, instructing the operator to allow eSIM transfer.

[0167] In step 1820, GSMA OS 1804 sends a request to TS.43 stack 1802 to obtain a temporary token, including the target EID. In step 1822, TS.43 stack 1802 contacts the operator to obtain a temporary token for eSIM profile delivery. In step 1824, when TS.43 stack 1802 successfully obtains the temporary token, it sends an OK message to GSMA OS 1804, including the temporary token.

[0168] In 1826, GSMA OS 1804 displays a QR code on the display of source 1801. This QR code includes a temporary token, a mobile country code (MCC), a mobile network code (MNC), a first group identifier (GID1), a GID2, and a mobile station international subscriber directory number (MSISDN).

[0169] In step 1828, target 1805, using a camera or other optical scanning device controlled by MSP OS 1806, scans the QR code generated in step 1826. In step 1830, MSP OS 1806 sends a getAuthentication message to MSP authorization server 1808, including a temporary token, a cross-platform indicator, and the target EID.

[0170] In step 1832, MSP Authorization Server 1808 verifies the temporary token against the target EID. In step 1834, MSP Authorization Server 1808 and MSP OS 1806 perform the getEntitlement:MSP operation. In step 1836, MSP Authorization Server 1808 and MSP OS 1806 perform the TransferAuthorization:TransferType operation.

[0171] In step 1838, MSP Authorization Server 1808 and MSP OS 1806 perform the TransferSIMService operation. In step 1840, MSP Authorization Server 1808 confirms that the BSS transfer has been completed between the source and the destination (e.g., GSMA OS 1804 and MSP OS 1806).

[0172] In 1842, the MSP licensing server 1808 sends the eSIM profile to the MSP OS 1806, which has the eSIM profile installed.

[0173] Example In a first embodiment, a method includes participating in an embedded user identity module (eSIM) profile transfer process to transfer an eSIM profile from a source device executing a first operating system (OS) to a target device executing a second OS, the first OS implementing a first protocol stack associated with the eSIM profile transfer, and the second OS implementing a second protocol stack associated with the eSIM profile transfer, wherein the first protocol stack and the second protocol stack are different; processing a token for transferring the eSIM profile based on signaling received from an authorization server; and generating a message including the token for sending to the target device.

[0174] In a second embodiment, according to the method of the first embodiment, the first protocol stack includes a standardized protocol stack, the second protocol stack includes a manufacturer-specific protocol (MSP) stack, and the token includes a temporary token generated by the standardized protocol stack of the authorization server, wherein the temporary token includes an expiration time.

[0175] In a third embodiment, according to the method of the first embodiment, the first protocol stack includes a manufacturer-specific protocol (MSP) stack, the second protocol stack includes a standardized protocol stack, and the token includes a delivery token generated by the MSP stack of the authorization server, wherein the delivery token includes an expiration time.

[0176] In the fourth embodiment, according to the method of the first embodiment, the method further includes establishing a secure tunnel via a wireless communication connection with the target device.

[0177] In a fifth embodiment, according to the method of the fourth embodiment, the method further includes processing a message including the International Mobile Equipment Identity (IMEI) of the target device, the Embedded Identity Document (EID) of the target device, and the platform type of the target device based on signaling received from the target device via the secure tunnel, wherein the platform type corresponds to the second OS; determining a server random number associated with the authorization server; calculating a binary large object including the server random number; signing the binary large object to create a signed binary large object; and generating a request for the token including the signed binary large object for sending to the authorization server.

[0178] In a sixth embodiment, according to the method of the fifth embodiment, the processing circuitry is configured to hash the authentication token received from the authorization server to determine the server random number.

[0179] In the seventh embodiment, according to the method of the fifth embodiment, the processing circuit is configured to retrieve the server random number from the authorization server using an application programming interface (API) to determine the server random number.

[0180] In the eighth embodiment, according to the method of the fifth embodiment, the binary large object further includes (i) the IMEI of the target device, (ii) the EID of the target device, (iii) the platform type of the target device, (iv) the IMEI of the source device, (v) the EID of the source device, (vi) the platform type of the source device and (vii) a user intent level, the user intent level including an authentication level for transmitting the eSIM profile.

[0181] In the ninth embodiment, according to the method of the eighth embodiment, the signing of the binary large object is permitted when user authentication performed by the source device is successful, wherein the user authentication includes biometric input by the user or password input by the user.

[0182] In the tenth embodiment, according to the method of the fifth embodiment, the binary large object further includes an integrated circuit card identification code (ICCID) of the eSIM profile, wherein the binary large object is allowed to be signed by the eUICC when the embedded universal integrated circuit card (eUICC) of the source device verifies that the eSIM profile with the ICCID is installed on the eUICC.

[0183] In the eleventh embodiment, according to the method of the fifth embodiment, the token includes an indication of the platform type of the source device.

[0184] In the twelfth embodiment, according to the method of the fifth embodiment, the method further includes processing a request for further authentication of the source device based on signaling received from the authorization server, wherein the request includes a Uniform Resource Locator (URL) for the source device to access for the further authentication.

[0185] In the thirteenth embodiment, according to the method of the fifth embodiment, the token includes a representation of the EID of the target device.

[0186] In the fourteenth embodiment, according to the method of the fourth embodiment, the processing circuit executes a third-party application to perform at least some operations of the eSIM profile transfer process.

[0187] In the fifteenth embodiment, according to the method of the fourteenth embodiment, the method further includes: performing a discovery process with the target device via the third-party application before establishing the secure tunnel to determine whether the eSIM profile transfer process will be performed with the target device; and having the third-party application process a setup start message from the target device including the target device's target public key.

[0188] In the sixteenth embodiment, according to the method of the fifteenth embodiment, the discovery process is performed via a short-range communication connection or by scanning an optical code.

[0189] In the seventeenth embodiment, according to the method of the fifteenth embodiment, the discovery process includes: configuring transceiver circuitry to scan for announcements from the target device, wherein the announcements include beacons; or configuring transceiver circuitry to transmit the announcements including the beacons.

[0190] In the eighteenth embodiment, according to the method of the seventeenth embodiment, the beacon includes: a length field indicating the length of the beacon, a tag field including a beacon indicator, a version field indicating the protocol version of the first protocol stack or the second protocol stack; a device type field indicating the type of the source device or the target device; a platform field indicating the identity of the first OS or the second OS, or a role field indicating the role that the source device or the target device will perform during the eSIM transfer process.

[0191] In the nineteenth embodiment, according to the method of the fifteenth embodiment, the method further includes: using the third-party application to generate a source public key and a source private key pair; using the third-party application to process user input including a personal identification number (PIN) associated with the target device; using the third-party application to generate a session key including a hash of the PIN and the source public key; generating a setup verification message including the session key by the third-party application for sending to the target device; and using the third-party application to process encrypted information from the target device for establishing the secure tunnel.

[0192] In the twentieth embodiment, according to the method of the fifteenth embodiment, the method further includes: using the third-party application to process user input including a personal identification number (PIN) associated with the target device; using the third-party application to generate a symmetric key; generating a setup verification message by the third-party application including the PIN and the symmetric key encrypted using the target public key for sending to the target device; and using the third-party application to process encrypted information from the target device for establishing the secure tunnel.

[0193] In the twenty-first embodiment, according to the method of the fourteenth embodiment, the method further includes the third-party application retrieving phone numbers and other data associated with the eSIM profile from the first OS.

[0194] In the twenty-second embodiment, according to the method of the twenty-first embodiment, the method further includes using the third-party application to process user input, the user input including selection of a subset of the phone number and other data to be migrated to the target device during the eSIM transfer process.

[0195] In the twenty-third embodiment, according to the method of the twenty-first embodiment, the method further includes: using the third-party application to generate the phone number and other data associated with the eSIM profile for sending to the target device; and using the third-party application to process selections from the target device, the selections including a subset of the phone number and other data to be migrated to the target device during the eSIM transfer process.

[0196] In the 24th embodiment, according to the method of the 14th embodiment, the method further includes: transmitting a Token Transfer Request Application Programming Interface (API) from the third-party application to the first OS, the Token Transfer Request API including the Integrated Circuit Card Identifier (ICCID) of the eSIM profile, the International Mobile Equipment Identity (IMEI) of the target device, and the Embedded Identity Document (EID) of the target device, wherein the first OS uses the Token Transfer Request API to request the token from the authorization server; processing the token by the third-party application based on signaling received from the first OS, wherein the third-party application configures the transceiver circuitry to send the token to the target device; processing a transfer completion message from the target device indicating that the eSIM profile has been successfully transferred to the target device; transmitting the transfer completion message to the first OS by the third-party application; and processing a confirmation message by the third-party application based on signaling received from the first OS, the confirmation message indicating that the operation related to the eSIM transfer process performed by the first OS has been completed.

[0197] In the 25th embodiment, according to the method of the 14th embodiment, the method further includes: transmitting an eSIM delivery request application programming interface (API) from the third-party application to the first OS, the eSIM delivery request API including the integrated circuit card identification code (ICCID) of the eSIM profile, the International Mobile Equipment Identity (IMEI) of the target device, the Embedded Identity Document (EID) of the target device, and information for establishing a short-range connection with the target device, wherein the first OS uses the eSIM delivery request API to request the token from the authorization server; the first OS uses the information to establish the short-range connection with the target device, wherein the first OS configures the transceiver circuitry to send the token to the target device via the short-range connection; the first OS processes a delivery completion message based on signaling received from the target device, the delivery completion message indicating that the eSIM profile has been successfully delivered to the target device; the first OS performs operations related to completing the eSIM delivery process; and the first OS transmits a confirmation message to the third-party application, the confirmation message indicating that the operations related to completing the eSIM delivery process have been completed.

[0198] In the twenty-sixth embodiment, according to the method of the fourth embodiment, the first OS performs the operation of the eSIM profile transfer process.

[0199] In the twenty-seventh embodiment, according to the method of the twenty-sixth embodiment, the method further includes: performing a discovery process with the target device before establishing the secure tunnel to determine that the eSIM profile transfer process will be performed with the target device; and processing a setup start message including the target device's target private key based on signaling received from the target device.

[0200] In the twenty-eighth embodiment, according to the method of the twenty-seventh embodiment, the discovery process is performed via a short-range communication connection or by scanning an optical code.

[0201] In the twenty-ninth embodiment, according to the method of the twenty-seventh embodiment, the discovery process includes: configuring transceiver circuitry to scan for announcements from the target device, wherein the announcements include beacons; or configuring transceiver circuitry to transmit the announcements including the beacons.

[0202] In the thirtieth embodiment, according to the method of the twenty-ninth embodiment, the beacon includes: a length field indicating the length of the beacon; a tag field including a beacon indicator; a version field indicating the protocol version of the first protocol stack or the second protocol stack; a device type field indicating the type of the source device or the target device; a platform field indicating the identity of the first OS or the second OS; or a role field indicating the role that the source device or the target device will perform during the eSIM transfer process.

[0203] In the thirty-first embodiment, according to the method of the twenty-seventh embodiment, the method further includes: generating a source public key and a source private key pair; processing user input including a personal identification number (PIN) associated with the target device; generating a session key including a hash of the PIN and the source public key; generating a setup verification message including the session key for sending to the target device; and processing encrypted information to be used to establish the secure tunnel based on signaling received from the target device.

[0204] In the thirty-second embodiment, according to the method of the twenty-seventh embodiment, the method further includes: processing user input including a personal identification number (PIN) associated with the target device; generating a symmetric key; generating a setup verification message including the PIN and the symmetric key encrypted using the target public key for sending to the target device; and processing encrypted information to be used to establish the secure tunnel based on signaling received from the target device.

[0205] In the thirty-third embodiment, according to the method of the twenty-sixth embodiment, the method further includes processing user input, the user input including selection of a phone number and other data to be migrated to the target device during the eSIM transfer process.

[0206] In the thirty-fourth embodiment, according to the method of the twenty-sixth embodiment, the method further includes: generating a telephone number and other data associated with the eSIM profile for transmission to the target device; and processing the selection of a subset including the telephone number and other data to be migrated to the target device during the eSIM transfer process based on signaling received from the target device.

[0207] In the thirty-fifth embodiment, according to the method of the twenty-sixth embodiment, the method further includes: using the information to establish a short-range connection with the target device, wherein the first OS configures the transceiver circuitry to send the token to the target device via the short-range connection; processing a delivery completion message indicating that the eSIM profile has been successfully delivered to the target device based on signaling received from the target device; and performing operations related to completing the eSIM delivery process.

[0208] In the thirty-sixth embodiment, according to the method of the first embodiment, a third-party application performs at least some operations of the eSIM profile transfer process, wherein the method further includes: using the third-party application to process user input including selection of the eSIM profile to be transferred to the target device; and using the third-party application to configure the display of the source device to display an optical code, the optical code including an indication of an integrated circuit card identification code (ICCID) of the eSIM profile, an operator identifier of the eSIM profile, or the token.

[0209] In the thirty-seventh embodiment, according to the method of the first embodiment, a third-party application performs at least some operations of the eSIM profile transfer process, wherein the method further includes: using the third-party application to configure the optical scanning component of the source device to scan a first optical code displayed by the target device, the first optical code including the International Mobile Equipment Identity (IMEI) of the target device and the Embedded Identity Document (EID) of the target device; transmitting a Token Transfer Request Application Programming Interface (API) from the third-party application to the first OS, the Token Transfer Request API including the Integrated Circuit Card Identifier (ICCID) of the eSIM profile, the IMEI of the target device, and the EID of the target device, wherein the first OS uses the Token Transfer Request API to request the token from the authorization server; and using the first OS to configure the display of the source device to display a second optical code, the second optical code including an indication of the ICCID of the eSIM profile and the token.

[0210] In the thirty-eighth embodiment, according to the method of the first embodiment, wherein the first OS performs the operation of the eSIM profile transfer process, wherein the method further includes: processing user input including selection of the eSIM profile to be transferred to the target device; and configuring the display of the source device to display an optical code, the optical code including an indication of an integrated circuit card identification code (ICCID) of the eSIM profile, an operator identifier of the eSIM profile, or the token.

[0211] In the thirty-ninth embodiment, according to the method of the first embodiment, wherein the first OS performs the operation of the eSIM profile transfer process, wherein the method further includes: configuring the optical scanning component of the source device to scan a first optical code displayed by the target device, the first optical code including the International Mobile Equipment Identity (IMEI) of the target device and the Embedded Identity Document (EID) of the target device, wherein the source device uses the IMEI and the EID of the target device to request the token from the authorization server; and configuring the display of the source device to display a second optical code, the second optical code including an indication of the Integrated Circuit Card Identifier (ICCID) of the eSIM profile and the token.

[0212] In the fortieth embodiment, a processor is configured to perform any one of the methods described according to the first to the thirty-ninth embodiments.

[0213] In the forty-first embodiment, a user equipment (UE) is configured to perform any one of the methods described according to the first to the thirty-ninth embodiments.

[0214] Those skilled in the art will understand that the example embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Example hardware platforms for implementing the example embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Example embodiments of the methods described above may be embodied as programs containing lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0215] Although this application describes various embodiments that have different features in various combinations, those skilled in the art will understand that any feature of one embodiment can be combined with features of other embodiments in any way that is not expressly denied or that is not functionally or logically inconsistent with the operation of the device or the specified function of the disclosed embodiment.

[0216] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0217] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover modifications and variations thereof, provided they fall within the scope of the appended claims and their equivalents.

Claims

1. An apparatus comprising a processing circuit configured to: The device participates in the embedded user identity module (eSIM) profile transfer process to transfer the eSIM profile from a source device running a first operating system (OS) to a target device running a second OS. The first operating system (OS) implements a first protocol stack related to the eSIM profile transfer, and the second OS implements a second protocol stack related to the eSIM profile transfer, wherein the first protocol stack and the second protocol stack are different. The token used to transmit the eSIM profile is processed based on signaling received from the authorization server; and Generate a message including the token for sending to the target device.

2. The apparatus of claim 1, wherein the first protocol stack includes a standardized protocol stack, the second protocol stack includes a manufacturer-specific protocol (MSP) stack, and the token includes a temporary token generated by the standardized protocol stack of the authorization server, wherein the temporary token includes an expiration time.

3. The apparatus of claim 1, wherein the first protocol stack includes a manufacturer-specific protocol (MSP) stack, the second protocol stack includes a standardized protocol stack, and the token includes a delivery token generated by the MSP stack of the authorization server, wherein the delivery token includes an expiration time.

4. The apparatus of claim 1, wherein the processing circuit is further configured to: A secure tunnel is established via a wireless communication connection with the target device.

5. The apparatus of claim 4, wherein the processing circuit is further configured to: The message, including the International Mobile Equipment Identity (IMEI) of the target device, the Embedded Identity Document (EID) of the target device, and the platform type of the target device, is processed based on the signaling received from the target device via the secure tunnel, wherein the platform type corresponds to the second OS; Determine a random number for the server associated with the authorization server; Calculate a binary large object that includes the server's random numbers; Sign the binary large object to create a signed binary large object; and A request is generated for the token, which includes the signed binary object, to be sent to the authorization server.

6. The apparatus of claim 5, wherein the processing circuitry is configured to hash the authentication token received from the authorization server to determine the server random number.

7. The apparatus of claim 5, wherein the processing circuitry is configured to retrieve the server random number from the authorization server using an application programming interface (API) to determine the server random number.

8. The apparatus of claim 5, wherein the binary large object further comprises (i) the IMEI of the target device, (ii) the EID of the target device, (iii) the platform type of the target device, (iv) the IMEI of the source device, (v) the EID of the source device, (vi) the platform type of the source device and (vii) a user intent level, the user intent level including an authentication level for transmitting the eSIM profile.

9. The apparatus of claim 8, wherein signing of the binary large object is permitted when user authentication performed by the source device is successful, wherein the user authentication includes biometric input by the user or password input by the user.

10. The apparatus of claim 5, wherein the binary large object further includes an integrated circuit card identifier (ICCID) of the eSIM profile, wherein the binary large object is allowed to be signed by the eUICC when the embedded universal integrated circuit card (eUICC) of the source device verifies that the eSIM profile having the ICCID is installed on the eUICC.

11. The apparatus of claim 5, wherein the token includes an indication of the platform type of the source device.

12. The apparatus of claim 5, wherein the processing circuit is further configured to: The request for further authentication of the source device is processed based on signaling received from the authorization server, wherein the request includes a Uniform Resource Locator (URL) for the source device to access for the further authentication.

13. The apparatus of claim 5, wherein the token comprises a representation of the EID of the target device.

14. The apparatus of claim 4, wherein the processing circuitry executes a third-party application to perform at least some operations of the eSIM profile transfer process.

15. The apparatus of claim 14, wherein the processing circuitry is further configured to: Before establishing the secure tunnel, a discovery process is performed between the third-party application and the target device to determine whether the eSIM profile transfer process will be performed with the target device; and The third-party application processes the setup start message from the target device, which includes the target public key of the target device.

16. The apparatus of claim 15, wherein the discovery process is performed via a short-range communication connection or by scanning an optical code.

17. The apparatus of claim 15, wherein the discovery process includes the processing circuitry configured to: The transceiver circuitry is configured to scan for announcements from the target device, wherein the announcements include beacons; or The transceiver circuitry is configured to transmit the announcement including the beacon.

18. The apparatus of claim 17, wherein the beacon comprises: The system includes a length field indicating the length of the beacon, a tag field including a beacon indicator, a version field indicating the protocol version of the first protocol stack or the second protocol stack, a device type field indicating the type of the source device or the target device, a platform field indicating the identity of the first OS or the second OS, or a role field indicating the role that the source device or the target device will perform during the eSIM transfer process.

19. The apparatus of claim 15, wherein the processing circuitry is further configured to: Use the third-party application to generate the source public key and source private key pair; The third-party application is used to process user input, including a personal identification number (PIN) associated with the target device. Use the third-party application to generate a session key that includes a hash of the PIN and the source public key; The third-party application generates a setup verification message including the session key for sending to the target device; and The third-party application is used to process encrypted information from the target device for establishing the secure tunnel.

20. The apparatus of claim 15, wherein the processing circuit is further configured to: The third-party application is used to process user input, including a personal identification number (PIN) associated with the target device. Use the third-party application to generate the symmetric key; The third-party application generates a setup verification message including the PIN and the symmetric key encrypted using the target public key for transmission to the target device; and The third-party application is used to process encrypted information from the target device for establishing the secure tunnel.

21. The apparatus of claim 14, wherein the processing circuit is further configured to: The third-party application retrieves phone numbers and other data associated with the eSIM profile from the first OS.

22. The apparatus of claim 21, wherein the processing circuit is further configured to: The third-party application is used to process user input, which includes the selection of a subset of the phone number and other data to be migrated to the target device during the eSIM transfer process.

23. The apparatus of claim 21, wherein the processing circuitry is further configured to: The third-party application is used to generate the phone number and other data associated with the eSIM profile for transmission to the target device; and The third-party application is used to process selections from the target device, including a subset of the phone number and other data to be migrated to the target device during the eSIM transfer process.

24. The apparatus of claim 14, wherein the processing circuit is further configured to: The first OS transmits a Token Request Application Programming Interface (API) from the third-party application to the first OS. The Token Request API includes the Integrated Circuit Card Identifier (ICCID) of the eSIM profile, the International Mobile Equipment Identity (IMEI) of the target device, and the Embedded Identity Document (EID) of the target device. The first OS uses the Token Request API to request the token from the authorization server. The token is processed by the third-party application based on signaling received from the first OS, wherein the third-party application configures the transceiver circuitry to send the token to the target device; The third-party application is used to process a delivery completion message from the target device indicating that the eSIM profile has been successfully delivered to the target device. The third-party application transmits the delivery completion message to the first OS; and The third-party application processes the confirmation message based on signaling received from the first OS, the confirmation message indicating that the operation related to the eSIM delivery process performed by the first OS has been completed.

25. The apparatus of claim 14, wherein the processing circuit is further configured to: The third-party application transmits an eSIM delivery request application programming interface (API) to the first OS. The eSIM delivery request application programming interface (API) includes the integrated circuit card identification code (ICCID) of the eSIM profile, the International Mobile Equipment Identity (IMEI) of the target device, the Embedded Identity Document (EID) of the target device, and information for establishing a short-range connection with the target device. The first OS uses the eSIM delivery request API to request the token from the authorization server. The first OS uses the information to establish the short-range connection with the target device, wherein the first OS configures the transceiver circuitry to send the token to the target device via the short-range connection; The first OS processes a delivery completion message based on signaling received from the target device, the delivery completion message indicating that the eSIM profile has been successfully delivered to the target device; The first OS performs operations related to completing the eSIM transfer process; and The first OS sends a confirmation message to the third-party application, the confirmation message indicating that the operation related to completing the eSIM transfer process has been completed.

26. The apparatus of claim 4, wherein the processing circuitry of the source device executes the first OS to perform the operation of the eSIM profile transfer process.

27. The apparatus of claim 26, wherein the processing circuitry is further configured to: Before establishing the secure tunnel, a discovery process is performed with the target device to determine whether the eSIM profile transfer process will be performed with the target device; and The setup start message, including the target private key of the target device, is processed based on the signaling received from the target device.

28. The apparatus of claim 27, wherein the discovery process is performed via a short-range communication connection or by scanning an optical code.

29. The apparatus of claim 27, wherein the discovery process includes the processing circuitry configured to: The transceiver circuitry is configured to scan for announcements from the target device, wherein the announcements include beacons; or The transceiver circuitry is configured to transmit the announcement including the beacon.

30. The apparatus of claim 29, wherein the beacon comprises: The system includes a length field indicating the length of the beacon, a tag field including a beacon indicator, a version field indicating the protocol version of the first protocol stack or the second protocol stack, a device type field indicating the type of the source device or the target device, a platform field indicating the identity of the first OS or the second OS, or a role field indicating the role that the source device or the target device will perform during the eSIM transfer process.

31. The apparatus of claim 27, wherein the processing circuit is further configured to: Generate a source public key and a source private key pair; Processing includes user input including a personal identification number (PIN) associated with the target device; Generate a session key that includes a hash of the PIN and the source public key; Generate a setup verification message including the session key for sending to the target device; and The encrypted information to be used to establish the secure tunnel is processed based on the signaling received from the target device.

32. The apparatus of claim 27, wherein the processing circuit is further configured to: Processing includes user input including a personal identification number (PIN) associated with the target device; Generate a symmetric key; Generate a setup verification message including the PIN and the symmetric key encrypted using the target public key for sending to the target device; The encrypted information to be used to establish the secure tunnel is processed based on the signaling received from the target device.

33. The apparatus of claim 26, wherein the processing circuit is further configured to: Processing user input, which includes selections of phone numbers and other data to be migrated to the target device during the eSIM transfer process.

34. The apparatus of claim 26, wherein the processing circuitry is further configured to: Generate a phone number and other data associated with the eSIM profile for transmission to the target device; and The selection of a subset of data, including the phone number and other data, to be migrated to the target device during the eSIM transfer process is processed based on signaling received from the target device.

35. The apparatus of claim 26, wherein the processing circuitry is further configured to: The information is used to establish a short-range connection with the target device, wherein the first OS configures the transceiver circuitry to send the token to the target device via the short-range connection; The signaling received from the target device is used to process a delivery completion message indicating that the eSIM profile has been successfully delivered to the target device; and Perform operations related to completing the eSIM transfer process.

36. The apparatus of claim 1, wherein the processing circuitry of the source device executes a third-party application to perform at least some operations of the eSIM profile transfer process, wherein the processing circuitry is further configured to: The third-party application is used to process user input, including selection of the eSIM profile to be passed to the target device; and The third-party application is used to configure the display of the source device to display an optical code, which includes an indication of the integrated circuit card identification code (ICCID) of the eSIM profile, the operator identifier of the eSIM profile, or the token.

37. The apparatus of claim 1, wherein the processing circuitry of the source device executes a third-party application to perform at least some operations of the eSIM profile transfer process, wherein the processing circuitry is further configured to: The third-party application is used to configure the optical scanning component of the source device to scan a first optical code displayed by the target device, the first optical code including the target device's International Mobile Equipment Identity (IMEI) and the target device's Embedded Identity Document (EID). The first OS transmits a Token Request Application Programming Interface (API) from the third-party application to the first OS. The Token Request API includes the Integrated Circuit Card Identifier (ICCID) of the eSIM profile, the IMEI of the target device, and the EID of the target device. The first OS uses the Token Request API to request the token from the authorization server. The first OS is used to configure the display of the source device to display a second optical code, the second optical code including an indication of the ICCID of the eSIM profile and the token.

38. The apparatus of claim 1, wherein the processing circuitry of the source device executes the first OS to perform the eSIM profile transfer process, wherein the processing circuitry is further configured to: The process includes user input regarding the selection of the eSIM profile to be passed to the target device; and The display of the source device is configured to display an optical code, which includes an indication of the integrated circuit card identification code (ICCID) of the eSIM profile, the operator identifier of the eSIM profile, or the token.

39. The apparatus of claim 1, wherein the processing circuitry of the source device executes the first OS to perform the eSIM profile transfer procedure, wherein the processing circuitry is further configured to: The optical scanning component of the source device is configured to scan a first optical code displayed by the target device, the first optical code including the International Mobile Equipment Identity (IMEI) and the Embedded Identity Document (EID) of the target device, wherein the source device uses the IMEI and EID of the target device to request the token from the authorization server; and The display of the source device is configured to display a second optical code, which includes an indication of the integrated circuit card identification code (ICCID) of the eSIM profile and the token.

Images