TEILNEHMERIDENTITÄTSMODUL UND SUBSKRIPTIONS-SERVER

TECHNISCHES GEBIET DER ERFINDUNG

Die Erfindung bezieht sich auf ein Verfahren zum Bereitstellen von Subskriptions-Profilen an ein Teilnehmeridentitätsmodul, bevorzugt eine eUICC, mittels eines Subskriptions-Servers, bevorzugt ein SM-DP, sowie ein Verfahren zum Verwalten von Subskriptionsprofilen in einem Teilnehmeridentitätsmodul, ein entsprechendes Teilnehmeridentitätsmodul, ein entsprechender Subskriptions-Server und ein Computerprogramm-Produkt.

Zur Nutzung von Diensten eines Kommunikationsnetzes enthält ein Endgerät, beispielsweise ein Mobiltelefon oder ein Maschine-zu-Maschine-Modul, englisch Machine-to-Machine-Module, kurz M2M-Modul, ein Teilnehmeridentitätsmodul. In dem Teilnehmeridentitätsmodul ist zumindest ein Subskriptions-Profil, nachfolgend vereinfacht auch als Profil bezeichnet, enthalten. Das Profil umfasst Teilnehmeridentitätsdaten, um einen Teilnehmer am Kommunikationsnetz, beispielsweise einem Mobilfunknetz, zu identifizieren und zu authentisieren. Durch dieses Profil ist es einem Betreiber des Kommunikationsnetzwerks möglich, die Nutzung eines angebotenen Dienstes, beispielsweise eines Sprach- und/oder Datendienstes, jedem Teilnehmer im Kommunikationsnetzwerk eindeutig zuzuordnen. Weiterhin ist es dem Betreiber möglich, einen Netzzugang, also das Einbuchen in das Kommunikationsnetz, zu ermöglichen, sobald eine Authentisierung des Teilnehmers stattgefunden hat. Er kann zudem den Netzzugang verweigern, falls eine Authentisierung des Teilnehmers nicht möglich ist.

TECHNISCHER HINTERGRUND

Heutige Teilnehmeridentitätsmodule sind dazu eingerichtet, ein Profil auch nach ihrer Herstellung zu empfangen, einzurichten, zu verwenden, zu aktualisieren, zu aktivieren, zu deaktivieren, zu löschen und/oder zu erweitern. Dies wird allgemein als Teilnehmeridentitätsverwaltung, auch Subskriptions-Management, bezeichnet. Ein Teilnehmeridentitätsmodul kann dabei mehrere unterschiedliche Profile aufweisen.

Änderungen an einem Profil erfordern dabei das Bereitstellen eines vollständigen Profils. Bei konventionellen Plug-In-SIM-Karten könnte die Profil-Änderung einfach durch Austausch der SIM-Karte im Endgerät durchgeführt werden. Alternativ wird ein neues Profil in dem Teilnehmeridentitätsmodul eingerichtet, was besonders bei Teilnehmeridentitätsmodulen durchgeführt wird, die nicht ohne Weiteres im Endgerät ausgetauscht werden können. Beim Einrichten eines Profils in einer eUICC wird eine Profil-Dateistruktur in dem Teilnehmeridentitätsmodul erstellt und Profil-Daten werden in einem nachgelagerten Schritt in diese Profil-Dateistruktur hineingeladen und dort installiert. Die technischen GSMA Spezifikationen„12FAST.13 - Embedded SIM Remote Provisioning Architecture 17 Dezember 2013“ - nachfolgend als technische Spezifikation [1] bezeichnet - und „SGP02-Remote-Provisioning-Architecture-for-Embedded-UICC- Technical-Spezifikation V2.0, 13 Oktober 2014“ - nachfolgend als technische Spezifikation [2] bezeichnet - beschreiben eine derartige Verwaltung von Subskriptionen. Die technische Spezifikation [1] beschreibt dabei die Aufgaben und Funktionen, mittels derer ein Profil von einem Subskriptions-Server in eine eUICC geladen und dort installiert wird. Die technische Spezifikation [2] beschreibt den protokollarischen Ablauf beim Herunterladen und Installieren eines Subskriptions-Profils in eine eUICC. Fig. 1 zeigt vereinfacht ein System zum Verwalten von Profilen bzw. Teilnehmeridentitätsmodulen gemäß der technischen Spezifikationen [1] und [2]. Aspekte betreffend das Herunterladen und Installieren von Subskriptionen in eUICCs sind zudem in den technischen Spezifikationen [3] GSMA SGP.22 - RSP Technical Specification, Version 2.2, 01 September 2017, und [4] GSMA SGP.21 - RSP Architecture, Version 2, 01 September 2017, offenbart.

Ein Aktivieren eines Profil, ein Deaktivieren eines Profils, ein Löschen eines Profils, ein Erstellen eines Profils, ein Wechsel von einem ersten Profil auf ein zweites Profil und/oder das Aktualisieren eines vorhandenen Profils wird beispielsweise zu einem Zeitpunkt erforderlich, zu dem das Teilnehmeridentitätsmodul bereits an einen Teilnehmer ausgeliefert ist und ein Profil zum Nutzen von Diensten eines Kommunikationsnetzes verwendet wird. Darüber hinaus könnte der Teilnehmer zu einem Zeitpunkt nach der Auslieferung/Herstellung des Teilnehmeridentitätsmoduls wünschen, weitere Dienste des Kommunikationsnetzes oder eines anderen Kommunikationsnetzes zu nutzen. Derartige Vorgänge können nicht während einer Personalisierung bei der Herstellung von Teilnehmeridentitätsmodulen vorbereitet werden.

Wünschenswert ist eine Lösung zum Verwalten von Subskriptions-Profilen, bei welcher die Menge der an das Teilnehmeridentitätsmodul gesendeten Daten, insbesondere der zusätzlich zu den eigentlichen Profil-Daten eines Profils gesendeten Daten, stark reduziert ist.

Die DE 10 2012 018 540 Al offenbart dazu ein Teilnehmeridentitätsmodul mit zwei identischen Profilen, bei denen immer nur eins aktiv sein darf. Somit kann ein Subskriptionswechsel weitgehend ohne OTA Übertragung von Daten vorgenommen werden. Unterschiedliche Profile können dabei aber nicht betrieben werden.

Die EP 2 802 162 Al beschreibt eine SIM-Karte, in der eine Profil-Vorlage permanent eingebracht ist. Aus dieser Profil-Vorlage lassen sich mittels eines von einem Server an die SIM- Karte gesendeten Befehls Profil-Strukturen erzeugen. Diese Profil-Strukturen können in einem zweiten Schritt mit Profil-Daten befällt werden. Diese Profil-Vorlage benötigt permanent Speicherplatz in der SIM-Karte. Dieser Speicherplatz steht sodann nicht mehr für Profile bereit.

Die DE 10 2012 020 690 Al beschreibt eine eUICC, bei der verschiedene Profile abgelegt sind. Mittels einer Femverwaltung werden Teilnehmeridentitätsdaten durch ein Ladekommando aktiviert, indem ein Link auf eine Datei umgeschrieben wird. Die Datei verbleibt dabei immer an ihrem Speicherort, wodurch Speicherzugriffe reduziert werden können. Es änderts sich lediglich der Aufruf der Datei. Auch hier wird eine permanent eingebrachte Profil-Vorlage benötigt.

Die WO 2016/128 141 Al beschreibt eine eUICC mit einer lokalen Klonierungsfunktion. Die lokale Klonierungsfunktion der eUICC kopiert eine Profil-Dateistruktur eines vorhandenen ersten Profils und speichert diese als zweite Profil-Dateistruktur in der eUICC. In diese zweite Profil-Dateistruktur werden in einem Folgeschritt zweite Profil-Daten aufgenommen., um ein zweites Profil einzurichten.

Manchmal unterscheiden sich zwei Profile nur geringfügig, wenn ein erstes Profil durch ein zweites Subskriptions-Profil ersetzt werden soll. Beispielsweise können nur einzelne Parameter oder Daten (nachfolgend als Teile von Profil-Daten bezeichnet) des zweiten Profils von einzelnen Parametern oder Daten des ersten Profils verschieden sein, wohingegen alle übrigen Parameter oder Daten des ersten Profils vollkommen identisch mit den Profil-Daten des zweiten Profils sind. Dennoch muss bislang stets ein vollständiges Profil heruntergeladen werden.

Manchmal soll ein vorhandenes aktives Profil nur um eine weitere Funktionalität erweitert werden oder auf eine aktuellere Version umgestellt werden. Bislang muss dabei stets das vollständige Profil neu erstellt und eingerichtet (geladen und installiert) werden. Dies verursacht ein hohes Datenaufkommen im Kommunikationsnetz. Zudem müssen zumindest Teile der Profil-Daten und ggf. auch der Profil-Dateistruktur neu zwischen zwei Systemkomponenten des in Fig. 1 gezeigten Systems (außerhalb des Teilnehmeridentitätsmoduls) ausgehandelt werden, beispielsweise OTA-Schlüssel oder sonstige Teilnehmeridentitätsdaten. Dieses Aushandeln verursacht zusätzliches Datenaufkommen im Kommunikationsnetz.

ZUSAMMENFASSUNG DER ERFINDUNG

Der Erfindung liegt die Aufgabe zu Grunde, ein Teilnehmeridentitätsmodul bzw. Verfahren zu schaffen, die ein Bereitstellen und Verwalten von Subskription-Profilen im Teilnehmeridentitätsmodul mit einer noch geringeren Menge von an das Teilnehmeridentitätsmodul zu übertragenden Daten im Kommunikationsnetz erlaubt. Die Aufgabe wird gelöst durch ein Teilnehmeridentitätsmodul nach einem der vorhergehenden Ansprüche gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.

Erfindungsgemäß wird ein Verfahren zum Bereitstellen von Subskriptions-Profilen an ein Teilnehmeridentitätsmodul, bevorzugt eine eUICC, mittels eines Subskriptions-Servers, bevorzugt eines SM-DP, vorgesehen. Dabei hat der Subskriptions-Server Kenntnis über ein im Teilnehmeridentitätsmodul installiertes erstes Subskriptions-Profil aufweisend eine erste Profil- Dateistruktur und in der ersten Profil-Dateistruktur abgespeicherte erste Profil-Daten. Im Subskriptions-Server laufen die folgenden Verfahrensschritte ab: Markieren zumindest eines Teils einer zweiten Profil-Dateistruktur eines zweiten Subskriptions-Profils; und Senden des zweiten Subskriptions-Profils zum Teilnehmeridentitätsmodul, wobei der markierte Teil des zweiten Subskriptions-Profils ohne zweite Profil-Daten gesendet wird, wobei im Senden-Schritt diejenigen ersten Profil-Daten des ersten Subskriptions-Profils angegeben werden, die zu kopieren sind, um als zweite Profil-Daten in den markierten Teil der zweiten Profil-Dateistruktur des zweiten Subskriptions-Profils abgespeichert zu werden.

Bei einem Teilnehmeridentitätsmodul im Sinne der Erfindung handelt es sich um ein in Baugröße und Ressourcenumfang reduziertes elektronisches Modul, welches einen Mikrocontroller und mindestens eine Datenschnittstelle zur Kommunikation mit dem Endgerät aufweist. Dieses Teilnehmeridentitätsmodul weist einen sicheren Speicherbereich auf, indem Teilnehmeridentitätsdaten sicher eingebracht sind, um Manipulation- und/oder Missbrauchsversuche bei der Identifizierung und/oder Authentisierung am Netzwerk zu verhindern. Das Teilnehmeridentitätsmodul ist mittels eines Endgeräts betriebsfähig, wobei das Modul bis auf Versorgungssignale, wie Versorgungsspannung, Takt, Reset etc. autark ist.

Bei dem Teilnehmeridentitätsmodul handelt es sich beispielsweise um eine Chipkarte, auch als Universal Integrated Circuit Card, kurz UICC, oder SIM-Karte bezeichnet. Das Teilnehmeridentitätsmodul dient dazu, mit den im sicheren Speicherbereich gespeicherten maschinenlesbaren Teilnehmeridentitätsdaten einen Teilnehmer in einem Kommunikationsnetz zu identifizieren und für das Nutzen von Diensten zu authentifizieren.

Alternativ handelt es sich bei dem Teilnehmeridentitätsmodul um einen integralen Bestandteil innerhalb des Endgeräts, beispielsweise als fest verdrahteter elektronischer Baustein. Derartige Teilnehmeridentitätsmodule werden auch als embedded UICC (eUICC) bezeichnet. In dieser Bauform sind diese Teilnehmeridentitätsmodule nicht für eine Entnahme aus dem Endgerät vorgesehen und können prinzipiell nicht einfach ausgetauscht werden. Derartige Teilnehmeridentitätsmodule können auch als embedded Secure Elements, also als eine sichere Hardwarekomponente im Endgerät ausgestaltet sein.

Alternativ handelt es sich bei dem Teilnehmeridentitätsmodul um ein Machine-to-Machine-, kurz M2M-, Modul. Diese Module dienen der Fernüberwachung, -kontrolle und -Wartung von Endgeräten wie Maschinen, Anlagen und Systemen. Sie können alternativ auch für Zähleinheiten wie Stromzähler, Warmwasserzähler etc. verwendet werden.

Alternativ ist das Teilnehmeridentitätsmodul als eine Softwarekomponente in einem vertrauenswürdigen Teil eines Betriebssystems, einer sogenannten Trusted Execution Environment, kurz TEE, des Endgerätes ausgebildet. Das Teilnehmeridentitätsmodul ist dann beispielsweise innerhalb einer gesicherten Laufzeitumgebung in Form von darin ablaufenden Programmen, sogenannten„Trustlets“ ausgebildet.

Teilnehmeridentitätsdaten im Sinn der Erfindung sind beispielsweise Daten, die einen Teilnehmer eindeutig im Kommunikationsnetz identifizieren. Dazu zählt beispielsweise eine Teilnehmerkennung, auch International Mobile Subscriber Identity, kurz IMSI und/oder teilnehmerspezifische Daten. Die IMSI ist das in einem Mobilfunkkommunikationsnetzwerk eindeutige Teilnehmeridentitätsdatei. Sie setzt sich zusammen aus dem Landescode MCC (Mobile Country Code), dem Netzwerkcode MNC (Mobile Network Code) und einer laufenden Nummer, die vom Netzbetreiber vergeben wird.

Darüber sind Teilnehmeridentitätsdaten beispielsweise Daten, die einen Teilnehmer eindeutig am Kommunikationsnetz authentisieren, beispielsweise ein Authentisierungsalgorithmus, spezifische Algorithmus-Parameter, ein kryptografischer Authentisierungsschlüssel Ki und/oder ein kryptografischer Over-The-Air, kurz OTA, Schlüssel.

Ein Kommunikationsnetzwerk im Sinn der Erfindung ist eine technische Einrichtung, auf der die Übertragung von Signalen unter Identifizierung und/oder Authentisierung des Teilnehmers stattfindet, wodurch Dienste angeboten werden. Das Kommunikationsnetz ist bevorzugt ein Mobilfunknetz. Eine Gerät-zu-Gerät Kommunikation unter Aufsicht des Kommunikationsnetzes ist ebenfalls denkbar. Insbesondere wird hier ein Mobilfunknetz beispielsweise das„Global System for Mobile Communications”, kurz GSM als Vertreter der zweiten Generation oder das „General Packet Radio Service”, kurz GPRS bzw. „Universal Mobile Telecommunications System”, kurz UMTS als Vertreter der dritten Generation, das„Long Term Evolution”, kurz LTE, als Vertreter der vierten Generation als Mobilfunknetz verstanden oder ein Mobilfunknetz der 5. Generation mit dem derzeitigen Arbeitstitel„5G“ als ein Kommunikationsnetz verstanden. Ein Dienst ist insbesondere ein Sprachdienst oder ein Datendienst, mit dem Informationen und/oder Daten über das Kommunikationsnetzwerk übertragen werden.

Ein Subskriptions-Server ist eine Komponente, die Teil des Kommunikationsnetzes ist oder mit ihm in Kommunikationsverbindung steht, um Teilnehmeridentitätsmodule zu verwalten, beispielsweise verschieden Profile zu erstellen („create profile “), einzurichten („profile download and Installation“), zu aktivieren („enable profile“), zu deaktivieren („disable profile“) und/oder zu löschen („delete profile“). Der Subskriptions-Server ist beispielsweise in Serverkomponenten, beispielsweise einem Subscription Managing Secure Routing Server, SM- SR und einen Subscription Managing Data Preparation, SM-DP unterteilt, oder ist ein kombinierter SM-DP+ Server gemäß Spezifikation [3] SGP.21 oder [4] SGP.22, der SM-SR und SM-DP in dem einzigen Server SM-DP+ beinhaltet, wobei jeweils das erfindungsgemäße Verfahren bevorzugt mit einem SM-DP - bzw. dem SM-DP-Teil des SM-DP+ - durchgeführt wird. Die Kommunikation zwischen Subskriptions-Server und eUICC erfolgt bevorzugt über einen sicheren Kanal, beispielsweise SCP80 und SCP81, wie in ETSI 102 225 und/oder ETSI 102 226 definiert ist.

