Update of a trusted name list

Methods, devices, and servers for as-needed update of a trusted list are provided herein. An electronic subscriber identity module (eSIM) server receives a request for an eSIM of a particular type from a wireless device. The eSIM server evaluates the particular type and requests an eSIM of the particular type from a second eSIM server, which is not initially trusted by a secure element (SE) of the wireless device. The eSIM server sends a policy update to the wireless device. The wireless device passes the policy update to the SE, for example, a universal integrated circuit card (UICC). The UICC updates the trusted list with an identity of the second eSIM server. When the wireless device downloads a bound profile package (BPP) containing an eSIM from the second eSIM server, the UICC validates the BPP based on the updated trusted list. The eSIM is then installed on the UICC.

FIELD

The described embodiments relate to updating a trusted list in a secure element (SE).

BACKGROUND

A wireless device can be provisioned with an electronic subscriber identity module (eSIM). Various network entities participate in provisioning of an eSIM to an SE, where the SE is present in a wireless device. To establish trust between communicating entities, public key infrastructure (PKI) techniques can be used. Problems can arise if a SE does not trust one of these entities.

Aspects of eSIM provisioning include the downloading, installing, enabling, disabling, switching and deleting of a profile on an eUICC or universal integrated circuit card (UICC). UICCs and eUICCs are secure elements (SEs) for hosting profiles. A profile is a combination of operator data and applications provisioned on an SE in a device for the purposes of providing services by an operator. A profile can contain one or more secure data used to prove identity and thus verify contract rights to services. During assembly of a device, the SE can be inserted into the device. A UICC may identified by a card serial number (CSN), and an eUICC may be identified by an eUICC identifier (EID). This application will generally refer to a UICC; the same techniques and apparatuses are applicable for an eUICC.

A profile can be identified by a unique number called an ICCID (Integrated Circuit Card Identifier). A wireless operator is a company providing wireless cellular network services. A mobile network operator (MNO) is an entity providing access capability and communication services to its subscribers through a mobile network infrastructure. In some cases, the device is user equipment used in conjunction with a UICC to connect to a mobile network. An end user or customer is a person using a device. An enabled profile can include files and/or applications which are selectable over an UICC-device interface. An architecture framework related to remote provisioning and management of secure elements in devices is outlined in GSM Association document GSMA SGP.22: “RSP Technical Specification,” Version 1.0 Jan. 13, 2016 (hereinafter “SGP.22”).

A digital signature is authentication data that binds the identity of the signer to a data part of a signed message. A certificate issuer (CI) is a trusted third party whose signature on a certificate vouches for the authenticity of the public key of the associated user identity. A public-key certificate may also be referred to herein simply as a certificate. A user may store a copy of a certificate, where the certificate holds the name of a given party (user identity). The public key recorded in the certificate can be used to check the signature on a message signed using a PKI private key of the given party. Further details with regard to PKI techniques in eSIM provisioning can be found in SGP.22.

SUMMARY

Representative embodiments set forth herein disclose various systems and techniques for updating a trusted in list in a UICC when an eSIM is to be provisioned to the UICC from a server that is initially untrusted.

Provisioning UICCs in a broadcast fashion with certificates and/or names of servers worthy of trust is neither an efficient use of UICC memory nor an efficient use of network bandwidth. Also, trust has a time-dependent aspect. Universal provisioning of trusted name lists is sensitive to entries of a given trusted name list becoming out-of-date. Embodiments provided herein update a trusted name list, also referred to as a trusted list, in a particular UICC associated with a need at a particular time for secure communication with a given eSIM server. An eSIM server may be referred to herein as, for example, an eSIM delivery server, as an SM-DP server, or as an SM-DP+ server.

A UICC in a device includes a trusted list of servers. In some embodiments, this list identifies trusted servers by their names, thus the expression trusted name list. The UICC possesses a PKI certificate of a trusted root server. The UICC trusts communications signed with the corresponding private key of the root server. The signature of any communications from the root server is verified by the UICC using the public key of the root server, found in a PKI certificate of the root server.

A common name of a given server authenticated by the root server is bound to a public key of the given server by a signature operation of the root server using the root server private key corresponding to the root server public key. The UICC thus also trusts communications from the given server because it recognizes the common name based on the root server signature operation. The identities of servers trusted by the UICC are stored in the trusted list of servers in the UICC.

In some embodiments, a user of a device chooses a carrier data plan of a selected carrier associated with eSIMs supplied by a third party eSIM server. A trusted list in the UICC does not include the common name or other identifier of the third party eSIM server. In some instances, the UICC possesses a certificate of the third party eSIM server but does not trust a CA that signed that certificate. After the user makes the selection, the device sends a data plan identifier to a carrier server associated with the carrier data plan. The carrier server sends a request for an eSIM to an eSIM server, for example, a host server hosted by a mobile device manufacturer. The host server may also be referred to herein as an original equipment manufacturer (OEM) eSIM server.

