DE69829684T2

DE69829684T2 - Chipkarten verwendendes system zum bezahlen und laden im internet

Info

Publication number: DE69829684T2
Application number: DE69829684T
Authority: DE
Inventors: M. Virgil DAVIS; C. Suzanne CUTINO; J. Michael BERG; Sidney Fredrick CONKLIN; John Steven PRINGLE
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 1997-04-30
Filing date: 1998-04-30
Publication date: 2006-03-09
Anticipated expiration: 2018-05-01
Also published as: AU7272698A; EP1023705A1; DE69839731D1; CA2287960C; US6282522B1; PT1003139E; WO1998049658A1; ATE292833T1; ES2307481T3; CA2686483A1; AU754072B2; CA2686483C; EP1023705B1; DE69829684D1; ATE401628T1; CA2287960A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft allgemein ein Zahlungssystem und ein System zum Laden von Guthabenwerten unter Verwendung eines Computernetzwerks. Insbesondere betrifft die vorliegende Erfindung ein Zahlungssystem und ein System zum Laden von Guthabenwerten für eine Chipkarte unter Verwendung eines offenen Netzwerks wie dem Internet.
ALLGEMEINER STAND DER TECHNIK
Die explosionsartige Zunahme von offenen Netzwerken (wie dem Internet) in den letzten Jahren und die rasch ansteigende Anzahl von Verbrauchern mit Zugang zum World Wide Web haben zu einem großen Interesse an der Entwicklung des elektronischen Handels im Internet geführt. Herkömmliche Finanztransaktionen befinden sich im Wandel.
Eine Vielzahl von Dienstleistern hat Zahlungssysteme eingeführt, die den Online-Kauf von Waren oder Dienstleistungen in einer virtuellen Handelsumgebung unterstützen. Diese Ansätze haben mehrere Modelle verwendet, die auf herkömmlichen, im direkten Einzelhandel bestehenden Zahlungsverfahren basieren, einschließlich Kredit/Debitkarten, Schecks und Bargeld. Jedoch haben verschiedene dieser Systeme aus unterschiedlichsten Gründen bestimmte Nachteile.
Gegenwärtig kann ein Verbraucher seine oder ihre herkömmliche Kredit- oder Debitkarte benutzen, um einen Kauf im Internet zu tätigen. Ein Verbraucher gibt einfach seine Kartenkontonummer an, die dann über das Internet zu einem Händler übertragen wird, und die Zahlungstransaktion wird in der für Kreditkarten herkömmlichen Weise beendet. Oft werden diese Kontonummern mit extrem eingeschränkter oder gar keiner Sicherheit über das Internet übertragen. Die Sicherheit kann durch Verwendung des von Visa International und Mastercard 1996 veröffentlichten Protokolls „Secure Electronic Transaction" verbessert werden. Diese Transaktionen erfordern immer noch eine gewisse Form der Validierung von Karten und die Durchführung einer Kontostandsüberprüfung. Diese Überprüfungen werden online zwischen dem Händler, einem Erwerber und einer ausstellenden Bank durchgeführt, ein Vorgang, der zeitaufwändig und unwirtschaftlich werden kann, wenn der Wert der Transaktion gering ist oder wenn eine Anzahl Transaktionen von geringem Wert innerhalb eines kurzen Zeitraums erfolgen.
Der elektronische Scheck ist dem Papierscheck nachgebildet, wird aber elektronisch unter Verwendung einer digitalen Signatur und Kryptographie mit öffentlichem Schlüssel in Umlauf gebracht. Einzahlungen werden von Banken über elektronische Post gesammelt und durch bestehende Einrichtungen wie das Automated Clearing House (ACH) abgerechnet. Jedoch hat die Verwendung eines solchen elektronischen Schecks durch einen Verbraucher verschiedene Nachteile. Zum einen erfordern digitale Signaturen und Kryptographie mit öffentlichem Schlüssel die Einschaltung einer zertifizierenden Stelle, wodurch zu der Transaktion zusätzliche Einheiten und „Reisen" durch das Netz hinzukommen. Außerdem ist eine Registrierung des Kartenbesitzers erforderlich.
Andere Zahlungsmöglichkeiten über Internet sind Bargeldtransaktionen nachgebildet und umfassen eine Vielzahl von Systemen. Bei CyberCash hängt der Verbraucher seine Kreditkartennummer an eine elektronische Rechnung an, die er von dem Händler erhalten hat, schickt die Kreditkartennummer an den Händler zurück, die dann verarbeitet und an CyberCash weitergeleitet wird, wo sie dann wie eine normale Kreditkartentransaktion behandelt wird. Jedoch weist diese Technik einige der Nachteile auf, die zuvor in Bezug auf die herkömmliche Kreditkartentransaktion im Internet erörtert wurden, und erfordert von dem Händler zusätzliche Arbeit beim Verarbeiten der Kreditkartennummer. Debit-Transaktionen können ebenfalls ausgeführt werden, erfordern aber, dass der Verbraucher im Vorwege ein Konto bei CyberCash-Konto eröffnet.
Ein digitales, Token-basiertes System für Internet-Transaktionen ist von DigiCash umgesetzt worden. Bei DigiCash werden sogenannte „digitale Münzen" von DigiCash von einem vorausbezahlten Einzahlungskonto erworben und auf dem Festplattenlaufwerk des Verbrauchers gespeichert. Diese digitalen Münzen werden dann für eine Internet-Transaktion mit einem Händler verwendet. Die Nachteile dieses Systems bestehen darin, dass der Verbraucher zunächst eine Beziehung zu DigiCash herstellen und eine Kreditkarte oder ein ähnliches Instrument benutzen muss, um die digitalen Münzen zu erwerben, die dann auf den Computer des Verbrauchers heruntergeladen werden müssen. Diese Transaktion kann zeitaufwändig für den Verbraucher sein und ist betrugsanfällig. Außerdem muss ein Händler gefunden werden, der diese digitalen Münzen nicht nur akzeptiert, sondern auch ihre Authentizität überprüft, die Transaktion bestätigt und abschließend diese Nummern an seine Bank weiterleitet, um endlich bezahlt zu werden. Ein Nachteil vom Standpunkt des Händlers aus ist, dass ein großer Teil der mit der Transaktion verbundenen Arbeit von dem Händler geleistet werden muss.
Ein weiteres System für die Ausführung einer Internet-Transaktion wird von First Virtual Holding, Inc. angeboten. First Virtual bietet eine Softwarelösung an, die auf einer eindeutigen Identifizierungsnummer und einer Bestätigung über elektronische Post basiert. Um dieses System zu nutzen, eröffnet ein Verbraucher ein spezielles Konto bei First Virtual und erhält dann eine vertrauliche Identifizierungsnummer. Wenn der Verbraucher ein Produkt oder eine Dienstleistung über das Internet zu kaufen wünscht, sendet er oder sie mittels elektronischer Post eine Meldung an den Händler, die die vertrauliche Identifizierungsnummer enthält. Der Händler sendet dann die Nummer über elektronische Post an First Virtual zwecks Überprüfung und Identifizierung des Kunden. First Virtual vergewissert sich dann bei dem Verbraucher über elektronische Post, dass der Verbraucher tatsächlich die Transaktion eingeleitet hat und den Kauf zu tätigen wünscht. Die Nachteile dieses Systems bestehen darin, dass der Verbraucher zunächst ein spezielles Konto bei First Virtual eröffnen muss. Auch muss der Händler mit First Virtual kommunizieren, um den Kunden und die Kreditkartenkontonummer des Kunden zu identifizieren, die durch die vertrauliche Identifizierungsnummer identifiziert wird.
Abgesehen von Zahlungssystemen über Internet wird eine Technik angewandt, die zur Ausführung einer Finanztransaktion an einem einzelnen Terminal eine Chipkarte verwendet. Eine Chipkarte ist üblicherweise eine Plastikkarte von der Größe einer Kreditkarte, die einen Halbleiterchip umfasst, der den digitalen Gegenwert von Bargeld unmittelbar enthält, anstatt auf ein Konto zu verweisen oder Kreditsummen bereitzustellen. Wenn eine Karte dieser Art verwendet wird, um einen Kauf zu tätigen, wird der digitale Gegenwert von Bargeld an die „Registrierkasse" des Händlers und dann an eine Finanzinstitution übermittelt. Guthabenkarten sind entweder aufladbar (unter Verwendung eines Terminals kann wieder Wert auf die Karte geladen werden) oder nicht aufladbar (der Wert auf der Karte verringert sich bei jeder Transaktion und die Karte wird weggeworfen, wenn sie vollständig entwertet ist).
Äußerlich ähnelt eine Chipkarte oft einer herkömmlichen „Kredit"-Karte, die ein oder mehrere Halbleiterelemente aufweist, die mit einem in die Karte eingebetteten Modul verbunden sind, das Verbindungen zur Außenwelt herstellt. Die Karte kann eine Schnittstelle zu einem Verkaufsstellenterminal bilden, mit einem Geldautomaten oder mit einem Kartenleser, der in ein Telefon, einen Computer, einen Verkaufsautomaten oder ein anderes Gerät integriert ist. Ein mit einem Halbleiterelement ausgestatteter Mikrocontroller, der in eine „Prozessor"-Chipkarte eingebettet ist, ermöglicht es der Karte, eine Reihe von Rechenoperationen, geschützte Speicherung und Verschlüsselung durchzuführen und Entscheidungen zu treffen. Ein solcher Mikrocontroller umfasst üblicherweise einen Mikroprozessor; einen Speicher und weitere funktionale Hardwareelemente. Verschiedene Arten von Karten sind in „The Advanced Card Report: Smart Card Primer", Kenneth R. Ayer und Joseph F. Schuler, The Schuler Consultancy, 1993, beschrieben.
Ein Beispiel für eine Chipkarte, die als Prozessorkarte umgesetzt ist, ist in 1 dargestellt. Natürlich kann eine Chipkarte auf viele Arten umgesetzt sein und muss nicht notwendigerweise einen Mikroprozessor oder andere Eigenschaften umfassen. Die Chipkarte kann mit unterschiedlichen Arten von Funktionalität wie einer Anwendung zur Speicherung von Werten; Kredit/Debit; Loyalitätsprogrammen usw. programmiert sein. Für den Zweck dieser Offenbarung ist die Karte 5 mit mindestens einer Anwendung zur Speicherung von Werten programmiert und wird im Weiteren als „Guthaben"-Karte 5 bezeichnet.
Die Guthabenkarte 5 besitzt einen eingebetteten Mikrocontroller 10, der einen Mikroprozessor 12, einen Random Access Memory (RAM-Speicher) 14, einen Read Only Memory (ROM-Speicher) 16, einen nicht-flüchtigen Speicher 18, ein Verschlüsselungsmodul 22 und eine Kartenleserschnittstelle 24 besitzt. Andere Merkmale des Mikrocontrollers können vorhanden sein, sind aber nicht dargestellt, wie eine Uhr, ein Zufallszahlengenerator, eine Unterbrechungssteuerung, eine Steuerlogik, eine Ladungspumpe, Stromversorgungsanschlüsse und Schnittstellenkontakte, die es der Karte ermöglichen, mit der Außenwelt zu kommunizieren.
Der Mikroprozessor 12 ist jede beliebige geeignete zentrale Verarbeitungseinheit zur Ausführung von Befehlen und zur Steuerung des Geräts. Der RAM-Speicher 14 dient als Speicher für errechnete Ergebnisse und als Stapelspeicher. Der ROM-Speicher 16 speichert das Betriebssystem, unveränderliche Daten, Standardroutinen und Nachschlagetabellen. Der nicht-flüchtige Speicher 18 (wie EPROM oder EEPROM) dient zur Speicherung von Informationen, die nicht verloren gehen dürfen, wenn die Karte von einer Stromquelle getrennt wird, er muss aber auch veränderbar sein, um spezifische Daten einzelner Karten oder beliebige Änderungen während der Lebensdauer der Karte aufzunehmen. Diese Informationen könnten eine Karten-Identifizierungsnummer, eine persönliche Identifizierungsnummer, Berechtigungsebenen, Kontostände, Kreditbegrenzungen etc. umfassen. Das Verschlüsselungsmodul 22 ist ein optionales Hardwaremodul, das benutzt wird, um eine Vielzahl von Verschlüsselungsalgorithmen auszuführen. Die Kartenleserschnittstelle 24 umfasst die Software und Hardware, die für die Kommunikation mit der Außenwelt erforderlich sind. Eine Vielzahl von Schnittstellen ist möglich. Zum Beispiel kann die Schnittstelle 24 eine Kontaktschnittstelle bereitstellen, eine direkt gekoppelte Schnittstelle, eine indirekt gekoppelte Schnittstelle oder eine Vielzahl anderer Schnittstellen. Mit einer Kontaktschnittstelle werden Signale von dem Mikrocontroller an eine Anzahl von Metallkontakten auf der Außenseite der Karte geleitet, die in physischen Kontakt mit ähnlichen Kontakten eines Kartenlesegeräts kommen.
Eine mögliche Verwendung einer Guthabenkarte durch einen Verbraucher ist in 2 dargestellt. 2 zeigt ein Blockdiagramm eines von dem Kunden bedienten Leistungs-Zahlungsterminals 50. Ein Kunde benutzt ein solches Leistungs-Zahlungsterminal üblicherweise in einer direkten Umgebung, um Waren in einem Geschäft oder unmittelbar von dem Terminal selbst zu kaufen. Das Leistungs-Zahlungsterminal 50 kann ein überwachtes Gerät sein oder es kann in ein Selbstbedienungsgerät wie einen Verkaufsautomaten oder ein öffentliches Telefon integriert sein. Zum Beispiel kann das Leistungs-Zahlungsterminal in einem Limonadenautomat eingebaut sein, um Limonade an einen Kunden auszugeben, bei dem der Kunde zahlt, indem er die Guthabenkarte einführt. Oder das Leistungs-Zahlungsterminal kann ein Verkaufsstellenterminal sein, wie es am Tresen einer Kasse vorhanden ist, an der ein Kunde seine Guthabenkarte einführt, um Waren zu kaufen.
Das Leistungs-Zahlungsterminal 50 umfasst einen Router 51, eine Benutzerschnittstelle 52, einen Karten-Handler-/Leser 54, einen Sicherheitskarten-Handler 56, eine Sicherheitskarte 58, eine Terminalanwendung 60, einen Datenspeicher 64 und einen Konzentrator-Handler 66. Bei dem Router 51 handelt es sich um Hardware und Software, um die Informationen zwischen funktionellen Blöcken zu leiten. Die Benutzerschnittstelle 52 steuert den Status von Anzeigen am Terminal und versorgt den Benutzer mit Anweisungen. Zum Beispiel stellt die Benutzerschnittstelle Anweisungen hinsichtlich der Einführung der Guthabenkarte 5 oder der Sicherheitskarte 58 bereit. Die Benutzerschnittstelle stellt auch Anweisungen und/oder Schaltflächen für den Kunden bereit, mit denen er mit der Terminalanwendung 60 in Wechselbeziehung treten kann, um Waren und/oder Dienstleistungen zu kaufen. Der Karten-Handler 54 stellt einen physischen Kartenleser und zugehörige Software zum Akzeptieren und Kommunizieren mit der Guthabenkarte 5 bereit. Auf ähnliche Weise stellt der Karten-Handler 56 einen Kartenleser und zugehörige Software für das Kommunizieren mit der Sicherheitskarte 58 bereit. In Verbindung mit dem Sicherheitskarten-Handler 56 steuert die Sicherheitskarte 58 die Befehlsabfolge des Terminals und stellt die Sicherheit für die Transaktion und für den ganzen Stapel bereit.
Die Terminalanwendung 60 erhält Befehle und Informationen über die Transaktion und leitet den eigentlichen Kauf ein. Außerdem ist die Terminalanwendung 60 für jede anwendungsspezifische Funktionalität verantwortlich, wie das Führen des Kunden durch die Verwendung des Terminals über eine Anzeige, und für das Bereitstellen aller Hardware und Software, die nötig ist, um den Benutzer mit einer Ware und/oder einer Dienstleistung zu versorgen, sobald sie von der Sicherheitskarte darüber informiert worden ist, dass ein entsprechender Wert von der Guthabenkarte abgebucht worden ist.
Der Datenspeicher 64 steuert die Speicherung von Kauftransaktionen und Gesamtsummen. Der Konzentrator-Handler 66 steuert das Senden und Erhalten von Informationen an bzw. von einem Konzentrator aus. Der Konzentrator 68 ist ein Zwischenspeicher-Computer, der mit einer beliebigen Anzahl anderer Leistungs-Zahlungsterminals kommuniziert, um Transaktionsstapel zu sammeln. Der Konzentrator sendet diese Transaktionsstapel dann zur Verarbeitung an ein Abrechnungs- und Verwaltungssystem (wie in 3). Sobald die Stapel-Empfangsbestätigungen verarbeitet sind, werden sie, zusammen mit anderen Systemaktualisierungen, über den Konzentrator an die Terminals geschickt. Der Konzentrator stellt eine erfolgreiche Übermittlung von Daten zwischen den Leistungs-Zahlungsterminals und dem Abrechnungs- und Verwaltungssystem sicher und verhindert die Überlastung des Abrechnungs- und Verwaltungssystems. Der Dienstleister schließt einen Vertrag mit einem Konzentrator zur Sammlung der Leistungszahlungen ab. Der Konzentrator kann auch eine existierende Einrichtung wie eine Telefongesellschaft sein, die ihre eigenen Zahlungen von Kartentelefonen sammelt.
Ein solches Leistungs-Zahlungsterminal 50 ermöglicht es einem Kunden, eine Guthabenkarte zu benutzen, um Waren und/oder Dienstleistungen zu bezahlen, erstellt ein Zahlungsergebnis aus einer Transaktion und bündelt einzelne Zahlungsergebnisse zu einer Sammlung zur Übermittlung an ein Abrechnungs- und Verwaltungssystem, das dann Geld, das von der Guthabenkarte eines Kunden abgebucht worden war, an einen Händler übermittelt, dessen Waren und/oder Dienstleistungen von dem Terminal aus gekauft worden waren.
3 stellt eine Umgebung 100 dar, die nützlich für das Ausstellen von Guthabenkarten und das Abgleichen von Transaktionen ist, die mit einer solchen Karte ausgeführt werden. Ein Terminallieferant 102 baut die Ausrüstung, die von einem Dienstleister 104 benutzt wird, um Kunden, die eine Guthabenkarte besitzen, Waren und/oder Dienstleistungen an einem Terminal 50 bereitzustellen. Der Kartenlieferant 106 schließt einen Vertrag mit einem Hersteller von integrierten Schaltkreisen und einem Kartenhersteller für integrierte Schaltkreise und Plastikkartenkörper, bettet dann den integrierten Schaltkreis in die Karten ein und versieht sie mit einer Seriennummer. Dann liefert er die Karte an den Kartenaussteller 108. In Verbindung mit dem Abrechnungs- und Verwaltungssystem 110 (einem System, wie es von Visa International in Foster City, Kanada, bereitgestellt wird) personalisiert der Kartenaussteller 108 neue Karten und übermittelt dann diese Karten an Einzelpersonen (Kartenbesitzer 112). Der Kartenbesitzer kann dann vor Gebrauch die Karte mit Wert aufladen. Wahlweise kann die Karte auch bereits einen geladenen Wert aufweisen. Der Kartenbesitzer 112 kann die Karte dann an einem Leistungs-Zahlungsterminal 50 nutzen, um Waren und/oder Dienstleistungen von einem Dienstleister 104 zu erwerben. Das Terminal 50 bucht dann den Wert von der Karte ab und tätigt auf diese Weise eine Leistungszahlung.
In regelmäßigen Abständen werden alle Transaktionen in einer Datendatei vom Terminal 50 aus über den Konzentrator 68 und einen Erwerber 114 an das Abrechungs- und Stapelverwaltungssystem 110 geschickt, zusammen mit angehäuften Stapeln von Leistungszahlungen von anderen Terminals. Auf Grundlage dieser Datensammlung erhält das Abrechnungs- und Verwaltungssystem 110 dann Geld von dem Kartenaussteller 108, das ursprünglich von dem Kartenbesitzer 112 gekommen war. Das Abrechnungs- und Verwaltungssystem 110 übermittelt dann eine Pauschalsumme an den Erwerber 114 unter Verwendung eines geeigneten Zahlungsdienstes (wie einem von Visa International bereitgestellten), um die verschiedenen Dienstleister zu bezahlen, die eine Beziehung zu dem Erwerber 114 unterhalten. Auf Grundlage der früheren Datensammlung übermittelt dann der Erwerber 114 einen entsprechenden Geldbetrag an jeden Dienstleister 104, der den Wert der Waren und/oder Dienstleistungen angibt, die dieser Dienstleister Kartenbesitzern an diesem Tag bereitgestellt hatte, basierend auf Abbuchungen von ihren Guthabenkarten.
Obwohl ein solches zuvor beschriebenes Leistungs-Zahlungsterminal nützlich für den Kauf von Waren durch einen Verbraucher mit einer Chipkarte vor Ort ist, erlaubt es nicht den Kauf von Waren und/oder Dienstleistungen durch den Kunden über ein Netzwerk. Außerdem erlaubt ein solches Terminal nicht die unmittelbare Übermittlung von elektronischen Informationen an den Computer eines Verbrauchers. Leistungs-Zahlungsterminals sind üblicherweise speziell gestaltete Hardware- und Softwareeinheiten, die sich an dem Standort eines Händlers befinden. Außerdem ist das Leistungs-Zahlungsterminal so ausgestaltet, dass es die Funktionen der Terminalanwendung (das Bereitstellen von Waren und/oder Dienstleistungen), einen Karten-Handler für die Guthabenkarte und die Transaktionsverwaltung, die in der Sicherheitskarte enthalten ist, in einem Hardwarestandort vereinigt. Eine solche Gestaltung ist nicht geeignet für Transaktionen, bei denen ein Kunde eine Transaktion von nahezu jedem Standort (einschließlich von zuhause oder von seinem Büro aus) schnell und einfach und mit einem Minimum an zuvor getroffenen Maßnahmen und Kosten auszuführen wünscht. Obwohl verschiedene Internetzahlungssysteme vorgeschlagen worden sind, sind diese außerdem nicht auf Transaktionen von geringem Wert ausgerichtet und erlauben nicht die Verwendung einer Chipkarte für Transaktionen über das Internet.
Somit wäre es wünschenswert, über eine Architektur und ein System zu verfügen, die es einem Verbraucher erlauben würden, schnell und leicht Transaktionen über ein offenes Netzwerk wie das Internet unter Verwendung einer Chipkarte auszuführen. Es ist auch wünschenswert, über eine Architektur und ein System zu verfügen, bei dem ein Verbraucher eine Chipkarte nicht nur für Käufe über das Internet, sondern auch für Käufe an vorhandene Leistungs-Zahlungsterminals verwenden kann.
Um jedoch Käufe damit tätigen zu können, muss die Karte zunächst mit einem Wert geladen werden. Ein Wert kann auf unterschiedlichste Art auf eine Guthabenkarte geladen werden. Gegenwärtig ist es unbequem für einen Benutzer, Wert auf seine oder ihre Guthabenkarte zu laden. Ein Benutzer muss sich physisch zu einer Bank oder einer anderen Institution begeben, die über einen Geldautomaten (ATM) oder ein anderes ähnliches Gerät verfügt, um einen Wert auf seine oder ihre Guthabenkarte zu laden. Der Benutzer kann Geld in die Maschine einführen und so einen entsprechenden Wert auf seine Guthabenkarte packen, der Benutzer kann eine Debitkarte verwenden, um einen Wert von dem Konto des Benutzers bei der Bank abzubuchen und auf die Karte zu übertragen, oder eine Kreditkarte kann als Quelle des auf die Guthabenkarte zu übertragenden Geldes benutzt werden. In jedem Fall muss der Benutzer sich zu der Bank begeben, um einen Wert zu laden. Schwierigkeiten bereitet auch, dass nicht alle Banken oder andere Finanzinstitute über eine solche Maschine für das Laden von Werten auf die Guthabenkarte eines Benutzers verfügen.
WO 96/04618 offenbart ein Terminal für die Bezahlung von Fernkäufen und Rechnungszahlungstransaktionen. Daten werden mit einem entfernten Server ausgetauscht. Die Ausführungsformen von WO 96/04618 besitzen eine Chipkarte. Der Benutzer gibt einen Geldbetrag in das Terminal ein, die Chipkarte wird überprüft, um sicherzugehen, dass genug Guthaben auf der Karte ist, und dann wird auf ein entferntes Händlerterminal zugegriffen. Ein Kaufverzeichnis im Terminal wird dann aktualisiert.
WO 96/32701 beschreibt ein Netzwerk aus Einzelhändler-Serverstationen und Kundenstationen. Der Einzelhändlerserver erstellt ein Zahlungsformular, das mehrere Datenposten umfasst und dann über das Netzwerk zum Zahlungsserver übertragen wird, der das Kundenkonto abfragt. Wenn der Zahlungsserver berechtigt ist, erstellt der Zahlungsserver einen Bargeldgutschein, der an den Einzelhändler übertragen wird und den Fortgang der Transaktion erlaubt.
Dementsprechend wäre es auch wünschenswert, über eine Technik zu verfügen, die es einem Benutzer erlaubt, leicht und bequem Wert auf eine Guthabenkarte zu laden.
KURZDARSTELLUNG DER ERFINDUNG
Um das zuvor Ausgeführte zu erreichen und entsprechend dem Zweck der vorliegenden Erfindung werden eine Architektur und ein System offenbart, die es dem Benutzer einer Chipkarte ermöglichen, Waren und/oder Dienstleistungen, die online über ein offenes Netzwerk wie das Internet erworben wurden, zu bezahlen. Außerdem werden eine Architektur und ein System offenbart, die es ermöglichen, dass eine Chipkarte online über ein offenes Netzwerk wie das Internet mit Wert geladen wird.
Als einen ersten Gesichtspunkt stellt die vorliegende Erfindung eine Lösung für die Zahlung im elektronischen Handel bereit, die Verbrauchern ein Online-Gegenstück zu Einkäufen mit Bargeld oder Münzen bietet. Sie weitet das Konzept einer Chipkarte auf den Internetmarktplatz aus, wobei sie eine Wahmöglichkeit für Transaktionen von geringem Wert bereitstellt. Die vorliegende Erfindung erleichtert nicht nur den Kauf von physischen Waren, sondern auch den Kauf von digitalen Gütern (wie elektronischen Informationen).
In einer Ausführungsform der vorliegenden Erfindung steuert ein Kundenserver auf einem Kundenterminal die Wechselbeziehung mit dem Verbraucher und bildet eine Schnittstelle zu einem Kartenleser, der die Chipkarte des Verbrauchers akzeptiert, die in einer spezifischen Ausführungsform eine Guthabenanwendung umfasst. Für die Zwecke dieser Beschreibung wird die Chipkarte mit einer Guthabenanwendung, die in den Ausführungsformen der Erfindung verwendet wird, einfach als „Guthabenkarte" bezeichnet. Ein Zahlungsserver im Internet umfasst einen Computer und Terminals, die Sicherheitskarten enthalten, um die Transaktion und die Speicherung und Sammlung von Daten durchzuführen. An das Kundenterminal und den Zahlungsserver ist auch ein Händlerserver über das Internet angeschlossen, der die von einem Händler zum Kauf angebotenen Waren und/oder Dienstleistungen bewirbt. In einer Ausführungsform der Erfindung umfasst der Händlerserver eine Webseite und der Händler hat mit einem Erwerber einen Vertrag abgeschlossen, Zahlungen über Guthabenkarte für Waren und/oder Dienstleistungen zu akzeptieren, die über das Internet gekauft worden sind. Somit kann ein Verbraucher seine oder ihre Guthabenkarte an einem Kundenterminal-Standort benutzen, um Waren und/oder Dienstleistungen von einem entfernten Händlerserver zu kaufen. Das Internet stellt die Router-Funktionalität zwischen dem Kundenterminal, dem Händlerserver und dem Zahlungsserver bereit.
Vom Standpunkt des Verbrauchers funktioniert die vorliegende Erfindung in einer ähnlichen Weise wie die Verwendung einer Guthabenkarte in einer realen Handelsumgebung. Der Transaktionsablauf ist ähnlich wie die Wechselbeziehung zwischen einer Guthabenkarte und einem Leistungs-Zahlungsterminal in einer direkten Handelsumgebung, aber mit einer Funktionalität, die über das Internet verteilt ist, und zwar zwischen dem Kartenlesegerät, das sich dort befindet, wo der Kunde ist, dem Händlerserver, der die Waren des Händlers bewirbt, und einem Zahlungsserver mit einer Sicherheitskarte, die die Transaktion verwaltet. Alle diese Einheiten können physisch voneinander entfernt sein, wobei die Router-Funktionalität vom Internet bereitgestellt wird. Die vorliegende Erfindung ist leicht zu benutzen. Ein Verbraucher muss weder eine neue Beziehung zu einer Bank oder einer anderen Internet-Dienstleistungsgesellschaft herstellen, noch muss er ein spezielles Interneteinzahlungskonto eröffnen, um mit dem Kauf von Waren und/oder Dienstleistungen im Internet beginnen zu können. Ein Verbraucher benutzt einfach die gegenwärtig erhältlichen Guthabenkarten, um einen Kauf im Internet zu tätigen.
Wenn der Kartenbesitzer die Schaufenster des Händlers im Internet ansieht und sich entscheidet, Waren und/oder Dienstleistungen zu kaufen, wählt er die Zahlungsoption über Guthabenkarte, die von dem Händler angeboten wird. Der Kartenbesitzerführt dann seine oder ihre Karte in einen Kartenleser ein, der mit einem PC verbunden ist (zum Beispiel). Der Kontostand des Kartenbesitzers und der Kaufbetrag werden angezeigt, der Kartenbesitzer gibt den Kauf frei und der Betrag wird von dem auf der Guthabenkarte gespeicherten Wert abgebucht. Der Transaktionsbetrag wird von der Sicherheitskarte oder dem Händlerserver zur späteren Stapelbezahlung an den Aussteller und Erwerber über ein Abrechnungs- und Verwaltungssystem erfasst. In einer Ausführungsform folgt die Transaktionssicherheit und Authentifizierung für das System einer ähnlichen Methodik, wie sie in einem tatsächlichen Leistungs-Zahlungsterminal zwischen einer Guthabenkarte und der Sicherheitskarte in dem Terminal verwendet wird. Vorteilhafterweise kann ein Kunde bereits existierende Guthabenkarten für Käufe über Internet nutzen, ohne vorher ein Konto zu eröffnen, Guthaben oder Gutscheine zu erwerben oder eine neue Beziehung zu einer Bank oder einer anderen Gesellschaft herzustellen.
Sobald ein Wert von der Guthabenkarte abgebucht worden ist, der Händler informiert worden ist und die Sicherheitskarte im Zahlungsserver die Transaktion aufgezeichnet hat, kann außerdem ein vorhandenes Abrechnungs- und Verwaltungssystem benutzt werden, um die Transaktion abzugleichen und die entsprechenden Parteien zu bezahlen. Vorteilhafterweise muss weder ein neues System noch eine neue Methodik zum Abgleichen von Transaktionen entwickelt oder umgesetzt werden. Ein bereits vorhandenes Abrechnungs- und Verwaltungssystem kann verwendet werden, das die Umsetzung der vorliegenden Erfindung beträchtlich vereinfacht.
Die Verwendung einer Guthabenkarte als Zahlungsmittel für Internet-Transaktionen bietet zahlreiche Vorteile. Zum Beispiel kann die Guthabenkarte bei Transaktionen von geringem Wert benutzt werden, bei denen Kreditkarten oder Schecks unrealistisch wären. Andere Vorteile für den Verbraucher umfassen die Erhöhung des Werts einer Guthabenkarte, indem der Zugang zu sowohl realen als auch Internethandelsumgebungen mit einer einzigen Karte ermöglicht wird. Die vorliegende Erfindung erlaubt auch eine anonyme Zahlungslösung für Transaktionen über offene Netzwerke. Außerdem wird bei einer Ausführungsform der Erfindung die Guthabenkarte auf einer herkömmlichen Kreditkarte ausgeführt; eine einzige Karte stellt somit Zahlungslösungen für Transaktionen von sowohl geringem als auch hohem Wert bereit.
Außerdem ist die Verwendung einer Guthabenkarte äußerst vorteilhaft für Transaktionen kleiner Dollarbeträge. Oft widerstrebt es Verbrauchern wie auch Händlern, für Transaktionen kleiner Dollarbeträge Kreditkarten zu verwenden bzw. zu akzeptieren. Dem Verbraucher und dem Händler kann die Beschäftigung mit vielen dieser kleinen Transaktionen Kopfschmerzen bei der Buchführung bereiten und die Kosten nicht wert sein. Auch wegen der Bearbeitungsgebühren für jede Transaktion ist es unwahrscheinlich, dass ein Händler eine Kreditkarte für Transaktionen über einen kleinen Dollarbetrag akzeptiert. Indem ein Händler den Gebrauch einer Guthabenkarte für das Tätigen von Käufen über kleine Dollarbeträge über Internet zulässt, kann er durchaus damit beginnen, für Waren und/oder Dienstleistungen Geld zu verlangen, die er in der Vergangenheit kostenlos bereitgestellt hat. Eine Ausführungsform der Erfindung eignet sich gut für Käufe unter 10,00 $, obwohl Käufe in beliebiger Betragshöhe getätigt werden können.
Die vorliegende Erfindung bietet auch Händlern zahlreiche Vorteile, die Waren und/oder Dienstleistungen über das Internet zu verkaufen wünschen. Zum Beispiel stellt die vorliegende Erfindung eine Zahlungslösung für Transaktionen von geringem Wert bereit, die es Händlern ermöglicht, ein breiteres Sortiment an digitalen Gütern anzubieten. Einem Händler wird auch ein Verfahren zum Wiedererlangen von Kosten für zuvor nicht in Rechnung gestellte Dienstleistungen bereitgestellt, und er erhält sofortigen Zugang zu einer bereits vorhandenen und schnell wachsenden Anzahl von Kartenbesitzern. Außerdem fügt sich die vorliegende Erfindung in ein bestehendes Abrechnungs- und Verwaltungssystem ein, was bedeutet, dass der Händler keine neuen Verfahren für das Abgleichen von Transaktionen einsetzen oder sich mit ihnen vertraut machen muss.
Außerdem muss ein Händler nur eine minimale Investition an Zeit und Geld tätigen, um sich die vorliegende Erfindung zunutze zu machen und Zahlungen über das Internet zu akzeptieren. Der Händler muss sich nicht mit der Entwicklung komplexer Software oder Buchführungsverfahren befassen. Daher werden kleinere Händler aus der vorliegenden Erfindung besonderen Nutzen ziehen. Indem ein Händler eine Geschäftsbeziehung zu einem Erwerber herstellt und Standardhändler-Software installiert, ist ein Händler bereit für den Verkauf von Waren und/oder Dienstleistungen von seiner Webseite aus. Da eine Chipkarte mit einer Guthabenanwendung verwendet wird, führen der Zahlungsserver und das Kundenterminal die Einzelheiten der Transaktion aus und ein Händler ist davon befreit, eine Transaktion überwachen und im Auge behalten zu müssen. Außerdem verwalten der Zahlungsserver und seine zugehörigen Sicherheitskarten die Transaktion und stellen Sicherheit für die Transaktion bereit. Vom Standpunkt eines Händlers gesehen weiß der Händler, dass ein Verbraucher einen Posten zu kaufen wünscht und ein Preis an den Verbraucher übermittelt worden ist, so dass, wenn der Händler eine Bestätigungsmeldung erhält, er den Posten an den Verbraucher ausgeben kann. Der Händler muss sich weder Sorgen über die Sicherheit machen, noch ist er verantwortlich für die Authentifizierung einer Guthabenkarte oder die Bestimmung eines Kontostands auf der Karte. Natürlich könnte ein Zahlungsserver neben dem Händlerserver vorhanden sein oder er könnte sogar derselbe Computer sein. Das bedeutet, dass ein Händler die Zahlungsserver-Funktionalität an seinem eigenen Standort umsetzen könnte, wenn es erwünscht ist.
Als einen zweiten Gesichtspunkt der vorliegenden Erfindung erlaubt ein Ladeverfahren dem Verbraucher, über ein offenes Netzwerk wie das Internet von einem beliebigen geeigneten Gerät aus bequem Wert auf seine oder ihre Guthabenkarte zu laden. Ein Verbraucher darf jeden beliebigen geeigneten Computer zuhause, im Büro oder an einem anderen Ort benutzen, um sich mit seiner Bank oder einer anderen Finanzinstitution zu verbinden. Durch die Verwendung einer geeigneten Meldungsintegrität wird Wert von der Bank auf die Guthabenkarte des Verbrauchers übertragen. Gleichzeitig wird der entsprechende Wert über vorhandene Netzwerke von der Bank zu dem Aussteller der Guthabenkarte zur späteren Bezahlung bei einem Händler übertragen, von dem der Verbraucher Waren oder Dienstleistungen kauft. Vorteilhafterweise nutzt diese Ausführungsform ein vorhandenes Abrechnungs- und Verwaltungssystem für die schließliche Bezahlung der Transaktion zwischen dem Händler und dem Kartenaussteller. Außerdem ist die Transaktion vollständig rechnungsprüffähig und ein Verzeichnis früherer Transaktionen wird zur späteren Anzeige auf der Karte gespeichert. Ein Verbraucher kann daher bequem Wert auf seine oder ihre Karte laden, während ein hohes Maß an Sicherheit aufrechterhalten wird und der Kartenaussteller das nicht ausgegebene Geld auf der Karte nutzen kann.
Vom Standpunkt des Verbrauchers funktioniert die vorliegende Erfindung in einer ähnlichen Weise wie das Laden einer Guthabenkarte an einem Geldautomaten, außer dass der Verbraucher weder Bargeld oder eine zusätzliche Debit- oder Kreditkarte einführen, noch sich zu einer Bank begeben muss. Die Ladefunktionalität ist über das Internet verteilt zwischen dem Kartenlesegerät, das sich dort befindet, wo der Kunde ist, einem Bankserver, der das Konto des Kunden enthält, und einem Ladeserver mit einem Host-Sicherheitsmodul, das Sicherheit bereitstellt. Alle diese Einheiten können physisch voneinander entfernt sein, wobei die Router-Funktionalität vom Internet bereitgestellt wird.
Außerdem muss eine Bank nur eine minimale Investition an Zeit und Geld tätigen, um sich die vorliegende Erfindung zunutze zu machen, um es ihren Kunden zu ermöglichen, Wert von ihren vorhandenen Konten über das Internet zu laden. Die Bank muss sich nicht mit der Entwicklung komplexer Software oder Buchführungsverfahren befassen. Indem eine Bank Softwarebibliotheken installiert, ist sie bereit, damit zu beginnen, von ihrer Webseite aus Wert auf die Karten ihres Kunden zu laden. Vorzugsweise werden Bibliotheken bereitgestellt, die eine Schnittstelle zu einem vorhandenen Server bei einer Bank bilden, um den Aufbau einer HTML-Seite zu erleichtern. Da eine Chipkarte mit einer Guthabenanwendung verwendet wird, führen der Bankserver, der Ladeserver und das Kundenterminal die Einzelheiten der Transaktion aus und die Bank selbst ist davon befreit, die Transaktion überwachen und im Auge behalten zu müssen. Außerdem verwalten der Ladeserver und die Guthabenkarte die Transaktion und stellen Sicherheit für sie bereit. Das heißt, die Bank muss sich weder Sorgen über die Sicherheit machen, noch ist sie verantwortlich für die Authentifizierung einer Guthabenkarte oder für die Bestimmung eines Kontostands auf der Karte. Natürlich könnte ein Ladeserver neben dem Bankserver vorhanden sein oder er könnte sogar derselbe Computer sein. Das bedeutet, dass eine Bank die Ladeserver-Funktionalität an ihrem eigenen Standort umsetzen könnte, wenn es erwünscht ist. In einer bevorzugten Ausführungsform werden der Ladeserver und sein Sicherheitsmodul durch eine separate Finanzinstitution oder durch den Prozessor einer dritten Partei bereitgestellt.
Sowohl der Zahlungs- als auch der Ladegesichtspunkt der vorliegenden Erfindung verschaffen Ausstellern und Erwerbern Vorteile. Die Ausweitung der Funktionalität für eine Guthabenkarte erhöht die Einnahmemöglichkeiten von Kartenbesitzern und Händlern. Auch kann es neue Händler-Marketingmöglichkeiten für Erwerber geben. Die vorliegende Erfindung bietet auch eine Mikrozahlungsmöglichkeit für den elektronischen Handel, ohne die Notwendigkeit, ein separates Produkt oder eine separate Marke einzuführen oder neue Beziehungen zu Dienstleistern herzustellen. Außerdem wird bei einer besonderen Ausführungsform der Erfindung Geld, das auf eine Karte geladen wird, von der ladenden Bank an den Kartenaussteller übermittelt, so dass der Aussteller das Geld auf der Karte nutzen kann, bis es ausgegeben ist.
Ein weiterer Vorteil beider Gesichtspunkte der vorliegenden Erfindung ist ihre Fähigkeit, den Transaktionsverkehr im Internet auf ein Mindestmaß herabzusetzen und die Zeit auf ein Mindestmaß zu verringern, die eine Sicherheitskarte (oder ein Sicherheitsmodul) mit einer Transaktion beschäftigt ist. Bezüglich des Bezahlungsgesichtspunkts kann ein Kundenterminal durch das Emulieren von Sicherheitskartenbefehlen alle Antworten für die Übermittlung an einen Zahlungsserver auf einmal empfangen und gruppieren, anstatt sie nacheinander über das Internet abzuwickeln. Der Zahlungsserver kann dann eine Guthabenkarte emulieren, weil er mit der Sicherheitskarte bei der Zustellung der Antworten an die Sicherheitskarte in Wechselbeziehung tritt. Das Ergebnis ist weniger Meldungsverkehr über das Internet, was Zeit und Unterbrechungen erspart.
Außerdem wird durch die Zustellung einer erwarteten Guthabenkartensignatur an den Zahlungsserver die Sicherheitskarte davon befreit, die Signaturen selbst vergleichen zu müssen und kann schneller freigeben und zu einer neuen Transaktion übergehen. Der Zahlungsserver kann auch die erwartete Guthabenkartensignatur für den Vergleich an das Kundenterminal oder den Händlerserver zustellen und somit den Meldungsverkehr zwischen dem Zahlungsserver und dem Kundenterminal auf eine Hin- und Rückreise reduzieren.
Die vorliegende Erfindung ist für die Verwendung mit jedem beliebigen Guthabenkartentyp geeignet, der einen Betrag speichern und einen Wert auf einen Befehl hin verringern kann. In einer Ausführungsform der Erfindung eignet sich eine als Prozessorkarte ausgeführte Guthabenkarte gut. Die Verwendung einer Prozessorkarte hat Vorteile, wo die Informationsverarbeitung auf der Karte erfolgt anstatt in dem Terminal oder dem Host-Computer. Prozessorkarten erlauben das Ausführen der Verschlüsselung von der Karte, erlauben das Erstellen von Signaturen und können zahlreiche Passworte oder persönliche Kennungen (wie biometrische Daten, die den Besitzer der Karte eindeutig identifizieren) unterbringen. Prozessorkarten stellen auch erhöhte Datensicherheit bereit, eine Anti-Betrugs-Fähigkeit, Flexibilität bei den Anwendungen, eine Mehrzweck-Fähigkeit und eine Offline-Validierung. Weil hohe Telekommunikationskosten und/oder die geringe Verlässlichkeit eines Netzwerks Online-Authorisierung unanwendbar machen, ist eine Guthabenkarte mit der Fähigkeit zur Offline-Verarbeitung und -Authentifizierung an sich schon äußerst wertvoll.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung und weitere ihrer Vorteile können am besten mit Bezug auf die folgende Beschreibung zusammen mit den begleitenden Zeichnungen verstanden werden, in denen
1 ein Blockdiagramm eines Beispiels für eine Guthabenkarte ist, die nützlich in Ausführungsformen der vorliegenden Erfindung ist.
2 ein Blockdiagramm eines Leistungs-Zahlungsterminals ist, in das eine Guthabenkarte eingeführt werden kann, um Waren zu kaufen.
3 ein Blockdiagramm eines Beispiels für ein Abrechnungs- und Verwaltungssystem ist, das nützlich zum Abgleichen von Finanztransaktionen ist, die von einem Leistungs-Zahlungsterminal erhalten werden.
4 eine Architektur und ein System für die Zahlung über Internet unter Verwendung einer Guthabenkarte darstellt.
5 eine Zahlungs-Ausführungsform der vorliegenden Erfindung darstellt.
6 eine weitere Ausführungsform der vorliegenden Erfindung darstellt, in der die Sicherheitskarte früher ausgibt.
7 eine weitere Zahlungs-Ausführungsform der vorliegenden Erfindung darstellt, die weniger Hin- und Rückreise-Meldungen zwischen dem Kundenterminal und dem Zahlungsserver aufweist.
8 eine weitere Zahlungs-Ausführungsform der vorliegenden Erfindung darstellt, bei der der Händlerserver Guthabenkartensignaturen vergleicht.
9 eine hinzugefügte Verschlüsselungsschicht darstellt, die nützlich für Ausführungsformen der vorliegenden Erfindung ist.
10 ein Flussdiagramm ist, das die Perspektive eines Benutzers auf eine Guthabenkartenkauftransaktion unter Verwendung der vorliegenden Erfindung beschreibt.
11A–11D ein Flussdiagramm sind, das die Bearbeitung eines Benutzerkaufs unter Verwendung einer Ausführungsform der vorliegenden Erfindung beschreibt.
12 ein Flussdiagramm ist, das die mögliche Ausführungsform von 6 beschreibt.
13 ein Flussdiagramm ist, das die mögliche Ausführungsform von 7 beschreibt.
14 ein Flussdiagramm ist, das die mögliche Ausführungsform von 8 beschreibt.
15A und 15B ein Flussdiagramm sind, das die hinzugefügte Sicherheitsschicht von 9 beschreibt.
16 eine Architektur und ein System für die Authentifizierung über ein Internet unter Verwendung einer Guthabenkarte darstellt.
17 ein System zum Laden von Wert auf eine Guthabenkarte nach einer Ausführungsform der vorliegenden Erfindung darstellt.
18A–18D ein Flussdiagramm sind, das das Laden der Guthabenkarte eines Verbrauchers unter Verwendung einer Ausführungsform der vorliegenden Erfindung beschreibt.
19 ein Blockdiagramm eines typischen Computersystems ist, das für die Verwendung in Ausführungsformen der vorliegenden Erfindung geeignet ist.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
ALLGEMEINE ARCHITEKTUR
Die vorliegende Erfindung teilt die Funktionalität, die an einer Transaktion beteiligt ist, unter Verwendung einer Guthabenkarte auf, um die Router-Fähigkeiten des Internets zu nutzen. 4 stellt symbolisch eine Architektur 200 für ein Internetzahlungssystem dar, das eine Chipkarte einschließt, wie eine Chipkarte, die eine Guthabenfähigkeit besitzt. Ein Internetladesystem ist in 17 dargestellt und kann eine ähnliche Funktionalität besitzen, wie nachfolgend beschrieben wird. Dargestellt sind ein Internet 202, ein Kundenterminal 204, ein Zahlungsserver 206 und ein Händlerserver 208. Die lokalen Kartenbesitzerfunktionen, die eine Verbraucher-Karten-Schnittstelle, eine Anzeige und Akzeptieren/Abbrechen-Wahlmöglichkeiten umfassen, werden am Kundenterminal 204 ausgeführt. Die Zahlungsfunktionen, die eine Sicherheitskartensteuerung, einen Datenspeicher und die Verwendung eines Konzentrators umfassen, werden von dem Zahlungsserver 206 ausgeführt. Die Präsentation und die letztendliche Lieferung von Waren und/oder Dienstleistungen durch einen Händler werden unter der Kontrolle des Händlerservers 208 durchgeführt. Das Internet 202 führt Router-Funktionen zwischen jeder Einheit aus. Es sollte geschätzt werden, dass das Internet 202 die Form des Internets aufweisen kann, das gegenwärtig in Gebrauch ist, oder auch ein anderes offenes Netzwerk sein kann, das unter Verwendung jeder beliebigen Kombination von Computer-, Telefon-, Mikrowellen-, Satelliten- und/oder Kabelnetzwerken umgesetzt ist.
Im Grunde steuert das Kundenterminal 204 die Wechselbeziehung mit einem Benutzer und bildet eine Schnittstelle zum Kartenleser 210, der eine Chipkarte akzeptiert, die eine Guthabenanwendung aufweist. Der Einfachheit halber wird die Karte 5 im noch verbleibenden Rest dieser Beschreibung als Guthabenkarte 5 bezeichnet. Der Zahlungsserver 206 kommuniziert direkt mit einem Terminal oder über einen Konzentrator 212, der eine beliebige Anzahl von Terminals 214–216 handhabt, von denen jedes eine Sicherheitskarte 218 bzw. 220 besitzt. Der Zahlungsserver 206 kommuniziert auch mit dem Konzentrator 68 zum Übertragen von Transaktionsdaten an ein Abrechnungs- und Verwaltungssystem. Die Datenbank 223 speichert für jede Transaktion alle geeigneten Informationen, die den Zahlungsserver 206 durchlaufen. Die Verwendung einer solchen Datenbank ermöglicht es einer beliebigen Anzahl von Händlern (oder Händlerservern), den Zahlungsserver 206 für Transaktionen zu nutzen. Der Zahlungsserver 206 steuert Zahlungsfunktionen wie die Handhabung von angeschlossenen Terminals, das Verwalten der Datenbank 223 und Sammelfunktionen. Der Händlerserver 208 ist eine Stelle, die einen Vertrag mit einem Erwerber abgeschlossen hat, Guthabenkartentransaktionen als Zahlung für Waren und/oder Dienstleistungen zu akzeptieren, die über das Internet gekauft werden.
Die Guthabenkarte 5 kann eine Vielzahl von Formen aufweisen und ist in vielen Situationen nützlich, in denen es wünschenswert ist, einen Geldwert auf einer Karte zu speichern, die ein Kunde benutzen kann. Im Allgemeinen handelt es sich bei einer Guthabenkarte um jede beliebige Karte oder ein ähnliches Gerät, das einen Wert speichern kann, der verringert wird, wenn die Karte benutzt wird. Die Karte kann komplett mit einem Guthabenwert gekauft oder der Wert kann später durch einen Benutzer zu der Karte hinzugefügt werden. Der Wert solcher Karten kann auch wieder aufgeladen werden. Natürlich muss eine Guthabenkarte nicht die Form einer herkömmlichen Kreditkarte aufweisen, sondern könnte in jeder beliebigen Form und aus jedem beliebigen Material vorliegen, das Wert speichern und von einem Benutzer für eine Zahlungstransaktion bedient werden kann. Andere Formen, die eine Guthabenkarte aufweisen kann, sind zum Beispiel alle elektronischen Darstellungen. Außerdem kann die Funktionalität der Guthabenkarte 5 in Software auf dem Kundenterminal 204 umgesetzt sein, das heißt, die Karte 5 kann eine „virtuelle" Karte sein.
Eine Guthabenkarte kann neben dem einfachen Speichern von Guthaben auch eine Vielzahl von Funktionen ausführen. Eine Karte kann dem Speichern von Guthaben dienen oder einen Speicher und Programme auch für andere Anwendungen umfassen. Zum Beispiel bezeichnet eine „elektronische Geldbörse" eine Prozessorkarte, die eine Vielzahl von finanziellen Transaktionen und Identifizierungsfunktionen ausführen kann. Solch eine Karte kann Debit-, Kredit-, Vorauszahlungs- und andere Funktionen ausführen. Eine Guthabenkarte umfasst üblicherweise Informationen wie eine Bankkennungsnummer, eine Abfolgenummer, einen Kaufschlüssel, einen Ladeschlüssel, einen Aktualisierungsschlüssel, ein Ablaufdatum, einen Transaktionszählerstand, einen Sitzungsschlüssel usw. zusätzlich zu einem laufenden Kontostand.
Eine Guthabenkarte kann auch als Vorauszahlungskarte, als Bargeldkarte oder als Wertverringerungskarte bezeichnet werden. Eine Guthabenkarte kann auch unter Verwendung einer Vielzahl von Kartentechnologien umgesetzt werden. Zum Beispiel ist eine Guthabenkare üblicherweise als eine Karte umgesetzt, die einen oder mehrere integrierte Schaltkreise umfasst. Ein Beispiel für eine Karte mit integriertem Schaltkreis ist eine Speicherkarte, die ein Halbleiterelement zum Speichern von Informationen aufweist, der aber die Rechenfähigkeit fehlt. Ein weiteres Beispiel für eine Karte mit integriertem Schaltkreis ist eine Prozessorkarte, die nicht nur einen Speicher, sondern auch einen Mikrocontroller aufweist, um es der Karte zu ermöglichen, Entscheidungen zu treffen. Eine Prozessorkarte kann auch als Mikroprozessorkarte oder „Chipkarte" bezeichnet werden.
Eine Prozessorkarte kann ein Verschlüsselungsmodul umfassen, um eine Vielzahl von Sicherheitsvorkehrungen bereitzustellen. Die Sicherheitsvorkehrungen können zum Beispiel einfache PIN-Nummern, biometrische Daten, einfache Algorithmen oder anspruchsvolle Algorithmen wie den Data Encryption Standard (DES) oder die Rivest, Sharnir, Adelman (RSA)-Verschlüsselung umfassen. Die Karte kann somit diese Vorkehrungen anwenden, um Benutzer, Kartenleser usw. zu überprüfen, um Sicherheitskarten zu validieren und/oder um eine eindeutige Signatur bereitzustellen. Vorzugsweise umfasst die Karte 5 eine beliebige Anzahl von Schlüsseln, die dem Kartenaussteller bekannt sind, die im Laufe einer Zahlungs- oder Ladetransaktion verwendet werden, um Signaturen für die Validierung der Guthabenkarte, der Sicherheitskarte oder des Moduls oder des Systems selbst zu erstellen.
Das Kundenterminal 204 ist ein beliebiges geeignetes Gerät für die Wechselbeziehung mit einer Guthabenkarte 5 und das Kommunizieren mit einem Zahlungsserver oder einem Händlerserver über ein Netzwerk. Zum Beispiel kann das Kundenterminal 204 ein Mainframe-Computer, eine Workstation, ein Personal Computer, ein Kiosk oder ein beliebiger anderer Typ von Leistungs-Zahlungsterminal sein, den ein Kunde nutzen könnte, um Waren und/oder Dienstleistungen zu kaufen. Außerdem kann das Kundenterminal 204 auch in einem beliebigen tragbaren Gerät wie einem Laptop, einem Mobiltelefon oder in einer Vielzahl von persönlichen digitalen Assistenten (PDA) enthalten sein, wie sie von Apple Computer, Inc. oder U.S. Robotics hergestellt werden. Der Kartenleser 210 ist ein beliebiges geeignetes Schnittstellengerät, das dazu dient, Informationen und Befehle zwischen dem Kundenterminal 204 und der Guthabenkarte 5 zu übermitteln. Zum Beispiel kann der Kartenleser 210 ein Kartenleser sein, der von Fischer-Farr International in Naples, Florida, von Hewlett-Packard in Palo Alto, Kalifornien, von Schlumberger, von Gem Plus usw. hergestellt wird. Der Kartenleser 210 kann eine beliebige Anzahl von Formen aufweisen, wie eine einzelne Einheit, die in dem Kundenterminal integriert ist, an die Tastatur des Kundenterminals angeschlossen ist oder sogar in eine Einheit von der Größe einer Diskette eingebaut ist, die von dem Diskettenlaufwerk des Kundenterminals gelesen werden kann usw.
Das Kundenterminal 204 umfasst das Client-Codemodul 224 und das Kartenlesemodul 226. Das Lesemodul 226 kann unter Verwendung einer beliebigen geeigneten Software und beliebiger Bibliotheken für das Kommunizieren mit dem Kartenleser 210 umgesetzt werden, wobei seine tatsächliche Umsetzung vom Typ des Kartenlesers abhängt, der verwendet wird. Das Client-Modul 224 steuert die Kommunikation zwischen dem Kundenterminal, dem Kartenleser, dem Zahlungsserver und dem Händlerserver. Das Client-Modul 224 kann unter Verwendung jedes beliebigen geeigneten Codes umgesetzt werden. In einer Ausführungsform der Erfindung wird das Client-Modul 224 unter Verwendung einer Kombination des „C"-Codes und eines Java-Applets umgesetzt. Das Applet wird auch durch Parameter von einer HTML-Seite ergänzt, die von dem Händlerserver geschickt werden. Es wird davon ausgegangen, dass der Java-Code gut für das Umsetzen der Module auf dem Kunden-, Zahlungs- und Händlerserver geeignet ist, weil er plattform-unabhängig ist und sogar den verwendeten „C" und „C++"-Code ersetzen könnte.
Das Client-Modul 224 ist auch verantwortlich für die Steuerung von Anzeigen für den Benutzer und die Wechselbeziehung zwischen der Karte und dem Kartenleser. Das Modul erstellt auch die Abbuchungsanforderungsmeldung, nachdem es sämtliche Startinformationen von der Karte und den Kaufbetrag von dem Händlerserver erhalten hat. Das Client-Modul kann mit allen Komponenten im Internet kommunizieren, entweder direkt oder indirekt.
Der Zahlungsserver 206 umfasst das Zahlungscodemodul 228 und die Terminalschnittstelle 230. Wie das Kundenterminal 204 kann der Zahlungsserver 206 unter Verwendung jedes beliebigen geeigneten Computers umgesetzt werden. Ein Personal Computer zum Beispiel ist gut geeignet. Es kann einen Zahlungsserver für jeden Händlerserver geben oder ein einziger Zahlungsserver kann eine beliebige Anzahl von Händlerservern bedienen. Wahlweise kann es zahlreiche Zahlungsserver für einen einzigen Händler geben. Außerdem muss der Zahlungsserver 206 nicht entfernt von dem Händlerserver 208 sein, sondern kann sich an demselben Standort befinden und eine andere Internetadresse haben, oder der Zahlungsserver und der Händlerserver können sogar auf demselben Computer eingerichtet sein. Der Zahlungsserver 206 ist so ausgestaltet, dass er die Kommunikation zwischen der Guthabenkarte des Benutzers und der Sicherheitskarte eines Terminals erleichtert. Wenn ein Teil der Transaktion nicht vollständig abgeschlossen wird, kann der Zahlungsserver die beteiligten Systemkomponenten benachrichtigen.
Das Zahlungsmodul 228 kann unter Verwendung jedes beliebigen geeigneten Codes umgesetzt werden. Zum Beispiel wird das Zahlungsmodul 228 unter Verwendung einer Kombination des „C"-Codes, des „C++"-Codes und des Java-Codes umgesetzt. Das Zahlungsmodul 228 ist in einer spezifischen Ausführungsform ein Multi-Thread-Prozess, der auf Anfrage zahlreiche gleichzeitige Client-Applet-Transaktionen bedienen kann. Das Modul ist verantwortlich für die Steuerung aller Wechselbeziehungen mit den Terminals und ihrem Konzentrator einschließlich der Transaktionssammelfunktion. Für einzelne Transaktionen steuert das Zahlungsmodul die Meldungsströme und zeichnet vorläufige Ergebnisse auf. Wenn sich ein Applet mit dem Zahlungsserver verbindet, erstellt es einen Transaktions-Thread, um die Transaktion über ihre Lebensdauer hinweg zu unterstützen. Jeder Thread weist nacheinander ein Terminal für die Kommunikation zu. Es hat sich erwiesen, dass eine direkte Kommunikation zwischen Transaktions-Threads und Terminals wünschenswerte Ergebnisse erbringt.
Die Terminalschnittstelle 230 ist ein beliebiger geeigneter Satz Software und Bibliotheken für das Kommunizieren mit einem Terminal 214, entweder direkt oder, wie dargestellt, über den Terminalkonzentrator 212. Die tatsächliche Ausführung von Terminalschnittstelle 230 hängt vom Terminaltyp ab, der verwendet wird. Ein Terminal wie 214 kann jedes beliebige geeignete Terminal sein, wie es in dem Fachgebiet bekannt ist. Es hat sich erwiesen, dass zum Beispiel ein von Schlumberger hergestelltes iq Delta 2010 Terminal wünschenswerte Ergebnisse bereitstellt. Ein solches Terminal kann eine Vielzahl von Befehlen unterstützen, die an der Terminalschnittstelle entstehen. Diese Befehle emulieren die normalen Antworten, die ein angeschlossenes Terminal von der Guthabenkarte zu der Sicherheitskarte weitergeben würde. Die eigentlichen Sicherheitskartenbefehle werden im Terminal aufbewahrt, während das Terminal die Aufgaben ausführt, die nötig sind, um das Vorhandensein einer Guthabenkarte zu simulieren.
Die Sicherheitskarte 218 kann jede beliebige geeignete Sicherheitskarte sein, wie sie in dem Fachgebiet bekannt ist (oft als Purchase Secure Application Module – PSAM bezeichnet). In weiteren Ausführungsformen kann die Funktionalität der Sicherheitskarte 218 durch ein Hardware-Sicherheitsmodul ersetzt werden, oder sie könnte innerhalb des Zahlungsservers in Hardware oder sogar in Software umgesetzt werden.
Die Sicherheitskarte 218 ist zum Beispiel eine austauschbare Prozessorkarte von der Größe einer Kreditkarte, die darauf programmiert ist, Daten zu verarbeiten und zu speichern, die sich auf Finanztransaktionen beziehen. Die Sicherheitskarte 218 umfasst einen Mikrochip, der in die Karte eingebettet ist und es der Sicherheitskarte ermöglicht, die Guthabenkarte des Benutzers zu authentifizieren und zu validieren. Wenn die Guthabenkarte eines Benutzers von der Sicherheitskarte akzeptiert wird und die Guthabenkarte genügend Wert enthält, garantiert die Sicherheitskarte, dass der Händler, der die Waren und/oder Dienstleistungen bereitstellt, eine Zahlung entsprechend dem Betrag erhält, der für die gelieferten Waren und/oder erwiesenen Dienstleistungen von der Guthabenkarte abgebucht wurde. In einer bevorzugten Ausführungsform umfasst die Sicherheitskarte auch DES-Kaufsicherheitsschlüssel und authentifiziert die Guthabenkarte während einer Kauftransaktion und sichert die Gesamtsumme der Zahlung und der Sammlung. Eine Sicherheitskarte speichert auch Signaturalgorithmen für im Gebrauch befindliche Guthabenkarten. Eine Sicherheitskarte kann auch eine Transaktionskennung für die aktuelle Transaktion umfassen, eine finanzielle Summe aller Transaktionen, die zu bezahlen bleiben, einen Sitzungsschlüssel und Generalschlüssel für alle in Gebrauch befindlichen Guthabenkarten. Außerdem kann die Sicherheitskarte Generationen von Schlüsseln umfassen, Anzeiger für gesperrte Karten, das Datum der letzten Aktualisierung, mehrere Kartenprogramme, verschiedene Währungskurse und zusätzliche Sicherheit.
Der Konzentrator 68 ist ein Zwischenspeichercomputer, der mit Terminals kommuniziert, um Stapel von Kauftransaktionen zu sammeln. Der Konzentrator sendet diese Transaktionsstapel dann an zur Verarbeitung ein Abrechnungs- und Verwaltungssystem. Sobald die Stapelempfangsbestätigungen verarbeitet sind, werden sie, zusammen mit anderen Systemaktualisierungen, über den Konzentrator zurück an die Terminals geschickt.
Der Händlerserver 208 umfasst ein Händlercodemodul 232. Der Händlerserver 208 kann auf jedem beliebigen geeigneten Computer umgesetzt werden, der mit Benutzern über ein Internet kommunizieren und ihnen Informationen vorlegen kann. Das Händlercodemodul 232 kann unter Verwendung eines beliebigen geeigneten Codes umgesetzt werden. Zum Beispiel kann das Händlercodemodul 232 unter Verwendung einer Kombination von Perl, HTML und dem Java-Code umgesetzt werden. Der Händlerserver 208 ist üblicherweise ein generischer Webserver, der speziell für die Tätigkeit des Händlers ausgelegt ist. Der Händlerserver 208 kann Datenbanken, CGI-Skripte und Back-Office-Programme umfassen, die HTML-Seiten für einen Internetbenutzer erstellen.
Nun folgt eine kurze Erläuterung des Ablaufs einer Transaktion. Während einer Finanztransaktion tauschen das Kundenterminal und der Händlerserver die Informationen 234 über das Internet 202 aus. Jede Transaktion, die von einem Benutzer eingeleitet wird, besitzt eine Transaktionskennung, die im Händlerserver erstellt wird, und eine Händlerkennung, die für den Zahlungsserver eindeutig ist, ist ebenfalls von dem Händlerserver erhältlich. Das Client-Modul 224 und der Zahlungsserver benutzen diese eindeutige Transaktionskennung ebenfalls, um Informationen über die Transaktion zu verfolgen und aufzuzeichnen. Der Händlerserver 208 erstellt eine eindeutige Identifizierung der Transaktion, vervollständigt weitere erforderliche Parameter, verschlüsselt entsprechend, erstellt eine HTML-Seite und schickt sie an das Kundenterminal. Das Client-Modul lässt 235 mit der Guthabenkarte in Wechselbeziehung treten und erstellt eine Abbuchungsanforderungsmeldung, die diesbezügliche Karteninformationen, den Kaufbetrag und weitere Informationen umfasst, die von dem Händlerserver geliefert werden.
Das Kundenterminal lässt dann 236 mit dem Zahlungsserver 206 in Verbindung treten, zuerst, indem es die Abbuchungsanforderung an den Zahlungsserver weiterleitet. Der Zahlungsserver 206 überprüft die Transaktion, um zu bestimmen, ob es sich um eine gültige Transaktion von einem bekannten Händler handelt. Die Transaktion wird in der Transaktionsdatenbank 223 des Zahlungsservers verzeichnet. Nach Abschluss einer Transaktion erstellt der Zahlungsserver 206 eine Ergebnismeldung, die die Identifizierung der Transaktion enthält, und unterschreibt sie. Die Meldung wird dann über das Kundenterminal 204 an den Händlerserver 208 geleitet. Der Händlerserver 208 validiert dann die Ergebnismeldung. Nachdem der Händlerserver 208 bestimmt hat, dass die Transaktion erfolgreich war, erstellt er eine HTML-Seite für die erhaltenen Informationen und schickt sie an das Kundenterminal 204. Wahlweise kann der Händler die gekauften Waren an diesem Punkt auch an den Benutzer liefern. Es ist für den Zahlungsserver und den Händlerserver auch möglich, die Informationen 238 einander direkt mitzuteilen. Da das Kundenterminal 204 bereits eine Verbindung zu dem Händlerserver und dem Zahlungsserver hergestellt hat, werden vorzugsweise die Verbindungen 234 und 236 benutzt, um Informationen zwischen dem Zahlungsserver und dem Händlerserver auszutauschen, anstatt eine neue Verbindung 238 herzustellen.
BENUTZERPERSPEKTIVE BEI EINER ZAHLUNGSTRANSAKTION
10 ist ein Flussdiagramm, das eine Ausführungsform der vorliegenden Erfindung vom Standpunkt eines Benutzers beschreibt, wie sie bei der in 4 dargestellten Ausführungsform auftreten kann. In Schritt 502 erwirbt ein Benutzer eine Guthabenkarte und lädt Wert auf die Guthabenkarte. Wahlweise kann ein Benutzer eine Guthabenkarte erwerben, die bereits Wert enthält. Diese Guthabenkarte kann die Form einer beliebigen der oben beschriebenen Guthabenkarten aufweisen, die Wert speichern und Wert von der Karte abbuchen können. In Schritt 504 greift der Benutzer über die Kommunikationsverbindung 234 über das Internet auf die Webseite des Händlerservers zu. Dieser Zugriff auf eine Webseite kann auf jede beliebige Weise durchgeführt werden, wie durch das Verwenden eines beliebigen, im Handel erhältlichen Webbrowsers. In Schritt 506 führt der Benutzer eine Guthabenkarte in den Kartenleser 210 am Benutzerterminal ein. Wahlweise kann der Benutzer die Karte einführen, bevor er auf die Webseite zugreift, oder sogar nach der Auswahl von Waren und/oder Dienstleistungen von der Webseite des Händlers. In Schritt 508 schaut der Benutzer die Webseite des Händlers an und wählt Waren und/oder Dienstleistungen zum Kauf von dem Händler aus, wobei er die Webseitenschnittstelle verwendet, die der Händler bereitgestellt hat. Der Benutzer wählt dann einen entsprechenden Knopf auf der Webseite des Händlers aus, um anzugeben, was der Benutzer zu kaufen wünscht. Anschließend erhält der Benutzer in Schritt 510 einen Gesamtverkaufsbetrag von dem Händlerserver und wird angewiesen, eine Schaltfläche auf der Webseite zu drücken, der anzeigt, dass der Benutzer unter Verwendung der Guthabenkarte mit dem Kauf fortzufahren wünscht.
In Schritt 512 verarbeiten die Architektur und das System der vorliegenden Erfindung (wie zum Beispiel in 4 dargestellt) die Bestellung des Benutzers über den Zahlungsserver, das Terminal und die Sicherheitskarte. In Schritt 514 wird der Gesamtverkaufsbetrag von der Guthabenkarte des Benutzers abgebucht und der Benutzer erhält eine „Abgebucht-"Meldung am Benutzerterminal. Diese Meldung ist optional, wenn das System so ausgelegt ist, dass es den Benutzer nicht über diese Abbuchung informiert. In Schritt 516 erhält der Benutzer eine Bestätigungsmeldung von dem Händlerserver, die anzeigt, dass die Transaktion abgeschlossen worden ist. Der Benutzer kann nun die erhaltenen Informationen herunterladen und/oder eine Quittung für Waren und/oder Dienstleistungen erhalten, die von dem Händler zu einem späteren Zeitpunkt geliefert bzw. erbracht werden sollen. In Schritt 518 erhält der Händler über ein Abrechnungs- und Verwaltungssystem die Zahlung für die gelieferten Waren und/oder erbrachten Dienstleistungen mittels Informationen auf sein Bankkonto, die von dem Zahlungsserver gesammelt wurden. In einer Ausführungsform der Erfindung wird ein existierendes Abrechnungs- und Verwaltungssystem benutzt, ebenso wie eine bestehende Methodologie zum Übertragen von Informationen von einer Sicherheitskarte zum späteren Abgleichen. Diese Verwendung eines bestehenden „Back End" ermöglicht das schnelle und kostengünstige Umsetzen der Systeme der Erfindung. Dieser Ansatz stellt auch sicher, dass Karten, die in dem System verwendet werden, mit anderen Guthabenterminals kompatibel sind.
GENAUER ABLAUF EINER ZAHLUNGSTRANSAKTION
5 stellt die ausführliche Ausführungsform einer Internetzahlungsarchitektur 200 dar, die ein Kundenterminal 204, einen Zahlungsserver 206 und einen Händlerserver 208 besitzt. Eine Guthabenkarte 5 kommuniziert mit dem Kundenterminal 204, und eine Sicherheitskarte 218 in einem Terminal 214 kommuniziert mit dem Zahlungsserver 206. Der Einfachheit halber sind in dieser Figur keine weiteren Elemente des Systems dargestellt, das in 4 gezeigt wird. Unter Verwendung des Flussdiagramms von 11A bis 11D mit Bezug auf 5 wird nun eine Ausführungsform eines Verfahrens beschrieben, durch das eine Finanztransaktion über das Internet durchgeführt werden kann.
Es sollte geschätzt werden, dass eine große Vielzahl von Fachausdrücken verwendet werden kann, um den Meldungsfluss durch die Architektur zu beschreiben. Zum Beispiel können die Fachausdrücke, die hier verwendet werden, um die aufeinander folgenden Meldungen Abbuchungsanforderung, Abbuchung, Erfolg und Bestätigung zu beschreiben, auch durch die folgenden Fachausdrücke bezeichnet werden: Abbuchungsanforderung, IEP (Intersector Electronic Purse)-Abbuchung, Abbuchungsantwort und Abbuchungsergebnis (oder Meldungsergebnis).
Zuerst wird ein geeigneter Webbrowser des Kundenterminals 204 von dem Benutzer verwendet, um auf die Webseite eines Händlerservers zuzugreifen, wie durch 302 angezeigt wird. In Schritt 602 wählt der Benutzer Waren und/oder Dienstleistungen von der Händlerwebseite aus und gibt der Seite an, dass der Benutzer diese Posten unter Verwendung einer Guthabenkarte zu kaufen wünscht, wie durch 304 dargestellt. In Schritt 604 erhält der Händlerserver diese Anforderung für eine Guthabenkartentransaktion.
In Schritt 606 erstellt der Händlerserver eine HTML-Seite, die die folgenden Client-Applet-Parameter umfasst: die Gesamtkosten der Transaktion, wie sie von dem Händlerserver bestimmt wurden; der Währungstyp, der verwendet wird; den Port und die IP-Adresse des Zahlungsservers; eine eindeutige Transaktionskennung, die sowohl von dem Zahlungsserver als auch dem Händlerserver verwendet wird, um eine Transaktion zu überwachen; und eine eindeutige Händlerkennung, die dem Händler von dem Erwerber zugewiesen wird und die dem Zahlungsserver bekannt ist. Weitere Informationen können ebenfalls enthalten sein, wie der Währungsexponent, eine Status-URL-Adresse des Händlerservers, die für die Kommunikation von dem Kundenterminal aus verwendet wird, und einen von dem Händlerserver erstellten Schlüssel und weitere Sicherheitsinformationen, um die Identität des Händlerservers und die Integrität der Meldung sicherzustellen. Weitere auf den Vorgang bezogene Informationen, wie die Software-Ausgabe-Nummer, eine Verschlüsselungsmethodologie und Schlüssel können ebenfalls übermittelt werden. Sobald diese Seite erstellt ist, wird die Seite an den anfordernden Browser geschickt 306 und löst das Laden des Client-Codemoduls (in diesem Beispiel ein Java-Applet) im Kundenterminal aus.
Einige Browser erlauben möglicherweise aus Sicherheitsgründen nicht, dass ein Applet eine dynamische Linkbibliothek (Dynamic Link Library – DLL) aufruft. In einer Ausführungsform der vorliegenden Erfindung wird das Client-Applet, zusammen mit jeder beliebigen erforderlichen DLL, im Voraus auf das Kundenterminal geladen. Dann ist es dem Händlerserver möglich, das Client-Applet und die DLLs dynamisch aufzurufen, um diese Sicherheitsvorkehrung zu umgehen.
In Schritt 608 tritt das Client-Modul des Kundenterminals in Wechselbeziehung mit der Guthabenkarte 5, um Karteninformationen 308 zu erlangen, um eine Abbuchungsanforderungsmeldung zur späteren Übermittlung 310 an den Zahlungsserver 206 zu erstellen. In einer Ausführungsform der Erfindung lädt das Client-Applet eine lokale DLL, tätigt einen API-Aufruf an diese Bibliothek, die ihrerseits eine weitere DLL aufruft, die schließlich den Kartenleser aufruft. Auf diese Weise wird die Kommunikation mit der Karte erreicht. Sobald die Antworten von der Karte erhalten sind, vereinigt das Client-Modul diese Antworten auch zu einem Bytestrom, der für die Übermittlung an einen Zahlungsserver über ein Netzwerk geeignet ist. An diesem Punkt werden auch der Währungstyp und das Ablaufdatum auf der Karte überprüft, und die Gesamtkosten der bestellten Ware wird im Hinblick auf den Kartenkontostand überprüft, um sicherzustellen, dass der Wert auf der Karte groß genug ist, um die Transaktion zu decken. Wenn die Überprüfungen nicht erfolgreich sind, wird eine entsprechende Meldung an den Benutzer geschickt, und diese Transaktion endet.
Das Client-Modul emuliert eine Vielzahl von Sicherheitskartenbefehlen, um Antworten von diesen Befehlen von der Guthabenkarte zu erhalten. Da die Guthabenkarte und die Sicherheitskarte nun physisch getrennt voneinander sind und die Kommunikation über das Internet stattfindet, wäre es nicht vorteilhaft, sich in zahlreichen Befehlen und Antworten über ein solches offenes Netzwerk zu verwickeln. Im Interesse von Schnelligkeit und Zuverlässigkeit ist es vorteilhaft, wenn weniger Meldungen ausgetauscht werden.
Um in dieser Umgebung sicher und zuverlässig zu arbeiten, emuliert das Client-Modul 224 in einer Ausführungsform der vorliegenden Erfindung eine Sicherheitskarte und sammelt alle Antworten für die Übermittlung in einer Abbuchungsanforderungsmeldung. Die Abbuchungsanforderungsmeldung kann eine Vielzahl von Informationen umfassen, einschließlich eines Abbuchungsanforderungs-Tokens, Zustandsinformationen, der Händlerkennung, der Transaktionskennung, Sicherheitsinformationen, einer Kennung des Geldbörsenlieferanten, einer IEP-Kennung, eines Algorithmus', den die Karte verwendet, eines Ablaufdatums, des Kontostands der Karte, eines Währungscodes, eines Währungsexponenten, des Authentifizierungsmodus' des IEP, der Transaktionsnummer des IEP, einer Schlüsselversion und des Kaufbetrags. Da alle diese Informationen im Voraus in eine einzige Abbuchungsanforderungsmeldung verpackt werden, wird die Anzahl der Meldungen zwischen der Guthabenkarte und der Sicherheitskarte über das Internet beträchtlich reduziert.
In dieser Ausführungsform wird die Abbuchungsanforderungsmeldung erstellt, indem die Antwort der Guthabenkarte in die Befehle „Zurücksetzen"- und „Initialisieren" und ein beliebiges Zertifikat mit öffentlichem Schlüssel zusammen mit den Gesamtkosten und der Währung der Transaktion verpackt wird, die von der HTML-Seite erhalten werden. Bei Karten mit öffentlichem Schlüssel werden das Karten- und das Aussteller- Zertifikat durch Lesebefehle bereitgestellt und können ebenfalls in der Abbuchungsabforderung enthalten sein. Durch das Verpacken all dieser Informationen in eine Abbuchungsanforderungsmeldung ist es möglich, die Anzahl der zwischen dem Kundenserver und dem Zahlungsserver ausgetauschten Meldungen zu verringern und Zuverlässigkeit und Schnelligkeit zu verbessern. In einer Ausführungsform der Erfindung wird ein IEP-Protokoll verwendet, um die Karte zurückzusetzen und zu initialisieren und eine Antwort zu erhalten.
Anschließend greift in Schritt 610 das Kundenterminal unter Verwendung der IP-Adresse, die es von dem Händlerserver erhalten hat, auf den Zahlungsserver zu. In Schritt 612 sendet das Kundenterminal die Abbuchungsanforderungsmeldung an den Zahlungsserver, wie in 310 dargestellt. Das Kundenterminal erstellt auch ein Protokoll darüber, dass diese Meldung geschickt wird.
In Schritt 614 verarbeitet der Zahlungsserver die Abbuchungsanforderung in Verbindung mit einer zugehörigen Sicherheitskarte, wie es ausführlicher mit Bezug auf 11D erklärt wird. Es wird angezeigt, dass die Abbuchungsanforderung 312 an das Terminal 214 geschickt wird. In einer Ausführungsform der Erfindung erstellt der Zahlungsserver einen Transaktions-Thread für jedes angeschlossene Client-Modul, um es über die Lebensdauer der Transaktion zu bedienen. Nach Schritt 614 hat der Zahlungsserver einen Abbuchungsbefehl und eine Sicherheitskartensignatur 314 von der Sicherheitskarte im Terminal enthalten. Dieser Abbuchungsbefehl kann auch als „IEP-Abbuchungs"-Befehl bezeichnet werden. Die Sicherheitskartensignatur ist ein Wert, der die Sicherheitskarte 218 eindeutig identifiziert und validiert, um gegenüber der Guthabenkarte 5 zu beweisen, dass der eintreffende Abbuchungsbefehl ein gültiger Befehl von einer realen Sicherheitskarte ist. Diese Gültigkeitsüberprüfung stellt sicher, dass, wenn von der Guthabenkarte abgebucht wird, die finanziellen Gesamtsummen in der Sicherheitskarte aktualisiert werden. So wird dem Benutzer der Guthabenkarte garantiert, dass eine gültige Abbuchung von der Karte erfolgt ist. In einer bevorzugten Ausführungsform der Erfindung ist die Sicherheitskartensignatur ein verschlüsselter Wert, der sicherstellt, dass keine andere Einheit die Identität einer Sicherheitskarte fälschen kann.
In Schritt 616 sendet der Zahlungsserver den Abbuchungsbefehl zusammen mit der Sicherheitskartensignatur an das Kundenterminal, wie in 316 dargestellt, so dass die Guthabenkarte eine Abbuchung von ihrem Speicherwert vornimmt. Zu diesem Zeitpunkt verzeichnet der Zahlungsserver diesen Abbuchungsbefehl auch in seiner Datenbank.
In Schritt 618 ersetzt das Client-Modul, nachdem es den Abbuchungsbefehl von dem Zahlungsserver erhalten hat, den Betrag in dem Abbuchungsbefehl durch den ursprünglichen Betrag (von dem Händlerserver), um sicherzustellen, dass der Betrag während seiner Reise durch das Netzwerk nicht verfälscht worden ist. Zu diesem Zeitpunkt erstellt das Client-Modul auch ein Protokoll des Abbuchungsbefehls. Das Client-Modul 224 leitet dann 318 den Abbuchungsbefehl und die Sicherheitskartensignatur an die Guthabenkarte 5 weiter, die die Signatur überprüft, eine Abbuchung in Höhe des Kaufbetrags von ihrem Speicherwert vornimmt und sowohl eine Erfolgsmeldung (auch „Abbuchungsantwort"-Meldung genannt) als auch eine Guthabenkartensignatur erstellt. Die Guthabenkartensignatur ist ein eindeutiger Wert, der eine gültige Guthabenkarte identifiziert. In einer bevorzugten Ausführungsform der Erfindung liegt die Signatur in verschlüsselter Form vor, um Verfälschung zu verhindern. Wenn die Karte 5 nicht genug Wert aufweist, um den Kaufbetrag zu decken, zeigt die „Abbuchungsantwort"-Meldung dies an.
In Schritt 620 sendet die Karte 5 eine Erfolgsmeldung 320 zusammen mit der Kartensignatur zurück an das Client-Modul 224 im Kundenterminal 204. Diese Erfolgsmeldung kann auch als „Abbuchungsantwort"-Meldung bezeichnet werden. An diesem Punkt ist der Kaufbetrag von dem Kontostand auf der Guthabenkarte 5 abgezogen worden. Anschließend verpackt in Schritt 622 das Client-Modul 224 die Erfolgsmeldung zusammen mit der Kartensignatur und sendet sie zurück an den Zahlungsserver 206, wie in 322 dargestellt. Das Client-Modul 224 verzeichnet auch das Ergebnis dieser Abbuchung von der Guthabenkarte.
In Schritt 624 erhält der Zahlungsserver die eingehende Meldung 322 und erstellt ein Protokoll und aktualisiert den Transaktionsstatus in seiner Datenbank zur zukünftigen Fehlerfindung. Der Zahlungsserver leitet dann diese erhaltene Meldung an die Sicherheitskarte in dem Terminal, wie in 324 dargestellt. Anschließend verarbeitet in Schritt 626 die Sicherheitskarte die Antwort von dem Kundenterminal und überprüft die erhaltene Guthabenkartensignatur.
Da die Sicherheitskarte die Schlüssel und Algorithmen umfasst, die nötig sind, um Guthabenkartensignaturen zu berechnen, kann die Sicherheitskarte auch bestätigen, dass eine erhaltene Guthabenkartensignatur tatsächlich gültig ist, in dem sie diese Guthabenkartensignatur mit einem erstellten erwarteten Wert vergleicht. Ein erfolgreicher Vergleich zeigt an, dass es sich bei einer Erfolgsmeldung 324, die von der Guthabenkarte erhalten wurde, tatsächlich um eine gültige Erfolgsmeldung handelt und dass eine Abbuchung von der Guthabenkarte vorgenommen worden ist. Ein Fehlerergebniscode oder ein Vergleich, der nicht erfolgreich ausfällt, zeigt möglicherweise an, dass von der Guthabenkarte nicht der richtige Betrag abgebucht worden ist. Dieser Vergleich von Guthabenkartensignaturen durch die Sicherheitskarte stellt sicher, dass von einer Guthabenkarte tatsächlich abgebucht wird, bevor der Händlerserver angewiesen wird, die gekaufte Ware auszugeben. Dieser Vergleich der Guthabenkartensignatur mit einem erwarteten Wert wird von der Sicherheitskarte für das höchste Sicherheitsniveau durchgeführt. Wie in 6, 7 und 8 beschrieben, kann dieser Vergleich von Guthabenkartensignaturen mit einer Vielzahl von weiteren Vorteilen auch im Zahlungsserver stattfinden, im Kundenterminal oder im Händlerserver. Vorausgesetzt, dass die Transaktion bis zu diesem Punkt gültig ist, sendet die Sicherheitskarte in Schritt 628 eine „Bestätigungs"-Meldung zurück an den Zahlungsserver, wie in 326 dargestellt. Diese Bestätigungsmeldung kann auch als „Meldungsergebnis" bezeichnet werden.
In Schritt 630 aktualisiert das Terminal seinen Datenspeicher mit der Guthabenkartennummer, einer Transaktionsgesamtzahl, dem Gesamtverkaufsbetrag, der Antwort von der Sicherheitskarte und Transaktionsnummern von der Guthabenkarte und der Sicherheitskarte. Der Zahlungsserver verzeichnet auch die Antwort, die er von dem Terminal erhalten hat, die die Händlerkennung usw. umfasst, wie in Schritt 632 dargestellt. Anschließend erstellt der Zahlungsserver in Schritt 634 eine Bestätigungsmeldung, die die Transaktionskennung umfasst, und sendet diese Meldung in verschlüsselter Form an das Kundenterminal, wie in 328 dargestellt. Diese Meldung 328 kann auch als „Ergebnismeldung" bezeichnet werden.
Indem die Bestätigungsmeldung in verschlüsselter Form gesendet wird, kann die Bestätigungsmeldung über das Kundenterminal an den Händlerserver weitergeleitet werden, ohne dass Verfälschung befürchtet werden muss. Da die Bestätigungsmeldung verschlüsselt ist, wäre es äußerst schwierig für das Kundenterminal oder eine andere Einheit, eine Bestätigungsmeldung zu fälschen und den Händlerserver dahingehend zu täuschen, dass er annimmt, es habe eine Transaktion stattgefunden. In noch einer weiteren Ausführungsform der Erfindung muss die Bestätigungsmeldung nicht verschlüsselt werden, wenn das Kundenterminal ein vertrauenswürdiger Agent ist. In einer weiteren Ausführungsform kann der Zahlungsserver zwei Bestätigungsmeldungen senden, eine nicht verschlüsselte, die der Client verarbeitet, und eine verschlüsselte für den Händlerserver. 15A und 15B stellen eine Ausführungsform dar, bei der der Zahlungsserver zwei Meldungen an das Kundenterminal sendet.
An diesem Punkt kann der Transaktions-Thread des Zahlungsservers, der für die aktuelle Transaktion verwendet wurde, das Terminal freigeben und so ermöglichen, dass das Terminal durch andere Transaktionen benutzt wird. Dieser Transaktions-Thread endet dann zu diesem Zeitpunkt.
In Schritt 636 leitet das Kundenterminal dann diese Bestätigungsmeldung 330 an den Händlerserver an die zuvor vom Händlerserver erhaltene URL-Adresse weiter. Die Meldung 330 kann auch als „Meldungsergebnis" bezeichnet werden. Der Client kann auch eine Meldung an den Benutzer schicken, die ihn darüber informiert, dass die Abbuchung abgeschlossen ist. Der Client verzeichnet auch die Bestätigung der Zahlung. In Schritt 638 registriert der Händlerserver diese Bestätigungsmeldung und überprüft auf Erfolg. Der Händlerserver ruft mit der Bestätigungsmeldung eine Validierungs- Routine innerhalb des Händlercodemoduls auf, um die Antwort von dem Client zu bestätigen. Die Validierungs-Routine kann die Transaktionskennung mit der verschlüsselten Bestätigungsmeldung mitführen, um die Bestätigungsmeldung zu entschlüsseln. Wenn die entschlüsselte Bestätigungsmeldung akzeptabel ist, bestimmt der Händlerserver dann, dass eine erfolgreiche Transaktion erfolgt ist. Anschließend erstellt der Händlerserver in Schritt 640 eine HTML-Seite mit den erhaltenen Informationen und liefert diese Informationen an das Kundenterminal. Wahlweise kann der Händlerserver eine Kaufquittung erstellen, die er an das Kundenterminal liefert, auf der Waren und/oder Dienstleistungen angegeben sind, die geliefert bzw. erbracht werden sollen. An diesem Punkt kann das Kundenterminal auch die Antwort des Händlerservers verzeichnen. Der Abschluss dieser Schritte zeigt eine erfolgreiche Finanztransaktion über das Internet unter Verwendung einer Guthabenkarte an.
11D kommt auf eine ausführlichere Erläuterung von Schritt 614 zurück und beschreibt ein Verfahren zum Bearbeiten einer Abbuchungsanforderungsmeldung in Verbindung mit einer Sicherheitskarte. Sobald diese Abbuchungsanforderungsmeldung von dem Zahlungsserver erhalten und an das Terminal weitergeleitet worden ist, teilt das Terminal die Meldung wieder in einzelne Antworten auf und leitet diese Antworten nacheinander an die Sicherheitskarte weiter, wie nachfolgend erklärt wird. In einer möglichen Ausführungsform wird ein nichtprogrammierbares Terminal verwendet und die Abbuchungsanforderung wird in ihre Bestandteile aufgeteilt und auf andere Weise durch den Zahlungsserver verarbeitet, der dann selbst die Antworten an die Sicherheitskarte schickt.
In Schritt 680 überprüft das Zahlungscodemodul des Zahlungsservers die Abbuchungsanforderung auf syntaktische Korrektheit und verzeichnet die Abbuchungsanforderungsmeldung als erhalten. In Schritt 682 wird die Abbuchungsanforderung an das Terminalschnittstellenmodul des Zahlungsservers weitergegeben. In einer besonderen Ausführungsform fordert die Terminalschnittstelle dann ein Terminal aus dem Terminalpool des Zahlungsservers an. Der Zahlungsserver besitzt einen Pool von Terminals, die mit dem Terminalkonzentrator verbunden sind, der beim Start eingerichtet wird. Beim Start erhält der Zahlungsserver eine Liste aller gültigen Terminalkennungen. Der Zahlungsserver benutzt diese Kennungen und seine Kenntnis der laufenden Transaktionen, um ein geeignetes Terminal zu bestimmen, das die Transaktion verarbeitet. Sobald ein Terminal bestimmt ist, erstellt die Terminalschnittstelle eine terminalspezifische Meldung, die auf der Abbuchungsanforderung und dem Terminaltyp basiert.
In Schritt 686 wird die terminalspezifische Abbuchungsanforderung 312 über den Konzentrator über ein lokales Netzwerk an das gewählte Terminal geschickt. Der Konzentrator dient als Router zwischen einem Transaktions-Thread in dem Zahlungsserver und seinem entsprechenden Terminal. Der Konzentrator betrachtet eine Kopfzeile auf der Abbuchungsanforderung, um zu bestimmen, an welches Terminal die Transaktion geleitet werden sollte. In einer Ausführungsform wird der Konzentrator 212 entfernt und der Zahlungsserver 206 kommuniziert direkt mit dem Terminal 214 (zum Beispiel).
In Schritt 688 analysiert das Terminal die Abbuchungsanforderungsmeldung in ihre verschiedenen Bestandteile und verarbeitet jeden Bestandteil nacheinander, um eine Guthabenkarte zu emulieren, die mit der Sicherheitskarte in einem physischen Terminal in Wechselbeziehung steht. Das Verpacken im Voraus einer Vielzahl von Informationen in die Abbuchungsanforderungsmeldung führt zu weniger Austausch zwischen dem Kundenterminal und dem Zahlungsserver über das Internet. Indem die Sicherheitskarte nun eine Wechselbeziehung simuliert, verhält sie sich, als ob sie sich zusammen mit der Guthabenkarte in einem physischen Terminal befände. Eine Vielzahl von Antworten von einer Guthabenkarte kann emuliert werden. In dieser Ausführungsform sendet das Terminal jede der drei Pakete „Antwort auf Neustart", „IEP initialisieren" und „Abbuchung" einzeln an die Sicherheitskarte und wartet auf eine Rückmeldung, bevor es die nächste Antwort schickt. Für eine Transaktion mit öffentlichem Schlüssel werden auch die Zertifikate, die von dem Client gelesen werden, als einzelne Antworten mit eingeschlossen. Auf diese Weise kann die herkömmliche Wechselbeziehung zwischen der Guthabenkarte und der Sicherheitskarte in einem physischen Terminal an einem Terminal an einem entfernten Standort simuliert werden, obwohl alle Guthabenkarteninformationen (die Abbuchungsanforderung), die von dem Kundenterminal stammen, auf einmal in im Voraus verpackter Form über das Internet geschickt worden sind.
In Schritt 690 erreicht das Terminal einen „Abbuchungsbetrag"-Zustand und zeigt an, dass die Sicherheitskarte einen Abbuchungsbefehl erstellen kann. In Schritt 692 erstellt die Sicherheitskarte ihre Sicherheitskartensignatur und den Abbuchungsbefehl. Der Abbuchungsbefehl kann auch als „IEP-Abbuchungs"-Befehl bezeichnet werden. Die Signatur und der Abbuchungsbefehl 314 werden an das Terminal geschickt. Der Abbuchungsbefehl, der von der Sicherheitskarte ausgegeben wird, kann eine Vielzahl von Informationen umfassen, einschließlich der Sicherheitskartenkennung, der Transaktionskennung, des abzubuchenden Betrags, der Währung und des Währungsexponenten für den Betrag, die Sicherheitskartensignatur, das Datum, die Zeit und den Standort. Das Terminal schickt wiederum die Signatur, den Befehl und die Terminalkennung an den Zahlungsserver, wie in Schritt 694 dargestellt. Die Informationen können über einen Konzentrator an den Zahlungsserver gesendet werden, wie in 314 dargestellt. An diesem Punkt endet Schritt 614 und die Steuerung geht wieder zu Schritt 616 zurück.
ERSTE MÖGLICHE ZAHLUNGSAUSFÜHRUNGSFORM
6 stellt eine mögliche Ausführungsform 200a dar, in der die Sicherheitskarte früher freigegeben werden kann als die Sicherheitskarte von 5; diese Ausführungsform erfordert auch weniger Austausch zwischen dem Terminal und dem Zahlungsserver. Eine Sicherheitskarte in einem Terminal ist einer bestimmten Transaktion von dem Moment an zugeordnet, wenn die Terminalschnittstelle dieses Terminal auswählt, bis die Sicherheitskarte schließlich eine „Bestätigungs"-Meldung ausgibt und von einer Terminalschnittstelle freigegeben wird. Somit ist es unter gewissen Umständen wünschenswert, die Sicherheitskarte früher freizugeben. Durch das frühere Freigeben einer Sicherheitskarte ist die Karte je Transaktion eine kürzere Zeit beschäftigt und kann eher zu der nächsten Transaktion übergehen. Außerdem ist die Gefahr eines Kommunikationsfehlers, der die Transaktion unterbrechen und anhalten könnte, desto geringer, je kürzer die Zeit ist, die ein Terminal einer bestimmten Transaktion zugeordnet ist und je weniger Meldungen zwischen den beiden ausgetauscht werden.
Die Ausführungsform 200a umfasst ein Kundenterminal 204, einen Zahlungsserver 206, einen Händlerserver 208, eine Guthabenkarte 5 und ein Terminal 214, das eine Sicherheitskarte 218 besitzt. Die Kommunikation zwischen den verschiedenen Einheiten kann in ähnlicher Weise stattfinden wie in 5, wie von den Kommunikationsverbindungen 234, 235 und 236 angezeigt. Anstelle der zwei Hin- und Rückreisen der Informationen zwischen dem Terminal und dem Zahlungsserver gibt es jedoch nur eine Hin- und Rückreise in dieser Ausführungsform.
12 ist ein Flussdiagramm, das ein Verfahren zum Umsetzen dieser Ausführungsform mit Bezug auf 6 beschreibt: Schritt 702 zeigt an, dass die Kommunikation zwischen den verschiedenen Einheiten in ähnlicher Weise stattfindet wie in 5, hoch bis zu dem Punkt, an dem das Terminal den „Abbuchungsbetrag"-Zustand erreicht. An diesem Punkt ist die Abbuchungsanforderung 312 von der Sicherheitskarte erhalten und verarbeitet worden. Anschließend erstellt die Sicherheitskarte in Schritt 704 nicht nur die Sicherheitskartensignatur und den Abbuchungsbefehl, sondern auch eine erwartete Guthabenkartensignatur. Diese erwartete Guthabenkartensignatur ist ein Wert, der von der Sicherheitskarte von der Guthabenkarte erwartet wird, um die Erfolgsmeldung der Guthabenkarte zu validieren. Die Validierung stellt sicher, dass die Guthabenkarte tatsächlich eine Abbuchung von ihrem Speicherwert vorgenommen hat.
In Schritt 706 werden die Sicherheitskartensignatur, der Abbuchungsbefehl und die erwartete Guthabenkartensignatur an das Zahlungscodemodul in dem Zahlungsserver geschickt, wie bei 314a angezeigt. Außerdem aktualisiert das Terminal seinen Datenspeicher in ähnlicher Weise wie in Schritt 630. Anschließend zeigt Schritt 708 mit Bezug auf Schritte 616–622 an, dass die Transaktion wie zuvor erfolgt. Die Schritte zeigen an, dass die Guthabenkarte den Abbuchungsbefehl erhält, eine Abbuchung von ihrem Speicherwert vornimmt und die Erfolgsmeldung (auch „Abbuchungsantwort"-Meldung genannt) und ihre Kartensignatur an den Zahlungsserver zurückschickt.
Anschließend verarbeitet das Zahlungsservercodemodul in Schritt 710 diese Antwort von der Guthabenkarte, indem es 346 die erhaltene Kartensignatur mit der erwarteten Guthabenkartensignatur vergleicht, die zuvor von der Sicherheitskarte erhalten wurde. Der Vergleich der zwei Signaturen durch das Zahlungsmodul des Zahlungsservers vermeidet eine weitere Hin- und Rückreise zwischen dem Zahlungsserver und der Sicherheitskarte. Da die Sicherheitskarte die erwartete Kartensignatur schon an den Zahlungsserver zugestellt hat, kann die Sicherheitskarte freigegeben werden, sobald die Meldung 314a erhalten wird.
Vorausgesetzt, dass der Vergleich erfolgreich ist, kann das Zahlungsmodul dann seine eigene Bestätigungsmeldung erstellen, anstatt auf eine „Bestätigungs"-Meldung von der Sicherheitskarte zu warten. Anschließend zeigt Schritt 712 an, dass die Verarbeitung in ähnlicher Weise fortschreitet wie in Schritt 632–640. Die Bestätigungsmeldung wird durch das Kundenterminal an den Händlerserver weitergegeben und der Händlerserver kann dann die gekaufte Ware an den Benutzer liefern.
ZWEITE MÖGLICHE ZAHLUNGSAUSFÜHRUNGSFORM
In einer weiteren Ausführungsform 200b der vorliegenden Erfindung wie in 7 dargestellt, ist es nicht nur der Sicherheitskarte erlaubt, früher freizugeben, sondern es wird auch die Anzahl der Meldungen verringert, die zwischen dem Kundenterminal und dem Zahlungsserver ausgetauscht wird. Anstelle eines Vergleichs von Guthabenkartensignaturen im Zahlungsserver wird die erwartete Guthabenkartensignatur von der Sicherheitskarte an das Kundenterminal übertragen, wo ein vertrauenswürdiger Agent 356 den Vergleich der erwarteten Guthabenkartensignatur mit der tatsächlichen Signatur ausführt, die von der Guthabenkarte 5 erhalten wird. Somit wird der Meldungsaustausch zwischen dem Kundenterminal und dem Zahlungsserver auf eine Hin- und Rückreise verringert. Dies ist vorteilhaft insofern, als die Zeit für eine Transaktion verringert wird, die Sicherheitskarte früher freigegeben wird und weniger Meldungsaustausch mehr Zuverlässigkeit über das Internet bedeutet.
Die Ausführungsform 200b umfasst ein Kundenterminal 204, einen Zahlungsserver 206, einen Händlerserver 208, eine Guthabenkarte 5 und ein Terminal 214, das eine Sicherheitskarte 218 besitzt. Die Kommunikation zwischen den verschiedenen Einheiten kann in ähnlicher Weise stattfinden wie in 5, wie durch die Kommunikationsverbindungen 234 und 235 dargestellt.
13 ist ein Flussdiagramm, das ein Verfahren zum Umsetzen dieser Ausführungsform mit Bezug auf 7 beschreibt. Schritt 722 zeigt an, dass die Kommunikation zwischen den verschiedenen Einheiten in ähnlicher Weise stattfindet wie in 5, bis das Terminal den „Abbuchungsbetrag"-Zustand erreicht. An diesem Punkt ist die Abbuchungsanforderung 312 von der Sicherheitskarte erhalten und verarbeitet worden. Als nächstes erstellt die Sicherheitskarte in Schritt 724 nicht nur die Sicherheitskartensignatur und den Abbuchungsbefehl, sondern auch eine erwartete Guthabenkartensignatur.
In Schritt 726 werden die Sicherheitskartensignatur, der Abbuchungsbefehl und diese erwartete Guthabenkartensignatur an das Zahlungscodemodul in dem Zahlungsserver geschickt, wie in 314a dargestellt. Außerdem aktualisiert das Terminal seinen Datenspeicher in ähnlicher Weise wie in Schritt 630. Anschließend schickt das Zahlungsservercodemodul in Schritt 728 den Abbuchungsbefehl, die Händlersignatur und die erwartete Guthabenkartensignatur an das Kundenterminal.
Anschließend zeigt Schritt 730 an, dass die Transaktion wie zuvor mit Bezug auf Schritt 618 und 620 erfolgt. Die Schritte zeigen an, dass die Guthabenkarte den Abbuchungsbefehl erhält und eine Abbuchung von ihrem Speicherwert vornimmt. In Schritt 732 vergleicht das Client-Modul selbst die tatsächliche Kartensignatur von der Guthabenkarte mit der erwarteten Signatur von der Sicherheitskarte. Dieser Vergleich der zwei Signaturen durch das Client-Modul des Kundenterminals vermeidet eine weitere Hin- und Rückreise zwischen dem Zahlungsserver und dem Kundenterminal.
Außerdem kann die Sicherheitskarte freigegeben werden, sobald die Meldung 314a erhalten wird, da die Sicherheitskarte die erwartete Kartensignatur bereits an den Zahlungsserver zugestellt hat.
Vorausgesetzt, der Vergleich ist erfolgreich, kann das Kundenterminal dann seine eigene Bestätigungsmeldung in Schritt 734 erstellen, anstatt auf eine Bestätigungsmeldung von dem Zahlungsserver zu warten. Anschließend zeigt Schritt 736 an, dass die Verarbeitung in ähnlicher Weise wie in Schritt 636–640 weitergeht. Die Bestätigungsmeldung wird an den Händlerserver weitergegeben und der Händlerserver kann dann die gekaufte Ware an den Benutzer liefern.
DRITTE MÖGLICHE ZAHLUNGSAUSFÜHRUNGSFORM
8 stellt eine weitere Ausführungsform 200c der Erfindung dar, in der der Händlerserver den Vergleich der Guthabenkartensignatur mit der erwarteten Signatur ausführt. Diese Ausführungsform weist sämtliche Vorteile der vorherigen Ausführungsform auf, in der die Sicherheitskarte früher freigegeben wird, und es werden auch weniger Meldungen zwischen den Einheiten hin- und hergegeben. In dieser Ausführungsform wird eine verschlüsselte Signatur an den Händlerserver über das Kundenterminal weitergegeben, wenn man sich nicht darauf verlassen kann, dass das Kundenterminal die Guthabenkartensignaturen vergleicht. Das Kundenterminal gibt auch die ursprüngliche, unverschlüsselte Signatur von der Guthabenkarte an den Händlerserver weiter. Eine Routine 366 in dem Händlerserver vergleicht dann die beiden Signaturen.
Die Ausführungsform 200c umfasst ein Kundenterminal 204, einen Zahlungsserver 206, eine Guthabenkarte 5 und ein Terminal 214, das eine Sicherheitskarte 218 aufweist. Die Kommunikation zwischen den verschiedenen Einheiten kann in ähnlicher Weise stattfinden wie in 5, wie durch die Meldungen 302–306 und die Kommunikationsverbindung 235 dargestellt.
14 ist ein Flussdiagramm, das ein Verfahren zum Umsetzen dieser Ausführungsform mit Bezug auf 8 beschreibt. Schritt 742 zeigt an, dass die Kommunikation zwischen den verschiedenen Einheiten in ähnlicher Weise stattfindet wie in 5, bis das Terminal den „Abbuchungsbetrag"-Zustand erreicht. An diesem Punkt ist die Abbuchungsanforderung 312 von der Sicherheitskarte erhalten und verarbeitet worden. Anschließend erstellt die Sicherheitskarte in Schritt 744 nicht nur die Sicherheitskartensignatur und den Abbuchungsbefehl, sondern auch eine erwartete Guthabenkartensignatur.
In Schritt 746 werden die Sicherheitskartensignatur, der Abbuchungsbefehl und diese erwartete Guthabenkartensignatur an das Zahlungscodemodul im Zahlungsserver geschickt, wie in 314a dargestellt. Außerdem aktualisiert das Terminal seinen Datenspeicher in ähnlicher Weise wie in Schritt 630. Anschließend sendet das Zahlungsservercodemodul in Schritt 748 den Abbuchungsbefehl, die Händlersignatur und eine verschlüsselte erwartete Guthabenkartensignatur an das Kundenterminal. Die erwartete Guthabenkartensignatur ist verschlüsselt, um Verfälschung durch das Kundenterminal oder eine andere außenstehende Einheit zu verhindern.
Anschließend zeigt Schritt 750 an, dass die Transaktion wie zuvor mit Bezug auf Schritt 618 und 620 erfolgt. Die Schritte zeigen an, dass die Guthabenkarte den Abbuchungsbefehl erhält und eine Abbuchung von ihrem Speicherwert vornimmt. In Schritt 752 sendet das Client-Codemodul die Erfolgsmeldung, die ursprüngliche Guthabenkartensignatur und die verschlüsselte Signatur weiter an den Händlerserver. In Schritt 754 verarbeitet der Händlerserver die Erfolgsmeldung, entschlüsselt die verschlüsselte Signatur und vergleicht die zwei Signaturen. Dieser Vergleich der zwei Signaturen durch den Händlerserver vermeidet eine weitere Hin- und Rückreise zwischen dem Zahlungsserver und dem Kundenterminal. Außerdem kann die Sicherheitskarte freigegeben werden, sobald die Meldung 314a erhalten ist, da die Sicherheitskarte die erwartete Kartensignatur bereits an den Zahlungsserver zugestellt hat.
Vorausgesetzt, der Vergleich ist erfolgreich, kann der Händlerserver nun in Schritt 756 seine eigene Bestätigungsmeldung erstellen, anstatt auf eine Bestätigungsmeldung von dem Kundenterminal zu warten. Anschließend zeigt Schritt 758 an, dass die Verarbeitung in ähnlicher Weise fortschreitet wie in Schritt 638 und 640. Der Händlerserver kann dann die gekaufte Ware an den Benutzer liefern. In all den zuvor dargestellten Ausführungsformen macht der Zahlungsserver die Transaktion innerhalb des Terminals rückgängig, wenn die Transaktion nicht erfolgreich abgeschlossen wird.
AUSFÜHRUNGSFORM MIT VERSCHLÜSSELUNGSSCHICHT
9 stellt eine Ausführungsform 200d der vorliegenden Erfindung dar, in der eine Verschlüsselungsschicht hinzugefügt worden ist. Obwohl die vorliegende Erfindung ohne diese hinzugefügte Verschlüsselungsschicht verwendet werden kann, wird diese Verschlüsselungsschicht in einer bevorzugten Ausführungsform der Erfindung angewendet. 9 umfasst das Kundenterminal 204, den Zahlungsserver 206 und den Händlerserver 208. Weitere Elemente der Architektur sind in dieser Figur der Einfachheit halber weggelassen worden. Diese zusätzliche Verschlüsselungsschicht wird nicht nur angewendet, um den Inhalt von Meldungen, die über das Internet übertragen werden, zu schützen, sondern auch, um ein Kundenterminal, eine Guthabenkarte oder eine andere Einheit daran zu hindern, eine Meldung zu empfangen oder zu erstellen, die eine andere Einheit dahingehend täuschen würde, dass diese annimmt, eine gültige Transaktion habe stattgefunden. Diese Verschlüsselung verhindert auch, dass Meldungen zufällig oder absichtlich verändert oder fehlgeleitet werden.
Es sollte geschätzt werden, dass die Verschlüsselung aus Sicherheitsgründen in jeder beliebigen Ausführungsform in allen Teilen jeder beliebigen Meldung vorhanden sein kann. Vorzugsweise ist jede beliebige Signatur, die über ein Netzwerk verschickt wird, verschlüsselt.
15A und 15B sind ein Flussdiagramm, das diese Ausführungsform der Erfindung mit Bezug auf 9 beschreibt. In Schritt 802 teilen der Zahlungsserver und der Händlerserver einen eindeutigen Verschlüsselungsschlüssel. Aufgrund einer zuvor getroffenen Geschäftsvereinbarung sind beide Server übereingekommen, diesen eindeutigen Schlüssel zu teilen, um der Transaktion Sicherheit zu verleihen. Der gemeinsame Schlüssel kann jeden beliebigen geeigneten Verschlüsselungsstandard verwenden und eine beliebige Länge aufweisen. Der Schlüssel kann ein Data Encryption Standard (DES)-Schlüssel sein und eine Länge von 128 Bits einschließlich Parität aufweisen. Obwohl dieser gemeinsame Schlüssel unmittelbar verwendet werden könnte, gibt es in einer bevorzugten Ausführungsform der Erfindung einen abgeleiteten eindeutigen Schlüssel für jede Transaktion zwischen dem Händlerserver und dem Zahlungsserver. Wahlweise kann auch ein anderer Verschlüsselungsstandard wie RSA verwendet werden. Vorzugsweise wird das Laden von Wert unter DES durchgeführt, während ein Kauf entweder unter DES oder Public-Key-Technologie durchgeführt wird.
In Schritt 804 arbeiten das Kundenterminal und der Händlerserver in einer geschützten Secure Sockets Layer (SSL)-Sitzung 404, in der eine Verbindung hergestellt wird, ein Benutzer sich umschaut und eine Kaufauswahl trifft. Die SSL-Sitzung schützt die Informationen, die über das Internet übertragen werden, wie Karteninformationen, Befehle und Verschlüsselungsschlüssel, davor, durch eine nicht authorisierte Partei entdeckt zu werden. Andere Verfahren zum Schutz einer Sitzung können ebenfalls angewendet werden.
In Schritt 806 leitet der Händlerserver einen Schlüssel von dem DES-Schlüssel ab, wobei er Informationen verwendet, die eindeutig für diese Transaktion sind, wie die Händlerkennung, die Transaktionskennung oder andere Informationen, die für diese Transaktionen eindeutig sind, wie eine Zufallszahl. Da der Zahlungsserver den DES-Schlüssel mit dem Händlerserver teilt und auch Zugang zu diesen eindeutigen Informationen über die Transaktion hat, kann der Zahlungsserver auch diesen gleichen Schlüssel von dem gemeinsamen DES-Schlüssel ableiten. In diesem Schritt erstellt der Händlerserver auch einen Transaktionssitzungsschlüssel (Transaction Session Key – TSK) zur Verwendung durch das Kundenterminal und den Zahlungsserver bei der Verschlüsselung von Informationen.
In Schritt 808 lädt der Händlerserver eine HTML-Seite mit den Informationen 406 herunter, die den TSK und den TSK, der unter Verwendung des abgeleiteten Schlüssels (Encrypted Transaction Session Key – ETSK) verschlüsselt wird, umfasst. Der TSK, der mit dem abgeleiteten Schlüssel verschlüsselt ist, wird von dem Zahlungsserver verwendet, um eine verschlüsselte (und für den Kunden unlesbare) Bestätigungsmeldung an den Händlerserver zurückzuschicken. Nur der Händlerserver kann diese Bestätigungsmeldung entschlüsseln und erhält somit die Garantie, dass eine erfolgreiche Transaktion stattgefunden hat und Ware an den Kunden ausgegeben werden kann.
In Schritt 810 bereitet der Client die Abbuchungsanforderung in Verbindung mit der Guthabenkarte vor und schickt die Abbuchungsanforderung 408, die mit dem TSK verschlüsselt ist, zusammen mit dem ETSK an den Zahlungsserver. In Schritt 812 verwendet der Zahlungsserver den gemeinsamen DES-Schlüssel und die zuvor vereinbarten Informationen, die für die Transaktion eindeutig sind, um den gleichen Schlüssel abzuleiten, die der Händlerserver benutzt hat. Somit kann der abgeleitete Schlüssel verwendet werden, um den ETSK zu entschlüsseln, um den TSK zu erstellen. Sobald der Zahlungsserver den TSK erstellt hatte, kann er die Abbuchungsanforderung entschlüsseln und die Abbuchungsanforderung in jeder geeigneten Weise mit der Sicherheitskarte verarbeiten. Sobald der Zahlungsserver den Abbuchungsbefehl von der Sicherheitskarte erhalten hat, verschlüsselt er den Abbuchungsbefehl mit dem TSK. Der Abbuchungsbefehl kann auch als „IEP-Abbuchungsbefehl" bezeichnet werden.
In Schritt 814 sendet der Zahlungsserver den verschlüsselten Abbuchungsbefehl 410 an das Kundenterminal. In Schritt 816 entschlüsselt der Client den Abbuchungsbefehl mit dem TSK, den er zuvor von dem Händlerserver erhalten hatte, und verarbeitet den Abbuchungsbefehl in einer geeigneten Weise mit einer Guthabenkarte. Sobald das Kundenterminal die Abbuchungsantwortmeldung von der Guthabenkarte erhalten hat, verschlüsselt es diese Meldung mit dem TSK und sendet die Abbuchungsantwortmeldung 412 an den Zahlungsserver. In Schritt 820 entschlüsselt der Zahlungsserver die Abbuchungsantwortmeldung mit dem TSK und verarbeitet die Abbuchungsantwortmeldung in einer geeigneten Weise mit der Sicherheitskarte.
Sobald der Zahlungsserver eine „Abbuchungsergebnis"-Meldung von der Sicherheitskarte erhalten hat, verschlüsselt der Zahlungsserver die „Abbuchungsergebnis"-Meldung mit dem TSK, um eine „Abbuchungsergebnis-C"-Meldung für den Client zu erstellen. Die „Abbuchungsergebnis-C"-Meldung wird von dem Kundenterminal verwendet, um den Benutzer über eine erfolgreiche Transaktion zu informieren. Der Zahlungsserver erstellt auch seine eigene Bestätigungsmeldung und verschlüsselt die Bestätigungsmeldung mit dem abgeleiteten Schlüssel, um eine „Abbuchungsergebnis-H"-Meldung zu bilden. Der Händlerserver schickt dann 414 die „Abbuchungsergebnis-C"-Meldung und die „Abbuchungsergebnis-H"-Meldung an das Kundenterminal.
In Schritt 822 entschlüsselt und verarbeitet das Kundenterminal die „Abbuchungsergebnis-C"-Meldung und gibt die „Abbuchungsergebnis-H"-Meldung 416 an den Händlerserver weiter. Da die „Abbuchungsergebnis-H"-Meldung mit dem abgeleiteten Schlüssel verschlüsselt ist, kann das Kundenterminal oder eine andere Einheit sie nicht verfälschen. In Schritt 824 kann der Händlerserver die „Abbuchungsergebnis-H"-Meldung entschlüsseln, weil er den abgeleiteten Schlüssel ursprünglich von dem DES-Schlüssel erstellt hatte. Sobald der Händlerserver bestimmt hat, dass eine gültige „Abbuchungsergebnis-H"-Meldung erhalten worden ist, bestätigt er, dass eine gültige Transaktion stattgefunden hat und kann Ware an den Benutzer freigeben.
Diese Sicherheitsausführungsform von 9 kann mit jeder beliebigen der zuvor beschriebenen Ausführungsformen der Erfindung verwendet werden. Zum Beispiel kann diese Sicherheitsausführungsform mit den Ausführungsformen von 7 und 8 verwendet werden, in denen es nur eine Hin- und Rückreise zwischen dem Kundenterminal und dem Zahlungsserver gibt. Insbesondere kann die erwartete Guthabenkartensignatur, die von der Sicherheitskarte erhalten wird, mit dem abgeleiteten Schlüssel verschlüsselt werden, so dass sie für den Kunden unlesbar ist, doch der Händlerserver kann die erhaltene Guthabenkartensignatur mit der erwarteten Kartensignatur vergleichen, um die Gültigkeit der Transaktion zu überprüfen.
Eine große Vielzahl von Fachausdrücken kann benutzt werden, um die zuvor beschriebenen Schlüssel zu beschreiben. Zum Beispiel können die Schlüssel, die zuvor als gemeinsamer DES-Schlüssel, Transaktionssitzungsschlüssel (TSK) und abgeleiteter Schlüssel bezeichnet wurden, auch als gemeinsamer Schlüssel, Sitzung-C-Schlüssel und Sitzung-H-Schlüssel bezeichnet werden.
AUTHENTIFIZIERUNGSAUSFÜHRUNGSFORM
16 stellt eine Architektur und ein System 200' für die Authentifizierung über ein Internet (wie das Internet) unter Verwendung einer Pseudo-Guthabenanwendung dar. Diese Anwendung könnte in einer Guthabenkarte zusammen mit Standardkonten-, Guthaben- oder anderen Kartenanwendungen bestehen. Die Karte bestimmt den Zugang zu der Pseudo-Guthabendienstleistung und stellt sicher, dass die Karte vorhanden ist und die Sicherheitsüberprüfungen durchläuft.
In einer Ausführungsform der vorliegenden Erfindung kann ein Verbraucher wünschen, auf eine beliebige Vielzahl von Webservern zuzugreifen, um Vielfliegermeilen, Belohnungspunkte usw. einzulösen, die er oder sie angehäuft hat. In dieser Ausführungsform hat ein Verbraucher „Punkte" durch eine beliebige Vielzahl von Programmen bei Fluggesellschaften, Restaurants, Autovermietungen, Hotels, Banken, Kredit- oder Debitkartenausstellern, Telefon- oder einer anderen Kommunikationsgesellschaft usw. angehäuft. Der Verbraucher wünscht diese Punkte einzulösen, um kostenlose Flugtickets, Mahlzeiten, Mietwagen, Übernachtungen, Prämien, Belohnungen, Rabatte oder andere „Vergünstigungen" zu erhalten. Indem der Verbraucher auf einen Webserver zugreift, der mit dem bestimmten Programm in Zusammenhang steht, kann der Verbraucher seine oder ihre Karte in jeder beliebigen der hier beschriebenen Ausführungsformen verwenden, um die Karte zu authentifizieren und diese Vergünstigungen von dem Programm zu erhalten. Meistens besitzt eine Karte eine Kartennummer, die mit dem Namen des Verbrauchers in einer Datenbank auf dem Webserver in Zusammenhang steht. Diese Kartennummer wird an den Webserver als Teil der Kartensignatur oder in ähnlicher Weise übertragen. Somit kann eine authentifizierte Karte, die in dieser Ausführungsform benutzt wird, um Dienstleistungen einzulösen, an den entsprechenden Verbraucher angepasst werden.
Zum Beispiel kann ein Verbraucher mit 30.000 Vielfliegermeilen bei einer Fluggesellschaft diese Ausführungsform der vorliegenden Erfindung verwenden, um auf einen Webserver zuzugreifen, der mit der Fluggesellschaft in Zusammenhang steht. Der Verbraucher fordert einen kostenlosen Hin- und Rückflug im Austausch gegen 20.000 Meilen an. Die vorliegende Erfindung arbeitet dann in der Weise, dass sie die Guthaben-Loyalitätsanwendung des Verbrauchers auf der Karte authentifiziert und eine Bestätigung der Authentifizierungsmeldung an den Webserver der Fluggesellschaft zustellt. Der Webserver zieht dann 20.000 Meilen von dem Konto des Verbrauchers ab (wobei er 10.000 Meilen übrig lässt) und stellt dem Verbraucher das kostenlose Ticket zu. In einer spezifischen Ausführungsform überwacht der Webserver, der der Fluggesellschaft zugehörig ist (oder die Fluggesellschaft selbst) das Konto des Verbrauchers und zieht den Meilenstand ab. In diesem Augenblick wird eine Authentifizierungsanwendung benutzt, um das Vorhandensein der Karte zu validieren oder Zugang zu der Webseite zu erreichen.
In einer weiteren spezifischen Ausführungsform umfasst die Karte des Verbrauchers eine Loyalitätsanwendung, die die angehäuften Vielfliegermeilen des Verbrauchers speichert; der Meilenstand von der Karte wird dann abgebucht und dem Webserver in einer ähnlicher Weise bestätigt, wie in verschiedenen der Ausführungsformen beschrieben, durch die ein Bargeldwert auf einer Karte gespeichert und von ihr abgebucht wird.
Das System 200' kann in ähnlicher Weise umgesetzt werden wie das System 200 von 4. Die Elemente, die in System 200' dargestellt werden, die Gegenstücke in System 200 besitzen, werden zuvor beschrieben und weisen eine ähnliche Funktionalität auf. Das System 200' umfasst einen Webserver 208', der jeder beliebige geeignete Computerserver sein kann, der fähig ist, einem Verbraucher über ein offenes Netzwerk wie das Internet Belohnungsinformationen (im Folgenden „Vergünstigungen") vorzulegen. Der Webserver 208' kann derselbe wie der Händlerserver 208 von 4 oder ein separater Computer sein. Vorzugsweise ist der Webserver 208' in ähnlicher Weise umgesetzt wie zuvor in Bezug auf den Händlerserver 208 beschrieben. Der Webserver 208' umfasst das Servermodul 232', das vorzugsweise in ähnlicher Weise umgesetzt ist wie das Händlermodul 232. Zusätzlich umfasst das Servermodul 232' eine Funktionalität, die Vergünstigungen speichert und vorlegt, die für bestimmte Verbraucher erhältlich sind. Zum Beispiel können erhältliche Vergünstigungen wie Flugtickets, Prämien usw. ... vorgelegt werden.
Punkte (wie Vielfliegermeilen zum Beispiel), die ein Verbraucher anhäuft, um Vergünstigungen zu erhalten, können durch eine Kontonummer, ein Passwort oder andere Kennungen mit einem bestimmten Verbraucher verbunden sein. Die Menge an Punkten, die für jeden Verbraucher angehäuft ist, kann auf dem Webserver 208' unter Verwendung des Servermoduls 232' gespeichert werden oder kann sich in einer anderen Datenbank der Organisation befinden, die die Vergünstigungen bereitstellt. In einer anderen möglichen Ausführungsform werden diese Punkte für jedes Programm, an dem ein Verbraucher teilnimmt, in einer Loyalitätsanwendung auf der Karte des Verbrauchers gespeichert. Zum Beispiel kann ein Verbraucher eine Guthabenkarte besitzen, die nicht nur Geldwert, sondern zusätzlich auch eine Menge an Vielfliegermeilen speichert, die für eine bestimmte Fluggesellschaft (oder eine Anzahl von Fluggesellschaften) angehäuft werden, Punkte, die für das Benutzen einer bestimmten Kreditkarte angehäuft werden, Punkte für Hotelaufenthalte in bestimmten Hotels usw. In Bezug auf Punkte, die auf der Loyalitätsanwendungskarte des Verbrauchers gespeichert sind, können diese Punkte in fast derselben Weise überprüft und abgebucht werden, in der Geldwert auf der Karte des Verbrauchers abgebucht wird, wie hier beschrieben wird.
Eine Ausführungsform, durch die ein Verbraucher seine oder ihre Pseudo-Guthabenanwendung auf einer Karte authentifizieren lässt, um Punkte für Vergünstigungen einzulösen, wird nun erklärt. In einer spezifischen Ausführungsform kann ein ähnliches Verfahren wie das in dem Flussdiagramm von 11A–11D zur Abbuchung von Geldwert beschriebene angewendet werden. Zuerst greift ein Kundenterminal 204, das einen Benutzer (Verbraucher) bedient, über die Verbindung 234' auf den Webserver 208' zu, überprüft die Vergünstigungen, die für ein bestimmtes Programm (wie ein Vielfliegerprogramm einer Fluggesellschaft) vorgelegt werden, wählt Vergünstigungen von diesem Programm aus und fordert an, dass die Transaktion unter Verwendung seiner oder ihrer Pseudo-Guthabenanwendung ausgeführt wird, um zu validieren, dass die Karte Zugang zu den Dienstleistungen hat. Der Webserver 208' erhält und verarbeitet diese Anforderung. Die zuvor beschriebenen Schritte können in ähnlicher Weise ausgeführt werden wie Schritt 602 und 604.
Anschließend sendet der Webserver 208' in Schritt 606 eine Informationsseite an das Kundenterminal 204. Beim Anfordern von Vergünstigungen ist das Gesamtkostenfeld null und das Währungsfeld ist ein speziell zugewiesener Wert. Durch Halten des Gesamtkostenfelds gleich null wird bewirkt, dass das System die Authentifizierung ausführt, aber keinen Zahlungseintrag erstellt. Wahlweise können für diejenigen Benutzer, deren Karten den Betrag ihrer Punkte enthalten, zusätzliche Felder von dem Server 208' an das Terminal 204 gesendet werden, die anzeigen, wie viele Punkte von welchem Konto abgebucht werden sollen. Das Gesamtkosten- und Währungsfeld können ohne Weiteres für diesen Zweck angepasst werden.
Anschließend wird eine Abbuchungsanforderungsmeldung in ähnlicher Weise wie in den Schritten 608–612 erstellt, und die Abbuchungsanforderung wird über die Verbindung 236' an den Authentifizierungsserver 206' geschickt. Ähnlich wie in Schritt 614 verarbeitet der Authentifizierungsserver nun die Abbuchungsanforderung in Verbindung mit der Sicherheitskarte 218 (zum Beispiel) und schickt einen „Abbuchungs"-Befehl und eine Sicherheitskartensignatur an den Authentifizierungsserver 206' zurück. Da die Gesamtkosten null sind, ist der „Abbuchungsbetrag"-Zustand, der von der Sicherheitskarte 218 erreicht wird, ebenfalls null. In der möglichen Ausführungsform, in der die Guthabenkarte 5 Punkte für ein bestimmtes Programm speichert, können die Gesamtkosten ein Wert sein und ein „Abbuchungsbetrag"-Zustand kann erreicht werden, der eine Anzahl von Punkten anzeigt, die von Karte 5 abgebucht werden sollen.
Anschließend schickt der Authentifizierungsserver 206' den Abbuchungsbefehl und die Sicherheitskartensignatur in ähnlicher Weise wie in den Schritten 616–618 an das Kundenterminal 204, und diese Informationen werden von der Karte 5 verarbeitet. Obwohl kein Geldwert abgebucht wird, führt die Karte 5 die Verarbeitung aus, wie das Erhöhen eines Zählerstands, wobei sie die Anzahl der Transaktionen anzeigt und eine Guthabenkartensignatur erstellt. In der möglichen Ausführungsform, in der Punkte auf der Karte 5 gespeichert werden, können die Punkte, die benötigt werden, um die Vergünstigung, die der Benutzer von dem Webserver 208' ausgewählt hat, einzulösen, in diesem Schritt von dem entsprechenden Konto abgebucht werden.
Die Schritte 620 bis 638 werden in ähnlicher Weise ausgeführt wie in 11B und 11C, außer dass in diesem Fall eine Geldtransaktion nicht überprüft wird, sondern die Karte 5 authentifiziert wird, um es dem Benutzer zu ermöglichen, seinen Zugang zu Dienstleistungen oder Vergünstigungen durchzuführen. Insbesondere in Schritt 626 wird die Signatur von Karte 5 von der Sicherheitskarte 218 überprüft. In dieser Ausführungsform würde die Sicherheitskarte 218 eine „Authentifizierung OK"-Meldung statt der „Bestätigungs"-Meldung von Schritt 628 schicken. Der Webserver 208' bucht dann die entsprechende Anzahl an Punkten von dem Konto des Benutzers ab oder erlaubt den Zugang zu einer bevorrechtigten Dienstleistung für die angeforderte Vergünstigung. In der möglichen Ausführungsform, in der Punkte auf der Karte 5 gespeichert werden, dient die „Authentifizierung OK"-Meldung nicht nur als Authentifizierung der Karte 5, sondern auch als Bestätigung dafür, dass die richtige Anzahl an Punkten für das entsprechende Programm von der Karte 5 abgebucht worden ist. Anschließend gibt der Webserver 208' ähnlich wie in Schritt 640 die Vergünstigung frei, die der Benutzer angefordert hat (wie Flugtickets, Prämien, Rabatte usw.), und es wird eingerichtet, dass die Vergünstigung dem Benutzer bereitgestellt wird.
Es sollte geschätzt werden, dass dieses Verfahren zum Einlösen von Punkten für Vergünstigungen auch unter Verwendung jeder beliebigen der möglichen Ausführungsformen von 6, 7 oder 8 angewendet werden kann, wodurch die Vorteile, die mit diesen Ausführungsformen verbunden sind, erreicht werden. Außerdem kann dieses Verfahren die Verschlüsselungsschicht-Ausführungsform von 9 nutzen. Zusätzlich kann die vorliegende Erfindung, wie nachfolgend beschrieben, auch verwendet werden, um mehr Punkte auf die Karte 5 zu laden, in nahezu der gleichen Weise, in der Geldwert hinzugefügt wird.
LADEN EINER GUTHABENKARTE
17 stellt ein System 850 für das Laden von Wert auf eine Guthabenkarte gemäß einer Ausführungsform der vorliegenden Erfindung dar. Das System 850 umfasst ein Kundenterminal 204, einen Bankserver 860 und den Ladeserver 862. Das Kundenterminal 204 kommuniziert mit der Karte 5 über den Kartenleser 210 und mit dem Bankserver 860 und dem Ladeserver 862 über jedes beliebige geeignete offene Netzwerk wie das Internet 202. Geeignete Ausführungsformen für das Kundenterminal, den Kartenleser und die Guthabenkarte sind zuvor in der Beschreibung eines Zahlungsverfahrens beschrieben worden. Vorzugsweise setzen das Kundenterminal 204, der Bankserver 860 und der Ladeserver 862 jeweils ein Codemodul (im Betrieb ähnlich wie die zuvor beschriebenen Codemodule) in der Programmiersprache Java um, die die nachfolgend beschriebene Funktionalität bereitstellt. Der Einfachheit halber wird nachfolgend Bezug auf „Kundenterminal", „Bankserver" und „Ladeserver" genommen, obwohl der enthaltene Code die Funktionen ausführt. Der Kartenaussteller 108 ist zuvor in 3 beschrieben worden. Bei dem Kartenaussteller 108 kann es sich um eine von der Bank, die den Bankserver 860 umfasst, getrennte Finanzinstitution handeln, oder bei dem Kartenaussteller 108 kann es sich um dieselbe Bank handeln, die den Bankserver 860 umfasst.
Der Bankserver 860 ist jeder beliebige geeignete Computer innerhalb einer Bank oder einer anderen Finanzinstitution. Zum Beispiel ist der Bankserver 860 jeder beliebige geeignete Personal Computer, eine Workstation oder ein Mainframe-Computer. In einer Ausführungsform betreibt der Bankserver 860 ein „Servlet"-Programm (ein Java-Applet, das auf einem Server läuft) für die Kommunikation mit dem Client 204.
Der Ladeserver 862 ist ebenfalls jeder beliebige geeignete Computer und kann sich an dem Standort einer dritten Partei befinden (wie ein Prozessor) oder kann sich innerhalb derselben Bank wie der Bankserver 860 befinden. Der Ladeserver 862 betreibt ebenfalls ein Servlet-Programm für die Kommunikation mit dem Kundenterminal 204 und dem Host-Sicherheitsmodul 864. In einer anderen möglichen Ausführungsform handelt es sich bei dem Ladeserver 862 und dem Bankserver 860 um denselben Computer, der zwei verschiedene Anwendungen betreibt, wobei er die Funktionalität jedes Servers darstellt.
Das Host-Sicherheitsmodul (HSM) 864 ist eine Vorrichtung, die im Fachgebiet bekannt ist und in eine Hardware-„Blackbox" oder jeden beliebigen geeigneten Computer eingebaut werden kann. Das Host-Sicherheitsmodul kann in einem Hardwaremodul außerhalb von Ladeserver 862 umgesetzt sein, es kann in dem Ladeserver 862 umgesetzt sein, es kann in Software umgesetzt sein oder es kann als eine zuvor beschriebene Sicherheitskarte umgesetzt sein. Das Host-Sicherheitsmodul 864 umfasst die Verschlüsselungsschlüssel in der Hardware, die für das Erstellen von Signaturen (zum Beispiel S1, S2 und S3) verwendet werden, die Sicherheit für die Transaktion bereitstellen. Diese Signaturen werden von der Guthabenkarte 5 und dem Host-Sicherheitsmodul 864 verwendet, um sicherzustellen, dass die Karte nicht abgelaufen oder gefälscht ist (das heißt, eine echte Karte ist), um sicherzustellen, dass das Modul 864 authentisch ist, um sicherzustellen, dass das System 850 authentisch ist und allgemein für eine gültige Transaktion zu sorgen und Betrug zu verhindern. Die Karte 5 umfasst auch Verschlüsselungsschlüssel für das Erstellen einer Guthabenkartensignatur. In einer anderen möglichen Ausführungsform könnte das Modul 864 durch ein Standardterminal ersetzt werden, das eine Sicherheitskarte umfasst, wie in den zuvor beschriebenen Ausführungsformen dargestellt. In dieser Situation wären die Verschlüsselungsschlüssel in der Sicherheitskarte gespeichert.
Kurz gesagt funktioniert das System 850 wie folgt. Ein Verbraucher greift auf den Bankserver 860 über das Kundenterminal 204 zu. Vorausgesetzt, dass die Karte 5 nicht überlastet ist und das Konto des Benutzers genügend Geld aufweist, kann der Benutzer über den Bankserver 860 Wert auf seine Guthabenkarte 5 herunterladen. Das Kundenterminal 204 kommuniziert mit dem Ladeserver 862, um die Authorisierung für das Laden und höhere Sicherheit zu erhalten. Die Karte 5 kann dann verwendet werden, um Käufe über das Internet zu tätigen, wie zuvor in der Anwendung beschrieben, oder kann für anderweitige Käufe benutzt werden. Sobald die Bank Wert auf die Karte 5 heruntergeladen hat, wird ein entsprechender Geldbetrag von der Bank an den Kartenaussteller 108 übertragen.
Der Kartenaussteller 108 legt dieses Geld in einen Aufbewahrungspool. Sobald die Guthabenkarte 5 verwendet wird, um einen Kauf von einem Händler zu tätigen, wird die Transaktion erfasst und durch einen Bezahldienst wie VisaNet bezahlt. Die Ausstellerbank verringert den Aufbewahrungspool um den Betrag des Kaufs, der an die Händlerbank bezahlt wird. Die Händlerbank bezahlt den Händler für die Transaktion. Die Bezahlung kann in jeder beliebigen geeigneten Weise erfolgen, wie sie im Fachgebiet bekannt ist, und insbesondere kann sie umgesetzt werden, wie zuvor in 3 beschrieben.
AUSFÜHRLICHER LADETRANSAKTIONSFLUSS
Eine Ausführungsform eines Verfahrens, durch das eine Guthabenkarte über das Internet geladen wird, wird nun unter Verwendung des Flussdiagramms von 18A bis 18D mit Bezug auf 17 beschrieben. Verschiedene der nachfolgenden Schritte können in unterschiedlicher Reihenfolge auftreten; die folgende Beschreibung dient der Veranschaulichung. Die Wechselbeziehung zwischen dem Kundenterminal 204 und dem Bankserver 860 und zwischen dem Kundenterminal 204 und dem Ladeserver 862 ist vorzugsweise in einer ähnlichen Weise umgesetzt wie die zwischen dem Kundenterminal 204 und dem Händlerserver 208 und zwischen dem Kundenterminal 204 und dem Zahlungsserver 206, wie zuvor beschrieben wurde. Gewisse Einzelheiten der Umsetzung bezüglich der Bezahlung, die zuvor erwähnt wurden, sind auch auf das Laden einer Guthabenkarte anwendbar. Außerdem stellt der beispielhafte Fluss, der in den Figuren gezeigt wird, eine erfolgreiche Transaktion dar (obwohl auch ein negatives Ergebnis im nachfolgenden Text erklärt wird). Aus diesem Grund wird Bezug auf eine „Bestätigungs"-Meldung genommen, die allgemeiner als „Ergebnis"-Meldung bezeichnet werden kann (um sowohl die Möglichkeit des Erfolgs als auch des Fehlschlagens eines Ladevorgangs anzuzeigen). Außerdem wird Bezug auf eine „Ladeerfolgs"-Meldung genommen, die auch als „Bestätigungs"-Meldung bezeichnet werden kann, um ihren Status anzuzeigen, der entweder ein positives Ladeergebnis oder ein negatives Ladeergebnis bestätigt.
Zunächst wird ein geeigneter Webbrowser des Kundenterminals 204 von einem Benutzer verwendet, um auf die Internetseite eines Bankservers zuzugreifen. In Schritt 871 wählt der Benutzer eine Option aus, um Wert auf die Karte 5 zu laden. In Schritt 872 schickt der Bankserver eine Anforderung für Karteninformationen (einschließlich des gegenwärtigen Kartenkontostands und des maximalen Kartenkontostands); das Kundenterminal 204 liest den gegenwärtigen Kartenkontostand, die Währung und andere Karteninformationen über den Kartenleser 210 und schickt den Kontostand an den Bankserver 860 zurück. In Schritt 873 bestimmt der Bankserver den maximalen Ladewert und überprüft, ob genug Geld auf dem Konto des Benutzers ist, um einer Ladeanforderung nachzukommen.
In Schritt 874 erstellt der Bankserver eine HTML-Seite, die die folgenden Client-Applet-Parameter umfasst: den Ladewert; den Währungstyp, der verwendet wird; den Port und die IP-Adresse des Ladeservers; eine eindeutige Transaktionskennung, die sowohl von dem Ladeserver als auch von dem Bankserver verwendet wird, um eine Transaktion zu überwachen; und einen Sitzungsschlüssel. Weitere Informationen können ebenfalls enthalten sein, wie der Währungsexponent, eine Status-URL-Adresse des Bankservers, der für die Kommunikation von dem Kundenterminal verwendet wird, und andere Sicherheitsinformationen, um die Identität der Bank und die Integrität der Meldung sicherzustellen. Weitere prozessbezogene Informationen, wie die Software-Ausgabenummer, die Verschlüsselungsmethodologie und die Schlüssel können ebenfalls übermittelt werden. Sobald diese Seite erstellt worden ist, wird die Seite an den anfordernden Kundenbrowser geschickt und löst die Aktivierung des Client-Codemoduls (in diesem Beispiel ein Java-Applet) aus.
Um den Ladewert zu bestimmen, verlangt der Bankserver, dass der Benutzer den Wert eingibt, mit dem die Karte geladen werden soll. Vorausgesetzt, dass das Konto des Benutzers ausreichend ist, verlangt der Bankserver, dass in Schritt 875 eine Abbuchung um den Ladewert von dem Konto des Benutzers vorgenommen wird, Vorteilhafterweise kann die Abbuchungsanforderung von dem Bankserver den vorhandenen Geldautomaten und die Abrechnungssysteme der Bank benutzen, um eine Abbuchung von dem Konto des Benutzers vorzunehmen. Vom Standpunkt der Bank aus wird Wert von dem Konto des Benutzers in ganz ähnlicher Weise übertragen, in der Wert an einen Benutzer in Form von Bargeld an einem Geldautomaten übertragen werden würde. In dieser Situation allerdings wird der Wert nicht als Bargeld an einem Geldautomaten ausgegeben, sondern wird über das Internet an eine Guthabenkarte geschickt.
In Schritt 876 tritt das Kundenterminal in Wechselbeziehung mit der Guthabenkarte 5, um Karteninformationen zu erhalten, um eine Ladeantwortmeldung für die spätere Übermittlung an den Ladeserver 862 zu erstellen. Sobald die Antworten von der Karte erhalten worden sind, kombiniert das Kundenterminal diese Antworten zu einem Bytestrom, der für die Übermittlung über ein Netzwerk an einen Ladeserver geeignet ist.
Das Kundenterminal emuliert eine Vielzahl von Befehlen des Host-Sicherheitsmoduls 864, um Antworten von diesen Befehlen von der Guthabenkarte zu erhalten. Die Guthabenkarte und das Sicherheitsmodul sind physisch getrennt voneinander; die Kommunikation findet über das Internet statt. Im Interesse von Schnelligkeit und Zuverlässigkeit ist es vorteilhaft, nur die herkömmliche Authentifizierung, Antwort und Bestätigungsmeldung austauschen zu lassen.
Um in dieser Umgebung sicher und zuverlässig zu arbeiten, emuliert das Kundenterminal in einer Ausführungsform der vorliegenden Erfindung ein Sicherheitsmodul und sammelt alle Antworten zur Übertragung in einer Ladeanforderungsmeldung. Die Ladeanforderungsmeldung kann eine Vielzahl von Informationen umfassen und umfasst vorzugsweise eine erste Kartensignatur (S1 genannt), eine Kartennummer, ein Ablaufdatum und einen Ladebetrag. Weitere Informationen wie der Sicherheitsalgorithmus, der Transaktionszählerstand, der gegenwärtige Kartenkontostand und der Zeitstempel des Bankservers werden vorzugsweise ebenfalls bereitgestellt.
Da alle diese Informationen im Voraus in eine einzige Ladeanforderungsmeldung verpackt werden, wird die Anzahl der Meldungen, die zwischen der Guthabenkarte und dem Sicherheitsmodul über das Internet ausgetauscht werden, auf ein Mindestmaß verringert.
Anschließend greift in Schritt 877 das Kundenterminal unter Verwendung der IP-Adresse, die es von dem Bankserver erhalten hat, auf den Ladeserver zu. In Schritt 878 schickt das Kundenterminal die Ladeanforderungsmeldung an den Ladeserver. In Schritt 879 verarbeitet der Ladeserver die Ladeanforderung in Verbindung mit einem zugehörigen Host-Sicherheitsmodul 864, wie im Folgenden ausführlicher mit Bezug auf 18D erklärt wird. Nach Schritt 879 hat der Ladeserver eine Sicherheitsmodulsignatur des Ausstellers (S2 genannt) als Teil eines Ladebefehls von dem Sicherheitsmodul 864 erhalten. Die Sicherheitsmodulsignatur ist ein Wert, der das Sicherheitsmodul eindeutig identifiziert und validiert, um der Guthabenkarte 5 zu beweisen, dass der eingehende Ladebefehl ein gültiger Befehl von einem realen Sicherheitsmodul ist. Somit ist dem Benutzer der Guthabenkarte und anderen beteiligten Parteien garantiert, dass ein gültiges Laden der Karte erfolgt ist. In einer bevorzugten Ausführungsform der Erfindung ist die Sicherheitsmodulsignatur ein verschlüsselter Wert, der sicherstellt, dass keine andere Einheit eine Identität eines Sicherheitsmoduls fälschen kann.
In Schritt 880 schickt der Ladeserver den Ladebefehl einschließlich der Sicherheitsmodulsignatur an das Kundenterminal, damit sich die Guthabenkarte selbst lädt. In Schritt 881 gibt das Kundenterminal, nachdem es den Ladebefehl von dem Ladeserver erhalten hat, den Ladebefehl an die Guthabenkarte 5 weiter, die die Signatur überprüft, sich selbst mit dem Ladewert lädt und auch eine Ladeerfolgsmeldung, eine zweite Guthabenkartensignatur (S3 genannt) und einen Ergebniscode erstellt, der den Erfolg oder den Fehlschlag des Ladens angibt. In einer bevorzugten Ausführungsform der Erfindung liegt diese Signatur in verschlüsselter Form vor, um Verfälschung zu verhindern.
In Schritt 882 sendet die Karte 5 eine Ladeerfolgsmeldung, die die Kartensignatur (S3) und den Ergebniscode umfasst, zurück an das Kundenterminal 204. Anschließend verpackt in Schritt 883 das Kundenterminal 204 die Ladeerfolgsmeldung zusammen mit der Kartensignatur und schickt diese zurück an den Ladeserver 862. In Schritt 884 erhält der Ladeserver die eingehende Meldung. Der Ladeserver verarbeitet die Meldung dann in ihre Bestandteile und leitet die Bestandteile an das Sicherheitsmodul. Anschließend kann in Schritt 885 das Sicherheitsmodul diese Antwort von dem Kundenterminal verarbeiten und die erhaltene Guthabenkartensignatur (S3) überprüfen.
Da das Sicherheitsmodul die Schlüssel und Algorithmen umfasst, die notwendig sind, um Guthabenkartensignaturen zu berechnen, kann das Sicherheitsmodul überprüfen, dass eine erhaltene Guthabenkartensignatur tatsächlich gültig ist, indem es die Guthabenkartensignatur mit einem erstellten erwarteten Wert vergleicht. Ein erfolgreicher Vergleich zeigt an, dass eine Ladeerfolgsmeldung, die von der Guthabenkarte erhalten wird, tatsächlich eine gültige Erfolgsmeldung ist und dass die Guthabenkarten geladen worden ist. In Schritt 886 sendet das Sicherheitsheitsmodul eine „Bestätigungs"-Meldung zurück an den Ladeserver, vorausgesetzt, die Transaktion ist so weit gültig.
Es ist möglich, dass die Guthabenkarte nicht mit dem richtigen Betrag aufgeladen worden ist, dass die Karte ungültig ist, ein Benutzer betrügerisch ist oder eine andere Unstimmigkeit auftritt. Zum Beispiel ist es möglich, dass ein Benutzer sich an der Karte zu schaffen gemacht hat, um es so erscheinen zu lassen, dass kein Laden erfolgt ist, wenn tatsächlich ein Laden erfolgt ist. In dieser Situation ist der Fortgang in Schritt 882 und im Folgenden ein etwas anderer. Zum Beispiel kann die Karte, anstatt eine „Ladeerfolg"-Meldung zu erstellen, einen „negatives Ergebnis"-Code erstellen, der möglicherweise anzeigt, dass die Karte nicht geladen worden ist. Der Fortgang in dieser Situation würde dann wie folgt vor sich gehen.
In Schritt 882 schickt die Karte 5 eine Lademeldung, die den Ergebniscode und die Guthabenkartensignatur S3 umfasst, zurück an das Kundenterminal 204. Das Kundenterminal 204 erkennt einen negativen Ergebniscode und ruft die Verarbeitung für Negativergebnisse auf. Das Kundenterminal tritt in Wechselbeziehung mit der Karte 5 und erstellt eine neue Ladeanforderung für einen Nullwert unter Verwendung von Elementen von der ursprünglichen Anforderung, zusammen mit einer neuen Kartensignatur S1.
Der Negativergebniscode wird, zusammen mit den Signaturen S3 und der neuen S1 und der Nullwertladeanforderung, zur Analyse an den Ladeserver weitergegeben. Der Ladeserver bestimmt, ob der Transaktionszählerstand in dem Nullladewert dem Transaktionszähler in der vorigen Anforderung entspricht und überprüft andere aussagekräftige Informationen wie Datum und Zeit, Kartennummer und Währungscode und – exponent. Wenn die Transaktionszähler gleich sind, ist es möglich, dass ein gültiges negatives Ergebnis erhalten worden ist, es sollte jedoch überprüft werden, da der Kunde nicht vertrauenswürdig ist. Wenn die Zähler gleich sind, enthält der Ladeserver die ursprüngliche S3 und erstellt eine neue Ladeanforderung an das Sicherheitsmodul unter Verwendung von Datenelementwerten, die erwartet worden wären, wenn die ursprüngliche Transaktion fehlgeschlagen wäre. Die neue Ladeanforderung wird, zusammen mit der neuen S1, an das Sicherheitsmodul geschickt. Das Sicherheitsmodul vergleicht dann die ursprüngliche S1 (von der ursprünglichen Ladeanforderung) mit der neuen S1. Wenn S1 gültig ist, ist das ursprüngliche negative Ergebnis richtig und das Sicherheitsmodul erstellt eine Signatur, um dem Ladeserver zu bestätigen, dass kein Laden erfolgt ist. Das ursprüngliche negative Ergebnis von der Karte wird dann an das Sicherheitsmodul freigegeben, damit dieses die ursprüngliche Transaktion abschließt. Die Verarbeitung würde fortschreiten, aber es würde keine Abbuchung von einem Benutzerkonto erfolgen, und eine Bezahlung braucht nicht stattzufinden, weil die Karte tatsächlich nicht geladen wurde. Wenn S1 nicht gültig ist, ist die negative Antwort nicht richtig, und dann wird der Ergebniscode in der ursprünglichen Anforderung geändert, um ein erfolgreiches Laden anzuzeigen, und an das Sicherheitsmodul weitergegeben. Die Bearbeitung schreitet dann fort, wobei sie anzeigt, dass ein Laden erfolgt ist.
Andererseits ist es, wenn die Transaktionszähler nicht gleich sind, dennoch möglich, dass ein gültiges negatives Ergebnis erhalten worden ist, es sollte jedoch überprüft werden, weil der Kunde nicht vertrauenswürdig ist. Zunächst verringert der Ladeserver den Transaktionszähler in der neuen Ladeanforderung, so dass er dem ursprünglichen entspricht. Die Anforderung wird, zusammen mit der neuen S1, an das Sicherheitsmodul weitergegeben. Das Sicherheitsmodul berechnet seine eigene neue S1, die auf der veränderten neuen Ladeanforderung basiert. Wenn es keine Entsprechung gibt, bedeutet das, dass das negative Ergebnis ein Fehler war und dass die Karte geladen worden war. Die Bearbeitung schreitet fort und zeigt eine geladene Karte an. Wenn es eine Entsprechung gibt, bedeutet das, dass das negative Ergebnis richtig war und der Transaktionszähler zufällig erhöht worden war. Es wird keine Abbuchung von dem Benutzerkonto vorgenommen und es erfolgt keine Bezahlung.
Was nun den weiteren Fortgang betrifft, so verzeichnet in Schritt 887 der Ladeserver die Antwort, die er von dem Sicherheitsmodul erhalten hat, und aktualisiert seine Datenbank mit der Transaktionskennung, der Bankkennung, dem Ladewert usw. Im Allgemeinen kann jeder der Informationsüberflüsse, die den Ladeserver durchlaufen, in seine Datenbank aufgenommen werden. Anschließend erstellt der Ladeserver in Schritt 890 eine Bestätigungsmeldung, die die Transaktionskennung umfasst, und schickt diese Meldung in verschlüsselter Form an das Kundenterminal. Durch das Senden dieser Bestätigungsmeldung in verschlüsselter Form kann die Bestätigungsmeldung über das Kundenterminal an den Bankserver weitergeleitet werden, ohne dass Verfälschung befürchtet werden muss. Da die Bestätigungsmeldung verschlüsselt ist, wäre es schwierig für das Kundenterminal oder eine andere Einheit, eine Bestätigungsmeldung zu fälschen und den Bankserver dahingehend zu täuschen, dass er annimmt, es habe ein gültiges Laden stattgefunden.
In Schritt 891 leitet das Kundenterminal die Bestätigungsmeldung an den Bankserver unter der URL-Adresse weiter, die zuvor von dem Bankserver erhalten wurde. Das Kundenterminal kann auch eine Meldung an den Benutzer schicken, die ihn darüber informiert, dass das Laden abgeschlossen worden ist. Das Kundenterminal verzeichnet auch die Bestätigung des Ladens. In Schritt 892 registriert der Bankserver die Bestätigungsmeldung. Der Bankserver ruft eine Routine auf, um die Bestätigungsmeldung zu entschlüsseln. Wenn die entschlüsselte Bestätigungsmeldung akzeptabel ist, bestimmt der Bankserver, dass ein erfolgreiches Laden stattgefunden hat. Die Bestätigungsmeldung verschafft der Bank die Gewissheit, dass die Karte des Benutzers tatsächlich mit einem bestimmten Wert geladen wurde, und verhindert Betrug. Zum Beispiel würde einem betrügerischen Benutzer, der versucht, zu behaupten, dass sein Bankkonto vermindert und seine Karte nicht geladen wurde (und der somit mehr Geld von der Bank bekommen müsste), ein Strich durch die Rechnung gemacht, weil die Bestätigungsmeldung beweist, dass die Karte des Benutzers tatsächlich geladen wurde. Wahlweise kann die „Bestätigungs"-Meldung anzeigen, dass ein Laden nicht erfolgt ist, in welchem Fall keine Abbuchung von dem Konto vorgenommen und keine Bezahlung erfolgen würde.
An diesem Punkt ist ein erfolgreiches Laden der Benutzerkarte erfolgt (vorausgesetzt, alles ist in Ordnung). Wenn der Benutzer zum Beispiel 100 $ angefordert hatte, ist dieser Betrag von dem Konto des Benutzers bei der Bank abgebucht worden und 100 $ sind auf die Guthabenkarte des Benutzers geladen worden. Vorzugsweise wird an diesem Punkt der geladene Betrag (in diesem Beispiel 100 $) von der Bank an den Guthabenkartenaussteller übermittelt, vorzugsweise über ein existierendes Netzwerk. Die 100 $ werden übermittelt, so dass der Kartenaussteller den Wertstellungsgewinn für diese nicht ausgegebenen Geldmittel verwalten kann, bis der Benutzer die 100 $ ausgibt. Sobald die 100 $ (oder ein kleinerer Teil) bei einem Händler ausgegeben worden sind, kann der Kartenaussteller die Transaktion bei dem Händler unter Verwendung jedes beliebigen Abrechnungs- und Verwaltungssystems bezahlen. In einer anderen möglichen Ausführungsform kann die Bank die 100 $ zurückhalten und den Händler direkt bezahlen. In einer weiteren Ausführungsform handelt es sich bei der Bank und dem Kartenaussteller um dieselbe Finanzinstitution, und die 100 $ können zwischen Teilen der Organisation verlagert werden oder am Platz bleiben.
Um nun ausführlicher auf Schritt 879 einzugehen, beschreibt 11D ein Verfahren zum Verarbeiten einer Ladeanforderungsmeldung in Verbindung mit einem Sicherheitsmodul. Sobald die Ladeanforderungsmeldung durch den Ladeserver erhalten wird, teilt der Ladeserver sie in ihre entsprechenden Elemente auf und gibt eine Anforderung an das Sicherheitsmodul weiter, wie nachfolgend erklärt wird. Wahlweise kann der Ladeserver eine Netzwerkmeldung erstellen und die Anforderung an einen entfernten Authentifizierungsserver weiterzugeben. Oder ein intelligentes Terminal könnte die Meldung aufteilen und die Antworten an das Sicherheitsmodul weitergeben.
In Schritt 895 überprüft der Ladeserver die Ladeanforderung auf syntaktische Korrektheit und verzeichnet die Anforderung als erhalten. In Schritt 896 erstellt der Ladeserver eine Ladeanforderungsmeldung. In Schritt 897 gibt der Ladeserver die Ladeanforderung an das Sicherheitsmodul weiter, damit es eine Guthabenkarte emuliert, die mit dem Sicherheitsmodul in Wechselbeziehung tritt. Der Ladeserver verhält sich, als ob tatsächlich eine Guthabenkarte in einem Geldautomaten (zum Beispiel) über ein Netzwerk zu einem Host mit einem Sicherheitsmodul in Wechselbeziehung träte. Auf diese Weise ist die Ladeanforderung, die von dem Kundenterminal stammt, in im Voraus verpackter Form über das Internet geschickt worden, wobei sie eine herkömmliche Wechselbeziehung zwischen der Guthabenkarte in einem Geldautomaten emuliert.
In Schritt 898 überprüft das Sicherheitsmodul die erhaltene Guthabenkartensignatur (S1), um Betrug zu verhindern. Das Sicherheitsmodul erstellt seine Sicherheitsmodulsignatur (S2 genannt) und den Ladebefehl. Die Signatur S2 bestätigt dem Kundenterminal und der Guthabenkarte, dass das Host-Sicherheitsmodul authentisch ist und zu dem Aussteller der Guthabenkarte gehört. Zusätzlich schützt S2 vor einem Benutzer, der versucht, ein Laden zu fälschen, gegen unsynchrone Schlüssel, eine gefälschte Karte, eine abgelaufene Karte usw. Das Sicherheitsmodul schickt dann die Signatur und den Ladebefehl an den Ladeserver, wie in Schritt 899 angezeigt. An diesem Punkt endet Schritt 879, und die Steuerung kehrt zu Schritt 880 zurück.
In einer weiteren Ausführungsform des Ladeverfahrens kann ein Verbraucher wünschen, auf eine Vielzahl von Webservern zuzugreifen, um Vielfliegermeilen, Belohnungspunkte usw. zu laden, die er oder sie angehäuft hat. Ein Verfahren zum Authentifizieren und Einlösen solcher „Punkte" ist zuvor beschrieben worden. In der Ladeausführungsform hat ein Verbraucher Punkte durch eine beliebige Vielzahl von Programmen bei Fluggesellschaften, Restaurants, Autovermietungen, Hotels, Banken, Kredit- oder Debitkartenausstellern, Telefon- oder anderen Kommunikationsgesellschaften usw. angehäuft. Diese Punkte werden von der bestimmten Fluggesellschaft usw. gespeichert, die sie ausgegeben hat. Der Verbraucher wünscht, diese Punkte auf sein oder ihr Konto zu laden, um sie anderweitig einzulösen und somit Flugtickets, Mahlzeiten, Übernachtungen, Prämien, Belohnungen, Rabatte oder andere Vergünstigungen zu erhalten. Indem der Verbraucher auf einen Internetserver zugreift, der dem bestimmten Programm zugehörig ist, kann er seine oder ihre Guthabenkarte in jeder beliebigen der hier beschriebenen Ausführungsformen laden, um die Vergünstigungen des Programms zu erhalten, in einer sehr ähnlichen Weise, wie Währung geladen wird.
COMPUTERSYSTEM-AUSFÜHRUNGSFORM
19 stellt ein Computersystem 900 dar, das für das Umsetzen einer Ausführungsform der vorliegenden Erfindung geeignet ist. Das Computersystem 900 umfasst eine beliebige Anzahl von Prozessoren 902 (auch als zentrale Verarbeitungseinheiten oder CPUs bezeichnet), die mit Speichergeräten gekoppelt sind, einschließlich Primärspeicher 906 (wie ein RAM-Speicher) und Primärspeicher 904 (wie ein ROM-Speicher). Wie im Fachgebiet bekannt ist, dient der Primärspeicher 904 dazu, Daten und Anweisungen unidirektional an die CPU zu übertragen, und der Primärspeicher 906 wird üblicherweise dazu verwendet, Daten und Anweisungen in einer bidirektionalen Weise zu übertragen. Beide Primärspeichergeräte können alle beliebigen computerlesbaren Medien umfassen, die nachfolgend beschrieben werden.
Ein Massenspeichergerät 908 ist ebenfalls bidirektional mit der CPU 902 gekoppelt und stellt zusätzliche Datenspeicherkapazität bereit und kann ebenfalls alle beliebigen computerlesbaren Medien umfassen, die nachfolgend beschrieben werden. Das Massenspeichergerät 908 kann verwendet werden, um Programme, Daten und ähnliches zu speichern und ist üblicherweise ein Sekundärspeichermedium (wie eine Festplatte), das langsamer ist als der Primärspeicher. Es wird geschätzt werden, dass die Informationen, die in dem Massenspeichergerät 908 gespeichert werden, in angebrachten Fällen auf Standardweise in dem Massenspeichergerät 908 als Teil des Primärspeichers 906 als virtueller Speicher eingebunden werden können. Ein spezifisches Massenspeichergerät wie eine CD-ROM 914 gibt Daten unidirektional an die CPU weiter.
Die CPU 902 ist auch mit einer Schnittstelle 910 gekoppelt, die ein oder mehrere Eingabe-/Ausgabegeräte umfasst, wie Videomonitore, Track-Balls, Mäuse, Tastaturen, Mikrofone, berührungssensitive Anzeigen, Transducer-Kartenleser, Magnet- oder Papierbandleser, Grafiktabletts, Eingabestifte, Stimmen- oder Handschrifterkenner, biometrische Leser oder weitere Computer. Die CPU 902 kann wahlweise an einen weiteren Computer oder an ein Telekommunikationsnetzwerk unter Verwendung einer Netzwerkverbindung gekoppelt werden, wie allgemein in 912 dargestellt. Mit einer solchen Netzwerkverbindung wird erwartet, dass die CPU Informationen von dem Netzwerk erhalten oder Informationen an das Netzwerk im Laufe der Ausführung der zuvor beschriebenen Verfahrensschritte ausgeben könnte. Außerdem können Verfahrensausführungsformen der vorliegenden Erfindung nur auf CPU 902 arbeiten oder können über eine Netzwerkverbindung wie das Internet in Verbindung mit einer entfernten CPU arbeiten, die an einem Teil der Verarbeitung beteiligt ist.
Außerdem betreffen Ausführungsformen der vorliegenden Erfindung des weiteren Computer-Speicherprodukte mit einem computerlesbaren Medium, die Programmcodes zum Ausführen verschiedener computer-implementierter Vorgänge besitzen. Bei dem Medium und dem Programmcode kann es sich um speziell für die Zwecke der vorliegenden Erfindung entworfene und aufgebaute handeln, oder sie können von der Art sein, die den Fachleuten im Fachgebiet Software gut bekannt und verfügbar sind.
Beispiele für computerlesbare Medien umfassen, wobei sie nicht darauf beschränkt sind: magnetische Medien wie Festplatten, Disketten und Magnetband; optische Medien wie CD-ROMs; magneto-optische Medien wie Floptical-Discs; und Hardwaregeräte, die speziell dafür ausgelegt sind, den Programmcode zu speichern und auszuführen, wie anwendungsspezifische integrierte Schaltkreise (ASICs), programmierbare logische Geräte (Programmable Logical Devices, PLDs) und ROM- und RAM-Geräte. Beispiele für Programmcodes umfassen Maschinencode, wie er von einem Compiler erstellt wird, und Dateien, die Code einer höheren Programmiersprache enthalten, die von einem Computer unter Verwendung eines Interpreters ausgeführt werden.
Obwohl die vorhergehende Erfindung zum Zwecke der Verständlichkeit in einiger Ausführlichkeit beschrieben worden ist, ist es offensichtlich, dass bestimmte Änderungen und Abwandlungen innerhalb des Umfangs der angehängten Ansprüche umgesetzt werden können. Zum Beispiel kann jede beliebige Guthabenkarte, die auf Befehl Wert laden, speichern und verringern kann, mit der vorliegenden Erfindung verwendet werden. Außerdem kann jedes beliebige Netzwerk, das eine Router-Funktionalität zwischen einem Kundenterminal und einem Lade- und Bankserver ausführen kann, verwendet werden. Außerdem kann das Sicherheitsmodul ein physisch getrenntes Modul sein, eine Karte, die sich in einem Terminal befindet, das an einen Ladeserver angeschlossen ist, oder seine Funktionalität kann direkt in einen Ladeserver in Hardware oder Software eingebunden sein. Und obwohl das Kundenterminal dazu verwendet werden kann, Meldungen zwischen dem Bankserver und dem Ladeserver zu routen, können diese beiden Server auch direkt miteinander kommunizieren und sogar derselbe Computer sein. Die dargestellten spezifischen Meldungen, die zwischen den Computern hin- und hergehen, sind beispielhaft, und es können andere Arten von Meldungen verwendet werden. Eine spezifizierte Ladeanforderung ist dargestellt, andere Informationen können. jedoch ebenfalls auf eine Guthabenkarte unter Verwendung einer Sicherheitsmodulemulation geladen und dann in einer Meldung verpackt an das Sicherheitsmodul über ein Netzwerk geschickt werden. Zusätzlich zu Geldwert können andere Arten von Wert wie elektronisches Geld, Schecks, Belohnungen, Treuepunkte, Vergünstigungen usw. auf eine Karte geladen werden, und der Begriff „Wert" ist dafür bestimmt, alle diese Arten von Abwandlungen allgemein abzudecken. Jede beliebige Art der Verschlüsselung kann verwendet werden, um Meldungen zu verschlüsseln, die zwischen den Computern hin- und hergehen. Darum sollte die beschriebene Erfindung als Veranschaulichung dienen und nicht als Einschränkung aufgefasst werden, und die Erfindung sollte nicht auf die Einzelheiten, die hier behandelt wurden, begrenzt sein, sondern durch die folgenden Ansprüche bestimmt werden.

Claims

Netzwerkzahlungssystem (200) zum Abwickeln eines Warenverkaufs über ein Netzwerk unter Verwendung einer Guthabenkarte (5), umfassend: einen Router (202) zum Routen der Kommunikation zwischen an das Netzwerk angeschlossenen Einheiten; einen mit dem Netzwerk kommunizierenden Händlerserver (208), der über zumindest einen ersten Warenposten zum Verkauf verfügt; ein mit dem Netzwerk kommunizierendes Kundenterminal (204), das ein Kartenlesegerät (210) zum Kommunizieren mit der Guthabenkarte, ein Ausgabegerät (910) zum Prüfen des ersten Verkaufspostens und ein Eingabegerät (910) zum Einleiten einer Kauftransaktion zum Kauf des ersten Verkaufspostens umfasst, wobei das Kundenterminal so aufgebaut ist, dass es anhand von Informationen, die von der Guthabenkarte erhalten werden, eine Kaufmeldung (304) erstellt, wobei die Guthabenkarte so aufgebaut ist, dass sie bei Erhalt eines Abbuchungsbefehls (314) von einer Sicherheitskarte (220) eine automatische Abbuchung von ihrem Speicherwert vornimmt; und gekennzeichnet durch einen mit dem Netzwerk kommunizierenden Zahlungsserver (206), der eine Schnittstelle zum Kommunizieren mit der Sicherheitskarte umfasst und so aufgebaut ist, dass er die Kaufmeldung einschließlich einer Anzeige der Kauftransaktion erhält und über das Netzwerk eine Bestätigungsmeldung (326) an den Händlerserver überträgt, die anzeigt, dass eine Abbuchung von der Guthabenkarte vorgenommen wurde, wobei die Sicherheitskarte so aufgebaut ist, dass sie den für die Guthabenkarte bestimmten Abbuchungsbefehl erstellt, wodurch der Händlerserver autorisiert wird, den Warenposten an einen der Guthabenkarte zugewiesenen Benutzer auszugeben.
Netzwerkzahlungssystem nach Anspruch 1, wobei es sich beim dem Netzwerk um ein Internet (202) handelt und der Händlerserver eine Händlerwebseite zum Bewerben des ersten Verkaufspostens über das Internet umfasst.
Netzwerkzahlungssystem nach Anspruch 1 oder 2, wobei sich das Kundenterminal und der Händlerserver an unterschiedlichen Standorten befinden und über das Internet Informationen austauschen.
Netzwerkzahlungssystem nach Anspruch 1 bis 3, weiterhin umfassend: ein Abrechnungs- und Verwaltungssystem (110) zum Abgleichen einer Vielzahl von Transaktionen über das Netzwerk.
Netzwerkzahlungssystem nach einem der Ansprüche 1 bis 4, wobei das Kundenterminal weiterhin einen Befehlsemulator zum Emulieren von Sicherheitskartenbefehlen, die an die Guthabenkarte gesendet werden, und zum Gruppieren von Antworten auf die Sicherheitskartenbefehle in eine an den Zahlungsserver zu sendende Abbuchungsanforderungsmeldung (310) umfasst, und wobei der Zahlungsserver einen Antwortemulator zum Emulieren von Antworten der Guthabenkarte umfasst, die an die Sicherheitskarte gesendet werden.
Netzwerkzahlungssystem nach einem der Ansprüche 1 bis 5, wobei der Zahlungsserver einen Komparator zum Vergleichen einer Guthabenkartenunterschrift (324), die von der Guthabenkarte erhalten wurde, mit einer erwarteten Unterschrift (314), die von der Sicherheitskarte erhalten wurde, zur Bestätigung einer Transaktion umfasst, wodurch der Meldungsverkehr zwischen dem Zahlungsserver und der Sicherheitskarte reduziert wird.
Netzwerkzahlungssystem nach einem der Ansprüche 1 bis 5, wobei das Kundenterminal einen Komparator zum Vergleichen einer Guthabenkartenunterschrift (320), die von der Guthabenkarte erhalten wurde, mit einer erwarteten Unterschrift (316), die von der Sicherheitskarte über den Zahlungsserver erhalten wurde, zur Bestätigung einer Transaktion umfasst, wodurch der Meldungsverkehr zwischen dem Zahlungsserver und dem Kundenterminal sowie zwischen dem Zahlungsserver und der Sicherheitskarte reduziert wird.
Netzwerkzahlungssystem nach einem der Ansprüche 1 bis 5, wobei der Händlerserver einen Komparator zum Vergleichen einer Guthabenkartenunterschrift (360), die von der Guthabenkarte erhaltene wurde, mit einer erwarteten Unterschrift, die von der Sicherheitskarte über den Zahlungsserver erhalten wurde, umfasst, wodurch eine Transaktion bestätigt wird und wodurch der Meldungsverkehr vom Zahlungsserver sowie zwischen dem Zahlungsserver und der Sicherheitskarte reduziert wird.
Computer-implementiertes Verfahren zum Verkaufen von Waren über ein Netzwerk (202) unter Verwendung eines Händlerservers (208), wobei die Waren für den Kauf durch einen Benutzer mit einer Guthabenkarte (5) vorgesehen sind, umfassend: das Herstellen der Kommunikation (234) zwischen dem Händlerserver (208) und einem Kunden (204) über das Netzwerk; den Empfang einer Anforderung vom Kunden (204) zum Kauf eines vom Händlerserver (208) verfügbaren Postens; das Übertragen eines Kaufbetrags für den Posten an den Kunden, so dass der Kunde unter Verwendung von Informationen, die von einer Guthabenkarte erhalten werden, eine Abbuchungsanforderungsmeldung (310) erstellen und bei Erhalt eines Abbuchungsbefehls (314) von einer Sicherheitskarte (220) diesen Betrag von der dem Kunden zugewiesenen Guthabenkarte abbuchen kann; gekennzeichnet durch das Übertragen (236) des Betrags, einer Transaktionskennung und einer Händlerkennung an einen mit dem Netzwerk verbundenen Zahlungsserver (206), wobei der Zahlungsserver der Sicherheitskarte zugewiesen ist, die einen für die Guthabenkarte bestimmten Abbuchungsbefehl erstellt und den Kauf des Postens sichert, wobei die Transaktionskennung den Kauf des Postens und die Händlerkennung den Händlerserver eindeutig beim Zahlungsserver identifiziert; und durch einen Bestätigungsschritt (238) zum Durchführen des Bestätigungsvorgangs des Kaufs des Postens beim Händlerserver, wodurch der Händlerserver darüber informiert wird, dass der Verkauf des Postens erfolgreich war und der Händlerserver den Posten an den mit der Guthabenkarte verbundenen Benutzer ausgeben kann.
Verfahren nach Anspruch 9, wobei es sich bei dem Netzwerk um ein Internet (202) handelt, über das die genannten Schritte des Verfahrens ausgeführt werden, wobei der Händlerserver eine Händlerwebseite zum Bewerben der Ware über das Internet umfasst, und wobei sich das Kundenterminal (204) und der Händlerserver (208) an unterschiedlichen Standorten befinden.
Verfahren nach Anspruch 9 oder 10, weiterhin umfassend: das Übertragen eines ersten Schlüssels an den Kunden zum Verschlüsseln einer vom Kundenterminal an den Zahlungsserver zu sendenden Abbuchungsanforderungsmeldung; das Bereitstellen des ersten Schlüssels zum Entschlüsseln der an den Zahlungsserver gesendeten, verschlüsselten Abbuchungsanforderungsmeldung, ohne dass der erste Schlüssel in offener Form an den Zahlungsserver gesendet wird; und das Empfangen einer verschlüsselten Bestätigungsmeldung für die Transaktion vom Zahlungsserver, die anhand eines zweiten Schlüssels verschlüsselt wird, der vom Händlerserver und vom Zahlungsserver gemeinsam verwendet wird.
Verfahren nach einem der Ansprüche 9 bis 11, wobei der Schritt des Übertragens des Kaufbetrags und der Schritt des Bestätigens über den Kunden geroutet werden, um so eine Kommunikation zwischen dem Händlerserver und dem Zahlungsserver bereitzustellen, wodurch die Anzahl der Kommunikationsverbindungen reduziert wird.