DE102023110415A1 - A method for providing data to a subscriber profile for a Secure Element - Google Patents

Abstract

The invention relates to a method and a system for providing data for a subscription profile for a secure element, preferably a subscriber identity module or an eUICC, with the method steps: establishing a communication connection between a profile provision server and a notification server by specifying a secure element identifier; and publishing, by the profile provisioning server, preferably a Subscription Management Data Preparation Server, SM-DP+, the subscription profile data for the Secure Element on the notification server using the SE identifier, thereby automatically informing the Secure Element that the Subscription profile data available for download from the notification server. The invention also relates to a profile provision server, a secure element and a telemetry data server.

Description

TECHNICAL FIELD OF THE INVENTION

The invention relates to a method and a system for providing data for a subscription profile for a Secure Element, a corresponding Secure Element, a provisioning server and a notification server (telemetry data server).

To use the services of a communication network, a device, for example a mobile phone or a machine-to-machine device, or M2M device for short, or a device for using Internet of Things technologies contains Things, English: Intemet-of-Things, short: IoT, or a vehicle a Secure Element, short SE. In this description, the term “SE” is synonymous with the terms “eUICC”, “subscriber identity module”, “chip card”, “UICC”, “iUICC”, “Integrated eUICC”, “Integrated Secure Element”, “embedded Secure Element” or “SIM” is used. Data from a subscription profile is stored in the SE in order to uniquely identify and/or authenticate a subscriber (person or device) for the use of services of a communications network or on a communications network. This makes it possible for a service provider or an operator of the communications network to clearly assign the use of the service offered to each subscriber. Furthermore, it is possible for the service provider or an operator of the communications network to enable network access, i.e. logging into the communications network, as soon as the subscriber has been authenticated. He can also refuse network access if the subscriber cannot be authenticated.

From the GSMA specification SGP.31 eSIM IoT Architecture and Requirements, Version 1.0, April 19, 2022, a method for providing data for a subscription profile for a Secure Element is known, which includes a step for establishing a communication connection between an “SM-DP+ (Subscription-Management Data Preparation Server) and an “eIM” (eSIM IoT Remote Manager) as well as a step for storing a subscription profile received in the form of a “Bound Profile Package” from the SM-DP+ on the secure element. To do this, the eIM sends a load command to the secure element that contains the Bound Profile Package.

From the CN 112565439 A The use of a notification server in the form of an “MQTT (Message Queuing Telemetry Transport) broker” is known to manage eSIM cards. The notification server is located between an IoT device containing an eSIM card and a management server. The communication partners exchange management messages using an MQTT protocol. The “EID” (eUICC Identifier) of the eSIM card is used as an identifier for the exchange of messages.

TECHNICAL BACKGROUND

SEs are also increasingly being used in vehicles, for example in platforms, applications or systems for “vehicle-to-vehicle communication” or “connected car” to provide a communication link between the vehicle and the background system via a communication network or a communication link between vehicles or of vehicle with the environment. This also makes services in connection with a vehicle, for example “connected car services” or “car rental” (for example to unlock the vehicle) user-friendly and easy.

In order to communicate with the device or the vehicle, the SE should at least have a subscription profile or it must receive a subscription profile in order to be able to carry out identification and/or authentication on the communication network.

It is known to only introduce data from a subscription profile into the SE when the device/vehicle is commissioned/delivered or even during operation of the device/vehicle. Such procedures are summarized under the generic term of subscription management, also known as subscription management. These procedures are standardized by the GSMA, for example, to enable a variety of different device and vehicle manufacturers (English OEM) and many different architectures and technologies from SE to download, install, activate, deactivate and delete individual subscription profiles or data from subscription profiles in a standardized manner . Such procedures are described, for example, in the GSMA standards SGP.02 and SGP.22.

What is unsatisfactory, at least for some applications, is that the existing SGP.22 standard does not provide for a push mechanism for system-triggered downloading of the profile. As an auxiliary solution, an SMS is currently sent as a trigger message via a first communication path. This trigger message causes a switch to a second communication path to transfer the subscription profile.

The problem here is that two separate and isolated communication paths are used to load and install the subscription profile data onto an SE of an M2M or IOT device or vehicle.

Compared to typical customer requirements, the existing mechanisms for triggering and providing subscription profile data are slow, unreliable (e.g. in the event of a lack of network coverage, e.g. in a tunnel or in network overload), inflexible (sending profile data to SE for a large number of vehicles or adapting to different merchandise management systems , ERP systems), difficult to maintain and complex.

SUMMARY OF THE INVENTION

The invention is based on the object of creating a method and a system for providing data for a subscription profile for a Secure Element that is faster, more secure, more flexible, easier to maintain and less complex.

The task is solved by the features described in the independent patent claims. Advantageous embodiments of the invention are specified in the dependent claims.

According to the invention, a method for providing data for a subscription profile for a secure element, preferably a subscriber identity module or an eUICC, is provided. The method includes the method steps: establishing a communication connection between a profile provisioning server and a notification server using an SE identifier and publishing, by the profile provisioning server, preferably a subscription management data preparation server, SM-DP+, the data of the Subscription profile for the Secure Element on the notification server using the SE identifier, which automatically informs the Secure Element that the subscription profile is ready for download from the notification server.