Das erfindungsgemäße Teilnehmeridentitätsmodul weist mindestens das erste Profil mit einer ersten Dateistruktur und darin installierten ersten Profildaten auf. Das Teilnehmeridentitätsmodul kann bereits weitere unterschiedliche Profile aufweisen. Installierte erste Profil-Daten sind insbesondere Profil-Daten, die vollständig auf dem Teilnehmeridentitätsmodul eingerichtet sind. Der Subskriptions-Server hat also während einer„download and Installation“ Prozedur gemäß technischer Spezifikationen [1] oder [2] eine„download complete“ als Bestätigung erhalten hat, bzw.eine Notification gemäß [4] SGP.22, Kapitel 3.5, dass das erste Profil eingerichtet ist und alle Zustände eines Lebenszyklus eines Profils im Subskriptions-Management aufweisen kann.

Eine Dateistruktur im Sinne der Anmeldung ist insbesondere ein strukturierter profilbasierter Sicherheitsbereich, englisch profile security domain, beispielsweise ein ISD-P gemäß den technischen Spezifikationen [1] oder/und [2] oder [3] oder [4]. Jedem Profil eines Teilnehmeridentitätsmoduls sind eine Profil-Dateistruktur und darin abzulegende Profil-Daten eindeutig zugeordnet. Ein Profil ist dabei bevorzugt einem Teilnehmeridentitätsmodul eindeutig zugeordnet, sogenanntes „profile binding package“. Auf einem Teilnehmeridentitätsmodul können mehrere Profile mit unterschiedlichen Profil-Dateistrukturen und darin abgelegten unterschiedlichen Profil-Daten nebeneinander existieren. Das Einrichten einer Profil- Dateistruktur ist nur mittels eines Subskriptions-Servers möglich, der entsprechende Zugriffsrechte für ein derartiges Einrichten mittels eines der Profil-Dateistrukturen übergeordneten teilnehmeridentitätsmodulbasierten Sicherheitsbereich aufweist, beispielsweise ein ISD-R gemäß den technischen Spezifikationen [1], [2], [3], [4]. Wenn eine neue (zweite) Profil-Dateistruktur auf dem Teilnehmeridentitätsmodul erstellt werden darf, beispielsweise für die Kommunikation über ein anderes (weiteres) Kommunikationsnetz oder das gleiche Netz mit anderen Dienstnutzungen, kann eine solche Dateistruktur (ISD-P) mit Hilfe des Subskriptions- Servers im Rahmen einer„create profile“ Prozedur erstellt werden.

Jedes der in dem Teilnehmeridentitätsmodul eingerichteten Profile weist eine eigene Dateistruktur mit darin installierten Profil-Daten auf. Diese Profil-Daten ermöglichen den Aufbau, Betrieb und Abbau einer Verbindung des Endgeräts im Kommunikationsnetz. Die Profildaten eines Profils sind insbesondere Daten, die einen Teilnehmer eindeutig am Kommunikationsnetz identifizieren und authentisieren können, beispielsweise ein Authentisierungsalgorithmus, spezifische Algorithmus-Parameter, ein kryptografischer Authentisierungsschlüssel Ki, ein kryptografischer Over-The-Air (OTA) Schlüssel, eine Teilnehmerkennung, IMSI; eine Teilnehmeridentitätsmodulkennung, 1CCID. Die Profil-Daten können auch Anwendungen sein, die diesem Profil eindeutig zuzuordnen sind, beispielsweise eine Authentisierungsanwendung, eine Signieranwendung, oder eine Verschlüsselungsanwendung.

Insbesondere sind erste Profil-Daten in einer ersten Profil-Dateistruktur eines ersten Profils installiert. Ein Teil dieser ersten Profil-Daten kann erfindungsgemäß in einer zweiten Dateistruktur eines zweiten Profils installiert werden (nachfolgend auch als Kopieren und Abspeichern bezeichnet). Damit wird dieser Teil der ersten Profil-Daten als Teil der zweiten Profildaten weiterverwendet. Durch das Weiterverwenden dieses Teils der Profil-Daten kann ein Datenaufkommen im Kommunikationsnetz eingespart werden, da einerseits dieser Teil der Profildaten nicht vom Server zum Teilnehmeridentitätsmodul transportiert (übertragen) werden muss und andererseits, dieser Teil der zweiten Profil-Daten nicht im System gemäß Fig. 1 zwischen unterschiedlichen Systemkomponenten ausgehandelt oder generiert werden muss.

Die Profil-Daten weisen beispielsweise mindestens einen Ordner (Directory File, DF) und mindestens eine Elementardatei (Elementary File, EF) auf. In diese DF und EF sind möglicherweise der Authentisierungsalgorithmus, spezifische Algorithmus-Parameter, der Ki, der OTA Schlüssel, die IMSI, die ICC ID untergebracht. Der Authentisierungsalgorithmus, die spezifischen Algorithmus-Parameter, der Ki, der OTA Schlüssel, die IMSI, die ICCID etc. können statt in DFs und EFs alternativ auch als Objekte oder anderweitig, ohne File-System- Struktur, im Speicher abgelegt sein.

Als ein (zu markierender bzw. markierter) Teil einer Profil-Dateistruktur wird bevorzugt eine Untermenge der gesamten zweiten Profil-Dateistruktur eines zweiten Profils bezeichnet. Dieser Teil kann wiederum die Gesamtheit oder auch nur eine Untermenge einer gesamten ersten Profil-Dateistruktur eines ersten Profils umfassen. Beispielsweise umfasst das zweite Profil die Gesamtheit der Profil-Dateistruktur des (bereits in dem Teilnehmeridentitätsmodul installierten) ersten Profils und darüber hinaus noch Funktionserweiterungen oder Aktualisierungen. Der bereits installierte Teil eines ersten Profils wird nun erfindungsgemäß nicht beim Senden des zweiten Profils gesendet, sondern in dem Teilnehmeridentitätsmodul lokal vom ersten Profil kopiert.

Das Markieren erfolgt also für einen Teil der zweiten Profil-Dateistruktur, in dem normalerweise zweite Profil-Daten eingerichtet würden. Da diese zweiten Profil-Daten nach Kenntnis des Servers bereits in der ersten Profil-Dateistruktur als erste Profil-Daten im ersten Profil des Teilnehmeridentitätsmoduls vorhanden sind, kann ein erneutes Senden an das Teilnehmeridentitätsmodul unterbleiben. Damit ist es möglich, bereits installierte Profil-Daten, weiterzuverwenden, ohne dass diese erneut vom Server bereitgestellt werden müssen und/oder ohne dass diese zwischen Systemkomponenten ausgehandelt werden müssen. Dies verringert das Datenaufkommen beim Bereitstellen eines neuen Profils. Zudem wird der Aufwand zur Synchronisation von zu synchronisierenden Strukturen verringert. Zu aktualisierende Strukturen sind z.B. Zähler wie der OTA-Zähler, der die Anzahl OTA-Einwahlen des Teilnehmeridentitätsmoduls zählt, und der Authentisierungszähler, welcher die Anzahl der mit dem Teilnehmeridentitätsmodul bereits durchgeführten Authentisierungen zählt. Zudem kann ein Nutzer beispielsweise seine PIN mitnehmen, mit welcher der Zugang zum Teilnehmeridentitätsmodul beschränkt ist, insbesondere eine eventuell geänderte PIN.

Der markierte Teil der zweiten Dateistruktur betrifft erste Profil-Daten für das zweite Profil, die bereits im Teilnehmeridentitätsmodul installiert sind. Diese ersten Profil-Daten können in einem oder in mehreren eingerichteten Profilen des Teilnehmeridentitätsmoduls installiert sein.

Die zweite Profil-Dateistruktur des zweiten Profils wird entsprechend markiert. Beispielsweise wird in die zweite Profil-Dateistruktur anstelle der zweiten Profil-Datei ein Hinweis als die Markierung eingebracht. Dieser Hinweis umfasst eine Information von welchem Teil eines bereits auf dem Teilnehmeridentitätsmodul installierten Profils dieser markierte Teil der Profil- Dateistruktur kopiert werden kann. Der Hinweis ist vom Teilnehmeridentitätsmodul interpretierbar und führt das Teilnehmeridentitätsmodul zu den zu den nicht-gesendeten zweiten Profildaten entsprechenden ersten Profildaten.

Beispielsweise ist die Markierung eine Kennzeichnung in der zweiten Profil-Dateistruktur, beispielsweise ein gesetztes Flag für eine Profil-Datei. Jede Kennzeichnung zeigt dem Teilnehmeridentitätsmodul an, dass für diese spezielle zweite Profil-Datei eine erste Profil-Datei eines bereits vorhandenes (installierten) ersten Profils zu verwenden ist. Die zweiten Profildaten der zweiten Profil-Dateistruktur werden nicht mitgesendet. Das zweite Profil ist demnach beim Empfang im Teilnehmeridentitätsmodul unvollständig und kann in dieser unvollständigen Form noch nicht für ein Authentisieren/Identifizieren am Kommunikationsnetz verwendet werden.

Während bzw. mit dem Senden wird vom Server angegeben, wo sich die (nicht-gesendeten) fehlenden Profil-Daten des zweiten Profils auf dem Teilnehmeridentitätsmodul befinden. Diese Angabe wird vom Teilnehmeridentitätsmodul dahingehend interpretiert, dass die angegebenen ersten Profildaten zu kopieren sind und in der zweiten Dateistruktur als zweite Profil-Daten abzuspeichem sind. Nachdem alle ersten Profil-Daten auch in der zweiten Profil-Dateistruktur abgelegt wurden, ist das zweite Profil vollständig. Diese Angabe kann beispielsweise eine Liste von ersten Profil-Daten sein, die vom Teilnehmeridentitätsmodul nacheinander abgearbeitet wird, um ggf. eine Mehrzahl von ersten Profildaten aus einem vorhandenen ersten (oder mehreren) Profil(en) zu kopieren.

Alternativ oder zusätzlich zu einer Liste kann auch eine Regel definiert werden, dass die fehlenden Profil-Daten des markierten Teils der zweiten Profil-Dateistruktur automatisch aus einem vorhandenen Profil, beispielsweise dem derzeit aktivierten Profil, kopiert werden, um das zweite Profil zu vervollständigen.

Das Kopieren erfolgt beispielsweise während einer Installieren-Prozedur gemäß der technischen Spezifikationen [1] und [2] und wird durch ein Applet des Teilnehmeridentitätsmoduls realisiert.

Wird beispielsweise ein erstes Profil lediglich aktualisiert oder erweitert, ist es nunmehr möglich, bereits ausgehandelte Identifizierungs- und Authentisierungsdaten, wie (IMSI, ICCID; Ki, OTA, etc.) auch für ein - zum ersten Profil erweitertes - zweites Profil weiterzu verwenden. Damit wird in dem Teilnehmeridentitätsmodul zunächst ein zweites unvollständiges Profil empfangen und mittels einer Kopier- und Abspeicherungs-Funktion in der eUICC vervollständigt. Aufwendiges Erzeugen des markierten Teils der Profil-Daten der zweiten Profil- Dateistruktur kann dabei entfallen, beispielsweise kann ein bereits ausgehandeltes OTA- Schlüsselpaar weiterverwendet werden, die ausgehandelten Authentisierungsparameter bleiben auch für das zweite Profil gültig. Auf komplexe Anpassungen von Sicherheitsbereichen oder Applikationen in der Kommunikationsnetz-Infrastruktur verzichtet werden.

Das erste Profil ist ein Profil, welches auf dem Teilnehmeridentitätsmodul vollständig eingerichtet ist. Es ist bevorzugt das aktivierte Profil. Alternativ ist unter dem ersten Profildaten ein aus verschiedenen eingerichteten Profilen des Teilnehmeridentitätsmoduls zusammengesetzter Datensatz gefasst.

Der Subskriptions-Server ist dabei eine Fern Verwaltung des Teilnehmeridentitätsmoduls, insbesondere gemäß der Definition aus den technischen Spezifikationen [1] und [2].

Das Teilnehmeridentitätsmodul weist erfindungsgemäß alle zum Kopieren der Profil-Daten benötigten Zugriffsrechte auf, es kann insbesondere für das Erstellen des zweiten Profils auf unterschiedliche erste Profile des Teilnehmeridentitätsmodul zugreifen. Entsprechende Rechte- Regeln in den technischen Spezifikationen [1] und [2] sind dabei ggf. abzuändem.

In einer bevorzugten Ausgestaltung umfasst das Verfahren zudem die Schritte: Empfangen einer Bestätigung vom Teilnehmeridentitätsmodul, dass die diejenigen ersten Profil-Daten kopiert wurden und dass die kopierten ersten Profil-Daten in den markierten Teil der zweiten Profil- Dateistruktur des zweiten Subskriptions-Profils abgespeichert wurden; und Senden eines Profil- Aktivieren Kommandos an das Teilnehmeridentitätsmodul zum Aktivieren des zweiten Subskriptions-Profils. Die Bestätigen kann beispielsweise im Rahmen einer „Download complete“ Bestätigung in der„download and installation“ Prozedur gemäß der technischen Spezifikationen [1] und [2] durch die eUICC erfolgen.

Das Senden des Profil- Aktivieren Kommandos an das Teilnehmeridentitätsmodul zum Aktivieren des zweiten Subskriptions-Profils bewirkt bevorzugt ein automatisches Deaktivieren des ersten Profils. Ein Umschalten zwischen zwei Profilen ist somit erfolgt.

Bevorzugt umfasst das Verfahren weiter das Senden eines Löschen-Kommandos an das Teilnehmeridentitätsmodul zum Löschen derjenigen zumindest ersten Profil-Datei des ersten Subskriptions-Profils. Damit ist sichergestellt, dass auf der eUICC keine zwei Profile mit gleichen sicherheitsrelevanten Profil-Daten abgelegt sind. Ein sogenanntes Klonen ist damit unterbunden.

Bevorzugt ist der markierte Teil der zweiten Dateistruktur des zweiten Subskriptions-Profils zumindest eines der folgenden Elemente: zumindest eine Profil-Elementardatei; eine Teilnehmerkennung (IMSI); eine Teilnehmeridentitätsmodulkennung (ICCID); ein Authentisierungsschlüssel (Ki); ein OTA-Schlüssel; eine Subskription-Profil Anwendungsaktualisierung; und/oder eine Subskription-Profil-Datei-Aktualisierung.

In einem weiteren Aspekt betrifft die Erfindung ein Verfahren zum Verwalten von Subskriptionsprofilen in einem Teilnehmeridentitätsmoduls, bevorzugt eine embedded UICC, wobei im Teilnehmeridentitätsmodul zumindest ein erstes Subskriptions-Profil installiert ist und wobei das erste installierte Subskription-Profil eine erste Profil-Dateistruktur und in der Dateistruktur abgespeicherte erste Profil-Daten umfasst. Im Teilnehmeridentitätsmodul laufen die folgenden Verfahrensschritte ab: Empfangen eines zweiten, unvollständigen Subskriptions- Profils von einem Subskriptions-Server unter Angabe von ersten Profil-Daten des ersten Subskriptions-Profils, die zu kopieren sind, und als zweite Profil-Daten in die zweite Profil- Dateistruktur des zweiten unvollständigen Subskriptions-Profils abzuspeichem sind; Kopieren der angegebenen ersten Profil-Daten des ersten Subskriptions-Profils; Abspeichem der kopierten angegebenen ersten Profil-Daten in der zweiten Profil- Dateistruktur des zweiten Subskriptions- Profils, um das zweite Subskriptions-Profil zu vervollständigen, wodurch das zweite Subskription-Profil eingerichtet ist; und Senden einer Bestätigung an den Subskriptions-Server, dass die angegeben ersten Profil-Daten in den markierten Teil der zweiten Profil-Dateistruktur des zweiten Subskriptions-Profils abgespeichert wurden.

Mit Kopieren und Abspeichem ist sowohl ein temporäres Vervielfältigen als auch ein bloßes Verschieben der entsprechenden Profil-Daten in die zweite Profil-Dateistruktur zu verstehen.

Das Kopieren erfolgt beispielsweise im Rahmen einer Installations-Prozedur gemäß der technischen Spezifikationen [1] und [2], wobei die Angabe beim Senden des zweiten Profils verwendet wird, um die entsprechenden (fehlenden) zweiten Profil-Daten aus einem bereits eingerichteten Profil zu kopieren und in der zweiten Profil-Dateistruktur abzulegen. Dazu können ggf. die Funktionen„Store Metadaten“ etc. in Verbindung mit dem Kopieren der Profildaten verwendet werden.

Bevorzugt umfasst das Verfahren weiter ein Empfangen eines Profil-Aktivieren Kommandos vom Subskriptions-Server zum Aktivieren des zweiten Subskriptions-Profils; und ein Aktivieren des zweiten Subskriptions-Profils unter Deaktivieren des ersten Subskriptions-Profils.

Bevorzugt umfasst das Verfahren weiter ein Empfangen eines Löschen-Kommandos vom Subskriptions-Server zum Löschen zumindest der ersten Profil-Daten des ersten Subskriptions- Profils. Damit bleibt die erste Dateistruktur erhalten und kann für ein einzurichtendes weiteres (drittes) Profil genutzt werden. Alternativ kann auch das gesamte erste Profil gelöscht werden.

Bevorzugt wird das Kopieren der angegebenen ersten Profil-Daten und das Abspeichem der kopierten angegebenen ersten Profil-Daten in die zweite Profil-Dateistruktur des zweiten Subskriptions-Profils ohne Übertragung von Daten, insbesondere Profil-Daten, zwischen dem Teilnehmeridentitätsmodul und dem Subskriptions-Server durchgeführt. Bevorzugt umfassen die Verfahrensschritte eine Erstei len-Funktion („create profile“) und/oder eine Aktivieren-Funktion („enable profile“) und/oder eine Deaktivieren-Funktion („disable profile“) gemäß der technischen Spezifikationen [1] und [2].

In einem weiteren Aspekt ist ein Teilnehmeridentitätsmodul, eingerichtet für ein oder umfassend ein im Teilnehmeridentitätsmodul installiertes erstes Subskriptions-Profil vorgesehen, wobei das erste installierte Subskription-Profil eine erste Profil-Dateistruktur und in der Profil- Dateistruktur abgespeicherte erste Profil-Daten umfasst. Das Teilnehmeridentitätsmodul umfasst eine Kopier- und Abspeichem-Funktion, die dazu eingerichtet ist, nach einem Empfangen eines zweiten, unvollständigen Subskriptions-Profils von einem Subskriptions-Server unter Angabe von ersten Profil-Daten des ersten Subskriptions-Profils, die angegebenen ersten Profil -Daten des ersten Subskriptions-Profils in eine zweite Profil-Dateistruktur eines zweiten unvollständigen Subskriptions-Profils zu kopieren, um das zweite Subskriptions-Profil zu vervollständigen, wodurch das zweite Subskriptions-Profil im Teilnehmeridentitätsmodul eingerichtet ist.

Die Kopier- und Abspeichem-Funktion ist bevorzugt durch eine Funktionalität des Betriebssystems realisiert, die nach dem Empfang des zweiten, unvollständigen Subskriptions- Profils gestartet wird. Eine Funktionalität des Betriebssystems ist bevorzugt, da gerade sensitive Daten verschlüsselt abgespeichert werden, und es Vorteile hat wenn Applets keinen Zugriff auf solche Daten haben. Die Kopier- und Abspeichem-Funktion kann aber alternativ auch durch ein Applet realisiert sein, welches eingerichtet ist, nach dem Empfangen des zweiten, unvollständigen Subskriptions-Profils zu starten, mit den oben beschriebenen Nachteilen, aber dem Vorteil größerer Flexibilität. Wahlweise ist die Kopier- und Abspeichem-Funktion ist durch eine Funktionalität des Betriebssystems realisiert, und die Funktionalität (Kopier- und Abspeichem-Funktion) des Betriebssystems wird durch ein Applet lediglich ausgelöst, nachdem der Empfang des zweiten, unvollständigen Subskriptions-Profils erfolgt ist; das Ausfuhren der Funktionalität erfolgt hingegen durch das Betriebssystem, und nicht durch das Applet.

Bevorzugt umfasst das Teilnehmeridentitätsmodul einen Datenspeicher zum Abspeichern der Subskriptions-Profile; eine Schnittstelle, die eingerichtet ist zur Kommunikation mit dem Subskriptions-Server, bevorzugt über ein Endgerät, welches das Teilnehmeridentitätsmodul aufweist; und eine Schnittstelle, die eingerichtet ist zur Kommunikation mit einem Netzwerk- Server. Zudem sind Mittel, die eingerichtet sind, das vorhergehend beschriebene Verfahren durchzuführen, vorgesehen.

Bei einem Endgerät im Sinn der Erfindung handelt es sich prinzipiell um ein Gerät oder eine Gerätekomponente, welches Mittel zur Kommunikation mit dem Kommunikationsnetzwerk aufweist, um Dienste des Kommunikationsnetzes nutzen zu können. Beispielsweise ist ein mobiles Endgerät wie ein Smart Phone, ein Tablet-PC, ein Notebook, ein PDA unter dem Begriff zu fassen. Unter dem Endgerät können beispielsweise auch Multimedia-Endgeräte wie digitale Bilderrahmen, Audiogeräte, Fernsehgeräte, E-Book-Reader verstanden werden, die ebenfalls Mittel zur Kommunikation mit dem Kommunikationsnetzwerk aufweisen. Beispielsweise umfasst der Begriff Endgeräte auch jegliche Art von Maschinen, Automaten, Fahrzeuge, Einrichtungen welche Mittel, insbesondere Mobilfunkmodems, zur Kommunikation mit dem Kommunikationsnetzwerk aufweisen.

In einem weiteren Aspekt ist ein Subskriptions-Server, bevorzugt ein SM-DP, eingerichtet zum Bereitstellen von Subskriptions-Profilen für ein Teilnehmeridentitätsmodul, bevorzugt eine eUICC, vorgesehen, wobei der Subskriptions-Server Kenntnis über ein im Teilnehmeridentitätsmodul installiertes erstes Subskriptions-Profil aufweisend eine erste Profil- Dateistruktur und in der ersten Profil-Dateistruktur abgespeicherte erste Profil-Daten hat. Der Server umfasst eine Markier-Funktion, die dazu eingerichtet ist, zumindest einen Teil einer zweiten Profil-Dateistruktur eines zweiten Subskriptions-Profils zu markieren und eine Sende- Funktion, die dazu eingerichtet ist, das zweite unvollständige Subskriptions-Profil zu senden, wobei der markierte Teil des zweiten Subskriptions-Profils ohne zweite Profil-Daten gesendet wird, wobei die Sende-Funktion diejenigen ersten Profil-Daten des ersten Subskriptions-Profils angibt, die zu kopieren sind, um als zweite Profil-Daten in den markierten Teil der zweiten Profil-Dateistruktur des zweiten Subskriptions-Profils abgespeichert zu werden.

Der Subskriptions-Server umfasst weiter eine Erkennen-Funktion, die dazu eingerichtet ist, den zu markierenden Teil der zweiten Dateistruktur zu erkennen, eine Schnittstelle, die eingerichtet ist zur Kommunikation mit dem Teilnehmeridentitätsmodul, bevorzugt über ein Endgerät, welches das Teilnehmeridentitätsmodul aufweist; eine Schnittstelle, die eingerichtet zur Kommunikation mit einem Netzwerk-Server; und Mittel, die eingerichtet sind, das vorhergehende Verfahren durchzuführen.

Zudem ist ein Computerprogramprodukt vorgesehen, welches ausführbar installiert in einem Teilnehmeridentitätsmodul und aufweisend Mittel zum Ausfuhren der Verfahrensschritte einer der vorhergehenden Verfahren ist. Bevorzugt ist das Computerprogrammprodukt ein Java Card Applet, welches in der eUICC zum Ausfuhren der Verfahrensschritte eingebracht ist.

Eine Funktion ist ein in dem Teilnehmeridentitätsmodul installierter ausführbarer Programmcode, der sich durch ein der Funktion entsprechendes Kommando, das an die Teilnehmeridentitätsmodul gesandt wird, zur Ausführung bringen lässt. Eine Funktion kann Teil eines Applets auf dem Teilnehmeridentitätsmodul sein. Mehrere Funktionen können durch ein Applet nacheinander aufgerufen werden.

Die Kopier- und Abspeichern-Funktion bzw. die entsprechenden Kopier- und abspeichere- Schritte sind somit in der Lage, ohne OTA- Verbindung, innerhalb des Teilnehmeridentitätsmoduls durch Kopieren der ersten Profil-Daten in eine zweite Profil- Dateistruktur, diese ersten Profil-Daten als zweite Profil-Daten anzulegen. Damit wird ein empfangenes unvollständiges zweites Profil vervollständigt. Die herkömmlicherweise erforderlichen Verbindungskosten für die Übertragung der zweiten Profildaten für das zweite Profil an das Teilnehmeridentitätsmodul und auch das ggf. notwendige Aushandeln neuer zweiter Profil-Daten für das zweite Profil können entfallen. Lediglich für ein erforderliches Übertragen der nicht im ersten Profil bereits installierten ersten Profil-Daten als zweiten Profildaten, mit denen das zweite Profil vervollständigt wird, um eingerichtet zu sein, fallen OTA- Verbindungskosten an.

Somit ist erfindungsgemäß ein Teilnehmeridentitätsmodul geschaffen, das ein Verwalten von Subskriptions-Profilen im Teilnehmeridentitätsmodul mit einer geringeren Menge von an das Teilnehmeridentitätsmodul zu übertragenden Daten erlaubt.

Beispielsweise weist das erste Subskriptions-Profil eine Mehrzahl von Profil-Elementardateien als erste Profi-Daten auf, wobei ein oder mehrere Profil-Elementardateien des ersten Subskriptions-Profils kopiert werden mittels der Kopier- und Abspeichern-Funktion.

Im Rahmen des Abspeichems der ersten Profildaten als zweite Profildaten in der zweiten Dateistruktur kann zumindest eines der Profildaten an das zweite Profil angepasst werden, beispielsweise verändert werden oder beispielsweise auf Initialwerte zurückgesetzt werden.

Beispielsweise erfolgt die Kommunikation mittels SMS, HTTPS oder TCP Sitzungen (=Sessions).

Das Aktivieren/Deaktivieren eines Profils erfolgt beispielsweise mittels eines proaktiven Kommandos (REFRESH), welches von der eUICC an das Endgerät gesendet wird, um die eUICC neu zu starten.

Dem Senden des zweiten Profils geht beispielsweise ein Erstellen-Kommando voraus, so wie es in der GSMA-Spezifikation beschrieben ist. KURZE BESCHREIBUNG DER FIGUREN

Nachfolgend wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.

Fig. 1 zeigt eine beispielhafte Ausführung eines Systems zum Verwalten von Teilnehmerprofilen gemäß den GSMA-Spezifikationen [1] und [2];

Fig. 2 zeigt ein erfindungsgemäßes Markieren von Teilen einer Profil -Dateistruktur eines Profils;

Fig. 3 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens in einem Teilnehmeridentitätsmodul;

Fig. 4 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens in einem Subskriptions-Server;

Fig. 5 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zwischen einem Teilnehmeridentitätsmodul und einem Subskriptions-Server.

DETALLIERTE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN

Fig. 1 zeigt eine beispielhafte Ausführung eines Systems zum Verwalten von Teilnehmerprofilen 11a, 1 1b, 1 lx gemäß der oben erwähnten GSMA-Spezifikation [1] und [2]

Gemäß Fig. 1 wird eine eUICC 1 durch den Server 2 femadministriert. Die eUICC 1 ist dabei in einem Endgerät 6 fest- oder entnehmbar installiert. Eine eUICC 1 des Systems in Fig. 1 hat eine Sicherheitsdomäne (=SD) mit unterschiedlichen Privilegien und Konfigurationen für das Verwalten von den Teilnehmerprofilen 1 1a, 1 1b, 1 lx, wie beispielsweise eine ISD-R 12, die durch eine Serverkomponente 2a (=Subscription Manager Secure Routing, kurz SM-SR) verwaltet wird. Eine eUICC-gesteuerte Sicherheitsdomäne, ECASD, kann ebenfalls aufgenommen werden, die durch einen Zertifikatsherausgebers 4 (=englisch Certificate Issuer, CI) auf der eUICC 1 verwaltet wird. Eine Dateistruktur eines Profils 1 1a, 11b, l lx wird durch die Serverkomponente 2b (=die Datenaufbereitung, englisch Subscription Manager Data Preparation SM-DP) verwaltet. In Fig. 1 sind drei Profile 1 1a, 11b, l lx dargestellt, von denen jedes eine Dateistruktur 10 (=ISD-P) aufweist und deren Profildaten innerhalb der Dateistruktur 10 durch den Server 2 verwaltet und gesichert wird. Die Anzahl der Profile 11a, 11b, l lx, die die eUICC 1 beinhalten kann, ist nicht auf drei beschränkt und kann mehr oder weniger betragen.

In Fig. 1 sind der SM-SR 2a und der SM-DP 2b als getrennte Serverkomponenten des Servers 2 dargestellt, sie werden nachfolgend aber als ein Server 2 betrachtet, analog zum Server SM-DP+ gemäß den Spezifikationen [3] und [4].

Pro eUICC 1 ist nur ein ISD-R 12 vorgesehen. Das ISD-R 12 kann von einem eUICC-Hersteller 5, (=eUICC-Manufacturer, EUM), während der Herstellung der eUICC 1 installiert und erstmals personalisiert werden. Nach der Herstellung der eUICC 1 befindet sich das ISD-R 12 im Lebenszykluszustand PERSONALISIERT. Das ISD-R 12 kann sodann Teilnehmerverwaltungs- Funktionen auf jedem ISD-Ps 10 durchfuhren.

Pro Profil 11a, 11b, l lx ist eine Dateistruktur 10a, 10b, lOx (ISD-P) vorgesehen. Auf einer eUICC 1 ist zu jedem Zeitpunkt nur eine Dateistruktur 10a (ISD-P) aktiviert. Eine Dateistruktur 10a (ISD-P) wird vom ISD-R 12 installiert und dann mit dem Server 2 personalisiert. Mindestens eine Dateistruktur 10a (ISD-P) mit einem Profil 11a, 1 1b, l lx kann installiert und erstmals von der EUM 5 während der Herstellung von eUICC 1 personalisiert werden, um zukünftige eUICC-Konnektivität zu ermöglichen.

Außer dem ISD-R 12 hat keine Komponente außerhalb des ISD-P 10 Einsicht oder Zugriff auf eine Profilkomponente der Profile 11a, 1 1b, l lx. Das ISD-R 12 hat Lesezugriff auf Verbindungsparameter der einzelnen Profile 1 1a, 1 1b, l lx. Keine Profi lkomponente ist von Komponenten außerhalb des jeweiligen Profils sichtbar oder zugänglich. Durch das ISD-R 12 wird es erfindungsgemäß ermöglicht, dass zum Installieren eines zweiten Profils auch auf Profil- Daten eines ersten Profils zugegriffen werden kann.

Eine Dateistruktur 10 bleibt während ihrer gesamten Lebensdauer dem ISD-R 12 zugeordnet, damit das ISD-R 12 folgende Teilnehmerverwaltungsfunktionen ausführen kann: Profilerstellung - die Zuordnung zwischen dem ISD-R 12 und einer Dateistruktur 10 kann jederzeit erstellt werden; Profillöschung; Profilaktivierung; Profildeaktivierung; Rückfallpositions-Einstellung; und Profiltransportfunktion. Die Struktur der Profile 1 1a, 1 1b, 1 lx wird in Fig. 2 gezeigt.

In Fig. 1 ist eine Vielzahl von Schnittstellen ESx des System vorgesehen:

Eine Schnittstelle ES8 adressiert Funktionen an die eUICC 1 über einen sicheren Kanal, der zwischen dem SM-DP 2b und der Dateistruktur 10 eines Profils 1 1 aufgebaut ist. Um das in sicherer Form zu ermöglichen, wird das Profil 11 mit mindestens einem Schlüsselsatz personalisiert. Die ES8 Schnittstelle wird durch einen sicheren Kanal realisiert, der durch einen sicheren Kanal zwischen dem SM-DP 2b und dem SM-SR 2a (=ES3-Schnittstelle) eingerichtet ist, und weiter durch einen sicheren Kanal SCP80 oder SCP81 zwischen dem SM-SR 2a über den ISD-R 12 bis in den ISD-P des betroffenen Profils 11 (Profill 11a, Profil2 11b, ... bzw. Profiix l lx) getunnelt werden kann. Die Kommunikation wird dann vom ISD-P 10 (10a, 10b, ... lOx) entschlüsselt und an das jeweilige Profil 1 1 (11a, 11b, ... 1 lx) übergeben.

Die Schnittstelle ES6 adressiert Funktionen an die eUICC 1 über einen sicheren Kanal, der zwischen einem Mobilfunknetzbetreiber (Mobile network Operator, MNO) 3 und einer MNO- Sicherheitsdomäne eingerichtet wurde, die in jedem ISD-P 10 enthalten ist. Die eUICC 1 unterstützt die Ports SCP80 und SCP81 gemäß der Definition in ETSI 102 225 und ETSI 102 226 für diese E6-Schnittstelle. Die anfänglichen OTA-Schlüsselsätze sind Teil jedes Profils 1 l a, 11b, l lx und werden vom SM-DP 2b während eines Profil-Download- und Installationsvorgangs geladen oder von der EUM 5 geladen, bevor eUICC 1 ausgegeben wird.

Die Schnittstelle ES5 adressiert Funktionen an die eUICC 1 über einen sicheren Kanal, der zwischen dem SM-SR 2a und dem ISD-R 12 aufgebaut ist. Die eUICC 1 unterstützt SCP80 und SCP81, wie in ETSI 102 225 und ETSI 102 226 definiert ist, für diese E5-Schnittstelle. Um SCP80/SCP81 zu aktivieren, wird das ISD-R 12 vor der Ausgabe durch die EUM 5 mit entsprechenden Schlüsselsätzen personalisiert. Die Schlüsselsätze werden über die SM-SR 2a in das ISD-R 12 geladen; z.B. mittels Schnittstelle ESI .

Im System von Fig. 1 wird die OTA-Kommunikation ausschließlich von der SM-SR 2a übernommen. Die SM-SR 2a verwendet beispielsweise SMS, CAT TP oder HTTPS für die Over-The-Air, OTA, Kommunikation mit der eUICC 1. Bei Verwendung von HTTPS unterstützen SM-SR 2a und eUICC 1 eine Domain-N ame-Auflösung, um eine IP-Adresse des SM-SR 2a auflösen zu können. In Long-Term-Evolution-Netzen unterstützt das System von Fig.

1 auch Kurznachrichten (=Short-Message-Service, SMS). Die SM-SR 2a ist frei in der Wahl des Übertragungsprotokolls entsprechend der Fähigkeiten der eUICC 1 , des Endgeräts 6 und des ausführenden Servers 2. Die eUICC 1 unterstützt den Versand von sicheren Datenpaketen über SMS gemäß 3GPP TS 31.115.

Gemäß der technischen Spezifikation [1], Kapitel 3.3.1.2.2„Profile Download and Installation Function" wird mit einer„Download“ Funktion ein Profil in eine eUICC 1 geladen. Über „Download“ hinaus sind jedoch weitere, begleitende Funktionen durchzuführen. Gemäß der technischen Spezifikation [1], Kap. 3.3.1.3.1 „ISD-P Creation Function“ und der technischen Spezifikation [2], Kap. 3.1.1 ,,1SD-P Creation“ werden„Create“ Funktionen benötigt, um in der eUICC 1 eine Dateistruktur 10, insbesondere die ISD-P, anzulegen.

Gemäß der technischen Spezifikation [2], Kap. 3.1.3„Download an Installation of the Profile“ wird nach Anlegen der ISD-P ein Profil heruntergeladen und in der Dateistruktur, insbesondere der ISD-P, abgespeichert. Gemäß der technischen Spezifikation [1], Kapitel 3.3.1.2.3„Profile Content Update Function“ und Kapitel 3.3.1.2.4 „Policy Rules Update Function“ werden „Update“ Funktionen angewandt, um Aktualisierungen entsprechend dem neu heruntergeladenen Profil vorzunehmen. Gemäß der technischen Spezifikation [1], Kap. 3.3.1.3.4„Profile Enabling Function“ und der technischen Spezifikation [2], Kap. 3.2„Profile Enabling“ werden„Enable“ Funktionen durchgefuhrt, um ein heruntergeladenes Profil zu aktivieren, insbesondere eine ISD- P, und hierdurch für den Nutzer der eUICC 1 verwendbar zu machen.

Gemäß der technischen Spezifikationen [1] und [2] sind also zusätzlich zur„Download“ Funktion zumindest die drei zusätzlichen Funktionen „Create“, „Update“ und „Enable“ anzuwenden, die einen massiven Overhead verursachen. Jede dieser Funktionen muss kostenverursachend über eine Over-The-Air, OTA, Verbindung vom Server 2 an die eUICC 1 aufgerufen bzw. gesendet werden. Beispielsweise müssen zum Fierunterladen von zehn Kilobyte Profildaten in eine eUICC 1 schätzungsweise mindestens 20 Kilobyte (also ungefähr doppelt so viel) an Daten vom Server 2 via OTA an die eUICC 1 gesendet werden.

Fig. 2 zeigt ein erfindungsgemäßes Markieren von Teilen 1110 einer zweiten Profil- Dateistruktur 10b eines zweiten Profils 1 lb der Fig. 1. Die Dateistruktur 1 lb weist Profil-Daten auf. Beispielsweise kann eine der folgenden Komponenten als Profil-Datei enthalten sein in der Dateistruktur 1 1b: eine MNO-Sicherheitsdomäne (MNO-SD) mit den OTA-Schlüsselsätzen der MNO-Server 3; mindestens ein Authentisierungsparameter (Ki), eine Netzwerkzugriffsanwendung, Richtlinienregeln, ein Dateisystem beinhaltend Ordner (DF) und Elementardateien (EF); Verbindungsparameter des Profils, Anwendungen; eine Teilnehmerkennung, IMSI, eine Teilnehmeridentitätsmodulkennung ICCID, Profilaktualisierungen.

Erfindungsgemäß sind Teile 1110 der Profil-Daten 10b der Dateistruktur 10b des Profils 11b markiert. Diese markierten Teile 1110 sind in Fig. 2 gestrichelt dargestellt. Die Markierung erfolgt im Server 2, bevorzugt im SM-DP 2b, zeitlich bevor das Profil 1 1b in die eUICC 1 geladen wird. Gemäß Fig. 2 sind die markierten Teile 1110 des Profils 11b ein OTA-Schlüssel, eine SSD, eine IMSI und eine ICCID. Diese markierten Teile 1 1 10 sind beim Senden des zweiten Profils 11b vom Server 2 an die eUICC 1 nicht im zweiten Profil 1 lb vorhanden. Somit ist dieser markierte Teil 1 1 10 ein Platzhalter für erste Profildaten eines anderen - auf der eUICC 1 installierten - Profils 1 1a, l lx. Der markierte Teil 1 110 kann nur eine Profil-Datei betreffen oder auch die gesamte Dateistruktur 10b. Die Menge der im markierten Teil 1110 befindlichen Profil-Daten ist nicht beschränkt.

Wenn ein Profil 11b von der eUICC 1 empfangen wird, werden Profildaten aus einem anderen Profil 11a, 1 1 x der eUICC 1 angegeben. Diese angegeben Profil-Daten werden kopiert und an entsprechende Bereiche des markierten Teils 11 10 des zweiten Profils 1 1b abgespeichert. Sind alle Profildaten im markierten Teil 11 10 abgelegt, so gilt das zweite Profil 1 1b als vollständig eingerichtet. Der markierte Teil 1110 repräsentiert beim Empfang in der eUICC 1 also Lücken im unvollständigen Profil 1 1 b, in die eine entsprechende Profil-Datei eines anderen Profils 1 la, 1 lx hineingespeichert werden soll.

Auf diese Weise wird ein unvollständiges Profil geladen, welches mittels Markierung und Angabe der Profil-Daten anderer Profile auf der eUICC 1 durch die eUICC 1 unter Verwendung von Profil-Daten der eUICC 1 vervollständigt wird. Das entsprechende Verfahren dazu ist in den folgenden Figuren 3 bis 5 beschrieben.

Fig. 3 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens 100 in einem Teilnehmeridentitätsmodul 1, nachfolgend als eUICC 1 bezeichnet.

Ein optionaler Schritt 101 stellt dar, dass die eUICC 1 ein erstes Profil 1 la mit ersten Profildaten innerhalb einer ersten Dateistruktur 10a aufweist. Die eUICC 1 empfängt im Schritt 102 ein zweites Profil 1 lb. Zudem empfangt die eUICC 1 im Schritt 102 Angaben von Profildaten aus dem ersten Profil 1 la, die zum Vervollständigen des zweiten Profils 1 lb zu verwenden sind. Im optionalen Schritt 102a wird dazu mittels eines Erstellen-Kommando von einem Server 2, beispielsweise ein„create-Kommando“ der technischen Spezifikationen [1] und [2], eine zweite Profil-Dateistruktur 10b für ein zweites Profil 1 1b aufgebaut.

Nach Erhalt des zweiten Profils 1 1b wird die eUICC 1 im Schritt 103 mittels einer Kopierfunktion in der eUICC 1 die angegebenen Profildaten des ersten Profils 1 1 a kopieren. Nach dem Kopieren-Schritt 103 wird ein Abspeichern-Schritt 104 in der eUICC 1 ausgefuhrt, um die kopierten Profildaten des ersten Profils 1 1a an die jeweilige Stelle des zweiten Profils 1 lb in der eUICC 1 zu platzieren. Mit Blick auf die Fig. 2 wird nach dem Schritt 104 der OTA- Schlüssel des ersten Profils 1 1a auch als OTA-Schlüssel im zweiten Profil abgelegt sein. Weiterhin wird die IMSI des ersten Profils 11a auch als IMSI im zweiten Profil abgelegt sein. Weiterhin wird die ICCID des ersten Profils 1 la auch als ICCID im zweiten Profil abgelegt sein. Weiterhin wird die SSD des ersten Profils 1 la auch als SSD im zweiten Profil abgelegt sein. Eine Vorschrift, welche Profil-Daten aus welchem Profil 1 1 an welche Stelle des zweiten Profils 11b abzulegen sind, wird als das erfindungsgemäße Angeben der Profildaten verstanden. Es kann hierbei eine Liste mit den zu kopierenden Profildaten mitgesendet werden. Die entsprechende Markierung der zweiten Dateistruktur 10b des zweiten Profils 11b kann mittels eines gesetzten Flags realisiert werden. Alternativ werden nicht-vorhandene zweite Profil-Daten (also Platzhalter) in einer Dateistruktur 10b des zweiten Profils 1 lb als Markierung interpretiert.

Am Ende des Schritts 104 ist ein vollständiges zweites Profil 11b in der eUICC 1 erhalten, wobei ein Teil der Profil-Daten des zweiten Profils 1 lb nicht beim Senden des zweiten Profils 11b von dem Server 2 mitgesendet wurden.

Im optionalen Schritt 105 erfolgt das Bestätigen des erfolgreichen Kopierens und Abspeichems an den Server 2. Damit wird dem Server 2 angezeigt, dass nunmehr ein vollständiges zweites Profil 11b in der eUICC 1 vorhanden ist, das nach den gängigen Verfahren der technischen Spezifikationen [1] und [2] behandelt werden kann. Lediglich beispielhaft wird im Schritt 106 ein Aktivieren-Kommando empfangen, mit dessen Hilfe, das zweite Profil 1 lb aktiviert wird und fortan zur Nutzung von Diensten im Kommunikationsnetz des MNO Server 3 der Fig. 1 verwendet wird. In einem optionalen Schritt 1 10 wird das erste Profil 11a in der eUICC 1 gelöscht, um sicherzustellen, dass keine zwei Profile mit gleichen Teilnehmeridentitätsdaten (IMSI, ICCID, OTA Schlüssel, etc.) in der eUICC 1 abgelegt sind.

Fig. 4 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens 200 in einem Subskriptions-Server 2. Der Server 2 ist in einem Schritt 201a in Kenntnis über die in der eUICC 1 befindlichen Profile 11 und kennt damit auch die erste Profil- Dateistruktur 10a und die ersten Profildaten des ersten Profils 11a.

In einem zu ladenden zweiten Profil 1 1b wird gemäß Schritt 201 zumindest ein Teil 1 1 10 der zweiten Dateistruktur 10 b des zweiten Profils 1 1b markiert. Das Ergebnis einer derartigen Markierung 11 10 gemäß Schritt 201 ist in der Fig. 2 dargestellt, wo der markierte Teil 11 10 der Profil-Dateistruktur 10b gestrichelt dargestellt ist. Im Schritt 202 wird das zweite Profil 1 lb an die eUICC 1 gesendet, wobei die Profildaten des markierten Teils 1110 der zweiten Dateistruktur 10b nicht gesendet wird. Dementgegen wird eine Angabe mitgesendet, welche Profildaten aus einem vorhanden Profil 1 1 der eUICC 1 zu kopieren und in den markierten Teil 1110 abzulegen sind. Der zu übertragende Datensatz - der das zweite Profil 1 lb repräsentiert - ist damit verkleinert.

Im Schritt 203 wird eine Bestätigung über einen erfolgreichen Kopier- und Abspeicher-Vorgang (Schritte 103, 104 der Fig. 3) erhalten. Damit ist dem Server 2 signalisiert worden, dass das zweite Profil 1 lb vollständig in der eUlCC 1 vorhanden ist. Im Schritt 203a wird an den MNO- Server 3 gesendet, dass das zweite Profil 2 vollständig ist und eine entsprechende Aktivierung des zweiten Profils 1 1b nun jederzeit erfolgen kann.

Im Schritt 204 sendet der Server 2 ein Aktivieren-Kommando zum Aktivieren des zweiten Profils 1 lb unter gleichzeitiger Deaktivierung des ersten Profils 1 la an die eUICC 1. Daraufhin empfängt der Server 2 im Schritt 205 eine Bestätigung der erfolgreichen Aktivierung durch die eUICC 1. Im Schritt 206 wird optional ein Löschen-Kommando an die eUICC 1 gesendet, um das erste Profil 1 la zu löschen.

In Fig. 5 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zwischen einem Teilnehmeridentitätsmodul 1 und einem Subskriptions-Server 2 gezeigt. Fig. 5 vereint die beiden Verfahren 100 und 200 aus den vorhergehend beschriebenen Figuren 3 und 4. Auf eine Wiederholung des vorher dargestellten kann damit verzichtet werden.

Ausgangspunkt der Erfindung ist das Vorhandensein eines ersten Profils 11a mit einer ersten Dateistruktur 10a und ersten Profildaten in einer eUICC 1. Dieses Vorhandensein und auch der Inhalt des ersten Profils 1 la ist dem Server 2 bekannt, siehe Schritt 201a. Im Schritt 201 wird ein vom ersten Profil 1 la verschiedenes zweites Profil 1 lb markiert, siehe Ausführungen zu Fig. 2. Im Schritt 202 wird vom Server das zweite Profil 1 1b mit der markierten Datei -Struktur unter Angabe der Profildaten des ersten Profils 11a an die eUICC 1 über die Schnittstelle ES5 oder ES8 gesendet. Nach Empfang im Schritt 102 kopiert die eUICC 1 die Profildaten des ersten Profils 1 1a im Schritt 103 und speichert diese im Schritt 104 in der Dateistruktur 10b des zweiten Profils 11b entsprechend ab. Die eUICC 1 bestätigt das erfolgreiche Kopieren und Abspeichem im Schritt 105 (Schritt 203) als Zeichen der Vervollständigung des zweiten Profils 1 1b an den Server 2 über die Schnittstellen ES5 oder ES8. Im Schritt 203a wird dieses Vervollständigen einem M O-Server 3 über die Schnittstellen ES2 oder ES4 angezeigt. Im Schritt 204 erfolgt das Aktiveren des zweiten Profils 1 1 b. Dazu erhält der Server 2 im Schritt 204a eine Aktivierungs-Aufforderung vom MNO-Server 3 über die Schnittstellen ES2 oder ES4. Daraufhin wird im Schritt 204b ein Aktivierungs-Kommando an die eUICC 1 gesendet. Im Schritt 106a wird das zweite Profil 11b aktiviert und (damit gleichzeitig) das erste Profil 1 1a deaktiviert. Im Rahmen der Aktivierung wird im Schritt 107 ein REFRESH proaktives Kommando an das Endgerät 6 gesendet, um die eUICC neu zu starten. Anschließend erfolgt im Schritt 108 ein Bestätigen der Aktivierung an den Server 2. Nach Empfang 205 des Bestätigung wird im Schritt 206 ein Löschen-Kommando vom Server 2 an die eUICC 1 über die Schnittstellen ES5 oder ES8 gesendet, um das erste Profil 1 1a zu löschen oder zumindest die Profildaten des ersten Profils 11a zu löschen. Dies wird von der eUICC 1 im Schritt 110 durchgeführt. Durch das Löschen wird sichergestellt, dass keine zwei gleichen Profildaten in einer eUICC 1 vorhanden sind.

Somit können innerhalb der eUICC 1 zwei Profile 1 1a, 11b definiert werden, ohne dass serverseitig die entsprechenden Sicherheits-Parameter (IMSI, 1CCID, OTA, Ki, etc.) geklont werden müssen. Dieses Kopieren im Schritt 103 und Abspeichem im Schritt 104 in der eUICC 1 wird ermöglicht, da die eUICC 1 als Sicherheitselement als vertrauenswürdig für diese Daten eingestuft wird und somit keine serverseitige Sicherheit garantiert werden muss. Auf diese Weise kann ein initiales, weniger Profildaten umfassendes erstes Profil 1 la durch ein späteres, mehr Profildaten und damit einhergehend mehr Funktionalität aufweisendes zweites Profil 11b ersetzt werden, ohne dass bereits vorhandene Profildaten erneut versendet oder aufgrund der Komplexität des Systems gemäß Fig. 1 aufwendig generiert werden müssen. Es ist also möglich, die mehr Funktionalität zu erwirken, ohne ein komplett neues Profil 11 zu generieren und zu übertragen. Damit ist Zeit und Netzwerklast eingespart.

Im Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/oder beanspruchten Elemente beliebig miteinander kombiniert werden.

BEZUGSZEICHENLISTE

1 Teilnehmeridentitätsmodul, eUICC

1 Oa-b Profll-Dateistruktur, Issuer Security Domain, ISD-P

l la-c Subskriptions-Profile,

1110 Markierter Teil der Profil-Dateistruktur

12 Herausgebersicherheitsbereich-UICC-basiert, Issuer Security Domain, ISD-R

2 Subskriptions-Server

2a Serverkomponente, Subscription Manager Secure Routing, SM-SR

2b Serverkomponente, Subscription Manager Data Preparation, SM-DP 3 Mobilfunknetzbetreiber, Mobile Network Operator, MNO

4 Zertifikatsherausgeber, CI

5 eUICC Hersteller, EUM

6 Endgerät

101-1 10 Verfahrensschritte im Teilnehmeridentitätsmodul, eUICC

201-206 Verfahrensschritte im Subskriptions-Server

ES1 -ES8 Schnittstellen