DE69011877T2 - Transaktionszustimmungssystem. - Google Patents
Transaktionszustimmungssystem.Info
- Publication number
- DE69011877T2 DE69011877T2 DE69011877T DE69011877T DE69011877T2 DE 69011877 T2 DE69011877 T2 DE 69011877T2 DE 69011877 T DE69011877 T DE 69011877T DE 69011877 T DE69011877 T DE 69011877T DE 69011877 T2 DE69011877 T2 DE 69011877T2
- Authority
- DE
- Germany
- Prior art keywords
- transaction
- card
- indicator
- block
- errors
- 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.)
- Expired - Lifetime
Links
Classifications
-
- 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
-
- 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/403—Solvency checks
Landscapes
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Radar Systems Or Details Thereof (AREA)
- Image Processing (AREA)
- Cash Registers Or Receiving Machines (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Description
- Der Erfindungsgegenstand betrifft ein Finanztransaktionsnetz. Die Erfindung schließt ein verbessertes System zur Verteilung von Information über ungültige Transaktionskarten ein.
- Im Verlauf der letzten fünfzehn Jahren hat der Gebrauch von Transaktionskarten anstelle von Bargeld stark zugenommen. Dieser zunehmende Gebrauch hat einen Anstieg der Verluste aufgrund von Betrug mit sich gebracht. Eines der kostspieligsten Probleme ist die Verwendung ungültiger Karten. Der Begriff der ungültigen Karte umfaßt verlorene oder gestohlene Karten. Der Begriff schließt ebenfalls jene Karten ein, deren Kreditrahmen vom Inhaber überschritten wurde. Wichtige Arbeit wurde geleistet, um den Gebrauch und den Mißbrauch von ungültigen Karten auf ein Mindestmaß zu reduzieren.
- Eines der ersten Konzepte zur Bekämpfung dieser Art von Betrug war die Verbreitung einer Liste, in welcher die ungültigen Karten abgedruckt werden. Eine dieser Listen trägt den Namen Card Recovery Bulletin [Mitteilungsblatt zur Wiedererlangung von Karten] oder CRB. In der Praxis vergleicht der Verkäufer die Kontonummer auf der Karte, die für die Transaktion vorgelegt wurde, mit den Kontonummern, die im CP-Bulletin abgedruckt sind. Befindet sich die Kontonummer in der Liste, wird die Transaktion abgelehnt.
- Durch diesen Einsatz des CRB lassen sich die Verluste durch Betrug bedeutend verringern. Dieses Konzept weist jedoch einige Nachteile auf. Beispielsweise werden Transaktionskarten häufig fast unmittelbar nachdem sie verloren gingen oder gestohlen wurden verwendet. Dieser unmittelbare Gebrauch findet statt, bevor die Karte in das Bulletin aufgenommen oder das Bulletin verbreitet werden kann. Des weiteren liegt ein zusätzliches Problem dieses Konzepts darin, daß es mitunter nicht einfach ist sicherzustellen, daß die Angestellten die Liste ordnungsgemäß oder überhaupt einsetzen.
- Aufgrund dieser Schwierigkeiten wurden viele weitere, technisch ausgereiftere Konzepte entwickelt. Eines der wirkungsvollsten Systeme sieht vor, jede Transaktion durch ein in Echtzeit arbeitendes Online-Nachrichtennetz zuzulassen. Beispielsweise kann der Verkäufer die Kontonummer der für eine Transaktion vorgelegten Karte telephonisch einer zentralen Verarbeitungseinheit melden. Die Kontonummer auf der Karte kann daraufhin mit einer aktuellen Liste der ungültigen Kartennummern verglichen werden, die entweder in der zentralen Verarbeitungseinheit oder beim Aussteller der Karte gespeichert ist. Bei einer Variation dieses Systems kann ein Transaktionsterminal mit einer Kartenlesevorrichtung ausgestattet sein, welche einen Magnetstreifen liest, auf dem eine Kontonummer codiert ist. Der Terminal kann daraufhin die Kontonummer der zentralen Verarbeitungseinheit zur Zulassung übermitteln.
- Dieses Online-System beseitigt die Zeitdifferenz, die bei der Verwendung des Card Recovery Bulletins auftritt. Leider erweist sich ein System, welches gänzlich online arbeitet, als untragbar teuer und als anfällig für Übertragungsverzögerungen. Ein Online-Konzept stellt ebenfalls keinen Schutz dar, wenn das Netz ausfällt.
- In der jüngeren Vergangenheit wurden zahlreiche Konzepte zur Kostensenkung hinsichtlich der Zulassung von Transaktionen bei gleichzeitiger Eindämmung der Verluste durch Betrug ausgearbeitet. Mit der Entwicklung immer kleinerer, preiswerterer und schnellerer Mikroprozessoren können einige der für die Transaktion relevanten Überprüfungen am Terminal selbst vorgenommen werden. Die Entwicklung von Überprüfungsverfahren wurde angestrebt, bei denen die Übertragung der Transaktionsinformationen zur zentralen Verarbeitungseinheit entfällt. Beispielsweise kann der Transaktionsterminal so programmiert werden, daß er jedwede Transaktion zuläßt, die unterhalb einer bestimmten Dollar- oder Mindestgrenze erfolgt. Auf diese Weise lassen sich die Übertragungskosten und das Verlustrisiko abwägen.
- Der Terminal kann ebenfalls mit der Fähigkeit ausgestattet sein, die persönliche Geheimnummer (PIN, personal identification number) des Karteninhabers zu überprüfen. In diesem Fall ist eine Version der persönlichen Geheimnummer auf dem Magnetstreifen der Karte codiert und wird vom Terminal gelesen. Der Terminal vergleicht daraufhin die auf der Karte gelesene persönliche Geheimnummer mit einer persönlichen Geheimnummer, die der Karteninhaber an der Tastatur des Terminals eingibt. Stimmen die beiden Geheimnummern überein, wird die Transaktion zugelassen. Der Einsatz von persönlichen Geheimnummern verringert den betrügerischen Gebrauch verlorener oder gestohlener Karten beträchtlich.
- Ein weiterentwickeltes Konzept wird in der am 29. März 1988 erteilten U.S.-Patentschrift Nr. 4,734,564 beschrieben, welche demselben Übertragungsempfänger übertragen wurde wie der Erfindungsgegenstand und welche hier durch Bezugnahme aufgenommen ist. In dieser Patentanmeldung wird ein System beschrieben, worin Daten zur Beurteilung des Risikos vom Kartenaussteller auf der Karte codiert werden. Diese Daten zur Risikobeurteilung werden der Kreditwürdigkeit jedes einzelnen Karteninhabers angepaßt. Die Daten zur Risikobeurteilung können vom Transaktionsterminal geprüft werden, und wenn der Transaktionsbetrag sich innerhalb der Parameter befindet, die der Aussteller auf der Karte codiert hat, kann die Transaktion automatisch zugelassen werden. Übersteigt der Transaktionsbetrag diese Parameter, werden die Transaktionsdaten an die zentrale Verarbeitungseinheit geleitet, wo sie weiter überprüft werden.
- Mit dem Kostenrückgang für Speicherraum bei Computern wurde die Möglichkeit geprüft, die Kontonummern ungültiger Karten in jedem Transaktionsterminal zu speichern. Wird dieses System implementiert, kann die Kontonummer der für die Transaktion vorgelegten Karte am Terminal automatisch verglichen werden. Ein dem Stand der Technik entsprechendes System, welches dieses Konzept verwendet, wird in der U.S.-Patentschrift Nr. 3,696,335 beschrieben, welches am 3. Oktober 1972 an Lemelson erteilt wurde.
- Das in der Patentschrift von Lemelson erläuterte Konzept wurde wegen einer Reihe von Gründen für unzweckmäßig erachtet. Insbesondere muß die Liste regelmäßig an die Terminals ausgegeben und aktualisiert werden, um sie auf dem aktuellen Stand zu halten. Mit der rasch zunehmenden Verbreitung von Transaktionsterminals, ist es tatsächlich völlig unmöglich, diese Daten regelmäßig physikalisch an die Terminals zu übermitteln. Aus diesem Grund muß die Verteilung der Liste der ungültigen Kontonummern durch eine Art der Nachrichtenverbindung erfolgen. Leider sind bei den wichtigsten Transaktionskartensystemen die Listen der ungültigen Karten so lang, daß sich die Online-Verteilung recht schwierig gestaltet. Wird jedoch eine Möglichkeit gefunden, die Liste auf wirkungsvolle Art und Weise zu verteilen, wäre dieses Konzept hinsichtlich der Verringerung sowohl der Übertragungskosten als auch der Verluste durch Betrug wirkungsvoll.
- In der U.S.-Patentschrift Nr. 4,558,211, die am 10. Dezember 1985 an Berstein erteilt wurde, wird ein Verfahren beschrieben, mit dessen Hilfe dieses Ziel erreicht wird. Diese Offenbarung geht davon aus, daß eine vollständige Liste der ungültigen Karten, der sogenannten "hot cards", zu umfassend ist, um sie jedem Transaktionsterminal zu übermitteln. Die in der letztgenannten Patentschrift vorgeschlagene Lösung sieht vor, jeder aufgelisteten hot card eine Identifizierung hinzuzufügen, welche den geographischen Bereich kennzeichnet, in dem die Karte höchstwahrscheinlich benutzt wird. Nun können Teilmengen der Liste der hot cards erstellt werden, die auf die einzelnen geographischen Bereiche abgestimmt sind. Die bedeutend kürzeren Listen können daraufhin an die Terminals verteilt und gespeichert werden. Die Patentschrift sieht vor, daß ein 4-KB-Standardspeicher eines Terminals eine Liste von 800 ungültigen Karten speichern kann. Da die meisten ungültigen Karten in der Gegend verwendet werden, in der sie verloren gingen oder gestohlen wurden, kann dieses Konzept sehr wirkungsvoll sein, solange nicht mehr als 800 ungültige Karten im jeweiligen geographischen Bereich existieren.
- Leider werden an jedem beliebigen Tag allein in den Vereinigten Staaten normalerweise mehr als eine Million ungültige Karten in den Listen der wichtigsten Gesellschaften für Transaktionskarten geführt. Selbst wenn diese Listen nach den geographischen Gebieten aufgeteilt werden, umfaßt die kürzeste Liste nicht viel weniger als 100.000 Karten. Es ist offensichtlich, daß die Wirksamkeit des Systems abnimmt, wenn der geographische Bereich zu klein gefaßt wird, da es somit darauf beschränkt wird, einen unbefugten Benutzer an genau dem Ort zu erwischen, an dem die Karte verloren ging oder gestohlen wurde.
- Die Patentschrift EP-A-0274191 offenbart ein Verfahren zur Erzeugung und Verteilung einer Haupttabelle, welche Informationen über ungültige Karten enthält. Ein einzigartiges Verfahren der Datenkomprimierung wird verwendet, um den für das Speichern der Haupttabelle erforderlichen Speicherplatz deutlich zu verringern. Durch die Verringerung der Größe der Datei wird das Abziehen der Information auf örtliche Transaktionsterminals bedeutend erleichtert.
- Die in der Haupttabelle enthaltenen Daten sind geringer als die eigentlichen Kontonummern der ungültigen Karten. Die Daten sind jedoch so angeordnet, daß bei einer ungültigen Karte, die einem Transaktionsterminal vorgelegt wird, die Notwendigkeit einer weiteren Überprüfung vor der Erteilung der Zulassung erkannt wird. Wird erkannt, daß eine Karte überprüft werden muß, werden die Abrechnungsdaten einer zentralen Verarbeitungseinheit übermittelt, welche sie vor der endgültigen Zulassung mit einer vollständigen Liste der ungültigen Karten vergleicht. Wird eine Kontonummer jedoch mit der Haupttabelle des Transaktionsterminals verglichen und freigegeben, kann die Transaktion risikofrei offline zugelassen werden, da dieses Ergebnis sicherstellt, daß die Kontonummer nicht in der Liste der ungültigen Karten geführt wird.
- Aufgrund der typischen Eigenschaften von Systemen zur Datenkomprimierung wird ein Teil der vorgelegten, gültigen Karten als potentiell ungültig eingestuft. In diesen Fällen werden die Transaktionsdaten an die zentrale Verarbeitungseinheit geleiet, um dies genau zu überprüfen. Die Wahrscheinlichkeit, mit der eine Karte als potentiell ungültig eingestuft wird, ist regelbar, indem die Merkmale der Haupttabelle verändert werden. Die Wahrscheinlichkeit, daß eine gültige Karte als potentiell ungültig eingestuft wird, soll bei weniger als zehn Prozent liegen, vorzugsweise jedoch im Bereich von ein bis drei Prozent. Da viele Transaktionen aus anderen Gründen an die zentrale Verarbeitungseinheit übertragen werden (d.h. Transaktionen mit hohen Dollarbeträgen, welche die Mindestgrenze des Terminals überschreiten), wirkt sich die Tatsache, daß in diesem System ein geringer Prozentsatz an Transaktionen an die zentrale Verarbeitungseinheit übermittelt wird, nur unbedeutend auf die Leistungsfähigkeit des Systems insgesamt aus.
- Die Haupttabelle wird durch mehrere Bitmuster festgelegt. Wie nachfolgend im einzelnen erläutert wird, kann die Wahrscheinlichkeit verringert werden, daß eine gültige Karte als potentiell ungültig eingestuft wird, indem in einer Haupttabelle mehrere Bitmuster anstelle von nur einem einzelnen Bitmuster verwendet werden. Umgekehrt erhöht sich mit der zunehmenden Anzahl an Bitmustern auch die Verarbeitungszeit.
- Jedes der Bitmuster der Tabelle weist eine Länge von B Bit auf. Daten über die ungültigen Karten werden durch Anzeigezeichen im Bitmuster dargestellt. Um die Anzeigezeichen zu plazieren, wird die Kontonummer der ungültigen Karte einer algorithmischen Funktion unterworfen, so daß ein Sollwert zwischen Null und der Bitanzahl des Bitmusters erzeugt wird. Wurde dieser Wert erzielt, wird ein Anzeigezeichen in der Stelle im Bitmuster angeordnet, die dem erzeugten Sollwert entspricht. In einer Ausführung, in welcher fünf Bitmuster verwendet werden, wird die Kontonummer fünf verschiedenen algorithmischen Verfahren unterzogen, um fünf unterschiedliche Sollwerte zu erzielen, wobei jeder von ihnen verwendet wird, um ein Anzeigezeichen in einem der fünf Bitmuster anzuordnen.
- Der zur Erzeugung eines Sollwerts verwendete Algorithmus kann relativ kompliziert sein, wie beispielsweise der DES (data encryption standard; kryptographischer Standard). Zur Erhöhung der Geschwindigkeit und zur Vereinfachung können selektierte Ziffern der Kontonummer gemischt und addiert werden, um einen Sollwert zu erzeugen. Das Verfahren der mathematischen Reduzierung des Informationsgehalts in einem Datenstrom wird als "Hashing" bezeichnet.
- Die selektierten Hashing-Verfahren werden bei jeder der ungültigen Karten der Liste wiederholt. Ist die Tabelle vollständig, wird sie an die Transaktionsterminals verteilt. In der bevorzugten Ausführung wird diese Liste mittels Funkübertragung an alle Terminals gleichzeitig übertragen. Die Liste kann mit Hilfe jeder beliebigen anderen Art von Nachrichtenverbindung übertragen werden, die hierfür geeignet ist.
- Während des Betriebs wird die Kontonummer der für die Transaktion vorgelegten Karte in den Terminal eingelesen. Der Terminal führt daraufhin für die Kontonummer dieselben algorithmischen Schritte bzw. den Hashing-Vorgang durch, der bereits zur Erstellung der Tabelle durchgeführt wurde. Für jedes Bitmuster wird ein Sollwert erzeugt. Der Transaktionsterminal stellt daraufhin fest, ob in jedem Bitmuster der Haupttabelle ein Anzeigezeichen vorhanden ist, das jedem der neu erzeugten Sollwerte entspricht. Enthält ein beliebiges der Bitmuster kein Anzeigezeichen, wird die Karte unverzüglich als gültig erkannt und die Transaktion kann offline zugelassen werden. Stellt sich bei dem Vergleich heraus, daß die Anzeigezeichen in jedem Bitmuster vorhanden sind, besteht die Wahrscheinlichkeit, daß eine ungültige Karte vorgelegt wurde. In diesem Fall ist eine weitere Bearbeitung erforderlich. Zu diesem Zeitpunkt kann die Transaktion an die zentrale Verarbeitungseinheit zum Absolutvergleich der Kontonummern mit der vollständigen Liste der ungültigen Karten umgeleitet werden. Ist das Transaktionssystem gerade nicht betriebsbereit, muß dem Operator übermittelt werden, daß die Kontonummer mit einer gedruckten Liste zu vergleichen ist. Wie weiter oben dargelegt wurde, wird der Terminal einen geringen Prozentsatz an gültigen Karten als potentiell ungültig einstufen, die Ergebnisse einer weiteren Bearbeitung werden jedoch erkennen lassen, daß die so eingestuften Karten tatsächlich gültig sind, und die Transaktion fortgesetzt werden kann.
- Schätzungen zufolge wird eine Haupttabelle, die mit Hilfe der Datenkomprimierung erstellt wurde, ein Viertel bis ein Sechstel der Länge einer Liste der tatsächlich ungültigen Kontonummern aufweisen. Die kürzere Liste kann einfacher übertragen und gespeichert werden. Ein weiterer Vorteil dieses Konzepts liegt darin, daß nicht die gesamte Tabelle abgetastet werden muß, um festzustellen, ob eine Karte gültig ist. Die Sollwerte werden verwendet, um bestimmte Stellen in der Tabelle zu bestimmen. Sobald eine solche Stelle, an der kein Anzeigezeichen vorhanden ist, gefunden wird, wird die betreffende Karte als gültig erkannt.
- Wie ersichtlich ist, stellt das bekannte System ein verbessertes Verfahren zur Verfügung, mit dessen Hilfe festgestellt werden kann, ob eine Transaktionskarte als verloren oder gestohlen gemeldet wurde oder ob der Inhaber die zugeteilte Kreditgrenze überschritten hat.
- Leider kann auch bei diesem System der Fall auftreten, daß Karten, die als ungültig erkannt wurden, nicht in jeder Haupttabelle vorhanden sind. Während des Betriebs wird eine Karte, die gerade als gestohlen oder verloren gemeldet wurde, unverzüglich vom Kartenaussteller und von der zentralen Verarbeitungseinheit in die Liste aufgenommen. Die Karte kann jedoch betrügerisch verwendet werden, bevor sich die Gelegenheit ergab, die Haupttabelle im entfernten Terminal zu aktualisieren.
- Um diesen betrügerischen Gebrauch weiter einzuschränken, kann das System so aufgebaut sein, daß die verteilte Datei der hot cards durch die Kontonummer jeder Karte ergänzt wird, die an den örtlichen Terminals verwendet wird. Im Betrieb wird die Kontonummer der vorgelegten Karte zunächst mit der vorhandenen Haupttabelle verglichen. Ist die Kontonummer nicht vertreten, kann die Transaktion zur weiteren Bearbeitung zugelassen werden. Gleichzeitig werden Anzeigezeichen, welche die Kontonummern der verwendeten Karte darstellen, in die Haupttabelle eingegeben. Durch dieses Verfahren wird jede weitere Verwendung der Karte an diesem Terminal als möglicherweise ungültig eingestuft und zur weiteren Online-Bearbeitung übermittelt. Dieses Konzept verhindert, daß die Karte wiederholt verwendet wird und macht eine vollständigere Online-Überprüfung überflüssig, mit deren Hilfe eine Karte ermittelt werden kann, die seit der letzten Verteilung der Haupttabelle in der zentralen Verarbeitungseinheit oder beim Aussteller in der Liste geführt wird.
- Wie oben festgestellt wurde, kann die Haupttabelle an die örtlichen Terminals übertragen werden. Bei der Übertragung von Daten treten jedoch immer Fehler auf. Übertragungsfehler sind häufiger, wenn eine Technik der Funkübertragung verwendet wird und wenn die entfernten Terminals in Empfangsrandgebieten liegen.
- Viele Verfahren zur Erkennung und Korrektur von Datenübertragungsfehlern wurden entwickelt, die dem Stand der Technik entsprechen. Einige Systeme erfordern lediglich redundante Übertragungen und Vergleiche. In anderen Fällen wurden verschiedene Paritäts- und Prüfziffern zur Erkennung von Übertragungsfehlern verwendet.
- Die Patentschrift EP-A-0101218 offenbart ein Verfahren zur Korrektur von Fehlern bei Binärdaten, welches die Zuordnung mehrerer Prüfworte zu jedem Datenwortsatz umfaßt.
- Fehlererkennungsverfahren dieser Art können zur Korrektur einiger der Übertragungsfehler verwendet werden, die bei der Verteilung der gemäß der vorliegenden Erfindung festgelegten Haupttabelle auftreten. Viele dieser Fehlererkennungsverfahren stellen jedoch keine eindeutigen Informationen über Übertragungsfehler zur Verfügung. Beispielsweise liefern sie Informationen darüber, welche Datenbytes fehlerhaft sind, sie können jedoch nicht erkennen, welche Bits des Bytes fehlerhaft sind. In einem derartigen Fall ist eine Korrektur nicht möglich, und der Datensatz muß möglicherweise aufgegeben werden.
- Werden unbestimmte Übertragungsfehler erkannt, wird im Gegensatz hierzu gemäß der vorliegenden Erfindung, wie es in den angefügten Ansprüchen festgelegt ist, eine Vorrichtung zum Ausgleich dieser Übertragungsfehler zur Verfügung gestellt, und zwar auf eine Art, daß die Information über ungültige Karten nicht verloren geht. Wie weiter oben festgestellt wurde, werden ungültige Karten in einem Bitmuster der Haupttabelle unter Anwendung von Anzeigezeichen aufgelistet. Wird festgestellt, daß bestimmte Bits nicht ordnungsgemäß übertragen wurden, können sie abgeändert werden, indem Anzeigezeichen in diesen Bitstellen angeordnet werden. Zwar erhöht dieses Konzept die Anzahl der gültigen Karten, die als möglicherweise ungültig eingestuft werden, es verringert jedoch gleichzeitig das Risiko, daß eine Karte ausgelassen wird, die in der Haupttabelle hätte aufgelistet werden müssen. Somit verbessert dieses Konzept die Integrität der übertragenen Datei bedeutend und schützt vor betrügerischem Gebrauch der Karten.
- Die vorliegende Erfindung kann somit ein System zur Verteilung von Informationen über ungültige Karten, ein System zur Verteilung von Listen der ungültigen Karten, welches zur Zulassung von Transaktionen an einem Transaktionsterminal verwendet werden kann, ein System zur preiswerten Verteilung der Listen der ungültigen Karten, ein System zur schnellen Online-Verteilung von Listen der ungültigen Karten, eine Datenlistendatei, welche Informationen über ungültige Karten enthält und sehr wenig Speicherplatz beansprucht, eine komprimierte Datenlistendatei, welche problemlos an Ferntransaktionsterminals übermittelt werden kann, eine komprimierte Datenlistendatei, welche die Vorlage einer ungültigen Karte immer anzeigt, wobei die Wahrscheinlichkeit, daß eine gültige Karte als potentiell ungültig erkannt wird, im Bereich von ein bis drei Prozent liegt, ein System zur Zulassung von hot cards, welches problemlos in heutige Ferntransaktionsterminals, deren Arbeitsgrundlage Mikroprozessoren sind, implementiert werden kann, eine komprimierte Datenlistendatei mit Informationen über eine ungültige Transaktion, welche derart angeordnet wird, daß nicht die gesamte Datei überprüft werden muß, um festzustellen, ob eine bestimmte Kontonummer ungültig ist, Mittel zur Erkennung des mehrfachen Gebrauchs von Karten, ein Mittel zur Ergänzung der örtlich gespeicherten Liste der ungültigen Karten durch Karten, die an diesem Ort bereits benutzt wurden, ein Mittel zum Ausgleich der Fehler bei der Übertragung der Liste der Karten sowie ein Mittel zum Ausgleich der unbestimmten Fehler in der Übertragung einer Liste von ungültigen Karten, so daß keine Informationen zu den aufgelisteten Karten verloren gehen, zur Verfügung stellen.
- Die Erfindung wird im folgenden detailliert beschrieben, und zwar unter Bezugnahme auf die begleitenden Zeichnungen, worin :
- Figur 1 eine Prinzipskizze eines Transaktionsnetzes darstellt, bei dem das Verfahren des Erfindungsgegenstands implementiert werden kann.
- Figur 2 eine Darstellung der Haupttabelle mit fünf Bitmustern ist.
- Figur 3 eine Darstellung der letzten 12 Ziffern einer ungültigen Kontonummer ist.
- Figur 4 ein Anlaufdiagramm ist, welches die am Transaktionsterminal gemäß der vorliegenden Erfindung unternommenen Schritte darstellt.
- Figur 5 ein mit Figur 4 vergleichbares Anlaufdiagramm ist, welches die am Transaktionsterminal in einer unterschiedlichen Ausführung der vorliegenden Erfindung unternommenen Schritte darstellt.
- Figur 6 ein Anlaufdiagramm ist, welches das Verfahren zum Ausgleich von Fehlern gemäß der vorliegenden Erfindung darstellt.
- Mit Bezug auf Figur 1 wird ein Transaktionsnetz dargestellt, in das die vorliegende Erfindung implementiert werden kann. Wie in Figur 1 dargestellt ist, umfaßt ein Transaktionsnetz charakteristischerweise einen oder mehrere Aussteller von Transaktionskarten 10. Die Transaktionskarten werden an die Kunden verteilt und beinhalten eine Kontonummer, die den Karteninhaber identifiziert. Die Karten werden Kaufleuten anstelle von Bargeld für Waren und Dienstleistungen vorgelegt.
- Die Transaktion wird häufig durch den Einsatz von Transaktionsterminals 20 zugelassen. Eine große Anzahl an Transaktionsterminals ist öffentlich erhältlich und wird aus diesem Grund hier nicht in Einzelheiten beschrieben. Der derzeitige Stand der Technik bei Transaktionsterminals umfaßt charakteristischerweise ein Kartenlesegerät, welches die Informationen über das Konto sowie andere Daten vom Magnetstreifen der Transaktionskarte liest. Der Terminal kann ebenfalls mit der Fähigkeit ausgestattet sein, den bei der Handelsbank befindlichen Computer, einen Netzschalter oder einen der Kartenaussteller automatisch anzuwählen und eine Online-Verbindung herzustellen. Für den Zweck dieser Offenbarung soll Block 30, genannt "ZE", einer zentralen Verarbeitungseinheit entsprechen, welche über Entscheidungsgewalt auf höherer Ebene verfügt. Beispielsweise kann in der zentralen Verarbeitungseinheit 30 eine vollständige Liste der ungültigen Karten 32 gespeichert werden, welche bei der Entscheidung zu Rate gezogen wird, ob eine Transaktion zugelassen werden soll.
- Wie oben erläutert wurde, kann der Transaktionsterminal 20 mit der Fähigkeit ausgestattet sein, einige Transaktionsanalysen ohne Verbindung zur übergeordneten zentralen Verarbeitungseinheit (ZE) 30 durchzuführen. Damit sie diese Funktionen ausüben können, umfassen Terminals einen Mikroprozessor, zweckbestimmte Festwertspeicher, Speicher mit wahlfreiem Zugriff (RAMs), ein Tastenfeld und ein Display. Eine Art des dynamischen Speicherraums muß zum Speichern der Haupttabelle 40 zugeordnet werden, um den Erfindungsgegenstand ausführen zu können. Zusätzlich muß ein Programm zur Verfügung stehen, um die vorgelegten Kontonummern anhand der Daten der Haupttabelle zu überprüfen. Fachleute im Bereich der Programmentwicklung sind durchaus in der Lage, einen Terminal so zu programmieren, daß er diese Funktionen erfüllt.
- Gemäß dem Erfindungsgegenstand ist Terminal 20 fähig festzustellen, ob eine für eine Transaktion vorgelegte Karte möglicherweise ungültig ist. Diese Leistung wurde mit Hilfe der obengenannten U.S.-Patentschriften erzielt. Bei Systemen, die dem Stand der Technik entsprechen, werden jedem Transaktionsterminal die eigentlichen ungültigen Kontonummern zugeführt. Die Kontonummer der vorgelegten Karte wird mit den im Speicher aufgelisteten Kontonummern verglichen, um festzustellen, ob die Transaktion zulässig ist. Dagegen wird im Falle des Erfindungsgegenstands eine Haupttabelle, welche weniger Daten als die ungültigen Kontonummern enthält, erzeugt und den Terminals zugeführt. Auf diese Art können wichtige Daten in weniger Raum gespeichert werden. Zusätzlich werden nur bestimmte Stellen in der Tabelle überprüft, um festzustellen, ob die Karte ungültig ist.
- Gemäß dem Erfindungsgegenstand sind die Daten über die ungültigen Karten in einer Haupttabelle 40 enthalten, welche an der zentralen Verarbeitungseinheit 30 erzeugt wird. Ein Beispiel für eine Haupttabelle 40 ist in Figur 2 detailliert dargestellt. Die Haupttabelle umfaßt mindestens ein Bitmuster mit einer Länge von B Bit. Vorzugsweise werden mehrere Bitmuster verwendet. Wie nachfolgend dargestellt ist, wird die Wahrscheinlichkeit vermindert, daß eine gültige Karte als potentiell ungültig eingestuft wird, indem in der Haupttabelle mehrere Bitmuster anstelle von nur einem einzelnen Bitmuster verwendet werden. In der in Figur 2 dargestellten Ausführung werden fünf Bitmuster verwendet.
- Bei der Auswahl der Länge der Bitmuster ist Wert darauf zu legen, daß der Informationsgehalt im Muster maximiert wird. Statistische Analysen belegen, daß der größte Informationsgehalt in Bitmustern auftritt, wenn ungefähr die Hälfte der Bits die Null und die andere Hälfte die binäre Eins aufweist. Geht man davon aus, daß die algorithmischen Funktionen, die zur Erzeugung der Tabelle angewendet werden, Ergebnisse mit pseudozufälligen Eigenschaften liefern, ergibt sich der Teil der Bits eines Bitmusters, welcher Null entspricht, durch die folgende Gleichung :
- (1) Z = [1 - (1/B) ]N
- worin Z den Teil, B die Anzahl der Bits des Musters und N die Anzahl der aufgelisteten, ungültigen Karten darstellt. Weist jedes Bitmuster eine Länge von 200.000 Bits auf, tritt bei ca. 138.000 aufgelisteten Kontonummern eine durchschnittliche Verteilung auf, bei der die Hälfte der Bits die Null und die andere Hälfte der Bits die binäre Eins aufweist (Z = 0,5). In der dargestellten Ausführung, in der anfangs 100.000 Karten aufgelistet werden, liegt die Wahrscheinlichkeit, daß ein beliebiges Bit die binäre Eins aufweist, bei 0,4. Werden im Betrieb die Kontonummern gemäß dem weiter unten erläuterten Aktualisierungsvorgang der Haupttabelle hinzugefügt, erhöht sich der Informationsgehalt im Bitmuster, während die Wahrscheinlichkeit auf 0,5 ansteigt.
- Zur Erstellung der Haupttabelle werden die Kontonummern der ungültigen Karten dem Vorgang des "Hashing" unterzogen, um komprimierte Daten zu erhalten. Eine Kontonummer läßt sich durch Codierung der Nummer unter Anwendung des kryptographischen Standards (DES, data encryption standard) und eines geheimen Schlüssels "hashen". Die sich ergebende Nummer kann auf einen Sollwert zwischen Null und B-1 gerundet werden. Ein Anzeigezeichen (beispielsweise eine "Eins", wenn alle Bits anfänglich auf die "Null" eingestellt waren) kann daraufhin im Bitmuster an der Stelle angeordnet werden, die dem durch die algorithmische Funktion erzeugten Sollwert entspricht. Wird mehr als ein Bitmuster verwendet, kann die Kontonummer unter Anwendung eines anderen Schlüssels erneut codiert werden. Das Ergebnis wird gerundet, um einen anderen Sollwert zu erzielen, der verwendet wird, um ein Anzeigezeichen in das zweite Bitmuster zu plazieren. Dieser Vorgang wird wiederholt, wobei die Kontonummer einmal für jedes in der Haupttabelle vorhandene Bitmuster codiert wird. Jede ungültige Karte weist dann in jedem der Bitmuster ein Anzeigezeichen auf. Vergleichbare Schritte werden für jede ungültige Karte unternommen, und Anzeigezeichen werden der Tabelle hinzugefügt. Befand sich durch eine frühere Karte bereits ein Anzeigezeichen an einem Sollwert, bleibt dieses Anzeigezeichen unverändert.
- Zwar stellt der kryptographische Standard (DES) ein Verfahren mit geeigneten pseudozufälligen Eigenschaften für den Hashing-Vorgang von Kontonummern zur Verfügung, er ist jedoch zeitaufwendig und kompliziert. In der dargestellten Ausführung wird ein einfacherer und schnellerer Hashing-Algorithmus beschrieben, der ein annehmbares Maß an pseudozufälligen Eigenschaften aufweist. In diesem Zusammenhang stellt eine pseudozufällige algorithmische Funktion sicher, daß jedweder Sollwert, der von der Kontonummer erzeugt wurde, mit der gleichen Wahrscheinlichkeit irgendwo im Bitmuster liegt. Des weiteren dürfen die Ergebnisse der algorithmischen Funktion, die mit einem Bitmuster verwendet werden, in keiner Weise den Ergebnissen der algorithmischen Funktion entsprechen, die zur Erzeugung eines anderen Bitmusters verwendet wurden.
- In der dargestellten Ausführung werden diese Faktoren im Gleichgewicht gehalten, indem kleine Gruppen von Ziffern der Kontonummern ausgewählt und zusammengestellt werden, um Sollwerte zu erzeugen. Dieses Konzept ist am besten verständlich, wenn Figur 3 und die nachfolgenden Tabellen hinzugezogen werden. Figur 3 stellt die letzten 12 Ziffern einer Kontonummer 0358-2314-2787 dar. Die Position dieser Ziffern wurde mit 1 bis 12 bezeichnet, und zwar von rechts nach links. Weist ein Bitmuster 200.000 Eingaben auf, müssen Sollwerte zwischen 0 und 199.999 erzeugt werden. Die bedeutendste Ziffer dieses sechsstelligen Sollwerts muß entweder eine Eins oder eine Null sein. Die übrigen fünf Ziffern müssen zwischen 0 und 9 liegen.
- Der erste Sollwert, der verwendet wird, um ein Anzeigezeichen im ersten Bitmuster der Figur 2 zu plazieren, kann unter Anwendung der Tabelle I erzeugt werden, welche lediglich eine geeignete Hashing-Funktion darstellen soll. TABELLE I ZIFFER DES SOLLWERTS POSITIONEN DER KONTONUMMERN ENTSPRECHENDE KONTOZIFFERN SOLLWERT
- Wie aus obiger Tabelle I ersichtlich ist, ergibt sich die erste Ziffer auf der Grundlage, ob die Summe der beiden Ziffern in der Kontonummer gerade oder ungerade ist. In diesem Beispiel befinden sich die zwei ausgewählten Ziffern der Kontonummer (2, 4) an der vierten und fünften Stelle. Da die Summe aus 2 plus 4 gerade ist, ist die erste Ziffer des Sollwertes 0. Ziffer 2 der Kennzahl 1 ist die Modulo-10-Summe der Ziffern der Kontonummer, die sich an den Positionen 1, 7 und 8 befinden, nämlich 7, 3 und 2. Die Summe aus 7+3+2 ergibt 12, wobei die Modulo-10-Summe 2 beträgt, so daß Ziffer 2 des Sollwertes 2 ist. Dementsprechend ist Ziffer 3 die Modulo-10-Summe aus 8+2+8 (Positionen 2, 4 & 9), welche 8 entspricht. Aus diesem Grund ist die dritte Ziffer der Kennzahl 8. Die übrigen Ziffern werden auf vergleichbare Art und Weise berechnet, wobei sich die Ziffern 7, 1 und 0 ergeben. Werden im Falle der Figur 3 diese Ziffern zusammen gelesen, beträgt der Sollwert 028170. Ein Anzeigezeichen wird daraufhin im ersten Bitmuster am 28.170sten Bit plaziert. Befindet sich aufgrund einer früheren Eingabe in die Tabelle bereits ein Anzeigezeichen an diesem Bit, wird keine Änderung vorgenommen.
- Vergleichbare Sollwerte werden daraufhin für jedes Bitmuster der Haupttabelle berechnet. In der bevorzugten Ausführung mit 5 Bitmustern werden weitere vier Sollwerte erzeugt. Für jeden Sollwert wird eine Tabelle verwendet, deren Aufbau mit der oben dargestellten Tabelle vergleichbar ist, deren Inhalt jedoch abweicht. Die für die Tabellen ausgewählten Ziffern der Kennzahl müssen voneinander so unterschiedlich wie möglich sein.
- Eine zweite Tabelle (Tabelle II) ist nachfolgend als weiteres, erläuterndes Beispiel dargestellt: TABELLE II ZIFFER DES SOLLWERTS POSITIONEN DER KONTONUMMERN ENTSPRECHENDE KONTOZIFFERN SOLLWERT
- Wird die in Figur 3 dargestellte Kontonummer (0358-2314-2787) gemäß dem Algorithmus der Tabelle II dem Vorgang des Hashing unterzogen, wird ein Sollwert von 182.643 erzeugt. Ein Anzeigezeichen wird daraufhin in Bit 182.643 des zugeordneten Bitmusters plaziert.
- Wird eine Haupttabelle auf diese Art und Weise erzeugt, wird für jede ungültige Karte ein Anzeigezeichen in jedem Bitmuster plaziert. Wird die Tabelle verwendet, um eine ungültige Kontonummer zu ermitteln (ein Vorgang, der nachfolgend genauer beschrieben wird), muß ein Anzeigezeichen in jedem geprüften Bitmuster vorhanden sein, ansonsten wird die Karte als gültig erkannt. Das Gegenteil dieser Aussage trifft nicht zu. Genauer gesagt kann die Karte selbst dann gültig sein, wenn ein Anzeigezeichen in jedem Bitmuster vorhanden ist. Es ist ersichtlich, daß die Wahrscheinlichkeit des Vorhandenseins von Anzeigezeichen für die durch Hashing jedweder Kontonummer erzielten Sollwerte zunimmt, je mehr ungültige Karten in der Tabelle aufgelistet sind und je mehr Anzeigezeichen dem Bitmuster aufgrund der Ergebnisse der zufälligen algorithmischen Funktion hinzugefügt werden.
- Die Wahrscheinlichkeit, daß eine nicht aufgelistete, gültige Kontonummer als potentiell ungültig erkannt wird, wird durch folgende Formel dargestellt:
- (2) P = [1 - (1-1/B)N]M
- worin P der Wahrscheinlichkeit, B der Anzahl der Bits in jedem Muster, N der Anzahl der aufgelisteten Kontonummern und M der Anzahl der Bitmuster entspricht. In der hierin dargestellten Anordnung, in der fünf Bitmuster mit einer Länge von jeweils 200.000 Bits verwendet werden, liegt die Wahrscheinlichkeit, daß eine gültige Karte als potentiell ungültig erkannt wird, im Bereich von 10,1 Prozent, wenn 200.000 Kontonummern aufgelistet werden. Wird die Datei auf 100.000 Kontonummern reduziert, sinkt die Wahrscheinlichkeit, daß eine gültige Karte als potentiell ungültig erkannt wird, auf weniger als ein Prozent.
- Die Wahrscheinlichkeit, eine gültige Karte als potentiell ungültig zu erkennen, läßt sich variieren, indem die Gesamtzahl der Bitmuster in der Haupttabelle verändert wird. Geht man davon aus, daß die Länge des Bitmusters so angepaßt wurde, daß der Informationsgehalt maximiert ist (wie oben erläutert wurde), ergibt sich die Wahrscheinlichkeit, daß eine gültige Karte als potentiell ungültig erkannt wird, durch die folgende Gleichung:
- (3) P = 1/2M
- Diese Gleichung zeigt, daß die Wahrscheinlichkeit, eine gültige Karte als potentiell ungültig zu erkennen, bei 1 zu 32 oder bei ungefähr 3,1 Prozent liegt, wenn fünf Bitmuster verwendet werden. In der dargestellten Ausführung, in der anfänglich nur 100.000 Karten aufgelistet werden, werden die Bitmuster nicht bis zu ihrer vollständigen Datenspeicherkapazität ausgenutzt, und die Wahrscheinlichkeit, daß eine gültige Karte als potentiell ungültig erkannt wird, liegt unterhalb von einem Prozent, wie es oben bereits festgestellt wurde.
- Statistische Analysen legen nahe, sieben Bitmuster zu verwenden, wenn 100.000 ungültige Karten in einer Haupttabelle aufzulisten sind, die eine Länge von einer Million Bits aufweist. Um eine solche Haupttabelle zu implementieren, muß ein Hashing-Algorithmus erzeugt werden, der die Informationen willkürlich in den sieben Bitmustern mit einer Länge von jeweils 142,857 Bits verteilt. Aus praktischen Überlegungen wurden für diese Darstellung fünf Bitmuster gewählt, da ein geeigneter Hashing-Algorithmus müheloser erzeugt werden konnte. Obwohl die Anwendung von fünf Bitmustern anstelle von sieben in der Haupttabelle zu einem Anstieg des Prozentsatzes der gültigen Karten führt, die als potentiell ungültig eingestuft werden, ist dieser Anstieg recht gering und wird als annehmbar betrachtet. Schließlich ermöglicht es die Anwendung von fünf Bitmustern, daß die Anzahl der aufgelisteten Kontonummern auf ungefähr 140.000 ansteigt, wobei die Wahrscheinlichkeit, eine gültige Karte als potentiell ungültig zu erkennen, sich lediglich auf 3,25 Prozent erhöht.
- Die Wirkungsweise des vorliegenden Systems der Datenkomprimierung läßt sich mit dem Auflisten der eigentlichen Kontonummern in einem Speicher vergleichen. Zum Zwecke des Vergleichs werden die letzten 12 wesentlichen Ziffern der Kontonummer ausgewählt. Jede Kontonummer mit 12 Ziffern benötigt 48 Bits Speicherplatz, wenn man von vier Bits pro Ziffer in einem binärcodierten Dezimalformat ausgeht. Im Gegensatz hierzu wird im vorliegenden System eine zufriedenstellende Arbeitsweise erzielt, wenn die Anzahl der Bits in der Haupttabelle ungefähr sieben bis zehnmal größer als die Anzahl der aufzulistenden, ungültigen Kontonummern ist. Dies stellt eine Verringerung des Speicherbedarfs um den Faktor 5 dar und hält die konkurrierenden Faktoren des begrenzten Speichers und des Informationsgehalts im Gleichgewicht.
- In der Praxis kann die Liste der ungültigen Karten, die zur Erstellung der Tabelle verwendet wird, auch in Hinblick auf ihr geographisches Auftreten gekürzt werden, und zwar auf eine mit der Berstein-Patentschrift vergleichbare Art und Weise. Anstatt die gekürzten Listen jedoch zu verteilen, wie es in der Berstein-Patentschrift vorgeschlagen wird, werden die Listen zur Anfertigung mehrerer Haupttabellen verwendet, die daraufhin geographisch verteilt werden. Auf diese Weise läßt sich die Liste der ungültigen Karten, die allein in den Vereinigten Staaten eine Million übersteigen kann, in regionale Untermengen mit einem Umfang von jeweils 100.000 Karten aufteilen. Diese Haupttabelle kann eine Länge von einer Million Bits oder 125 KB aufweisen. 128K dynamischer RAM sind zu relativ geringen Kosten problemlos erhältlich und können eine Haupttabelle dieser Größe ohne Schwierigkeiten speichern. Noch wichtiger ist die Tatsache, daß die verringerte Größe der Hauptdateien die für die Übertragung der Information an die Terminals benötigte Zeit vereinfacht und verkürzt.
- Die Übertragung der Haupttabelle an jeden einzelnen Terminal kann mit Hilfe derselben Art von Fernmeldeleitung erfolgen, die zur Verknüpfung des Terminals und der zentralen Verarbeitungseinheit für Online-Zulassungen verwendet wird. Diese Leitungen sind in Figur 1 unter der Kennziffer 50 dargestellt. In diesem Konzept muß mit jedem Terminal ein Kommunikationsprotokoll hergestellt werden, um die Daten zu übermitteln. In der bevorzugten Ausführung des Erfindungsgegenstands wird die Haupttabelle 40 mittels Radio- oder Fernsehwellen an den Terminal gesendet. Wie in Figur 1 dargestellt ist, ist die zentrale Verarbeitungseinheit mit einem Sender 60 verbunden. Der Sender 60 erzeugt elektromagnetische Wellen, die von der Antenne 72 des in jedem Terminal vorhandenen Empfängers 70 empfangen werden. Die vom Empfänger empfangenen Daten werden in den Speicher eines jeden Terminals geladen. Daten auf Radiowellen können problemlos mit 38.400 Bits pro Sekunde übertragen werden, so daß die gesamte Haupttabelle mit einer Million Bits in weniger als dreißig Sekunden übertragen werden kann. Diese Datei kann einmal täglich erstellt und übertragen werden, so daß den Terminals die aktuellsten Daten über ungültige Karten vorliegen. Wird ein Fernsehsignal verwendet, kann die Information in das Vertikalaustastungsintervall eingefügt werden, wie es Fachleuten gut bekannt ist.
- Soll die gesamte Tabelle weniger häufig übertragen werden, läßt sich die Tabelle durch Zusätze aktualisieren. Wird die Haupttabelle beispielsweise wöchentlich übertragen, können Aktualisierungen täglich übertragen werden. In diesem Fall werden die Listen der zusätzlichen, ungültigen Karten jedem Terminal zugeführt. Jede neu übertragene, ungültige Kontonummer wird durch den einzelnen Terminal dem Vorgang des Hashing unterzogen, und Anzeigezeichen werden in den Bitmustern der Haupttabelle plaziert.
- Verwendet das System eine Arbeitsweise, bei der eine bedeutende Anzahl an neuen Einträgen üblicherweise dem Terminal zugeführt werden, bevor eine völlig neue Haupttabelle erneut übertragen wird, können Schritte zur Verringerung der für die Aktualisierungen erforderlichen Übertragungszeit unternommen werden. Beispielsweise können alle Kontonummern mit zwölf Ziffern "prehashed", d.h. im voraus dem Hashing-Vorgang unterzogen werden, um eine siebenstellige Zahl zu erzielen, wenn eine Tabelle anfänglich erstellt wird. Die siebenstellige Nummer wird daraufhin dem Hashing-Vorgang unterzogen, um auf eine Art Sollwerte zu erzielen, die mit der oben beschriebenen Art vergleichbar ist. Wird die Haupttabelle auf diese Weise erstellt, müssen bei der Aktualisierung der Haupttabelle lediglich die siebenziffrigen, im voraus dem Hashing-Vorgang unterzogenen Kontonummern anstelle der vollständigen zwölfziffrigen Nummern den Transaktionsterminals zugeführt werden. Dieses Konzept kann die Übertragungszeit annähernd halbieren.
- Es ist zu berücksichtigen, daß keine einzelnen Kontonummern aus der Haupttabelle gelöscht werden können, auch wenn ihr einzelne Kontonummern hinzugefügt werden können. Es ist offensichtlich, daß bei jeder Erstellung einer Datei mittels Datenkomprimierung doppelte oder überschneidende Eingaben auftreten. Aus diesem Grund können die Anzeigezeichen nicht sicher aus der Datei entfernt werden, ohne daß weitere wichtige Daten unbeabsichtigt zerstört würden, wenn eine einzelne Karte wieder als gültig eingestuft wird (oder der Zeitraum für die Führung in der Liste beendet ist).
- Ein wirksames Löschen der Kontonummern läßt sich nur durch die Übertragung einer neu erstellten Haupttabelle erreichen. Die Übertragung einer neuen Haupttabelle muß erfolgen, bevor die Anzahl der in der Liste geführten Kontonummern, die sich durch Aktualisierungen (oder den weiter unten beschriebenen Gebrauch von Karten) erhöht, einen Stand erreicht, an dem eine unannehmbare Anzahl an gültigen Karten als potentiell ungültig erkannt wird.
- Auch andere Verfahren der Bereitstellung von Zwischenaktualisierungen der Dateien sind denkbar. Beispielsweise kann eine neue Haupttabelle unter Anwendung der aktuellsten Liste der ungültigen Karten an der zentralen Verarbeitungseinheit erstellt werden. Die neue Haupttabelle kann daraufhin mit der alten Haupttabelle verglichen werden, und die Informationen über Abweichungen können verteilt werden. Wie oben festgestellt wurde, müssen sich Aktualisierungen der Haupttabelle darauf beschränken, Informationen über neu hinzugekommene Karten hinzuzufügen. In diesem Fall werden die neu aufgelisteten Karten in der Haupttabelle durch auf logisch "Eins" gesetzte Bits dargestellt, die vorher auf logisch "Null" gesetzt worden waren. Aktualisierungen können der Datei zugefügt werden, indem die Adressen jedweder Bits übertragen werden, die auf logisch "Eins" abgeändert wurden. Der Prozessor des Terminals kann daraufhin in der örtlich gespeicherten Version der Haupttabelle die erkannten Bits auf logisch "Eins" setzen.
- Schätzungen zufolge kann die insgesamt übertragene Datenmenge um mehr als sechzig Prozent reduziert werden, wenn die gesamte Datei wöchentlich übertragen wird und täglich eine aktualisierende Übertragung erfolgt. Trotz dieser Sachlage wird es bevorzugt, die gesamte Datei täglich zu übertragen, da jeder neu installierte Terminal eine vollständige Haupttabelle anstelle einer Aktualisierung empfangen muß, um in Betrieb genommen werden zu können.
- Da die Erstellung der Haupttabelle und ihre Übertragung an die Transaktionsterminals nun bereits erläutert wurden, wird im folgenden die Verwendung der Haupttabelle im Transaktionsterminal beschrieben, und zwar unter Bezugnahme auf das in Figur 4 dargestellte Ablaufdiagramm. Zum Zeitpunkt des Kaufvorgangs legt der Karteninhaber dem Verkäufer seine Transaktionskarte vor. Die Kontonummer der Karte wird daraufhin an den Transaktionsterminal übertragen, wie es in Schritt 100 der Figur 4 dargestellt ist. Der Prozessor des Transaktionsterminals kann daraufhin Sollwerte für jedes Bitmuster erzeugen, und zwar auf eine Art, die den für die Erstellung der Haupttabelle verwendeten Algorithmen genau entspricht.
- Geht man davon aus, daß das oben beschriebene Hashing- System zur Erstellung der Haupttabelle verwendet wurde, wird die erste Ziffer des ersten Sollwerts dadurch festgelegt, ob die Summe der in den Positionen 4 und 5 befindlichen Ziffern gerade oder ungerade ist. Die verbleibenden fünf Ziffern des ersten Sollwerts sind die Modulo-Summe jeder Gruppe dreier ausgewählter Ziffern. Nachdem der erste Sollwert erzeugt wurde (Schritt 102), untersucht der Prozessor das erste Bitmuster der Haupttabelle daraufhin, ob ein Anzeigezeichen an der Stelle plaziert wurde, die durch den Sollwert festgelegt wurde (Schritt 104). Befindet sich kein Anzeigezeichen an dieser Stelle des ersten Bitmusters, ist die Überprüfung abgeschlossen und die Transaktion kann zur weiteren Bearbeitung zugelassen werden (Schritt 106).
- Schritt 106 soll die nächste Schrittfolge darstellen, der die Transaktion normalerweise unterworfen wird. Beispielsweise wird die Höhe des Betrags der Transaktion mit der Dollargrenze verglichen, die entweder auf der Karte als Information zur Risikobeurteilung oder im Terminal gespeichert ist. Liegt die Transaktion unterhalb dieser Dollargrenze, kann sie automatisch direkt am Terminal zugelassen werden. Liegt die Transaktion über diesem Betrag, kann die Information über die Transaktion noch an die zentrale Verarbeitungseinheit zur weiteren Bearbeitung übermittelt werden.
- Befindet sich ein Anzeigezeichen im ersten Bitmuster, wird die Überprüfung eines jeden der verbleibenden Bitmuster fortgesetzt. Der Prozessor bestimmt zunächst, ob noch ungeprüfte Bitmuster vorhanden sind (Schritt 107). Sind noch Bitmuster vorhanden, erzeugt der Prozessor den Sollwert für das nächste Bitmuster in Schritt 108. Der Prozessor überprüft, ob ein Anzeigezeichen im nächsten Bitmuster der Haupttabelle angeordnet ist, und zwar an der Stelle, die durch den neu erzeugten Sollwert bestimmt wird (Schritt 104). Wie oben festgestellt wurde, wird die Karte als gültig erkannt und die Transaktion zugelassen, wenn sich an dieser Stelle kein Anzeigezeichen befindet (Schritt 106).
- Befinden sich in allen Bitmustern Anzeigezeichen (d.h. es liegen keine weiteren Bitmuster zur Überprüfung vor, und deshalb lautet die Antwort auf Entscheidungsschritt 107 "Nein"), besteht die Möglichkeit, daß die Karte ungültig ist, und die Information muß zur weiteren Bearbeitung weitergeleitet werden, wie es in Schritt 110 dargestellt ist. In diesem Schritt kann eine Online-Verbindung mit der zentralen Verarbeitungseinheit 30 hergestellt werden. Die Transaktionsdaten werden der zentralen Verarbeitungseinheit übertragen, wo sie weiter überprüft werden. Die Überprüfung kann durch die zentrale Verarbeitungseinheit erfolgen, wenn die Liste aller ungültigen Karten dort gespeichert ist. In dem Fall, daß die Listen der ungültigen Karten bei den Ausstellern 10 gespeichert werden, kann die Transaktion zur weiteren Bearbeitung durch den Aussteller umgeleitet werden. Ist die Karte tatsächlich ungültig, kann die Nachricht zurück an den Terminal gesendet werden, die Transaktion abzulehnen. Ist die Karte jedoch gültig, wird die Transaktion zugelassen.
- Wie oben erläutert wurde, stellt der Erfindungsgegenstand eine Haupttabelle mit einer großen Datenmenge, die in einem geringen Raum gespeichert wird, zur Verfügung. Das hierin beschriebene Konzept hat jedoch einen zusätzlichen Vorteil. Genauer gesagt ist es nicht erforderlich, die gesamte Tabelle zu überprüfen, um eine beliebige Karte mit der Haupttabelle zu vergleichen. In dem in der U.S.-Patentschrift 3,696,335 beschriebenen System, in dem die Liste der eigentlichen Kontonummern dem Terminal zugeführt wird, wird die Kontonummer mit jeder der Nummern in der Liste verglichen, um festzustellen, ob die Karte in der Liste geführt wird. Selbst wenn kompliziertere Algorithmen für die Binärsuche verwendet werden (wenn Listen numerisch angeordnet werden), bleibt eine Reihe von Vergleichen erforderlich. Im Gegensatz hierzu muß im Erfindungsgegenstand nur die Stelle des Bitmusters überprüft werden, die dem Sollwert entspricht, um festzustellen, ob ein Anzeigezeichen vorhanden ist. Es ist nicht erforderlich, das gesamte Bitmuster zu überprüfen. In einer Haupttabelle mit fünf Bitmustern kann festgestellt werden, ob sich eine Kontonummer unter 100.000 ungültigen Karten befindet, indem lediglich fünf Stellen der Haupttabelle überprüft werden. Fehlt ein beliebiges der Anzeigezeichen, steht die Gültigkeit der Karte fest.
- Im den Versuchsprogrammen, die vom Abtretungsempfänger zur Implementierung des Erfindungsgegenstands veranlaßt wurden, erfolgt die Übertragung der Haupttabelle zu den entfernten Terminals täglich. Die große Häufigkeit der Verteilung ermöglicht es, daß die Daten in der Haupttabelle wesentlich aktueller sind, als die in den herkömmlichen, gedruckten Mitteilungsblättern enthaltenen Informationen, die wöchentlich verteilt werden. Dennoch enthalten auch die täglich verteilten Informationen nicht alle Karten, die dem Aussteller als ungültig bekannt sind. Beispielsweise werden zahlreiche Karten unmittelbar nachdem sie als gestohlen oder verloren gemeldet werden verwendet. Somit verstreichen einige Stunden bis zur Verteilung der Information, selbst wenn der Karteninhaber sich unmittelbar nachdem die Karte gestohlen wurde oder verloren ging mit dem Aussteller in Verbindung setzt.
- Das Fehlen einer als ungültig bekannten Karte in der Haupttabelle beschränkt sich nicht auf diejenigen Fälle, in denen nicht genügend Zeit zur Verfügung stand, um die gemeldeten Informationen zu verteilen. Wie weiter oben festgestellt wurde, werden ungültige Transaktionskarten auf der Grundlage des geographischen Gebiets, in dem sie am wahrscheinlichsten gebraucht werden, im Kartenmitteilungsblatt aufgelistet. Beispielsweise wird eine Karte, die in New York gestohlen wurde oder verloren ging, im allgemeinen nicht in Kalifornien in den Listen erscheinen. Diese Einschränkung wurde aus Gründen der Kostenersparnis auferlegt und um sicherzustellen, daß das Kartenmitteilungsblatt (und nun die Haupttabelle) nicht unverhältnismäßig lang ausfällt. Leider führt diese Beschränkung auch dazu, daß ein geringer Prozentsatz an ungültigen Karten, die in einem unerwarteten, geographischen Bereich verwendet werden, schwieriger ermittelt werden kann.
- Um die Häufigkeit des unentdeckten, betrügerischen Gebrauchs von bekanntermaßen ungültigen Karten zu verringern, kann daß vorliegende System so abgeändert werden, daß die Haupttabelle in den örtlichen Terminals durch die Kontonummern jedweder Karte, die für eine Transaktion verwendet wird, ergänzt wird. Durch diese Einrichtung führt ein nochmaliger Gebrauch der Karte an diesem Terminal zu der Einstufung, daß die Karte möglicherweise ungültig ist. Wie weiter oben festgestellt wurde, und zwar unter Bezugnahme auf Figur 4, wird eine als potentiell ungültig eingestufte Karte zu ihrer weiteren Online- Bearbeitung umgeleitet. Ist die Karte beim Aussteller als ungültig aufgelistet, wird dies während des Verfahrens der Online-Zulassung festgestellt und angemessene Schritte können eingeleitet werden.
- Figur 5 stellt die Implementierung dieses zusätzlichen Aspekts der vorliegenden Erfindung dar. Die Schritte, die mit denen der Figur 4 vergleichbar sind, weisen die gleichen Nummern auf und werden nicht weiter erörtert. Um die vorliegende Erfindung zu implementieren, wird die Kontonummer der Haupttabelle hinzugefügt, indem Anzeigezeichen, welche die Karte repräsentieren, in jedem der Bitmuster angebracht werden. Wie oben unter Bezugnahme auf Figur 4 festgestellt wurde, ist der Prozessor des Terminals bereits darauf programmiert festzustellen, ob Anzeigezeichen in jedem der Bitmuster vorhanden sind, und zwar an den Adressen, welche durch die in Schritt 102 berechneten Sollwerte bestimmt werden. Ist kein Anzeigezeichen vorhanden (die Antwort auf Schritt 104 lautet "Nein") wird die Karte als gültig betrachtet und die Transaktion wird fortgesetzt. In Verbindung mit der weiteren Bearbeitung werden der Haupttabelle Anzeigezeichen zugefügt, wie es durch die neuen Schritte in Figur 5 dargestellt und unmittelbar im Anschluß erörtert wird. Es ist zu berücksichtigen, daß ein Anzeigezeichen bereits an der geprüften Stelle vorliegt und dem Bitmuster nicht zugefügt werden muß, wenn die Antwort auf Schritt 104 "Ja" lautet. Wie zuvor wird die Karte als in der Liste befindlich betrachtet und muß als potentiell ungültig in Schritt 110 online bearbeitet werden, wenn alle Bitmuster Anzeigezeichen aufweisen (die Antwort auf Schritt 107 lautet "Nein").
- Ist in keinem der Bitmuster ein Anzeigezeichen vorhanden, muß eines angebracht werden. Wie in Schritt 112 dargelegt ist, wird ein Anzeigezeichen an der Stelle des Bitmusters hinzugefügt, die in Schritt 104 gerade als frei bestimmt wurde. In Schritt 107a stellt der Prozessor fest, ob noch Bitmuster verbleiben, die bisher nicht überprüft wurden. Wenn dies nicht der Fall ist, kann die Transaktion mit Schritt 106 fortgeführt werden. Sind zusätzliche Bitmuster zu überprüfen, wird der nächste Sollwert in Schritt 108a erzeugt. Der erzeugte Sollwert wird verwendet, um das nächste Bitmuster zu adressieren und in Schritt 104a zu bestimmen, ob ein Anzeigezeichen vorhanden ist. Ist dies der Fall, fährt der Prozessor mit der Überprüfung der eventuell noch verbleibenden Bitmuster fort. Ist kein Anzeigezeichen vorhanden, wird in Schritt 112 eines hinzugefügt. Dieser Vorgang dauert an, bis alle Bitmuster überprüft und aktualisiert wurden.
- Es ist anzumerken, daß die Schritte 104a, 107a und 108a mit identischen Teilprogrammen der jeweiligen Originalschritte 104, 107 und 108 durchgeführt werden. Somit erfordert die Implementierung dieses zusätzlichen, erfinderischen Aspekts, bei dem Anzeigezeichen in den berechneten Stellen der Bitmuster plaziert werden, faktisch keine zusätzliche Programmierung. Ist der Vorgang abgeschlossen, ist ein Anzeigezeichen in jeder der Stellen des Bitmusters vorhanden. Dementsprechend wird eine Karte, wenn sie für eine Folgetransaktion an demselben Terminal vorgelegt wird, als potentiell ungültig erkannt und zur Online- Bearbeitung umgeleitet.
- Im allgemeinen ist die Wahrscheinlichkeit nicht sonderlich hoch, daß eine bestimmte Transaktionskarte innerhalb eines Zeitraumes von vierundzwanzig Stunden an einem bestimmten Terminal rechtmäßig häufiger als ein Mal benutzt wird. Eine ungültige Karte wird jedoch häufig an einem Ort für mehrere Einkäufe verwendet. Dies wurde bei Transaktionen an Tankstellen beobachtet, für welche dieser Aspekt der vorliegenden Erfindung besonders geeignet sein dürfte.
- Auch große Einzelhandelsgeschäfte mit zahlreichen Transaktionsterminals zählen zu den weiteren geeigneten Einsatzorten. Diese Terminals sind normalerweise mit einem Leitcomputer verbunden, der sich im Geschäft befindet. In dieser Anordnung wird die Haupttabelle der vorliegenden Erfindung an einer Stelle gespeichert und ist mit dem Leitcomputer verbunden. Jeder der Terminals im Geschäft (oder möglicherweise einer Gruppe von Läden, die sich im allgemeinen in demselben Gebiet befindet) verfügt durch den Leitcomputer über einen direkten Zugriff auf die Haupttabelle.
- Nun ist es für einen Karteninhaber nicht ungewöhnlich, einen Einkauf in einer Abteilung eines Geschäfts zu tätigen und sich dann für einen zweiten Einkauf in eine andere Abteilung zu begeben. Der getätigte erste Einkauf in einer Abteilung führt dazu, daß Informationen über die Kontonummer der Karte in die Haupttabelle eingegeben werden. Somit wird die Kontonummer als potentiell ungültig erkannt und im Online-Verfahren zur Zulassung durch die zentrale Verarbeitungseinheit weitergeleitet, wenn sie während des zweiten Einkaufs in einer anderen Abteilung bearbeitet wird.
- Es ist anzumerken, daß es im Umfang der vorliegenden Erfindung liegt, daß die Haupttabelle an einen entfernten Standort ausgegeben wird, der als Netzknoten für zahlreiche Terminals fungiert. Diese Anordnung bewahrt noch eines der Merkmale des vorliegenden Systems, worin die Notwendigkeit verringert wird, daß die entfernten Stationen und die zentrale Verarbeitungseinheit online verbunden sind.
- Es ist ebenfalls anzumerken, daß dieser Aspekt der vorliegenden Erfindung in jedem Terminal implementiert werden kann, der über den Raum zur Speicherung von Informationen bezüglich der Kontonummern von Karten verfügt. Somit kann auch ein Terminal, der nicht für die Arbeit mit einer datenkomprimierten Haupttabelle ausgerüstet ist, dennoch Informationen speichern, die eine Kontonummer repräsentieren, so daß bei nochmaligem Gebrauch die Notwendigkeit der weiteren Bearbeitung im Online- Verfahren erkannt wird. Selbstverständlich wird der für die Hinzufügung von Daten über weitere Kontonummern zusätzlich erforderliche Speicherraum auf ein Mindestmaß herabgesetzt, wenn er mit einem Terminal gekoppelt ist, der über eine datenkomprimierte Haupttabelle verfügt.
- Es ist ersichtlich, daß der Prozentsatz der gültigen Karten, die als potentiell ungültig erkannt werden, sich mit der Hinzufügung von Kontonummern in die Haupttabelle erhöht. Diese Folge wird auf ein Mindestmaß begrenzt, indem die gesamte Haupttabelle ersetzt wird, wenn die neueste Version am Terminal empfangen wird. Die neue Haupttabelle muß alle Karten umfassen, die seit der letzten Aktualisierung als ungültig gemeldet wurden.
- Um die Wirksamkeit der vorliegenden Erfindung zu maximieren, ist es wünschenswert, die Haupttabelle regelmäßig zu verteilen. Um die Datei täglich zu verteilen, muß eine Art der Übertragung, wie zum Beispiel Funkübertragung, verwendet werden. Leider treten bei der Übertragung von Daten Fehler auf.
- Viele Verfahren, die dem Stand der Technik entsprechen, wurden zur Erkennung und Korrektur von Datenübertragungsfehlern entwickelt. Diese Verfahren können zur Steigerung der Richtigkeit der übertragenen Daten verwendet werden, so wie es hierin beschrieben wurde. Die meisten Verfahren zur Fehlererkennung stellen jedoch keine völlig eindeutigen Informationen zu allen Arten von Übertragungsfehlern bereit. Beispielsweise liefern sie Informationen darüber, welche Datenbytes fehlerhaft sind, sie können jedoch nicht erkennen, welche Bits innerhalb des Bytes fehlerhaft sind. In einem solchen Fall kann eine Korrektur unmöglich sein.
- Im Fall der vorliegenden Erfindung können Daten verloren gehen, und eine Transaktionskarte, die als ungültig erkannt werden müßte, kann als gültig eingestuft werden, wenn ein Übertragungsfehler in der Haupttabelle auftritt und unberichtigt bleibt. Um dies zu vermeiden, stellt die vorliegende Erfindung ein einzigartiges System zum Ausgleich von Übertragungsfehlern (im Vergleich zu einem System zur Fehlerkorrektur) zur Verfügung, welches die empfangene Haupttabelle verändert, um die Wahrscheinlichkeit zu verringern, daß eine als ungültig geführte Karte als gültig betrachtet wird.
- Um dieses Ziel zu erreichen, sieht die vorliegende Erfindung ein Konzept zur Erkennung von Fehlern vor, die während der Übertragung aufgetreten sind. Selbstverständlich kann jedweder Fehler, der eindeutig erkannt wird, gemäß den Verfahren korrigiert werden, die dem Stand der Technik entsprechen. Diejenigen Fehler, die zwar erkannt jedoch nicht genau bestimmt werden können, werden ausgeglichen, indem in der Haupttabelle an jeder der verdächtigen Stellen Anzeigezeichen plaziert werden. Da ein Anzeigezeichen im Bitmuster auf eine möglicherweise ungültige Karte hinweist, gehen keine Informationen über ungültige Karten verloren.
- Es gibt zahlreiche Arten der Implementierung solcher Systeme zum Ausgleich von Fehlern. In der bevorzugten Ausführung der vorliegenden Erfindung werden Standardverfahren der Fehlerkorrektur als Grundlage für die Erkennung von Fehlern verwendet. Um die bevorzugte Ausführung richtig einschätzen zu können, muß das Format der Datenübertragung zunächst erläutert werden. Wie weiter oben festgestellt wurde, enthält die Haupttabelle der vorliegenden Erfindung eine Million Datenbits. Diese Haupttabelle wird logisch mit 5953 Datenblöcken mit jeweils 21 Bytes definiert. Jedes Byte besitzt 8 Datenbits, so daß eine Gesamtheit von 168 Datenbits pro Block vorliegt.
- Zum Zwecke der Datenübertragung werden diese 168 Datenbits in 24 Bytes umkonfiguriert, wobei jedes Byte sieben Datenbits und ein Paritätsprüfbit besitzt. Paritätsprüfbits sind nicht neu und der Fachwelt gut bekannt. Kurz zusammengefaßt wird das Paritätsprüfbit so eingestellt, daß die Gesamtanzahl der "Einsen" in jedem Byte eine ungerade Zahl ergibt. Liegt nach der Übertragung eine gerade Zahl an Einsen im Byte vor, so kann daraus geschlossen werden, daß eine ungerade Anzahl an Übertragungsfehlern im Byte vorliegt. Den wahrscheinlichsten Fehler stellt ein fehlerhaftes Einzelbit dar.
- Zusätzlich zu den 24 Bytes, auf die oben Bezug genommen wurde, wird dem Block vor der Übertragung ein 25stes Byte hinzugefügt. Dieser Block wird Längsredundanzkontrollbyte oder LRC-Byte (Longitudinal Redundancy Check byte) genannt. Auch LRC-Bytes sind der Fachwelt bekannt. Das LRC wird durch logische ENTWEDER-ODER-Verbindung eines jeden der vorangegangenen Bytes zusammen erzeugt. Durch dieses Verfahren ist die Gesamtanzahl an "Einsen" in jeder gleichartigen Stelle in jedem Byte eines Blocks (einschließlich des LRC-Bytes) gerade. Das LRC kann verwendet werden, um eine Paritätsprüfung für die Bitstellen in jedem Byte des Blocks zur Verfügung zu stellen (im Gegensatz zur Byteparitätserkennung, die durch das Paritätsbit zur Verfügung gestellt wird). Nach der Übertragung werden alle Bytes, einschließlich des LRC-Bytes) dem ENTWEDER-ODER-Vorgang unterzogen. Liegen keine Übertragungsfehler vor, muß das Ergebnis (genannt Blockfehlerbyte) Null lauten. Hat ein beliebiges der Bits im Blockfehlerbyte den Wert Eins, so ist dies ein Hinweis, daß an dieser Bitstelle in einem der Bytes ein Übertragungsfehler vorliegt. Das Paritätsprüfbit und das LRC-Byte werden gemeinsam zur Erkennung und Korrektur bestimmter Fehler verwendet sowie zur Bereitstellung eines Ausgleichs bei anderen Fehlern.
- In der vom Übertragungsempfänger hierin implementierten Ausführung umfaßt jeder der übertragenen Blöcke tatsächlich 28 Bytes. In den beiden ersten Bytes wird eine Adresse gespeichert, welche die Stelle des Blocks innerhalb der Haupttabelle näher bestimmt. Ein anderes Byte steht für eine zyklische Redundanzkontrolle (CRC; cyclical redundancy check) zur Verfügung. Bei der Anwendung des zyklischen Redundanzkontrollbytes handelt es sich um ein weiteres Fehlerkorrekturverfahren, welches bei Verfahren eingesetzt wurde, die dem Stand der Technik entsprechen, und da es im vorliegenden System des Fehlerausgleichs keine Anwendung findet, ist eine weiterführende Beschreibung nicht erforderlich. In der Praxis werde sowohl die Adreßbytes als auch das CRC-Byte zur Erzeugung des LRC-Bytes verwendet. Es ist wünschenswert, eine ungerade Anzahl an Bytes (in diesem Falle 27) zur Erzeugung des LRC-Bytes zu verwenden, wodurch sichergestellt wird, daß das LRC-Byte eine ungerade Parität aufweist, die der aller Datenbytes entspricht.
- Nachdem das Format der Übertragungsblöcke beschrieben wurde, wird nun das System zur Fehlerkorrektur und zum Fehlerausgleich erläutert, und zwar unter Bezugnahme auf Figur 6. In Schritt 202 wird das Blockfehlerbyte durch eine ENTWEDER-ODER- Verbindung aller Bytes, die nicht übertragen wurden, erzeugt. Das Blockfehlerbyte wird gespeichert. Wie oben festgestellt wurde, muß der gesamte Inhalt der Blockfehlerbytes Null lauten, wenn keine Fehler aufgetreten sind. Das Vorhandensein jedweder "Einsen" ist ein Hinweis darauf, daß an dieser Bitstelle ein Fehler in einem der Bytes aufgetreten ist. Die Anzahl der im Blockfehlerbyte dargestellten Fehler (die Anzahl der "Einsen") wird in einem LRC-Fehlerzähler in Schritt 204 gespeichert.
- In Schritt 206 werden die Paritätsfehler erkannt, und die Stelle eines jeden Bytes wird gespeichert, das einen Paritätsfehler aufweist. Die Anzahl der Bytes mit Paritätsfehlern wird in einem Paritätsfehlerzähler in Schritt 208 gespeichert. Wie weiter oben festgestellt wurde, müssen die Bytes eine ungerade Parität aufweisen. Ist die Parität gerade, ist bei diesem Byte ein Übertragungsfehler aufgetreten. Die Schritte 202, 204 sowie 206, 208 können Byte für Byte parallel durchgeführt werden, während der Block am Terminal empfangen wird.
- Werden in Schritt 210 keine Fehler erkannt, kann der nächste Block in Schritt 212 weiter bearbeitet werden. Werden Fehler erkannt, wird die Nummer im Paritätsfehlerzähler mit der Nummer im LRC-Fehlerzähler in Schritt 214 verglichen. In Schritt 216 wird bestimmt, ob die Nummer des Paritätsfehlerzählers und die Nummer des LRC-Fehlerzählers sich entsprechen. Entsprechen sie sich, wird in Schritt 218 bestimmt, ob beide Zähler dem Wert Eins entsprechen. Entsprechen beide Zähler dem Wert Eins, ist es wahrscheinlich, daß nur ein Fehler vorliegt, und zwar in dem Byte, welches den Paritätsfehler aufweist, und in dem Bit, bei welchem das Blockfehlerbyte einen Fehler anzeigt. Dieser Fehler kann durch das Abändern des Bits korrigiert werden. Diese Art der Fehlerkorrektur ist gut bekannt und kann erfolgen, indem das erkannte Byte mit dem Blockfehlerbyte dem ENTWEDER-ODER-Verfahren unterzogen wird, so wie es in Schritt 220 beschrieben wurde.
- Entspricht die Nummer des Paritätsfehlerzählers der Nummer des LRC-Fehlerzählers, ist sie jedoch größer als Eins, so ist es wahrscheinlich, daß einzelne Fehler in mehreren Bytes vorliegen. Das Blockfehlerbyte stellt Informationen darüber zur Verfügung, welche Bits der Bytes möglicherweise fehlerhaft sind. Die Informationen darüber, welches Byte einen bestimmten Bitfehler aufweist, ist jedoch unvollständig. In diesem Fall wird, gemäß dem System zum Ausgleich von Fehlern der vorliegenden Erfindung, jedes der erkannten Bits in den erkannten Bytes auf den Wert 1 abgeändert. Dies erfolgt durch logisches ODER- Verbinden eines jeden der Bytes, bei denen ein Paritätsfehler erkannt wurde, mit dem Blockfehlerbyte, und zwar gemäß der Darstellung in Schritt 222. Dieser Schritt führt dazu, daß ein Anzeigezeichen in jedem der verdächtigen Bits angebracht wird. Wie ersichtlich ist, gewährleistet dies, daß jedes der Bits, bei dem möglicherweise ein Übertragungsfehler aufgetreten ist, ein Anzeigezeichen aufweist, so daß keine Informationen über ungültige Karten verloren gehen.
- Zeigt die Bestimmung in Schritt 216, daß die Nummer des Paritätsfehlerzählers und die des LRC-Fehlerzählers nicht übereinstimmen, wird in Schritt 224 bestimmt, ob die Nummer des Paritätsfehlerzählers höher ist als die Nummer des LRC-Fehlerzählers. Ist dies der Fall, so bedeutet dies, daß mehrere Übertragungsfehler kombiniert auftraten und Informationen im Blockfehlerbyte gelöscht wurden. Es wird dann davon ausgegangen, daß nur die Daten über die Paritätsfehler zuverlässig sind. Auf der Grundlage der Paritätsfehler allein lassen sich zwar bestimmte Bytes als fehlerhaft erkennen, die Stelle dieser Fehler innerhalb des erkannten Bytes bleibt jedoch unbekannt. In diesem Fall erfolgt der Ausgleich, indem alle Bits in jedem der fehlerhaften Bytes auf 1 eingestellt werden, so wie es in Schritt 226 dargestellt wurde.
- Zeigt das Ergebnis aus Schritt 224, daß die Nummer des Paritätsfehlerzählers geringer ist als die des LRC-Fehlerzählers, so ist dies ein Anzeichen dafür, daß eine gerade Zahl an Fehlern (wahrscheinlich zwei) in einem Byte auftraten, wodurch die Paritätsprüfung abgebrochen wurde. In dem Fall sind keine eindeutigen Informationen darüber erhältlich, welche Bytes fehlerhaft sind. Geht man davon aus, daß das Blockfehlerbyte gültig ist, sind Informationen darüber erhältlich, an welchen Bitstellen Fehler aufgetreten sind, selbst wenn der Byteplatz unbekannt ist. Der mehrdeutige Fehler wird ausgeglichen, indem an den erkannten Bitstellen eines jedem Byte des Blocks Anzeigezeichen angebracht werden. Dies wird durch logische ODER-Verbindung des Blockfehlerbytes mit allen Datenbytes erreicht, so wie es in Schritt 228 dargestellt ist. Wenn alle Schritte zur Fehlerkorrektur oder zum Fehlerausgleich abgeschlossen sind, kann der nächste Block in Schritt 212 bearbeitet werden.
- Das in den Schritten 218, 222 und 224 erläuterte Konzept des Ausgleichs beruht auf der Hinzufügung von Anzeigezeichen in das Bitmuster. Zwar vermindert dies die Wahrscheinlichkeit, daß Informationen über ungültige Karten verloren gehen, die Anzahl der als ungültig erkannten gültigen Karte erhöht sich jedoch. Wie weiter oben festgestellt wurde, wird ein gewisser Prozentsatz an gültigen Karten, die als potentiell ungültig erkannt und zur Online-Zulassung weitergeleitet werden, nicht als Problem angesehen. Es wurde festgestellt, daß das hierin beschriebene Konzept zum Fehlerausgleich diesen Prozentsatz nicht über ein annebmbares Maß hinaus erhöht. Beispielsweise tritt der in Schritt 224 angesprochene Fehlertyp nur mit einer relativ geringen Wahrscheinlichkeit auf, so daß der Anstieg des Prozentsatzes gültiger Karten, die als ungültig erkannt werden, sich statistisch nur unbedeutend bemerkbar macht, selbst wenn in Schritt 224 der Tabelle eine bedeutende Anzahl an Anzeigezeichen hinzufügt wird.
- Des weiteren muß berücksichtigt werden, daß bestimmte, seltene Kombinationen von Übertragungsfehlern sich gegenseitig kompensieren und eine Erkennung völlig verhindern können. Die letztgenannte Eigenschaft ist bei Fehlerkorrekturverfahren, die zur Fehlererkennung keine Redundanzübertragungen anwenden, nicht ungewöhnlich. Da eine Aufgabe der vorliegenden Erfindung darin besteht, die zu übertragende Datenmenge zu verringern, sind Redundanzübertragungen nicht wünschenswert und zu vermeiden. Glücklicherweise sind diese Arten des Fehlerausgleichs nicht so üblich, daß die Anwendung von Fehlererkennungsverfahren gerechtfertigt wäre, die Redundanzübertragungen verwenden.
- Zusammenfassend läßt sich sagen, daß ein neues und verbessertes System zur Verteilung von Daten über ungültige Transaktionskarten zur Verfügung gestellt wird. Bei diesem System wird eine Haupttabelle erstellt, welche weniger als die gesamte Kontonummer der Karten enthält. Die Haupttabelle umfaßt mindestens ein Bitmuster mit Anzeigezeichen, welche den ungültigen Karten entsprechen. Die Stelle eines jeden Anzeigezeichens wird bestimmt, indem die Kontonummern einem Hashing-Verfahren unterzogen werden, so daß ein Sollwert erzeugt wird, der daraufhin als Adresse für die Hinzufügung eines Anzeigezeichens in das Bitmuster Anwendung findet. Sobald Anzeigezeichen in jedem der Bitmuster der Haupttabelle für jede der ungültigen Kontonummern plaziert wurden, wird die Haupttabelle an die Transaktionsterminals übertragen. Die Transaktionsterminals verwenden die in der Haupttabelle enthaltenen Daten, um anstehende Transaktionen zu überprüfen. Die Daten der Tabelle werden so angeordnet, daß bei Vorlage einer ungültigen Karte ein Signal erzeugt wird, welches die Weiterleitung der Transaktion zur weiteren Überprüfung an die zentrale Verarbeitungseinheit veranlaßt. In der bevorzugten Ausführung wird die Tabelle so angeordnet, daß die Wahrscheinlichkeit, eine gültige Karte als potentiell ungültig zu erkennen, weniger als zehn Prozent beträgt und sich vorzugsweise im Bereich von einem bis drei Prozent befindet. Somit wird als Folge dieses Systems nur ein geringer Prozentsatz der gültigen Transaktionen zur weiteren Überprüfung an die zentrale Verarbeitungseinheit weitergeleitet. Bei jeder Transaktion kann die Haupttabelle mit Daten über die Kontonummer der für den Einkauf vorgelegten Transaktionskarte ergänzt werden. Auf diese Weise wird jeder nochmalige Gebrauch zur zusätzlichen Bearbeitung weitergeleitet. Ein System zum Ausgleich von Datenübertragungsfehlern wird verwendet, um die Wahrscheinlichkeit zu verringern, daß Daten über ungültige Karten verloren gehen, wenn die Haupttabelle verteilt wird.
- longitudinal redundancy check byte = Längenredundanzkontrollbyte = Blockprüfzeichen
Claims (20)
1. Ein Verfahren zum Ausgleich von
Übertragungsfehlern in einer Datei, bei dem die besagte
Datei eine Liste von Transaktionskarten betreffenden
Informationen enthält und bei der jede in der Liste
aufgeführte Karte durch mindestens ein Anzeigezeichen
vertreten ist, umfassend die Schritte des Anbringens eines
Anzeigezeichens an jeder Stelle in der Datei, an der
möglicherweise ein Übertragungsfehler vorgekommen ist, so
daß Informationen über die in der Liste aufgeführten Karten
nicht verloren werden.
2. Ein Verfahren zum Betrieb eines
Transaktionsterminals zwecks Erleichterung der Offline-
Zulassung von auf der Verwendung von Transaktionskarten,
von denen jede eine Kontonummer hat, basierenden
Transaktionen, wobei Informationen hinsichtlich einer Liste
von Transaktionskarten in der Form einer Haupttabelle
empfangen werden, in der jede aufgeführte Karte durch
mindestens ein Anzeigezeichen vertreten ist, dadurch
gekennzeichnet, daß das Verfahren die Schritte des
Nachweisens von Übertragungsfehlern und des Ausgleichens
etwaiger Übergangsfehler durch Anbringung eines
Anzeigezeichens in der Tabelle an jeder der Stellen, an dem
möglicherweise ein Übertragungsfehler vorgekommen ist,
umfaßt, so daß aufgeführte Karten betreffende Informationen
nicht verloren werden.
3. Ein Verfahren nach Anspruch 2, bei dem die
besagte Haupttabelle in Datenblöcken angeordnet ist und
sich jeder Datenblock aus einer Mehrzahl von Bytes
zusammensetzt, wobei jedes Byte ein Paritätsprüfbit umfaßt,
und wobei jeder Block des weiteren ein durch logische
ENTWEDER-ODER-Verbindung der anderen Bytes in dem Block
erzeugtes Blockprüfzeichen umfaßt, und zwar erstreckt sich
das Verfahren auf logische ENTWEDER-ODER-Verbindung aller
der in jedem Block enthaltenden Bytes zwecks Erzeugung
eines Blockfehlerbytes und auf die Erfassung der Anzahl von
gemäß dem Inhalt des Blockfehlerbytes vorhandenen Fehlern
sowie auf die Bestimmung, wie viele und welche Bytes dem
Paritätsprüfbit gemäß mit einem Paritätsfehler behaftet
sind.
4. Ein Verfahren nach Anspruch 3, umfassend die
Schritte der Bestimmung, ob die Anzahl von Paritätsfehlern
in einem Block der Anzahl von Fehlern in dem entsprechenden
Blockfehlerbyte gleich ist und ob diese Anzahl höher ist
als eins, und, wenn dies der Fall ist, der Einfügung von
Anzeigezeichen in jedes Byte, bei dem erwiesen ist, daß es
einen Paritätsfehler enthält, wobei die besagten
Anzeigezeichen an Bitstellen eingefügt werden, an denen
gemäß dem Inhalt des besagten Blockfehlerbytes
erwiesenermaßen Fehler vorhanden sind.
5. Ein Verfahren nach Anspruch 3, umfassend die
Schritte des Bestimmens, ob die Anzahl von Paritätsfehlern
in einem Block höher ist als die Anzahl von gemäß dem
entsprechenden Blockfehlerbyte vorhandenen Fehlern, und,
wenn dies der Fall ist, des Einfügens von Anzeigezeichen in
alle der Bits eines mit einem Paritätsfehler behafteten
Bytes.
6. Ein Verfahren nach Anspruch 3 oder jedem damit in
Verbindung stehenden Anspruch, bei dem Anzeigezeichen in
alle der Bytes in dem Block eingefügt werden, und zwar an
den Bitstellen, an denen gemäß dem Inhalt des
Blockfehlerbytes erwiesenermaßen Fehler vorhanden sind.
7. Ein Verfahren nach einem der Ansprüche 3 bis 6,
bei dem der besagte Schritt des Einfügens von
Anzeigezeichen durch logisches ODER- Verbinden des
Blockfehlerbytes mit allen der mit einem Paritätsfehler
behafteten Bytes in dem Block bewirkt wird.
8. Ein Verfahren zum Betrieb eines
Transaktionsterminals nach Anspruch 2 oder jedem damit in
Verbindung stehenden Anspruch, bei dem die Haupttabelle
durch eine Mehrzahl von Bitmustern definiert und jede in
der Liste aufgeführte Karte durch ein Anzeigezeichen in
jedem der Bitmuster dargestellt ist.
9. Ein Verfahren zur Erleichterung der Offline-
Zulassung von Transaktionen in einem Transaktionsnetzwerk,
das eine zentrale Verarbeitungseinheit, eine Mehrzahl von
Ferntransaktionsterminals und eine Mehrzahl von
Transaktionskarten umfaßt, wobei zu jeder Karte eine
Kontonummer gehört, während in der zentralen
Verarbeitungseinheit eine Haupttabelle erzeugt wird, die
eine von einer Liste von Transaktionskarten abgeleitete
Datenmenge enthält, die geringer ist als die gesamte
Kontonummer jeder Karte, und wobei jede in der Liste
aufgeführte Karte durch mindestens ein Anzeigezeichen
vertreten ist, während die Haupttabelle für örtlichen
Zugriff durch die Ferntransaktionsterminals verteilt ist,
dadurch gekennzeichnet, daß das Verfahren die Schritte des
Nachweisens von Übertragungsfehlern und des Anbringens
eines Anzeigezeichens an möglicherweise fehlerbehafteten
Stellen in der Haupttabelle sowie des Vergleichens der
Kontonummer einer im Zusammenhang mit einer anstehenden
Transaktion dargebotenen Transaktionskarte mit den Daten in
der Haupttabelle und der Erzeugung eines auf dem Ergebnis
dieses Vergleiches basierenden Ausgangsignals umfaßt.
10. Ein Verfahren nach Anspruch 9, bei dem die
Haupttabelle durch eine Mehrzahl von Bitmustern definiert
ist, wobei jede in der Liste aufgeführte Karte durch ein
Anzeigezeichen in jedem der Bitmuster vertreten ist.
11. Ein Gerät zum Ausgleich von Übertragungsfehlern
in einer Datei, bei dem die besagte Datei eine Liste von
Transaktionskarten betreffenden Informationen enthält, bei
dem jede in der Liste aufgeführte Karte durch mindestens
ein Anzeigezeichen vertreten ist, umfassend Speichermittel
zum Speichern der besagten Datei; Mittel zum Nachweis von
Übertragungsfehlern; und Mittel zum Anbringen eines
Anzeigezeichens an jeder Stelle in der Datei, an der
möglicherweise ein Übertragungsfehler vorgekommen ist, so
daß Informationen über die in der Liste aufgeführten Karten
nicht verloren werden.
12. Ein Transaktionsterminal zwecks Erleichterung der
Offline-Zulassung von Transaktionen, basierend auf der
Verwendung von Transaktionskarten, von denen jede eine
Kontonummer hat, umfassend Speichermittel zum Speichern
einer Datei übertragener Daten, die Informationen über eine
Liste von Transaktionskarten in der Form einer Haupttabelle
enthält, in der jede aufgeführte Karte durch mindestens ein
Anzeigezeichen vertreten ist; sowie ein
Verarbeitungsmittel, dadurch gekennzeichnet, daß das
Verarbeitungsmittel Übertragungsfehler nachweist und auch
etwaige Übergangsfehler ausgleicht, indem es in der Tabelle
an jede der Stellen, an denen möglicherweise ein
Übertragungsfehler vorgekommen ist, ein Anzeigezeichen
anbringt, so daß Informationen über in der Liste
aufgeführte Karten nicht verloren werden.
13. Ein Terminal nach Anspruch 12, bei dem die
besagte Haupttabelle in Datenblöcken angeordnet ist, von
denen jeder aus einer Mehrzahl von Bytes besteht, und bei
dem jedes Byte ein Paritätsprüfbit umfaßt und bei dem jeder
Block des weiteren ein durch logische ENTWEDER-ODER-
Verbindung der anderen Bytes in dem Block erzeugtes
Blockprüfzeichen umfaßt, und bei dem die besagte
Verarbeitungseinheit des weiteren logische ENTWEDER-ODER-
Verbindung aller Bytes in jedem Block bewirkt, um ein
Blockfehlerbyte zu erzeugen und danach die Anzahl von
Fehlern gemäß dem Inhalt des Blockfehlerbytes zu erfassen,
wobei das besagte Verarbeitungsmittel des weiteren bewirkt,
das bestimmt wird, wie viele und welche Bytes gemäß dem
Paritätsprüfbit mit einem Paritätsfehler behaftet sind.
14. Ein Terminal nach Anspruch 13, bei dem das
Verarbeitungsmittel so wirkt, daß bestimmt wird, ob die
Anzahl der Paritätsfehler in einem Block der Anzahl von
Fehlern in dem entsprechenden Blockfehlerbyte gleich ist
und ob die besagte Anzahl höher ist als eins, und wenn dies
der Fall ist, in jedes Byte, von dem erwiesen ist, daß es
einen Paritätsfehler enthält, Anzeigezeichen einfügt, wobei
es die besagten Anzeigezeichen an Bitstellen einfügt, an
denen gemäß dem Inhalt des besagten Blockfehlerbytes
erwiesenermaßen Fehler vorhanden sind.
15. Ein Terminal nach Anspruch 13, bei dem das
Verarbeitungsmittel bewirkt, daß bestimmt wird, ob die
Anzahl von Paritätsfehlern in einem Block höher ist als die
Anzahl von Fehlern gemäß dem entsprechenden
Blockfehlerbyte, und, wenn dies der Fall ist, in alle der
Bits etwaiger mit einem Paritätsfehler behafteter Bytes
Anzeigezeichen einfügt.
16. Ein Terminal nach Anspruch 14 oder 15, bei dem
das besagte Verarbeitungsmittel bewirkt, daß bestimmt wird,
ob die Anzahl von Paritätsfehlern in einem Block geringer
ist als die Anzahl von Fehlern gemäß dem entsprechenden
Blockfehlerbyte, und, wenn dies der Fall ist, in alle der
Bytes in dem Block an den Bitstellen, die dem Inhalt des
Blockfehlerbytes gemäß erwiesenermaßen fehlerbehaftet sind,
Anzeigezeichen einfügt.
17. Ein Terminal nach Anspruch 15 oder jedem damit in
Verbindung stehenden Anspruch, bei dem die Anzeigezeichen
von dem Verarbeitungsmittel durch logische ODER-Verbindung
des Blockfehlerbytes mit allen der mit einem Paritätsfehler
behafteten Bytes in dem Block eingefügt werden.
18. Ein Transaktionsterminal nach Anspruch 12 oder
jedem damit in Verbindung stehenden Anspruch, bei dem die
gespeicherte Haupttabelle durch eine Mehrzahl von
Bitmustern definiert ist und bei dem jede in der Tabelle
aufgeführte Karte durch ein Anzeigezeichen in jedem
Bitmuster dargestellt ist.
19. Ein Transaktionsnetzwerk, umfassend eine zentrale
Verabeitungseinheit, eine Mehrzahl von
Ferntransaktionsterminals und eine Mehrzahl von
Transaktionskarten, zu jeder von denen eine Kontonummer
gehört, wobei das System Offline-Zulassung von
Transaktionen erleichtert, umfassend Mittel in der
zentralen Verarbeitungseinheit zur Erzeugung einer
Haupttabelle, die aus einer Liste von Transaktionskarten
abgeleitete Daten enthält, wobei die Datenmenge geringer
ist als die gesamte Kontonummer jeder Karte und wobei jede
in der Liste aufgeführte Karte durch mindestens ein
Anzeigezeichen vertreten ist, Mittel zur Verteilung der
Haupttabelle auf für örtlichen Zugriff durch die
Ferntransaktionsterminals geeignete Art, und Mittel an
jedem Terminal zum Empfang der einer zur Transaktion
dargebotenen Transaktionskarte entsprechenden Daten,
dadurch gekennzeichnet, daß in Verbindung mit den
Fernterminals betrieblich ein Verarbeitungsmittel
vorgesehen ist, um Übertragungsfehler nachzuweisen, wobei
das besagte Verarbeitungsmittel an möglicherweise
fehlerbehafteten Stellen in der Haupttabelle ein
Anzeigezeichen anbringt und das Verarbeitungsmittel auch
die Kontonummer einer im Zusammenhang mit einer anstehenden
Transaktion dargebotenen Transaktionskarte mit den Daten in
der Haupttabelle vergleicht und ein auf dem Ergebnis dieses
Vergleiches basierendes Ausgangssignal erzeugt.
20. Ein Transaktionsnetzwerk nach Anspruch 19, bei
dem die in der zentralen Verarbeitungseinheit gespeicherte
Haupttabelle durch eine Mehrzahl von Bitmustern definiert
ist und jede in der Liste aufgeführte Karte durch ein
Anzeigezeichen in jedem Bitmuster vertreten ist.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US07/295,662 US4908521A (en) | 1987-01-06 | 1989-01-10 | Transaction approval system |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69011877D1 DE69011877D1 (de) | 1994-10-06 |
DE69011877T2 true DE69011877T2 (de) | 1995-04-20 |
Family
ID=23138694
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69011877T Expired - Lifetime DE69011877T2 (de) | 1989-01-10 | 1990-01-09 | Transaktionszustimmungssystem. |
Country Status (9)
Country | Link |
---|---|
US (1) | US4908521A (de) |
EP (1) | EP0378349B1 (de) |
JP (1) | JP2714869B2 (de) |
AT (1) | ATE110868T1 (de) |
AU (1) | AU613574B2 (de) |
CA (1) | CA2007234C (de) |
DE (1) | DE69011877T2 (de) |
ES (1) | ES2063911T3 (de) |
NO (1) | NO300944B1 (de) |
Families Citing this family (103)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2633411B1 (fr) * | 1988-06-28 | 1991-09-27 | Schlumberger Ind Sa | Systeme de gestion de supports d'informations portatifs |
FR2660088B1 (fr) * | 1990-03-26 | 1992-06-26 | Arditti David | Dispositif de condensation de donnees numeriques. |
US5231569A (en) * | 1990-06-12 | 1993-07-27 | Sears Payment Systems, Inc. | Account transaction system |
US5285382A (en) * | 1991-02-25 | 1994-02-08 | Keyosk Corporation | System and method for processing credit and debit card validity and funds transactions from vending machines and similar terminals |
US5384449A (en) * | 1992-04-28 | 1995-01-24 | Visa International Service Association | Authorization matching system |
US5679938A (en) * | 1994-12-02 | 1997-10-21 | Telecheck International, Inc. | Methods and systems for interactive check authorizations |
KR0146624B1 (ko) * | 1994-12-19 | 1998-09-15 | 김광호 | 신용거래용 카드 및 이를 이용한 신용거래장치 및 방법 |
US5737423A (en) * | 1995-08-23 | 1998-04-07 | Pitney Bowes Inc. | Old modified smart card or similar apparatus having a remote inspection capability |
US6260026B1 (en) * | 1996-08-12 | 2001-07-10 | Kabushiki Kaisha Media Marketing Network | Credit card information management system |
JPH1097572A (ja) * | 1996-09-20 | 1998-04-14 | Media Maaketeingu Network:Kk | クレジットカードのカード情報管理方法とその装置 |
US7809642B1 (en) | 1998-06-22 | 2010-10-05 | Jpmorgan Chase Bank, N.A. | Debit purchasing of stored value card for use by and/or delivery to others |
US6615189B1 (en) | 1998-06-22 | 2003-09-02 | Bank One, Delaware, National Association | Debit purchasing of stored value card for use by and/or delivery to others |
WO2000008610A1 (en) * | 1998-08-03 | 2000-02-17 | Microsoft Corporation | Offline verification of integrated circuit card using hashed revocation list |
JP3638220B2 (ja) * | 1998-10-06 | 2005-04-13 | 株式会社日立製作所 | 不正電子記憶媒体の検出方法とそれを用いたicカードシステム |
US6032136A (en) | 1998-11-17 | 2000-02-29 | First Usa Bank, N.A. | Customer activated multi-value (CAM) card |
US7660763B1 (en) | 1998-11-17 | 2010-02-09 | Jpmorgan Chase Bank, N.A. | Customer activated multi-value (CAM) card |
US6882984B1 (en) | 1999-06-04 | 2005-04-19 | Bank One, Delaware, National Association | Credit instrument and system with automated payment of club, merchant, and service provider fees |
US8706630B2 (en) | 1999-08-19 | 2014-04-22 | E2Interactive, Inc. | System and method for securely authorizing and distributing stored-value card data |
US7249093B1 (en) | 1999-09-07 | 2007-07-24 | Rysix Holdings, Llc | Method of and system for making purchases over a computer network |
US7370004B1 (en) | 1999-11-15 | 2008-05-06 | The Chase Manhattan Bank | Personalized interactive network architecture |
US8793160B2 (en) | 1999-12-07 | 2014-07-29 | Steve Sorem | System and method for processing transactions |
US6615190B1 (en) * | 2000-02-09 | 2003-09-02 | Bank One, Delaware, National Association | Sponsor funded stored value card |
US6941279B1 (en) * | 2000-02-23 | 2005-09-06 | Banke One Corporation | Mutual fund card method and system |
US7113914B1 (en) | 2000-04-07 | 2006-09-26 | Jpmorgan Chase Bank, N.A. | Method and system for managing risks |
AU2001282935A1 (en) | 2000-08-01 | 2002-02-13 | First Usa Bank, N.A. | System and method for transponder-enabled account transactions |
US6631849B2 (en) | 2000-12-06 | 2003-10-14 | Bank One, Delaware, National Association | Selectable multi-purpose card |
US7433829B2 (en) | 2000-12-12 | 2008-10-07 | Jpmorgan Chase Bank, N.A. | System and method for managing global risk |
US6985873B2 (en) * | 2001-01-18 | 2006-01-10 | First Usa Bank, N.A. | System and method for administering a brokerage rebate card program |
US7313546B2 (en) | 2001-05-23 | 2007-12-25 | Jp Morgan Chase Bank, N.A. | System and method for currency selectable stored value instrument |
WO2003010701A1 (en) | 2001-07-24 | 2003-02-06 | First Usa Bank, N.A. | Multiple account card and transaction routing |
US7809641B2 (en) * | 2001-07-26 | 2010-10-05 | Jpmorgan Chase Bank, National Association | System and method for funding a collective account |
US8020754B2 (en) | 2001-08-13 | 2011-09-20 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
US7311244B1 (en) | 2001-08-13 | 2007-12-25 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
US6945453B1 (en) * | 2001-08-13 | 2005-09-20 | Bank One Delaware N.A. | System and method for funding a collective account by use of an electronic tag |
US8800857B1 (en) | 2001-08-13 | 2014-08-12 | Jpmorgan Chase Bank, N.A. | System and method for crediting loyalty program points and providing loyalty rewards by use of an electronic tag |
PT1442404E (pt) | 2001-09-24 | 2014-03-06 | E2Interactive Inc | Sistema e método para fornecer um serviço de comunicação |
CN1608267A (zh) * | 2001-11-26 | 2005-04-20 | 埃帕西菲克公司 | 用于资金转帐的系统和方法 |
US20100030675A1 (en) * | 2001-12-06 | 2010-02-04 | Hanan Christopher C | Payor focused business to business electronic invoice presentment and accounts payable reconciliation system and method |
US7512566B1 (en) | 2001-12-11 | 2009-03-31 | Jpmorgan Chase Bank, N.A. | System and method for using a stored value account having subaccount feature |
FR2834841B1 (fr) | 2002-01-17 | 2004-05-28 | France Telecom | Procede cryptographique de revocation a l'aide d'une carte a puce |
US7756896B1 (en) | 2002-03-11 | 2010-07-13 | Jp Morgan Chase Bank | System and method for multi-dimensional risk analysis |
US7899753B1 (en) | 2002-03-25 | 2011-03-01 | Jpmorgan Chase Bank, N.A | Systems and methods for time variable financial authentication |
US20180165441A1 (en) | 2002-03-25 | 2018-06-14 | Glenn Cobourn Everhart | Systems and methods for multifactor authentication |
US20040210498A1 (en) | 2002-03-29 | 2004-10-21 | Bank One, National Association | Method and system for performing purchase and other transactions using tokens with multiple chips |
WO2003083619A2 (en) | 2002-03-29 | 2003-10-09 | Bank One, Delaware, N.A. | System and process for performing purchase transaction using tokens |
US8239304B1 (en) | 2002-07-29 | 2012-08-07 | Jpmorgan Chase Bank, N.A. | Method and system for providing pre-approved targeted products |
US7809595B2 (en) | 2002-09-17 | 2010-10-05 | Jpmorgan Chase Bank, Na | System and method for managing risks associated with outside service providers |
US20040122736A1 (en) * | 2002-10-11 | 2004-06-24 | Bank One, Delaware, N.A. | System and method for granting promotional rewards to credit account holders |
WO2004077278A2 (en) * | 2003-02-27 | 2004-09-10 | Jp Morgan Chase & Co. | System and method for collecting data for risk events |
WO2004091170A2 (en) * | 2003-03-31 | 2004-10-21 | Visa U.S.A. Inc. | Method and system for secure authentication |
US20040220876A1 (en) * | 2003-05-02 | 2004-11-04 | Liu David J. | Systems and methods for services over a financial transaction platform |
US8306907B2 (en) | 2003-05-30 | 2012-11-06 | Jpmorgan Chase Bank N.A. | System and method for offering risk-based interest rates in a credit instrument |
US7086586B1 (en) | 2003-08-13 | 2006-08-08 | Bank One, Delaware, National Association | System and method for a card payment program providing mutual benefits to card issuers and cardholders based on financial performance |
US7953663B1 (en) | 2003-09-04 | 2011-05-31 | Jpmorgan Chase Bank, N.A. | System and method for financial instrument pre-qualification and offering |
US8239323B2 (en) | 2003-09-23 | 2012-08-07 | Jpmorgan Chase Bank, N.A. | Method and system for distribution of unactivated bank account cards |
US8655309B2 (en) * | 2003-11-14 | 2014-02-18 | E2Interactive, Inc. | Systems and methods for electronic device point-of-sale activation |
US7392222B1 (en) | 2004-08-03 | 2008-06-24 | Jpmorgan Chase Bank, N.A. | System and method for providing promotional pricing |
US20070288313A1 (en) * | 2006-06-09 | 2007-12-13 | Mark Brodson | E-Coupon System and Method |
US10248951B2 (en) | 2004-12-01 | 2019-04-02 | Metavante Corporation | E-coupon settlement and clearing process |
US8630898B1 (en) | 2005-02-22 | 2014-01-14 | Jpmorgan Chase Bank, N.A. | Stored value card provided with merchandise as rebate |
US7472822B2 (en) | 2005-03-23 | 2009-01-06 | E2Interactive, Inc. | Delivery of value identifiers using short message service (SMS) |
US7401731B1 (en) | 2005-05-27 | 2008-07-22 | Jpmorgan Chase Bank, Na | Method and system for implementing a card product with multiple customized relationships |
EP1913514A4 (de) * | 2005-07-15 | 2013-09-25 | Serve Virtual Entpr Inc | System und verfahren zum unmittelbaren ausgeben von transaktionskarten |
US20070027799A1 (en) * | 2005-07-29 | 2007-02-01 | Jpmorgan Chase Bank, N.A. | Universal line of credit having multiple financial product features |
US7784682B2 (en) | 2006-02-08 | 2010-08-31 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
US8408455B1 (en) | 2006-02-08 | 2013-04-02 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
US7753259B1 (en) | 2006-04-13 | 2010-07-13 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
US7505918B1 (en) | 2006-05-26 | 2009-03-17 | Jpmorgan Chase Bank | Method and system for managing risks |
US7698220B2 (en) | 2006-09-14 | 2010-04-13 | E2Interactive, Inc. | Virtual terminal for payment processing |
US20080203170A1 (en) * | 2007-02-28 | 2008-08-28 | Visa U.S.A. Inc. | Fraud prevention for transit fare collection |
US8386349B2 (en) | 2007-02-28 | 2013-02-26 | Visa U.S.A. Inc. | Verification of a portable consumer device in an offline environment |
US20080208681A1 (en) * | 2006-09-28 | 2008-08-28 | Ayman Hammad | Payment using a mobile device |
US8738485B2 (en) * | 2007-12-28 | 2014-05-27 | Visa U.S.A. Inc. | Contactless prepaid product for transit fare collection |
US8118223B2 (en) | 2006-09-28 | 2012-02-21 | Visa U.S.A. Inc. | Smart sign mobile transit fare payment |
US8346639B2 (en) | 2007-02-28 | 2013-01-01 | Visa U.S.A. Inc. | Authentication of a data card using a transit verification value |
US8523069B2 (en) | 2006-09-28 | 2013-09-03 | Visa U.S.A. Inc. | Mobile transit fare payment |
US7527208B2 (en) | 2006-12-04 | 2009-05-05 | Visa U.S.A. Inc. | Bank issued contactless payment card used in transit fare collection |
US7866551B2 (en) * | 2007-02-15 | 2011-01-11 | Visa U.S.A. Inc. | Dynamic payment device characteristics |
US8676642B1 (en) | 2007-07-05 | 2014-03-18 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to financial account holders |
US8676672B2 (en) * | 2007-08-23 | 2014-03-18 | E2Interactive, Inc. | Systems and methods for electronic delivery of stored value |
US8417601B1 (en) | 2007-10-18 | 2013-04-09 | Jpmorgan Chase Bank, N.A. | Variable rate payment card |
US20100027786A1 (en) * | 2008-02-14 | 2010-02-04 | Patrick Faith | Dynamic encryption authentication |
US8725611B1 (en) | 2008-02-21 | 2014-05-13 | Jpmorgan Chase Bank, N.A. | System and method for providing borrowing schemes |
USD582977S1 (en) | 2008-02-21 | 2008-12-16 | Jpmorgan Chase Bank, N.A. | Transaction device |
US9208485B2 (en) | 2008-03-24 | 2015-12-08 | American Express Travel Related Services Company, Inc. | System and method for facilitating online transactions |
US10008067B2 (en) | 2008-06-16 | 2018-06-26 | Visa U.S.A. Inc. | System and method for authorizing financial transactions with online merchants |
US20110137740A1 (en) | 2009-12-04 | 2011-06-09 | Ashmit Bhattacharya | Processing value-ascertainable items |
US20110153441A1 (en) * | 2009-12-23 | 2011-06-23 | Merrill Brooks Smith | Systems and Methods for Authorizing Use of Validly Sold Merchandise |
US9846872B2 (en) | 2010-04-06 | 2017-12-19 | American Express Travel Related Services Company, Inc. | Secure exchange of indicia of value and associated information |
US10068287B2 (en) | 2010-06-11 | 2018-09-04 | David A. Nelsen | Systems and methods to manage and control use of a virtual card |
US9031869B2 (en) | 2010-10-13 | 2015-05-12 | Gift Card Impressions, LLC | Method and system for generating a teaser video associated with a personalized gift |
US9483786B2 (en) | 2011-10-13 | 2016-11-01 | Gift Card Impressions, LLC | Gift card ordering system and method |
US11978031B2 (en) | 2010-12-14 | 2024-05-07 | E2Interactive, Inc. | Systems and methods that create a pseudo prescription from transaction data generated during a point of sale purchase at a front of a store |
US9075741B2 (en) * | 2011-12-16 | 2015-07-07 | Intel Corporation | Dynamic error handling using parity and redundant rows |
US10417677B2 (en) | 2012-01-30 | 2019-09-17 | Gift Card Impressions, LLC | Group video generating system |
US9565911B2 (en) | 2013-02-15 | 2017-02-14 | Gift Card Impressions, LLC | Gift card presentation devices |
US11219288B2 (en) | 2013-02-15 | 2022-01-11 | E2Interactive, Inc. | Gift card box with slanted tray and slit |
US10217107B2 (en) | 2013-05-02 | 2019-02-26 | Gift Card Impressions, LLC | Stored value card kiosk system and method |
US10262346B2 (en) | 2014-04-30 | 2019-04-16 | Gift Card Impressions, Inc. | System and method for a merchant onsite personalization gifting platform |
CN107948123B (zh) | 2016-10-12 | 2021-01-12 | 钉钉控股(开曼)有限公司 | 文件传输方法及装置 |
US10954049B2 (en) | 2017-12-12 | 2021-03-23 | E2Interactive, Inc. | Viscous liquid vessel for gifting |
EP3503063B1 (de) * | 2017-12-22 | 2020-04-29 | Deutsche Telekom AG | Automatisierungssteuerungssystem zur steuerung einer sicherheitsfunktion einer entfernten maschine |
US12020309B2 (en) | 2018-05-18 | 2024-06-25 | E2Interactive, Inc. | Augmented reality gifting on a mobile device |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3852571A (en) * | 1970-05-18 | 1974-12-03 | Hempstead Bank | System of transferral of funds |
SE417760B (sv) * | 1979-05-15 | 1981-04-06 | Ellemtel Utvecklings Ab | Sett att vid dataoverforing mellan en sendande dator och en mottagande dator overvaka fel och anordning for genomforande av settet |
FR2471000B1 (fr) * | 1979-11-30 | 1985-06-28 | Dassault Electronique | Procede et dispositif de controle du nombre de tentatives d'acces a une memoire electronique, notamment celle d'un circuit integre d'un objet comme une carte de credit ou une carte d'achat |
US4346474A (en) * | 1980-07-03 | 1982-08-24 | International Business Machines Corporation | Even-odd parity checking for synchronous data transmission |
FR2497617B1 (fr) * | 1981-01-07 | 1989-08-18 | Transac Develop Transactions A | Procede et dispositif de securite pour communication tripartie de donnees confidentielles |
FR2514592A1 (fr) * | 1981-10-12 | 1983-04-15 | Widmer Michel | Procede et dispositif de consultation de fichiers de donnees et/ou de transactions bancaires, preserves des fraudes grace a un procede de communication code par variable aleatoire |
US4485300A (en) * | 1982-03-18 | 1984-11-27 | Visa U.S.A., Inc. | Loss control system |
DE3223034C2 (de) * | 1982-06-19 | 1986-12-11 | Mico Datensysteme GmbH, 7252 Weil der Stadt | Verfahren zur Erkennung von gefälschten Datenträgern |
GB2124806B (en) * | 1982-08-06 | 1986-05-14 | Sony Corp | Method of correcting errors in binary data |
US4558211A (en) * | 1983-05-23 | 1985-12-10 | Imperial Oil Limited | Transaction terminal system |
GB2183376B (en) * | 1985-02-06 | 1988-11-02 | Colin Philip Westlake | Data distribution system |
FR2584516B1 (fr) * | 1985-07-02 | 1988-05-13 | Smh Alcatel | Procede et systeme de controle pour machines a affranchir |
NL8600217A (nl) * | 1986-01-30 | 1987-08-17 | Philips Nv | Dataverwerkende inrichting bevattende een geheugeninrichting voorzien van een coincidentieschakeling die in een foutherkennings- en een coincidentiemode schakelbaar is. |
JPS62262175A (ja) * | 1986-05-08 | 1987-11-14 | Omron Tateisi Electronics Co | 取引処理装置 |
IE64070B1 (en) * | 1986-07-25 | 1995-07-12 | Trintech Ltd | A credit card verifier |
US4822985A (en) * | 1987-01-06 | 1989-04-18 | Visa International Service Association | Transaction approval system |
JPS63168734A (ja) * | 1987-01-07 | 1988-07-12 | Fuji Sangyo Kk | デジタル計算機のエラ−の検出・訂正方法 |
-
1989
- 1989-01-10 US US07/295,662 patent/US4908521A/en not_active Expired - Lifetime
- 1989-12-21 AU AU47083/89A patent/AU613574B2/en not_active Expired
-
1990
- 1990-01-05 CA CA002007234A patent/CA2007234C/en not_active Expired - Lifetime
- 1990-01-09 AT AT90300209T patent/ATE110868T1/de not_active IP Right Cessation
- 1990-01-09 ES ES90300209T patent/ES2063911T3/es not_active Expired - Lifetime
- 1990-01-09 EP EP90300209A patent/EP0378349B1/de not_active Expired - Lifetime
- 1990-01-09 NO NO900103A patent/NO300944B1/no unknown
- 1990-01-09 DE DE69011877T patent/DE69011877T2/de not_active Expired - Lifetime
- 1990-01-09 JP JP116190A patent/JP2714869B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
DE69011877D1 (de) | 1994-10-06 |
JPH02226362A (ja) | 1990-09-07 |
CA2007234A1 (en) | 1990-07-10 |
ATE110868T1 (de) | 1994-09-15 |
US4908521A (en) | 1990-03-13 |
CA2007234C (en) | 1994-05-24 |
AU4708389A (en) | 1990-07-19 |
EP0378349A3 (de) | 1991-05-15 |
JP2714869B2 (ja) | 1998-02-16 |
EP0378349B1 (de) | 1994-08-31 |
EP0378349A2 (de) | 1990-07-18 |
AU613574B2 (en) | 1991-08-01 |
ES2063911T3 (es) | 1995-01-16 |
NO300944B1 (no) | 1997-08-18 |
NO900103D0 (no) | 1990-01-09 |
NO900103L (no) | 1990-07-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69011877T2 (de) | Transaktionszustimmungssystem. | |
DE69022610T2 (de) | Verfahren zum Chiffrieren von übertragenen Daten, das einen Einheitsschlüssel anwendet. | |
DE69415053T2 (de) | Verfahren und Vorrichtung zur Kreditkartenechtheitsprüfung | |
DE3103514C2 (de) | Verfahren und Vorrichtung zum Sichern von Transaktionen | |
DE19539801C2 (de) | Überwachung von Transaktionen mit Chipkarten | |
DE3044463A1 (de) | Verfahren und vorrichtung zum codieren einer karte | |
DE69019037T2 (de) | Mehrebenen-Sicherheitsvorrichtung und -verfahren mit persönlichem Schlüssel. | |
DE3700663C2 (de) | ||
DE2645564C2 (de) | Automatischer Geldausgeber | |
DE69033017T2 (de) | Verfahren zur Beglaubigung einer Mikroprozessorkarte und System zu seiner Durchführung | |
DE69014817T2 (de) | System zum Bezahlen oder Transferieren von Informationen mit einer als Geldbörse dienenden elektronischen Speicherkarte. | |
EP0030381B1 (de) | Verfahren und Vorrichtung zur Erzeugung und späteren Kontrolle von gegen Nachahmung, Verfälschung und Missbrauch abgesicherten Dokumenten und Dokument zu dessen Durchführung | |
DE2916454A1 (de) | Verfahren und schaltungsanordnung zum sichern von datenuebertragungen | |
DE4142964C2 (de) | Datenaustauschsystem mit Überprüfung der Vorrichtung auf Authentisierungsstatus | |
EP1374011A2 (de) | Verfahren zum absichern einer transaktion auf einem computernetzwerk | |
EP0805607B1 (de) | Verfahren zum Zugriff auf zumindest einen Teil der Daten einer Mikroprozessorkarte | |
DE2901521A1 (de) | Persoenliches identifizierungssystem | |
CH629902A5 (de) | Verfahren zur identitaetsueberpruefung. | |
WO1999008230A2 (de) | Verfahren zur echtheitsprüfung eines datenträgers | |
EP1062641A1 (de) | Verfahren und vorrichtung zur prüfung eines biometrischen merkmals | |
DE69736283T2 (de) | Zugangskontrollsystem zu einer funktion, in der die chiffrierung mehrere dynamische veränderliche enthält | |
DE69729685T2 (de) | Verfahren zur Verdeckung eines Geheimcodes in einer Rechnerbeglaubigungsvorrichtung | |
EP1185960A2 (de) | Verfahren und vorrichtung zum abspeichern und wiederauffinden von pin-codes | |
DE69825410T2 (de) | Verfahren zur Kompression von digitalen Zertifikaten zur Verwendung in einer Chipkarte | |
EP1374189A2 (de) | Verfahren zum sichern von digitalen waren beim verkauf über ein computernetzwerk |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition |