-
Die Erfindung bezieht sich auf Kommunikationsverfahren zwischen elektronischen Geräten. Sie bezieht sich insbesondere auf die Steuerung einer Kommunikation innerhalb eines Geräts, das bei der Nahfeldkommunikation eingesetzt wird, speziell im 13,56 MHz-Band, sowie auf Geräte mit entsprechend gesteuerter Kommunikation.
-
Es wird erwartet, dass mobile elektronische Geräte in Zukunft verstärkt mit zusätzlichen Hochfrequenz(HF)-Kommunikationsfunktionen ausgestattet sein werden. Dies betrifft z. B. Mobiltelefone, tragbare Medienspieler, Smartphones, persönliche digitale Assistenten (PDAs), Hand-Spielekonsolen, Tablet-Computer, Laptopcomputer etc. Neben ihren herkömmlichen Funktionen werden diese Geräte damit in der Lage sein, zusätzliche Kommunikationsfunktionen ausführen. Zum Spektrum der Anwendungen von HF-Kommunikationsfunktionen gehören vor allem kontaktlose Chipkartenfunktionen, wie z. B. Buchungen, Zahlungen, Käufe, und ähnliches mehr, aber auch die einfache durch den Benutzer initiierte Kommunikation von Endgerät zu Endgerät, etwa für den Foto-, MP3-Song- oder Visitenkartenaustausch. Solche zusätzlichen HF-Kommunikationsfunktionen sind zunehmend unter Verwendung der so genannten Nahfeldkommunikations-Technik implementiert (NFC/Near Field Communication).
-
Die NFC-Technik ist eine drahtlose Kurzbereichs-Konnektivitäts-Technik, die einfache und sichere Zweiwege-Interaktionen zwischen elektronischen Geräten ermöglicht. Das erlaubt es Verbrauchern, kontaktlose Transaktionen auszuführen, auf digitale Inhalte zuzugreifen und elektronische Geräte bzw. Vorrichtungen zu verbinden. Anders ausgedrückt, ermöglicht die NFC-Technik eine kontaktlose, bidirektionale Kommunikation zwischen Geräten. Diese Bauelemente können mit NFC ausgestattete Mobiltelefone, Computer, Consumer-Elektronik, Karten, Etiketten, Zeichen, Plakate, Waschmaschinen und ähnliches sein. Ein mit der NFC-Technik ausgerüstetes Gerät kann grundsätzlich in einem Lese-/Schreib-, Peer-zu-Peer-, oder Kartenemulationsmodus arbeiten.
-
Die NFC-Technik ist als kontaktlose Technik im 13,56 MHz-Frequenzband standardisiert. Der ISO-14443-Standard ist ein Grundbaustein für einen Großteil der Nahfeldoperationen. Die NFC-Technik ist im Allgemeinen kompatibel mit zumindest den Standards ISO 14443 Typ A und Typ B. Die Komponenten einer NFC-Sitzung umfassen Initiatoren und Ziele. Der Initiator ist das Bauelement, das die Kommunikation und den Austausch von Daten beginnt und verwaltet. Das Ziel antwortet auf Anforderungen von dem Initiator. Ein Merkmal der NFC-Technik ist, dass Bauelemente entweder als ein Initiator oder ein Ziel handeln können. Die NFC-Technik erfordert, dass ein dedizierter HF-Chipsatz und eine Antenne in das mobile Bauelement integriert sind.
-
In einer bekannten Konfiguration ist der ISO 14443 Standard in einem mobilen Endgerät auf eine kontaktbasierte, transparente Schnittstelle zwischen, beispielsweise, einem NFC Frontend und einem Secure Element abgebildet, wobei das Secure Element z. B. als SmartCard realisiert sein kann. Wird eine räumliche Nähe zwischen dem Endgerät und einem kontaktlosen externen Terminal hergestellt, zum Beispiel um eine elektronische Bezahlung vorzunehmen, wird per RF-Kommunikation eine Kommunikation zwischen dem Terminal und dem mobilen Endgerät etabliert. Gemäß dem Standard ISO 14443 ist dabei die Kommunikation zwischen dem drahtlosen Terminal und dem Secure Element, auf dem eine Applikation zur Abwicklung der Zahlungstransaktion gehostet ist, in der Regel transparent. Dies bedeutet, dass das NFC Frontend als zwischengeschaltetes Element den Datenstrom zwischen dem Secure Element (SE) und dem externen drahtlosen Terminal in beiden Kommunikationsrichtungen quasi unverändert durchreicht. Dabei wird eine bloße Dekodierung nicht als Bruch der Transparenz betrachtet, solange die transportierte Information nicht verändert wird. Diese Transparenz ist unter anderem deswegen von Vorteil, da sie die Kommunikationsgeschwindigkeit durch fehlende Zwischenschritte im NFC-Frontend, sowie die Sicherheit des Gesamtprozesses erhöht.
-
Es ist zu erwarten, dass kommerziell erhältliche Endgeräte, wie z. B. Mobiltelefone, auf absehbare Zeit zunehmend mit jeweils mehreren Secure Elements, beziehungsweise mindestens der Option zur Verwendung mehrerer Elemente ausgestattet sein werden. Dies ist unter anderem darin begründet, dass es bisher keinen international anerkannten Industriestandard gibt, der ein einheitliches Format eines Secure Elements für die unterschiedlichen Marktteilnehmer im Bereich der Nahfeldkommunikation bereitstellt. Dazu gehören etwa Hersteller von mobilen Endgeräten wie Mobiltelefonen und Tablet Computern etc., Mobilfunkanbieter, Anbieter von Zahlungssystemen, etc. Die einzelnen Teilnehmer haben unterschiedliche Kanäle und Möglichkeiten, um die Hardware ihrer Zahlungssysteme an den Kunden zu bringen. Bei einem Mobiltelefon-Hersteller kann dies etwa der Einbau eines kompletten Nahfeld-Kommunikationssystems inklusive eines NFC-Frontends und einem fest installierten, d. h. zum Beispiel eingelöteten Secure Element sein. Der Mobilfunkprovider kann dagegen in der Regel gar nicht, oder nur sehr begrenzt, auf die Hardware des Endgeräts Einfluss nehmen, und wird daher z. B. ein Secure Element in Form einer bzw. als Kombination mit einer SIM-Karte bereitstellen, die, wie aus der herkömmlichen Mobilfunktechnologie bekannt, vom Endnutzer in sein Mobiltelefon eingelegt wird, z. B. anstelle seiner herkömmlichen bisherigen SIM-Karte ohne Secure Element. Eine weitere Möglichkeit ist zum Beispiel ein Secure Element in Form einer Chipkarte (SmartCard) oder SD-Karte, die in einen Kartenslot des Endgeräts, also etwas des Mobiltelefons, Handheld- oder Tablet-Computers eingelegt wird.
-
Gemäß dem ISO-Standard 14443 ist die Kommunikation zwischen einem Secure Element und einem NFC-Frontend definiert. Eine Möglichkeit, um etwa mehrere Bezahlsysteme in einem mobilen, nahfeld-kommunikationsfähigen Endgerät wie einem Mobiltelefon bereitzustellen, ist die entsprechenden zu den unterschiedlichen Bezahlsystemen gehörenden Applikationen auf demselben Secure Element bereit zu stellen (Multi-Application Secure Element). Dies bietet jedoch insofern nur geringe Flexibilität, als z. B. der Anbieter eines Bezahlsystems sich gegebenenfalls erst mit demjenigen Marktteilnehmer einigen muss, der den Zugang auf das Secure Element des betreffenden Endgeräts kontrolliert, bei einer SIM-Karte etwa einem Mobilfunkanbieter. Je nach Marktstruktur und Wettbewerbsverhältnissen kann sich dies für den Anbieter eines Bezahlsystems als unökonomisch, kompliziert oder letztlich unmöglich herausstellen. Technische Inkompatibilitäten der betreffenden Applikationen mit bestimmten Typen von Secure Elements können eine weitere technische und ökonomische Hürde darstellen.
-
Vor diesem Hintergrund besteht ein Bedarf nach Verfahren und Vorrichtungen, die es erlauben, verschiedene Applikationen zur Nahfeldkommunikation in einem Endgerät zu implementieren, ohne auf den Zugang zu einem bestimmten Secure Element angewiesen zu sein.
-
Vor diesem Hintergrund wird daher ein Verfahren für die Steuerung des Datenflusses gemäß Anspruch 1, ein Nahfeld-Kommunikationssystem gemäß Anspruch 12, ein mobiles Endgerät gemäß Anspruch 13, und ein Secure Element gemäß Anspruch 15 vorgeschlagen. Weitere bevorzugte Aspekte der Erfindung ergeben sich aus den abhängigen Ansprüchen, aus den Figuren und aus der Beschreibung.
-
In einem ersten Ausführungsbeispiel bezieht sich die Erfindung auf ein Verfahren für die Steuerung des Datenflusses in einem Nahfeld-Kommunikationsgerät mit einem zwischengeschalteten Element und mehreren damit transparent verbundenen Secure Elements. Das Verfahren umfasst Empfangen einer von einem externen Gerät gesendeten ersten Kommunikation, die zu einer in einem von mehreren Secure Elements des Nahfeld-Kommunikationsgeräts befindlichen Applikation passt, durch ein erstes Secure Element; Testen durch das erste Secure Element, ob es selbst die betreffende Applikation enthält, und Stummschalten des ersten Secure Elements, falls es die betreffende Applikation nicht enthält.
-
In einem weiteren Ausführungsbeispiel bezieht sich die Erfindung auf ein Nahfeld-Kommunikationssystem mit einem zwischengeschalteten Element und mindestens zwei Secure Elements. Das System ist eingerichtet zum Empfangen einer von einem externen Gerät gesendeten ersten Kommunikation, die zu einer in einem von mehreren Secure Elements des Nahfeld-Kommunikationsgeräts befindlichen Applikation passt; Testen durch mindestens eines der Secure Elements, ob es selbst die betreffende Applikation enthält; und zum Stummschalten mindestens eines Secure Elements, das die betreffende Applikation nicht enthält.
-
Im Weiteren soll die Erfindung anhand von in Figuren dargestellten Ausführungsbeispielen erläutert werden, aus denen sich weitere Vorteile und Abwandlungen ergeben.
-
1 zeigt eine schematische Darstellung eines in einem Endgerät eingebauten Nahfeld-Kommunikationsgeräts gemäß Ausführungsbeispielen der Erfindung;
-
2 zeigt schematisch ein Verfahren gemäß Ausführungsbeispielen der Erfindung;
-
3 zeigt schematisch ein Verfahren gemäß Ausführungsbeispielen der Erfindung;
-
4 zeigt schematisch ein Zeitschema gemäß Ausführungsbeispielen;
-
5 zeigt ein Endgerät gemäß Ausführungsbeispielen.
-
Im Folgenden werden verschiedene Ausführungsformen der Erfindung beschrieben, von denen einige auch in den Figuren beispielhaft dargestellt sind. Bei der folgenden Beschreibung der Figuren beziehen sich gleiche Bezugszeichen auf gleiche oder ähnliche Komponenten. Im Allgemeinen werden nur Unterschiede zwischen verschiedenen Ausführungsformen beschrieben. Hierbei können Merkmale, die als Teil einer Ausführungsform beschrieben werden, auch ohne weiteres im Zusammenhang mit anderen Ausführungsformen kombiniert werden, um noch weitere Ausführungsformen zu erzeugen.
-
Ausführungsbeispiele beziehen sich auf ein Verfahren für die Steuerung der Kommunikation in einem NFC-Endgerät, das ein NFC-Frontend und mindestens zwei Secure Elements umfasst. Dabei wird sichergestellt, dass eine von einem externen Gerät, etwa einem kontaktlosen Terminal, eingehende Kommunikation möglichst ohne oder mit geringem Zeitversatz von genau demjenigen Secure Element aus der Mehrzahl der vorhandenen beantwortet wird, das die zur eingehenden Kommunikation passende bzw. gehörende Applikation aufweist. Es kann also eine Applikation in einem von mehreren Secure Elements adressiert werden, unabhängig davon, ob ein oder mehrere Secure Elements angeschlossen sind.
-
Diese Auswahl bzw. Sicherstellung der zielgenauen Kommunikation kann gemäß Ausführungsbeispielen auf verschiedene Arten durchgeführt werden. Dabei kann typischerweise die standardgemäße Transparenz der Kommunikation zwischen dem externen Gerät (also etwa einem kontaktlosen NFC-Terminal) durch das NFC-Frontend mit einem Secure Element zumindest für kurze Zeit unterbrochen werden, während der entschieden bzw. geschaltet wird, welches Secure Element die zur eingehenden Kommunikation passende Applikation beinhaltet und welches somit als tatsächlicher Endpunkt der Kommunikation in dem Nahfeld-Kommunikationsgerät festzulegen ist. Gleichzeitig kann mit den in Ausführungsbeispielen beschriebenen Verfahren und Geräten in der Regel sichergestellt werden, dass dabei der Bruch der Transparenz von dem externen Gerät nicht feststellbar ist, der Kommunikationsverlauf nach außen also so erscheint, als wäre er vollständig und durchgehend transparent.
-
Der hierin verwendete Begriff der „Transparenz” bzw. der „transparenten Verbindung” ist wie folgt definiert. Gemäß Ausführungsbeispielen stellt ein zwischengeschaltetes Element, das in einer Realisierung etwa ein NFC-Frontend ist, eine Brücke zwischen einem externen NFC-Terminal und den im erfindungsgemäßen NFC-Gerät eingebauten Secure Elements oder auch einer Host-Komponente dar. Transparenz ist so zu verstehen, dass das NFC-Frontend lediglich die Wandlung der RF-Informationen (also etwa im 13,56 MHz-Band) in digitale Informationen vornimmt. Dabei wird der in der RF-Kommunikation kodierte (z. B. gemäß ISO 14443 Standard) Datenstrom bzw. die einkodierte Bitfolge von dem NFC-Frontend lediglich aus dem RF-Signal gewandelt, also durch Analog-Digital-Wandlung. Die resultierende Bitfolge wird dann ohne weitere Veränderung an das transparent angebundene Secure Element weitergeleitet. Dies ist unter „Transparenz” bzw. „transparenter Verbindung von zwischengeschaltetem Element und Secure Element” im Sinne dieser Schrift zu verstehen.
-
Ein Beispiel für einen Bruch der Transparenz wäre z. B., wenn der dekodierte Bitstrom in dem zwischengeschalteten Element für eine definierte, signifikante Zeitspanne zwischengespeichert bzw. gepuffert wird, also im Wesentlichen nicht in Echtzeit weitergeleitet wird. Dabei soll eine der Bedingungen, ob die Verbindung zwischen dem zwischengeschalteten Element und einem Secure Element als transparent anzusehen ist oder nicht, hierin wie folgt definiert sein: Wenn die Zeitspanne der Verzögerung zwischen dem Empfang eines ersten, in RF modulierten Bits durch das zwischengeschaltete Element und dem Weitersenden desselben Bits größer ist als die Zeitspanne, die rechnerisch gemäß der Eingangs-Bitrate für die Übertragung eines Bytes benötigt wird, ist die Verbindung definitionsgemäß nicht mehr als transparent anzusehen. Anders ausgedrückt, soll bei Transparenz die „Verweildauer” eines Bits in dem zwischengeschalteten Element kleiner oder maximal gleich sein als eine gemäß der Eingangs-Datenrate zur Übertragung eines Bytes äquivalente Zeitspanne. Auch signifikante Änderungen der Bitfolge, etwa durch Änderung des Kodierungsverfahrens durch De- und anschließende Rekodierung gelten in diesem Sinn als Bruch der Transparenz. Kleine, systematische zeitliche Verzögerungen, etwa durch ein zwischengeschaltetes Schieberegister im Digitalpfad, sind dagegen nicht als Bruch der Transparenz zu sehen. Grundsätzlich sprechen für einen Bruch der Transparenz alle Bitorientierten Operationen auf den dekodierten Datenstrom, die über das obige hinausgehen.
-
Das oben beschriebene Konzept, nach außen hin transparent die eingehende Kommunikation mit dem passenden Secure Element zu verknüpfen, wobei intern die Transparenz der Kommunikation gebrochen werden kann, wird gemäß vorgeschlagener Ausführungsbeispiele in mehreren Varianten gelöst.
-
Gemäß Ausführungsbeispielen wird verfahrensgemäß mindestens ein Secure Elements kontrolliert stummgeschaltet. Dabei kann die Kommunikation von einem ersten an ein anderes Secure Element übergeben (handover) werden, und zwar in dem Fall, wenn die Applikation auf einem anderen Secure Element beheimatet ist als dem ersten, das die Schritte der protocol activation ausführt. Dabei schaltet sich ein Secure Element, das transparent mit dem externen Terminal kommuniziert, in dem Fall stumm bzw. bleibt stumm, sobald eine Anforderung (Request) eingeht, die zu einer Applikation gehört, die nicht auf diesem Secure Element gehostet ist. Im Fall einer kontaktgebundenen Schnittstelle zwischen einem NFC-Frontend und einem Secure Element, die das kontaktlose Protokoll gemäß ISO 14443-2/3/4 implementiert, kann dies folgendes beinhalten. Initial ist die Kommunikation zwischen dem externen Terminal und dem Secure Element standardgemäß transparent, was bedeutet, dass alle von der RF-Schnittstelle des NFC-Frontends kommenden Daten direkt zu dem Secure Element geleitet werden und umgekehrt, und von dort im ausgehenden Fall wieder an das externe Terminal gesendet werden. Nach Empfang des „Select Application Identifier” (im Folgenden auch „Select AID”) Befehls stellt das Secure Element fest, ob es die angeforderte Applikation beinhaltet/hostet oder nicht. Wenn es feststellt, dass es die angeforderte Applikation nicht selbst beinhaltet, sondern ein anderes Secure Element oder auch ein zusätzlich an das NFC-Frontend angeschlossener Application Host, bleibt es stumm, um nicht die Kommunikation des anderen Secure Elements oder des Application Hosts zu beeinflussen oder zu stören. Die oben genannten Varianten können auch mit weiter unten beschriebenen Verfahren zum Power Management kombiniert werden. Dabei steuert typischerweise ein NFC-Frontend den Betriebszustand der angeschlossenen Secure Elements, so dass z. B. in einer Art Zeitschlitz-Verfahren nur die Secure Elements eingeschaltet sind, mit denen eine Kommunikation stattfindet oder bevorsteht.
-
1 zeigt eine Vorrichtung gemäß Ausführungsbeispielen. Ein NFC-fähiges Endgerät 100 umfasst ein NFC-Gerät (Nahfeld-Kommunikationsgerät) 25, das ein zwischengeschaltetes Element 10 (typischerweise ein NFC-Frontend, auch: Contactless Frontend, CLF, oder NFC-Modem) aufweist. Dieses fungiert als Bridge bzw. Hub in der Kommunikation zwischen einem externen NFC-Terminal/Lesegerät 5 und mehreren Secure Elements 40, 42, von denen mindestens eines eine Applikation aufweist bzw. hostet. Jedes der Secure Elements weist eine Kodier-/Dekodiereinheit 41, 43 auf und ist über drahtgebundene Schnittstellen 50, 52 mit dem NEC-Frontend verbunden.
-
Gemäß Ausführungsbeispielen ist das NFC-Frontend 10 mit seiner analogen RF-Schnittstelle 15 und einer Encoder/Decoder-Einheit 20 zusammen mit den Secure Elements 40, 42 und einer Host-Komponente 30 Bestandteil eines NFC-fähigen Endgeräts 100 (nur schematisch in 1 dargestellt, siehe dazu auch 5. Die Secure Elements 40, 42 umfassen typischerweise jeweils eine Encoder/Decoder-Einheit 41, 43. Das Endgerät 100 kann einer Vielzahl mobiler oder stationärer Endgeräte entsprechen, wie eingangs aufgezählt. Dazu gehören z. B. Mobiltelefone, tragbare Medienspieler, Smartphones, persönliche digitale Assistenten (PDAs), Hand-Spielekonsolen, Tablet-Computer, Laptopcomputer, Consumer-Elektronik, Karten, Etiketten, Zeichen, Plakate, oder Haushaltsgeräte. Die Host-Komponente 30 steht dabei stellvertretend und vereinfacht für die gesamte Elektronik-Hard- und Software, die neben dem NFC-bezogenen Teil in den Endgeräten 100 enthalten ist. Gezeigt ist in 1 auch ein externes Terminal 5 bzw. kontaktloses Lesegerät, dass mit dem Nahfeld-Kommunikationsgerät gemäß Ausführungsformen in Kontakt treten kann.
-
Gemäß Ausführungsbeispielen kann ein Secure Element gezielt deaktiviert bzw. stummgeschaltet werden. Dies ist als Verfahren 200 schematisch in 2 gezeigt. Nach Empfang einer Anforderung „Select AID” verifiziert das transparent an das zwischengeschaltete Element angeschlossene Secure Element, ob es die adressierte Applikation beinhaltet, Block 220. Wenn ja, fährt das Secure Element mit der Ausführung der Applikation fort und muss die Antwort innerhalb einer definierten Zeitspanne tACK senden und eine Kommunikation mit dem externen Gerät aufbauen, Block 240. Wenn die Verifizierung ein negatives Ergebnis zeigt, bleibt das Secure Element stumm, um zu vermeiden, dass eine negative Antwort („not acknowledge”) an das externe Terminal gesendet wird, Block 260. In der Zwischenzeit kann das NFC-Frontend die Anforderung an andere Secure Elements weiterleiten, Block 280. Wenn nach der definierten Zeitspanne tACK weder von dem ersten Secure Element noch von einem weiteren Secure Element eine Antwort beim NFC-Frontend registriert wird, antwortet das Frontend an das externe Terminal mit „not acknowledge”, Block 290. Ansonsten beginnt das Secure Element, das die Ziel-Applikation enthält, eine Kommunikation mit dem externen Gerät 5, Block 300.
-
3 zeigt ein Verfahren 300 für die Steuerung des Datenflusses in einem Nahfeld-Kommunikationsgerät 25 mit einem zwischengeschalteten Element 10 und mehreren damit verbundenen Secure Elements 40, 42 gemäß Ausführungsbeispielen. Das Verfahren 300 umfasst das Empfangen einer von einem externen Gerät gesendeten ersten Kommunikation, die zu einer in einem von mehreren Secure Elements des Nahfeld-Kommunikationsgeräts befindlichen Applikation passt, durch ein erstes Secure Element, in einem Block 310. Ferner das Testen durch das erste Secure Element, ob es selbst die betreffende Applikation enthält, in einem Block 320; und das Stummschalten des ersten Secure Elements, falls es die betreffende Applikation nicht enthält, in einem Block 330.
-
4 zeigt schematisch ein Timing-Beispiel eines Verfahrens gemäß Ausführungsbeispielen. Ein von extern eingehender RF Request, eine Anforderung von einem externen Gerät, wird durch das zwischengeschaltete Element in dekodierter Form an die Secure Elements 1 und 2 weitergeleitet (Request). Das Secure Element 2, das die adressierte Applikation enthält, antwortet dem externen Gerät (Response) auf den Request, während sich Secure Element 1 stummschaltet (Mute), weil es die in der externen Anforderung (Request) adressierte Applikation nicht enthält.
-
Gemäß Ausführungsbeispielen behandelt ein transparent verbundenes Secure Element 40, 42 die Aktivierung auf Ebene des RF-Protokolls und besitzt zudem Routing- bzw. Weiterleitungsinformationen. Dazu ist es erforderlich, dass das Secure Element 40, 42 (siehe 1) Informationen über die Layer-3-Ebene von allen im NFC-Kommunikationsgerät 25 vorhandenen Secure Elements sammelt, bevor die Kommunikation mit dem externen Gerät/Terminal 5 beginnt. Das NFC-Frontend 10 überwacht/beobachtet dabei sämtliche von extern ankommenden Daten parallel. Im Fall eines von extern hereinkommenden Applikations-Auswahlbefehls „Select AID” (Select Application ID) muss dieser durch das NFC-Frontend 10 und das transparente Secure Element 40, 42 erkannt werden. Das Frontend schickt die Anforderung nun zu allen gepufferten Schnittstellen, zum Beispiel zu Secure Elements, die über das Single Wire Protocol (SWP) und/oder andere Schnittstellentypen angebunden sind. Im Fall, dass das transparente Secure Element 40, 42 der Host der adressierten Applikation ist, antwortet es dementsprechend innerhalb einer definierten Zeitspanne, die definitiv unterhalb der Frame Delay Time auf RF-Ebene liegt. Die Frame Delay Time ist dabei definiert als die mit dem externen Lesegerät/Terminal 5 (auch: RWD oder Read Write Device) ausverhandelte maximal erlaubte Zeit für das Senden einer Rückantwort. Im Fall jedoch, dass das transparente Secure Element feststellt, dass die adressierte Applikation auf keinem der angeschlossenen bzw. vorhandenen Secure Elements gehostet ist, antwortet es mit einem „not acknowledge”, ebenfalls in einer Zeitspanne kürzer als der Frame Delay Time auf RF-Ebene. Wenn das transparente Secure Element feststellt, dass die Applikation auf einem anderen Secure Element gehostet ist, bleibt es stumm. Das NFC-Frontend 10 wartet die Antwort auf der gepufferten Schnittstelle (z. B. SWP) und leitet eine positive Antwort auf die „Select AID” Anforderung an die RF-Schnittstelle 15 und somit an das externe Terminal 5. Diese kann in Bezug auf die Antwort des Secure Elements verzögert sein, muss aber nach wie vor unterhalb der definierten Frame Delay Time auf RF-Ebene liegen. Die Schnittstelle 50, 52 zwischen NFC-Frontend 10 und Secure Element 40, 42 muss dabei nicht deaktiviert werden, oder kann später deaktiviert werden.
-
Gemäß Ausführungsbeispielen mit gezielter Deaktivierung behandelt ein transparentes Secure Element die Aktivierung auf Ebene des RF-Protokolls, während jedoch abweichend vom obigen Fall das NFC-Frontend 10 (und nur im optionalen Fall das Secure Element) Routing- bzw. Weiterleitungsinformationen besitzt. Dazu ist es erforderlich, dass das Secure Element 40, 42 alle Informationen über die Layer-3-Ebene von allen vorhandenen Secure Elements sammelt, bevor die Kommunikation mit dem externen Gerät/Terminal 5 beginnt. Das NFC-Frontend 10 überwacht/beobachtet dabei sämtliche von extern ankommenden Daten parallel. Im Fall eines von extern hereinkommenden „Select AID” Befehls muss dieser durch das NFC-Frontend 10 und das transparente Secure Element 40, 42 erkannt werden. Das Frontend schickt die Anforderung nun zu allen gepufferten Schnittstellen. Im Fall, dass das transparente Secure Element 40, 42 der Host der adressierten Applikation ist, antwortet es dementsprechend innerhalb einer definierten Zeitspanne, die definitiv unterhalb der Frame Delay Time auf RF-Ebene liegt. Im Fall jedoch, dass das transparente Secure Element feststellt, dass die adressierte Applikation auf keinem der Secure Elements gehostet ist, antwortet es mit einem „not acknowledge”, ebenfalls in einer Zeitspanne kürzer als der Frame Delay Time auf RF-Ebene. Unterschiedlich zum weiter oben beschriebenen Fall ist zudem, dass das transparente Secure Element 40, 42, wenn es feststellt, dass es die Applikation nicht selbst beinhaltet, stumm bleibt. Die Schnittstelle 50, 52 zwischen NFC-Frontend 10 und Secure Element 40, 42 muss nicht deaktiviert werden, oder kann später deaktiviert werden.
-
Gemäß Ausführungsbeispielen kann die Ebene der Applikationsschicht, also etwa der ISO 14443 Layer 3, dabei von dem zwischengeschalteten Element, etwa einem NFC-Frontend 10 gehandhabt werden. Die zwei (in diesem nicht-limitierenden Beispiel) Secure Elements 40, 42 sind dabei immer auf den Modus der Applikationsschicht (Applikation layer) gesetzt. Dies kann entweder durch Aussendung von Layer-3-Befehlen durch das NFC-Frontend vor Beginn der RF-Kommunikation mit dem externen Terminal 5 geschehen, oder durch grundsätzliche Konfiguration der Secure Elements 40, 42 in einer Weise, dass diese automatisch auf Ebene der Anwendungsschicht starten. Vor dem „Select AID” Befehl wird von dem NFC-Frontend die Schnittstelle 50, 52 zu einem Secure Element 40, 42 aktiviert. Das NFC-Frontend 10 verifiziert dann, ob dieses Secure Element 40, 42 die adressierte Applikation hostet. Falls ja, fährt dieses Secure Element mit der Ausführung der betreffenden Applikation fort. Wenn es die Applikation nicht beinhaltet, deaktiviert das NFC-Frontend die Schnittstelle 50, 52 zu diesem Secure Element 40, 42, und die Kommunikation wird zu einem weiteren Secure Element weitergereicht. Schließlich wird die Kommunikation über die Schnittstellen 50, 52 wieder auf den transparenten Modus geschaltet.
-
In Ausführungsbeispielen können die obigen Verfahren und Geräte auch mit Methoden zum Power Management kombiniert sein. Das bedeutet, dass eine zentrale Einheit, in diesem Fall typischerweise das NFC-Frontend, an das andere Geräte angeschlossen sind, durch gezieltes Ein- und Ausschalten zur Kommunikation steuern kann, ob mit diesen Geräten zu einem bestimmten Zeitpunkt überhaupt eine Kommunikation möglich ist. Dies bietet folglich eine elegante Lösung, durch ein NFC-Frontend gleichzeitig die Kommunikation zu steuern und den Energieverbrauch zu senken. Durch Einschalten in einem Zeitschlitz-Verfahren kann man so sicherstellen, dass immer nur das oder die Secure Elements eingeschaltet sind und Strom verbrauchen, die gerade benötigt werden.
-
Da der induzierte Strom begrenzt ist, sollte angestrebt werden, dass nur die absolut notwendige Zahl an Elementen aktiv ist. Abhängig von Timeout-Zeiten, die für unterschiedliche Befehle unterschiedlich sein können, kann das korrespondierende Secure Element dazu gebracht werden, seinen Energeiverbrauch zu ändern. Das NFC-Frontend 10 muss dabei die Timeout-Zeit berücksichtigen, bevor ein weiteres Secure Element aktiviert wird. Es kann auch die Stromversorgung für bestimmte Secure Elements nach bestimmten Timeouts abstellen, im Fall dass dieses Secure Element nicht mehr benötigt wird. Für das Power Management sind entsprechende Hard- und/oder Softwaremittel typischerweise in dem zwischengeschalteten Element 10 implementiert.
-
5 zeigt ein mobiles Endgerät 100, hier ein Smartphone, mit einem Nahbereichskommunikationsgerät bzw. -system 25 nach ISO 14443 gemäß Ausführungsbeispielen. Das mobile Endgerät kann in Ausführungsformen unter anderem ein tragbarer Medienspieler, ein Smartphone, ein persönlicher digitaler Assistent (PDA), eine Hand-Spielekonsole, ein Tablet-Computer, eine Smartcard, oder ein Personal Computer, insbesondere ein Laptop, sein.
-
Es ist dem Fachmann ohne weiteres verständlich, dass das hier beschriebene Verfahren gemäß Ausführungsformen nicht nur in den detailliert beschriebenen Varianten ausgeführt werden kann, sondern prinzipiell für eine Vielzahl von Anwendungsfällen angewendet werden kann. Insbesondere eignet es sich für gemäß einem Standard implementierte elektronische Geräte, bei denen die standardgemäße Datenkommunikation zwischen Geräten oder Bauelementen beschleunigt werden soll.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- ISO-14443-Standard [0004]
- ISO 14443 Typ A und Typ B [0004]
- ISO 14443 Standard [0005]
- Standard ISO 14443 [0005]
- ISO-Standard 14443 [0007]
- ISO 14443 Standard [0021]
- ISO 14443-2/3/4 [0024]
- ISO 14443 Layer [0032]
- ISO 14443 [0035]
