DE112020002160T5 - System und verfahren zum betreiben einer sicheren kontaktlosen transaktion - Google Patents

System und verfahren zum betreiben einer sicheren kontaktlosen transaktion Download PDF

Info

Publication number
DE112020002160T5
DE112020002160T5 DE112020002160.2T DE112020002160T DE112020002160T5 DE 112020002160 T5 DE112020002160 T5 DE 112020002160T5 DE 112020002160 T DE112020002160 T DE 112020002160T DE 112020002160 T5 DE112020002160 T5 DE 112020002160T5
Authority
DE
Germany
Prior art keywords
buyer
transaction
seller
device associated
request
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.)
Pending
Application number
DE112020002160.2T
Other languages
English (en)
Inventor
Eran Hollander
Damien Balsan
Olivier De La Bastide
Sebastien Fontaine
Frank Van Den Berg
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 DE112020002160T5 publication Critical patent/DE112020002160T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4015Transaction verification using location information
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3278RFID or NFC payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224Transactions dependent on location of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825Use of electronic signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment

Landscapes

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

Abstract

Es wird ein Verfahren und ein System zum Autorisieren der Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer offenbart. Eine Zahlungsanforderung kann von einer Vorrichtung empfangen werden, die dem Verkäufer zugeordnet ist. Eine Authentifizierungsanfrage, die Transaktionsinformationen umfasst, kann an einen Authentifizierungsdienst übermittelt werden. Ein Hinweis, dass der Käufer authentifiziert wurde, kann von dem Authentifizierungsdienst empfangen werden. Eine Transaktionsanforderung kann übermittelt werden, nachdem der Käufer authentifiziert wurde.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
  • Diese Anmeldung beansprucht den Vorteil und die Priorität der Vorläufigen US-Patentanmeldung Nr. 62/901,623 , eingereicht am 17. September 2019, der vorläufigen US-Patentanmeldung Nr. 62/874,224 , eingereicht am 15. Juli 2019, der vorläufigen US-Patentanmeldung Nr. 62/841,030 , eingereicht am 30. April 2019, und der vorläufigen US-Patentanmeldung Nr. 62/840,376 , eingereicht am 29. April 2019. Jedes Patent und jede Anmeldung, die in diesem Absatz erwähnt ist, wird durch Bezugnahme in seiner/ihrer Gesamtheit hierin eingeschlossen.
  • GEBIET
  • Die vorliegende Technologie betrifft Systeme und Verfahren zum Betreiben einer sicheren kontaktlosen Transaktion.
  • HINTERGRUND
  • Zahlungsdienste, wie Kreditkartentransaktionen oder -Zahlungen, die mit mobilen Vorrichtungen durchgeführt werden, sind häufig Gegenstand betrügerischer Transaktionen. Diese betrügerischen Transaktionen können für Aussteller, Verkäufer, Kunden usw. durchaus teuer sein. Um die Menge betrügerischer Transaktionen zu reduzieren, wurden verschiedene Authentifizierungsmaßnahmen entwickelt. Diese Authentifizierungsmaßnahmen können für Käufer und Verkäufer umständlich sein.
  • KURZDARSTELLUNG
  • Zur Authentifizierung einer Transaktion können verschiedene Maßnahmen verwendet werden. Der Authentifizierungsprozess erfordert möglicherweise wenig bis keine zusätzliche Eingabe vom Käufer und/oder Verkäufer. Das Zahlungskonto eines Käufers kann einer mobilen Käufervorrichtung zugeordnet sein. Nachdem ein Käufer versucht, eine Zahlung vorzunehmen, kann eine Nachricht an die mobile Käufervorrichtung gesendet werden, die anfordert, dass der Käufer verifiziert, dass er die Transaktion autorisieren möchte. Der Standort der Käufervorrichtung kann bestimmt und mit dem Standort des Verkäufers verglichen werden. Wenn sich die Käufervorrichtung in der Nähe des Verkäufers befindet, kann die Transaktion autorisiert werden. Eine Signatur der Käufervorrichtung kann bestimmt und gespeichert werden. Wenn die Signatur der Käufervorrichtung von der Verkäufervorrichtung erfasst wird, kann die Transaktion autorisiert werden.
  • Gemäß einem ersten breiten Aspekt der vorliegenden Technologie wird ein Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer bereitgestellt. Das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Übertragen, an einen Authentifizierungsdienst, einer Authentifizierungsanforderung, die Transaktionsinformationen umfasst; Empfangen, von dem Authentifizierungsdienst, einer Angabe, dass der Käufer authentifiziert wurde, und nachdem der Käufer authentifiziert worden ist, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  • In einigen Implementierungen des Verfahrens umfasst das Verfahren ferner das Übertragen einer Anforderung zum Autorisieren der Transaktion durch eine Anwendung auf der dem Käufer zugeordneten Vorrichtung durch den Authentifizierungsdienst, und an die dem Käufer zugeordnete Vorrichtung.
  • In einigen Implementierungen des Verfahrens umfasst das Verfahren ferner das Bestimmen, durch den Authentifizierungsdienst, einer Kennung, die der dem Käufer zugeordneten Vorrichtung entspricht.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung Informationen, die der dem Verkäufer zugeordneten Vorrichtung entsprechen.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung ein Token von einer mobilen Geldbörse.
  • In einigen Implementierungen des Verfahrens umfasst die Transaktionsanforderung das Token von der mobilen Geldbörse.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung eine Zahlungskartennummer.
  • In einigen Implementierungen des Verfahrens umfasst die Transaktionsanforderung die Zahlungskartennummer.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung einen Betrag der Transaktion.
  • In einigen Implementierungen des Verfahrens umfasst die Transaktionsanforderung den Betrag der Transaktion.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung Informationen, die den Verkäufer angeben.
  • In einigen Implementierungen des Verfahrens umfasst die Transaktionsanforderung die Informationen, die den Verkäufer angeben.
  • In einigen Implementierungen des Verfahrens umfasst die Angabe, dass der Käufer authentifiziert wurde, ein Token.
  • In einigen Implementierungen des Verfahrens umfasst die Transaktionsanforderung das Token.
  • Gemäß einem weiteren breiten Aspekt der vorliegenden Technologie wird ein Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer bereitgestellt. Das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Übertragen, an einen Authentifizierungsdienst, einer Authentifizierungsanforderung, die Transaktionsinformationen umfasst; Empfangen, von dem Authentifizierungsdienst, einer Angabe, dass die Authentifizierung des Käufers fehlgeschlagen ist; und nach dem Empfangen der Angabe, dass die Authentifizierung des Käufers fehlgeschlagen ist, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  • In einigen Implementierungen des Verfahrens umfasst das Verfahren ferner das Bestimmen durch den Authentifizierungsdienst, dass die dem Verkäufer zugeordnete Vorrichtung eine fehlgeschlagene Authentifizierung aufweist.
  • In einigen Implementierungen des Verfahrens umfasst das Verfahren ferner das Übertragen eines zur Authentifizierung einzugebenden Einmalpassworts durch den Authentifizierungsdienst und an die dem Käufer zugeordnete Vorrichtung.
  • In einigen Implementierungen des Verfahrens umfasst das Verfahren ferner das Übertragen einer Anforderung zum Autorisieren der Transaktion durch eine Anwendung auf der dem Käufer zugeordneten Vorrichtung durch den Authentifizierungsdienst, und an die dem Käufer zugeordnete Vorrichtung.
  • In einigen Implementierungen des Verfahrens umfasst das Verfahren ferner das Bestimmen, durch den Authentifizierungsdienst, einer Kennung, die der dem Käufer zugeordneten Vorrichtung entspricht.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung Informationen, die der dem Verkäufer zugeordneten Vorrichtung entsprechen.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung ein Token von einer mobilen Geldbörse.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung eine Zahlungskartennummer.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung einen Betrag der Transaktion.
  • In einigen Implementierungen des Verfahrens umfasst die Authentifizierungsanforderung Informationen, die den Verkäufer angeben.
  • Verschiedene Implementierungen der vorliegenden Technologie stellen ein nicht-transitorisches computerlesbares Medium bereit, in dem Programmanweisungen zum Ausführen eines oder mehrerer hierin beschriebener Verfahren gespeichert sind, wobei die Programmanweisungen durch einen Prozessor eines computerbasierten Systems ausführbar sind.
  • Verschiedene Implementierungen der vorliegenden Technologie stellen ein computerbasiertes System bereit, wie zum Beispiel, ohne jedoch darauf beschränkt zu sein, eine elektronische Vorrichtung, die mindestens einen Prozessor und einen Speicher umfasst, in dem Programmanweisungen zum Ausführen eines oder mehrerer hierin beschriebener Verfahren gespeichert sind, wobei die Programmanweisungen durch den mindestens einen Prozessor der elektronischen Vorrichtung ausführbar sind.
  • Zusätzliche und/oder alternative Merkmale, Aspekte und Vorteile von Implementierungen der vorliegenden Technologie werden aus der folgenden Beschreibung, den beigefügten Zeichnungen und den beigefügten Ansprüchen ersichtlich.
  • Figurenliste
  • Diese und andere Merkmale, Aspekte und Vorteile der vorliegenden Technologie werden mit Bezug auf die folgende Beschreibung, die beigefügten Ansprüche und die beigefügte Zeichnung besser verständlich, wobei:
    • 1 eine Veranschaulichung einer beispielhaften Umgebung zum Ausführen einer sicheren kontaktlosen Transaktion gemäß Ausführungsformen der vorliegenden Technologie ist;
    • 2 eine Veranschaulichung einer Architektur auf hoher Ebene von bestimmten Komponenten der in 1 gezeigten Umgebung ist;
    • 3 und 4 Flussdiagrammdarstellungen von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer sicheren kontaktlosen Transaktion gemäß Ausführungsformen der vorliegenden Technologie sind;
    • 5 eine Veranschaulichung eines Verfahrens ist, das gemäß nicht einschränkenden Ausführungsformen der vorliegenden Technologie ausgeführt wird;
    • 6 eine Flussdiagrammdarstellung von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer sicheren kontaktlosen Transaktion gemäß einer ersten alternativen Ausführungsform ist;
    • 7 eine Veranschaulichung eines ersten alternativen Verfahrens ist, das gemäß nicht einschränkenden Ausführungsformen der vorliegenden Technologie ausgeführt wird;
    • 8 eine Flussdiagrammdarstellung von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer sicheren kontaktlosen Transaktion gemäß einer zweiten alternativen Ausführungsform ist;
    • 9 eine Veranschaulichung eines zweiten alternativen Verfahrens ist, das gemäß nicht einschränkenden Ausführungsformen der vorliegenden Technologie ausgeführt wird;
    • 10 bis 15 beispielhafte Ausführungsformen von grafischen Benutzerschnittstellen (GUIs) veranschaulichen, die die vorliegende Technologie implementieren;
    • 16 eine Flussdiagrammdarstellung eines Verfahrens zum Durchführen einer Transaktion gemäß nicht einschränkenden Ausführungsformen der vorliegenden Technologie ist; und
    • 17 eine Flussdiagrammdarstellung von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer Transaktion gemäß Ausführungsformen der vorliegenden Technologie ist.
  • AUSFÜHRLICHE BESCHREIBUNG DER ZEICHNUNGEN
  • Verschiedene Ausführungsbeispiele der beschriebenen Technologie werden nachstehend unter Bezugnahme auf die beigefügten Zeichnungen, in denen Ausführungsbeispiele gezeigt sind, ausführlicher beschrieben. Der vorliegende Erfindungsgedanken kann jedoch in vielen verschiedenen Formen ausgeführt werden und sollte nicht als auf die hierin angegebenen Ausführungsbeispiele beschränkt verstanden werden. Vielmehr werden diese Ausführungsbeispiele bereitgestellt, damit die Offenbarung gründlich und vollständig ist und den Fachleuten den Umfang des vorliegenden Erfindungsgedankens vollständig vermittelt. In den Zeichnungen können die Größen und relativen Größen von Schichten und Regionen der Übersichtlichkeit halber übertrieben groß dargestellt sein. Gleiche Zahlen bezeichnen durchwegs gleiche Elemente.
  • Es versteht sich, dass die Begriffe „erste/r/s“, „zweite/r/s“, „dritte/r/s“ usw. in diesem Schriftstück dazu verwendet werden, verschiedene Elemente zu beschreiben, die aber durch diese Begriffe nicht eingeschränkt werden sollten. Diese Begriffe werden verwendet, um ein Element von einem anderen zu unterscheiden. Somit könnte ein erstes Element, das im Folgenden erörtert wird, als ein zweites Element bezeichnet sein, ohne von den Lehren des vorliegenden Erfindungsgedankens abzuweichen. Wie hierin verwendet, schließt der Begriff „und/oder“ jegliche und alle Kombinationen von einem oder mehreren der zugehörigen aufgeführten Punkte ein.
  • Es versteht sich, dass, wenn ein Element als mit einem anderen Element bezeichnet „verbunden“ oder „gekoppelt“ wird, es direkt mit dem anderen Element verbunden oder gekoppelt sein kann oder dazwischenliegende Elemente vorhanden sein können. Wenn ein Element dagegen als „direkt verbunden“ oder „direkt gekoppelt“ mit einem anderen Element bezeichnet wird, sind keine dazwischenliegenden Elemente vorhanden. Andere Wörter, die verwendet werden, um die Beziehung zwischen Elementen zu beschreiben, sollten auf gleiche Weise interpretiert werden (z. B. „zwischen“ und „direkt zwischen“, „benachbart“ und „direkt benachbart“ usw.).
  • Die hierin verwendete Terminologie dient lediglich dem Zweck des Beschreibens bestimmter Aspekte und soll den vorliegenden Erfindungsgedanken nicht einschränken. So wie hierin verwendet, sollen die Singularformen „ein“, „eine“, „eines“ und „der“, „die“, „das“ auch die Pluralformen einschließen, es sei denn, der Kontext gibt etwas anderes an. Es versteht sich ferner, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn sie in dieser Spezifikation verwendet werden, das Vorhandensein von angegebenen Funktionen, Einheiten, Schritten, Arbeitsgängen, Elementen und/oder Komponenten bezeichnen, nicht aber das Vorhandensein oder das Hinzufügen von einer oder mehreren anderen Funktionen, Einheiten, Schritten, Arbeitsgängen, Elementen, Komponenten und/oder Gruppen von diesen ausschließen.
  • In der gesamten vorliegenden Offenbarung wird auf sichere Transaktionen (zum Beispiel, aber ohne Einschränkung, kontaktbehaftete und kontaktlose Transaktionen), sichere Elemente (zum Beispiel, aber ohne Einschränkung, Chipsatz, gesicherter Chipsatz, gesicherte Hardwareeinbettungskomponente, gesicherte Softwareeinbettungskomponente oder gesicherte Firmwareeinbettungskomponente) und Sicherheitsstandards verwiesen. Beispiele für Sicherheitsstandards beinhalten, ohne einschränkend zu sein, Zertifizierungsstandards von Europay, MasterCard, und Visa (EMV), EMVCo, MasterCard®, Visa®, American Express®, JCB®, Discover® und aus dem PCI SSC (Payment Card Industry Security Standards Council, Sicherheitsgremium der Kreditkartenfirmen), das von MasterCard®, Visa®, American Express®, Discover® und JCB® begründet wurde und sich speziell auf die Definition von Sicherheitsstandards für Finanztransaktionen bezieht. Zur Veranschaulichung wird auf sichere Transaktionen, sichere Elemente und Sicherheitsstandards Bezug genommen, die beispielhaft für die vorliegende Technologie und nicht einschränkend für deren Umfang sein sollen.
  • Im Kontext der vorliegenden Technologie kann sich ein „Prozessor“ auf ein System-on-Chip, System auf einem Chip (SoC), eine integrierte Schaltung, die Komponenten eines Computers in einem einzelnen Chip integriert, beziehen. Ein typischer SoC kann einen oder mehrere Universalmikroprozessoren oder Zentralverarbeitungseinheiten (Central Processing Units, CPUs), Coprozessoren, wie einen digitalen Signalprozessor (Digital Signal Processor, DSP), eine Grafikverarbeitungseinheit (Graphics Processing Unit, GPU), und Multimedia-Coprozessoren, wie MPEG- und JPEG-Codierer und -Decodierer, einschließen, ist jedoch nicht darauf beschränkt. Der SoC kann auch Modems für verschiedene drahtlose Kommunikationsschnittstellen einschließen, einschließlich Mobilfunk (z. B. LTE/4G, 3G, GSM, CDMA usw.), Bluetooth und Wireless Fidelity (Wi-Fi) (IEEE 802.11). Der SoC kann Speichersteuerungen zum Verbinden mit chipinternen oder externen DRAM-Speicherchips und chipinternen Speicherblöcken einschließlich einer Auswahl von ROM-, SRAM-, DRAM-, EEPROM- und Flash-Speichern einschließen. Der SoC kann zusätzlich Zeitquellen, Peripheriegeräte einschließlich Zähler-Zeitgebern, Echtzeitzeitgebern und Hochlauf-Rücksetzgeneratoren, Debug-, JTAG- und Design For Test-Schnittstellen (DFT-Schnittstellen), externe Schnittstellen, analoge Schnittstellen, Spannungsregler, Leistungsmanagementschaltungen usw. einschließen. Der SoC kann auch Konnektivitätskomponenten einschließen, wie einfache Busse oder On-Chip-Netzwerke, die der ARM-Spezifikation Advanced Microcontroller Bus Architecture (Architektur für hochentwickelte Mikrocontroller-Busse, AMBA) folgen, die diese Blöcke miteinander verbindet, wie im Stand der Technik bekannt. Einige Blöcke können separat gepackt und auf der Oberseite des SoC gestapelt sein, ein Design, das in der Technik als Package-on-Package (PoP) bekannt ist. Alternativ können einige Blöcke in verschiedenen integrierten Schaltungen (oder Chips) enthalten sein, aber zusammen gepackt sein, was in der Technik als System in Package (SiP) bekannt ist.
  • Im Kontext der vorliegenden Technologie kann sich ein „isolierter gesicherter Bereich des Prozessors (ISA)“ auf eine Verarbeitungsentität beziehen, die durch spezifische Hardware- und/oder Softwarekomponenten gekennzeichnet ist, die einer Zertifizierung unterliegen, die eine spezifische Sicherheitsstufe gemäß spezifischen Sicherheitsstandards gewährleistet. Der isolierte gesicherte Bereich stellt sicher, dass sensible Daten in einer gesicherten und vertrauenswürdigen Umgebung des Prozessors gespeichert, verarbeitet und geschützt werden, während hohe Verarbeitungsgeschwindigkeiten und große Mengen an zugänglichem Speicher beibehalten werden. Der isolierte gesicherte Bereich kann isolierte Ausführung, sicheren Speicher, Remote-Attestierung, sichere Bereitstellung, zuverlässiges Booten und zuverlässigen Pfad bieten. Der isolierte gesicherte Bereich ermöglicht es dem Prozessor, in zwei logischen Modi zu arbeiten: normale Welt oder gesicherte Welt. Die normale Welt wird von dem nicht sicheren Bereich des Prozessors betrieben und kann das nicht sichere Rich Operating System (leistungsstarkes Betriebssystem, Rich OS) und die Softwarekomponenten und Anwendungen umfassen, die auf dem Rich OS ausgeführt werden. Die normale Welt kann nicht auf Ressourcen zugreifen, die zur ausschließlichen Nutzung in der sicheren Welt vorgesehen sind. Die sichere Welt wird von dem isolierten gesicherten Bereich ausgeführt, der die einzige Entität ist, die Zugriff auf Ressourcen hat, die zur Verwendung ausschließlich in dem gesicherten Bereich bereitgestellt werden, wie bestimmte abgegrenzte Bereiche von ROM- oder RAM-Speicher, Prozessor oder Coprozessor-Konfigurationsregistern, und bestimmte Peripheriegeräte, wie Anzeigesteuerungen oder Touchscreensteuerungen, und deren zugehörigen Konfigurationsregister. Einige der Ressourcen, die für die ausschließliche Verwendung des isolierten sicheren Bereichs bereitgestellt werden, können sich auf demselben Chip oder Package wie der SoC befinden, während andere in einem anderen Chip oder Package enthalten sein können. Einige der Ressourcen können zu bestimmten Zeiten dynamisch für die ausschließliche Verwendung des isolierten sicheren Bereichs bereitgestellt werden, während sie zu anderen Zeiten für die Verwendung durch die normale Welt verfügbar sein können. Der isolierte gesicherte Bereich führt nur autorisierte und vertrauenswürdige Anwendungen aus und bietet Sicherheit gegen logische Angriffe, die in der Rich OS-Umgebung erzeugt werden, Angriffe, die darauf abzielen, Boot-Firmware zu beeinträchtigen, Angriffe, die Debug- und Testschnittstellen ausnutzen, und andere nichtinvasive Angriffe. Nicht einschränkende Beispiele für einen isolierten gesicherten Bereich des Prozessors schließen Trusted Execution Environment (TEE), Intel Trusted Execution Technology (TXT), das Trusted Platform Module (TPM), den Hengzhi-Chip und den IBM Embedded Security Subsystem-Chip (ESS-Chip) ein. In einigen Ausführungsformen ist der isolierte gesicherte Bereich des Prozessors so ausgelegt, dass auch von einem menschlichen Administrator nicht darauf zugegriffen werden kann. In einigen Ausführungsformen kann der isolierte gesicherte Bereich teilweise oder vollständig über ein dediziertes Hardwareelement implementiert werden, wie, ohne jedoch darauf beschränkt zu sein, ein sicheres Element, wie im nachstehenden Absatz definiert. Andere Variationen des isolierten gesicherten Bereichs können vom Fachmann auf dem Gebiet der vorliegenden Technologie ebenfalls in Betracht gezogen werden, ohne vom Umfang der vorliegenden Technologie abzuweichen.
  • Im Kontext der vorliegenden Technologie kann sich ein „sicheres Element“ auf eine Verarbeitungsentität beziehen, die durch spezifische Hardware- und/oder Softwarekomponenten gekennzeichnet ist, die einer Zertifizierung unterliegen können, die eine spezifische Sicherheitsstufe gemäß spezifischen Sicherheitsstandards gewährleistet. Hardwaremäßig umfasst ein sicheres Element die in einer Rechenentität üblichen Komponenten: mindestens einen Mikroprozessor (z. B. CPU), Speicher (z. B. ROM, RAM oder FLASH-Speicher), Kommunikationsschnittstellen usw. Spezifische Hardwarekomponenten können auch eingeschlossen sein, um spezifische Funktionalitäten zu implementieren, die für ein sicheres Element spezifisch sind. Beispielsweise kann ein kryptographischer Beschleuniger enthalten sein. Außerdem können verschiedene Manipulationsresistenz-, Manipulationserfassungs- und/oder Manipulationsreaktionsmerkmale eingeschlossen sein, um zu verhindern, dass eine Person in böswilliger Absicht sensible Informationen aus dem sicheren Element extrahiert. Manipulationsschutzmaßnahmen können Hardware-Aspekte, Software-Aspekte oder eine Kombination von Hardware und Software umfassen. Auch können bestimmte Gegenmaßnahmen zum Verhindern von Seitenkanalangriffen, die darauf abzielen, kryptographische Schlüssel oder andere sensible Informationen wiederherzustellen, in dem sicheren Element enthalten sein. Gegenmaßnahmen gegen Seitenkanalangriffe können Hardware-Aspekte, Software-Aspekte oder beides einschließen. Außerdem können Maßnahmen zur Reduzierung von EM-Emissionen, wie Abschirmung, eingeschlossen sein, um das sichere Element gegen Abhören zu schützen. Im Kontext von Finanztransaktionen stellt die Zertifizierung des sicheren Elements sicher, dass verschiedene Finanzentitäten bereit sind, das sichere Element zum Speichern und Verarbeiten kritischer Finanzdaten zu verwenden und gesicherte Finanztransaktionen unter Verwendung der kritischen Finanzdaten durchzuführen. In einigen Ausführungsformen kann das sichere Element ausschließlich durch Softwarekomponenten gekennzeichnet sein. Das sichere Element kann in einigen Ausführungsformen teilweise oder vollständig als ein isolierter gesicherter Bereich des Prozessors implementiert sein, wie der isolierte gesicherte, wie im vorstehenden Absatz beschrieben, wobei in diesem Fall das sichere Element zum Beispiel, aber ohne Einschränkung, als ein TEE, ein TPM und/oder ein ESS implementiert sein kann. In einigen Ausführungsformen kann das sichere Element (SE) ebenfalls als eingebettetes sicheres Element (eSE) bezeichnet werden. Andere Variationen des sicheren Elements können vom Fachmann auf dem Gebiet der vorliegenden Technologie ebenfalls in Betracht gezogen werden, ohne vom Umfang der vorliegenden Technologie abzuweichen.
  • Obwohl die verschiedenen vorstehend definierten Komponenten jeweils einer Definition zugeordnet sind, versteht es sich, dass jede der verschiedenen Komponenten nicht als ausschließlich auf die spezifischen Funktionen und/oder Spezifika beschränkt ausgelegt werden sollte, die in der zugeordneten Definition bereitgestellt werden. Vielmehr können andere Funktionen und/oder Spezifika hinzugefügt, entfernt oder kombiniert werden, ohne vom Umfang der vorliegenden Technologie abzuweichen.
  • 1 veranschaulicht eine schematische Darstellung einer Umgebung 9 zum Durchführen einer gesicherten Finanztransaktion von einer ersten Vorrichtung 102 (z. B. einer Verkäufervorrichtung 102 im veranschaulichten Beispiel, die auch als Händlervorrichtung bezeichnet werden kann), während eine zweite Vorrichtung 104 (z. B. eine Käufervorrichtung 104) dazu genutzt wird, einen Authentifizierungsschritt gemäß Ausführungsformen der vorliegenden Technologie auszuführen. Im dargestellten Ausführungsbeispiel ist die Verkäufervorrichtung 102 einem Verkäufer 2 (d. h. Händler) und die Käufervorrichtung 104 einem Käufer 4 (d. h. Kunden) zugeordnet. In diesem Beispiel steht der Käufer 4 in einer Vertragsbeziehung mit einem Aussteller 6, der auch als Finanzinstitut bezeichnet wird, das ein Finanzkonto eines Käufers führt. Der Aussteller 6 kann eine Bank sein, die das Girokonto und/oder Kreditkartenkonto des Kunden verwaltet. In einigen Ausführungsformen kann der Aussteller 6 auch eine Organisation sein, die Prepaid-Karten, Kundenkreditkarten und/oder Sammelkonten betreibt, die einem Dritten gehören, und der Käufer hat eine Karte unter diesem Konto. Der Aussteller 6 kann dem Käufer 4 ein Token bereitstellen, um eine Authentifizierung während Finanztransaktionen bereitzustellen. Ein derartiges Token kann zum Beispiel eine Zahlungskarte und/oder eine gesicherte eindeutige Identifikationskomponente sein, die in die Käufervorrichtung 104 eingebettet sein kann (z. B. als virtualisierte Zahlungskarte, die in einer mobilen Geldbörse gespeichert sein kann), einschließlich, aber nicht beschränkt auf, einen Quick Response-Code (QR-Code), einen Barcode, einen alphanumerischen Code, einen hörbaren Ton, eine Bild-, eine NFC- oder Bluetooth-Kommunikation oder ein beliebiges anderes audio/visuelles/digitales „Token“, das zwischen Verkäufervorrichtungen 102 und Käufervorrichtungen 104 kommuniziert werden kann. In einigen Ausführungsformen kann das Token auch beliebige biometrische Informationen über den Käufer 4 enthalten, wie einen Fingerabdruck, eine Sprachsignatur, eine Bildkennung (ID), einen Netzhautscan, eine Anwendung auf der Vorrichtung, Code usw.
  • Die Zahlungskarte wird von einem Zahlungskartenunternehmen 8 bereitgestellt und kann beispielsweise, ohne jedoch darauf beschränkt zu sein, eine Kundenkreditkarte eines regionalen Zahlungsverfahrens (wie der Gesellschaft Interac® oder China Union Pay®) oder eine Kreditkarte eines der Kreditkartenunternehmen wie MasterCard®, Visa®, American Express®, JCB® und Discover® sein. Andere Beispiele für eine Zahlungskarte sind denkbar, ohne vom Umfang der vorliegenden Technologie abzuweichen. Die Zahlungskarte kann Daten enthalten und/oder bereitstellen, die durch einen Magnetstreifen, einen Smart-Kartenchip und/oder durch ein Tag mit einer RFID-Schaltung, Funkfrequenzidentifizierungsschaltung, Radio Frequency Identification-Schaltung, auf das Finanzkonto des Käufers bezogen sind. Das Tag, das RFID-Schaltungen einschließt, kann kontaktlose Transaktionsfähigkeiten bereitstellen, insbesondere kontaktlose Transaktionsfähigkeiten, die Europay-, MasterCard- und Visa-(EMV)-Sicherheitsstandards (z. B. Visa Paywave®, MasterCard PayPass®, American Express ExpressPay®, Interac Flash®, DiscoverZip®) entsprechen. Die Daten, die sich auf das Finanzkonto des Käufers beziehen, können jede Art von Daten sein, die es ermöglichen, ein Finanzkonto während einer Transaktion zu identifizieren. Zum Beispiel, ohne jedoch darauf beschränkt zu sein, können solche Daten Schlüssel, Zertifikate und Zahlungskartennummern einschließen. In einigen Ausführungsformen können die Zahlungskartennummern als primäre Kontonummer, Primary Account Number, PAN, ausgeführt sein. In einigen Ausführungsformen speichert das Zahlungskartenunternehmen 8 Daten in Bezug auf die Person, an die die Zahlungskarte ausgegeben wird, wie den Käufer 4. Solche Informationen können den Namen eines Karteninhabers, eine der Person zugeordnete Adresse und/oder Informationen bezüglich einer mobilen Geldbörse der Person einschließen.
  • Im veranschaulichten Ausführungsbeispiel steht der Verkäufer 2 in einer vertraglichen Beziehung mit einem Finanzinstitut 11, das ein Finanzkonto des Verkäufers führt. Das Finanzinstitut 11 kann eine Bank sein, die das Girokonto des Verkäufers und/oder Kredit-, Kundenkredit- oder Prepaid-Kartenkonto verwaltet, das mit dem Zahlungskartenunternehmen 8 interagieren kann. Das Finanzinstitut 11 ermöglicht dem Verkäufer 2 die Durchführung von Finanztransaktionen über einen Server 20. Der Server 20 kann dazu konfiguriert sein, Zahlungsendgeräte zu verwalten und/oder Transaktionen zur Zahlungsannahme durch den Verkäufer 2 durchzuführen. Zum Beispiel kann der Server 20 auf der Hive™-Plattform von Mobeewave oder einer beliebigen anderen geeigneten Plattform basieren.
  • Gemäß Ausführungsformen der vorliegenden Technologie kann der Server 20 mit einem Identifikations-Verifizierungsdienst (ID-Verifizierungsdienst) 22, einem Kommunikationsdienst 24, einem Lokalisierungsdienst 25 und einem Verifizierungs- & Authentifizierungsdienst 26 interagieren. In einigen Ausführungsformen kann der Kommunikationsdienst 24 einen Kurznachrichtendienst (SMS-Dienst) implementieren. Als Beispiel, ohne jedoch darauf beschränkt zu sein, kann der ID-Verifizierungsdienst 22 als PayFone™ oder Whitepages Pro™-API ausgeführt sein. Der ID-Verifizierungsdienst 22 kann das Abrufen eines Namens und/oder einer Adresse, die einer Telefonnummer oder einer Telefon-ID zugeordnet ist, ermöglichen. Als ein Beispiel kann der Kommunikationsdienst 24 das automatische Senden von SMS-Nachrichten ermöglichen, wie an die Verkäufervorrichtung 102 und/oder die Käufervorrichtung 104. Als Beispiel, ohne jedoch darauf beschränkt zu sein, kann der Kommunikationsdienst 24 als Twilio™ SMS-API ausgeführt sein.
  • Der Lokalisierungsdienst 25 kann einen Standort der Verkäufervorrichtung 102 und/oder einen Standort der Käufervorrichtung 104 bestimmen. Diese Standorte können auf mehrere Arten erhalten werden, zum Beispiel durch Anfordern von Positionen direkt von den Vorrichtungen 102 oder 104, die Selbstlokalisierungsdienste betreiben können. Positionen der Verkäufervorrichtung 102 und/oder der Käufervorrichtung 104 können auch indirekt festgelegt werden, zum Beispiel durch Abfragen von Betreibern, die den Vorrichtungen 102 zugeordnet sind, oder durch Abfragen anderer telefonnummernbasierter Positionsdienste wie PayFone™. In einigen Ausführungsformen kann die Käufervorrichtung 104 den Lokalisierungsdienst 25 mit seiner aktuellen Position kontinuierlich aktualisieren (z. B. über eine Lokalisierungsverfolgungsfunktionalität). In einigen Ausführungsformen kann die Positionsbestimmung auf satellitengestützten Funknavigationssystemen (z. B. dem globalen Positionsbestimmungssystem (GPS), dem Galileo-Positionsbestimmungssystem usw.) und/oder einem Netzwerk von Vorrichtungen basieren, deren Positionen bekannt sind (z. B. dem Funkbakensystem). In einigen Ausführungsformen kann die Positionierung auch als Näherungserfassung bezeichnet werden. In einigen Ausführungsformen kann die Positionierung auch von dem Webbrowser stammen, der auf den Selbstlokalisierungsdienst der Vorrichtung zugreifen kann. In einigen Ausführungsformen kann die Positionierung von der IP-Adresse abgeleitet werden, die von der Käufervorrichtung verwendet wird, um die Webseite zu laden. Mehrere Variationen, wie die Lokalisierung/Positionierung/Näherungserfassung implementiert werden kann, können in Betracht gezogen werden, ohne vom Umfang der vorliegenden Technologie abzuweichen. In einigen Ausführungsformen können die Koordinaten der Käufervorrichtung aus dem Link abgerufen werden, der an den Käufer aus der Textnachricht gesendet wird. In einer anderen können die Koordinaten entsprechend einer App auf dem Käufertelefon übertragen werden (ob eine dedizierte heruntergeladene App oder Teil der Betriebssystem-App (z. B. Google OS) oder Teil einer anderen App, die GPS-Berechtigungen für andere Dinge verwendet (z. B. Google Maps) und Koordinaten auf Anforderung kommuniziert. Wenn sich der Standort der Käufervorrichtung 104 und der Standort der Verkäufervorrichtung 102 in der Nähe befinden, wird der Server 20 daraus ableiten, dass der Käufer 4 tatsächlich vor dem Verkäufer 2 steht und/oder physisch im Geschäft des Verkäufers 2 anwesend ist. An dieser Stelle kann der Server 20 ohne weitere Kommunikation zwischen der Verkäufervorrichtung 102 und der Verkäufervorrichtung 104 darauf schließen, dass sich der Käufer 4 in der Nähe des Verkäufers 2 befindet. Da zum Beispiel bestätigt wird, dass sich die Käufervorrichtung 104 in der Nähe der Verkäufervorrichtung 102 befindet, wird möglicherweise keine Textnachricht an die Käufervorrichtung 104 gesendet, mit der der Käufer 4 bestätigen soll, dass der Käufer 4 beabsichtigt, diese Transaktion durchzuführen. Dadurch kann sich die Notwendigkeit für Käufer 4 verringern, auf sein Telefon zuzugreifen (Käufervorrichtung 104) und Maßnahmen zu ergreifen, um die Transaktion zu genehmigen.
  • Der Verifizierungs- & Authentifizierungsdienst 26 kann Daten über die Transaktion, die verwendete Karte, die Händlerinformationen und die Vorrichtung des Karteninhabers empfangen, um eine Risikobewertung durchzuführen und zu entscheiden, den Karteninhaber ohne weitere Verifizierung zu authentifizieren oder den Karteninhaber mit zusätzlichen Verifizierungen zu hinterfragen. Beispielsweise kann der Verifizierungs- & Authentifizierungsdienst 26 ein 3DS-Service-Provider sein und als Cardinal Commerce oder NuData ausgeführt sein.
  • In einigen alternativen Ausführungsformen kann der ID-Verifizierungsdienst 22 durch den Server 20 betrieben werden, der mit einem oder mehreren mobilen Betreibern und/oder einem oder mehreren Vorrichtungsanbietern der Käufervorrichtung 104 (z. B. Apple, Samsung usw.) kommunizieren kann, um bestimmte Informationen zu erhalten. In einigen Ausführungsformen können die Informationen eine Dauer umfassen, wie lange die Käufervorrichtung 104 mit dem Käufer 4 gehalten/assoziiert wurde, Standortinformationen, Informationen über menschliches Verhalten, die der eine oder die mehreren mobilen Betreiber unter Umständen über den Käufer 4 gesammelt haben, Mobiltelefonrechnungsinformationen und/oder Kaufhistorie (z. B. Kaufhistorie von Apps). Die Informationen können durch den Server 20 genutzt und/oder kompiliert werden, um eine zusätzliche Sicherheitsstufe hinzuzufügen, die das Bestätigen ermöglicht, dass der Käufer 4 der tatsächliche Eigentümer der Käufervorrichtung 104 ist und/oder dass der Käufer 4 das Individuum ist, das der Käufervorrichtung 104 zugeordnet ist. Andere Alternativen können ebenfalls in Betracht gezogen werden, wie alternative Ansätze, die biometrische Informationen über den Käufer 4 nutzen, Analytik, soziale Physik basierend auf einer großen Menge an Verhaltensdaten kombiniert mit der Verwendung von maschinellen Lernalgorithmen, um einen Namen und/oder eine Adresse mit hoher Genauigkeit und Übereinstimmung mit der Mobiltelefonnummer oder Mobiltelefon-ID bereitzustellen. Insbesondere kann die Verwendung von 3D Secure 1.0, 2.0 und späteren Versionen genutzt werden, obwohl es sich um ein Card Not Present-System (System ohne vorliegende Karte) handelt, um den Käufer in diesem Beispiel der Card Present-Transaktion (Transaktion mit vorliegender Karte) zu authentifizieren. Sobald also der Käufer den Link im Text öffnet, öffnet sich ein Browser, der nicht nur eine Genehmigungs-/Ablehnungsanforderung für die Transaktion erzeugen kann, sondern auch Informationen über das Telefon per 3DS-Protokoll an die 3DS-Systeme sendet. Der Browser kann einen SDK enthalten, um Telefoninformationen zu sammeln und mit der Kartennummer zu vergleichen. Falls der Dienst, wie 3D Secure, zusätzliche Authentifizierungsverfahren erfordert, wie Fragen nach persönlicher ID, die Anforderung, dass der Käufer eine Bankanwendung auf dem Telefon öffnet usw., können diese direkt vom geöffneten Browser auf dem Telefon des Käufers abgefragt werden. Im Falle eines von dem Dienst angeforderten Einmalpassworts (One-Time Password, OTP) wird der Dienst das OTP an den Käufer übermitteln oder anderweitig dem Käufer mitteilen, und der Käufer gibt dann das OTP auf der Verkäufervorrichtung ein.
  • In einigen Ausführungsformen kann der Server 20 den Verifizierungs- & Authentifizierungsdienst 26 direkt aufrufen, initiiert durch die Ursprungsvorrichtung (zum Beispiel die Verkäufervorrichtung 102), ohne die Signatur der Käufervorrichtung 104 bereitzustellen, stattdessen kann sie die Signatur der Verkäufervorrichtung 102 einschließen oder nicht, und sie kann ein Flag einschließen oder nicht, um anzugeben, dass die Anforderung von der Verkäufervorrichtung 102 kommt. Wenn der Verifizierungs- & Authentifizierungsdienst 26 auf einem 3DS-Dienst basiert, kann der Aussteller eine risikobasierte Bewertung durchführen oder nicht, um zu entscheiden, ob der Käufer 4 mit einem „Step-up“ hinterfragt werden soll oder nicht. Ein Step-up wird verwendet, um den Käufer 4 mit einem zweiten Faktor zu verifizieren und zu authentifizieren; es kann darin bestehen, dass der Ausstellerserver 10 eine Nachricht an die Käufervorrichtung 104 sendet, wie, aber nicht beschränkt auf, eine SMS mit Einmal-Passwortcode zur Eingabe in die Verkäufervorrichtung 102, oder eine Push-Mitteilung, die den Käufer 4 auffordert, seine Bankanwendung zu öffnen, um eine Transaktion oder Operation nach einer PIN oder biometrischen Verifizierung zu autorisieren. Bei der Authentifizierung wird die Transaktion zur Autorisierung bearbeitet. Obwohl diese Schritte als von dem Aussteller ausgeführt beschrieben werden, können sie von anderen Diensten und/oder Parteien ausgeführt werden. Der „Aussteller“, der die risikobasierte Bewertung und/oder Step-up-Hinterfragung durchführt, kann der Aussteller der „Karte“ sein, oder, wenn der Aussteller nicht für diese Art von Step-up vorbereitet ist, kann ein anderer Dienst (wie ein Kartenschema (z. B. VISA)) die Gesamtheit oder einen Anteil dieser Aktionen durchführen.
  • In einigen Ausführungsformen kann der Server 20 prüfen, ob die Transaktion mit den Mustern des Käufers hinsichtlich Ort und Kostenart (Kauf von Waren oder Dienstleistungen, Betrag usw.) übereinstimmt, indem er die Daten von dem Aussteller 6, dem Zahlungskartenunternehmen 8, dem Ausstellerserver 10 und/oder einem Dritt-Verifizierungsdienst anfordert, der Zugriff auf aggregierte Daten von Ausstellern und Händlern hat. Wenn der Standort des Verkäufers und/oder die Kostenart nicht mit dem Profil des Käufers übereinstimmen, könnten zusätzliche Überprüfungen erforderlich sein.
  • In einigen Ausführungsformen kann der Betreiber des Servers 20 ein Risiko verwalten, das mit der Transaktion verbunden ist, und kann daher der Kartenvereinigung 8 eine höhere Transaktionsgebühr in Rechnung stellen. Der Server 20 kann die Transaktionsgebühr basierend auf einem vorhergesagten Risikoniveau für die Transaktion bestimmen. Der Server 20 kann das Risiko basierend auf den Informationen verwalten, die von dem einen oder den mehreren mobilen Betreibern und/oder dem einen oder den mehreren Vorrichtungsanbietern der Käufervorrichtung 104 gesammelt werden.
  • In einigen Ausführungsformen kann der Server 20 der Kartenvereinigung 8 auch Daten bereitstellen, die aus den gesammelten Informationen erzeugt werden, um es der Kartenvereinigung 8 zu ermöglichen, potenzielle Rückbuchungen zu arbitrieren.
  • Bezug nehmend auf 2 wird nun eine Architektur auf hohem Niveau von bestimmten Komponenten der in 1 gezeigten Umgebung veranschaulicht. Die Verkäufervorrichtung 102 kann ein Mobiltelefon oder ein Tablet sein (wie, ohne jedoch darauf beschränkt zu sein, ein Galaxy™ von Samsung Inc., ein iPhone™ oder ein iPad™ von Apple Inc.), die einen Transaktionsbestätigungsmechanismus betreiben, wie, ohne jedoch darauf beschränkt zu sein, eine Verkaufsstellenanwendung (Point-of-Sale-Anwendung, POS-Anwendung) 206, die es der Verkäufervorrichtung 102 ermöglicht, als Zahlungsterminal zu arbeiten. Die POS-Anwendung 206 kann es der Verkäufervorrichtung 102 ermöglichen, als Zahlungsterminal zu arbeiten, obwohl die Verkäufervorrichtung 102 kein dediziertes Zahlungsterminal ist. Zum Beispiel kann der POS Anwendung 206 auf der Bee™-Technologie von Mobeewave und/oder einer beliebigen anderen geeigneten Plattform für eine POS-Anwendung basieren. Die POS-Anwendung 206 kann gesicherte Finanztransaktionen ermöglichen, indem bestimmte Softwaremodule auf einem isolierten gesicherten Bereich des Prozessors und/oder einem sicheren Element der Verkäufervorrichtung 102 betrieben werden.
  • Die POS-Anwendung 206 ermöglicht es der Verkäufervorrichtung 102, kontaktlos Daten von einer Zahlungseinrichtung 210 über eine Nahfeldkommunikations-Schnittstelle (NFC-Schnittstelle) 208 zu erfassen. Die Zahlungseinrichtung 210 kann eine kontaktlose Zahlungskarte oder eine Vorrichtung sein, die eine kontaktlose Zahlungskarte emuliert (z. B. eine Vorrichtung, die Apple Pay™ oder Samsung Pay™ betreibt). Die von der Zahlungseinrichtung 210 erfassten Daten können eine PAN und/oder beliebige andere Zahlungskartendaten sein. Sobald die Daten erfasst wurden, können sie sicher an den Server 20 übertragen werden.
  • Der Server 20 kann verschiedene Schritte im Zusammenwirken mit dem ID-Verifizierungsdienst 22, dem Kommunikationsdienst 24 und/oder der Käufervorrichtung 104 ausführen, um eine Finanztransaktion zwischen dem Verkäufer 2 und dem Käufer 4 sicher abzuschließen. In einigen Ausführungsformen kann die Transaktion eine Card-Present-Transaktion (Karte vorhanden-Transaktion, CP-Transaktion) sein, die von einem CP-Transaktionsprozessor 202 ausgeführt wird, oder eine Card-Non-Present-Transaktion, Karte-nicht-vorhanden-Transaktion, CnP-Transaktion, die von einem CnP-Transaktionsprozessor 204 ausgeführt wird. Der CP-Prozessor 202 und/oder der CnP-Prozessor 204 kann von dem Server 20 und/oder dem Finanzinstitut 11 und/oder dem Zahlungskartenunternehmen 8 betrieben werden.
  • Die Käufervorrichtung 104 kann verwendet werden, um eine Transaktion zwischen dem Käufer 4 und dem Verkäufer 2 zu autorisieren. Um eine Transaktion zu autorisieren, kann die Käufervorrichtung 104 einen Standort der Käufervorrichtung 104 an den Lokalisierungsdienst 25 übertragen. Der Standort kann durch ein GPS oder ein anderes Positionierungssystem in der Käufervorrichtung 104 bestimmt werden. Der Standort kann unter Verwendung des Webbrowsers 212 übertragen werden. In ähnlicher Weise kann der Lokalisierungsdienst 25 eine Position der Verkäufervorrichtung erfassen. Der Standort der Verkäufervorrichtung 102 kann als ein bekannter physischer Standort des Verkäufers 2 angenommen werden. Der Standort der Käufervorrichtung 104 und der Verkäufervorrichtung 102 kann verglichen werden, um zu bestimmen, ob die Transaktion autorisiert sein sollte.
  • Die Käufervorrichtung 104 kann eine Signatur übertragen, wie eine Audiosignatur und/oder eine Signatur, die unter Verwendung eines drahtlosen Protokolls wie Bluetooth, NFC oder Wi-Fi emittiert wird. Nachdem eine Transaktion initiiert wurde, kann die Käufervorrichtung eine Anforderung zum Emittieren der Signatur empfangen, wie von dem Server 20. Der Käufer 4 kann bewirken, dass die Käufervorrichtung 104 die Signatur emittiert, wie durch Öffnen einer Anwendung auf der Käufervorrichtung 104. Die Signatur kann von der Verkäufervorrichtung 102 erfasst werden. Dies kann ein Hinweis darauf sein, dass sich die Käufervorrichtung 104 in der Nähe der Verkäufervorrichtung 102 befindet. Anstatt zu bewirken, dass die Käufervorrichtung 104 die Signatur emittiert, kann die Käufervorrichtung 104 die Signatur als Teil normaler Operationen emittieren. Zum Beispiel kann eine MAC-Adresse, eine Bake oder eine andere Angabe der Käufervorrichtung 104 von der Verkäufervorrichtung 102 erfasst werden. Die Signatur der Käufervorrichtung 104 kann von einer anderen Vorrichtung abgefangen werden, die dem Verkäufer 2 zugeordnet ist, wie einem drahtlosen Zugangspunkt.
  • Wenn bestimmt wird, dass sich die Käufervorrichtung 104 nicht in der Nähe der Verkäufervorrichtung 102 befindet, oder wenn der Standort entweder der Käufervorrichtung 104 oder der Verkäufervorrichtung 102 nicht bestimmt werden kann, kann eine Nachricht an die Käufervorrichtung 104 gesendet werden, die anfordert, dass der Käufer 4 die Transaktion autorisiert. Eine Nachricht kann an die Käufervorrichtung 104 gesendet werden, wie von dem Server 20, die anfordert, dass der Käufer 4 die Transaktion autorisiert. Der Käufer 4 kann einen Webbrowser 212 verwenden, um zu bestätigen, dass er die Transaktion autorisieren oder ablehnen möchte. Die Nachricht kann als Textnachricht an die Käufervorrichtung 104 gesendet werden. Der Käufer 4 kann auf die Textnachricht antworten und/oder eine WEB-URL in der Textnachricht öffnen, um die Transaktion zu autorisieren oder abzulehnen.
  • Unter Bezugnahme nun auf 3 und 4 sind in den Figuren Flussdiagramme von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer sicheren kontaktlosen Transaktion veranschaulicht. In bestimmten Anwendungsfällen und/oder Rechtsprechungen können kontaktlose Transaktionen, die einen vorgegebenen Betrag überschreiten, einen zusätzlichen Authentifizierungsschritt erfordern, bevor eine Transaktion verarbeitet werden kann. Transaktionen können, wenn der Kartenzähler einen bestimmten Zählerstand passiert, oder aus anderen Gründen einen zusätzlichen Authentifizierungsschritt erfordern, bevor eine Transaktion verarbeitet werden kann. Ein solcher zusätzlicher Authentifizierungsschritt kann als Karteninhaber-Verifizierungsverfahren (CVM) bezeichnet werden. Als ein Beispiel kann eine vorgegebene Grenze für kontaktlose Transaktionen 100 $ sein, sodass, wenn ein Betrag einer Transaktion 100 $ überschreitet, möglicherweise eine CVM-Aktion vorgenommen werden muss, bevor eine Transaktion verarbeitet werden kann (das Fehlschlagen des Abschließens der CVM-Aktion führt in der Regel dazu, dass die Transaktion abgelehnt wird). Bei herkömmlichen Ansätzen kann es für die CVM-Aktion erforderlich sein, dass der Karteninhaber (z. B. auf der Verkäufervorrichtung 102) eine physische Interaktion der Zahlungskarte mit dem Terminal (Lesen von auf einem Chipsatz der Zahlungskarte befindlichen Daten) und/oder eine persönliche Identifikationsnummer (PIN) eingibt. Solche herkömmlichen CVM-Aktionen können, zumindest in bestimmten Kontexten, umständlich und/oder unsicher sein. Die vorliegende Technologie bietet ein weniger störendes Authentifizierungsverfahren, das ohne die Eingabe einer PIN auskommen kann, während eine zusätzliche Sicherheitsschicht bereitgestellt wird, die eine kontaktlose Transaktion ermöglicht, auch wenn aus irgendeinem Grund eine CVM-Anforderung ausgelöst wird.
  • Gemäß der Flussdiagrammdarstellung von 3 ermöglicht eine auf der Verkäufervorrichtung 102 ablaufende POS-Applikation ein kontaktloses Lesen einer Zahlungseinrichtung (z. B. einer Zahlungskarte). Die PAN wird von der Verkäufervorrichtung 102 erfasst (z. B. erfasst von dem sicheren Element und/oder TEE, die auf dem Prozessor der Verkäufervorrichtung 102 ausgeführt werden), verschlüsselt und an den Server 20 übertragen. Der Server 20 fragt ein Register, beispielsweise eine Datenbank, ab, um zu bestimmen, ob die PAN bereits einer Käuferkennung, wie einer Telefonnummer, zugeordnet ist. In einigen Fällen kann das Register auch eine Kennung umfassen, wie einen Karteninhabernamen und/oder eine Karteninhaberadresse der Person, die der PAN zugeordnet ist. Besteht eine Zuordnung, so übermittelt der Server 20 an den Kommunikationsdienst 24 eine Aufforderung, eine SMS-Nachricht an die Käufervorrichtung 104 zu senden. Obwohl auf eine SMS-Nachricht Bezug genommen wird, ist dieser Gesichtspunkt nicht einschränkend, und andere Arten von Nachrichten können in Betracht gezogen werden, wie Mitteilungsnachrichten. Besteht keine Zuordnung (kann z. B. keine Telefonnummer der PAN zugeordnet werden), so fordert der Server 20 auf der Verkäufervorrichtung 102 den Käufer 4 auf, eine Kennung, wie seine Mobiltelefonnummer, einzugeben.
  • Nach Empfang der Kennung (z. B. Mobilfunknummer) durch den Server 20 fragt der Server 20 den ID-Verifikationsdienst 22 ab, der einen Namen und/oder eine Adresse und/oder ein anderes der bereitgestellten Kennung zugeordnetes Element sucht. Wird keine Übereinstimmung festgestellt, so übernimmt der Server 20 das Ablehnen der Transaktion oder das Ergreifen weiterer Maßnahmen zur Überprüfung der Transaktion. Wird eine Übereinstimmung festgestellt, so wird die Kennung, wie Name und/oder Adresse, an den Server 20 übermittelt. In einigen Ausführungsformen kann der Server 20 auch zusätzliche Daten an den ID-Verifizierungsdienst 22 liefern, wie, aber nicht beschränkt auf, Standort, Verkäufertyp (z. B. Verkäuferkategoriecode) und einen Transaktionsbetrag. In einigen Ausführungsformen verwendet der ID-Verifizierungsdienst 22 diese Daten, um eine Vertrauensbewertung oder dergleichen zu berechnen, die an den Server 20 zurückgesendet wird, der sie verwenden kann, um zu entscheiden, mit der Transaktion fortzufahren oder sie abzulehnen.
  • Sobald eine Telefonnummer identifiziert wird (d. h. am Register des Servers 20 identifiziert oder vom ID-Verifikationsdienst 22 übermittelt wird), kann der Server 20 anfordern, dass eine Nachricht, wie eine SMS-Nachricht oder eine Mitteilungsnachricht, vom Kommunikationsdienst 24 an die Käufervorrichtung 104 gesendet wird. Der Server 20 kann auch gleichzeitig auf der Verkäufervorrichtung 102 anzeigen, dass die Nachricht gesendet wurde. Optionen können auch auf der Verkäufervorrichtung 102 angezeigt werden. Die von dem Kommunikationsdienst 24 an die Käufervorrichtung 104 gesendete SMS-Nachricht oder Mitteilungsnachricht kann einen Link umfassen, auf den zu klicken ist, um die Transaktion zu bestätigen/zu autorisieren/abzuschließen. Die SMS-Nachricht oder Mitteilungsnachricht kann auch zusätzliche Informationen wie den Verkäufernamen, den Betrag der Transaktion, die letzten vier Ziffern der Zahlungskarte, das Datum und die Uhrzeit, einen Transaktionsbestätigungs-Link/-Button und/oder eine Ablehnungs-Link/-Button umfassen. Nach dem Empfang kann der Käufer 4 die Transaktion bestätigen/autorisieren/abschließen oder ablehnen/verweigern. In einigen Ausführungsformen kann es erforderlich sein, dass der Käufer 4 die Käufervorrichtung 104 entsperrt, bevor er den Schritt des Bestätigens/Autorisierens/Abschließens oder Ablehnens/Verweigerns der Transaktion abschließt. Das Entriegeln kann über Code, Muster, Gesichtserkennung und/oder Fingerabdruck abgeschlossen werden, wodurch eine Bestätigung ermöglicht wird, dass der Käufer 4 der Käufervorrichtung 104 ordnungsgemäß zugeordnet ist. Dieser Schritt führt zu einer verstärkten Sicherheitsstufe, die der Transaktion zugeordnet ist.
  • Wenn der Käufer 4 auf die Nachricht antwortet, kann der Verifizierungs- und Authentifizierungsdienst 26 den Käufer 4 authentifizieren. Eine Signatur der Käufervorrichtung 104 kann an den Verifizierungs- und Authentifizierungsdienst 26 gesendet werden. Die Signatur kann Informationen einschließen, die die Käufervorrichtung 104 beschreiben, wie einen Hersteller, ein Betriebssystem, eine Zeitzone, einen Webbrowser usw. der Käufervorrichtung 104. Informationen, die die Vorrichtung 104 beschreiben, können an den Verifizierungs- und Authentifizierungsdienst 26 gesendet werden. Der Verifizierungs- und Authentifizierungsdienst 26 kann die empfangenen Informationen mit zuvor aufgezeichneten Informationen über den Käufer 4 vergleichen. Wenn die Informationen übereinstimmen, kann der Verifizierungs- und Authentifizierungsdienst den Käufer 4 authentifizieren und es der Transaktion ermöglichen, fortzufahren. Andernfalls kann der Verifizierungs- und Authentifizierungsdienst 26 und/oder jedes andere System, wie der Ausstellerserver 10, anfordern, dass der Käufer 4 eine Aktion durchführt, um sich selbst zu authentifizieren. An die Käufervorrichtung 104 kann eine Nachricht gesendet werden, die anfordert, dass der Käufer 4 eine Anwendung auf der Käufervorrichtung 104 aktiviert, wie eine Bankanwendung, und bestätigt, dass der Käufer 4 die Transaktion autorisieren möchte. Der Verifizierungs- und Authentifizierungsdienst 26 kann dem Käufer 4 eine Nachricht mit einem Einmalpasswort (OTP) senden, das der Käufer 4 in die Verkäufervorrichtung 102 eingeben kann. Nach Erhalt einer Bestätigung, dass das korrekte OTP in die Verkäufervorrichtung 102 eingegeben wurde, kann der Verifizierungs- und Authentifizierungsdienst 26 den Käufer 4 authentifizieren und es der Transaktion ermöglichen, fortzufahren. Wenn der Verifizierungs- und Authentifizierungsdienst 26 den Käufer 4 nicht authentifiziert, kann die Transaktion abgebrochen werden. Es versteht sich, dass ein anderes System einige oder alle Schritte zur Authentifizierung durchführen kann. Zum Beispiel kann der Ausstellerserver 10 die OTP- oder eine andere Authentifizierungsanforderung an die Käufervorrichtung 104 senden.
  • In manchen Ausführungsformen kann eine Anwendung auf der Käufervorrichtung 104 und/oder ein Teil des Betriebssystems (OS) auf der Käufervorrichtung 104 die gesendete Nachricht lesen (z. B. Mitteilung, SMS), sie entschlüsseln und damit Maßnahmen ergreifen, anstatt den Käufer direkt auf die Nachricht zugreifen zu lassen. Zusätzlich kann die Nachricht direkt an eine Anwendung oder das OS auf der Vorrichtung gerichtet sein, wodurch eine Aktion ausgelöst wird. Es kann auch sein, dass kein Käufereingriff erforderlich ist, wenn die Anwendung oder das OS den Käufer bereits identifiziert hat und an seiner Stelle antworten kann.
  • Wenn der Käufer 4 die Transaktion ablehnt/verweigert, löscht der Server 20 die Transaktion und überträgt eine Löschnachricht an die Verkäufervorrichtung 102. Wenn der Käufer 4 die Transaktion bestätigt/autorisiert/abschließt, so unternimmt es der Server 20, eine Anforderung zur Autorisierung der Transaktion an den Ausstellerserver 10 zu senden. Die Anforderung umfasst die PAN und alle anderen Informationen zum Anlegen oder Eingeben der Kartenanforderungen. Dies kann einen Zip- oder Kartenverifikationswert (CVV) oder eine andere Information einschließen, ähnlich einer Transaktion mit nicht vorhandener Karte. Alternativ kann ein Dritter die Haftung dafür übernehmen, wenn die Transaktion betrügerisch ist, und den Aussteller zur Genehmigung auffordern. Der Ausstellerserver 10 kann die Anforderung verarbeiten und bestimmen, ob die Transaktion autorisiert werden soll. Anschließend wird eine Antwort an den Remote-Server 20 und/oder die Verkäufervorrichtung 102 übertragen.
  • Die an den Ausstellerserver 10 gesendete Anforderung kann als eine Anforderung „Karte nicht vorhanden“ (CnP) angesehen werden, da sie Daten (d. h. PAN, Karteninhabername und/oder Adresse) umfasst, die erforderlich sind, um eine solche CnP-Transaktion abzuschließen. Ein Teil solcher Daten (d. h. PAN, Karteninhabername und/oder -Adresse) ist in der Regel aus einem kontaktlosen Lesen einer Zahlungskarte nicht verfügbar, da das Lesen in der Regel auf das Extrahieren der PAN beschränkt ist. Da die Transaktion außerdem als eine CnP-Transaktion verarbeitet wird, unterliegt sie nicht dem Grenzwert, der in bestimmten Fällen für eine kontaktlose Transaktion festgelegt ist. In einigen Ausführungsformen wird angenommen, dass der Ausstellerserver 10 die CnP-Transaktion nur autorisieren wird, wenn die PAN mit dem bereitgestellten Karteninhabernamen und/oder der bereitgestellten Karteninhaberadresse übereinstimmt, und andernfalls die Transaktion ablehnen wird.
  • Bezug nehmend auf 4 veranschaulicht das Flussdiagramm eine alternative Abfolge von Schritten, die zwischen dem Server 20 und dem Ausstellerserver 10 ausgeführt werden können, um die Transaktion zu autorisieren. In dieser alternativen Ausführungsform wird eine Anforderung, die die PAN und den Namen des Karteninhabers umfasst, mit einem geringen Betrag (unterhalb des festgelegten Grenzwerts für kontaktlose Transaktionen) an den Ausstellerserver 10 gesendet. Die Anfrage wird als CnP Pre-Autorisierungsanfrage gesendet. Der Ausstellerserver 10 kann eine Vorautorisierungsbestätigung zurückgeben, die vom Server 20 ungültig gemacht werden kann. Der Server 20 kann dann eine CP-Anforderung übertragen, die ein CVM-Flag umfasst. Der Server 20 kann es übernehmen, das CVM zu übertragen, da die Transaktion zuvor über die an die Käufervorrichtung 104 gesendete SMS-Nachricht oder Mitteilungsnachricht verifiziert wurde. Der Ausstellerserver 10 kann dann die CP-Anforderung empfangen und eine Transaktionsgenehmigung bzw. Transaktionsverweigerung zurückgeben.
  • Nachdem unter Bezugnahme auf 1 bis 4 einige nicht einschränkende beispielhafte Fälle von Systemen und computerimplementierten Verfahren beschrieben wurden, die in Verbindung mit der Durchführung einer sicheren kontaktlosen Transaktion verwendet werden, wird nun unter Bezugnahme auf 5 eine allgemeine Lösung beschrieben.
  • Genauer gesagt, zeigt 5 ein Flussdiagramm, das ein computerimplementiertes Verfahren 500 veranschaulicht, das Ausführungsformen der vorliegenden Technologie implementiert. Das computerimplementierte Verfahren von 5 kann ein computerimplementiertes Verfahren umfassen, das durch einen Prozessor der Verkäufervorrichtung 102, der Käufervorrichtung 104 und/oder des Servers 20 und/oder eines oder mehrerer Server ausführbar ist, wobei das Verfahren eine Reihe von Schritten umfasst, die durch die Verkäufervorrichtung 102, die Käufervorrichtung 104 und/oder den Server 20 und/oder einen oder mehrere Server auszuführen sind.
  • Das computerimplementierte Verfahren von 5 kann zum Beispiel dadurch ausgeführt werden, dass ein Prozessor Programmanweisungen ausführt, die zum Beispiel in Direktzugriffsspeicher und/oder ein sicheres Element geladen wurden.
  • Das Verfahren 500 startet in Schritt 502, indem es eine Zahlungsanforderung von der Verkäufervorrichtung 102 empfängt. Die Zahlungsanforderung umfasst eine PAN. Die Zahlungsanforderung kann einen Betrag, einen Indikator des Verkäufers, wie eine Händlerkennung, und/oder beliebige andere Informationen bezüglich der Transaktion umfassen.
  • In Schritt 504 fragt das Verfahren 500 ein Register ab, um zu bestimmen, ob die PAN bereits einer Käuferkennung, wie einer Mobiltelefonnummer, zugeordnet ist. Wenn zum Beispiel der Käufer zuvor während einer Transaktion seine Telefonnummer eingegeben hat, kann die Telefonnummer des Käufers in Verbindung mit der PAN gespeichert worden sein. Wenn eine Zuordnung besteht, fährt das Verfahren mit Schritt 512 fort, indem es das Senden einer Nachricht an eine Käufervorrichtung 104 anfordert, wobei die Nachricht die Autorisierung der Transaktion anfordert. Wenn keine Zuordnung besteht, fährt das Verfahren mit Schritt 508 fort, indem es an die Verkäufervorrichtung 102 eine Anforderung sendet, den Käufer aufzufordern, eine Kennung, wie eine Mobiltelefonnummer, einzugeben. In Schritt 510 wird, sobald die Kennung von dem Käufer empfangen wird, ein ID-Verifizierungsdienst abgefragt, um einen Namen und/oder eine Adresse oder ein anderes Element zu suchen, das der bereitgestellten Kennung zugeordnet ist. Wird keine Übereinstimmung festgestellt, so übernimmt der Server 20 das Ablehnen der Transaktion bei Schritt 514. Wird eine Übereinstimmung festgestellt, so wird die Kennung, wie Name und/oder Adresse, an den Server 20 übermittelt.
  • In Schritt 512 wird eine Nachricht an die Käufervorrichtung 104 gesendet, um die Autorisierung der Transaktion anzufordern. Sobald die Autorisierung von der Käufervorrichtung 104 empfangen wurde, sendet der Server 20 in Schritt 516 die Transaktionsanforderung, die die PAN und den Karteninhabernamen (und optional die Karteninhaberadresse) enthält, an den Ausstellerserver 6, der die Transaktionsanforderung verarbeitet. Obwohl die Transaktionsanforderung hier als an den Ausstellerserver 10 gesendet beschrieben wird, versteht es sich, dass die Transaktionsanforderung an verschiedene andere Entitäten und/oder Server gesendet werden kann. Zum Beispiel kann die Transaktionsanforderung an den Verkäufer, einen Erfasser, einen Prozessor usw. gesendet werden. Die Transaktionsanforderung kann zunächst an eine andere Entität gesendet und dann an den Ausstellerserver 10 weitergeleitet werden.
  • Bezug nehmend nun auf 6 ist eine Flussdiagrammdarstellung von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer sicheren kontaktlosen Transaktion gemäß einer ersten alternativen Ausführungsform veranschaulicht.
  • In dieser ersten alternativen Ausführungsform fragt der Server 20, sobald die PAN durch den Server 20 von der Verkäufervorrichtung 102 empfangen wird, ein Register ab, um zu bestimmen, ob die PAN bereits einer Käuferkennung zugeordnet ist. Besteht eine Zuordnung, so fordert der Server 20 eine Position der Käufervorrichtung 104 an. Besteht keine Zuordnung, so fordert der Server 20 auf der Verkäufervorrichtung 102 den Käufer 4 auf, eine Kennung, wie z. B. seine/ihre Mobilfunknummer, einzugeben. Sobald die Kennung erhalten wurde, kann der Server 20 dann eine Position der Käufervorrichtung 104 anfordern.
  • In einigen Ausführungsformen kann die Anforderung zum Erhalten der Position der Käufervorrichtung 104 durch die Verkäufervorrichtung 102 oder durch den Server 20 an die Käufervorrichtung 104 oder an den Lokalisierungsdienst 25 gesendet werden. Das Senden der Anforderung kann auf der Käuferkennung basieren, die der PAN zugeordnet ist (z. B. einer Mobiltelefonnummer). In alternativen Ausführungsformen kann die Anforderung die Käuferkennung umfassen (z. B. in Implementierungen, in denen die Anforderung an den Lokalisierungsdienst 25 gesendet wird). Im Gegenzug erhält der Server 20 von der Käufervorrichtung 104 und/oder von der Verkäufervorrichtung 102 und/oder vom Lokalisierungsdienst 25 eine Position (z. B. Koordinaten) der Käufervorrichtung 104. Die Position der Käufervorrichtung kann eine exakte Position sein, wie ein Satz von Koordinaten, oder kann als ein Bereich definiert sein.
  • In einigen Ausführungsformen kann die Position der Verkäufervorrichtung 102 dem Server 20 vorab bekannt sein, wie ein bekannter physischer Standort des Verkäufers 2. In einigen anderen Ausführungsformen kann die Position der Verkäufervorrichtung 102 durch den Server 20 von der Verkäufervorrichtung 102 (z. B. beim Durchführen der Transaktion) und/oder vom Lokalisierungsdienst 25 empfangen werden.
  • Sobald die Position der Käufervorrichtung 104 und die Position der Verkäufervorrichtung 102 bekannt sind, kann der Server 20 bestimmen, ob eine Position der Käufervorrichtung 104 und eine Position der Verkäufervorrichtung 102 übereinstimmen, um festzustellen, ob sich der Käufer tatsächlich in einer Nähe der Verkäufervorrichtung 102 befindet. Der Server 20 kann bestimmen, ob sich die Käufervorrichtung 104 innerhalb eines vorgegebenen Schwellenabstands von der Verkäufervorrichtung 102 befindet. Dieser vom Server 20 ausgeführte Vergleichsschritt kann als Authentifizierungsschritt qualifiziert werden.
  • Der Server 20 kann bestimmen, wie nahe die Käufervorrichtung 104 und die Verkäufervorrichtung 102 voneinander entfernt sind. Wenn ein Abstand zwischen der Käufervorrichtung 104 und der Verkäufervorrichtung 102 unter einem gegebenen Schwellenwert liegt (z. B. einem Schwellenwert, der angesichts des Kontexts des Abschlusses einer Finanztransaktion eine akzeptable Nähe festlegt), so kann festgestellt werden, dass der Käufer in der Nähe der Verkäufervorrichtung steht und dass er/sie der-/diejenige ist, der/die die Karte auf die Verkäufervorrichtung 102 gelegt hat. In solchen Fällen kann der Server 20 es übernehmen, eine Anforderung zum Autorisieren der Transaktion gemäß der zuvor in Verbindung mit 3-5 beschriebenen Abfolge von Schritten an den Ausstellerserver 10 zu senden.
  • Wenn ein Abstand zwischen der Käufervorrichtung 104 und der Verkäufervorrichtung 102 über dem gegebenen Schwellenwert liegt, kann festgestellt werden, dass der Käufer nicht in der Nähe der Verkäufervorrichtung steht und/oder dass er/sie nicht der-/diejenige ist, der/die auf die Karte auf die Verkäufervorrichtung 102 gelegt hat. In einigen Ausführungsformen kann die Transaktion unter solchen Umständen abgebrochen werden. In alternativen Ausführungsformen kann der Server unter solchen Umständen zu einem alternativen Authentifizierungsschritt übergehen. Als ein Beispiel kann der alternative Authentifizierungsschritt das Anfordern, durch den Server 20, einer Nachricht, wie einer SMS-Nachricht oder einer Mitteilungsnachricht, implementieren, die durch den Kommunikationsdienst 24 an die Käufervorrichtung 104 zu senden ist.
  • Sobald sie empfangen wurde, kann der Käufer 4 die Transaktion gemäß der Abfolge von Schritten bestätigen/autorisieren/abschließen oder ablehnen/verweigern, die zuvor in Verbindung mit 3-5 beschrieben wurden. Wenn der Käufer aufgefordert wird, auf die Mitteilungsnachricht zu antworten, kann der Verifizierungs- und Authentifizierungsdienst 26 aufgerufen werden, um den Käufer 4 zu authentifizieren. Der Käufer 4 kann aufgefordert werden, die Transaktion unter Verwendung einer Anwendung auf der Käufervorrichtung 104 zu verifizieren, und/oder dem Käufer 4 kann ein OTP bereitgestellt werden, die in die Verkäufervorrichtung 102 einzugeben ist. In einigen Ausführungsformen kann der alternative Authentifizierungsschritt auch ausgeführt werden, wenn der Server 20 die Position der Käufervorrichtung 104 und/oder die Position der Verkäufervorrichtung 102 nicht erhalten konnte. In noch einigen alternativen Ausführungsformen kann der alternative Authentifizierungsschritt auch ausgeführt werden, selbst wenn bestimmt wurde, dass die Position der Käufervorrichtung 104 und die Position der Verkäufervorrichtung 102 übereinstimmen.
  • Bezug nehmend auf 7 ist nun ein Flussdiagramm dargestellt, das ein computerimplementiertes Verfahren 700 veranschaulicht, das Schritte der Ausführungsform der ersten alternativen Ausführungsform von 6 implementiert. Das Verfahren 700 umfasst die Schritte 702, 704, 708, 710 und 720, die den Schritten 502, 504, 508, 510 und 514 des Verfahrens 500 ähnlich sind.
  • In einem Schritt 712 führt das Verfahren 700 die Anforderung aus, eine Position der Käufervorrichtung 104 bereitzustellen. Wie in Verbindung mit der Beschreibung von 6 ausführlich beschrieben, kann die Position der Käufervorrichtung 104 von der Käufervorrichtung 104 und/oder von der Verkäufervorrichtung 102 und/oder von dem Lokalisierungsdienst 25 erhalten werden.
  • In einem Schritt 714 bestimmt das Verfahren 700, ob eine Position der Verkäufervorrichtung 102 und eine Position der Käufervorrichtung 104 übereinstimmen. Wenn die Position der Käufervorrichtung 104 innerhalb eines Schwellenabstands von der Position der Verkäufervorrichtung 102 liegt, können die Positionen als übereinstimmend betrachtet werden. Wenn Übereinstimmung vorliegt, fährt das Verfahren 700 mit Schritt 720 fort, der dem Schritt 514 von Verfahren 500 ähnlich ist. Wenn (i) keine Übereinstimmung vorliegt oder wenn (ii) die Erfassung der Position der Verkäufervorrichtung 102 fehlgeschlagen ist oder wenn (iii) die Erfassung der Position der Käufervorrichtung 104 fehlgeschlagen ist, fährt das Verfahren 700 mit den Schritten 716 und 718 und/oder 720 fort, die den Schritten 512, 514 und/oder 516 des Verfahrens 500 ähnlich sind.
  • Bezug nehmend nun auf 8 ist eine Flussdiagrammdarstellung von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer sicheren kontaktlosen Transaktion gemäß einer zweiten alternativen Ausführungsform veranschaulicht.
  • Diese zweite alternative Ausführungsform unterscheidet sich von der ersten alternativen Ausführungsform dadurch, dass der Server 20 das Erhalten einer Signatur der Käufervorrichtung 104 anfordert, anstatt das Erhalten einer Position der Käufervorrichtung 104 anzufordern. In einigen Ausführungsformen kann die Signatur der Käufervorrichtung 104 als eine eindeutige ID implementiert sein, die der Käufervorrichtung 104 zugeordnet ist (z. B. einer MAC-Adresse, einer Bakensignatur) und/oder dem Käufer zugeordnet ist (z. B. einer Mobiltelefonnummer). Mehrere Variationen, wie die Signatur der Käufervorrichtung 104 implementiert werden kann, werden in Betracht gezogen, ohne vom Umfang der vorliegenden Technologie abzuweichen. Die gesamte Signatur oder ein Anteil davon kann vom Verifizierungs- und Authentifizierungsdienst 26 verwendet werden, um die Käufervorrichtung 104 zu authentifizieren.
  • Die Signatur der Käufervorrichtung 104 kann von der Verkäufervorrichtung 102 erfasst werden, wenn sich die Käufervorrichtung 104 in der Nähe der Verkäufervorrichtung 102 befindet. In einigen Ausführungsformen kann die Signatur der Käufervorrichtung 104 von der Käufervorrichtung 104 gemäß einem oder mehreren Kommunikationsprotokollen (z. B. Beacon, Bluetooth, Wi-Fi usw.) ausgehen. In alternativen Ausführungsformen können andere Vorrichtungen, die mit der Verkäufervorrichtung 102 und/oder dem Server 20 kommunizieren, die Erfassung der Signatur der Käufervorrichtung 104 durchführen (z. B. Bakenvorrichtungen, die sich in einer Anlage befinden, in der sich der Verkäufer befindet usw.). Die Erfassung der Signatur der Käufervorrichtung 104 kann kontinuierlich oder ausschließlich bei Authentifizierung einer Anwesenheit des Käufers während des Prozesses des Abschließens einer Transaktion durchgeführt werden. In einigen Ausführungsformen kann die Erfassung der Signatur der Käufervorrichtung 104 als Näherungserfassung bezeichnet werden. Sobald die Erfassung der Signatur der Käufervorrichtung 104 erfolgt ist, kann der Server 20 bestimmen, dass sich der Käufer tatsächlich in der Nähe der Verkäufervorrichtung 102 befindet. Der Server 20 kann über die Erfassung der Käufervorrichtung 104 durch die Verkäufervorrichtung 102 und/oder andere Vorrichtungen informiert werden, die in einer Anlage installiert sind, in der sich der Verkäufer befindet. In einigen Ausführungsformen kann der Verkäufer 20 eine oder mehrere Signaturen von einer oder mehreren Vorrichtungen empfangen und muss dann feststellen, ob eine der Signaturen der Signatur der Käufervorrichtung 104 entspricht. Diese Bestimmung kann durchgeführt werden, indem der Server 20 eine Signatur einer Vorrichtung erworben hat, die der PAN zugeordnet ist, und/oder indem der Server 20 einen Dienst abfragt, der eine eindeutige Käufer-ID und Signaturen von dem Käufer zugeordneten Vorrichtungen zuordnet.
  • Stellt der Server 20 fest, dass die Signatur der Käufervorrichtung 104 an einem ordnungsgemäßen Ort (z. B. in der Nähe der Verkäufervorrichtung 102 und/oder an einer Anlage, in der sich der Verkäufer befindet) erfasst wurde, so kann er feststellen, dass der Käufer in der Nähe der Verkäufervorrichtung steht und dass er derjenige ist, der die Karte auf der Verkäufervorrichtung 102 gelegt hat. In solchen Fällen kann der Server 20 es übernehmen, eine Anforderung zum Autorisieren der Transaktion gemäß der zuvor in Verbindung mit 3-5 beschriebenen Abfolge von Schritten an den Ausstellerserver 10 zu senden.
  • Wenn der Server 20 bestimmt, dass die Signatur der Käufervorrichtung 104 nicht erfasst wurde, kann festgestellt werden, dass der Käufer nicht in der Nähe der Verkäufervorrichtung 102 steht und/oder dass er/sie nicht der-/diejenige ist, der/die die Karte auf der Verkäufervorrichtung 102 gelegt hat. In einigen Ausführungsformen kann die Transaktion unter solchen Umständen abgebrochen werden. In alternativen Ausführungsformen kann der Server unter solchen Umständen zu einem alternativen Authentifizierungsschritt übergehen, wie zuvor in Verbindung mit 3-5 beschrieben. Wenn der Käufer aufgefordert wird, während der alternativen Authentifizierung auf eine Mitteilungsnachricht zu antworten, kann der Verifizierungs- und Authentifizierungsdienst 26 aufgerufen werden, um den Käufer 4 zu authentifizieren. Der Käufer 4 kann aufgefordert werden, die Transaktion unter Verwendung einer Anwendung auf der Käufervorrichtung 104 zu verifizieren, und/oder dem Käufer 4 kann ein OTP bereitgestellt werden, die in die Verkäufervorrichtung 102 einzugeben ist.
  • In einigen alternativen Ausführungsformen wird die Signatur der Käufervorrichtung 104 für jede Transaktion erfasst und aufgezeichnet. In einigen alternativen Ausführungsformen kann der Server 20 während der Zahlung vermuten, dass die Kreditkarte gestohlen wurde, wenn die erfasste Signatur sich von der Signatur unterscheidet, die zuvor der Käufervorrichtung 104 zugeordnet wurde. In einigen alternativen Ausführungsformen kann der Server 20 in der Lage sein, dynamisch festzustellen, wenn eine oder mehrere dem Käufer zugeordnete Signaturen aktualisiert werden (z. B. wenn der Käufer die Vorrichtung wechselt, wenn neue Signaturen generiert werden usw.).
  • Bezug nehmend auf 9 ist nun ein Flussdiagramm dargestellt, das ein computerimplementiertes Verfahren 900 veranschaulicht, das Schritte der Ausführungsform der zweiten alternativen Ausführungsform von 8 implementiert. Das Verfahren 900 umfasst die Schritte 902, 904, 908, 910 und 920, die den Schritten 502, 504, 508, 510 und 514 des Verfahrens 500 ähnlich sind.
  • In einem Schritt 912 führt das Verfahren 900 das Erhalten der Signatur der Käufervorrichtung 104 aus. Dann bestimmt das Verfahren 900 in einem Schritt 914, ob die Signatur der Käufervorrichtung 104 erhalten wurde und der Signatur entspricht, die zuvor der Käufervorrichtung 104 zugeordnet wurde. Wenn die Signatur der Käufervorrichtung 104 ordnungsgemäß erfasst wurde, fährt das Verfahren 900 mit Schritt 920 fort, der dem Schritt 516 des Verfahrens 500 ähnlich ist. Wenn die Signatur der Käufervorrichtung 104 nicht ordnungsgemäß erfasst wurde, fährt das Verfahren 900 mit Schritt 916 fort, der dem Schritt 512 des Verfahrens 500 ähnlich ist.
  • In einigen alternativen Ausführungsformen kann die von dem Kommunikationsdienst 24 an die Käufervorrichtung 104 gesendete SMS-Nachricht oder Mitteilungsnachricht einen Link zu einer sicheren Webseite umfassen, auf der der Karteninhaber nach seiner persönlichen Zahlungskartenidentifikationsnummer (PIN) gefragt wird; wenn die PIN beim Absenden von der Webseite verschlüsselt, an den Server 20 gesendet und mit den restlichen kontaktlosen Transaktionsdaten zusammengeführt wird, dann wird die Transaktion zur Autorisierung an den Card Present Processor 202 übermittelt. Alternativ kann die Mitteilungsnachricht einen Bildschirm auf Betriebssystemebene (OS) für die einzugebende Karteninhaber-PIN umfassen oder öffnen. Alternativ kann die Mitteilung den Karteninhaber auffordern, biometrische Daten (wie Fingerabdruck oder Gesichtserkennung, ohne darauf beschränkt zu sein) zu verwenden, um die Transaktion zu bestätigen, wodurch effektiv keine weitere Notwendigkeit einer PIN besteht.
  • Um eine Transaktion unter Verwendung der hierin beschriebenen Verfahren zu autorisieren, kann der Käufer 4 eine Textnachricht empfangen und eine Webseite öffnen. Um diese Schritte durchzuführen, kann der Käufer 4 einen Telefonplan mit einem aktivierten Datenplan verwenden. Bei einer Fahrt des Käufers 4 in ein anderes Land ist es möglich, dass vom Mobilfunkbetreiber des Käufers keine Roaming-Dienstleistung erbracht wird. In diesem Szenario kann die Verkaufsstellenanwendung 206 Anweisungen dafür bereitstellen, wie ein eSIM-Plan mit Datendienst auf der Käufervorrichtung 104 gefunden und aktiviert werden kann, der dann verwendet werden kann, um die Textnachricht zu empfangen und/oder eine Webseite von einer URL, wie einer URL in der Textnachricht, zu öffnen.
  • Alle diese Risikomanagementinformationen, die während einer Transaktion durch die verschiedenen beschriebenen Ausführungsformen gesammelt wurden, können in dem Server 20 für einen begrenzten Zeitraum gespeichert werden, als Beweis dafür, dass der Käufer 4 während der Transaktion in der Nähe des Verkäufers 2 anwesend war, sodass, wenn der Käufer 4 beschließt, die Kosten anzufechten, eine an der Transaktion beteiligte Partei, wie der Verkäufer 2 oder das Finanzinstitut 11, eingreifen und den Fall zugunsten des Verkäufers 2 anfechten kann, um Rückbuchungen zu verhindern. Zum Beispiel können alle Positionsdaten, die abgefangen wurden, Signaldaten, die abgefangen wurden, oder Datensätze, die angeben, dass der Käufer 4 die Transaktion autorisiert hat, gespeichert werden.
  • 10-15 veranschaulichen nicht einschränkende beispielhafte Ausführungsformen von grafischen Benutzeroberflächen (GUIs), die bestimmte Schritte der Verfahren 500, 700 und/oder 900 implementieren. Es versteht sich, dass die in 10-15 veranschaulichten Schnittstellen beispielhaft sind und dass jede andere geeignete Benutzerschnittstelle verwendet werden kann.
  • 10 veranschaulicht eine anfängliche Benutzerschnittstelle, die von der Verkäufervorrichtung 102 angezeigt werden kann, um eine Transaktion abzuschließen. Die in 10 veranschaulichte Schnittstelle schließt einen Transaktionsbetrag und eine Angabe ein, dass der Benutzer seine Zahlungskarte oder Käufervorrichtung 104 auflegen sollte, um die Zahlung durchzuführen.
  • 11 veranschaulicht eine Schnittstelle, die eine Kennung des Käufers 4 anfordert, wie die Telefonnummer des Käufers. Die in 11 veranschaulichte Schnittstelle kann von der Verkäufervorrichtung 102 angezeigt werden. Der Verkäufer 2 oder Käufer 4 kann die Telefonnummer des Käufers unter Verwendung der in 11 dargestellten Schnittstelle eingeben. Obwohl die dargestellte Schnittstelle eine Telefonnummer anfordert, versteht es sich, dass jede andere Kennung angefordert und/oder eingegeben werden kann, wie eine E-Mail-Adresse des Käufers 4.
  • 12 veranschaulicht eine Schnittstelle, die von der Verkäufervorrichtung 102 angezeigt werden kann. Die Schnittstelle in 12 kann angezeigt werden, während die Transaktion autorisiert wird. Die Schnittstelle in 12 kann während des Empfangens und Vergleichens von Standortdaten, des Empfangens und Vergleichens von Signaldaten und/oder des Wartens auf den Empfang einer Autorisierung vom Käufer 4 angezeigt werden. Zum Beispiel kann die Schnittstelle in 12 angezeigt werden, während eine Textnachricht an die Käufervorrichtung 104 gesendet wird und der Käufer 4 die Transaktion autorisiert. Nachdem der Käufer 4 die Transaktion genehmigt hat, kann sich die in 12 veranschaulichte Schnittstelle schließen und/oder zu einer anderen Schnittstelle übergehen, wie einer Schnittstelle, die angibt, dass die Transaktion genehmigt oder abgelehnt wurde.
  • 13 veranschaulicht eine Schnittstelle, die von der Käufervorrichtung 104 angezeigt werden kann. Die in 13 veranschaulichte Schnittstelle kann es dem Käufer ermöglichen, eine Transaktion abzulehnen oder zu bestätigen. Die Schnittstelle kann einen Transaktionsbetrag, eine Angabe der verwendeten Zahlungseinrichtung, eine Angabe des Verkäufers 2, ein Datum und/oder eine Uhrzeit einschließen. Wenn der Käufer 4 beabsichtigt, die Transaktion abzuschließen, kann der Käufer 4 den Bestätigungs-Button auswählen. Wenn andererseits der Käufer 4 nichts von der Transaktion weiß, beispielsweise wenn die Zahlungskarte des Käufers gestohlen wurde, kann der Käufer 4 den Ablehnungs-Button auswählen.
  • 14 veranschaulicht eine Schnittstelle, die angezeigt werden kann, um zu bestätigen, dass der Käufer 4 eine Transaktion autorisieren möchte. Die Schnittstelle kann von der Käufervorrichtung 104 angezeigt werden. Die in 14 veranschaulichte Schnittstelle kann anfordern, dass der Käufer 4 eine biometrische Authentifizierung bereitstellt, wie einen Scan seines Gesichts, der von der Käufervorrichtung 104 durchgeführt wird. Nach Authentifizierung des Käufers 4 kann die Transaktion durch den Käufer 4 autorisiert werden.
  • 15 veranschaulicht eine Schnittstelle, die von der Verkäufervorrichtung 102 und/oder der Käufervorrichtung 104 angezeigt werden kann. Die in 15 veranschaulichte Schnittstelle kann nach der in 12 dargestellten Schnittstelle angezeigt werden. Die in 15 veranschaulichte Schnittstelle kann angeben, dass eine Transaktion autorisiert wurde. Die Schnittstelle bietet dem Käufer 4 die Möglichkeit, einen Beleg zu erhalten.
  • 16 zeigt ein Flussdiagramm, das ein computerimplementiertes Verfahren 1600 veranschaulicht, das Ausführungsformen der vorliegenden Technologie implementiert. Das computerimplementierte Verfahren von 16 kann ein computerimplementiertes Verfahren umfassen, das durch einen Prozessor der Verkäufervorrichtung 102, der Käufervorrichtung 104, des Servers 20, des Verifizierungs- und Authentifizierungsdienstes 26, und/oder einen oder mehrere andere Server ausführbar ist, wobei das Verfahren eine Reihe von Schritten umfasst, die von der Verkäufervorrichtung 102, der Käufervorrichtung 104, dem Server 20, dem Verifizierungs- und Authentifizierungsdienst 26 und/oder einem oder mehreren anderen Servern auszuführen sind.
  • Das computerimplementierte Verfahren von 16 kann zum Beispiel dadurch durchgeführt werden, dass ein Prozessor Programmanweisungen ausführt, die zum Beispiel in Direktzugriffsspeicher und/oder ein sicheres Element geladen wurden.
  • In Schritt 1605 kann eine Zahlungsanforderung empfangen werden. Die Zahlungsanforderung kann von der Verkäufervorrichtung 102 empfangen werden. Die Zahlungsanforderung kann eine PAN, eine Zahlungskartennummer, eine Kontonummer, einen Namen, ein Datum, einen Transaktionsbetrag und/oder beliebige andere Daten bezüglich einer Transaktion umfassen. Die Zahlungsanforderung kann eine Signatur der Verkäufervorrichtung 102 umfassen. Aktionen, die in Schritt 1605 durchgeführt werden, können ähnlich denen sein, die in Schritt 502 des Verfahrens 500 durchgeführt werden.
  • In Schritt 1610 kann eine Authentifizierungsanforderung übertragen werden, beispielsweise an den Verifizierungs- und Authentifizierungsdienst 26 und/oder den Ausstellerserver 10. Die Authentifizierungsanforderung kann eine Vorrichtungssignatur der Verkäufervorrichtung 102 einschließen. Die Vorrichtungssignatur kann einen Typ der Vorrichtung, einen Hersteller der Vorrichtung, eine Angabe des Betriebssystems der Vorrichtung, eine Zeitzone der Vorrichtung, eine Angabe eines Webbrowsers, der von der Vorrichtung verwendet wird, welche Drahtlosprotokolle die Vorrichtung aktiv verwendet, und/oder beliebige andere Informationen, die die Verkäufervorrichtung 102 beschreiben, einschließen. Die Authentifizierungsanforderung kann beliebige andere Informationen in Bezug auf die Verkäufervorrichtung 102 einschließen.
  • In Schritt 1615 kann die Authentifizierung der Verkäufervorrichtung 102 fehlschlagen. Der Verifizierungs- und Authentifizierungsdienst 26, der Ausstellerserver 10 und/oder jedes andere System können bestimmen, dass die Authentifizierung der Verkäufervorrichtung 102 fehlgeschlagen ist. Nach dem Empfangen der Authentifizierungsanforderung kann der Authentifizierungsdienst eine dem Käufer zugeordnete Vorrichtungssignatur abrufen. Der Authentifizierungsdienst kann eine PAN oder andere identifizierende Informationen in der Zahlungsanforderung verwenden, um die dem Käufer zugeordnete Vorrichtungssignatur abzurufen. Der Authentifizierungsdienst kann die dem Käufer zugeordnete Vorrichtungssignatur mit der empfangenen Vorrichtungssignatur vergleichen. Da die empfangene Vorrichtungssignatur der Verkäufervorrichtung entspricht, kann die Authentifizierung fehlschlagen. Da die Authentifizierung fehlgeschlagen ist, kann eine zweite Authentifizierung verwendet werden, um die Transaktion zu verifizieren.
  • In Schritt 1620 kann eine Authentifizierungsanforderung an die Käufervorrichtung gesendet werden. Die Authentifizierungsanforderung kann vom Verifizierungs- und Authentifizierungsdienst 26, dem Ausstellerserver 10 und/oder einem anderen System gesendet werden. Unter Verwendung der Zahlungsanforderung können Kontaktinformationen für den Käufer abgerufen werden. Die Kontaktinformationen können verwendet werden, um eine Authentifizierungsanforderung an die Käufervorrichtung zu übertragen. Jede geeignete sekundäre Form der Authentifizierung kann verwendet werden. Ein Einmalpasswort (OTP) kann an die Käufervorrichtung gesendet werden. Der Käufer kann angewiesen werden, das OTP in die Verkäufervorrichtung einzugeben. Eine Anforderung zum Verifizieren der Transaktion über eine Anwendung kann an den Käufer übermittelt werden. Zum Beispiel kann eine Anforderung, eine Bankanwendung zu öffnen und die Transaktion zu verifizieren, an den Käufer übertragen werden.
  • In Schritt 1625 kann eine Bestimmung durchgeführt werden, ob der Käufer authentifiziert wurde. Wenn der Käufer die sekundäre Form der Authentifizierung in Schritt 1620 abgeschlossen hat, kann der Käufer als authentifiziert betrachtet werden. Das Verfahren 1600 kann dann mit Schritt 1635 fortfahren, um zu kommunizieren, dass die Authentifizierung erfolgreich war. Der Verifizierungs- und Authentifizierungsdienst 26 kann ein Token senden, das angibt, dass die Authentifizierung erfolgreich war. Aktionen, die in Schritt 1635 durchgeführt werden, können ähnlich denen sein, die in Schritt 516 von 5 durchgeführt werden. Wenn der Käufer die sekundäre Form der Authentifizierung nicht abgeschlossen hat, kann der Authentifizierungsfehler in Schritt 1630 übermittelt werden. Die Transaktion kann abgebrochen werden, wenn die Authentifizierung fehlschlägt, oder die Transaktion kann ungeachtet des Authentifizierungsfehlschlags fortgesetzt werden. Aktionen, die in Schritt 1630 durchgeführt werden, können ähnlich denen sein, die in Schritt 514 von 5 durchgeführt werden.
  • 17 ist eine Flussdiagrammdarstellung von Kommunikationsflüssen zwischen mehreren Entitäten zum Durchführen einer sicheren kontaktlosen Transaktion. 17 veranschaulicht eine Abfolge von Kommunikationen, die auftreten können, während das Verfahren 1600 durchgeführt wird. Eine Zahlungskarte oder eine mobile Vorrichtung, die eine mobile Geldbörse implementiert, kann auf die Verkäufervorrichtung 102 aufgelegt werden. Die Verkäufervorrichtung 102 kann Informationen empfangen, die der Zahlungskarte entsprechen, wie eine PAN, Kartennummer, Ablaufdatum, Name, Adresse, Token von einer mobilen Geldbörse usw. Die Verkäufervorrichtung 102 kann alle oder einen Anteil der empfangenen Daten an den Server 20 übertragen. Die Verkäufervorrichtung 102 kann zusätzliche Daten an den Server 20 übertragen, wie einen Transaktionsbetrag, Händlerinformationen usw.
  • Die von der Verkäufervorrichtung 102 empfangenen Informationen können angeben, dass eine zusätzliche Authentifizierung durchgeführt werden sollte. Der Server 20 kann eine Anforderung an den Verifizierungs- und Authentifizierungsdienst 26 senden, die Transaktion zu authentifizieren. Die Anforderung kann eine Anforderung an ein Token sein, anzugeben, dass die Transaktion authentifiziert wurde. Die vom Server 20 an den Verifizierungs- und Authentifizierungsdienst 26 gesendete Anforderung kann alle oder einen Anteil der vom Server 20 von der Verkäufervorrichtung 102 empfangenen Daten einschließen.
  • Der Verifizierungs- und Authentifizierungsdienst 26 kann die Transaktion basierend auf den vom Server 20 empfangenen Daten authentifizieren. Wenn die Authentifizierung erfolgreich ist, kann der Verifizierungs- und Authentifizierungsdienst 26 ein Token an den Server 20 senden. Das Token kann angeben, dass die Transaktion autorisiert wurde.
  • Wenn der Verifizierungs- und Authentifizierungsdienst 26 die Transaktion basierend auf den von der Verkäufervorrichtung 102 gesendeten Daten nicht authentifizieren konnte, kann der Verifizierungs- und Authentifizierungsdienst 26 eine Authentifizierungsanforderung an die Käufervorrichtung 104 senden. Die Authentifizierungsanforderung kann eine Anforderung für den Käufer sein, die Transaktion unter Verwendung einer Anwendung auf der Käufervorrichtung 104, wie einer Bankanwendung, zu autorisieren. Der Verifizierungs- und Authentifizierungsdienst 26 kann ein OTP an die Käufervorrichtung 104 senden. Der Käufer kann das OTP in die Verkäufervorrichtung 102 eingeben. Die Verkäufervorrichtung 102 kann dann das OTP an den Verifizierungs- und Authentifizierungsdienst 26 senden. Obwohl 17 veranschaulicht, dass der Verifizierungs- & Authentifizierungsdienst 26 die Authentifizierungsanforderung an die Käufervorrichtung 104 sendet, versteht es sich, dass jedes andere System die Authentifizierungsanforderung senden kann, wie der Ausstellerserver 10.
  • Nachdem der Verifizierungs- und Authentifizierungsdienst 26 den Käufer authentifiziert hat, kann der Verifizierungs- und Authentifizierungsdienst 26 ein Token an den Server 20 senden. Das Token kann angeben, dass der Käufer authentifiziert wurde.
  • Der Server 20 kann eine Transaktionsanforderung an den Ausstellerserver 10 senden. Die Transaktionsanforderung kann das Token einschließen. Wenn die Authentifizierung fehlgeschlagen ist und kein Token empfangen wurde, sendet der Server 20 möglicherweise weiterhin die Transaktionsanforderung an den Ausstellerserver 10, jedoch ohne Token. Die Transaktionsanforderung kann Daten einschließen, die von der Verkäufervorrichtung 102 empfangen werden, wie eine PAN, ein Token, einen Transaktionsbetrag und/oder beliebige andere Daten, die sich auf die Transaktion beziehen. Der Ausstellerserver 10 kann bestimmen, ob die Transaktion genehmigt oder abgelehnt werden soll. Obwohl die Transaktionsanforderung hier als an den Ausstellerserver 10 gesendet beschrieben wird, versteht es sich, dass die Transaktionsanforderung an verschiedene andere Entitäten und/oder Server gesendet werden kann. Zum Beispiel kann die Transaktionsanforderung an den Verkäufer, einen Erfasser, einen Prozessor usw. gesendet werden. Die Transaktionsanforderung kann an den Ausstellerserver 10 weitergeleitet werden.
  • Insbesondere sollen die vorstehenden Merkmale und Beispiele den Schutzumfang der vorliegenden Offenbarung nicht auf eine einzige Ausführungsform beschränken, da andere Ausführungsformen durch Austausch einiger oder aller der beschriebenen oder veranschaulichten Elemente möglich sind. Darüber hinaus werden, wenn bestimmte Elemente der vorliegenden Offenbarung teilweise oder vollständig unter Verwendung bekannter Komponenten implementiert werden können, nur diejenigen Anteile solcher bekannter Komponenten beschrieben, die zum Verständnis der vorliegenden Offenbarung erforderlich sind, und detaillierte Beschreibungen anderer Anteile solcher bekannter Komponenten werden weggelassen, um die Offenbarung nicht zu verdecken. In der vorliegenden Beschreibung sollte eine Ausführungsform, die eine einzelne Komponente zeigt, nicht notwendigerweise auf andere Ausführungsformen beschränkt sein, die eine Vielzahl derselben Komponente einschließen, und umgekehrt, sofern hier nicht ausdrücklich etwas anderes angegeben ist. Außerdem beabsichtigen die Anmelder nicht, einem in der Beschreibung oder den Ansprüchen verwendeten Begriff eine ungewöhnliche oder spezielle Bedeutung zuzuschreiben, sofern nicht explizit als solche dargelegt. Ferner schließt die vorliegende Offenbarung gegenwärtige und zukünftige bekannte Äquivalente zu den bekannten Komponenten ein, auf die hierin zur Veranschaulichung Bezug genommen wird.
  • Die vorstehende Beschreibung der spezifischen Ausführungsformen offenbart die allgemeine Natur der Offenbarung so vollständig, dass andere durch Anwenden des Wissen eines Fachmanns auf dem/den relevanten Fachgebiet(en) (einschließlich der Inhalte der hierin zitierten und durch Bezugnahme eingeschlossenen Dokumente) solche spezifischen Ausführungsformen ohne weiteres für verschiedene Anwendungen ohne übermäßigen Versuchsaufwand und ohne vom allgemeinen Konzept der vorliegenden Offenbarung abzuweichen, modifizieren und/oder anpassen können. Solche Anpassungen und Modifikationen sollen daher basierend auf der hierin vorgelegten Lehre und Anleitung innerhalb der Bedeutung und des Bereichs von Äquivalenten der offenbarten Ausführungsformen liegen. Es versteht sich, dass die Ausdrucksweise oder die Terminologie hierin dem Zweck der Beschreibung und nicht der Einschränkung dient, sodass der Fachmann die Terminologie oder Ausdrucksweise der vorliegenden Beschreibung angesichts der hierin vorgestellten Lehren und Anleitung in Verbindung mit dem Wissen eines Fachmanns auf dem/den relevanten Fachgebiet(en) interpretiert.
  • Während die vorstehend offenbarten Umsetzungen in Bezug auf besondere, in einer bestimmten Reihenfolge ausgeführte Schritte beschrieben und gezeigt worden sind, versteht es sich, dass diese Schritte kombiniert, unterteilt oder in einer anderen Reihenfolge angeordnet werden können, ohne von den Lehren der vorliegenden Technologie abzuweichen. Die Schritte können parallel oder seriell ausgeführt werden. Dementsprechend stellt die Reihenfolge und Gruppierung der Schritte keine Einschränkung der vorliegenden Offenbarung dar.
  • Obwohl verschiedene Ausführungsformen der vorliegenden Offenbarung vorstehend beschrieben wurden, versteht es sich, dass sie beispielhaft und nicht einschränkend dargestellt wurden. Es wäre für einen Fachmann auf dem/den relevanten Gebiet(en) offensichtlich, dass verschiedene Änderungen in Form und Detail darin vorgenommen werden könnten, ohne vom Geist und Schutzumfang der Offenbarung abzuweichen. Somit sollte die vorliegende Offenbarung nicht durch die vorstehend beschriebenen Ausführungsbeispiele eingeschränkt werden, sondern sollte nur gemäß den nachfolgenden Ansprüchen und deren Äquivalenten definiert werden.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62/901623 [0001]
    • US 62/874224 [0001]
    • US 62/841030 [0001]
    • US 62/840376 [0001]

Claims (50)

  1. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Übertragen, an einen Authentifizierungsdienst, einer Authentifizierungsanforderung, die Transaktionsinformationen umfasst; Empfangen, von dem Authentifizierungsdienst, einer Angabe, dass der Käufer authentifiziert wurde, und nachdem der Käufer authentifiziert worden ist, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  2. Verfahren nach Anspruch 1, ferner umfassend das Bestimmen durch den Authentifizierungsdienst, dass die Authentifizierung der dem Käufer zugeordneten Vorrichtung fehlgeschlagen ist.
  3. Verfahren nach einem der Ansprüche 1-2, ferner umfassend das Übertragen eines zur Authentifizierung einzugebenden Einmalpassworts durch den Authentifizierungsdienst und an die dem Käufer zugeordnete Vorrichtung.
  4. Verfahren nach Anspruch 3, das ferner das Empfangen einer Angabe, dass das Einmalpasswort eingegeben wurde, und seines Werts von der dem Verkäufer zugeordneten Vorrichtung umfasst.
  5. Verfahren nach einem der Ansprüche 1-2, ferner umfassend das Übertragen, durch den Authentifizierungsdienst und an die dem Käufer zugeordnete Vorrichtung, einer Anforderung zum Autorisieren der Transaktion durch eine Anwendung auf der dem Käufer zugeordneten Vorrichtung.
  6. Verfahren nach einem der Ansprüche 1-5, ferner umfassend das Bestimmen, durch den Authentifizierungsdienst, einer Kennung, die der dem Käufer zugeordneten Vorrichtung entspricht.
  7. Verfahren nach einem der Ansprüche 1-6, wobei die Authentifizierungsanforderung Informationen umfasst, die der dem Verkäufer zugeordneten Vorrichtung entsprechen.
  8. Verfahren nach einem der Ansprüche 1-6, wobei die Authentifizierungsanforderung ein Token von einer mobilen Geldbörse umfasst.
  9. Verfahren nach Anspruch 8, wobei die Transaktionsanforderung das Token von der mobilen Geldbörse umfasst.
  10. Verfahren nach einem der Ansprüche 1-6, wobei die Authentifizierungsanforderung eine Zahlungskartennummer umfasst.
  11. Verfahren nach Anspruch 10, wobei die Transaktionsanforderung die Zahlungskartennummer umfasst.
  12. Verfahren nach einem der Ansprüche 1-6, wobei die Authentifizierungsanforderung einen Betrag der Transaktion umfasst.
  13. Verfahren nach Anspruch 12, wobei die Transaktionsanforderung den Betrag der Transaktion umfasst.
  14. Verfahren nach einem der Ansprüche 1-6, wobei die Authentifizierungsanforderung Informationen umfasst, die den Verkäufer angeben.
  15. Verfahren nach Anspruch 14, wobei die Transaktionsanforderung die Informationen umfasst, die den Verkäufer angeben.
  16. Verfahren nach einem der Ansprüche 1-15, wobei die Angabe, dass der Käufer authentifiziert wurde, ein Token umfasst.
  17. Verfahren nach Anspruch 16, wobei die Transaktionsanforderung das Token umfasst.
  18. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Übertragen, an einen Authentifizierungsdienst, einer Authentifizierungsanforderung, die Transaktionsinformationen umfasst; Empfangen, von dem Authentifizierungsdienst, einer Angabe, dass die Authentifizierung des Käufers fehlgeschlagen ist; und nach dem Empfangen der Angabe, dass die Authentifizierung des Käufers fehlgeschlagen ist, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  19. Verfahren nach Anspruch 18, ferner umfassend das Bestimmen durch den Authentifizierungsdienst, dass die Authentifizierung der dem Käufer zugeordneten Vorrichtung fehlgeschlagen ist.
  20. Verfahren nach einem der Ansprüche 18-19, ferner umfassend das Übertragen eines zur Authentifizierung einzugebenden Einmalpassworts durch den Authentifizierungsdienst und an die dem Käufer zugeordnete Vorrichtung.
  21. Verfahren nach einem der Ansprüche 18-19, ferner umfassend das Übertragen, durch den Authentifizierungsdienst und an die dem Käufer zugeordnete Vorrichtung, einer Anforderung zum Autorisieren der Transaktion durch eine Anwendung auf der dem Käufer zugeordneten Vorrichtung.
  22. Verfahren nach einem der Ansprüche 18-21, ferner umfassend das Bestimmen, durch den Authentifizierungsdienst, einer Kennung, die der dem Käufer zugeordneten Vorrichtung entspricht.
  23. Verfahren nach einem der Ansprüche 18-22, wobei die Authentifizierungsanforderung Informationen umfasst, die der dem Verkäufer zugeordneten Vorrichtung entsprechen.
  24. Verfahren nach einem der Ansprüche 18-23, wobei die Authentifizierungsanforderung ein Token von einer mobilen Geldbörse umfasst.
  25. Verfahren nach einem der Ansprüche 18-23, wobei die Authentifizierungsanforderung eine Zahlungskartennummer umfasst.
  26. Verfahren nach einem der Ansprüche 18-23, wobei die Authentifizierungsanforderung einen Betrag der Transaktion umfasst.
  27. Verfahren nach einem der Ansprüche 18-26, wobei die Authentifizierungsanforderung Informationen umfasst, die den Verkäufer angeben.
  28. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Bestimmen eines Namens oder einer Adresse, der/die der Zahlungsanforderung zugeordnet ist; Vergleichen des Namens oder der Adresse mit der Zahlungsanforderung; nach dem Bestimmen, dass der Name oder die Adresse mit der Zahlungsanforderung übereinstimmt, Übertragen einer Nachricht an eine Vorrichtung, die dem Käufer zugeordnet ist, wobei die Nachricht anfordert, dass der Käufer die Transaktion autorisiert; Empfangen, von einem Authentifizierungsdienst, einer Angabe, dass der Käufer authentifiziert wurde, und nachdem der Käufer die Transaktion autorisiert hat und nachdem der Käufer authentifiziert wurde, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  29. Verfahren nach Anspruch 28, wobei das Bestimmen des Namens oder der Adresse, der/die der Zahlungsanforderung zugeordnet ist, umfasst: Senden einer Anforderung zum Erfassen einer Kennung, die dem Käufer entspricht, an die dem Verkäufer zugeordnete Vorrichtung; Empfangen der Kennung; und Bestimmen, basierend auf der Kennung, des Namens oder der Adresse.
  30. Verfahren nach Anspruch 29, wobei die Kennung eine Telefonnummer umfasst.
  31. Verfahren nach Anspruch 29, wobei die Kennung eine E-Mail-Adresse umfasst.
  32. Verfahren nach Anspruch 29, das ferner vor dem Senden der Anforderung zum Erfassen der Kennung das Abfragen einer Datenbank von Kennungen umfasst, um festzustellen, ob in der Datenbank Informationen gespeichert sind, die dem Käufer entsprechen.
  33. Verfahren nach einem der Ansprüche 28-32, wobei die Zahlungsanforderung eine Zahlungskartennummer oder ein Token von einer mobilen Geldbörse umfasst.
  34. Verfahren nach einem der Ansprüche 28-33, wobei die Zahlungsanforderung eine Kontonummer des Käufers umfasst.
  35. Verfahren nach einem der Ansprüche 28-34, wobei die Zahlungsanforderung ein Ablaufdatum umfasst.
  36. Verfahren nach einem der Ansprüche 28-35, wobei die Zahlungsanforderung mindestens einen Anteil einer Adresse des Käufers umfasst.
  37. Verfahren nach einem der Ansprüche 28-36, wobei die Zahlungsanforderung mindestens einen Anteil eines Namens des Käufers umfasst.
  38. Verfahren nach einem der Ansprüche 28-37, wobei der Authentifizierungsdienst einen 3-D Secure-Authentifizierungsdienst (3DS-Authentifizierungsdienst) umfasst.
  39. Verfahren nach einem der Ansprüche 28-38, wobei das Übertragen der Transaktionsanforderung das Übertragen der Transaktionsanforderung an einen Aussteller umfasst.
  40. Verfahren nach einem der Ansprüche 28-38, wobei das Übertragen der Transaktionsanforderung das Übertragen der Transaktionsanforderung an einen Erfasser umfasst.
  41. Verfahren nach einem der Ansprüche 28-40, wobei die Nachricht ein Einmalpasswort umfasst.
  42. Verfahren nach Anspruch 41, wobei die Nachricht eine Anforderung zum Eingeben des Einmalpassworts in die dem Verkäufer zugeordnete Vorrichtung umfasst.
  43. Verfahren nach einem der Ansprüche 28-40, wobei die Nachricht eine Anforderung zum Authentifizieren der Transaktion unter Verwendung einer Anwendung auf der dem Käufer zugeordneten Vorrichtung umfasst.
  44. Verfahren nach einem der Ansprüche 28-44, wobei die Angabe, dass der Käufer authentifiziert wurde, eine Angabe umfasst, dass die dem Käufer zugeordnete Vorrichtung authentifiziert wurde.
  45. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Übertragen, basierend auf der Zahlungsanforderung, einer Nachricht an eine dem Käufer zugeordnete Vorrichtung, wobei die Nachricht anfordert, dass der Käufer die Transaktion autorisiert; Empfangen, von einem Authentifizierungsdienst, einer Angabe, dass der Käufer authentifiziert wurde, und nachdem der Käufer die Transaktion autorisiert hat und nachdem der Käufer authentifiziert wurde, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  46. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Bestimmen eines Standorts einer dem Käufer zugeordneten Vorrichtung; Bestimmen eines Standorts der dem Verkäufer zugeordneten Vorrichtung; Vergleichen des Standorts der dem Käufer zugeordneten Vorrichtung mit dem Standort der dem Verkäufer zugeordneten Vorrichtung; und nach dem Bestimmen, dass sich der Standort der dem Käufer zugeordneten Vorrichtung, innerhalb eines Schwellenabstands von der dem Verkäufer zugeordneten Vorrichtung, befindet, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  47. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Bestimmen eines Standorts einer dem Käufer zugeordneten Vorrichtung; Bestimmen eines Standorts der dem Verkäufer zugeordneten Vorrichtung; Vergleichen des Standorts der dem Käufer zugeordneten Vorrichtung mit dem Standort der dem Verkäufer zugeordneten Vorrichtung; nach dem Bestimmen, dass sich der Standort der dem Käufer zugeordneten Vorrichtung nicht innerhalb eines Schwellenabstands von dem Standort der dem Verkäufer zugeordneten Vorrichtung befindet, Übertragen einer Nachricht an eine dem Käufer zugeordneten Vorrichtung, wobei die Nachricht anfordert, dass der Käufer die Transaktion autorisiert; Empfangen, von einem Authentifizierungsdienst, einer Angabe, dass der Käufer authentifiziert wurde, und nachdem der Käufer die Transaktion autorisiert hat und nachdem der Käufer authentifiziert wurde, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  48. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Bestimmen einer Vorrichtungssignatur einer dem Käufer zugeordneten Vorrichtung; Erfassen der Vorrichtungssignatur durch die dem Verkäufer zugeordnete Vorrichtung; und nach dem Erfassen der Vorrichtungssignatur durch die dem Verkäufer zugeordnete Vorrichtung, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  49. Verfahren zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das Verfahren umfasst: Empfangen einer Zahlungsanforderung von einer dem Verkäufer zugeordneten Vorrichtung; Bestimmen einer Vorrichtungssignatur einer dem Käufer zugeordneten Vorrichtung; Übertragen einer Nachricht an die dem Käufer zugeordnete Vorrichtung, nachdem das Erfassen der Vorrichtungssignatur durch die dem Verkäufer zugeordnete Vorrichtung fehlgeschlagen ist, wobei die Nachricht anfordert, dass der Käufer die Transaktion autorisiert; Empfangen, von einem Authentifizierungsdienst, einer Angabe, dass der Käufer authentifiziert wurde, und nachdem der Käufer die Transaktion autorisiert hat und nachdem der Käufer authentifiziert wurde, Übertragen einer Transaktionsanforderung, um die Transaktion abzuschließen.
  50. System zum Autorisieren einer Zahlung für eine Transaktion zwischen einem Käufer und einem Verkäufer, wobei das System umfasst: einen Prozessor; und ein nicht-transitorisches, computerlesbares Medium, das Anweisungen umfasst, wobei der Prozessor beim Ausführen der Anweisungen die Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche bewirkt.
DE112020002160.2T 2019-04-29 2020-04-29 System und verfahren zum betreiben einer sicheren kontaktlosen transaktion Pending DE112020002160T5 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201962840376P 2019-04-29 2019-04-29
US62/840,376 2019-04-29
US201962841030P 2019-04-30 2019-04-30
US62/841,030 2019-04-30
US201962874224P 2019-07-15 2019-07-15
US62/874,224 2019-07-15
US201962901623P 2019-09-17 2019-09-17
US62/901,623 2019-09-17
PCT/IB2020/054049 WO2020222143A1 (en) 2019-04-29 2020-04-29 System and method of operating a secure contactless transaction

Publications (1)

Publication Number Publication Date
DE112020002160T5 true DE112020002160T5 (de) 2022-01-13

Family

ID=73029687

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020002160.2T Pending DE112020002160T5 (de) 2019-04-29 2020-04-29 System und verfahren zum betreiben einer sicheren kontaktlosen transaktion

Country Status (4)

Country Link
US (2) US20220036340A1 (de)
DE (1) DE112020002160T5 (de)
GB (2) GB2619424A (de)
WO (1) WO2020222143A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11113688B1 (en) 2016-04-22 2021-09-07 Wells Fargo Bank, N.A. Systems and methods for mobile wallet provisioning
US11928666B1 (en) 2019-09-18 2024-03-12 Wells Fargo Bank, N.A. Systems and methods for passwordless login via a contactless card
US11704632B2 (en) * 2020-12-17 2023-07-18 Marqeta, Inc. Computer transaction security with delegated decisions
WO2022256917A1 (en) * 2021-06-07 2022-12-15 Mastercard Technologies Canada ULC Systems, methods, and non-transitory computer-readable media for authentication and authorization of payment request

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7778934B2 (en) * 2000-04-17 2010-08-17 Verisign, Inc. Authenticated payment
US20020133408A1 (en) * 2001-03-15 2002-09-19 Walker Jay S. Process and product for promoting a product
GB2466676A (en) * 2009-01-06 2010-07-07 Visa Europe Ltd A method of processing payment authorisation requests
US9070146B2 (en) * 2010-02-04 2015-06-30 Playspan Inc. Method and system for authenticating online transactions
WO2011112990A1 (en) * 2010-03-11 2011-09-15 Wal-Mart Stores, Inc. System and method for transaction payments using a mobile device
US8355987B2 (en) * 2010-05-06 2013-01-15 Boku, Inc. Systems and methods to manage information
US9489669B2 (en) * 2010-12-27 2016-11-08 The Western Union Company Secure contactless payment systems and methods
WO2013013192A2 (en) * 2011-07-20 2013-01-24 Visa International Service Association Cryptographic expansion device and related protocols
US10699273B2 (en) * 2013-03-14 2020-06-30 Lookout, Inc. System and method for authorizing payment transaction based on device locations
US11138605B2 (en) * 2013-07-02 2021-10-05 Visa International Service Association Online authentication in access transactions
US20150012305A1 (en) * 2013-07-03 2015-01-08 Research In Motion Limited Mobile device for managing e-tickets and payment transactions
US10304042B2 (en) * 2014-11-06 2019-05-28 Early Warning Services, Llc Location-based authentication of transactions conducted using mobile devices
CN106897874B (zh) * 2016-06-01 2021-02-09 创新先进技术有限公司 移动支付方法、装置及系统
SG10201706266YA (en) * 2017-08-01 2019-03-28 Mastercard International Inc Method and system for transaction authorization

Also Published As

Publication number Publication date
US20230410087A1 (en) 2023-12-21
GB2619424A (en) 2023-12-06
US20220036340A1 (en) 2022-02-03
GB2597159A (en) 2022-01-19
GB202115548D0 (en) 2021-12-15
GB202311678D0 (en) 2023-09-13
WO2020222143A1 (en) 2020-11-05

Similar Documents

Publication Publication Date Title
DE112020002160T5 (de) System und verfahren zum betreiben einer sicheren kontaktlosen transaktion
US11599883B2 (en) System and method for fraud risk analysis in IoT
US11151567B2 (en) Authentication and fraud prevention in provisioning a mobile wallet
RU2691590C2 (ru) Системы и способы замены или удаления секретной информации из данных
DE69023843T2 (de) Automatisches Geschäftsverfahren und Vorrichtung.
DE60316498T2 (de) Chipkarte, tragbares Endgerät und Zugriffsteuerungsverfahren
DE102013106295A1 (de) Eingebettetes sicheres Element zur Authentifizierung, Speicherung und Transaktion in einem mobilen Endgerät
DE212010000059U1 (de) Veränderbarer Sicherheitswert
US20200143377A1 (en) Systems and methods for user identity authentication
US20140358704A1 (en) Secured point-of-sale transactions
US20140358778A1 (en) Multi-level know your customer (kyc) data collection and verification
CN104361491A (zh) 一种移动支付方法及系统
US11188919B1 (en) Systems and methods for contactless smart card authentication
US20210201294A1 (en) Bank card privacy information hiding method, bank card and computer readable storage medium
CN107633162A (zh) 一种身份认证方法、装置、系统、设备及存储介质
CN105956858B (zh) 一种支付方法及电子设备
US11301862B2 (en) Secure transfer of tokens between devices
CN104486306A (zh) 基于指静脉识别和云服务进行身份认证的方法
CN108460263A (zh) 信息分享方法、装置和电子设备
CN107944871A (zh) 身份认证方法、装置、计算机设备及计算机可读存储介质
DE102013016119B4 (de) Verfahren zur Bezahlung
EP3035270A1 (de) Kartenbasierte offline-token generierung
DE112020002601T5 (de) System und verfahren zum betreiben einer verbrauchervorrichtung als zahlungsvorrichtung
US10812459B2 (en) Method for verifying identity during virtualization
US9767519B2 (en) Method for processing transactional data, corresponding terminal, server and computer program

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R130 Divisional application to

Ref document number: 112020007836

Country of ref document: DE

R016 Response to examination communication