Token based ESIM transfer

Abstract

A user equipment (UE) is described, including as a source or target device. A UE, or processor thereof, can perform initiating a device change procedure from the source that uses a cellular carrier to the target that uses the cellular carrier. The target UE can receive, from a cloud-based service for a user of the target, a symmetric key associated with a transfer token for an embedded subscriber identity module (eSIM) of the user. The target UE can receive, from a subscription manager, a ciphered transfer token for the eSIM, and decrypt the ciphered transfer token using the symmetric key to obtain the transfer token. The target UE can receive, in response to providing the transfer token to the cellular carrier, profile information for the eSIM and configure, according to the profile information, the target UE to communicate with the cellular carrier using the eSIM.

Description

TOKEN BASED ESIM TRANSFERCROSS-REFERENCE TO RELATED APPLICATION

[0001] This Patent Cooperation Treaty patent application claims priority to U.S. Provisional Patent Application No. 63 / 620,091, filed January 11, 2024, and titled “Cloud-Based Device Change Tokens,” the contents of which are incorporated herein by reference as if fully disclosed herein in its entirety.TECHNICAL FIELD

[0002] This application relates generally to wireless communication systems, including systems, apparatuses, and methods for cloud-based device change tokens.BACKGROUND

[0003] Wireless mobile communication technology uses various standards and protocols to transmit data between a network device (e.g., a base station, a radio head, etc.) and a wireless communication device. Wireless communication system standards and protocols can include, for example, 3rd Generation Partnership Project (3GPP) long term evolution (LTE) (e.g., 4G), 3GPP new radio (NR) (e.g., 5G), and IEEE 802.11 standard for wireless local area networks (WLAN) (commonly known to industry groups as Wi-Fi®).

[0004] As contemplated by the 3GPP, different wireless communication systems standards and protocols can use various radio access networks (RANs) for communicating between a network device of the RAN (which may also sometimes be referred to generally as a RAN node, a network node, or simply a node) and a wireless communication device known as a UE. 3GPP RANs can include, for example, global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and / or Next-Generation Radio Access Network (NG-RAN).

[0005] Each RAN may use one or more radio access technologies (RATs) to perform communication between the network device and the UE. For example, the GERAN implements GSM and / or EDGE RAT, the UTRAN implements universal mobile telecommunication system (UMTS) RAT or other 3GPP RAT, the E-UTRAN implements LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements NR RAT (sometimes referred to herein as 5G RAT,5G NR RAT, or simply NR). In certain deployments, the E-UTRAN may also implement NR RAT. In certain deployments, NG-RAN may also implement LTE RAT.

[0006] A network device used by a RAN may correspond to that RAN. One example of an E- UTRAN network device is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB). One example of an NG-RAN network device is a next generation Node B (also sometimes referred to as a g Node B or gNB).

[0007] A RAN provides its communication services with external entities through its connection to a core network (CN). For example, E-UTRAN may utilize an Evolved Packet Core (EPC), while NG-RAN may utilize a 5G Core Network (5GC).BRIEF DESCRIPTION OF THE DRAWINGS

[0008] To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0009] FIG. 1 shows an example wireless communication system, according to embodiments described herein.

[0010] FIG. 2 shows an example device change procedure, according to one or more aspects described herein.

[0011] FIG. 3 shows an example signaling flow, according to one or more aspects described herein.

[0012] FIG. 4 shows an example signaling flow, according to one or more aspects described herein.

[0013] FIG. 5 shows an example signaling flow, according to one or more aspects described herein.

[0014] FIG. 6 shows an example signaling flow, according to one or more aspects described herein.

[0015] FIG. 7 shows an example signaling flow, according to one or more aspects described herein.

[0016] FIG. 8 shows an example signaling flow, according to one or more aspects described herein.

[0017] FIG. 9 shows an example method of wireless communication by a UE, according to one or more aspects described herein.

[0018] FIG. 10 shows an example method of wireless communication by a UE, according to one or more aspects described herein.

[0019] FIG. 11 illustrates an example architecture of a wireless communication system, according to embodiments described herein.

[0020] FIG. 12 illustrates an example system for performing signaling between a wireless device and a network device, according to embodiments described herein.DETAILED DESCRIPTION

[0021] Various embodiments are described with regard to a user equipment (UE). However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with a network. Therefore, the UE as described herein is used to represent any appropriate electronic device.

[0022] A UE or other mobile device may use a subscriber identity module (SIM) card to store information about a user of the UE. Rather than a physical card to be changed out or installed for different deployments, an eSIM (embedded SIM) may be embedded directly into a UE, such as a smartphone or Internet of Things (loT) device, rather than being a physical, removable card. The term eSIM, as used herein, refers generally to remote SIM provisioning according to the Global System for Mobile Communications Association (GSMA). The eSIM is designed in part to replace traditional physical SIM cards. One advantage of eSIM technology is flexibility, as eSIM technology allows users to remotely provision and manage the user’s mobile subscriptions without the need for a physical SIM card swap.

[0023] Many mobile wireless devices are configured to use removable Universal Integrated Circuit Cards (UICCs) that enable the mobile wireless devices to access services provided by Mobile Network Operators (MNOs). In particular, each UICC includes at least a microprocessor and a read-only memory (ROM), where the ROM is configured to store an MNO profile that the wireless device can use to register and interact with an MNO to obtain wireless services via a cellular wireless network. A profile may also be referred to as SIM. Typically, a UICC takes the form of a small removable card, commonly referred to as a SIM card, which is inserted into a UICC -receiving bay of a mobile wireless device. In more recent implementations, UICCs are being embedded directly into system boards of wireless devices as embedded UICCs (eUICCs), which can provide advantages over traditional, removable UICCs. The eUICCs can include a rewritable memory that can facilitate installation, modification, and / or deletion of one or more electronic SIMs (eSIMs) on the eUICC, where the eSIMs can provide for new and / or different services and / or updates for accessing extended features provided by MNOs. An eUICC can store a number of MNO profiles — also referred to herein as eSIMs — and can eliminate the need to include UICC-receiving bays in wireless devices. Applets associated with eSIMs can also be installed on the eUICC from CAP files provided in a bound profile package (BPP) received from a provisioning server. An eUICC may allow customers and equipment manufactures to more easilyand conveniently provision a SIM with a new operator profile, for example by provisioning a new operator profile over the air.

[0024] An eUICC incorporates both the functionality of a traditional SIM card and an additional layer of programmability for managing multiple mobile subscriptions. An eUICC may be a removable or a non-removable UICC, and enables the remote and / or local management of profiles in a secure way. An eUICC may have multiple “eSIM profiles,” which may also be referred to herein as simply a “SIM” or “profile.”

[0025] A user of a device (e.g., a UE, such as a mobile device) may decide to change that device to a new device. In some systems, where the source device uses an eSIM and the devices are to be used with a same cellular carrier (e.g., a same cellular network operator), a transfer token may be generated from the source device, and then provided to the target device during the device change (e.g., during authorization and / or initialization portions of the device change flow). For example, the transfer token may be sent from the source device to the target device using a short-range wireless communication standard (e.g., Bluetooth®). Such transfer token identifies security information association with the source device and eSIM, allowing a user to provide the transfer token to the cellular carrier from the target device. Having received and determined that the token is valid, the cellular carrier then provides an eSIM to the target device, thus allowing transfer of the eSIM from the source device to the target device. However, such procedures use a present source device, for example according to a procedure of the Global System for Mobile Communications Association (GSM A) in the TS.43 specification. As such, if the source device is lost, stolen, or broken, the device change token cannot be generated or retrieved, and an offline process with the cellular carrier may be required to obtain the eSIM for the target device.