This method combines the infrastructure of a notification communication path (specifically a trigger channel via SMS) with that of a subscription profile provisioning communication path. This allows synergies of both communication paths to be exploited, reducing the cost and complexity of providing data to a subscription profile. Among other things, it is no longer necessary to store data identifying a specific provisioning server on an SE.

A subscription profile is a data record for identifying and/or authenticating a subscriber to a communications network, preferably a mobile communications network. Subscription profile data relates either to a complete subscription profile or only a subset of it (update data). The data can also or alternatively also be instructions and commands for a subscription profile that already exists on the SE, for example an activation (Enable) or deactivation (Disable) or deletion (Delete) or unpacking (Unwrap) or installing (Install) or command for a Subscription profile already existing on the SE.

A subscription profile or data for it to be made available for an SE is commissioned by a background system from a provision server. This provisioning server establishes a communication connection with the notification server using the SE identifier of the SE that is to receive the subscription profile or data therefor. As a result, the subscription profile or data for it is published on the notification server. By publishing, the notification server provides information to the SE (based on the SE identifier) that the subscription profile or data for it can be downloaded from the notification server.

A notification server, for example a telemetry data server, is a server that is set up to transmit one or more notifications between two communication partners, for example telemetry data clients. The communication partners are everyone who is connected to the notification server and has subscribed to information (news, news) that contains the SE identifier. Here the communication partners are at least the provision server and the SE with the SE identifier.

An MQTT protocol can be used for M2M or IOT or vehicle communication. This MQTT protocol enables the transmission of telemetry data in the form of messages/notifications between devices, even when there are long delays or access-restricted communication networks. This communication is used by sensors, actuators, cell phones and, in particular, embedded systems in vehicles or laptops. According to the invention, this MQTT protocol is now used to inform a device or vehicle that new data from a subscription profile is available for the SE of the device/vehicle.

This notification server, also known as a “broker”, keeps all the data from its communication partners. The notification server acts as a state database and can be used as such. It is thus possible to connect resource-limited devices and SE in the form of communication partners of the notification server, for example in the form of telemetry data clients, to the telemetry data server, for example designed as an MQTT broker. These communication partners, i.e. devices or SE, provide or receive the notifications and, as a result, possibly also data. A complex situation picture is only created on the notification server. The situation picture can be evaluated on the notification server (telemetry data server) and/or by a powerful communication partner. In this way, the data of a subscription profile for an SE can be transmitted from one or more provisioning servers (e.g. as telemetry data clients) to the notification server (e.g. as telemetry data server) and distributed to the individual devices or SE.

In addition to the notification function, the notification server also provides a data transmission function. For example, the or some of the subscription profile data is transmitted from the provisioning server to the notification server in the publish step. The SE can then download this data from the notification server.

Using a telemetry data server as a preferred embodiment of a notification server, the provision of data for a subscription profile can be used as an automation solution. For example, the Message Queuing Telemetry Transport Protocol, MQTT protocol for short, is used. The telemetry data server can be an MQTT broker.

To establish a communication connection, for example through a CONNECT and subsequent CONNACK message type of an MQTT protocol, between the profile provisioning server and the notification server, an SE identifier is specified. This SE identifier is added as a message topic to every communication between the profile provisioning server and the notification server when the communication concerns the SE with the SE identifier. This SE identifier is used in the notification server to inform all interested communication partners about notifications in connection with this SE identifier. As part of the establishment of this communication connection, for example, a queue with the SE identifier is set up as a “message topic” on the telemetry data server.

An SE identifier is an identifier that uniquely identifies the SE in the telemetry data server environment, for example the SE's EID. The EID is the SE's identifier used to remotely manage an SE. Alternatively, an ICCID or eUICC ID or other unique number can be used to identify the SE. Using the SE identifier, the SE can subscribe to messages about itself. This makes it possible to ensure that the SE receives messages (is informed about messages) that concern the SE itself, for example according to the SGP.02 or SGP.22 standard. Alternatively, a unique device or vehicle ID can also be used.

A provisioning server is a data management server that hosts one or many subscription profiles for one or more SEs. These are downloaded and installed on an SE from a background system upon request, for example through a message from an OEM, an MNO or a service operator. For this purpose, the SE may use a local profile assistant (LPA), which is either integrated as a component (LPAd) in the device/vehicle or which is integrated as a component (LPAe) in the SE. The provision server is preferably an SM-DP+ server, for example according to the SGP.02 or SGP.22 standard. The respective Local Profile Assistant (LPA) can include an MQTT client.

The profile provisioning server is set up to publish the subscription profile data for the SE on the notification server, preferably using the PUBLISH message type of the MQTT protocol. When publishing the subscription profile data, the SE identifier (from the build step) is specified again.

By publishing using the SE identifier, this SE is automatically informed that the data of the subscription profile can now be downloaded from the notification server (data availability).

Automatically informed means that when the subscription profile data is published on the notification server, the notification server sends a notification regarding the publication to the SE and the SE receives this notification. This message from the notification server is evaluated by the SE and the published subscription profile data can subsequently be downloaded from the notification server.

Preferably, the profile provision server enters the SE identifier as a notification identifier in the notification server in the build step. This notification identifier is specified in the publish step. A notification identifier, also known as a notification topic, enables the notification server to assign notifications to communication partners. The notification identifier can be a queue entry, particularly in the case of a telemetry data server (MQTT server) as a notification server.

The secure element preferably subscribes to all notifications from the notification server in which the SE identifier of the SE is specified as the notification identifier. Subscribing can be done, for example, by a SUBSCRIBE message type of an MQTT protocol. When subscribing, the SE preferably provides its own SE ID as the notification identifier. This means that the SE is automatically informed of all notifications with this notification identifier. Before subscribing, the SE establishes a communication connection to the notification server. The communication connection can be established, for example, using a CONNECT and then CONNACK message type of an MQTT protocol.

By subscribing to notifications of a specific notification identifier, all notifications with this notification identifier are automatically forwarded from the notification server to the subscribing participant (e.g. SE or profile provision server).

After the publishing step, the data of the subscription profile can be downloaded from the notification server into the Secure Element and preferably installed executable there. The subscription profile or data for it is received directly from the notification server. It is not necessary to establish a standalone communication path between Secure Element and a profile data provisioning server.

The SE preferably publishes a confirmation of the download and, if necessary, the installation on the notification server, preferably using the PUBLISH message type of the MQTT protocol. When publishing the confirmation(s), the SE identifier is specified as the notification identifier. Publishing the confirmation automatically informs the profile provisioning server that the subscription profile data has been downloaded and installed preferentially.

Preferably, the profile provisioning server subscribes to all notifications from the notification server in which the SE identifier of the SE is specified as the notification identifier. Subscribing can be done, for example, by a SUBSCRIBE message type of an MQTT protocol. This means that the provisioning server is automatically informed of all notifications with this notification identifier and, for example, automatically receives the information that the subscription profile data has been downloaded from the SE.

According to the invention, subscription by the profile provision server is not necessary, but it is helpful for recognizing the SE-side confirmation of the profile download. Instead of a subscription by the profile provision server, the information about the SE-side profile download can also be provided via alternative communication paths, for example via SMS or HTTPS.

Preferably, before the publishing step by the profile provision server, the data of the subscription profile for the secure element is generated and/or received by the profile provision server. For this purpose, information is preferably forwarded from a background system, for example an OEM or MNO or VMNO or vehicle manufacturer, to the profile provision server, in which it is stated that data from the subscription profile is to be provided to the SE. This data can be generated by the profile provisioning server itself or this data can be obtained in the profile provisioning server.

The building, publishing, optionally subscribing and informing steps are preferably carried out by a notification client, preferably a telemetry data client, more preferably an MQTT client, of the profile provision server. This adds notification client functionality to the profile provisioning server to communicate with the notification server. This extension allows the two communication paths to be combined in traditional deployment, increasing efficiency.

The setting up, publishing, possibly subscribing and informing steps are preferably carried out by a notification client, preferably a telemetry data client, more preferably an MQTT client, of the SE. This extends the SE to include the functionality of the notification client in order to be able to communicate with the notification server. This expansion allows the two to be combined Communication paths in traditional deployment, increasing efficiency.

In a preferred embodiment, the secure element includes a local profile assistant. This supports the resource-limited SE in managing profiles on the SE, in particular downloading, installing, unpacking, deleting, activating and/or deactivating.

In an alternative or additional embodiment, the SE is incorporated into a device or vehicle, the device or vehicle having a local profile assistant. This supports the resource-limited SE in managing profiles on the SE, in particular downloading, installing, unpacking, deleting, activating and/or deactivating.

To solve the task, a secure element, preferably a subscriber identity module or eUICC, is also provided. The SE includes a telemetry data client that is set up for data communication with a remote telemetry data server as a notification server, the telemetry data client preferably being incorporated into a local profile assistant of the SE; a non-volatile memory configured to store at least one subscription profile; and a control unit configured to receive automatic information that subscription profile data is available for download from the notification server.

To solve the problem, a profile provision server, preferably an SM-DP+, is also provided. The profile provisioning server includes a telemetry data client configured for data communication with a remote telemetry data server as a notification server; an interface for data communication with a background system set up to receive a profile order with a secure element identifier; a non-volatile memory configured to store at least one or more subscription profiles for Secure Elements; and a control unit, set up to establish a communication connection to the notification server by specifying a secure element identifier; and publishing data of a subscription profile for a Secure Element on the notification server using the SE identifier.

To solve the task, a telemetry data server is also provided as a notification server, preferably an MQTT broker. The telemetry data server includes an interface for data communication with one or more telemetry data clients; a non-volatile memory configured to store at least one or more subscription profiles for Secure Elements; and a control unit configured to establish a communication connection to a telemetry data client of a profile provision server; obtaining data of a subscription profile for one of the Secure Elements from a profile provisioning server, the data comprising a Secure Element identifier of a Secure Element; Sending an automatic notification to the Secure Element with the Secure Element identifier that a subscription profile is available for download from the telemetry data server to the Secure Element.

The control unit of the telemetry data server is further set up to set up a subscription service for all telemetry data clients, whereby a notification identifier is entered in the telemetry data server as part of the subscription service and whereby all telemetry data clients who are registered for one are automatically informed Notification identifier has commissioned a subscription service.

To solve the problem, a system for providing data from a subscription profile is also provided. The system includes a profile provisioning server of the type described herein, one or more secure elements of the type described herein; and a notification server of the type described here.

A UICC in the sense of the invention is an electronic module that is reduced in size and resources and has a control unit (microcontroller) and at least one interface (data interface) for communication with the device. This communication preferably takes place via a connection protocol, in particular a protocol according to the ETSI TS 102 221 or ISO-7816 standard. With UICC designs integrated into System on Chip, SoC for short, such as the “iUICC”, “Integrated eUICC”, “Integrated SE” or the “Integrated TRE”, communication takes place via an SoC internal bus. The UICC has an internal or external secure non-volatile storage area in which subscriber identity data is securely stored to prevent attempts at manipulation and/or misuse of identification and/or authentication on the network. This UICC has a memory area in which internal states of a UICC session can be stored.

In one embodiment, the UICC can be operable by means of a device, with the UICC in this embodiment except for supply signals, such as supply voltage, clock, reset etc. is self-sufficient.

The term “SE” is synonymous with the term “eUICC”, “subscriber identity module”, “chip card”, “iUICC”, “Integrated eUICC”, “Integrated Secure Element”, “embedded Secure Element”, “UICC” or “SIM”. The SE is used to identify a participant in a communication network and to authenticate them for using services. SEs also include USIM, TSIM, ISIM, CSIM or R-UIM. For example, an SE is defined as a USIM application in ETSI TS 131 102. For example, an SE is defined as a SIM application in ETSI TS 151 011. For example, an SE is defined as a TSIM application according to ETSI TS 100 812. For example, an SE is defined as an ISIM application according to ETSI TS 131 103. For example, an SE is defined as a CSIM application according to 3GPP2 C.S0065-B. For example, an SE is defined as an R-UIM application according to 3GPP2 C.S0023-D.

The SE may be an integral part within the device, such as a hard-wired electronic component. Such SEs are also referred to as eUICC. In this design, these UICC are not intended to be removed from the device/vehicle and in principle cannot be easily replaced. Such UICC can also be designed as embedded secure elements and are a secure hardware component in the device.

The SE can also be a software component in a trustworthy part of an operating system, a so-called Trusted Execution Environment, or TEE for short, of the device/vehicle. The SE, for example, is designed within a secure runtime environment in the form of programs running in it, so-called “trustlets”.

The SE can also be an integral part of a larger integrated circuit, such as a modem or application processor. Such SEs are referred to as “integrated UICC”, “integrated TRE”, “integrated eUICC” or “Integrated SE”. Such SEs are permanently integrated into an SoC as an integrated processor block and can be connected via an internal chip bus.

The UICC can be used for remote monitoring, control and maintenance of devices such as machines, plants and systems. It can be used for counting units such as electricity meters, hot water meters etc. The UICC, for example, is part of the IoT technology.

The terms “end device” and “device” and “vehicle” are used synonymously. A device in the sense of the invention is in principle a device or a device component with means for communicating with a communications network in order to be able to use services of the communications network or to be able to use services of a server via a gateway of the communications network. For example, a mobile device such as a smartphone, a tablet PC, a notebook, or a PDA can be included under the term. The device can also be understood to mean, for example, multimedia devices such as digital picture frames, audio devices, televisions, e-book readers, which also have means for communicating with the communication network.

The SE can use the device, for example a modem of the device, to establish a data connection to a server via the communications network. For example, the device can be used to contact a server from the device manufacturer in order to address control units, e.g. ECUs (ECU = Electronic Control Unit) for functionalities of the device/vehicle.

In particular, the device is installed in a machine, an automatic machine and/or a vehicle. If the device is installed in a motor vehicle, it has an integrated SE, for example.

The area of application according to the invention is the subscription management for one or more vehicles as any mobile means of transport and transportation for the transport of people and/or goods.

A communication network is a technical device on which the transmission of signals takes place with identification and/or authentication of the subscriber. The communication network offers its own services (own voice and data services) and/or enables the use of services from external entities. The communication network is preferably a mobile radio network. Device-to-device communication under the supervision of the communication network is possible. In particular, a mobile network is used here, for example the “Global System for Mobile Communications”, GSM for short, as a representative of the second generation or the “General Packet Radio Service”, GPRS for short or “Universal Mobile Telecommunications System”, UMTS for short as a representative of the third generation. the “Long Term Evolution”, LTE for short, is understood as a representative of the fourth generation as a mobile network or a fifth generation mobile network with the current working title “5G” is understood as a communications network.

According to the invention, a server is an instance that is spatially distant from the device. The server can be part of the communication network. Alternatively or additionally, the server is an external instance (i.e. not an instance of the communication network).

Vehicles prefer to communicate their data via telemetry data servers, rather than a server primarily intended for remote measurements. The notification server is preferably not part of the conventional mobile communications infrastructure and is also preferably not part of the conventional subscription management for SE.

The subscription profile includes subscriber identity data. These are, for example, data that uniquely identify a participant (a person or a device) in the communication network. This includes, for example, a subscriber ID, also known as International Mobile Subscriber Identity, or IMSI for short, and/or subscriber-specific data. The IMSI is the subscriber identity file that is unique in a cellular communications network. It consists of the country code MCC (Mobile Country Code), the network code MNC (Mobile Network Code) and a serial number assigned by the network operator. In addition, subscriber identity data are, for example, data that uniquely authenticate a subscriber on the communication network, for example an authentication algorithm, specific algorithm parameters, a cryptographic authentication key Ki and/or a cryptographic over-the-air, or OTA for short, key. In addition, subscriber identity data is, for example, data that uniquely authenticates a subscriber to a service (=service), for example a unique identifier or signature. A service is in particular a voice service or a data service of a server with which information and/or data is transmitted over the communication network.