In response to the request from the carrier server, the host eSIM server recognizes that a policy update should be performed to ensure that the UICC has the third party eSIM server on its trusted list. The host eSIM server prepares a policy update notification. When the device next checks for policy updates, it will pull the policy update notification from the host eSIM server and pass the policy update notification on to a policy control function (PCF) in the UICC. The UICC will verify that the policy update notification is from a trusted source (the host eSIM server) and will then update its trusted list to include the common name of the third party eSIM server. At this, or a later time, the UICC may obtain a PKI certificate of the third party eSIM server.

The host eSIM server, in an exemplary embodiment, coordinates operations of the third party eSIM server and the carrier server to enable the deployment of the eSIM to the device. For example, upon receiving the request for an eSIM from the carrier server, the host eSIM server sends a request to the third party eSIM server. This causes the third party eSIM server to reserve an eSIM for the UICC and to bind the reserved eSIM to create a bound profile package (BPP). Binding is done by encrypting an eSIM based on the targeted UICC that the eSIM is to be delivered to. Only the targeted UICC is able to decrypt the BPP and recover the eSIM in decrypted form.

The carrier server confirms to the device that the carrier plan is now activated. Activation, in some embodiments, includes updating a home location register (HLR) database to recognize the eSIM identifier and associate it with an identifier of the device, such as an international mobile equipment identifier (IMEI). After receiving the plan activation confirmation, the device commences operations to download the eSIM. The device sends a policy update query to the host eSIM server. In response, the host eSIM server provides a new list of trusted servers or additions to the list of trusted servers. The device passes on the new list of trusted servers to the UICC. The UICC updates its trusted server list using the new list of trusted servers sent by the host eSIM server. The UICC then, in some embodiments, confirms to the device that the trusted server list has been updated.

Continuing with the operations to the download the eSIM, the device sends a request for pending eSIMs to the host eSIM server. This request, in some embodiments, identifies the UICC using an ICCID or an EID. Because the eSIM is reserved at the third party eSIM server, the host eSIM server responds with a message redirecting the device to the third party eSIM server. For example, the host eSIM server, in some embodiments, sends a name or network address of the third party eSIM server to the device. The device responds to the redirection message by sending a message to the third party eSIM server requesting any reserved eSIMs. Because the device has received a redirection message, it also sends an inquiry to the UICC to confirm that the third party eSIM server is trusted. Based on the updated trusted list, the UICC confirms that the third party eSIM server is trusted. The device receives a data blob including the BPP. The device and the UICC perform installation of the eSIM in the UICC from the data blob.

The device, with the aid of authentication and encryption operations performed by the UICC including the use of over-the-air (OTA) keys comprised in the eSIM, is now able to communicate with the selected carrier using the selected carrier data plan and provide wireless servers to the user of the device.

In some embodiments, the device comprises a processor and a memory coupled to the processor. The memory comprises instructions that when executed by the processor cause the device to perform a number of steps. The steps can include: i) sending a plan identifier to a carrier billing server, ii) receiving a plan confirmation from the carrier billing server, iii) requesting, responsive to receiving the plan confirmation, a policy update from a first eSIM server, iv) receiving the policy update from the first eSIM server, wherein the policy update comprises an identification of a second eSIM server, v) sending the policy update to a universal integrated circuit card (UICC) of the device for update of a trusted list, vi) sending a first request to the second eSIM server, wherein the first request is directed to a pending eSIM, vii) receiving a data binary large object (blob) from the second eSIM server, wherein the data blob comprises: i) the eSIM in encrypted form, and ii) a signature of the second eSIM server, viii) sending a first portion of the data blob to the UICC for verification of the signature of the second eSIM server, and ix) providing a profile installation command to the UICC, wherein the profile installation command refers to the eSIM. In some embodiments, the pending eSIM in encrypted form is bound to the UICC. In some embodiments, the UICC is identified by a card serial number (CSN). In some embodiments: i) the UICC is an embedded UICC (eUICC), and ii) the eUICC is identified by an eUICC-ID (EID).

DETAILED DESCRIPTION

Representative applications of apparatuses, systems, and methods according to the presently described embodiments are provided in this section. These examples are being provided solely to add context and aid in the understanding of the described embodiments. It will thus be apparent to one skilled in the art that the presently described embodiments can be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the presently described embodiments. Other applications are possible, such that the following examples should not be taken as limiting.

A wireless device can be provisioned with an eSIM. Various network entities participate in provisioning of an eSIM to an SE (e.g., a UICC or an eUICC), where the SE is associated with a wireless device. To establish trust between communicating entities, PKI techniques can be used. Problems can arise if an eSIM is reserved for a UICC by a particular eSIM server, but a trusted list of the UICC does not initially identify the particular eSIM server.

Embodiments disclosed herein avoid these problems by updating a trusted list on an as-needed basis or, in other words, on an on-demand basis. If an eSIM is requested, via a device on which a UICC is present, from a server that may not be trusted by the UICC, the trusted list is updated to allow provisioning of the UICC with the requested eSIM. Before describing the methods, servers, and devices involved with this solution, eSIM provisioning and PKI techniques will be described to aid in the subsequent discussion.

A function which provides profile packages is known as a subscription manager data preparation (SM-DP, or SM-DP+). An SM-DP may also be referred to as a profile provider, an eSIM server, an eSIM delivery server, or as an eSIM vendor. An eSIM is an electronic SIM. A physical SIM can be an electronic card, which can be inserted into a wireless device. An eSIM is an example of a profile. A profile package can be a personalized profile using an interoperable description format that is transmitted to a UICC as the basis for loading and installing a profile. Profile data which is unique to a subscriber, e.g., a phone number or an International Mobile Subscriber Identity (IMSI), are examples of personalization data. The SM-DP communicates over an interface with a UICC. Certificates used for authentication and confidentiality purposes can be generated by a trusted certificate issuer.

Some aspects of an SE will be described here with respect to a UICC. A UICC includes an operating system, and the operating system can include ability to provide authentication algorithms to network access applications associated with a given operator. The operating system also can include the ability to translate profile package data into an installed profile using a specific internal format of the UICC. In some embodiments, the UICC is an embedded UICC (eUICC). An ISD-P (issuer security domain-profile) can host a unique profile within a UICC. The ISD-P is a secure container or security domain for the hosting of the profile. The ISD-P is used for profile download and installation based on a received bound profile package. A bound profile package is a profile package which has been encrypted for a target UICC. An ISD-R (issuer security domain-root) is a function in a eUICC responsible for the creation of new ISD-Ps on the UICC. An ECASD (embedded UICC controlling authority security domain) provides secure storage of credentials required to support the security domains on a UICC. A controlling authority security domain (CASD) may also be referred to as a “key store” herein. A security domain within the UICC contains the operator's over the air (OTA) keys and provides a secure OTA channel. OTA keys are credentials used by an operator for remote management of operator profiles on a UICC.

Some activities related to a UICC resident in a device may be performed by the device. Examples of such activities are profile download assistance and local user interface functions. More information on profile download assistance and local user interface functions can be found in SGP.22.

Public Key Infrastructure Techniques

Communications of a UICC may be authenticated using PKI techniques. The techniques disclosed herein are applicable to eUICCs, UICCs, and SEs. Certificates used for authentication and confidentiality purposes can be generated by a trusted certificate issuer (CI or root CA). A public-key certificate may also be referred to herein simply as a certificate.

A user may store a copy of a certificate, where the certificate holds the name of a given party (user identity). The public key recorded in the certificate can be used to check the signature on a message signed using a PKI private key of the given party. A user or message recipient may use an on-line protocol such as on-line certificate status protocol (OCSP) to determine if a certificate is valid.

The UICC operating system can include ability to provide authentication algorithms to network access applications associated with a given operator. The operating system also can include the ability to translate profile package data into an installed profile using a specific internal format of the UICC. An ECASD provides secure storage of credentials required to support the security domains on the UICC. A controlling authority security domain (CASD) may also be referred to as a “key store” herein.

System

FIG. 1illustrates a system100in which an end user120, in communication with a data plan server140via the Internet190, selects a carrier data plan from a particular cellular carrier using a device110. After selection of the carrier data plan, the carrier server130, in some embodiments, sends a message to eSIM server150requesting that an eSIM be reserved corresponding to the selected carrier data plan. A UICC101is associated with, and is within, the device110. In some embodiments, the UICC101is an embedded UICC (eUICC). In some instances, the particular cellular carrier uses an eSIM server160that is not indicated as trusted by a trusted list in the UICC101. Embodiments described with respect to one or more entities shown inFIG. 1update a trusted list in the UICC101. Provisioning of an eSIM in the UICC101corresponding to the selected carrier data plan then proceeds.

