DE112018006031T5 - Authentifizieren einer zahlungskarte - Google Patents

Authentifizieren einer zahlungskarte Download PDF

Info

Publication number
DE112018006031T5
DE112018006031T5 DE112018006031.4T DE112018006031T DE112018006031T5 DE 112018006031 T5 DE112018006031 T5 DE 112018006031T5 DE 112018006031 T DE112018006031 T DE 112018006031T DE 112018006031 T5 DE112018006031 T5 DE 112018006031T5
Authority
DE
Germany
Prior art keywords
payment card
hash value
block
payment
computer
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.)
Granted
Application number
DE112018006031.4T
Other languages
English (en)
Other versions
DE112018006031B4 (de
Inventor
Edgar Adolfo Zamora Duran
Franz Friedrich Liebinger Portela
Roxana Monge Nunez
Sheyla Vanessa Vargas
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.)
Kyndryl Inc
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112018006031T5 publication Critical patent/DE112018006031T5/de
Application granted granted Critical
Publication of DE112018006031B4 publication Critical patent/DE112018006031B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/409—Device specific authentication in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/06187—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with magnetically detectable marking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/073—Special arrangements for circuits, e.g. for protecting identification code in memory
    • G06K19/07309—Means for preventing undesired reading or writing from or onto record carriers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/343—Cards including a counter
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/353—Payments by cards read by M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/401—Transaction verification
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G07F7/082—Features insuring the integrity of the data on or in the card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G07F7/0826—Embedded security module
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0833—Card having specific functional components
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/12—Card verification
    • G07F7/122—Online card verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G06K19/0772—Physical layout of the record carrier
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K2019/06215—Aspects not covered by other subgroups
    • G06K2019/06253—Aspects not covered by other subgroups for a specific application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K2019/06215—Aspects not covered by other subgroups
    • G06K2019/06271—Relief-type marking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

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

Abstract

Bereitgestellt wird ein Ansatz zum Prüfen der Berechtigung einer Zahlungskarte. Informationen werden von der Zahlungskarte gelesen, die gerade für einen Kauf verwendet wird. Die Informationen weisen eine Kennung und Daten auf einem Chip in Braille-Zellen und in Markierungen in der Zahlungskarte auf. Ein vom Chip gelesener Hash-Wert, die Kennung und Sicherheitscodes, die aus den Braille-Zellen und den Markierungen abgeleitet werden, werden an ein Zahlungssystem gesendet. Ein Hash-Wert eines (n + 1)-ten Blocks einer Blockkette wird empfangen und im Chip als Reaktion darauf aufgezeichnet, dass Validierungen des Hash-Werts Übereinstimmungen mit einem Hash-Wert eines n-ten Blocks der Blockkette ergeben, auf die Kennung und den ersten und den zweiten Sicherheitscode und auf eine Erzeugung des Hash-Werts des (n + 1)-ten Blocks. Daten über den Kauf und der Hash Wert des (n + 1)-ten Blocks werden an das Zahlungssystem gesendet.

Description

  • HINTERGRUND
  • Die vorliegende Erfindung betrifft das Prüfen der Berechtigung einer Zahlung und insbesondere das Bestätigen, dass es sich bei der Zahlungskarte um das Original handelt.
  • Die Verwendung der Zwei-Faktor-Berechtigungsprüfung zum Nachweis der Identität einer Person beruht auf der Grundannahme, dass ein unberechtigter Akteur wahrscheinlich nicht in der Lage ist, beide für den Zugriff erforderlichen Faktoren bereitzustellen. Wenn bei einem Versuch zur Prüfung der Berechtigung mindestens einer der Faktoren fehlt oder nicht korrekt bereitgestellt wird, wird die Identität des Benutzers nicht mit ausreichender Sicherheit bestätigt, und der Zugriff auf die geschützte Ressource bleibt gesperrt. Zu einem Berechtigungsprüfungsfaktor bei einem Konzept der Zwei-Faktor-Berechtigungsprüfung können gehören (1) ein physisches Objekt im Besitz des Benutzers wie zum Beispiel ein USB-Stick (USB = Universal Serial Bus) mit einem geheimen Merkmal (Token), eine Bankkarte, ein Schlüssel usw.; (2) ein dem Benutzer bekanntes Geheimnis wie zum Beispiel ein Kennwort, eine persönliche Identifikationsnummer (PIN), eine Transaktionsberechtigungsnummer (transaction authentication number, TAN) usw.; oder (3) eine physiologische Eigenschaft oder eine Verhaltenseigenschaft des Benutzers (d.h. biometrische Kennung) wie zum Beispiel ein Fingerabdruck, Regenbogenhaut des Auges, Stimme, Geschwindigkeit beim Tippen, Muster bei den Tastenbetätigungsintervallen usw.
  • Ein Nachteil bekannter Techniken der Zwei-Faktor-Berechtigungsprüfung, bei denen ein physisches Objekt verwendet wird, besteht in ihrer Abhängigkeit von einer möglicherweise falschen Annahme, dass die ursprüngliche Anforderung unter Verwendung des physischen Objekts von einer berechtigten Einheit stammt und das physische Objekt sicher ist. Durch die weitverbreitete Nutzung der drahtlosen Nahfeldkommunikation (near field communication, NFC) und der Hochfrequenztechnik (HF-Technik) kann das physische Objekt leicht kopiert werden, wodurch die Zwei-Faktor-Berechtigungsprüfung auf eine Ein-Faktor-Berechtigungsprüfung reduziert wird, die zum Beispiel auf einer Kenntnis einer PIN-Nummer beruht.
  • Des Weiteren ist eine auf einem Chip und einer PIN beruhende Zahlungskarte anfällig gegenüber dem Abschöpfen der PIN über elektronische Mittel.
  • Darüber hinaus besteht ein Bedarf an einer Technik zur Berechtigungsprüfung, die bestätigt, dass das als einer der Berechtigungsprüfungsfaktoren dienende physische Objekt wirklich das originale physische Objekt und keine digitale Kopie des physischen Objekts ist (z.B. eine Kopie, die unter Verwendung einer der vielen bekannten Duplizierungstechnologien gescannt wurde).
  • KURZDARSTELLUNG
  • Bei einer Ausführungsform stellt die vorliegende Erfindung ein Verfahren zum Prüfen der Berechtigung einer Zahlungskarte bereit. Das Verfahren beinhaltet, dass ein Computer Informationen von der zu einem Kauf verwendeten Zahlungskarte liest. Die Informationen beinhalten eine Kennung der Zahlungskarte, Daten auf einem in der Zahlungskarte enthaltenen Chip, in Braille-Zellen auf der Zahlungskarte codierte Daten und Daten, die in Markierungen codiert sind, die in der Zahlungskarte enthalten sind. Das Verfahren beinhaltet ferner, dass der Computer die von der Zahlungskarte gelesenen Informationen entschlüsselt, indem ein Entschlüsselungsschlüssel verwendet wird, der in den Daten enthalten ist, die in den Markierungen codiert sind. Das Verfahren beinhaltet ferner, dass als Reaktion auf eine Feststellung, dass der Entschlüsselungsschlüssel korrekt ist, und auf der Grundlage der entschlüsselten Informationen der Computer an ein Zahlungssystem sendet (i) einen Hash-Wert, der von dem Chip gelesen wurde, der in der Zahlungskarte enthalten ist, (ii) die Kennung der Zahlungskarte, (iii) einen auf die Zahlungskarte gedruckten ersten Sicherheitscode und (iv) einen zweiten Sicherheitscode, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind. Das Verfahren beinhaltet ferner, dass der Computer vom Zahlungssystem einen Hash-Wert eines (n + 1)-ten Blocks eines Blockkettenhauptbuchs als Reaktion darauf empfängt, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert, (ii) die Kennung der Zahlungskarte validiert, (iii) den ersten Sicherheitscode validiert, (iv) den zweiten Sicherheitscode validiert, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind, und (v) den Hash-Wert des (n + 1)-ten Blocks erzeugt. Das Verfahren beinhaltet ferner, dass der Computer den Hash-Wert des (n + 1)-ten Blocks in dem in der Zahlungskarte enthaltenen Chip als Aktualisierung des Hash-Werts aufzeichnet, der vom Chip gelesen wurde. Das Verfahren beinhaltet ferner, dass der Computer Daten über den Kauf und den Hash-Wert des (n + 1)-ten Blocks an das Zahlungssystem sendet, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert, der bestätigt, dass der Hash-Wert des (n + 1)-ten Blocks im Chip aufgezeichnet ist, und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  • Die oben erwähnte Ausführungsform stellt eine Berechtigungsprüfung für eine Zahlungskarte bereit, die Daten beinhaltet, die in Braille-Zellen codiert sind, die in der Zahlungskarte enthalten sind, wobei die Daten nicht im Chip oder Magnetstreifen der Zahlungskarte enthalten sind, wodurch verhindert wird, dass eine Kopie der Zahlungskarte eine Transaktion durchführt, da die Kopie keine Braille-Zellen enthält oder Braille-Zellen enthält, deren Daten nicht mit den Daten übereinstimmen, die in den Braille-Zellen codiert sind, die in der Originalzahlungskarte enthalten sind. Die oben erwähnte Ausführungsform stellt eine Berechtigungsprüfung für eine Zahlungskarte bereit, die einen Verweis auf die jüngst zurückliegende Transaktion in einem Block einer Blockkette erfordert, wodurch verhindert wird, dass eine Kopie der Zahlungskarte eine Transaktion durchführt, da die Kopie nicht weiß, welcher Verweis zu dem Zeitpunkt vorliegen sollte, zu dem die Kopie versucht, eine Transaktion abzuschließen.
  • Die oben erörterten Vorteile gelten auch für Ausführungsformen des Computersystems und des Computerprogrammprodukts, die nachstehend zusammengefasst sind.
  • Bei einem optionalen Aspekt der vorliegenden Erfindung beinhalten die Markierungen ein eindeutiges Muster aus Quantenpunkten in einem Farbstoff auf mindestens einem Abschnitt der Zahlungskarte. Der Schritt des Entschlüsselns der von der Zahlungskarte gelesenen Informationen beinhaltet das Entschlüsseln von Daten, die in dem eindeutigen Muster der Quantenpunkte codiert sind, auf der Grundlage des Entschlüsselungsschlüssels. Die entschlüsselten Daten, die in dem eindeutigen Muster der Quantenpunkte codiert sind, kennzeichnen eine Person, auf die die Zahlungskarte ausgestellt ist. Der oben erwähnte Aspekt der vorliegenden Erfindung stellt vorteilhafterweise ein eindeutiges Muster oder einen Abschnitt eines eindeutigen Musters bereit, das eine bestimmte Zahlungskarte kennzeichnet und eine Bank oder ein anderes Zahlungssystem nutzen kann, um die Person zu erkennen, auf die die Zahlungskarte ausgestellt ist. Der oben erwähnte Aspekt verhindert außerdem vorteilhafterweise das Kopieren der Zahlungskarte, da eine Fotokopie der Zahlungskarte nicht in der Lage ist, das eindeutige Muster der Quantenpunkte zu kopieren. Ferner stellen die Quantenpunkte ein kostengünstiges Hindernis gegenüber dem Kopieren dar, da sich das Platzieren von Nanoelementen auf einer Kopie an exakt denselben Stellen wie die Quantenpunkte auf der Originalzahlungskarte aus Kostengründen verbietet.
  • Bei einem weiteren optionalen Aspekt der vorliegenden Erfindung wird eine betrügerische Kopie der Zahlungskarte für einen aktuellen Kauf verwendet, und ein von einem Chip in der betrügerischen Zahlungskarte gelesener Hash-Wert wird an das Zahlungssystem gesendet. Es wird ein Hinweis empfangen, dass die Transaktion zum Abschließen des Kaufs als Reaktion darauf verweigert wird, dass das Zahlungssystem (i) feststellt, dass Daten über einen jüngst zurückliegenden Kauf unter Verwendung der Zahlungskarte vor dem aktuellen Kauf in einem m-ten Block des Blockkettenhauptbuchs gespeichert sind, und (ii) feststellt, dass der Hash-Wert, der von dem in der betrügerischen Kopie der Zahlungskarte enthaltenen Chip gelesen wurde, nicht mit einem Hash-Wert des m-ten Blocks des Blockkettenhauptbuchs übereinstimmt. Der oben erwähnte Aspekt der vorliegenden Erfindung verweigert vorteilhafterweise eine Transaktion durch eine Zahlungskarte, auf der nicht der Hash-Wert eines Blocks in einem Blockkettenhauptbuch gespeichert ist, der die letzte validierte Transaktion angibt, wodurch die Karte als betrügerische Kopie der Originalkarte erkannt wird.
  • Bei einem weiteren optionalen Aspekt der vorliegenden Erfindung beinhaltet der Schritt des Lesens der Informationen von der Zahlungskarte das Lesen der in den Braille-Zellen codierten Daten und das Lesen der in den Markierungen codierten Daten ohne einen Abschnitt der in den Braille-Zellen codierten Daten und der in den Markierungen codierten Daten, die auf dem Chip oder auf einem Magnetstreifen der Zahlungskarte gespeichert sind. Der oben erwähnte Aspekt verhindert vorteilhafterweise böswillige Einträge, indem die in den Braille-Zellen und den Markierungen codierten Daten durch Lesen in einem Abstand erhalten werden oder indem Informationen auf einem Chip oder Magnetstreifen der Zahlungskarte auf andere Weise erhalten werden.
  • Bei einer weiteren Ausführungsform stellt die vorliegende Erfindung ein Computerprogrammprodukt zum Prüfen der Berechtigung einer Zahlungskarte bereit. Das Computerprogrammprodukt beinhaltet einen durch einen Computer lesbares Speichermedium. Auf dem durch einen Computer lesbaren Speichermedium sind Programmanweisungen gespeichert. Bei dem durch einen Computer lesbaren Speichermedium handelt es sich nicht um ein flüchtiges Signal an sich. Die Programmanweisungen werden durch eine Zentraleinheit (central processing unit, CPU) eines Computersystems ausgeführt, um zu bewirken, dass das System ein Verfahren durchführt. Das Verfahren beinhaltet, dass das Computersystem Informationen von der zu einem Kauf verwendeten Zahlungskarte liest. Die Informationen beinhalten eine Kennung der Zahlungskarte, Daten auf einem in der Zahlungskarte enthaltenen Chip, in Braille-Zellen auf der Zahlungskarte codierte Daten und Daten, die in Markierungen codiert sind, die in der Zahlungskarte enthalten sind. Das Verfahren beinhaltet ferner, dass das Computersystem die von der Zahlungskarte gelesenen Informationen entschlüsselt, indem ein Entschlüsselungsschlüssel verwendet wird, der in den Daten enthalten ist, die in den Markierungen codiert sind. Das Verfahren beinhaltet ferner, dass als Reaktion auf eine Feststellung, dass der Entschlüsselungsschlüssel korrekt ist, und auf der Grundlage der entschlüsselten Informationen das Computersystem an ein Zahlungssystem sendet (i) einen Hash-Wert, der von dem Chip gelesen wurde, der in der Zahlungskarte enthalten ist, (ii) die Kennung der Zahlungskarte, (iii) einen auf die Zahlungskarte gedruckten ersten Sicherheitscode und (iv) einen zweiten Sicherheitscode, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind. Das Verfahren beinhaltet ferner, dass das Computersystem vom Zahlungssystem einen Hash-Wert eines (n + 1)-ten Blocks eines Blockkettenhauptbuchs als Reaktion darauf empfängt, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert, (ii) die Kennung der Zahlungskarte validiert, (iii) den ersten Sicherheitscode validiert, (iv) den zweiten Sicherheitscode validiert, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind, und (v) den Hash-Wert des (n + 1)-ten Blocks erzeugt. Das Verfahren beinhaltet ferner, dass das Computersystem den Hash-Wert des (n + 1)-ten Blocks in dem in der Zahlungskarte enthaltenen Chip als Aktualisierung des Hash-Werts aufzeichnet, der vom Chip gelesen wurde. Das Verfahren beinhaltet ferner, dass das Computersystem Daten über den Kauf und den Hash-Wert des (n + 1)-ten Blocks an das Zahlungssystem sendet, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert, der bestätigt, dass der Hash-Wert des (n + 1)-ten Blocks im Chip aufgezeichnet ist, und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  • Bei einer weiteren Ausführungsform stellt die vorliegende Erfindung ein Computersystem bereit, das eine Zentraleinheit (CPU) beinhaltet; einen mit der CPU verbundenen Hauptspeicher; und eine durch einen Computer lesbare Speichereinheit, die mit der CPU verbunden ist. Die Speichereinheit enthält Anweisungen, die durch die CPU über den Hauptspeicher ausgeführt werden, um ein Verfahren zum Prüfen der Berechtigung einer Zahlungskarte zu realisieren. Das Verfahren beinhaltet, dass das Computersystem Informationen von der zu einem Kauf verwendeten Zahlungskarte liest. Die Informationen beinhalten eine Kennung der Zahlungskarte, Daten auf einem in der Zahlungskarte enthaltenen Chip, in Braille-Zellen auf der Zahlungskarte codierte Daten und Daten, die in Markierungen codiert sind, die in der Zahlungskarte enthalten sind. Das Verfahren beinhaltet ferner, dass das Computersystem die von der Zahlungskarte gelesenen Informationen entschlüsselt, indem ein Entschlüsselungsschlüssel verwendet wird, der in den Daten enthalten ist, die in den Markierungen codiert sind. Das Verfahren beinhaltet ferner, dass als Reaktion auf eine Feststellung, dass der Entschlüsselungsschlüssel korrekt ist, und auf der Grundlage der entschlüsselten Informationen das Computersystem an ein Zahlungssystem sendet (i) einen Hash-Wert, der von dem Chip gelesen wurde, der in der Zahlungskarte enthalten ist, (ii) die Kennung der Zahlungskarte, (iii) einen auf die Zahlungskarte gedruckten ersten Sicherheitscode und (iv) einen zweiten Sicherheitscode, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind. Das Verfahren beinhaltet ferner, dass das Computersystem vom Zahlungssystem einen Hash-Wert eines (n + 1)-ten Blocks von einem Blockkettenhauptbuch als Reaktion darauf empfängt, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert, (ii) die Kennung der Zahlungskarte validiert, (iii) den ersten Sicherheitscode validiert, (iv) den zweiten Sicherheitscode validiert, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind, und (v) den Hash-Wert des (n + 1)-ten Blocks erzeugt. Das Verfahren beinhaltet ferner, dass das Computersystem den Hash-Wert des (n + 1)-ten Blocks in dem in der Zahlungskarte enthaltenen Chip als Aktualisierung des Hash-Werts aufzeichnet, der vom Chip gelesen wurde. Das Verfahren beinhaltet ferner, dass das Computersystem Daten über den Kauf und den Hash-Wert des (n + 1)-ten Blocks an das Zahlungssystem sendet, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert, der bestätigt, dass der Hash-Wert des (n + 1)-ten Blocks im Chip aufgezeichnet ist, und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  • Figurenliste
  • Im Folgenden werden Ausführungsformen der Erfindung unter Bezugnahme auf die beigefügten Zeichnungen beispielhaft beschrieben, wobei:
    • 1 ein Blockschema eines Systems zum Prüfen der Berechtigung einer Zahlungskarte gemäß Ausführungsformen der vorliegenden Erfindung ist.
    • 2 ein Beispiel einer Zahlungskarte ist, deren Berechtigung im System von 1 gemäß Ausführungsformen der vorliegenden Erfindung geprüft wird.
    • die 3A bis 3B ein Flussdiagramm eines Prozesses zum Prüfen der Berechtigung einer durch ein Kartenlesegerät gelesenen Zahlungskarte darstellen, wobei der Prozess im System von 1 gemäß Ausführungsformen der vorliegenden Erfindung realisiert ist.
    • die 4A bis 4B ein Flussdiagramm eines Prozesses zum Prüfen der Berechtigung einer bei einer Online-Transaktion verwendeten Zahlungskarte gemäß Ausführungsformen der vorliegenden Erfindung darstellen.
    • 5 ein Beispiel der Verwendung des Systems von 1 und des Prozesses der 4A bis 4B ist, um einen betrügerischen Kauf unter Verwendung gestohlener Kreditkarteninformationen gemäß Ausführungsformen der vorliegenden Erfindung zu verhindern.
    • 6 ein erstes Beispiel der Verwendung des Systems von 1 und des Prozesses der 3A bis 3B ist, um einen betrügerischen Kauf unter Verwendung einer unberechtigten Kopie einer Kreditkarte gemäß Ausführungsformen der vorliegenden Erfindung zu verhindern.
    • 7 ein zweites Beispiel der Verwendung des Systems von 1 und des Prozesses der 3A bis 3B ist, um einen betrügerischen Kauf unter Verwendung gestohlener Kreditkarteninformationen gemäß Ausführungsformen der vorliegenden Erfindung zu verhindern.
    • 8 ein Blockschema eines Computers ist, der im System von 1 enthalten ist und die Prozesse der 3A bis 3B und 4A bis 4B gemäß Ausführungsformen der vorliegenden Erfindung realisiert.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Überblick
  • Ausführungsformen der vorliegenden Erfindung prüfen die Berechtigung eines physischen Objekts, das in einem System mit Zwei-Faktor-Berechtigungsprüfung als Originalobjekt (d.h. keine Kopie des Originalobjekts) bereitgestellt wird. Bei einer Ausführungsform handelt es sich bei dem physischen Objekt um eine sichere zugängliche Zahlungskarte, die beinhaltet (1) Braille-Elemente und zufällig platzierte Markierungen zum Bereitstellen von Benutzerinformationen und einen Schlüssel zum Decodieren von Informationen bereitzustellen, und (2) anteilige Informationen auf einem Magnetstreifen und/oder einem Chip in der Karte, die zumindest keinen Abschnitt der Informationen beinhalten, die durch die Braille-Elemente und die zufällig platzierten Markierungen bereitgestellt werden. Bei einer Ausführungsform beinhaltet ein System zur Prüfung der Berechtigung von Zahlungskarten ein Kartenlesegerät, das in der Lage ist, die Braille-Elemente und die Markierungen zu lesen und einen Hash-Wert im Chip der Karte zu speichern. Bei einer Ausführungsform kennzeichnen Datensätze, die durch eine Bankeneinheit oder ein anderes Zahlungssystem verwaltet werden, Zahlungskarten, die für sehbehinderte Benutzer ausgestellt wurden. Bei einer Ausführungsform wird ein Blockkettenhauptbuch für Transaktionen des Zahlungskarteninhabers zusammen mit Mitteln zum Aufzeichnen von Transaktionen in Blöcken des Blockkettenhauptbuchs bereitgestellt, wobei neue Blöcke gemäß der Transaktionsart markiert werden (d.h. ob die Transaktionen in einem Kartenlesegerät oder in einem Online-System ausgeführt werden), und Mitteln zum Abrufen des die jüngst zurückliegende Transaktion betreffenden Blocks aus dem Blockkettenhauptbuch gemäß der Art der auftretenden neuen Transaktion (d.h. Kartenlesegerät oder Online-System). Bei einer Ausführungsform erkennen Verarbeitungsmittel nicht vertrauenswürdige Aktionen, wenn Daten unvollständig sind und/oder der durch die Verwendung der Zahlungskarte bereitgestellte Hash-Wert nicht dem erwarteten Hash-Wert entspricht, der auf die durch die Zahlungskarte abgeschlossene letzte Transaktion verweist. Eine mobile App wird für das Mobilgerät des Zahlungskarteninhabers zur Verwendung im Falle einer Online-Transaktion oder einer Transaktion unter Verwendung eines herkömmlichen Lesegeräts zum Empfangen und Speichern des Hash-Werts bereitgestellt, der auf den Block verweist, der die jüngst zurückliegende Transaktion angibt, die vor einer aktuellen Transaktion durch die Zahlungskarte abgeschlossen wurde.
  • Ausführungsformen der vorliegenden Erfindung stellen vorteilhafterweise sicher, dass es sich bei einer Zahlungskarte um eine Originalzahlungskarte und nicht um eine berechtigte Kopie der Zahlungskarte handelt, wodurch die Nutzung unberechtigter Kopien der Zahlungskarten zum Abschließen von Käufen und anderen Transaktionen verhindert wird. Eine unberechtigte Kopie der Zahlungskarte wird daran gehindert, eine aktuelle Transaktion durchzuführen, da die Kopie nicht die Braille-Zellen oder zufällig platzierten Markierungen enthält, die in der Originalzahlungskarte enthalten sind, oder Braille-Zellen oder Markierungen enthält, deren Daten nicht mit den Daten übereinstimmen, die in den Braille-Zellen oder den Markierungen in der Originalzahlungskarte enthalten sind. Des Weiteren wird eine Kopie daran gehindert, eine aktuelle Transaktion durchzuführen, da die Kopie den Verweis auf den Block in einem Blockkettenhauptbuch nicht kennt oder keinen Zugriff darauf hat, der die jüngst zurückliegende Transaktion angibt, die vor dem Zeitpunkt der aktuellen Transaktion durch die Zahlungskarte abgeschlossen wurde. Ausführungsformen der vorliegenden Erfindung stellen Braille-Elemente auf Zahlungskarten bereit, die die oben erwähnten Vorteile bereitstellen und außerdem sehbehinderten Zahlungskarteninhabern einen Zugriff auf sichere Informationen bereitstellen, die in den Braille-Elementen codiert sind.
  • System zum Prüfen der Berechtigung einer Zahlungskarte
  • 1 ist ein Blockschema eines Systems 100 zum Prüfen der Berechtigung einer Zahlungskarte gemäß Ausführungsformen der vorliegenden Erfindung. Das System 100 beinhaltet ein Kartenlesegerät 102 und einen Computer 103. Das Kartenlesegerät 102 beinhaltet einen Computerprozessor (nicht gezeigt) und einen Hauptspeicher (nicht gezeigt) und führt über den Computerprozessor und den Hauptspeicher ein auf Software beruhendes Berechtigungsprüfungssystem 104 aus, das die Berechtigung einer Zahlungskarte 106 prüft, die im Kartenlesegerät 102 gelesen wird. Der Computer 103 führt eine Softwareanwendung (nicht gezeigt) aus, die in einem Online-Einkaufssystem verwendet wird, und führt ein Zahlungskarten-Berechtigungsprüfungssystem 105 aus, um die Berechtigung einer Zahlungskarte 106 zu prüfen, deren Daten verwendet werden, um einen Kauf in einem Online-Einkaufssystem einzuleiten. Bei einer Ausführungsform handelt es sich bei der Zahlungskarte 106 um eine Kreditkarte oder eine Bankkarte.
  • Bei dem Kartenlesegerät 102 handelt es sich um eine Dateneingabeeinheit, die Daten liest, die auf einem Magnetstreifen und oder auf einem in der Zahlungskarte 106 eingebetteten Computerchip codiert sind, zusammen mit einer Zahlungskartenkennung, die auf die Zahlungskarte 106 geprägt oder in anderer Weise darin enthalten ist, und einem auf die Zahlungskarte 106 gedruckten Sicherheitscode. Das Kartenlesegerät 102 beinhaltet eine optische Komponente, die die Oberfläche der Zahlungskarte 106 abtastet und andere in Markierungen codierte Daten liest, die unter Licht im sichtbaren Spektrum unsichtbar und auf der Zahlungskarte zufällig positioniert sind. Bei einer Ausführungsform handelt es sich bei den Markierungen um Quantenpunkte, die in „Optical Storage Device Utilizing Quantum Silos“, US-Patent Nr. 9 691482 , beschrieben sind, das durch Bezugnahme in seiner Gesamtheit einen Bestandteil des vorliegenden Dokuments bildet. Bei einer Ausführungsform enthielten die Markierungen der Zahlungskarte 106 einen Schlüssel zum Entschlüsseln von Daten auf dem in der Zahlungskarte 106 eingebetteten Computerchip, die es dem Kartenlesegerät 102 ermöglichen, einen Hash-Wert eines Blocks in einem Hauptbuch abzurufen, die die jüngst zurückliegende vorhergehende Transaktion angibt, die die Zahlungskarte 106 nutzte. Eine optische Komponente des Kartenlesegeräts 102 liest Daten, die in Braille-Zellen codiert sind, die auf die Zahlungskarte 106 geprägt sind. Bei einer Ausführungsform beinhalten die in den Braille-Zellen codierten Daten einen Sicherheitscode.
  • Das Kartenlesegerät 102 liest während einer Transaktion Daten von der Zahlungskarte 106 und sendet die Daten an ein Zahlungssystem 108 eines Ausstellers (z.B. einer Bank), der die Zahlungskarte 106 ausstellt. Das Zahlungssystem 108 führt ein auf Software beruhendes Transaktionsverarbeitungssystem 110 aus, das die aus den Braille-Zellen gelesenen Daten als Häufigkeitsmodifikator verwendet, um zu erkennen, ob die Übertragung der von der Zahlungskarte 106 gelesenen Daten ihren Ursprung in einem sicheren System hat. Das Transaktionsverarbeitungssystem 110 validiert die durch das Kartenlesegerät 102 gelesene Zahlungskartenkennung gegenüber einer Kennung, die in einem Daten-Repository 112 gespeichert ist. Das Transaktionsverarbeitungssystem 110 validiert außerdem den durch das Kartenlesegerät 102 gelesenen Hash-Wert gegenüber einem Hash-Wert des Blocks, der die jüngst zurückliegende vorhergehende Transaktion angibt, die die Zahlungskarte 106 nutzte, wobei der Hash Wert des Blocks in einem Hauptbuch 114 gespeichert ist. Bei einer Ausführungsform handelt es sich bei dem Hauptbuch 114 um ein Blockkettenhauptbuch.
  • Bei einer Ausführungsform fordert das Transaktionsverarbeitungssystem 110 eine sekundäre Validierung der Transaktion an, die die Zahlungskarte 106 nutzt, indem eine persönliche Identifikationsnummer (PIN) oder eine biometrische Kennung angefordert wird.
  • Das Transaktionsverarbeitungssystem 110 erzeugt einen neuen Hash-Wert eines nächsten Blocks des Hauptbuchs 114, der die aktuelle Transaktion angibt, bei der die Zahlungskarte 106 gegenwärtig verwendet wird. Das Kartenlesegerät 102 empfängt den neuen Hash-Wert und speichert ihn in dem in der Zahlungskarte 106 eingebetteten Computerchip.
  • Bei einer in einem Online-Einkaufssystem durchgeführten Transaktion führt das Transaktionsverarbeitungssystem 110 eine erste Ebene der Validierung durch, indem die Kennung der Zahlungskarte 106 und der Sicherheitscode gegenüber Kennungen und Sicherheitscodes validiert werden, die im Daten-Repository 112 gespeichert sind. Die gegenwärtig validierte Kennung und der gegenwärtig validierte Sicherheitscode wurden durch das Zahlungskarten-Berechtigungsprüfungssystem 105 empfangen, das im Computer 103 ausgeführt wird. Wenn der Inhaber der Zahlungskarte 106 sehbehindert ist, wird der oben erwähnte Sicherheitscode durch Braille-Zellen auf der Zahlungskarte 106 bereitgestellt; anderenfalls wird der Sicherheitscode durch gedruckte Zeichen auf der Zahlungskarte 106 bereitgestellt.
  • Das Transaktionsverarbeitungssystem 110 führt eine zweite Ebene der Validierung durch, indem ein Hash-Wert des Blocks im Hauptbuch 114 gesendet wird, der die jüngst zurückliegende vorgehende Online-Transaktion unter Verwendung der Zahlungskarte 106 angibt, wobei der Hash-Wert an ein anderes Datenaustauschmittel gesendet wird, das sich vom Online-Einkaufssystem und vom Computer 103 unterscheidet. Bei einer oder mehreren Ausführungsformen der vorliegenden Erfindung sendet das Transaktionsverarbeitungssystem 110 den oben erwähnten Hash-Wert an eine App 116 (z.B. an eine durch den Aussteller der Zahlungskarte bereitgestellte App), die auf einer mobilen Einheit des Zahlungskarteninhabers (nicht gezeigt) ausgeführt wird. Bei anderen Ausführungsformen sendet das Transaktionsverarbeitungssystem 110 den Hash-Wert an die E-Mail-Adresse oder registrierte Web-App des Zahlungskarteninhabers. Bei einer Ausführungsform wird der Hash-Wert über die auf der mobilen Einheit ausgeführte App in ein Web-Formular kopiert, das durch den Computer 103 empfangen wird, und der Computer 103 sendet den Hash-Wert dann an das Transaktionsverarbeitungssystem 110 zur Validierung gegenüber einem zuvor durch die App 116 gespeicherten Hash-Wert, wobei der zuvor gespeicherte Hash-Wert auf den Block verweist, der die jüngst zurückliegende vorhergehende Transaktion unter Verwendung der Zahlungskarte 106 angibt. Wenn das Transaktionsverarbeitungssystem 110 feststellt, dass der Hash-Wert ungültig ist, verweigert das Transaktionsverarbeitungssystem 110 anschließend die aktuelle Transaktion, wodurch eine Durchführung eines betrügerischen Kaufs verhindert wird.
  • Die Funktionalität der in 1 gezeigten Komponenten wird ausführlicher in der nachstehenden Erörterung von 2, der 3A bis 3B, der 4A bis 4B, von 5, 6 und 7 beschrieben.
  • 2 ist ein Beispiel einer Zahlungskarte 106, deren Berechtigung im System von 1 gemäß Ausführungsformen der vorliegenden Erfindung geprüft wird. Die Zahlungskarte 106 beinhaltet eine Vorderseite 202 der Karte und eine Rückseite 204 der Karte. Die Vorderseite 202 beinhaltet einen Computerchip 206 (d.h. integrierte Schaltung), der in die Zahlungskarte 106 eingebettet ist, und zufällig positionierte Markierungen 208-1, 208-2, 208-3, 208-4 und 208-5. Bei einer Ausführungsform beinhaltet der Computerchip 206 anteilige verschlüsselte Informationen über die Zahlungskarte 106. Bei einer Ausführungsform beinhalten die Markierungen 208-1, ..., 208-5 einen Schlüssel zum Entschlüsseln der Informationen im Computerchip 206. Obwohl in 2 fünf zufällig positionierte Markierungen gezeigt sind, beinhalten Ausführungsformen der vorliegenden Erfindung N zufällig positionierte Markierungen auf der Zahlungskarte 106, wobei N eine Ganzzahl größer oder gleich zwei ist. Bei einer Ausführungsform handelt es sich bei den Markierungen 208-1, ..., 208-5 um Quantenpunkte. Bei einer Ausführungsform randomisiert ein Zufallszahlengenerator (nicht gezeigt) die Positionen der Markierungen auf der Zahlungskarte 106.
  • Die Rückseite 204 der Zahlungskarte 106 beinhaltet einen Magnetstreifen 210, erste Braille-Zellen 212 und zweite Braille-Zellen 214. Der Magnetstreifen 210 beinhaltet verschlüsselte, anteilige Informationen über die Zahlungskarte 106. Die ersten Braille-Zellen 212 beinhalten einen Sicherheitscode, der zur Validierung der Zahlungskarte 106 verwendet wird. Die zweiten Braille-Zellen 214 beinhalten Informationen über die Zahlungskarte 106 wie zum Beispiel den Namen der Finanzdienstleistungseinheit, die Zahlungen für Käufe unter Verwendung der Zahlungskarte 106 verarbeitet, eine Angabe darüber, ob es sich bei der Zahlungskarte 106 um eine Kreditkarte oder eine Bankkarte handelt, und die konkrete Art von Karte, die Merkmale angibt, die dem Inhaber der Zahlungskarte 106 zur Verfügung stehen.
  • Prozesse zum Prüfen der Berechtigung einer Zahlungskarte
  • Die 3A bis 3B stellen ein Flussdiagramm eines Prozesses zum Prüfen der Berechtigung einer durch ein Kartenlesegerät gelesenen Zahlungskarte dar, wobei der Prozess im System von 1 gemäß Ausführungsformen der vorliegenden Erfindung realisiert ist. Der Prozess der 3A bis 3B beginnt bei Schritt 300 in 3A. In Schritt 302 liest das im Kartenlesegerät 102 (siehe 1) ausgeführte Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1) Informationen von der Zahlungskarte 106 (siehe 1), die verwendet werden, um einen Kauf in einer Transaktion vorzunehmen (im Folgenden die „aktuelle Transaktion“). Die in Schritt 302 gelesenen Informationen beinhalten (1) eine Kennung (ID) der Zahlungskarte 106 (siehe 1) (z.B. eine auf die Zahlungskarte 106 geprägte ID (siehe 1)), (2) verschlüsselte Daten, die auf einem in der Zahlungskarte 106 eingebetteten Computerchip gespeichert sind (siehe 1), (3) Daten, die in Braille-Zellen auf der Zahlungskarte 106 codiert sind (siehe 1), und (4) Daten, die in zufällig auf der Zahlungskarte 106 positionierten Markierungen codiert sind (siehe 1).
  • Vor dem Schritt 304 ermittelt das Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1) einen Entschlüsselungsschlüssel, der in den Daten enthalten ist, die in Braille-Zellen codiert sind, die in Schritt 302 gelesen wurden, in den Daten, die in den Markierungen codiert sind, die in Schritt 302 gelesen wurden, oder in einer Kombination aus den Daten, die in den Braille-Zellen codiert sind, und den Daten, die in den Markierungen codiert sind, die in Schritt 302 gelesen wurden. In Schritt 304 entschlüsselt das Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1) unter Verwendung des Entschlüsselungsschlüssels Daten auf dem Computerchip, die in Schritt 302 gelesen wurden.
  • In Schritt 306 ermittelt das Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1), ob der Entschlüsselungsschlüssel korrekt ist. Wenn der Entschlüsselungsschlüssel in Schritt 306 als nicht korrekt ermittelt wird, wird der „Nein“-Zweig des Schritts 306 eingeschlagen, und Schritt 308 wird durchgeführt. In Schritt 308 verweigert das Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1) die aktuelle Transaktion. In Schritt 310 endet der Prozess der 3A bis 3B.
  • Unter erneuter Bezugnahme auf Schritt 306 werden der „Ja“-Zweig des Schritts 306 eingeschlagen und Schritt 312 durchgeführt, wenn das Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1) feststellt, dass der Entschlüsselungsschlüssel korrekt ist. In Schritt 312 sendet das Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1) an das Zahlungssystem 108 (siehe 1) des Ausstellers der Zahlungskarte 106 (siehe 1) Informationen, die beinhalten: (1) einen in Schritt 302 vom Computerchip gelesenen und in Schritt 304 entschlüsselten Hash-Wert; (2) die ID der Zahlungskarte 106 (siehe 1), die in Schritt 302 gelesen wurde; (3) einen ersten Sicherheitscode, der auf die Zahlungskarte 106 gedruckt ist (siehe 1); und (4) einen zweiten Sicherheitscode, der in den Daten enthalten ist, die in den Braille-Zellen verschlüsselt sind, die in Schritt 302 gelesen wurden. Das Zahlungssystem 108 (siehe 1) empfängt die in Schritt 312 gesendeten Informationen.
  • In Schritt 314 ruft das Zahlungssystem 108 (siehe 1) einen Hash-Wert eines n-ten Blocks aus dem Hauptbuch 114 ab (siehe 1), der die jüngste zurückliegende vorhergehende Transaktion unter Verwendung der Zahlungskarte 106 angibt (siehe 1), und validiert den in Schritt 312 gesendeten Hash-Wert gegenüber dem abgerufenen Hash-Wert des n-ten Blocks. Schritt 314 beinhaltet außerdem, dass das Zahlungssystem 108 (siehe 1) die ID der Zahlungskarte 106 (siehe 1) und den in Schritt 312 gesendeten ersten und zweiten Sicherheitscode validiert.
  • In Schritt 316 ermittelt das Zahlungssystem 108 (siehe 1), ob die Validierung in Schritt 314 feststellt, dass es sich bei der Zahlungskarte 106 (siehe 1) um eine gültige Zahlungskarte handelt. Wenn die Zahlungskarte 106 (siehe 1) in Schritt 316 als nicht gültig ermittelt wird, wird der „Nein“-Zweig des Schritts 316 eingeschlagen, und Schritt 318 wird durchgeführt. In Schritt 318 verweigert das Zahlungssystem 108 (siehe 1) die aktuelle Transaktion unter Verwendung der Zahlungskarte 106 (siehe 1). Der Prozess der 3A bis 3B endet bei Schritt 320.
  • Unter erneuter Bezugnahme auf Schritt 316 wird der „Ja“-Zweig des Schritts 316 eingeschlagen, und Schritt 322 wird durchgeführt, wenn die Zahlungskarte 106 (siehe 1) als gültig ermittelt wird. In Schritt 322 erzeugt das Zahlungssystem 108 (siehe 1) einen Hash-Wert eines (n + 1)-ten Blocks im Hauptbuch 114, der die aktuelle Transaktion unter Verwendung der Zahlungskarte 106 angibt (siehe 1). In Schritt 324 sendet das Zahlungssystem 108 (siehe 1) den Hash-Wert des (n + 1)-ten Blocks an das Kartenlesegerät 102 (siehe 1). Das Kartenlesegerät 102 (siehe 1) empfängt den in Schritt 324 gesendeten Hash-Wert des (n + 1)-ten Blocks.
  • In Schritt 326 in 3B zeichnet das Kartenlesegerät 102 (siehe 1) den Hash-Wert des (n + 1)-ten Blocks in dem in der Zahlungskarte 106 (siehe 1) eingebetteten Computerchip als Aktualisierung des Hash-Werts des n-ten Blocks auf, der in den Informationen enthalten ist, die in Schritt 302 (siehe 3A) gelesen und in Schritt 304 entschlüsselt wurden (siehe 3A).
  • In Schritt 328 sendet das Kartenlesegerät 102 (siehe 1) (1) Daten über den Kauf in der aktuellen Transaktion und (2) den Hash-Wert des (n + 1)-ten Blocks an das Zahlungssystem 108 (siehe 1). Das Zahlungssystem 108 (siehe 1) empfängt den in Schritt 328 gesendeten Hash-Wert.
  • In Schritt 330 validiert das Zahlungssystem 108 (siehe 1) den Hash-Wert des (n + 1)-ten Blocks. In Schritt 332 fügt das Zahlungssystem 108 (siehe 1) die Daten über den Kauf als Transaktion in den (n + 1)-ten Block ein.
  • Bei einer Ausführungsform beinhaltet eine Berechtigungsprüfung der Zahlungskarte 106 (siehe 1) für die aktuelle Transaktion eine Durchführung des Schritts 322 in 3A und der Schritte 330 und 332 in 3B.
  • Der Prozess der 3A bis 3B endet bei Schritt 334.
  • Die 4A bis 4B stellen ein Flussdiagramm eines Prozesses zum Prüfen der Berechtigung einer bei einer Online-Transaktion verwendeten Zahlungskarte gemäß Ausführungsformen der vorliegenden Erfindung dar. Der Prozess der 4A bis 4B beginnt bei Schritt 400. In Schritt 402 empfängt das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1) Informationen von der Zahlungskarte 106 (siehe 1), die bei einer aktuellen Transaktion für einen Kauf in einem Online-Einkaufssystem verwendet wird. Die in Schritt 402 empfangenen Informationen beinhalten: die ID der Zahlungskarte 106 (siehe 1), einen ersten Sicherheitscode, der auf die Zahlungskarte 106 gedruckt ist (siehe 1), und einen zweiten Sicherheitscode, der in den Braille-Zellen auf der Zahlungskarte 106 enthalten ist (siehe 1). Nach Schritt 402 und vor Schritt 404 sendet das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1) die in Schritt 402 empfangenen Informationen an das Zahlungssystem 108 (siehe 1).
  • In Schritt 404 validiert das Transaktionsverarbeitungssystem 110 (siehe 1) im Zahlungssystem 108 (siehe 1) die ID und den an das Zahlungssystem 108 (siehe 1) gesendeten ersten und zweiten Sicherheitscode gegenüber einer ID und gegenüber Sicherheitscodes, die zur Zahlungskarte 106 gehörig und im Daten-Repository 112 gespeichert sind (siehe 1). In Schritt 406 ermittelt das Transaktionsverarbeitungssystem 110 (siehe 1), ob die Validierung in Schritt 404 anzeigt, dass es sich bei der Zahlungskarte 106 (siehe 1) in der aktuellen Transaktion um eine gültige Zahlungskarte handelt. Wenn das Transaktionsverarbeitungssystem 110 (siehe 1) feststellt, dass die Zahlungskarte 106 (siehe 1) nicht gültig ist, wird der „Nein“-Zweig des Schritts 406 eingeschlagen, und Schritt 408 wird durchgeführt.
  • In Schritt 408 verweigert das Transaktionsverarbeitungssystem 110 (siehe 1) die aktuelle Transaktion. In Schritt 410 endet der Prozess der 4A bis 4B.
  • Unter erneuter Bezugnahme auf Schritt 406 wird der „Ja“-Zweig des Schritts 406 eingeschlagen, und Schritt 412 wird durchgeführt, wenn das Transaktionsverarbeitungssystem 110 (siehe 1) feststellt, dass die Zahlungskarte 106 gültig ist (siehe 1). In Schritt 412 ruft das Transaktionsverarbeitungssystem 110 (siehe 1) einen Hash-Wert des n-ten Blocks aus dem Hauptbuch 114 ab (siehe 1).
  • In Schritt 414 sendet das Transaktionsverarbeitungssystem 110 (siehe 1) den Hash-Wert des n-ten Blocks an die App 116 (siehe 1) (z.B. eine Bank-App) die auf der mobilen Einheit des Inhabers der Zahlungskarte 106 ausgeführt wird (siehe 1).
  • In Schritt 416 empfängt die App 116 (siehe 1) den in Schritt 414 gesendeten Hash-Wert und kopiert den Hash-Wert des n-ten Blocks in ein Web-Formular zum Empfang durch das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1), das im Computer 103 ausgeführt wird (siehe 1), der gegenwärtig für die aktuelle Transaktion verwendet wird. Vor Schritt 418 empfängt das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1) den Hash-Wert, der in Schritt 416 in das Web-Formular kopiert wurde.
  • In Schritt 418 sendet das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1) den Hash-Wert des n-ten Blocks an das Zahlungssystem 108 (siehe 1). Nach Schritt 418 wird der Prozess der 4A bis 4B in 4B fortgesetzt.
  • In Schritt 420 in 4B empfängt das Transaktionsverarbeitungssystem 110 (siehe 1) den in Schritt 418 gesendeten Hash-Wert (siehe 4A) und validiert den empfangenen Hash-Wert gegenüber dem Hash-Wert des im Hauptspeicher 114 gespeicherten n-ten Blocks (siehe 1).
  • In Schritt 422 ermittelt das Transaktionsverarbeitungssystem 110 (siehe 1), ob die Validierung in Schritt 420 anzeigt, dass die Zahlungskarte 106 gültig ist (siehe 1). Wenn das Transaktionsverarbeitungssystem 110 (siehe 1) in Schritt 422 feststellt, dass die Validierung in Schritt 420 anzeigt, dass die Zahlungskarte 106 (siehe 1) nicht gültig ist, wird der „Nein“-Zweig des Schritts 422 eingeschlagen, und Schritt 424 wird durchgeführt. In Schritt 424 verweigert das Transaktionsverarbeitungssystem 110 (siehe 1) die aktuelle Transaktion. Der Prozess der 4A bis 4B endet bei Schritt 426.
  • Unter erneuter Bezugnahme auf Schritt 422 wird der „Ja“-Zweig des Schritts 422 eingeschlagen, und Schritt 428 wird durchgeführt, wenn das Transaktionsverarbeitungssystem 110 (siehe 1) feststellt, dass die Validierung in Schritt 420 anzeigt, dass die Zahlungskarte 106 gültig ist (siehe 1). In Schritt 428 erzeugt das Transaktionsverarbeitungssystem 110 (siehe 1) einen Hash-Wert des (n + 1)-ten Blocks des Hauptbuch 114 (siehe 1).
  • In Schritt 430 sendet das Transaktionsverarbeitungssystem 110 (siehe 1) den Hash-Wert des (n + 1)-ten Blocks an (1) das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1), das gegenwärtig im Computer 103 ausgeführt wird (siehe 1), und (2) die App 116 (siehe 1) die gegenwärtig in der mobilen Einheit des Inhabers der Zahlungskarte 106 ausgeführt wird (siehe 1).
  • In Schritt 432 empfängt die App 116 (siehe 1) den in Schritt 430 gesendeten Hash-Wert des (n + 1)-ten Blocks und zeichnet den Hash-Wert des (n + 1)-ten Blocks in einem Daten-Repository in der mobilen Einheit des Inhabers der Zahlungskarte 106 auf (siehe 1).
  • In Schritt 434 sendet das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1) Daten über den Kauf in der aktuellen Transaktion und den Hash-Wert des (n + 1)-ten Blocks an das Transaktionsverarbeitungssystem 110 (siehe 1). Nach Schritt 434 und vor Schritt 436 empfängt das Transaktionsverarbeitungssystem 110 (sie 1) die Daten und den Hash-Wert, die in Schritt 434 gesendet wurden.
  • In Schritt 436 validiert das Transaktionsverarbeitungssystem 110 (siehe 1) den in Schritt 434 gesendeten Hash-Wert (n + 1)-ten Blocks. In Schritt 438 fügt das Transaktionsverarbeitungssystem 110 (siehe 1) Daten über den Kauf in der aktuellen Transaktion zum (n + 1)-ten Block im Hauptbuch 114 hinzu (siehe 1). Im Anschluss an Schritt 438 endet der Prozess der 4A bis 4B bei Schritt 426.
  • Beispiele
  • 5 ist ein Beispiel 500 der Verwendung des Systems von 1 und des Prozesses der 4A bis 4B, um einen betrügerischen Kauf unter Verwendung gestohlener Kreditkarteninformationen gemäß Ausführungsformen der vorliegenden Erfindung zu verhindern. In Schritt 502 verwendet ein Kreditkarteninhaber C eine Kreditkarte bei einer Transaktion zum Kauf von Früchten in einem physischen Supermarkt. Bei der Kreditkarte handelt es sich um ein Beispiel der Zahlungskarte 106 (siehe 1). Das Transaktionsverarbeitungssystem 110 (siehe 1) erzeugt ein „X“ als Verweis auf einen Block in einem Blockkettenhauptbuch (d.h. Blockkettenhauptbuch 114 in 1), der die Transaktion angibt, über die die Früchte gekauft wurden.
  • In Schritt 504 geht C nach Hause und nutzt dieselbe Kreditkarte, um eine Online-Transaktion zum Kauf eines Mobiltelefons über eine elektronische Handelswebsite einzuleiten.
  • In Schritt 506 gibt C den Verweis „X“ in ein Web-Formular ein, um die Online-Transaktion abzuschließen, wobei „X“ während der Transaktion im Supermarkt erzeugt wurde. Bei Schritt 506 handelt es sich um ein Beispiel des Schritts 416 in 4A.
  • In Schritt 508 erzeugt das Transaktionsverarbeitungssystem 110 (siehe 1) als Reaktion auf die Online-Transaktion „Y“ als Verweis auf einen neuen Block im Hauptbuch 114 (siehe 1), wobei es sich bei dem neuen Block um den nächsten Block nach dem Block handelt, auf den durch „X“ verwiesen wird. Bei Schritt 508 handelt es sich um ein Beispiel des Schritts 428 in 4B.
  • In Schritt 510 stiehlt ein Hacker zur Kreditkarte gehörige Daten und in den Verweis „X“ aus der Eingabe von C in Schritt 506.
  • In Schritt 512 verwendet der Hacker die zur Kreditkarte gehörige Daten zum Einleiten einer Online-Transaktion, um einen betrügerischen Kauf vorzunehmen. Bei Schritt 512 handelt es sich um ein Beispiel des Schritts 402 in 4A.
  • In Schritt 514 fordert das Transaktionsverarbeitungssystem 110 (siehe 1) den Verweis auf die letzte Transaktion von C an (d.h. Verweis „Y“, der auf den durch C vorgenommenen Kauf des Mobiltelefons in der Online-Transaktion verweist).
  • In Schritt 516 stellt die Online-Transaktion des Hackers möglicherweise den Verweis auf „X“ bereit (den der Hacker gestohlen hatte), stellt aber nicht den Verweis „Y“ bereit, da der Hacker „Y“ nicht gestohlen hat. Bei Schritt 516 handelt es sich um ein Beispiel der Schritte 416 und 418 in 4A.
  • In Schritt 518 stellt das Transaktionsverarbeitungssystem 110 (siehe 1) fest, dass der durch die Online-Transaktion des Hackers gesendete Hash-Wert nicht mit dem Verweis „Y“ (d.h. dem Verweis auf die durch den Karteninhaber abgeschlossene letzte Transaktion) übereinstimmt, und verweigert als Reaktion die Transaktion des Hackers (d.h. schließt sie nicht ab) und verhindert den betrügerischen Kauf. Bei Schritt 518 handelt es sich um ein Beispiel der Schritte 422 und 424 in 4B.
  • 6 ist ein erstes Beispiel 600 der Verwendung des Systems von 1 und des Prozesses der 3A bis 3B, um einen betrügerischen Kauf unter Verwendung einer unberechtigten Kopie einer Kreditkarte gemäß Ausführungsformen der vorliegenden Erfindung zu verhindern. In Schritt 602 erzeugt eine Person Z eine Kopie der Kreditkarte eines Karteninhabers E. Bei der Kreditkarte von E handelt es sich um ein Beispiel der Zahlungskarte 106 (siehe 1).
  • In Schritt 604 verwendet Z die Kopie im Kartenlesegerät 102 (siehe 1), um eine Transaktion an einer Tankstelle einzuleiten.
  • In Schritt 606 erkennt das Kartenlesegerät 102 (siehe 1), dass die Braille-Zellen, die den Sicherheitscode beinhalten, auf der Kopie fehlen, die gegenwärtig im Kartenlesegerät 102 gelesen wird (siehe 1). Bei Schritt 606 handelt es sich um ein Beispiel eines Schritts, der in Schritt 302 (siehe 3A) enthalten ist.
  • In Schritt 608 stellt das Transaktionsverarbeitungssystem 110 (siehe 1) fest, dass der Sicherheitscode nicht validiert werden kann, der eigentlich in den Daten in den Braille-Zellen enthalten sein soll, da die Braille-Zellen fehlen, und verweigert als Reaktion die Transaktion an der Tankstelle und meldet die Transaktion als betrügerisch. Bei Schritt 608 handelt es sich um ein Beispiel des Schritts 318 (siehe 3A).
  • 7 ist ein zweites Beispiel 700 der Verwendung des Systems von 1 und des Prozesses der 3A bis 3B, um einen betrügerischen Kauf unter Verwendung gestohlener Kreditkarteninformationen gemäß Ausführungsformen der vorliegenden Erfindung zu verhindern. In Schritt 702 erzeugt die Person Z eine Kopie der Kreditkarte eines Karteninhabers J. Bei der Kreditkarte von J handelt es sich um ein Beispiel der Zahlungskarte 106 (siehe 1).
  • In Schritt 704 hat Z Braille-Zellen zur Kopie hinzugefügt. In Schritt 706 verwendet Z die Kopie im Kartenlesegerät 102 (siehe 1). In Schritt 708 erkennt das Transaktionsverarbeitungssystem 110 (siehe 1), dass die Braille-Zellen auf der Kopie keinen Sicherheitscode bereitstellen, der mit dem Sicherheitscode übereinstimmt, der durch die Braille-Zellen auf der Originalkreditkarte bereitgestellt wird. Bei Schritt 708 handelt es sich um ein Beispiel des Schritts 314 in 3A. In Schritt 710 verweigert das Transaktionsverarbeitungssystem 110 (siehe 1) als Reaktion darauf, dass der Code in den Braille-Zellen auf der Kopie nicht mit dem Code in den Braille-Zellen auf der Originalkreditkarte übereinstimmt, die Transaktion an der Tankstelle und meldet die Transaktion als betrügerisch. Bei Schritt 710 handelt es sich um ein Beispiel des Schritts 318 (siehe 3A).
  • Computersystem
  • 8 ist ein Blockschema eines Computers, der im System von 1 enthalten ist und die Prozesse der 3A bis 3B und 4A bis 4B gemäß Ausführungsformen der vorliegenden Erfindung realisiert. Bei dem Computer 102 handelt es sich um ein Computersystem, das im Allgemeinen eine Zentraleinheit (CPU) 802, einen Hauptspeicher 804, eine Eingabe-/Ausgabe-Schnittstelle (E/A-Schnittstelle) 806 und einen Bus 808 beinhaltet. Ferner ist der Computer 102 mit E/A-Einheiten 810 und einer Computerdatenspeichereinheit 812 verbunden. Die CPU 802 führt Berechnungs- und Steuerfunktionen des Computers 800 durch, darunter das Ausführen von im Programmcode 814 enthaltenen Anweisungen für das Zahlungskarten-Berechtigungsprüfungssystem 104 (siehe 1) oder das Zahlungskarten-Berechtigungsprüfungssystem 105 (siehe 1), um ein Verfahren zum Prüfen der Berechtigung einer Zahlungskarte durchzuführen, wobei die Anweisungen durch die CPU 802 über den Hauptspeicher 804 ausgeführt werden. Die CPU 802 kann eine einzige Verarbeitungseinheit beinhalten oder über eine oder mehrere Verarbeitungseinheiten hinweg an einem oder mehreren Standorten verteilt sein (z.B. auf einem Client und einem Server). Bei einer Ausführungsform handelt es sich bei dem Computer 800 um das Kartenlesegerät 102 (siehe 1) oder den Computer 103 (siehe 1).
  • Der Hauptspeicher 804 beinhaltet ein bekanntes durch einen Computer lesbares Speichermedium, das im Folgenden beschrieben ist. Bei einer Ausführungsform stellen Cache-Speicherelemente des Hauptspeichers 804 eine zeitweilige Speicherung von mindestens einem Teil des Programmcodes (z.B. des Programmcode 814) bereit, um die Anzahl der Abrufe von Code aus dem Massenspeicher zu verringern, während Anweisungen des Programmcodes ausgeführt werden. Darüber hinaus kann sich der Hauptspeicher 804 ähnlich wie die CPU 802 an einem einzigen physischen Ort befinden, darunter einige oder mehrere Arten von Datenspeichern, oder in verschiedenen Formen über eine Mehrzahl physischer Systeme hinweg verteilt sein. Ferner kann der Hauptspeicher 804 Daten beinhalten, die zum Beispiel über ein lokales Netzwerk (local area network, LAN) oder ein Weitverkehrsnetzwerk (wide area network, WAN) hinweg verteilt sind.
  • Die E/A-Schnittstelle 806 beinhaltet ein beliebiges System zum Übertragen von Daten zu oder von einer externen Quelle. Zu den E/A-Einheiten 810 gehören beliebige bekannte Arten externer Einheiten, darunter eine Anzeige, eine Tastatur usw. Der Bus 808 stellt eine Datenaustauschverbindung zwischen jeder der Komponenten im Computer 800 bereit und kann eine beliebige Art von Übertragungsverbindung beinhalten, unter anderem elektrisch, optisch, drahtlos usw.
  • Die E/A-Schnittstelle 806 ermöglicht einem Computer 800 außerdem, Informationen (z.B. Daten oder Programmanweisungen wie zum Beispiel den Programmcode 814) auf der Computerdatenspeichereinheit 812 oder einer anderen Computerdatenspeichereinheit (nicht gezeigt) zu speichern oder von dieser abzurufen. Die Computerdatenspeichereinheit 812 beinhaltet ein bekanntes durch einen Computer lesbares Speichermedium, das im Folgenden beschrieben ist. Bei einer Ausführungsform handelt es sich bei der Computerdatenspeichereinheit 812 um eine nicht flüchtige Datenspeichereinheit wie zum Beispiel ein Magnetplattenlaufwerk (d.h. Festplattenlaufwerk) oder ein optisches Plattenlaufwerk (z.B. ein CD-ROM-Laufwerk, das eine CD-ROM-Platte aufnimmt).
  • Der Hauptspeicher 804 und/oder die Speichereinheit 812 können den Computerprogrammcode 814 speichern, der Anweisungen beinhaltet, die durch die CPU 802 über den Hauptspeicher 804 ausgeführt werden, um die Berechtigung einer Zahlungskarte zu prüfen. Obwohl der Hauptspeicher 804 in 8 so dargestellt ist, dass er Programmcode beinhaltet, sieht die vorliegende Erfindung Ausführungsformen vor, bei denen der Hauptspeicher 804 nicht gleichzeitig den gesamten Code 814 beinhaltet, sondern stattdessen jeweils nur einen Abschnitt des Codes 814 beinhaltet.
  • Ferner kann der Hauptspeicher 804 ein Betriebssystem (nicht gezeigt) und in 8 nicht gezeigte andere Systeme beinhalten.
  • Die Speichereinheit 812 und/oder eine oder mehrere andere Computerdatenspeichereinheiten (nicht gezeigt), die mit dem Computer 800 verbunden sind, können eine Kennung und Sicherheitscodes der Zahlungskarte 106 (siehe 1) und Daten beinhalten, die von einem Computerchip gelesen wurden, der in die Zahlungskarte 106 eingebettet ist (siehe 1).
  • Wie dem Fachmann klar sein wird, kann es sich bei einer ersten Ausführungsform bei der vorliegenden Erfindung um ein Verfahren handeln; bei einer zweiten Ausführungsform kann es sich bei der vorliegenden Erfindung um ein System handeln; und bei einer dritten Ausführungsform kann es sich bei der vorliegenden Erfindung um ein Computerprogrammprodukt handeln.
  • Beliebige der Komponenten einer Ausführungsform der vorliegenden Erfindung können durch einen Dienstanbieter installiert, verwaltet, gewartet usw. werden, zu dessen Angebot das Bereitstellen oder Integrieren von Computerinfrastruktur in Bezug auf das Prüfen der Berechtigung einer Zahlungskarte gehört. Daher offenbart eine Ausführungsform der vorliegenden Erfindung einen Prozess zum Unterstützen von Computerinfrastruktur, wobei der Prozess das Bereitstellen mindestens eines Unterstützungsdienstes für mindestens eines aus Integrieren, Hosten, Pflegen und Bereitstellen von durch einen Computer lesbarem Code (z.B. des Programmcodes 814) in einem Computersystem (z.B. im Computer 800) einschließlich eines oder mehrerer Prozessoren (z.B. der CPU 802) beinhaltet, wobei der bzw. die Prozessor(en) im Code enthaltene Anweisungen ausführt bzw. ausführen, die bewirken, dass das Computersystem die Berechtigung einer Zahlungskarte prüft. Eine weitere Ausführungsform offenbart einen Prozess zum Unterstützen von Computerinfrastruktur, wobei der Prozess das Integrieren von durch einen Computer lesbarem Programmcode in ein Computersystem beinhaltet, das einen Prozessor beinhaltet. Der Prozess des Integrierens beinhaltet das Speichern des Programmcodes in einer durch einen Computer lesbaren Speichereinheit des Computersystems durch Verwendung des Prozessors. Der Programmcode realisiert nach dem Ausführen durch den Prozessor ein Verfahren zum Prüfen der Berechtigung einer Zahlungskarte.
  • Obwohl es sich versteht, dass der Programmcode 814 zum Prüfen der Berechtigung einer Zahlungskarte durch direktes manuelles Laden in Client-, Server- und Proxy-Computer (nicht gezeigt) bereitgestellt werden kann, indem ein durch einen Computer lesbares Speichermedium (z.B. die Computerdatenspeichereinheit 812) geladen wird, kann der Programmcode 814 auch automatisch oder halbautomatisch im Computer 800 bereitgestellt werden, indem der Programmcode 814 an einen zentralen Server oder eine Gruppe zentraler Server gesendet wird. Der Programmcode 814 wird anschließend in Client-Computer (z.B. den Computer 800) heruntergeladen, die den Programmcode 814 ausführen. Alternativ wird der Programmcode 814 per eMail direkt an den Client-Computer gesendet. Der Programmcode 814 wird dann mit Hilfe einer Schaltfläche in der eMail, die ein Programm ausführt, das den Programmcode 814 in ein Verzeichnis herauslöst, entweder in ein Verzeichnis auf dem Client-Computer herausgelöst oder in ein Verzeichnis auf dem Client-Computer geladen. Eine weitere Alternative besteht darin, den Programmcode 814 direkt in ein Verzeichnis auf der Festplatte des Client-Computers zu senden. Bei Vorhandensein von Proxy-Servern wählt der Prozess den Code des Proxy-Servers aus, ermittelt, auf welchen Computern der Code der Proxy-Server abgelegt werden soll, überträgt den Code des Proxy-Servers und installiert dann den Code des Proxy-Servers auf dem Proxy-Computer. Der Programmcode 814 wird zum Proxy-Server übertragen und danach auf dem Proxy-Server gespeichert.
  • Eine weitere Ausführungsform der Erfindung stellt ein Verfahren bereit, das die Prozessschritte auf der Grundlage von Abonnements, Werbung und/oder Gebühren durchführt. Das bedeutet, dass ein Dienstanbieter wie zum Beispiel ein Lösungsanbieter anbieten kann, einen Prozess zum Prüfen der Berechtigung einer Zahlungskarte einschließlich des entsprechenden Supports usw. zu erstellen und zu pflegen. In diesem Fall kann der Dienstanbieter eine Computerinfrastruktur schaffen, aufrechterhalten, unterstützen usw., die die Prozessschritte für einen oder mehrere Kunden durchführt. Im Gegenzug kann der Dienstanbieter im Rahmen einer Abonnement- und oder Gebührenvereinbarung Zahlungen von den Kunden erhalten, und/oder der Dienstanbieter kann Zahlungen aus dem Verkauf von Werbeinhalten an einen oder mehrere Dritte erhalten.
  • Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt in einem beliebigen möglichen Integrationsgrad technischer Einzelheiten handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) (z.B. den Hauptspeicher 804 und die Computerdatenspeichereinheit 812) beinhalten, auf dem/denen durch einen Computer lesbare Programmanweisung 814 gespeichert sind, um einen Prozessor (z.B. die CPU 802) zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
  • Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen (z.B. den Programmcode 814) zur Verwendung durch eine Einheit zur Ausführung von Anweisungen (z.B. den Computer 800) behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel, ohne auf diese beschränkt zu sein, um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder eine beliebige geeignete Kombination des Vorstehenden handeln. Zu einer nicht erschöpfenden Liste konkreterer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine transportable Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (random access memory, RAM), ein Nur-Lese-Speicher (read-only memory, ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (erasable programmable read-only memory, EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (static random access memory, SRAM), ein transportabler Kompaktspeicherplatte-Nur-Lese-Speicher (compact disc read-only memory, CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und beliebige geeignete Kombinationen des Vorstehenden. Ein durch einen Computer lesbares Speichermedium im hierin verwendeten Sinne ist nicht so auszulegen, dass es sich dabei um flüchtige Signale an sich handelt, wie zum Beispiel um Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, um elektromagnetische Wellen, die sich durch einen Hohlleiter oder andere Übertragungsmedien ausbreiten (z.B. Lichtimpulse, die ein Lichtwellenleiterkabel durchlaufen) oder um elektrische Signale, die über ein Kabel übertragen werden.
  • Hierin beschriebene durch einen Computer lesbare Programmanweisungen (z.B. der Programmcode 814) können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten (z.B. den Computer 800) oder über ein Netzwerk (nicht gezeigt) wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer (z.B. die Datenspeichereinheit 812) oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenleiter, Drahtlosübertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte (nicht gezeigt) oder Netzwerkschnittstelle (nicht gezeigt) in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
  • Bei durch einen Computer lesbaren Programmanweisungen (z.B. dem Programmcode 814) zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (ISA = Instruction Set Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben sind, darunter objektorientierte Programmiersprachen wie z.B. Smalltalk, C++ o.Ä. sowie herkömmliche prozedurale Programmiersprachen wie zum Beispiel die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers' teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Beim letztgenannten Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers über eine beliebige Art von Netzwerk verbunden sein, unter anderem über ein lokales Netzwerk (Local Area Network, LAN) oder über ein Weitverkehrsnetzwerk (Wide Area Network, WAN), oder die Verbindung kann zu einem externen Computer hergestellt sein (beispielsweise über das Internet unter Nutzung eines Internet-Dienstanbieters (Internet Service Provider)). Bei einigen Ausführungsformen können elektronische Schaltungen, zu denen beispielsweise programmierbare Logikschaltungen, vor Ort programmierbare Schaltkreise (Field-Programmable Gate Arrays, FPGA) oder programmierbare logische Arrays (PLA) gehören, die durch einen Computer lesbaren Programmanweisungen ausführen, indem Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen genutzt werden, um die elektronische Schaltung zu personalisieren, sodass Aspekte der vorliegenden Erfindung durchgeführt werden.
  • Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Flussdiagrammdarstellungen (z.B. die 3A bis 3B und die 4A bis 4B) und/oder Blockschemata (z.B. 1 und 8) von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird klar sein, dass jeder Block der Flussdiagrammdarstellungen und/oder der Blockschemata sowie Kombinationen von Blöcken in den Flussdiagrammdarstellungen und/oder den Blockschemata mi Hilfe durch einen Computer lesbarer Programmanweisungen (z.B. des Programmcodes 814) ausgeführt werden können.
  • Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor (z.B. der CPU 802) eines Mehrzweckcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung (z.B. des Computers 800) bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen Mittel zur Realisierung der in dem Block bzw. den Blöcken der Flussdiagramme und/oder der Blockschemata festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium (z.B. der Computerdatenspeichereinheit 812) gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, sodass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, die Aspekte der/des in dem Block bzw. den Blöcken des Flussdiagramms und/oder des Blockschemas angegebenen Funktion/Vorgangs realisieren.
  • Die durch einen Computer lesbaren Programmanweisungen (z.B. der Programmcode 814) können auch auf einen Computer (z.B. den Computer 800), eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu bewirken, um einen auf einem Computer ausgeführten Prozess zu erzeugen, sodass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Flussdiagramme und/oder der Blockschemata angegebenen Funktionen/Vorgänge realisieren.
  • Die Flussdiagramme und Blockschemata in den Figuren veranschaulichen die Architektur, Funktionalität und Wirkungsweise möglicher Realisierungsformen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Flussdiagrammen bzw. in den Blockschemata eine Steuerungskomponente, ein Segment oder einen Abschnitt von Anweisungen darstellen, das bzw. der eine oder mehrere ausführbare Anweisungen zur Realisierung der angegebenen Logikfunktion bzw. Logikfunktionen aufweist. Bei einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben stattfinden. Beispielsweise können zwei hintereinander aufgeführte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können je nach der mit den Blöcken verbundenen Funktionalität manchmal in umgekehrter Reihenfolge ausgeführt werden. Darüber hinaus ist anzumerken, dass jeder Block der dargestellten Blockschemata und/oder Flussdiagramme sowie Kombinationen von Blöcken in den dargestellten Blockschemata und/oder Flussdiagrammen mit Hilfe zweckgebundener hardwaregestützter Systeme zum Ausführen der angegebenen Funktionen bzw. Aktionen oder mit Hilfe von Kombinationen aus zweckgebundener Hardware und zweckgebundenen Computeranweisungen realisiert werden kann bzw. können.
  • Obwohl Ausführungsformen der vorliegenden Erfindung zu Veranschaulichungszwecken beschrieben wurden, sind dem Fachmann viele Modifikationen und Änderungen klar. Dementsprechend sollen die beigefügten Ansprüche und alle derartigen Modifikationen und Änderungen als innerhalb den eigentlichen Ideengehalt und Schutzbereich dieser Erfindung fallend gelten.
  • 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 9691482 [0018]

Claims (25)

  1. Verfahren zum Prüfen der Berechtigung einer Zahlungskarte, wobei das Verfahren die Schritte aufweist: Lesen, durch einen Computer, von Informationen von der Zahlungskarte, die gegenwärtig für einen Kauf verwendet wird, wobei die Informationen eine Kennung der Zahlungskarte, Daten auf einem in der Zahlungskarte enthaltenen Chip, in Braille-Zellen auf der Zahlungskarte codierte Daten und Daten aufweisen, die in Markierungen codiert sind, die in der Zahlungskarte enthalten sind; Entschlüsseln, durch den Computer, der von der Zahlungskarte gelesenen Informationen unter Verwendung eines Entschlüsselungsschlüssels, der in den Daten enthalten ist, die in den Markierungen codiert sind,; als Reaktion auf eine Feststellung, dass der Entschlüsselungsschlüssel korrekt ist, und auf der Grundlage der entschlüsselten Informationen durch den Computer, Senden an ein Zahlungssystem (i) eines Hash-Werts, der von dem Chip gelesen wurde, der in der Zahlungskarte enthalten ist, (ii) der Kennung der Zahlungskarte, (iii) eines auf die Zahlungskarte gedruckten ersten Sicherheitscodes und (iv) eines zweiten Sicherheitscodes, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind; Empfangen, durch den Computer, vom Zahlungssystem eines Hash-Werts eines (n + 1)-ten Blocks eines Blockkettenhauptbuchs als Reaktion darauf, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert, (ii) die Kennung der Zahlungskarte validiert, (iii) den ersten Sicherheitscode validiert, (iv) den zweiten Sicherheitscode validiert, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind, und (v) den Hash-Wert des (n + 1)-ten Blocks erzeugt; Aufzeichnen, durch den Computer, des Hash-Werts des (n + 1)-ten Blocks in dem in der Zahlungskarte enthaltenen Chip als Aktualisierung des Hash-Werts, der vom Chip gelesen wurde; und Senden, durch den Computer, von Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks an das Zahlungssystem, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert, der bestätigt, dass der Hash-Wert des (n + 1)-ten Blocks im Chip aufgezeichnet ist, und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  2. Verfahren nach Anspruch 1, wobei die Markierungen ein eindeutiges Muster aus Quantenpunkten in einem Farbstoff auf mindestens einem Abschnitt der Zahlungskarte aufweisen und wobei der Schritt des Entschlüsselns der von der Zahlungskarte gelesenen Informationen ein auf dem Entschlüsselungsschlüssel beruhendes Entschlüsseln von Daten aufweist, die in dem eindeutigen Muster der Quantenpunkte codiert sind, wobei die entschlüsselten Daten, die in dem eindeutigen Muster der Quantenpunkte codiert sind, eine Person kennzeichnen, auf die die Zahlungskarte ausgestellt ist.
  3. Verfahren nach Anspruch 1, ferner aufweisend die Schritte: Lesen, durch den Computer, zweiter Informationen von einer betrügerischen Kopie, die gegenwärtig für einen zweiten Kauf verwendet wird, wobei die zweiten Informationen die Kennung der Zahlungskarte und Daten auf dem Chip aufweisen, der in der betrügerischen Kopie der Zahlungskarte enthalten ist; Entschlüsseln, durch den Computer, der von der Zahlungskarte gelesenen Informationen unter Verwendung eines zweiten Entschlüsselungsschlüssels, der in den zweiten Informationen enthalten ist,; Feststellen, durch den Computer, dass der zweite Entschlüsselungsschlüssel ein falscher Schlüssel ist; und Verweigern, durch den Computer, einer Transaktion zum Abschließen des zweiten Kaufs als Reaktion darauf, dass es sich bei dem zweiten Entschlüsselungsschlüssel um den falschen Schlüssel handelt,.
  4. Verfahren nach Anspruch 1, ferner aufweisend die Schritte: Lesen, durch den Computer, zweiter Informationen von einer betrügerischen Kopie, die gegenwärtig für einen zweiten Kauf verwendet wird, wobei die zweiten Informationen die Kennung der Zahlungskarte und Daten auf einem Chip aufweisen, der in der betrügerischen Kopie der Zahlungskarte enthalten ist; Senden, durch den Computer, eines Hash-Werts an ein Zahlungssystem, der von dem in der betrügerischen Kopie der Zahlungskarte enthaltenen Chip gelesen wurde; und Empfangen, durch den Computer, eines Hinweises vom Zahlungssystem, dass eine Transaktion zum Abschließen des zweiten Kaufs als Reaktion darauf verweigert wird, dass das Zahlungssystem (i) feststellt, dass Daten über einen jüngst zurückliegenden Kauf unter Verwendung der Zahlungskarte vor dem zweiten Kauf in einem m-ten Block des Blockkettenhauptbuchs gespeichert sind, und (ii) feststellt, dass der Hash-Wert, der von dem in der betrügerischen Kopie der Zahlungskarte enthaltenen Chip gelesen wurde, nicht mit einem Hash-Wert des m-ten Blocks des Blockkettenhauptbuchs übereinstimmt.
  5. Verfahren nach Anspruch 1, wobei der Schritt des Lesens der Informationen von der Zahlungskarte ein Lesen der in den Braille-Zellen codierten Daten und das Lesen der in den Markierungen codierten Daten ohne einen Abschnitt der in den Braille-Zellen codierten Daten und der in den Markierungen codierten Daten aufweist, die auf dem Chip oder auf einem Magnetstreifen der Zahlungskarte gespeichert sind.
  6. Verfahren nach Anspruch 1, wobei der Schritt des Empfangens des Hash Werts des (n + 1)-ten Blocks eines Blockkettenhauptbuchs vom Zahlungssystem ein Empfangen des Hash-Werts des (n +1)-ten Blocks als Verweis auf eine aktuelle Transaktion aufweist, die den Kauf aufweist, und wobei der Hash-Wert des n-ten Blocks des Blockkettenhauptbuchs auf eine Transaktion für einen weiteren Kauf unter Verwendung der Zahlungskarte verweist, bei der es sich um die jüngst zurückliegende Transaktion unter Verwendung der Zahlungskarte handelt, die vor der aktuellen Transaktion abgeschlossen wurde.
  7. Verfahren nach Anspruch 1, wobei der Schritt des Lesens der Informationen von der Zahlungskarte durch ein Kartenlesegerät durchgeführt wird, das so eingerichtet ist, dass die Daten auf dem Chip gelesen werden, und eine optische Komponente aufweist, die die Zahlungskarte abtastet und die in den Braille-Zellen codierten Daten und die in den Markierungen codierten Daten liest.
  8. Verfahren nach Anspruch 1, ferner aufweisend die Schritte: Ermitteln, durch den Computer, einer Art des Kaufs, wobei die Art ausgewählt ist aus der Gruppe, bestehend aus einem Kauf unter Verwendung eines Kartenlesegeräts an einer physischen Kasse und einem Kauf, der durch ein Online-Einkaufssystem ohne einen Kartenlesegeräts abgeschlossen wurde; Feststellen, durch den Computer, dass der n-te Block angibt, dass eine vorhergehende Transaktion unter Verwendung der Zahlungskarte einer Art entspricht, die mit der Art des Kaufs übereinstimmt; und Angeben, teilweise auf der Grundlage des n-ten Blocks, dass die vorhergehende Transaktion einer Art entspricht, die mit der Art des Kaufs übereinstimmt, wobei der Computer den n-ten Block als eine jüngst zurückliegende Transaktion durch die Zahlungskarte erkennt, die vor dem Kauf abgeschlossen wurde und derselben Art wie die Art des Kaufs entspricht.
  9. Verfahren nach Anspruch 1, ferner aufweisend den Schritt: Bereitstellen mindestens eine Unterstützungsdienstleistung für mindestens eines aus Erstellen, Integrieren, Hosten, Pflegen und Bereitstellen von durch einen Computer lesbarem Programmcode im Computer, wobei der Programmcode durch einen Prozessor des Computers ausgeführt wird, um die Schritte des Lesens der Informationen von der Zahlungskarte, des Entschlüsselns der von der Zahlungskarte gelesenen Informationen, des Sendens (i) des vom Chip gelesenen Hash-Werts, (ii) der Kennung der Zahlungskarte, (iii) des ersten Sicherheitscodes und (iv) des zweiten Sicherheitscodes, des Empfangens des Hash Werts des (n + 1)-ten Blocks, des Aufzeichnens des Hash Werts des (n + 1)-ten Blocks im Chip und des Sendens der Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks an das Zahlungssystem zu realisieren.
  10. Computerprogrammprodukt zum Prüfen der Berechtigung einer Zahlungskarte, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium aufweist, wobei auf dem durch einen Computer lesbaren Speichermedium Programmanweisungen gespeichert sind, wobei es sich bei dem durch einen Computer lesbaren Speichermedium um ein nicht flüchtiges Signal an sich handelt und die Programmanweisungen durch eine Zentraleinheit (CPU) eines Computersystems ausgeführt werden, um zu bewirken, dass das Computersystem ein Verfahren durchführt, das die Schritte aufweist: Lesen, durch das Computersystem, von Informationen von der Zahlungskarte, die gegenwärtig für einen Kauf verwendet wird, wobei die Informationen eine Kennung der Zahlungskarte, Daten auf einem in der Zahlungskarte enthaltenen Chip, in Braille-Zellen auf der Zahlungskarte codierte Daten und Daten aufweisen, die in Markierungen codiert sind, die in der Zahlungskarte enthalten sind; Entschlüsseln, durch das Computersystem, der von der Zahlungskarte gelesenen Informationen unter Verwendung eines Entschlüsselungsschlüssels, der in den Daten enthalten ist, die in den Markierungen codiert sind,; als Reaktion auf eine Feststellung, dass der Entschlüsselungsschlüssel korrekt ist, und auf der Grundlage der entschlüsselten Informationen durch das Computersystem Senden an ein Zahlungssystem (i) eines Hash-Werts, der von dem Chip gelesen wurde, der in der Zahlungskarte enthalten ist, (ii) der Kennung der Zahlungskarte, (iii) eines auf die Zahlungskarte gedruckten ersten Sicherheitscodes und (iv) eines zweiten Sicherheitscodes, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind; Empfangen, durch das Computersystem, vom Zahlungssystem eines Hash-Werts eines (n + 1)-ten Blocks eines Blockkettenhauptbuchs als Reaktion darauf, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert, (ii) die Kennung der Zahlungskarte validiert, (iii) den ersten Sicherheitscode validiert, (iv) den zweiten Sicherheitscode validiert, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind, und (v) den Hash-Wert des (n + 1)-ten Blocks erzeugt; Aufzeichnen, durch das Computersystem, des Hash-Werts des (n + 1)-ten Blocks in dem in der Zahlungskarte enthaltenen Chip als Aktualisierung des Hash-Werts, der vom Chip gelesen wurde; und Senden, durch das Computersystem, von Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks an das Zahlungssystem, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert, der bestätigt, dass der Hash-Wert des (n + 1)-ten Blocks im Chip aufgezeichnet ist, und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  11. Computerprogrammprodukt nach Anspruch 10, wobei die Markierungen ein eindeutiges Muster aus Quantenpunkten in einem Farbstoff auf mindestens einem Abschnitt der Zahlungskarte aufweisen und wobei der Schritt des Entschlüsselns der von der Zahlungskarte gelesenen Informationen ein auf dem Entschlüsselungsschlüssel beruhendes Entschlüsseln von Daten aufweist, die in dem eindeutigen Muster der Quantenpunkte codiert sind, wobei die entschlüsselten Daten, die in dem eindeutigen Muster der Quantenpunkte codiert sind, eine Person kennzeichnen, auf die die Zahlungskarte ausgestellt ist.
  12. Computerprogrammprodukt nach Anspruch 10, wobei das Verfahren ferner die Schritte aufweist: Lesen, durch das Computersystem, zweiter Informationen von einer betrügerischen Kopie, die gegenwärtig für einen zweiten Kauf verwendet wird, wobei die zweiten Informationen die Kennung der Zahlungskarte und Daten auf dem Chip aufweisen, der in der betrügerischen Kopie der Zahlungskarte enthalten ist; Entschlüsseln, durch das Computersystem, der von der Zahlungskarte gelesenen Informationen unter Verwendung eines zweiten Entschlüsselungsschlüssels, der in den zweiten Informationen enthalten ist,; Feststellen, durch das Computersystem, dass der zweite Entschlüsselungsschlüssel ein falscher Schlüssel ist; und Verweigern, durch das Computersystem, einer Transaktion zum Abschließen des zweiten Kaufs als Reaktion darauf, dass es sich bei dem zweiten Entschlüsselungsschlüssel um den falschen Schlüssel handelt,.
  13. Computerprogrammprodukt nach Anspruch 10, wobei das Verfahren ferner die Schritte aufweist: Lesen, durch das Computersystem, zweiter Informationen von einer betrügerischen Kopie, die gegenwärtig für einen zweiten Kauf verwendet wird, wobei die zweiten Informationen die Kennung der Zahlungskarte und Daten auf einem Chip aufweist, der in der betrügerischen Kopie der Zahlungskarte enthalten ist; Senden, durch das Computersystem, eines Hash-Werts an ein Zahlungssystem, der von dem in der betrügerischen Kopie der Zahlungskarte enthaltenen Chip gelesen wurde; und Empfangen, durch das Computersystem, eines Hinweises vom Zahlungssystem, dass eine Transaktion zum Abschließen des zweiten Kaufs als Reaktion darauf verweigert wird, dass das Zahlungssystem (i) feststellt, dass Daten über einen jüngst zurückliegenden Kauf unter Verwendung der Zahlungskarte vor dem zweiten Kauf in einem m-ten Block des Blockkettenhauptbuchs gespeichert sind, und (ii) feststellt, dass der Hash-Wert, der von dem in der betrügerischen Kopie der Zahlungskarte enthaltenen Chip gelesen wurde, nicht mit einem Hash-Wert des m-ten Blocks des Blockkettenhauptbuchs übereinstimmt.
  14. Computerprogrammprodukt nach Anspruch 10, wobei der Schritt des Lesens der Informationen von der Zahlungskarte ein Lesen der in den Braille-Zellen codierten Daten und ein Lesen der in den Markierungen codierten Daten ohne einen Abschnitt der in den Braille-Zellen codierten Daten und der in den Markierungen codierten Daten aufweist, die auf dem Chip oder auf einem Magnetstreifen der Zahlungskarte gespeichert sind.
  15. Computersystem, aufweisend: eine Zentraleinheit (CPU); einen mit der CPU verbundenen Hauptspeicher; und eine durch einen Computer lesbare Speichereinheit, die mit der CPU verbunden ist, wobei die durch einen Computer lesbare Speichereinheit Anweisungen enthält, die durch die CPU über den Hauptspeicher ausgeführt werden, um ein Verfahren zum Prüfen der Berechtigung einer Zahlungskarte zu realisieren, wobei das Verfahren die Schritte aufweist: Lesen, durch das Computersystem, von Informationen von der Zahlungskarte, die gegenwärtig für einen Kauf verwendet wird, wobei die Informationen eine Kennung der Zahlungskarte, Daten auf einem in der Zahlungskarte enthaltenen Chip, in Braille-Zellen auf der Zahlungskarte codierte Daten und Daten aufweisen, die in Markierungen codiert sind, die in der Zahlungskarte enthalten sind; Entschlüsseln, durch das Computersystem, der von der Zahlungskarte gelesenen Informationen unter Verwendung eines Entschlüsselungsschlüssels, der in den Daten enthalten ist, die in den Markierungen codiert sind,; als Reaktion auf eine Feststellung, dass der Entschlüsselungsschlüssel korrekt ist, und auf der Grundlage der entschlüsselten Informationen durch das Computersystem Senden an ein Zahlungssystem (i) eines Hash-Werts, der von dem Chip gelesen wurde, der in der Zahlungskarte enthalten ist, (ii) der Kennung der Zahlungskarte, (iii) eines auf die Zahlungskarte gedruckten ersten Sicherheitscodes und (iv) eines zweiten Sicherheitscodes, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind; Empfangen, durch das Computersystem, vom Zahlungssystem eines Hash-Werts eines (n + 1)-ten Blocks eines Blockkettenhauptbuchs als Reaktion darauf, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert, (ii) die Kennung der Zahlungskarte validiert, (iii) den ersten Sicherheitscode validiert, (iv) den zweiten Sicherheitscode validiert, der in den Daten enthalten ist, die in den Braille-Zellen codiert sind, und (v) den Hash-Wert des (n + 1)-ten Blocks erzeugt; Aufzeichnen, durch das Computersystem, des Hash-Werts des (n + 1)-ten Blocks in dem in der Zahlungskarte enthaltenen Chip als Aktualisierung des Hash-Werts, der vom Chip gelesen wurde; und Senden, durch das Computersystem, von Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks an das Zahlungssystem, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert, der bestätigt, dass der Hash-Wert des (n + 1)-ten Blocks im Chip aufgezeichnet ist, und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  16. Computersystem nach Anspruch 15, wobei die Markierungen ein eindeutiges Muster aus Quantenpunkten in einem Farbstoff auf mindestens einem Abschnitt der Zahlungskarte aufweisen und wobei der Schritt des Entschlüsselns der von der Zahlungskarte gelesenen Informationen ein auf dem Entschlüsselungsschlüssel beruhendes Entschlüsseln von Daten aufweist, die in dem eindeutigen Muster der Quantenpunkte codiert sind, wobei die entschlüsselten Daten, die in dem eindeutigen Muster der Quantenpunkte codiert sind, eine Person kennzeichnen, auf die die Zahlungskarte ausgestellt ist.
  17. Computersystem nach Anspruch 15, wobei das Verfahren ferner die Schritte aufweist: Lesen, durch das Computersystem, zweiter Informationen von einer betrügerischen Kopie, die gegenwärtig für einen zweiten Kauf verwendet wird, wobei die zweiten Informationen die Kennung der Zahlungskarte und Daten auf dem Chip aufweisen, der in der betrügerischen Kopie der Zahlungskarte enthalten ist; Entschlüsseln, durch das Computersystem, der von der Zahlungskarte gelesenen Informationen unter Verwendung eines zweiten Entschlüsselungsschlüssels, der in den zweiten Informationen enthalten ist,; Feststellen, durch das Computersystem, dass der zweite Entschlüsselungsschlüssel ein falscher Schlüssel ist; und Verweigern, durch das Computersystem, einer Transaktion zum Abschließen des zweiten Kaufs als Reaktion darauf, dass es sich bei dem zweiten Entschlüsselungsschlüssel um den falschen Schlüssel handelt,.
  18. Computersystem nach Anspruch 15, wobei das Verfahren ferner die Schritte aufweist: Lesen, durch das Computersystem, zweiter Informationen von einer betrügerischen Kopie, die gegenwärtig für einen zweiten Kauf verwendet wird, wobei die zweiten Informationen die Kennung der Zahlungskarte und Daten auf einem Chip aufweisen, der in der betrügerischen Kopie der Zahlungskarte enthalten ist; Senden, durch das Computersystem, eines Hash-Werts an ein Zahlungssystem, der von dem in der betrügerischen Kopie der Zahlungskarte enthaltenen Chip gelesen wurde; und Empfangen, durch das Computersystem, eines Hinweises vom Zahlungssystem, dass eine Transaktion zum Abschließen des zweiten Kaufs als Reaktion darauf verweigert wird, dass das Zahlungssystem (i) feststellt, dass Daten über einen jüngst zurückliegenden Kauf unter Verwendung der Zahlungskarte vor dem zweiten Kauf in einem m-ten Block des Blockkettenhauptbuchs gespeichert sind, und (ii) feststellt, dass der Hash-Wert, der von dem in der betrügerischen Kopie der Zahlungskarte enthaltenen Chip gelesen wurde, nicht mit einem Hash-Wert des m-ten Blocks des Blockkettenhauptbuchs übereinstimmt.
  19. Computersystem nach Anspruch 15, wobei der Schritt des Lesens der Informationen von der Zahlungskarte ein Lesen der in den Braille-Zellen codierten Daten und ein Lesen der in den Markierungen codierten Daten ohne einen Abschnitt der in den Braille-Zellen codierten Daten und der in den Markierungen codierten Daten aufweist, die auf dem Chip oder auf einem Magnetstreifen der Zahlungskarte gespeichert sind.
  20. Verfahren zum Prüfen der Berechtigung einer Zahlungskarte, wobei das Verfahren die Schritte aufweist: Empfangen, durch einen Computer, von Informationen von der Zahlungskarte, die gegenwärtig durch einen Benutzer für einen Kauf verwendet wird, und ein Senden der Informationen an ein Zahlungssystem, wobei die Informationen eine Kennung der Zahlungskarte, einen auf die Zahlungskarte gedruckten ersten Sicherheitscode, einen in Braille-Zellen auf der Zahlungskarte codierten zweiten Sicherheitscode und ein Ablaufdatum der Zahlungskarte aufweisen; Empfangen, durch den Computer, eines Hash-Werts über einen Eintrag in einem Web-Formular und ein Senden des empfangenen Hash-Werts an ein Zahlungssystem, wobei es sich bei dem Eintrag um eine Kopie des Hash-Werts eines n-ten Blocks eines Blockkettenhauptbuchs handelt, der durch das Zahlungssystem an eine mobile Einheit des Benutzers als Reaktion darauf gesendet wird, dass das Zahlungssystem (i) die Kennung der Zahlungskarte validiert, (ii) den ersten Sicherheitscode validiert, (iii) den in den Braille-Zellen codierten zweiten Sicherheitscode validiert und (iv) den Hash Wert des n-ten Blocks aus dem Blockkettenhauptbuch abruft, indem festgestellt wird, dass der n-te zur Kennung der Zahlungskarte gehörig ist; Empfangen, durch den Computer, vom Zahlungssystem eines Hash-Werts eines (n + 1)-ten Blocks des Blockkettenhauptbuchs als Reaktion darauf, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert und (ii) den Hash-Wert des (n + 1)-ten Blocks erzeugt; und Senden, durch den Computer, von Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks an das Zahlungssystem, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  21. Verfahren nach Anspruch 20, wobei der Schritt des Sendens der Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks als Reaktion darauf durchgeführt wird, dass das Zahlungssystem den Hash-Wert des (n + 1)-ten Blocks an die mobile Einheit sendet und die mobile Einheit den Hash-Wert des (n + 1)-ten Blocks aufzeichnet.
  22. Verfahren nach Anspruch 20, wobei der Schritt des Empfangens der Informationen von der Zahlungskarte durch ein Online-Einkaufsystem durchgeführt wird.
  23. Computerprogrammprodukt zum Prüfen der Berechtigung einer Zahlungskarte, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium aufweist, wobei auf dem durch einen Computer lesbaren Speichermedium Programmanweisungen gespeichert sind, wobei es sich bei dem durch einen Computer lesbaren Speichermedium um ein nicht flüchtiges Signal an sich handelt und die Programmanweisungen durch eine Zentraleinheit (CPU) eines Computersystems ausgeführt werden, um zu bewirken, dass das Computersystem ein Verfahren durchführt, das die Schritte aufweist: Empfangen, durch ein Computersystem, von Informationen von der Zahlungskarte, die gegenwärtig durch einen Benutzer für einen Kauf verwendet wird, und ein Senden der Informationen an ein Zahlungssystem, wobei die Informationen eine Kennung der Zahlungskarte, einen auf die Zahlungskarte gedruckten ersten Sicherheitscode, einen in Braille-Zellen auf der Zahlungskarte codierten zweiten Sicherheitscode und ein Ablaufdatum der Zahlungskarte aufweisen; Empfangen, durch das Computersystem, eines Hash-Werts über einen Eintrag in einem Web-Formular und ein Senden des empfangenen Hash-Werts an ein Zahlungssystem, wobei es sich bei dem Eintrag um eine Kopie des Hash-Werts eines n-ten Blocks eines Blockkettenhauptbuchs handelt, der durch das Zahlungssystem an eine mobile Einheit des Benutzers als Reaktion darauf gesendet wird, dass das Zahlungssystem (i) die Kennung der Zahlungskarte validiert, (ii) den ersten Sicherheitscode validiert, (iii) den in den Braille-Zellen codierten zweiten Sicherheitscode validiert und (iv) den Hash Wert des n-ten Blocks aus dem Blockkettenhauptbuch abruft, indem festgestellt wird, dass der n-te zur Kennung der Zahlungskarte gehörig ist; Empfangen, durch das Computersystem, vom Zahlungssystem eines Hash-Werts eines (n + 1)-ten Blocks des Blockkettenhauptbuchs als Reaktion darauf, dass das Zahlungssystem (i) den an das Zahlungssystem gesendeten Hash-Wert als übereinstimmend mit einem Hash-Wert eines n-ten Blocks des Blockkettenhauptbuchs validiert und (ii) den Hash-Wert des (n + 1)-ten Blocks erzeugt; und Senden, durch das Computersystem, von Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks an das Zahlungssystem, der bewirkt, dass das Zahlungssystem (i) den Hash-Wert des (n + 1)-ten Blocks validiert und (ii) die Daten über den Kauf als Transaktion zum (n + 1)-ten Block hinzufügt.
  24. Computerprogrammprodukt nach Anspruch 23, wobei der Schritt des Sendens der Daten über den Kauf und des Hash-Werts des (n + 1)-ten Blocks als Reaktion darauf durchgeführt wird, dass das Zahlungssystem den Hash-Wert des (n + 1)-ten Blocks an die mobile Einheit sendet und die mobile Einheit den Hash-Wert des (n + 1)-ten Blocks aufzeichnet.
  25. Computerprogrammprodukt nach Anspruch 23, wobei der Schritt des Empfangens der Informationen von der Zahlungskarte durch ein Online-Einkaufsystem durchgeführt wird.
DE112018006031.4T 2017-11-27 2018-11-16 Authentifizieren einer zahlungskarte Active DE112018006031B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/822,564 2017-11-27
US15/822,564 US10990982B2 (en) 2017-11-27 2017-11-27 Authenticating a payment card
PCT/IB2018/059029 WO2019102322A1 (en) 2017-11-27 2018-11-16 Authenticating a payment card

Publications (2)

Publication Number Publication Date
DE112018006031T5 true DE112018006031T5 (de) 2020-09-17
DE112018006031B4 DE112018006031B4 (de) 2023-05-04

Family

ID=66631830

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112018006031.4T Active DE112018006031B4 (de) 2017-11-27 2018-11-16 Authentifizieren einer zahlungskarte

Country Status (6)

Country Link
US (1) US10990982B2 (de)
JP (1) JP7267278B2 (de)
CN (1) CN111386690B (de)
DE (1) DE112018006031B4 (de)
GB (1) GB2581935B (de)
WO (1) WO2019102322A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11153069B2 (en) * 2018-02-27 2021-10-19 Bank Of America Corporation Data authentication using a blockchain approach
US20210080393A1 (en) * 2019-09-17 2021-03-18 Quantum Materials Corp. Using Quantum Dots for Identification, Authentication, and Tracking of Objects
US11230136B1 (en) 2021-05-10 2022-01-25 Nu Pagamentos S.A. Container for payment cards with hidden features

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6196459B1 (en) 1998-05-11 2001-03-06 Ubiq Incorporated Smart card personalization in a multistation environment
US7024395B1 (en) 2000-06-16 2006-04-04 Storage Technology Corporation Method and system for secure credit card transactions
US20040177045A1 (en) * 2001-04-17 2004-09-09 Brown Kerry Dennis Three-legacy mode payment card with parametric authentication and data input elements
JP2007095020A (ja) 2005-09-27 2007-04-12 Hiroshi Funai カード、及び該カードを使った店頭ショッピングの取引確認及び決済処理方法、及び該カードを使ったオンラインショッピングの取引確認及び決済処理方法、及びオンラインショッピングにおける取引処理装置、及びそのプログラム並びに記録媒体。
US7778935B2 (en) 2006-03-09 2010-08-17 Colella Brian A System for secure payment and authentication
US8365986B2 (en) 2006-03-14 2013-02-05 Perry Securities Llc Credit card security system and method
USD578159S1 (en) 2008-02-13 2008-10-07 Visa U.S.A. Inc. Braille financial transaction card
US7793834B2 (en) 2008-02-13 2010-09-14 Visa U.S.A. Inc. Financial transaction card with non-embossed, raised indicia
US9215331B2 (en) 2008-10-02 2015-12-15 International Business Machines Corporation Dual layer authentication for electronic payment request in online transactions
GB2476987B (en) 2010-01-19 2013-11-27 Haim Cohen Transaction card with improved security features
GB201209232D0 (en) 2012-05-25 2012-07-04 Secure Electrans Ltd Card payment unit and method
CN105103525A (zh) 2013-01-29 2015-11-25 玛丽·格蕾丝 具有增强的安全特性的智能卡和智能卡系统
US9552578B2 (en) * 2015-02-25 2017-01-24 Mastercard International Incorporated Method and system for authentication of payment card transactions
JP2018508907A (ja) 2015-03-04 2018-03-29 トゥルソナ，インコーポレイテッド ペイメントカード認証読取りデータを使用したユーザー識別のためのシステムおよび方法
KR101680540B1 (ko) * 2015-06-18 2016-11-30 주식회사 코인플러그 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
US9460328B1 (en) 2016-01-15 2016-10-04 International Business Machines Corporation Extracting information from surface coatings
CN105931052A (zh) * 2016-04-21 2016-09-07 四川大学 一种基于区块链多因子交叉验证的虚拟货币交易验证方法
KR101780636B1 (ko) * 2016-05-16 2017-09-21 주식회사 코인플러그 인증 정보의 발급 방법 및 이를 지원하는 블록체인기반 인증 정보 관리 서버
CN106097073A (zh) 2016-06-20 2016-11-09 深圳市淘淘谷信息技术有限公司 一种用区块链来赋予数字账户交易过程独有id的方法
CN106503981A (zh) * 2016-10-19 2017-03-15 江苏通付盾科技有限公司 简单支付验证节点交易查询方法及系统
US9691482B1 (en) 2016-10-31 2017-06-27 International Business Machines Corporation Optical storage device utilizing quantum silos
CN107077674B (zh) * 2016-12-29 2021-06-11 达闼机器人有限公司 交易验证处理方法、装置及节点设备
CN107070660B (zh) 2017-03-03 2020-03-17 上海唯链信息科技有限公司 一种区块链加密射频芯片的存储设计方法
CN107257336A (zh) 2017-06-15 2017-10-17 北京汇通金财信息科技有限公司 一种用户认证方法及系统
CN107257340B (zh) 2017-06-19 2019-10-01 阿里巴巴集团控股有限公司 一种认证方法、基于区块链的认证数据处理方法及设备

Also Published As

Publication number Publication date
CN111386690B (zh) 2022-08-05
JP2021505049A (ja) 2021-02-15
CN111386690A (zh) 2020-07-07
GB2581935A (en) 2020-09-02
WO2019102322A1 (en) 2019-05-31
US20190164160A1 (en) 2019-05-30
JP7267278B2 (ja) 2023-05-01
DE112018006031B4 (de) 2023-05-04
GB202008473D0 (en) 2020-07-22
GB2581935B (en) 2021-02-03
US10990982B2 (en) 2021-04-27

Similar Documents

Publication Publication Date Title
KR102052036B1 (ko) 블록체인에 분산저장된 데이터의 탐색 및 조합을 통한 데이터 획득방법
EP2533172B2 (de) Gesicherter Zugriff auf Daten in einem Gerät
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
DE102016100494A1 (de) Sichere Identitätsauthentifizierung in einer elektronischen Transaktion
DE112018006031B4 (de) Authentifizieren einer zahlungskarte
WO2014114476A1 (de) Verfahren zur authentisierung eines nutzers gegenüber einem automat
EP3699791B1 (de) Zugangskontrolle mit einem mobilfunkgerät
DE602004003566T2 (de) Verfahren und Vorrichtung zur Identifizierung einer authorisierten Person mittels nicht vorhersagbaren einmal benutzbaren Passwörtern
DE102019002731A1 (de) Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
DE102011116489A1 (de) Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
DE102020104906A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE112017000633T5 (de) Sichere archivierung und wiederherstellung von multifaktor-authentifizierungsschablonen
DE102018005038A1 (de) Smartcard als Sicherheitstoken
EP1964042B1 (de) Verfahren zur vorbereitung einer chipkarte für elektronische signaturdienste
EP2512090B1 (de) Verfahren zur authentifizierung eines teilnehmers
DE112019003528T5 (de) Verfahren zum Einrichten einer anonymen digitalen Identität
DE102011119103A1 (de) Verfahren zum Authentisieren einer Person an einer Serverinstanz
DE102007023003A1 (de) Verfahren zum mobilen Bezahlen sowie Computerprogrammprodukt
KR20210017308A (ko) 디바이스 등록 및 데이터 분산저장을 이용하는 2차인증 서비스 제공방법
EP3219133A1 (de) Authentifizierungsverfahren, authentifizierungssystem und authentifizierungsvorrichtungen zum authentifizieren eines objektes
EP3358488B1 (de) Verfahren zum erkennen von unberechtigten kopien digitaler sicherheits-token
AT411947B (de) System für die sichere durchführung von transaktionen zwischen informationsverarbeitenden anlagen
EP3312753B1 (de) Physisches sicherheitselement zum zurücksetzen eines passworts
KR20210017968A (ko) 블록체인에 분산저장된 데이터의 탐색 및 조합을 통한 데이터 획득방법
EP4179489A1 (de) Verfahren, endgerät sowie münzregister zum übertragen von elektronischen münzdatensätzen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: G06F0021000000

R082 Change of representative

Representative=s name: RICHARDT PATENTANWAELTE PARTG MBB, DE

R081 Change of applicant/patentee

Owner name: KYNDRYL, INC., NEW YORK, US

Free format text: FORMER OWNER: INTERNATIONAL BUSINESS MACHINES CORPORATION, ARMONK, NY, US

R016 Response to examination communication
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021000000

Ipc: G06F0021440000

R018 Grant decision by examination section/examining division
R020 Patent grant now final