The SE is inserted into the device ready for operation. The communication between SE and device is based on a connection protocol. The device can also be set up to independently establish a data connection to the remote server in order to also use its services and exchange data with this server.

BRIEF DESCRIPTION OF THE FIGURES

• 1 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams einer konventionellen Profilbereitstellung für Fahrzeuge mit SE;
• 2 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens;
• 3 zeigt ein ausführliches Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens;
• 4 zeigt ein Ausführungsbeispiel eines erfindungsgemäßen Systems; und
• 5 zeigt ein Ausführungsbeispiel eines erfindungsgemäßen SE mit Profildaten.

The invention and further embodiments and advantages of the invention are explained in more detail below using figures, with the figures only describing exemplary embodiments of the invention. The same components in the figures are given the same reference numbers. The figures are not to be viewed as true to scale; individual elements of the figures may be shown in an exaggeratedly large or oversimplified manner. Elements shown in dashed lines are optional elements that may or may not be provided.

• 1 shows an exemplary embodiment of a flowchart of a conventional profile provision for vehicles with SE;
• 2 shows an exemplary embodiment of a flowchart of a method according to the invention;
• 3 shows a detailed exemplary embodiment of a flowchart of a method according to the invention;
• 4 shows an exemplary embodiment of a system according to the invention; and
• 5 shows an exemplary embodiment of an SE according to the invention with profile data.

DETAILED DESCRIPTION OF EMBODIMENTS

1 shows an exemplary embodiment of a flowchart of a conventional profile provision for vehicles with SE.

For this purpose, a first communication path A is set up between an IOT background system 9 and a vehicle 2 in order to signal to the vehicle 2 by means of a wake-up trigger signal that a new subscription profile for an SE 1 is present in the vehicle 2. This communication path A can be created as part of an SMS service. After the wake-up trigger signal has been recognized in the vehicle 2, either directly between the vehicle 2 and a profile provision server 4 or, if a specific profile provision server 4 is not stored in the vehicle, initially between the vehicle 2 and a switching server , typically in the form of a subscription management discovery service SM-DS, and then a second communication path B is set up between vehicle 2 and the determined profile provision server 4, for example using the HTTPS protocol. The subscription profile is then transmitted via the second communication path B from the profile provision server 4 to the SE 1 of the vehicle 1 and installed there. The transmission via the second communication path B takes place, for example, according to the mechanisms specified in the standard SGP.22 version 2.2.1 and later. The existing SGP.22 standard does not provide a mechanism for system-triggered downloading of the profile. Currently, as an auxiliary solution, an SMS is first sent via the first communication path A or an MQTT trigger message is sent det, which then switches to an HTTP channel as the second communication path B.

The known, complex solution uses two different and isolated communication paths A, B to vehicle 2 to download the subscription profile. This is disadvantageous because two communication paths must be provided.

2 shows a flowchart of a basic exemplary embodiment of a method according to the invention. In a vehicle 2, an SE 1 is provided into which a new profile is to be loaded. The SE 1 may include an LPA. Alternatively, the vehicle 2 may include an LPA. An MQTT client 121 or 211 can be included in the respective LPA.

A profile provision server 4 connects to a notification server 3. In one embodiment, the profile provision server 4 includes an MQTT client 42 and connects via this MQTT client 42 to the notification server 3, which is an MQTT server 3. For this connection establishment, a new notification identifier is created by the profile provision server 4 and communicated to the server 3. For example, this notification identifier is an SE identifier of SE 1. The connection can be established using the MQTT message types CONNECT (connection) and CONNACK (connection confirmation) (not shown in 2 ).

Parallel to or downstream of the connection establishment between the servers 3 and 4, the vehicle 2 connects to the notification server 3. In the embodiment, the SE 1 includes an MQTT client 121, 211 and connects to the notification server using this MQTT client. Server 3. The connection can be established using the message types CONNECT (connection) and CONNACK (connection confirmation) (not shown in 2 ). In addition, the SE 1 can subscribe to notifications with the notification identifier (e.g. the SE identifier of the SE1). Subscribing can be done using the MQTT message type SUBSCRIBE.

In a subsequent step, the profile provisioning server 4 publishes the new subscription profile or data for it on the notification server 3. Publishing can be done with the MQTT message type PUBLISH. As part of the publishing process, the server 4 makes the data of the subscription profile available to the server 3. The server 3 saves the profile in the meantime.

By publishing, the SE 1 is automatically informed that the subscription profile is available for download from the notification server 3 for the SE 1.

With the in 2 The solution presented in 1 The required communication channels A and B are now combined into a single communication path, reducing costs and complexity. This leads to harmonization towards standardized updates for vehicle software via a PUSH mechanism, which is not provided for in the GSMA standard SGP.22.

3 shows a - compared to 2 - More detailed exemplary embodiment of a flow chart of a method according to the invention. The basic concept in 3 is equal to the basic concept of 2 . The main differences are highlighted below.

In step 101, the profile provision server 4, hereinafter also simply referred to as server 4, receives a confirmation message from a background system (not shown in 3 ). The background system can be an OEM backend. The confirmation message in step 101 can be SGP.22 compliant and, for example, represent an “ES2+ConfirmOrder EID”. With the confirmation message 101, the server 4 receives an SE identifier, here an EID, which the server uses as a notification identifier for MQTT communication.

In step 102, the server 4 creates a queue for the MQTT server (MQTT broker) 3 using the MQTT client 42 located therein. For this purpose, for example, a unique server address (FQDN) with the EID is sent to the server 3. For example, the queue is FQDN/EID.

In step 103, the server 4 connects to the server 3. The connection can be established in step 107 using the CONNECT (connection) and CONNACK (connection confirmation) message types.

In step 107, the vehicle 2, preferably the LPA 12 of the SE 1 of the vehicle 2, connects to the server 3. For this purpose, the LPA 12 has an MQTT client (not shown in 3 ). The connection establishment in step 107 can be done using the CONNECT (connection) and CONNACK (connection confirmation) message types.

In step 108, the LPA 12 of the SE 1 of the vehicle 2 subscribes to the queue FQDN/EID generated by the server 4 in step 102. Subscribing in step 108 can be done using the MQTT message type SUBSCRIBE (subscribe). This means that the SE 1 is automatically informed about all notifications regarding the EID of the SE1, i.e. the server 3 sends the notifications to the SE 1, without an additional request from the SE 1. For this purpose, the SE 1 informs the LPA 12 of the EID of the SE 1 if necessary with, see step 112.

In the optional step 104, the server 4 also subscribes to the queue FQDN/EID generated in step 102. Subscribing in step 104 can be done using the MQTT message type SUBSCRIBE. This means that the server 4 is automatically informed about all notifications regarding the EID of the SE1, i.e. the server 3 sends the notifications to the server 4 without any additional request from the SE 1.

In step 105, the server 4 publishes the new profile on the server 3. For publishing with the MQTT message type PUBLISH, the EID of the SE 1 is sent as the notification identifier.

Due to the subscription in step 108, publishing the profile in step 105 will result in the SE 1 or LPA 12 being automatically informed that a new profile is available to download and install on the SE 1. The LPA 12 or the SE 1 then downloads the profile from the server 3 and installs it in the SE 1, see step 111.

In step 110, the result of downloading and, if necessary, installing the new profile is published on the server 3 as a profile installation confirmation.

If the queue was subscribed in step 104, publishing the confirmation in step 110 will result in the server 4 being informed of the profile installation confirmation. This information can be forwarded as confirmation from server 4 to the background system, for example as ES2+.HandleDownloadProgressInfo in accordance with the GSMA standard SGP.22.

Before or immediately at the beginning of the implementation of the method 100, the LPA 12 or the SE 1 can be informed in step 103 that a profile download is imminent and the LPA 12 or the SE 1 should log on to the server 3 via the domain address FQDN . In essence, a “queue” or queue is set up between server 4 (SM-DP+) and the vehicle-side LPA 12, to which server 4 (SM-DP+) can always add new subscription profiles (or other data, e.g. certificates or applets). can set. The proposed solution uses the MQTT (Message Queuing Telemetry Transport) protocol. To set it up, an MQTT broker 3 is placed between server 4 (SM-DP+) and LPA 12 and both server 4 (SM-DP+) and LPA 12 are equipped with appropriate mechanisms for communicating with MQTT broker 3. An EID-specific queue is then established between server 4 (SM-DP+) and the LPA 12 via the MQTT broker 3. The server 4 (SM-DP+) uses this queue to publish a (new) profile, which is loaded into the vehicle-side SE 1 via the LPA 12.

In 4 a system for providing data of a subscription profile is shown. The system uses the procedure of 2 and 3 um, repetitions in this regard will be omitted below.

The SE 1 includes an SE identifier, here the EID 1, which uniquely identifies the SE 1 on the system. The SE 1 can also include an LPA 12. The SE 1 includes an MQTT client 121. The MQTT client 121 is preferably integrated into the LPA 12 (shown in dashed lines). Alternatively, the MQTT client is integrated in SE 1 (without LPA). In addition, a profile management 13 is shown in the SE 1, which manages two profiles 14a and 14b. The profile management 13 can be a security domain (preferably the root security area, SD-R). The profiles 14a, b can each be a security area, SD-P.

The SE 1 is installed in a vehicle 2. For this purpose, the SE 1 can be an integrated component on a control board of the vehicle 2. The vehicle 2 may include an LPA 21. The LPA 21 may include an MQTT client 211.

Either the MQTT client 121 or the MQTT client 211 is intended to communicate with an MQTT broker 3 (notification server) via the communication path 6. Queue 31 was set up in the MQTT broker according to step 102. The queue 31 is the SE identifier EID 1. Alternatively, the queue 31 can also be another identifier, for example an LPA identifier, a UICC identifier, an ICCID or a unique vehicle identifier.

The MQTT broker 3 communicates with the server 4 (SM-DP+) via a communication channel 7. The communication channels 6 and 7 can use TCP and have a 2-byte header for MQTT protocols.

Profiles 41 or data on profiles or other data, such as certificates or applets, for the SE 1 are hosted on the server 4. An MQTT client 42 in the server 4 communicates with the MQTT broker 3 via the communication channel 7. The profile data 41 can already be stored SE-specifically in server 4. Alternatively, the profile data 41 is SE-unspecific and is enriched with SE-specific data through information from the background system 5 via the communication channel 8. Alternatively or additionally, the profile data 41 can be SE-unspecific and can be loaded onto the SE 1 in this form by publishing on the MQTT broker 3.

The SE 1 is inserted into the vehicle 2 ready for operation and is supplied by the vehicle 2 with a supply voltage Vcc and a clock CLK. The SE 1 can have applets.

These applets can send different APDU commands to vehicle 2 via a Card Application Toolkit, CAT. The vehicle 2 may also include a modem (not shown). The modem can be viewed, for example, as a logical unit for converting data between the SE 1 and the server 3. The vehicle 2 can establish a communication connection to the SE 1 through the modem. The communication between the vehicle 2 and the SE 1 can take place according to the protocols defined in the international standards ISO/IEC 7816-3 and ISO/IEC 7816-4.

The entire data exchange between SE 1 and the vehicle 2 can preferably take place using so-called APDUs (application protocol data units) in accordance with the ISO/IEC 7816-4 standard.

The SE 1 has an operating system in which the method 100 according to 2 and 3 partially expires. For example, the operating system is a native operating system. It is conceivable that the operating system is set up to run a Javacard runtime environment, JCRE.

The LPA 12 (or 21) is a local profile assistant intended according to standard SGP.22 to support remote management of SE 1. The LPA 12 (or 21) is preferably used in the method and system of this invention. In principle, an LPA can also be dispensed with if the SE 1 is set up to operate an MQTT client directly.

The SE 1 has a central processor or control unit, CPU, which is in communication with the interface. The primary tasks of the CPU include performing arithmetic and logic functions and reading and writing data elements as defined by program code executed by the CPU. The CPU is also connected to volatile memory, RAM and non-volatile rewritable memory. The non-volatile memory is preferably a flash memory (flash EEPROM). This can be, for example, a flash memory with a NAND or a NOR architecture. The SE's profile data is stored in the non-volatile memory.

At the in 4 In the preferred embodiment shown, the program code that can be executed by the CPU is also stored in the non-volatile memory. In particular, the program code of the chip card operating system, OS, the Java Card runtime environment, JCRE, (consisting of Java Card Virtual Machine, JCVM and Java Card Application Programming Interfaces, JCAPI) can be stored in the non-volatile memory.

5 shows an exemplary embodiment of an SE 1 according to the invention with profile data 14a and 14b. In addition, an LPA 12 is repeatedly shown, which shows an MQTT client 121. The MQTT client establishes the connection with the MQTT broker 3 via the communication path 6. The profile management 13 is shown here as ISD-R according to the SGP.22 standard. An SE identifier EID1 is shown with the reference number 11. Three profiles 14am, 14b, 14c are shown as examples.

The SE 1 according to 5 has, for example (but not necessarily) profile management 13 (ISD-R), which can manage the various profiles 14a-c (=subscription profiles). By means of OTA communication between servers 4 (and 3), for example subscription servers SM-SR or data provision servers SM-DP, SM-DP+ in accordance with the GSMA specifications SGP.02 and SGP.22, a profile 14 ac can be managed, for example SMS , CAT_TP or HTTPS is used for over-the-air, OTA, communication with the UICC 1. This profile management includes “creating”, “loading”, “activating”, “deactivating”, “deleting” and “updating”. For details, please refer to the GSMA specifications mentioned.

A profile 14a-c has profile data. For example, one of the following components may exist as a profile file per profile 14a-c: an MNO security domain (MNO-SD) with the OTA key sets from OTA servers; at least one authentication parameter (Ki, OP, RAND, SGN) or at least one reference (pointer or address) to a corresponding entry in the file system of the SE 1; a network access application, policy rules; a profile-specific file system containing DFs, EFs for the respective profile 14a-c; Connection parameters of the profile; applications; a subscriber identifier, IMSI, a subscriber identity module identifier ICCID and profile updates if applicable.

According to the exemplary embodiment, the SE 1 comprises at least one profile 14a-c, in particular a plurality of profiles 14a-c and a subscription management 13, wherein the or each profile 14a-c has a state that is active or inactive. The subscription management 13 can be a Root Issuer Security Domain (ISD-R), preferably a Root Issuer Security Domain (ISD-R) according to the GSM SGP.22 specification, in particular according to the GSM SGP.22 specification.

Within the scope of the invention, all described and/or drawn and/or claimed elements can be combined with one another as desired.

REFERENCE SYMBOL LIST

1

Secure Element, Subscriber Identity Module, SIM, eUICC

11

SE identifier, EID

12

LPA(s), local profile assistant

121

MQTT client

13

Profile management

14a,b,c

Subscription profile

2

device, vehicle

21

LPA(d), local profile assistant

211

MQTT client

3

Notification server, telemetry data server, MQTT broker,

31

Notification identifier

32

Profile data (published)

4

Provisioning Server, SM-DP+

41

Profile data

42

MQTT client

5

Background system, OEM

6

Communication connection between device and notification server

7

Communication connection between provisioning server and notification server

8th

Communication connection between provisioning server and background system

9

IOT devices background system

A

First communication path

b

Second communication path

101-113

Process steps according to the invention

Abbreviations

SE

Secure element

IOT

Internet of Things, Internet-of-Things MQTTMessage Queuing Telemetry Transport

LPA

Local Profile Assistant, local profile assistant

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• CN 112565439 A [0004]

Claims (12)

A method (100) for providing data for a subscription profile (14) for a secure element (1), preferably a subscriber identity module or an eUICC, with the method steps: - Establishing (102, 103) a communication connection (7) between a profile provision server (4) and a notification server (3) by specifying a Secure Element (SE) identifier (11), the profile provision server (4) being the SE Enters the identifier (11) as a notification identifier in the notification server (3) (102); and - Publishing (105), by the profile provision server (4), preferably a subscription management data preparation server, SM-DP+, of the data of the subscription profile (14) for the secure element (1) on the notification server (3), where the SE identifier (11) is specified as a notification identifier, - Subscribing (108) to all notifications from the notification server (3) through the secure element (1), in which the SE identifier (11) is specified as the notification identifier, whereby the secure element (1) after publishing (105) the data a subscription profile (14) is automatically informed (109) that the data of the subscription profile (14) is available for download from the notification server (3). The procedure (100) according to Claim 1 , wherein after the publishing step (105), the data of the subscription profile (14) is downloaded (111) from the notification server (3) into the secure element (1) and is preferably installed there in an executable manner. The procedure (100) according to Claim 1 or 2 , wherein a confirmation of the download (111) and preferably the installation is published (110) by the secure element (1) on the notification server (3), whereby the profile provision server (4) is automatically informed (106) that the data of the subscription profile (14) was downloaded (111) and preferably installed. The method (100) according to any one of the preceding claims, wherein the profile provision server (4) subscribes (104) to information regarding the notification identifier from the notification server (3), whereupon the automatic notification (106) of the download (111) takes place. The method (100) according to one of the preceding claims, wherein before the publishing step (105) by the profile provision server (4), the data of the subscription profile (14) for the secure element (1) from the profile provision server (4) are generated and/or obtained (101). The method (100) according to one of the preceding claims, - wherein the notification server (3) is a telemetry data server, preferably a Message Queuing Telemetry Transport, MQTT server, and/or - wherein the building (102, 103) and publishing (105) is carried out by a notification client, preferably a telemetry data client, more preferably an MQTT client (42), of the profile provision server (4), and / or - wherein the automatic informing (109) to a notification client, preferably a telemetry data client, more preferably an MQTT client (121) of the secure element (1) or an MQTT client (211) of a device (2) in which the secure Element (1) is introduced. The method (100) according to one of the preceding claims, wherein the secure element (1) comprises a local profile assistant (12) and/or wherein the secure element (1) in a device (2) or a vehicle comprises a local profile assistant (21 ) is introduced and wherein the respective local profile assistant (12) comprises an MQTT client (211, 121). A secure element (1), preferably having a subscriber identity module or eUICC - a telemetry data client (121), set up for data communication with a remote telemetry data server as a notification server (3), the telemetry data client (121) preferably being incorporated in a local profile assistant (12) of the secure element (1). ; - a non-volatile memory, set up to store at least one subscription profile (14); and - a control unit, set up to: - Obtaining (109) automatic information that a subscriber profile (14) is available for download from the notification server (3). A profile provision server (4), preferably an SM-DP+, comprising - a telemetry data client (42) set up for data communication with a remote telemetry data server as a notification server (3); - an interface for data communication (8) with a background system (5) set up to receive (101) a profile order with a secure element identifier (11); - a non-volatile memory, set up to store at least one or more subscription profiles (41) for Secure Elements (1); and - a control unit, set up to: - Establishing (102, 103) a communication connection (7) to the notification server (3) by specifying a secure element identifier (11); and - publishing (105) data of a subscription profile (14) for a secure element (1) on the notification server (3) using the SE identifier (11). Having a telemetry data server as a notification server (3), preferably an MQTT broker - an interface for data communication (6, 7) with one or more telemetry data clients (211, 121, 42), - a non-volatile memory, set up to store at least one or more subscription profiles (32) for Secure Elements (1); and - a control unit, set up to: - Establishing (102, 103) a communication connection (7) to a telemetry data client (42) of a profile provision server (4); - Obtaining data of a subscription profile (17) for one of the secure elements (1) from a profile provision server (4), the data comprising a secure element identifier (11) of a secure element (1); - Sending (109) automatic information to the secure element (1) with the secure element identifier (11) that a subscription profile (32) is available for download from the telemetry data server (3) to the secure element (3). A telemetry data server (3) according to Claim 10 , wherein the control unit is further set up to set up a subscription service for all telemetry data clients (211, 121, 42), wherein a notification identifier is entered (102) in the telemetry data server (3) as part of the subscription service and where all telemetry data clients (211, 121, 42) who have ordered a subscription service (104, 108) for a notification identifier are automatically informed (109, 106). A system for providing data for a subscription profile (14), comprising: - a profile provision server (4) according to Claim 11 ; - one or more secure elements (1), according to Claim 10 ; and - a notification server (3). Claim 12 or 13.

Images