In some embodiments, the device110is a portable wireless device such as a smart phone or a tablet. The device110includes a device operating system (OS)111, a key store112, and a user interface113. The UICC includes a UICC OS102and a secure memory103. The device OS111communicates with the UICC101via an interface115and with the key store112via an interface116. The user interface is coupled to the UICC101by an interface117and with an end user120by an interface125.

The eSIM server150is associated with a certificate authority (CA)170. System100also includes an eSIM server160, which may be a third-party eSIM server. The eSIM server160may distribute a PKI certificate signed by the CA180. In some instances, the UICC101does not recognize the public key of CA180or of eSIM server160. That is, in some instances, CA180and eSIM server160are not initially represented on the trusted list of UICC101.

FIG. 1is a system diagram; some aspects are represented in schematic form. Connections to the Internet are represented as191,192,193,194, and195for the device110, the carrier server130, the data plan server140, the eSIM server160, and the eSIM server150, respectively. CA170and CA180also have access (not shown) to Internet190. CA170communicates with the eSIM server150using an interface155and CA180communicates with the eSIM server160by an interface165.

The carrier server130, in some embodiments, is hosted by SoftBank Group Corp. The eSIM server150, in some embodiments, is hosted by the manufacturer of the device110. Examples of the eSIM server160are servers hosted by Oberthur Technologies, Giesecke and Devrient (“G&D”) or Gemalto N.V. Examples of carriers are AT&T, T-Mobile, and Sprint.

Trusted List Logic

FIG. 2illustrates logic200for updating a trusted list on an on-demand basis. At201, a user of a device housing a UICC chooses a data plan from a carrier. The carrier uses, in some instances, an eSIM server not represented, at the time of the user selection, in a trusted list of the UICC. At202, the device receives a policy update indicating that the eSIM server is to be added to the trusted list in the UICC. The trusted list is updated accordingly. At203, the device downloads an eSIM corresponding to the chosen data plan from the eSIM server. Based on the updated trusted list, the UICC is able to authenticate the cryptographic signature of the eSIM server. The UICC then permits the download and provisioning of the UICC with the eSIM corresponding to the chosen data plan to be completed.

Use of Trusted List

FIG. 3illustrates a view300of portions of the system100. UICC101communicates with the eSIM server150via an interface311and the eSIM server160via an interface314. Communication by the UICC101is via the device110(not shown inFIG. 3, seeFIGS. 1, 9, and 10). Secure memory103of the UICC101holds a copy of the PKI certificate306of the CA170. In some instances, the CA170and the eSIM server150are the same server. The UICC101trusts CA170. Thus, CA170, in some embodiments, is identified by a name, public key from the certificate306, object identifier (OID), common name, or other identifier in a trusted list301in the secure memory103. Secure memory103also holds the PKI public key-private key pair of the UICC101, in particular, public key308-private key309of UICC101. UICC101cryptographically signs messages, in some embodiments, using the private key309. Other parties, such as the eSIM server150, are able to authenticate those messages using the public key308.

The UICC101uses the trusted list301to keep track of servers that it can trust. If the UICC101receives a communication from a server with a given name, and the given name does not correspond to any entry on the trusted list301, then the UICC101will ignore that communication. For example, if a malicious server sends a provisioning command to the UICC101, the UICC101will not execute the provisioning command because the malicious server is not represented in the trusted list301. The entries on the trusted list301, in some embodiments, include common names of servers. A common name is a value that, in some instances, appears in a PKI certificate, such as an X.509 certificate. X.509 is an International Telecommunication Union (ITU) PKI certificate standard. The common name value can be used to identify the subject of the certificate. Another identifier is a distinguished name, which is a fully-qualified domain name of the server that the certificate is for. An object identifier (OID) listed with a registration entity may be used to identify a server. Other names appearing in the trusted list301may be associated with the Global Platform (GP) family of standards.

Tables 1 and 2 provide examples of trusted list301in the UICC101before and after addition of the eSIM server160to the trusted list301. In Table 2, a common name (CN) of the eSIM server160has been added to the trusted list. In this example, the eSIM server160is hosted by G&D and the common name of the eSIM server160is GD L3.

The UICC101, in some embodiments, also maintains an untrusted list. An untrusted list can represent a list of entities, servers, CAs, or CIs, for example, which the UICC101does not trust. For example, presence of an entity identity or user identity on the untrusted list can indicate to the UICC101that there is no unexpired or unrevoked certificate for that entity stored in the UICC101.

UICC101, in some embodiments, updates trusted list301and, if maintained, the untrusted list, based on events. For example, a given entity identified on the untrusted list may become a trusted entity if a trusted third party, such as a CI or a CA trusted by the UICC101, provides a signed certificate for the given entity.

Message Flow Overview

FIG. 4is an exemplary message flow diagram showing some messages and activities associated with updating a trusted list subsequent to a user selecting a carrier data plan. Additional details are provided inFIG. 8. Entities are indicated across the top ofFIG. 4, and time advances from top to bottom as indicated on a time axis420. At a time t1, the end user120selects a carrier data plan and a plan identifier is sent in a message401from the device110to the carrier server130. A “Reserve and Bind eSIM” event402then occurs around the time t2involving: i) the carrier server130sends an instruction to the eSIM server150asking that an eSIM be reserved, ii) the eSIM server150determines that the selected carrier uses eSIM server160for distribution of eSIMs, iii) the eSIM server150forwards the eSIM reservation request to the eSIM server160, iv) the eSIM server160reserves an eSIM with an identifier value ICCID-value, v) the carrier server130activates service for ICCID-value in carrier billing systems, vi) the carrier server130issues a bind command based on the pairing of ICCID-value with an identifier of the UICC (for example, a CSN or an EID value), vii) the eSIM server150forwards the bind command to the eSIM server160, viii) the eSIM server160performs the bind operation to create a BPP and stores the BPP until such time as the device110sends a request to download the BPP, and ix) the eSIM server150sends a bind confirmation message to the carrier server130confirming that the ICCID-value is bound to UICC101.

Also near the time t2, the eSIM server150determines whether the UICC101trusts the eSIM server160. If not, the eSIM server150recognizes that a policy update should be performed for the UICC101so that the UICC101will trust the eSIM server160when the BPP is downloaded from the eSIM server160to the device110housing the UICC101.

After receiving the bind confirmation message, the carrier server130sends a plan confirmation in message403at time t3to the device110. The device110then recognizes that a profile download should be performed. The device110sends a policy inquiry in a message404at time t4to get policy updates. At a time t5, policy updates are delivered in a message405to the UICC101via the device110. The policy update includes a list of server identifiers; the list identifies one or more trusted servers that the UICC101is to add to the trusted list301. Upon receiving the message405, the UICC101updates the trusted list301; the trusted list301now includes an identifier of the eSIM server160; for an example updated list, see Table 2. At a time t6, the device110continues with the profile download. Initially a message is sent (seeFIG. 8) to the eSIM server150requesting pending eSIMs, and the eSIM server150replies to the device110with information that the message should be redirected to the eSIM server160. The device110then sends, based on the redirection information, a message406requesting that pending eSIMs be delivered. The redirection can be based on a name or address of the eSIM server160. Based on the redirection, the device110confirms with the UICC101whether the eSIM server160is trusted; see the event407at time t7: “Verify Trust of Server160.” Based on the updated trust list301, the UICC101confirms to the device110that eSIM server160is trusted.

At a time t8, the eSIM server160sends a data blob include the BPP containing the eSIM with identifier ICCID-value. The eSIM is in encrypted form. At a time t9, the device110and UICC101perform event409, “eSIM Installation,” including verification of the signature of the eSIM server160by the UICC101. The UICC101proceeds to the signature verification because the trusted list301includes an identifier of the eSIM server160. After the eSIM installation, the end user120begins using device110with the new carrier plan, supported by UICC101.

Host eSIM Server Logic

FIG. 5illustrates exemplary host eSIM server logic500. At501, an eSIM server that provides some eSIM types but not some other eSIM types receives a request for an eSIM of a first type from a device. At502, the first eSIM server determines an eSIM server decision value. If the eSIM server decision value indicates that the first eSIM server hosts the first type of eSIM, then the logic flows to503. At503, the first eSIM server downloads an eSIM of the first type to the device. If the decision value indicates that the first eSIM server does not host the first type of eSIM, then the logic flows from502to504. At504, the first eSIM server requests that an eSIM of the first type be reserved by a second eSIM server. At505, the first eSIM server sends a policy update message to a UICC associated with the device; the policy update directs the UICC to update a trusted list to include an identity of the second eSIM server.

Device Logic

FIG. 6provides exemplary logic600for a device to request a data plan from a carrier, update a trusted list based an eSIM needed for the requested data plan, and download the eSIM. At601, the device sends a plan identifier to a carrier billing server. At602, the device receives a policy update indicating that an eSIM server is to be trusted. At603, the device sends the policy update to the UICC of the device. At604, the device receives a data blob including a bound profile package (BPP). The BPP contains an encrypted eSIM associated with the carrier and the data plan. At605, the device sends the data blob, or a portion of it, to the UICC to authenticate the PKI signature of the eSIM server. This authentication succeeds because the eSIM server is now on the trusted list in the UICC. At606, the device installs the eSIM on the UICC.

UICC Logic

