DE112014000702T5 - Vorrichtungen und Verfahren für sichere Elementtransaktionen und die Verwaltung von Assets - Google Patents

Vorrichtungen und Verfahren für sichere Elementtransaktionen und die Verwaltung von Assets Download PDF

Info

Publication number
DE112014000702T5
DE112014000702T5 DE112014000702.1T DE112014000702T DE112014000702T5 DE 112014000702 T5 DE112014000702 T5 DE 112014000702T5 DE 112014000702 T DE112014000702 T DE 112014000702T DE 112014000702 T5 DE112014000702 T5 DE 112014000702T5
Authority
DE
Germany
Prior art keywords
asset
client device
request
identifier
vme
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE112014000702.1T
Other languages
English (en)
Inventor
David T. Haggerty
Ahmer A. Khan
Christopher Sharp
Joakim Linde
Kevin P. McLaughlin
Mehdi ZIAT
Yousuf H. Vaid
Jerrold Von Hauck
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Inc filed Critical Apple Inc
Publication of DE112014000702T5 publication Critical patent/DE112014000702T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123—Shopping for digital content
    • G06Q20/1235—Shopping for digital content with control of digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Verfahren und Vorrichtungen für die Umsetzung finanzieller Instrumente und sonstiger Assets sind offenbart. In einer Ausführungsform ist ein Sicherheits-Softwareprotokoll offenbart, dass garantiert, dass das Asset immer sicher verschlüsselt ist, dass eine und nur eine Kopie des Assets existiert und das Asset an einen authentifizierten und/oder berechtigten Kunden geliefert wird. Zusätzlich werden beispielhafte Ausführungsformen von Bereitstellungssystemen offenbart, die unter anderem hohe Datenverkehrsaufkommen verwalten können (dies kann z. B. an einem sogenannten „Einführungstag” eines Geräts geschehen).

Description

  • Gebiet
  • Die vorliegende Offenbarung bezieht sich allgemein auf das Gebiet der sicheren Gerätetransaktionen und insbesondere in einer beispielhaften Ausführungsform auf den Einsatz finanzieller Instrumente und sonstiger Assets.
  • Allgemeiner Stand der Technik
  • Kunden und Händler wünschen im Allgemeinen komfortable und sichere Mittel zur Durchführung finanzieller und sonstiger damit verbundener Transaktionen. Assets wie zum Beispiel Kreditkarten, Debitkarten, Prepaid-Karten, Geschenkkarten, Gutscheine, usw. sind alle Beispiele der zunehmend „virtualisierten” Art von Zahlungsmitteln. Anstatt die physische Währung oder physische Gutscheine für Güter und/oder Dienstleistungen tatsächlich umzutauschen, wird die Transaktion insbesondere z. B. mit einer Kontonummer oder „Proxy-”Kontonummer durchgeführt (z. B. eine für die Abwicklung des Geschäfts am Verkaufsort erstellte, die jedoch keine tatsächliche Kredit- oder Schuldkontonummer ist), und die Gelder werden elektronisch gutgeschrieben/abgebucht.
  • Leider sind die bestehenden Lösungen zur Verteilung dieser Assets aus hier nachstehend genauer beschriebenen Gründen unpraktisch und fehleranfällig. Ein virtuelles Musterbeispiel einer Geldbörse kann zum Beispiel auf zuvor bestehenden Konten beruhen; und um eine monetäre Transaktion durchzuführen, muss ein Benutzer eines Client-Geräts ein zuvor bestehendes Konto mit einem Wallet-Service besitzen (z. B. eine vertrauenswürdige Instanz, die eine Buchhaltungsdatenbank in Verbindung mit der Geldbörse anbietet) oder bereits über einen vorausbezahlten Wallet-Service verfügen. Zudem sind vorhandene Assets nicht „übertragbar” und sind bei ihrer Anlegung einem bestimmten Zweck vorbehalten.
  • Da Kunden und Händler sich in Bezug auf die transaktionale Komplexität und/oder Komfort ständig weiterentwickelt haben (einschließlich der zunehmend durchdringenden Nutzung von Mobilgeräten) werden neue und verbesserte Modelle zur Verteilung von Assets benötigt. Idealerweise sollten diese Lösungen angemessene und praktische Verwaltungsmöglichkeiten für Kunden, Händler und emittierende Unternehmen bieten, ohne die Flexibilität von Assets zu beeinträchtigen.
  • Zusammenfassung
  • Die vorliegende Veröffentlichung bezieht sich auf die vorgehenden Bedürfnisse, indem sie unter anderem Vorrichtungen und Verfahren für sichere Elementtransaktionen und die Verwaltung von Assets bietet.
  • In einer Ausführungsform wird ein Verfahren zur Verteilung eines Assets an ein Client-Gerät offengelegt. Das Verfahren kann durch Erhalten einer Anfrage zur Übertragung des Assets von dem Client-Gerät auf ein Konto durchgeführt werden. Die Anfrage zur Übertragung des Assets kann von einem Geräte-Identifikator begleitet sein, der das Client-Gerät eindeutig erkennt. Als nächstes wird die Anfrage zur Übertragung des Assets authentifiziert. In einem Fall wird die Anfrage zur Übertragung des Assets mithilfe des Geräte-Identifikators durch Überprüfen authentifiziert, ob das Client-Gerät mit dem Konto verbunden ist. Nach dem Authentifizieren der Anfrage wird das Asset auf das Konto übertragen und das Asset wird dem Client-Gerät zugeordnet. Dann wird ein das zugeordnete Asset eindeutig identifizierender Asset-Identifikator von einem Remote-Gerät, wie zum Beispiel ein Asset-Schließfach, empfangen. Der Asset-Identifikator wird dann an das Client-Gerät gesendet. Anschließend kann das Client-Gerät das zugeordnete Asset mithilfe des Asset-Identifikators anfordern. Nach Erhalten einer Anfrage für das zugeordnete Asset und des Asset-Identifikators vom Client-Gerät wird das zugeordnete Asset dem Client-Gerät zugeführt.
  • In einer Ausführungsform wird ein Verfahren zur Verteilung eines Assets an ein Client-Gerät offengelegt. Das Client-Gerät ist mit einem Geräte-Identifikator verbunden, der das Client-Gerät eindeutig identifiziert. Das Verfahren wird durch vorkonfigurieren des Asset für das Client-Gerät durchgeführt. Der vorkonfigurierende Prozess kann beinhalten (i) Verschlüsseln des Assets mit einem einmaligen Schlüssel auf Grundlage des Geräte-Identifikators, (ii) Einbetten von Testdaten in das Asset und/oder (iii) Verbinden des Assets mit einem Benutzerkonto. Entsprechend wird das Asset für das Client-Gerät konfiguriert oder „individualisiert”. Als nächstes wird das vorkonfigurierte Asset mit einem Asset-Identifikator verbunden. In einem Aspekt der Ausführungsform wird der Asset-Identifikator vor dem Vorkonfigurieren des Assets auf das Client-Gerät übertragen. Das Client-Gerät kann dann das vorkonfigurierte Asset anfordern. Die Anfrage kann den Asset-Identifikator beinhalten. Nach Erhalten der Anfrage kann das vorkonfigurierte Asset dem Client-Gerät zugeführt werden.
  • In wiederum einer anderen Ausführungsform wird ein computerlesbares Speichermedium offengelegt. Das computerlesbare Speichermedium speichert Anweisungen, die bei Ausführung durch einen Prozessor eines Client-Geräts das Client-Gerät zum Senden einer Anfrage zur Übertragung eines Assets auf ein Konto veranlassen. Die Anfrage kann an ein Remote-Gerät gesendet werden. Das Konto kann mit einem Benutzer des Client-Geräts verbunden werden. Gemeinsam mit der Anfrage kann das Client-Gerät einen Geräte-Identifikator senden, der das Client-Gerät eindeutig identifiziert. In einem Aspekt der Ausführungsform wird der Geräte-Identifikator auf einem sicheren Element gespeichert, das im Client-Gerät angeordnet ist. Weiterhin können eine oder mehrere Anforderungen ebenso auf dem sicheren Element gespeichert werden. Ferner veranlassen die Anweisungen das Client-Gerät dazu, eine Anforderung an das Remote-Gerät zu übermitteln. Das Client-Gerät kann dann das Asset von dem Remote-Gerät empfangen. Das erhaltene Asset kann Testdaten beinhalten, die das sichere Element verwenden kann, um zu prüfen, ob das empfangene Asset gültig ist. Die Testdaten können auf der übermittelten Anforderung beruhen.
  • Diese Zusammenfassung wird lediglich zu Zwecken des Zusammenfassens mancher Beispielausführungsformen bereitgestellt, um ein grundlegendes Verständnis mancher Aspekte des hierin beschriebenen Gegenstandes bereitzustellen. Dementsprechend wird ersichtlich sein, dass die vorstehend beschriebenen Merkmale lediglich Beispiele darstellen und nicht als den Umfang oder Geist des hierin beschriebenen Gegenstands in irgendeiner Weise einengend aufzufassen sind. Weitere Merkmale, Aspekte und Vorteile des hierin beschriebenen Gegenstands werden anhand der folgenden detaillierten Beschreibung, Figuren und Ansprüche ersichtlich.
  • Weitere Aspekte und Vorteile der Erfindung werden anhand der folgenden detaillierten Beschreibung in Verbindung mit den begleitenden Zeichnungen ersichtlich, die in beispielhafter Weise die Prinzipien der beschriebenen Ausführungsformen veranschaulichen.
  • Kurze Beschreibung der Zeichnungen
  • Die beschriebenen Ausführungsformen sind besser unter Verweis auf die folgende Beschreibung und die beigefügten Zeichnungen zu verstehen. Zudem sind die Vorteile der beschriebenen Ausführungsformen sind besser unter Verweis auf die folgende Beschreibung und die beigefügten Zeichnungen zu verstehen.
  • 1 ist eine graphische Darstellung einer beispielhaften Konfiguration eines Transaktionsnetzes gemäß der vorliegenden Offenbarung.
  • 2 ist eine graphische Darstellung einer beispielhaften Konfiguration eines Bereitstellungssystems gemäß der vorliegenden Offenbarung.
  • 3A ist eine graphische Darstellung einer beispielhaften Ausführungsform eines Client-Geräts gemäß der vorlegenden Offenbarung.
  • 3B ist ein logisches Blockdiagramm einer beispielhaften Ausführungsform eines Händler-Geräts gemäß der vorliegenden Offenbarung.
  • 4 ist ein logisches Blockdiagramm einer beispielhaften Ausführungsform eines Asset-Agents gemäß der vorliegenden Offenbarung.
  • 5 ist ein logisches Blockdiagramm einer beispielhaften Ausführungsform eines Kontenservers eines Asset-Brokers gemäß der vorliegenden Offenbarung.
  • 6 ist ein logisches Blockdiagramm einer beispielhaften Ausführungsform eines Asset-Schließfachs gemäß der vorliegenden Offenbarung.
  • 7 ist ein logisches Ablaufdiagramm einer Ausführungsform eines verallgemeinerten Verfahrens zur Verteilung von Assets gemäß der vorliegenden Offenbarung.
  • 8 ist ein logischer Kontaktplan, der eine beispielhafte Übertragungstransaktion gemäß der vorliegenden Offenbarung darstellt.
  • 9A und 9B zeigen ein logisches Ablaufdiagramm eines verallgemeinerten Verfahrens zur Verteilung von Assets gemäß der vorliegenden Offenbarung.
  • 10A und 10B zeigen ein logisches Ablaufdiagramm eines verallgemeinerten Verfahrens zur Verteilung von Assets gemäß der vorliegenden Offenbarung.
  • 11 ist ein logisches Ablaufdiagramm einer weiteren Ausführungsform eines verallgemeinerten Verfahrens zur Verteilung von Assets gemäß der vorliegenden Offenbarung.
  • 12 ist ein logisches Ablaufdiagramm einer weiteren Ausführungsform eines verallgemeinerten Verfahrens zur Verteilung von Assets gemäß der vorliegenden Offenbarung.
  • 13A, 13B und 13C zeigen ein logisches Ablaufdiagramm einer weiteren Ausführungsform eines verallgemeinerten Verfahrens zur Verteilung von Assets gemäß der vorliegenden Offenbarung.
  • Ausführliche Beschreibung
  • Repräsentative Anwendungen von Verfahren und Vorrichtungen nach der vorliegenden Anmeldung werden in diesem Abschnitt beschrieben. Diese Beispiele werden lediglich zur Verfügung gestellt, um zum Verständnis der beschriebenen Ausführungsformen Kontext und Hilfestellungen hinzuzufügen. Es ist daher für den Fachmann ersichtlich, dass die beschriebenen Ausführungsformen ohne manche oder alle dieser spezifischen Details ausgeführt werden können. In anderen Fällen wurden allgemein bekannte Prozessschritte nicht detailliert beschrieben, um ein unnötigen Verschleiern der beschriebenen Ausführungsformen zu vermeiden. Andere Anwendungen sind möglich, sodass die folgenden Beispiele nicht als einschränkend verstanden werden sollten.
  • In der nachfolgenden detaillierten Beschreibung erfolgen Bezugnahmen auf dir begleitenden Zeichnungen, die einen Teil der Beschreibung bilden und in denen spezifische Ausführungsformen gemäß den beschriebenen Ausführungsformen veranschaulicht werden. Auch wenn diese Ausführungsformen ausreichend detailliert beschrieben werden, um es dem Fachmann zu ermöglichen, die beschriebenen Ausführungsformen auszuführen, versteht es sich, dass diese Beispiele nicht einschränkend sind, sodass andere Ausführungsformen verwendet werden können und Veränderungen vorgenommen werden können, ohne vom Geist und Umfang der beschriebenen Ausführungsformen abzuweichen.
  • Virtualisierte „Wallets” können Kunden, Händlern und Finanzinstitutionen bedeutende Vorteile bieten. Die virtuellen „Inhalte” der virtualisierten Wallets können ein oder mehrere Assets enthalten. Eine Instanz (z. B. Benutzer, Händler, Finanzinstitution, usw.) kann diese Assets frei zwischen angemessen freigegebenen und sicheren Geräten übertragen; zudem können diese Assets flexibel gespeichert, gesichert, usw. werden. Bestehende Lösungen bieten über Internetprotokoll-(IP)Netzwerke gewisse rudimentäre Transaktionen, z. B. Austeilung, Aktualisieren, Korrigieren, usw. Allerdings sind aufgrund der Sensibilität finanzieller Transaktionen und Informationen umfangreiche Sicherheitsmaßnahmen erforderlich, um Diebstahl, Missbrauch, arglistiges Verhalten, usw. zu verhindern.
  • Dabei ist zu beachten, dass Ausführungsformen in der gesamten Offenbarung im Kontext dieser Erläuterung Assets beschreiben, die die Form von virtualisierten Zahlungsmitteln (Virtualized Mediums of Exchange, VMEs) annehmen. Geläufige Beispiele von virtualisierten Zahlungsmitteln beinhalten, ohne sich darauf zu beschränken: Kredit-„karten”-Nummern, Debit-„karten”-Nummern, Prepaid-„karten”-Nummern, Konteninformationen und virtualisierte Zahlungsmittel, usw. Allgemeiner betrachtet umfassen virtualisierte Zahlungsmittel auch Instrumente ohne tatsächlichen Wert, z. B. elektronische Gutscheine, elektronische Belege, elektronische Tickets, elektronische Ausweise usw. Dabei ist zu berücksichtigen, dass diese Beschreibung nicht beschränkend ist und dass die beschriebenen Ausführungsformen verwendet werden können, um irgendetwas nützliches und/oder wertvolles zu verteilen. Weiterhin können VMEs in einer breiten Vielfalt von Datenstrukturen eingesetzt werden, die in der Komplexität (z. B. Reihungen, Felder, Objekte, kryptographische Elemente, usw.) variieren, so können zum Beispiel einfache Implementierungen eine einfache Kontonummer sein, komplexere Implementierungen können Konteninformationen einfügen und/oder Werte prüfen. In einigen Fällen kann ein VME zusätzliche Funktionen liefern, wie z. B. kryptographischen Schutz, Haftung (d. h. Transaktionsverlauf, Anonymität, Betrugsentdeckung, usw.)
  • Die beschriebenen Ausführungsformen beziehen sich auf Verfahren und Vorrichtungen für sichere Transaktionen und Verwaltung von VMEs. In einer Ausführungsform verteilt ein Übertragungssystem ein VME an ein Client-Gerät. Das Übertragungssystem beinhaltet eine oder mehrere Instanzen, die das VME in Übereinstimmung mit einem Sicherheitsprotokoll mit drei Ebenen, die als L1, L2 und L3 bezeichnet werden können, verwalten und an das Client-Gerät verteilen. Auf L1 werden die VMEs sicher erzeugt, gespeichert und verschlüsselt. L1 kann durch ein oder mehrere Schließfächer unterstützt werden. L2 kontrolliert und verwaltet die Anzahl gültiger Kopien eines VMEs. L2 kann das unbeabsichtigte und/oder arglistige Klonen eines VMEs verhindern. In einem Aspekt der Ausführungsform kann L2 eine oder mehrere Anforderungen verwenden, um zweifache Kopien eines VMEs zu annullieren, nachdem eine erste Kopie des VMEs ausgeteilt wurde. L2 kann von einem oder mehreren Asset-Agents unterstützt werden. L3 authentifiziert und erlaubt die Verteilung von Assets an die beabsichtigten Client-Geräte. In einem Aspekt der Ausführungsform kann L3 einen Identifikator verwenden, der von einem sicheren Element erhalten wurde, das in einem Client-Gerät währen des Authentifizierungsprozesses angeordnet wurde. Ebenso kann L3 während des Authentifizierungsprozesses Informationen verwenden, die mit einem Benutzerkonto verbunden sind. L3 kann von einem oder mehreren Asset-Brokern unterstützt werden.
  • In einer Ausführungsform wird eine Übertragungstransaktion zwischen einem Client-Gerät und deinem Übertragungssystem offenbart. Das Übertragungssystem beinhaltet einen Asset Broker, einen Asset-Agent und ein Asset-Schließfach. Das Client-Gerät beinhaltet einen Geräte-Identifikator, der mit dem Client-Gerät verbunden ist. Der Identifikator kann in einem sicheren Element, das in dem Client-Gerät angeordnet ist, gespeichert und verschlüsselt werden. Ein Benutzerkonto kann eröffnet werden, wenn das Client-Gerät vom Benutzer gekauft wird (d. h. einem Kunden). Alternativ kann das Benutzerkonto ein zuvor bestehendes Konto sein, dass vom Benutzer identifiziert wird, wenn das Client-Gerät gekauft wird. Das Client-Gerät fordert ein VME von einem Asset-Broker an und liefert identifizierende Informationen, z. B. den Geräte-Identifikator. Der Asset-Broker authentifiziert die identifizierenden Informationen und bestimmt, dass das SE/Client-Gerät mit dem Benutzerkonto verbunden ist. Nach der Authentifizierung kann der Asset-Broker die Signatur des SE an den Asset-Agent weiterleiten. Der Asset-Agent prüft die Identität des sicheren Elements und identifiziert ein VME für das sichere Element. Dann liefert das sichere Element dem übertragenden System eine Anforderung. Testdaten, die auf der gelieferten Anforderung beruhen, können vom Asset-Agent in das VME eingebettet werden. Dementsprechend können die Testdaten verwendet werden, um zu verhindern, dass zweifache Kopien des VMEs ausgestellt werden. Das Asset-Schließfach kann einen Identifikator für das sichere Element des Client-Geräts bereitstellen, der mit dem VME verbunden ist, z. B. ein VME-Identifikator. Nach Erhalt des VME-Identifikators kann das Client-Gerät anschließend mithilfe des VME-Identifikators die Lieferung eines VMEs vom Asset-Broker fordern.
  • In einer anderen Ausführungsform kann die Konfiguration und Lieferung des VMEs zurückgestellt werden, bis ein Benutzer ein Client-Gerät mit einem sicheren Element kauft. Somit wird das Client-Gerät nicht mit einem VME hergestellt oder vorprogrammiert. Vielmehr ist das Client-Gerät „vor-individualisiert”, so dass es vor der Lieferung des Client-Geräts an den Benutzer ein VME zugeordnet bekommt. Der Prozess der „Vor-Individualisierung” kann das Verbinden eines in einem Übertragungssystem gespeicherten VMEs mit einem Identifikator beinhalten, der mit dem Client-Gerät verbunden ist. Zum Zeitpunkt des Kaufs werden die Authentifizierungsinformationen vom Benutzer bereitgestellt. Während des Übergangs (z. B. ein Zeitraum zwischen dem Kauf des Client-Geräts durch den Benutzer und der Anforderung des VMEs durch den Benutzer das VME, und/oder einen erforderlichen Zeitraum für den Versand des Client-Geräts zum Benutzer) kann das VME für das Client-Gerät vorkonfiguriert werden. Das Vorkonfigurieren des VMEs kann beinhalten (i) das Verschlüsseln des VMEs mit einem einmaligen sicheren Element, (ii) das Einbetten von Testdaten in das VME und/oder (iii) das Verbinden des VMEs mit Authentifizierungsinformationen. Das VME wird dann mit dem VME-Identifikator verbunden. Anschließend kann das Client-Gerät das VME mithilfe des VME-Identifikators anfordern. Dann kann das Übertragungssystem das VME an das vorkonfigurierte Client-Gerät liefern. Auf diese Weise kann das VME nahtlos auf das Client-Gerät geladen werden, wenn das VME ohne Anforderung von Echtzeitinformationen angefordert wird.
  • In einer weiteren Ausführungsform wird ein VME aus einem VME-Pool vor dem Erhalten einer Anfrage von dem Client-Gerät für ein VME einem Client-Gerät zugeordnet (z. B. jedes VME im VME-Pool ist anfänglich nicht mit einem speziellen Client-Gerät verbunden). Wenn das Client-Gerät gekauft ist, werden die Authentifizierungsinformationen vom Benutzer bereitgestellt. Das Client-Gerät kann dem Benutzer geliefert werden. Zusätzlich zum Client-Gerät können die identifizierenden Informationen verwendet werden, um das Client-Gerät zu authentifizieren, z. B. wird ein Geräte-Identifikator, der das Client-Gerät eindeutig identifiziert, auch für den Benutzer bereitgestellt. Zum Beispiel kann der Geräte-Identifikator von einem auf einem Aufkleber, der auf einem Karton angebracht ist, in dem das Client-Gerät verpackt ist, entnommen werden. Das Client-Gerät gerät kann dann bei der Anforderung der Aktivierung eines VME auf Anweisung des Benutzers den Geräte-Identifikator an das Übertragungssystem liefern.
  • Diese und andere Ausführungsformen werden unten mit Bezug auf 1 bis 13C erläutert; allerdings werden Fachleute leicht verstehen, dass die hier enthaltenen detaillierten Beschreibungen bezüglich dieser Abbildungen nur der Erläuterung dienen und nicht als einschränkend auszulegen sind.
  • Bezugnehmend auf 1 ist ein beispielhaftes Transaktionsnetzwerk 100 dargestellt. Das beispielhafte Transaktionsnetzwerk 100 beinhaltet ein oder mehrere Client-Geräte 102, ein oder mehrere Händler-Geräte (auch als „Point of Sale” (POS, Verkaufsstelle) bezeichnet) 104 und einen oder mehrere Backend-Server 106. Fachleute werden es schätzen, dass das vorgenannte Transaktionsnetzwerk 100 nur veranschaulichend für das breitere Feld der möglichen Netzwerktopologien und -Funktionen dient. Weiterhin sollte erkannt werden, dass verschiedene Implementierungen die verschiedenen in 1 dargestellten Einheiten kombinieren und/oder weiter teilen können.
  • Eine Transaktion wird durchgeführt, wenn das Client-Gerät 102 Transaktionsinformationen kryptographisch verschlüsselt und an das Händler-Gerät 104 sendet. In einem Beispiel kann das Client-Gerät 102 ein virtuelles „Wallet” beinhalten, das konfiguriert ist, um Transaktionen mit dem Händler-Gerät 104 z. B. durch Wischen gegen ein entsprechendes Lesegerät durchzuführen (wie z. B. Nahbereichskommunikation (Near-Field Communication, NFC), usw.), visuelle Prüfung eines Transaktions-Identifikators (z. B. ein Barcode, eine Zahl, usw.) von einer graphischen Benutzerschnittstelle (Graphical User Interface, GUI) usw. In einem anderen Beispiel kann das Client-Gerät 102 ein Global Positioning System (GPS), einen Empfänger oder sonstige Standortinformationen beinhalten (z. B. Vorhandensein von Wi-Fi, usw.), die verwendet werden, um das Händler-Gerät 104 (z. B. Registrierkasse, tragbarer Tablet-PC, usw.) über die Gegenwart des Client-Geräts 102 zu informieren, und die nachfolgende Validierung des Benutzers des Client-Geräts 102 (z. B. Biometrie wie z. B. ein Foto seines Gesichts) wird durchgeführt, um die Belastung eines bekannten Benutzerkontos zu genehmigen. Die Transaktionsinformationen können eine Kombination aus Folgendem beinhalten: (i) ein Pseudonym, (ii) einen inkrementellen Zähler, (iii) eine zufällige Zahl, (iv) einen Händler-Identifikator, (v) sonstige Transaktions-Errata (z. B. abgewickelter Betrag, Zeitstempel, Standortstempel, usw.).
  • Das Händler-Gerät 104 liefert die geschützten Transaktionsinformationen an den Backend-Server 106. Danach kann der Backend-Server 106 die geschützten Transaktionsinformationen entschlüsseln, die Transaktion prüfen und die Transaktion entsprechend verarbeiten. Zum Beispiel wird ein Aliaswert einer Kreditkartennummer zugeordnet und wenn die verschlüsselten Informationen korrekt sind, dann verarbeitet der Backend-Server 106 die Transaktion mit der Kreditkartennummer, die dem Aliaswert zugeordnet ist. Anderenfalls wird die Transaktion abgewiesen, wenn die Transaktionsinformationen beschädigt sind oder betrügerisch erscheinen.
  • In dem beispielhaften Transaktionsnetzwerk 100 schützt der auf die Transaktionsinformationen angewendeter kryptographische Schutz die wertvollen Informationen des Benutzers vor arglistigen Parteien und/oder den Händler. Insbesondere kann der kryptographische Schutz helfen zu verhindern, dass die Transaktion später auf betrügerische Weise wiederholt wird, selbst wenn eine betrügerische Partei versuchen würde, die Transaktionsinformationen abzufangen oder wenn das Händler-Gerät 104 beeinträchtigt wäre (z. B. durch einen Virus, usw.). Um den Benutzerschutz zu maximieren, sind die kryptographischen Elemente dementsprechend physisch innerhalb eines sicheren Elements geschützt, das in dem Client-Gerät 102, welches einen sicheren Prozessor, ein sicheres Dateisystem und Arbeitsspeicher beinhaltet, angeordnet ist. Allerdings werden Fachleute erkennen, dass das Erhalten der Sicherheit des in dem Gerät des Kunden gespeicherten kryptographischen Materials schwierig ist. Ein solches Problem ist zum Beispiel die anfängliche Konfiguration, die Umsetzung und Wartung. Client-Geräte werden von Geräteherstellern gefertigt (die unzuverlässig sein könnten). Ebenso können einige Geschäftsmodelle von einem Markt von Drittteilnehmern abhängen (die unzuverlässig sein könnten).
  • Idealerweise sollten die Lösungen für die Austeilung von kryptographischem Material über große Distributionsnetzwerke hinweg anpassbar sein. Weiterhin muss ein Distributionsmodell die kryptographischen Materialien (Anmeldedaten) vor Zwischeninstanzen schützen (z. B. Gerätehersteller, Dritt-Brokern, usw.). In einigen Ausführungsformen sollten die kryptographischen Materialien einmalig vorkommen (d. h. eine einzige Asset-Instanz kann in nur jeweils einem einzigen sicheren Element verwendet werden). Abschließend sollten Lösungen die Anforderungen auf Echtzeit-Interaktion auf ein Mindestmaß beschränken.
  • Bezugnehmend auf 2 ist ein beispielhaftes Transaktionsnetzwerk 200 dargestellt. Wie gezeigt beinhaltet das Übertragungssystem 200: Client-Gerät 300, Asset-Agent 400, Asset-Broker 500 und Asset-Schließfach 600. Wie zuvor im Zusammenhang mit dem VME-Vorgang beschrieben, kann die VME-Sicherheit weiter in Ebenen unterteilt werden, die beinhalten: Ebene 1 (L1), Ebene 2 (L2) und Ebene 3 (L3). Jede Ebene kann durch ein Element des Übertragungssystems 200 unterstützt werden.
  • Das Asset-Schließfach 600 kann verwendet werden, um die VME-Sicherheit in Übereinstimmung mit der Sicherheit der Ebene 1 (L1) zu schaffen. Die hier verwendete Sicherheit der Ebene 1 (L1) bezieht sich im Allgemeinen und ohne Einschränkung auf die zum Schutz der Geheimnisse und/oder in einem VME enthaltenen kryptographischen Materialien konfigurierten Sicherheitsmechanismen (z. B. Sicherheitsschlüssel, kryptographisches Material, Benutzerhistorie, usw.). Weiterhin bezieht sich der Begriff „Sicherheit” im Allgemeinen auf den Schutz von Daten und/oder Software. So schützt zum Beispiel die kryptographische Sicherheit Daten und/oder Software, die mit einem VME verbunden ist, vor Diebstahl, Missbrauch, Beschädigung, Veröffentlichung/oder Fälschung durch unerlaubte Tätigkeiten und/oder arglistige Dritte.
  • Der Asset-Agent 400 kann verwendet werden, um die VME-Sicherheit in Übereinstimmung mit der Sicherheit der Ebene 2 (L2) zu schaffen. Die hier verwendete Sicherheit der Ebene 2 bezieht sich im Allgemeinen und ohne Einschränkung auf Sicherheitsmechanismen zur Verhinderung von zufälligem und/oder bösartigem Klonen eines VME (Erhaltungserzwingung). Ferner beziehen sich die hier verwendeten Begriffe „Erhaltung”, „erhalten” und „bewahrt” auf ein (entweder physisches oder virtuelles) Element, das nicht belanglos vervielfältigt oder vermindert werden kann. So kann zum Beispiel ein bewahrtes VME nicht während des normalen Betriebs kopiert oder repliziert werden. Zudem bezieht sich der hier für ein (entweder physisches oder virtuelles) Element angewandte Begriff „Einmaligkeit” auf die Eigenschaft, wobei das Element das eine und einzige Element ist, das eine besondere Eigenschaft und/oder ein besonderes Merkmal besitzt. So kann zum Beispiel ein einmaliges VME kein zweites VME haben.
  • Der Asset-Broker 500 kann verwendet werden, um die VME-Sicherheit in Übereinstimmung mit der Sicherheit der Ebene 3 (L3) zu schaffen. Die hier verwendete Ebene 3 (L3) bezieht sich im Allgemeinen und ohne Einschränkung auf Sicherheitsmechanismen, die VMEs sicher an ein Gerät liefern (z. B. Client-Gerät, POS, usw.), das mit dem beabsichtigten Benutzer (z. B. eine Person, ein Unternehmen, ein Maschinen-Client, usw.) verbunden ist. Zudem bezieht sich der hier verwendete Begriff (Benutzerberechtigung) im Allgemeinen auf das Angeben eines Benutzerzugangs zu Ressourcen. Mit gängigen Zahlungsmitteln (Kreditkarten, Debitkarten, Bargeld) können Transaktionen den physischen Besitz des Mittels erfordern; und die physische Karte wird vom Benutzer geschützt. Wenn zum Beispiel eine physische Kreditkarte verwendet wird, ist davon auszugehen, dass die Karte sich im Besitz des Benutzers befindet (und somit vom Benutzer erlaubt ist). Im Rahmen des VME-Vorgehens werden analoge Ressourcen für die Benutzerberechtigung von VME-Übertragungen benötigt. Insbesondere benötigt der „Eigentümer” des VME (und auch das Übertragungssystem 200) Gewährleistungen, dass das VME nur auf ein oder mehrere rechtmäßige Geräte übertragen wird.
  • Aus nachstehend erklärten Gründen ist jede Sicherheitsebene mit einer beschränkten Reihe von Ressourcen/Verantwortlichkeiten verbunden; somit kann ein Gerät, dass die Sicherheit der Ebene 2 bietet, mit Ebene 2 verbundene Bewegungen frei ausführen, muss jedoch auch die Sicherheit der Ebene 1 enthalten, die in der Lage ist, die Elemente des VME der Ebene 1 zu beeinflussen. Ein Asset-Agent (nachstehend genauer beschrieben) verhindert zum Beispiel, dass ein VME geklont wird; allerdings hat der Asset-Agent nicht unbedingt die Fähigkeit, das in einem VME enthaltene kryptographische Material zu ändern, noch ist der Asset-Agent dafür verantwortlich, beschädigtes kryptographisches Material zu erkennen.
  • Die vorgenannten Definitionen von VME-Sicherheitsebenen sind rein veranschaulichend und nicht dazu bestimmt, die hier angegebenen Beschreibungen einzuschränken. Tatsächlich ist davon auszugehen, dass die vorgenannte Terminologie als „Umgangssprache” der jeweiligen Techniken angesehen wird und sich im Hinblick auf die einsetzende Entwicklung der damit verbundenen Branchen und/oder Technologien wahrscheinlich verändern wird.
  • Es ist bekannt, dass Software oft flexibler als Hardware ist; so kann Software zum Beispiel leichter kopiert, verändert und verbreitet werden. Zusätzlich kann Software oft günstiger, energieeffizienter und physisch kleiner hergestellt werden als gleichwertige Hardware. Allerdings erfordert die Sensibilität der VME-Daten (z. B. finanzielle Kundeninformationen, kryptographische Geheimnisse des Asset-Brokers, usw.) besondere Beachtung. Es wird erwartet, dass die unbeabsichtigte Vervielfältigung und/oder Zerstörung von VMEs im Interesse des Benutzerschutzes verhindert werden muss. Dementsprechend sollte der VME-Vorgang folgende Merkmale erfüllen: (i) Sicherheit, (ii) Einmaligkeit und (iii) Erhaltung.
  • In einer beispielhaften Ausführungsform wird eine Verteilerinfrastruktur offenbart, die die Lieferung von VMEs an sichere Elemente ermöglicht. Ein sicheres Element kann in einem Client-Gerät und/oder einem Händler-Gerät angeordnet sein. Zudem können verschiedene Funktionen der offenbarten Infrastruktur flexibel unterteilt und/oder angepasst werden, so dass einzelne Parteien (z. B. Gerätehersteller, Dritthändler, Kunden, usw.,) Teile der Infrastruktur aufnehmen können; diese stückweisen Lösungen können für die Bedürfnisse jeder einzelnen Partei optimiert werden. Weitere beispielhafte Ausführungsformen können betriebliche Redundanz bereitstellen.
  • Bezugnehmend auf 3A ist ein beispielhaftes Client-Gerät 300 dargestellt. Das beispielhafte Client-Gerät 300 beinhaltet: eine Client-Händler-Schnittstelle 302, ein Prozessor-Teilsystem 304, ein nicht-flüchtiges computerlesbares Medium (Speicher-Teilsystem) 306 und ein sicheres Element 308. In einigen Varianten beinhaltet das sichere Element 308 weiterhin einen sicheren Prozessor 308A und ein sicheres nicht-flüchtiges computerlesbares Medium (sicherer Speicher) 308B. Der hier verwendete Begriff „Client-Gerät” beinhaltet unter anderem Geräte, die konfiguriert sind, um ein oder mehrere VMEs eines Benutzers zu übertragen und/oder zu verwalten. Gängige Beispiele von Client-Geräten sind unter anderem kabellose Mobiltelefone, Smartphones (wie zum Beispiel ein iPhoneTM), drahtlose Personal Computers (PCs), Mobilgeräte wie z. B. Taschencomputer, Personal Digital Assistants (PDAs), Personal Media Devices (PMDs), drahtlose Tablets (wie zum Beispiel ein iPadTM), sogenannte „Phablets” oder jede Kombination aus den Vorgenannten.
  • Das Prozessor-Teilsystem 304 kann einen oder mehrere digitale Signalprozessoren, Mikroprozessoren, Field Programmable Gate Arrays, oder eine Vielzahl von verarbeitenden Komponenten beinhalten, die auf einem oder mehreren Substraten angebracht sind. Das Prozessor-Teilsystem 304 kann ebenso einen internen Zwischenspeicher beinhalten. Das Prozessor-Teilsystem 304 kommuniziert mit dem Speicher-Teilsystem 306, wobei letzteres einen Speicher beinhaltet, der zum Beispiel Komponenten eines statischen Arbeitsspeichers (SRAM), Flashs und/oder synchronen dynamischen Arbeitsspeichers (SDRAM) beinhalten kann. Das Speicher-Teilsystem 306 kann einen oder mehrere direkte Hardware-Speicherzugänge (DMA) enthalten, um den Datenzugang zu erleichtern, wie bei Fachleuten bekannt ist. Das Speicher-Teilsystem 306 der beispielhaften Ausführungsform enthält computerausführbare Anweisungen, die vom Prozessor-Teilsystem 304 ausgeführt werden können.
  • In einer beispielhaften Ausführungsform umfasst das Client-Gerät 300 eine oder mehrere Schnittstellen, z. B. die Client-Händler-Schnittstelle 302, die für den Anschluss an ein Händler-Gerät angepasst ist. Die Client-Händler-Schnittstelle 302 kann eine drahtlose Schnittstelle oder alternativ eine physische Schnittstelle (verdrahtet) sein. Drahtlose Schnittstellen können Touch- oder Bump-Schnittstellen beinhalten, die Betriebsbereiche von bis zu einigen Zentimetern haben (z. B. Radiofrequenz-Identifizierung (RFID), NFC, usw. wie zum Beispiel diejenigen, die der Norm 14443A/B der International Organization for Standardization (ISO) entsprechen, die hier durch Verweis in ihrer Gesamtheit beinhaltet ist) bis zu leistungsfähigeren Drahtlosschnittstellen wie z. B. Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE)/LTE-Advanced, Worldwide Interoperability for Microwave Access (WiMAX), Wi-Fi, Bluetooth, Wireless Universal Serial Bus (USB), usw. Geläufige Beispiele physischer Schnittstellen beinhalten z. B. USB (z. B. USB 2.0, USB 3.0), FireWire, Thunderbolt, usw. Zudem ist bekannt, dass bestimmte Geräte einen Karten-Formfaktor haben können, wie zum Beispiel eine Subcriber Identity Module(SIM)-karte oder Kreditkarte usw. Diese „Karten-”geräte können mit dem vorhandenen Ökosystem von Bezahl-Lesegeräten rückwärtskompatibel sein und dennoch die hier beschriebenen verbesserten Funktionen unterstützen.
  • In einigen Ausführungsformen kann das Client-Gerät 300 zudem andere Komponenten beinhalten, wie z. B. ein Benutzerschnittstellen-Teilsystem, dass eine beliebige Anzahl gut bekannter I/O beinhaltet, einschließlich und ohne Einschränkung; eine Kleintastatur, einen Touchscreen (z. B. eine Multi-Touch-Oberfläche) eine Flüssigkristallanzeige (LCD), eine Hintergrundbeleuchtung, einen Lautsprecher und/oder ein Mikrofon. Es ist bekannt, dass eine Benutzerschnittstelle in einigen Anwendungen unnötig sein kann. So können zum Beispiel Ausführungsformen des Karten-Clients keine Benutzerschnittstelle besitzen.
  • In der dargestellten Ausführungsform beinhaltet das Client-Gerät 300 ein sicheres Element 308. Das sichere Element 308 beinhaltet in dieser Ausführungsform: einen sicheren Prozessor 308A, der die im sicheren Speicher 308B gespeicherte Software ausführt. Der sichere Speicher 308B ist für alle anderen Komponenten nicht zugänglich (mit Ausnahme des sicheren Prozessors 308A). Zudem kann das sichere Element 308 physisch weiter gehärtet werden, um Fremdeinwirkung zu verhindern (z. B. in Harz gegossen).
  • Das sichere Element 308 ist in der Lage, einen oder mehrere VMEs zu erhalten, zu übertragen und zu speichern. In einer Ausführungsform speichert das sichere Element 308 ein Feld oder eine Vielzahl von VMEs, die mit einem Benutzer (z. B. Kredit-„karten”, Debit-„karten”, vorbezahlte Konten- oder Kartennummern, Busfahrscheine, Kinoeintrittskartengutscheine, sonstige Gutscheine, Elemente von „Treue-”programmen usw.) In einigen Varianten kann jedes VME weiterhin mit einem kleinen Dateisystem verbunden werden, das computerlesbare Anweisungen und zugehörige Daten beinhaltet (z. B. Chiffrierschlüssel, Integritätsschlüssel, usw.)
  • Das Dateisystem kann zusätzliche Funktionen unterstützen. Zum Beispiel kann das Dateisystem Programme und Daten z. B. für Sicherheit (zum Beispiel: Authentifizierungsprogramme, Berechtigungsprogramme und kryptographisches Material zum Schutz von Kommunikationen mit anderen Instanzen), Benutzerverwaltung (z. B. Kontostand-Informationen, kürzlicher Transaktionsverlauf, usw.), usw. beinhalten. Fachleute werden schnell erkennen, dass ein VME mit dem verbundenen Dateisystem ein einmaliger und bewahrter Datensatz ist.
  • Zudem führt das sichere Element 308 in einer Ausführungsform eine Listung oder ein Verzeichnis der gespeicherten VMEs und ihrer zugehörigen Dateisysteme. Das Verzeichnis kann Information bezüglich des aktuellen Status der gespeicherten VMEs beinhalten; diese Informationen können zum Beispiel beinhalten: Verfügbarkeit für die Nutzung, Gültigkeit, Kontoinformationen (z. B. aktueller Stand, usw.) und/oder zuvor erfolgte Fehler. Weiterhin kann das Verzeichnis mit einer Benutzerschnittstelle verbunden oder verkoppelt sein, um die Benutzerwahl eines verfügbaren VME für die Nutzung zu ermöglichen. In einigen Fällen kann der Benutzer ein VME als Standard wählen (z. B. eine Standard-Kreditkarte) z. B. für alle Transaktionen, alle Transaktionen mit einem Händler, alle Transaktionen in einem Zeitraum, usw.
  • In einigen Varianten kann das sichere Element 308 einen oder mehrere zugehörige kryptographische Geräteschlüssel besitzen. Diese Geräteschlüssel werden zur Sicherung der Geschäfte verwendet. In einer solchen Variante sind die kryptographischen Schlüssel ein asymmetrisches öffentliches/privates Schlüsselpaar zur Verschlüsselung von Transaktionen des Nachrichtenaustauschs. Der öffentliche Schlüssel kann ohne Beschädigung der Integrität der privaten Schlüssel frei verteilt werden. So kann zum Beispiel dem Client-Gerät 300 ein öffentlicher/privater Schlüssel auf Basis des Algorithmus Rivest, Shamir und Adleman (RSA) zugeordnet (oder intern generiert) werden; der öffentliche Schlüssel wird jedem Gerät zur Verfügung gestellt, das sicher mit dem Client-Gerät 300 kommunizieren möchte. Eine mit einem öffentlichen Schlüssel des Client-Geräts 300 verschlüsselte Mitteilung kann nur durch den eigenen privaten Schlüssel des Client-Geräts entschlüsselt werden (der sicher im Client-Gerät 300 gespeichert ist). In anderen Varianten sind die kryptographischen Schlüssel symmetrisch (d. h. das verschlüsselnde Gerät und das entschlüsselnde Gerät haben den gleichen Schlüssel). Symmetrische Varianten können verminderte kryptographische Komplexität bieten, erfordern jedoch, dass sowohl das verschlüsselnde Gerät als auch das entschlüsselnde Gerät ihren gemeinsamen Schlüssel streng schützen.
  • In anderen Varianten kann das sichere Element 308 kryptographische Schlüssel zum Prüfen und/oder Ausstellen von digitalen Zertifikaten besitzen. Ein digitales Zertifikat kann z. B. zur Prüfung der Identität des Ausstellers (des Zertifikats) verwendet werden. Zum Beispiel kann das sichere Element 308 ein digitales Zertifikat für ein Händler-Gerät ausstellen, so dass das Händler-Gerät später nachweisen kann, dass die Transaktion erfolgt ist (durch Abrufen des unterzeichneten Zertifikats des Client-Geräts). Ähnlich kann das sichere Element 308 ein vom einem Händler-Gerät bereitgestelltes digitales Zertifikat prüfen, das beweist, dass das Händler-Gerät vertrauenswürdig ist.
  • Während einer Client-Händler-Transaktion (oder Client/zwischengeschaltete Dritttransaktion) führt das sichere Element 308 eine Transaktion mit einem oder mehreren zugehörigen VMEs aus. Einfache Ausführungsformen können eine Übertragung einer Kontonummer, Proxy-Nummer oder eine Teilgruppe dieser sein. In komplexeren Varianten kann die Übertragung z. B. einen getätigten Betrag, kryptographischen Schutz, bescheinigende Informationen (z. B. Uhrzeit/Datum und Ort der Übertragung), Händler-ID-Informationen usw. beinhalten.
  • Während viele der hier beschriebenen Ausführungsformen im Rahmen von Finanztransaktionen beschrieben sind, sind auch nicht-finanzielle Transaktionen geeignet. Zum Beispiel können Gutscheine, Fahrscheine usw. entsprechend der Nutzung um eine Anzahl von Punkten erhöht und/oder gemindert werden. In anderen Beispielen kann die Transaktion eine Gültigkeitsprüfung sein; zum Beispiel ist ein Busausweis für einen zeitlichen Bereich gültig (z. B. Tage, Wochen, Monate, Jahre, usw.), somit ist jede Anzahl von Nutzungen innerhalb dieses zeitlichen Bereichs gültig. Ähnlich können bestimmte Ausweisarten Ausschlussterminen unterliegen, zu denen der Ausweis für die Dauer des Ausschlusstermins ungültig ist.
  • In einigen Ausführungsformen wird die Client-Händler(oder sonstige)-Transaktion zwischen dem Client-Gerät 300 und einem Händler-Gerät zu einem gemeinsamen Zeitpunkt ausgeführt (d. h. das Client-Gerät 300 und das Händler-Gerät erleben die Transaktion beide zum gleichen Zeitpunkt); in einer NFC-Transaktion ist die NFC-Schnittstelle des Client-Geräts zum Beispiel nahe („bumped” an der NFC-Schnittstelle eines Händler-Geräts angebracht, wie z. B. ein Abfragesystem, das ein Signal an ein zumindest teilweise passives NFC-IC im Client-Gerät 300 überträgt.
  • Allerdings ist bekannt, dass eine Client-Händler-Transkation in wechselweisen Szenarios zeitlich versetzt ausgeführt werden kann. Zum Beispiel kann ein Client-Gerät oder ein Händler-Gerät die Transaktion zu einem ersten Zeitpunkt auslösen und das zugehörige Gerät bestätigt die Transaktion zu einem späteren Zeitpunkt. Nachdem die Geräte beide die Transaktion bestätigt haben, kann die Transaktion abgeschlossen werden (z. B. Übertragen der jeweiligen Mittel, usw.). Zum Beispiel führen ein Kunde und ein Händler eine Transaktion z. B. auf einem Bauernmarkt durch, wo keine Konnektivität besteht. Wenn das Händler-Gerät sich später mit einem Asset-Broker verbindet, wird die Transaktion ausgelöst. Danach synchronisiert das Client-Gerät seinen Transaktionsbericht, was die Transaktion abschließt. In einigen Fällen kann der Asset Broker zudem das Client-Gerät informieren, wenn ausstehende Kosten anfallen.
  • Bezugnehmend auf 3B ist ein beispielhaftes Händler-Gerät 350 dargestellt. Das beispielhafte Händler-Gerät 350 beinhaltet: eine Händler-Client-Schnittstelle 352, ein Prozessor-Teilsystem 354, ein nicht-flüchtiges computerlesbares Medium (Speicher-Teilsystem) 356 und eine Netzwerkschnittstelle 358. Der hier verwendete Begriff „Händler-Gerät” beinhaltet unter anderem Geräte, die konfiguriert sind, um auf einen einem VME zugehörigen Server zu übertragen und/oder diesen abzufragen (z. B. Backend-Server 106) (z. B. um festzustellen, ob eine Transaktion genehmigt werden sollte, usw.). Dabei gilt, dass die Verwendung des Begriffs „Händler” diese Definition nicht nur auf Geräte beschränkt sein soll, die Eigentum von Instanzen sind oder von diesen betrieben werden, die etwas kaufen oder verkaufen. Vielmehr soll dieser Begriff weitergehend und ohne Einschränkung eine Vorrichtung beinhalten, die für die Verarbeitung von Transaktionen konfiguriert oder freigegeben ist, gleichgültig, ob diese Transaktion für Güter, Dienstleistungen, virtuelle Bezahlungen, das Empfangen oder das Einzahlen von Mitteln oder Guthaben, die Einlösung von Gutscheinen usw. bestimmt ist. Geläufige Beispiele von Händler-Geräten beinhalten unter anderem: Kiosks, Geldautomaten (z. B. ATM), Registrierkassen, mobile Checkout-Lesegeräte (z. B. auf Basis von RIFD oder Barcodes), mobile drahtlose Tablets und sogar Smartphones. Weiterhin ist bekannt, dass, während Händler-Geräte seit jeher zweckgebundene Geräte sind, eine zunehmende Anzahl der elektronischen Kundengeräte nun befähigt sind, kleine Geschäfte durchzuführen (z. B. drahtlose Mobiltelefone, Smartphones, Personal Computer (PC), Taschencomputer, PDAs, Personal Media-Geräte (PMDs), drahtlose Tablets, „Phablets”, usw.), die zum Zeitpunkt der Herstellung oder im Nachhinein durch Dritte oder Benutzer der Geräte selbst ausgestattet werden.
  • Das Prozessor-Teilsystem 354 kann einen oder mehrere digitale Signalprozessoren, Mikroprozessoren, Field Programmable Gate Arrays, oder eine Vielzahl von verarbeitenden Komponenten beinhalten, die auf einem oder mehreren Substraten angebracht sind. Das Prozessor-Teilsystem 354 kann ebenso einen internen Zwischenspeicher beinhalten. Das Prozessor-Teilsystem 354 kommuniziert mit dem Speicher-Teilsystem 356, wobei letzteres einen Speicher beinhaltet, der zum Beispiel Komponenten eines SRAM, Flashs und/oder SDRAM beinhalten kann. Das Speicher-Teilsystem 356 kann eine oder mehrere Hardware-Elemente des Typs DMA enthalten, um den Datenzugang zu erleichtern, wie im Stand der Technik bekannt ist. Das Speicher-Teilsystem 356 der beispielhaften Ausführungsform enthält computer-ausführbare Anweisungen, die vom Prozessor-Teilsystem 354 ausgeführt werden können.
  • In einer beispielhaften Ausführungsform umfasst das Händler-Gerät 350 eine oder mehrere Schnittstellen, z. B. die Händler-Schnittstelle 352, die für den Anschluss an ein Client-Gerät angepasst ist. Die Händler-Client-Schnittstelle 352 kann eine drahtlose Schnittstelle oder alternativ eine physische Schnittstelle (verdrahtet) sein. Drahtlose Schnittstellen können Touch-Schnittstellen mit Betriebsbereich von bis zu wenigen Zentimetern (z. B. RFID, NFC, usw.) bis hin zu leistungsfähigeren drahtlosen Schnittstellen wie z. B. GSM, CDMA, UMTS, LTE/LTE-A, WiMAX, Wi-Fi, Bluetooth, Wireless USB, usw. oder eine beliebige Kombination der Vorgenannten beinhalten. Zum Beispiel kann ein Händler-Gerät 350 eine Nahbereichs-NFC-Schnittstelle sowie eine Wi-Fi-Schnittstelle mit größerer Reichweite und sogar eine WiMAX-, Satelliten- oder Funkschnittstelle beinhalten. Geläufige Beispiele physischer Schnittstellen beinhalten z. B. USB, FireWire, Thunderbolt, usw. In einigen Varianten kann die Händler-Client-Schnittstelle 352 als Kartenlesegerät oder Smartcard-Anschluss eingebaut werden (z. B. zur fortgesetzten Kompatibilität mit bestehenden rechtmäßigen Karten, usw.).
  • In einigen Ausführungsformen kann das Händler-Gerät 350 auch andere Komponenten beinhalten, wie z. B. ein Benutzerschnittstellen-Teilsystem, dass eine beliebige Anzahl gut bekannter I/O beinhaltet, einschließlich und ohne Einschränkung; eine Kleintastatur, eine Touchscreen (z. B. eine Multi-Touch-Oberfläche) eine Flüssigkristallanzeige (LCD), eine Hintergrundbeleuchtung, einen Lautsprecher und/oder ein Mikrofon. Es ist bekannt, dass eine Benutzerschnittstelle in einigen Anwendungen unnötig sein kann. So können zum Beispiel einfache Kartenlese-Händlergeräte keine Benutzerschnittstelle besitzen.
  • In der dargestellten Ausführungsform beinhaltet das Händler-Gerät 350 eine Netzwerkschnittstelle 358, die konfiguriert ist, um eine Transaktion mit einem oder mehreren VMEs sicher an einen Asset-Broker zu berichten. In einigen Varianten kann jede Transaktion für die weitere Verwendung/Buchhaltung zudem in einem sicheren Dateisystem gespeichert werden. Geläufige Beispiele einer Netzwerkschnittstelle beinhalten, ohne darauf beschränkt zu sein: Ethernet, Digital Subscriber Line (DSL), Kabel, Hybrid Fiber Coaxial, drahtloses lokales Netzwerk (WLAN), Funkdatenverbindungen usw.
  • In einigen Ausführungsformen kann das Händlergerät 350 zugehörige kryptographische Geräteschlüssel oder sonstige kryptographische Möglichkeiten besitzen, wie z. B. unter anderem die Verschlüsselung Advanced Encryption Standard (AES/Data Encryption Standard (DES), Internet Protocol Security (IPSec), Multimedia Internet Keying (MIKEY), Secure Socket Layer (SSL)/Transport Layer Security (TLS). Diese Geräteschlüssel (und/oder sonstige Eigenschaften) können zur Sicherung von Geschäften verwendet werden. In einer dieser Varianten sind die kryptographischen Schlüssel ein asymmetrisches öffentliches/privates Schlüsselpaar. In weiteren Varianten sind die kryptographischen Schlüssel ein symmetrisches Schlüsselpaar. In anderen Varianten kann das Händlergerät 350 kryptographische Schlüssel zum Prüfen und/oder Ausstellen digitaler Zertifikate besitzen. Zudem kann eine NFC-Schnittstelle (falls verwendet) darauf angewandte Verschlüsselung besitzen, wie zum Beispiel zum Verschlüsseln sensibler Benutzer- oder Zahlungsinformationen während der Übermittlung.
  • Während einer beispielhaften Client-Händler-Transaktion führt das Händler-Gerät 350 eine Transaktion mit einem oder mehreren verbundenen VMEs durch. Zum Beispiel kann das Händlergerät 350 die virtuelle Kreditkarte eines Client-Geräts im Austausch gegen eine Ware/Dienstleistung empfangen (oder anfordern). Die empfangenen Informationen können zusätzlich z. B. einen abzuwickelnden Betrag, Informationen zur Validitätsprüfung, kryptographischen Schutz, Beleginformationen (z. B. Uhrzeit/Datum und Ort der Transaktion), Händler-ID, usw. beinhalten. In anderen Ausführungsformen kann das Händlergerät 350 dem Client-Gerät Meldung erstatten, z. B. über einen abgewickelten Betrag, ob die Transaktion erfolgreich verlaufen ist, verwendete Zahlungsquelle, Händler-ID, usw.
  • Während einer beispielhaften Transaktion zwischen Händlergerät und Asset-Broker meldet das Händlergerät 350 die Transaktion an einen Asset-Broker. Dies kann Meldeinformationen in Verbindung mit dem VME des Client-Geräts, das zu kreditierende/zu belastende Händlerkonto, usw., und einen abzuwickelnden Betrag beinhalten. Als Antwort bestätigt der Asset-Broker, dass der Betrag erfolgreich (oder erfolglos) von einem entsprechenden Konto des Client-Geräts auf ein Konto des Händlergeräts übertragen wurde.
  • In 4 ist ein beispielhafter Asset-Agent 400 dargestellt. Der beispielhafte Asset-Agent 400 beinhaltet: eine Client-Geräteschnittstelle 402, ein Prozessor-Teilsystem 404, ein nicht-flüchtiges computerlesbares Medium (Speicher-Teilsystem) 406 und eine Netzwerkschnittstelle 408. Der hier verwendete Begriff „Asset-Agent” beinhaltet unter anderem Einheiten, die konfiguriert sind, VMEs zu verteilen. Geläufige Beispiele von VMEs beinhalten unter anderem: Gerätehersteller, Drittwiederverkäufer, usw.
  • Das Prozessor-Teilsystem 404 kann einen oder mehrere digitale Signalprozessoren, Mikroprozessoren, feldprogrammierbare Gate-Arrays, oder eine Vielzahl von verarbeitenden Komponenten beinhalten, die auf einem oder mehreren Substraten angebracht sind. Das Prozessor-Teilsystem 404 kann ebenso einen internen Zwischenspeicher beinhalten. Das Prozessor-Teilsystem 404 kommuniziert mit dem Speicher-Teilsystem 406, wobei letzteres einen Speicher beinhaltet, der zum Beispiel SRAM-, Flash- und/oder SDRAM-Komponenten beinhalten kann. Das Speicher-Teilsystem 406 kann ein oder mehrere DMA-Hardware-Elemente beinhalten, um die Fachleuten bekannten Datenzugänge zu ermöglichen. Das Speicher-Teilsystem 406 der beispielhaften Ausführungsform enthält computer-ausführbare Anweisungen, die von dem Prozessor-Teilsystem 404 ausgeführt werden können.
  • In einer beispielhaften Ausführungsform beinhaltet der Asset-Agent 400 eine oder mehrere Schnittstellen, z. B. die Client-Geräteschnittstelle 402, die für den Anschluss an ein Client-Gerät geeignet ist. Die Client-Geräteschnittstelle 402 kann eine Drahtlos-Schnittstelle oder wechselweise eine physische Schnittstelle (verdrahtet) sein. Drahtlos-Schnittstellen können z. B. GSM, CDMA, UMTS, LTE/LTE-A, WiMAX, Wi-Fi, Bluetooth, Wireless USB, usw. beinhalten. Geläufige Beispiele physischer Schnittstellen beinhalten z. B. USB, FireWire, Thunderbolt, usw.
  • In der dargestellten Ausführungsform beinhaltet der Asset-Agent eine Netzwerkschnittstelle 408, die konfiguriert ist, die Verteilung von einem oder mehreren VMEs mit einem Asset-Broker sicher zu melden. Geläufige Beispiele einer Netzwerkschnittstelle beinhalten unter anderem: Ethernet, DSL, Cable, Hybrid Fiber Coaxial, WLAN, Mobilfunk-Datenverbindungen, usw.
  • In einigen Ausführungsformen kann der Asset-Agent 400 verbundene kryptographische Geräteschlüssel besitzen. Diese Geräteschlüssel können zur Sicherung von Geschäften verwendet werden. In einer solchen Variante sind die kryptographischen Schlüssel ein asymmetrisches öffentliches/privates Schlüsselpaar. In weiteren Varianten sind die kryptographischen Schlüssel ein symmetrisches Schlüsselpaar. In anderen Varianten kann der Asset-Agent 400 kryptographische Schlüssel zum Prüfen und/oder Ausstellen digitaler Zertifikate besitzen.
  • In einer beispielhaften Ausführungsform hat der Asset-Agent 400 eine Datenbank von VMEs, die nicht a priori mit sicheren Elementen verbunden sind (d. h. mit Client-Geräten verbunden sind, die sichere Elemente besitzen), usw. Wie nachstehend genauer beschrieben, kann ein VME entsprechend der Sicherheitsebene L2 durch den Asset-Agent mit einem sicheren Element verbunden sein. Die Sicherheitsebene L2 verhindert, dass VMEs „geklont” werden, wenn sie geliefert werden.
  • So fordert zum Beispiel in einer Umsetzung ein Client-Gerät eine Anzahl von „Anforderungen” an und wird mit diesen vorgeladen; jede Anforderung wird verwendet, um zu prüfen, ob die Anfrage gültig und aktuell ist (z. B. nicht von einer vorherigen Anfrage wiederholt). Konkret ist jede Anforderung eine Anforderung zur einmaligen Verwendung, die die einzig gültige Anforderung für ein sicheres Element des Client-Geräts ist, d. h. nach dem Verbrauchen der Anforderung ist nur die nächste Anforderung für das sichere Element zulässig. Da der Benutzer sich für verschiedene Konten anmeldet, wird ein VME vom Asse-Agent 400 bereitgestellt. Wenn das Client-Gerät einen Vorrat von Anforderungen erschöpft hat, kann der Benutzer das Client-Gerät anweisen, einen neuen Satz Anforderungen anzufordern. In einigen Varianten wird die Übertragung von VMEs über eine sichere Verbindung hergestellt, z. B. über einen Anschluss eines Service Kiosks, eines Personal Computers (PC), eines virtuellen privaten Netzwerks (VPN), usw.
  • In 5 ist ein beispielhafter Kontenserver 501 des Asset-Brokers 500 dargestellt. Der beispielhafte Kontenserver 501 beinhaltet: eine Netzwerkschnittstelle 502, ein Prozessor-Teilsystem 504, ein nicht-flüchtiges computerlesbares Medium (Speicher-Teilsystem) 506 und eine Kontendatenbank 508. Der hier verwendete Begriff „Asset Broker” beinhaltet unter anderem Systeme und Netzwerke, die konfiguriert sind, ein mit einem VME verbundenes Konto entsprechend zu belasten, zu kreditieren und/oder zu bestätigen. Die genannten Systeme können einen oder mehrere Kontenserver beinhalten, z. B. Kontenserver 501. Deshalb ist davon auszugehen, dass Verweise auf einen „Asset-Broker” ebenso auf einen oder mehrere Kontenserver eines Asset-Brokers oder umgekehrt verweisen können.
  • Das Prozessor-Teilsystem 504 kann einen oder mehrere digitale Signalprozessoren, Mikroprozessoren, feldprogrammierbare Gate-Arrays, oder eine Vielzahl von verarbeitenden Komponenten beinhalten, die auf einem oder mehreren Substraten angebracht sind. Das Prozessor-Teilsystem 504 kann ebenso einen internen Zwischenspeicher beinhalten. Das Prozessor-Teilsystem 504 kommuniziert mit dem Speicher-Teilsystem 506, wobei letzteres einen Speicher beinhaltet, der zum Beispiel SRAM-, Flash- und/oder SDRAM-Komponenten beinhalten kann. Das Speicher-Teilsystem 506 kann ein oder mehrere DMA-Hardware-Elemente beinhalten, um die Fachleuten bekannten Datenzugänge zu ermöglichen. Das Speicher-Teilsystem 506 der beispielhaften Ausführungsform enthält computer-ausführbare Anweisungen, die von dem Prozessor-Teilsystem 504 ausgeführt werden können.
  • In einer beispielhaften Ausführungsform beinhaltet der Kontenserver 501 eine Netzwerkschnittstelle 502, die für die Errichtung einer Netzwerkverbindung zu Client-Geräten und Händler-Geräten geeignet ist. Geläufige Beispiele einer Netzwerkschnittstelle beinhalten unter anderem: Ethernet, DSL, Kabel/Hybrid Fiber Coaxial, WLAN, drahtlose Stadtnetzwerke (WMAN), Mobilfunkdatenverbindungen, Millimeterwelle, usw.
  • In einigen Ausführungsformen kann der Kontenserver 501 verbundene kryptographische Geräteschlüssel besitzen. Diese Schlüssel können zum Sichern des Nachrichtenaustauschs verwendet werden. In einer solchen Variante sind die kryptographischen Schlüssel ein asymmetrisches öffentliches/privates Schlüsselpaar. In weiteren Varianten sind die kryptographischen Schlüssel ein symmetrisches Schlüsselpaar. In anderen Varianten kann der Kontenserver 501 kryptographische Schlüssel z. B. zum Prüfen und/oder Ausstellen digitaler Zertifikate besitzen.
  • In einer beispielhaften Ausführungsform ist der Kontenserver 501 konfiguriert, die VMEs für Kundenkonten zu authentifizieren und zuzulassen. Die VMEs sind vom Kontenserver 501 entsprechend der Sicherheitsebene L3 verbunden. Die Sicherheitsebene L3 prüft, ob der VME-Kombination des Kundenkontos authentisch und zugelassen (d. h. nicht betrügerisch oder missbraucht) ist.
  • In 6 ist ein beispielhaftes Asset-Schließfach 600 dargestellt. Das beispielhafte Asset-Schließfach kann beinhalten: eine Netzwerkschnittstelle 602, ein Prozessor-Teilsystem 604, ein nicht-flüchtiges computerlesbares Medium (Speicher-Teilsystem) 606 und eine sichere Datenbank 608. Der hier verwendete Begriff „Asset-Schließfach” beinhaltet unter anderem Geräte, die konfiguriert sind, VMEs zu speichern, zu verschlüsseln und zu generieren. Zum Beispiel kann das Asset-Schließfach 600 ein vertrauenswürdiges Sicherheitsmodul (TSM) sein.
  • Das Prozessor-Teilsystem 604 kann einen oder mehrere digitale Signalprozessoren, Mikroprozessoren, feldprogrammierbare Gate-Arrays, oder eine Vielzahl von verarbeitenden Komponenten beinhalten, die auf einem oder mehreren Substraten angebracht sind. Das Prozessor-Teilsystem 604 kann ebenso einen internen Zwischenspeicher beinhalten. Das Prozessor-Teilsystem 604 kommuniziert mit dem Speicher-Teilsystem 606, wobei letzteres einen Speicher beinhaltet, der zum Beispiel SRAM-, Flash- und/oder SDRAM-Komponenten beinhalten kann. Das Speicher-Teilsystem 606 kann ein oder mehrere DMA-Hardware-Elemente beinhalten, um die Fachleuten bekannten Datenzugänge zu ermöglichen. Das Speicher-Teilsystem 606 enthält computer-ausführbare Anweisungen, die vom Prozessor-Teilsystem 604 ausgeführt werden können, obwohl auch andere Arten computergestützter Logik (z. B. Kombinationen von Hardware und Software/Firmware) verwendet werden können.
  • In einer beispielhaften Ausführungsform beinhaltet das Asset-Schließfach 600 eine Netzwerkschnittstelle 602, die für die Errichtung einer Netzwerkverbindung zu einem oder mehreren Kontenservern geeignet ist. Geläufige Beispiele einer Netzwerkschnittstelle beinhalten unter anderem: Ethernet, DSL, Cable, Hybrid Fiber Coaxial, WLAN, Mobilfunk-Datenverbindungen, usw.
  • In einigen Ausführungsformen kann das Asset-Schließfach 600 verbundene kryptographische Schlüssel besitzen. Diese Schlüssel können zum Sichern des Nachrichtenaustauschs verwendet werden. In einer solchen Variante sind die kryptographischen Schlüssel ein asymmetrisches öffentliches/privates Schlüsselpaar. In weiteren Varianten sind die kryptographischen Schlüssel ein symmetrisches Schlüsselpaar. In anderen Varianten kann das Asset-Schließfach 600 kryptographische Schlüssel zum Prüfen und/oder Ausstellen digitaler Zertifikate besitzen.
  • Das Asset-Schließfach 600 ist ferner konfiguriert, eine oder mehrere VMEs bereitzustellen und/oder zu generieren. In einer beispielhaften Ausführungsform werden die VMEs in Übereinstimmung mit einer besonderen Norm (z. B. dem Standard X4.13-1983 des American National Standards Institute (ANSI) (hier als Referenz in seiner Gesamtheit eingefügt) generiert und in der sicheren Datenbank 608 gespeichert. Alternativ kann das VME entsprechend z. B. geschützten oder verwendungsspezifischen Formaten konstruiert sein. Fachleute werden die Fülle der möglichen Formate in Anbetracht der Inhalte dieser Offenbarung schätzen.
  • In einer beispielhaften Ausführungsform ist das Asset-Schließfach 600 konfiguriert, ein VME für ein sicheres Element eines Client-Geräts zu verschlüsseln. Das Asset-Schließfach 600 ermöglicht, dass jedes Asset gemäß Sicherheitsebene L1 nur im verschlüsselten Zustand übertragen wird. Die Sicherheitsebene L1 ermöglicht, dass ein VME nur im Klartext (unverschlüsselt) entweder im Asset-Schließfach 600 oder in einen sicheren Element eines Client-Geräts besteht.
  • In 7 ist eine Ausführungsform eines verallgemeinerten Verfahrens 700 für das Verteilen von VMEs innerhalb eines Systems offenbart. In Schritt 702 sind die Inhalte eines oder mehrerer VMEs gemäß einem ersten bewährten Standardverhältnis geschützt. In einer Ausführungsform ist das erste bewährte Verhältnis konfiguriert, die in dem VME enthaltenen vertraulichen Elemente und/oder kryptographischen Materialien (z. B. sichere Schlüssel, kryptographisches Material, Benutzerhistorie, usw.) zu schützen. Zum Beispiel basiert das erste bewährte Verhältnis auf einem Sicherheitsmodul (in der Hardware oder Software eingebaut), das konfiguriert ist, VMEs nach einmaligen Geräteschlüsseln und Bestätigungsbescheinigungen zu verschlüsseln oder zu entschlüsseln. Insbesondere ist das Sicherheitsmodul konfiguriert, VMEs für die Lieferung an ein gewünschtes Bestimmungsgerät (z. B. ein Client-Gerät oder Händler-Gerät), das dem ersten bewährten Verhältnis entspricht, zu verschlüsseln oder die Zugriffskontrolle, die Clients von einem Quellgerät empfangen haben, das dem ersten bewährten Verhältnis entspricht, zu entschlüsseln. In einer beispielhaften Ausführungsform müssen alle VMEs bei der Übertragung zwischen Geräten verschlüsselt sein (d. h. VMEs können nicht in einer unverschlüsselten Form auf ein anderes Gerät übertragen werden). Jedes Gerät auf der Ebene des ersten bewährten Verhältnisses erhält einmalige Geräteschlüssel und Bestätigungsbescheinigungen, die zum sicheren Übertragen von VMEs genutzt werden können.
  • Verschiedene Umsetzungen des ersten bewährten Standardverhältnisses können auch physisch und/oder logisch geschützt werden. Zum Beispiel kann das erste bewährte Standardverhältnis den Schutz innerhalb eines Hardware-Sicherheitsmoduls (HSM) beinhalten, das konfiguriert ist, sich selbst zu zerstören, wenn es gewaltsam geöffnet/darauf zugegriffen wird. Generell schützt die beispielhafte Ausführungsform des ersten bewährten Standardverhältnisses eine vertrauenswürdige Grenze minimal. Geläufige Beispiele einer vertrauenswürdigen Grenze beinhalten sowohl physische Grenzen (z. B. physische Isolierung, usw.) und/oder logische Grenzen (z. B. verschlüsselte Kommunikation, usw.).
  • In Schritt 704 ist die Anzahl der Kopien eines VME gemäß einem zweiten bewährten Standardverhältnis kontrolliert. In einer beispielhaften Ausführungsform ist das zweite bewährte Standardverhältnis konfiguriert, zufälliges und/oder betrügerisches Klonen eines VME zu verhindern (Erhaltungserzwingung). Das zweite bewährte Standardverhältnis kann zum Beispiel von einem Sicherheitsmodul verwaltet werden, das konfiguriert ist, ein VME für sich selbst oder ein anderes Gerät zu verschlüsseln. Ähnlich kann das Sicherheitsmodul ein VME so verschlüsseln, dass es nur durch ein anderes spezifisches Gerät entschlüsselt werden kann (zum Beispiel auf Basis eines asymmetrischen kryptographischen Schlüssels). In einigen Ausführungsformen kann das Verschlüsselungssystem des Sicherheitsmoduls auf einem asymmetrischen Schlüsselpaar beruhen; oder alternativ kann das Verschlüsselungssystem des Sicherheitsmoduls ein symmetrisches Schlüsselpaar verwenden.
  • Wie zuvor angemerkt, basiert ein öffentliches/privates Schlüsselpaar auf einem geheimen privaten Schlüssel und einem publizierbaren öffentlichen Schlüssel. Öffentliche/private Schlüsselsysteme werden als „asymmetrisch” erachtet, da der Schlüssel zum Verschlüsseln und Entschlüsseln nicht der gleiche ist und somit verwenden der Verschlüsseler und der Entschlüsseler nicht den gleichen Schlüssel. Im Gegensatz dazu verwenden „symmetrische” Schlüsselsysteme den gleichen Schlüssel (oder geringfügig veränderte Schlüssel) für die Verschlüsselung und die Entschlüsselung. Der RSA-Algorithmus ist eine Art der öffentlichen/privaten Schlüsselpaar-Kryptographie, die häufig in diesem Fachbereich verwendet wird, allerdings ist davon auszugehen, dass die hier beschriebenen Ausführungsformen auf keinen Fall auf den RSA-Algorithmus beschränkt sind (oder diesbezüglich auf asymmetrische oder symmetrische Schlüsselpaare).
  • Öffentliche/private Kryptographiesysteme können zum Verschlüsseln einer Nachricht und/oder zum Generieren von Unterschriften verwendet werden. Insbesondere kann eine Nachricht mit einem privaten Schlüssel verschlüsselt und mit dem öffentlichen Schlüssel entschlüsselt werden, wodurch sichergestellt ist, dass die Nachricht bei der Übertragung nicht verändert wurde. Ähnlich kann eine mit dem privaten Schlüssel generierte Unterschrift mit dem öffentlichen Schlüssel geprüft werden, wodurch sichergestellt ist, dass die die Unterschrift generierende Einheit rechtmäßig ist. In beiden Verwendungen bleibt der private Schlüssel unsichtbar, und der öffentliche Schlüssel wird frei verteilt.
  • In Schritt 706 wird das VME für die Verwendung gemäß einem dritten bewährten Verhältnis an Bestimmungsgeräte verteilt. Das dritte bewährte Verhältnis erfordert die Authentifizierung und die Zulassung der Einheit. Das dritte bewährte Verhältnis stellt unmittelbar sicher, dass ein VME nur an eine Einheit übertragen wird, die dessen Identität bestätigen kann und die für das VME berechtigt ist.
  • Aufgrund der Flexibilität der Verteilermodelle sind viele unterschiedliche Systeme vorhergesehen und werden von Fachleuten erkannt, wenn sie in dieser Offenbarung vorgestellt werden. Einige VME-Verteilersysteme, die die breite Vielfalt der Systeme veranschaulichen, die in Übereinstimmung mit verschiedenen Aspekten dieser Offenbarung für den Einsatz geeignet sind, sind nachstehend detaillierter offengelegt.
  • In 8 ist ein logischer Kontaktplan, der eine beispielhafte Ausführungsform einer Bereitstellungstransaktion darstellt, veranschaulicht. Die Bereitstellungstransaktion kann von einem Client-Gerät, einem Asset-Broker, einem Asset-Agent und einem Asset-Schließfach ausgeführt werden. Das Client-Gerät beinhaltet ein sicheres Element (SE) und einen Anwendungsprozessor (AP) (z. B. Prozessor-Teilsystem 304). Das SE kann Software speichern, die einen sogenannten „Stapelspeicher” von Software-Ebenen beinhaltet, der Transaktionen in Übereinstimmung mit dieser Offenbarung ermöglicht. Jede Software-Ebene ist für einen Satz hierarchischer Funktionen verantwortlich, die mit der zugehörigen Peer-Software-Ebene ausgehandelt werden. Ferner wird anerkannt, dass der AP in einigen Fälle gefährdet (z. B. „geknackt” usw.) werden kann; dementsprechend bestehen die bewährten Verhältnisse nur zwischen dem SE und der zugehörigen logischen Ebenen-Einheit; d. h. der AP ist nicht vertrauenswürdig.
  • Das Sicherheits-Softwareprotokoll beinhaltet eine Ebene L1, eine Ebene L2 und eine Ebene L3. Die L1-Sicherheit führt die Verschlüsselung und Entschlüsselung von VME-Daten aus. L1-Operationen sind auf die Sicherung von Ausführungsumgebungen beschränkt (z. B. ein SE oder TSM). Innerhalb von L1 können die Daten in Klartext (d. h. unverschlüsselt) innerhalb der logischen L1-Grenze gespeichert werden; außerhalb der logischen L1-Grenze werden die VME-Daten sicher verschlüsselt. Die L2-Sicherheit verhindert, dass VME-Daten vervielfältigt werden. Die L2-Grenze stellt sicher, dass eine und nur eine Kopie eines VME außerhalb der L2-Grenze existiert. Innerhalb der L2-Grenze können zahlreiche Kopien existieren. Zudem kann die L2-Sicherheit ferner eine Anforderung in die verschlüsselten VME-Daten einbetten. Vor dem Einbau eines VME kann ein Client-Gerät die in dem VME eingebettete Anforderung mit einer Anforderung vergleichen, die auf dem Client-Gerät gespeichert ist, um zu prüfen, ob das VME nicht abgelaufen ist (d. h. das VME ist das aktuelle und einzige VME). Die L3-Sicherheit ist für die Errichtung des Vertrauens, des Eigentums und der Prüfung des Kunden, der das VME besitzt, verantwortlich. Für jedes VME kann das SE Informationen zur Anzeige des Eigentums in Verbindung mit dem VME speichern.
  • In einer beispielhaften Ausführungsform ist das Asset-Schließfach ein TSM, das konfiguriert ist, die Datenkomponenten des VME zu generieren und die VMEs in Massenlosen zu speichern. Das Asset-Schließfach führt VME-Operationen in Übereinstimmung mit der L1-Sicherheit aus und stellt sicher, dass nur verschlüsselte VMEs übertragen werden (d. h. VMEs werden nicht in unverschlüsselter Form außerhalb des Asset-Schließfachs übertragen). Um einem Kunden ein VME bereitzustellen, empfängt der Asset-Agent verschlüsselte VMEs vom Asset-Schließfach und speichert die den Client-Geräten bereitzustellenden VMEs nach Bedarf. Der Asset-Agent führt VME-Operationen in Übereinstimmung mit der L2-Sicherheit aus und stellt sicher, dass einem Client-Gerät nur eine Kopie des verschlüsselten VME bereitgestellt wird. Zuletzt führt die beispielhafte Ausführungsform des Asset Brokers VME-Operationen in Übereinstimmung mit der L3-Sicherheit aus und ermöglicht, dass die Übertragung der verschlüsselten VMEs nur an Client-Geräte mit SE erfolgt, die authentifiziert und berechtigt sind. Nachdem ein VME an das Client-Gerät geliefert wurde, kann der Asset-Broker das VME mit einem Konto verbinden, das mit dem Client-Gerät verbunden ist und/oder einem Konto, dass mit einem Benutzer des Client-Geräts verbunden ist.
  • In einer Ausführungsform fordert eine im Client-Gerät gespeicherte Software-Anwendung, dass eine neue Virtuelle Kreditkarte (VKK) einem Konto eines Benutzers zum Gebrauch bereitgestellt wird. Die Software-Anwendung wird mit dem AP ausgeführt. In 802 fordert der AP Informationen vom SE, die das Client-Gerät oder das SE eindeutig identifizieren. Zum Beispiel können die Informationen einen Geräte-Identifikator beinhalten. Der AP überträgt den Geräte-Identifikator in einer Anfrage für eine neue VKK an den Asset-Broker in 804. Der Asset-Broker authentifiziert die Anfrage zur Bereitstellung der VKK an das Konto des Benutzers. Die Authentifizierung basiert auf dem Geräte-Identifikator. In einem Aspekt der Ausführungsform authentifiziert der Asset-Broker die Anfrage durch Feststellen, ob das SE/Client-Gerät mit dem Benutzerkonto verbunden ist.
  • Das SE kann den Geräte-Identifikator mit einer digitalen Unterschrift verschlüsseln, so dass der Geräte-Identifikator sicher vom Client-Gerät auf den Asset-Broker übertragen wird. Nachdem der Asset-Broker die neue VKK authentifiziert/zugelassen hat, leitet der Asset-Broker die digitale Unterschrift des SE an den Asset-Agent weiter. Der Asset Agent prüft die digitale Unterschrift des SE, wodurch das Bestimmungs-SE für die VKK in 806 eindeutig identifiziert wird. In 807 werden dem Client-Gerät zusätzliche VKK-Optionen bereitgestellt.
  • Nebenbei bemerkt sind sogenannte „Anforderungen” ein entscheidendes Mittel, das zur Verbindung eines spezifischen VME mit einem SE verwendet wird. Insbesondere erhält jedes SE eine bestimmte Anzahl von Anforderungen, um die L2-Sicherheit zu erhalten. Durch Prüfen, ob eine Anforderung gültig ist, kann das SE sicher sein, dass das VME kein „abgelaufenes” VME ist (d. h. eine ungültige oder nicht nutzbare Kopie). Das SE löscht eine Anforderung, wenn ein VME mit den zugehörigen Anforderungsdaten empfangen wird. Für die folgende Umsetzung erstellt (oder erhält) ein SE eine Anzahl von Anforderungen, die es mit dem Asset-Agent teilt. Anschließend kann der Asset-Agent die aktuelle Anforderung in ein VME, das für das SE bereitgestellt wurde, einbetten. Wenn das SE ein VME empfängt, kann das SE prüfen, ob das erhaltene VME die angemessene Anforderung enthält und nicht abgelaufen ist.
  • Ein mögliches Manko des vorgenannten Systems ist, dass eine festgelegte Anzahl von Anforderungen leicht mit einem Angriff auf Dienstleistungsverhinderung (DOS) gefährdet werden kann. In einem DOS-Angriff wird ein SE fortlaufend veranlasst, Anforderungen zu generieren, bis all seine Anforderungsressourcen erschöpft sind. Zu diesem Zweck führt die beispielhafte Ausführungsform des SE vor dem Verarbeiten von Anfragen, die das SE veranlassen würden, eine Anforderungen zu verbrauchen, zusätzlich einen Session-Handshake mit dem Asset Broker/Asset-Agent aus. Zudem kann das SE im unwahrscheinlichen Falle, dass die Mittel erschöpft sind und das SE nicht in der Lage ist, neue Anforderungen zu generieren, einen separaten Satz an vorbehaltenen Anforderungen speichern, der speziell für die Freigabe eines weiteren Satzes von Anforderungen bestimmt ist. In einigen Fällen kann das SE auch eine Referenz für einen Original Equipment Manufacturer (OEM) beinhalten, die der OEM verwenden kann, um die Anforderungsoperation weiterhin zu steuern.
  • In 808 fordert der AP, dass das SE eine Anforderungen für die Verbindung mit der VKK bereitstellt. Nach der Bereitstellung durch das SE wird die Anforderung in 810 an den Asset-Broker gesendet und dann in 812 dem Asset-Agent weitergeleitet. Der Asset Agent prüft die Anforderung und stellt dann in 814 dem Asset-Schließfach die Personalisierungsinformationen bereit. Das Asset-Schließfach personalisiert eine neue VKK für das SE und stellt dem Asset-Broker in 816 einen verbundenen VKK-Identifikator bereit. Dann stellt der Asset-Broker dem AP in 817 den VKK-Identifikator bereit. Wenn der AP den VKK-Identifikator empfängt, kann der AP die Lieferung der VKK in 818 anfordern. Anschließend kann der Asset-Broker in 820 dem SE des Client-Geräts die VKK bereitstellen.
  • Fachleute der Netzwerktechnik werden erkennen, dass während des Betriebs von großflächigen Verteilernetzwerken zahlreiche praktische Fragen aufkommen. Insbesondere müssen großflächige Verteilernetzwerke skalierbar sein, um große Datenverkehrs-Bursts verarbeiten zu können (dies kann an dem so genannten „Einführungstag” eines Client-Geräts geschehen). Ein System zur Reduzierung des gesamten Netzwerkverkehrs beinhaltet die verzögerte Lieferung von VMEs (wenn möglich).
  • In 9A und 9B ist eine Ausführungsform eines verallgemeinerten Verfahrens 900 für das Verteilen von VMEs innerhalb eines Systems offenbart. Während einer vor-personalisierten Operation wird ein sogenanntes „vor-personalisiertes” Client-Gerät mit einem SE einem VME vor dem Versand zugeordnet (z. B. wenn ein Benutzer ein Gerät in einem Geschäft kauft, das Gerät Online bestellt, usw.) Bevor das Client-Gerät an den Benutzer geliefert wird, wird in 902 ein Aufkleber, Etikett oder ein sonstiger Vermerk, der auf einem Behältnis angebracht ist, das mit dem Client-Gerät verbunden ist, gescannt. Zum Beispiel kann das Behältnis die Einzelhandelsverpackung sein, in der das Client-Gerät eingeschlossen ist. Dieser Aufkleber enthält Informationen (z. B. einen Geräte-Identifikator), die das Client-Gerät eindeutig identifizieren und die mit dem VME verbunden sein können. Das VME kann für das Client-Gerät vorkonfiguriert sein, zum Beispiel durch (i) Verschlüsseln des VME mit dem SE eigenen Schlüssel (L1) (vom Aufkleber festgelegt) in 904, (ii) Einbetten einer angegebenen ersten Anforderung im VME (L2) in 906, und (iii) Verbinden des VME mit den Authentifizierungs-/Zulassungsinformationen des Benutzers (L3) (zum Zeitpunkt des Kaufs festgelegt) in 908. Das VME wird dann einem Identifikator zugeordnet, der das VME in 910 eindeutig identifiziert, z. B. ein VME-Identifikator. Danach kann das Client-Gerät das VME mithilfe des VME-Identifikators in 912 anfordern. In 914 kann das VME nach dem Erhalten der Anfrage und des VME-Identifikators in seinem vollständig konfigurierten Zustand an das Client-Gerät geliefert werden.
  • Das vorhergehende System vor-konfiguriert ein VME wirksam auf der Basis von Informationen, die es vom Client-Gerät (und/oder einem mit dem Client-Gerät verbundenen Behältnis) und aus Informationen vom Benutzer zum Zeitpunkt des Kaufs erhalten hat. Das VME wird konfiguriert, während das Gerät nach besten Bemühungen übertragen wird (z. B. versendet, nach Hause mitgenommen, usw.) (d. h. die Konfigurierung erfolgt, wenn die Ressourcen verfügbar sind). Danach kann das VME nahtlos von einem Zwischenspeicher in das Client-Gerät geladen werden, ohne Echtzeit-Datenverkehr zu erfordern. Um die Systemzuverlässigkeit zu steigern, kann das vorkonfigurierte VME auch an zahlreichen geographischen Orten redundant zwischengespeichert werden; d. h. wo zahlreiche Datenzentren an verschiedenen geographischen Orten Kopien der VMEs besitzen (die L2-Sicherheit stellt ein erstes Anforderungssystem bereit, so dass die Duplikate nach dem Abrufen der ersten Kopie des VME abgelaufen sind).
  • Genauer gesagt, wird die beispielhafte Ausführungsform des Client-Geräts anders als herkömmliche Herstellungssysteme nicht mit einem VME hergestellt und vorprogrammiert. Die Konfiguration und Lieferung des VME kann „zurückgestellt” werden, bis das Client-Gerät hergestellt und/oder eingesetzt wurde. Zum Beispiel kann das Client-Gerät über generische Software verfügen, die später, nachdem der Benutzer ein Konto aktiviert hat, mit einem ausgewählten VME konfiguriert werden kann, wenn mehrere VMEs vom Client-Gerät unterstützt werden können. In einigen Umsetzungen kann die generische Software ein generisches oder vorgegebenes VME beinhalten. Wenn ein Benutzer ein Client-Gerät kauft, kann es dem Benutzer in dieser Umsetzung erlaubt sein (oder von ihm gefordert werden), ein Kreditkartenkonto (oder ähnliches) für die Verwendung mit dem vorgegebenen VME bereitzustellen. Nachdem das Client-Gerät aktiviert wurde, wird das vorgegebene VME dann automatisch als Bestandteil des Aktivierungsablaufs geladen.
  • In 10A und 10B ist eine weitere Ausführungsform eines verallgemeinerten Verfahrens 1000 für das Verteilen von VMEs innerhalb eines Systems offenbart. In dieser Variante wird ein Client-Gerät mit einem SE einem VME aus einem Pool von VMEs in 1002 beim Versand (d. h. wenn ein Benutzer ein Gerät in einem Geschäft kauft, das Gerät Online bestellt, usw.) zugeordnet; d. h. ein spezifisches VME ist nicht mit dem Client-Gerät verbunden. Zu diesem Zeitpunkt kann der Benutzer die Informationen zur Authentifizierung/Zulassung in 1004 bereitstellen. Nachdem das Client-Gerät in 1006 dem Benutzer geliefert wurde, werden die das Client-Gerät eindeutig identifizierenden Informationen eingegeben, z. B. vom Händler des Verkaufsorts, dem Benutzer zu Hause, usw. Die Informationen können von einem Aufkleber, Etikett oder sonstigen Vermerken, die auf einem mit dem Client-Gerät verbundenen Behältnis angebracht sind, abgelesen werden. Die Informationen können ebenso angeben, dass ein VME für das Client-Gerät zugewiesen sein sollte, dass jedoch noch keines zugeordnet wurde. Als Reaktion auf das Erhalten der Informationen in 1008 koordinieren der Asset Broker, der Asset-Agent und der Asset-Broker, ein verfügbares VME zuzuordnen durch: Verschlüsseln des VME mit einem SE-spezifischen Schlüssel (L1) (vom Aufkleber festgelegt) in 1010, Einbetten der Anforderungsdaten im VME (L2) in 1012 und Verbinden des VME mit den Informationen des Benutzers zur Authentifizierung/Zulassung (L3) (zum Zeitpunkt des Kaufs festgelegt) in 1014. In 1016 wird das neu erstellte und verschlüsselte VME in seinem vollständig konfigurierten Zustand an das Client-Gerät geliefert.
  • Das vorhergehende System konfiguriert ein VME wirksam nach Bedarf. Diese Umsetzungen erlauben es dem Asset-Broker und/oder Asset-Agent, einen Pool von VMEs intelligent zu verwalten. Da jedes VME im Pool von VMEs nicht einem spezifischen Client-Gerät zugeordnet ist (d. h. für eine spezifische Verwendung bestimmt ist) und nach Bedarf zugeordnet wird, müssen der Asset-Broker und/oder der Asset-Agent den Bestand nicht nachverfolgen, der noch nicht aktiv ist (z. B. können einige Geräte gekauft und vor dem Aktivieren zurückgegeben werden, dies mindert den unnötigen „Verlust” von VMEs). Dies kann in Fällen nützlich sein, wenn ein VME eine begrenzte Ressource ist. Fachleute werden es schätzen, dass eine Kontonummer eine begrenzte Ressource ist (und somit wertvoll in ihrer Knappheit); zum Beispiel ist der ANSI-Standard X4.13-1983 (zuvor hier als Referenz in seiner Gesamtheit angegeben) ein Konten-Nummerierungssystem, das von den meisten staatlichen Kreditkartensystemen verwendet wird. Entsprechend dem ANSI-Standard X4.13-1983 von sechzehn (16) Ziffern einer Kreditkartennummer stellt nur eine Teilgruppe dieser eine tatsächliche Kontonummer dar (z. B. können acht (8) Ziffern nur verwendet werden, um bis zu 10 Millionen eindeutiger Kontonummern zu bilden); die anderen Ziffern sind anderen Verwendungen vorbehalten (z. B. Identifizieren des Kartenausstellers, Bereitstellen eines „Prüf”-Wertes, Identifizieren einer Kartennummer, usw.)
  • In 11 ist eine weitere Ausführungsform eines verallgemeinerten Verfahrens 1100 für das Verteilen von VMEs innerhalb eines Systems offenbart. In dieser Ausführungsform kann die Konfiguration eines VME vollständig zurückgestellt werden, bis eine erste Transaktion stattgefunden hat. Diese Ausführungsform kann in Fällen nützlich sein, in denen mehrere Transaktionen (z. B. periodische Transaktionen) zwischen einem System und einem Client-Gerät stattfinden. Zum Beispiel kann ein Benutzer sich entscheiden, z. B. einen mehrfachen Filmpass, monatlichen Busausweis, usw. zu kaufen, In 1102 stellt ein Benutzer dem System Zahlungsinformationen bereit, z. B. Kreditkarteninformationen. In 1104 werden dem System Informationen zum Identifizieren eines Client-Geräts, z. B. ein Geräte-Identifikator, bereitgestellt. Der Geräte-Identifikator kann in Übereinstimmung mit einer der vorgenannten Ausführungsformen bereitgestellt werden (z. B. Prozess der „Vorpersonalisierung”, Eingabe durch einen Benutzer, bereitgestellt durch einen AP, usw.) Eine erste Transaktion kann normal in 1106 durchgeführt werden. Zwischenzeitlich wird ein VME für das Client-Gerät mithilfe des Geräte-Identifikators, bereitgestellten Zahlungsinformationen und/oder Anforderungsdaten konfiguriert; nachdem das VME in 1108 konfiguriert wurde, wird es für weitere Verwendungen in 1110 an das Client-Gerät geliefert. In einigen Fällen kann die Lieferung bei Bereitschaft auf einer Push-Benachrichtigung, automatischem Download oder manuellem Download beruhen.
  • In 12 ist eine weitere Ausführungsform eines verallgemeinerten Verfahrens 1200 für das Verteilen von VMEs innerhalb eines Systems offenbart. Das Verfahren 1200 kann mit einem Asset Broker, der mit einem Client-Gerät, das ein SE, einen Asset-Agent und ein Asset-Schließfach besitzt, kommuniziert, durchgeführt werden. In 1202 empfängt der Asset-Broker vom Client-Gerät eine Anfrage zur Bereitstellung eines VME zum Gebrauch an ein Konto eines Benutzers. Das Konto kann mit einem Benutzer des Client-Geräts verbunden sein (d. h. das Konto ist Eigentum des Benutzers). Die Anfrage kann Identitätsinformationen beinhalten, die eindeutig mit dem Client-Gerät verbunden sind, z. B. ein Geräte-Identifikator. In einem Aspekt der Ausführungsform kann die Anfrage ebenso das Senden von Informationen, die das Konto identifizieren, beinhalten. Dann authentifiziert der Asset-Broker die Anfrage in 1204. Der Asset-Broker kann die Anfrage durch Prüfen, ob das vom Client-Identifikator identifizierte Client-Gerät mit dem Konto verbunden ist, authentifizieren. Der Asset-Broker koordiniert dann mit dem Asset-Agent und dem Asset-Schließfach die Bereitstellung eines VME für das Konto und konfiguriert das VME für ein Client-Gerät in Übereinstimmung mit den hier beschriebenen Ausführungsformen. In 1206 empfängt der Asset-Broker einen VME-Identifikator von einem Asset-Schließfach. Der VME-Identifikator identifiziert das VME, das für das Client-Gerät konfiguriert ist. Dann kann der Asset-Broker den VME-Identifikator in 1208 an das Client-Gerät senden. Das Client-Gerät kann den VME-Identifikator speichern und anschließend den VME-Identifikator verwenden, wenn er das konfigurierte VME vom Asset-Broker anfordert. Bei Erhalt einer Anfrage für das VME vom Client-Gerät in 1210 kann der Asset-Broker das konfigurierte VME in 1212 an das Client-Gerät senden.
  • In 13A–C ist eine weitere Ausführungsform eines verallgemeinerten Verfahrens 1300 für das Verteilen von VMEs innerhalb eines Systems offenbart. Das Verfahren 1300 kann von einem Client-Gerät, das mit einem Bereitstellungssystem kommuniziert, das einen Asset-Agent, einen Asset-Broker und/oder ein Asset-Schließfach beinhalten kann, durchgeführt werden. Das Client-Gerät kann ein SE und einen AP beinhalten. Es ist zu beachten, dass nachfolgend das Verfahren 1300, das zwischen einem Client-Gerät und einem Asset-Broker durchgeführt wird, aus Gründen der Klarheit und der Präzision beschrieben ist. Dabei ist davon auszugehen, dass die Schritte des Verfahrens 1300 auch zwischen dem Client-Gerät und einer oder mehreren Einheiten des Bereitstellungssystems durchgeführt werden können (z. B. ein Asset-Agent, Asset Broker).
  • In 1302 empfängt das Client-Gerät eine Information, die den Wunsch angibt, dass ein VME einem Konto eines Benutzers zum Gebrauch bereitgestellt werde. Die Information kann vom Benutzer mit einer I/O-Schnittstelle am Client-Gerät (z. B. einer Taste, Tastatur, Touchscreen, Sprachsteuerung, usw.) eingegeben werden. In 1304 kann das Client-Gerät Identitätsinformationen vom SE anfragen. Die Identitätsinformationen sind eindeutig mit dem Client-Gerät verbunden, z. B. ein Geräte-Identifikator. Die Identitätsinformationen können vom SE erhalten werden. In einer alternativen Ausführungsform können die Identitätsinformationen von einer Quelle erhalten werden, die sich außerhalb des Client-Geräts befindet. Zum Beispiel kann der Benutzer die Identitätsinformationen von einem Aufkleber auf einem Behältnis des Client-Geräts erhalten und die Identitätsinformationen mithilfe einer I/O-Vorrichtung des Client-Geräts eingeben.
  • Nach dem Erhalten eines Geräte-Identifikators vom SE kann das Client-Gerät in 1306 eine Anfrage zur Bereitstellung eines VME an einen Asset-Broker senden. Zusätzlich zur Anfrage sendet das Client-Gerät in 1308 auch den Geräte-Identifikator an den Asset Broker. In 1310 empfängt das Client-Gerät eine Anfrage für eine Anforderung vom Asset Broker. Die Anforderung kann verwendet werden, um VMEs in Übereinstimmung mit der hier beschriebenen L2-Sicherheit zu prüfen. Als Reaktion auf das Erhalten der Anfrage vom Asset-Broker kann der AP in 1312 eine Anforderung vom SE anfordern. Nach dem Erhalten einer Anforderung vom SE sendet das Client-Gerät die Anforderung in 1314 an den Asset Broker. Das Bereitstellungssystem kann die Anfrage authentifizieren und ein VME für das Client-Gerät konfigurieren. Dann kann das Client-Gerät in 1316 einen VME-Identifikator vom Asset-Broker empfangen. Der VME-Identifikator kann das VME, das für das Client-Gerät konfiguriert ist, eindeutig identifizieren. Anschließend kann das Client-Gerät in 1318 eine Anfrage für das konfigurierte VME an den Asset-Broker senden. Zusätzlich zur Anfrage sendet das Client-Gerät in 1320 den VME-Identifikator. Als Reaktion auf das Erhalten der Anfrage und des VME-Identifikators kann der Asset-Broker das konfigurierte VME in 1322 an das Client-Gerät senden. Das SE kann prüfen, ob das empfangene VME gültig ist (d. h. das empfangene VME ist nicht abgelaufen), indem in 1324 geprüft wird, ob das empfangene VME mit gültigen Anforderungsdaten eingebettet ist.
  • Auch wenn bestimmte Funktionen als ein bestimmter Ablauf von Schritten eines Verfahrens beschrieben sind, ist davon auszugehen, dass diese Beschreibungen nur veranschaulichend für die hier offenbarten, umfassenderen Verfahren stehen und wie von der besonderen Anwendung gefordert, verändert werden können. Einige Schritte können unter gewissen Umständen überflüssig oder optional gemacht werden. Zudem können gewisse Schritte oder Funktionen den offenbarten Ausführungsformen hinzugefügt oder die Reihenfolge der Ausführung zweier oder mehrerer Schritte vertauscht werden. Alle diese Variationen werden als in der Offenbarung umfasst erachtet und hier beansprucht.
  • Ferner können die verschiedenen Aspekte, Ausführungsformen, Umsetzungen oder Merkmale der beschriebenen Ausführungsformen separat oder in jeder Kombination verwendet werden. Verschiedene Aspekte der beschriebenen Ausführungsformen können durch Software, Hardware oder eine Kombination aus Hardware und Software implementiert werden. Die beschriebenen Ausführungsformen können auch als computerlesbarer Code auf einem computerlesbaren Medium enthalten sein. Das computerlesbare Medium ist eine beliebige Datenspeichervorrichtung, die Daten speichern kann, welche danach durch ein Computersystem gelesen werden können. Beispiele des computerlesbaren Mediums schließen Nur-Lese-Speicher, Speicher mit wahlfreiem Zugriff, CD-ROMs, HDDs, DVDs, Magnetband und optische Datenspeichervorrichtungen ein. Das computerlesbare Medium kann auch über netzwerkgekoppelte Computersysteme verteilt werden, so dass der computerlesbare Code auf eine verteilte Weise gespeichert und ausgeführt wird.
  • Die vorgehende Beschreibung verwendete zum Zwecke der Erklärung eine bestimmte Nomenklatur, um ein durchgängiges Verständnis der beschriebenen Ausführungsformen zur Verfügung zu stellen. Jedoch wird es von Fachleuten verstanden werden, dass die bestimmten Details nicht benötigt werden, um die beschriebenen Ausführungsformen auszuführen. Damit sind die vorhergehenden Beschreibungen der spezifischen Ausführungsformen zum Zwecke der bildlichen Darstellung und Beschreibung vorgestellt. Sie zielen nicht darauf ab, umfassend zu sein oder die Ausführungsformen auf die präzisen offenbarten Formen zu begrenzen. Es wird dem Fachmann ersichtlich sein, dass viele Modifikationen und Variationen im Lichte der obigen Lehre möglich sind.

Claims (35)

  1. Verfahren für einen Asset-Broker, umfassend einen oder mehrere Kontenserver zur Verteilung eines Assets an ein Client-Gerät, das ein sicheres Element beinhaltet, wobei das Verfahren für den Asset-Broker mindestens umfasst: Erhalten seitens des Client-Geräts (i) einer Anfrage zur Bereitstellung des Assets an ein Konto und (ii) eines Geräte-Identifikators, der das Client-Gerät eindeutig identifiziert; Authentifizieren der Anfrage zur Bereitstellung des Assets an das Konto; Erhalten eines Asset-Identifikators von einem Asset-Schließfach, wobei der Asset-Identifikator das Asset, das dem Client-Gerät zugeordnet ist, eindeutig identifiziert; Senden des Asset-Identifikators an das Client-Gerät; Erhalten einer Anfrage für das zugeordnete Asset vom Client-Gerät; Erhalten des Asset-Identifikators vom Client-Gerät; und Senden des zugeordneten Assets an das Client-Gerät.
  2. Verfahren nach Anspruch 1, welches für den Asset-Broker ferner Folgendes umfasst: vor dem Erhalten des Asset-Identifikators vom Asset-Schließfach: Erhalten vom Client-Gerät einer digitalen Unterschrift, die mit dem Geräte-Identifikator assoziiert ist; und Senden der digitalen Unterschrift an einen Asset-Agent, wobei die gesendete digitale Unterschrift vom Asset-Agent geprüft wird.
  3. Verfahren nach Anspruch 2, welches für den Asset-Broker ferner Folgendes umfasst: nach dem Senden der digitalen Unterschrift an den Asset-Agent: Erhalten einer Anforderung vom Client-Gerät, wobei die Anforderung von dem sicheren Element erzeugt wurde; und Senden der Anforderung an den Asset-Agent, wobei die gesendete Anforderung vom Asset-Agent geprüft wird.
  4. Verfahren nach Anspruch 1, wobei das Authentifizieren der Anfrage zur Bereitstellung des Assets an das Konto das Prüfen umfasst, ob der Geräte-Identifikator mit dem Konto assoziiert ist.
  5. Verfahren nach Anspruch 1, welches für den Asset-Broker ferner Folgendes umfasst: Assoziieren des zugeordneten Assets mit dem Client-Gerät oder dem Geräte-Identifikator.
  6. Verfahren nach Anspruch 1, welches für den Asset-Broker ferner Folgendes umfasst: nach dem Senden des zugeordneten Assets an das Client-Gerät, Belasten des Kontos aufgrund eines Wertes des zugeordneten Assets.
  7. Verfahren nach Anspruch 1, wobei das Asset eine Kreditkartennummer umfasst.
  8. Verfahren nach Anspruch 1, wobei das Senden des zugeordneten Assets an das Client-Gerät das Senden des zugeordneten Assets an das sichere Element umfasst.
  9. Verfahren nach Anspruch 3, wobei das zugeordnete Asset Anforderungsdaten beinhaltet, die auf der vom Client-Gerät erhaltenen Anforderung beruhen.
  10. Verfahren nach Anspruch 1, welches für den Asset-Broker ferner Folgendes umfasst: vor dem Erhalten der Anfrage zur Bereitstellung des Assets an das Konto, Erhalten von Konteninformationen, die das Benutzerkonto identifizieren, vom Client-Gerät.
  11. Verfahren nach Anspruch 10, wobei das Erhalten der Konteninformationen vom Benutzer erfolgt, wenn der Benutzer das Client-Gerät kauft.
  12. Verfahren nach Anspruch 1, welches für den Asset-Broker ferner Folgendes umfasst: Speichern des zugeordneten Assets an einem ersten geographischen Ort und an einem zweiten geographischen Ort, der von dem ersten geographischen Ort getrennt ist.
  13. Verfahren nach Anspruch 12, wobei das Senden des zugeordneten Assets an das Client-Gerät das Senden des zugeordneten Assets von dem ersten geographischen Ort oder von dem zweiten geographischen Ort beinhaltet, und wobei das Client-Gerät konfiguriert ist, das gesendete zugeordnete Asset aufgrund der im gesendeten zugeordneten Asset eingebetteten Anforderungsdaten zu prüfen.
  14. Verfahren für eine oder mehrere Vorrichtungen, ein Asset an ein Client-Gerät zu verteilen, das ein sicheres Element beinhaltet, wobei jede Vorrichtung einen Speicher und einen Prozessor umfasst, wobei das Verfahren für die eine oder mehreren Vorrichtungen mindestens umfasst: vorkonfigurieren des Assets durch Verschlüsseln des Assets mit einem einmaligen Schlüssel, der auf einem Geräte-Identifikator beruht, der das Client-Gerät eindeutig identifiziert und durch Einbetten der Anforderungsdaten in dem Asset; Assoziieren des vorkonfigurierten Assets mit einem Asset-Identifikator; Erhalten einer Anfrage vom Client-Gerät, wobei die Anfrage den Asset-Identifikator beinhaltet; und Liefern des vorkonfigurierten Assets an das Client-Gerät als Antwort auf das Erhalten der Anfrage.
  15. Verfahren nach Anspruch 14, wobei das Asset eine Kreditkartennummer umfasst.
  16. Verfahren nach Anspruch 14, welches die eine oder mehrere Vorrichtungen umfasst und welches ferner umfasst: vor dem Vorkonfigurieren des Assets, Erhalten von Konteninformationen von einem Benutzer des Client-Geräts, wobei die Konteninformationen ein Benutzerkonto identifizieren.
  17. Verfahren nach Anspruch 16, wobei das Erhalten der Konteninformationen vom Benutzer erfolgt, wenn der Benutzer das Client-Gerät kauft.
  18. Verfahren nach Anspruch 16, wobei das Vorkonfigurieren des Assets ferner das Assoziieren des Assets mit dem Benutzerkonto umfasst.
  19. Verfahren nach Anspruch 14, welches die eine oder mehrere Vorrichtungen umfasst und welches ferner umfasst: vor dem Vorkonfigurieren des Assets, Übertragen des Asset-Identifikators auf das Client-Gerät.
  20. Verfahren nach Anspruch 14, welches die eine oder mehrere Vorrichtungen umfasst und welches ferner umfasst: Speichern des zugeordneten Assets an einem ersten geographischen Ort und an einem zweiten geographischen Ort, der von dem ersten geographischen Ort getrennt ist.
  21. Verfahren nach Anspruch 20, wobei das Liefern des vorkonfigurierten Assets an das Client-Gerät das Liefern des vorkonfigurierten Assets von dem ersten geographischen Ort oder von dem zweiten geographischen Ort umfasst, und wobei das Client-Gerät konfiguriert ist, das gelieferte vorkonfigurierte Asset aufgrund der im gelieferten vorkonfigurierten Asset eingebetteten Anforderungsdaten zu prüfen.
  22. Verfahren nach Anspruch 14, welches die eine oder mehrere Vorrichtungen umfasst und welches ferner umfasst: vor dem Vorkonfigurieren des Assets, Erhalten des Geräte-Identifikators von einem Aufkleber oder einer Markierung, die auf einem Behältnis angebracht ist, das mit dem Client-Gerät verbunden ist.
  23. Verfahren nach Anspruch 14, wobei die Anfrage eine digitale Unterschrift beinhaltet, die mit dem Asset-Identifikator verbunden ist.
  24. Verfahren nach Anspruch 14, welches die eine oder mehrere Vorrichtungen umfasst und welches ferner umfasst: vor dem Erhalten der Anfrage vom Client-Gerät, Senden des Asset-Identifikators an das Client-Gerät.
  25. Verfahren nach Anspruch 14, wobei die Anforderungsdaten auf einer Anforderung beruhen, die auf dem sicheren Element gespeichert ist.
  26. Ein Client-Gerät, das konfiguriert ist, ein Asset von einem Remote Server anzufordern, wobei das Client-Gerät umfasst: einen Anwendungsprozessor; ein Speichergerät, das konfiguriert ist, Anweisungen zu erhalten, die das Client-Gerät bei Ausführung durch den Anwendungsprozessor veranlassen: eine Anfrage zur Bereitstellung eines Assets an ein Konto an den Remote Sever zu übermitteln, einen Geräte-Identifikator, das das Client-Gerät eindeutig identifiziert, an den Remote Server zu übermitteln, wobei der übermittelte Geräte-Identifikator genutzt wird, um die Anfrage zur Bereitstellung des Assets zu authentifizieren, eine Anforderung von einem sicheren Element des Client-Geräts zu erhalten, und die Anforderung an den Remote Server zu übermitteln, und wobei das sichere Element umfasst: einen sicheren Prozessor; und einen sicheren Speicher, der konfiguriert ist, Anweisungen zu speichern, die das sichere Gerät bei Ausführung durch den sicheren Prozessor veranlassen: das Asset von dem Remote Server zu empfangen, wobei das empfangene Asset Anforderungsdaten beinhaltet, die auf der an den Remote Server übermittelten Anforderung beruhen, und das empfangene Asset aufgrund der Anforderungsdaten zu prüfen.
  27. Das Client-Gerät nach Anspruch 26, wobei der sichere Speicher ferner konfiguriert ist, Anweisungen zu speichern, die das sichere Element bei Ausführung durch den sicheren Prozessor veranlassen, die Anforderung nach dem Prüfen des empfangenen Assets von dem sicheren Element zu löschen.
  28. Das Client-Gerät nach Anspruch 27, wobei der sichere Speicher ferner konfiguriert ist, Anweisungen zu speichern, die das sichere Element bei Ausführung durch den sicheren Prozessor veranlassen: eine neue Anforderung zu generieren, und die neue Anforderung auf dem sicheren Element zu speichern.
  29. Das Client-Gerät nach Anspruch 26, wobei das Speichergerät ferner konfiguriert ist, Anweisungen zu speichern, die das Client-Gerät bei Ausführung durch den Anwendungsprozessor veranlassen: einen Asset-Identifikator vom Remote Server zu empfangen; und den empfangenen Asset-Identifikator zum Remote Server zurückzusenden.
  30. Das Client-Gerät nach Anspruch 26, wobei das Speichergerät ferner konfiguriert ist, Anweisungen zu speichern, die das Client-Gerät bei Ausführung durch den Anwendungsprozessor veranlassen, den Geräte-Identifikator vor dem Übermitteln des Geräte-Identifikators an den Remote Server von dem sicheren Element zu erhalten.
  31. Verfahren nach Anspruch 26, wobei das Asset eine Kreditkartennummer umfasst.
  32. Das Client-Gerät nach Anspruch 26, wobei das Speichergerät ferner konfiguriert ist, Anweisungen zu speichern, die das Client-Gerät bei Ausführung durch den Anwendungsprozessor veranlassen, eine Benachrichtigung von dem Remote Server zu empfangen, die angibt, dass das Konto nach dem Erhalten des Assets von dem Remote Server aufgrund eines Wertes des Assets belastet wird.
  33. Das Client-Gerät nach Anspruch 26, wobei das Speichergerät ferner konfiguriert ist, Anweisungen zu speichern, die das Client-Gerät bei Ausführung durch den Anwendungsprozessor veranlassen, das Konto identifizierende Konteninformationen vor dem Übermitteln der Anfrage an den Remote Server zu übermitteln.
  34. Verfahren nach Anspruch 33, wobei die Konteninformationen übermittelt werden, wenn der Benutzer das Client-Gerät kauft.
  35. Verfahren nach Anspruch 26, wobei die Anforderung eine Anforderung zur einmaligen Verwendung ist.
DE112014000702.1T 2013-02-06 2014-02-06 Vorrichtungen und Verfahren für sichere Elementtransaktionen und die Verwaltung von Assets Withdrawn DE112014000702T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201361761654P 2013-02-06 2013-02-06
US61/761,654 2013-02-06
PCT/US2014/015050 WO2014124108A1 (en) 2013-02-06 2014-02-06 Apparatus and methods for secure element transactions and management of assets

Publications (1)

Publication Number Publication Date
DE112014000702T5 true DE112014000702T5 (de) 2015-11-26

Family

ID=51260132

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112014000702.1T Withdrawn DE112014000702T5 (de) 2013-02-06 2014-02-06 Vorrichtungen und Verfahren für sichere Elementtransaktionen und die Verwaltung von Assets

Country Status (6)

Country Link
US (2) US9619799B2 (de)
JP (2) JP6101824B2 (de)
CN (2) CN109118193B (de)
DE (1) DE112014000702T5 (de)
TW (1) TWI534731B (de)
WO (1) WO2014124108A1 (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109118193B (zh) 2013-02-06 2022-04-05 苹果公司 用于安全元件交易和资产管理的装置和方法
US20140330722A1 (en) * 2013-05-02 2014-11-06 Prasanna Laxminarayanan System and method for using an account sequence identifier
TWI666963B (zh) 2013-06-10 2019-07-21 美商蘋果公司 組態無線配件裝置
US9825944B2 (en) * 2014-01-24 2017-11-21 Microsoft Technology Licensing, Llc Secure cryptoprocessor for authorizing connected device requests
US10679212B2 (en) * 2014-05-26 2020-06-09 The Toronto-Dominion Bank Post-manufacture configuration of pin-pad terminals
WO2015184064A1 (en) 2014-05-30 2015-12-03 Apple Inc. Secure storage of an electronic subscriber identity module on a wireless communication device
US10154082B2 (en) * 2014-08-12 2018-12-11 Danal Inc. Providing customer information obtained from a carrier system to a client device
DE102014013031A1 (de) * 2014-09-02 2016-03-03 Giesecke & Devrient Gmbh Informationseinrichtung
US10089607B2 (en) * 2014-09-02 2018-10-02 Apple Inc. Mobile merchant proximity solution for financial transactions
JP6818679B2 (ja) * 2014-10-13 2021-01-20 シークエント ソフトウェア、インコーポレイテッド セキュアホストカードエミュレーションクレデンシャル
WO2016129863A1 (en) 2015-02-12 2016-08-18 Samsung Electronics Co., Ltd. Payment processing method and electronic device supporting the same
US10193700B2 (en) 2015-02-27 2019-01-29 Samsung Electronics Co., Ltd. Trust-zone-based end-to-end security
US11107047B2 (en) 2015-02-27 2021-08-31 Samsung Electronics Co., Ltd. Electronic device providing electronic payment function and operating method thereof
KR102460459B1 (ko) 2015-02-27 2022-10-28 삼성전자주식회사 전자 장치를 이용한 카드 서비스 방법 및 장치
US10185949B2 (en) * 2015-03-05 2019-01-22 American Express Travel Related Services Company, Inc. System and method for authentication of a mobile device configured with payment capabilities
TWI632514B (zh) * 2015-04-08 2018-08-11 財團法人工業技術研究院 數位交易方法、使用者裝置、服務提供端裝置與數位交易管理伺服系統
BR112018014982A8 (pt) * 2016-01-25 2023-04-11 Apple Inc Conduzir transações usando dispositivos eletrônicos com credenciais não nativas
US11107071B2 (en) * 2016-02-01 2021-08-31 Apple Inc. Validating online access to secure device functionality
EP3255597A1 (de) * 2016-06-12 2017-12-13 Apple Inc. Verwaltung sicherer transaktionen zwischen elektronischen vorrichtungen und dienstanbietern
FR3053548B1 (fr) * 2016-06-30 2019-07-19 Ingenico Group Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.
CN106250966A (zh) * 2016-07-21 2016-12-21 大连梅泰诺信息技术有限公司 一种公交账户支付系统
US10542072B1 (en) * 2017-10-04 2020-01-21 Parallels International Gmbh Utilities toolbox for remote session and client architecture
CA3109247C (en) * 2018-02-09 2022-08-09 Ka Wai Wayne LEUNG Universal passive provisioning unit and method for secure element
JP6535394B1 (ja) * 2018-02-15 2019-06-26 クールビックス リミテッド デジタル資産取引方法
JP6466011B1 (ja) * 2018-04-13 2019-02-06 クールビックス リミテッド 電子ウォレットの生成及び復元方法
US11164179B2 (en) * 2019-01-22 2021-11-02 Apple, Inc. Secure credential storage and retrieval
US10902705B1 (en) * 2019-12-09 2021-01-26 Evan Chase Rose Biometric authentication, decentralized learning framework, and adaptive security protocols in distributed terminal network
US11113665B1 (en) 2020-03-12 2021-09-07 Evan Chase Rose Distributed terminals network management, systems, interfaces and workflows
US11200548B2 (en) 2019-12-09 2021-12-14 Evan Chase Rose Graphical user interface and operator console management system for distributed terminal network
US10873578B1 (en) 2019-12-09 2020-12-22 Evan Chase Rose Biometric authentication, decentralized learning framework, and adaptive security protocols in distributed terminal network
EP4123536A1 (de) * 2021-07-22 2023-01-25 Deutsche Telekom AG Verfahren und system zur konfiguration einer mobilen verkaufsstellenanwendung

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1312549C (zh) * 1995-02-13 2007-04-25 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US6609113B1 (en) * 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US20030024975A1 (en) 2001-07-18 2003-02-06 Rajasekharan Ajit V. System and method for authoring and providing information relevant to the physical world
JP3532543B2 (ja) * 2001-08-27 2004-05-31 エヌ・ティ・ティ・コムウェア株式会社 携帯電話端末装置
GB2387253B (en) * 2002-04-03 2004-02-18 Swivel Technologies Ltd System and method for secure credit and debit card transactions
US20040230328A1 (en) 2003-03-21 2004-11-18 Steve Armstrong Remote data visualization within an asset data system for a process plant
GB0308522D0 (en) 2003-04-12 2003-05-21 Ibm Access to web services
US8185475B2 (en) * 2003-11-21 2012-05-22 Hug Joshua D System and method for obtaining and sharing media content
US7734732B2 (en) * 2005-05-12 2010-06-08 At&T Mobility Ii Llc System, apparatus and methods for storing links to media files in network storage
JP4473189B2 (ja) * 2005-07-22 2010-06-02 株式会社椿本チエイン 創薬用試料保管システム
US20070178885A1 (en) * 2005-11-28 2007-08-02 Starhome Gmbh Two-phase SIM authentication
CN101523428A (zh) * 2006-08-01 2009-09-02 Q佩控股有限公司 交易授权系统和方法
US11195163B2 (en) * 2006-09-01 2021-12-07 Mastercard International Incorporated Methods, systems and computer readable media for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities
US8165635B2 (en) 2006-09-01 2012-04-24 Vivotech, Inc. Methods, systems, and computer readable media for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities
US20120130838A1 (en) * 2006-09-24 2012-05-24 Rfcyber Corp. Method and apparatus for personalizing secure elements in mobile devices
US8015409B2 (en) * 2006-09-29 2011-09-06 Rockwell Automation Technologies, Inc. Authentication for licensing in an embedded system
US8538819B2 (en) * 2007-07-30 2013-09-17 Ebay Inc. Method and system for dynamic funding
US8200736B2 (en) 2007-12-24 2012-06-12 Qualcomm Incorporated Virtual SIM card for mobile handsets
JP4987820B2 (ja) 2008-08-11 2012-07-25 日本電信電話株式会社 認証システム、接続制御装置、認証装置および転送装置
AU2009302485C1 (en) 2008-10-06 2015-10-22 Mastercard International, Inc. Systems, methods, and computer readable media for payment and non-payment virtual card transfer between mobile devices
US10454693B2 (en) 2009-09-30 2019-10-22 Visa International Service Association Mobile payment application architecture
US8996002B2 (en) 2010-06-14 2015-03-31 Apple Inc. Apparatus and methods for provisioning subscriber identity data in a wireless network
KR101327434B1 (ko) 2010-10-20 2013-11-20 비씨카드(주) 고객 단말기의 맥 어드레스 정보를 이용한 결제 방법 및 시스템
US8805434B2 (en) * 2010-11-23 2014-08-12 Microsoft Corporation Access techniques using a mobile communication device
US9509686B2 (en) * 2010-12-03 2016-11-29 Microsoft Technology Licensing, Llc Secure element authentication
KR20120076654A (ko) 2010-12-09 2012-07-09 인포뱅크 주식회사 개인 휴대폰 번호를 기반으로 한 카드결제 중계 시스템 및 그 방법
CA2724297C (en) * 2010-12-14 2013-11-12 Xtreme Mobility Inc. System and method for authenticating transactions through a mobile device
US8196131B1 (en) 2010-12-17 2012-06-05 Google Inc. Payment application lifecycle management in a contactless smart card
WO2012085675A2 (en) * 2010-12-20 2012-06-28 Eram Antonio Claudiu System, method and apparatus for mobile payments enablement and order fulfillment
KR20120108599A (ko) * 2011-03-25 2012-10-05 주식회사 스마트솔루션 온라인 신용카드 결제 단말기를 활용한 신용카드 결제 서비스
WO2012168940A1 (en) * 2011-06-09 2012-12-13 Accells Technologies (2009), Ltd. A transaction system and method for use with a mobile device
AU2012284047B2 (en) * 2011-07-18 2016-10-06 Visa International Service Association Mobile device with secure element
US8566168B1 (en) * 2012-01-05 2013-10-22 Sprint Communications Company L.P. Electronic payment using a proxy account number stored in a secure element
CN104221347B (zh) 2012-02-14 2017-03-29 苹果公司 支持多个访问控制客户端的移动装置和对应的方法
EP2741461A1 (de) * 2012-12-07 2014-06-11 Gemalto SA Verfahren zum Ermöglichen der Kommunikation zwischen einem sicheren Element und einem Server
CN109118193B (zh) 2013-02-06 2022-04-05 苹果公司 用于安全元件交易和资产管理的装置和方法

Also Published As

Publication number Publication date
JP6438989B2 (ja) 2018-12-19
CN104969245A (zh) 2015-10-07
JP2016513317A (ja) 2016-05-12
WO2014124108A1 (en) 2014-08-14
US11068883B2 (en) 2021-07-20
US9619799B2 (en) 2017-04-11
CN109118193A (zh) 2019-01-01
JP2017134848A (ja) 2017-08-03
CN104969245B (zh) 2018-10-19
TWI534731B (zh) 2016-05-21
CN109118193B (zh) 2022-04-05
JP6101824B2 (ja) 2017-03-22
US20170278097A1 (en) 2017-09-28
TW201443800A (zh) 2014-11-16
US20140222688A1 (en) 2014-08-07

Similar Documents

Publication Publication Date Title
DE112014000702T5 (de) Vorrichtungen und Verfahren für sichere Elementtransaktionen und die Verwaltung von Assets
AU2017263465B2 (en) Application framework using blockchain-based asset ownership
EP3518567B1 (de) Fernserversystem zur bereitstellung verschlüsselter daten und verfahren
AU2012284047B2 (en) Mobile device with secure element
US9916576B2 (en) In-market personalization of payment devices
CN112037068B (zh) 资源转移方法、系统、装置、计算机设备和存储介质
US20220255725A1 (en) System and method for authorizing transactions in an authorized member network
WO2017160877A1 (en) Technical architecture supporting tokenized payments
DE102018122997A1 (de) Blockkettenentität, kettenexterne entität, zertifizierungsvorrichtung für blockkettenoperationen und verfahren zum durchführen einer kooperation zwischen einer blockkettenentität und einer kettenexternen entität
JP2019525326A (ja) トランザクションデバイスによるデジタル資産分配
US11694182B2 (en) Systems and methods for displaying payment device specific functions
WO2018114654A1 (de) System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement
EP2858023B1 (de) Artikel und Verfahren zur Transaktionsunregelmäßigkeitserkennung
CN112513904B (zh) 一种数字资产交易控制方法、装置、终端设备及存储介质
KR101587475B1 (ko) 비방문 대출 거래 방법, 이를 수행하기 위한 장치 및 컴퓨터 프로그램
US20150206125A1 (en) Method, system, and computer-readable medium for providing a near field secure electronic token transaction
US20130066787A1 (en) System and treatment process of a financial transaction

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: BARDEHLE PAGENBERG PARTNERSCHAFT MBB PATENTANW, DE

R083 Amendment of/additions to inventor(s)
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee