DE60317169T2 - Authentifizierungsanordnung und verfahren zur verwendung mit finanztransaktionen - Google Patents

Authentifizierungsanordnung und verfahren zur verwendung mit finanztransaktionen Download PDF

Info

Publication number
DE60317169T2
DE60317169T2 DE60317169T DE60317169T DE60317169T2 DE 60317169 T2 DE60317169 T2 DE 60317169T2 DE 60317169 T DE60317169 T DE 60317169T DE 60317169 T DE60317169 T DE 60317169T DE 60317169 T2 DE60317169 T2 DE 60317169T2
Authority
DE
Germany
Prior art keywords
der
cardholder
ucaf
card
data
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
Application number
DE60317169T
Other languages
English (en)
Other versions
DE60317169D1 (de
Inventor
Fikret Ates
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard Europe SA
Original Assignee
Mastercard Europe SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mastercard Europe SA filed Critical Mastercard Europe SA
Application granted granted Critical
Publication of DE60317169D1 publication Critical patent/DE60317169D1/de
Publication of DE60317169T2 publication Critical patent/DE60317169T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—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 together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • 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/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—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 together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025—Identification of user by a PIN code

Description

  • Die vorliegende Erfindung betrifft allgemein ein Bezahlungssystem und ein Verfahren, bei denen ein Computernetzwerk, wie beispielsweise ein Datenfernnetzwerk, verwendet wird. Spezieller betrifft der vorliegende Erfindung ein Zugriffsberechtigungsprüfungssystem, das Teil eines Bezahlungssystems ist, und ein entsprechendes Verfahren, das über ein offenes Netzwerk, wie beispielsweise das Internet, unter Verwendung einer IC-Karte durchgeführt wird. Die vorliegende Erfindung betrifft auch eine Software zur Realisierung des Zugriffsberechtigungsprüfungssystems und -verfahrens.
  • Technischer Hintergrund
  • Das Dokument US-A-6 038 551 offenbart eine Chipkarte, die eine Hash-Information erzeugt, wobei die Karte die Hash-Information an den Kartenleser sendet. Der Kartenleser ist mit dem Client verbunden, der die Hash-Information an einen Server weiterleitet.
  • Es ist bekannt, Käufe im Internet unter Verwendung eines Benutzerterminals oder einer Hauptzugangseinrichtung, wie beispielsweise eines Personalcomputers, durchzuführen. Eine Architektur und ein System, das eine Smart-Card zur Bezahlung der Waren und/oder Dienstleistungen, die Online über das Internet erworben werden, verwendet, ist aus US 6 282 522 bekannt. Ein Clientserver am Clientterminal steuert den Dialog mit einem Kunden und stellt eine Verbindung zu einem Kartenleser her, der die Smart-Card des Kunden annimmt. Ein Bezahlungsserver im Internet weist einen Computer und Terminals auf, die die Transaktion und den Datenspeicher bearbeiten. Auch über das Internet angeschlossen ist ein Händlerserver, der die Waren und/oder Dienstleistungen bewirbt, die durch einen Händler zum Verkauf auf einer Webseite angeboten werden. Der Händler schließt einen Vertrag mit einem Erfasser, Smart-Card-Bezahlungen für Waren und/oder Dienstleistungen, die über das Internet gekauft werden, zu akzeptieren.
  • Ein Kunde benutzt seine Smart-Card am Clientterminal, um Waren und/oder Dienstleistungen von dem entfernten Händlerserver zu kaufen. Das Internet schafft die Funktionalität des Routings zwischen dem Clientterminal, dem Händlerserver und dem Bezahlungsserver zur Verfügung.
  • 1 ist eine schematische Darstellung eines Benutzerterminals oder einer Hauptzugangseinrichtung 1, beispielsweise für den Zugang zum Internet und zum Browsen im Internet. Typischerweise weist das Terminal 1 eine zentrale Einheit (CPU) 2 auf, die mit einem Speicher 4 und Eingangs-/Ausgangs-Einrichtungen (I/O-Einrichtungen) 6 über einen Bus 3 für eine Zweiwegekommunikation verbunden ist. Die I/O-Einrichtungen 6 können eine Tastatur zum Eingeben von Daten und ein Bildschirm, wie beispielsweise eine visuelle Anzeigeeinheit, beispielsweise ein Flüssigkristall-Display (LCD-Display) oder ein Leuchtdiodendisplay (LED-Display), eine CTR zum Anzeigen des Fortschritts der Transaktion und/oder zum Anzeigen von Nachrichten oder Aufforderungen, sein. Eine der I/O-Einrichtungen 6 kann ein Kartenleser 7 sein, mit dem eine IC-Karte (ICC) 5 gelesen werden kann, wenn sie in einen Aufnahmeschlitz des Lesers 7 eingeführt wird. Alternativ kann der Kartenleser 7 eine autonome Einrichtung zum Lesen der ICC 5 sein. Eine der I/O-Einrichtungen 6 kann auch ein Modem 9 für den Zugang zum Internet über einen Internetserviceprovider (ISP), beispielsweise ein 56K-, ein ADSL-, ein Funk- oder ein Kabelmodem, sein. Die tatsächliche Form des Terminals kann sehr variieren und kann einen Prozessor, wie beispielsweise einen Mikroprozessor der PentiumTM-Familie, geliefert von der Intel Corp., USA, aufweisen. Des Weiteren ist es nicht notwendig, dass sich das Terminal 1 insgesamt an einer Stelle befindet, die verschiedenen Teile des Terminals, wie beispielsweise der Kartenleser 7, die I/O-Einrichtungen, wie beispielsweise die Tastatur und das Anzeigegerät, das Modem und der Prozessor können an unterschiedlichen Stellen angeordnet und über Kabel, über eine Funkverbindung oder Ähnliches verbunden oder Teil eines lokalen Netzes oder über Telekommunikationsnetzwerke verbunden sein.
  • 2 ist eine schematische Darstellung einer IC-Karte (ICC) 5. Die ICC 5 weist mindestens einen Eingangs-/Ausgangs-Anschluss (I/O-Port) 10 und einen Permanent speicher, beispielsweise einen nicht-flüchtigen Speicher, auf, der beispielsweise durch ein EEPROM 15, das an dem I/O-Anschluss 10 über einen Bus 17 angeschlossen ist, oder durch einen batteriegestützten Direktzugriffsspeicher (RAM) zur Verfügung gestellt sein kann. Der I/O-Anschluss 10 kann für die Kommunikation mit dem Terminal 1 über den Kartenleser 7 verwendet werden. Die IC-Karte ist eine Karte, in die ein oder mehrere IC's eingesetzt sind, um mindestens Speicherfunktionen durchzuführen. Gegebenenfalls kann die ICC 5 eine unabhängige, tragbare intelligente Karte sein und einen Lese-/Schreib-Arbeitsspeicher, beispielsweise einen flüchtigen Speicher, der durch ein RAM 14 gebildet ist, und einen zentralen Prozessor 12 sowie alle nötigen Schaltungen, damit die ICC 5 als Mikroprozessor arbeitet, beispielsweise einen Lesespeicher 13 zum Speichern eines Codes, einen Sequenzer 16 und Verbindungen mit dem Kartenleser 7 zur Aufnahme der Spannungsversorgungen Vss und VDD, einen Rückstellschalter für den Prozessor 12 und eine Uhr CLK für den Sequenzer 16, aufweisen. Die ICC 5 kann als Bankkarte, Kreditkarte, Debetkarte, elektronische Geldbörse, Gesundheitskarte, SIMM-Karte oder ähnliches verwendet werden. Weitere Merkmale des Microcontrollers können gegeben sein, sind jedoch nicht dargestellt, wie beispielsweise eine Uhr, ein Zufallszahlengenerator, eine Unterbrechungssteuerung, eine Steuerungslogik, eine Ladepumpe, Stromverbindungen und Schnittstellenkontakte, die gestatten, dass die Karte mit der Außenwelt kommunizieren kann. Beispielsweise ist ein Verschlüsselungsmodul (nicht dargestellt) ein optionales Hardwaremodul, das zur Durchführung einer Vielzahl von Verschlüsselungsalgorithmen verwendet wird.
  • E-Commerce-Händler stellen einen Webserver mit webseitigem Zugang zu Waren oder Dienstleistungen zur Verfügung, der von Benutzerterminals aus erreicht werden kann, wie in 1 dargestellt ist, üblicherweise über Webseiten, und diese Waren und Dienstleistungen können unter Verwendung von Karten, wie beispielsweise der ICC 5 von 2, gekauft werden. Viele E-Commerce-Händler unterstützen die Bildung eines Profils für den Kartenbesitzer. Die Bildung eines Profils für den Kartenbesitzer besteht aus dem Sammeln von Informationen über den Kartenbesitzer und die Verwendung dieser Daten zur Rationalisierung des den Kartenbesitzer betreffenden Checkout-Verfahrens. Die gesammelten Informationen enthalten typischerweise die Rechnungsad resse, die Versandadresse, Einzelheiten der Bezahlungsweise (beispielsweise Kartennummer und Ablaufdatum), die E-Mail-Adresse und bevorzugte Verbindungen. Die meisten Händler unterstützen auch ein nicht-profiliertes Checkout. Entweder unterstützen in diesem Fall die Händler keine Datenbank für das Profil des Kartenbesitzers, oder hat der Kartenbesitzer die Wahl getroffen, kein Profil in Verbindung mit diesem Händler zu schaffen. In jedem Fall macht das nicht-profilierte Checkout-Verfahren es erforderlich, dass der Kartenbesitzer alle Details zum Versand, zur Rechnungsstellung und zur Bezahlung manuell zur Verfügung stellt. Die E-Commerce-Händler haben eine Vielzahl von Online-Checkout-Verfahren in dem Versuch implementiert, den Online-Einkauf und die Online-Einkaufserfahrungen für die Kartenbesitzer effizienter zu gestalten. Eine Anzahl von Händlern hat ein Express-Checkout-Verfahren (3) implementiert, das dazu bestimmt ist, dem Kartenbesitzer ein beschleunigtes Einkaufsverfahren zur Verfügung zu stellen, indem vollständig Gebrauch von den in einer vom Händler geführten Profildatenbank gespeicherten Daten des Kartenbesitzers und Bezahlungseinzelheiten gemacht wird. Nach dem Suchen und Auswählen eines bestimmten Warenpostens, oder Warenposten, wählt der Kartenbesitzer die Express-Checkout-Option. Der Händler ruft das Profil des Kartenbesitzers ab und bietet eine Seite auf dem Benutzerterminal an, die die Auftragseinzelheiten und die Bezahlungseinzelheiten des Kartenbesitzers dargestellt. Der Kartenbesitzer kann diese Einzelheiten überprüfen und den Auftrag einreichen/bestätigen.
  • Einzelclick-Checkout-Verfahren sind durch viele Händler implementiert worden (siehe 4). Das Einzelclick-Checkout-Verfahren dient dazu, dem Kartenbesitzer das effizienteste Online-Einkaufsverfahren zur Verfügung zu stellen, das verfügbar ist, indem vollständig Gebrauch von den in einer vom Händler geführten Profildatenbank gespeicherten Daten des Kartenbesitzers und dessen Bezahlungseinzelheiten gemacht wird. Nach dem Suchen und Auswählen eines bestimmten Warenpostens wählt der Kartenbesitzer die Einzelclick-Auftragsoption, die im Allgemeinen auf allen Seiten verfügbar ist, wo die Einzelheiten und der Preis eines Warenpostens beschrieben sind. Üblicherweise kann der Kunde entweder den Warenposten seinem "Einkaufskorb" hinzufügen oder mit einem "Einzelclick" für diesen einen Auftrag erteilen und bezahlen. Der Händler kombi niert die Auftragseinzelheiten und die Bezahlungseinzelheiten des Kartenbesitzers, um einen Auftrag zu schaffen, der dann auf einer Seite dem Kartenbesitzer bestätigt wird. Die Kunden können nach dem anfänglichen Einzelclick über eine Form einer Verwaltungs-/Statusseite für den Kunden üblicherweise Aufträge stornieren, ändern oder sogar mehrere Einzelclick-Aufträge kombinieren.
  • Die meisten Händler unterstützen den Standard-Checkout, der üblicherweise ein Verfahren zum Bestätigen der Auftragseinzelheiten und zum Erheben der Bezahlungseinzelheiten des Kartenbesitzers ist (siehe 5). Das Standard-Checkout-Verfahren muss den von nicht-profilierten Kartenbesitzern verwendet werden, da die Bezahlungseinzelheiten erhoben werden müssen. Jedoch wählen sogar profilierte Kartenbesitzer häufig die Verwendung des Standard-Checkouts, wenn sie beispielsweise andere Einzelheiten zur Bezahlung und zur Person zu verwenden wünschen.
  • Nach dem Suchen und Auswählen eines besonderen Warenpostens, oder Warenposten, wählt der Kartenbesitzer die Standard-Checkout-Option. Der Händler präsentiert eine Seite, die Auftragseinzelheiten zeigt und Bezahlungseinzelheiten des Kartenbesitzers abruft. Der Kartenbesitzer kann die Einzelheiten des Auftrags überprüfen, die Einzelheiten seiner Bezahlung und nötigenfalls andere relevante Informationen zur Person zur Verfügung stellen und den Auftrag einreichen/bestätigen. In einigen Fällen kann diese Abfrageseite, in der Einzelheiten des Auftrags und Einzelheiten der Einreichung/Bezahlung kombiniert sind, in zwei Seiten aufgeteilt werden, wie in 5 dargestellt ist.
  • Gegenwärtig stellen Ferntransaktionen ein erhebliches Transaktionsvolumen aller finanziellen Transaktionen dar. Eine Erläuterung verschiedener finanzieller Transaktionssysteme kann in Büchern gefunden werden, wie beispielsweise "Secure Eletronic Commerce", W. Ford und M. S. Baum, Prentice Hall, 1997; "Digital Cash" von P. Wagner, Academic Press, 2. Auflage, 1997; "Designing Systems for Internet Commerce", G. W. Treese und L. C. Stewart, Addison-Wesley, 1998. Aus der Perspektive eine Risikos sind diese Transaktionen häufig nicht garantiert, und stellen sie daher eine Risiko für den Erfasser/Händler dar. Die Sicherheit solcher finanziellen Überweisungen im Internet sollte hoch sein, aber auch einen bequemen Einkauf ohne komplexe Prozeduren gestatten. Es gibt eine fortbestehende Notwendigkeit, die Einfachheit und Sicherheit finanzieller Transaktionen im Internet zu verbessern.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung erfüllt die Aufgaben der Zugriffsberechtigungsprüfung des Kartenbesitzers im Umfeld von finanziellen Transaktionen, da sie herkömmlicherweise unter Rücküberweisungen bzw. Ausgleichsbuchungen leiden, weil nicht bewiesen werden kann, dass die finanzielle Transaktion tatsächlich von dem Kartenbesitzer genehmigt ist. Sie bietet einen Mechanismus zur Sicherung des Internetkanals durch eine strenge Zugriffsberechtigungsprüfung des Kartenbesitzers am Ort der wechselseitigen Handlung (POI) und zur Schaffung eines expliziten Beweises sowohl des Vorhandenseins der Karte als auch, dass die Transaktion auf den Kartenbesitzer zurückgeht. Der Erfindung liegt eine Anzahl von Aufgaben zu Grunde, die mindestens eine der nachfolgenden umfassen:
    • – Verringerung der Rücküberweisungen bzw. Ausgleichsbuchungen aus Gründen von nicht durch den Kartenbesitzer genehmigten Transaktionen.
    • – Unterstützung von sowohl Haben- als auch Soll-Transaktionen.
    • – Minimierung von Systemstörungen beim Erfasser.
    • – Sicherstellung einer schnellen Annahme durch den Händler.
    • – Unterstützung der Zugriffsberechtigungsprüfung für echte Kontonummern, virtuelle Konten und Pseudo-Kontonummern.
  • Unter einem Aspekt stellt die vorliegende Erfindung ein computergestütztes Zugriffsberechtigungsprüfungsschema zur Verfügung, insbesondere stellt die vorliegende Erfindung ein computerimplementiertes Verfahren und System zur Durchführung von finanziellen Transaktionen über das Internet zur Verfügung.
  • Die vorliegende Erfindung stellt unter einem Aspekt eine Zugriffsberechtigungsprüfungsanordnung zur Verwendung in einem Netzwerkbezahlungssystem für die Durchführung eines Verkaufs einer Handelsware über ein Netzwerk unter Verwendung einer IC-Karte zur Verfügung, wobei die Zugriffsberechtigungsprüfungsanordnung umfasst: einen Händlerserver, der mit dem Netzwerk in Verbindung steht, wobei der Händlerserver mindestens einen ersten Warenposten der Handelsware für den Verkauf aufweist; ein Clientterminal, das mit dem Netzwerk in Verbindung steht, wobei das Clientterminal eine Ausgabeeinrichtung zur Überprüfung des ersten Warenpostens für den Verkauf und eine Eingabeeinrichtung zur Auslösung einer Einkaufstransaktion zum Einkauf des ersten Warenpostens für den Verkauf aufweist, wobei das Clientterminal zur Bildung einer Einkaufsnachricht unter Verwendung einer eine Händleridentifikationskennung betreffenden Information und einer Finanztransaktionsinformation dient, die von dem Händlerserver erhalten wird; einen Kartenleser zur Verbindung mit der IC-Karte, wobei der Kartenleser mit dem Netzwerk nicht verbunden ist; wobei das Clientterminal Mittel zur Erzeugung einer Abfragenachricht aufweist, wobei diese Abfragenachricht aus der Information betreffend die Händleridentifikationskennung und eine Kontonummer erzeugt wird; ein Mittel zum Empfang der Abfragenachricht an dem Kartenleser und zur Erzeugung eines Wertes aus der Abfragenachricht. Der Wert ist vorzugsweise ein Wert, der durch die ICC nicht vorhersagbar ist. Die ICC weist ein Mittel zur Erzeugung einet kryptografischen Nachricht aus mindestens einem Teil dieses Wertes auf, und der Kartenleser weist ein Mittel zur Erzeugung eines Zugriffsberechtigungsprüfungsbeweises aus einem ausgewählten Bereich des Kryptogramms auf, wobei das Kryptogramm in dem Kartenleser einer Maske ausgesetzt wird, wobei die Maske definiert, welche Bits des Kryptogramms den ausgewählten Bereich des Kryptogramms bilden, wobei der ausgewählte Bereich zur Verifizierung des Kryptogramms nach einer Neuberechnung des Kryptogramms benötigt wird. Das Clientterminal weist Mittel zur Übertragung des Zugriffsberechtigungsprüfungsbeweises in einer Nachricht über das Internet auf. Die Übertragung kann zu dem Händlerserver erfolgen. Das Netzwerk kann einen Transaktionsgenehmigungsserver zum Genehmigen von finanziellen Transaktionen aufweisen, und die Übertragung erfolgt zu diesem Genehmigungsserver. Das Mittel zur Erzeugung einer Abfragenachricht kann dazu dienen, die Abfragenachricht aus der Information betreffend die Händleridentifikationskennung, eine Kontonummer und einen Einkaufsbetrag und/oder eine Einkaufswährung zu erzeugen.
  • Das Mittel zur Übertragung des Zugriffsberechtigungsprüfungsbeweises kann dazu dienen, den Zugriffsberechtigungsprüfungsbeweis an den Händlerserver zu übertragen, und der Händlerserver dient dazu, mindestens einen Teil des Zugriffsberechtigungsprüfungsbeweises an den Transaktionsgenehmigungsserver mit einer Kaufinformation in einer Genehmigungsabfragenachricht zu übertragen. Das Mittel zur Erzeugung einer Abfragenachricht kann dazu dienen, die Händleridentifikationskennung und die Kontonummer und gegebenenfalls einen Einkaufsbetrag und/oder eine Einkaufswährung zu verknüpfen. Das Mittel zur Erzeugung einer Abfragenachricht kann dazu dienen, die Verknüpfung der Händleridentifikationskennung und der Kontonummer und gegebenenfalls eines Einkaufsbetrags und/oder einer Einkaufswährung zu komprimieren, wobei die Komprimierung die Anwendung einer Hash-Funktion sein kann. Der Genehmigungsserver kann mindestens einen Teil des Zugriffsberechtigungsprüfungsbeweises neu aufbauen und die neu aufgebaute Nachricht mit mindestens einem Teil des Zugriffsberechtigungsprüfungsbeweises in der Genehmigungsabfragenachricht vergleichen, die von dem Händlerserver übermittelt wird. Der Transaktionsgenehmigungsserver kann dazu dienen, eine Genehmigungsnachricht an den Händlerserver zu senden, wenn der Vergleich positiv ist. Die IC-Karte kann einen Speicher und einen ersten In diesem Speicher gespeicherten Datengegenstand aufweisen, und das Mittel zur Erzeugung eines Zugriffsberechtigungsprüfungsbeweises aus einem ausgewählten Bereich der kryptografischen Nachricht kann dazu dienen, einen Teil des Bereichs der kryptografischen Nachricht in Übereinstimmung mit dem ersten Datengegenstand auszuwählen. Ein zweiter Datengegenstand kann in dem Speicher gespeichert sein, und das Mittel zur Erzeugung einer Abfragenachricht kann einen Einkaufsbetrag und/oder eine Einkaufswährung bei der Erzeugung der Abfragenachricht in Übereinstimmung mit dem zweiten Datengegenstand aufweisen.
  • Unter einem weiteren Aspekt stellt die vorliegende Erfindung ein Verfahren zur Zugriffsberechtigungsprüfung als Teil der Durchführung eines Verkaufs von Handelsware über ein Netzwerk unter Verwendung einer IC-Karte zur Verfügung, wobei das Verfahren umfasst: Herstellen einer Verbindung zwischen einem Händlerserver und einem Clientterminal über das Netzwerk, wobei der Händlerserver mindestens einen ersten Warenposten der Handelsware für den Verkauf aufweist; Überprüfen des ersten Warenpostens für den Verkauf auf dem Clientterminal, Auslösen einer Einkaufstransaktion zum Einkauf des ersten Warenpostens für den Verkauf und Bilden bzw. Aufbauen einer Einkaufsnachricht unter Verwendung einer eine Händleridentifikationskennung betreffenden Information und einer Finanztransaktionsinformation, die von dem Händlerserver erhalten wird; Erzeugen einer Abfragenachricht an dem Clientterminal aus der Information betreffend die Händleridentifikationskennung und eine Kontonummer; Empfangen der Abfragenachricht an einem Kartenleser und Erzeugen eines Wertes aus der Abfragenachricht, wobei der Kartenleser mit dem Netzwerk nicht verbunden ist; Herstellen einer Verbindung zwischen der IC-Karte und dem Kartenleser und Erzeugen einer kryptografischen Nachricht aus mindestens einem Teil des Wertes; Erzeugen eines Zugriffsberechtigungsprüfungsbeweises an dem Kartenleser aus einem ausgewählten Bereich des Kryptogramms, mindestens einem Teil der kryptografischen Nachricht; Aussetzen des Kryptogramms in dem Kartenleser gegenüber einer Maske, wobei die Maske definiert, welche Bits des Kryptogramms den ausgewählten Bereich des Kryptogramms bilden, wobei der ausgewählte Bereich zur Verifizierung des Kryptogramms nach einer Neuberechnung des Kryptogramms benötigt wird; und Übertragen des Zugriffsberechtigungsprüfungsbeweises in einer Nachricht von dem Clientterminal zur Übertragung über das Netzwerk zu einem Genehmigungsserver. Das Erzeugen einer Abfragenachricht kann das Erzeugen der Abfragenachricht aus der Information betreffend die Händleridentifikationskennung, eine Kontonummer und einen Einkaufsbetrag und/oder eine Einkaufswährung umfassen. Die Übertragung des Zugriffsberechtigungsprüfungsbeweises kann die Übertragung des Zugriffsberechtigungsprüfungsbeweises an den Händlerserver und die Übertragung mindestens eines Teils des Zugriffsüberprüfungsberechtigungs-beweises von dem Händlerserver an den Transaktionsgenehmigungsserver mit einer Einkaufsinformation in einer Genehmigungsabfragenachricht aufweisen. Das Erzeugen einer Abfragenachricht kann das Verknüpfen der Händleridentifikationskennung und der Kontonummer und gegebenenfalls eines Einkaufsbetrags und/oder einer Einkaufswährung umfassen. Das Erzeugen einer Abfragenachricht kann das Komprimieren der Verknüpfung der Händleridentifikationskennung und der Kontonummer und gegebenenfalls eines Einkaufsbetrags und/oder einer Einkaufswährung umfassen, beispielsweise durch die Anwendung einer Hash-Funktion. Das Verfahren kann den erneuten Aufbau mindestens eines Teils des Zugriffsberechtigungsprüfungsbeweises an dem Genehmigungsserver und das Vergleichen der erneut aufgebauten Nachricht mit mindestens dem Teil des Zugriffsberechtigungsprüfungsbeweises in der Genehmigungsabfragenachricht, die von dem Händlerserver aus übertragen worden ist, gefolgt von der Übermittlung einer Genehmigungsnachricht an den Händlerserver aufweisen, wenn der Vergleich positiv ist. Die IC-Karte kann einen Speicher und einen in diesem Speicher gespeicherten ersten Datengegenstand aufweisen, wobei das Verfahren ferner umfasst das Erzeugen eines Zugriffsberechtigungsprüfungsbeweises aus einem ausgewählten Bereich der kryptografischen Nachricht durch Auswählen eines Teils des Bereichs der kryptografischen Nachricht in Übereinstimmung mit dem ersten Datengegenstand.
  • Das Verfahren kann ferner das Erzeugen einer Abfragenachricht aus einem Einkaufsbetrag und/oder einer Einkaufswährung in Übereinstimmung mit dem zweiten Datengegenstand umfassen.
  • Die vorliegende Erfindung kann sich mit allen Kanälen und Transaktionsarten für eine Ferntransaktion durch die Bildung von vier Bildungsblöcken, die die Basis für eine Garantie in jedem Umfeld darstellen sollen, befassen:
    • a) eine CAM-Funktion, d. h. ein Nachweis, dass die Karte bzw. das Konto nicht ist,
    • b) eine CVM-Funktion, d. h. ein Nachweis, dass der Kartenbesitzer echt ist,
    • c) Beweis der Transaktionsgenehmigung durch den Aussteller,
    • d) eine Beschreibung des Umfeldes einer Transaktion.
  • Die Definition und Implementierung einer Infrastruktur unter einem Aspekt der vorliegenden Erfindung realisiert garantierte Transaktionen im Umfeld des E-Commerce. Eine erste Kategorie von für solche Dienstleistungen geeigneten Transaktionen sind Bezahlungen im E-Commerce, sowohl im internetgestützten E-Commerce als auch im funkgestützten Handel (M-Commerce). Da das Modell ein generisches Modell ist, kann es durchweg über mehrere Kanäle verwendet und auf weitere Umfelder ausgedehnt werden, zu denen postalische Aufträge oder telefonische Aufträge gehören. Indirekte Vorteile des Kartenbesitzers sind:
    • – Verringerung des eingegangenen Risikos,
    • – mehr Händler, die zum Geschäft über das Internet bereit sind,
    • – der vorstehende Sachverhalt führt zu einem weiteren Gewinn des E-Commerce mit der Folge eines angeregten geschäftlichen Wettbewerbs,
    • – Verringerung/Überwindung von Erörterungen über echte "not-me" Transaktionen mit folglich verringerten Auseinandersetzungen.
  • Die Erfindung wird jetzt unter Bezugnahme auf die nachfolgend angegebenen Zeichnungen beschrieben.
  • Kurze Beschreibung der dargestellten Ausführungsformen
  • 1 zeigt eine Hauptzugangseinrichtung, die mit der vorliegenden Erfindung verwendet werden kann.
  • 2 zeigt eine IC-Karte, die mit der vorliegenden Erfindung verwendet werden kann.
  • 3 zeigt einen bekannten Ablauf einer Express-Checkout-Seite.
  • 4 zeigt einen bekannten Ablauf eines Einzelclick-Verfahrens.
  • 5 zeigt einen bekannten Ablauf eines Standard-Verfahrens.
  • 6zeigt, wie Bytes beschrieben werden.
  • 7 zeigt ein Zugriffsberechtigungsprüfungssystem gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 8 zeigt einen detaillierteren Ablauf eines Zugriffsberechtigungsprüfungssystems gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 9 zeigt eine IIPB-Datenstruktur gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 10 zeigt eine UCAF-Datenstruktur gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 11 zeigt das Codieren von AAV bei einer Ausführungsform der vorliegenden Erfindung.
  • 12 zeigt "Füllfeld einstellen auf 0" gegenüber "Daten einstellen auf 0".
  • 13 zeigt den Ablauf eines Verfahrens zur Bildung einer PCR-Abfrage gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 14 zeigt 8 Digits aus einer Abfrage, die bis zu 27 Bits von UN ergibt, dem aus der Abfragenachricht erzeugten Wert, gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 15 zeigt eine Bit-Extraktion und -Kompression gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 16 zeigt ein Beispiel der Umwandlung von benötigten Datenbits der Basis 2 zu einem Basis 10 Beweis.
  • 17 zeigt einen Überblick über ein Ablaufverfahren gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 18 zeigt ein Ablaufverfahren von dem Abschluss eines Einkaufs bis zur Annahme durch einen Händler gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 19 zeigt einen modifizierten Ablauf einer Express-Checkout-Seite gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 20 zeigt einen modifizierten Ablauf eines Einzelclick-Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 21 zeigt einen modifizierten Ablauf eines Standard-Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 22 zeigt einen Ablauf des KartenaAktivierungsverfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 23 zeigt ein Ablaufverfahren eines PCR-ICC-Austauschs gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 24 zeigt ein Ablaufverfahren von der Kartenaktivierung bis zur Beweiserzeugung gemäß einer Ausführungsform.
  • Beschreibung der erläuternden Ausführungsformen
  • Die vorliegende Erfindung betrifft ein ICC-Zugriffsberechtigungsprüfungsprogramm, beispielsweise für E-Commerce-Anwendungen unter Verwendung eines persönlichen Kartenlesers (PCR), der Zugriffsberechtigungsprüfungsbeweise für den Transport an den Aussteller in einem universellen Kartenbesitzer-Zugriffsberechtigungsprüfungsfeld (UCAF) erzeugt. Bei der Gestaltung des Beweiserzeugungsschemas ist die Bedienungsfreundlichkeit dem Kartenbesitzer – im Wege der Verkürzung der Datenerfordernisse auf ihr bloßes Minimum unter Verwendung von Prüfdigits etc. – zur Verfügung gestellt worden. Unter einem Aspekt weist die vorliegende Erfindung eine funktionelle Architektur eines Schemas auf, das dazu verwendet wird, eine ICC-basierte Zugriffsberechtigungsprüfung unter Verwendung eines persönlichen Kartenlesers für internetbasierte E-Commerce-Transaktionen über das UCAF zu erreichen.
  • Die Ausdrücke Kunde und Kartenbesitzer sind für die Zwecke dieser Erfindung gegenseitig austauschbar, jedoch wird durchweg üblicherweise der Ausdruck Kartenbesitzer verwendet. Dies bedeutet nicht streng genommen die Personen, für die die Karte ausgestellt worden ist, sondern bezieht sich vielmehr auf eine Person, für die im Besitz sowohl der Karte als auch des Zugriffsberechtigungsprüfungsmechanismus dieser Karte ist, beispielsweise einer PIN als Beispiel. In der Gesamtheit des Textes und der Figuren bezieht sich die Bezugnahme auf einen Händler, einen Erfasser und einen Aussteller auf jeweilige Server in Verbindung mit dem Internet, wenn der Eingabe von Daten oder den Übergabe von Nachrichten, Web-Seiten etc. betroffen ist.
  • Alle Tabellen, Diagramme und Bezugnahmen im Text auf nummerierte Bytes, beispielsweise "Byte 1 wird übertragen", sind solche in der Art von Bezugnahmen auf Bytes innerhalb eines größeren Blocks, wobei vom Anfang des Blocks/Unterblocks aus gezählt wird. Die Bytes werden nicht wie bei Werten als am höchsten bzw. am niedrigsten signifikante Bytes nummeriert. Dies führt gelegentlich zu dem signifikantesten Byte eines numerischen Datenelements, beispielsweise bei dem Anwendungstransaktionszähler, das als Byte 1 bezeichnet wird, und zu dem am wenigsten signifikanten Byte, das als Byte 2 bezeichnet wird. Andererseits werden Bits in der umgekehrten Weise identifiziert, wobei das signifikanteste Bit das "erste" Bit ist und als Bit 8 bezeichnet wird, während das am wenigsten signifikante Bit das "letzte" Bit ist und als Bit 1 bezeichnet wird. Siehe 6. In Fällen, in denen eine Zahl angegeben/dargestellt ist und die Basis dieser Zahl nicht beschrieben ist, wird angenommen, dass sie eine Dezimalzahl (Basis 10) ist. In Fällen, in denen eine Zahl mit einem vorausgehenden "0x" angegeben/dargestellt ist, wird angenommen, dass sie eine hexadezimale Zahl (Basis 16) ist.
  • Wenn Beispiele zur Unterstützung der Darstellung und Klarstellung des Textes der Beschreibung verwendet werden und es irgendwelche Diskrepanzen zwischen der Beschreibung und dem gibt, was aus dem zugehörigen Beispiel ersichtlich ist, sollte stets die Beschreibung als Bezugnahme berücksichtigt werden.
  • Terminologie
    • AAC
      Anwendungs-Zugriffsberechtigungsprüfungskryptogramm
      AAV
      Kontoinhaber-Zugriffsberechtigungsprüfungswert
      AC
      Zugriffsberechtigungsprüfungskryptogramm
      AFL
      Anwendungs-Filepositionsanzeiger der identifiziert, welche Aufzeichnungen wo auf der ICC verfügbar sind,
      AID
      Anwendungs-Identifikationkennung, der hex-String, der eine gegebene Anwendung auf der ICC identifiziert.
      AIP
      Anwendungs-Austauschprofil, es gibt die Fähigkeiten der ICC an, spezifische Funktionen zu unterstützen.
      APDU
      Anwendungs-Datenverabeitungseinheit, die zwischen ICC und externer Anwendung versandten Nachrichten
      ARQC
      Anwendungs-Anforderungskryptogramm
      ATC
      Anwendungs-Transaktionszähler
      BCD
      Binärcodierte Dezimalzahl
      Big-Endian
      Codierungsart, bei der ein Wert zuerst mit seinem am signifikantesten Byte gespeichert wird, gefolgt von jedem nachfolgenden Byte, wobei das am wenigsten signifikante Byte zuletzt gespeichert wird.
      CAP
      Chip-Zugriffsberechtigungsprüfungsprogramm
      CDOL
      Kartenrisiko-Management-Datenobjektliste
      CID
      Kryptogramm-Informationsdaten
      CSN
      Karten-Folgenummer
      CVC2
      Karten-Bestätigungscode
      CVM
      Kartenbesitzer-Bestätigungsverfahren, das Verfahren, das einen Kartenbesitzer in Hinblick auf die Karte bestätigt.
      DAC
      dynamisches Zugriffsberechtigungsprüfungskryptogramm
      DOM
      Dokumentenobjektmodel, die Programmansicht der gegenwärtigen HTML-Seite, die von einem Browser an ein Plug-In-Teil geliefert wird.
      HHD
      ein Handgerät, beispielsweise ein Kartenleser
      EMV
      Europay MasterCard Visa
      IA
      Schnittstellenanwendung
      IAD
      Aussteller-Anwendungsdaten
      IAF
      Internet-Zugriffsberechtigungsprüfungs-Flagsignal, das erste Byte von IIPD
      ICC
      IC-Karte, auch bekannt als Chipkarte oder Smart Card
      IIPB
      systemspezifisches Aussteller-Internet-Bitmuster, identifiziert Bits, die an den Aussteller gesandt werden müssen, um das AC zu bestätigen, wobei das AC das Kryptogramm ist.
      IIPD
      systemspezifische Aussteller-Internet-Daten, systemspezifische Daten, die durch den Aussteller mit Bezug auf die Berechnung eines Kryptogramms für die Zwecke von internetgestützten Transaktionen verwendet werden.
      ITV
      Interaktives Fernsehen
      LATC
      Unterer (Byte von) Anwendungs-Transaktionszähler
      Little-Endian
      Codierungsart, bei der ein Wert zuerst mit seinem am wenigsten bedeutenden Byte gespeichert wird, gefolgt von jedem nachfolgenden Byte, wobei das signifikanteste Byte zuletzt gespeichert wird.
      MAC
      Nachrichten-Zugriffsberechtigungsprüfungscode, eine kryptografische Signatur, berechnet über Datenelementen in einer Nachricht, sowohl um den Ursprung einer Nachricht zu beweisen als auch um die Feststellung zu gestatten, ob diese Datenelemente modifiziert worden sind.
      MCD
      Haupt-Kartenbesitzereinrichtung, die Einrichtung, mit der das Suchen und/oder eine Auftragserteilung und/oder eine Bezahlung durchgeführt wird.
      Nibble
      Ein halbes Byte, d. h. 4 Bits
      P1
      Parameter 1 einer APDU, der den an die ICC gesandten Befehl wirksam anpasst.
      PAN
      primäre Kontonummer
      PC
      Personalcomputer
      PCR
      Persönlicher Kartenleser
      Cardholder IA
      Kartenbesitzer-Schnittstellenanwendung, die Anwendung, die auf der MCD läuft und eine Schnittstellenverbindung zwischen dem Anforderer der Zugriffsberechtigungsprüfung, dem Kartenbesitzer und dem PCR herstellt.
      PDa
      Persönlicher digitaler Assistent
      PDOL
      Datenobjektliste der Verarbeitungsoptionen, die Liste der Verarbeitungsoptionen, die für das Terminal verfügbar sind bzw. durch das Terminal (d. h. PCR) unterstützt werden..
      PIN
      Persönliche Identifikationsnummer
      SFA
      Anwendung für eine sichere Bezahlung
      TLV
      Längenwert für eine Identifizierungkennung
      UCAF
      Universelles Kartenbesitzer-Zugriffsberechtigungsprüfungsfeld
      UN
      nicht-vorhersagbare Zahl
  • Das Zugriffsberechtigungsprüfungsschema gemäß der vorliegenden Erfindung ist eine Verwendung des universellen Kartenbesitzer-Zugriffsberechtigungsprüfungsfelds (UCAF). Dieses Schema wird nur aus Zweckmäßigkeit als Chip-UCAF bezeichnet. Der Ausdruck selbst beschränkt die vorliegende Erfindung nicht. Die vorliegende Erfindung stellt sichere Zugriffsberechtigungsprüfungsverfahren zur Verfügung, die die UCAF-Infrastruktur ausnutzen. Sie umfasst die folgenden Elemente:
    • – vom Aussteller zur Verfügung gestellte Chip-UCAF-freigegebene Schnittstellenanwendung;
    • – Chip-UCAF-Erzeugung des Kontoinhaber-Zugriffsberechtigungsprüfungswerts (AAV);
    • – Karteninhaber-Zugriffsberechtigungsprüfung;
    • – Händlerdarstellung, Sammlung und Verarbeitung von AAV-Daten in dem UCAF-Zugriffsberechtigungsprüfungsdatenfeld; Akzeptieren des Erfassers und Verarbeitung von AAV-Daten wie in dem UCAF enthalten;
    • – Entwicklung des Bankennetzwerks, um eine Unterstützung des Transports der AAV-Daten in dem UCAF-Zugriffsberechtigungsprüfungsdatenfeld zu umfassen;
    • – Genehmigungsunterstützung der AAV-Daten in dem UCAF-Zugriffsberechtigungsprüfungsdatenfeld.
  • Folgendes ist während der Lebenszeit einer Chip-UCAF-Zugriffsberechtigungsprüfungs-Transaktion involviert:
    • – Kartenbesitzer – der Kartenbesitzer initiiert die Transaktion und ist für die Eingabe von Daten in sowohl die Bezahlung-Webseiten des Händlers, die Kartenbesitzer-Schnittstellenanwendung als auch den persönlichen Kartenleser verantwortlich.
    • – Händler – der Händler liefert, beispielsweise von einem Händlerserver, der mit dem Internet in Verbindung steht, die Daten, die für den Start der Zugriffsberechtigungsprüfungs-Transaktion notwendig sind, und empfängt die sich ergebenden UCAF-Daten, um sie, über ihren Erfasser, an den Kartenaussteller zur Genehmigung weiterzugeben.
    • – Kartenbesitzer-Schnittstellenanwendung – die Kartenbesitzer-IA stellt die relevanten Daten fest, die von dem Händler geliefert werden, und führt mit dem Kartenbesitzer direkt oder indirekt, über den Kartenbesitzer, einen Dialog mit de persönlichen Kartenleser. Die Kartenbesitzer-IA schafft das AAV und das UCAF und versieht die Seite des Händlers mit den geeigneten Daten. Beispielsweise kann die Kartenbesitzer-IA als Teil eines Internetbrowsers an der Haupt-Kartenbesitzer-Einrichtung (MCD) arbeiten, die für den Zugang zum Händler im Internet verwendet wird.
    • – Persönlicher Kartenleser – der PCR führt einen Dialog mit dem Kartenbesitzer und der ICC, um einen Zugriffsberechtigungsprüfungsbeweis zu schaffen, der indirekt an den Aussteller weitergeführt wird.
    • – ICC – die Chipkarte prüft die Zugriffsberechtigung des Kartenbesitzers durch Verwendung der Bestätigung der aufgerufenen PIN und erzeugt ein geeignetes Kryptogramm auf der Grundlage der von den dem PCR gelieferten Daten.
    • – Erfasser – der Erfasser akzeptiert die formatierten UCAF-Daten eines Händlers, beispielsweise an einem Erfasserserver, und schickt sie mit der Angabe der Verwendung und des Vorhandenseins der UCAF-Daten an die ausstellende Bank über ein geeignetes Telekommunikationsnetzwerk. Mastercard ist ein Erfasser.
    • – Aussteller – der Kartenaussteller teilt PCR's denjenigen Kartenbesitzern zu, die an dem Chip-UCAF-Schema teilnehmen. Der Aussteller unterhält eine Ausstellerserverplattform, die mit dem Internet in Verbindung steht. Erfindungsgemäß bestätigt gemäß den Regeln des Ausstellers der Ausstellerserver den Zugriffsberechtigungsprüfungsbeweis, der in das UCAF codiert ist und in der Genehmiganforderung durch einen Erfasser übermittelt wird,.
  • Unter einem Aspekt stellt die vorliegende Erfindung eine Zugriffsberechtigungsprüfung für E-Commerce-Bezahlungsdienste zur Verfügung. Der Anwesenheitsstatus des Kartenbesitzers ist für Transaktionen vorgesehen, die für den Aussteller online sind. Der klassische Genehmigungsweg über das bestehende Netzwerk des Bezahlungsschemas kann verwendet werden. Ein persönlicher Kartenleser wird verwendet, der entweder als eigenständige Einrichtung oder angeschlossen an/integriert mit der Zugriffseinrichtung des Kartenbesitzers (beispielsweise Laptop, PC, Taschen-PC, Handy-Kleincomputer-Kombination, Palm-Pilot, PDA) arbeitet. Der Leser weist vorzugsweise eine Anzeige und einen Tastenblock auf, um einen beschränkten Dialog des Kartenbesitzers zu gestatten. Die Spezifikationen für den persönlichen Kartenleser sollten vorzugsweise eine maximal mögliche Anzahl von unterschiedlichen Kartenimplementierungen gestatten, bei gleichzeitiger Zurverfügungstellung einer leichten Benutzung durch den Kartenbesitzer. Der persönliche Kartenleser sollte vorzugsweise das Ergebnis der PIN-Bestätigung anzeigen können und für nicht-angeschlossene Einrichtungen einen Token haben, der von Hand an der Haupt-Kartenbesitzereinrichtung eingegeben werden muss. Der persönliche Kartenleser muss in der Lage sein, von der ICC eine Angabe von dem Aussteller der Daten zu erhalten, die an diesen übertragen werden müssen, damit die ICC-Signatur auf Richtigkeit geprüft werden kann. Der persönliche Kartenleser sollte vorzugsweise in der Lage sein, von der ICC eine Angabe von dem Aussteller zu erhalten, ob der Betrag und die Währung der Transaktion in dem erzeugten Token einzusetzen sind oder nicht. Wenn eine solche Angabe gemacht wird, muss der Leser in der Lage sein, dass dem Kartenbesitzer zu gestatten, den Betrag und den zugehörigen numerischen Währungscode einzugeben. Wenn der Transaktionsbetrag durch den Kartenbesitzer einzugeben ist, erfolgt dies vorzugsweise in einem "natürlichen" Format, d. h. einschließlich der Dezimalanzeige, jedoch umgewandelt in Währungseinheiten der ISO 4217-Basis um die Kartensignatur einzubeziehen. Jeder solche Betrag, der von dem Kartenbesitzer eingegeben oder anderweitig dem Leser mitgeteilt wird, sollte vorzugsweise zusammen mit einem zugehörigen Währungssymbol mit 3 Zeichen, beispielsweise EUR, vor der Genehmigung über die PIN durch den Kartenbesitzer angezeigt werden.
  • Das UCAF(das universelle Kartenbesitzer-Zugriffsberechtigungsprüfungsfeld)-Datenfeld ist ein Mehrzweck-Datentransportbereich in einer digitalen Nachricht, um eine Übermittlung von Zugriffsberechtigungsprüfungsdaten an einen Aussteller von einem Erfasser aus über irgendeine Form eines Telekommunikationsnetzes zu gestatten. Beispielsweise kann das UCAF ein 32-Zeichen-Feld (24 Bytes-1 Steuerbyte und 23 Datenbytes – diese sind Basis 64 codiert, um zu 32 Zeichen zu werden) mit einer flexiblen Datenstruktur sein, die darauf abgestimmt sein kann, die Bedürfnisse einer Vielzahl von Ausstellersicherheits- und Zugriffsberechtigungsprüfungs-Erfordernissen zu unterstützen. Beispielsweise kann das ISO 8583 Datenelement 48, Unter-Element 43, in Hinblick darauf bestimmt sein, das UCAF zu enthalten. Der Ausdruck UCAF umfasst auch die Bezugnahme auf die Schnittstelle, die in Hinblick darauf definiert ist, Daten zwischen dem Händler und der MCD hin und her zu senden, d. h. die Feldnamen in der Spezifikation für jeden gegebenen Kanal.
  • Der Kontoinhaberzugriffsberechtigungsprüfungswert (AAV) ist der Ausdruck, mit dem ein Teil (beispielsweise 23 Bytes) der UCAF-anwendungsspezifischen Daten bezeichnet ist. Jede UCAF-Anwendung ist für die Bestimmung der geeigneten Struktur für seinen AAV verantwortlich. Jeder Fall einer Implementierung einer gegebenen UCAF-Anwendung muss die AAV-Struktur der Anwendung konsequent verwenden, d. h. das AAV-Format ist für eine gegebene UCAF-Anwendung standardisiert.
  • Um das Schema der Chip-UCAF-Kartenbesitzer-Zugriffsberechtigungsprüfung zu verwenden, muss der Kartenbesitzer eine geeignete ICC-Bezahlungskarte und einen persönlichen Kartenleser besitzen. Der PCR wird dem Kartenbesitzer von seinem Kartenaussteller geliefert, der registriert, dass dieser Kartenbesitzer einen PCR besitzt und in dem Schema der Chip-UCAF-Kartenbesitzer-Zugriffsberechtigungsprüfung "registriert" ist. Die von dem Händler gelieferten UCAF-Transaktionsdaten werden zu Anzeigezwecken verwendet, und einige von ihnen werden bei der Erzeugung einer eine Transaktion betreffenden PCR-Abfrage verwendet. Es gibt keine zusätzliche Verarbeitung, die der Händler an den AAV-Daten innerhalb der UCAF-Antwort durchführen muss. Dies wird dem Händler über den Wert des UCAF-Steuerbytes angezeigt, der auf den Wert für das Chip-UCAF eingestellt ist. Die Kartenbesitzer-Schnittstellenanwendung (Kartenbesitzer-IA) schafft einen Dialog zwischen den Anforderungen der Zugriffsberechtigungsprüfung (Händler), dem Kartenbesitzer und dem PCR. Die Schnittstellenanwendung bietet dem Kartenbesitzer ein sicheres Erscheinungsbild des gegenwärtigen UCAF-Schemas. Sie ist dafür verantwortlich die Transaktionsdaten dem Kartenbesitzer anzuzeigen, die an den PCR übertragene Anforderung zu erzeugen, die PCR-Tokenantwort bzw. Beweisantwort zu empfangen, das UCAF zu formatieren und die Rückdaten für den gegebenen Kanal zu verbreiten. Die Kartenbesitzer-IA weist einen Mindestsatz von Erfordernissen auf, die erfüllt werden müssen, um eine Chip-UCAF-Transaktion durchzuführen. Sie kann auch eine zusätzliche Funktionalität hinzufügen, wie beispielsweise das intelligente Ausfüllen eines Formulars, das Verfolgen/Protokollieren einer Quittung, die Integration mit einer persönlichen Finanzsoftware etc.
  • Die Haupt-Kartenbesitzereinrichtung (MCD) ist die Einrichtung, an der das Suchen/Einkaufen wahrscheinlich ausgeführt wird, und für den Umfang dieser Spezifikation bzw. dieses Schemas wird das Bezahlungs- und das Zugriffsberechtigungsprüfungsverfahren zuverlässig ausgeführt. Die vorliegende Erfindung wird unter Bezugnahme auf eine PC-Einrichtung an einer Plattform im Umfeld eines Internet-Browsers beschrieben. Die Kartenbesitzer-IA muss in diesem Umfeld betrieben werden.
  • Der persönliche Kartenleser (PCR) ist eine Einrichtung, die für Zwecke von E-Commerce-Transaktionen eine PIN-Eingabe und PIN-Bestätigung, beispielsweise offline, und eine Zugriffsberechtigungsprüfung der Transaktion-Kontext-Daten durch eine Kartenbesitzer-ICC, die in die Einrichtung eingeführt wird, möglich macht. Ein nicht-angeschlossener PCR kann bei der vorliegenden Erfindung verwendet werden, d. h. eine Einrichtung, die keine gegenständliche/elektrische Verbindung mit irgendeinem externen System aufweist und deren Schnittstelle für Daten in die und aus der Einrichtung der Kartenbesitzer über einen Tastenblock und eine Anzeige ist. Persönliche Kartenleser mit einer Verbindung anderer Art können ebenfalls verwendet werden.
  • Eine nicht-angeschlossene PCR-Einrichtung besitzt keine gegenständliche/elektrische Verbindung mit irgendeinem externen System. Die Schnittstelle für Daten in die und aus der Einrichtung ist ein Tastenblock und eine Anzeige zum Dialog mit einer Person, d. h. dem Kartenbesitzer. Bei der Verwendung einer nicht-angeschlossenen Einrichtung muss der Kartenbesitzer manuell zusätzlich zu einer PIN bestimmte Daten, die der PCR verwendet, in Verbindung mit der Karte eingeben, um einen Zugriffsberechtigungsprüfungswert zu erzeugen. Der Zugriffsberechtigungsprüfungswert wird an der Anzeige des PCR für den Kartenbesitzer angezeigt, um danach manuell in die Kartenbesitzer-Schnittstellenanwendung eingegeben zu werden. Prüfdigits werden dazu verwendet, die Bestätigung der Dateneingabe möglich zu machen.
  • Ferner sind PCR-Einrichtungen, die an der MCD angeschlossen sind, bekannt und in der vorliegenden Erfindung nicht enthalten.
  • An dem PCR angeschlossene Einrichtungen gestatten die Übertragung von mehr Daten an die MCD ohne die Unannehmlichkeit für den Kartenbesitzer, die Daten manuell einzugeben. Es können angeschlossene Einrichtungen erfunden werden, die in einem nicht-angeschlossenen Zustand arbeiten können, wenn das Anschlusskabel entfernt ist.
  • Eine PCR-Einrichtung mit einem Einwegeanschluss ist mit der MCD ausschließlich in Richtung aus dieser heraus verbunden. Die Schnittstelle für Daten in die Einrichtung ist der Tastenblock. Sie weist eine Anzeige für den Dialog mit einem Kartenbesitzer auf. Der Kartenbesitzer handelt wiederum als Datentransportmechanismus zwischen der MCD und dem PCR. Der Kartenbesitzer muss zusätzlich zu seiner PIN bestimmte Daten manuell eingeben, die der PCR in Verbindung mit der Karte verwendet, um einen Zugriffsberechtigungsprüfungswert zu erzeugen. Der Zugriffsberechtigungsprüfungswert wird an die MCD über den Einwegeanschluss gesandt.
  • Eine PCR-Einrichtung mit einem Zweiwegeanschluss ist mit der MCD in beiden Richtungen verbunden. Die Einrichtung weist einen Tastenblock für die Eingabe der Kartenbesitzer-PIN und eine Anzeige für einen Dialog mit dem Kartenbesitzer auf. Der Kartenbesitzer muss nur seine PIN eingeben. Die MCD kann alle Daten übermitteln, die der PCR in Verbindung mit der Karte benutzt, um einen Zugriffsberechtigungsprüfungswert zu erzeugen. Der Zugriffsberechtigungsprüfungswert wird an die MDC gesandt.
  • Eine integrierte PCR-Einrichtung ist eine MCD, die eine direkte Verbindung zu einem Smart-Card-Leser aufweist. Die Terminologie soll sich auf PDAs mit eingebauten Smart-Card-Lesern beziehen, jedoch könnte sich die Technologie ebensogut auf einen Desktop-PC mit einem direkt angeschlossenen Smart-Card-Leser beziehen. Der Kartenbesitzer muss nur seine PIN eingeben. Die MCD führt die gesamte PCR-Funktionalität durch und überträgt Befehle direkt an die ICC über den angeschlossenen Leser. Die Antwort von der ICC wird durch die MCD selbst verarbeitet. Die Software ist in einer solchen Weise geschrieben, dass die Kartenbesitzer-IA in derselben Weise wie für eine Einrichtung mit einem Zweiwegeanschluss arbeiten kann, d. h. wenn die Kommunikation zu dem PCR mittels der Kartenbesitzer-IA hergestellt ist, wobei die Treiber die Daten an einen PCR, der sich zufällig an der gleichen MCD befindet, senden und die Daten von diesem empfangen.
  • Eine angeschlossene und integrierte PCR-Einrichtung würde ein unabhängiger PCR sein, derin die MCD integriert ist. Die Erfordernisse für eine solche Einrichtung unterscheiden sich nicht von denjenigen für eine angeschlossene Einrichtung und können in einer andere Eingangs-/Ausgangs-Einrichtungals eine PC-Tastatur integriert sein.
  • Im Zusammenhang mit einer UCAF weist ein UCAF-ermächtigter Erfasser eine Beziehung zu einem UCAF-ermächtigten Händler auf. Die Erfasser machen es möglich, dass die Händler die Extra-UCAF-Daten an die Erfassungssysteme senden, und machen es möglich, dass ihre Systeme das Vorhandensein von gelieferten UCAF-Daten identifizieren und an die ausstellende Bank weiterleiten.
  • Der Aussteller-Rost oder irgendein anderes Element, das für das Schema als Aussteller-Host arbeitet, ist dafür verantwortlich, die in der Genehmigungs-Netzwerknachricht durchgelaufenen Daten zu übernehmen einschließlich der Daten in dem UCAF, und es möglich zu machen, den Zugriffsberechtigungsprüfungsbeweis zu bestätigen.
  • Angenommen, dass die in der vorliegenden Erfindung beschriebenen Funktionen, die auf einem Chip basieren, Mittel zur Prüfung des Vorhandenseins des Kartenbesitzers bei der ausstellenden Bank zur Verfügung stellen, kann die vorliegende Erfindung auch im Umfeld des Bankings mit Fernzugriff ("e-" oder "m-Banking") realisiert werden. Dies würde Banken ein konsistentes Kunden-Zugriffsberechtigungsprüfungsverfahren zu Produkten, Dienstleistungen und Umgebungen zur Verfügung stellen.
  • Chip-UCAF verwendet die UCAF-Infrastruktur zum Transport von Zugriffsberechtigungsprüfungs- und Sicherheitsdaten zwischen dem Kartenbesitzer, dem Händler, dem Erfasser und dem Aussteller. 7 zeigt den Verfahrensablauf für eine typische Chip-UCAF-Transaktion gemäß einer Ausführungsform der vorliegenden Erfindung. Dieser Ablauf nimmt an, dass sich vor der Durchführung einer Transaktion der Kartenbesitzer bei seinem Aussteller für die Dienstleistung registriert hat, die Kartenbesitzer-Schnittstellenanwendung erhalten und initialisiert hat und einen persönlichen Kartenleser erhalten hat, der mit seiner ICC-Karte kompatibel ist. Es wird auch angenommen, dass der Kartenbesitzer ein Produkt oder eine Dienstleistung, die auf dem Händlerserver angeboten wird, identifiziert hat und das Checkout-Verfahren initiiert und bereits vom Händler aufgefordert worden ist, Einzelheiten der Bezahlungskarte zur Verfügung zu stellen. Wenn die Warenposten ausgewählt sind und die Checkout-Phase beginnt, stellt der Kartenbesitzer die Rechnungsadresse, die Versandadresse und Einzelheiten der Bezahlungskarte dem Händler zur Verfügung. Die Information zur Rechnung- und Versandadresse kann direkt oder auf der Grundlage einer Information eingegeben werden, die beim Händler für den bestimmten Kartenbesitzer gespeichert ist. Wenn der Händler eine Bestätigung und eine Zugriffsberechtigungsprüfung des Auftrags anfordert, liefert der Webserver des Händlers eine Reihe von verborgenen Feldern, die ausschließlich diese Transaktion beschreiben. Beispielsweise kann diese Information einen oder mehrere der folgenden Punkte aufweisen:
    • – Name des Händlers
    • – Stadt des Kartenempfängers
    • – Kartenempfängerstaat/Ländercode
    • – Währungscode Verkaufsbetrag Transaktionskennzeichnung des Händlers
    • – UCAF-Zugriffsberechtigungsprüfungs-Datenfeld
    • – Nummer der Bezahlungskarte (von dem Händler mit den letzten 5 Digits der zuvor gelieferten Kartennummerversehen)
    • – UCAF-Marke
  • Unter Bezugnahme jetzt auf die Nummerierung von 7 ist das folgende eine Beschreibung einer Ausführungsform der vorliegenden Erfindung.
    • 1. Die Kartenbesitzer-Schnittstellenanwendung erfasst die Händler-Kennzeichnungsinformation und die Transaktionsdaten aus der Seite der UCAF-Zugriffsberechtigungsprüfung und baut eine Anforderung auf, die dem Kartenbesitzer präsentiert wird.
    • 2. Der Kartenbesitzer setzt die Bezahlungskarte (ICC 5) in den persönlichen Kartenleser ein. Die Anwendung, die an dem persönlichen Kartenleser implementiert wird, fordert den Kartenbesitzer auf, die Anforderung einzugeben hat, oder die Anforderung wird automatisch dorthin übertragen. Der persönliche Kartenleser kann dann die Währung des Verkaufsbetrags abfragen, und der Kartenbesitzer wird aufgefordert, die Verkaufsbetrag in dieser Währung einzugeben.
    • 3. Der Kartenbesitzer wird dann als Beweis, dass er/sie mit der Transaktion einverstanden ist, gebeten, einen persönlichen Sicherheitscode, beispielsweise eine PIN, an dem persönlichen Kartenleser einzugeben. Der persönliche Kartenleser fordert die Bezahlungskarte (ICC) auf, die PIN zu prüfen.
    • 4 Der persönliche Kartenleser fordert die Bezahlungskarte (ICC) auf, die die Transaktion betreffenden Daten (d. h. die Anforderung) unter Verwendung einer geeigneten Verschlüsselungsroutine zu unterzeichnen.
    • 5. Die ICC sendet ein Kryptogramm (MAC) zu den Transaktionsdaten und anderen ICC-spezifischen Daten zurück, die der Kartenbesitzer benötigt, um das Kryptogramm zu bestätigen. Signier- oder Verschlüsselungsprogramme sind aus den oben angegebenen Büchern bekannt sowie aus "Applied Cryptography", B. Schneier, 1996, ISBN 0-471-11709-9, "Understanding Public Key Infrastructure", C. Adams, S. Lloyd, New Riders, 1999.
    • 6. Der persönliche Kartenleser bildet dann einen Datenbeweis unter Verwendung eines Teils des Kryptogramms und der variablen Daten, die durch den Kartenaussteller identifiziert sind.
    • 7. Der persönliche Kartenleser formatiert den Datenbeweis und präsentiert ihn dem Kartenbesitzer, der ihn in der Kartenbesitzer-Schnittstellenanwendung oder manuell oder durch Übertragung eingibt.
    • 8. Die Kartenbesitzer-Schnittstellenanwendung baut den AAV zur Einschließung in dem UCAF auf. Die Kartenbesitzer-Schnittstellenanwendung setzt das für diese besondere Transaktion erzeugte Chip-UCAF in ein verborgenes Zugriffsberechtigungsprüfungs-Datenfeld ein, das auf der Seite der Händler-UCAF-Zugriffsberechtigungsprüfung vorgesehen ist. Die Transaktion wird dann für eine Genehmigungsverarbeitung durch den Händler übermittelt.
    • 9. Der Händler übermittelt die Anforderung einer Genehmigung an den Erfasser. Die Anforderung der Genehmigung muss den unveränderten Chip-UCAF-Wert enthalten, der durch den Aussteller während der Genehmigungsverarbeitung geprüft wird.
    • 10. Der Erfasser akzeptiert die (lokale) Anforderung einer Genehmigungund schafft eine Anforderungsnachricht für die Genehmigung. Diese Nachricht enthält die Chip-UCAF-Daten. Die Anforderungsnachricht für die Genehmigung wird über ein Banking-Netzwerk an den Kartenaussteller weitergegeben. Der Erfasser und der Aussteller müssen sich über UCAF-Spezifikationen für jedes systemspezifische Nachrichtenformat einig sein.
    • 11. Das Banking-Netzwerk sendet die Anforderungsnachricht für die Zugriffsberechtigungsprüfung, einschließlich des Chip-UCAF, an den Kartenaussteller.
    • 12. Nach dem Empfang der Anforderungsnachricht für die Genehmigung führt der Kartenaussteller folgendes durch: a) Wenn die Anforderungsnachricht für die Genehmigung nicht angibt, dass der Händler für UCAF ermächtigt worden ist (beispielsweise gibt das auf "0" eingestellte Sicherheitslevel-Anzeigebit an "UCAF durch den Händler nicht unterstützt", siehe weiter unten), wird die Anforderung der Genehmigung in einer im Geschäftsleben üblichen Weise durch das Genehmigungssystem des Ausstellers verarbeitet. B) Wenn die Anforderung für die Genehmigung angibt, dass der Händler für UCAF ermächtigt worden ist und der Kartenbesitzer für den Chip-UCAF-Dienst registriert ist, jedoch keine Chip-UCAF-Zugriffsberechtigungsprüfungsdaten vorhanden sind (beispielsweise gibt das auf "1" eingestellte Sicherheitslevel-Anzeigebit an "UCAF durch den Händler unterstützt, jedoch durch den Kartenbesitzer nicht zur Verfügung gedtellt", siehe weiter unten), muss der Aussteller bestimmen, ob er die Genehmigung anerkennt oder ablehnt. Dieses Szenario zeigt ein, dass der Kartenbesitzer nicht die durch das Chip-UCAF ermächtigte Kartenbesitzer-Schnittstelle und den persönlichen Kartenleser verwendet, um die Bezahlungstransaktion zu verarbeiten. C) Wenn die Anforderung der Genehmigung UCAF-Zugriffsberechtigungsprüfungsdaten enthält, bestätigt der Kartenaussteller den AAV.
    • 13. Der Aussteller antwortet mit einer Anerkennung oder Ablehnung auf der Grundlage des Ergebnisses des vorausgehenden Schritts. Diese Antwort wird an den Händler über dieselben Netzwerksysteme zurückgesandt, der dann seinem Kunden in geeigneter Weise antwortet.
    • 14. Die Antwort des Händlers an seinem Kunden kann in irgendeinem geeigneten Format erfolgen, beispielsweise über eine HTML-Seiten-Bestätigung für Online-Zugriffsberechtigungsprüfungen und über E-Mail für Stapel-Genehmigungen.
  • Die Sicherheit des Chip-UCAF verlässt sich auf bestimmte Sicherheitsmerkmale. Im Besonderen verlässt sich das Chip-UCAF auf die Erzeugung von Kryptogrammen durch die ICC, nämlich das Anwendungs-Anforderungskryptogramm (ARQC) oder das Anwendungs-Zugriffsberechtigungsprüfungskryptogramm (AAC), um zu schaffen:
    • – einen Beweis des Anwesenheit des Kartenbesitzers und
    • – einen Beweis der Transaktionsgenehmigung durch den Kartenbesitzer.
  • Zusätzlich bietet sie einen Schutz gegen die Wiederholung von unverfälschten Transaktionen und gegen die Erzeugung von verfälschten Chip-UCAF-Transaktionen. Daher bietet bei Verwendung in Verbindung mit geeigneten Sicherheitsmaßnahmen, insbesondere in Hinblick auf die PIN-Sicherheit, das Chip-UCAF einen adäquaten Sicherheitslevel, um die nicht erfolgte Zurückweisung durch den Kartenbesitzer bei Internet-Transaktionen zu verstärken.
  • Die Festlegung des durch das Chip-UCAF angebotenen Sicherheitslevels beruht auf den folgenden Annahmen:
    • – Die Haupt-Kartenbesitzereinrichtung (MCD), d. h. die von dem Kartenbesitzer zur Durchführung des gegenwärtigen Bezahlungsvorgangs verwendete Plattform, wird als vertraulich angesehen. Dies führt bei der physikalischen Einrichtung, beispielsweise einem PC oder einem mobilen Telefon, zu der Schnittstellenanwendung (IA), die die Anforderung erzeugt, und zu der Anwendung, die mit dem persönlichen Kartenleser, sofern relevant, kommuniziert. Wegen der un-gesteuerten Art der MCD wird diese Annahme für jedes ähnliche Produkt als gültig verstanden.
    • – Die Sicherheit der vertraulichen Bezahlungseinzelheiten, beispielsweise der PAN oder des Ablaufdatums, die an der MCD eingegeben und an den Händler gesandt werden, liegt außerhalb des Umfangs dieses Produkts. Die Vertraulichkeit dieser Daten sollte durch Verschlüsselung der Verbindung zwischen der MCD und dem Händler verstärkt werden, beispielsweise dadurch, dass man sich auf eine SSL-Verschlüsselung verlässt, und durch den Schutz der Karteneinzelheiten auf dem Händler-Hostsystem des.
  • Die ICC erstellt den Beweis für die Anwesenheit des Kartenbesitzers über die Verwendung einer Bestätigung, beispielsweise eine Offline-PIN-Bestätigung. Eine Offline-PIN-Bestätigung ist vor der Erzeugung eines ARQC erforderlich. Folglich ist die Anwesen heit des Kartenbesitzers erforderlich, um eine gültige ARQC zu erzeugen, und das Vorhandensein eines solchen gültigen Kryptogramms reicht aus, um diese Anwesenheit des Kartenbesitzers zu demonstrieren.
  • Jedoch ist dies nicht der Fall bei der Erzeugung des AAC, das keine Offline-PIN-Bestätigung erforderlich macht. Um den Beweis der Anwesenheit des Kartenbesitzers zu erstellen, verlässt sich der Aussteller ausschließlich auf die CVR, die innerhalb der Antwort auf die Abfrage übermittelt werden. Die Ergebnisse der Kartenprüfung auf Richtigkeit (CVR) beziehen sich auf irgendeine Information, die von der Karte aus übermittelt wird und zulässt, dass der Aussteller prüft, ob die Kartenbesitzer-PIN durch die Karte korrekt geprüft worden ist oder nicht. Dies ist wichtig, um die Integrität der CVR während der Übermittlung zu schützen.
  • Diese Eigenschaft wird sichergestellt, wenn die ICC die CVR in die AAC-Berechnungseingangsdaten einschließt. Jedoch ist ein solches Verhalten kein zwangsweises. Es ist einzusehen, dass diejenigen ICCs, die die CVR nicht in die ARQC- oder die AAC-Berechnungseingangsdaten einschließen, ohne die PIN für Internet-Transaktionen verwendet werden könnten. Folglich sollten solche ICCs im Rahmen des Chip-UCAF-Programms vorzugsweise nicht verwendet werden.
  • Das Chip-UCAF verwendet eine Zusammenstellung der Transaktionsbeschreibung als Eingabe für die ARQC- oder AAC-Berechnung. Diese Zusammenstellung wird als das UN-Feld verwendet, wobei die UN der Wert ist, der aus der Abrufnachricht erzeugt wird, aus den Eingabeparametern zu der ARQC- oder AAC-Berechnung. Eine erfolgreiche Bestätigung des Kryptogramms durch den Aussteller kombiniert mit dem Beweis der Anwesenheit des Kartenbesitzers schafft ein gewisses Vertrauen auf die Genehmigung der Transaktion durch den Kartenbesitzer.
  • Um sicherzustellen, dass die Transaktionsbeschreibung tatsächlich berücksichtigt wird, muss die ARQC- oder AAC-Berechnung wirksam die nicht-voraussagbare Zahl (UN) verwenden, wobei die UN der Wert ist, der aus der Abrufnachricht erzeugt wird. Jedoch ist ein solches Verhalten kein zwangsweises. Folglich sollten diejenigen ICCs, die die UN, wobei die UN der Wert ist, der aus der Abrufnachricht erzeugt wird, nicht in die Eingabedaten für die ARQC- oder AAC-Berechnung einführen, im Rahmen des Chip-UCAF-Programms vorzugsweise nicht verwendet werden.
  • Um den Schutz gegen Wiederholungen von unverfälschten Transaktionen sicherzustellen, sollten zwei Bedingungen erfüllt sein:
    • – Der ATC, wie von der ICC empfangen,, uss gegen den zuletzt empfangenen ATC für diese besondere ICC geprüft werden. Transaktionen, die einen bereits empfangenen ATC verwenden, sollten nicht berücksichtigt werden.
    • – Das ARQC oder das AAC, die durch die ICC erzeugt werden, muss als Funktion des ATC variieren. Dies ist nur der Fall, wenn der ATC in die Eingabedaten für die ARQC- oder AAC-Berechnung eingeschlossen wird. Jedoch ist ein solches Verhalten kein zwangsweises. Daher sollten diejenigen ICCs, die den ATC nicht in die Eingabedaten für die ARQC- oder AAC-Berechnung einschließen, im Rahmen des Chip-UCAF-Programms vorzugsweise nicht verwendet werden.
  • Das Haupt-Sicherheitsproblem, das mit der Verwendung einer persönlichen Kartenlesereinrichtung in Verbindung steht, ist die Gefahr eines Bekanntwerdens der Karten-PIN oder von auf der Karte gespeicherten vertraulichen Informationen, wie der ISO2-Spur, durch die Einrichtung selbst. Betrügerische oder verkürzte persönliche Kartenleser können die Vertraulichkeit der PINs oder der ISO2-Spur gefährden. Die Höhe des Risikos hängt von der Art der Einrichtung ab:
    • – Die selbstständige Art der nicht-angeschlossenen persönlichen Kartenleser macht es erforderlich, dass diese Einrichtungen für böswillige Dritte, die einen Zugang zu den vertraulichen Informationen erlangen wollen, gegenständlich zugänglich sind. Nur Angriffe in kleinem Ausmaß sind auf solche Einrichtungen durchführbar, und daher wird erwartet, dass der Einfluss solcher Angriffe gering ist.
    • – Persönliche Kartenleser mit einem Einwege- oder einem Zweiwegeanschluss bieten mehr betrügerische Möglichkeiten infolge des Vorhandenseins eines gegenständli chen Anschlusses. Angriffe in einem großen Ausmaß könnten an solchen Einrichtungen durchführbar sein, und daher wird erwartet, dass der Einfluss solcher Angriffe höher ist.
    • – Integrierte persönliche Kartenleser sorgen sogar für eine größere Flexibilität in Hinblick auf eine transparente Kommunikation mit der Außenwelt, wobei ein zusätzliches Potenzial zum Betrug angeboten ist.
  • Auch muss das ARQC oder das AAC bei der Rücksendung durch die ICC nicht vollständig an den Aussteller übermittelt werden. Sie können wie durch das IIPB spezifiziert verkürzt werden, und das IIPB muss in einer solchen Weise definiert werden, dass eine bestimmte Anzahl von Bits, beispielsweise mindestens 16 Bits, aus dem ARQC oder dem AAC in den von dem persönlichen Kartenleser zurückgeführten Datenbeweis eingeschlossen ist. Wegen der verkleinerten Größe des verkürzten Kryptogramms sollten Betrugs-Feststellungssysteme vorgesehen sein, um anormale Zahlen der gestörten Kryptogrammbestätigung festzustellen und irgendeine geeignete Aktion zu ergreifen.
  • Das ARQC oder das AAC sollte durch den Aussteller auf der Grundlage der durch den Händler geschaffenen Information bestätigt werden. Das heißt, in dem Prüfungs- bzw. Bestätigungsverfahren sollte der Aussteller die Abfrage aus den ursprünglichen Eingabedaten bilden, statt sich auf eine durch die Kartenbesitzer-Einrichtung geschaffene Abfrage zu verlassen. Dies macht es erforderlich, dass die Eingabedaten an den Aussteller von dem Händler ebenso wie der spezielle Zugriffsberechtigungsprüfungsbeweis gemäß der vorliegenden Erfindung gesandt werden.
  • Eine Karte, die zum Berechnen des Anwendungskryptogramms (ARQC oder AAC) verwendet wird, muss das CVR als Eingang für die Berechnung verwenden. Karten, bei denen dies nicht der Fall ist, dürfen für die Chip-UCAF-Zugriffsberechtigungsprüfung nicht verwendet werden. Eine Karte, die zum Berechnen des Anwendungskryptogramms (ARQC oder AAC) verwendet wird, muss die UN, wobei die UN der Wert ist, der von der Abfragenachricht erzeugt wird, als Eingabe für die Berechnung verwenden. Karten, bei denen dies nicht der Fall ist, dürfen für die Chip-UCAF-Zugriffsberechtigungsprüfung nicht verwendet werden. Eine Karte, die zum Berechnen des Anwendungskryptogramms (ARQC oder AAC) verwendet wird, muss den ATC als Eingabe für die Berechnung verwenden. Karten, bei denen dies nicht der Fall ist, dürfen für die Chip-UCAF-Zugriffsberechtigungsprüfung nicht verwendet werden. Aussteller sollten sicherstellen, dass ein ATC nicht erneut verwendet wird.
  • Aussteller sollten idealerweise Betrugsfeststellungssysteme verwenden, um anormale Zahlen der gestörten Kryptogrammsendungen festzustellen und auf diese zu agieren.
  • Der Aussteller sollte die Abfragedaten für die Prüfung des Kryptogramms aus der Zugriffsberechtigungsprüfungsnachricht neu aufbauen, statt sich auf die diejenigen zu verlassen, die von der Software des Kartenbesitzers in der UCAF selbst geliefert werden.
  • 8 zeigt detailliert den PCR- und den Chip-UCAF-Ablauf entsprechend einer Ausführungsform der vorliegenden Erfindung. Diese schematische Darstellung und der nachfolgende Text dienen als Erläuterungen ausschließlich einer Ausführungsform der vorliegenden Erfindung und der in dem Chip-Zugriffsberechtigungsprüfungs-Programm involvierten Schritte beginnend mit dem Zeitpunkt, zu dem der Händler die UCAF-Händlerdaten auf einer Seite für die UCAF-Zugriffsberechtigungsprüfung liefert, bis zu dem Zeitpunkt, zu dem der Händler die Zugriffsberechtigungsprüfungs-Antwort von seinem Erfasser empfängt. Ferner ist die besondere Reihenfolge einiger Schritte willkürlich statt zwangsläufig, beispielsweise das Einsetzen der Karte in Schritt 8.
  • Für die Zwecke dieser Ausführungsform wird angenommen, dass die Haupt-Kartenbesitzereinrichtung ein PC ist, der mit einem Standard-Browser arbeitet, und dass die UCAF-Händlerdaten in verborgenen HTML-Formblattfeldern präsentiert werden. Diese Ausführungsform nimmt an, dass ein nicht-angeschlossener PCR verwendet wird. Wo eine nicht-angeschlossene Einrichtung oder eine Einrichtung mit einem Einwegeanschluss eine Aufforderung dem Kartenbesitzer anzeigt, bestimmte Daten einzugeben, die nicht die Eingabe der PIN einschließen, muss die Einrichtung mit einem Zweiwegeanschluss oder integrierte Einrichtung bei der Kartenbesitzer-IA die Forderung stellen, das gleiche Datenelement zu ihr zu führen. Jedoch gehören die präzisen Mechanismen dieses Kommunikationsprotokolls zu jeder Implementierung.
  • Die Bestätigung der Zugriffsberechtigungsprüfung von dem Händler an den Kartenbesitzer ist nicht von dieser Erfindung ausgeschlossen.
  • In 8 wird angenommen, dass der Händler bereits die Bezahlungseinzelheiten, einschließlich der PAN, des Ablaufdatums etc., gesammelt bzw. abgerufen hat und sich im Zustand der Auftragsbearbeitungspipeline befindet, wo die Auftrags- und Bezahlungseinzelheiten durch eine Seite der UCAF-Zugriffsberechtigungsprüfung abgeschlossen werden können. Der Kartenbesitzer hat bereits seine/ihre Kartenbesitzer-IA mit Einzelheiten der PAN personalisiert, sodass dann, wenn die letzten 5 Digits der PAN, die für diese Bezahlung verwendet werden, in dem UCAF präsentiert werden, die Kartenbesitzer-IA in der Lage ist zu erkennen, dass sie im Auftrag bzw. Namen dieser PAN arbeiten kann.
  • Bezugnahme auf die Nummerierung von 8:
    • 1. Abgleichen der Transaktionsdaten – Der Händler gleicht die die Transaktion betreffenden Daten wie durch die UCAF-Spezifikation gefordert ab.
    • 2. Senden der Transaktionsdaten – Der Händler übermittelt die Transaktionsdaten über den Mechanismus, der für den gegebenen E-Commerce-Kanal definiert ist, wie durch die UCAF-Spezifikation für diesen Kanal gefordert.
    • 3. Feststellen der UCAF-Felder – Die an der Haupt-Kartenbesitzereinrichtung (MCD) installierte Schnittstellenanwendung (IA) stellt das Vorhandensein der verborgenen UCAF-Felder fest, bestimmt, dass eine Zahl, beispielsweise die letzten 5 PAN-Digits, die von dem Händler geliefert wurden, eine PAN betreffen, die der IA bereits bekannt ist, bestätigt die verbleibenden UCAF-Daten und präsentiert sich selbst.
    • 4. Anzeigen der Transaktionsdaten – Die IA zeigt die die Transaktion betreffenden Daten dem Kartenbesitzer über seine Benutzerschnittfläche an. Der Kartenbesitzer kann zu diesem Zeitpunkt entscheiden, die Transaktion zurückzuweisen.
    • 5. Bestätigen der Kartendetails – Die Schnittstellenanwendung kann den Kartenbesit zer auffordern zu bestätigen, dass die Kartendetails, die er gewählt hat, korrekt sind. Dies kann in der Form stattfinden, dass beispielsweise der Kartenbesitzer erinnert wird, welche Karte gegenständlich in dem PCR zu verwenden ist, beispielsweise vielleicht durch die Verwendung eines "freundlich" Kennzeichens für den Kartenbesitzer, das mit der besonderen Karte in Verbindung steht, wenn die Kartenbesitzer-AI mit den Kartendetails personalisiert wird.
    • 6. Erzeugen einer Abfrage – Die Schnittstellenanwendung veranlasst, dass die PCR-Abfrage aus bestimmten Transaktionsdaten + PAN erzeugt wird.
    • 7. Anzeigen der PCR-Abfrage – Für nicht-angeschlossene Einrichtungen oder Einrichtung mit einem Einwegeanschluss zeigt die Schnittstellenanwendung die Abfrage an, die in den PCR durch den Kartenbesitzer eingegeben werden muss.
    • 8. Einsetzen der Karte – Der Kartenbesitzer setzt die ICC 5 in den PCR ein.
    • 9. Weiterleiten der PCR-Abfrage – Die PCR-Abfrage wird an den PCR weitergeleitet. Für eine nicht-angeschlossene Einrichtung oder eine Einrichtung mit einem Einwegeanschluss führt der Kartenbesitzer dies durch, indem die Abfrage in den PCR in Reaktion auf eine Anforderung von der Schnittstellenanwendung und dem PCR selbst eingegeben wird. Ansonsten kann sie an den PCR übermittelt werden.
    • 10. Optional: Übermittlung des Betrags – Wenn das Zugriffsberechtigungsprüfungsschema einen Betrag und eine Währung anfordert, wird der Betrag an den PCR transferiert. Für eine nicht-angeschlossene Einrichtung oder eine Einrichtung mit einem Einwegeanschluss führt der Kartenbesitzer dies durch, indem der Betrag der Transaktion in den PCR in Reaktion auf die Anforderung von dem PCR eingegeben wird. Ansonsten kann sie an den PCR übermittelt werden.
    • 11. Eingeben der PIN – Der Kartenbesitzer gibt einen Sicherheits- oder Bestätigungscode, beispielsweise eine PIN, an dem PCR oder der MCD in Reaktion auf eine Aufforderung von der Schnittstellenanwendung und/oder dem PCR selbst ein.
    • 12. Schaffen einer UN, wobei die UN der Wert ist, der von der Abfragenachricht erzeugt wird – Der PCR schafft die nicht-voraussagbare Zahl.
    • 13. Erzeugen des AC, wobei das AC das Kryptogramm ist. – Der PCR baut einen AC-Erzeugungsbefehl auf und sendet diesen an die Karte.
    • 14. Antwort mit AC, wobei das AC das Kryptogramm ist. – Die Karte führt ein AC, wobei das AC das Kryptogramm ist, neben anderen Daten als Antwort an den PCR zurück.
    • 15. Schaffen des PCR-Beweises, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist. – Der PCR "streift herunter" die Antwort auf der Grundlage der in dem IPIPB gefundenen Aussteller-Spezifikationen, um den PCR-Beweis zu schaffen, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist.
    • 16. Anzeigen des PCR-Beweises, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist. – Der PCR zeigt den dezimalen numerischen Beweis dem Kartenbesitzer an.
    • 17. Übermittlung des PCR-Beweises, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist. – Der PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, wird von dem PCR übermittelt. Für eine nicht-angeschlossene Einrichtung führt der Kartenbesitzer dies durch, indem er den PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, in die Schnittstellenanwendung in Reaktion auf die Anforderung von der Schnittstellenanwendung und der Anzeige an dem PCR eingibt. Ansonsten kann er automatisch übermittelt werden.
    • 18. Codieren des UCAF – Die Schnittstellenanwendung codiert die Chip-UCAF-Struktur, setzt das Steuerbyte und das kodiert es auf Basis 64 zur Übertragung in dem UCAF.
    • 19. Rückübermitteln des UCAF – Die Schnittstellenanwendung codiert die verschiedenen Rückübermittlungsdaten in die Händler-Bezahlungsanforderungsmitteilung.
    • 20. Aufbauen der Zugriffsberechtigungsprüfungsanforderung – Der Händler extrahiert die durch die IA in den verborgenen Feldern gelieferten Daten, die an dem Händler zurückgeführt worden sind, und baut die systemspezifische Zugriffsberechtigungsprüfungsanforderung für ihren Erfasser auf.
    • 21. Zugriffsberechtigungsprüfungsanforderung – Der Händler führt die Zugriffsberechtigungsprüfungsdaten einschließlich des UCAF an ihren Erfasser weiter, der sie an den geeigneten Aussteller weitergibt.
    • 22. Einstellen des SLI – Der Erfasser stellt den Sicherheitslevelanzeiger (SLI) wie für die Zugriffsberechtigungsprüfungstransaktion geeignet ein.
    • 23. ISO 8583-0100 – Der Erfasser sendet die Zugriffsberechtigungsprüfungsanforderung an den Aussteller, der dann eine gewisse anfängliche Standardverarbeitung an der Nachricht durchführt.
    • 24. UCAF-Verarbeitung – Der Aussteller prüft auf das Vorhandensein des UCAF.
    • 25. Optional: Neuaufbau der Abfrage – Die Abfrage an dem PCR wird aus den Nachrichtendaten neu aufgebaut, damit die nicht-voraussagbare Zahl erneut erzeugt werden kann.
    • 26. Wiederaufsuchen von Kartendaten – Der Aussteller muss bestimmte Datenelemente aus der ICC-Datenbank wieder heraussuchen, um eine erneute Bildung zu ermöglichen.
    • 27. Neuaufbau – Der PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, wird durch den Aussteller auf der Grundlage der Kenntnis des durch den PCR verwendeten Algorithmus geschaffen.
    • 28. Vergleichen – Der Aussteller vergleicht den reduzierten PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, in der Zugriffsberechtigungsprüfungsnachricht mit dem PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, der aus den Eingabedaten geschaffen worden ist. Dies kann Änderungen an einer "Sicherheitsbox" zur Folge haben, wo er den Vergleich durchführt.
    • 29. ISO 8583-0100 – Der Aussteller sendet die Antwort auf die Zugriffsberechtigungsprüfungsanforderung an den Erfasser.
    • 30. Antwort auf die Zugriffsberechtigungsprüfungsanforderung – Der Aussteller führt die Antwort auf die Zugriffsberechtigungsprüfungsanforderung über den Erfasser an den Händler zurück.
  • Die Schritte 1 bis 21 sind für dieses Schema spezifisch;
    • – Der Händler gleicht die Transaktionsdaten ab und präsentiert sie in einem besonderen, spezifizierten Format.
    • – Die Kartenbesitzer-Haupt-Zugangseinrichtung, die Kartenbesitzer-Schnittstellenanwendung, der PCR und der Kartenbesitzer selbst veranlassen, dass der PCR- Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, erzeugt und an den Händler zurückgeführt wird.
    • – Der Händler führt die neuen Daten in die vorhandene Erfassermitteilung ein. Schritt 22 zeigt Extraschritte, die ein Erfasser bei der Handhabung der UCAF-Daten durchführen muss;
    • – Der Erfasser ist für das Einstellen des Sicherheitslevelanzeigers in Abhängigkeit von den durch den Händler gelieferten Daten verantwortlich. Schritt 23 ist eine Zusammenfassung der vorhandenen Übermittlung der Bezahlungsdaten an den Erfasser und dann an den Aussteller über die ISO 8583-0100 Zugriffsberechtigungsprüfungsanforderungsnachricht;
    • – Bei Erhalt der 0100 Nachricht muss der Aussteller einen kleinen Schritt durchführen um zu bestimmen, ob irgendwelche Daten in dem UCAF vorhanden sind, und sie in geeigneter Weise bearbeiteten.
  • Die Schritte 24 bis 28 sind für dieses Schema spezifisch;
    • – Der Aussteller zieht die Daten aus dem UCAF heraus und bestätigt den PCR-Zugriffsberechtigungsprüfungsbeweis.
  • Die Schritte 29 und 30 sind eine Zusammenfassung der vorhandenen ISO 8583-0100 Zugriffsberechtigungsprüfungsanforderungsantwortnachricht; und der Antwort an den Händler;
    • – Der Aussteller, der damit, dass der PCR-Beweis, wobei der PCR- Beweis der Zugriffsberechtigungsprüfungsbeweis ist, gültig ist, zufrieden ist, führt eine 0110 Nachricht an den Händler über den Erfasser.
  • Diese schematische Darstellung des detaillierten Ablaufprogramms und die Beschreibung zeigen eine Lösung, die von dem betroffenen E-Commerce-Kanal unabhängig ist. Die Schritte 2 und 19, die Verbindung zwischen der Schnittstellenanwendung und den Händlersystemen, sind Punkte, bei denen es eine Abhängigkeit von den Spezifikationen für einen gegebenen E-Commerce-Kanal gibt.
  • Entsprechend einem Aspekt der vorliegenden Erfindung können unterschiedliche Kanäle verwendet werden, und erfordern diese unterschiedliche Aussteller-Software, in der Form der Schnittstellenanwendung, und wahrscheinlich einen unterschiedlichen, jedoch notwendigerweise standardisierten Händlerdialog, beispielsweise HTML-Formblätter, XML-Datenaustausch etc.. Jedoch bleiben der Dateninhalt, die Algorithmen und der Ablauf über andere Kanäle die gleichen.
  • In dem obigen Schema liefert der Händler Einzelheiten über sich selbst und die Transaktion.
  • In Zusammenfassung sind diese Datenelemente ausgewählt aus:
    • – Name des Händlers
    • – Stadt des Händlers
    • – Staat/Ländercode des Händlers
    • – Währungscode
    • – Verkaufsbetrag Transaktionskennung des Händlers
    • – UCAF-Marke
    • – Nummer der Bezahlungskarte (die letzten 5 Digits)
  • Eine kartenpezifische Dateninformation, die bei dem erfindungsgemäßen Verfahren verwendet werden kann, ist die systemspezifische Aussteller-Internet-Dateninformation (IIPD). Die systemspezifische Aussteller-Internet-Dateninformation (IIPD). ist ein Datenobjekt, dessen Vorhandensein auf einer Karte optional ist. Sie steht in keiner Beziehung zu dem ähnlich bezeichneten systemspezifischen Aussteller-Internet-Bitmuster (IIPB) mit Ausnahme bei ihrer Einführung infolge des Chip-Zugriffsberechtigungsprüfungsprogramms. Es enthält Daten, die der Aussteller zur Verwendung in systemgebundener Weise, normalerweise in Verbindung mit der Erzeugung des Kryptogramms bei Verwendung in dem Internet-Umfeld, wählt, obwohl sie auch andere oder alternative Daten enthalten kann. Beispielsweise kann die Übermittlung einer Karten-Folgenummer (CSN) an den Aussteller erforderlich sein. Diese ist für eine gegebene Karte unveränderlich und kann an den Aussteller durch Eincodieren in die IIPD weitergegeben werden. Diese CSN kann das untere Halbbyte des ersten IAF- "Bytes" passieren. Diese Technik erspart eine Dateneingabe durch den Kartenbesitzer. Ihre Verwendung ist wörtlich systemspezifisch für einen Aussteller.
  • Das erste Byte der IIPD trägt einen Satz generischer Flagsignale, vorwiegend zur Verwendung durch den persönlichen Kartenleser (PCR). Tabelle 1 stellt eine schematische Angabe derselben zur Verfügung. Tabelle 1 IIBD-Flagsignal-Byte-Einstellungen
    Bit Beschreibung Einstellen auf 1 Einstellen auf 0 Ausgangswert
    8 Betrag- und Währungsanzeiger Betrag und Währung werden explizit bei der AC-Erzeugung verwendet, wobei AC das Kryptogramm ist Betrag und Währung werden nicht verwendet, und somit werden Ausgangswerte für AC-Erzeugung verwendet, wobei AC das Kryptogramm ist 0
    7 Art des Kryptogramms ARQC angefordert in erster AC-Erzeugung ACC angefordert in erster AC-Erzeugung 1
    6 auf 1 Nicht verwendet N/A N/A 0
  • Wenn das Bit 88 auf 1 eingestellt ist, bedeutet dies, dass der Aussteller verlangt, dass der Transaktionsbetrag und die Transaktionswährung bei der Erzeugung des AC verwendet werden müssen, wobei das AC das Kryptogramm ist. Für den PCR bedeutet dies, dass er die Kartenbesitzer-/Haupt-Kartenbesitzer-Zugangseinrichtung (MCD) auffordert, die Währung und den Betrag zu liefern, und für die Schnittstellenanwendung (IA), dass der Betrag und die Währung zugeführt werden müssen. Wenn das Bit 8 auf 0 eingestellt ist, werden die Ausgangswerte für den Betrag (0) und die Währung (999 – für Transaktionen ohne betroffene Währung verwendeter Code) bei der AC-Erzeugung verwendet, wobei das AC das Kryptogramm ist. Wenn das Bit 7 auf 1 eingestellt ist, bedeutet dies, dass der Aussteller verlangt, dass die Art des von der Karte anzufordernden Kryptogramms ein ARQC ist. Wenn das Bit 7 auf 0 eingestellt ist, bedeutet dies, dass der Aussteller verlangt, dass die Art des von der Karte anzufordernden Kryptogramms ein AAC ist. Die IIPD-Daten hinter dem ersten Byte sind für eine Verwendung frei, die für den Aussteller systemspezifisch ist.
  • Die IIPD sind eine optionale Struktur, da ihre Inhalte nicht durch eine gegebene Chip-Implementation benötigt werden, um Kryptogramme für eine mit dem Internet in Verbindung stehende Verwendung zu erzeugen. Da sie jedoch Anzeiger enthält, die den PCR instruieren, wie mit der Verarbeitung fortzufahren ist, wenn sie nicht vorhanden sind, muss sich der PCR auf eine Ausgangseinstellung verlassen. Wenn die Karte keine IIPD aufweist, dann kann ein Ausgangsbytewert von 0×40 verwendet werden, beispielsweise "kein Transaktionsbetrag und keine Transaktionswährung, ARQ ist zu erzeugen".
  • Die IIPD müssen an den Aussteller in dem Kontoinhaber-Zugriffsberechtigungsprüfungswert (AAV) übermittelt werden. Jedoch werden sie vorzugsweise nicht an die Kartenbesitzer-Schnittstelle (IA) durch den PCR übermittelt, da dies eine zu große Datenübermittlungsbelastung für den Kartenbesitzer über nicht-angeschlossene Einrichtungen verursachen würde. Da die IIPD für eine gegebene Karte unveränderlich sind, können sie der Kartenbesitzer-IA in derselben Weise wie die PAN und andere unveränderliche Kartendaten der Kartenbesitzer-IA zugeführt werden.
  • Ferner muss die Kartenbesitzer-IA die IIPD kennen oder den Ausgangswert, beispielsweise 0×40, verwenden um zu bestimmen, ob die Währung und der Betrag an den PCR weitergegeben werden müssen oder nicht. Die Währungsinformation kann als Teil der PCR-Abfrage weitergegeben werden.
  • Infolge sowohl der durch die UCAF-Einwilligung auferlegten Datenraumeinschränkungen und der Notwendigkeit, mindestens für einige Aussteller, eine nicht-angeschlossene Einrichtung oder eine Einrichtung mit einem Einwegeanschluss zu verwenden, sind die Daten, die die Einrichtung an die MCD zurück übertragen muss, in ihrer Größe beschränkt. Daher wird vorzugsweise nur ein ausgewählter Teil der Daten, die durch den Aussteller zur erneuten Berechnung des AC benötigt werden, wobei das AC das Kryptogramm ist, das in Reaktion auf den an die ICC übermittelten AC-Erzeugungsbefehl erzeugt worden ist, übertragen.
  • Die Antwort durch die ICC auf den AC-Erzeugungsbefehl besteht aus den folgenden Elementen:
    • – Kryptogramm-Informationsdaten (CID)
    • – Anwendungs-Transaktionszähler (ATC)
    • – durch die ICC berechnetes Kryptogramm (AC, d. h. das AC ist das Kryptogramm)
    • – Aussteller-Anwendungsdaten (IAD)
  • Sie enthalten Daten, die entweder sind:
    • – einzigartig für diese Transaktion und von dem PCR an die Kartenbesitzereinrichtung durch den Kartenbesitzer übermittelt werden müssen.
    • – von denen angenommen wird, dass sie besondere Werte für dieses besondere Schema sind und somit nicht von dem PCR an die Kartenbesitzereinrichtung durch den Kartenbesitzer übermittelt werden müssen.
    • – einzigartig für diese Transaktion oder die ICC und bekannt oder mindestens ableitbar durch den Aussteller-Rost über seine Kartendatenbank sind und somit nicht von dem PCR an die Kartenbesitzer-Zugangseinrichtung durch den Kartenbesitzer übermittelt werden müssen.
  • Das systemspezifische Ausstellerr-Internet-Bitmuster (IIPB) ist ein Datenobjekt, dessen Vorhandensein auf einer Karte optional ist. Die Daten bestehen aus Übermittlungsflagsignalen, die anzeigen, welche Bits in der Antwort auf die AC-Erzeugung durch das Aussteller-Hostsystem benötigt werden. Diese Flagsignale entsprechen auf einer Bit-für-Bit-Basis den Bits, die von CID (beispielsweise 1 Byte), ATC (beispielsweise 2 Bytes), AC (beispielsweise 8 Bytes), wobei dieses das Kryptogramm ist, und IAD (beispielsweise 0–32 Bytes) geschickt werden müssen (siehe 9). Die Länge des IIPB kann variieren, beispielsweise von 11 Bytes, wo keine IAD definiert sind, bis 43 Bytes, wo eine Aussteller-Anwendungstechnologie die vollen 32 Bytes verwendet, die für die Aussteller-Anwendungsdaten (IAD) zur Verfügung stehen.
  • Das IIPB gestattet, dass der Aussteller vollständig wählen kann, welche und wieviele Bits dieser Werte er für die Zwecke der Bestätigung der Zugriffsberechtigungsprüfung verwenden wird, womit die Notwendigkeit für den PCR überwunden wird, selbst unterrichtet zu sein von irgendeiner besonderen Kartentechnologie und somit spezifisch für die besondere Kartentechnologie zu sein. Das IIPB kann als Bit-Maske verwendet werden, die gestattet, dass der PCR einen Beweis aufbaut, der in den AAV durch die Kartenbesitzer-IA eingeführt und zu dem Aussteller weitergeführt wird.
  • Ein Aussteller kann ein IIPB definieren, das die minimal möglichen Bits markiert, die sie benötigen, um das Kryptogramm zu bestätigen. Die Anzahl der markierten Bits, die erforderlich sind, bestimmt die mögliche Größe des durch den PCR erstellten Datenbeweises.
  • Für Zwecke hauptsächlich in Verbindung mit vorhandenen Karten, die kein neues IIPB-Kennzeichen enthalten, ist das IIPB eine optionale Struktur. Da es jedoch verwendet wird, um die Bits, die der PCR extrahieren und komprimieren muss, zu identifizieren, muss, wenn es nicht vorhanden ist, sich der PCR dann auf eine Ausgangs-Einstellung verlassen. Das Ausgangs-IIPB kann beispielsweise eine 19-Byte-Struktur sein. Das Ergebnis hiervon ist, dass 35 Datenbits an den Aussteller gesendet werden und 11 dezimale Digits benötigt werden, um es an der Anzeige des PCR darzustellen. Das Hinzufügen des abschließenden Prüfdigits zu dem Ausgangs-IIPB führt zu einem 12-Digit-Beweis, der durch den Kartenbesitzer einzugeben ist.
  • Aussteller können ein IIPB in geeigneter Weise für eine Anwendungstechnologie spezifizieren. Dieses IIPB muss dann in den Personalisierungsspezifikationen für diese Anwendung enthalten sein, damit der PCR das in der Karte gespeicherte IIPB statt des in dem PCR gespeicherten Ausgangs-IIPB verwendet.
  • Wenn ein Aussteller es als angenehm empfindet oder fordert, dass es eine Eins-zu-Eins-Übereinstimmung zwischen seiner herausgegebenen Karte und dem zur Schaffung des Beweises verwendeten PCR gibt, dann kann er die Ausgangs-IIPB in diesen besonderen Lesern ändern. Dies würde bedeuten, dass in der Karte kein IIPB gespeichert sein muss. Jedoch können solche Karten, die die Ausgangs-IIPB verwenden, an dem PCR nicht verwendet werden.
  • Die Daten, die an den Händler von dem Browser des Kartenbesitzers geschickt werden, können aus genau dem UCAF-Zugriffsberechtigungsprüfungs-Datenfeld für jeden Browser-Kanal bestehen.
  • Das UCAF kann einen 24-Byte-Benutzer-Zugriffsberechtigungsprüfungsbeweis enthalten. Diese 24 Bytes sind vorzugsweise codiert, beispielsweise Basis 64 codiert, durch die Kartenbesitzer-IA, um 32 ASSII-Datenzeichen zu liefern, die an den Händler zurückgeführt werden. Der Händler gibt die UCAF-Daten in seinen systemspezifischen Kommunikationen mit dem Erfasser weiter, der dann das UCAF in der an den Aussteller gesandten Zugriffsberechtigungsprüfungs-Anforderungsnachricht vorsieht. Die generische Struktur des UCAF ist in 10 dargestellt.
  • Das UCAF-Steuerbit ist ein 1-Bytewert, der angibt, welche Datenart das UCAF für den Transport verwendet. Die nachstehend angegebenen Werte können für die Codierung des UCAF-Steuerbytes verwendet werden.
    als erster Wert 0×82 – SPA-UCAF, bei Verwendung eines Taschenservers
    als erster Wert 0×88 – Chip-UCAF, bei Verwendung einer ICC.
  • Wenn der Händler eine Rückübermittlung einer Zugriffsberechtigungsprüfung benötigt entweder infolge einer vorausgehenden Abweichung oder für gesplittete Auslieferungen, muss das obere Bit des UCAF-Steuerbytes gelöscht werden, was zu den folgenden Werten führt:
    • – als dritter Wert 0×02 – anschließende SPA-UCAF-Zugriffsberechtigungsprüfung, bei Verwendung eines Taschenservers
    • – als vierter Wert 0×08 – anschließende Chip-UCAF-Zugriffsberechtigungsprüfung, bei Verwendung eines Chips.
  • Die vorliegende Erfindung umfasst andere Zugriffsberechtigungsprüfungstechniken, wie beispielsweise biometrische, und in einem solchen Fall würde die spezifische Technik ihren eigenen Steuerbytewert einführen, und würde die Struktur der anwendungsspezifischen Daten darauf abgestimmt, einen biometrischen Zugriffsberechtigungsprüfungsablauf zu unterstützen. In diesem Fall sollten alle biometrischen Zugriffsberechtigungsprüfungsanwendungen eine folgerichtige anwendungsspezifische Datenstruktur verwenden.
  • Der Kontoinhaber-Zugriffsberechtigungsprüfungswert (AAV) ist schematisch in 11 dargestellt. Die folgenden Daten werden an den Aussteller in der UCAF übermittelt:
    • – IIPD – optional, mit variabler Länge, jedoch stets ein Mehrfaches von Bytes. Sie können eine Karten-Folgenummer, beispielsweise 4 Bits, die durch den Aussteller definiert ist, zur Anordnung in einer durch den Aussteller definierten Position in der IPD für diese Karte enthalten.
    • – eine nicht voraussagbare Zahl, beispielsweise mit einer Länge von 32 Bits (4 Bytes)
    • – IIPB-Datenbeweis, wie in dem PCR-Beweis codiert, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist. – Unbekannte Länge, Anzahl der Bits bestimmt durch das IIPB.
  • Die Länge ist vorzugsweise beschränkt, beispielsweise auf eine erste maximale Anzahl von Bits, wie beispielsweise nicht größer als 184, da idealerweise der Aussteller keine IiPB liefern sollte, die bei Kombination mit der IIPB zu mehr als einer zweiten maxima len Anzahl von Bits, beispielsweise 152 Bits (maximaler Datenbereich-Länge (UN)) führt, was seine Übermittlung erforderlich macht. Als Vorsichtsmaßnahme kann die Kartenbesitzer-IA sicherstellen, dass jede Operation, die zu mehr als dem ersten Maximum, d. h. > 184 Bits führt, zu einem Fehler führt und die Daten nicht codiert werden.
  • Es besteht keine Notwendigkeit für eine Anzeige, die in die Codierung des AAV für das Chip-UCAF zum Anzeigen eingebaut ist, ob irgendwelche IIPD-Daten vorhanden sind oder nicht. Es ist Sache des Ausstellers sicherzustellen, dass sein Hostsystem weiß, was in dem AAV zu erwarten ist. Die codierte Einschließung irgendeiner IIPD durch die Kartenbesitzer-IA hängt davon ab, ob irgendeine IIPD zu der Bezahlungskarte gehört oder nicht, die durch den Kartenbesitzer für die besondere Transaktion verwendet wird.
  • Die UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, codiert in die AAV für das Chip-UCAF kann eine solche in einer vollen 4-Byte-Größe sein, was dieselbe Größe ist wie die der UN, die der von der Abfragenachricht erzeugte Wert ist und die zu der ICC in dem AC-Erzeugungsbefehl gesandt wird. Die Größe der UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, kann innerhalb ihres vollen Bereichs geändert werden, beispielsweise entweder vergrößert oder möglicherweise sogar verkleinert werden, ohne das Datentransportformat zu beeinflussen Eine UN-Bereichsbeschränkung kann eine Folge der Beschränkung der Anzahl der Digits sein, die ein Kartenbesitzer eingeben muss, um Daten an den PCR von der MCD aus zu übermitteln. Aus Kompatibilitätsgründen kann diese Beschränkung zu sowohl bei angeschlossenen als auch bei nicht-angeschlossenen Einrichtungen Anwendung finden, es sei denn, es gäbe eine andere Angabe der Größe der PCR-Abfrage, die dem PCR dargeboten wird.
  • Der Aussteller kennt die Länge sowohl der IIPD als auch des IIPB-Datenbeweises. Die Kartenbesitzer-IA kennt die Länge der IIPD, sie kennt jedoch nicht die Länge des IIPB-Datenbeweises, und so sollte sie vorzugsweise die Bits rechts ausrichten, d. h. das am wenigsten signifikante Bit erscheint in der letzten Bit-Stellung unter Verwendung von 0 zum Auffüllen, wie in 12 dargestellt ist. Folglich werden alle links ausgerichteten Daten des IIPB-Datenbeweises, die nicht in den PCR-Beweis eingeführt worden sind, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, weil sie auf 0 eingestellt waren und daher nicht in der numerischen Beweisherleitung aufgetreten sind, auf den Wert 0 eingestellt, der angeboten wird. Dies geschieht, weil die Kartenbesitzer-IA zuerst die vollständigen 23 Bytes des AAV auf 0 eingestellt hat, was bei allen verbleibenden Bits von dem am weitesten links ausgerichteten Bit des übermittelten PCR-Beweises aus, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, zur Sicherung auf die UN führt, wobei die UN der von der Abfragenachricht erzeugte Wert ist, der die Einstellung auf 0 aufweist. Einige dieser Bits zeigen den Wert 0, den sie in dem IIPB-Datenbeweis besitzen, während der übrige Teil mit 0 aufgefüllt ist.
  • Obwohl die Kartenbesitzer-IA nicht weiß, welche Bits eine Dateneinstellung auf 0 aufweisen und welche Auffüller ebenfalls auf 0 eingestellt sind, spielt dies keine Rolle, weil der Aussteller weiß, welche Bits Daten sind, da er die effektive Länge des IIPB kennt.
  • Die Verbindung zwischen dem Händler und dem Erfasser kann systemspezifisch sein, jedoch sollte der Händler vorzugsweise die nachfolgend angegebenen zusätzlichen Daten an den Erfasser übermitteln:
    • – UCAF-Zugriffsberechtigungsprüfungsdatenfeld
    • – Fehlerstatusanzeiger
  • Der Aussteller empfängt die Zugriffsberechtigungsprüfungs-Anforderungsnachricht über das Zugriffsberechtigungsprüfungsnetzwerk von dem Erfasser. Sie enthält die Standard-Zugriffsberechtigungsprüfungsdaten zusätzlich zu einem modifizierten Sicherheitslevelanzeiger (SLI) und den UCAF-Zugriffsberechtigungsprüfungsdaten. Die Zugriffsberechtigungsprüfungs-Anforderungsnachricht enthält den SLI, der zur Verwendung mit UCAF-Transaktionen erweitert worden ist.
  • Zur Verbesserung der Genauigkeit der Kartenbesitzer-Dateneingabe kann ein einzelnes hinteres Prüfdigit verwendet werden. Die Unannehmlichkeit der Eingabe eines zusätzli chen Digits wird durch den Wert des Bestätigungschecks überwogen, den dieses Extradigit zur Verfügung stellt. Der für das Prüfdigit verwendete Algorithmus kann irgendein geeigneter Priüfalgorithmus, wie beispielsweise "Luhn Formula", auch bekannt als "Modulus 10", sein, wie er zur Bestätigung einer PAN verwendet wird. Das Prüfdigits kann bei der n-Digit-PCR-Abfrage Anwendung finden, beispielsweise fordern, dass der Kartenbesitzer, eine bestimmte Anzahl von Digits eingibt, beispielsweise 8 Digits für eine 7-Digit-Abfrage. Der persönliche Kartenleser bestätigt das Prüfdigit und informiert den Kartenbesitzer, wenn ein nicht-korrekter Wert eingegeben ist. Wenn eine kombinierte UN/Währungszahl verwendet wird, findet das Prüfdigit auf die vollständige "Zahl" Anwendung. Wenn ein nicht-korrekter Wert eingegeben ist, wird die Einrichtung das Verfahren vorzugsweise nicht verlassen oder erneut starten, sondern kann sie warten/fordern, dass die PCR-Abfrage erneut eingegeben wird. Sofern erwünscht kann eine Grenze betreffend die Anzahl der Versuche der Eingabe einer ungültigen PCR-Abfrage gesetzt werden, oder eine solche Grenze wird nicht gesetzt.
  • Für eine nicht-angeschlossene Einrichtung wird das Prüfdigit auf den angezeigten n-Digit-PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, zur Anwendung gebracht, beispielsweise indem der Kartenbesitzer aufgefordert wird, an der MCD eine bestimmte Anzahl von Digits, beispielsweise 13 Digits für einen 12-Digit-PCR-Beweis, einzugeben. Der persönliche Kartenleser berechnet das Prüfdigit und setzt es an das Ende des angezeigten PCR-Beweises, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist.
  • Für eine Einrichtung mit einem Einwegeanschluss sollte das Prüfdigit zur Anwendung gebracht werden, da eine Einwegekommunikation keine Bestätigung der Datenübermittlung im Wege des Handshakings gestattet. Die Kartenbesitzer-IA muss das Prüfdigit für diese Einrichtungen auf Richtigkeit prüfen und einen Fehler an den Kartenbesitzer melden, wenn ein solcher festgestellt wird. Dies würde zu einer Transaktion mit dem PCR führen, bei der eine Wiederholung erforderlich ist.
  • Das Prüfdigit ist ein Fehlerfeststellungsmechanismus für ein Übermittlungsmedium. Zur Kommunikation in jeder Richtung zwischen einer MCD und einer Einrichtung mit einem Zweiwegeanschluss bzw. einer integrierten Einrichtung kann das zu Grunde liegende Übermittlungsprotokoll auch alle Fehler, die sich nur auf die Übermittlung beziehen, korrigieren.
  • Die PCR-Abfrage wird an den Aussteller weitergegeben. Die PCR-Abfrage besteht aus einem Teil oder mehreren Teilen, beispielsweise 2 oder 3 Teilen, beispielsweise in Abhängigkeit davon, ob der Transaktionsbetrag in dem AC-Erzeugungsbefehl benötigt wird:
    • – nicht-voraussagbare Zahl (UN)
    • – optionaler Währungscode
    • – ein oder mehrere Prüfdigits wie beispielsweise das oben erwähnte Luhn-Prüfdigit.
  • Die PCR-Abfrage wird dazu verwendet, die nicht-voraussagbare Zahl (UN) zu schaffen. Der PCR liefert die UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, an die ICC als Teil des AC-Erzeugungsbefehls. Die UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, kann als eine volle 32-Bit-Struktur geliefert werden, die den von der Kartenbesitzer-IA erhaltenen Wert enthält. Der Bereich dieses Wertes ist vorzugsweise beschränkt. Die Größe dieses Bereichs kann durch die maximale Anzahl von Digits bestimmt werden, die für den Kartenbesitzer annehmbar erscheint, um sie in eine nicht-angeschlossene Einrichtung einzugeben. Der Ausdruck "nicht-voraussagbar" bezieht sich darauf, dass die Zahl für die ICC nicht voraussagbar ist, nicht jedoch, dass sie für eine Anwendung nicht voraussagbar ist, die den Wert an die ICC oder eine andere Einheit außerhalb der Karte liefert.
  • Die PCR-Abfrage ist vorzugsweise eine Dezimalzahl mit einer bestimmten Anzahl von Digits, die an den PCR übermittelt werden müssen. Ebenso wie die UN kann auch sie aus einem zusätzlichen hinteren Prüfdigit und einem optionalen Währungscode bestehen. Somit ist für nicht-angeschlossene Einrichtungen und Einrichtungen mit einem Einwegeanschluss, bei denen der Kartenbesitzer die Abfrage manuell übermittelt, die Anzahl der einzugebenden Digits eine Frage der Annehmlichkeit oder vielmehr der Unannehmlichkeit für den Kartenbesitzer. Für andere Arten von angeschlossenen Einrichtungen kann die Abfrage direkt weitergegeben werden, und ist daher die Anzahl der verwendeten Digits kein Problem. Da der Aussteller keine Kenntnis von der Art der durch den Kartenbesitzer für eine besondere Transaktion Einrichtung hat und dann, wenn dies der Fall ist, verwendeten sollten aus Gründen der Fähigkeit zur direkten Kommunikation alle Kartenbesitzer-IAs vorzugsweise die gleiche maximale Anzahl von Digits zur Darstellung des möglichen Bereichs der UN verwenden.
  • Die Anzahl der Digits kann beschränkt sein, beispielsweise auf 8. Der PCR hat möglicherweise keine Kenntnis von dieser "Beschränkung", da der UN-Teil, wobei die UN der von der Abfragenachricht erzeugte Wert ist, der PCR-Abfrage einfach ein Wert ist, der in die 32-Bit Struktur der UN passen muss, wobei die UN der von der Abfragenachricht erzeugte Wert ist.
  • In einem Schema, bei dem der Aussteller fordert, dass der PCR den Betrag und die Währung in dem AC-Erzeugungsbefehl, der zur Erzeugung des AC verwendet wird, das das Kryptogramm ist, einsetzt (beispielsweise wie angegeben durch die IAF-Flagssignaleinstellung in Byte 1 der IIPD), kann der PCR fordern, dass der Betrag und die Währung an ihn übermittelt werden. Um die Konfusion für den Kartenbesitzer zu verringern, die bei der Übermittlung eines 3-Digit-Währungscode an eine nicht-angeschlossene Einrichtung oder eine Einrichtung mit einem Einwegeanschluss auftreten könnte, kann der Code an das Ende der UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, gesetzt werden, der die Abfrage durchläuft. Somit gibt, wenn auf das Prüfdigit berücksichtigt wird, ein Kartenbesitzer eine insgesamt 12-Digit-Abfrage ein, wenn das Schema die Eingabe des Betrags fordert.
  • In Zusammenfassung können die Quellen der PCR-Abfrage sein:
    • – Transaktionsbetrag
    • – Transaktionswährung
    • – Name des Händlers
    • – PAN
  • Der zur Erzeugung der PCR-Abfrage verwendete Mechanismus muss direkt kommunikationsfähig sein, da der Aussteller die gleichen Aktionen an dem Hostsystem reproduzieren muss, wo die UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, auf Gültigkeit gegenüber den Quellendaten geprüft wird.
  • Der Betrag, wie er durch den Händler in den UCAF-Datenfeldern geliefert und dem Kartenbesitzer angezeigt wird, ist vorzugsweise codiert, beispielsweise BCD-codiert, rechts ausgerichtet und mit Null in 6 Bytes aufgefüllt.
  • Die Währung, wie sie durch den Händler in den UCAF-Datenfeldern geliefert und in einer Währungs-Nachschlagetabelle verwendet wird, um dem Kartenbesitzer den alphabetischen Code anzuzeigen, ist vorzugsweise codiert, beispielsweise BCD-codiert, rechts ausgerichtet und mit Null in 6 Bytes aufgefüllt.
  • Der Transaktionsbetrag und die Transaktionswährung werden vorzugsweise immer bei der Berechnung des Teils der nicht-voraussagbaren Zahl der PCR-Abfrage ohne Rücksicht auf die IAF-Einstellung (Bit 8) zur Verwendung des Betrags und der Währung verwendet. Das Flagsignal bestimmt, ob der Betrag und die Währung zusätzlich und explizit in der Kryptogramm-Berechnung verwendet werden, und bewirkt in Hinblick auf die Abfrage nur, ob die Abfrage als Übermittlungsmechanismus für den Währungscode von der Kartenbesitzer-IA an einen nicht-angeschlossenen persönlichen Kartenleser verwendet wird.
  • Der Name des Händlers, wie durch den Händler in den UCAF-Datenfeldern geliefert und dem Kartenbesitzer angezeigt, wird von den 22 Unicode-2-Byte-Zeichen, die vom Händler empfangen werden, in 22 1-Byte-ASCII-Zeichen umgewandelt. Dies kann dadurch erreicht werden, dass jedes "ungerade" Byte – das erste Byte in jeder der 22 2-Byte-Unicodesequenzen – entfernt wird.
  • Die PAN sollte codiert sein, beispielsweise BCD-codiert, in die kleinste Anzahl von Bytes und sollte dort, wo eine ungerade Anzahl von PAN-Digits geliefert wird, beispielsweise bei einer 19-Digit-Maestro-PAN, rechts ausgerichtet und mit Null in 6 Bytes aufgefüllt werden. Der Einschluss der PAN in der Abfrageerzeugung macht es erforderlich, dass die Kartenbesitzer-IA Kenntnis von der vollständigen PAN hat, die durch den Kartenbesitzer für diese Transaktion verwendet wird.
  • Ein geeigneter Verschlüsselungsalgorithmus beispielsweise ein SHA-1-Hash-Algorithmus, wird auf die verketteten Eingabedaten von 38 oder 40 Bytes zur Anwendung gebracht, die gebildet sind aus: Betrag, Währung, Name und PAN. Die ersten 4 Bytes der sich ergebenden 20-Byte-Hash-Datenstruktur werden "extrahiert" und als ein 32-Bit-Wert einer ganzen Zahl ohne Vorzeichen behandelt. Ein Modul von 100.000.000 wird dann bei diesem Wert angewendet, um einen Wert in dem Bereich bis zu 99.999.999 zu erreichen. Wenn der Währungscode übermittelt werden muss, wird er jetzt angehängt. Schließlich wird einen Prüfbit, wie beispielsweise ein Luhn-Prüfbit, an den Digits zur Anwendung gebracht, die berechnet und am Ende angehängt sind, um die Abfrage zu schaffen. Der vollständige Verfahrensablauf ist in 13 dargestellt.
  • Die PCR-Abfrage wird als eine Zahl mit einer optionalen Auffüllung bis zu 8 Digits mit 0 weitergegeben. Die Auffüllung mit 0 ist optional, da sich der PCR nicht auf eine festgelegte Anzahl von Digits für die PCR-Abfrage verlässt, sondern stattdessen einen OK/Eingabe-Knopf verwendet, um das Ende der PCR-Abfrage anzugeben. Zu dieser Zahl können der optionale Währungscode und das berechnete Prüfdigit hinzugefügt werden.
  • Dieses Übermittlungsformat sollte idealerweise für alle Arten einer Einrichtung verwendet werden, um logische Unterschiede zwischen den Einrichtungen so klein wie möglich zu halten, idealerweise sollte nur das Kommunikationsprotokoll selbst unterschiedlich sein. Dies bedeutet, dass der Unterschied zwischen der Weiterführung von Abfragedaten zu jeder Art einer Einrichtung ausschließlich auf dem Kommunikations-/Übermittlungsmechanismus und nicht auf der Verarbeitung dieser Daten beruht.
  • Da die Abfrage in dem AAV weitergeführt wird, besteht eine mögliche Optimierung für den Ausstellerhost in der Verwendung der letzten weitergeführten Abfrage bei der erneuten Berechnung des PCR-Beweises, wobei der PCR-Beweis der Berichtigungsprüfungsbeweis ist, ohne Notwendigkeit zuerst die PCR-Abfrage erneut zu berechnen. Der Nachteil dieser Optimierung besteht darin, dass der Aussteller die Gültigkeit der Abfrage nicht prüft, was später zu Erörterungen mit dem Kartenbesitzer und potenziellen Rücküberweisungen führen kann.
  • Die Realisierung des beschriebenen Schemas verwendet ein Anwendungskryptogramms (AC), wobei das Ac das Kryptogramm ist, als Mechanismus für die Zugriffsberechtigungsprüfung der ICC und des Kartenbesitzers. Der AC-Erzeugungsbefehl wird dazu verwendet, die ICC aufzufordern, entweder ein Anwendung-Anforderungskryptogramm (ARQC) oder, sofern Bit 7 des IAF auf 1 eingestellt ist,, ein Anwendungs-Zugriffsberechtigungsprüfungskryptogramm (AAC) zu erzeugen. Die Daten, die in diesem Befehl zugeführt werden können, sind:
    • – nicht-voraussagbare Zahl (UN)
    • – Betrag
    • – Währung
  • Die nicht-voraussagbare Zahl (UN) ist eine 4-Byte/32-Bit-Komponente der in dem AC-Erzeugungsbefehl der ICC zugeführten Daten. Sie ist eine Zahl bzw. deren Daten, die für die ICC im Gegensatz zu der Anwendung nicht-voraussagbar ist, und sie ist die die Transaktion betreffende Abfrage an der Karte. Die PCR-Abfrage wird dazu verwendet, die UN aufzubauen, wobei die UN der von der Abfragenachricht erzeugte Wert ist. Die maximale Zahl von 8 Digits der Abfrage berücksichtigt die unteren 27 von 32 Bits, die für die UN erforderlich sind. Die verbleibenden 5 Bits sind daher für die Zwecke dieses Schemas Null. Der Teil der UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, der PCR-Abfrage sollte als ein durchlaufender numerischer Wert verstanden werden (siehe 14). Wenn dieser numerische Wert als ganze Zahl ohne Vorzeichen mit 32-Bit behandelt wird, sind alle Bits hinter dem als signifikantesten Bit eingestellten Bit implizit auf 0 eingestellt. Wenn die UN, wobei die UN der von der Abfragenachricht erzeugte Wert ist, an die Karte gesandt wird, wird der unbearbeitete binäre Wert der Dezimalzahlen-Abfrage, die durch den Kartenbesitzer eingegeben worden ist, in dem APDU-Befehl weitergeführt. Er wird nicht als das BCD codierte Äquivalent der eingegebenen Abfragedigits verschickt.
  • Die Verwendung des Betrags und der Währung findet mit der Diskretion des Ausstellers statt. Wenn der Aussteller angezeigt hat, dass der Betrag und die Währung verwendet werden müssen, wird der persönliche Kartenleser mit den Daten des Betrags und der Währung versorgt. Die Währung wird als Teil einer verlängerten PCR-Abfrage zugeführt, und der Betrag wird explizit/separat übermittelt/eingegeben. Wenn der Aussteller angezeigt hat, dass der Betrag und die Währung nicht verwendet werden müssen, oder diese Wahl nicht angezeigt hat und der Ausgangswert der Nicht-Verwendung derselben verfolgt worden ist, dann können die Ausgangswerte für den Betrag und die Währung verwendet werden.
  • Da die vollständige Antwort auf dem AC-Erzeugungsbefehl zu groß zum Senden an den Aussteller sein kann, kann der PCR das IIPB dazu verwenden, ein Datenextraktions- und Datenkompressionsverfahren durchführen, das zu einer Kette von Bit werden führt, die nach der Bestimmung durch den Aussteller diesem mitgeteilt werden muss – siehe 15. Eine Biteinstellung von 1 kann zur Anzeige verwendet werden, dass die entsprechende Bitposition in den Daten benötigt wird und gesendet werden muss. Eine Biteinstellung von 0 kann zur Anzeige verwendet werden, dass der Aussteller entweder weiß oder in der Lage ist, anderweitig herzuleiten, wie die Biteinstellung sein sollte, und somit das Bit nicht gesendet werden muss. Der IIPB-Datenbeweis wird vorzugsweise von rechts nach links aufgebaut, wobei das erste zu extrahierende Bit als Bit 1 des letzten Bytes der Ausgangsdaten platziert wird, das zweite als Bit 2 etc. Der IIPB-Datenbeweis wird in dieser Weise aufgefüllt, bis keine weiteren Bits zur Übermittlung geblieben sind.
  • Der IIPB-Datenbeweis sind die Daten, die von dem PCR an die Kartenbesitzer-IA übermittelt werden. Alle Arten einer angeschlossenen Einrichtung übermittelten diese Daten direkt an die MCD, während eine nicht-angeschlossene Einrichtung den Kartenbesitzer zur manuellen Übermittlung dieser Daten verwendet.
  • In Hinblick auf den PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, für eine nicht-angeschlossene Einrichtung, berechnet eine nicht-angeschlossene Einrichtung eine Zahl und zeigt diese an, die das Bitmuster der zu übermittelnden Daten repräsentiert. Der Kartenbesitzer muss dann diese Zahl in den geeigneten Bereich eingeben, der in der an der MCD laufenden Kartenbesitzer-IA verfügbar gemacht ist. Ein nicht-angeschlossener PCR schafft einen numerischen Beweis, der ausschließlich zur Übermittlung von Daten von dem PCR an die an der MCD laufenden Kartenbesitzer-IA von dem IIPB-Datenbeweis erzeugt wird. Es ist wichtig, dass der zur Umwandlung der Bits in angezeigte numerische Digits verwendete Algorithmus kommunikationsfähig und somit an der Kartenbesitzer-IA reversibel ist, d. h. derselbe zur Umwandlung von Bits in einen Beweis verwendete Algorithmus muss umgekehrt werden, um einen Beweis in Bits umzuwandeln. Ein "komprimierter" Weg hierfür besteht darin, das Bitmuster als eine binäre Zahl zu behandeln und eine mathematische Umwandlung von Basis-2 zu Basis-10 durchzuführen (16).
  • Der PC-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, kann unter Verwendung von Leerräumen, Schrägstrichen oder Kommatas als Trennelement dargestellt werden und ist auf eine maximal mögliche Anzeigelänge, beispielsweise von 20 Digits, einschließlich eines oder mehrerer Prüfdigits, beschränkt.
  • Die Kartenbesitzer-IA erwartet einen in seiner Größe besonders gestalteten Beweis, da sie die vordere Auffüllung mit Null bei der Kodierung des IIPB-Datenbeweises in das UCAF zum Ausfüllen des verbleibenden Datenraums verwendet.
  • Eine Fehlerfeststellung und eine Fehlerkorrektur können vorgesehen sein. Der PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, kann von einem oder mehreren Prüfdigits, wie beispielsweise einem Luhn-Prüfdigit, in Anwendung an den vollen Beweisdigits Gebrauch machen. Die Kartenbesitzer-IA prüft das Prüfdigit auf Richtigkeit bzw. bestätigt es, um irgendwelche Übermittlungsfehler zu berichten. In dem Fall irgendeines fehlerhaften Eintastens informiert die Kartenbesitzer-IA den Kartenbesitzer, der den PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, in der Kartenbesitzer-IA erneut eingeben muss.
  • Für eine Einrichtung mit einem Einwegeanschluss kann der Kommunikationsmechanismus zwischen dem PCR und der Kartenbesitzer-IA an der MCD systemspezifisch sein, und kann jeder Fehlerfeststellungsmechanismus ebenfalls systemspezifisch sein. Jedoch muss es möglich sein, dass die Kartenbesitzer-IA erkennt, dass ein Fehler aufgetreten ist, insbesondere bei Einrichtungen mit einem Einwegeanschluss, wo es nicht möglich ist, irgendeine Art eines Handshaking-Protokolls durchzuführen und den Kartenbesitzer zu informieren. Da in dem ungewöhnlichen Fall eines Übermittlungsfehlers die Kartenbesitzer-IA nicht in der Lage ist, dem PCR von diesem Fehler zu informieren, ist es akzeptabel, den Kartenbesitzer zu bitten, das Zugriffsberechtigungsprüfungsverfahren an dem PCR wiederum von Beginn an zu wiederholen, d. h. Einsetzen der Karte/Einschalten, Eingeben der Daten und der PIN und dann Gestatten, dass der PCR erneut eine Übermittlung durchführt. Alternativ kann der PCR von einer Funktion für eine erneute Übermittlung bzw. einem Stopp für eine erneute Übermittlung Gebrauch machen.
  • Für andere Arten einer angeschlossenen Einrichtung kann der Übermittlungsmechanismus zwischen dem PCR und der Kartenbesitzer-IA an der MCD zusammen mit irgendeinem Fehlerfeststellungsmechanismus systemspezifisch sein.
  • Eine Zusammenfassung des oben beschriebenen vollständigen Verfahrens ist in 17 angegeben.
  • Verwendung des Chip-UCAF – eine Perspektive des Kartenbesitzers Die Kartenbesitzer müssen sich in das Schema eintragen. Um ein Chip-UCAF zu verwenden, muss ein Kartenbesitzer zunächst eine geeignete ICC besitzen. Dann müssen sie einen persönlichen Kartenleser (PCR, entweder angeschlossenen oder nicht- angeschlossen) und die notwendige einfache Client-Kartenbesitzer-Schnittstellenanwendung (IA)-Software installiert an einer Haupt-Zugangseinrichtung, beispielsweise einem PC, besitzen. Infolge der Art des UCAF, das ein Bezahlungs-Zugriffsberechtigungsprüfungsschema für Einzelheiten der Bezahlungskarte ist, die bereits vorgesehen worden sind, antwortet die Kartenbesitzer-Schnittstellenanwendung (IA) nur auf Zugriffsberechtigungsprüfungsanforderungen für Bezahlungskarten, deren PAN bereits bekannt ist. Daher registrieren die Kartenbesitzer vorab die Einzelheiten aller Bezahlungskarten, die für eine Bezahlung verwendet werden sollen, an der Kartenbesitzer-IA, bevor diese Karten für eine UCAF-Zugriffsberechtigungsprüfung verwendet werden können. Bei der Anforderung einer Zugriffsberechtigungsprüfung durch einen UCAF-ermächtigten Händler präsentiert der Händler die UCAF-Daten dem Kartenbesitzer. Wenn ein UCAF-Client zur Verfügung steht, führt er einen Dialog mit dem Kartenbesitzer. Kartenbesitzer müssen einen ersten und einen zweiten Code, nämlich die PAN und die IIDPD "kennen". Der Kartenbesitzer muss für die Geheimhaltung der Einzelheiten seiner PIN verantwortlich sein, sodass es in dem Fall, dass ein Versuch zur Verwendung der Karte ohne Zustimmung des Kartenbesitzers unternommen wird, für einen PCR nicht möglich ist, einen Beweis ohne die korrekte PIN zu schaffen. Der Kartenbesitzer muss den örtlichen Chip-UCAF-Client an jedem PC installieren, der möglicherweise für E-Commerce gestützte Einkäufe verwendet wird. Der Kartenbesitzer muss die Einzelheiten der PAN jeder Bezahlungskarte registrieren, die für eine UCAF-Bezahlungszugriffsberechtigungsprüfung mit der Kartenbesitzer-Schnittstellenanwendung verwendet wird, bevor versucht wird, diese Karte für eine Bezahlung und eine zugehörige Zugriffsberechtigungsprüfung zu verwenden.
  • Aus der Perspektive des Händlers
  • Der Haupt-Händler-Verfahrensablauf ist in 18 dargestellt. Die zwei Hauptaspekte den Händler betreffend sind zunächst Wechsel zu den Web-Seiten des Händlers und dann die notwendige Bearbeitung zur Unterstützung des UCAF. Damit die Händler-Server das Chip-UCAF unterstützen, müssen die Händler-Server zusätzliche Daten über ihre Web-Seiten präsentieren und zusätzliche Daten verarbeiten, die über die Kartenbesitzer-Schnittstelle eingegeben werden. Für Zwecke der Beschreibung des UCAF-Schemas im Zusammenhang mit der durch die Händler benötigten Bemühung werden zwei Arten einer Beziehung, die ein Kunde mit dem Händler als Kartenbesitzer unterhalten kann, in Betracht gezogen: profiliert, nicht-profiliert. Express-Checkout und Einzelclick erfordern, dass die Kartenbesitzer profiliert sind, während Standard-Checkouts durch profilierte und durch nicht-profilierte Kartenbesitzer in gleicher Weise verwendet werden können. Einzelclick erfordert im Allgemeinen, dass der Kunde die Einzelclick-Option zugelassen hat, da viele Kunden sich durch diese Möglichkeit eines impulsiven Einkaufs beunruhigt fühlen. Zur Verwendung der UCAF muss der Händlerserver bestimmte Bezahlungseinzelheiten des Kartenbesitzers kennen, beispielsweise die PAN, das Ablaufdatum und den CVC2, bevor eine UCAF Zugriffsberechtigungsprüfungs-Seite präsentiert wird, die die verborgenen UCAF-Datenfelder enthält, da eines der Felder die letzten 5 Digits der PAN enthalten muss, die für die Transaktion verwendet wird.
  • Zur Unterstützung der Verwendung der UCAF für das Express-Checkout (19) muss die Bestätigungsseite für die Einzelheiten des Auftrags bzw. der Bezahlung die verborgenen UCAF-Felder unterstützen, und wird sie mit Bezug auf die UCAF-Funktionalität eine UCAF-Zugriffsberechtigungsprüfungs-Seite. Dies schafft die Möglichkeit für die Kartenbesitzer-Schnittstellenanwendung (IA), sich selbst zu präsentieren und den notwendigen Dialog mit dem Kartenbesitzer zu fordern, um die UCAF-Zugriffsberechtigungsprüfungsdaten zu erhalten. Die Kartenbesitzer-IA kann dann das UCAF-Zugriffsberechtigungsprüfungsfeld vor der Vorlage des Auftrags durch den Kartenbesitzer vorsehen.
  • Zur Unterstützung der Verwendung des UCAF während des Einzelclick-Einkaufsverfahrens (20) kann der Händlerserver eine UCAF-Übermittlungsseite unterstützen. Die UCAF-Übermittlungsseite dient nicht zur Verwendung durch den Kartenbesitzer, und ihre Anzeige sollte angeben, dass ein Zugriffsberechtigungsprüfungsverfahren läuft. Diese Seite arbeitet als die UCAF-Zugriffsberechtigungsprüfungsseite und präsentiert die verborgenen UCAF-Felder. Die UCAF-Übermittlungsseite muss auch die verborgenen UCAF-Felder unterstützen und schafft die Möglichkeit für die Kartenbesitzer-Schnittstellenanwendung, sich selbst zu präsentieren und den notwendigen Dialog mit dem Kartenbesitzer anzufordern, um die UCAF-Zugriffsberechtigungsprüfungsdaten zu erhalten. Einige Händler, die den Einzelclick anbieten, bieten auch die Möglichkeit der automatischen Kombination einer Reihe von Einzelclick-Einkäufen, die innerhalb eines bestimmten Zeitfensters durchgeführt werden, zu einem einzelnen Auftrag. D. h. "ich will das haben – Click-das – Click – o ja und das-Click". Wenn mehrere benachbarte Einzelclick-Einkäufe kombiniert werden, wird die Zugriffsberechtigungsprüfung im Allgemeinen nur aufgesucht, nachdem der Auftrag "geschlossen" ist und die kombinierten Kosten bekannt sind. Hierdurch wird das Problem hinterlassen, wie die für die Zugriffsberechtigungsprüfung verwendeten Beträge gegenüber dem für die die Zugriffsberechtigungsprüfung verwendeten Betrag aufzulösen ist, sowie die Unterbrechung des Einzelclick-Verfahrens. Händler können sich für eine Zugangsberechtigungsprüfung entscheiden;
    • – Nur der anfängliche Einkauf einer kombinierten Einzelclick-Einkaufsaktion – durch spezielle Anordnung würde der Erfasser dann die Genehmigung behandeln müssen, als wäre sie eine für eine Währung konvertierte Genehmigung. Dies bedeutet die Ausgabe des anfänglichen Betrags – der für das Zugriffsberechtigungsprüfungsverfahren verwendete Betrag, sodass die Bestätigung der Zugriffsberechtigungsprüfung stattfinden könnte.
  • Jeder kumulative Einkauf – jeder Einzelclick ist durch eine Anforderung einer Zugriffsberechtigungsprüfung (UCAF-Übermittlungsseite) an den Kartenbesitzer begleitet, und jederzeit wächst der Betrag zusammen mit dem gegenwärtigen gesammelten Gesamtbetrag. Nur die letzte UCAF-Zugriffsberechtigungsprüfung würde dann an den Aussteller gesendet
  • Die UCAF-Übermittlungsseite wird benötigt, wenn ein Kartenbesitzer unter Verwendung des UCAF einen Einzelclick-Checkout initiiert, um in der Lage zu sein, das Zugriffsberechtigungsprüfungsverfahren aufzurufen und die UCAF-Daten zu liefern. Somit muss der Händler wissen, ob das UCAF verwendet wird, bevor die Einzelclick-Option durch den Kartenbesitzer gewählt wird. Ein zusätzliches verborgenes Feld, das UCAF-ermächtigte Feld, muss auf wirklich jeder Seite unterstützt werden, die die Einzelclick-Checkout-Option vorsieht.
  • Die Kartenbesitzer-Schnittstellenanwendung erkennt dieses Feld und füllt das Feld mit einem bestimmten Wert, wie beispielsweise "01", automatisch auf um anzuzeigen, dass eine UCAF-gerechte Kartenbesitzer-IA die Bezahlung ermöglicht.
  • Die UCAF-Übermittlungsseite muss nicht angezeigt werden, wenn ein Einzelclick-Checkout ohne eine UCAF-gerechte Kartenbesitzer-IA initiiert wird, die die UCAF-Zugriffsberechtigungsprüfung für die durch den Kartenbesitzer verwendete besondere Karte durchführen kann.
  • Zur Minimierung des Einflusses auf das Einzelclick-Konzept und zum Abschließen des Formblattauffüllverfahrens auf der UCAF-Übermittlungsseite, was dem Händler das Sammeln der Daten gestattet, initiiert die Kartenbesitzer-IA ein Clickereignis an einem verborgenen Knopf. Der Händler stellt den verborgenen Knopf, den "UCAF-Aufrufen"-Knopf, auf der UCAF-Übermittlungsseite zur Verfügung. Dieser Knopf gestattet es, dass die Kartenbesitzer-IA ein Clickereignis initiiert, wenn das Auffüllen des Formblatts abgeschlossen ist. Wenn das Clickereignis stattfindet, übermittelt die "Seite" die Daten, die der Zugriffsberechtigungsprüfungsanforderung zu senden sind, an den Webserver des Händlers.
  • Da die IA nicht sagen kann, ob eine Seite eine Übermittlungsseite ist oder nicht, wenn ein UCAF-Aufrufen-Knopf die benötigten UCAF-Dateneingabefelder und das Zugriffsberechtigungsprüfungsfeld auf einer Seite begleitet, wird die IA bei Beendigung des Verfahrens zur Erzeugung des Zugriffsberechtigungsprüfungsbeweises stets an ihm arbeiten. Die Händler sind frei, diese Möglichkeit zu verwenden, wenn sie dies wünschen, d. h. sie können "Auto Aufrufen" auf den herkömmlichen UCAF-Zugriffsberechtigungsprüfungsseiten verwenden, wenn sie dies zu tun wünschen.
  • Wenn die IA Fehler feststellt, die zu der Einstellung spezifischer Fehleranzeigeinhalte in das UCAF-Zugriffsberechtigungsprüfuungs-Datenfeld führen oder wenn der Kartenbesitzer eine Löschung durchführt und ein Aufrufen-Knopf für die UCAF vorhanden ist, wird die IA noch an dem Klickereignis arbeiten, wobei die Formblattdaten für den Händler aufgerufen werden. Händler, die wünschen, nur "gute" Zugriffsberechtigungsprüfungsdaten zu senden, sollten daher Kenntnis von den Fehleranzeigen haben und in Betracht ziehen, eine geeignete Fehlerseite an den Kartenbesitzer zurückzuführen.
  • Zur Unterstützung der Verwendung des UCAF für ein Standard-Checkout (21) muss die Bestätigungsseite der Auftragseinzelheiten/Bezahlungseinzelheiten die verborgenen UCAF-Felder unterstützen, und wird sie zu einer UCAF-Zugriffsberechtigungsprüfungsseite. Dies schafft die Möglichkeit, dass die Kartenbesitzer-Schnittstellenanwendung (Kartenbesitzer-IA) sich selbst präsentiert und den notwendigen Dialog mit dem Kartenbesitzer fordert, um die UCAF-Zugriffsberechtigungsprüfungsdaten zu erhalten. Die Kartenbesitzer-IA kann dann das UCAF-Zugriffsberechtigungsprüfungsfeld vor dem Aufruf des Auftrags durch die Kartenbesitzer verbreiten.
  • Zur Verwendung des UCAF muss der Händler Kenntnis von den Bezahlungseinzelheiten des Kartenbesitzers, der PAN, dem Ablaufdatum und dem CVC2 haben, bevor eine UCAF-Zugriffberechtigungsseite mit verborgenen UCAF-Datenfeldern präsentiert wird, da eines der Felder die letzten 5 Digits der für die Transaktion verwendeten PAN enthalten muss. Daher muss bei Verwendung des UCAF die kombinierte Seite der Bestätigung von Auftragseinzelheiten und der Anforderung von Bezahlungseinzelheiten in zwei Seiten, wie dargestellt, aufgeteilt werden.
  • Die UCAF-Zugriffsberechtigungsprüfungs- oder Übermittlungsseiten sind Webseiten, die der Händler den Kartenbesitzer präsentiert um die Information der Auftragseinzelheiten und Bezahlungseinheiten zu bestätigen. Für UCAF-ermächtigte Händler sind diese Seiten die Möglichkeit, über die UCAF-Daten präsentiert und erfasst werden, bevor eine Zugriffsberechtigungsprüfung versucht wird. Daher sind die UCAF-Zugriffsberechtigungsprüfungsseite und die UCAF-Übermittlungsseite die primären Verknüpfungspunkte zwischen Händler, Kartenbesitzer und Aussteller.
  • Die UCAF-Zugriffsberechtigungsprüfungsseite enthält spezifische Daten zu dem Kartenbesitzer und der Transaktion, die über das öffentliche Internet übertragen werden. Daher sollte die UCAF-Zugriffsberechtigungsprüfungsseite vorzugsweise unter Verwendung eines ausreichend sicheren Verschlüsselungsverfahrens (beispielsweise 128-Bit SSL oder äquivalent hierzu) geschützt werden, um die Gefährdung dieser Daten zu verhindern.
  • Jeder Dialog des Händlerservers mit der Kartenbesitzer-IA in dem auf dem PC-Browser basierenden Kanal erfolgt über verborgene HTML-Formblattfelder. Zur Sicherstellung der Durchführbarkeit einer gegenseitigen Kommunikation mit allen Händlern und allen UCAF-Anwendungen ist die Implementierung dieser verborgenen Felder standardisiert worden, wobei die Benennung von Konventionen, Größe und erlaubtem Inhalt eingeschlossen sind.
    • – Eintreffende Datenfelder, d. h. solche, die von dem Händler geliefert werden, erscheinen auf der HTLM-Seitenquelle, die von dem Händler-Webserver an den Kartenbesitzer-Browser geliefert wird. Die Werte für diese Felder werden direkt innerhalb der Seitenquelle eingestellt und in einem Zeichenstringformat ausgedrückt. Beispielsweise <Eingabeart = "VERBORGEN"; Name = "UCAF-Währungscode" Wert = "978"
    • – Auslaufende Datenfelder, d. h. solche, die durch den Kartenbesitzer zurückgeführt werden, erscheinen auf der HTLM-Seitenquelle, die von dem Händler-Webserver an den Kartenbesitzer-Browser geliefert wird. Die Werte für diese Felder werden anfänglich auf Leerwerte innerhalb der Seitenquelle eingestellt. Beispielsweise <Eingabeart = "VERBORGEN"; Name = "UCAF-Zugriffsberechtigungsprüfung-Daten" Wert = "".
  • Die Kartenbesitzer-IA wird im Wege eines Dialogs mit dem Dokumentenobjektmodel (DOM) des Browsers die Werte programmtechnisch als Zeichenstring einstellen.
  • Für vom Händler gelieferte, eintreffende Daten präsentiert der Händlerserver die Datenwerte, die er in den folgenden verborgenen Formfeldern zur Verfügung stellen muss:
    • – Name des UCAF-Händlers – der Name des Händlers besteht aus 88 hexadezimalen Zeichen (0–9, A–F) in der Form von 22 Gruppen mit 4 Zeichen, wobei jede Gruppe ein Unicodezeichen darstellt. Der von dem Händler gelieferte Name in dem UCAF-Feld ist der Name, der dem Kartenbesitzer durch die Kartenbesitzer-Schnittstellenanwendung (Kartenbesitzer-IA) angezeigt wird. Er ist auch der Name, der bei der Erzeugung der Abfrage verwendet wird.
    • – UCAF-Stadt – bis zu 13 Zeichen, die Stadt, in der der Händler mit seiner Erfasserdatenbank registriert ist.
    • – UCAF-Staat-Land – bis zu 3 Zeichen für den US-Staatencode oder 3 Zeichen des alphabetischen ISO 3166 Ländercodes.
    • – UCAF-Währungscode – der ISO 4217 Code mit drei Digits für die Währung der Transaktion.
    • – UCAF-Verkaufsbetrag – bis zu 12 Digits für den Betrag der Transaktion in den durch den Währungscode angegebenen Einheiten der Basiswährung.
    • – UCAF-MTS – ein optionales Feld mit der hexadezimalen Darstellung einer Händlerreferenz mit zwei Bytes.
    • – UCAF-Marke – ein Code mit zwei Digits, der die Marke der Bezahlungskarteneinzelheiten darstellt, die für diese Transaktion durch den Kartenbesitzer gewählt werden.
    • – UCAF-Nummer der Bezahlungskarte – die letzten 5 Digits der Bezahlungskarteneinzelheiten, die für diese Transaktion durch den Kartenbesitzer gewählt ist. Diese wird durch die Kartenbesitzer-IA(s) zur Bestimmung verwendet, ob die gerade verwendete Karte eine solche ist, mit der sie vertraut sind und die daher in Hinblick auf der Erzeugung eines UCAF-Zugriffsberechtigungsprüfungswertes wird für den Kontoinhaber arbeiten kann.
  • In Hinblick auf die vom Kartenbesitzer zurückgeführten, auslaufenden Daten präsentiert der Händler die folgenden verborgenen Felder, um eine Zugriffsberechtigungsprüfungsinformation zu sammeln:
    UCAF-Zugriffsberechtigungsprüfungsdaten – auf leer einstellen, d. h. '=""' durch den Händler und übernommen durch die Kartenbesitzer-IA mit den UCAF Zugriffsberechtigungsprüfungsdaten. Die Daten werden an den Händler in der üblichen Weise für HTML-Formblaattdaten zurückgeführt. Dies bedeutet, dass alle Formblattfelder an den Händlerwebserver des in einer HTTP-Absende-Anforderung im Textformat "abgesandt" werden. Sowohl die eintreffenden als auch die auslaufenden Felder werden mit dem Webserververfahren des Händlers zurückgesandt, das unterscheidet zwischen Daten, an denen ein Interesse als zurückgeführte Daten besteht, und Daten, denen keine Beachtung geschenkt wird, da sie ursprünglich gesendete Daten sind. d. h. der Read-Only-Aspekt der eintreffenden Felder wird durch die Verarbeitung des Händlers wirksam verstärkt, wobei kein Gebrauch von den Daten gemacht wird, die durch den Browser gesandt werden.
  • In Hinblick auf die zusätzlichen UCAF-Felder zur Unterstützung des Einzelclick, damit der Händler in der Lage ist, das UCAF zu unterstützen und die UCAF-Übermittlungsseite während einer Einzelclick-Bezahlung zu präsentieren, müssen die folgenden verborgenen Formblattelemente auf wirklich jeder Seite vorhanden sein, sodass es möglich ist, eine Einzelclick-Bezahlungsoption auszuwählen aus:
    • – UCAF-Nummer der Bezahlungskarte – die letzten 5 Digits der Bezahlungskarteneinzelheiten, die für diese Transaktion durch den Kartenbesitzer gewählt ist. Diese wird durch die Kartenbesitzer-IA(s) zur Bestimmung verwendet, ob die gerade verwendete Karte eine solche ist, mit der sie vertraut sind und die daher in Hinblick auf der Erzeugung eines UCAF-Zugriffsberechtigungsprüfungwert für den Kontoinhaber arbeiten kann.
    • – UCAF-ermächtigtes Einstellen auf 0, d. h. '="00" oder Leerraum, d. h. '=""', durch den Händler und einstellen auf "01" durch die Kartenbesitzer-IA, wenn 1 angegeben ist und die Nummer der Bezahlungskarte mit einer der Kartenbesitzer-IA bekannten Bezahlungskarte zusammenpasst.
  • Kartenbesitzer können wählen, ein Einzelclick-Bezahlungsverfahren aus Gründen seiner Bequemlichkeit und wegen des Fehlens eines erforderlichen Dialogs zu verwenden. Zur Aufrechterhaltung dieses einfachen Ablaufs für die Kartenbesitzer bei Verwendung der Extra-Zugriffsberechtigungsprüfungserfordernisse des UCAF ist ein Aufrufknopf für ein Formblatt zur Verfügung gestellt. Die Kartenbesitzer-IA initiiert ein Klickereignis, um die UCAF Übermittlungsseite für den Händler bei Abschluss des Erhaltens und Verwendens der UCAF-Zugriffsberechtigungsprüfungsdaten automatisch aufzurufen.
  • Zur ordnungsgemäßen Realisierung dieses Klickereignisses benötigt die UCAF-Übermittlungsseite das nachfolgend angegebene, zusätzliche, verborgene Formblattelement:
    • – Aufruf des UCAF-AAV – der verborgene virtuelle Knopf für die Kartenbesitzer-IA zum Initialisieren eines Klickereignisses.
  • Der Händlerserver kann relevante Daten empfangen und speichern. Der Händlerserver kann das von der Kartenbesitzer-Schnittfstellenanweldung gelieferte UCAF-Zugriffsberechtigungsprüfungs-Datenfeld aufnehmen und aufrechterhalten. Das Zugriffsberechtigungsprüfungs-Datenfeld versorgt den Händler mit Daten, die den Kartenbesitzer mit Transaktionen verbinden. Diese Daten sind für den Aufruf anschließender Zugriffsberechtigungsprüfungen für gesplitteten Versand erforderlich und können für den Händler während der Verarbeitung von Ausnahmen von Wert sein.
  • Die Händler müssen eine Zugriffsberechtigungsprüfung für alle Chip-UCAF-E-Commerce-Transaktionen anfordern. Die Händler müssen das UCAF bei allen Versuchen einer zur Zugriffsberechtigungsprüfung liefern. Anschließende Versuchen einer Zugriffsberechtigungsprüfung müssen ebenfalls das AAV aufweisen. Jedoch muss der Händler das Steuerbyte für anschließende Zugriffsberechtigungsprüfungen einstellen. Der Aussteller kann anfängliche Anforderungen von Zugriffsberechtigungsprüfungen mit einem AAV älter als eine bestimmte Zeit, beispielsweise 30 Kalendertage, ablehnen.
  • Die UCAF-Zugriffsberechtigungsprüfungsdaten müssen nicht in Echtzeit an die Aussteller gesandt werden, eben weil die Zugriffsberechtigungsprüfungen nicht in Echtzeit gesandt werden müssen. Anforderungen einer Zugriffsberechtigungsprüfung, die UCAF-Zugriffsberechtigungsprüfungsdaten enthalten, müssen nicht irgendwie unterschiedlich zu normalen Anforderungen einer Zugriffsberechtigungsprüfung in Hinblick auf das Stapeln von Daten behandelt werden, die dem Erfasser des Händlers gesandt werden. Vorab-Zugriffsberechtigungsprüfungen sind auch gestattet und werden wie anfängliche Zugriffsberechtigungsprüfungen behandelt.
  • Wiederkehrende Bezahlungstransaktionen sollten die AAV-Daten für nur die anfängliche Zugriffsberechtigungsprüfung aufweisen. Die anfängliche Zugriffsberechtigungsprüfung für eine wiederkehrende Bezahlung kann für eine Chip-UCAF-Verarbeitung akzeptabel sein. Die Händler müssen die UCAF-Daten in wiederkehrenden Bezahlungs-Zugriffsberechtigungsprüfungen für wiederkehrende Transaktionen nicht vorsehen.
  • Der Händler sind gehalten, eine Zugriffsberechtigungsprüfung für jeden Teil eines gesplitteten Versandes zu erhalten. Die Händler müssen das UCAF mit jeder sowohl anfänglichen als auch nachfolgenden Anforderung einer Zugriffsberechtigungsprüfung liefern. Das Versäumnis, das Steuerbytes bei nachfolgenden Zugriffsberechtigungsprüfungen zu modifizieren, kann zu einer Ablehnung durch den Aussteller zur Zeit einer Zugriffsberechtigungsprüfung führen.
  • Die Händler können genötigt sein, eine Anforderung einer Zugriffsberechtigungsprüfung zu wiederholen, beispielsweise empfangen sie keine Antwort auf die ursprüngliche Anforderung einer Zugriffsberechtigungsprüfung innerhalb einer gewissen Unterbrechungszeit, oder sie empfangen andere Anzeichen für einen Fehler bei der Datenübermittlung an den Erfasser. Unter solchen Umständen sollten die UCAF-Zugriffsberechtigungsprüfungsdaten wie für eine anfängliche Zugriffsberechtigungsprüfung behandelt werden. Vorhandene Protokolle zeigen den Erfassern an, ob die Anforderung einer Zugriffsberechtigungsprüfung Wiederholungsaufruf oder ein erneuter Aufruf ist.
  • Unter gewissen Umständen kann ein Händler eine zweite Anforderung einer Zugriffsberechtigungsprüfung für eine gegebene Chip-UCAF-Transaktion erzeugen, die denselben AAV-Wert wie die Original-Transaktion hat.
  • In den folgenden Ausführungen werden die Anforderungen für eine Zugriffsberechtigungsprüfung, die nicht bitweise identisch mit der Originalanforderung sind, angesprochen – beispielsweise können die Anforderungen einer Zugriffsberechtigungsprüfung unterschiedliche ID-Nummern der Systemspeicherspur aufweisen. Ein Händler kann zweite Anforderungen einer Zugriffsberechtigungsprüfung erzeugen, wenn:
    • – sie eine erneute Übermittlung einer Anforderung einer Zugriffsberechtigungsprüfung nach einer anfänglichen Ablehnung wünschen;
    • – sie die ursprüngliche Zugriffsberechtigungsprüfung vollständig zurückweisen, jedoch später entscheiden, sie wieder in Kraft zu setzen. Die Händler sollten solche Zugriffsberechtigungsprüfungen als anschließende Zugriffsberechtigungsprüfungen behandeln, indem sie den Wert des Steuerbytes modifizieren. Dies verhindert, dass sie bei der Möglichkeit der AAV-Bestätigung fälschlicherweise als mögliche Replayangriffe zurückgewiesen werden.
  • Die Händler sollten sich nicht mit dem Inhalt der UCAF-Daten befassen, Da dies für die Herausgeber bestimmt ist, ausgenommen unter zwei Umständen:
    • – Modifikation des Steuerbytes bei der Durchführung nachfolgender Zugriffsberechtigungsprüfungen;
    • – Prüfung von durch die Schnittstellenanwendung festgestellten Fehlern, die dem Händler über bestimmte UCAF-Inhalte berichtet worden sind.
  • Beispielsweise bei der Verarbeitung nachfolgender Zugriffsberechtigungsprüfungen infolge eines gesplitteten Versandes müssen die Händler das Steuerbyte des in der anfänglichen Zugriffsberechtigungsprüfung enthaltenen UCAF von dem durch die Kartenbesitzer-Schnittstellenanwendung eingestellten Wert durch Löschung des oberen Bits modifizieren. Dies zeigt, dass die UCAF-Zugriffsberechtigungsprüfung als Teil einer Zugriffsberechtigungsprüfung im Anschluss an die anfängliche Zugriffsberechtigungsprüfung durchgeführt wird.
  • Das Steuerbit kann durch eine Basis-64-Decodierung der UCAF-Daten, um den 24-Byte-Wert zu erhalten, Änderung des Werts des ersten Bytes und dann erneutes Basis-64-Codieren, um ein erneuertes UCAF zu schaffen, modifiziert werden. Oder einfach durch Änderung des ersten Basis-64-codierten Zeichens durch Subtraktion der Konstante 38 von dem ASCII-Zeichenwert des ersten Zeichens, um einen neuen Wert für das erste Zeichen zu schaffen.
  • Wenn die Kartenbesitzer-IA Fehler in den durch den Händler gelieferten Daten entweder über Datenformat-/Gültigkeitsprobleme oder durch das Fehlen von benötigten, verborgenen UCAF-Feldern oder auf Grund ihrer eigenen inneren Probleme feststellt, wird die Kartenbesitzer-IA versuchen, den Händler zu informieren. Da das UCAF ein Zugriffsberechtigungsprüfungsmechanismus und kein Bezahlungsschema ist, sind die Händler frei, ihre eigene Beurteilung zu treffen, ob das Zugriffsberechtigungsprüfungsverfahren mit nicht-zugeführten UCAF-Daten oder solchen mit angezeigtem Fehler fortgesetzt werden soll.
  • Wenn der Kartenbesitzer das Zugriffsberechtigungsprüfungsverfahren annulliert, wird das verborgene UCAF-Feld, das als UCAF-Zugriffsberechtigungsprüfungsdaten bezeichnet wird, auf einen leeren Wert eingestellt, und erscheint es somit nicht anders als dann, wenn es keinen UCAF-Client gibt.
  • Der Händlerserver besitzt die Fähigkeit, das Vorhandensein von UCAF-Daten in einem Bericht festzustellen, der auf seiner UCAF-Zugriffsberechtigungsprüfungsseite oder UCAF-Übermittlungsseite aufgerufen wird. Wenn UCAF-Zugriffsberechtigungsprüfungsdaten vorhanden sind, muss der Händler sie unverändert für den Erwerber zur Übermittlung der anfänglichen Zugriffsberechtigungsprüfungen aufrufen. Der Händler modifiziert nur den Wert des Steuerbytes für die nachfolgenden Zugriffsberechtigungsprüfungen. Der Händler kennzeichnet auch die Transaktion als UCAF-ermächtigt mit einem Flagsignal, sodass der Erwerber in der Lage ist, den Sicherheitslevelanzeiger mit dem geeigneten Wert zu verbreiten.
  • An der Verbindung zwischen dem Händler und dem Erwerber kann ein Teil des Dateninhalts gegen Modifikation unterwegs durch die Verwendung der Anwendung einer MAC geschützt werden, und in einem solchen Fall können die UCAF-Daten auch als Eingang zu der MAC enthalten sein.
  • Funktionelle Erfordernisse der Kartenbesitzer-Schnittstellenanwendung Die Schnittstellenanwendung des persönlichen Kartenlesers (Kartenbesitzer-IA) ist die Komponente der Software, die als Schnittstelle zwischen dem Händler, dem Kartenbesitzer und über den Kartenbesitzer dem persönlichen Kartenleser (PCR) arbeitet. Die Standard-Kartenbesitzer-IA nimmt nicht an dem Entscheidungsverfahren für das Bezahlungsinstrument teil, obwohl die Verkäufer frei sind, eine Unterstützung für eine größere Funktionalität hinzuzufügen, die in der Tat eine Unterstützung für den Kartenbesitzer bei der Wahl der geeigneten Bezahlungskarte einschließen kann. Die Kartenbesitzer-IA muss, wenn aufgerufen, die folgenden Aktionen durchführen:
    • – Abrufen von Daten von dem Kanal.
    • – Bestimmen, ob die gerade für die Transaktion verwendete PAN eine ihr bekannte PAN ist.
    • – Bestätigen bzw. Gültigerklären der Transaktionsdaten des Händlers.
    • – Anzeigen der Transaktionseinzelheiten bei dem Kartenbesitzer.
    • – Sicherstellen, dass die gewählte PAN und jeder Name, über den diese Karte der IA bekannt ist, klar angezeigt wird, um den Kartenbesitzer des gegenständlichen ICC daran zu erinnern, dass sie zur Durchführung der Zugriffsberechtigungsprüfung verwenden zu müssen.
    • – Berechnen und Anzeigen der Anforderung des PCR.
    • – Sicherstellen, dass Instruktionen angezeigt werden oder verfügbar sind, sodass der Kartenbesitzer Kenntnis von den Aktionen hat, die er unternehmen muss, einschließlich der Eingabe seiner PIN an dem persönlichen Kartenleser.
    • – Warten, dass der Beweis durch den Kartenbesitzer als Anzeichen der Genehmigung des Kartenbesitzers eingegeben wird.
    • – Verbreiten des AAV in dem UCAF und Basis-64-Codieren der sich ergebenden UCAF-Daten.
    • – Ausstatten des Kanals mit dem benötigten UCAF-Datenfeld.
    • – Instruieren des Kartenhalters, die Daten für den Händler aufzurufen oder, wenn ein Einzelclick-Verkauf verarbeitet wird, in dem PC-Browserkanal "Auslösen" des Aufrufknopfs für ein Clickereignis.
    • – Abschließendes Durchführenden irgendeiner optionalen Protokollierung.
  • Die Kartenbesitzer-IA sollte automatisch aktiviert werden, wenn der geeignete Punkt in dem Händler-Beauftragungsverfahren erreicht worden ist. Die Kartenbesitzer-IA ist in der Lage, die Daten von dem Händler über den Versorgungskanal zu empfangen, der durch diese Kartenbesitzer-IA unterstützt wird und in der geeigneten Kanalspezifikation spezifiziert ist. Die Kartenhalter-IA erklärt die Eingabedaten des Händlers für gültig und fährt nur mit Transaktionsdaten fort, die gültig sind. Die Kartenbesitzer-IA erhält auch bestimmte Eingabedaten von dem Kartenbesitzer betreffend die Bezahlungskarte, die für die Transaktion verwendet wird. Die Kartenbesitzer-IA zeigt dem Kartenbesitzer eine Information zu der Transaktion an, die den Betrag der Transaktion in einer Darstellung enthalten müssen, die Währungsbuchstaben, beispielsweise EUR, USD etc. mit der korrekten Betragformatierung enthalten muss. Die PCR-Anforderung wird dem Kartenbesitzer mit einer klaren Instruktionen angezeigt, dass diese in den PCR eingegeben werden muss. Es wird ebenfalls klar angezeigt, dass es erforderlich ist, dass der Kartenbesitzer seine PIN in den PCR eingibt und dass der sich ergebende PCR-Beweis, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, in die Kartenbesitzer-IA eingegeben werden sollte.
  • Die Kartenbesitzer-IA erzeugt die PCR-Anforderung oder veranlasst diese Erzeugung, und beim Empfangen des PCR-Beweises, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, verbreitet die IA den AAV, und sie das das UCAF Basis-64-codiert.
  • Die Kartenbesitzer-IA ist in der Lage, UCAF-Daten an der Händlerserver über den Versorgungskanal zu senden, der durch die Kartenbesitzer-IA unterstützt wird und in der geeigneten Kanalspezifikation spezifiziert ist.
  • Die Kartenbesitzer-IA kann auch zusätzliche Möglichkeiten die "einfach zu verwenden" sind, wie beispielsweise eine automatische Feldauffüllungsfunktionalität für Bezahlungseinzelheiten, PAN, Ablaufdatum und zusätzliche Kundeneinzelheiten wie beispielsweise Adresse vorsehen. Es ist ohne Weiteres möglich, dass der Kartenbesitzer mehr als eine Bezahlungskarte bei der Kartenbesitzer-IA registriert, und so würde die Kartenbesitzer-IA dann dem Kartenbesitzer in irgendeiner Formblattausfüllung die Wahl anbieten, welche Karte für eine besondere Bezahlung verwendet wurde. Die Einzelheiten für diese Erfordernisse liegen außerhalb des Umfangs dieses Dokuments. Die IA kann eine ECML(E-Commerce Modelling Language)-Formblattausfüllung und eine automatische Ausfüllung des Feldnamens "beste Schätzung" unterstützen.
  • Der Händler muss die letzten 5 Digits der Nummer der Bezahlungskarte in den Nummernfeld der UCAF-Bezahlungskarte auf irgendeiner Seite liefern, auf der er nach einem Dialog mit einer UCAF-Kartenbesitzer-Schnittstellenkarte-IA sucht, die an dem Kartenbesitzer-PC installiert sein könnte. Kartenbesitzer-IAs müssen nur aktiviert sein, um eine Karte auf Zugriffsberechtigung zu prüfen, von der er bereits frühere Kenntnis hat, d. h. ob die von dem Händler gelieferten letzten 5 Digits mit den letzten 5 Digits mit einer der bei der Kartenbesitzer-IA registrierten Karten zusammenpassen.
  • Wenn zum Laufen ermächtigt integriert sich die Kartenbesitzer-IA in das Internet-Browserverfahren oder bringt sich anderweitig selbst an, dies in einer solchen Weise, dass sie in der Lage ist, die Feldnamen von Feldern innerhalb von Formblättern auf einer gegebenen Webseite zu bestimmen, wenn Seiten geladen und in dem Browser angezeigt werden.
  • Wenn irgendwelche der definierten UCAF-Formblattfelder erkannt werden, muss die Anwendung dann die UCAF-Verarbeitung starten und die notwendigen Daten aus diesen Feldern extrahieren, um mit dem Zugriffsberechtigungsprüfungsverfahren fortzufahren.
  • Der Ablauf der Aktivierung der Kartenbesitzer-IA ist in 22 dargestellt.
  • Der persönliche Kartenleser (PCR) ist eine Komponente des Chip-UCAF-Schemas. 23 ist eine schematische Darstellung des Konzepts des Ablaufs der PCR-Verarbeitung.
    • 1. Die Verarbeitung beginnt, wenn der Kartenbesitzer eine ICC 5 in eine angeschlossene oder eine nicht-angeschlossene Einrichtung einsetzt. Im Folgenden wird eine nicht-angeschlossene Einrichtung angenommen.
    • 2. Der PCR sucht nach der ICC 5 und relevanten Programmen auf der Karte und bestätigt die Karte dem Kartenbesitzer durch Anzeigen des Anwendungslabels für eine kurze Zeitspanne.
    • 3. Der persönliche Kartenleser liest das systemspezifische Herausgeber-Internet-Bitmuster (IIPB) aus der ICC 5. Wenn die Länge des IIPB falsch ist oder wenn die Anzahl der Bits, die zu übermitteln sind, angezeigt durch das IIPB, für den besonderen persönlichen Kartenleser zu hoch ist, zeigt der persönliche Kartenleser die Nachricht an: fataler Fehler.
    • 4. Der persönliche Kartenleser fordert den Kartenbesitzer auf, die Anforderung einzugeben. Die Anforderung enthält die Daten, die für die nicht-voraussagbare Zahl (UN) verwendet werden, den Transaktionswährungscode (optional) und ein hinteres Prüfdigit.
    • 5 Der Kartenbesitzer gibt die 12-Digit-Zahl ein, die in einer Aufforderung auf der Haupt-Zugangseinrichtung angezeigt wird, und der PCR führt eine Prüfung auf Fehler durch. Der persönliche Kartenleser bestimmt, dass das Prüfdigit korrekt ist, und informiert den Kartenbesitzer, ob die Anforderung gültig ist oder ungültig ist. Im Falle der Ungültigkeit verlangt der PCR erneut die Anforderung.
    • 6. Der persönliche Kartenleser fordert den Kartenbesitzer auf, den Betrag der Transaktion einzugeben. Wenn die Zugriffsberechtigungsprüfung der Transaktion nicht von dem Transaktionsbetrag Gebrauch macht, wird dieser Schritt vollständig übersprun gen. Da die Anforderung den Transaktionswährungscode enthielt, setzt die Anzeige das Währungssymbol mit seinen 3 Buchstaben am Ende der Anzeigezeile als eine sichtbare Bestätigung der Währung für den Kartenbesitzer ein.
    • 7. Der Kartenbesitzer gibt die angezeigte Summe bei einer Aufforderung an seiner Haupt-Zugangseinrichtung ein.
    • 8. Der Kartenbesitzer muss jetzt seine PIN eingeben, und so zeigt der persönliche Kartenleser eine Aufforderung für den Kartenbesitzer an, seine PIN einzugeben.
    • 9. Der Kartenbesitzer gibt seine PIN-Digits ein und drückt "eingeben".
    • 10. Der persönliche Kartenleser gibt die PIN an die ICC weiter. Wenn die ICC als Rückantwort eine ungültige PIN-Eingabe berichtet, informiert der persönliche Kartenleser den Kartenbesitzer über die Anzahl der verbleibenden Versuche, ansonsten meldet er eine gültige PIN.
    • 11. Die Einrichtung bereitet einen AC-Erzeugungsbefehl unter Verwendung der Transaktionsdaten wie der nicht-voraussagbaren Zahl und des Betrags und des Währungcodes vor, die alle durch den Kartenbesitzer eingegeben worden sind. Der Befehl wird an die ICC gesendet. Wenn die Zugriffsberechtigungsprüfung der Transaktion keinen Gebrauch von dem Transaktionsbetrag macht, werden Ausgangswerte, jedoch falsche Werte, für den Betrag (0) und den Währungscode (999) verwendet.
    • 12. Die ICC antwortet, und der PCR verwendet die IIPB, die von der Karte herunter gelesen wird, um die Bits aus der Antwort auf den AC-Erzeugungsbefehl zu bestimmen, die gestrippt und in einen Befehl zusammen gepresst werden müssen. Wenn keine IIPB auf der ICC gefunden wird, wird der in dem Leser gespeicherte Ausgangswert der IIPB verwendet. Wenn die Länge der IIPB falsch ist, zeigt der persönliche Kartenleser die Nachricht an: fataler Fehler.
    • 13. Die Einrichtung rechnet dann und zeigt einen numerischen Beweis mit n-Digits (+ 1 Prüfdigit) an. Der Kartenbesitzer liest den Beweis und gibt diesen in die Anwendung an seiner Haupt-Zugangseinrichtung ein. Die Anwendung an der Haupt-Zugangseinrichtung prüft das Prüfdigit auf Richtigkeit und informiert den Kartenbesitzer, wenn der Beweis einen Fehler enthält, und fordert, dass der Beweis erneut eingegeben wird. Wenn der Kartenbesitzer korrekt in den Beweis eingibt, wird das Online-Transaktionsverfahren fortgesetzt..
  • Das oben angegebene Schema erfordert bestimmte Datenstrukturen. Die systemspezifischen Aussteller-Internetdaten (IIPD) sind eine optionale 0-Byte bis 32-Byte Struktur allgemeinen Zwecks, die binäre Daten mit der folgenden Struktur enthält:
    • – Byte 1 – IAF
    • – Byte 2 bis 31 – zusätzlicher ausstellerspezifischer Inhalt.
  • Das erste Byte der IIPD ist ein Internet-Zugriffsberechtigungsprüfungs-Flagsignal(IAF)-Byte. Jedes Bit übermittelt eine Mitteilung zu Aktionen oder Optionen von dem Aussteller, die der PCR aufnehmen/verwenden muss. Die Flagsignaleinstellungen zeigen an, ob der Betrag und die Währung explizit in der AC-Erzeugung, wobei das AC das Kryptogramm ist, verwendet werden müssen und ob ein AAC oder ein ARQC von der ICC angefordert werden sollte. Wenn die ICC 5 keine IIPD besitzt, dann wird ein Ausgangs-Bytewert mit 0×40 für die IAF verwendet.
  • Alle Daten, die nach dem IAF folgen, sind solche für die systemspezifische Verwendung durch den Aussteller. Die systemspezifischen Internet-Ausstellerdaten (IIPD) gestatten, dass der Aussteller diese systemspezifischen Daten, im Allgemeinen kartenspezifische feste Daten spezifiziert, die an das Aussteller-Zugriffsberechtigungsprüfungs-Bestätigungsystem zu übermitteln sind, um die Bestätigung des Zugriffsberechtigungsprüfungsbeweises zu unterstützen. Sie dienen als Objekt allgemeinen Zwecks, um die systemspezifischen Ausstellerdaten für das Internet-Zugriffsberechtigungsprüfungs-Umfeld zu halten. Die innerhalb der IIPD zu transportierenden Daten sind grundsätzlich irgendwelche feste Kartendaten, die durch das Aussteller-Hostsystem benötigt werden, das das Anwendungskryptogramm auf Richtigkeit prüft beziehungsweise bestätigt, jedoch besteht aus dem einen oder anderen Grund keine Möglichkeit oder ist es kompliziert, sie von der Kartendatenbank zu erhalten. Beispiele können den Schlüsselherleitungsindex und/oder die Kryptogrammsversionsnummer umfassen.
  • Karten können eine 1-Digit-Karten-Folgenummer (CSN) verwendet. Da die UCAF-Spezifikationen keine Vorschriften für dieses Feld machen, können die IIPD dazu verwendet werden, die CSN zu übermitteln. Sie werden zu dem Aussteller transportiert, indem sie in den IIPD platziert werden, wobei 4 Bits benötigt werden, um sie darzustellen. Die Positionierung und das Format der CSN hängen vom Aussteller ab.
  • Der Kartenbesitzer muss die IIPD, sofern es solche gibt, direkt an die Kartenbesitzer-IA liefern. Dies bedeutet, dass ein Aussteller alle kartenspezifischen IIPD den Kartenbesitzer mitteilen muss, sodass diese Daten der Kartenbesitzer-IA, wie erforderlich, zugeführt werden können. Aus Gründen der Fähigkeit zur gegenseitigen Kommunikation muss statt der Übermittlung der Daten in der präziseren hexedezimalen Form der Aussteller die IIPD, eine veränderliche ganze Zahl von Bytes, in einer dezimalen Trielet-Form übermitteln, d. h. der Wert jedes Bytes wird als ein dezimaler Wert eingegeben, getrennt von dem Wert des nächsten Bytes durch einen Schrägstrich oder Leerraum. Eine Auffüllung vorne mit Null wird verwendet um sicherzustellen, dass die IIPD als Triplets dargestellt werden. Dieses Erfordernis ist notwendig, damit die MCDs, die keine Schrägstrich- oder Leerraum-Taste besitzen, jedes Trielet erkennen können.
  • Obwohl der PCR nur das erste Byte der IIPD als Internet-Zugriffsberechtigungsprüfungs-Flagsignal (IAF)-Byte verwendet, sollten alle IIPD in der ICC personifiziert werden. Dies ist so, damit angeschlossene Leser, die Daten aus der ICC abrufen können, in der Lage sind, die IIPD zu finden und es somit nicht erforderlich machen, dass der Kartenbesitzer die IIPD manuell eingibt.
  • Eine weitere Datenstruktur ist das systemspezifische Aussteller-Internet-Bitmuster. Das systemspezifische Aussteller-Internet-Bitmuster (IIPB) ist eine optionale 11-Byte- bis 43-Byte-Struktur, die binäre Daten enthält. Dieses Bitmuster ist eine Maske für die verketteten Werte von Datenelementen CID, ATC, AC, das das Kryptogramm ist, und IAD. Sie ist nicht notwendigerweise einen gerade Maske für die Antwortdaten, da sowohl eine erste nicht-gekennzeichnete als auch eine zweite gekennzeichnete AC-Erzeugungs-Antwort durch den PCR bearbeitet werden können. Die zweiten Antwortdaten enthalten das Kennzeichen und die Länge sowie die Werte von CID, ATC, AC, das das Kryptogramm ist, und IAD. Wenn die ICC 5 keine IIPB besitzt, dann wird ein Ausgangs-Bytewert mit einer 19-Byte-Struktur verwendet. Nach der Verwendung des IIPB zur Bestimmung der Bits, die in dem IIPB-Datenbeweis zu übertragen sind, muss ein nicht-angeschlossene PCR den PCR-Beweis zur Anzeige gegenüber den Kartenbesitzer aufbauen, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist.
  • Wegen der beschränkten Datenübertragung, die über nicht nur den AAV-Datenraum innerhalb der UCAF, sondern noch wichtiger von dem nicht-angeschlossenen persönlichen Kartenleser (PCR) zur Verfügung steht, ist es das IIPB, das definiert, welche Bit der Informationen dem Aussteller zugeführt werden, um das Zugriffsberechtigungsprüfungskryptogramm zu bestätigen. Das IIPB bildet daher die Definition der Aussteller-Bestätigungsdatenerfordernisse. Das IIPB ist eine Maske derjenigen Bits, die benötigt werden von:
    • – Kryptogramm-Informationsdaten (Ca)
    • – Anwendungs-Transaktionszähler (ATC)
    • – Anwendung-Kryptogramm (das AC ist das Kryptogramm)
    • – Aussteller-Anwendungsdaten
  • Die einzige Information, die von den CID benötigt wird, ist diejenige, ob das durch die Karte erzeugte AC, das das Kryptogramm ist, ein ARQC oder ein AAC. Da die Karte entweder ein ARQC oder ein AAC erzeugt, besteht keine Notwendigkeit, beide Kryptogramm-Anzeigebits zu senden, da nur das oberste der beiden Anzeigerbits benötigt wird. Der restliche Teil der CID wird wie unten angegeben eingestellt und somit nicht gesendet.
  • Der ATC ist ein 16-Bit-Zähler, der nach jeder Transaktion ansteigt. Der Wert des ATC ist in dem Kryptogramm enthalten und sorgt für Einzigartigkeit des Kryptogramms. Infolge der ansteigenden Art des ATC ist es möglich, die Anzahl der Bits des ATC, die übertragen werden, ganz erheblich zu verringern.
  • Das Kryptogramm (AC), das auf die Anforderung der ICC für dieses Schema zu berechnen ist, ist ein Anwendungs-Anforderungskryptogramm (ARQC), jedoch können einige Kartenimplementationen stattdessen wählen oder durch ihren Aussteller dazu aufgefordert sein, ein Anwendungs-Zugriffsberechtigungsprüfungskryptogramm (AAC) zu erzeugen. In beiden Fällen ist das AC, das das Kryptogramm ist, ein 8-Byte-Nachrichten-Zugriffsberechtigungsprüfungscode (MAC), der über Daten berechnet wird, die zu der ICC geführt sind oder dieser anderweitig bekannt sind. Nur 2 Bytes des 8-Byte-AC, das das Kryptogramm ist, werden in dem PCR-Beweis übertragen, wobei der PCR-Beweis der Zugriffsberechtigungsprüfungsbeweis ist, und die Verarbeitung in dem Ausstellerhost muss dies berücksichtigen bei dem Vergleich des empfangenen AC, wobei das AC das Kryptogramm ist, mit dem AC, das das durch die erneute Bildung geschaffene Kryptogramm ist. Welche 2 Bytes gewählt werden, wird selbstverständlich durch das IIPB bestimmt. Das Ausgangs-IIPB ist so eingestellt, dass die ersten 2 Bytes genommen werden.
  • Die Aussteller-Anwendungsdaten (IAD) enthalten Felder mit einer Kombination von angenommenen festen Werten, von transaktionsspezifischen Werten und von dem Aussteller bekannten Werten, die den Schlüsselherleitungsindex und die Kryptogrammsversionsnummer umfassen, die in der Karte gespeicherte feste Werte sind und die der Aussteller aus der ICC-Datenbank auf der Grundlage der PAN und des Ablaufdatums erlangen kann und die somit nicht übermittelt werden müssen. Auch dazu gehört das dynamische Zugriffsberechtigungsprüfungskryptogramm (DAC), das eine Konstante ist, und diese muss nicht übermittelt werden. Ebenfalls dazu gehören die Kartenbestätigungsergebnisse (CVR), die ein 4-Byte-Feld sind, dessen Byte-1 die Länge der CVR ist und eine festgelegte bekannte Konstante ist. Die Bytes 2, 3 und 4 enthalten eine Mischung aus angenommenen und benötigten transaktions- oder kartenspezifischen Bitwerten. Diese Bits schaffen eine wertvolle Informationen dazu, ob die offline-PIN-Überprüfung auf Richtigkeit erfolgreich war, die PIN-Wiedereingabezahl überschritten wurde und die vorausgehende Transaktion fehlerhaft war.
  • 24 zeigt die bei einer Standardtransaktion involvierten Schritte und wird nachfolgend beschrieben.
    • 1. Kartenaktivierung: die Karte muss in einen Kartenleser eingesetzt sein, wenn die Transaktion durchgeführt wird.
    • 2. Wahl der Anwendung: das Anwendungswahlverfahren ist das Verfahren, mittels dessen das Terminal Daten in der ICC verwendet, um zu die zu verwendende ICC-Anwendung bestimmen, um ein Zugriffsberechtigungsprüfungskryptogramm zu schaffen. Das Verfahren besteht aus zwei Schritten: – Schaffen einer Liste von ICC-Anwendungen, die durch das Terminal unterstützt werden. – Auswählen der laufenzulassenden Anwendung aus der oben geschaffenen Liste.
    • 3. Initiieren der Anwendungsverarbeitung: das Terminal initiiert die Transaktionsverarbeitung.
    • 4. Lesen der Anwendungsdaten: das Terminal liest die durch den AFL angezeigten Daten.
    • 5. Offline-Karten-Zugriffsberechtigungsprüfung: die Daten- und Karten-Zugriffsberechtigungsprüfung wird durch das Terminal durchgeführt, um die Legitimität kritischer ICC-residenter Daten zu bestätigen und eine Zugriffsberechtigungsprüfung der ICC durchzuführen. Der persönliche Kartenleser, wie für den Chip-UCAF-Zugriffsberechtigungsprüfungsservice verwendet, kann als ein online arbeitendes Terminal betrachtet werden, die Terminalanwendung muss daher die Karten-Zugriffsberechtigungsprüfung nicht online durchführen, wie in den Einstellungen des Anwendung-Austauschprofils angegeben ist. Dies bedeutet, dass das Terminal nicht auf Richtigkeit überprüfen beziehungsweise bestätigen muss, dass die in das Terminal eingesetzte Karte echt ist; dies kann dem Kartenaussteller überlassen sein, wenn er das Kryptogramm bestätigt.
    • 6. Verfahrensbeschränkungen: der Zweck der Funktion der Verarbeitungsbeschränkungen besteht darin, das Ausmaß der Kompatibilität der Anwendung in dem Terminal mit der Anwendung in der ICC zu bestimmen und alle notwendigen Einstellungen durchzuführen, einschließlich einer möglichen Zurückweisung der Transaktion. Die Terminalanwendung muss diese Tests nicht durchführen, da unabhängig von dem Ausgang das Terminal ein ARQC (aber auch ein AAC akzeptiert, wenn die ICC die Forderung "ablehnt") oder ein AAC anfordert.
    • 7. Kartenbesitzer-Prüfung bzw. -Bestätigung: das Chip-UCAF-Zugriffsberechtigungsprüfungsschema erfordert eine gültige PIN (persönliche Identifikationsnummer) für die Zugriffsberechtigungsprüfung des Kartenbesitzers.
    • 8. Terminal-Risikomanagement: das Terminalrisikomanagement ist der Teil des Risikomanagements, der durch das Terminal durchgeführt wird, um den Erfasser, den Aussteller und das System vor Betrug zu schützen. Da der Kartenaussteller die Transaktion online verarbeitet, ist das Terminal-Risikomanagement optional.
    • 9. Terminal-Aktionsanalyse: wenn das Terminal-Risikomanagement und die Anwendungsfunktionen betreffend eine normale Offline-Transaktion abgeschlossen sind, trifft das Terminal die erste Entscheidung, ob die Transaktion offline zu genehmigen, offline abzulehnen oder online zu übermitteln ist.
    • 10. Erste Aktionsanalyse: eine ICC kann ihr eigenes Risikomanagement zum Schutz des Ausstellers vor Betrug oder einem übermäßigen Kreditrisiko durchführen. Als Folge des Risikomanagementverfahrens kann eine ICC entscheiden, eine Transaktion online oder offline abzuschließen, oder eine Überweisung fordern oder die Transaktion zurückweisen. Das Terminal bittet die Karte, ein Anwendungskyptogramm zu erzeugen, entweder ein ARQC oder ein AAC. Bit 7 des Internet-Zugriffsberechtigungsprüfungs-Flagsignals (IAF) zeigt an, ob um ein ARQC (einstellen auf 0) oder um ein AAC (einstellen auf 1) zu bitten ist. Wenn die ICC gebeten wird, ein AAC zu erzeugen, wird P1 der APDU auf 0×0 eingestellt.
  • Bei der Anforderung muss das Terminal spezifische Daten aufweisen; beispielsweise:
    • – genehmigter Betrag
    • – Terminal-Ländercode
    • – Terminal-Überprüfungsresultate
    • – Transaktions-Währungscode
    • – Transaktionsdatum
    • – Transaktionsart
    • – nicht-voraussagbare Zahl Terminaltyp Datenzugriffsberechtigungsprüfungscode
  • Das Terminal baut den Datenstring auf, der in dem AC-Erzeugungsbefehl enthalten sein muss. Die ICC erzeugt ein Anwendungskryptogramm (AC), wobei das AC das Kryptogramm ist, über den Datenelementen und anderen Datenelementen, die auf der Karte gespeichert sind. Die Antwort des Terminals auf den AC-Erzeugungsbefehl weist das AC, das das Kryptogramm ist, und die anderen auf der Karte gespeicherte Daten auf, die bei der Kryptogrammerzeugung beteiligt waren:
    • – Kryptogramm-Informationsdaten (CID)
    • – Anwendungs-Transaktionszähler (ATC)
    • – optionale Aussteller-Anwendungsdaten (IAD)
  • Andere Datenelemente können ebenso gut zurückgeführt werden, oder aber durch die Terminalanwendung ignoriert werden.
    • 11. Terminal-Online-Verarbeitung: die Online-Verarbeitung wird normalerweise durchgeführt um sicherzustellen, dass der Aussteller Transaktionen nachprüfen und in Hinblick auf die Zugriffsberechtigung prüfen oder zurückweisen kann, die außerhalb durch den Aussteller, das Bezahlungssystem oder den Erfasser definierter annehmbarer Risikogrenzen liegen. Für persönliche Kartenleser-Terminalanwendungen erstellt das Äquivalent zu der Online-Verarbeitungsstufe den Datenbeweis, der dem Kartenbesitzer angezeigt wird, aus den Antwortdaten der AC-Erzeugung. Jedoch findet dies tatsächlich nicht statt, bis die Transaktion mit der ICC abgeschlossen worden ist, und dies wird unten beschrieben. Das Terminal muss keine Online-Verarbeitung durchführen.
    • 12. Verarbeitung des Scripts von Aussteller an Karte: ein Aussteller kann Befehlscripts schaffen, die an die ICC durch das Terminal zu liefern sind, um Funktionen durchzuführen, die für die gegenwärtige Transaktion nicht notwendigerweise relevant, aber für die fortgesetzte Funktion der Anwendung in der ICC wichtig sind. Der persönliche Kartenleser ist nicht fähig, Befehlscripts zu schaffen, und somit führt das Terminal diesen Schritt nicht durch.
    • 13. Transaktionsabschluss: die Abschlussfunktion schließt die Verarbeitung einer Transaktion. Der Terminal für diese Funktion immer durch, es sei denn die Transaktion wird vorzeitig durch eine Fehlerverarbeitung beendet. Einige Kartenimplementierungen gemäß Ihrem inneren Risikomanagement ein AAC statt ein ARQC erzeugen. Das Bit 8 der CID bestimmt, ob die Karte ein AAC oder ein ARQC erzeugt hat. Wenn das Bit 8 0 ist, hat die Karte ein AAC erzeugt. Wenn das Bit 8 1 ist, darin hat die Karte ein ARQC erzeugt. Wenn die ICC ein AAC bei der ersten AC-Erzeugung zurücksendet, dann war die Transaktion "offline abgelehnt", und wird eine weitere Verarbeitung benötigt. Wenn die ICC ein ARQC bei der ersten AC-Erzeugung zurücksendet, dann sollte das Terminal die Karte auffordern, ein AAC zu erzeugen. Bei dieser Anforderung muss das Terminal besondere Daten aufweisen, beispielsweise aus der nachfolgenden Datenliste: – genehmigter Betrag – Terminal-Ländercode – Terminal-Überprüfungsresultate – Transaktions-Währungscode – Transaktionsdatum – Transaktionsart – nicht-voraussagbare Zahl – Terminaltyp – Datenzugriffsberechtigungsprüfungscode Das Terminal baut den Datenstring auf, der in dem AC-Erzeugungsbefehl enthalten sein muss. Die ICC erzeugt ein Anwendungskryptogramm (AC), wobei das AC das Kryptogramm ist, über den Datenelementen in der CDOL2. Der Transaktionszustand innerhalb der ICC ist jetzt geschlossen, und die Karte kann jetzt abgeschaltet werden.
    • 14. Beweiserzeugung: wenn eine erfolgreiche Transaktion mit der Karte geschlossen worden ist, muss das Terminal den dem Kartenbesitzer zu präsentierenden Beweis erzeugen. Der Beweis wird aus der Antwort auf den ersten oder nur den Befehl zur AC-Erzeugung entsprechend dem IIPB-Wert erzeugt. Der Beweis muss dem Kartenbesitzer nur angezeigt werden, wenn die Karte sich gegenständlich im Terminal befindet. Dies bedeutet, dass sogar in dem Fall, dass die Karte während der gesamten Zeit des Dialogs zwischen dem PCR und der ICC im Leser verbleibt, wenn sie während der Anzeige des Beweises entfernt ist, das Terminal seine Anzeige löschen und sich selbst abschalten muss. In dem obigen Schema müssen alle Fehler, die in den Rückführungsdaten von der ICC durch die Kartenbesitzeraktion oder durch die Feststellung von Fehlern durch das Terminal angezeigt werden, dazu führen, dass die Verarbeitung der Transaktion angehalten wird und eine geeignete Fehlernachricht angezeigt wird, bevor sich der PCR selbst abgeschaltet hat. Der PCR darf unter solchen Bedingungen keinen Befehl erzeugen und anzeigen.

Claims (16)

  1. Zugriffsberechtigungsprüfungssystem zur Verwendung mit einem Netzwerkbezahlungssystem für die Durchführung eines Verkaufs einer Handelsware über ein Netzwerk unter Verwendung einer IC-Karte zur Zugriffsberechtigungsprüfung, wobei das Zugriffsberechtigungsprüfungssystem umfasst: einen Händlerserver, der mit dem Netzwerk in Verbindung steht, wobei der Händlerserver mindestens einen ersten Warenposten der Handelsware für den Verkauf aufweist; ein Clientterminal, das mit dem Netzwerk in Verbindung steht, wobei das Clientterminal eine Ausgabeeinrichtung zur Überprüfung des ersten Warenpostens für den Verkauf und eine Eingabeeinrichtung zur Auslösung einer Einkaufstransaktion zum Einkauf des ersten Warenpostens für den Verkauf aufweist, wobei das Clientterminal zur Bildung einer Einkaufsnachricht unter Verwendung einer eine Händleridentifikationskennung betreffenden Information und einer Finanztransaktionsinformation dient, die von dem Händlerserver erhalten wird; einen Kartenleser zur Verbindung mit der IC-Karte, wobei der Kartenleser mit dem Netzwerk nicht verbunden ist; wobei das Clientterminal Mittel zur Erzeugung einer Abfragenachricht aufweist, wobei diese Abfragenachricht aus der Information betreffend die Händleridentifikationskennung und eine Kontonummer erzeugt wird; ein Mittel zum Empfang der Abfragenachricht an dem Kartenleser und zur Erzeugung eines Wertes aus der Abfragenachricht; wobei die IC-Karte ein Mittel zur Erzeugung eines Kryptogramms aus mindestens einem Teil dieses Wertes aufweist; wobei der Kartenleser ein Mittel zur Erzeugung eines Zugriffsberechtigungsprüfungsbeweises aus einem ausgewählten Bereich des Kryptogramms aufweist, wobei das Kryptogramm in dem Kartenleser einer Maske ausgesetzt wird, wobei die Maske definiert, welche Bits des Kryptogramms den ausgewählten Bereich des Kryptogramms bilden, wobei der ausgewählte Bereich zur Verifizierung des Kryptogramms nach einer Neuberechnung des Kryptogramms benötigt wird; und wobei das Clientterminal Mittel zur Übertragung des Zugriffsberechtigungsprüfungsbeweises in einer Nachricht zur Übertragung über das Netzwerk zu dem Händlerserver oder zu einem Genehmigungsserver aufweist.
  2. System nach Anspruch 1, wobei das Mittel zur Erzeugung einer Abfragenachricht dazu dient, die Abfragenachricht aus der Information betreffend die Händleridentifikationskennung, einer Kontonummer und einem Einkaufsbetrag und/oder einer Einkaufswährung zu erzeugen.
  3. System nach Anspruch 1 oder 2, wobei das Mittel zur Erzeugung einer Abfragenachricht dazu dient, die Händleridentifikationskennung und die Kontonummer und gegebenenfalls einen Einkaufsbetrag und/oder eine Einkaufswährung zu verknüpfen.
  4. System nach einem der Ansprüche 1 bis 3, wobei das Mittel zur Erzeugung einer Abfragenachricht dazu dient, die Verknüpfung der Händleridentifikationskennung und einer Kontonummer und gegebenenfalls eines Einkaufsbetrags und/oder einer Einkaufswährung zu komprimieren.
  5. System nach Anspruch 4, wobei die Komprimierung eine Hash-Funktion ist.
  6. System nach einem der Ansprüche 1 bis 5, wobei die IC-Karte einen Speicher aufweist und ein erster Datengegenstand in diesem Speicher gespeichert ist und das Mittel zur Erzeugung eines Zugriffsberechtigungsprüfungsbeweises aus einem ausgewählten Bereich des Kryptogramms dazu dient, einen Teil des Bereichs des Kryptogramms in Übereinstimmung mit dem ersten Datengegenstand auszuwählen.
  7. System nach einem der Ansprüche 1 bis 6, wobei die IC-Karte einen Speicher aufweist und ein zweiter Datengegenstand in diesem Speicher gespeichert ist und das Mittel zur Erzeugung einer Abfragenachricht einen Einkaufsbetrag und/oder eine Einkaufswährung bei der Erzeugung der Abfragenachricht in Übereinstimmung mit dem zweiten Datengegenstand aufweist.
  8. Verfahren zur Zugriffsberechtigungsprüfung für die Durchführung eines Verkaufs von Handelsware über ein Netzwerk unter Verwendung einer IC-Karte, wobei das Verfahren umfasst: Herstellen einer Verbindung zwischen einem Händlerserver und einem Clientterminal über das Netzwerk, wobei der Händlerserver mindestens einen ersten Warenposten der Handelsware für den Verkauf aufweist; Überprüfen des ersten Warenpostens für den Verkauf, Auslösen einer Einkaufstransaktion zum Einkauf des ersten Warenpostens für den Verkauf und Bilden einer Einkaufsnachricht unter Verwendung einer eine Händleridentifikationskennung betreffenden Information und einer Finanztransaktionsinformation, die von dem Händlerserver erhalten wird; Erzeugen einer Abfragenachricht an dem Clientterminal aus der Information betreffend die Händleridentifikationskennung und einer Kontonummer; Empfangen der Abfragenachricht an einem Kartenleser und Erzeugen eines Wertes aus der Abfragenachricht, wobei der Kartenleser mit dem Netzwerk nicht verbunden ist; Herstellen einer Verbindung zwischen der IC-Karte und dem Kartenleser und Erzeugen eines Kryptogramms aus mindestens einem Teil des Wertes auf der IC-Karte; Erzeugen eines Zugriffsberechtigungsprüfungsbeweises an dem Kartenleser aus einem ausgewählten Bereich des Kryptogramms; Aussetzen des Kryptogramms in dem Kartenleser gegenüber einer Maske, wobei die Maske definiert, welche Bits des Kryptogramms den ausgewählten Bereich des Kryptogramms bilden, wobei der ausgewählte Bereich zur Verifizierung des Kryptogramms nach einer Neuberechnung des Kryptogramms benötigt wird; und Übertragen des Zugriffsberechtigungsprüfungsbeweises in einer Nachricht von dem Clientterminal zur Übertragung über das Netzwerk zu dem Händlerserver oder zu einem Genehmigungsserver.
  9. Verfahren nach Anspruch 8, wobei das Erzeugen einer Abfragenachricht das Erzeugen der Abfragenachricht aus der Information betreffend die Händleridentifikationskennung, einer Kontonummer und einem Einkaufsbetrag und/oder einer Einkaufswährung umfasst.
  10. Verfahren nach Anspruch 8 oder 9, wobei das Erzeugen einer Abfragenachricht das Verknüpfen der Händleridentifikationskennung und der Kontonummer und gegebenenfalls eines Einkaufsbetrags und/oder einer Einkaufswährung umfasst.
  11. Verfahren nach einem der Ansprüche 8 bis 10, wobei das Erzeugen einer Abfragenachricht das Komprimieren der Verknüpfung der Händleridentifikationskennung und der Kontonummer und gegebenenfalls eines Einkaufsbetrags und/oder einer Einkaufswährung umfasst.
  12. Verfahren nach Anspruch 11, wobei das Komprimieren die Anwendung einer Hash-Funktion umfasst.
  13. Verfahren nach einem der Ansprüche 8 bis 12, wobei die IC-Karte einen Speicher aufweist und ein erster Datengegenstand in diesem Speicher gespeichert ist, ferner umfassend das Erzeugen eines Zugriffsberechtigungsprüfungsbeweises aus dem ausgewählten Bereich des Kryptogramms durch Auswählen eines Teils des Bereichs des Kryptogramms in Übereinstimmung mit dem ersten Datengegenstand.
  14. Verfahren nach einem der Ansprüche 8 bis 13, wobei die IC-Karte einen Speicher aufweist und ein zweiter Datengegenstand in diesem Speicher gespeichert ist, ferner umfassend das Erzeugen eines Abfragenachricht aus einem Einkaufsbetrag und/oder einer Einkaufswährung in Übereinstimmung mit dem zweiten Datengegenstand.
  15. Zugriffsberechtigungsprüfungssystem nach Anspruch 1 bis 7, wobei der Kartenleser ein Handgerät ist.
  16. Verfahren zur Zugriffsberechtigungsprüfung nach einem der Ansprüche 8 bis 14, wobei der Kartenleser ein Handgerät ist.
DE60317169T 2002-02-28 2003-02-28 Authentifizierungsanordnung und verfahren zur verwendung mit finanztransaktionen Expired - Lifetime DE60317169T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0204620 2002-02-28
GBGB0204620.9A GB0204620D0 (en) 2002-02-28 2002-02-28 Chip authentication programme
PCT/BE2003/000036 WO2003073389A2 (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions

Publications (2)

Publication Number Publication Date
DE60317169D1 DE60317169D1 (de) 2007-12-13
DE60317169T2 true DE60317169T2 (de) 2008-08-07

Family

ID=9931909

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60317169T Expired - Lifetime DE60317169T2 (de) 2002-02-28 2003-02-28 Authentifizierungsanordnung und verfahren zur verwendung mit finanztransaktionen
DE60335049T Expired - Lifetime DE60335049D1 (de) 2002-02-28 2003-02-28 Authentifizierungsanordnung und Verfahren zur Verwendung für Finanztransaktionen

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60335049T Expired - Lifetime DE60335049D1 (de) 2002-02-28 2003-02-28 Authentifizierungsanordnung und Verfahren zur Verwendung für Finanztransaktionen

Country Status (12)

Country Link
US (1) US10395462B2 (de)
EP (4) EP2309465B1 (de)
JP (1) JP4597529B2 (de)
KR (1) KR20040089682A (de)
AT (2) ATE488823T1 (de)
AU (1) AU2003209860A1 (de)
BR (1) BR0308111A (de)
DE (2) DE60317169T2 (de)
GB (1) GB0204620D0 (de)
MX (1) MXPA04008410A (de)
WO (1) WO2003073389A2 (de)
ZA (1) ZA200406805B (de)

Families Citing this family (167)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2377706A1 (en) * 1999-06-18 2000-12-28 Echarge Corporation Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US7889052B2 (en) 2001-07-10 2011-02-15 Xatra Fund Mx, Llc Authorizing payment subsequent to RF transactions
US8429041B2 (en) 2003-05-09 2013-04-23 American Express Travel Related Services Company, Inc. Systems and methods for managing account information lifecycles
US8543423B2 (en) 2002-07-16 2013-09-24 American Express Travel Related Services Company, Inc. Method and apparatus for enrolling with multiple transaction environments
US7627531B2 (en) 2000-03-07 2009-12-01 American Express Travel Related Services Company, Inc. System for facilitating a transaction
US7725427B2 (en) 2001-05-25 2010-05-25 Fred Bishop Recurrent billing maintenance with radio frequency payment devices
US7503480B2 (en) 2001-07-10 2009-03-17 American Express Travel Related Services Company, Inc. Method and system for tracking user performance
US7805378B2 (en) 2001-07-10 2010-09-28 American Express Travel Related Servicex Company, Inc. System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions
US8635131B1 (en) 2001-07-10 2014-01-21 American Express Travel Related Services Company, Inc. System and method for managing a transaction protocol
US20050160003A1 (en) * 2001-07-10 2005-07-21 American Express Travel Related Services Company, Inc. System and method for incenting rfid transaction device usage at a merchant location
US9454752B2 (en) 2001-07-10 2016-09-27 Chartoleaux Kg Limited Liability Company Reload protocol at a transaction processing entity
US7762457B2 (en) 2001-07-10 2010-07-27 American Express Travel Related Services Company, Inc. System and method for dynamic fob synchronization and personalization
US8548927B2 (en) 2001-07-10 2013-10-01 Xatra Fund Mx, Llc Biometric registration for facilitating an RF transaction
US20040236699A1 (en) 2001-07-10 2004-11-25 American Express Travel Related Services Company, Inc. Method and system for hand geometry recognition biometrics on a fob
US7705732B2 (en) 2001-07-10 2010-04-27 Fred Bishop Authenticating an RF transaction using a transaction counter
US8284025B2 (en) 2001-07-10 2012-10-09 Xatra Fund Mx, Llc Method and system for auditory recognition biometrics on a FOB
US7668750B2 (en) 2001-07-10 2010-02-23 David S Bonalle Securing RF transactions using a transactions counter
US8001054B1 (en) 2001-07-10 2011-08-16 American Express Travel Related Services Company, Inc. System and method for generating an unpredictable number using a seeded algorithm
US9031880B2 (en) 2001-07-10 2015-05-12 Iii Holdings 1, Llc Systems and methods for non-traditional payment using biometric data
US7925535B2 (en) 2001-07-10 2011-04-12 American Express Travel Related Services Company, Inc. System and method for securing RF transactions using a radio frequency identification device including a random number generator
US8960535B2 (en) 2001-07-10 2015-02-24 Iii Holdings 1, Llc Method and system for resource management and evaluation
US9024719B1 (en) 2001-07-10 2015-05-05 Xatra Fund Mx, Llc RF transaction system and method for storing user personal data
US7735725B1 (en) 2001-07-10 2010-06-15 Fred Bishop Processing an RF transaction using a routing number
US7996324B2 (en) * 2001-07-10 2011-08-09 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia
US7587756B2 (en) * 2002-07-09 2009-09-08 American Express Travel Related Services Company, Inc. Methods and apparatus for a secure proximity integrated circuit card transactions
US7792759B2 (en) * 2002-07-29 2010-09-07 Emv Co. Llc Methods for performing transactions in a wireless environment
US6805287B2 (en) 2002-09-12 2004-10-19 American Express Travel Related Services Company, Inc. System and method for converting a stored value card to a credit card
US7761374B2 (en) 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US7740168B2 (en) 2003-08-18 2010-06-22 Visa U.S.A. Inc. Method and system for generating a dynamic verification value
US20050177510A1 (en) * 2004-02-09 2005-08-11 Visa International Service Association, A Delaware Corporation Buyer initiated payment
US20050242176A1 (en) * 2004-04-28 2005-11-03 Dexit Inc. RFID-based system and method of conducting financial transactions
JP4730694B2 (ja) * 2004-06-30 2011-07-20 フランス テレコム 多目的電子支払方法及びシステム、並びにマルチメディア端末とそのコンピュータプログラム
US7318550B2 (en) 2004-07-01 2008-01-15 American Express Travel Related Services Company, Inc. Biometric safeguard method for use with a smartcard
US7669772B2 (en) * 2004-07-15 2010-03-02 Mastercard International Incorporated Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
US8439271B2 (en) 2004-07-15 2013-05-14 Mastercard International Incorporated Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
US7958030B2 (en) 2004-09-01 2011-06-07 Visa U.S.A. Inc. System and method for issuer originated payments for on-line banking bill payments
US7506812B2 (en) * 2004-09-07 2009-03-24 Semtek Innovative Solutions Corporation Transparently securing data for transmission on financial networks
DE102004049878B4 (de) * 2004-10-13 2006-09-21 Deutscher Sparkassen Verlag Gmbh System und Verfahren zur Überprüfung einer Zugangsberechtigung
US10248951B2 (en) * 2004-12-01 2019-04-02 Metavante Corporation E-coupon settlement and clearing process
US20070288313A1 (en) * 2006-06-09 2007-12-13 Mark Brodson E-Coupon System and Method
US7694341B2 (en) * 2005-06-03 2010-04-06 Apple Inc. Run-time code injection to perform checks
US8762263B2 (en) 2005-09-06 2014-06-24 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
CN106447310A (zh) 2005-09-28 2017-02-22 维萨国际服务协会 减少无接触交易的交互时间的设备，系统和方法
US8874477B2 (en) * 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US7992203B2 (en) 2006-05-24 2011-08-02 Red Hat, Inc. Methods and systems for secure shared smartcard access
US8180741B2 (en) 2006-06-06 2012-05-15 Red Hat, Inc. Methods and systems for providing data objects on a token
US8098829B2 (en) 2006-06-06 2012-01-17 Red Hat, Inc. Methods and systems for secure key delivery
US8332637B2 (en) 2006-06-06 2012-12-11 Red Hat, Inc. Methods and systems for nonce generation in a token
US8364952B2 (en) * 2006-06-06 2013-01-29 Red Hat, Inc. Methods and system for a key recovery plan
US8495380B2 (en) 2006-06-06 2013-07-23 Red Hat, Inc. Methods and systems for server-side key generation
US7822209B2 (en) 2006-06-06 2010-10-26 Red Hat, Inc. Methods and systems for key recovery for a token
US8707024B2 (en) 2006-06-07 2014-04-22 Red Hat, Inc. Methods and systems for managing identity management security domains
US8589695B2 (en) 2006-06-07 2013-11-19 Red Hat, Inc. Methods and systems for entropy collection for server-side key generation
US8412927B2 (en) 2006-06-07 2013-04-02 Red Hat, Inc. Profile framework for token processing system
US9769158B2 (en) * 2006-06-07 2017-09-19 Red Hat, Inc. Guided enrollment and login for token users
US8099765B2 (en) 2006-06-07 2012-01-17 Red Hat, Inc. Methods and systems for remote password reset using an authentication credential managed by a third party
US8806219B2 (en) 2006-08-23 2014-08-12 Red Hat, Inc. Time-based function back-off
US8074265B2 (en) 2006-08-31 2011-12-06 Red Hat, Inc. Methods and systems for verifying a location factor associated with a token
US8356342B2 (en) 2006-08-31 2013-01-15 Red Hat, Inc. Method and system for issuing a kill sequence for a token
US8977844B2 (en) 2006-08-31 2015-03-10 Red Hat, Inc. Smartcard formation with authentication keys
US9038154B2 (en) 2006-08-31 2015-05-19 Red Hat, Inc. Token Registration
US8693690B2 (en) 2006-12-04 2014-04-08 Red Hat, Inc. Organizing an extensible table for storing cryptographic objects
US8041030B2 (en) * 2007-01-09 2011-10-18 Mastercard International Incorporated Techniques for evaluating live payment terminals in a payment system
US8813243B2 (en) 2007-02-02 2014-08-19 Red Hat, Inc. Reducing a size of a security-related data object stored on a token
GB2442249B (en) * 2007-02-20 2008-09-10 Cryptomathic As Authentication device and method
US9846866B2 (en) * 2007-02-22 2017-12-19 First Data Corporation Processing of financial transactions using debit networks
US8832453B2 (en) 2007-02-28 2014-09-09 Red Hat, Inc. Token recycling
US8639940B2 (en) 2007-02-28 2014-01-28 Red Hat, Inc. Methods and systems for assigning roles on a token
US9081948B2 (en) 2007-03-13 2015-07-14 Red Hat, Inc. Configurable smartcard
FR2914763B1 (fr) * 2007-04-06 2013-02-15 Grp Des Cartes Bancaires Cryptogramme dynamique
TW200845690A (en) * 2007-05-14 2008-11-16 David Chiu Business protection system in internet
US8121956B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Cardless challenge systems and methods
US20090089211A1 (en) * 2007-10-02 2009-04-02 Patricia Morse System and method for person to person fund transfer
US8214291B2 (en) * 2007-10-19 2012-07-03 Ebay Inc. Unified identity verification
GB2468817A (en) 2008-01-15 2010-09-22 Visa Usa Inc System and method for data completion including push identifier
US8255688B2 (en) * 2008-01-23 2012-08-28 Mastercard International Incorporated Systems and methods for mutual authentication using one time codes
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US20100005028A1 (en) * 2008-07-07 2010-01-07 International Business Machines Corporation Method and apparatus for interconnecting a plurality of virtual world environments
AU2009311303B2 (en) 2008-11-06 2015-09-10 Visa International Service Association Online challenge-response
US20100131397A1 (en) * 2008-11-25 2010-05-27 Patrick Killian Providing "on behalf of" services for mobile telephone access to payment card account
US7896247B2 (en) 2008-12-01 2011-03-01 Research In Motion Limited Secure use of externally stored data
EP2192512A1 (de) * 2008-12-01 2010-06-02 Research In Motion Limited Sichere Verwendung von extern gespeicherten Daten
US8838503B2 (en) * 2008-12-08 2014-09-16 Ebay Inc. Unified identity verification
US20100180329A1 (en) * 2009-01-09 2010-07-15 International Business Machines Corporation Authenticated Identity Propagation and Translation within a Multiple Computing Unit Environment
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US8370258B2 (en) * 2009-04-28 2013-02-05 Mastercard International Incorporated Apparatus, method, and computer program product for recovering torn smart payment device transactions
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
ES2338403B1 (es) * 2009-06-02 2011-06-10 Micro Codigos, S.L. Sistema de comunicacion con tarjetas inteligentes que comprende un lector de tarjetaqs inteligentes y un programa intermediartio, y lector de tarjetas adaptado para dicho sistema.
FR2950768A1 (fr) 2009-09-30 2011-04-01 Xiring Sa Systeme et procede de transaction securisee en ligne
AU2010315111B2 (en) * 2009-11-04 2015-03-19 Visa International Service Association Verification of portable consumer devices for 3-D secure services
US9240005B2 (en) 2009-11-06 2016-01-19 Mastercard International, Incorporated Methods for risk management in payment-enabled mobile device
WO2011088508A1 (en) * 2010-01-19 2011-07-28 Glencurr Pty Ltd Method, device and system for securing payment data for transmission over open communication networks
US9424413B2 (en) 2010-02-24 2016-08-23 Visa International Service Association Integration of payment capability into secure elements of computers
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
JP5589471B2 (ja) * 2010-03-19 2014-09-17 大日本印刷株式会社 ロイヤリティ管理システム，ロイヤリティ管理方法及びトークン
US9189786B2 (en) * 2010-03-31 2015-11-17 Mastercard International Incorporated Systems and methods for operating transaction terminals
US8473414B2 (en) * 2010-04-09 2013-06-25 Visa International Service Association System and method including chip-based device processing for transaction
US8700895B1 (en) 2010-06-30 2014-04-15 Google Inc. System and method for operating a computing device in a secure mode
US9118666B2 (en) 2010-06-30 2015-08-25 Google Inc. Computing device integrity verification
US10217109B2 (en) 2010-07-09 2019-02-26 Mastercard International Incorporated Apparatus and method for combining cryptograms for card payments
US8746553B2 (en) 2010-09-27 2014-06-10 Mastercard International Incorporated Purchase Payment device updates using an authentication process
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
KR101049072B1 (ko) * 2011-02-17 2011-07-15 (주)케이사인 식별 데이터를 이용하여 맵핑하는 방법
US10534931B2 (en) 2011-03-17 2020-01-14 Attachmate Corporation Systems, devices and methods for automatic detection and masking of private data
US9256874B2 (en) * 2011-04-15 2016-02-09 Shift4 Corporation Method and system for enabling merchants to share tokens
US9818111B2 (en) 2011-04-15 2017-11-14 Shift4 Corporation Merchant-based token sharing
US8688589B2 (en) 2011-04-15 2014-04-01 Shift4 Corporation Method and system for utilizing authorization factor pools
US8544735B2 (en) * 2011-05-23 2013-10-01 Mastercard International Incorporated Combicard transaction method and system having an application parameter update mechanism
US10325265B2 (en) * 2011-05-26 2019-06-18 Facebook, Inc. Methods and systems for facilitating E-commerce payments
US9607336B1 (en) 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry alerts
US10242368B1 (en) * 2011-10-17 2019-03-26 Capital One Services, Llc System and method for providing software-based contactless payment
US20130103574A1 (en) * 2011-10-19 2013-04-25 First Data Corporation Payment Delegation Transaction Processing
CA2860586C (en) * 2012-01-13 2017-05-09 Ebay Inc. Systems, methods, and computer program products providing payment in cooperation with emv card readers
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
WO2013140196A1 (en) * 2012-03-23 2013-09-26 Jetchev Dimitar A system for electronic payments with privacy enhancement via trusted third parties
US20130282588A1 (en) * 2012-04-22 2013-10-24 John Hruska Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System
US10423952B2 (en) * 2013-05-06 2019-09-24 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US11250423B2 (en) * 2012-05-04 2022-02-15 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US10410212B2 (en) * 2012-05-04 2019-09-10 Institutional Cash Distributors Technology, Llc Secure transaction object creation, propagation and invocation
CA2817431A1 (en) * 2012-06-01 2013-12-01 Nameh Jabbour System and method for requesting and processing pin data using a digit subset for subsequent pin authentication
US9667668B2 (en) * 2012-10-17 2017-05-30 Nvidia Corporation Managing SIM indications
US10572873B2 (en) * 2013-02-15 2020-02-25 Mastercard International Incorporated Method and system for the transmission of authenticated authorization requests
US20140279379A1 (en) * 2013-03-14 2014-09-18 Rami Mahdi First party fraud detection system
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US20150006382A1 (en) * 2013-06-27 2015-01-01 German Scipioni Systems and methods for implementing money orders
US10489852B2 (en) * 2013-07-02 2019-11-26 Yodlee, Inc. Financial account authentication
EP2838060A1 (de) 2013-08-14 2015-02-18 Facebook, Inc. Verfahren und Systeme zur Vereinfachung von Zahlungen im elektronischen Handel
US9647999B2 (en) 2014-02-07 2017-05-09 Bank Of America Corporation Authentication level of function bucket based on circumstances
US9286450B2 (en) 2014-02-07 2016-03-15 Bank Of America Corporation Self-selected user access based on specific authentication types
US9390242B2 (en) 2014-02-07 2016-07-12 Bank Of America Corporation Determining user authentication requirements based on the current location of the user being within a predetermined area requiring altered authentication requirements
US9965606B2 (en) 2014-02-07 2018-05-08 Bank Of America Corporation Determining user authentication based on user/device interaction
US9305149B2 (en) 2014-02-07 2016-04-05 Bank Of America Corporation Sorting mobile banking functions into authentication buckets
US9213974B2 (en) 2014-02-07 2015-12-15 Bank Of America Corporation Remote revocation of application access based on non-co-location of a transaction vehicle and a mobile device
US9208301B2 (en) 2014-02-07 2015-12-08 Bank Of America Corporation Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location
US9721268B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation Providing offers associated with payment credentials authenticated in a specific digital wallet
US20150254646A1 (en) * 2014-03-04 2015-09-10 Bank Of America Corporation Restoring or reissuing of a token based on user authentication
US10050787B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Authentication objects with attestation
US10049202B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Strong authentication using authentication objects
WO2015163771A1 (en) * 2014-04-23 2015-10-29 Julien Truesdale Payment systems
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US20150317630A1 (en) * 2014-04-30 2015-11-05 MasterCard Incorporated International Method and system for authentication token generation
US9264419B1 (en) 2014-06-26 2016-02-16 Amazon Technologies, Inc. Two factor authentication with authentication objects
US10891622B2 (en) * 2014-11-13 2021-01-12 Mastercard International Incorporated Providing online cardholder authentication services on-behalf-of issuers
SG10201500276VA (en) * 2015-01-14 2016-08-30 Mastercard Asia Pacific Pte Ltd Method and system for making a secure payment transaction
US9881166B2 (en) * 2015-04-16 2018-01-30 International Business Machines Corporation Multi-focused fine-grained security framework
GB2542617B (en) * 2015-09-28 2020-06-24 Touchtech Payments Ltd Transaction authentication platform
SG10201508034PA (en) * 2015-09-28 2017-04-27 Mastercard Asia Pacific Pte Ltd Device For Facilitating Identification Of A Fraudulent Payment Card
US9729536B2 (en) 2015-10-30 2017-08-08 Bank Of America Corporation Tiered identification federated authentication network system
US11107071B2 (en) * 2016-02-01 2021-08-31 Apple Inc. Validating online access to secure device functionality
US10861042B2 (en) * 2016-04-19 2020-12-08 Mastercard International Incorporated Method and system for platform attribution using digitized tokens
CN106603636B (zh) * 2016-11-29 2020-05-26 中国银联股份有限公司 一种差错交易的标准化方法及装置
US10755339B2 (en) 2017-03-17 2020-08-25 Team Labs, Inc. System and method of purchase request management using plain text messages
US11308107B1 (en) * 2017-12-15 2022-04-19 Groupon, Inc. Method, apparatus, and computer program product for network data linking and transmission thereof
AU2018202320A1 (en) * 2018-04-03 2019-10-17 Currency Select Pty Ltd Transaction security
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US10949520B2 (en) * 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US20200118122A1 (en) * 2018-10-15 2020-04-16 Vatbox, Ltd. Techniques for completing missing and obscured transaction data items
US20200167780A1 (en) * 2018-11-28 2020-05-28 Mastercard International Incorporated System and method for linking authentication and authorization processes in payment card-based financial transactions
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
WO2022250188A1 (ko) * 2021-05-28 2022-12-01 주식회사 유스비 로우레벨 데이터 분석 기반의 이상 금융거래 탐지 시스템 및 그 방법
US20230316275A1 (en) * 2022-04-04 2023-10-05 Capital One Services, Llc Systems and methods for token-based device binding during merchant checkout

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4736094A (en) * 1984-04-03 1988-04-05 Omron Tateisi Electronics Co. Financial transaction processing system using an integrated circuit card device
US5768390A (en) * 1995-10-25 1998-06-16 International Business Machines Corporation Cryptographic system with masking
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US6016484A (en) 1996-04-26 2000-01-18 Verifone, Inc. System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment
JPH10207962A (ja) * 1996-11-19 1998-08-07 Toppan Printing Co Ltd ネットワークを用いた商品販売システム及び電子決済システム
US6247129B1 (en) * 1997-03-12 2001-06-12 Visa International Service Association Secure electronic commerce employing integrated circuit cards
US6868391B1 (en) * 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
US6173400B1 (en) * 1998-07-31 2001-01-09 Sun Microsystems, Inc. Methods and systems for establishing a shared secret using an authentication token
FR2787273B1 (fr) * 1998-12-14 2001-02-16 Sagem Procede de paiement securise
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
CA2259089C (en) 1999-01-15 2013-03-12 Robert J. Lambert Method and apparatus for masking cryptographic operations
US6480935B1 (en) 1999-01-15 2002-11-12 Todd Carper Smart card memory management system and method
US7343351B1 (en) * 1999-08-31 2008-03-11 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US6289455B1 (en) * 1999-09-02 2001-09-11 Crypotography Research, Inc. Method and apparatus for preventing piracy of digital content
US7249093B1 (en) * 1999-09-07 2007-07-24 Rysix Holdings, Llc Method of and system for making purchases over a computer network
US6834271B1 (en) * 1999-09-24 2004-12-21 Kryptosima Apparatus for and method of secure ATM debit card and credit card payment transactions via the internet
US20030130955A1 (en) * 1999-12-17 2003-07-10 Hawthorne William Mcmullan Secure transaction systems
JP2001175737A (ja) * 1999-12-20 2001-06-29 Orient Corp クレジット情報処理システム及び方法並びにクレジット情報処理用ソフトウェアを記録した記録媒体
US20010039535A1 (en) * 2000-02-09 2001-11-08 Tsiounis Yiannis S. Methods and systems for making secure electronic payments
JP3801833B2 (ja) * 2000-02-14 2006-07-26 株式会社東芝 マイクロプロセッサ
JP2001236487A (ja) * 2000-02-21 2001-08-31 Ryutsu Kogaku Kenkyusho:Kk 不正使用防止機能を備えた有価担体ならびに有価担体作成装置および有価担体認証装置
KR100395296B1 (ko) * 2000-03-21 2003-08-21 권황섭 아이씨 카드를 이용한 복권 서비스 시스템 및 그 방법
GB0006668D0 (en) 2000-03-21 2000-05-10 Ericsson Telefon Ab L M Encrypting and decrypting
EP1139200A3 (de) 2000-03-23 2002-10-16 Tradecard Inc. Chipkarte und Chipkartenleser enthaltendes System zum Erzeugen eines Zugangkodes
US6856975B1 (en) * 2000-03-30 2005-02-15 Verify & Protect Inc. System, method, and article of manufacture for secure transactions utilizing a computer network
US7177848B2 (en) * 2000-04-11 2007-02-13 Mastercard International Incorporated Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
JP3399442B2 (ja) * 2000-05-15 2003-04-21 日本電気株式会社 電子商取引システム及び電子商取引方法
WO2002001522A1 (en) * 2000-06-26 2002-01-03 Covadis S.A. Computer keyboard unit for carrying out secure transactions in a communications network
US6931382B2 (en) * 2001-01-24 2005-08-16 Cdck Corporation Payment instrument authorization technique
US7292999B2 (en) * 2001-03-15 2007-11-06 American Express Travel Related Services Company, Inc. Online card present transaction
US7499888B1 (en) * 2001-03-16 2009-03-03 Fusionone, Inc. Transaction authentication system and method
GB2374498B (en) 2001-04-12 2004-02-18 Intercede Ltd Multi-stage authorisation system
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
US8909557B2 (en) 2002-02-28 2014-12-09 Mastercard International Incorporated Authentication arrangement and method for use with financial transaction
US7669772B2 (en) 2004-07-15 2010-03-02 Mastercard International Incorporated Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
KR20080059617A (ko) 2005-10-05 2008-06-30 프리바스피어 아게 사용자 인증 방법 및 디바이스
GB2442249B (en) 2007-02-20 2008-09-10 Cryptomathic As Authentication device and method
CN101981585A (zh) 2008-03-10 2011-02-23 环球蓝联货币优选控股股份有限公司 动态货币转换系统和方法
FR2934910B1 (fr) 2008-08-05 2013-08-16 Inside Contactless Procede de securisation d'une transaction executee au moyen d'un dispositif portable programmable.

Also Published As

Publication number Publication date
EP2309465A1 (de) 2011-04-13
JP2005519375A (ja) 2005-06-30
EP1850297B1 (de) 2010-11-17
EP1850297A2 (de) 2007-10-31
DE60335049D1 (de) 2010-12-30
ZA200406805B (en) 2005-09-12
DE60317169D1 (de) 2007-12-13
BR0308111A (pt) 2005-01-04
JP4597529B2 (ja) 2010-12-15
MXPA04008410A (es) 2005-05-17
US20050119978A1 (en) 2005-06-02
WO2003073389A2 (en) 2003-09-04
ATE488823T1 (de) 2010-12-15
EP2309465B1 (de) 2013-09-04
AU2003209860A1 (en) 2003-09-09
KR20040089682A (ko) 2004-10-21
EP1850297A3 (de) 2008-03-05
EP1865471A3 (de) 2008-03-05
EP1479052A2 (de) 2004-11-24
EP1479052B1 (de) 2007-10-31
GB0204620D0 (en) 2002-04-10
US10395462B2 (en) 2019-08-27
EP1865471A2 (de) 2007-12-12
WO2003073389A3 (en) 2003-12-18
ATE377226T1 (de) 2007-11-15

Similar Documents

Publication Publication Date Title
DE60317169T2 (de) Authentifizierungsanordnung und verfahren zur verwendung mit finanztransaktionen
AU2004252824B2 (en) Customer authentication in e-commerce transactions
EP1497947B1 (de) Mobil-account-authentifikationsdienst
DE60007883T2 (de) Verfahren und vorrichtung zum durchführen von elektronischen transaktionen
US8909557B2 (en) Authentication arrangement and method for use with financial transaction
DE69534441T2 (de) System und Verfahren zum Verkaufen von elektronischen Wertkarten
DE69913929T2 (de) Gesichertes Bezahlungsverfahren
AU2001257280C1 (en) Online payer authentication service
AT506775A2 (de) Gesicherte finanzielle transaktionen
DE112009000137T5 (de) System und Verfahren zur Datenvervollständigung mit Anschubkennung
DE10296919T5 (de) System und Verfahren zur sicheren Rückzahlung
EP3014540A1 (de) Elektronisches transaktionsverfahren und computersystem
DE60210270T2 (de) Verfahren, bei de, elektronische Zahlkarten zum Sichern der Transaktionen eingesetzt werden
DE202019106383U1 (de) Elektronische Zahlungsvorrichtung
US20030164851A1 (en) Method and system for securing credit transactions
DE112018005524T5 (de) Zahlungsterminalvorrichtung und -verfahren
WO2010030362A1 (en) Authentication arrangement and method for use with financial transaction
DE102013022438B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE10207932A1 (de) Datenverarbeitungssystem und Verfahren zur elektronischen Zahlungsvermittlung
JP2003085366A (ja) ウェブサイト経由の受付認証システム、方法及びプログラム

Legal Events

Date Code Title Description
8364 No opposition during term of opposition