Patent Grant
11553328
This application is a Submission Under 35 U.S.C. § 371 for U.S. National Stage Patent Application of International Application No.: PCT/EP2018/056686, filed Mar. 16, 2018 entitled “METHODS, DEVICES, AND COMPUTER PROGRAMS FOR PROVISIONING OR CONTROLLING OPERATOR PROFILES IN TERMINALS,” which claims priority to European Application No.: 18382112.3, filed Feb. 26, 2018, the entireties of both of which are incorporated herein by reference.
The present invention relates to methods for provisioning and/or controlling operator profiles in terminals, and to methods for participating in doing so. The invention also relates to devices for carrying out such methods, and to computer programs therefor. Some embodiments of the invention may for example be used in a telecommunication network supporting embedded subscriber identity modules (eSIM) and remote subscriber identity module (SIM) provisioning (RSP).
A SIM is an integrated circuit containing information for identifying and authenticating subscribers of terminals, such as mobile phones, to enable them access a mobile communication network. SIM cards are well known and widely used.
In the meantime, the GSM Association (GSMA) has defined an architecture (“Embedded SIM Remote Provisioning Architecture”, GSM Association, Official Document SGP.01, Version 1.1, 30 Jan. 2014; hereinafter referred to as “SGP.01”, and available at the time of writing from www.gsma.com/newsroom/all-documents/sgp-01-embedded-sim-remote-provisioning-architecture-v1-1/) and related technical specification (“Remote Provisioning Architecture for Embedded UICC Technical Specification”, GSM Association, Official Document SGP.02, Version 3.2, 27 Jun. 2017; hereinafter referred to as “SGP.02”, and available at the time of writing from www.gsma.com/newsroom/all-documents/sgp-02-v3-2-remote-provisioning-architecture-for-embedded-uicc-technical-specification/) for remote SIM provisioning (RSP) directed to machine-to-machine (M2M) devices. SGP.01 defines a mechanism for “over-the-air” (OTA) remote provisioning of M2M devices with credentials to gain mobile network access (SGP.01, section 1.1). Remotely provisioning M2M devices is desirable, because such devices may not be easily reachable to provision a subscription.
Another GSMA architecture (“RSP Architecture”, GSM Association, Official Document SGP.21, Version 2.2, 1 Sep. 2017; hereinafter referred to as “SGP.21”, and available at the time of writing from www.gsma.com/newsroom/all-documents/sgp-21-rsp-architecture-v2-2/) and related technical solution (“RSP Technical Specification”, GSM Association, Official Document SGP.22, Version 2.2, 1 Sep. 2017; hereinafter referred to as “SGP.22”, and available at the time of writing from www.gsma.com/newsroom/all-documents/sgp-22-v2-2-technical-specification/) have been defined for consumer devices, i.e. devices for the consumer market (SGP.21, section 1.1). The architecture is illustrated in SGP.2.2, p. 19, FIG. 1. It enables remote (e.g., OTA) provisioning of eUICC-capable devices with mobile network operator (MNO) profile (e.g. authentication key (Ki), MNO network access configuration etc.) to gain mobile network access.
In that architecture, a so-called “Subscription Manager Data Preparation+” (SM-DP+) is responsible for device MNO profile handling (creation, generation, management, protection, delivery) upon the input/request of MNO. The SM-DP+ is also the off-card entity “responsible for the lifecycle management of the ISD-P [Issuer Security Domain-Profile]” (SGP.21, section 4.10.1). In short, SM-DP+ is the sender of MNO profile in that architecture.
Besides, a so-called “Subscription Manager—Discovery Service” (SM-DS) provides mechanisms that allow an SM-DP+ to inform any eUICC device that an SM-DP+ wishes to communicate (SGP.21, section 4.12.1).
On the device, a Local Profile Assistant (LPA) provides three distinct functions, the Local User Interface (LUI), the Local Profile Download (LPD), and the Local Discovery Service (LDS) (SGP.21, section 4.11.1).
It is desirable to improve the prior art methods notably by providing efficient profile provisioning and control mechanisms that can be performed in a variety of situations and configurations, such as when there is no end user behind a device (e.g. a M2M device).
To meet or at least partially meet the above-mentioned goals, methods, network nodes, and terminals according to the invention are defined in the independent claims. Particular embodiments are defined in the dependent claims.
In one embodiment, a method is carried out by a network node, hereinafter referred to as “discovery server” (DS), for participating in provisioning and/or controlling operator profiles in terminals, each terminal comprising an integrated circuit card identified by an integrated circuit card identifier. The method comprises the following. The DS is configured with a plurality of associations, hereinafter collectively referred to as “authorization table”, wherein each association comprises: (i) an integrated circuit card identifier; (ii) a service provider identifier (SPID) for identifying a service provider (SP) in charge of a terminal comprising an integrated circuit card identified by the integrated circuit card identifier; and, (iii) for each of at least one operator authorized to handle profiles of the integrated circuit card, an operator identifier. The DS receives, from another network node, hereinafter referred to as “data preparation node” or simply “DP node”, a request, hereinafter referred to as “event registration request”, comprising: (a) an integrated circuit card identifier; (b) a SPID; (c) an operator identifier; and (d) a DP node identifier for identifying the DP node. The DS determines that the received integrated circuit card identifier, the received SPID, and the received operator identifier are associated with one another in the authorization table; and the DS then registers an event record comprising the received integrated circuit card identifier, SPID, and DP node identifier.
This enables the registering of an event record at the discovery server (DS), which a terminal may then retrieve in order to perform a profile operation. This also enables, in particular, the network to initiate the performance of a profile operation at the terminal, without participation of an end user behind the terminal or when there is no end user behind the terminal (e.g. a M2M device).
In one embodiment, the event registration request further comprises an event identifier for identifying the event to be registered; and the event record registered by the DS further comprises the received event identifier.
In another embodiment, registering the event record further comprises: the DS assigning an event identifier for identifying the event record; and the DS sending the event identifier to the DP node.
In one embodiment, after event registration as described above, the DS further receives from a terminal a request for an available event. The request comprises the integrated circuit card identifier and the SPID. The DS then determines that the event record comprises the received integrated circuit card identifier and SPID, and the DS sends, to the terminal, the DP node identifier comprised in the event record. This enables the terminal to query the DP node for information about a profile operation to be performed at the terminal. In an embodiment, the DS may send, to the terminal, the event identifier.
The invention also relates, in one embodiment, to a discovery server (DS) configured to perform any of the above-described methods.
The invention further relates, in one embodiment, to a method carried out by a data preparation (DP) node for participating in provisioning and/or controlling operator profiles in terminals, each terminal comprising, as mentioned above, an integrated circuit card identified by an integrated circuit card identifier. The method comprises the following. The DP node receives a request to perform a profile operation. The request comprises: (I) an integrated circuit card identifier; (II) a SPID; (Ill) an operator identifier; and (IV) information relating to the profile operation to be performed. The DP node sends, to a discovery server (DS), an event registration request comprising: (a) the received integrated circuit card identifier; (b) the received SPID; (c) the received operator identifier; and (d) a DP node identifier for identifying the DP node; and the DP node associates the integrated circuit card identifier, the SPID, and an indication of the profile operation to be performed, with one another.
In one embodiment, the event registration request further comprises an event identifier for identifying the event to be registered; and associating, by the DP node, the integrated circuit card identifier, the SPID, and the indication of the profile operation to be performed, with one another, further comprises: the DP node associating the event identifier with the integrated circuit card identifier, the SPID, and the indication of the profile operation.
In another embodiment, the method further comprises the DP node receiving, from the DS, an event identifier. In addition, associating, by the DP node, the integrated circuit card identifier, the service provider identifier, and the indication of the profile operation to be performed with one another, further comprises: associating the received event identifier with the integrated circuit card identifier, the service provider identifier, and the indication of the profile operation.
In one embodiment, after having sent an event registration request to the DS, the DP node receives, from a terminal, a request for a profile operation comprising the above-mentioned event identifier. The DP node then determines that the event identifier is associated with the indication of the profile operation to be performed; and the DP node sends, to the terminal, the indication of the profile operation to be performed determined to be associated with the event identifier. This enables the terminal to receive information about a profile operation to be performed.
In another embodiment, after having sent an event registration request to the DS, the DP node receives, from a terminal, a request for a profile operation comprising the integrated circuit card identifier and the SPID. The DP node then determines that the integrated circuit card identifier and the SPID are associated with the indication of the profile operation to be performed; and the DP node sends, to the terminal, the indication of the profile operation to be performed determined to be associated with the integrated circuit card identifier and the SPID. This also enables the terminal to receive information about a profile operation to be performed.
The invention also relates, in one embodiment, to a data preparation (DP) node configured to perform any of the above-described methods.
The invention further relates, in one embodiment, to a method carried out by a terminal for allowing provisioning and/or controlling operator profiles in the terminal, the terminal comprising, as mentioned above, an integrated circuit card identified by an integrated circuit card identifier. The method comprises the following. The terminal sends, to a discovery server (DS), a request for an available event, wherein the request comprises the integrated circuit card identifier for identifying the integrated circuit card comprised in the terminal, and a SPID for identifying a service provider in charge of the terminal. The terminal then receives, from the DS, a DP node identifier for identifying a DP node. The terminal then sends, to the DP node identified by the DP node identifier, a request for a profile operation. The terminal eventually receives, from the DP node, an indication of a profile operation to be performed; and it performs the indicated profile operation.
The invention also relates, in one embodiment, to a terminal configured to perform the above-described method.
The invention further relates, in one embodiment, to a method performed by at least two of, or by all of, a discovery server (DS), a data preparation (DP) node, and a terminal, according to any of the above-described embodiments.
The invention also relates to a system comprising two of, or all of, a DS, a DP node, and a terminal, as described above.
The invention also relates to computer programs, computer program products and storage mediums comprising computer-readable instructions configured, when executed on network nodes and/or terminals, to cause the network nodes and/or terminals to carry out a method according to any one of the above-described embodiments, or to implement the functions of a network node or terminal according to any one of the above-described embodiments.
Embodiments of the present invention shall now be described, in conjunction with the appended figures, in which:
The present invention shall now be described in conjunction with specific embodiments. These specific embodiments serve to provide the skilled person with a better understanding, but are not intended to in any way restrict the scope of the invention, which is defined by the appended claims. A list of abbreviations and their meaning is provided at the end of the detailed description.
The method aims at preparing the provisioning and/or controlling of operator profiles in terminals 300, wherein each terminal 300 comprises an integrated circuit card 301 identified by an integrated circuit card identifier. In one embodiment, provisioning an operator profile in a terminal 300 involves providing credentials to be stored in the terminal's 300 integrated circuit card 301 so that the terminal 300 may communicate over the mobile communication network controlled by the operator. In one embodiment, controlling (also called “managing”) an operator profile in a terminal 300 involves changing the status or parameters of, or deleting, an operator profile stored in the terminal's 300 integrated circuit card 301. In one embodiment, a profile comprises data and applications to be provisioned onto, or present on, a terminal's 300 integrated circuit card 301, for the purpose of providing services to the terminal 300, such as providing mobile communication access to the terminal 300.
Terminal 300 may be any type of communication terminal (or user equipment (UE)) such as, for example, a machine-to-machine (M2M) device (e.g., a M2M device included in a utility meter, a sensor, an actuator, a car, or a camera), a mobile phone, a smartphone, a laptop, a desktop computer, a tablet PC, a watch phone, a gaming device, an e-book reader, a fixed telephone, an IoT device, etc. In one embodiment, terminal 300 is self-operable and does not require a human operating the device for communicating with a telecommunications system. In one embodiment, terminal 300 is a piece of equipment into which an eUICC and a communication module are inserted during assembly. By “eUICC”, i.e. embedded UICC, it is meant here “[a] UICC which is not easily accessible or replaceable, is not intended to be removed or replaced in the terminal, and enables the secure changing of Subscriptions” (SGP.01, section 1.5). An eUICC is also referred to in the art as an embedded SIM (eSIM). In that respect, DP node 200 may be regarded as a profile manager to initiate profile provisioning and/or management in the eUICC of a terminal 300, whereas DS 100 is used to trigger the terminal 300 to connect to DP node 200 so that the profile operation can be pushed to the terminal 300. At the same time, DS 100 is also used to enforce authorization within the procedure.
The method illustrated in
In step 2, DS 100 is configured with a plurality of associations, here collectively referred to as “authorization table”. In one embodiment, the authorization table is stored in DS 100. In another embodiment, the authorization table is accessible to DS 100, although not stored therein. Each association comprises: (i) an integrated circuit card identifier; (ii) a service provider identifier (SPID) for identifying a service provider (SP) in charge of a terminal comprising an integrated circuit card identified by the integrated circuit card identifier; and, (iii) one or more operator identifiers for identifying operators authorized to handle profiles for the integrated circuit card, i.e., for each of at least one operator authorized to handle profiles of the integrated circuit card, an operator identifier.
In one embodiment, terminal 300 comprises an eUICC, and the integrated circuit card identifier is an eUICC identifier (EID), as exemplarily illustrated in
In one embodiment, a SP is an entity providing “services to its service Subscribers on a contractual basis and who is responsible for the services offered” (SGP.01, section 1.5). In that sense, the SP is in charge of terminal 300. In one embodiment, for example if terminal 300 is a M2M device, or more generally a self-operable device that does not require a human operating the device for communicating with a telecommunications system, the SP in charge of the terminal 300 is responsible for operating it. For example, the M2M device may be a utility meter, and the SP may be the utility or a meter operator. More specifically, if the M2M device is an electricity meter, the SP may be the electricity utility or a meter operator. In one embodiment, the SP is an original equipment manufacturer (OEM) or a car manufacturer.
In one embodiment, an operator is a mobile network operator (MNO), i.e. “[a]n entity providing access capability and communication services to its Customers [or Subscribers] through a mobile network infrastructure” (SGP.01, section 1.5; SGP.21, section 1.4). In that embodiment, the operator identifier is a mobile network operator identifier (MNOID), as exemplarily illustrated in
Prior to being configured with the authorization table, DS 100 may obtain or receive information making up the authorization table. For example, the DS configuration may be initiated by a network node controlled by the SP in charge of terminal 300, as described below with reference to
Referring again to
In one embodiment, DP node 200 receives the request to perform a profile operation from a network node controlled by an operator (e.g. a MNO), as will be described below with reference to
In step 6 (which may be performed in parallel with, or after, step 2), DP node 200 sends, to DS 100, an event registration request comprising: (a) the received integrated circuit card identifier, which may for example be an eUICC identifier (EID) as illustrated in
In step 8, DS 100 determines whether the received integrated circuit card identifier, the received SPID, and the received operator identifier are associated with one another in the authorization table. In other words, DS 100 determines whether the received SPID and the received operator identifier are configured for the received integrated circuit card identifier (which may for example be an EID, as mentioned above).
If so, the combination of integrated circuit card identifier, SPID, and operator identifier is authorized in the authorization table, and DS 100 registers, in step 10, an event record comprising the received integrated circuit card identifier, SPID, and DP node identifier. In other words, DS 100 registers an event record for the integrated circuit card identifier. The event record may optionally comprise information relating to the profile operation to be performed.
Otherwise (i.e., if DS 100 determines that the received integrated circuit card identifier, SPID, and operator identifier are not associated with one another in the authorization table), the combination of integrated circuit card identifier, SPID, and operator identifier is not authorized in the authorization table. In such a case, DS 100 refrains from registering any event record as a result of receiving the event registration request (not illustrated in
Optionally, in step 12, DS 100 may send an event registration confirmation to DP node 200 to indicate that the event has been registered (the dashed arrow in
In step 14, DP node 200 associates the integrated circuit card identifier, the SPID, and an indication of the profile operation to be performed, with one another, for example by storing the association in memory. In one embodiment, DP node 200 also associates the operator identifier received in step 4 with the three above-mentioned elements. In one embodiment, step 14 is performed after receiving an event registration confirmation (as illustrated in
The profile operation request, the event registration request, and the optional event registration confirmation may each be transmitted by means of a respective message, i.e. a set of bits forming a packet which can be transmitted over a communication network. They may also each be transmitted through a series of packets. They may for example each be transmitted in an IP packet. Furthermore, they may be transmitted through one or more intermediate network nodes (not illustrated in
In one embodiment (not illustrated in
In one embodiment (not illustrated in
In one embodiment (not illustrated in
In one embodiment (not illustrated in
In step 16, terminal 300 transmits, to DS 100, an event retrieval request, i.e. a request for an available event. As discussed above, terminal 300 comprises an integrated circuit card 301 identified by an integrated circuit card identifier. The event retrieval request comprises the integrated circuit card identifier of the integrated circuit card comprised in terminal 300, and a SPID for identifying a service provider in charge of terminal 300. The integrated circuit card identifier may for example be an eUICC identifier (EID), as illustrated in
In step 18, DS 100 determines whether it has a registered event record comprising the received integrated circuit card identifier, which may be an EID as mentioned above, and the received SPID. If so, in step 20, DS 100 transmits, to terminal 300, the DP node identifier comprised in the identified event record. In one embodiment, DS 100 also transmits, to terminal 300, an event identifier for identifying the event record. If DS 100 has no registered event record comprising the received integrated circuit card identifier and the received SPID, the event retrieval process may end at that stage (not illustrated in
In step 22, terminal 300 then transmits, to the DP node 200 identified by the DP node identifier, a profile operation request, i.e. request for a profile operation. In one embodiment, the profile operation request comprises the terminal's 300 integrated circuit card identifier and the SPID. In another embodiment, the profile operation request comprises the event identifier that terminal 300 may have received from DS 100. In one embodiment, the profile operation request comprises the terminal's 300 integrated circuit card identifier, the SPID, and the event identifier.
In step 24, DP node 200 identifies, based on the information it receives from terminal 300, the profile operation to be performed at terminal 300. In one embodiment, the profile operation request comprises the terminal's 300 integrated circuit card identifier and the SPID, and DP node 200 then determines that the integrated circuit card identifier and the SPID are associated with an indication of the profile operation to be performed, which DP node 200 then transmits, in step 26, to terminal 300. In another embodiment, the profile operation request comprises an event identifier, and DP node 200 then determines the event identifier is associated with the indication of the profile operation to be performed, which DP node 200 then transmits, in step 26, to terminal 300. Terminal 300 then performs, in step 28, the indicated profile operation.
Service provider (SP) 400 is in charge of terminal 300 having a given integrated circuit card identifier, hereinafter referred to as eUICC identifier (EID) (although the invention is not limited thereto). In step 1, SP 400 triggers the configuration of a DS 100 with its own identifier (SPID), with an EID, and with one or more identifiers of mobile network operator (MNO) nodes 500 authorized to handle profiles for the eUICC. As a result, in step 2, an authorization table is configured in DS 100. Table 1 shows such an exemplary authorization table.
According to Table 1, SP 400 with SPID1 has authorized MNOs to perform any profile operations on MNOA, MNOB and MNOC profiles, when it comes to integrated circuit card with identifier EID1. Furthermore, SP 400 with SPID1 has authorized MNOs to perform any profile operations on MNOA and MNOB profiles, when it comes to integrated circuit cards with identifiers EID2 and EID3.
In step 3, DS 100 may then confirm to SP 400 that the authorization table has been successfully configured, i.e. created or updated.
In one embodiment, the authorization table may also contain authorizations at the operation level. That is, DS 100 may be configured with one or more profile operations authorized to be performed by each MNO node 500. DS 100 stores this information in an authorization table. Table 2 shows such an exemplary authorization table.
According to Table 2, SP 400 with SPID1 has authorized MNOs to perform profile download operations on MNOB and MNOC profiles, profile enable/disable operations on MNOA, MNOB, and MNOC profiles, and profile delete operations on MNOC profiles, when it comes to integrated circuit card with identifier EID1. Further, SP 400 with SPID1 has authorized MNOs to perform profile download operations on MNOC profiles, profile enable/disable operations on MNOB, and MNOC profiles, and profile delete operations on MNOC profiles, when it comes to integrated circuit cards with identifiers EID2 and EID3.
In particular, SP 400 sends a DS configuration request towards DS 100, with a SPID of a service provider (SP) node in charge of a terminal 300 (e.g., an M2M device) with an eUICC identifier (EID), and one or more identifiers of respective MNOs authorized to handle profiles for the eUICC, and, optionally, one or more profile operations authorized to be performed by each MNO node.
The SP 400 in charge of a terminal 300 does the DS configuration, but SP 400 may delegate the implementation of such a configuration to a MNO 500 or to a DP node 200. If delegated to a MNO 500, MNO 500 may further delegate the implementation to an DP node 200.
This delegation process may be implemented by transmitting authorization tokens from SP 400 towards DP node 200, and using further authorization tokens when delegation is done through an MNO 500, as follows:
In more detail, an implementation of the delegation process may be performed as follows:
Steps 1a, 1b, and 1c (see
This embodiment enables an authorization framework to be established. That is, different entities with the access rights have control on the profiles being used by the terminals 300 (such as M2M devices), i.e. the SP 400 or the MNO 500.
Steps 4a, 4b: The SP 400, which is in charge of the device with certain EID, requires the performance of a profile operation, and sends the request (e.g. enable/disable, prepare/delete profile) to the MNO 500 handling the EID. MNO 500 sends the request to a DP node (e.g. SM-DP+) 200.
Optionally, the operation may be initiated directly by MNO 500 or DP node (e.g. SM-DP+) 200 if the SP 400 has previously delegated the subscription management of the EID to them. In this case, DS 100 should be configured accordingly.
Step 5: DP node (e.g. SM-DP+) 200 creates a record (EID, profile operation (e.g., enable/disable . . . ), SPID) to store the pending request.
Step 6: DP node (e.g. SM-DP+) 200 registers an event for the EID in the DS 100, adding the MNOID if needed, and, optionally, the profile operation.
Steps 8 and 10: DS 100 authorizes or not the registration based on the data stored in the authorization table. If positive, DS 100 creates, i.e. registers, an event record with following information: EID, DP node (e.g. SM-DP+) address, and SPID.
Step 12: DS 100 returns the registered event identifier, if DS 100 created the event identifier.
Step 14: DP node (e.g. SM-DP+) 200 adds the event identifier in its own record.
Step 15: Terminal 300 accesses SM-DS 100 and mutual authentication is performed, as known in the art.
Step 16: Terminal 300 sends an event retrieval request, i.e. a request for an available event to DS 100. The event retrieval request includes the SPID of the SP in charge of terminal 300. The SPID is configured in LPA by SP 400 (e.g., OEM) either during device manufacturing phase or later. This SPID may be signed by SP 400, so that it is not possible, or at least very difficult, to change it.
Step 18: DS 100 authorizes the operation based on the SPID received from terminal 300 and the authorization table.
Step 20: DS 100 then returns the event identifier and the DP node (e.g., SM-DP+) address to the terminal's 300 LPA. Optionally, if authorization tokens are available, they may be also forwarded to the LPA, so that the LPA may check if DP node (e.g., SM-DP+) 200 is authorized for the profile operations.
Steps 21 and 22: After mutual authentication, terminal 300 contacts the DP node (e.g., SM-DP+) 200 and requests the event(s) that may be available.
Step 24: DP node (e.g., SM-DP+) 200 determines the profile operation to which the event relates (e.g. enabling/disabling profile, profile download, etc.).
Steps 26 and 27: DP node (e.g., SM-DP+) 200 sends information about the profile operation (e.g. enable, disable . . . ) and EID to which it relates, as well as metadata if available (e.g. time window during the profile operation has to be performed). The information is forwarded to the eUICC.
Step 28: The terminal's 300 eUICC performs the required profile operation.
Step 29a: The eUICC notifies the LPA that the profile operation has been performed.
Step 29b: The LPA notifies DP node (e.g., SM-DP+) 200 that the profile operation has been performed.
Step 30: DP node (e.g., SM-DP+) 200 confirms receipt.
In one embodiment, DS 100 may send, in step 20, the indication of the profile operation to be performed, provided that DS 100 received that indication from DP node 200 and that the event record registered at DS 100 included that indication. In that embodiment, DS 100 need not transmit any DP node identifier to terminal 300, steps 23 to 26 may be skipped, and terminal 300 may directly proceed to perform the indicated profile operation (step 28) without contacting DP node 200.
As illustrated by
Processing unit 153 may include a processor, a microprocessor, or processing logic that may interpret and execute instructions. Main memory 157 may include a RAM or another type of dynamic storage device that may store information and instructions for execution by processing unit 153. ROM 158 may include a ROM device or another type of static storage device that may store static information and instructions for use by processing unit 153. Storage device 159 may include a magnetic and/or optical recording medium and its corresponding drive.
Input device 152 may include a mechanism that permits a user to input information to discovery server 100, such as a keypad, a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, etc. Output device 154 may include a mechanism that outputs information to the user, including a display, a printer, a speaker, etc. Communication interface 156 may include any transceiver-like mechanism, or receiver and transmitter, that enables discovery server 100 to communicate with other devices and/or systems (such as with a data preparation node 200, a terminal 300, etc.). For example, communication interface 156 may include mechanisms for communicating with another device or system via a telecommunication network.
DS 100 may perform certain operations or processes described herein. These operations may be performed in response to processing unit 153 executing software instructions contained in a computer-readable medium, such as main memory 157, ROM 158, and/or storage device 159. A computer-readable medium may be defined as a physical or a logical memory device. For example, a logical memory device may include memory space within a single physical memory device or distributed across multiple physical memory devices. Each of main memory 157, ROM 158 and storage device 159 may include computer-readable media. The magnetic and/or optical recording media (e.g., readable CDs or DVDs) of storage device 159 may also include computer-readable media. The software instructions may be read into main memory 157 from another computer-readable medium, such as storage device 159, or from another device via communication interface 156.
The software instructions contained in main memory 159 may cause processing unit 153 to perform operations or processes described herein, such as communicating with a DP node 200 or a terminal 300. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes and/or operations described herein. Thus, implementations described herein are not limited to any specific combination of hardware and software.
According to the embodiment illustrated by
Authorization table storage unit 102 is configured for storing a plurality of associations, here collectively referred to as “authorization table”, wherein each association comprises: (i) an integrated circuit card identifier; (ii) a SPID for identifying a service provider 400 in charge of a terminal 300 comprising an integrated circuit card 301 identified by the integrated circuit card identifier; and, (iii) for each of at least one operator 500 authorized to handle profiles of the integrated circuit card 301, an operator identifier.
Event registration request receiver 106 is configured for receiving, from a DP node 200, a request, here referred to as “event registration request”, which comprises: (a) an integrated circuit card identifier; (b) a service provider identifier; (c) an operator identifier; and (d) a DP node identifier for identifying the DP node 200.
First determiner 108 is configured for determining that the received integrated circuit card identifier, SPID, and operator identifier are associated with one another in the authorization table.
Register 110 is configured for registering an event record comprising the received integrated circuit card identifier, the received SPID, and the received DP node identifier.
In one embodiment, the event registration request, which the event registration request receiver 106 is configured to receive, further comprises an event identifier for identifying the event to be registered; and the event record that the register 110 is configured to register further comprises the received event identifier.
In one embodiment, register 110 is further configured for assigning an event identifier for identifying the event record; and DS 100 further comprises the above-referred first transmitter 112, which is configured for sending, to the DP node 200, the event identifier.
In one embodiment, DS 100 further comprises: the above-referred second receiver 116, the above-referred second determiner 118, and the above-referred second transmitter 120. Available event request receiver 116 is configured for receiving, from terminal 300, a request for an available event, the request comprising the integrated circuit card identifier and the SPID. Second determiner 118 is configured for determining that the event record comprises the received integrated circuit card identifier and SPID. Second transmitter 120 is configured for sending, to terminal 300, the DP node identifier comprised in the event record.
In one embodiment, second transmitter 120 is further configured for sending, to terminal 300, the event identifier.
In one embodiment, at least one of the associations in the authorization table, which authorization table storage unit 102 is configured to store, further comprises, for at least one operator identifier, indication of at least one authorized profile operation; the event registration request, which event registration request receiver 106 is configured to receive, further comprises an indication of a profile operation to be performed; and first determiner 108 is further configured for determining that the profile operation for which an indication has been received is indicated as authorized in the authorization table.
In one embodiment, the at least one authorized profile operation comprises at least one of: a profile download, a profile enable, a profile disable, and a profile delete.
According to the embodiment illustrated by
First receiver 204 is configured for receiving a request to perform a profile operation, the request comprising: (I) an integrated circuit card identifier; (II) a service provider identifier (SPID); (III) an operator identifier; and (IV) information relating to the profile operation to be performed.
Event registration request transmitter 206 is configured for sending, to DS 100, an event registration request comprising: (i) the received integrated circuit card identifier; (ii) the received SPID; (iii) the received operator identifier; and (iv) a DP node identifier for identifying the DP node 200.
Storage unit 214 is configured for associating the integrated circuit card identifier, the SPID, and an indication of the profile operation to be performed, with one another.
In one embodiment, the event registration request, which the event registration request transmitter 206 is configured to send, further comprises an event identifier for identifying the event to be registered; and storage unit 214 is further configured for associating the event identifier with the integrated circuit card identifier, the SPID, and the indication of the profile operation.
In one embodiment, DP node 200 further comprises the above-referred second receiver 212 configured for receiving, from DS 100, an event identifier; wherein storage unit 214 is further configured for associating the received event identifier with the integrated circuit card identifier, the SPID, and the indication of the profile operation.
In one embodiment, DP node 200 further comprises: the above-referred further receiver 222 configured for receiving, from a terminal 300, a request for a profile operation comprising the event identifier; the above-referred first determiner 224 configured for determining that the event identifier is associated with the indication of the profile operation to be performed; and the above-referred second transmitter 226 configured for sending, to terminal 300, the indication of the profile operation to be performed determined to be associated with the event identifier.
In one embodiment, DP node 200 further comprises the above-referred further receiver 222 configured for receiving, from a terminal 300, a request for a profile operation comprising the integrated circuit card identifier and the SPID; the above-referred first determiner 224 configured for determining that the integrated circuit card identifier and the SPID are associated with the indication of the profile operation to be performed; and the above-referred second transmitter 226 configured for sending, to the terminal 300, the indication of the profile operation to be performed determined to be associated with the integrated circuit card identifier and the SPID.
Terminal 300 comprises, as mentioned above, an integrated circuit card 301 identified by an integrated circuit card identifier. Terminal 300 further comprises a first transmitter 316, a first receiver 320, a second transmitter 322, a second receiver 326, and a processor 328 (which may be the same as processing unit 153 of
In one embodiment, the request for a profile operation comprises the integrated circuit card identifier and the SPID.
In one embodiment, first receiver 320 is further configured for receiving, from DS 100, an event identifier for identifying an event record; and the request for a profile operation, which second transmitter 322 is configured to send, comprises the event identifier.
Where the terms “authorization table storage unit”, “event registration request receiver”, “first determiner”, “register”, “first transmitter”, “storage unit”, “processor” etc. are used herewith, no restriction is made regarding how distributed these elements may be and regarding how gathered elements may be. That is, the constituent elements of a unit, function or network node may be distributed in different software or hardware components or devices for bringing about the intended function. A plurality of distinct elements may also be gathered for providing the intended functionalities.
Any one of the above-referred units of a network node may be implemented in hardware, software, field-programmable gate array (FPGA), application-specific integrated circuit (ASICs), firmware or the like.
In further embodiments of the invention, any one of the above-mentioned authorization table storage unit, event registration request receiver, first determiner, register, first transmitter, storage unit, processor, etc. is replaced by authorization table storage means, event registration request receiving means, first determining means, registering means, first transmitting means, storage means, processing means, etc. or authorization table storage module, event registration request receiving module, first determining module, registering module, first transmitting module, storage module, processing module, etc. respectively, for performing the functions of the authorization table storage unit, event registration request receiver, first determiner, register, first transmitter, storage unit, processor, etc.
In further embodiments of the invention, any one of the above-described procedures, steps or processes may be implemented using computer-executable instructions, for example in the form of computer-executable procedures, methods or the like, in any kind of computer languages, and/or in the form of embedded software on firmware, integrated circuits or the like.
Although the present invention has been described on the basis of detailed examples, the detailed examples only serve to provide the skilled person with a better understanding, and are not intended to limit the scope of the invention. The scope of the invention is much rather defined by the appended claims.
Abbreviations:
DP data preparation
DS discovery server
EID eUICC identifier
eSIM embedded SIM
eUICC embedded universal integrated-circuit card
GSM Global System for Mobile communications
GSMA GSM Association
IoT Internet of things
IP Internet Protocol
ISD-P Issuer Security Domain-Profile
LDS Local Discovery Service
LPA Local Profile Assistant
LPD Local Profile Download
LUI Local User Interface
M2M machine-to machine
MNO mobile network operator
MNOID MNO identifier
OEM original equipment manufacturer
OTA over-the-air
RAM Random-access memory
ROM Read-only memory
RSP remote SIM provisioning
SIM subscriber identity module
SM-DP+ Subscription Manager Data Preparation+
SM-DS Subscription Manager Discovery Service
SP service provider
SPID service provider identifier
UE user equipment
| Number | Date | Country | Kind |
|---|---|---|---|
| 18382112 | Feb 2018 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2018/056686 | 3/16/2018 | WO |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2019/161939 | 8/29/2019 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 5471203 | Sasaki | Nov 1995 | A |
| 8286883 | Asnaashari | Oct 2012 | B2 |
| 10939447 | Cheng | Mar 2021 | B2 |
| 11488173 | Wall | Nov 2022 | B1 |
| 20160352698 | Long | Dec 2016 | A1 |
| 20160373920 | Petersson et al. | Dec 2016 | A1 |
| 20170338944 | Yang et al. | Nov 2017 | A1 |
| 20190028881 | Namiranian | Jan 2019 | A1 |
| 20190230645 | Cheng | Jul 2019 | A1 |
| 20210092589 | Alonso Alarcon | Mar 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| WO-2019161939 | Aug 2019 | WO |
| Entry |
|---|
| Gustavus J. Simmons, “The Smart Card: A Standardized Security Device Dedicated to Public Cryptology,” in Contemporary Cryptology: The Science of Information Integrity , IEEE, 1992, pp. 561-613, doi: 10.1109/9780470544327.ch 12. (Year: 1992). |
| Y.-K. Park, S.-H. Lim, O. Yi, S. Lee and S.-H. Kim, “User Authentication Mechanism Using Java Card for Personalized IPTV Services,” 2008 International Conference on Convergence and Hybrid Information Technology, 2008, pp. 618-626, doi: 10.1109/ICHIT.2008.275. (Year: 2008). |
| I. Broustis, G. S. Sundaram and H. Viswanathan, “Detecting and preventing machine-to-machine hijacking attacks in cellular networks,” in Bell Labs Technical Journal, vol. 17, No. 1, pp. 125-140, Jun. 2012, doi: 10.1002/bltj.21527. (Year: 2012). |
| International Search Report and Written Opinion dated May 11, 2018 for International Application No. PCT/EP2018/056686 filed on Mar. 16, 2018, consisting of 15-pages. |
| Embedded SIM Remote Provisioning Architecture Version 1.1; GSM Association; Jan. 30, 2014, consisting of 85-pages. |
| Remote Provisioning Architecture for Embedded UICC Technical Specification Version 3.2; GSM Association; Jun. 27, 2017, consisting of 309-pages. |
| RSP Architecture Version 2.2; GSM Association; Sep. 1, 2017, consisting of 95-pages. |
| RSP Technical Specification Version 2.2; GSM Association; Sep. 1, 2017, consisting of 264-pages. |
| Embedded SIM Remote Provisioning Architecture Version 1.1; GSM Association; Dec. 17, 2013, consisting of 84-pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20210092589 A1 | Mar 2021 | US |