[0026] As further discussed herein, a transfer token escrow and retrieval process allows for the presentation of a transfer token to obtain an eSIM for a target device, even where the source device is no longer present. In some cases, cloud-based services may be used and a source device authorized (e.g., pre-authorized) at the time of the setup and eSIM installation at the source device. For example, during the first provisioning for the source device the transfer token may be generated (e.g., issued). The transfer token may then have multiple layers of protection applied, for example including one or more of using the device passcode from the user, the cloud account key bag of the user (e.g., on a cloud-based service), or providing the transfer token to a server trusted by the cellular carrier for escrow (e.g., a subscription manager, such as a subscription manager data preparation (SM-DP+) server). The transfer token itself may be ciphered and secured with multiple layers of security. For example, a first portion of the token can be stored in the keybag (e.g., at the cloud-based service), and a second portion of the token can be stored at the server truest by the cellular carrier (e.g., the subscription manager, or an entitlement server).

[0027] In one or more embodiments, the transfer token is ciphered with a random (e.g., pseudo- randomly generated) symmetric key. The symmetric key is ciphered with a unique key-pair (e.g., public-key private-key pair), and the pair is protected by the user’s cloud credentials and user’s device passcode in the cloud key bag. The ciphered token is stored in the subscription manager server or entitlement server, and the ciphered key-pair is stored in the user’s cloud (e.g., at the cloud-based service.

[0028] •On the target device, the user is able to perform the device change by “unlocking” the transfer token (e.g., the pre-authorization token) stored in the subscription manager server or entitlement, using the passcode in addition to the user’s cloud account key (e.g., a user’s password and personal identification number (PIN) for the source device), which protected the key when the key was escrowed.

[0029] FIG. 1 shows an example wireless communications system 100, according to one or more aspects described herein. In one or more embodiments, wireless communications system 100, supports one or more aspects of cloud-based device change tokens, as further described herein.

[0030] Wireless communications system 100 includes a source device 102 and a target device 104, each or both of which may be UEs, as further described herein. The source device 102 and the target device 104 are connected (e.g., via one or more wired or wireless access devices) to a cloud-based sendee 106. The source device 102 and the target device 104 are capable of operating in a network operated by a cellular carrier 110, for example via a wireless connection to one or more network devices (e.g., base stations) that provide wireless connectivity for the source device 102 and the target device 104. The source device 102 and the target device 104 are connected to the cellular carrier 110, as well as a subscription manager 108 (e.g., a subscription manager data preparation (SM-DP+) device). The subscription manager 108 is in communication with the cellular carrier 110.

[0031] The described connections between devices of the wireless communications system 100 may not be concurrent, and different connections may exist at different times. For examples, during a first time duration, a user 116 may operate the source device 102, which communicates with the cloud-based service 106, the subscription manager 108, and cellular carrier 110 to perform various aspects and features described herein. During a second time duration, the user 116 may operate the target device 104, which communicates with the cloud-based service 106, the subscription manager 108, and cellular carrier 110, while source device 102 is unavailable to the user 116.

[0032] The cellular carrier 110 includes one or more additional components, further described herein, including an entitlement server 112 and a carrier business support subsystem (BSS) 114. In some embodiments, the subscription manager 108 may be a server trusted by the cellular carrier 110 (e.g., for escrow as further described herein), and be operated by a third-party or the operator of the cellular network itself. In other embodiments, the subscription manager 108 may be a part of the cellular carrier 110.

[0033] The source device 102, for example during a first time duration, may have an eSIM provisioned for the user 116, for example the eSIM installed at an eUICC 122 of the source device 102. At a later time (a second time duration), for example after the user 116 acquires the target device that the user 116 desires to operate in a cellular network of the cellular carrier 110, the target device 104 may have transferred to the target device 104, the eSIM, where the eSIM may be installed at an eUICC 124 of the target device 104. However, the source device 102 may be unavailable to the user 116. For example, the source device 102 may be lost, stolen, damaged, destroyed, powered off, or otherwise unavailable for communications with one or more of the cloud-based sendee 106, the subscription manager 108, or the cellular carrier 110. The procedures and features described herein, while providing (among other things) the advantage of allowing efficient eSIM transfer to the target device 104 when the source device 102 is unavailable, may also be used when the source device 102 is available, for example available to the user 116.

[0034] As further described herein, a source device 102 can perform an escrow procedure for a transfer token, for example, in connection with an eSIM provisioning procedure. The source device 102 can perform transmitting, from a source device 102 (e.g., a source UE), a request from a user 116 to activate the source device 102 with a cellular carrier 110. The source device 102 receives (e.g., from the cellular carrier 110), in response to the request, profile information for an eSIM and a transfer token for the eSIM. The source device 102 encrypts the transfer token using a symmetric key to generate a ciphered transfer token and transmits the symmetric key to a cloud-based service 106 for the user 116. The source device 102 transmits, to a subscription manager 108 associated with the cellular carrier 110, the ciphered transfer token and an installation receipt for the profile information.

[0035] A user may later acquire a new UE (e.g., target device 104) and perform a procedure to transfer to the eSIM from a previous UE (e.g., the source device 102) to retrieve the transfer token and perform a device change procedure. For example, a user may buy, receive, or otherwise obtain a new phone (e.g., the target device 104) and want to transfer data such as capabilities, settings, configurations, or other information from their old phone (e.g., the source device 102) to the new phone. The device change procedure may be performed by the user (e.g., including by the targetdevice, new UE, and / or or a processor of the device or UE) to transfer at least a portion of the data, and may provide the user with the opportunity to selectively transfer such data.

[0036] A target device 104 (e.g., a target UE, new UE, or a processor of the device or UE) can perform initiating a device change procedure from the source device 102 (e.g., a UE, source UE) that uses a cellular carrier 110 to the target device 104 that also uses the cellular carrier 110. The target device 104 can further receive, from the cloud-based service 106 for a user 116 of the target device 104, a symmetric key associated with a transfer token for an eSIM of the user 116. The target device 104 can receive, from a subscription manager 108 of the cellular carrier, a ciphered transfer token for the eSIM, and decrypt the ciphered transfer token using the symmetric key to obtain the transfer token. The target device 104 can receive, in response to providing the transfer token to the cellular carrier 110, profile information for the eSIM and configure, according to the profile information, the target device 104 to communicate with the cellular carrier 110 using the eSIM, for example to communicate with one or more network devices operated by the cellular carrier 110.

[0037] FIG. 2 shows an example device change procedure 200, according to one or more aspects described herein. In one or more embodiments, device change procedure 200, supports one or more aspects of cloud-based device change tokens, as further described herein.

[0038] The device change procedure 200 includes, among other aspects, at 202, preparing a transfer token for the UE, for example the source device 102 during an eSIM provisioning procedure.

[0039] At 204, the device change procedure 200 includes downloading, by the source device 102, the provisioned eSIM, including a transfer token associated with the eSIM. In some examples, transfer token generation may occur prior to provisioning the eSIM to the source device 102. In other examples, transfer token generation may occur after provisioning the eSIM to the source device 102. In still other examples, one or more steps of the transfer token generation may occur in parallel with (e.g., concurrent or otherwise overlapping) with one or more steps used for provisioning the eSIM to the source device 102, including while the eSIM is installed at the source device 102.

[0040] At 206, the device change procedure 200 includes escrowing the transfer token, for example by the source device 102 and at the subscription manager 108. The transfer token may be encrypted (e.g., ciphered) using a symmetric key.

[0041] At 208, the device change procedure 200 includes escrowing symmetric key used to encrypt the transfer token, for example in the cloud-based service 106 by the source device 102.

[0042] At 210, the device change procedure 200 includes initiating a device change 210. In some examples, initiating a device change 210 may occur after the source device 102 is operated in the cellular network of the cellular carrier 110, for example days, weeks, months, or even years later. In some examples, the target device 104 may initiate and continue the device change without any interaction with the source device 102 (e.g., the source device 102 is lost or broken).

[0043] At 212, the device change procedure 200 includes retrieving the symmetric key, for example, the target device 104 retrieving the symmetric key from the cloud-based service 106.

[0044] At 214, the device change procedure 200 includes retrieving a token blob for the escrowed transfer token, for example the target device 104 retrieving the token blob for the transfer token from the subscription manager 108.

[0045] At 216, the device change procedure 200 includes performing a transfer- token based device change, for example, the transfer token provided to the subscription manager 108 (e.g., or a server of the cellular carrier 110), the eSIM downloaded from the subscription manager 108 (e.g., or the other server), and provisioned to the target device 104.

[0046] Following device change procedure 200, the target device 104 may be configured operate to communicate in the cellular network of the cellular carrier 110.

[0047] FIG. 3 shows example signaling flow 300 of a device change procedure, according to one or more aspects described herein. In one or more embodiments, signaling flow 300, supports one or more aspects of cloud-based device change tokens, as further described herein. Signaling flow 300 includes communications between one or more the cloud-based service 106, the source device 102 (including an eUICC 122 of the source device 102), a subscription manager (e.g., an SM-DP+), an entitlement server 112 (e.g., of a cellular carrier 110), and a carrier BSS 114 (e.g., of a cellular carrier 110). In one or more embodiments, signaling flow 300 includes one or aspects of preparing a transfer token described at 202 of the device change procedure 200. Signaling flow 300 may include aspects related to eSIM provisioning.

[0048] In one or more embodiments, the state of the source device 102 prior to signaling flow 300 includes the source device 102 having a cloud certificate (e.g., for the cloud-based service 106) present on the eUICC 122.

[0049] At 302, a user account is created and / or updated at the carrier BSS 114. A confirmation 304 may be provided by the carrier BSS 114 to the subscription manager 108. In one or more embodiments, the confirmation 304 for the eSIM order may include a matching identifier for the eSIM, and a device an embedded identity document (EID), which may be a serial number or other identifier corresponding to the eSIM installed or to be installed on the source device 102. Thesubscription manager 108 may provide a confirmation, ACK 306, responding to the confirmation 304. The ACK 306 may include an identifier, such as an integrated circuit card ID (ICCID), which is a serial number that identifies an eSIM.

[0050] The carrier BSS 114 may then request 308 that the entitlement server 112 prepare a transfer token associated with the eSIM, the request 308 including the ICCID. The entitlement server 112 may then provide a confirmation, ACK 310, responding to the request 308.

[0051] Following signaling flow 300, a transfer token corresponding to the eSIM for the source device 102 may be available at the cellular carrier 110.

[0052] FIG. 4 shows an example signaling flow 400, according to one or more aspects described herein. In one or more embodiments, signaling flow 400, supports one or more aspects of cloudbased device change tokens, as further described herein. In one or more embodiments, signaling flow 400, supports one or more aspects of cloud-based device change tokens, as further described herein. Signaling flow 400 includes communications between one or more the cloud-based service 106, the source device 102 (including an eUICC 122 of the source device 102), a subscription manager (e.g., an SM-DP+), an entitlement server 112 (e.g., of a cellular carrier 110), and a carrier BSS 114 (e.g., of a cellular carrier 110). In one or more embodiments, signaling flow 400 includes one or aspects of downloading an eSIM with a transfer token as described at 204 of the device change procedure 200.

[0053] In one or more embodiments, the state of the source device 102 prior to signaling flow 400 includes the user having a passcode set on the source device 102 and the user (using the source device 102) is logged into the cloud-based service 106.

[0054] At 402, a user initiates (e.g., using or via source device 102) an eSIM download. The source device 102 provides an indication of the request to the eUICC 122 to initiate eSIM download 404. In response, at 406, eUICC 122 generates (creates) an eSIM download key pair. In some examples, the key pair may be a public -key private-key key pair (pK / sK), such as generated consistent with elliptic curve cryptography (ECC).

[0055] At 408, the eUICC 422 (e.g., via the source device 102) may perform a mutual authentication procedure with the subscription manager 108. A key exchange procedure (e.g., a Diffie-Hellman (DH) key exchange) may be performed to establish a shared key (e.g., session key) between the subscription manager and source device 102 (e.g., and specifically the eUICC 122).

[0056] The eUICC 122 sends arequest 410 to the source device 102 to get an eSIM. The request 410 may include the EID for the eSIM, as well as an eSIM download public key (pK) generatedat 406. The source device 102 may the provide a request 412, include the same EID and pK as the request 410. At least in part in response to the request 412, the subscription manager 108 encrypts (ciphers) the eSIM to generate a bound profile package (BPP). In some examples, the encryption of the BPP uses the shared key that is calculated according to the pK. In some examples, the calculation of the shared key uses the DH procedure.

[0057] At 416, the subscription manager 108 sends a request 416 to the entitlement server 112 for the transfer token. In some examples, the request 416 includes an ICCID for the eSIM, and the pK (e.g., the public key of the eUICC 122 for the eSIM download). At 418, the entitlement server encrypts the transfer token using the pK, and transmits the ciphered transfer token at 420 to the subscription manager 108. In one or more embodiments, the subscription manager 108 does not have access to or the ability access or read the transfer token, for example because the transfer token is not provided nor seen by the subscription manager 108 in a cleartext form.

[0058] At 422, the subscription manager 108 generates a new transfer token matching identifier, for example for later retrieval of the transfer token. At the 424, the subscription manager 108 provides the eSIM BPP, the ciphered transfer token, and the transfer token matching identifier to the source device 102, which are in turn provided to the eUICC 122 at 426.

[0059] Once provided with the eSIM BPP, the ciphered transfer token, and the transfer token matching identifier, at 428, the eUICC 122 may perform one or more tasks for token process and symmetric key generation. In some embodiments, the eUICC 122 may decipher the received transfer token using the eSIM download private key (sK), for example, without using DH. The eUICC 122 may then generate (create) a new symmetric key and use the symmetric key to encrypt (cipher) the transfer token. The eUICC 122 then installs the eSIM. The eSIM download publickey private-key (e.g., ECC key pair generated at 406) may be deleted (for example, consistent with a GSM A standard). The ciphered transfer token may be merged with the transfer token matching ID and with the installation receipt. Also at 428, the symmetric key (e.g., the symmetric key used to cipher the transfer token) is saved, for example at the eUICC 122. The transfer token matching ID may also be saved, for example, at the eUICC 122 or at the source device 102.

[0060] Although discussed in an order, one or more of the tasks may be performed in an order different than discussed. For example, the eSIM may be installed prior to or concurrent with generating the symmetric key and encrypting the transfer token with the symmetric key.

[0061] FIG. 5 shows an example signaling flow 500, according to one or more aspects described herein. In one or more embodiments, signaling flow 500, supports one or more aspects of cloudbased device change tokens, as further described herein. In one or more embodiments, signaling flow 500, supports one or more aspects of cloud-based device change tokens, as further describedherein. Signaling flow 500 includes communications between one or more the cloud-based service 106, the source device 102 (including an eUICC 122 of the source device 102), a subscription manager (e.g., an SM-DP+), an entitlement server 112 (e.g., of a cellular carrier 110), and a carrier BSS 114 (e.g., of a cellular carrier 110). In one or more embodiments, signaling flow 500 includes one or aspects of escrowing a transfer token described at 206 of the device change procedure 200.

[0062] The source device 102 provides a request 502 for an installation receipt from the eUICC 122. The eUICC 122 provides the installation receipt 504, which includes (in addition to other portions compliant with GSMA standards such as ICCID and eUICC signature) the ciphered transfer token and the transfer token matching ID (e.g., from 428). The source device 102 may then provide the installation receipt 506 to the subscription manager 108. The installation receipt 506 may include the ciphered transfer token (in addition to other portions).

[0063] At 508, the subscription manager 108 (e.g., or one or more other servers or devices trusted by the cellular carrier 110) escrows or otherwise stores the ciphered transfer token. In some examples, the subscription manager 108 indexes the ciphered transfer token by ICCID and / or transfer token matching ID that is associated with the corresponding eSIM. The subscription manager 108 provides an ACK 510 to the source device 102 at 510.

[0064] FIG. 6 shows an example signaling flow 600, according to one or more aspects described herein. In one or more embodiments, signaling flow 600, supports one or more aspects of cloudbased device change tokens, as further described herein. In one or more embodiments, signaling flow 600, supports one or more aspects of cloud-based device change tokens, as further described herein. Signaling flow 600 includes communications between one or more the cloud-based service 106, the source device 102 (including an eUICC 122 of the source device 102), a subscription manager (e.g., an SM-DP+), an entitlement server 112 (e.g., of a cellular carrier 110), and a carrier BSS 114 (e.g., of a cellular carrier 110). In one or more embodiments, signaling flow 600 includes one or aspects of escrowing a symmetric key at 208 of the device change procedure 200.

[0065] The source device 102 may already be logged into the cloud-based service 106. At 602, the source device 102 initiates an escrow process for the symmetric key used for the transfer token, for example the symmetric key used to cipher the transfer token at 428. At 604, the cloud-based service 106 creates a new public -key private-key pair (pK / sK) for the symmetric key escrow. In some examples, the public -key private-key pair may be generated consistent with ECC. At 606, the private key (sK) generated as part of the pair is then secured using the user’s cloud security. In some embodiments, this security is based on the user’s passcode. In other embodiments, the security is based on the user’s device PIN, for example the PIN the user has set for the source device 102. In still other embodiments, a combination of the passcode and device PIN may beused. The cloud-based service 106 then transmits the escrow public key (pK) of the pair is then transmitted to the source device 102, the transmission signed using the cloud certificate of the cloud-based service 106.

[0066] The source device 102 sends a request 610 to the eUICC 122 to get the transfer token symmetric key. The request 610 may include the public key (pK) for the escrow procedure provide at 608, the request 610 including the cloud signature. The eUICC 122 then verifies the cloud signature at 612, and encrypts (ciphers) the symmetric key with the escrow pK at 614. In some cases, DH may not be used to encrypt the symmetric key. Then at 618, the encrypted (ciphered) symmetric key is provided to the source device 102, along with the ICCID, a URL for the subscription manager 108 (e.g., an SM-DP+ URL), and a transfer token matching ID.

[0067] At 620, the escrow procedure has concluded. Following the conclusion of the escrow procedure, for example days, weeks, months, or even years later, the user may obtain a new UE, such as target device 104, and want to transfer the eSIM from source device 102 to target device 104. Then, a retrieval procedure may be performed, to retrieve the escrowed transfer token and the escrowed symmetric key and perform a device change procedure.

[0068] FIG. 7 shows an example signaling flow 700, according to one or more aspects described herein. In one or more embodiments, signaling flow 700, supports one or more aspects of cloudbased device change tokens, as further described herein. In one or more embodiments, signaling flow 700, supports one or more aspects of cloud-based device change tokens, as further described herein. Signaling flow 700 includes communications between one or more the cloud-based service 106, the target device 104 (including an eUICC 124 of the target device 104), a subscription manager (e.g., an SM-DP+), an entitlement server 112 (e.g., of a cellular carrier 110), and a carrier BSS 114 (e.g., of a cellular carrier 110). In one or more embodiments, signaling flow 700 includes one or aspects of initiating a device change as described at 210 and retrieving a symmetric key at 212 of the device change procedure 200.

[0069] In one or more embodiments, the state of the target device 104 prior to signaling flow 700 includes one or more of a cloud certificate being present on the eUICC 124, a ciphered device change token (transfer token) being escrowed in the subscription manager 108 (e.g., at a SM-DP+ trusted by the cellular carrier), and the ciphered symmetric key escrowed in the cloud (e.g., at the cloud-based service 106).

[0070] First, at 702, the target device 104 (e.g., based on user input from a user 116) may initiate an eSIM download. At 704, the target device 104 authenticates the user with the cloud account, the cloud user authentication occurring at 706, for example using one or more of the passcode or device PIN of the user. In response to the authentication of the user, the cloud-based service 106may provide a list of transferrable eSIMs at 708. The list of transferrable eSIMs may be identified by one or more of an ICCID, a carrier name, or a mobile station international subscriber directory number (MSISDN). At 710, the target device 104 selects an eSIM to transfer from the list of transferrable eSIMs.

[0071] Having selected an eSIM, at 712, the target device 104 initiates symmetric key retrieval for the escrowed symmetric key. The eUICC 124 creates a symmetric key retrieval key pair, such as a public-key private key pair (pK / sK) at 714. The eUICC 124 then provides the public key pK to the target device 104 at 716. The target device 104 the provides a request 718 to the cloud-based service 106 to retrieve the ciphered symmetric key associated with the eSIM that the target device 104 selected for transfer. In one or more embodiments, the request 718 includes the public key pK (e.g., a symmetric key retrieval public key pK) and the ICCID corresponding to the eSIM.

[0072] In response to receiving the request 718, at 720, the cloud-based service 106 can rewrap the escrowed symmetric key with the symmetric key retrieval public key pK. The cloud-based service 106 then signs the rewrapped symmetric key and the token retrieval payload with the cloud certificate. In some embodiments, the token retrieval payload includes one or more of the ciphered symmetric key, URL for the subscription manager 108 (e.g., a SM-DP+ URL), the ICCID for the eSIM, and the transfer token matching ID further described herein. At 724, the cloud-based service 106 returns the re wrapped symmetric key and signed token retrieval payload to the target device 104, which provides the rewrapped symmetric key and signed token retrieval pay load to the eUICC 124. At 728, the eUICC 124 can verify the cloud signature and decrypt the ciphered symmetric key to obtain the symmetric key to be used to decrypt the escrowed transfer token at 814.

[0073] FIG. 8 shows an example signaling flow 800, according to one or more aspects described herein. In one or more embodiments, signaling flow 800, supports one or more aspects of cloudbased device change tokens, as further described herein. In one or more embodiments, signaling flow 800, supports one or more aspects of cloud-based device change tokens, as further described herein. Signaling flow 800 includes communications between one or more the cloud-based service 106, the target device 104 (including an eUICC 124 of the target device 104), a subscription manager (e.g., an SM-DP+), an entitlement server 112 (e.g., of a cellular carrier 110), and a carrier BSS 114 (e.g., of a cellular carrier 110). In one or more embodiments, signaling flow 800 includes one or aspects of retrieving a token blob at 214 and performing the token-based device change at 216 of the device change procedure 200.

[0074] The eUICC 124 may first perform a common mutual authentication procedure 802 with the subscription manager 108. At 804, the eUICC 124 and the subscription manager 108 can exchange device information and eUICC information, for example in two payloads. Following thisexchange, optionally, at 806, the subscription manager 108 may check the eligibility of the device (e.g., the target device 104) to receive an eSIM, such as the escrowed eSIM.

[0075] The target device 104 may then transmit a request 808 for the ciphered transfer token from the subscription manager 108. In one or more embodiments, the request 808 may include the ICCID for the eSIM and the transfer token matching ID described herein. The ciphered transfer token may then be provided to the target device 104 in response, at 810, and the ciphered transfer token provided to the eUICC 124 at 812. At 814, the eUICC 124 may then decrypt (decipher) the ciphered transfer token using the symmetric key obtained from the cloud-based service 106, for example as part of the herein-described symmetric key retrieval procedure 700. At 816, the target device 104 requests the transfer token (e.g., the plaintext transfer token) and, at 818, the eUICC 124 provides the transfer token.

[0076] After the target device 104 has obtained the transfer token, the target device 104 can present the transfer token to the cellular carrier 110 to obtain the eSIM to be transferred. At 820, the target device 104 performs a token exchange with the entitlement server 112 using the transfer token. At 822, having successfully exchanged the token, the subscription manager 108 provides the eSIM to the to the target device 104, and specifically to the eUICC 124, for example as a download. Following installation of the acquired eSIM and other procedures, the device change is complete at 824, the escrowed eSIM from the source device 102 having been successfully transferred to the target device 104 for the user.

[0077] FIG. 9 shows an example method 900 of wireless communication. In one or more embodiments, method 900, supports one or more aspects of cloud-based device change tokens, as further described herein. In some cases, the UE may be the source device 102, wireless device 1202, or one of the other UEs described herein. The method 900 may be performed using a processor, a transceiver (or a main radio), or other components of the UE.

[0078] At 902, the method 900 includes initiating, at a UE, a device change procedure to the UE, the UE using a cellular carrier.

[0079] At 904, the method 900 includes receiving, from a cloud-based service for a user of the UE, a symmetric key associated with a transfer token for an eSIM.

[0080] At 906, the method 900 includes receiving, from a subscription manager of the cellular carrier, a ciphered transfer token for the eSIM.

[0081] At 908, the method 900 includes decrypting the ciphered transfer token using the symmetric key to obtain the transfer token.

[0082] At 910, the method 900 includes receiving, in response to providing the transfer token to the cellular carrier, profile information for the eSIM.

[0083] At 912, the method 900 includes configuring, according to the profile information, the UE to communicate with the cellular carrier using the eSIM.

[0084] In one or more embodiments, the method further includes generating a public key and a private key of a public key-private key pair; transmitting, to the cloud-based service, the public key and a request for the symmetric key; receiving, in response to the request, an encrypted message; and decrypting, using the private key, the encrypted message to obtain the symmetric key associated with the transfer token of the eSIM. In one or more embodiments, the method further includes receiving, from the cloud-based service, a list of transferrable eSIMs; and selecting the eSIM from the list of transferrable eSIMs, where the request for the symmetric key includes an identifier of the selected eSIM.

[0085] In one or more embodiments, the method further includes authenticating the UE with the cloud-based service using one or more of a passcode or a personal identification number, the symmetric key received at least in part in response to the authentication.

[0086] In one or more embodiments, the method further includes transmitting, to the cloudbased service for the user, a request for the symmetric key associated with the transfer token for the eSIM, the ciphered transfer token received in response to the request. In some embodiment, the request includes an identifier of the eSIM.

[0087] In one or more embodiments, the method further includes transmitting, to the subscription manager of the cellular carrier, a request for a transfer token for the eSIM, the request including an identifier of the transfer token, where the ciphered transfer token corresponding to the identifier of the transfer token is received in response to the request.

[0088] In one or more embodiments, the method further includes receiving, from the cloudbased service of the cellular carrier, an encrypted message that includes the symmetric key, a uniform resource locator for the subscription manager, an identifier of the eSIM, and an identifier of the transfer token, where the symmetric key is received in the encrypted message from the cloud-based service.

[0089] In some embodiments, the subscription manager is a SM-DP+ device, and the transfer token is generated at one or more network devices of the cellular carrier that are exclusive of the subscription manager.

[0090] The method 900 may be variously embodied, extended, or adapted, as described in the following paragraphs and elsewhere in this description.

[0091] FIG. 10 shows an example method 1000 of wireless communication by a network device. In one or more embodiments, method 1000, supports one or more aspects of cloud-based device change tokens, as further described herein. In some cases, the network device may be the network device 1220, or one of the other network devices described herein. The method 1000 may be performed using a processor, a transceiver (eg., main radio), or other components of the network device.

[0092] At 1002, the method 1000 includes transmitting, from a UE, a request from a user to activate the UE with a cellular carrier.

[0093] At 1004, the method 1000 includes receiving, in response to the request, profile information for an eSIM and a transfer token for the eSIM.

[0094] At 1006, the method 1000 includes encrypting the transfer token using a symmetric key to generate a ciphered transfer token.

[0095] At 1008, the method 1000 includes transmitting the symmetric key to a cloud-based service for the user.

[0096] At 1010, the method 1000 includes transmitting, to a subscription manager of the cellular carrier, the ciphered transfer token and an installation receipt for the profile information.

[0097] In one or more embodiments, the method further includes transmitting, to the subscription manager, an identifier of the eSIM and a public key of a public key-private key pair, where the received transfer token is encrypted using the public key; and decrypting the transfer token using a private of the public key-private key pair prior to encrypting the transfer token using the symmetric key to generate the ciphered transfer token.

[0098] In one or more embodiments, the method further includes receiving, in response to the request, an identifier of the transfer token; and transmitting the identifier of the transfer token to the cloud-based service with the symmetric key.

[0099] In one or more embodiments, the method further includes authenticating the first with the cloud-based service using one or more of a passcode or a personal identification number; receiving, from the cloud-based service, a public key of a public key-private key pair generated at the cloud-based service; and encrypting the symmetric key using the public key generated at the cloud-based service, where the symmetric key transmitted to the cloud-based service is the symmetric key encrypted using the public key. In one or more embodiments, the method further includes verifying the certificate prior to encrypting the symmetric key using the public key generated at the cloud-based service, where the public key is signed with a certificate of the cloudbased service.

[0100] In some embodiments, the symmetric key is transmitted to the cloud-based service with an identifier of the eSIM, a uniform resource locator for the subscription manager, and an identifier of the transfer token.

[0101] In some embodiments, the method further includes generating the symmetric key to use to encrypt the transfer token after receiving the transfer token for the eSIM.

[0102] In some embodiments, an identifier of the transfer token is transmitted with the ciphered transfer token and the installation receipt.

[0103] The method 1000 may be variously embodied, extended, or adapted, as described in the following paragraphs and elsewhere in this description.

[0104] Embodiments contemplated herein include one or more non-transitory computer- readable media storing instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of the method 900 or 1000. In the context of method 900, this non-transitory computer-readable media may be, for example, a memory of a UE (such as a memory 1206 of a wireless device 1202 that is a UE, as described herein). In the context of method 1000, this non-transitory computer- readable media may be, for example, a memory of a network device (such as a memory 1224 of a network device 1220, as described herein).

[0105] Embodiments contemplated herein include an apparatus having logic, modules, or circuitry to perform one or more elements of the method 900 or 1000. In the context of method 900, this apparatus may be, for example, an apparatus of a UE (such as a wireless device 1202 that is a UE). In the context of method 1000, this apparatus may be, for example, an apparatus of a network device (such as a network device 1220, as described herein).

[0106] Embodiments contemplated herein include an apparatus having one or more processors and one or more computer-readable media, using or storing instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of the method 900 or 1000. In the context of method 900, this apparatus may be, for example, an apparatus of a UE (such as a wireless device 1202 that is a UE, as described herein). In the context of the method 1000, this apparatus may be, for example, an apparatus of a network device (such as a network device 1220, as described herein).

[0107] Embodiments contemplated herein include a signal as described in or related to one or more elements of the method 900, or 1000.

[0108] Embodiments contemplated herein include a computer program or computer program product having instructions, wherein execution of the program by a processor causes the processorto carry out one or more elements of the method 900 or 1000. In the context of method 900, the processor may be a processor of a UE (such as a processor(s) 1204 of a wireless device 1202 that is a UE, as described herein), and the instructions may be, for example, located in the processor and / or on a memory of the UE (such as a memory 1206 of a wireless device 1202 that is a UE, as described herein). In the context of method 1000, the processor may be a processor of a network device (such as a processor(s) 1222 of a network device 1220, as described herein), and the instructions may be, for example, located in the processor and / or on a memory of the network device (such as a memory 1224 of a network device 1220, as described herein).

[0109] FIG. 11 illustrates an example architecture of a wireless communication system, according to embodiments described herein. The following description is provided for an example wireless communication system 1100 that operates in conjunction with the LTE system standards or specifications and / or 5G or NR system standards or specifications, as provided by 3GPP technical specifications.

[0110] As shown, the wireless communication system 1100 includes UE 1102 and UE 1104 (although any number of UEs may be used). In this example, the UE 1102 and the UE 1104 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) but may also comprise any mobile or non-mobile computing device configured for wireless communication.