FIG. 7provides exemplary logic700for a UICC to receive an on-demand update to a trusted list and install an eSIM from a server identified on the updated trusted list. At701, the UICC receives a policy message indicating that an eSIM server is to be trusted. At702, the UICC adds an identifier of the eSIM server to a trusted list. At703, the UICC receives, from the device, a trust inquiry message providing an identifier of the eSIM server. The UICC finds the eSIM server identifier on the trusted list, and at704, confirms to the device that the eSIM server is trusted. At705, the UICC verifies the signature of the eSIM server on a data blob received at the UICC from the eSIM server via the device. At706, the UICC installs the eSIM from the data blob in the memory of the UICC.

Detailed Message Flow

FIG. 8provides a message flow800, which is a more detailed version of the message flow400shown inFIG. 4. Messages shown inFIG. 4which are shown again inFIG. 8use the same reference numerals in both. For example,FIG. 4illustrates a message401“Plan Identifier.” Message401occurs also inFIG. 8. Some events ofFIG. 4are replaced with a number of messages inFIG. 8. For example, the substance of theFIG. 4event402“Reserve and Bind eSIM,” occurs inFIG. 8with the events in messages831,851,861,832,833,834,852,853, and854. In other words,FIG. 4presents an overall message flow, andFIG. 8presents an exemplary embodiment with additional details.

Time advances from top to bottom inFIG. 8; for simplicity, a time axis is not shown. The detailed message flow800commences with event810at the device110, “810, Setup Cellular Data.” End user120, in some embodiments, taps an input field denoted something to the effect of “set up cellular data” on a display of the device110. The device sends message811to get available carrier data plans from a data plan purchase server810. The device receives message812with indications of the available plans based on the current location of the device. At813, the end user120makes a plan selection. A plan identifier is sent in message401to a web site provided by the selected carrier on a carrier server130. The end user120is then presented with a web site display of the web site. The end user120purchases the plan directly through the carrier web site. The carrier, in some embodiments, accepts payment directly from the end user120.

The carrier server130sends a message831requesting an eSIM, corresponding to the plan, to the eSIM server150. The eSIM server150, in some embodiments, is a host eSIM server hosted by a manufacturer of the device110. The eSIM server150determines that the requested eSIM is not provided by the eSIM server150, but is provided by the eSIM server160. The eSIM server150forwards the eSIM request as message851to the eSIM server160. The eSIM server160reserves an eSIM and sends message861including an identifier of the eSIM, e.g., an ICCID value identifying eSIM901(FIG. 9illustrates some features of the eSIM901on the UICC101after installation). The eSIM server150forwards the eSIM901identifier to the carrier server130in message832.

At event833, the carrier server130activates service for the device110with the eSIM901on carrier billing systems. Message834is a bind eSIM command to the eSIM server150, which is forwarded to the eSIM server160in message852. The bind command confirms the UICC and eSIM pairing. The eSIM server160binds the eSIM901to the UICC101to create a BPP. The BPP then rests at the eSIM server160until such time as device110seeks to download the BPP.

The eSIM server150then checks whether the UICC101trusts the eSIM server160. If not, event853is registered by the eSIM server150indicating that a policy update of the UICC101should occur. Message854indicates to the carrier server130that the eSIM901is bound to the UICC101. The carrier server130then sends a plan confirmation message403to the device110. The device110then registers a state indicating that an eSIM should be downloaded. This state is shown as event814“Trigger eSIM Download” inFIG. 8.

Based on the event814, which is indirectly responsive to the end user120event810“Setup Cellular Data,” the device110sends policy inquiry404to the eSIM server150asking for any policy updates. The eSIM server150has registered the event853, and so sends a policy update405. Message405may be referred to as a push of policies down to the device. Device110forwards the policy update as message815to a policy control function (PCF) of the UICC101. The UICC101then updates the trusted list301and sends a message801to the device110indicating that the trusted list of server names (FIG. 3, reference numeral301) has been updated.

Continuing with the sequence initiated by the event814“Trigger eSIM Download,” the device110sends a message816to the eSIM server150to obtain one or more pending eSIMs. The eSIM server150sends message855redirecting the device110to the eSIM server160. The device110then sends message817(“Trust Inquiry”) to the UICC101to confirm that the eSIM server160is trusted by the UICC101. Based on the updated trusted list301, the UICC101sends positive confirmation message802, “Trust Confirmation.”

In response to message406, the eSIM server160begins the download process of the BPP containing eSIM901to the device110(and ultimately the UICC101).818indicates installation of the eSIM901on the UICC101.818is a schematic figure indication, there are a number of events related to eSIM installation. For more details about installation of an eSIM, see SGP.22. After installation of the eSIM901, the UICC101confirms the installation with the message803.

