DE69431306T2

DE69431306T2 - Datennetzgestütztes zahlungssystem und verfahren zum gebrauch eines derartigen systems

Info

Publication number: DE69431306T2
Application number: DE69431306T
Authority: DE
Inventors: K. Gifford
Original assignee: Open Market Inc
Current assignee: Soverain Software (ndgesd Staates Delaware LLC
Priority date: 1993-12-16
Filing date: 1994-12-13
Publication date: 2003-05-15
Anticipated expiration: 2014-12-14
Also published as: JP3367675B2; US6205437B1; JPH10312433A; JP3190881B2; JP3190882B2; US6195649B1; US20100057561A1; JP3260693B2; DE69431306D1; US6199051B1; US5724424A; EP0734556A4; JPH10312434A; EP1235177A3; JPH09500470A; EP0734556A1; WO1995016971A1; JPH1196243A; EP1235177A2; EP0734556B1

Description

Das in letzter Zeit schnelle Wachstum von Informationsanwendungen auf internationalen öffentlichen paketvermittelten Computernetztwerken, wie etwa dem Internet, deutet darauf hin, daß öffentliche Computernetzwerke das Potential haben, eine neue Art eines offenen Marktplatzes für Güter und Dienstleistungen zu etablieren. Ein solcher Markplatz könnte mit einem Netzwerk-Verkaufssystem kreiert werden, das mehrere Käufer- und Händlercomputer, Mittel zur Wiedergabe digitaler Werbeanzeigen der Händlercomputer für die Benutzer der Käufercomputer und Mittel umfaßt, die es den Nutzern gestatten, durch die Werbeanzeigen beschriebene Produkte zu kaufen.
Ein netzwerkbasiertes Verkaufssystem wird es den Nutzern ermöglichen müssen, Produkte zu geringen Kosten oder kostenfrei vorzusichten, und wird eine große Anzahl von Produktanzeigen auf bequeme Weise verfügbar machen müssen. Außerdem wird das Einkaufssystem einfach zu benutzende Einrichtungen aufweisen müssen, die es einem Nutzer ermöglichen, gewünschte Produkte unter Verwendung einer händlerunabhängigen Zahlungsmethode zu kaufen. Weiterhin wird es der Netzwerkhandel neuen Käufern und Händlern ermöglichen müssen, in den Markt einzutreten.
Ein zentrales Erfordernis für einen Marktplatz ist ein Zahlungsmechanismus, doch ist gegenwärtig für Computernetzwerke kein händlerunabhängiger Zahlungsmechanismus verfügbar, der es Nutzern ermöglicht, herkömmliche Finanzinstrumente wie etwa Kreditkarten, Guthabenkarten und Sichteinlagen-Kontoguthaben zu benutzen. Wir erwarten, daß für Netzwerke sowohl Einzelhandels- Zahlungsmechanismen als auch Großhandels-Zahlungsmechanismen benötigt werden, wobei Verbraucher den Einzelhandelsmechanismus für Käufe in kleinerem Umfang benutzen werden, während Institutionen den Großhandelsmechanismus für den Zahlungsausgleich zwischen Handelspartnern benutzen werden. Für eine breite Akzeptanz wird der Einzelhandelsmechanismus eine logische Fortentwicklung bestehender Kreditkarten-, Guthabenkarten- und automatischer Clearingstellen-Einrichtungen sein müssen, während der Großhandelsmechanismus zur Akzeptanz eine weiterentwickelte Version des elektronischen Zahlungsverkehrs zwischen Unternehmen sein müssen wird.
US 4,799,156 beschreibt ein System zur elektronischen interaktiven Online- Kommunikation und zur Verarbeitung von Geschäftstransaktionen zwischen mehreren Typen unabhängiger Nutzer einschließlich mehrerer Käufer, mehrerer Verkäufer sowie Finanzinstitutionen. Durch Benutzung des Systems ist ein Käufer in der Lage, seine Bank anzuweisen, eine Rechnung an einen Händler oder ein anderes Finanzinstitut zu bezahlen.
US 5,025,373 beschreibt ein tragbares persönliches Banktransaktionssystem, das einen Verschlüsselungsalgorithmus für die sichere Datenübertragung zwischen einem Host-Computer einer Bank und einem persönlichen Banktermininal benutzt.
Gemäß einem Aspekt der vorliegenden Erfindung ist ein netzwerkbasiertes Zahlungssystem mit den Merkmalen nach Anspruch 1 vorgesehen. Gemäß einem anderen Aspekt der Erfindung ist ein Verfahren zur Verwendung eines netzwerkbasierten Zahlungssystems vorgesehen, wie es in Anspruch 8 beschrieben wird.
Ein bevorzugtes Merkmal der Erfindung ist es, ein netzwerkbasiertes Zahlungssystem zu schaffen, das Zahlungsanweisungen autorisiert und Händlern einen Teil des Betrugsrisikos abnimmt.
Es ist eine unvermeidbare Eigenschaft öffentlicher Computernetzwerke, daß sie Vermittlungs-, Übertragungs- und Host-Computer-Komponenten umfassen, die durch zahlreiche Einzelpersonen und Organisationen kontrolliert werden. So ist es unmöglich, daß ein netzwerkbasiertes Zahlungssystem von einem spezifizierten erforderlichen Mindestmaß an Software, Hardware und physikalischer Sicherheit für all die Komponenten in einem öffentlichen Netzwerk abhängig ist. Zum Beispiel können geheime Schlüssel, die im Personalcomputer eines gegebenen Nutzers gespeichert sind, gefährdet sein, Vermittlungsstellen können so manipuliert sein, daß sie den Verkehr umleiten, und Übertragungseinrichtungen können abgehört und manipuliert werden.
Das Risiko bei der Durchführung von Einzelhandels-Zahlungen in einem öffentlichen Netzwerk wird verstärkt durch Gesetze, die einen Betreiber eines Zah lungssystems zum Teil für die Sicherheitsmängel seiner Nutzer haftbar machen. Bestehende Bundesgesetze in den Vereinigten Staaten, einschließlich des Electronic Funds Transfer Act und des Consumer Credit Protection Act erfordern, daß der Betreiber eines Zahlungsmechanismus in vielen Fällen die Verbraucherhaftung begrenzt. Die Betreiber von Zahlungssystemen können andere treuhänderische Verantwortlichkeiten für Großhandeltransaktionen haben. Ähnliche Verantwortlichkeiten für Einzelhandels- und Großhandeltransaktionen bestehen auch in anderen Ländern.
Bei bestehenden Kreditkarten-Zahlungssystemen übernimmt eine die Kreditkarten herausgebende Bank das Betrugsrisiko, das mit dem Mißbrauch der Karte verbunden ist, wenn ein Händler die festgelegten Protokolle zur Akzeptierung von Kreditkarten beachtet. Akzeptierungsprotokolle können beinhalten, daß die Unterschrift eines Kreditkarteninhabers auf der Rückseite seiner Karte verifiziert wird und für Zahlungen oberhalb eines bestimmten Betrages eine Autorisierung eingeholt wird. Im netzwerkbasierten Handel kann jedoch ein Händler die Kreditkarte eines Käufers nicht physisch in Augenschein nehmen, und deshalb kann das Betrugsrisiko bei sogenannten Transaktionen mit "nicht vorhandener Karte" auf den Händler zurückfallen. Viele Händler sind aufgrund ihrer begrenzten finanziellen Mittel nicht qualifiziert, dieses Risiko zu übernehmen. Deshalb ist die Erfindung wichtig, um es vielen Händlern zu erlauben, am netzwerkbasierten Handel teilzunehmen.
Weitere bevorzugte Merkmale der Erfindung umfassen die Benutzung bestehender Finanzinstrumente wie etwa Kreditkarten, Guthabenkarten und Sichteinlagenkonten für Händlerzahlungen.
Bestehende netzwerkbasierte Zahlungssysteme sind nicht an das Finanzsystem für Autorisierungen angeschlossen und sind mit herkömmlichen Finanzinstrumenten nicht kompatibel. Bestehende netzwerkbasierte Systeme umfassen das "Simple Network Payment Protocol [Dukach, S. SNPP: A Simple Network Payment Protocol, MIT Laboratory for Computer Science, Cambridge, MA 1993], Sirbu's Internet Billing Server [Sirbu, M. A., Internet Billing Service Design and Prototype Implementation, Information Networking Program, Carnergie-Mellon University, 1993] und NetCash [Medvinsy, G., und Newman, B. C. NetCash: A Design for Practical Electronic Currency on the Internet, Proc. 1st ACM. Conf. on Comp, and Comm. Security, November 1993].
Ein weiteres bevorzugtes Merkmal der Erfindung besteht darin, daß sie es Nutzern ermöglicht, konventionelle Finanzinstrumente in einer ungesicherten Netzwerkumgebung zu verwenden, ohne daß Modifikationen an bestehenden Netzwerken für Finanzsysteme benötigt werden.
Für die vorliegende Erfindung gelten die folgenden Definitionen. Ein Prinzipal ist eine Person, Gesellschaft, Institution oder andere Körperschaft, die dazu autorisiert ist, Geschäftstransaktionen als Teil eines Netzwerk-Zahlungssystems vorzunehmen. Eine Zahlungsanweisung beschreibt die Identität eines Absenders, einen Zahlungsbetrag, einen Zahlungsempfänger und ein bezüglich des Absenders einmaliges Augenblickswort. Ein Absender ist ein Prinzipal, der eine Zahlung vornimmt. Ein Zahlungsempfänger ist ein Prinzipal, an den durch das Zahlungssystem bezahlt werden soll. Ein bezüglich des Absenders einmaliges Augenblickswort ist eine Identifizierung, die von einem gegebenen Absender nur einmal benutzt wird. Ein Beispiel für bezüglich des Absenders einmalige Augenblickswörter sind einmalige Zeitstempel. Ein externes Konto ist ein Konto, das zur Abwicklung einer Zahlungsanweisung für entweder einen Absender oder einen Zahlungsempfänger in dem externen Finanzsystem benutzt werden kann. Beispiele für externe Konten umfassen Sichteinlagenkonten und Kreditkartenkonten. Eine externe Einrichtung ist ein physikalisches Objekt, das zum Zweck der Identifizierung eines Benutzers im Besitz dieses Benutzers bleibt.
Ein netzwerkbasiertes Zahlungssystem ist ein Dienst, der digitale Zahlungsanweisungen, die durch externe Konten gedeckt sind, autorisiert und ausführt. Ein Zahlungssystem authentiziert eine Zahlungsanweisung, führt eine Prüfung auf ausreichendes Guthaben oder Kredit aus und löst dann Transaktionen zur Übertragung von Werten aus, um die Zahlungsanweisung auszuführen. Ein Zahlungssystem bestätigt die Akzeptierung oder Zurückweisung einer Zahlungsanweisung. In einem gegebenen Netzwerk können mehr als ein Zahlungssystem bestehen, und ein gegebenes Zahlungssystem kann auf mehr als einem Host laufen, um seine Zuverlässigkeit, Verfügbarkeit und Leistung zu erhöhen. Eine Authentizierung ist ein digitaler Wert, der an eine Zahlungsanweisung angehängt wird und derjenige Teil der Zahlungsanweisung wird, der die Zahlungsanweisung als echt authentiziert.
Die Erfindung wird nun beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen zeigen:
Fig. 1 ein Blockdiagramm eines typischen netzwerkbasierten Verkaufssystems;
Fig. 2 einen Screenshot einer Übersichtsseite eines Händlercomputers auf dem Display eines Käufercomputers;
Fig. 3 einen Screenshot einer Seite mit digitalen Anzeigen von einem Händlercomputer auf dem Display eines Käufercomputers;
Fig. 4 einen Screenshot einer Seite für eine Kontoanfrage auf dem Display eines Käufercomputers:
Fig. 5 einen Screenshot einer Erfüllungsseite auf dem Display eines Käufercomputers;
Fig. 6 ein Flußdiagramm zur Illustration der Abwicklung eines Kaufes zwischen einem Käufercomputer und einem Händlercomputer;
Fig. 7 ein Flußdiagramm zur Illustration einer alternativen Verarbeitung von Zahlungsanweisungsmitteln zur Einholung von fehlender Zahlungsinformation;
Fig. 8 einen Screenshot einer Übersichtsseite eines Händlercomputers, die eine vom Benutzer eingegebene Anfrage enthält, auf dem Display eines Käufercomputers:
Fig. 9 einen Screenshot digitaler Anzeigen als Antwort auf eine Benutzeranfrage, auf dem Display eines Käufercomputers;
Fig. 10 einen Screenshot einer Kaufbestätigung auf dem Bildschirm eines Käufercomputers;
Fig. 11 einen Screenshot einer Erfüllungsseite wie in Fig. 5 auf einem Käuferdisplay;
Fig. 12 ein Flußdiagramm zur Illustration einer alternativen Abwicklung eines Kaufes zwischen einem Käufercomputer und einem Händlercomputer, bei der eine Zahlungsanweisung vorab autorisiert ist;
Fig. 13 ein Blockdiagramm eines typischen netzwerkbasierten Zahlungssystems in Übereinstimmung mit der Erfindung;
Fig. 14 ein Flußdiagramm zur Illustration der Authentizierung, Autorisierung und Abwicklung einer Zahlungsanweisung;
Fig. 15 ein Flußdiagramm zur Illustration einer alternativen Abwicklung der Authentizierung und Verifizierung einer Zahlungsanweisung, bei der Transaktionskennungen benutzt werden; und
Fig. 16 ein Flußdiagramm einer alternativen Abwicklung der Autorisierung einer Zahlungsanweisung, bei der keine Echtzeit-Zustimmung vom Finanzautorisierungsnetzwerk erhalten werden kann.
Ein netzwerkbasiertes Verkaufssystem 200, wie es in Fig. 1 gezeigt ist, benutzt ein Netzwerk 67 dazu, mehrere Käufercomputer 61 und 62, Händlercomputer 63 und 64, jeder Händlercomputer mit jeweiligen Datenbanken 65 und 66 für digitale Anzeigen, und einen Zahlungscomputer 68 zu verbinden. Ein Nutzer des Systems benutzt einen Käufercomputer, um Anzeigen von den Händlercomputern aufzurufen und interessierende Güter zu kaufen. Ein Zahlungscomputer dient dazu, eine Kauftransaktion zu autorisieren.
Eine digitale Anzeige umfaßt eine Produktbeschreibung und einen Preis. In den Datenbanken 65 für digitale Anzeigen können Preise und Beschreibungen getrennt abgelegt sein und ein Preis kann für zahlreiche Produktbeschreibungen gelten.
In einer alternativen Ausführungsform umfaßt das netzwerkbasierte Verkaufssystem außerdem externe Einrichtungen, die im Besitz von Nutzern bleiben, so daß die Nutzer sich selbst authentizieren können, wenn sie einen Käufercomputer benutzen.
Die Softwarearchitektur, die der speziellen bevorzugten Ausführungsform zugrunde liegt, basiert auf den Hypertext-Konventionen des World Wide Web.
Ein Dokument ist definiert als irgendein Typ digitaler Daten in einem weiten Sinne, beispielsweise Multimediadokumente, die Text, Audio und Video umfassen, und Dokumente, die Programme enthalten.
Fig. 2 zeigt ein Übersichts-Bildschirmbild, das durch einen Käufercomputer von einem Händlercomputer abgerufen wurde und durch den Käufercomputer angezeigt wird. Es enthält Links 1, 2 und 3, die, wenn sie von einem Nutzer aktiviert werden, den Käufercomputer veranlassen, bestimmte Aktionen auszuführen. Im Fall des Links 1 wird das in Fig. 3 gezeigte Dokument von einem Händlercomputer abgerufen und angezeigt. Im Fall des Links 2 wird ein kurzes Audiosegment von einem Händlercomputer abgerufen und abgespielt. Im Fall des Links 3 wird die Anfrage, die im Anfrage-Dialogfeld 4 eingegeben werden kann, an einen Händlercomputer abgesandt, und ein Dokument wird vom Händlercomputer übermittelt und angezeigt.
Fig. 3 zeigt ein Dokument, das drei digitale Anzeigen enthält. Die digitalen Anzeigen sind nach Aktivierung des Links 1 vom Händlercomputer übermittelt worden. Der Händlercomputer kann die in den Anzeigen enthaltenen Preise z. B. anhand der Identität des Nutzers festsetzen, die z. B. durch die Netzwerkadresse des anfragenden Käufercomputers bestimmt ist. Das Dokument umfaßt Links 5, 6 und 7, die dazu benutzt werden, die durch die Anzeigen beschriebenen Produkte zu kaufen. Wenn z. B. das Link 5 aktiviert wird, wird das in Fig. 4 gezeigte Dokument für fehlende Zahlungsinformation vom Händlercomputer übermittelt und angezeigt.
Fig. 4 ist ein Dokument für fehlende Zahlungsinformation, das dazu benutzt wird, Information über das Benutzerkonto für den gewünschten Kauf in einem HTML-Format zusammenzustellen. Radioknöpfe 8, 9, 10, 11, 12 werden dazu benutzt, eine Zahlungsweise auszuwählen, ein Dialogfeld 13 dient zur Eingabe einer Kontonummer, ein Dialogfeld 14 dient zur Eingabe einer wahlfreien Authentizierung für das Konto, ein Kauf-Knopf 15 dient zum Absenden der Konto information an den Händlercomputer und zur Fortführung der Kauftransaktion, ein Link 16 dient zum Verlassen der Kauftransaktion und zum Zurückkehren zu dem in Fig. 2 gezeigten Dokument, und ein Dialogfeld 17 dient zur Eingabe wahlfreier Nutzerinformation, die mit dem Kauf zusammenhängt und letztlich von einem Finanzinstitut als Teil einer textlichen Abrechnungskennung für die Kauftransaktion verwendet wird. Soweit vorhanden, ist diese zusätzliche Information in der Zahlungsanweisung für den Kauf enthalten.
Fig. 5 ist ein Erfüllungsdokument 18, das geliefert wird, wenn für das in Fig. 4 gezeigte Dokument für fehlende Zahlungsinformation gültige Kontoinformation bereitgestellt worden ist, und der Kauf-Knopf 15 aktiviert worden ist.
Fig. 6 ist ein Flußdiagramm, das den Informationsfluß bei der in Fig. 2 bis 5 gezeigten Kauftransaktion vollständiger beschreibt. Eine anfängliche Nutzeranfrage 19 durch Aktivierung des Links 1 führt zu dem HTTP-Aufruf 20 für ein bestimmtes Dokument mit einer bestimmten URL. Die URL spezifiziert den Namen des Händlercomputers. Der Händlercomputer ruft bei 21 das Dokument mit der gegebenen URL ab und übermittelt es bei 22 an den Käufercomputer. Der Käufercomputer zeigt bei 23 das resultierende HTML-Dokument an. Wenn der Nutzer den Link 5 aktiviert, wird an den Händlercomputer ein HTTP-Aufruf 25 gesendet, mit dem das Dokument angefordert wird.
In einer alternativen Ausführungsform wird das Dokument 22 bei 23 als ein Programm ausgeführt. Ein Programm ist definiert als ein Satz von Instruktionen, der auf der Grundlage von Nutzeraktionen oder der Umgebung des Käufercomputers ein konditioniertes Verhalten zeigen kann. Wie dem Fachmann bekannt ist, gibt es zahlreiche Techniken, Programme als Daten darzustellen. Das Programm kann interpretiert oder direkt durch den Käufercomputer ausgeführt werden. Wenn das Programm ausgeführt wird, veranlaßt es den Käufercomputer, mit dem Nutzer zu interagieren, was zu der Kaufanfrage 24 des Nutzers und zur Kaufnachricht 25 führt.
Der Händlercomputer versucht dann, bei 26 eine Zahlungsanweisung zu konstruieren, unter Verwendung der Information, die er über den Nutzer eingeholt hat. Der Käufercomputer kann vorab mit bestimmten Berechtigungsnachweisen ausgestattet worden sein, unter Verwendung von auszufüllenden Formularen oder anderen Mitteln zur Kontoidentifizierung wie z. B. der Bereitstellung der Netzwerkadresse des Käufercomputers im normalen Ablauf der Kommunikation. Wenn der Händlercomputer bei 26 in der Lage ist, eine vollständige Zahlungsanweisung zu konstruieren, wird die Zahlungsanweisung bei 27 zur Autorisierung an einen Zahlungscomputer übermittelt. Wenn eine Zahlungsanweisung konstruiert werden kann, wird der Ablauf bei 28 fortgesetzt.
Alternativ kann der Käufercomputer bei 24 die Zahlungsanweisung konstruieren und sie bei 26 an den Händlercomputer senden. In diesem Fall braucht der Händlercomputer in den Schritten zum Zusammensetzen der Zahlungsanweisung bei 26 nur die vom Käufercomputer erhaltene Zahlungsanweisung weiterzuleiten.
Eine Zahlungsanweisung enthält Nutzer-Kontoinformation, Händler-Kontoinformation, einen Betrag und eine Augenblickswort-Kennung, die vorher noch nicht für dasselbe Nutzerkonto verwendet worden ist. Es können Abwandlungen von Zahlungsanweisungen konstruiert werden, einschließlich Zahlungsanweisungen, die anstelle von Kontoinformation Nutzer- oder Händlerkennungen angeben, Zahlungsanweisungen, die eine Gültigkeitszeitspanne spezifizieren, Zahlungsanweisungen, die Fremdwährungen spezifizieren, und Zahlungsanweisungen, die Kommentar-Zeichenketten enthalten. Ein Teil des Prozesses zur Konstruktion einer Zahlungsanweisung ist die Erzeugung einer entsprechenden Authentizierung unter Verwendung eines der weiter unten beschriebenen Authentizierungsverfahren.
In der gezeigten Ausführungsform nach Fig. 3 und 4 hat der Händlercomputer keine ausreichende Information zur Konstruktion einer Zahlungsanweisung bei 26, und er konstruiert und übermittelt deshalb als Antwort auf die Anfrage 25 bei 33 (Fig. 7) ein Dokument für fehlende Zahlungsinformation.
Die Operation 33 schließt in dem konstruierten Dokument geeignete Formularfelder ein, abhängig davon, welche Information der Händlercomputer bereits vom Benutzer eingeholt hat. Das Dokument wird bei 34 an den Käufercomputer zurückgesendet und bei 35 angezeigt. Wenn der Nutzer den Kauf-Knopf 15 betätigt, wird der Inhalt des Formulars bei 36 unter Verwendung eines HTTP-Aufrufs an den Händlercomputer, an einen bestimmten URL-Namen übermittelt. Auf der Grundlage der übermittelten Formularfelder konstruiert der Händlercomputer eine vollständige Zahlungsanweisung. Alternativ kann der Käufercomputer die Zahlungsanweisung bei 35 konstruieren und sie als Teil des Schrittes 36 an den Händlercomputer senden. In diesem Fall wird in den Schritten 37 zum Zusammensetzen der Zahlungsanweisung auf seiten des Händlercomputers einfach die Zahlungsanweisung vom Käufercomputer weitergeleitet. Die Zahlungsanweisung wird bei 38 in Form einer Nachricht an den Zahlungscomputer gesendet.
In jedem Fall erfolgt die Fortsetzung des Flußdiagramms in Fig. 6, wo der Zahlungscomputer bei 28 die Autorisierung der Zahlungsanweisung prüft. Wenn das Zahlungssystem die Anfrage autorisiert, wird eine Autorisierungsnachricht bei 29 an den Händlercomputer zurückgemeldet, und der Händlercomputer überprüft bei 30, daß die Autorisierungsnachricht von dem Zahlungscomputer gekommen ist, der den weiter unten beschriebenen Autorisierungsmechanismus benutzt. Unter der Annahme, daß die Autorisierungsnachricht gültig ist, erfüllt der Händlercomputer bei 30 den Auftrag und liefert als Antwort bei 31 das gekaufte Produkt aus. In unserem Beispiel in Fig. 5 ist die Antwort bei 31 das Dokument 18, das das logische Ziel des Links 5 war. Wenn das Zahlungssystem die Zahlungsanweisung nicht autorisiert, so ist die Antwort 31 eine Zurückweisung des Kaufauftrags des Nutzers.
In einer alternativen Ausführungsform kann Schritt 30 das Dokument verschlüsseln, mit einem Schlüssel, der dem Käufercomputer bekannt ist. Wie dem Fachmann bekannt ist, kann der Schlüssel durch vereinbarte Schlüsselverteilungsprotokolle an den Händlercomputer kommuniziert werden. Auf diese Weise wird das Dokument gegen Preisgabe an andere Nutzer geschützt.
Der Erfüllungsschritt 30 kann alternativ veranlassen, daß ein physisches Produkt auf normalem Postwege oder auf anderem Wege versandt wird. Dies kann dadurch erreicht werden, daß eine Erfüllungsanfrage-Datenbank aktualisiert wird, oder indem eine Nachricht an ein Versandsystem übermittelt wird. In diesem Fall ist die Antwort bei 31 eine Bestätigung, daß das Produkt zum Versand aufgegeben worden ist. Auf diese Weise kann das Netzwerk-Verkaufssystem ein elektronisches Post-Bestellsystem implementieren.
Fig. 8, 9, 10 und 11 zeigen ein zweites Beispiel, das mit anfragebasiertem Zugriff auf digitale Anzeigen arbeitet. Es wird angenommen, daß das vorherige Beispiel von dem Nutzer unmittelbar zuvor an demselben Käufercomputer be nutzt worden ist.
Fig. 8 zeigt den Übersichtsbildschirm, wo die Anfrage "Movie Review" (Filmrevue) im Dialogfeld 39 eingegeben worden ist. Wenn der Nutzer den Knopf 40 "process" (bearbeiten) betätigt, durchsucht der Händler die Datenbanken, wie durch die mit dem Knopf 40 verbundene URL beschrieben wird, und erzeugt ein Antwortdokument, wie es in Fig. 9 gezeigt ist.
Fig. 9 zeigt digitale Anzeigen 39, 40, 41, 42, 43 und 44, die auf die durch den Knopf 40 ausgelöste Anfrage gefunden wurden. Ein Rollbalken 45 zeigt, daß es noch weitere digitale Anzeigen gibt, die nicht gezeigt werden. Wenn das Link 46 aktiviert wird, wird das in Fig. 10 gezeigte Dokument für fehlende Kontoinformation vom Händlercomputer übermittelt.
Fig. 10 zeigt, daß der Händlercomputer unvollständige Information über das Konto des Käufers hat. Die Nachricht 47 zeigt, daß der Händlercomputer die Kontonummer des Käufers bereits kennt. Der Knopf 48 "purchase" (kaufen) bewirkt das Senden der wahlfreien Nutzer-Betreffzeichenkette im Dialogfeld 50 an den Händlercomputer, der durch die URL hinter dem Knopf 48 beschrieben wird, sowie den Kauf des Produkts entsprechend der digitalen Anzeige 39. Das Link 49 "cancel" (löschen) bringt den Nutzer in das in Fig. 2 gezeigte Dokument zurück.
Wenn der Kauf-Knopf 48 aktiviert wird, wird vom Händlercomputer ein Dokument 51 gesendet und vom Käufercomputer angezeigt, wie in Fig. 11 gezeigt ist.
Fig. 12 zeigt ein alternatives Verfahren zur Abwicklung einer Kauftransaktion. Wenn bei diesem Verfahren der Nutzer bei 52 einen Kauf aufruft, konstruiert der Käufercomputer bei 53 eine Zahlungsanweisung und sendet sie zur Zustimmung an den Zahlungscomputer 54. Der Zahlungscomputer autorisiert die Zahlungsanweisung bei 55, und wenn die Zahlungsanweisung autorisiert ist, meldet er bei 56 ein unfälschbares Zertifikat zurück, daß die Zahlungsanweisung gültig ist. Mittel zur Erzeugung eines solchen unfälschbaren Zertifikats werden weiter unten in dem Authentizierungsverfahren Nr. 1 beschrieben. Wenn die Zahlungsanweisung in Schritt 55 nicht autorisiert wird, wird bei 56 eine Zurückwei sungsnachricht gesendet, und die Verkaufstransaktion ist beendet.
Der Käufercomputer fährt dann bei 57 fort, indem er eine vorautorisierte Kaufanfrage an den Händlercomputer sendet. Das unfälschbare Zertifikat 56 ist in einer Kaufnachricht 57 enthalten, die bei 58 an den Händlercomputer gesendet wird. Auf der Grundlage der vorautorisierten Zahlungsanweisung erfüllt der Händlercomputer bei 59 den Auftrag und übermittelt bei 60 das Produkt. Gemäß einer Abwandlung führt der Händlercomputer bei 59 eine Überprüfung durch, um sicherzustellen, daß die Zahlungsanweisung noch nicht früher benutzt worden ist. Dies kann erreicht werden durch Abgleich mit einem Zahlungscomputer oder durch Pflege einer Datenbank früher akzeptierter Zahlungsanweisungen im Händlercomputer. Das in Schritt 56 erzeugte unfälschbare Zertifikat braucht nicht die Kontoinformation des Nutzers zu enthalten. Diese Variante ist nützlich, wenn der Nutzer Käufe tätigen und gegenüber dem Händler anonym bleiben will.

Ein netzwerkbasiertes Zahlungssystem

Ein netzwerkbasiertes Zahlungssystem 300, wie es in Fig. 13 gezeigt ist, benutzt ein öffentliches paketvermitteltes Netzwerk 69 dazu, mehrere Klientencomputer 70 und 71 und mehrere Zahlungscomputer wie z. B. 72 zu verbinden, wobei jeder Zahlungscomputer eine Konten-Datenbank 73, eine Abwicklungsdatenbank 74, eine Datenbank 75 mit autorisierten Adressen, eine Datenbank 76 für Absender-Berechtigungsnachweise, eine Finanzsystem-Schnittstelle 77 und eine Echtzeit-Autorisierungsschnittstelle 78 aufweist. Die Schnittstellen 77 und 78 können durch eine einzige Kommunikationsleitung implementiert sein.
In einer alternativen Ausführungsform umfaßt das netzwerkbasierte Zahlungssystem außerdem externe Einrichtungen, die im Besitz von Nutzern bleiben, so daß die Nutzer sich selbst authentizieren können, wenn sie einen Käufercomputer benutzen.
Die Konten-Datenbank 73 speichert temporäre Auszahlungsbeträge, etwa den am aktuellen Tag ausgezahlten Betrag, und speichert auch temporäre Auszahlungsgrenzen. Die Konten-Datenbank kann auch eine Übersetzung zwischen Prinzipal-Kennungen und externen Kontokennungen unterstützen. Die Abwicklungsdatenbank 74 zeichnet verfügte Zahlungsanweisungen zusammen mit et waiger Autorisierungsinformation für die Anweisungen auf, die von der Schnittstelle 78 erhalten wurde. Die Adressen-Datenbank 75 speichert für jeden Absender eine Liste von autorisierten Käufercomputer- und Zustelladressen. Die Berechtigungsnachweis-Datenbank 76 speichert eine Liste von Berechtigungsnachweisen für Prinzipale sowie Information, die zur Authentizierung der Prinzipale benutzt werden kann.
Fig. 14 ist ein Flußdiagramm, das die Arbeitsweise des Zahlungssystems beschreibt. Ein Klientencomputer 71 erzeugt bei 79 eine Zahlungsanweisung und berechnet bei 80 eine Authentizierung und hängt sie an die Zahlungsanweisung an. Die Zahlungsanweisung wird bei 81 an einen Zahlungscomputer übermittelt, wo die Authentizierung bei 82 verifiziert wird, um sicherzustellen, daß die Zahlungsanweisung von dem Absender stammt, den sie angibt.
Nachstehend stellen wir verschiedene Mittel zur Implementierung der Schritte 80 und 82 vor.
Wenn die Zahlungsanweisung authentisch ist und, bei 83, Adressenbeschränkungen gewünscht werden, so werden die Klientencomputer-Adresse oder die angegebene Zustelladresse oder beide mit der Adreßdatenbank 75 abgeglichen. Wenn Adressenbeschränkungen gewünscht werden und die Adresse in der Zahlungsanweisung nicht in der Datenbank vorhanden ist, sendet der Zahlungscomputer eine Zurückweisungsnachricht an den Klientencomputer. Die Adreßdatenbank 75 spezifiziert für jeden Prinzipal akzeptable Klientencomputer- Adressen und Zustelladressen. Eine Zustelladresse kann ein Netzwerkadresse oder eine postalische Adresse für Paketgüter sein. Wie bekannt ist, kann die Datenbank 75 Platzhalterspezifikationen und ähnliche Techniken zur Verringerung ihrer Größe einschließen.
Zum Beispiel könnte die Datenbank 75 für die Prinzipalkennung "*@acme.com" einen Eintrag enthalten, der legale Zustelladressen beschränkt auf "computer: *.com, "computer: cmu.edu" und "surface: *, 34 Main Street, Anytown, USA" und angibt, daß irgendein Nutzer mit dem Firmennamen Acme Produkte bestellen kann, die an die Neztwerkadresse bei Acme oder der Universität CMU zuzustellen sind oder an irgend jemanden in 34 Main Street, Anytown, USA.
Wenn Adressenbeschränkungen in der Zahlungsanweisung nicht gewünscht sind oder überprüft worden sind, wird die Bearbeitung bei 84 fortgesetzt, wo die Zahlungsanweisung auf Wiedergabe einer Aufzeichnung und auf temporäre Auszahlungsbeschränkungen geprüft wird. Die Prüfung auf Wiedergabe einer Aufzeichnung erfolgt, indem sichergestellt wird, daß der Absender nicht schon früher eine Zahlungsanweisung mit demselben Augenblickswort präsentiert hat, durch Überprüfung eines Index von verfügten Zahlungsanweisungen nach Augenblickswörtern in der Abwicklungsdatenbank 74. Wenn Augenblickswörter zeitbasiert sind, so kann eine Zahlungsanweisung, die älter ist als ein administrativ bestimmter Wert, sofort zurückgewiesen werden. Zeitbasierte Augenblickswörter oder sequentielle Augenblickswörter ermöglichen es, daß alte Augenblickswörter aus der Abwicklungsdatenbank 74 entfernt werden. Wenn eine Zahlungsanweisung schon früher bearbeitet worden ist oder ihr Augenblickswort zu alt ist, sendet der Zahlungscomputer eine Zurückweisungsnachricht an den Klienten. Nachdem die Zahlungsanweisung die Überprüfung auf Wiedergabe einer Aufzeichnung passiert hat, werden temporäre Auszahlungsbeschränkungen in der Konten-Datenbank 73 geprüft. Diese Auszahlungsbeschränkungen können für einen einzelnen Absender, eine Gruppe von Absendern oder für eine Zahlungsweise gelten, um das Betrugsrisiko zu begrenzen. Die Beschränkungen können für eine beliebige Zeitdauer gelten, z. B. ein maximaler Auszahlungsbetrag pro Stunde oder pro Tag. Wenn die Zahlungsanweisung die Auszahlungsbeschränkung verletzten würde, sendet der Zahlungscomputer eine Zurückweisungsnachricht an den Klienten.
Wenn die Zahlungsanweisung die Prüfung auf temporäre Auszahlungsbeschränkungen bei 84 passiert hat, wird bei 85 eine Nachricht erzeugt, die zur Überprüfung dient, daß das externe Konto, das die Deckung für das Zahlungssystem- Konto des Absenders bietet, ausreichend Guthaben oder Kredit hat. Wenn die Absenderkennung in der Zahlungsanweisung nicht bereits eine Kontonummer in dem externen Finanzsystem ist, wird sie mit Hilfe der Konten-Datenbank 73 in eine entsprechende Kontonummer in dem externem Finanzsystem übersetzt. Bei 86 wird eine Echtzeit-Autorisierungsanfragenachricht über die Schnittstelle 78 an das externe Finanzsystem gesendet. Wenn das externe Finanzsystem die Autorisierungsanfrage 86 bestätigt, wird bei 87 eine Autorisierungsnachricht zurückgesendet. Wenn die Anfrage 86 nicht bestätigt wird, sendet der Zahlungscomputer bei 87 eine Zurückweisungsnachricht an den Klienten.
Gemäß einer Abwandlung des oben beschriebenen Ansatzes wird die Bearbei tung nach 84 bei 95 fortgesetzt. Bei 95 wird eine Echtzeit-Autorisierung nur dann eingeholt, wenn die Gesamtsumme der Zahlungen des Absenders seit der letzten Echtzeit-Autorisierung einen voreingestellten Wert erreicht oder die Zahlungsanweisung über einem voreingestellten Wert liegt. Diese voreingestellten Werte können wahlweise für jeden Prinzipal in der Datenbank 73 aufgezeichnet sein oder für alle Prinzipale administrativ bestimmt werden. Auf diese Weise kann die Anzahl von Nachrichten an das externe Finanzsystem reduziert werden. Außerdem kann das Zahlungssystem vermeiden, daß Echtzeit-Autorisierungsanfragen für kleine Zahlungsbeträge gemacht werden, wenn das Risiko für den Betreiber des Zahlungssystems akzeptabel ist. Wenn eine Echtzeit-Autorisierung notwendig ist, wird die Bearbeitung nach Schritt 95 bei 85 fortgesetzt. Wenn für eine Anfrage keine Echtzeit-Autorisierung notwendig ist, wird bei 100 der Betrag der Zahlungsanweisung zu der Gesamtsumme der Zahlungen des Absenders seit der letzten Echtzeit-Autorisierung in der Datenbank 73 addiert, und die Bearbeitung wird mit 88 fortgesetzt.
Gemäß einer weiteren Abwandlung wird nach Schritt 100 bei 101 in der Datenbank 73 geprüft, ob ein Hintergrund-Autorisierungsprozeß angelegt werden soll. Ein Hintergrund-Autorisierungsprozeß ermöglicht es dem Zahlungscomputer, seine normale Bearbeitung fortzusetzen, während er mit dem Finanzautorisierungsnetzwerk das Konto des Absenders prüft. Dieser Mechanismus kann dazu benutzt werden, das Risiko des Zahlungssystems zu begrenzen. Wenn die Hintergrundautorisierung fehlschlägt, wird das Konto gesperrt, indem die Datenbank 73 entsprechend aktualisiert wird. Wenn die Gesamtsumme der Zahlungen des Absenders seit der letzten Autorisierung über einem voreingestellten Wert liegt, der in 73 gespeichert ist, so wird bei 102 ein Hintergrund-Autorisierungsprozeß angelegt. Andernfalls wird die Bearbeitung bei 88 fortgesetzt.
Gemäß einer weiteren Abwandlung werden bei 95 und 101 Autorisierungen auf der Grundlage des seit der letzten Autorisierung ausgegebenen Betrages und der Zeit seit der letzten Autorisierung eingeholt.
Bei 88 wird die Ausführung der Zahlungsanweisung verfügt und in der Abwicklungsdatenbank 74 aufgezeichnet. Zusammen mit der Zahlungsanweisung werden in der Datenbank 74 die Teile der Authentizierungsnachricht 87 aufgezeichnet, die zeigen, daß der Zahlungscomputer das externe Finanzsystem kontaktiert hat. Der Betrag der Zahlungsanweisung wird zu dem laufenden temporä ren Speicherwert für Auszahlungen in der Datenbank 73 addiert, und eine Autorisierungsnachricht wird bei 90 an den Klientencomputer gesendet. Die Autorisierungsnachricht enthält die Zahlungsanweisung. In einer alternativen Ausführungsform enthält die Autorisierungsnachricht bei 90 eine verkürzte Zahlungsanweisung, die wenigstens den Absender der Zahlungsanweisung und das einmalige Augenblickswort der Zahlungsanweisung enthält.
In einer alternativen Ausführungsform enthält die bei 90 an den Klienten gesandte Autorisierungsnachricht wenigstens eine legale Zustelladresse des Absenders, die anhand der Datenbank 75 bestimmt wird.
Die Autorisierungsnachricht 90 muß in solcher Weise übermittelt werden, daß der Klientencomputer sicher sein kann, daß sie vom Zahlungscomputer kommt. Bei 89 wird eine für das Zahlungssystem spezifische Authentizierung an die Zahlungsanweisung angehängt. Bei 91 wird diese Authentizierung vom Klientencomputer geprüft. Die Schritte bei 89 sind dual zu Schritt 80, und die Schritte bei 91 sind dual zu Schritt 82. Die Authentizierungsmittel für die Schritte 89 und 91 werden weiter unten beschrieben.
Schließlich wird bei 92 die Abwicklung in dem externen Finanzsystem 77 zwischen den externen Konten ausgeführt, die dem Absender und dem Zahlungsempfänger entsprechen. Wenn die Abwicklung als Teil der Echtzeit-Autorisierung in den Schritten 86 und 87 vollzogen wird, wie es in einem Echtzeit-Abrechnungsnetzwerk vorkommen kann, brauchen keine weiteren Schritte unternommen zu werden. Wenn die Abwicklung nicht als Teil des Autorisierungsprozesses vollzogen wurde, so werden Finanzsystem-Nachrichten an die Schnittstelle 77 übermittelt, um die Abwicklung auszuführen. Je nach den beteiligten externen Konten können diese Nachrichten elektronische Guthabenübertragungsnachrichten oder Nachrichten für automatische Clearingstellen umfassen
In einer alternativen Ausführungsform werden bei 92 Abwicklungsnachrichten übermittelt, um Netto-Überweisungssalden zwischen Prinzipalen auf einer Zeitbasis abzugleichen, z. B. einmal pro Tag. In dieser Ausführungsform kann die Anzahl von Abwicklungsnachrichten kleiner sein als die Anzahl von Zahlungsanweisungen.
Gemäß Ansprüchen 1 und 8 werden Authentizierungen nach einem der folgen den ersten, zweiten oder dritten Verfahren erzeugt und geprüft. Weiterhin werden vierte, fünfte, sechste und siebte Verfahren beschrieben, die von dem Zahlungscomputer und dem Klientencomputer zusätzlich in Kombination mit einem der ersten, zweiten und dritten Verfahren verwendet werden können.
Bei einem ersten Verfahren für Authentizierungen wird in Schritten 80 oder 89 eine Kurzfassung der Zahlungsanweisung von dem absendenden Computer mit Hilfe eines kryptographischen Systems mit öffentlichem Schlüssel wie etwa RSA signiert. Diese Signatur wird als Authentizierung verwendet. Wie bekannt ist, kann die Signatur mit Hilfe eines privaten Schlüssels vollzogen werden, der aus einem Paar öffentlicher Schlüssel erzeugt wird, wobei der Signaturschlüssel nur dem Unterzeichner und der andere öffentliche Schlüssel nur dem empfangenden Computer bekannt ist. Im Zahlungscomputer ist der zu jedem Absender gehörende öffentliche Schlüssel in seiner Berechtigungsnachweis-Datenbank 76 gespeichert. Der private Schlüssel für den Zahlungsdienst ist ebenfalls in der Datenbank 76 gespeichert. In Schritten 82 oder 91 wird die Signatur der empfangenen Nachricht mit Hilfe des öffentlichen Schlüssels geprüft, der dem empfangenden Computer bekannt ist.
In einem zweiten Verfahren für Authentizierungen wird in Schritten 80 oder 89 eine Kurzfassung der Zahlungsanweisung durch den absendenden Computer mit einem Verschlüsselungssystem mit privatem Schlüssel wie etwa DES signiert. Diese Signatur wird als die Authentizierung benutzt. Im Zahlungscomputer ist der private Schlüssel für jeden Absender in der Berechtigungsnachweis- Datenbank 76 gespeichert. In Schritt 80 wird eine Kurzfassung der Zahlungsanweisung durch den Klientencomputer signiert, und in Schritt 89 wird eine Kurzfassung der Zahlungsanweisung mit einem angehängten Bestätigungscode durch den Zahlungscomputer mit Hilfe desselben privaten Schlüssels signiert. In Schritten 82 oder 91 wird die Signatur der empfangenen Nachricht anhand des gemeinsamen privaten Schlüssels geprüft.
In einem dritten Verfahren für Authentizierungen wird in Schritt 80 die Authentizierung durch eine geschützte Einrichtung außerhalb des Systems, etwa durch eine Smart-Card berechnet. Eine geschützte Einrichtung ist speziell darauf ausgelegt, daß sie äußerst schwierig zu replizieren und zu manipulieren ist. Bei diesem Verfahren wird die Zahlungsanweisung bei 80 an eine Smart-Card kommuniziert. Die Smart-Card berechnet und signiert eine Kurzfassung der Zahlungs anweisung und sendet dann bei 80 die Signatur zurück, so daß sie als eine Authentizierung verwendet werden kann. Eine von einer Smart-Card erzeugte Authentizierung ordnet eine Zahlungsanweisung eindeutig der sie erzeugenden Smart-Card zu. Dies wird dadurch erreicht, daß die Smart-Card einen geheimen Schlüssel "K" enthält, der zur Erzeugung einer digitalen Signatur der Zahlungsanweisung verwendet wird. "K" wird nie außerhalb der Smart-Card preisgegeben. Die Smart-Card ist so ausgelegt, daß sie es rechnerisch unmöglich macht, "K" zu berechnen, selbst wenn man im Besitz der Einrichtung ist. Bei diesem Verfahren wird in Schritt 82 ein Signaturprüfschlüssel aus der Datenbank 76 zur Überprüfung der Authentizierung benutzt. In einer alternativen Ausführungsform muß ein Nutzer seine Zustimmung zu jeder Zahlungsanweisung von Hand an einer Eingabeeinrichtung eingegeben, die Teil der externen Einrichtung ist, bevor die Authentizierung von der externen Einrichtung erzeugt wird.
In einem vierten Verfahren für Authentizierungen, zur Verwendung mit einem der ersten bis dritten Verfahren, wird in Schritten 80 oder 89 eine Netzwerkadresse als eine Authentizierung benutzt. In Schritten 82 oder 91 wird eine Kurzfassung der Zahlungsanweisung zusammen mit einem Zufalls-Paßwort an die spezifizierte Netzwerkadresse zurückgesendet. Der Computer an der spezifizierten Netzwerkadresse muß dann die Kurzfassung der Zahlungsanweisung zusammen mit dem Paßwort zurückmelden. Wenn das Netzwerk sicherstellt, daß Nachrichten an die richtige Netzwerkadresse ausgeliefert werden, garantiert dieses Verfahren, daß der Nutzer oder Computer an der spezifizierten Netzwerkadresse die Zahlungsanweisung bestätigt. Unter der Annahme, daß die Zustellung über das Netzwerk zuverlässig ist, kann dieses Verfahren dazu benutzt werden, die Netzwerkadresse eines Absender-Computers in einer Zahlungsanweisung zu authentizieren. Alternativ kann elektronische Post dazu benutzt werden, solche Bestätigungsnachrichten zwischen einem Nutzer und dem Zahlungssystem zu übermitteln.
In einem fünften Verfahren für Authentizierungen, zur Verwendung mit einem der ersten bis dritten Verfahren, wird in Schritt 80 die Authentizierung von einer externen Einrichtung erzeugt, die eine Folge nicht vorhersagbarer Transaktionskennungen erzeugt, die für diese Einrichtung spezifisch sind. Die Authentizierung wird durch den Nutzer in den Klientencomputer eingegeben, indem er dessen Anzeige liest. Eine solche Einrichtung wird in dem US-Patent 4,856,062 beschrieben. Bei diesem Verfahren kann in Schritt 91 die Authentizierung mit Hil fe des absenderspezifischen festen Codes der Einrichtung geprüft werden, wobei der Code in der Datenbank 76 gespeichert ist. Diese Abfolge von Schritten ist auch in Fig. 15 bei den Schritten 93 und 94 gezeigt.
In einem sechsten Verfahren für Authentizierungen, zur Verwendung mit einem der ersten bis dritten Verfahren, wird in Schritt 80 die Authentizierung erzeugt, indem der Nutzer zur Eingabe einer Transaktionskennung aufgefordert wird, bei der es sich um die nächste Zeichenkette aus einer physischen Liste von Einmal- Autorisierungszeichenketten handelt. Eine solche Liste kann auf einer Karte wiedergeben sein, und der Nutzer kann Autorisierungszeichenketten durchstreichen, wenn sie benutzt werden. Bei diesem Verfahren wird in Schritt 91 die Authentizierung mit Hilfe der Datenbank 76 mit der nächsten vom Absender erwarteten Zeichenkette verglichen. Die Datenbank 76 kann für jeden Absender eine Liste von Zufalls-Autorisierungszeichenketten speichern oder kann einen absenderspezifischen geheimen Schlüssel speichern, der zur Erzeugung der Liste der Autorisierungszeichenketten benutzt wurde, zusammen mit Information darüber, wieviele Zeichenketten bisher benutzt worden sind. Diese Abfolge von Schritten ist auch in Fig. 15 bei 93 und 94 gezeigt.
In einem siebten Verfahren für Authentizierungen, zur Verwendung mit einem der ersten bis dritten Verfahren, ist in Schritt 80 die Authentizierung eine zuvor vergebene persönliche Identifizierungsnummer (PIN) für den Nutzer. Bei diesem Verfahren wird in Schritt 91 die Authentizierung mit Hilfe der Datenbank 76 mit der erwarteten PIN für den Absender verglichen.
Wie für den Fachmann auf der Hand liegt, können beliebige der Verfahren zur Erzeugung von Authentizierungen in Kombination verwendet werden, um die Sicherheit des Systems zu steigern. Zum Beispiel kann das sechste Authentizierungsverfahren dazu benutzt werden, eine Authentizierung auf der Grundlage einer Transaktionskennung zu erzeugen, und dann kann eine Zahlungsanweisung, die eine Transaktionskennung enthält, eine weitere Authentizierung mit Hilfe des ersten Authentizierungsverfahrens erhalten. Bei diesem Beispiel würden die resultierenden Authentizierungen gemäß ihren jeweiligen Verfahren geprüft.
Eine Kurzfassung einer Zahlungsanweisung kann mit einem Algorithmus erzeugt werden wie z. B. MD5 [R. Rivest, The MD5 Message-Digest Algorithm, MIT Laboratory for Computer Science, Network Working Group Request for Comments 1321]. Alternativ kann eine Kurzfassung die gesamte Zahlungsanweisung sein oder Funktionen von Bestandteilen der Zahlungsanweisung.
Weiterhin können sowohl bei Verkaufs- als auch bei Zahlungssystemen alternative Authentizierungstechniken verwendet werden, wie sie z. B. von Voydock und Kent in "Security Mechanisms in High-level Network Protocols", Computing Surveys Band. 15, Nr. 2, Juni 1983, beschrieben werden. Wie der Fachmann erkennt, können unsere nachrichtenbasierten Authentizierungen ersetzt werden durch zwei-wege-authentizierte Byte-Stream oder Fernverarbeitungs-Anrufschnittstellenverbindungen, die Schutz gegen das Abspielen von Aufzeichnungen bieten.

Claims

1. Netzwerkgestütztes Zahlungssystem (300) mit:

mehreren Klientencomputern (70, 71),

wenigstens einem Zahlungscomputer (72),

wobei die Klientencomputer und der Zahlungscomputer durch ein öffentliches paketvermitteltes Kommunikationsnetzwerk (69) verbunden sind, und

einem Finanzautorisierungsnetzwerk (via 78) außerhalb des öffentlichen paketvermittelten Kommunikationsnetzwerks (69), das dazu programmiert ist, die Zahlung eines Zahlungsbetrages auf der Grundlage eines externen Kreditkartenkontos oder eines externen Sichteinlagenkontos mit ausreichendem Kredit oder Guthaben zu autorisieren,

wobei jeder der Klientencomputer (70, 71) dazu programmiert ist, eine Zahlungsanweisung zu konstruieren, die einen von einem Absender an einen Zahlungsempfänger zu transferierenden Zahlungsbetrag, ein Augenblickswort, eine Absenderkennung oder -kontoinformation und eine Zahlungsempfängerkennung oder -kontoinformation spezifiziert, die Zahlungsanweisung mit einer digitalen Signatur einer Kurzfassung der Zahlungsanweisung zu signieren, welche digitale Signatur den Absender der Zahlungsanweisung authentiziert, wobei die digitale Signatur auf der Basis eines geheimen Schlüssels berechnet wird, zu veranlassen, daß die Zahlungsanweisung und die digitale Signatur über das öffentliche paketvermittelte Kommunikationsnetzwerk (69) an den Zahlungscomputer übermittelt werden, und eine Zahlungsanweisungs-Autorisierungsnachricht vom Zahlungscomputer zu empfangen,

wobei der Zahlungscomputer (72) dazu programmiert ist, die Zahlungsanweisung und die digitale Signatur zu empfangen und als Reaktion darauf anhand der empfangenen digitalen Signatur zu verifizieren, daß die Zahlungsanweisung vom Absender der Zahlungsanweisung stammt, eine Überprüfung auf Wiedergabe einer Aufzeichnung durchzuführen, um sicherzustellen, daß der Absender der Zahlungsanweisung nicht früher eine Zahlungsanweisung mit demselben Augenblickswort präsentiert hat, zu veranlassen, daß eine Nachricht in das Finanzautorisierungsnetzwerk übermittelt wird, um zu verifizieren, daß der Absender ein adäquates Guthaben oder Kredit hat, als Antwort auf die Nachricht eine Autorisierung vom Finanzautorisierungsnetzwerk zu empfangen, eine Zahlungsanweisungs-Autorisierungsnachricht über das öffentliche paketvermittelte Kommunikationsnetzwerk an den Klientencomputer zu übermitteln, zu ver anlassen, daß Information über die Zahlungsanweisung und die Autorisierung in einer Abwicklungsdatenbank (74) aufgezeichnet wird, und, konditioniert dadurch, daß der Zahlungscomputer die Autorisierung vom Finanzautorisierungsnetzwerk empfängt, ein Finanzsystem-Netzwerk außerhalb des öffentlichen paketvermittelten Kommunikationsnetzwerkes (69) zu veranlassen, Guthaben vom Absender an den Zahlungsempfänger zu transferieren.

2. Netzwerkgestütztes Zahlungssystem nach Anspruch 1, bei dem die Kurzfassung die gesamte Zahlungsanweisung ist.

3. Netzwerkgestütztes Zahlungssystem nach Anspruch 1, bei dem die Kurzfassung eine Funktion von Bestandteilen der Zahlungsanweisung ist.

4. Netzwerkgestütztes Zahlungssystem nach einem der Ansprüche 1 bis 3, bei dem die Zahlungsanweisung eine Zustelladresse enthält und der Zahlungscomputer (72) dazu programmiert ist, zu veranlassen, daß die Zustelladresse gegen eine Datenbank von zulässigen Zustelladressen für den Absender geprüft wird.

5. Netzwerkgestütztes Zahlungssystem nach irgendeinem vorstehenden Anspruch, bei dem der Zahlungscomputer (72) dazu programmiert ist, zu veranlassen, daß wenigstens eine zulässige Zustelladresse für den Absender bestimmt wird, und die Zahlungsanweisungs-Autorisierungsnachricht die wenigstens eine zulässige Zustelladresse enthält.

6. Netzwerkgestütztes Zahlungssystem nach irgendeinem vorstehenden Anspruch, bei dem die Zahlungsanweisungs-Autorisierungsnachricht eine Authentifizierung enthält.

7. Netzwerkgestütztes Zahlungssystem nach irgendeinem vorstehenden Anspruch, bei dem der Klientencomputer (70, 71) dazu programmiert ist, die digitale Signatur mit Hilfe einer externen Einrichtung zu erzeugen, und der Zahlungscomputer (72) dazu programmiert ist, zu verifizieren, daß die digitale Signatur mit Hilfe der externen Einrichtung erzeugt wurde.

8. Verfahren zum Gebrauch eines netzwerkgestützten Zahlungssystems (300) mit mehreren Klientencomputern (70, 71), wenigstens einem durch ein öffentliches paketvermitteltes Kommunikationsnetzwerk (69) verbundenen Zah lungscomputer (72) und einem Finanzautorisierungsnetzwerk außerhalb des öffentlichen paketvermittelten Kommunikationsnetzwerkes (69), mit den Schritten:

Konstruieren einer Zahlungsanweisung (79) an einem der Klientencomputer, die einen von einem Absender an einen Zahlungsempfänger zu transferierenden Zahlungsbetrag, ein Augenblickswort, eine Absenderkennung oder -kontoinformation und eine Zahlungsempfängerkennung oder -kontoinformation spezifiziert, Signieren (80) der Zahlungsanweisung mit einer digitalen Signatur einer Kurzfassung der Zahlungsanweisung, wobei die digitale Signatur den Absender der Zahlungsanweisung authentiziert und auf der Grundlage eines geheimen Schlüssels berechnet wird, und Veranlassen, daß die Zahlungsanweisung und die digitale Signatur über das öffentliche paketvermittelte Kommunikationsnetzwerk (69) an den Zahlungscomputer übermittelt (81) werden,

als Reaktion auf den Empfang der Zahlungsanweisung und der digitalen Signatur durch den Zahlungscomputer, verifizieren (82), daß die Zahlungsanweisung vom Absender der Zahlungsanweisung stammt, anhand der empfangenen digitalen Signatur, Prüfen auf Wiedergabe (84) einer Aufzeichnung, um sicherzustellen, daß der Absender der Zahlungsanweisung nicht früher eine Zahlungsanweisung mit demselben Augenblickswort präsentiert hat, veranlassen, daß eine Nachricht in das Finanzautorisierungsnetzwerk übermittelt (86) wird, um zu verifizieren, daß der Absender ein adäquates Guthaben oder Kredit hat,

wobei das Finanzauthorisierungsnetzwerk die Zahlung des Zahlungsbetrages auf der Grundlage eines externen Kreditkartenkontos oder eines externen Sichteinlagenkontos mit ausreichendem Kredit oder Guthaben autorisiert,

Empfangen (87), am Zahlungscomputer, einer Autorisierung vom Finanzauthorisierungsnetzwerk als Reaktion auf die Nachricht, Übermitteln einer Zahlungsanweisungs-Autorisierungsnachricht (90) vom Zahlungscomputer an den Klientencomputer über das öffentliche paketvermittelte Kommunikationsnetzwerk, Veranlassen, daß Information über die Zahlungsanweisung und Autorisierung in einer Abwicklungsdatenbank (74) aufgezeichnet werden, und Veranlassen eines Finanzsystem-Netzwerks außerhalb des öffentlichen paketvermittelten Kommunikationsnetzwerkes, Guthaben vom Absender an den Zahlungsempfänger zu transferieren, konditioniert dadurch, daß der Zahlungscomputer die Autorisierung vom Finanzautorisierungsnetzwerk empfängt, und

Empfängen der Zahlungsanweisungs-Autorisierungsnachricht am Klientencomputer.

9. Verfahren nach Anspruch 8, bei dem die Kurzfassung die gesamte Zahlungsanweisung ist.

10. Verfahren nach Anspruch 8, bei dem die Kurzfassung eine Funktion von Bestandteilen der Zahlungsanweisung ist.