[0111] The UE 1102 and UE 1104 may be configured to communicatively couple with a RAN 1106. In embodiments, the RAN 1106 may be NG-RAN, E-UTRAN, etc. The UE 1102 and UE 1104 utilize connections (or channels) (shown as connection 1108 and connection 1110, respectively) with the RAN 1106, each of which comprises a physical communications interface. The RAN 1106 can include one or more network devices, such as base station 1112 and base station 1114, that enable the connection 1108 and connection 1110.

[0112] In this example, the connection 1108 and connection 1110 are air interfaces to enable such communicative coupling and may be consistent with RAT(s) used by the RAN 1106, such as, for example, an LTE and / or NR.

[0113] In some embodiments, the UE 1102 and UE 1104 may also directly exchange communication data via a sidelink interface 1116. The UE 1104 is shown to be configured to access an access point (shown as AP 1118) via connection 1120. By way of example, the connection 1120 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 1118 may comprise a Wi-Fi® router. In this example, the AP 1118 may be connected to another network (for example, the Internet) without going through a CN 1124.

[0114] In embodiments, the UE 1102 and UE 1104 can be configured to communicate using orthogonal frequency division multiplexing (OFDM) communication signals with each other or with the base station 1112 and / or the base station 1114 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an orthogonal frequency division multiple access (OFDMA) communication technique (e.g., for downlink communications) or a single carrier frequency division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0115] In some embodiments, all or parts of the base station 1112 or base station 1114 may be implemented as one or more software entities running on server computers as part of a virtual network. In addition, or in other embodiments, the base station 1112 or base station 1114 may be configured to communicate with one another via interface 1122. In embodiments where the wireless communication system 1100 is an LTE system (e.g., when the CN 1124 is an EPC), the interface 1122 may be an X2 interface. The X2 interface may be defined between two or more network devices of a RAN (e.g., two or more eNBs and the like) that connect to an EPC, and / or between two eNBs connecting to the EPC. In embodiments where the wireless communication system 1100 is an NR system (e.g., when CN 1124 is a 5GC), the interface 1122 may be an Xn interface. The Xn interface is defined between two or more network devices of a RAN (e.g., two or more gNBs and the like) that connect to the 5GC, between a base station 1112 (e.g., a gNB) connecting to the 5GC and an eNB, and / or between two eNBs connecting to the 5GC (e.g., CN 1124).

[0116] The RAN 1106 is shown to be communicatively coupled to the CN 1124. The CN 1124 may comprise one or more network elements 1126, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UE 1102 and UE 1104) who are connected to the CN 1124 via the RAN 1106. The components of the CN 1124 may be implemented in one physical device or separate physical devices including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non- transitory machine-readable storage medium).

[0117] In embodiments, the CN 1124 may be an EPC, and the RAN 1106 may be connected with the CN 1124 via an SI interface 1128. In embodiments, the SI interface 1128 may be split into two parts, an S 1 user plane (S 1 -U) interface, which carries traffic data between the base station 1112 or base station 1114 and a serving gateway (S-GW), and the Sl-MME interface, which is asignaling interface between the base station 1112 or base station 1114 and mobility management entities (MMEs).

[0118] In embodiments, the CN 1124 may be a 5GC, and the RAN 1106 may be connected with the CN 1124 via an NG interface 1128. In embodiments, the NG interface 1128 may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the base station 1112 or base station 1114 and a user plane function (UPF), and the SI control plane (NG- C) interface, which is a signaling interface between the base station 1112 or base station 1114 and access and mobility management functions (AMFs).

[0119] Generally, an application server 1130 may be an element offering applications that use internet protocol (IP) bearer resources with the CN 1124 (e.g., packet switched data services). The application server 1130 can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for the UE 1102 and UE 1104 via the CN 1124. The application server 1130 may communicate with the CN 1124 through an IP communications interface 1132.

[0120] FIG. 12 illustrates an example system 1200 for performing signaling 1238 between a wireless device 1202 and a network device 1220, according to embodiments described herein. The system 1200 may be a portion of a wireless communication system as herein described. The wireless device 1202 may be, for example, a UE of a wireless communication system. The network device 1220 may be, for example, a base station (e.g., an eNB or a gNB) or a radio head of a wireless communication system.

[0121] The wireless device 1202 may include one or more processor(s) 1204. The processor(s) 1204 may execute instructions such that various operations of the wireless device 1202 are performed, as described herein. The processor(s) 1204 may include one or more baseband processors implemented using, for example, a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a controller, a field programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0122] The wireless device 1202 may include a memory 1206. The memory 1206 may be a non-transitory computer-readable storage medium that stores instructions 1208 (which may include, for example, the instructions being executed by the processor(s) 1204). The instructions 1208 may also be referred to as program code or a computer program. The memory 1206 may also store data used by, and results computed by, the processor(s) 1204.

[0123] The wireless device 1202 may include one or more transceiver(s) 1210 (also collectively referred to as a transceiver 1210) that may include radio frequency (RF) transmitter and / or receiver circuitry that use the antenna(s) 1212 of the wireless device 1202 to facilitate signaling (e.g., the signaling 1238) to and / or from the wireless device 1202 with other devices (e.g., the network device 1220) according to corresponding RATs.