At event813, end user120commences to use their device110based on authentication, encryption, and application services and functions provided in their data plan as supported by the eSIM901downloaded from the eSIM server160. The end user120has selected a carrier data plan in a user-friendly manner from a carrier of their choice. Download of the eSIM901has been enabled by an on-demand update of the trusted list in the UICC101to establish trust in the carrier's selected eSIM server, the eSIM server160. The device110now functions just as if a traditional physical SIM card had been installed after selection of a carrier.

SE Details

FIG. 9illustrates a system900with details of the UICC101including the eSIM901. The eSIM901is installed in the UICC101of the device110as indicated inFIG. 2at203,FIG. 4at409,FIG. 6at606,FIG. 7at706, andFIG. 8at818. The UICC101includes the operating system102. Within the operating system102is a telecom framework911which provides authentication algorithms to network access applications (such as NAAs905). Interpreter912translates profile package data into an installed profile using a specific internal format of the UICC101. ISD-P902hosts a profile, i.e., eSIM901. The ISD-P is a secure container (security domain) for the hosting of the eSIM901. The ISD-P is used for eSIM download and installation in collaboration with the interpreter912for the decoding of a received BPP. An issuer security domain (not shown) on the UICC101is responsible for the creation of new ISD-Ps on the UICC101and the lifecycle management of all ISD-Ps on the UICC101. Secure memory103, which can be an ECASD, provides secure storage of credentials required to support the security domains on UICC101. MNO-SD903is the representative on the UICC101of the operator providing services via the eSIM901to the end user120. The MNO-SD903contains the operator's OTA keys and provides a secure OTA channel. Further description of profile (eSIM) management can be found in SGP.22.

Example Device Connections

FIG. 10illustrates example connection methods for on-demand update of a trusted list in a UICC in a system1000. End user120can manage device110using interface918which can convey end user actions such as requesting a new carrier plan as described with respect toFIGS. 2, 4, 5, and 8, for example. The end user120can also remotely manage device110via the Internet190using interface934. The device110is shown connected to a wireless base station960. The wireless base station960communicates with the device110via a wireless link966. The wireless base station960can be an Institute of Electronic and Electrical Engineers 802.11 Wireless Fidelity (IEEE 802.11 Wi-Fi) access point (AP) or the wireless base station960can be, for example, a cellular mobile network base station. Examples of cellular mobile network base stations are a 2G or 3G base station or an LTE eNode B.

A data blob with the eSIM901in encrypted form, in some embodiments, is downloaded from the eSIM server160to the device110. The UICC101accepts the data blob based on finding an identity of the eSIM server160on the updated trusted list301. After deployment of the eSIM901, the end user120can now enjoy their requested carrier data plan or wireless service using the eSIM901.

Variety of Radio Access Technologies

Wireless devices, and mobile devices in particular, can incorporate multiple different radio access technologies (RATs) to provide connections through different wireless networks that offer different services and/or capabilities. A wireless device can include hardware and software to support a wireless personal area network (“WPAN”) according to a WPAN communication protocol, such as those standardized by the Bluetooth® special interest group (“SIG”) and/or those developed by Apple referred to as an Apple Wireless Direct Link (AWDL). The wireless device can discover compatible peripheral wireless devices and can establish connections to these peripheral wireless devices located in order to provide specific communication services through a WPAN. In some situations, the wireless device can act as a communications hub that provides access to a wireless local area network (“WLAN”) and/or to a wireless wide area network (“WWAN”) to a wide variety of services that can be supported by various applications executing on the wireless device. Thus, communication capability for an accessory wireless device, e.g., without and/or not configured for WWAN communication, can be extended using a local WPAN (or WLAN) connection to a companion wireless device that provides a WWAN connection. Alternatively, the accessory wireless device can also include wireless circuitry for a WLAN connection and can originate and/or terminate connections via a WLAN connection. Whether to use a direct connection or a relayed connection can depend on performance characteristics of one or more links of an active communication session between the accessory wireless device and a remote device. Fewer links (or hops) can provide for lower latency, and thus a direct connection can be preferred; however, unlike a legacy circuit-switched connection that provides a dedicated link, the direct connection via a WLAN can share bandwidth with other wireless devices on the same WLAN and/or with the backhaul connection from the access point that manages the WLAN. When performance on the local WLAN connection link and/or on the backhaul connection degrades, a relayed connection via a companion wireless device can be preferred. By monitoring performance of an active communication session and availability and capabilities of associated wireless devices (such as proximity to a companion wireless device), an accessory wireless device can request transfer of an active communication session between a direction connection and a relayed connection or vice versa.

In accordance with various embodiments described herein, the terms “wireless communication device,” “wireless device,” “mobile device,” “mobile station,” “wireless station”, “wireless access point”, “station”, “access point” and “user equipment” (UE) may be used herein to describe one or more common consumer electronic devices that may be capable of performing procedures associated with various embodiments of the disclosure. In accordance with various implementations, any one of these consumer electronic devices may relate to: a cellular phone or a smart phone, a tablet computer, a laptop computer, a notebook computer, a personal computer, a netbook computer, a media player device, an electronic book device, a MiFi® device, a wearable computing device, as well as any other type of electronic computing device having wireless communication capability that can include communication via one or more wireless communication protocols such as used for communication on: a wireless wide area network (WWAN), a wireless metro area network (WMAN) a wireless local area network (WLAN), a wireless personal area network (WPAN), a near field communication (NFC), a cellular wireless network, a fourth generation (4G) LTE, LTE Advanced (LTE-A), and/or 5G or other present or future developed advanced cellular wireless networks.

The wireless device, in some embodiments, can also operate as part of a wireless communication system, which can include a set of client devices, which can also be referred to as stations, client wireless devices, or client wireless devices, interconnected to an access point (AP), e.g., as part of a WLAN, and/or to each other, e.g., as part of a WPAN and/or an “ad hoc” wireless network, such as a Wi-Fi direct connection. In some embodiments, the client device can be any wireless device that is capable of communicating via a WLAN technology, e.g., in accordance with a wireless local area network communication protocol. In some embodiments, the WLAN technology can include a Wi-Fi (or more generically a WLAN) wireless communication subsystem or radio, the Wi-Fi radio can implement an Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology, such as one or more of: IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; IEEE 802.11ax; or other present or future developed IEEE 802.11 technologies.

Additionally, it should be understood that the wireless devices described herein may be configured as multi-mode wireless communication devices that are also capable of communicating via different third generation (3G) and/or second generation (2G) RATs. In these scenarios, a multi-mode wireless device or UE can be configured to prefer attachment to LTE networks offering faster data rate throughput, as compared to other 3G legacy networks offering lower data rate throughputs. For instance, in some implementations, a multi-mode wireless device or UE may be configured to fall back to a 3G legacy network, e.g., an Evolved High Speed Packet Access (HSPA+) network or a Code Division Multiple Access (CDMA) 2000 Evolution-Data Only (EV-DO) network, when LTE and LTE-A networks are otherwise unavailable.

Representative Exemplary Apparatus

FIG. 11illustrates in block diagram format an exemplary computing device1100that can be used to implement the various components and techniques described herein, according to some embodiments. In particular, the detailed view of the exemplary computing device1100illustrates various components that can be included in the eSIM server150, the device110, or the UICC101ofFIG. 1, 2, 9, or10. As shown inFIG. 11, the computing device1100can include a processor1102that represents a microprocessor or controller for controlling the overall operation of computing device1100. In some embodiments, the computing device1100can also include a user input device1108that allows a user of the computing device1100to interact with the computing device1100. For example, in some embodiments, the user input device1108can take a variety of forms, such as a button, keypad, dial, touch screen, audio input interface, visual/image capture input interface, input in the form of sensor data, etc. In some embodiments, the computing device1100can include a display1110(screen display) that can be controlled by the processor1102to display information to the user (for example, information relating to incoming, outgoing, or active communication session). A data bus1116can facilitate data transfer between at least a storage device1140, the processor1102, and a controller1113. The controller1113can be used to interface with and control different equipment through an equipment control bus1114. The computing device1100can also include a network/bus interface1111that couples to a data link1112. In the case of a wireless connection, the network/bus interface1111can include wireless circuitry, such as a wireless transceiver and/or baseband processor. The computing device1100can also include a secure element1150. The secure element1150can include a eUICC or UICC.

The computing device1100also includes a storage device1140, which can comprise a single storage or a plurality of storages (e.g., hard drives), and includes a storage management module that manages one or more partitions within the storage device1140. In some embodiments, storage device1140can include flash memory, semiconductor (solid state) memory or the like. The computing device1100can also include a Random Access Memory (“RAM”)1120and a Read-Only Memory (“ROM”)1122. The ROM1122can store programs, utilities or processes to be executed in a non-volatile manner. The RAM1120can provide volatile data storage, and stores instructions related to the operation of the computing device1100.

The various aspects, embodiments, implementations or features of the described embodiments can be used separately or in any combination. Various aspects of the described embodiments can be implemented by software, hardware or a combination of hardware and software. The described embodiments can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, hard storage drives, solid state drives, and optical data storage devices. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.