-
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).
-
Die Druckschrift
JP 2007 - 95 020 A betrifft eine Karte zur Verhinderung von betrügerischer Abhebung und betrügerischer Verwendung durch eine gestohlene oder gefälschte Karte und ein System zur Verhinderung betrügerischer Transaktionen. Im Gegensatz zu einer herkömmlichen Karte ist auf der Karte kein Name abgebildet, sie speichert einen aus einer Vielzahl von Punkten oder Linien strukturierten Identifikationscode, der von einem Computer gelesen werden kann, und sie speichert außerdem die Benutzungsnummer der Karte und kann die betrügerische Verwendung durch eine gefälschte Karte verhindern. Selbst wenn die Karte verloren geht oder gestohlen wird, ist es sehr schwierig, den Namen von der Karte ohne den Namen zu erraten, und die Benutzungsnummer der Karte wird in einem Host-Computer zur Verarbeitung der Karte gespeichert. Daher entspricht die Verwendung der gefälschten Karte nicht der Benutzungsnummer einer echten Karte, und die betrügerische Verwendung kann aufgedeckt werden.
-
Die Druckschrift
US 2009 / 0 200 385 A1 betrifft eine Finanztransaktionskarte, die eine erste Hauptfläche auf einer Seite und eine zweite Hauptfläche auf einer gegenüberliegenden Seite aufweist. Ein erster Satz erhabener Zeichen ragt von der ersten Hauptfläche nach außen. Ein zweiter Satz erhabener Zeichen ragt von der zweiten Hauptfläche nach au-ßen und befindet sich direkt kontralateral zum ersten Satz erhabener Zeichen. Die zweite Hauptoberfläche enthält keine Hinweise auf die erste Gruppe von erhabenen Zeichen und die erste Hauptoberfläche enthält keine Hinweise auf die zweite Gruppe von erhabenen Zeichen. Jedes Zeichen steht für einen Buchstaben oder eine Zahl und ist in einer Ausführungsform ein Braille-Zeichen.
-
Die Druckschrift
US 2017 / 0 206 443 A1 betrifft ein Verfahren und ein System zum Extrahieren von Informationen von einer Oberfläche, die mit einer Beschichtung beschichtet ist, die Quantenpunkte enthält. Das Verfahren umfasst: Aufladen der Quantenpunkte in der Oberflächenbeschichtung; Abtasten der Oberfläche, um Informationen von den Quantenpunkten abzurufen; und Verarbeiten der abgerufenen Informationen, um in den Quantenpunkten kodierte Daten zu identifizieren. Das Verarbeiten umfasst ein Filtern der abgerufenen Informationen, um die empfangenen Informationen auf der Grundlage definierter Effekte der Beschichtung anzupassen. Das Filtern umfasst ein Filtern der abgerufenen Informationen, um die chromatische Abweichung aufgrund der Farbe der beschichteten Oberfläche zu berücksichtigen. Die Quantenpunkte umfassen eine Vielzahl verschiedener Arten von Quantenpunkten. Das Verarbeiten der abgerufenen Informationen umfasst ein Verarbeiten der abgerufenen Informationen, um zwischen den Informationen zu unterscheiden, die von den verschiedenen Arten von Quantenpunkten abgerufen werden.
-
KURZDARSTELLUNG
-
Die Erfindung betrifft ein Verfahren und ein Computerprogrammprodukt zum Prüfen der Berechtigung einer Zahlungskarte sowie ein System, deren Merkmale in den unabhängigen Ansprüchen angegeben sind. Die Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen angegeben.
-
Ein Verfahren zum Prüfen der Berechtigung einer Zahlungskarte 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.
-
Das oben erwähnte Verfahren 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 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 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 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.
-
Ein Computerprogrammprodukt zum Prüfen der Berechtigung einer Zahlungskarte 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.
-
Ein Computersystem beinhaltet eine Zentraleinheit (CPU), 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 zum Bereitstellen eines Schlüssels zum Decodieren von Informationen, 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 unberechtigte 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 691 482 , 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.