[0124] The wireless device 1202 may include one or more antenna(s) 1212 (e.g., one, two, four, eight, or more). For embodiments with multiple antenna(s) 1212, the wireless device 1202 may leverage the spatial diversity of such multiple antenna(s) 1212 to send and / or receive multiple different data streams on the same time and frequency resources. This behavior may be referred to as, for example, MIMO behavior (referring to the multiple antennas used at each of a transmitting device and a receiving device that enable this aspect). MIMO transmissions by the wireless device 1202 may be accomplished according to precoding (or digital beamforming) that is applied at the wireless device 1202 that multiplexes the data streams across the antenna(s) 1212 according to known or assumed channel characteristics such that each data stream is received with an appropriate signal strength relative to other streams and at a desired location in the spatial domain (e.g., the location of a receiver associated with that data stream). Some embodiments may use single user MIMO (SU-MIMO) methods (where the data streams are all directed to a single receiver) and / or multi-user MIMO (MU-MIMO) methods (where individual data streams may be directed to individual (different) receivers in different locations in the spatial domain).

[0125] In some embodiments having multiple antennas, the wireless device 1202 may implement analog beamforming techniques, whereby phases of the signals sent by the antenna(s) 1212 are relatively adjusted such that the (joint) transmission of the antenna(s) 1212 can be directed (this is sometimes referred to as beam steering).

[0126] The wireless device 1202 may include one or more interface(s) 1216. The interface(s) 1216 may be used to provide input to or output from the wireless device 1202. For example, a wireless device 1202 that is a UE may include interface(s) 1216 such as microphones, speakers, a touchscreen, buttons, and the like in order to allow for input and / or output to the UE by a user of the UE. Other interfaces of such a UE may be made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver(s) 1210 / antenna(s) 1212 already described) that allow for communication between the UE and other devices and may operate according to known protocols (e.g., Wi-Fi®, Bluetooth®, and the like).

[0127] The wireless device 1202 may include transfer token manager 1216. The transfer token manager 1216 may be implemented via hardware, software, or combinations thereof. For example, the transfer token manager 1216 may be implemented as a processor, circuit, and / or instructions1208 stored in the memory 1206 and executed by the processor(s) 1204. In some examples, the transfer token manager 1216 may be integrated within the processor(s) 1204 and / or the transceiver(s) 1210. For example, the transfer token manager 1216 may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the processor(s) 1204 or the transceiver(s) 1210.

[0128] The transfer token manager 1216 may be used for various aspects of the present disclosure, for example, aspects of FIGs. 1-12, from a wireless device or UE perspective. The transfer token manager 1216 may be configured to, for example, perform initiating, at a UE, a device change procedure to the UE, the UE using a cellular carrier; receiving, via the transceiver 1210 and from a cloud-based service for a user of the UE, a symmetric key associated with a transfer token for an eSIM; receiving, via the transceiver 1210 and from a subscription manager of the cellular carrier, a ciphered transfer token for the eSIM; decrypting the ciphered transfer token using the symmetric key to obtain the transfer token; receiving, via the transceiver 1210 and in response to providing the transfer token to the cellular carrier, profile information for the eSIM; configuring, according to the profile information, the UE to communicate with the cellular carrier using the eSIM.

[0129] The transfer token manager 1216 may also be configured to, for example, perform transmitting, from a UE, a request from a user to activate the UE with a cellular carrier; receiving, in response to the request, profile information for an eSIM and a transfer token for the eSIM; encrypting the transfer token using a symmetric key to generate a ciphered transfer token; transmitting, via the transceiver 1210, the symmetric key to a cloud-based service for the user; transmitting, via the transceiver 1210 and to a subscription manager of the cellular carrier, the ciphered transfer token and an installation receipt for the profile information..

[0130] The network device 1220 may include one or more processor(s) 1222. The processor(s) 1222 may execute instructions such that various operations of the network device 1220 are performed, as described herein. The processor(s) 1222 may include one or more baseband processors implemented using, for example, a CPU, a DSP, an ASIC, a controller, an FPGA device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0131] The network device 1220 may include a memory 1224. The memory 1224 may be a non-transitory computer-readable storage medium that stores instructions 1226 (which may include, for example, the instructions being executed by the processor(s) 1222). The instructions1226 may also be referred to as program code or a computer program. The memory 1224 may also store data used by, and results computed by, the processor(s) 1222.

[0132] The network device 1220 may include one or more transceiver(s) 1228 (also collectively referred to as a transceiver 1228) that may include RF transmitter and / or receiver circuitry that use the antenna(s) 1230 of the network device 1220 to facilitate signaling (e.g., the signaling 1238) to and / or from the network device 1220 with other devices (e.g., the wireless device 1202) according to corresponding RATs.

[0133] The network device 1220 may include one or more antenna(s) 1230 (e.g., one, two, four, or more). In embodiments having multiple antenna(s) 1230, the network device 1220 may perform MIMO, digital beamforming, analog beamforming, beam steering, etc., as has been described.

[0134] The network device 1220 may include one or more interface(s) 1232. The interface(s) 1232 may be used to provide input to or output from the network device 1220. For example, a network device 1220 of a RAN (e.g., a base station, a radio head, etc.) may include interface(s) 1232 made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver(s) 1228 / antenna(s) 1230 already described) that enables the network device 1220 to communicate with other equipment in a network, and / or that enables the network device 1220 to communicate with external networks, computers, databases, and the like for purposes of operations, administration, and maintenance of the network device 1220 or other equipment operably connected thereto.

[0135] The network device 1220 may include at least one transfer token manager 1234. The transfer token manager 1234 may be implemented via hardware, software, or combinations thereof. For example, the transfer token manager 1234 may be implemented as a processor, circuit, and / or instructions 1226 stored in the memory 1224 and executed by the processor(s) 1222. In some examples, the transfer token manager 1234 may be integrated within the processor(s) 1222 and / or the transceiver(s) 1228. For example, the transfer token manager 1234 may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the processor(s) 1222 or the transceiver(s) 1228.

[0136] The transfer token manager 1234 may be used for various aspects of the present disclosure, for example, aspects of FIGs. 1-12, from a network device perspective. The transfer token manager 1234 may be configured to, for example, perform transmit, from a UE, a request from a user to activate the UE with a cellular carrier; receiving, in response to the request, profile information for an eSIM and a transfer token for the eSIM; encrypting the transfer token using a symmetric key to generate a ciphered transfer token; transmitting the symmetric key to a cloud-based service for the user; and transmitting, to a subscription manager of the cellular carrier, the ciphered transfer token and an installation receipt for the profile information.

