Installation and replacement operations for eUICC profiles
By processing the metadata and binding configuration file package of the eSIM profile through processing circuitry, delaying transmission and ensuring version consistency of the profile on the eUICC, the problem of repeated writes to the non-volatile memory of the eUICC is solved, and the secure update and stability of the eSIM profile are achieved.
Patent Information
- Application Number
- CN202480020216.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-03-21
- Filing Date
- 2024-03-21
- Publication Date
- 2025-11-04
AI Technical Summary
In existing technologies, repeated writes to eUICC non-volatile memory may lead to unrecoverable UE failures, and there is a lack of effective NVM protection mechanisms and operator management mechanisms.
The processing circuitry handles the metadata and binding configuration file packages of the eSIM profile, delays transmission, ensures version consistency of the profiles on the eUICC, prevents duplicate writes, and employs implicit or explicit methods for installing and replacing eSIM profiles.
This effectively prevents repeated writing of the eUICC NVM, reduces the risk of UE failure, and ensures the secure updating and stability of the eSIM configuration file.
Smart Images

Figure CN120898441A_ABST
Abstract
Description
[0001] Priority / Incorporation by Reference
[0002] This application claims priority to U.S. Provisional Application Serial No. 63,491,342, filed March 21, 2023, entitled “Install and Replace Operations for eUICC Profiles,” the entire contents of which are incorporated herein by reference. BACKGROUND
[0003] Existing implementations of user equipment (UE) embedded subscriber identity module (eSIM) operations use an embedded universal integrated circuit card (eUICC) to store one or more eSIM profiles.
[0004] It is possible that a malicious application or carrier error can cause repeated (i.e., consecutive) writes to the eUICC non-volatile memory (NVM). Repeated writes to the NVM in this manner can cause NVM failure. Due to the embedded nature of eSIMs, this is a serious issue that can potentially cause unrecoverable UE failure. Not all eUICC management procedures can have NVM protection mechanisms / logic, and existing implementations do not allow for simple carrier management of eSIM delivery procedures. SUMMARY
[0005] Some example embodiments relate to an apparatus having processing circuitry configured to: process, based on a signal received from a network, metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to the apparatus; determine that the eSIM profile is a new version of an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the apparatus; process, based on the signal received from the network, a bundle profile package (BPP) corresponding to the eSIM profile; and delay communicating the eSIM profile to the eUICC.
[0006] Other example embodiments relate to an apparatus having processing circuitry configured to: process, based on a signal received from a network, metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to the apparatus; determine that the eSIM profile is to replace an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the apparatus, wherein the eSIM profile has an integrated circuit card identity (ICCID) that is different from the existing eSIM profile; and process, based on the signal received from the network, a bundle profile package (BPP) corresponding to the eSIM profile.
[0007] Other example embodiments relate to a method performed by a user equipment (UE). The method includes receiving metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to the UE; determining that the eSIM profile is a new version of an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the UE; receiving a bundle profile package (BPP) corresponding to the eSIM profile; and delaying communicating the eSIM profile to the eUICC.
[0008] Additional example embodiments relate to a method performed by a user equipment (UE). The method includes receiving metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to the UE; determining that the eSIM profile will replace an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the UE, wherein the eSIM profile has an integrated circuit card identity (ICCID) that is different from the existing eSIM profile; and receiving a bundle profile package (BPP) corresponding to the eSIM profile. BRIEF DESCRIPTION OF DRAWINGS
[0009] Figure 1 An example network arrangement is shown in accordance with various example embodiments.
[0010] Figure 2 An example UE is shown in accordance with various example embodiments.
[0011] Figure 3 A call flow for implicit eSIM installation and replacement is shown in accordance with various example embodiments.
[0012] FIGS. 4A-4B show a call flow for explicit UE eSIM installation and replacement in accordance with various example embodiments. DETAILED DESCRIPTION
[0013] Example embodiments can be further understood with reference to the following description and related drawings in which like elements are referred to with the same reference numerals. The example embodiments relate to improvements in handling of installation and replacement operations for embedded subscriber identity module (eSIM) profiles on an embedded universal integrated circuit card (eUICC) of a user equipment (UE) by the UE and a network.
[0014] Example aspects are described with reference to a UE. However, the use of a UE is provided for illustrative purposes. Example aspects can be utilized with any electronic component that can establish a connection with a network and is configured with hardware, software, and / or firmware for exchanging information and data with the network. Thus, a UE as described herein is used to represent any electronic component that can access a wireless network and has an eUICC for storing eSIM profiles.
[0015] Example implementations are also described with reference to a 5G New Radio (NR) network. 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., Advanced 5G, 6G, etc.), or any other type of network.
[0016] Malicious applets or defective operator logic (and various possible causes) can cause continuous writes to a UE eUICC non-volatile memory (NVM). During the lifetime of a UE, the eUICC NVM is typically only written to occasionally. Repeatedly writing to the eUICC can cause the NVM to fail. A failed eUICC NVM can cause the UE to be out of cellular service.
[0017] Example implementations are directed to enhanced installation and replacement operations of eSIM profiles on an eUICC. Example implementations can prevent repeated writes of a sequence to the eUICC NVM, thereby mitigating the risk of eUICC NVM (and thus UE) failure.
[0018] Figure 1 An example network arrangement 100 is shown in accordance with various example implementations. The example network arrangement 100 includes a UE 110. The UE 110 can be any type of electronic component configured to communicate via a network, e.g., a mobile phone, a tablet computer, a desktop computer, a smart phone, a phablet, an embedded device, a wearable device, an Internet of Things (IoT) device, etc. A real network arrangement can include any number of UEs used by any number of users. Thus, only an example with one UE 110 is provided for illustrative purposes.
[0019] The UE 110 can be configured to communicate with one or more networks. In the example of the network arrangement 100, the UE 110 can wirelessly communicate with a 5G NR Radio Access Network (RAN) 120. The UE 110 can also communicate with other types of networks (e.g., a 5G Cloud RAN, a Next Generation RAN (NG-RAN), a legacy cellular network, etc.), and the UE 110 can also communicate with networks through a wired connection. With reference to the example implementation, the UE 110 can establish a connection with the 5G NR RAN 120. Accordingly, the UE 110 can have a 5G NR chipset to communicate with the NR RAN 120.
[0020] The 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.). The RAN 120 can include cells or base stations that are configured to transmit and receive traffic from UEs equipped with the appropriate cellular chipset. In this example, the 5G NR RAN 120 includes a gNB 120A. However, reference to a gNB is provided for illustrative purposes only, as any appropriate base station or cell (e.g., Node B, eNode B, HeNB, eNB, gNB, gNode B, macrocell, microcell, small cell, femtocell, etc.) can be deployed.
[0021] Any association procedure can be performed for connecting the UE 110 to the 5G NR RAN 120. For example, as discussed above, the 5G NR RAN 120 can be associated with a particular network operator at which the UE 110 and / or its user has subscription and credential information (e.g., stored on a SIM card). Upon detecting the presence of the 5G NR RAN 120, the UE 110 can transmit corresponding credential information in order to associate with the 5G NR RAN 120. More specifically, the UE 110 can associate with a particular cell (e.g., the gNB 120A).
[0022] The network arrangement 100 also includes a cellular core network 130, the 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 UEs 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UEs 110. The network services backbone 160 communicates with the Internet 140 and the cellular core network 130, either directly or indirectly. The network services backbone 160 can generally be described as a collection of components (e.g., servers, network storage arrangements, etc.) that implement a suite of services that can be used to extend functionality of the UEs 110 in communicating with various networks.
[0023] Figure 2 An example UE 110 is shown in accordance with various example embodiments. The UE 110 will be described with reference to the network arrangement 100 of Figure 1 The UE 110 can represent any electronic device, and can include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 can include, for example, an audio input device, an audio output device, a battery providing a limited power source, a data acquisition device, a port for electrically connecting the UE 110 to other electronic devices, a sensor for detecting a condition of the UE 110, etc. The eUICC 240 can be a hardware component embedded in the UE 110 configured to store multiple operator profiles.
[0024] The processor 205 can be configured to execute multiple engines of the UE 110. For example, these engines can include an eSIM installation / replace engine 235 for performing operations such as installing and replacing eUICC profiles on the UE. Details of example installation and replacement operations will be described in greater detail below.
[0025] The above engines are examples only of applications (e.g., programs) executed by the processor 205. The functionality associated with these engines can also be represented as separate combined components of the UE 110, or can be modular components coupled to the UE 110, such as integrated circuits with or without firmware. For example, the integrated circuits can include input circuitry for receiving signals and processing circuitry for processing the signals and other information. The engines can also be embodied as one application or multiple separate applications. Furthermore, in some UEs, the functionality described with respect to the processor 205 is split between two or more processors, such as a baseband processor and an application processor. The example embodiments can be implemented in any of these or other configurations of the UE.
[0026] Memory arrangement 210 can be a hardware component configured to store data related to operations performed by UE 110. Display device 215 can be a hardware component configured to display data to a user, while I / O device 220 can be a hardware component that enables the user to enter input. Display device 215 and I / O device 220 can be separate components or can be integrated together, such as a touch screen.
[0027] Transceiver 225 can be a hardware component configured to establish a connection with 5G-NR RAN 120. Thus, transceiver 225 can operate on a variety of different frequencies or channels (e.g., a set of contiguous frequencies). Transceiver 225 includes circuitry configured to send and / or receive signals (e.g., control signals, data signals). Such signals can be encoded with information implementing any of the methods described herein. Processor 205 can be operably coupled to transceiver 225 and configured to receive signals from and / or transmit signals to transceiver 225. Processor 205 can be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any of the methods described herein.
[0028] Figure 3 A call flow 300 for implicit eSIM installation and replacement is shown, in accordance with various example embodiments. Figure 3 An eUICC 301 is shown, which can be equivalent to eUICC 240. Figure 3 A local profile assistant (LPA) 302 is shown, which is a function (e.g., a function that can be implemented by processor 205) in the UE that allows the UE to download encrypted profiles to the UE eUICC. Thus, eUICC 301 and LPA 302 reside in UE 110. A discovery / push service 303 is shown, which can be a service that the UE can check to determine if there are any profiles or management operations available for download from a subscription manager-data preparation + (SM-DP+). In example embodiments, discovery / push service 303 can be considered to be implemented by an operator in cellular core network 130. However, it is not required that discovery / push service 303 be implemented in the core network, for example, it can also be implemented by an operator or a third party responsible for managing eSIM profiles in one or more servers in communication with cellular core network 130.
[0029] Figure 3An SM-DP+ 304 is also shown, which is a core network element that prepares, stores, and protects operator profiles (including operator credentials). The SM-DP+ 304 can be responsible for initiating profile download and installation operations for a UE eUICC (e.g., eUICC 301). Figure 3 An operator 305 is shown, e.g., a mobile network operator such as T-Mobile, Verizon, AT&T, etc. The operator 405 can be an entity that implements the gNB 120A, 5G-NR-RAN 120, and cellular core network 130. Any operations described as being performed by the operator 305 can also be performed by an agent of the operator, e.g., the operator 405 can contract with a third party to manage eSIM profiles.
[0030] In 306, the eUICC 301 can be considered to have an Integrated Circuit Card Identity (ICCID) that uniquely identifies the eSIM card to the operator 405. Specifically, the eUICC 301 has an ICCID l version 1 (v l) and an Embedded Identity Document (EID) l.
[0031] In 307, the operator 305 initiates an eSIM replacement procedure. Specifically, the eSIM replacement procedure is for EID l and ICCID l.
[0032] In 308, the operator 305 sends a bind message to the SM-DP+ 304. The bind message can include three parameters: EID: EID l, ICCID l v 2, and matchingID = null. Notably, the new profile (e.g., ICCID l v 2) is included in the message 308. This information is relevant to preventing erroneous writes to the eUICC NVM, as a write should only occur if the version number is different (e.g., higher / updated) than the version installed on the eUICC NVM. The matchingID can be null as the matching EID is sufficient in this example.
[0033] In 309, the SM-DP+ 304 sends a register event on a push service message to the discovery push service 303. The message 409 includes the address of the SM-DP+ 304 and includes information indicating event type = replacement (e.g., replacement of an eSIM). In 310, the discovery / push service 303 sends a message to the LPA 302 indicating that a profile replacement is available. In 311, the LPA 302 suppresses a profile download consent, e.g., the user of the UE 110 need not provide consent for the download at this time.
[0034] The suppression of user consent at this time in the call flow is based on the LPA 302 determining that the event is a replacement of an existing eSIM. The LPA 302 determines that the event is a replacement based on the message 310 indicating a replacement.
[0035] In some example embodiments, the registration event message 309 and the message 310 can not be used. In these example embodiments, the LPA 302 can not suppress profile download consent because the LPA 302 can not know that the eSIM profile to be downloaded is a replacement of an existing eSIM profile, e.g., the LPA can request user consent before performing the subsequent operations in the call flow 300.
[0036] In 312, the LPA 302 sends an authenticate_client message to the SM-DP+ 304. In 313, the SM-DP+ 304 responds to the LPA 302 with eSIM metadata indicating ICCID = ICCID l v_2, e.g., the eSIM profile is version 2 of ICCID l.
[0037] In 314, the LPA 302 sends a request to the eUICC 301 for a list of profiles on the eUICC 301. In 315, the eUICC 301 responds with a list of one or more profiles on the eUICC 301.
[0038] In 316, the LPA 302 determines whether there is a version discrepancy. Specifically, the LPA 302 determines that there is ICCID l and there is a version mismatch. For example, in this case, the eUICC 301 includes version 1 of ICCID l compared to version 2 of the carrier provisioned. As described above, in some example embodiments, the LPA 302 knows that the event is an eSIM replacement procedure based on a previously received message. However, in some example embodiments, the LPA 302 does not receive a message. Thus, in these example embodiments, the LPA 302 will determine that the event is an eSIM replacement procedure based on the mismatch between versions of the same ICCID.
[0039] In 317, the LPA 302 sends a get binding profile package (BPP) request to the SM-DP+ 304 for eSIM replacement. In 318, the SM-DP+ 304 responds to the LPA 302 with a BPP.
[0040] In 319, LPA 302 temporarily saves the BPP received in 318. This allows the deletion operation on the older version of the profile with the same ICCID on eUICC 301. Without the save operation 319, the new BPP profile would be rejected by eUICC 301 because it includes the same ICCID as the older version already stored by eUICC 301. Additionally, if the user rejects the prompt 320, saving the old profile enables the eUICC to continue using the profile.
[0041] In 320, LPA 302 prompts the user to replace the old profile. This can be accomplished by a pop-up notification on UE 110 that is accepted or rejected by the user. Assuming the user accepts the prompt 320, the call flow 300 continues, but it should be noted that if the user rejects the request, the call flow 300 terminates at this point. In an emergency situation, the operation can also not require user consent. Defining what constitutes or would not constitute an emergency situation is outside the scope of the present disclosure.
[0042] After the user accepts the prompt 320, then in 321, LPA 302 sends a message to eUICC 301 to disable and delete the old (existing) profile. The profile to be deleted in order to be replaced can be an enabled profile or a disabled profile. If the profile to be deleted in order to be replaced is disabled, eUICC 301 does not need to mark the profile as disabled because it is already disabled. However, if the profile to be deleted in order to be replaced is currently enabled, eUICC 301 will disable the profile before deleting the profile.
[0043] In 322, eUICC 301 deletes the profile with ICCID l (e.g., ICCID l v l). In 323, eUICC 301 generates a profile deletion notification indicating that ICCID l v l is deleted. In 324, eUICC 301 sends the profile deletion notification to LPA 302. In some example embodiments, when the call flow 400 begins, UE 110 can currently be using the ICCID l v l profile to enable connectivity. Thus, when the ICCID l v l profile is disabled, UE 110 can lose connectivity until the replacement ICCID l v 2 is installed and enabled. In other example embodiments, UE 110 can be using another profile to enable connectivity or can be connected to a non-cellular network (e.g., a WiFi network). In still other example embodiments, the deletion notification 324 can be for the same profile replacement (e.g., ICCID l v l) being deleted. For example, in Figure 3In this case, the deletion notification 324 can be conditionally deleted by the LPA 302 in the eUICC 301 to avoid putting the SM-DP+ 304 in an error state.
[0044] At this point, in the call flow 300, the replacement profile can be installed on the eUICC 301 because it will not be rejected due to the absence of other profiles with the same ICCID on that eUICC. Thus, in 325, the LPA 302 sends an install profile message to the eUICC 301 that includes the BPP of the replacement profile. In 326, the eUICC 301 installs the profile and generates a profile installation notification that includes that the installed profile is ICCID l v 2. In 327, the eUICC 301 sends the profile installation notification to the LPA 302. In 328, the LPA responds to the eUICC 301 with an enable profile message. At this point, the eUICC 301 enables the profile ICCID l v 2 (not shown). In 329, the LPA 302 sends a delete profile notification to the SM-DP+ 304 indicating that the ICCID l v l profile is deleted. In 330, the LPA 302 sends an installation notification to the SM-DP+ 304 indicating that the ICCID l v 2 profile is installed.
[0045] It will be apparent to those skilled in the art that the reference to ICCID l v l and ICCID l v 2 is merely an example and that any newer profile version number can be installed on the eUICC. The call flow 300 has two different versions of the same ICCID.
[0046] The call flow 300 replaces ICCID l with a nearly identical newer version (i.e., ICCID l v 2). The call flow 300 presumes that the entity managing the SM-DP+ 304 has retained the material needed to recreate the cryptographic elements of the profile. But this can not always be the case. In such cases, it can be necessary to issue a brand new profile with a brand new ICCID (as opposed to a version update of the same ICCID as shown in the call flow 300).
[0047] FIG. 4A illustrates a first portion of a call flow 400 for explicit UE eSIM installation and replacement, in accordance with various example embodiments. FIG. 4A (and FIG. 4B) is similar to FIG. 4. FIG. 4A (and FIG. 5B) includes eUICC 401, LPA 402, discovery / push service 403, SM-DP+ 404, and carrier 443. These entities / components are the same as described above with reference to FIG. 4. FIG. 4 also includes carrier website 441 and carrier backend system 442. Carrier website 441 can also be a carrier web service. Carrier website 441 is configured to receive old ICCID information and new ICCID information from LPA 402. Additionally, carrier website 441 can forward the old ICCID information and new ICCID information to carrier backend system 442.
[0048] Operations 406-407 are performed in exactly the same manner as operations 306-307 described above. In 408, carrier 443 sends a bind message to SM-DP+ 404 indicating EIC = EID_1, ICCID = ICCID_2, oldICCID = ICCID_1, matchingID = NULL. Bind message 408 indicates to SM-DP+ 404 that the ICCID is going to change. The message also includes that old ICCID_1 is going to be replaced by new ICCID_2.
[0049] In 409, SM-DP+ 404 sends a register event on a push service message to discovery push service 403. Message 409 includes the address of SM-DP+ 404 and includes information indicating event_type = replacement. Similar to operations described above with reference to FIG. 4, in some example embodiments, discovery / push service 403 can not inform LPA 402 that the event is a replacement event.
[0050] Operations 410, 411, and 412 are performed in exactly the same manner as operations 310, 311, and 312, respectively. In 413, SM-DP+ 404 sends eSIM metadata to LPA 402. The metadata message 413 includes information indicating that ICCID = ICCID_2 is a replacement of oldICCID = ICCID_1.
[0051] Operations 414 and 415 are performed in exactly the same manner as operations 314 and 315, respectively. In 416, LPA 402 determines that ICCID_2 is a replacement of ICCID_1. In other words, LPA 402 determines that it (LPA 402) is participating in an eSIM replacement profile flow.
[0052] Operations 417 and 418 are performed in exactly the same manner as 317 and 318, respectively. Upon receiving the BPP in 418, in 419, the LPA 402 sends an install profile message to the eUICC 401, which includes information indicating that the profile to be installed is ICCID_2. In 420, the eUICC 401 installs the profile and generates a profile installation notification, which includes that the installed profile is ICCID_2. In 421, the eUICC 401 sends the profile installation notification to the LPA 402. In 422, the LPA 402 sends an installation notification to the SM-DP+ 404, which includes information indicating that ICCID_2 has been installed on the eUICC 401.
[0053] At this point, in call flow 400, both the old profile ICCID_1 and the new profile ICCID_2 are installed on the eUICC 401. However, since the new profile ICCID_2 is a replacement for the old profile ICCID_1, the carrier 443 needs to provide the new ICCID_2 as the active subscription on the eUICC 401. Accordingly, in 423, the user receives a prompt / notification to update the eSIM. Specifically, the carrier 443 switches the provision of the user's subscription from the old ICCID_1 to the newly installed ICCID_2. This can be performed by the carrier website 441 and the carrier backend system 442.
[0054] In 423, the user receives a prompt / notification to update the eSIM. Similar to call flow 300, if the user rejects the request 423, the eUICC 401 will remain on ICCID_1 and the call flow terminates. The discussion regarding call flow 400 will continue assuming that the user accepts the prompt to update the eSIM.
[0055] FIG. 4B illustrates a second portion of a call flow 400 for explicit UE eSIM installation and replacement, according to various example embodiments. FIG. 4B can continue immediately after operation 423 in FIG. 4A.
[0056] In 424, the LPA sends a POST message to the carrier website 441. The POST message 424 includes information indicating that the eUICC 401 includes oldICCID = ICCID_1 and newICCID = ICCID_2.
[0057] In 425, the operator website 441 sends an ICCID_SWAP message to the operator backend system 442. The message 425 includes information indicating oldICCID = ICCID_1 and newICCID = ICCID_2. The operator backend system 442 switches the subscription to the eUICC 401 to the ICCID_2 profile. In 426, the operator backend system 442 sends an ACK message to the operator website 441.
[0058] In 427, the operator website 441 displays a confirmation to the user. In 428, the operator website 441 sends a final ICCID replacement message to the LPA 402. In 429, the user is prompted to agree to proceed with the eSIM replacement. Similar to the cases in this disclosure that require agreement, in some emergency cases, profile update can also be required without user agreement. Regardless of whether 429 is accepted by the user or forced by the operator, the call flow 400 will definitely proceed. If the user rejects in 429, the call flow ends and the eUICC stays on ICCID_1.
[0059] In 430, the LPA 402 sends a message to the eUICC 401 indicating to delete the old profile (ICCID_1). In 431, the LPA 402 sends a message to the eUICC 401 indicating to enable the new profile (ICCID_2). In 432, the LPA 402 sends a message to the eUICC 401 indicating that ICCID_1 should be deleted.
[0060] In 433, the eUICC 401 deletes the old profile ICCID_1. In 434, the eUICC 401 generates a profile deletion notification message indicating that ICCID_1 has been deleted. In 435, the eUICC sends the deletion notification to the LPA 402. In 436, the LPA 402 sends the deletion notification to the SM-DP+ 404.
[0061] Embodiments
[0062] In a first embodiment, a method includes receiving metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to a user equipment (UE); determining that the eSIM profile is a new version of an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the UE; receiving a bound profile package (BPP) corresponding to the eSIM profile; and delaying communicating the eSIM profile to the eUICC.
[0063] In a second embodiment, the method according to the first embodiment, the method further comprises: transmitting, to the eUICC, a message for deleting the existing eSIM profile prior to installing the eSIM on the eUICC; receiving, from the eUICC, an indication that the existing eSIM profile has been deleted.
[0064] In a third embodiment, the method according to the second embodiment, the method further comprises: transmitting, to the eUICC, an installation message indicating that the eSIM profile is to be installed on the eUICC after receiving the indication from the eUICC that the existing eSIM profile has been deleted, wherein the message includes the BPP corresponding to the eSIM profile.
[0065] In a fourth embodiment, the method according to the first embodiment, wherein determining that the eSIM profile is the new version of the existing eSIM profile stored on the eUICC of the UE comprises: receiving, from a network component prior to receiving the metadata, a message indicating that the eSIM profile is a replacement of the existing eSIM profile.
[0066] In a fifth embodiment, the method according to the fourth embodiment, the method further comprises: refraining from seeking a user’s consent to receive the BPP corresponding to the eSIM profile.
[0067] In a sixth embodiment, the method according to the first embodiment, wherein determining that the eSIM profile is the new version of the existing eSIM profile stored on the eUICC of the UE comprises: requesting, from the eUICC, a list of eSIM profiles currently stored on the eUICC, the list including the existing eSIM profile; determining that an integrated circuit card identity (ICCID) of the eSIM profile is identical to the ICCID of the existing eSIM profile; and determining that version information in the metadata of the eSIM profile is different from version data in metadata of the existing eSIM profile.
[0068] In a seventh embodiment, a processor configured to perform any of the methods according to the first through sixth embodiments.
[0069] In an eighth embodiment, a user equipment (UE) comprising: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform any of the methods according to the first through sixth embodiments.
[0070] In a ninth embodiment, a method comprises receiving metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to a user equipment (UE); determining that the eSIM profile is to replace an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the UE, wherein the eSIM profile has an integrated circuit card identity (ICCID) that is different from the existing eSIM profile; and receiving a bundle profile package (BPP) corresponding to the eSIM profile.
[0071] In a tenth embodiment, the method of the ninth embodiment, wherein determining that the eSIM profile is to replace the existing eSIM profile stored on the eUICC of the UE comprises receiving, from a network component, a message indicating that the eSIM profile is a replacement for the existing eSIM profile prior to receiving the metadata.
[0072] In an eleventh embodiment, the method of the tenth embodiment, the method further comprising suppressing a user’s consent to receive the BPP corresponding to the eSIM profile.
[0073] In a twelfth embodiment, the method of the ninth embodiment, wherein determining that the eSIM profile is to replace the existing eSIM profile stored on the eUICC of the UE comprises requesting, from the eUICC, a list of eSIM profiles currently stored on the eUICC, the list including the existing eSIM profile and the corresponding ICCID; and determining that the metadata of the eSIM includes an indication of the ICCID of the existing eSIM.
[0074] In a thirteenth embodiment, the method of the ninth embodiment, the method further comprising transmitting, to the eUICC, an installation message indicating that the eSIM profile is to be installed on the eUICC, wherein the message includes the BPP corresponding to the eSIM profile; and receiving, from the eUICC, an indication that the eSIM profile has been successfully installed on the eUICC.
[0075] In a fourteenth embodiment, the method of the thirteenth embodiment, the method further comprising transmitting, to an operator, a subscription message indicating that a subscription of the UE is to be switched from the existing eSIM profile to the eSIM profile; and receiving, from the operator, a confirmation message confirming that the subscription for the UE has been switched from the existing eSIM profile to the eSIM profile.
[0076] In a fifteenth embodiment, the method of the fourteenth embodiment, the method further comprises transmitting a disable message to the eUICC to disable the existing eSIM profile; transmitting an enable message to the eUICC to enable the eSIM profile; and transmitting a delete message to the eUICC to delete the existing eSIM profile.
[0077] In a sixteenth embodiment, a processor configured to perform any of the methods of the ninth through fifteenth embodiments.
[0078] In a seventeenth embodiment, a user equipment (UE) comprising a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the ninth through fifteenth embodiments.
[0079] Those skilled in the art will understand that the example embodiments described above can be implemented in any suitable software configuration or hardware configuration, or a combination thereof. Example hardware platforms for implementing the example embodiments can include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android, and the like. The example embodiments of the methods described above can be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium, which when compiled can be executed on a processor or microprocessor.
[0080] While the present application describes various embodiments each having different features in various combinations, those skilled in the art will appreciate that any feature of one embodiment can be combined with the features of another embodiment in any manner not specifically contemplated herein, unless contradicted by the specification or the functional or logical incompatibility of the features with the operation of the device or the specified functions of the disclosed embodiments.
[0081] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled in a way to minimize risk of unintentional or unauthorized access or use of the data, and every effort should be made to secure user's consent to the manner in which their personal information is being collected.
[0082] It will be apparent to those skilled in the art that various modifications can be made to the disclosed embodiments without departing from the spirit or scope of the disclosure. Thus, it is intended that the disclosure cover modifications and variations of the disclosed embodiments provided they come within the scope of the appended claims and their equivalents.
Claims
1. An apparatus comprising processing circuitry configured to: process metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to the apparatus based on signals received from a network; determine that the eSIM profile is a new version of an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the apparatus; process a bundle profile package (BPP) corresponding to the eSIM profile based on signals received from the network; and delay communicating the eSIM profile to the eUICC.
2. The apparatus of claim 1, wherein the processing circuitry is further configured to: transmit a message to the eUICC to delete the existing eSIM profile prior to installing the eSIM on the eUICC; process an indication from the eUICC that the existing eSIM profile has been deleted.
3. The apparatus of claim 2, wherein the processing circuitry is further configured to: transmit an installation message to the eUICC indicating that the eSIM profile is to be installed on the eUICC after processing the indication from the eUICC that the existing eSIM profile has been deleted, wherein the message includes the BPP corresponding to the eSIM profile.
4. The apparatus of claim 1, wherein determining that the eSIM profile is the new version of the existing eSIM profile stored on the eUICC of the apparatus is based on the processing circuitry being configured to: process a message indicating that the eSIM profile is a replacement for the existing eSIM profile based on signals received from the network prior to processing the metadata.
5. The apparatus of claim 4, wherein the processing circuitry is further configured to: suppress a user’s consent to receive the BPP corresponding to the eSIM profile.
6. The apparatus of claim 1, wherein determining that the eSIM profile is the new version of the existing eSIM profile stored on the eUICC of the apparatus is based on the processing circuitry being configured to: generate a request for a list of eSIM profiles currently stored on the eUICC to be transmitted to the eUICC, the list including the existing eSIM profile; determine that an integrated circuit card identity (ICCID) of the eSIM profile is identical to an ICCID of the existing eSIM profile; and determine that version information in the metadata of the eSIM profile is different from version data in metadata of the existing eSIM profile.
7. An apparatus comprising processing circuitry configured to: process metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to the apparatus based on signals received from a network; determine that the eSIM profile is to replace an existing eSIM profile stored on an embedded Universal Integrated Circuit Card (eUICC) of the device, wherein the eSIM profile has an Integrated Circuit Card Identity (ICCID) that is different from the existing eSIM profile; and process, based on signals received from the network, a bundle profile package (BPP) corresponding to the eSIM profile.
8. The apparatus of claim 7, wherein determining that the eSIM profile is to replace the existing eSIM profile stored on the eUICC of the device is based on the processing circuitry being configured to: process, based on signals received from the network, a message indicating that the eSIM profile is a replacement for the existing eSIM profile prior to processing the metadata.
9. The apparatus of claim 8, wherein the processing circuitry is further configured to: suppress a user’s consent to receive the BPP corresponding to the eSIM profile.
10. The apparatus of claim 7, wherein determining that the eSIM profile is to replace the existing eSIM profile stored on the eUICC of the device is based on the processing circuitry being configured to: generate a request for a list of eSIM profiles currently stored on the eUICC for transmission to the eUICC, the list including the existing eSIM profile and corresponding ICCID; and determine that the metadata of the eSIM includes an indication of the ICCID of the existing eSIM.
11. The apparatus of claim 7, wherein the processing circuitry is further configured to: generate an install message for transmission to the eUICC, the install message to indicate that the eSIM profile is to be installed on the eUICC, wherein the message includes the BPP corresponding to the eSIM profile; and process, based on signals received from the eUICC, an indication that the eSIM profile has been successfully installed on the eUICC.
12. The apparatus of claim 11, wherein the processing circuitry is further configured to: generate a subscription message for sending to a carrier via the network, the subscription message indicating that a subscription of the device is to be switched from the existing eSIM profile to the eSIM profile; and process, based on signals received from the carrier via the network, a confirmation message confirming that the subscription of the device has been switched from the existing eSIM profile to the eSIM profile.
13. The apparatus of claim 12, wherein the processing circuitry is further configured to: generate a disable message for transmission to the eUICC, the disable message to disable the existing eSIM profile; generate an enable message for transmission to the eUICC, the enable message to enable the eSIM profile; and generating a delete message for transmission to the eUICC, the delete message for deleting the existing eSIM profile.
14. A method performed by a user equipment (UE), the method comprising: receiving metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to the UE; determining that the eSIM profile is a new version of an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the UE; receiving a binding profile package (BPP) corresponding to the eSIM profile; and delaying communicating the eSIM profile to the eUICC.
15. The method of claim 14, the method further comprising: transmitting, to the eUICC, a message for deleting the existing eSIM profile prior to installing the eSIM on the eUICC; receiving an indication from the eUICC that the existing eSIM profile has been deleted.
16. The method of claim 15, the method further comprising: transmitting, to the eUICC, an install message indicating that the eSIM profile is to be installed on the eUICC after receiving the indication from the eUICC that the existing eSIM profile has been deleted, wherein the message includes the BPP corresponding to the eSIM profile.
17. The method of claim 14, wherein determining that the eSIM profile is the new version of the existing eSIM profile stored on the eUICC of the UE comprises: receiving, from a network component, a message indicating that the eSIM profile is a replacement for the existing eSIM profile prior to receiving the metadata.
18. The method of claim 17, the method further comprising: suppressing user consent to receive the BPP corresponding to the eSIM profile.
19. The method of claim 14, wherein determining that the eSIM profile is the new version of the existing eSIM profile stored on the eUICC of the UE comprises: requesting, from the eUICC, a list of eSIM profiles currently stored on the eUICC, the list including the existing eSIM profile; determining that an integrated circuit card identification (ICCID) of the eSIM profile is identical to an ICCID of the existing eSIM profile; and determining that version information in the metadata of the eSIM profile is different from version data in metadata of the existing eSIM profile.
20. A method performed by a network component, the method comprising: receiving metadata related to an embedded subscriber identity module (eSIM) profile to be downloaded to a user equipment (UE); determining that the eSIM profile is a new version of an existing eSIM profile stored on an embedded universal integrated circuit card (eUICC) of the UE; transmitting, to the UE, a message indicating that the eSIM profile is a replacement for the existing eSIM profile prior to receiving the metadata.
21. The method of claim 20, the method further comprising: receiving an indication from the eUICC that the existing eSIM profile has been deleted.
22. The method of claim 21, the method further comprising: transmitting, to the eUICC, an install message indicating that the eSIM profile is to be installed on the eUICC after receiving the indication from the eUICC that the existing eSIM profile has been deleted, wherein the message includes a binding profile package (BPP) corresponding to the eSIM profile.
23. The method of claim 20, wherein determining that the eSIM profile is the new version of the existing eSIM profile stored on the eUICC of the UE comprises: receiving, from the eUICC, a list of eSIM profiles currently stored on the eUICC, the list including the existing eSIM profile; determining that an integrated circuit card identification (ICCID) of the eSIM profile is identical to an ICCID of the existing eSIM profile; and determining that version information in the metadata of the eSIM profile is different from version data in metadata of the existing eSIM profile.