[0137] The transfer token manager 1234 may be configured to, for example, perform initiating, at a UE, a device change procedure to the UE, the UE using a cellular carrier; receiving, via the transceiver 1228 and from a cloud-based service for a user of the UE, a symmetric key associated with a transfer token for an eSIM; receiving, via the transceiver 1228 and from a subscription manager of the cellular carrier, a ciphered transfer token for the eSIM; decrypting the ciphered transfer token using the symmetric key to obtain the transfer token; receiving, via the transceiver 1228 and in response to providing the transfer token to the cellular carrier, profile information for the eSIM; configuring, according to the profile information, the UE to communicate with the cellular carrier using the eSIM.

[0138] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods as set forth herein. For example, a baseband processor (or processor) as described herein in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein. For another example, circuitry associated with a UE, network device, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein.

[0139] Any of the above described embodiments may be combined with any other embodiment (or combination of embodiments), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description but is not intended to be exhaustive or to limit the scope of embodiments to the precise form described. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0140] Embodiments and implementations of the systems and methods described herein may include various operations, which may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that include specific logic for performing the operations or may include a combination of hardware, software, and / or firmware.

[0141] The systems described herein pertain to specific embodiments but are provided as examples. These embodiments can be combined into single systems, partially combined into other systems, split into multiple systems or divided or combined in other ways. In addition, it iscontemplated that parameters, attributes, aspects, etc. of one embodiment can be used in another embodiment. The parameters, attributes, aspects, etc. are merely described in one or more embodiments for clarity, and it is recognized that the parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless specifically disclaimed herein.

[0142] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein but may be modified within the scope and equivalents of the appended claims.

Claims

CLAIMS1. A processor configured to: initiate a device change procedure for a device, the device using a cellular carrier; receive, via a transceiver and from a cloud-based service, a symmetric key associated with a transfer token for an embedded subscriber identity module (eSIM); receive, via the transceiver and from a subscription manager of the cellular carrier, a ciphered transfer token for the eSIM; decrypt the ciphered transfer token using the symmetric key to obtain the transfer token; receive, via the transceiver and in response to providing the transfer token to the cellular carrier, profile information for the eSIM; and configure, according to the profile information, the device to communicate with the cellular carrier using the eSIM.

2. The processor of claim 1 , further configured to: generate a public key and a private key of a public key-private key pair; transmit, via the transceiver and to the cloud-based service, the public key and a request for the symmetric key; receive, via the transceiver and in response to the request, an encrypted message; and decrypt, using the private key, the encrypted message to obtain the symmetric key associated with the transfer token of the eSIM.

3. The processor of claim 2, further configured to: receive, via the transceiver and from the cloud-based sendee, a list of transferrable eSIMs; and select the eSIM from the list of transferrable eSIMs, wherein the request for the symmetric key comprises an identifier of the selected eSIM.

4. The processor of claim 1 , further configured to: authenticate the device with the cloud-based service using one or more of a passcode or a personal identification number, the symmetric key received at least in part in response to the authentication.

5. The processor of claim 1, further configured to:transmit, via the transceiver and to the cloud-based service, a request for the symmetric key associated with the transfer token for the eSIM, the ciphered transfer token received in response to the request.

6. The processor of claim 5, wherein the request comprises an identifier of the eSIM.

7. The processor of claim 1 , further configured to: transmit, via the transceiver and to the subscription manager of the cellular carrier, a request for a transfer token for the eSIM, the request including an identifier of the transfer token, wherein the ciphered transfer token corresponding to the identifier of the transfer token is received in response to the request.

8. The processor of claim 1 , further configured to: receive, via the transceiver and from the cloud-based sendee of the cellular carrier, an encrypted message that includes the symmetric key, a uniform resource locator for the subscription manager, an identifier of the eSIM, and an identifier of the transfer token, wherein the symmetric key is received in the encrypted message from the cloud-based service.

9. The processor of claim 1 , wherein the subscription manager is a subscription manager data preparation (SM-DP+) device, and the transfer token is generated at one or more network devices of the cellular carrier that are exclusive of the subscription manager.

10. A user equipment (UE), comprising: a transceiver; and a processor configured to cause the UE to, transmit, via the transceiver, a request from a user to activate the UE with a cellular carrier; receive, via the transceiver in response to the request, profile information for an embedded subscriber identity module (eSIM) and a transfer token for the eSIM; encrypt the transfer token using a symmetric key to generate a ciphered transfer token; transmit, via the transceiver, the symmetric key to a cloud-based service for the user; and transmit, via the transceiver and to a subscription manager of the cellular carrier, the ciphered transfer token and an installation receipt for the profile information.

11. The UE of claim 10, wherein the processor is further configured to cause the UE to: transmit, via the transceiver and to the subscription manager, an identifier of the eSIM and a public key of a public key-private key pair; receive, via the transceiver in response to the request, a transfer token wherein the received transfer token is encrypted using the public key; and decrypt the transfer token using a private of the public key-private key pair prior to encrypting the transfer token using the symmetric key to generate the ciphered transfer token.

12. The UE of claim 10, wherein the processor is further configured to cause the UE to: receive, via the transceiver and in response to the request, an identifier of the transfer token; and transmit, via the transceiver, the identifier of the transfer token to the cloud-based service with the symmetric key.

13. The UE of claim 10, wherein the processor is further configured to cause the UE to: authenticate the with the cloud-based service using one or more of a passcode or a personal identification number; receive, via the transceiver and from the cloud-based sendee, a public key of a public key-private key pair generated at the cloud-based service; and encrypt the symmetric key using the public key generated at the cloud-based service, wherein the symmetric key transmitted to the cloud-based service is the symmetric key encrypted using the public key.

14. The UE of claim 13, wherein the public key is signed with a certificate of the cloud-based service, and the processor is further configured to cause the UE to: verify the certificate prior to encrypting the symmetric key using the public key generated at the cloud-based service.

15. The UE of claim 10, wherein the symmetric key is transmitted to the cloud-based service with an identifier of the eSIM, a uniform resource locator for the subscription manager, and an identifier of the transfer token.

16. The UE of claim 10, wherein the processor is further configured to cause the UE to: generate the symmetric key to use to encrypt the transfer token after receiving the transfer token for the eSIM.

17. The UE of claim 10, wherein an identifier of the transfer token is transmitted with the ciphered transfer token and the installation receipt.

18. A method of wireless communication at a user equipment (UE), comprising: initiating a device change procedure to the UE, the UE using a cellular carrier; receiving, from a cloud-based service for a user of the UE, a symmetric key associated with a transfer token for an embedded subscriber identity module (eSIM); receiving, from a subscription manager of the cellular carrier, a ciphered transfer token for the eSIM; decrypting the ciphered transfer token using the symmetric key to obtain the transfer token; receiving, in response to providing the transfer token to the cellular carrier, profile information for the eSIM; and configuring, according to the profile information, the UE to communicate with the cellular carrier using the eSIM.

19. The method of claim 18, further comprising: generating a public key and a private key of a public key-private key pair; transmitting, to the cloud-based service, the public key and a request for the symmetric key; receiving, in response to the request, an encrypted message; and decrypting, using the private key, the encrypted message to obtain the symmetric key associated with the transfer token of the eSIM.

20. The method of claim 19, further comprising: receiving, from the cloud-based service, a list of transferrable eSIMs; and selecting the eSIM from the list of transferrable eSIMs, wherein the request for the symmetric key comprises an identifier of the selected eSIM.

Images